Greetings Adam, Replies inline - and to keep things consistent, I will be referring to the newer nomenclature of the charm build process/tooling:
On Mon, Oct 19, 2015 at 9:23 AM, Adam Stokes <adam.sto...@canonical.com> wrote: > 'm looking to get my nodejs layer[1] included at > http://interfaces.juju.solutions and wanted to make sure that this charm > can be properly tested. I noticed that a Makefile is generated during > `charm-compose` > The Makefile can be overridden in upper layers if you have one that you're using in your charm layer. The default behavior when building charms is the following: If file conflict, take the top most layers file in leu of the lower layers file. If no conflict, simply copy the files across. 2 files are special cases to this rule, config.yaml and metadata.yaml's relations - in which case the files are merged according to their respective strategy. There are other strategies available, however - I'm not as intimiately familiar with these and hesitate to recommend changing the defaults at this time until we have further documentation around the merge strategies shipping with `charm build` With that being said, I've noticed some troubles with the shipping makefile that assumes its for the base layer project, and I feel this is a good candidate for simply replacing it in your layer. > and was curious how I can utilize that with amulet or whatever the > preferred way to test charms is. The amulet documentation doesn't really go > into how to actually run the tests locally so I can easily verify my charm. > Is there a how-to on the preferred (blessed) way of testing charms locally? > > This is a really good point that we need to update the docs to reflect that `bundletester` is our preferred method to test charms. It serves a few purposes - Running the gambit that we use in CI - charm proof - linting - make unit_test target (if your charm has unit tests) - anything in tests/* that is chmod+x > For the curious my charm layer simply installs Node.js based on whatever > version you set in the config (0.10, 0.12, 4.x) and will be used when > deploying whatever node app you require. > > Oh one other thing, I didn't see how to pass config options in amulet's > deploy so that I can test my different default versions from the config. > > You can set the version on the charm like the following example code: d.deployment = amulet.Deployment(series='trusty') d.deployment.add('mycharm') d.deployment.configure('mycharm', {'version': '1.0.0'}) > 1: https://github.com/battlemidget/juju-layer-node > > On Mon, Oct 19, 2015 at 11:08 AM, Adam Stokes <adam.sto...@canonical.com> wrote: > Additionally I was hoping I could just layer my application on top of the > nodejs layer and have my node version available to the application layer so > it would look like: > > - base layer > - node layer > - application api layer > > This is exactly what we are solving for. Abstract out the common bases that can be re-used across projects. This eases updates in the future for everyone involved. +1 to this sentiment > The application api layer would then have access to node/npm during charm > deployment and be able to react to node's layer state. However, in testing > this out it doesn't look like my application layer ever gets executed once > the node layer has finished. > > I need to look deeper at how you have this setup, but I imagine what's happened is you've defined 2 layers that execute under the same hook context. Take for example: layer0: @hook('install') layer1: @hook('install') This lends itself to troubling race conditions where layer1 may execute before layer0. What is a perferred method is to set a reactive state, and react to the new state layer0: @hook('install') ... stuff... reactive.set_state('thing.available') layer1: @when('thing.available') .. stuff.. This will ensure your methods in layer1 only execute after the dependent layer0 has completed its run and set the state. Please note, that you cannot decorate methods across the hook context and reactive states. Allow me to illustrate what not to do: @hook('config-changed') @when('thing.available') This will fail 100% of the time, and not execute, and its not terribly obvious that this is the case. > My thinking was that in order to test multiple node versions for my > application all I would need to do is deploy the charm with the node layers > default version configuration. To give you a better idea this is my api > service layer for an application I have: > > https://github.com/wffm/juju-layer-wffmapi > > That layer inherits from my node layer which inherits the base layer. I > was hoping to keep each layer's responsibility to just one thing, ie node > layer only installs node.js and exposes its installed state. > This sounds completely reasonable. Perhaps ship some extra bits in the node layer if applicable to handle common/routine node tasks, and include actions to perform things like module cleanup, et-al (?) All in all it sounds like you're well on your way to charming in reactive, and I'd like to thank you for your interest and reaching out about it. These are exciting times for early adopters :) We're shaping the future of charm writing as we know it. All the best, Charles Butler <charles.but...@canonical.com> - Juju Charmer Come see the future of datacenter orchestration: http://jujucharms.com On Mon, Oct 19, 2015 at 11:08 AM, Adam Stokes <adam.sto...@canonical.com> wrote: > Additionally I was hoping I could just layer my application on top of the > nodejs layer and have my node version available to the application layer so > it would look like: > > - base layer > - node layer > - application api layer > > The application api layer would then have access to node/npm during charm > deployment and be able to react to node's layer state. However, in testing > this out it doesn't look like my application layer ever gets executed once > the node layer has finished. > > My thinking was that in order to test multiple node versions for my > application all I would need to do is deploy the charm with the node layers > default version configuration. To give you a better idea this is my api > service layer for an application I have: > > https://github.com/wffm/juju-layer-wffmapi > > That layer inherits from my node layer which inherits the base layer. I > was hoping to keep each layer's responsibility to just one thing, ie node > layer only installs node.js and exposes its installed state. > > On Mon, Oct 19, 2015 at 9:23 AM, Adam Stokes <adam.sto...@canonical.com> > wrote: > >> I'm looking to get my nodejs layer[1] included at >> http://interfaces.juju.solutions and wanted to make sure that this charm >> can be properly tested. I noticed that a Makefile is generated during >> `charm-compose` and was curious how I can utilize that with amulet or >> whatever the preferred way to test charms is. The amulet documentation >> doesn't really go into how to actually run the tests locally so I can >> easily verify my charm. Is there a how-to on the preferred (blessed) way of >> testing charms locally? >> >> For the curious my charm layer simply installs Node.js based on whatever >> version you set in the config (0.10, 0.12, 4.x) and will be used when >> deploying whatever node app you require. >> >> Oh one other thing, I didn't see how to pass config options in amulet's >> deploy so that I can test my different default versions from the config. >> >> 1: https://github.com/battlemidget/juju-layer-node >> >> Thanks! >> > > > -- > Juju mailing list > Juju@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju > >
-- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
