On Tue, Jul 19, 2016 at 3:30 PM, Cory Johns <cory.jo...@canonical.com> wrote: > The individual Jiras that we proposed should be self-contained if we don't > mark them as dependent on another Jira ticket and ready for review if they > have a patch attached.
They depend on the patches that the Bigtop base layer throws in. That connection is not articulated anywhere but in the code of the Bigtop layer. A slightly more esoteric problem is that the Charms I've looked at so far are structured slightly differently. Now, I get the fact that commonality among all the charms is elusive, but perhaps we can at least get to certain commonality in the Bigtop-derived Charms. Here's an example from my recent memory: I remember looking at one Charm implementing tests as a call to smoke-test action and another one just running some code. If I had a single branch I could've immediately looked up how the rest of the Bigtop charms do it. Stuff like that. > The issue with the bigtop-base layer having to live outside the Bigtop repo > is a limitation of the charm-build tooling ( > https://github.com/juju/charm-tools/issues/212) and I don't think it will > be resolved soon. Right and this very well may be my inexperience with Juju, but my ideal state is havign Bigtop layer in the same repo so I can freely move code between Puppet, Charms and Bigtop layer for refactoring purposes. > However, the build process is always going to depend on > some external layers, such as the reactive base layer, and some interface > layers. This is just an aspect of how building charms from layers works. > Do you consider this an issue for the charms in Bigtop? At least initially Bigtop layer is really tightly coupled. Over time, I'd agree -- it will be less and less useful to have it closeby in the same repo. > We tend to think > of it like a "compile" step for the charms and the layers pulled from > http://interfaces.juju.solutions/ to be analogous to using libraries from > PyPI. Sure. But running with your analogy -- I agree that while I can link both glibc and libthrift just as opaque binary objects I need source code for thrift a lot more than I do for glibc. Thanks, Roman.
