This issue is similar to #28, but somewhat more general in that the requirements for the successful use of a given role may entail criteria beyond the simple presence of certain packages.
At first, I hadn't placed much effort in tracking the requirements of roles (particularly, how they alter the relationships between the various roles) since I didn't want any roles insisting on the presence of other roles. For example, if someone already has their own hadoop cluster figured out, they should be able to use the girder roles with it without the hadoop-hdfs-xyz roles interfering. The relationships were initially pretty straightforward, too, and I think it's reasonable to expect users to know what they want to provision and what pieces they need to do so.
With the GoBig ansible utilities collection growing, however, the once simple relationships between the roles have started to grow in complexity, and a number of curious interaction effects between them are starting to show themselves.
For example, to provision a mesos cluster, one must provision a set of mesos-master nodes and a set of mesos-slave nodes. The master service requires zookeeper, and so zookeeper must also be provisioned. However, the slave nodes also need zookeeper, but only for the client-side tools that it needs to connect to the quorum. You probably don't want them to install the zookeeper service, unless you want them to be a part of the quorum that doesn't actually manage any slaves (not very useful, and would probably break, anyway). So for a given mesos node, you need to install zookeeper, but leave the service out if the node's a slave -- except for when it's also a master.
Another example that I had just ran into is with spark running over mesos. Suppose you had a core cluster of slave nodes that ran jobs and backed the storage for a hadoop file system. For load balance reasons, you might want a set of mesos masters running separate from that core. The masters run neither hdfs-datanode nor hdfs-namenode services, and yet still require that hadoop be installed locally! The reason is that spark drivers can only run on a mesos master, but the driver process needs the hadoop libraries in order to read from the hdfs. So install hadoop on all the masters, and leave out any services...unless you decide to make one of the masters a namenode, too and/or a datanode, or... hopefully, the idea has gotten across by now.
Now, the roles have been carefully engineered to actually handle all of these cases. This issue is not about failing for some corner case, but is to say that we should spend some effort to fully understand how these roles interact with each other, before their complexity gets out of hand.
I don't know if we should develop anything to help deal with these requirements, but at the very least, I think we should spend more time documenting them, so users aren't trying to figure out what combination they need to address their particular use case.
kotfic
commented
9 years ago
This issue is similar to #28, but somewhat more general in that the requirements for the successful use of a given role may entail criteria beyond the simple presence of certain packages.
At first, I hadn't placed much effort in tracking the requirements of roles (particularly, how they alter the relationships between the various roles) since I didn't want any roles insisting on the presence of other roles. For example, if someone already has their own hadoop cluster figured out, they should be able to use the girder roles with it without the
hadoop-hdfs-xyzroles interfering. The relationships were initially pretty straightforward, too, and I think it's reasonable to expect users to know what they want to provision and what pieces they need to do so.With the GoBig ansible utilities collection growing, however, the once simple relationships between the roles have started to grow in complexity, and a number of curious interaction effects between them are starting to show themselves.
For example, to provision a mesos cluster, one must provision a set of mesos-master nodes and a set of mesos-slave nodes. The master service requires zookeeper, and so zookeeper must also be provisioned. However, the slave nodes also need zookeeper, but only for the client-side tools that it needs to connect to the quorum. You probably don't want them to install the zookeeper service, unless you want them to be a part of the quorum that doesn't actually manage any slaves (not very useful, and would probably break, anyway). So for a given mesos node, you need to install zookeeper, but leave the service out if the node's a slave -- except for when it's also a master.
Another example that I had just ran into is with spark running over mesos. Suppose you had a core cluster of slave nodes that ran jobs and backed the storage for a hadoop file system. For load balance reasons, you might want a set of mesos masters running separate from that core. The masters run neither hdfs-datanode nor hdfs-namenode services, and yet still require that hadoop be installed locally! The reason is that spark drivers can only run on a mesos master, but the driver process needs the hadoop libraries in order to read from the hdfs. So install hadoop on all the masters, and leave out any services...unless you decide to make one of the masters a namenode, too and/or a datanode, or... hopefully, the idea has gotten across by now.
Now, the roles have been carefully engineered to actually handle all of these cases. This issue is not about failing for some corner case, but is to say that we should spend some effort to fully understand how these roles interact with each other, before their complexity gets out of hand.
I don't know if we should develop anything to help deal with these requirements, but at the very least, I think we should spend more time documenting them, so users aren't trying to figure out what combination they need to address their particular use case.