Join GitHub today
GitHub is home to over 20 million developers working together to host and review code, manage projects, and build software together.
Added README.md. #11
Conversation
ktsakalozos
reviewed
May 25, 2016
| +hosts = {'myservice': <host>} | ||
| +roles = ['myservice-worker', 'myservice-client'] | ||
| +override = {'myservice::somevalue': <somevalue>, ...} | ||
| + |
ktsakalozos
May 25, 2016
Member
I think we need to be more precise here. For examples, the roles are actually the bigtop roles that they do not follow the pattern "'myservice-worker', 'myservice-client'". Instead we should be giving some link to a list of bigtop roles like this one inferred from https://github.com/apache/bigtop/blob/master/bigtop-deploy/puppet/manifests/cluster.pp#L16 . Unfortunately I haven't found an exhaustive list of all bigtop roles. Similarly, the hosts is there to indicate some fqdn the service we deploy might need, again a list of host types that we support would add more value.
petevg
May 25, 2016
I wanted to give a generic example, without being too specific. Does it work to replace "worker" and "client" with something even more generic? For example:
roles = ['myservice-servertype0', 'myservice-servertype1']
petevg
May 25, 2016
... or maybe:
roles = ['some_bigtop_service_worker', 'some_bigtop_service_client', ...]
ktsakalozos
reviewed
May 25, 2016
| +inspecting the "hosts" that you pass to .render_site_yaml, or it can | ||
| +install the specific services that you name in "roles". | ||
| + | ||
| +Of course, Bigtop needs to know how to deploy your service! |
ktsakalozos
May 25, 2016
Member
There are two service deployment methods for bigtop. You can either specify the roles to have a more fine grained control on what is deployed, or you can specify a component for with ultimately an predefined set of roles is configured. Our component deployment path is not well tested, so it might not be functional at the moment.
ktsakalozos
reviewed
May 25, 2016
| + | ||
| +This layer will set the following states: | ||
| + | ||
| + * **`apache-bigtop-base.puppet_queued`** This indicates that puppet |
ktsakalozos
May 25, 2016
Member
I do not know if this state has any practical use for the other layers
johnsca
May 25, 2016
•
Edited 1 time
-
johnsca
May 25, 2016
Owner
-
May 25, 2016
It does have use for charm layers, to allow them to know that the requested puppet apply has been processed (because the state is gone). We're using it in the DataNode layer (and similarly in the NameNode layer) for that purpose. I think it's worth keeping in the documentation.
ktsakalozos
reviewed
May 25, 2016
| + | ||
| +# Actions | ||
| + | ||
| +As of this writing, this layer does not define any actions. |
ktsakalozos
May 25, 2016
Member
There is some unofficial standard way to close the README. We always provide the the contact details of the team. IRC and lists.
petevg
added some commits
May 25, 2016
petevg
changed the title from
[WIP] Added README.md.
to
Added README.md.
May 27, 2016
kwmonroe
merged commit 97c9008
into
master
Jun 1, 2016
added a commit
that referenced
this pull request
Jun 1, 2016
petevg commentedMay 25, 2016
•
Edited 1 time
-
petevg
May 27, 2016
(No longer a WIP -- would like final feedback before merging.)
Outlines basic usage of the layer, with some example code. I patterned
the README after the one in layer-hadoop-client, as it was mentioned
positively in freenode#juju.
@juju-solutions/bigdata