Re: Multi-series charm authors: new functionality for comparing ubuntu versions
On Thu, Apr 13, 2017 at 09:15:08PM +0100, Alex Kavanagh wrote: > So instead of: > > if ubuntu_version > 'trusty': > > We do: > > cmp_version = CompareHostReleases(ubuntu_version) > if cmp_version > 'trusty': > > This version of the code checks that ubuntu_version and 'trusty' strings > are known releases and makes it easy to fix existing code. >, <, >=< <=, > ==, != are all supported. I have déjà vu: I did exactly the same thing in lp:ubuntu-cdimage in 2012. :-) I agree that this style makes things pretty nice for calling code. The one problem I've had with it is that every so often somebody looks at a bit of code and says "hey, isn't this going to break after 17.04?" and then I have to explain that it's actually magically OK, which as problems go is not really a bad one to have. -- Colin Watson [cjwat...@ubuntu.com] -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Hide resources from showing on the store
On Sun, Dec 11, 2016 at 12:57:35PM -0800, Mark Shuttleworth wrote: > On 05/12/16 07:12, Colin Watson wrote: > > As suggested in this thread and on IRC, I fell back to accepting > > zero-sized resources instead and uploading those to the store, and that > > works OK: > > > > https://jujucharms.com/u/launchpad/launchpad-buildd > > > > It seems like a fairly nasty hack though. Resources are pretty nice, > > and this feels like a wart. > > I think the point is that "juju deploy foo" should always give you a > reasonable result. In your case, that's the PPA option. *if* a resource > is specified, then it should be used. What we want to avoid is charms > which don't work at all unless a resource is specified. Right, I can definitely see that, and ensuring that there's always a reasonable result is exactly what I'm trying to do. I'm not sure that the current mechanism particularly helps with that, though. Charm authors can still easily upload a zero-sized resource to the store and then have their charm refuse to do anything unless you attach a "real" resource. If we assume that authors will legitimately want some way of doing optional resources (it seems like a handy way to have a payload which normally comes from some centralised source but which you might instead attach directly for quick iteration during development), then the zero-sized resource thing seems likely to become a fairly widespread pattern that people will copy. Given that, making authors resort to non-declarative hacks to achieve the goal of an optional resource might just increase the chance of mistakes. I can see how resources should default to being required at the charm store level to avoid making it easy to publish broken-by-default charms by accident. But how about something like this: * Add an "optional: true" option to resources, which the charm store would interpret as allowing a charm to be released without that resource. * Add some kind of affordance to charm-helpers to make this easy to use correctly. For instance, resource_get might be changed to take a "default" parameter, which would be accepted and required iff the resource in question is optional, or something along those lines. * Perhaps also add something to layer-apt and layer-snap to encapsulate the "install from this source by default, but use a resource if it's attached" pattern. I don't have a broad enough view of charms to be able to tell whether this is a good idea in general or overkill, but it would certainly have saved me some effort the other day if I could have just written something like this instead of a bunch of reactive code that took me several tries to get right: options: apt: packages: - launchpad-buildd - bzr-builder - git-build-recipe - quilt optional-package-resources: - launchpad-buildd - python-lpbuildd -- Colin Watson [cjwat...@ubuntu.com] -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Hide resources from showing on the store
Here's another use case for this kind of thing that doesn't involve proprietary code or terms. I recently put together a charm for launchpad-buildd: this lets you deploy a builder node in a container that can be attached to a local instance of Launchpad. There are two plausible ways to get the actual launchpad-buildd code in place: 1) You don't really care about the details and just want the latest stable version. For this, it makes sense to install from our PPA, which we're maintaining anyway for production use. I don't want to have to separately keep resources up to date. 2) You're hacking on a change to the launchpad-buildd code and want an easy way to deploy it locally to try it out. While you *could* build the whole thing in a PPA, that increases your iteration time quite a bit; it's much quicker to just build the packages locally and attach them as resources. My first attempt was to list the resources in metadata.yaml and only attach them if they were actually needed, which I naïvely assumed would work. And in fact it did almost entirely work: hookenv.resource_get returned False as documented, and my charm handled that and fell back to installing from a PPA. What didn't work was when I tried to do "charm release", which gave me: ERROR cannot release charm or bundle: bad request: charm published with incorrect resources: resources are missing from publish request: launchpad-buildd, python-lpbuildd As suggested in this thread and on IRC, I fell back to accepting zero-sized resources instead and uploading those to the store, and that works OK: https://jujucharms.com/u/launchpad/launchpad-buildd It seems like a fairly nasty hack though. Resources are pretty nice, and this feels like a wart. Thanks, -- Colin Watson [cjwat...@ubuntu.com] -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
