Re: [openstack-dev] [charms] inclusion of charm-helpers (LGPL licensed)

[James Page]

Hi Billy

On Thu, 30 Jun 2016 at 17:24 Billy Olsen  wrote:

> I suspect that the reactive charming model wouldn't have this issue
> due to the ability to essentially statically link the libraries via
> wheels/pip packages. If that's the case, it's likely possible to
> follow along the same lines as the base-layer charm and bootstrap the
> environment using pip/wheel libraries included at build time. As I see
> it, this would require:
>
> * Updates to the process/tooling for pushing to the charm store
> * Update the install/upgrade-charm hook to bootstrap the environment
> with the requirements files
> * If using virtualenv (not a requirement in my mind), then each of the
> hooks needs to be bootstrapped to ensure that they are running within
> the virtualenv.
>

I was thinking of something along those lines as well.  I'll spike on
something this week to figure out exactly how this might work.


> To make life easier in development mode, the charms can downla
> build step before deployment, though certainly for the published
> versions the statically linked libraries should be included (which,
> from my understanding, I believe the licensing allows and why the
> reactive charming/layered model wouldn't have this issue).
>

That sounds like a neat idea (although building out a layered charm is
pretty easy as well).
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [charms] inclusion of charm-helpers (LGPL licensed)

[Billy Olsen]

I suspect that the reactive charming model wouldn't have this issue
due to the ability to essentially statically link the libraries via
wheels/pip packages. If that's the case, it's likely possible to
follow along the same lines as the base-layer charm and bootstrap the
environment using pip/wheel libraries included at build time. As I see
it, this would require:

* Updates to the process/tooling for pushing to the charm store
* Update the install/upgrade-charm hook to bootstrap the environment
with the requirements files
* If using virtualenv (not a requirement in my mind), then each of the
hooks needs to be bootstrapped to ensure that they are running within
the virtualenv.

To make life easier in development mode, the charms can download from
pypi if the linked wheel/pip package isn't available - it saves a
build step before deployment, though certainly for the published
versions the statically linked libraries should be included (which,
from my understanding, I believe the licensing allows and why the
reactive charming/layered model wouldn't have this issue).


On Tue, Jun 28, 2016 at 6:29 AM, James Page  wrote:
> Hi All
>
> Whilst working on the re-licensing of the OpenStack charms to Apache 2.0,
> its apparent that syncing and inclusion of the charm-helpers python module
> directly into the charm is not going to work from a license compatibility
> perspective. charm-helpers is LGPL v3 (which is OK for a runtime dependency
> of an OpenStack project - see [0]).
>
> We already have a plan in place to remove the inclusion of charm-helpers for
> execution of functional tests, but we need to come up with a solution to the
> runtime requirement for charm-helpers, preferably one that does not involve
> direct installation at deploy time from either pypi or from
> lp:charm-helpers.
>
> Thoughts? ideas?
>
> Cheers
>
> James
>
> [0] http://governance.openstack.org/reference/licensing.html
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [charms] inclusion of charm-helpers (LGPL licensed)

[James Page]

Hi All

Whilst working on the re-licensing of the OpenStack charms to Apache 2.0,
its apparent that syncing and inclusion of the charm-helpers python module
directly into the charm is not going to work from a license compatibility
perspective. charm-helpers is LGPL v3 (which is OK for a runtime dependency
of an OpenStack project - see [0]).

We already have a plan in place to remove the inclusion of charm-helpers
for execution of functional tests, but we need to come up with a solution
to the runtime requirement for charm-helpers, preferably one that does not
involve direct installation at deploy time from either pypi or from
lp:charm-helpers.

Thoughts? ideas?

Cheers

James

[0] http://governance.openstack.org/reference/licensing.html
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev