Charms, layers, and Launchpad

Marco Ceppi marco at ondina.co
Thu Dec 17 23:45:29 UTC 2015


Not sure if it will work completely offline, but you'll probably want to
pull all the layers/interfaces you want into INTERFACE_PATH and LAYER_PATH.
If I recall correctly, those are searched first for matches before the
index. The pip stuff is a bit harder, but it seems reasonable that we could
evaluate whats in the output path before attempting to do more fetches.
I'll open an issue to track what might be needed for limited to no
networking.

On Thu, Dec 17, 2015 at 6:33 PM Andrew Wilkins <andrew.wilkins at canonical.com>
wrote:

> On Fri, Dec 18, 2015 at 9:27 AM Cory Johns <cory.johns at canonical.com>
> wrote:
>
>> Andrew,
>>
>> It's mentioned at the start of
>> https://jujucharms.com/docs/stable/authors-charm-building and there is a
>> PR (https://github.com/juju/docs/pull/746) to rework the existing
>> authors doc into a developer guide focused on creating charms with layers
>> that will bring a lot of this information together that is currently in
>> various locations.  Reviews on that are welcome.
>>
>
> Thanks, not sure how I missed that.
>
> As for building reactive charms offline, I'm not sure I understand the
>> question.  Layer and interface deps are cached under $JUJU_REPOSITORY/deps
>> and after the first build the wheelhouse will be in the charm output dir
>> and we could potentially prefer them over hitting the index again, but the
>> first build as well as any new deps, layer, interface, or wheelhouse, will
>> inherently require network access.
>>
>
> So I wanted to build charms while on a plane without Internet access.
> Maybe I was just doing something wrong, but it wanted network access
> despite having fetched/built the dependencies once before.
>
> Obviously we'll need to hit the network on the first build, and that's
> totally fine. If pip could be optionally instructed to reuse the existing
> wheelhouses, that would be helpful. I'd build the charms once before losing
> network, and then continue iterating with the cached dependencies.
>
> Cheers,
> Andrew
>
>
>> On Thu, Dec 17, 2015 at 6:09 PM, Andrew Wilkins <
>> andrew.wilkins at canonical.com> wrote:
>>
>>> On Fri, Dec 18, 2015 at 8:58 AM Cory Johns <cory.johns at canonical.com>
>>> wrote:
>>>
>>>> Greetings, all.
>>>>
>>>> I wanted to suggest a convention for managing layered charms with
>>>> Launchpad.
>>>>
>>>> Until the publish workflow is ready, the "built charm" (i.e., output
>>>> from `charm build`) must be checked in to Launchpad in a repo such as:
>>>>
>>>>     lp:~user/charms/trusty/foo/trunk
>>>>
>>>> The base path and branch are required to be charms/<series> and /trunk,
>>>> respectively, for the charm to be ingested into the store.
>>>>
>>>> Launchpad isn't really set up to deal with charm layers, but I think we
>>>> could settle on a convention of using the branch /layer to denote the
>>>> source charm layer for the corresponding /trunk built charm.  The source
>>>> layer (under /layer) is what we would like to have submitted to the Review
>>>> Queue, and the /trunk branch could be used only for ingestion into the
>>>> store.
>>>>
>>>> Note that interface and base layers would need to have their own
>>>> project, since they don't really fit into the charms/series project
>>>> structure.  They can also live outside of Launchpad and work just fine as
>>>> long as they are registered in http://interfaces.juju.solutions/
>>>> (which can be done by anyone with Launchpad credentials) (eventually, the
>>>> plan is for them to be published to the store in a similar way to charms).
>>>>
>>>> I'd also like to mention our recommendations for developing layered
>>>> charms.  Specifically, you should create a base Juju repository directory
>>>> (e.g., ~/charms) and subdirectories for "layers", "interfaces" (if you plan
>>>> to develop those), and any series directories such as "trusty".  Then, you
>>>> should ensure that the following variables are set in your environment:
>>>>
>>>>     JUJU_REPOSITORY=~/charms
>>>>     LAYER_PATH=$JUJU_REPOSITORY/layers
>>>>     INTERFACE_PATH=$JUJU_REPOSITORY/interfaces  # optional
>>>>
>>>> Many layer and interface repos are prefixed with "layer-" or
>>>> "interface-" to indicate their role (e.g.,
>>>> https://github.com/juju-solutions/layer-hadoop-base) but when cloned
>>>> locally to work on them, the directory name must match the layer or
>>>> interface name ("hadoop-base", in this case).  So, to clone that repo:
>>>>
>>>>     git clone https://github.com/juju-solutions/layer-hadoop-base
>>>> $JUJU_REPOSITORY/layers/hadoop-base
>>>>
>>>> This will ensure that `charm build` does the right thing, can find all
>>>> of your in-progress layers, and puts the built charm in the right place.
>>>>
>>>
>>> Is this all documented somewhere? I ended up doing almost exactly what
>>> you've described here through reading the charm tools code -- would be good
>>> to get it into the author's guide, I think.
>>>
>>> Is anyone looking at making it possible to build reactive charms
>>> offline? AFAICT, you have to have access to the Internet for the pip
>>> resources. And maybe the base layer?
>>>
>>> Cheers,
>>> Andrew
>>>
>>> Thanks!
>>>> --
>>>> Juju mailing list
>>>> Juju at lists.ubuntu.com
>>>> Modify settings or unsubscribe at:
>>>> https://lists.ubuntu.com/mailman/listinfo/juju
>>>>
>>>
>> --
> Juju mailing list
> Juju at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20151217/cfcdc906/attachment.html>


More information about the Juju mailing list