Re: [openstack-dev] [charms] Propose Felipe Reyes for OpenStack Charmers team

[Frode Nordahl]

Core membership application approved, welcome aboard Felipe!

FTR; I have also gathered a off-list +1 from David Ames

On Wed, Sep 12, 2018 at 4:04 AM Alex Kavanagh 
wrote:

> +1 from me too.
>
> On Wed, Sep 12, 2018 at 7:29 AM, Liam Young 
> wrote:
>
>> +1 and thanks for all your contributions Felipe!
>>
>> On Wed, Sep 12, 2018 at 6:51 AM Chris MacNaughton <
>> chris.macnaugh...@canonical.com> wrote:
>>
>>> +1 Felipe has been a solid contributor to the Openstack Charms for some
>>> time now.
>>>
>>> Chris
>>>
>>> On 11-09-18 23:07, Ryan Beisner wrote:
>>>
>>> +1  I'm always happy to see Felipe's contributions and fixes come
>>> through.
>>>
>>> Cheers!
>>>
>>> Ryan
>>>
>>>
>>>
>>>
>>> On Tue, Sep 11, 2018 at 1:10 PM James Page 
>>> wrote:
>>>
 +1

 On Wed, 5 Sep 2018 at 15:48 Billy Olsen  wrote:

> Hi,
>
> I'd like to propose Felipe Reyes to join the OpenStack Charmers team as
> a core member. Over the past couple of years Felipe has contributed
> numerous patches and reviews to the OpenStack charms [0]. His
> experience
> and knowledge of the charms used in OpenStack and the usage of Juju
> make
> him a great candidate.
>
> [0] -
>
> https://review.openstack.org/#/q/owner:%22Felipe+Reyes+%253Cfelipe.reyes%2540canonical.com%253E%22
>
> Thanks,
>
> Billy Olsen
>
>
> __
> 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 Development Mailing List (not for usage questions)
>>> Unsubscribe: 
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://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 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
>>
>>
>
>
> --
> Alex Kavanagh - Software Engineer
> Cloud Dev Ops - Solutions & Product Engineering - Canonical Ltd
> __
> 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
>


-- 
Frode Nordahl
Software Engineer
Canonical Ltd.
__
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] Propose Felipe Reyes for OpenStack Charmers team

[Alex Kavanagh]

+1 from me too.

On Wed, Sep 12, 2018 at 7:29 AM, Liam Young 
wrote:

> +1 and thanks for all your contributions Felipe!
>
> On Wed, Sep 12, 2018 at 6:51 AM Chris MacNaughton <
> chris.macnaugh...@canonical.com> wrote:
>
>> +1 Felipe has been a solid contributor to the Openstack Charms for some
>> time now.
>>
>> Chris
>>
>> On 11-09-18 23:07, Ryan Beisner wrote:
>>
>> +1  I'm always happy to see Felipe's contributions and fixes come through.
>>
>> Cheers!
>>
>> Ryan
>>
>>
>>
>>
>> On Tue, Sep 11, 2018 at 1:10 PM James Page 
>> wrote:
>>
>>> +1
>>>
>>> On Wed, 5 Sep 2018 at 15:48 Billy Olsen  wrote:
>>>
 Hi,

 I'd like to propose Felipe Reyes to join the OpenStack Charmers team as
 a core member. Over the past couple of years Felipe has contributed
 numerous patches and reviews to the OpenStack charms [0]. His experience
 and knowledge of the charms used in OpenStack and the usage of Juju make
 him a great candidate.

 [0] -
 https://review.openstack.org/#/q/owner:%22Felipe+Reyes+%
 253Cfelipe.reyes%2540canonical.com%253E%22

 Thanks,

 Billy Olsen

 
 __
 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 Development Mailing List (not for usage questions)
>> Unsubscribe: 
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://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 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
>
>


-- 
Alex Kavanagh - Software Engineer
Cloud Dev Ops - Solutions & Product Engineering - Canonical Ltd
__
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] Propose Felipe Reyes for OpenStack Charmers team

[Liam Young]

+1 and thanks for all your contributions Felipe!

On Wed, Sep 12, 2018 at 6:51 AM Chris MacNaughton <
chris.macnaugh...@canonical.com> wrote:

> +1 Felipe has been a solid contributor to the Openstack Charms for some
> time now.
>
> Chris
>
> On 11-09-18 23:07, Ryan Beisner wrote:
>
> +1  I'm always happy to see Felipe's contributions and fixes come through.
>
> Cheers!
>
> Ryan
>
>
>
>
> On Tue, Sep 11, 2018 at 1:10 PM James Page 
> wrote:
>
>> +1
>>
>> On Wed, 5 Sep 2018 at 15:48 Billy Olsen  wrote:
>>
>>> Hi,
>>>
>>> I'd like to propose Felipe Reyes to join the OpenStack Charmers team as
>>> a core member. Over the past couple of years Felipe has contributed
>>> numerous patches and reviews to the OpenStack charms [0]. His experience
>>> and knowledge of the charms used in OpenStack and the usage of Juju make
>>> him a great candidate.
>>>
>>> [0] -
>>>
>>> https://review.openstack.org/#/q/owner:%22Felipe+Reyes+%253Cfelipe.reyes%2540canonical.com%253E%22
>>>
>>> Thanks,
>>>
>>> Billy Olsen
>>>
>>>
>>> __
>>> 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 Development Mailing List (not for usage questions)
> Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://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 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] Propose Felipe Reyes for OpenStack Charmers team

[Chris MacNaughton]

+1 Felipe has been a solid contributor to the Openstack Charms for some 
time now.


Chris


On 11-09-18 23:07, Ryan Beisner wrote:

+1  I'm always happy to see Felipe's contributions and fixes come through.

Cheers!

Ryan




On Tue, Sep 11, 2018 at 1:10 PM James Page > wrote:


+1

On Wed, 5 Sep 2018 at 15:48 Billy Olsen mailto:billy.ol...@gmail.com>> wrote:

Hi,

I'd like to propose Felipe Reyes to join the OpenStack
Charmers team as
a core member. Over the past couple of years Felipe has
contributed
numerous patches and reviews to the OpenStack charms [0]. His
experience
and knowledge of the charms used in OpenStack and the usage of
Juju make
him a great candidate.

[0] -

https://review.openstack.org/#/q/owner:%22Felipe+Reyes+%253Cfelipe.reyes%2540canonical.com%253E%22

Thanks,

Billy Olsen


__
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 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

Re: [openstack-dev] [charms] Propose Felipe Reyes for OpenStack Charmers team

[Ryan Beisner]

+1  I'm always happy to see Felipe's contributions and fixes come through.

Cheers!

Ryan




On Tue, Sep 11, 2018 at 1:10 PM James Page  wrote:

> +1
>
> On Wed, 5 Sep 2018 at 15:48 Billy Olsen  wrote:
>
>> Hi,
>>
>> I'd like to propose Felipe Reyes to join the OpenStack Charmers team as
>> a core member. Over the past couple of years Felipe has contributed
>> numerous patches and reviews to the OpenStack charms [0]. His experience
>> and knowledge of the charms used in OpenStack and the usage of Juju make
>> him a great candidate.
>>
>> [0] -
>>
>> https://review.openstack.org/#/q/owner:%22Felipe+Reyes+%253Cfelipe.reyes%2540canonical.com%253E%22
>>
>> Thanks,
>>
>> Billy Olsen
>>
>> __
>> 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 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] Propose Felipe Reyes for OpenStack Charmers team

[James Page]

+1

On Wed, 5 Sep 2018 at 15:48 Billy Olsen  wrote:

> Hi,
>
> I'd like to propose Felipe Reyes to join the OpenStack Charmers team as
> a core member. Over the past couple of years Felipe has contributed
> numerous patches and reviews to the OpenStack charms [0]. His experience
> and knowledge of the charms used in OpenStack and the usage of Juju make
> him a great candidate.
>
> [0] -
>
> https://review.openstack.org/#/q/owner:%22Felipe+Reyes+%253Cfelipe.reyes%2540canonical.com%253E%22
>
> Thanks,
>
> Billy Olsen
>
> __
> 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

Re: [openstack-dev] [charms][ptg] Stein PTG team dinner

[Frode Nordahl]

Sounds great James.  Excellent choice of restaurant, I'm in! (My +1 will
probably be pre-occupied with other things that evening, so only count me
for the reservation)

On Mon, Sep 10, 2018 at 11:13 AM James Page 
wrote:

> Hi All
>
> As outgoing PTL I have the honour of organising the team dinner for the
> Stein PTG this week.
>
> I'm proposing Wednesday night at Russell's Smokehouse:
>
>   https://www.russellssmokehouse.com/
>
> Let me know if you will be along (and if you have a +1) by end of today
> and I'll make the reservation!
>
> Cheers
>
> James
> __
> 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
>


-- 
Frode Nordahl
Software Engineer
Canonical Ltd.
__
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] Deployment guide stable/rocky cut

[Alex Kavanagh]

Hi Ed

Yes, it's in hand.  I've got a review up:
https://review.openstack.org/#/c/598138/ but I also need to create some
stable branches, etc.  May take a few more days.

Thanks
Alex.

On Fri, Aug 31, 2018 at 12:48 PM, Edward Hope-Morley 
wrote:

> Hi Frode, I think it would be a good idea to add a link to the charm
> deployment guide at the following page:
>
> https://docs.openstack.org/rocky/deploy/
>
> - Ed
>
> On 17/08/18 08:47, Frode Nordahl wrote:
>
> Hello OpenStack charmers,
>
> I am writing to inform you that  a `stable/rocky` branch has been cut for
> the `openstack/charm-deployment-guide` repository.
>
> Should there be any further updates to the guide before the release the
> changes will need to be landed in `master` and then back-ported to
> `stable/rocky`.
>
> --
> Frode Nordahl
> Software Engineer
> Canonical Ltd.
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://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
>
>


-- 
Alex Kavanagh - Software Engineer
Cloud Dev Ops - Solutions & Product Engineering - Canonical Ltd
__
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] Deployment guide stable/rocky cut

[Edward Hope-Morley]

Hi Frode, I think it would be a good idea to add a link to the charm
deployment guide at the following page:

https://docs.openstack.org/rocky/deploy/

- Ed


On 17/08/18 08:47, Frode Nordahl wrote:
> Hello OpenStack charmers,
>
> I am writing to inform you that  a `stable/rocky` branch has been cut
> for the `openstack/charm-deployment-guide` repository.
>
> Should there be any further updates to the guide before the release
> the changes will need to be landed in `master` and then back-ported to
> `stable/rocky`.
>
> -- 
> Frode Nordahl
> Software Engineer
> Canonical Ltd.
>
>
> __
> 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

Re: [openstack-dev] [charms] PTL candidacy for Stein cycle

[David Ames]

On Sat, Jul 28, 2018 at 8:25 AM, Frode Nordahl
 wrote:
> Hello all,
>
> I hereby announce my candidacy for PTL of the OpenStack Charms project [0].
>
> Through the course of the past two years I have made many contributions to
> the Charms projects and I have had the privilege of becoming a Core
> developer.
>
> Prior to focusing on the Charms project I have made upstream contributions
> in
> other OpenStack projects and I have followed the unfolding and development
> of
> the OpenStack community with great interest.
>
> We live in exciting times and I believe great things are afoot for OpenStack
> as a stable, versatile and solid contender in the cloud space.  It would be
> my privilege to be able to help further that along as PTL for the Charms
> project.
>
> Our project has a strong and disperse group of contributors and we are
> blessed
> with motivated and assertive people taking interest in maintaining existing
> code as well as developing new features.
>
> The most important aspect of my job as PTL will be to make sure we maintain
> room for the diversity of contributions without losing velocity and
> direction.
> Maintaining and developing our connection with the broader OpenStack
> community
> will also be of great importance.
>
> Some key areas of focus for Stein cycle:
> - Python 3 migration
>   - The clock is ticking for Python 2 and we need to continue the drive
> towards
> porting all our code to Python 3
> - Continue modernization of test framework
>   - Sustained software quality is only as good as you can prove through the
> quality of your unit and functional tests.
>   - Great progress has been made this past cycle in developing and extending
> functionality of a new framework for our functional tests and we need to
> continue this work.
>   - Continue to build test driven development culture, and export this
> culture
> to contributors outside the core team.
> - [Multi-cycle] Explore possibilities and methodologies for Classic ->
> layered
>   Reactive Charm migrations
>   - A lot of effort has been put into the Reactive Charm framework and the
> reality of writing a new Charm today is quite different from what it was
> just a few years ago.
>   - The time and effort needed to maintain a layered Reactive Charm is also
> far
> less than what it takes to maintain a classic Charm.
>   - There are many hard and difficult topics surrounding such a migration
> but I
> think it is worth spending some time exploring our options of how we
> could
> get there.
> - Evaluate use of upstream release tools
>   - The OpenStack release team has put together some great tools that might
> make our release duties easier.  Let us evaluate adopting some of them
> for
> our project.
>
> 0: https://review.openstack.org/#/c/586821/
>
> --
> Frode Nordahl (IRC: fnordahl)


+1

I am certain Frode will work tirelessly as the Chrams PTL.

--
David Ames

__
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] PTL non-candidacy for Stein cycle

[Jean-Philippe Evrard]

On July 27, 2018 4:09:04 PM UTC, James Page  wrote:
>Hi All
>
>I won't be standing for PTL of OpenStack Charms for this upcoming
>cycle.
>
>Its been my pleasure to have been PTL since the project was accepted
>into
>OpenStack, but its time to let someone else take the helm.   I'm not
>going
>anywhere but expect to have a bit of a different focus for this cycle
>(at
>least).
>
>Cheers
>
>James

Thanks for the work done on a cross project level and your  communication!

JP (evrardjp)__
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] [tripleo] [puppet] [fuel] [kolla] [openstack-ansible] [cloudcafe] [magnum] [mogan] [sahara] [shovel] [watcher] [helm] [rally] Heads up: ironic classic drivers deprecation

[Jean-Philippe Evrard]

Hello,

Thanks for the notice!

JP

On 16 March 2018 at 12:09, Dmitry Tantsur  wrote:
> Hi all,
>
> If you see your project name in the subject that is because a global search
> revived usage of "pxe_ipmitool", "agent_ipmitool" or "pxe_ssh" drivers in
> the non-unit-test context in one or more of your repositories.
>
> The classic drivers, such as pxe_ipmitool, were deprecated in Queens, and
> we're on track with removing them in Rocky. Please read [1] about
> differences between classic drivers and newer hardware types. Please refer
> to [2] on how to update your code.
>
> Finally, the pxe_ssh driver was removed some time ago. Please use the
> standard IPMI driver with the virtualbmc project [3] instead.
>
> Please reach out to the ironic team (here or on #openstack-ironic) if you
> have any questions or need help with the transition.
>
> Dmitry
>
> [1] https://docs.openstack.org/ironic/latest/install/enabling-drivers.html
> [2]
> https://docs.openstack.org/ironic/latest/admin/upgrade-to-hardware-types.html
> [3] https://github.com/openstack/virtualbmc
>
> __
> 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

Re: [openstack-dev] [charms] 18.02 OpenStack Charms release

[Ryan Beisner]

URL correction for 18.02 OpenStack Charms release notes:

https://docs.openstack.org/charm-guide/latest/1802.html


Cheers,

Ryan

On Fri, Mar 9, 2018 at 2:46 PM, David Ames  wrote:

> Announcing the 18.02 release of the OpenStack Charms.
>
> The 18.02 charms have full support for the Queens OpenStack release.
> 112 bugs have been fixed and released across the OpenStack charms.
>
> For full details of the release, please refer to the release notes:
>
>   https://docs.openstack.org/charm-guide/latest/18.02.html
>
> Thanks go to the following contributors for this release:
>
>  Anton Kremenetsky
>  Billy Olsen
>  Corey Bryant
>  David Ames
>  Dmitrii Shcherbakov
>  Edward Hope-Morley
>  Felipe Reyes
>  Frode Nordahl
>  James Page
>  Jason Hobbs
>  Jill Rouleau
>  Liam Young
>  Nobuto Murata
>  Ryan Beisner
>  Seyeong Kim
>  Tytus Kurek
>  Xav Paice
>
> __
> 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

Re: [openstack-dev] [charms]

[Dmitrii Shcherbakov]

> Data migration from where to where? We access the current state by 
retrieving the data from leader db, or am I missing something here?


In case there are changes in how data is stored in one version of a 
charm vs the other.


Another problem is application versioning: we do have version-specific 
templates but this data may be versioned too. Old entries may not be 
simple strings, e.g. they can be small objects which can change 
following version changes (new data added or removed in a pre-defined way).


I can also see potential scenarios where you would need to gracefully 
retire old data as features get deprecated and, eventually, removed. So, 
during an upgrade you would have two copies of stateful data and a charm 
would react differently depending on the current application version 
set. After an upgrade the old copy could be automatically discarded.


> Perhaps I'm being naive but I don't see these developing into data 
sets large enough to cause performance problems.


I don't think it's going to be used for large data sets either but you 
never know.


> Each time the action is run the context associated with the action is 
deleted and recreated. If an action argument is unset I guess we could 
interpret that as leave-unchanged.


Leave unchanged - yes. Still need to be able to delete completely though.

What I like about actions is that you can clearly express imperative 
steps with arguments that you have to perform after a deployment and 
they have a very specific type of data in mind which is fetched from 
stateful applications out of band by an operator.


On 19.02.2018 18:11, Liam Young wrote:

On Mon, Feb 19, 2018 at 9:05 AM, Dmitrii Shcherbakov
 wrote:

Hi Liam,


I was recently looking at how to support custom configuration that relies
on post deployment setup.

I would describe the problem in general as follows:

1) charms can get context not only from Juju (config options, relation data,
leader data), environment (operating system release, OpenStack release,
services running etc.) but also from a stateful data store (e.g. a Keystone
database);
2) it's not easy to track application state from a charm because:
authentication is needed to fetch persistent state, notifications from a
data store cannot be reliably set up because charm code is ran periodically
and it is not always present in memory (polling is neither timely nor
efficient). Another problem is that software that holds the state needs to
support data change notifications which raises version compatibility
questions.

By using actions we move the responsibility for data retrieval and change
notifications to an operator but a more generic scenario would be modeling a
feedback loop from an application to Juju as a modeling system where changes
can be either automatic or gated by an operator (an orchestrator). Making it
automatic would mean that a service would get notifications/poll data from a
state store and would be authorized to use Juju client to make certain
changes.

This is an interesting idea, but there is no such mechanism within
Juju that I know of.


Another problem to solve is maintenance of that state: if we start
maintaining a key-value DB in leader settings we need to think about data
migration over time and how to access the current state.

Data migration from where to where? We access the current state by retrieving
the data from leader db, or am I missing something here?


In other words, in
CRUD, the "C" part is relatively straightforward, "R" is more complicated
with large data sets (if I have a lot of leader data, how do I interpret it
efficiently?),

Perhaps I'm being naive but I don't see these developing into data
sets large enough
to cause performance problems.


"UD" is less clear - seems like there will have to be 3 or 4
actions per feature for C, [R], U and D or one action that can multiplex
commands.

Each time the action is run the context associated with the action is deleted
and recreated. If an action argument is unset I guess we could interpret that as
leave-unchanged.


This brings me to the question of how is it different from state-specific
config values with a complex structure.

To my mind the difference is complexity for the end user. An action has clearly
defined arguments and the charm action code looks after forming this into
the correct context.


Instead of leader data, a per-charm
config option could hold state data in some format namespaced by a feature
name or config file name to render. A data model would be needed to make
sure we can create versioned application-specific state buckets (e.g. for
upgrades, hold both states, then remove the old one).

Application version-specific config values is something not modeled in Juju
although custom application versions are present
(https://jujucharms.com/docs/2.3/reference-hook-tools#application-version-set).
Version information has to be set via a hook tool which means that it has to
come from a 

Re: [openstack-dev] [charms]

[Liam Young]

On Mon, Feb 19, 2018 at 9:05 AM, Dmitrii Shcherbakov
 wrote:
> Hi Liam,
>
>> I was recently looking at how to support custom configuration that relies
>> on post deployment setup.
>
> I would describe the problem in general as follows:
>
> 1) charms can get context not only from Juju (config options, relation data,
> leader data), environment (operating system release, OpenStack release,
> services running etc.) but also from a stateful data store (e.g. a Keystone
> database);
> 2) it's not easy to track application state from a charm because:
> authentication is needed to fetch persistent state, notifications from a
> data store cannot be reliably set up because charm code is ran periodically
> and it is not always present in memory (polling is neither timely nor
> efficient). Another problem is that software that holds the state needs to
> support data change notifications which raises version compatibility
> questions.
>
> By using actions we move the responsibility for data retrieval and change
> notifications to an operator but a more generic scenario would be modeling a
> feedback loop from an application to Juju as a modeling system where changes
> can be either automatic or gated by an operator (an orchestrator). Making it
> automatic would mean that a service would get notifications/poll data from a
> state store and would be authorized to use Juju client to make certain
> changes.

This is an interesting idea, but there is no such mechanism within
Juju that I know of.

>
> Another problem to solve is maintenance of that state: if we start
> maintaining a key-value DB in leader settings we need to think about data
> migration over time and how to access the current state.

Data migration from where to where? We access the current state by retrieving
the data from leader db, or am I missing something here?

> In other words, in
> CRUD, the "C" part is relatively straightforward, "R" is more complicated
> with large data sets (if I have a lot of leader data, how do I interpret it
> efficiently?),

Perhaps I'm being naive but I don't see these developing into data
sets large enough
to cause performance problems.

> "UD" is less clear - seems like there will have to be 3 or 4
> actions per feature for C, [R], U and D or one action that can multiplex
> commands.

Each time the action is run the context associated with the action is deleted
and recreated. If an action argument is unset I guess we could interpret that as
leave-unchanged.

>
> This brings me to the question of how is it different from state-specific
> config values with a complex structure.

To my mind the difference is complexity for the end user. An action has clearly
defined arguments and the charm action code looks after forming this into
the correct context.

> Instead of leader data, a per-charm
> config option could hold state data in some format namespaced by a feature
> name or config file name to render. A data model would be needed to make
> sure we can create versioned application-specific state buckets (e.g. for
> upgrades, hold both states, then remove the old one).
>
> Application version-specific config values is something not modeled in Juju
> although custom application versions are present
> (https://jujucharms.com/docs/2.3/reference-hook-tools#application-version-set).
> Version information has to be set via a hook tool which means that it has to
> come from a custom config option anyway. Each charm has its own method to
> specify an application version and config dependencies are not modeled
> explicitly - one has to implement that logic in a charm without any Juju API
> for charms present the way I see it.
>
> config('key', 'app-version') - would be something to aim for.
>
> Do you have any thoughts about leader data vs a special complex config
> option per charm and versioning?
>
> Thanks!

Thanks for the feedback Dmitrii

__
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] Incorrect Padding for SSL Cert/Key

[Pete Vander Giessen]

Hi All,

I came across this thread when troubleshooting a similar problem, and
wanted to drop in the solution we came up with for posterity:

1) If you're dealing with an API, and the API comes back with an "incorrect
padding" error while parsing an SSL Cert, it usually means that the
formatting got munged somewhere. With most of the openstack charms, when
specifying an ssl cert in a bundle, you actually need to embed a yaml
escaped string inside of your yaml escaped string. I looks something like
this:

ssl_cert: |
|
your properly formatted ssl cert goes here.

Note that there are two pipes indicating the beginning of a yaml string in
the above config setup. You need them both! (Double escaping a big text
blob containing special characters is a really common pattern in a lot of
APIs -- you generally want to be aware of it, and watch out for it.)

2) For haproxy, you need to specify a service that listens on port 443 in
the "services" config key. By default, haproxy will only setup a service
listening on port 80. As Adam Collard mentioned, there are some great
examples in the haproxy tests: `tests/12_deploy_{trusty,xenial}.py`

~ PeteVG
__
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]

[Billy Olsen]

Seems very reasonable. +1

On 02/14/2018 05:35 AM, Alex Kavanagh wrote:
> Yes, that seems like a reasonable approach. +1
>
> On Wed, Feb 14, 2018 at 11:29 AM, Liam Young  > wrote:
>
> Hi,
>
> I would like to propose that we do not support the notifications
> method for automatically creating DNS records in Queens+. This method
> for achieving Neutron integration has been superseded both upstream
> and in the charms. By removing support for it in Queens we prevent the
> charm from attempting to make designate v1 api calls for Queens+ which
> is a positive thing given it will have been removed (
> 
> https://docs.openstack.org/releasenotes/designate/queens.html#critical-issues
> 
> 
> ).
>
> Thanks
> Liam
>
> __
> 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
> 
>
>
>
>
> -- 
> Alex Kavanagh - Software Engineer
> Cloud Dev Ops - Solutions & Product Engineering - Canonical Ltd
>
>
> __
> 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

Re: [openstack-dev] [charms]

[Alex Kavanagh]

Yes, that seems like a reasonable approach. +1

On Wed, Feb 14, 2018 at 11:29 AM, Liam Young 
wrote:

> Hi,
>
> I would like to propose that we do not support the notifications
> method for automatically creating DNS records in Queens+. This method
> for achieving Neutron integration has been superseded both upstream
> and in the charms. By removing support for it in Queens we prevent the
> charm from attempting to make designate v1 api calls for Queens+ which
> is a positive thing given it will have been removed (
> https://docs.openstack.org/releasenotes/designate/queens.
> html#critical-issues
> ).
>
> Thanks
> Liam
>
> __
> 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
>



-- 
Alex Kavanagh - Software Engineer
Cloud Dev Ops - Solutions & Product Engineering - Canonical Ltd
__
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]

[James Page]

+1

On Wed, 14 Feb 2018 at 11:29 Liam Young  wrote:

> Hi,
>
> I would like to propose that we do not support the notifications
> method for automatically creating DNS records in Queens+. This method
> for achieving Neutron integration has been superseded both upstream
> and in the charms. By removing support for it in Queens we prevent the
> charm from attempting to make designate v1 api calls for Queens+ which
> is a positive thing given it will have been removed (
>
> https://docs.openstack.org/releasenotes/designate/queens.html#critical-issues
> ).
>
> Thanks
> Liam
>
> __
> 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

Re: [openstack-dev] [charms]

[James Page]

+1

On Wed, 14 Feb 2018 at 11:29 Liam Young  wrote:

> Hi,
>
> I would like to propose that we do not support the notifications
> method for automatically creating DNS records in Queens+. This method
> for achieving Neutron integration has been superseded both upstream
> and in the charms. By removing support for it in Queens we prevent the
> charm from attempting to make designate v1 api calls for Queens+ which
> is a positive thing given it will have been removed (
>
> https://docs.openstack.org/releasenotes/designate/queens.html#critical-issues
> ).
>
> Thanks
> Liam
>
> __
> 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

Re: [openstack-dev] [charms] Propose Andrew McLeod for OpenStack Charmers team

[Pete Vander Giessen]

+1 from me, too.

On Mon, Feb 12, 2018 at 12:39 PM Alex Kavanagh 
wrote:

> Positive +1 from me.  Andrew would make a great additiona.
>
> On Mon, Feb 12, 2018 at 5:00 PM, Ryan Beisner 
> wrote:
>
>> Hi All,
>>
>> I'd like to propose Andrew McLeod for the OpenStack Charmers (LP) and
>> charms-core (Gerrit) teams.  Andrew has made many commits and bugfixes to
>> the OpenStack Charms over the past couple of years, and he has general
>> charming knowledge and experience which is wider than just OpenStack.
>>
>> He has actively participated in the last two OpenStack Charms release
>> processes.  He is also the original author and current maintainer of the
>> magpie charm.
>>
>> Cheers,
>>
>> Ryan
>>
>> __
>> 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
>>
>>
>
>
> --
> Alex Kavanagh - Software Engineer
> Cloud Dev Ops - Solutions & Product Engineering - Canonical Ltd
> __
> 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

Re: [openstack-dev] [charms] Propose Andrew McLeod for OpenStack Charmers team

[Alex Kavanagh]

Positive +1 from me.  Andrew would make a great additiona.

On Mon, Feb 12, 2018 at 5:00 PM, Ryan Beisner 
wrote:

> Hi All,
>
> I'd like to propose Andrew McLeod for the OpenStack Charmers (LP) and
> charms-core (Gerrit) teams.  Andrew has made many commits and bugfixes to
> the OpenStack Charms over the past couple of years, and he has general
> charming knowledge and experience which is wider than just OpenStack.
>
> He has actively participated in the last two OpenStack Charms release
> processes.  He is also the original author and current maintainer of the
> magpie charm.
>
> Cheers,
>
> Ryan
>
> __
> 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
>
>


-- 
Alex Kavanagh - Software Engineer
Cloud Dev Ops - Solutions & Product Engineering - Canonical Ltd
__
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] Propose Dmitrii Shcherbakov for OpenStack Charmers team.

[James Page]

+1 from me

On Thu, 8 Feb 2018 at 18:23 Billy Olsen  wrote:

> Dmitrii easily gets a +1 from me!
>
> On 02/08/2018 09:42 AM, Alex Kavanagh wrote:
> > Hi
> >
> > I'd like to propose Dmitrii Shcherbakov to join the launchpad
> > "OpenStack Charmers" team.  He's done some tremendous work on existing
> > the charms, has developed some new ones, and has really developed his
> > understanding of configuring and implementing OpenStack.  I think he'd
> > make a great addition to the team.
> >
> > Thanks
> > Alex.
> >
> >
> > --
> > Alex Kavanagh - Software Engineer
> > Cloud Dev Ops - Solutions & Product Engineering - Canonical Ltd
> >
> >
> >
> __
> > 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 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] Propose Dmitrii Shcherbakov for OpenStack Charmers team.

[Billy Olsen]

Dmitrii easily gets a +1 from me!

On 02/08/2018 09:42 AM, Alex Kavanagh wrote:
> Hi
>
> I'd like to propose Dmitrii Shcherbakov to join the launchpad
> "OpenStack Charmers" team.  He's done some tremendous work on existing
> the charms, has developed some new ones, and has really developed his
> understanding of configuring and implementing OpenStack.  I think he'd
> make a great addition to the team.
>
> Thanks
> Alex.
>
>
> -- 
> Alex Kavanagh - Software Engineer
> Cloud Dev Ops - Solutions & Product Engineering - Canonical Ltd
>
>
> __
> 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

Re: [openstack-dev] [charms] evolving the ha interface type

[Liam Young]

Hi James,
I like option 2 but I think there is a problem with it. I don't
think the hacluster charm sets any data down the relation with the
principle until it has first received data from the principle. As I
understand it option 2 would change this behaviour so that hacluster
immediately sets an api-version option for the principle to consume.
The only problem is the principle does not know whether to wait for
this api-version information or not. eg when the principle is deciding
whether to json encode its data it cannot differentiate between:

a) An old version of the hacluster charm which does not support
api-version or json
b) A new version of the hacluster charm which has not set the api-version yet.

Thanks
Liam

__
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] evolving the ha interface type

[Billy Olsen]

On 11/28/2017 01:50 PM, Dmitrii Shcherbakov wrote:

Hi James,

The side effect of using JSON is that we will lose type information:

In [0]: json.loads(json.dumps([{1: 2}]))
Out[0]: [{'1': 2}]

In [1]: ast.literal_eval(repr([{1: 2}]))
Out[1]: [{1: 2}]


I'm not sure this is really an issue for the hacluster interface. To my 
knowledge, all of the keys used for resources today are strings defining 
the pacemaker resource options (clones, groups, colocation options etc). 
The hacluster charm simply formats crm commands with the name/value 
pairs anyways [0]. It is true that type information is lost, but I don't 
think its an issue for this interface.


[0] - 
https://github.com/openstack/charm-hacluster/blob/master/hooks/hooks.py#L314




This is a hard requirement in the JSON spec:

https://tools.ietf.org/html/rfc7159#section-4
"An object structure is represented as a pair of curly brackets
surrounding zero or more name/value pairs (or members).  A name is
a string. "

I wonder if we could use some type-aware serialization format but I do
not have any suggestions without trade-offs because we need to keep in
mind that, in general, charms may not be python charms, may run on
hosts with different protocol parsing libraries etc.

If we only cared about python I would suggest using "pickle" but this
is not universal and not human-readable:

https://docs.python.org/3/library/pickle.html#comparison-with-json
"JSON, by default, can only represent a subset of the Python built-in
types, and no custom classes; pickle can represent an extremely large
number of Python types"

JSON has an advantage of being readable as opposed to a binary protocol
so we can explore what's available in relation data by doing relation-
get without additional tools. It is also ubiquitous so we don't have to
worry about spec changes, parsing bugs and other potential problems.

Thanks for bringing this topic up.

Dmitrii Shcherbakov

__
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

Re: [openstack-dev] [charms] [designate] Domain and server creation during deployment

[Dmitrii Shcherbakov]

Hi Liam,

We may do either of two but I think that we need to somehow make it
clear to a user that a setup is not over yet e.g. via a status string.
As a user you should be able to clear it if you want but I think we
need to provide guidance to somebody who doesn't have a full knowdledge
of all components in an OpenStack deployment.

In other words, if we cannot make it automatic, let's at least guide an
operator that there's more to do.

I think the idea of one-time actions is not that new and may be useful
here. Unless certain leader settings are not set a user would be warned
that this action is yet to be run to complete the setup or he has to
explicitly ignore it.

In my view, we should store enough configuration in leader settings so
that proper config rendering is possible during scale-out while domain
and nameserver creation can be offloaded to an operator.

Thanks,

Dmitrii Shcherbakov

__
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][ptg] PTG planning pad

[Billy Olsen]

A reminder that the PTG is only 2 1/2 weeks away. Please remember to
take time to add any topics that you wish to discuss or sprint on
during the week.

https://etherpad.openstack.org/p/ptg-queens-charms

Thanks,

Billy

On Wed, Aug 9, 2017 at 2:14 AM, James Page  wrote:
> Hi All
>
> I've started a planning etherpad for the PTG next month; feel free to add
> topics you want to discuss/sprint on during the week.
>
>   https://etherpad.openstack.org/p/ptg-queens-charms
>
> Cheers
>
> James
>
> __
> 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

Re: [openstack-dev] [charms] Onboarding session at next weeks summit

[Chris MacNaughton]

I'm looking forward to it!

On Thu, May 4, 2017 at 5:57 PM Andrew Mcleod 
wrote:

> I'll be there too! :)
>
>
> Andrew
>
> On Thu, May 4, 2017 at 5:34 PM, Alex Kavanagh  > wrote:
>
>> I will be there too.  Looking forward to catching up with existing and
>> new people.
>>
>> Cheers
>> Alex.
>>
>> On Tue, May 2, 2017 at 11:36 AM, James Page 
>> wrote:
>>
>>> Hi All
>>>
>>> The OpenStack summit is nearly upon us and for this summit we're running
>>> a project onboarding session on Monday at 4.40pm in MR-105 (see [0] for
>>> full details) for anyone who wants to get started either using the
>>> OpenStack Charms or contributing to the development of the Charms,
>>>
>>> The majority of the core development team will be present so its a great
>>> opportunity to learn more about our project from a use and development
>>> perspective!
>>>
>>> I've created an etherpad at [1] so if you're intending on coming along,
>>> please put your name down with some details on what you would like to get
>>> out of the session.
>>>
>>> Cheers
>>>
>>> James
>>>
>>> [0] http://tiny.cc/onhwky
>>> [1] https://etherpad.openstack.org/p/BOS-forum-charms-onboarding
>>>
>>>
>>> __
>>> 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
>>>
>>>
>>
>>
>> --
>> Alex Kavanagh - Software Engineer
>> Cloud Dev Ops - Solutions & Product Engineering - Canonical Ltd
>>
>> __
>> 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 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] Onboarding session at next weeks summit

[Andrew Mcleod]

I'll be there too! :)


Andrew

On Thu, May 4, 2017 at 5:34 PM, Alex Kavanagh 
wrote:

> I will be there too.  Looking forward to catching up with existing and new
> people.
>
> Cheers
> Alex.
>
> On Tue, May 2, 2017 at 11:36 AM, James Page  wrote:
>
>> Hi All
>>
>> The OpenStack summit is nearly upon us and for this summit we're running
>> a project onboarding session on Monday at 4.40pm in MR-105 (see [0] for
>> full details) for anyone who wants to get started either using the
>> OpenStack Charms or contributing to the development of the Charms,
>>
>> The majority of the core development team will be present so its a great
>> opportunity to learn more about our project from a use and development
>> perspective!
>>
>> I've created an etherpad at [1] so if you're intending on coming along,
>> please put your name down with some details on what you would like to get
>> out of the session.
>>
>> Cheers
>>
>> James
>>
>> [0] http://tiny.cc/onhwky
>> [1] https://etherpad.openstack.org/p/BOS-forum-charms-onboarding
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> Alex Kavanagh - Software Engineer
> Cloud Dev Ops - Solutions & Product Engineering - Canonical Ltd
>
> __
> 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

Re: [openstack-dev] [charms] Onboarding session at next weeks summit

[Pete Vander Giessen]

I will be there. It will kind of be an on-boarding experience for me, too
:-)

On Thu, May 4, 2017 at 11:37 AM Alex Kavanagh 
wrote:

> I will be there too.  Looking forward to catching up with existing and new
> people.
>
> Cheers
> Alex.
>
> On Tue, May 2, 2017 at 11:36 AM, James Page  wrote:
>
>> Hi All
>>
>> The OpenStack summit is nearly upon us and for this summit we're running
>> a project onboarding session on Monday at 4.40pm in MR-105 (see [0] for
>> full details) for anyone who wants to get started either using the
>> OpenStack Charms or contributing to the development of the Charms,
>>
>> The majority of the core development team will be present so its a great
>> opportunity to learn more about our project from a use and development
>> perspective!
>>
>> I've created an etherpad at [1] so if you're intending on coming along,
>> please put your name down with some details on what you would like to get
>> out of the session.
>>
>> Cheers
>>
>> James
>>
>> [0] http://tiny.cc/onhwky
>> [1] https://etherpad.openstack.org/p/BOS-forum-charms-onboarding
>>
>> __
>> 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
>>
>>
>
>
> --
> Alex Kavanagh - Software Engineer
> Cloud Dev Ops - Solutions & Product Engineering - Canonical Ltd
> __
> 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

Re: [openstack-dev] [charms] Onboarding session at next weeks summit

[Alex Kavanagh]

I will be there too.  Looking forward to catching up with existing and new
people.

Cheers
Alex.

On Tue, May 2, 2017 at 11:36 AM, James Page  wrote:

> Hi All
>
> The OpenStack summit is nearly upon us and for this summit we're running a
> project onboarding session on Monday at 4.40pm in MR-105 (see [0] for full
> details) for anyone who wants to get started either using the OpenStack
> Charms or contributing to the development of the Charms,
>
> The majority of the core development team will be present so its a great
> opportunity to learn more about our project from a use and development
> perspective!
>
> I've created an etherpad at [1] so if you're intending on coming along,
> please put your name down with some details on what you would like to get
> out of the session.
>
> Cheers
>
> James
>
> [0] http://tiny.cc/onhwky
> [1] https://etherpad.openstack.org/p/BOS-forum-charms-onboarding
>
> __
> 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
>
>


-- 
Alex Kavanagh - Software Engineer
Cloud Dev Ops - Solutions & Product Engineering - Canonical Ltd
__
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] Onboarding session at next weeks summit

[David Ames]

I'll be there.


--
David Ames

On Tue, May 2, 2017 at 3:36 AM, James Page  wrote:
> Hi All
>
> The OpenStack summit is nearly upon us and for this summit we're running a
> project onboarding session on Monday at 4.40pm in MR-105 (see [0] for full
> details) for anyone who wants to get started either using the OpenStack
> Charms or contributing to the development of the Charms,
>
> The majority of the core development team will be present so its a great
> opportunity to learn more about our project from a use and development
> perspective!
>
> I've created an etherpad at [1] so if you're intending on coming along,
> please put your name down with some details on what you would like to get
> out of the session.
>
> Cheers
>
> James
>
> [0] http://tiny.cc/onhwky
> [1] https://etherpad.openstack.org/p/BOS-forum-charms-onboarding
>
> __
> 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

Re: [openstack-dev] [charms] Onboarding session at next weeks summit

[Corey Bryant]

I'll be there as well. Looking forward to seeing everyone and meeting some
new folks.

Corey

On Tue, May 2, 2017 at 6:36 AM, James Page  wrote:

> Hi All
>
> The OpenStack summit is nearly upon us and for this summit we're running a
> project onboarding session on Monday at 4.40pm in MR-105 (see [0] for full
> details) for anyone who wants to get started either using the OpenStack
> Charms or contributing to the development of the Charms,
>
> The majority of the core development team will be present so its a great
> opportunity to learn more about our project from a use and development
> perspective!
>
> I've created an etherpad at [1] so if you're intending on coming along,
> please put your name down with some details on what you would like to get
> out of the session.
>
> Cheers
>
> James
>
> [0] http://tiny.cc/onhwky
> [1] https://etherpad.openstack.org/p/BOS-forum-charms-onboarding
>
> __
> 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

Re: [openstack-dev] [charms] Onboarding session at next weeks summit

[Ryan Beisner]

I plan to be there.  Looking forward to it!
-Ryan

On Tue, May 2, 2017 at 6:36 AM, James Page  wrote:

> Hi All
>
> The OpenStack summit is nearly upon us and for this summit we're running a
> project onboarding session on Monday at 4.40pm in MR-105 (see [0] for full
> details) for anyone who wants to get started either using the OpenStack
> Charms or contributing to the development of the Charms,
>
> The majority of the core development team will be present so its a great
> opportunity to learn more about our project from a use and development
> perspective!
>
> I've created an etherpad at [1] so if you're intending on coming along,
> please put your name down with some details on what you would like to get
> out of the session.
>
> Cheers
>
> James
>
> [0] http://tiny.cc/onhwky
> [1] https://etherpad.openstack.org/p/BOS-forum-charms-onboarding
>
> __
> 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

Re: [openstack-dev] [charms] Incorrect Padding for SSL Cert/Key

[James Beedy]

Ok, progress. I've encoded my cert and key to base64 strings and specified
them in my haproxy config, and seem to be getting past the padding error.
My issue now, is that I am not seeing the cert/key in /etc/ssl/private on
the haproxy host once deployed. I'm thinking specifying the ssl cert/key
will work for the Openstack charms now that I've got the encoding part
squared away. Still stumped by haproxy though ... can't seem to get it
provision the cert/key correctly for the life of me. Possibly there is
something else I'm missing here ...

On Sat, Jan 28, 2017 at 1:04 PM, James Beedy  wrote:

> I'm having issues with padding when trying to specify key/cert as config
> options for Haproxy, and have experienced the same issue in the past, when
> trying to specify key/cert for the Openstack charms. Could someone give an
> example of what the correct padding of a base64 encoded ssl cert might look
> like in the charm config yaml.
>
> My charm config looks like this -> http://paste.ubuntu.com/23882917/
>
> The error I'm getting is this -> http://paste.ubuntu.com/23882921/
>
> Thanks
>
__
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] monitoring interface

[Brad Marshall]

On Thu, Jan 19, 2017 at 12:44:22PM +, Liam Young wrote:
> Thanks for looking into it. I think things should actually work out of the
> box as they are now. So,
> 
> Should add nagios checks for glance and cinder to the juju deployed nagios.
> (Taken from
> https://wiki.ubuntu.com/OpenStack/OpenStackCharms/ReleaseNotes1504#Monitoring
> ).
> 
> Ideally we would rename the nrpe-external-master interface to local-monitor
> (or add it as an additional interface) but that is not needed to get it up
> and running.

The problem we were seeing was the nrpe charm wasn't passing the default
checks across, there's been a bug floating around for a while - LP#1605733.

There is a fix in that bug report which we've tried out and it seems to
fix the issue, but I'm not sure if there's any other side effects.

Thanks,
Brad
-- 
Brad Marshall
Cloud Reliability Engineer
Bootstack Squad, Canonical

__
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] monitoring interface

[Liam Young]

Hi Brad,

Thanks for looking into it. I think things should actually work out of the
box as they are now. So,

juju deploy nrpe nrpe-glance
juju deploy nrpe nrpe-cinder
juju deploy nagios
juju deploy glance
juju deploy cinder
juju add-relation nrpe-glance glance
juju add-relation nrpe-glance nagios
juju add-relation nrpe-cinder cinder
juju add-relation nrpe-cinder nagios

Should add nagios checks for glance and cinder to the juju deployed nagios.
(Taken from
https://wiki.ubuntu.com/OpenStack/OpenStackCharms/ReleaseNotes1504#Monitoring
).

Ideally we would rename the nrpe-external-master interface to local-monitor
(or add it as an additional interface) but that is not needed to get it up
and running.

Thanks
Liam

On 18 January 2017 at 16:07, Brad Marshall 
wrote:

> Hi all,
>
> We're looking at adding the monitor interface to the openstack charms to
> enable us to use the nagios charm, rather than via an external nagios
> using nrpe-external-master.
>
> I believe this will just be a matter of adding in the interface, adding
> an appropriate monitor.yaml that defines the checks, and updating
> charmhelpers.contrib.charmsupport.nrpe so that when it adds checks, it
> passes the appropriate information onto the relationship.
>
> Are there any concerns with this approach? Any suggestions on things to
> watch out for?  It does mean touching every charm, but I can't see any
> other way around it.
>
> Thanks,
> Brad
> --
> Brad Marshall
> Cloud Reliability Engineer
> Bootstack Squad, Canonical
>
> __
> 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

Re: [openstack-dev] [charms] ceilometer metering and event time-to-live defaults

[James Page]

Hi Julien

On Tue, 3 Jan 2017 at 09:17 Julien Danjou  wrote:

> > In the current ceilometer charms, we retain all ceilometer data
> > indefinitely;  the TTL can be overridden by users using configuration
> > options, but to me it feels like maybe retaining all data forever by
> > default is a trip hazard to users, and the actions required to backout
> of a
> > full DB for not that nice:
> >
> >   https://bugs.launchpad.net/charms/+source/ceilometer/+bug/1652856
> >
> > Any thoughts? What TTL defaults do deployments (and other deployment
> tools)
> > typically use for ceilometer data?
>
> The default are set to no expiry because we felt like deleting data by
> default is not a good choice. If there's a consensus that the default
> should be something else, maybe that could be fixed directly upstream.
>

Yeah - that's why we've had no expiry as a default as well.

I'm not convinced we need to switch - just felt like we could do more in a
number of ways to help users not trip over this.


> Now, I'd like to emphasize that this part of Ceilometer is officially
> deprecated, so I hope not too much effort is put into this, and more in
> the new projects that are now recommended (i.e. Gnocchi). :-)


Indeed - however the charms support older versions of OpenStack as well, so
to an extent we have to look back to the past as well as forward to the
future!

Cheers

James
__
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] ceilometer metering and event time-to-live defaults

[Julien Danjou]

On Tue, Jan 03 2017, James Page wrote:

Hi James,

> In the current ceilometer charms, we retain all ceilometer data
> indefinitely;  the TTL can be overridden by users using configuration
> options, but to me it feels like maybe retaining all data forever by
> default is a trip hazard to users, and the actions required to backout of a
> full DB for not that nice:
>
>   https://bugs.launchpad.net/charms/+source/ceilometer/+bug/1652856
>
> Any thoughts? What TTL defaults do deployments (and other deployment tools)
> typically use for ceilometer data?

The default are set to no expiry because we felt like deleting data by
default is not a good choice. If there's a consensus that the default
should be something else, maybe that could be fixed directly upstream.

Now, I'd like to emphasize that this part of Ceilometer is officially
deprecated, so I hope not too much effort is put into this, and more in
the new projects that are now recommended (i.e. Gnocchi). :-)

Cheers,
-- 
Julien Danjou
/* Free Software hacker
   https://julien.danjou.info */


signature.asc
Description: PGP signature
__
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] Barbican + Identity Standalone - AWS

[Marco Ceppi]

Hey James!

We were looking at adding Keystone as a user management backend for
Kubernetes. This is a great step forward in making that possible, I noticed
the barbican charm in the AWS deploy was "local", are there any major
changes to the charm from ~openstack-charmers needed for it to run in AWS?

Marco

On Wed, Nov 30, 2016 at 6:50 AM Mark Shuttleworth  wrote:

>
> Might be worth sharing this on some of the OpenStack lists too, for folks
> who are interested in using Horizon this way on other substrates.
>
> Mark
>
>
> On 29/11/16 21:36, James Beedy wrote:
>
> Another great day of Juju driven successes - deploying the barbican
> standalone stack for identity mgmt and secrets mgmt. For those that don't
> know, newton horizon brings support for identity only! This means you can
> (as I am) use the openstack-dashboard for mgmt of just users, projects, and
> domains, without a full Openstack! In previous Openstack releases, if you
> hooked up horizon and you didn't have the core Openstack services
> registered in your service catalogue, horizon would throw errors and would
> be unusable. This is a huge win for those wanting object storage and
> identity mgmt only, too!
>
> AWS Barbican Stack -> http://paste.ubuntu.com/23556001/
>
> LXD Barbican Bundle (with script to help get started setting secrets in
> barbican)-> https://github.com/jamesbeedy/juju-barbican-lxd-bundle
>
> Also, here's a utility function from barbican-client layer I've been using
> to make getting secrets from barbican containers easy for charms (WIP) ->
> https://github.com/jamesbeedy/juju-layer-barbican-client/blob/master/lib/charms/layer/barbican_client.py
>
> ~james
>
>
>
> --
> Juju mailing list
> j...@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
__
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] layer/source charm project-config changes

[Ryan Beisner]

Following review initial review and corresponding mods, this is ready for
re-review.
Cheers,
Ryan

On Mon, Nov 21, 2016 at 2:16 PM, Ryan Beisner 
wrote:

> Good day OpenStack Charmers,
>
> Project-config change proposed, ready for review:
> https://review.openstack.org/#/c/399299/
>
> To address bug:
> https://launchpad.net/bugs/1642981
>
> Which is preventing landing of even trivial changes in the source/layer
> repos:
> https://review.openstack.org/#/q/topic:update-readme+owner:%
> 22Ryan+Beisner%22+status:open
>
> Please do have a very close look at what I'm redefining here.
>
> Thanks in advance!
>
> Ryan
>
__
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] Barbican Hostname Config Params

[James Page]

Hi James

On Thu, 17 Nov 2016 at 20:05 James Beedy  wrote:

> Is there a specific reason the barbican charm doesn't have the
> os-{internal,private}-hostname config params?
>

The layers and charms.openstack don't currently have support for the
os-*-hostname configuration options yes  - barbican, aodh and designate are
all based off this stack of components so are a little different in
structure than some of the older charms.

We'll put these options on the TODO list (if they are not already there).

Cheers

James
__
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] Deploy Keystone To Public Cloud

[Andrey Pavlov]

Yeah, I had the same situation in Juju 2.0 ! (all is ok with Juju 1.25)
(with AWS provider)

It happens because OpenStack charms started to use 'network-get
--primary-address public' instead of 'unit-get'.
Then 'network-get public' returns private address and then charms register
endpoint with private address and then they do not work from outside.
I could solve this only be setting 'os-public-hostname' to floating-ip of
specific machine.

On Thu, Nov 17, 2016 at 2:14 AM, James Beedy  wrote:

> I'm having an issue getting a response back (mostly timeouts occur) when
> trying to talk to keystone deployed to AWS using private (on vpn) or public
> ip address. I've had luck with setting os-*-hostname configs, and ssh'ing
> in and running the keystone/openstack client locally from the keystone
> instance after adding the private ip <-> fqdn mapping in
> keystone:/etc/hosts, but can't seem to come up with any combination that
> lets me talk to the keystone api remotely. Just to be clear, I'm only
> deploying keystone and percona-cluster charms to AWS, not all of Openstack.
>
> If not possible using the ec2 provider, is this a possibility with any
> public providers?
>
> Thanks
>
> __
> 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
>
>


-- 
Kind regards,
Andrey Pavlov.
__
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] Deploy Keystone To Public Cloud

[Marco Ceppi]

This should work, a charm school at ODS drove this exact thing. I'll give
it a try tomorrow to see if I can help.

Marco

On Thu, Nov 17, 2016, 12:14 AM James Beedy  wrote:

> I'm having an issue getting a response back (mostly timeouts occur) when
> trying to talk to keystone deployed to AWS using private (on vpn) or public
> ip address. I've had luck with setting os-*-hostname configs, and ssh'ing
> in and running the keystone/openstack client locally from the keystone
> instance after adding the private ip <-> fqdn mapping in
> keystone:/etc/hosts, but can't seem to come up with any combination that
> lets me talk to the keystone api remotely. Just to be clear, I'm only
> deploying keystone and percona-cluster charms to AWS, not all of Openstack.
>
> If not possible using the ec2 provider, is this a possibility with any
> public providers?
>
> Thanks
> --
> Juju mailing list
> j...@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
__
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] Default KeystoneV3 Creds

[Liam Young]

On Fri, Nov 11, 2016 at 12:41 AM, James Beedy  wrote:

> Concerning the Juju Keystone charm, and api v3, can someone shed some
> light on how to find the default admin creds needed to access the keystone
> api, or what the novarc file might look like? I'm setting the
> 'admin-password' config of the keystone charm to "openstack", and am using
> this -> http://paste.ubuntu.com/23458768/ for my .novarc, but am getting
> a 401 -> http://paste.ubuntu.com/23458782/
>

https://wiki.ubuntu.com/OpenStack/OpenStackCharms/ReleaseNotes1604#Keystone_v3_API_support
should point you in the right direction


>
> Is there something I'm missing here?
>
> thx
>
> __
> 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

Re: [openstack-dev] [charms]Running two haproxy-using units on same machine?

[James Page]

I can't find the provider/colocation document I wrote a while back (its
disappeared from the canonical wiki)

I'll re-write it in the charm-guide soon.

On Wed, 14 Sep 2016 at 10:03 Neil Jerram  wrote:

> Thanks James for this quick and clear answer!
>
> Neil
>
>
> On Tue, Sep 13, 2016 at 8:46 PM, James Page  wrote:
>
>> Hi Neil
>>
>> On Tue, 13 Sep 2016 at 20:43 Neil Jerram  wrote:
>>
>>> Should it be possible to run two OpenStack charm units, that both use
>>> haproxy to load balance their APIs, on the same machine?  Or is there some
>>> doc somewhere that says that a case like that should use separate machines?
>>>
>>> (I'm asking in connection with the bug report at
>>> https://bugs.launchpad.net/openstack-charm-testing/+bug/1622697.)
>>>
>>
>> No - that's not currently possible.  For example, if you try to place
>> both nova-cloud-controller and cinder units on the same machine, they both
>> assume sole control over haproxy.cfg and will happily trample each others
>> changes.
>>
>> There is a doc somewhere - I'll dig it out and add to the charm-guide on
>> docs.openstack.org.
>>
>> Solution: use a LXC or LXD container for each service, assuring sole
>> control of the filesystem for each charm, avoiding said conflict.
>>
>> Cheers
>>
>> James
>>
>> __
>> 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 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]Running two haproxy-using units on same machine?

[Neil Jerram]

Thanks James for this quick and clear answer!

Neil


On Tue, Sep 13, 2016 at 8:46 PM, James Page  wrote:

> Hi Neil
>
> On Tue, 13 Sep 2016 at 20:43 Neil Jerram  wrote:
>
>> Should it be possible to run two OpenStack charm units, that both use
>> haproxy to load balance their APIs, on the same machine?  Or is there some
>> doc somewhere that says that a case like that should use separate machines?
>>
>> (I'm asking in connection with the bug report at
>> https://bugs.launchpad.net/openstack-charm-testing/+bug/1622697.)
>>
>
> No - that's not currently possible.  For example, if you try to place both
> nova-cloud-controller and cinder units on the same machine, they both
> assume sole control over haproxy.cfg and will happily trample each others
> changes.
>
> There is a doc somewhere - I'll dig it out and add to the charm-guide on
> docs.openstack.org.
>
> Solution: use a LXC or LXD container for each service, assuring sole
> control of the filesystem for each charm, avoiding said conflict.
>
> Cheers
>
> James
>
> __
> 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

Re: [openstack-dev] [charms]Running two haproxy-using units on same machine?

[James Page]

Hi Neil

On Tue, 13 Sep 2016 at 20:43 Neil Jerram  wrote:

> Should it be possible to run two OpenStack charm units, that both use
> haproxy to load balance their APIs, on the same machine?  Or is there some
> doc somewhere that says that a case like that should use separate machines?
>
> (I'm asking in connection with the bug report at
> https://bugs.launchpad.net/openstack-charm-testing/+bug/1622697.)
>

No - that's not currently possible.  For example, if you try to place both
nova-cloud-controller and cinder units on the same machine, they both
assume sole control over haproxy.cfg and will happily trample each others
changes.

There is a doc somewhere - I'll dig it out and add to the charm-guide on
docs.openstack.org.

Solution: use a LXC or LXD container for each service, assuring sole
control of the filesystem for each charm, avoiding said conflict.

Cheers

James
__
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] nominating thedac for charms-release team

[Billy Olsen]

+1

On Tue, Aug 9, 2016 at 9:13 AM, James Page  wrote:
> On Mon, 8 Aug 2016 at 18:19 Ryan Beisner  wrote:
>>
>> Greetings,
>>
>> I would like to nominate David Ames  for addition to the
>> charms-release team, as he has played a valuable role in the charm release
>> processes.  This change will grant privileges such as new stable branch
>> creation, among other things necessary to facilitate the charm release
>> process.
>
>
> +1
>
> __
> 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

Re: [openstack-dev] [charms] nominating thedac for charms-release team

[James Page]

On Mon, 8 Aug 2016 at 18:19 Ryan Beisner  wrote:

> Greetings,
>
> I would like to nominate David Ames  for addition to the
> charms-release team, as he has played a valuable role in the charm release
> processes.  This change will grant privileges such as new stable branch
> creation, among other things necessary to facilitate the charm release
> process.
>

+1
__
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] Project mascot

[Fawaz Mohammed]

I suggest horse, fast animal, faster deployment :) .

On Wed, Jul 20, 2016 at 10:39 PM, Billy Olsen  wrote:

> I like the idea of the Kraken...
>
> though I think I like the giant squid over an octopus, but either one
> is in the same vein :-)
>
> On Mon, Jul 18, 2016 at 1:27 AM, James Page  wrote:
> > Hi All
> >
> > As an approved project, we need to provide some ideas for a project
> mascot
> > for the Charms project (see [0]).
> >
> > Some suggestions as discussed on IRC:
> >
> > 1) cobra ('[snake] charming openstack') - which aligns with the Juju
> logo a
> > little.
> > 2) kraken ('many armed animal managing openstack') - but I think that
> falls
> > into mythical creatures so its probably excluded so maybe octopus
> instead?
> >
> > It would be nice to have one or two more ideas - any suggestions?
> >
> > Cheers
> >
> > James
> >
> > [0] http://www.openstack.org/project-mascots
> >
> >
> __
> > 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 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] Project mascot

[Billy Olsen]

I like the idea of the Kraken...

though I think I like the giant squid over an octopus, but either one
is in the same vein :-)

On Mon, Jul 18, 2016 at 1:27 AM, James Page  wrote:
> Hi All
>
> As an approved project, we need to provide some ideas for a project mascot
> for the Charms project (see [0]).
>
> Some suggestions as discussed on IRC:
>
> 1) cobra ('[snake] charming openstack') - which aligns with the Juju logo a
> little.
> 2) kraken ('many armed animal managing openstack') - but I think that falls
> into mythical creatures so its probably excluded so maybe octopus instead?
>
> It would be nice to have one or two more ideas - any suggestions?
>
> Cheers
>
> James
>
> [0] http://www.openstack.org/project-mascots
>
> __
> 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

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

Re: [openstack-dev] [charms] Re-licensing OpenStack charms under Apache 2.0

[Gabriel Samfira]

Hi James,


No problem on my side. This is a welcome change!

Regards,
Gabriel Samfira
Cloudbase Solutions SRL

On Mi, 2016-06-08 at 10:20 +, James Page wrote:
> Hi
> 
> We're currently blocked on becoming an OpenStack project under the
> big-tent by the licensing of the 26 OpenStack charms under GPL v3.
> 
> I'm proposing that we re-license the following code repositories as
> Apache 2.0:
> 
>   charm-ceilometer
>   charm-ceilometer-agent
>   charm-ceph
>   charm-ceph-mon
>   charm-ceph-osd
>   charm-ceph-radosgw
>   charm-cinder
>   charm-cinder-backup
>   charm-cinder-ceph
>   charm-glance
>   charm-hacluster
>   charm-heat
>   charm-keystone
>   charm-lxd
>   charm-neutron-api
>   charm-neutron-api-odl
>   charm-neutron-gateway
>   charm-neutron-openvswitch
>   charm-nova-cloud-controller
>   charm-nova-compute
>   charm-odl-controller
>   charm-openstack-dashboard
>   charm-openvswitch-odl
>   charm-percona-cluster
>   charm-rabbitmq-server
>   charm-swift-proxy
>   charm-swift-storage
> 
> The majority of contributors are from Canonical (from whom I have
> permission to make this switch) with a further 18 contributors from
> outside of Canonical who I will be directly contacting for approval
> in gerrit as reviews are raised for each repository.
> 
> Any new charms and supporting repositories will be licensed under
> Apache 2.0 from the outset.
> 
> Cheers
> 
> James
> _
> _
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubs
> cribe
> 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

Re: [openstack-dev] [charms] Re-licensing OpenStack charms under Apache 2.0

[Andrey Pavlov]

Hello James,

No problem on my side.

Regards,
Andrey.

On Wed, Jun 8, 2016 at 1:20 PM, James Page  wrote:
> Hi
>
> We're currently blocked on becoming an OpenStack project under the big-tent
> by the licensing of the 26 OpenStack charms under GPL v3.
>
> I'm proposing that we re-license the following code repositories as Apache
> 2.0:
>
>   charm-ceilometer
>   charm-ceilometer-agent
>   charm-ceph
>   charm-ceph-mon
>   charm-ceph-osd
>   charm-ceph-radosgw
>   charm-cinder
>   charm-cinder-backup
>   charm-cinder-ceph
>   charm-glance
>   charm-hacluster
>   charm-heat
>   charm-keystone
>   charm-lxd
>   charm-neutron-api
>   charm-neutron-api-odl
>   charm-neutron-gateway
>   charm-neutron-openvswitch
>   charm-nova-cloud-controller
>   charm-nova-compute
>   charm-odl-controller
>   charm-openstack-dashboard
>   charm-openvswitch-odl
>   charm-percona-cluster
>   charm-rabbitmq-server
>   charm-swift-proxy
>   charm-swift-storage
>
> The majority of contributors are from Canonical (from whom I have permission
> to make this switch) with a further 18 contributors from outside of
> Canonical who I will be directly contacting for approval in gerrit as
> reviews are raised for each repository.
>
> Any new charms and supporting repositories will be licensed under Apache 2.0
> from the outset.
>
> Cheers
>
> James
>
> __
> 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
>



-- 
Kind regards,
Andrey Pavlov.

__
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] Re-licensing OpenStack charms under Apache 2.0

[Antoni Segura Puimedon]

On Fri, Jun 10, 2016 at 6:45 PM, Bilal Baqar  wrote:

> Hey James
>
> No problem on my side for this change.
>
> Regards
>
> On Fri, Jun 10, 2016 at 3:25 PM, Neil Jerram  wrote:
>
>> Me too.
>>
>> On Fri, Jun 10, 2016 at 10:32 AM Cory Benfield  wrote:
>>
>>>
>>> > On 8 Jun 2016, at 11:20, James Page  wrote:
>>> >
>>> > The majority of contributors are from Canonical (from whom I have
>>> permission to make this switch) with a further 18 contributors from outside
>>> of Canonical who I will be directly contacting for approval in gerrit as
>>> reviews are raised for each repository.
>>>
>>
No problem on my side either.


>
>>> Hey James,
>>>
>>> I’m happy for you to relicense my contributions as Apache 2.0.
>>>
>>> Cory
>>>
>>>
>>> __
>>> 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
>>
>>
>
>
> --
> Bilal Baqar
> MTS - PLUMgrid Inc.
>
>
>
> __
> 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

Re: [openstack-dev] [charms] Re-licensing OpenStack charms under Apache 2.0

[Bilal Baqar]

Hey James

No problem on my side for this change.

Regards

On Fri, Jun 10, 2016 at 3:25 PM, Neil Jerram  wrote:

> Me too.
>
> On Fri, Jun 10, 2016 at 10:32 AM Cory Benfield  wrote:
>
>>
>> > On 8 Jun 2016, at 11:20, James Page  wrote:
>> >
>> > The majority of contributors are from Canonical (from whom I have
>> permission to make this switch) with a further 18 contributors from outside
>> of Canonical who I will be directly contacting for approval in gerrit as
>> reviews are raised for each repository.
>>
>> Hey James,
>>
>> I’m happy for you to relicense my contributions as Apache 2.0.
>>
>> Cory
>>
>> __
>> 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
>
>


-- 
Bilal Baqar
MTS - PLUMgrid Inc.
__
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] Re-licensing OpenStack charms under Apache 2.0

[Neil Jerram]

Me too.

On Fri, Jun 10, 2016 at 10:32 AM Cory Benfield  wrote:

>
> > On 8 Jun 2016, at 11:20, James Page  wrote:
> >
> > The majority of contributors are from Canonical (from whom I have
> permission to make this switch) with a further 18 contributors from outside
> of Canonical who I will be directly contacting for approval in gerrit as
> reviews are raised for each repository.
>
> Hey James,
>
> I’m happy for you to relicense my contributions as Apache 2.0.
>
> Cory
>
> __
> 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

Re: [openstack-dev] [charms] Re-licensing OpenStack charms under Apache 2.0

[Cory Benfield]

> On 8 Jun 2016, at 11:20, James Page  wrote:
> 
> The majority of contributors are from Canonical (from whom I have permission 
> to make this switch) with a further 18 contributors from outside of Canonical 
> who I will be directly contacting for approval in gerrit as reviews are 
> raised for each repository.

Hey James,

I’m happy for you to relicense my contributions as Apache 2.0.

Cory



signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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] Re-licensing OpenStack charms under Apache 2.0

[Gauvain Pocentek]

Hi James,

Le 2016-06-08 12:20, James Page a écrit :

Hi

We're currently blocked on becoming an OpenStack project under the
big-tent by the licensing of the 26 OpenStack charms under GPL v3.

I'm proposing that we re-license the following code repositories as 
Apache 2.0:


  charm-ceilometer
  charm-ceilometer-agent
  charm-ceph
  charm-ceph-mon
  charm-ceph-osd
  charm-ceph-radosgw
  charm-cinder
  charm-cinder-backup
  charm-cinder-ceph
  charm-glance
  charm-hacluster
  charm-heat
  charm-keystone
  charm-lxd
  charm-neutron-api
  charm-neutron-api-odl
  charm-neutron-gateway
  charm-neutron-openvswitch
  charm-nova-cloud-controller
  charm-nova-compute
  charm-odl-controller
  charm-openstack-dashboard
  charm-openvswitch-odl
  charm-percona-cluster
  charm-rabbitmq-server
  charm-swift-proxy
  charm-swift-storage

The majority of contributors are from Canonical (from whom I have
permission to make this switch) with a further 18 contributors from
outside of Canonical who I will be directly contacting for approval in
gerrit as reviews are raised for each repository.


No problem on my side to change the license to apache 2.0.

Thanks for checking with us.

Gauvain




Any new charms and supporting repositories will be licensed under
Apache 2.0 from the outset.

Cheers

James
__
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


Gauvain Pocentek

Objectif Libre - Infrastructure et Formations Linux
http://www.objectif-libre.com
phone: +33 972 54 98 01 / +33 611 60 84 25

__
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] Renaming openvswitch-odl -> openvswitch

[Ryan Beisner]

Project renames are limited to certain maintenance windows @ infra, so
that's something to be aware of re: timing and coordination.

Also for clarity, can we discuss and highlight the differing use cases and
eventual plans a bit re: the neutron-openvswitch subordinate charm vs. the
openvswitch subordinate charm?

Cheers,

Ryan

On Wed, Jun 8, 2016 at 4:37 AM, James Page  wrote:

> Hi All
>
> The current openvswitch-odl charm is designed for use with
> nova-compute/neutron-gateway and the odl-controller charm, but it declares
> and configures OVS in such a way that I think it has broader applicability
> than just OpenDayLight; specifically it looks like it would also work with
> ONOS which configures the OVS manager in exactly the same way as for ODL.
>
> I'd like to proposed renaming the openvswitch-odl charm to just
> openvswitch to support this generalisation of its use.
>
> Thoughts?
>
>
> __
> 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

Re: [openstack-dev] [charms] Juju Charms for OpenStack

[Neil Jerram]

+1 from me (as an OpenStack contributor, and one of those 'developers at
SDN and storage vendors' :-) ).

  Neil


On Thu, May 19, 2016 at 11:38 AM James Page  wrote:

> Hi All
>
> tl;dr Juju is a great way of deploying OpenStack, and we'd like the
> OpenStack Charms for Juju to become a official OpenStack Project
>
> read on if you want the full details
>
> Juju [0] is a service modelling tool that's been around since about 2010;
> developed primarily by Canonical, Juju takes a high level approach to
> modelling services and the relations between them (think cinder,
> neutron-api, nova-cloud-controller), with the details on exactly how each
> of those services is installed, configured, scaled-up, scaled-down, HA'ed
> etc.. implemented by a charm for each of the services that form part of a
> model;  Juju uses underlying providers (responsible for managing compute,
> storage and network resources) to translate the model onto actual machine
> resources - in the context of OpenStack, the MAAS (metal-as-a-service [1])
> provider is used to deploy an OpenStack model, using the OpenStack Charms,
> to a combination of physical servers and LXD containers running on those
> servers.
>
> The OpenStack Charms have been around for about the same time as Juju; I
> think the first release we supported was OpenStack Diablo, and we've
> updated, redesigned and re-factored the charms to support every OpenStack
> release on Ubuntu since then.
>
> The OpenStack Charms are a core part of the Ubuntu OpenStack teams
> approach to distributing OpenStack on Ubuntu (we use them for all of our
> deployment and testing CI, as well as for deploying production OpenStack
> Clouds at Canonical's customers). As a result when OpenStack releases we've
> always had aligned support in Ubuntu and the OpenStack charms for the
> latest release.
>
> The OpenStack charms (26 of them including some things not specifically
> OpenStack such as Ceph, Percona XtraDB Cluster and RabbitMQ) are written in
> Python; the code base has evolved a-lot over the years (once upon a time
> they where bash scripts), as has the approach to writing best practice
> charms, and we expect new OpenStack charms to take a slightly different
> approach to charm authoring which should make writing a new OpenStack charm
> much more lightweight (see [3]).
>
> We migrated development to OpenStack project infrastructure (from its
> original home in Launchpad and Bazaar branches) around 4 months ago at the
> request of the TC from our original request to be formally recognised as an
> OpenStack project; we now have some history that's readily re-viewable so
> I've restored our request to become a formal OpenStack project:
>
>  https://review.openstack.org/224797
>
> The community of developers around the charms is not as diverse as I would
> like, but we've had a number of contributions from developers at SDN and
> storage vendors (who are also maintaining charms for their own solutions)
> as well as contribution from CloudBase for enabling support for Microsoft
> Hyper-V in a Juju deployed OpenStack Cloud (Juju and MAAS can deploy
> WIndows machines as well).
>
> We have some outstanding work to consolidate developer and user
> documentation around the OpenStack charms, which the team currently expect
> to complete in the next few months.
>
> Cheers
>
> James
>
> [0] https://jujucharms.com/
> [1] https;//maas.ubuntu.com/
> [2] https://jujucharms.com/openstack
> [3]
> https://github.com/openstack-charmers/openstack-community/blob/master/openstack-api-charm-creation-guide.md
>
> __
> 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