Skip to content

Conversation

@d0zen1
Copy link
Contributor

@d0zen1 d0zen1 commented Jan 19, 2018

Change requiredServices in metainfo.xml

Today we define requiredServices as follows

ZOOKEEPER

In the mpack model we need to categorize the scope of service dependency. We could have an INSTALL time dependency (i.e. we should also install the dependent service) or a RUNTIME dependency (i.e. there should be a running instance of the service in the cluster).

For example HIVE in EDW mpack, will have an install-time dependency on ZOOKEEPER-CLIENT but a RUNTIME dependency on ZOOKEEPER.


ZOOKEEPER-CLIENT
INSTALL


ZOOKEEPER
RUNTIME

Patch was tested manually and with UT

@d0zen1 d0zen1 self-assigned this Jan 19, 2018
@d0zen1 d0zen1 requested a review from vbrodetskyi January 19, 2018 14:14
@asfgit
Copy link

asfgit commented Jan 19, 2018

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/Ambari-Github-PullRequest-Builder/205/
Test FAILed.
Test FAILured.

<service>HDFS</service>
<service>
<name>HDFS</name>
<scope>INSTALL</scope>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you rename "scope" to "type" or "dependencyType"? We might end up adding scope in the future to scope to HOST,CLUSTER etc.

</service>
<service>
<name>HDFS</name>
<scope>INSTALL</scope>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we keep a type=LEGACY for old stack definitions?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think it's necessary, since for old stacks the LEGACY will be the same as the INSTALL type

@mradha25 mradha25 self-requested a review January 23, 2018 21:51
Copy link
Contributor

@mradha25 mradha25 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do we need to change all the metainfo.xml here, considering it will be reworked by the module teams and we will not be using common-services?

@d0zen1
Copy link
Contributor Author

d0zen1 commented Jan 24, 2018

@mradha25 this is needed as long as we support the old stacks, but when we move to only modules architecture old files will be deleted

@d0zen1
Copy link
Contributor Author

d0zen1 commented Jan 24, 2018

Created new PR from the forked repo : #181
Closing this one.

@d0zen1 d0zen1 closed this Jan 24, 2018
@d0zen1 d0zen1 deleted the AMBARI-22815-branch-feature-AMBARI-14714 branch January 24, 2018 13:42
prabhjyotsingh pushed a commit to prabhjyotsingh/ambari that referenced this pull request Dec 9, 2024
* ODP-2577: kafka mirrormaker2  observability for jmx port

* ODP-2577: kafka mirrormaker2  observability for jmx port

* ODP-2577: kafka mirrormaker2  observability for jmx port-v2

---------

Co-authored-by: Shubham Sharma <shubham@acceldata.io>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants