[openstack-dev] [charms] 18.11 OpenStack Charms release

[David Ames]

Announcing the 18.11 release of the OpenStack Charms.

The 18.11 charms have support for Nova cells v2 for deployments of
Queens and later. The 18.11 release also has preview features including
series upgrades and the Octavia load balancer charm. 47 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/1811.html

Thanks go to the following contributors for this release:

Alex Kavanagh
Andrey Grebennikov
Aymen  Frikha
Billy Olsen
Chris MacNaughton
Chris Sanders
Corey Bryant
David Ames
Dmitrii Shcherbakov
Drew Freiberger
Edward Hope-Morley
Felipe Reyes
Frode Nordahl
Fulvio Galeazzi
James Page
Liam Young
Neiloy Mukerjee
Pedro Guimarães
Pete Vander Giessen
Ryan Beisner
Vladimir Grevtsev
dongdong tao
viswesuwara nathan

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

[openstack-dev] [charms] retiring the ceph charm

[James Page]

Hi All

We deprecated and stopped releasing the ceph charm a few cycles back in
preference to the split ceph-osd/ceph-mon charms; consider this official
notification of retirement!

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

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

[James Page]

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

[openstack-dev] [charms] 18.08 OpenStack Charms release

[David Ames]

Announcing the 18.08 release of the OpenStack Charms.

The 18.08 charms have support for the Rocky OpenStack, Ceph Mimic and
Keystone fernet token support. 51 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/1808.html

Thanks go to the following contributors for this release:

James Page
Frode Nordahl
David Ames
Chris MacNaughton
Ryan Beisner
Liam Young
Corey Bryant
Alex Kavanagh
Dmitrii Shcherbakov
Edward Hope-Morley
Van Hung Pham
Shane Peters
Billy Olsen
Nobuto Murata
Sean Feole
Pete Vander Giessen
daixianmeng
wangqi
Felipe Reyes
Nikolay Nikolaev
guozj
Nicolas Pochet
Nam
Xav Paice
Hua Zhang
huang.zhiping
Brin Zhang
Andrew McLeod
Tilman Baumann
yuhaijia
lvxianguo
Roger Yu
Chris Sanders
Rajat Dhasmana
zhangmin

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

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

[Billy Olsen]

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

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

[openstack-dev] [charms] Deployment guide stable/rocky cut

[Frode Nordahl]

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

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

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

[Frode Nordahl]

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

[openstack-dev] [charms] PTL non-candidacy for Stein cycle

[James Page]

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

[openstack-dev] [charms][ptg] Stein PTG planning etherpad for Charms

[Frode Nordahl]

Hello Charmers,

A etherpad for planning of the upcoming PTG in Denver has been created [0].

Please make a note signalling your attendance and any topics you want
covered.

0: https://etherpad.openstack.org/p/charms-stein-ptg

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

[openstack-dev] [charms] 18.05 OpenStack Charms release

[David Ames]

Announcing the 18.05 release of the OpenStack Charms.

The 18.05 charms have full support for the Bionic Ubuntu series.
Encryption at rest has been implemented in the storage charms.
In addition, the vault and neutron-dynamic-routing charms have been
introduced. 72 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.05.html

Thanks go to the following contributors for this release:

Alex Kavanagh
Andrew McLeod
Ante Karamatić
Billy Olsen
Chris MacNaughton
Chris Sanders
Corey Bryant
Craige McWhirter
David Ames
Drew Freiberger
Edward Hope-Morley
Felipe Reyes
Frode Nordahl
Fulvio Galeazzi
Jakub Rohovsky
James Hebden
James Page
Liam Young
Mario Splivalo
Michael Skalka
Peter Sabaini
Ryan Beisner
Sean Feole
Seyeong Kim
Tamas Erdei
Tytus Kurek
Xav Paice
viswesuwara nathan

__
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

[openstack-dev] [charms] [tripleo] [puppet] [fuel] [kolla] [openstack-ansible] [cloudcafe] [magnum] [mogan] [sahara] [shovel] [watcher] [helm] [rally] Heads up: ironic classic drivers deprecation

[Dmitry Tantsur]

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

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

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

[David Ames]

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-dev] [charms] queens support release date

[James Page]

Hi All

We're not quite fully baked with Queens testing for the OpenStack charms
for this week so we're going to push back a week to the 8th March to allow
pre-commit functional testing updates to land.

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-dev] [charms] [ptg] charms dinner

[James Page]

Hi Team

As I'm only managing to get to the PTG for Mon/Tues lets schedule a dinner
for Monday night; I'll sort out a venue - lemme know direct this week if
you'll be coming along!

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]

[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 custom config option anyway. Each charm

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

[openstack-dev] [charms]

[Dmitrii Shcherbakov]

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.


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. 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?), "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.


This brings me to the question of how is it different from 
state-specific config values with a complex structure. 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!

__
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

[openstack-dev] [charms]

[Liam Young]

Hi,

I was recently looking at how to support custom configuration that relies on
post deployment setup. Specifically about how to support designate optional
configuration for the sink service. The configuration lives on the application
units but needs the domain id of the designate domain that the records should
be created in. This domain is created post-deployment and, obviously, the uuid
of the domain will change on each deployment.

I would like to propose doing this through post deployment actions and I think
the general approach will be useful across multiple charms. The charm can have
pre-defined custom config which can be enabled through an action. The action
parameters also provide an additional context for rendering the template which
includes data from the post deployment setup. This approach does not allow
arbitrary config to be injected, instead it allows predefined config to
activated via actions.

To illustrate the approach I'll stick with the designate example:

1) Cloud deployed and administrator sets up new domain
2) Administrator runs a new add-sink-config action and passes the domain-id
   and sink config file name.
3) The lead unit updates a map in the leader db which lists additional config
   files and corresponding context derived from the action options. Each
   set of config stores its options in its own namespace.
4) The lead unit then triggers config to be rerendered locally.
5) Non-lead units are triggered by the leader-settings-changed hook and also
   rerender their configs.

Here is a prototype for the designate charm: https://goo.gl/CJj2Rh

Any thoughts, objections, you-haven;t-thought-of-this' gratefully recieved
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]

[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

[openstack-dev] [charms]

[Liam Young]

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

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

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

[Ryan Beisner]

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

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

[openstack-dev] [charms] Propose Dmitrii Shcherbakov for OpenStack Charmers team.

[Alex Kavanagh]

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-dev] [charms] PTL for Rocky

[James Page]

Hi All



It will (probably) come as no surprise that I'd like to announce

my candidacy for PTL of OpenStack Charms [0]!


We've made some good progress in the last cycle with some general

housekeeping across the charms set, including removal of untested

and generally unused database and messaging configurations. We've

also finally managed to complete the deprecation of the Ceph charm

with a well documented migration path to the newer Charms for

operators to use.


This is all great but we still have more housekeeping todo!


Specifically we need to complete migration to using Python 3

as the default execution environment for charms (this was started

during Queens, but is not yet complete).


I'd like to see more depth in the networking configurations and

choices the charms present (we already have specs raised for

Dynamic Routing and Network Segment support) and I think these

will appeal to operators with more complex networking requirements

for OpenStack.


I think we also need to finish the work we started last year on

improving the Telemetry storage; Aodh, Gnocchi and Ceilometer are

all looking in pretty good shape now, but we need to add Panko to

the fold!


I still think we have a bit of an issue with level of entry to

writing a charm - it turns out that writing a charm is dead easy;

writing unit tests is also pretty easy and familiar with anyone

who writes any amount of Python; enabling full functional testing

of a charm is much harder.  Our historic tool choice (amulet) does

not help in this area and I look forward to working with the dev

team this cycle to move us onto something that's a) more directly

maintainable and b) easier to engage with as we bring new charms

and features onboard.


I look forward to helping steer the project during the Rocky cycle!


Cheers


James

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

[openstack-dev] [charms] Dublin PTG devroom

[James Page]

Hi Team

The Dublin PTG is not so far away now, so lets start on the agenda for our
Devroom:

  https://etherpad.openstack.org/p/DUB-charms-devroom

We had a fairly formal agenda of design related topics in Denver for the
first day, and spent most of the second day mini-sprinting on various
features/bugs/issues/niggles etc...

I think it worked well - what do others think?

Please add topics to the pad.

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-dev] [charms][nova-compute] Services not running that should be: nova-api-metadata

[James Beedy]

Trying to bring up an Openstack, I keep hitting this issue where
nova-compute is giving a status "Services not running that should be:
nova-api-metadata" - are others hitting this?

juju status | https://paste.ubuntu.com/26480769/

Its possible something has changed in my infrastructure, but I feel like
when I deployed this same config last week I had a solid deploy with no
errors.

I know there are too many components and configuration to start
troubleshooting with this little detail, just thought I would check in
before diving in head first.

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

[openstack-dev] [charms] 17.11 OpenStack Charms release

[David Ames]

Announcing the 17.11 release of the OpenStack Charms.

In addition to 125 bug fixes across the charms, the release includes
official support for Gnocchi and support for QoS. Several charms have
made the migration to python3 only run-time.

For full details of the release, please refer to the release notes:

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

Thanks go to the following contributors for this release:

 Alex Kavanagh
 Andrew McLeod
 Aydin Doyak
 Billy Olsen
 Chris MacNaughton
 Corey Bryant
 David Ames
 Dmitrii Shcherbakov
 Edward Hope-Morley
 Evgeny Kremenetsky
 Felipe Reyes
 Frode Nordahl
 Fulvio Galeazzi
 Haw Loeung
 Hua Zhang
 James Page
 Jorge Niedbalski
 Liam Young
 Marian Gasparovic
 Michael Skalka
 Nobuto Murata
 Pete Vander Giessen
 Ryan Beisner
 Seyeong Kim
 Shane Peters
 Tytus Kurek
 Xav Paice
 viswesuwara nathan
 zhangyangyang

__
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

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

[Dmitrii Shcherbakov]

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}]

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

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

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

[Liam Young]

The Designate sink service relies on sink file(s) that contain the domain
id(s) of the domains that automatically generated records should be added
to.
At the moment the designate charm creates a server and domains during charm
installation if the neutron-domain and/or nova-domain config options have
been
set. It then renders the sink files accordingly. This is done via the
designate cli and obviously relies on the keystone API and designate API
services being up and avaliable. This is unsuprisngly proving to be
unreliable
and racey, particularly during HA deployments.

The heat charm has a similiar issue in that it relies on a domain to have
been
created before heat can be used. But rather than try and create the domain
during charm installation the heat charm exposes an action which should be
run post-installation to create the domain.

I think that the designate charm should be updated to work in a similar way
to
the heat charm and that the server and domain creation and sink file
rendering
should be done via a post-deployment action rather than during deployment
time. There is a complication to this approach. All the designate API units
will need to render sink configurations containing the domain id(s) once the
creation action has run. I can think of two similar ways to achieve this:

1) Expose a server and domain creation action that must be run on the
leader.
   During the action the leader then sets the domain ids via the leader db.
   The non-leaders can then respond to leader-settings-changed and render
   their sink file(s). Storing the sink config in the leader-db also has the
   advantage that if the designate service is scaled out at a later date
then
   the new unit will still have access to the sink configuration and can
   render the sink files.

2) A very similar approach would be to push the creation of servers and
   domains back to the administrator to perform and expose a generic action
   for creating sink files which accepts the domain id as one of its
   arguments. Again this would need to be run on the leader and propogated
via
   leader-settings

I'm inclined to do option 2 does anyone have any objections or suggestions
for an
alternative approach ?

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-dev] [charms] nominating admcleod for core openstack charmer

[Ryan Beisner]

Hi OpenStack Charmers,

I'd like to nominate Andrew McLeod (admcleod) to be promoted as a core
reviewer for the OpenStack Charms project.  I trust Andrew's judgement in
code review and collaboration with other core reviewers.

Please take this to the next IRC meeting for discussion and determination.
Thank you.

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

[openstack-dev] [charms] Sydney forum user feedback session (Tues@0950)

[James Page]

Hi All

Apologies for the late creation of this pad:

  https://etherpad.openstack.org/p/SYD-forum-charms-ops-feedback

if your planning on attending this session please add your name and any
topics for discussion!

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-dev] [charms] evolving the ha interface type

[James Page]

Hi Team

Whilst working on migrating to using Python 3 as the default charm
execution environment, I've hit upon a snag with presentation of data from
principle charms to the hacluster subordinate charm.

Specifically the data presented on the relation is simple str
representation of python dicts which are then parsed used ast in the
hacluster charm.

This has worked OK under Python 2, but due to the non-deterministic
iteration of dict keys, the data presented from the principle charm can
change over time when the ha_joined function is re-exec'ed (such as during
a config-changed hook execution).

I'd like to propose that we move to using json to serialise this data so
that we can used ordered dicts to present data in a consistent fashion.

We need to evolve the interface to deal with this - we could potentially
take two approaches:

a) Attempt to parse presented data using json, fallback to ast for
backwards compat

b) Present a version flag from the hacluster charm, allowing the principle
to switch to the new approach when the required version of the hacluster
charm is presented to it.  We'd still do a) but it would avoid hook
failures in the event that a user does not upgrade hacluster application
instances prior to upgrading principle charms.

Anyway - that's my current thoughts. I have a prototype for a) which works
nicely, but I think adding b) will provide a better UX (thanks gnuoy for
pointing to this solution).

Thoughts?

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-dev] [charms] bug day this Thursday

[James Page]

Hi All

Reminder that as this Thursday is the first Thursday of the month its
officially a bug triage/fix day!

Our new (23) queue is looking better than ever [0] so it would be great to
get that down to near 0.

After that focus should switch to High (62) and then Medium (174) bugs
already Triaged.

Please coordinate any activity in #openstack-charms so we don't all end up
triaging the same stuff; if you're working on a bug please make sure to
assign it to yourself and mark is as 'In Progress'.

Cheers

James

[0]
https://bugs.launchpad.net/openstack-charms/+bugs?search=Search&field.status=New&orderby=-importance
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [charms] PTG summary

[James Page]

Hi All

Here’s a summary of the charm related discussion from PTG last week.

# Cross Project Discussions

## Skip Level Upgrades

This topic was discussed at the start of the week, in the context of
supporting upgrades across multiple OpenStack releases for operators.  What
was immediately evident was this was really a discussion around
‘fast-forward’ upgrades, rather than actually skipping any specific
OpenStack series as part of a cloud upgrade.  Deployments would still need
to step through each OpenStack release series in turn, so the discussion
centred around how to make this much easier for operators and deployment
tools to consume than it has been to-date.

There was general agreement on the principles that all steps required to
update a service between series should be supported whilst the service is
offline – i.e. all database migrations can be completed without the
services actually running;  This would allow multiple upgrade steps to be
completed without having to start services up on interim steps. Note that a
lot of projects all ready support this approach, but its never been agreed
as a general policy as part of the ‘supports-upgrade‘ tag which was one of
the actions resulting from this discussion.

In the context of the OpenStack Charms, we already follow something along
these lines for minimising the amount of service disruption in the control
plane during OpenStack upgrades; with implementation of this approach
across all projects, we can avoid having to start up services on each
series step as we do today, further optimising the upgrade process
delivered by the charms for services that don’t support rolling upgrades.

## Policy in Code

Most services in OpenStack rely on a policy.{json,yaml} file to define the
policy for role based access into API endpoints – for example, what
operations require admin level permissions for the cloud. Moving all policy
default definitions to code rather than in a configuration file is a goal
for the Queens development cycle.

This approach will make adapting policies as part of an OpenStack Charm
based deployment much easier, as we only have to manage the delta on top of
the defaults, rather than having to manage the entire policy file for each
OpenStack release.  Notably Nova and Keystone have already moved to this
approach during previous development cycles.

## Deployment (SIG)

During the first two days, some cross deployment tool discussions where
held for a variety of topics; of specific interest for the OpenStack Charms
was the discussion around health/status middleware for projects so that the
general health of a service can be assessed via its API – this would cover
in-depth checks such as access to database and messaging resources, as well
as access to other services that the checked service might depend on – for
example, can Nova access Keystone’s API for authentication of tokens etc.
There was general agreement that this was a good idea, and it will be
proposed as a community goal for the OpenStack project.

# OpenStack Charms Devroom

## Keystone: v3 API as default

The OpenStack Charms have optionally supported Keystone v3 for some time;
The Keystone v2 API is officially deprecated, so we had discussion around
approach for switching the default API deployed by the charms going
forwards; in summary

New deployments should default to the v3 API and associated policy
definitions
Existing deployments that get upgraded to newer charm releases should not
switch automatically to v3, limiting the impact of services built around v2
based deployments already in production.
The charms already support switching from v2 to v3, so v2 deployments can
upgrade as and when they are ready todo so.
At some point in time, we’ll have to automatically switch v2 deployments to
v3 on OpenStack series upgrade, but that does not have to happen yet.

## Keystone: Fernet Token support

The charms currently only support UUID based tokens (since PKI was dropped
from Keystone); The preferred format is now Fernet so we should implement
this in the charms – we should be able to leverage the existing PKI key
management code to an extent to support Fernet tokens.

## Stable Branch Life-cycles

Currently the OpenStack Charms team actively maintains two branches – the
current development focus in the master branch, and the most recent stable
branch – which right now is stable/17.08.  At the point of the next
release, the stable/17.08 branch is no longer maintained, being superseded
by the new stable/XX.XX branch.  This is reflected in the promulgated
charms in the Juju charm store as well.  Older versions of charms remain
consumable (albeit there appears to be some trimming of older revisions
which needs investigating). If a bug is discovered in a charm version from
a inactive stable branch, the only course of action is to upgrade the the
latest stable version for fixes, which may also include new features and
behavioural changes.

There are some technical challenges with regard 

[openstack-dev] [charms] 17.08 OpenStack Charms release

[David Ames]

Announcing the 17.08 release of the OpenStack Charms.

In addition to 204 bug fixes across the charms and support for the
Pike OpenStack release, there is a new charm for Gnocchi, support
for neutron internal DNS, percona cluster tuning and much more.

For full details of the release, please refer to the release notes:

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

Thanks go to the following contributors for this release:

Nobuto Murata
Mario Splivalo
Ante Karamatić
zhangbailin
Shane Peters
Billy Olsen
Tytus Kurek
Frode Nordahl
Felipe Reyes
David Ames
Jorge Niedbalski
Daniel Axtens
Edward Hope-Morley
Chris MacNaughton
Xav Paice
James Page
Jason Hobbs
Alex Kavanagh
Corey Bryant
Ryan Beisner
Graham Burgess
Andrew McLeod
Aymen  Frikha
Hua Zhang
Alvaro Uría
Peter Sabaini

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

[openstack-dev] [charms] IRC meeting 11th September cancelled

[James Page]

Hi Team

I'm cancelling next Mondays IRC; we're (mostly) meeting for the PTG anyway
and can re-sync the following Monday.

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-dev] [charms][ceph-radosgw] radosgw-admin?

[James Beedy]

Hello,

Just wondering if the ceph-radosgw charm provides a method of
configuring/accessing the radosgw-admin utility, or if there is a suggested
way to get radosgw-admin working in conjunction with ceph/ceph-radosgw
charms?

In the ceph-radosgw charm, I see the radosgw-admin bin ends up in
/usr/bin/radosgw-admin, but I'm guessing there would need to be some
stanzas in the ceph.conf pertaining to radosgw.admin, and a keyring file
specifically for the radosgw-admin client (and probably more, I'm not
really to sure) to get the radosgw-admin working from locally from the
ceph-radosgw charm (or is there a better way?).

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

[openstack-dev] [charms] Openstack charm with OVN as SDN

[Aakash Kt]

Hi all,
   I am looking to develop an openstack bundle which uses OVN as the SDN. I
have been reading : https://docs.openstack.org/charm-guide/latest/
I have also read : https://docs.openstack.org/networking-ovn/latest/install/
index.html

As far as I understand, this will require me to replace the
"neutron-openvswitch" charm in the openstack base bundle. However, I am not
able to exactly understand what all I will have to rewrite / replace to
make this work.
I know I need to make neutron work only as an API instead of the full blown
SDN. Also, in the above doc, its mentioned that we have to run some setup
on "controller nodes". How does the term "controller node" map to the
openstack base charm?
Some guidelines as to what to read about and help in understanding the
already existing openstack charm would be great.

Thank you for helping out, and sorry if these doubts seem trivial.

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

[openstack-dev] [charms] PTL cover for the next two weeks

[James Page]

Hi All

As I'm off in the backwaters of Scotland with zero chance of any internet
access for the next two weeks, I'm delegating my PTL responsibilities to
the capable Ryan Beisner until my return.

I'll be back just after the charms final freeze in the leadup to the charms
release at the start of September.

Have fun

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

[James Page]

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-dev] [charms] ptl for queens

[James Page]

Hi All

I would like to announce my candidacy for PTL of the OpenStack Charms
project
for the Queens development cycle.

We've made some good progress during the Pike cycle in terms of improving
documentation, with a new deployment guide in the works which should make
things
much easier for new users of the OpenStack Charms going forwards; There is
still
work todo here and that's something I want to make sure we focus on during
the
next development cycle.

We also have a number of cleanups that need to be completed; ZeroMQ and
PostgreSQL
support in the charms are obsolete and not covered by any testing so should
be
dropped during Queens.  We also need to make the jump to Python 3 by default
across all charms.

I look forward to steering the helm for another cycle!

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

[openstack-dev] [charms] Bug Day Thursday 4th May

[James Page]

Hi Team

Just a quick reminder that this Thursday is charm bug day!

Please focus on triage and resolution of bugs across the openstack charms -
the new bugs URL is in the topic in #openstack-charms on Freenode IRC.

Happy bug hunting!

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-dev] [charms] Onboarding session at next weeks summit

[James Page]

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-dev] [charms] Charms IRC meetings

[Alex Kavanagh]

Hi

This is just a quick reminder that there are two meetings at different
times for folks interested in discussing the OpenStack charms.  This is so
we can get more geographic coverage:

 - ODD weeks (next on Monday 27th March at 10:00 UTC)
 - EVEN weeks (next on Monday 3rd April at 17:00 UTC)

The agenda and previous minutes can be found at:
https://etherpad.openstack.org/p/openstack-charms-weekly-meeting

Full details of the meetings is detailed at:
https://docs.openstack.org/developer/charm-guide/meetings.html

Look forward to meeting you in the future!
Kind regards
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-dev] [charms] bug day this thursday (2nd March)

[James Page]

Hi All

Just a reminder that we'll be running our regular bug day on the 2nd March
(this coming thursday).

Focus, as always, is to touch new bugs and work through in priority order
for any fixes!

Please co-ordinate any activity in the #openstack-charms channel!

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-dev] [charms] 17.02 OpenStack Charms release

[James Page]

Hi All

I'm pleased to announce the 17.02 release of the OpenStack Charms.

In addition to 120 bug fixes across the charms and support for the Ocata
OpenStack release, there are new charms for Ceph FS and Manila and to
support integration of Keystone with LDAP/Active Directory leveraging
domain specific drivers with Keystone v3 domains.

For full details of the release, please refer to the release notes:

  https://docs.openstack.org/developer/charm-guide/1702.html

It's also worth noting that bug reporting has now been moved out of the
Juju Charms distribution on Launchpad into individual projects for each
charm under the OpenStack Charms project group:

  https://launchpad.net/openstack-charms

All existing bugs have been migrated to the new project locations.

Thanks go to the following contributors for this release:

  Seyeong Kim
  Mario Splivalo
  Ante Karamatić
  Shane Peters
  JuanJo Ciarlante
  Billy Olsen
  Paolo de Rosa
  Frode Nordahl
  Felipe Reyes
  David Ames
  Liam Young
  Edward Hope-Morley
  Chris MacNaughton
  Chris Holcombe
  Alex Kavanagh
  Brad Marshall
  Dmitrii Shcherbakov
  Ryan Beisner
  Viswesuwara Nathan
  Pascal Mazon
  Hua Zhang
  Chris Glass

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-dev] [charms] no irc meeting today

[James Page]

Hi Team

As most people are at the PTG today, we'll skip todays team IRC meeting.

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-dev] [charms]

[Ryan Beisner]

Hello Charmers,

Today marks the start of regular feature freeze of OpenStack Charms, for
the planned OpenStack Charms stable release on Feb 23.

During this time, we focus on any critical bug fixes, any items with a
feature freeze exception, additional test coverage, and an increase in edge
case scenario testing.

More info:
  http://docs.openstack.org/developer/charm-guide/
  Freenode irc:  #openstack-charms

Cheers,

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

[openstack-dev] [charms] PTG topics

[James Page]

Hi Team

We're only a few weeks off the PTG, so I think its about time we started
the ball rolling on planning our time out over the Monday/Tuesday.

I've created an etherpad so we can brainstorm a schedule for the two days:

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

If you're attending the PTG, please put you irc nic down at the top of the
pad, so we can track who's coming along and which topics each person is
interested in.

I'm keen that we use the time for discussion and planning of objectives for
the next 6 months, but also to ensure that if people need to spend time
working on a specific challenge, we can accommodate that as well.

See you all in Atlanta!

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-dev] [charms] minutes from todays IRC meeting

[James Page]

Hi All

Here are the links from todays Charms IRC meeting:

 Agenda:
https://etherpad.openstack.org/p/openstack-charms-weekly-meeting-20170129
 Minutes:
http://eavesdrop.openstack.org/meetings/charms/2017/charms.2017-01-30-10.03.html
 Minutes (text):
http://eavesdrop.openstack.org/meetings/charms/2017/charms.2017-01-30-10.03.txt
 Log:
http://eavesdrop.openstack.org/meetings/charms/2017/charms.2017-01-30-10.03.log.html

Our next team meeting is at 1700 UTC on the 6th February in
#openstack-meeting-4

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

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

[James Beedy]

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

[openstack-dev] [charms] Thursday 2nd February - Bug Day!

[James Page]

Hi Team

Just a quick reminder that next Thursday marks our second bug day for the
year.

Please focus on triage and resolution of bugs across the openstack charms -
the new bugs URL is in the topic in #openstack-charms on Freenode IRC.

Happy bug hunting!

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-dev] [charms][ptl] PTL candidacy

[James Page]

Hi All

I would like to announce my candidacy for PTL of the OpenStack Charms
project.

Over the Ocata cycle, we've been incubating the community of developers
around
the Charms, with new charms for Murano, Trove, Mistral and CloudKitty all
due
to be included in the release in February.

We've also started to engage successfully with the vendor ecosystem around
OpenStack, with PLUMgrid, Calico and 6wind all working towards aligment and
inclusion in the OpenStack Charm release.

This is all helping to diversify the development community around the
Charms.

I'll continue to work to support the wider ecosystem adoption of the Charms
as a great way to deploy and manage OpenStack.

We've made some in-roads into improving the developer experience for charm
authors, but I feel there is still progress to be made so I will continue to
focus on this aspect of the project during the Pike cycle.

I look forward to working with the team and steering the project for another
cycle!

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

[openstack-dev] [charms] monitoring interface

[Brad Marshall]

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-dev] [charms] bug day this thursday

[James Page]

Hi All

Just a quick reminder that this Thursday (5th January) is our first bug day
for charms of the year.

Objective is to blast through the un-triaged bug backlog assigning some
initial priorities and then fixup as many bugs as possible!

Please co-ordinate via #openstack-charms so we don't all tread on each
others toes :-)

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

[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

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

[James Page]

Hi All

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?

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-dev] [charms] bug squash thursdays

[James Page]

Hi Team

Our last (and only) bug day was quite popular/successful, so lets try and
have one focus day on bugs a month.

So from January, the first Thursday of the month will officially be 'Charm
Bug Squash Day'.

The objective of the day is to triage any untouched bugs, sift through
triaged bugs in priority order and fix any long standing niggles and issues
in the charm set!

See you all on #openstack-charms on the 5th January for some bug triage and
fixing fun!

Cheers

James

P.S. please also continue to look at bugs on days other than the first
Thursday of the month!
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [charms] irc meetings for next few weeks

[James Page]

Hi All

As we're approaching a period where quite a few people will be having time
off, I'm cancelling the IRC meetings on Mondays (1000 and 1700 on alternate
weeks) until the 9th January at 1700 UTC - at which point we'll resume
normal service, with the next meeting after that at 1000 UTC on the 16th.

Have a nice break if you're taking some time out!

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-dev] [charms] Default SSL Service Endpoints

[James Beedy]

Running into a few bumps deploying keystone charm with SSL [1].

I'm wondering how others feel about having the Openstack charms account for
a heightened level of security by opting to use SSL endpoints over plain
http endpoints by default?

Something tells me having services default to using SSL endpoints, and have
the option to disable SSL, would be a better model then throwing up a
non-SSL Openstack as the default offering (and making this SSL breaks the
nice openstack story we have).

I'm thinking default SSL endpoints would help shed some light on the whole
SSL provisioning (there is an easyrsa charm now), and testing too, making
SSL Openstack something that is more common then not.

Thoughts?


[1] https://bugs.launchpad.net/charms/+source/keystone/+bug/1647193
__
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

[openstack-dev] [charms] Barbican + Identity Standalone - AWS

[James Beedy]

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

[openstack-dev] [charms] regular bug day

[James Page]

Hi Folks

We have an organised bug day prior to the OpenStack Summit in Barcelona; I
felt that this focused everyone onto collaborating on bugs in a good way,
and gave us a great checkpoint on what the key issues are that people are
hitting and reporting back on the charms.

I'd like to proposed that we have a regular month charm bug day on the
first Thursday of every month - starting this week on the 1st of December!

I'll (normally) send out a reminder a week in advance to remind everyone!

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

[openstack-dev] [charms] layer/source charm project-config changes

[Ryan Beisner]

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