[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

[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

[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

Re: [openstack-dev] [nova-lxd]Feature support matrix of nova-lxd

[James Page]

Hi Rikimaru

On Fri, 31 Aug 2018 at 11:28 Rikimaru Honjo 
wrote:

> Hello,
>
> I'm planning to write a feature support matrix[1] of nova-lxd and
> add it to nova-lxd repository.
> A similar document exists as todo.txt[2], but this is old.
>
> Can I write it?
>

Yes please!


> If someone is writing the same document now, I'll stop writing.
>

They are not - please go ahead - this would be a valuable contribution for
users evaluating this driver.

Regards

Jjames
__
OpenStack Development Mailing 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] [upgrade][sig] Upgrade SIG/Stein PTG etherpad

[James Page]

Hi Folks

We have a half day planned on Monday afternoon in Denver for the customary
discussion around OpenStack upgrades.

I've started a pad here:
https://etherpad.openstack.org/p/upgrade-sig-ptg-stein

Please feel free to add ideas and indicate if you will be participating in
the 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] 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] [sig][upgrades][ansible][charms][tripleo][kolla][airship] reboot or poweroff?

[James Page]

Hi All

tl;dr we (the original founders) have not managed to invest the time to get
the Upgrades SIG booted - time to hit reboot or time to poweroff?

Since Vancouver, two of the original SIG chairs have stepped down leaving
me in the hot seat with minimal participation from either deployment
projects or operators in the IRC meetings.  In addition I've only been able
to make every 3rd IRC meeting, so they have generally not being happening.

I think the current timing is not good for a lot of folk so finding a
better slot is probably a must-have if the SIG is going to continue - and
maybe moving to a monthly or bi-weekly schedule rather than the weekly slot
we have now.

In addition I need some willing folk to help with leadership in the SIG.
If you have an interest and would like to help please let me know!

I'd also like to better engage with all deployment projects - upgrades is
something that deployment tools should be looking to encapsulate as
features, so it would be good to get deployment projects engaged in the SIG
with nominated representatives.

Based on the attendance in upgrades sessions in Vancouver and
developer/operator appetite to discuss all things upgrade at said sessions
I'm assuming that there is still interest in having a SIG for Upgrades but
I may be wrong!

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] [sig][upgrade] Todays IRC meeting

[James Page]

Hi All

Unfortunately I can't make todays IRC meeting at 1600 UTC.

Should be back for next week, but I think we need todo some rescheduling to
fit better with other ops and dev meetings.

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] [sig][upgrade] Upgrade SIG IRC meeting 1600 UTC Tuesday

[James Page]

Hi All

Just a quick reminder that the Upgrade SIG IRC meeting will be held at 1600
UTC tomorrow (Tuesday) in #openstack-meeting-4.

If you're interested in helping improve the OpenStack upgrade experience be
sure to attend!

See [0] for previous meeting minutes and our standing agenda.

Regards

James

[0] https://etherpad.openstack.org/p/upgrades-sig-meeting
__
OpenStack Development Mailing 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] [sig] [upgrades] inaugural meeting minutes & vancouver forum

[James Page]

Hi All

Lujin, Lee and myself held the inaugural IRC meeting for the Upgrades SIG
this week (see [0]). Suffice to say that, due to other time pressures,
setup of the SIG has taken a lot longer than desired, but hopefully now we
have the ball rolling we can keep up a bit of momentum.

The Upgrades SIG intended to meet weekly, alternating between slots that
work for (hopefully) all time zones:

   http://eavesdrop.openstack.org/#Upgrades_SIG

That said, we'll skip next weeks meeting due to the OpenStack Summit and
Forum in Vancouver, where we have a BoF on the schedule (see [1]) instead.

If you're interested in OpenStack Upgrades the BoF and Erik's sessions on
Fast Forward Upgrades (see [2]) should be on your schedule for next week!

Cheers

James


[0]
http://eavesdrop.openstack.org/meetings/upgrade_sig/2018/upgrade_sig.2018-05-15-09.06.html
[1]
https://www.openstack.org/summit/vancouver-2018/summit-schedule/events/21855/upgrade-sig-bof
[2]
https://www.openstack.org/summit/vancouver-2018/summit-schedule/global-search?t=upgrades
__
OpenStack Development Mailing 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] [sig] [upgrades] inaugural meeting minutes & vancouver forum

[James Page]

Hi All

Lujin, Lee and myself held the inaugural IRC meeting for the Upgrades SIG
this week (see [0]). Suffice to say that, due to other time pressures,
setup of the SIG has taken a lot longer than desired, but hopefully now we
have the ball rolling we can keep up a bit of momentum.

The Upgrades SIG intended to meet weekly, alternating between slots that
work for (hopefully) all time zones:

   http://eavesdrop.openstack.org/#Upgrades_SIG

That said, we'll skip next weeks meeting due to the OpenStack Summit and
Forum in Vancouver, where we have a BoF on the schedule (see [1]) instead.

If you're interested in OpenStack Upgrades the BoF and Erik's sessions on
Fast Forward Upgrades (see [2]) should be on your schedule for next week!

Cheers

James


[0]
http://eavesdrop.openstack.org/meetings/upgrade_sig/2018/upgrade_sig.2018-05-15-09.06.html
[1]
https://www.openstack.org/summit/vancouver-2018/summit-schedule/events/21855/upgrade-sig-bof
[2]
https://www.openstack.org/summit/vancouver-2018/summit-schedule/global-search?t=upgrades
__
OpenStack Development Mailing 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] [ptg][sig][upgrades] Upgrade SIG

[James Page]

Hi All

I finally got round to writing up my summary of the Upgrades session at the
PTG in Dublin (see [0]).

One outcome of that session was to form a new SIG centered on Upgrading
OpenStack - I'm pleased to announce that the SIG has been formally accepted!

The objective of the Upgrade SIG is to improve the overall upgrade process
for OpenStack Clouds, covering both offline ‘fast-forward’ upgrades and
online ‘rolling’ upgrades, by providing a forum for cross-project
collaboration between operators and developers to document and codify best
practice for upgrading OpenStack.

If you are interested in participating in the SIG please add your details
to the wiki page under 'Interested Parties':

  https://wiki.openstack.org/wiki/Upgrade_SIG

I'll be working with the other SIG leads to setup regular IRC meetings in
the next week or so - we expect to alternate between slots that are
compatible with all time zones.

Regards

James

[0]
https://javacruft.wordpress.com/2018/03/16/winning-with-openstack-upgrades/
[1] https://governance.openstack.org/sigs/
__
OpenStack Development Mailing 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] [openstack][charms] Openstack + OVN

[James Page]

Hi Aakash

On Sun, 11 Mar 2018 at 19:01 Aakash Kt  wrote:

> Hi,
>
> I had previously put in a mail about the development for openstack-ovn
> charm. Sorry it took me this long to get back, was involved in other
> projects.
>
> I have submitted a charm spec for the above charm.
> Here is the review link : https://review.openstack.org/#/c/551800/
>
> Please look in to it and we can further discuss how to proceed.
>

I'll feedback directly on the review.

Thanks!

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

[James Page]

+1

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

> Hi,
>
> I would like to propose that we do not support the notifications
> method for automatically creating DNS records in Queens+. This method
> for achieving Neutron integration has been superseded both upstream
> and in the charms. By removing support for it in Queens we prevent the
> charm from attempting to make designate v1 api calls for Queens+ which
> is a positive thing given it will have been removed (
>
> https://docs.openstack.org/releasenotes/designate/queens.html#critical-issues
> ).
>
> Thanks
> Liam
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [charms]

[James Page]

+1

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

> Hi,
>
> I would like to propose that we do not support the notifications
> method for automatically creating DNS records in Queens+. This method
> for achieving Neutron integration has been superseded both upstream
> and in the charms. By removing support for it in Queens we prevent the
> charm from attempting to make designate v1 api calls for Queens+ which
> is a positive thing given it will have been removed (
>
> https://docs.openstack.org/releasenotes/designate/queens.html#critical-issues
> ).
>
> Thanks
> Liam
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [charms] Propose 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] [ptg] Track around release cycle, consumption models and stable branches

[James Page]

Hi Thierry

On Wed, 7 Feb 2018 at 11:42 Thierry Carrez  wrote:

> Hi everyone,
>
> I was wondering if anyone would be interested in brainstorming the
> question of how to better align our release cycle and stable branch
> maintenance with the OpenStack downstream consumption models. That
> includes discussing the place of the distributions, the need for LTS,
> and where does the open source upstream project stop.
>
> I have hesitated to propose it earlier, as it sounds like a topic that
> should be discussed with the wider community at the Forum. And it will,
> but it feels like this needs a deeper pre-discussion in a productive
> setting, and tonyb and eumel8 have been proposing that topic on the
> missing topics etherpad[1], so we might as well take some time at the
> PTG to cover that.
>
> Would anyone be interested in such a discussion ? It would be scheduled
> on the Tuesday. How much time would we need ? I was thinking we could
> use only Tuesday afternoon.


I would be interested in participating in this (and I'll still be around
Tuesday PM).

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

Re: [openstack-dev] [ptg] Dublin PTG proposed track schedule

[James Page]

Hi Thierry

On Thu, 18 Jan 2018 at 10:20 Thierry Carrez  wrote:

> Hi everyone,
>
> Here is the proposed pre-allocated track schedule for the Dublin PTG:
>
>
> https://docs.google.com/spreadsheets/d/e/2PACX-1vRmqAAQZA1rIzlNJpVp-X60-z6jMn_95BKWtf0csGT9LkDharY-mppI25KjiuRasmK413MxXcoSU7ki/pubhtml?gid=1374855307=true
>
> The proposed allocation takes into account the estimated group size and
> number of days that was communicated to Kendall and I by the team PTL.
> We'd like to publish this schedule on the event website ASAP, so please
> check that it still matches your needs (number of days, room size vs.
> expected attendance) and does not create too many conflicts. There are
> lots of constraints, so we can't promise we'll accommodate your remarks,
> but we'll do our best.
>

OpenStack Charms team preference would be to have our dedicated room
Wed/Thurs; in Denver we participated in some of the cross projects
discussions such as fast forward upgrades, and I'd not want to have to
fragment our time as a team to accommodate that if possible please!

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] [networking-bagpipe] [networking-bgpvpn] missing tarballs for queens milestone 1

[James Page]

Hi

Corey and I have been working through the first Queens milestones for
Ubuntu (and the UCA) - both networking-bagpipe and networking-bgpvpn don't
have published tarballs on tarballs.openstack.org.

Would it be possible to get those up? or we can cut our own from the git
repo for this milestone if that's not possible.

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

Re: [openstack-dev] [packaging][all] Sample Config Files in setup.cfg

[James Page]

On Tue, 3 Oct 2017 at 18:15 Doug Hellmann  wrote:

> Excerpts from Jesse Pretorius's message of 2017-10-03 15:57:17 +:
> > On 10/3/17, 3:01 PM, "Doug Hellmann"  wrote:
> >
> > >> Given that this topic has gone through several cycles of discussion
> and has never gone anywhere, does it perhaps merit definition as a project
> interface so that we can define the problem this is trying to solve and set
> a standard formally once and for all?
> >
> > >Maybe a couple of the various packaging projects can agree and just
> > >set a de facto rule (and document it). That worked out OK for us
> > >with the doc reorganization when we updated the docs.o.o site
> > >templates.
> >
> > I’m happy to facilitate that. Is there some sort of place where such
> standards are recorded? Ie Where do I submit a review to and is there an
> example to reference for the sort of information that should be in it?
> >
>
> The docs team put that info in the spec for the migration. Do we
> have a packaging SIG yet? That seems like an ideal body to own a
> standard like this long term. Short term, just getting some agreement
> on the mailing list would be a good start.


Bah - missed the start of this thread but here's my tuppence

1) +1 for a consistent approach across projects - /usr/share/
sounds like a sensible location - avoiding any complexity with managing
changes made by users in /etc/ for deploy from source use-cases,
and allowing packagers to know where to expect reference/sample config
files to appear during the package build-out/install process.

2) Looking at the Ubuntu packaging for OpenStack projects, we have quite a
few places where oslo-config-generator or oslo-policy-generator is used to
generate sample configuration files as part of the package build; I might
have missed it in my read through of this thread but it would be awesome if
those could be integrated as part of this process as well as the
originating project would then be able to provide some level for assurance
to the content of generated files in downstream distributions.

I'd also be +1 on a packaging SIG; I don't think it will ever be a high
overhead SIG but it sounds like there are common challenges for deployment
projects and distributors which would benefit from shared focus.

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

Re: [openstack-dev] [openstack] [charms] Openstack with OVN

[James Page]

Hi Aakash

On Tue, 29 Aug 2017 at 05:09 Aakash Kt  wrote:

> Hello all,
> Resending this mail since I think there might have been some error
> sending it the last time.
>
>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
>

Awesome; we chatted about this on IRC a few times but put off any concrete
work until OVN 2.8.0 is released (soon).

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 think the new charm work is actually three charms (or maybe two) -
neutron-ovn (replacing neutron-openvswitch alongside nova-compute
deployments), neutron-api-ovn (providing the API only integration of the
Neutron API to OVN), and probably an ovn charm for deployment of OVN
itself, with relations  <->  <->  for
propagation of configuration in deployments.  The ODL charm set is similar
is high level design (neutron-api-odl, odl-controller, openvswitch-odl).


> Specifically, 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 charm?
>

Controller nodes are one option for the charms, however components of the
controller nodes are deployed inside LXD containers to provide separation
between services.  For example, you can dedicated three physical servers
and then deploy the nova-cloud-controller, neutron-api, glance, keystone,
cinder, ceilometer, heat etc.. charms in LXD containers onto those physical
machines.  So in the case of OVN, we'd look to deploy the ovn charm on
these same physical servers.

Hope that helps explain things a bit; if you want to drop into
#openstack-charms to ask more questions please do, or you can join one of
our weekly meetings and we can discuss further.  We'd normally start a
piece of work like this with a spec (
http://specs.openstack.org/openstack/charm-specs/); this topic is something
we could discuss in a bit more detail at the PTG in Denver (I'll add an
item to the agenda for the charms room).

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 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] [Nova] [nova-lxd] Broken nova-lxd

[James Page]

Morning

On Thu, 27 Jul 2017 at 23:58 Michael Still  wrote:

> Hi,
>
> I'm cc'ing openstack-dev because your email is the same as the comment you
> made on the relevant review, and I think getting visibility with the wider
> Nova team is a good idea.
>
> Unfortunately this is a risk of having an out of tree Nova driver, which
> has never been the recommended path for implementing drivers for Nova.
> Being out of tree isn't forbidden, but it does come with the cost of
> staying up to date with Nova and handling changes as they occur.
>

Agreed - and we've felt this from time-to-time since the nova-lxd driver
was started.

Maybe the Queens cycle might be a good time to review our out-of-tree-ness
and see whether the Nova team would be prepared to accept the LXD driver
in-tree.

I'm more comfortable now with where we are with regards to devstack tempest
testing in the gate for the LXD driver, although we do still have some
feature gaps compared to the libvirt driver (specifically boot from volume)
which results in a large-ish skip list.


> In this case, if you look at the review chain you'll see that the move is
> a pre-cursor to moving this code to use oslo.privsep. Unless lxd is going
> to move to privsep in lockstep with nova, your best bet would be to
> duplicate this utility method in the nova-lxd codebase.
>

We'll duplicate right now (see [0]) to unblock the current problem and take
a look at the work to move lockstep with nova to use oslo.privsep.

Cheers

James

[0] https://review.openstack.org/#/c/488254/
__
OpenStack Development Mailing 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] Required Ceph rbd image features

[James Page]

On Wed, 21 Jun 2017 at 20:08 Jason Dillaman  wrote:

> On Wed, Jun 21, 2017 at 12:32 PM, Jon Bernard  wrote:
> > I suspect you'd want to enable layering at minimum.
>
> I'd agree that layering is probably the most you'd want to enable for
> krbd-use cases as of today. The v4.9 kernel added support for
> exclusive-lock, but that probably doesn't provide much additional
> benefit at this point. The striping v2 feature is still not supported
> by krbd for non-basic stripe count/unit settings.
>

The newer cinder ceph replication features use journaling and exclusive-lock
(see [0]), so any krbd based driver would not be able to support this
feature right now.

[0]
http://ceph.com/planet/openstack-cinder-configure-replication-api-with-ceph/
__
OpenStack Development Mailing 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] [infra] openstack-ubuntu-testing-bot -- please turn off

[James Page]

Hi Ian

On Fri, 9 Jun 2017 at 07:57 Ian Wienand  wrote:

> Hi,
>
> If you know of someone in control of whatever is trying to use this
> account, running on 91.189.91.27 (a canonical IP), can you please turn
> it off.  It's in a tight loop failing to connect to gerrit, which
> probably isn't good for either end :)


Disabled - apologies for any issues caused.
__
OpenStack Development Mailing 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] [networking-bagpipe] exabgp dependency

[James Page]

Hi Thomas

On Tue, 23 May 2017 at 09:14  wrote:

> Hi James,
>
> FYI, exabgp 4.0.0 has been released and this release can be package to
> satisfy networking-bagpipe needs.
> A request for adding exabgp as a proper OpenStack requirement is in
> flight: https://review.openstack.org/#/c/467068
>

Great - added to my TODO list for pike b2.

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

Re: [openstack-dev] [networking-bagpipe] exabgp dependency

[James Page]

Hi Thomas

On Thu, 27 Apr 2017 at 17:03  wrote:

> Indeed, we have moved from shipping a fork of an old exabgp in bagpipe-bgp
> (a.k.a."vendoring", i.e. baaad...) to using upstream, but we have
> dependencies on exabgp development branch.
>
> I've been in touch with ExaBGP main author, who plans to release exabgp 4
> from master "soon".
> The one pending item he would like to cover before releasing is having
> exabgp run with python3, and not everything is ready [1].
>
> So, while I don't have a full answer on the "when", this is reasonable
> information on the "how" this will happen.
> I hope this can be achieved in a timeframe compatible with Pike, and plan
> to spend some time helping this happen.
>
> Once this is done, we'll also work to include exabgp in
> global-requirements.
>

That all sounds great; I'll hold off on the first milestone for this
package in Ubuntu for now and we can review again at the next milestone!

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] [networking-bagpipe] exabgp dependency

[James Page]

Hi

I'm working on the wider networking-* packages we have in Ubuntu for Pike
milestone 1 and noticed that exabgp is currently being pulled in from the
master branch of exabgp; any ideas when you might be able to switch to a
released version of exabgp?

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] [all] Switching gate testing to use Ubuntu Cloud Archive

[James Page]

Hi Clark

On Tue, 4 Apr 2017 at 00:08 Clark Boylan  wrote:

> One of the major sets of issues currently affecting gate testing is
> Libvirt stability. Elastic-recheck is tracking Libvirt crashes for us
> and they happen frequently [0][1][2]. These issues appear to only affect
> Ubuntu Xenial (and not Trusty or CentOS or Fedora) and after talking in
> #openstack-nova it is clear that Libvirt isn't interested in debugging
> such an old version of Libvirt (1.3.1). And while it isn't entirely
> clear to me which exact version would be acceptable to them the Ubuntu
> Cloud Archive (UCA) does publish a much newer Libvirt (2.5.0).
>

tl;dr - Christian (cpaelzer) is working towards resolution of the libvirt
1.3.1 issues in Xenial, but right now we're stuck on reproduction of the
issues outside of the gate.


> I have pushed a change to devstack [3] to enable using UCA which pulls
> in new Libvirt and mostly seems to work. I think we should consider
> switching to UCA as this may fix our Libvirt problems and if it doesn't,
> we will be closer to a version of Libvirt that upstream should be
> willing to fix.
>
> This isn't the most straightfoward switch as UCA has a different repo
> for each OpenStack release. libvirt-python is sensitve to the underlying
> library changing; it is backward compatible but libvirt-python built
> against older libvirt won't work against new libvirt. The result is a
> libvirt-python wheel built on our wheel mirror does not work with UCA.
> On the positive side both the OpenStack puppet modules and OpenStack
> Ansible are using UCA with their deployment tooling so this should get
> us closer to what people are using in the wild.
>

+1 on taking this approach - this also aligned with what we deploy and test
with for the OpenStack Charms.

Please stick to using the updates pockets from the Ubuntu Cloud Archive
(which I can see in the review referenced that you are doing); all UCA
testing of packaging and version updates is done in the proposed pockets so
this should ensure a better level of stability for the OpenStack gate.

[...]

> Finally it is worth noting that we will get newer packages of other
> software as well, most notably openvswitch will be version 2.6.1 instead
> of 2.5.0.


Worth noting that in the same way that we update OpenStack packages in the
UCA for new minor and patch releases, we also do the same for Open vSwitch
patch releases - so the Ocata UCA will get released Open vSwitch versions
on the 2.6.x series.

The Pike UCA will (probably) get a newer version of Ceph which might be of
interest for gate testing as well.

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] [all] Switching gate testing to use Ubuntu Cloud Archive

[James Page]

On Tue, 4 Apr 2017 at 14:38 Daniel P. Berrange  wrote:

> On Mon, Apr 03, 2017 at 04:06:53PM -0700, Clark Boylan wrote:
> > Hello,
> >
> > One of the major sets of issues currently affecting gate testing is
> > Libvirt stability. Elastic-recheck is tracking Libvirt crashes for us
> > and they happen frequently [0][1][2]. These issues appear to only affect
> > Ubuntu Xenial (and not Trusty or CentOS or Fedora) and after talking in
> > #openstack-nova it is clear that Libvirt isn't interested in debugging
> > such an old version of Libvirt (1.3.1). And while it isn't entirely
> > clear to me which exact version would be acceptable to them the Ubuntu
> > Cloud Archive (UCA) does publish a much newer Libvirt (2.5.0).
>
> If going to the libvirt upstream community for help, we'd generally want
> to see the latest upstream release being used. Ideally along with
> willingness
> to test git master if investigating a troublesome issue, but we understand
> using git master is not practical for many people.
>
> If using an old version provided by an OS distro, then we would generally
> expect the OS distro maintainers to lead the investigation, and take the
> responsibility for reproducing on latest upstream. Upstream libvirt simply
> doesn't have bandwidth to do the OS distro maintainers job for them when
> using old distro versions.
>

Agree on the responsibility for maintenance of libvirt in Ubuntu. Christian
Ehrhardt (cpaelzer) has been working to help resolve the libvirt 1.3.1 bugs
currently impacting the gate and does have updated packages available for
testing, but right now we're not able to reproduce the bugs outside of the
gate environment so verifying that these actually resolve the underlying
issues is proving problematic.
__
OpenStack Development Mailing 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] [snaps] proposing Dmitrii Shcherbakov for core review team

[James Page]

On Wed, 22 Mar 2017 at 15:10 Corey Bryant 
wrote:
[...]

> +1
>
> I have full confidence in Dmitrii.  He's already a great asset to snaps
> and will be great to have as a core reviewer.
>

And then there were three...

welcome to the core reviewers team Dmitrii!

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] [snaps] proposing Dmitrii Shcherbakov for core review team

[James Page]

Hi Snappers

Dmitrii did some good work on the ceilometer snap and has been providing
reviews and feedback of other changes in the queue over the last few months
as well has hanging out and being a sounding board/answering questions in
#openstack-snaps.

He's also working out how to get libvirt functional in a snap (no mean
feat).

I'd like to propose Dmitrii to the snaps core reviewers team.

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] [ptls] Project On-Boarding Rooms

[James Page]

Hi Kendall

On Wed, 15 Mar 2017 at 18:22, Kendall Nelson  wrote:

> Hello All!
>
> As you may have seen in a previous thread [1] the Forum will offer project
> on-boarding rooms! This idea is that these rooms will provide a place for
> new contributors to a given project to find out more about the project,
> people, and code base. The slots will be spread out throughout the whole
> Summit and will be 90 min long.
>
> We have a very limited slots available for interested projects so it will
> be a first come first served process. Let me know if you are interested and
> I will reserve a slot for you if there are spots left.
>

Charms project would like a slot if possible please!

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 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] [snaps] announce: new snaps for rally, tempest and openstackclients

[James Page]

Hi All

Snap packages for rally (0.7.0), tempest (14.0.0) and openstackclients
(currently Newton aligned) are available for use; the associated git
repositories can also be found under the openstack org on github (see [0],
[1], [2]).  Git repos also contain details of use of each snap.

You can consume these snaps from any Ubuntu 16.04 install - for example:

 sudo snap install --edge --classic openstackclients

to enable all client tools provided by the openstackclients snap:

 ls -1 /snap/bin/openstackclients.* | cut -f 2 -d . | xargs sudo snap alias
openstackclients

Snaps will grow support for auto-aliasing at some point, so that second
step will go away in the future.

These are all still pretty fresh, so if you hit issues, please raise bugs
against the appropriate Launchpad projects; we're also hanging out in
#openstack-snaps on freenode if you want to ask any questions directly!

Enjoy

James

[0] https://github.com/openstack/snap-tempest
[1] https://github.com/openstack/snap-rally
[2] https://github.com/openstack/snap-openstackclients
__
OpenStack Development Mailing 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

[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

[openstack-dev] [snaps] alternative distribution approach for OpenStack

[James Page]

Hi All

I’ve been working with a few folk over the last few months to see if snaps
(see [0]) might be a good alternative approach to packaging and
distribution of OpenStack.

As OpenStack projects are Python based, producing snaps has been relatively
trivial with the snapcraft python plugin, which supports all of the tooling
that would be used in a deployment from source (pip, constraints etc…).
Thanks goes to Sam Yaple for his work on the Python plugin to support all
of the required features for snapping OpenStack!

The resulting snap for each project is self contained, with all required
dependencies baked into the snap, rather than using system provided
dependencies from the hosting operating system.

This means that the snap is directly aligned with each OpenStack project
from a software component perspective - avoiding the juggling act that
distro’s have to do each cycle to ensure the entire dependency chain for
OpenStack is lined up correctly.

Additionally, we can also include other non-Python dependencies in a snap -
for example the nova-hypervisor snap includes dnsmasq, ipset and
openvswitch tools built from source as part of the snap build process.  I’d
envision extending that list to include libvirt (but that was a bit too
much to bite off in the first few cycles or work).

>From an operations perspective, snaps are transactionally applied on
installation, which means that if an upgrade fails, the snap will be rolled
back to the last known good version.

Installs and upgrades are also fast, as the snap internally is a read only
squashfs filesystem which is simply mounted alongside the existing
installed snap, daemons are stopped, pointers switched and daemons
restarted.

Snaps typically run a confined environment, sandboxed using AppArmor and
Seccomp on Ubuntu. Snapd (the management daemon for snaps) provides a
number of interfaces to allow users to grant snaps permissions to perform
different operations on the host OS - for example network and firewall
control (the full interface list is much longer  - see [3]).

We’ve leveraged (and contributed to) a number of these interfaces to
support the nova-hypervisor snap.

Snap confinement means that snaps don’t (by default) have access to /etc -
instead configuration is supplied in a snap specific location on the
filesystem (take a look in the README of a snap for how that works at a
high level).  That location essentially mirrors /etc for the snap, which
should make adoption relatively easy for existing deployment tooling.

Snaps are also by design distro agnostic - so long as snapd has been ported
and the kernel version is sufficient to support the required security
features things should just work (but we’ve not tried that out just yet!).

We’ve snapped a few core components (see [1]) - enough to produce an
all-in-one install which you can try on Ubuntu 16.04 using snap-test [2] to
get a flavor of how things will look as this work develops further.


The source for each snap is being developed on OpenStack infra, however the
final build and publication to the snap store is being done on Launchpad
using git repo mirroring and automatic snap building on each change.   This
includes arm64 and ppc64el architecture builds.

Updates are only pushed to the edge channel on the snapstore today - we’ll
need to figure out a good channel strategy as things mature to include
great CI/CD as well as concurrent support for multiple OpenStack releases.

Anyway - that’s probably enough words for now!

We’re all hanging out in #openstack-snaps on Freenode IRC so come find us
if you have any questions!

Cheers

James

[0] http://snapcraft.io

[1] https://github.com/search?q=org%3Aopenstack+snap

[2] https://github.com/openstack-snaps/snap-test
[3] http://snapcraft.io/docs/reference/interfaces
__
OpenStack Development Mailing 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

[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] 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] Barbican Hostname Config Params

[James Page]

Hi James

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

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

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

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

Cheers

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

[openstack-dev] [charms] design summit sessions summary

[James Page]

Hi All

After some extended travel after the summit, I've finally got round to
writing a summary of the two design summit sessions we held in Barcelona
(see [0] and [1] for full notes).

1) Cross Charm Initiatives

We had general agreement to switch all charms to Python 3, dropping charm
support for Ubuntu 12.04 in the process in order to have a decent Python 3
baseline to work with from 14.04 onwards. This should be achievable this
cycle.

All charms will switch to using memcache locally for token caching, and
where possible API services will be run under Apache+mod_wsgi, inline with
changes in support policy being made across other projects.

The next charm release will be aligned to the Ocata release (February), and
then we'll resume the normal 3 month cadence from that point forward -
which means we have a slightly longer than normal cycle!

2) Testing REDUX

We had a number of discussion both in the fishbowl session and in the
workroom on Friday about re-aligning testing around bundles, rather than
individual charms - this is in alignment with a general shift in the wider
charm community, and some new tooling is appearing to support that
(Matrix).  I anticipate this will be a multi-cycle effort, but it should
make it much easier for the wider charm ecosystem to CI against core charm
changes going forward.

3) OpenStack LB

Currently all haproxy services are run on unit (i.e. embedded alongside
glance/cinder/neutron/nova etc...).  We discussed a plan to allow load
balancing to be placed separately from core services, supporting use of
multiple DMZ network topologies, and potentially easing lifecycle upgrades
from trusty->xenial (although that bit s part of a wider piece of work
around cross Ubuntu series upgrades for OpenStack).

I think that just about covers the high level items.

I really enjoyed the workroom time we had on Friday esp. helping the
developers from 6wind, Calico and CloudBase get started on the road to
making their charm integrations part of the Charms project - it was great
to see the start of the incubation process for growing and diversifying our
developer community!

Thank-you to all of those who participated!

Cheers

James

[0] https://etherpad.openstack.org/p/BCN-charms-fb-1
[1] https://etherpad.openstack.org/p/BCN-charms-fb-2
__
OpenStack Development Mailing 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] draft logo design

[James Page]

Hi Charmers

I've received a draft version of our project logo, using the mascot we
selected together. A final version (and some cool swag) will be ready for
us before the Project Team Gathering in February. Before they make our logo
final, they want to be sure we're happy with our mascot.

We can discuss any concerns in Barcelona and you can also provide direct
feedback to the designers:
  http://tinyurl.com/OSmascot

Logo feedback is due Friday, Nov. 11. To get a sense of how ours stacks up
to others, check out this sneak preview of several dozen draft logos from
our community:
  https://youtu.be/JmMTCWyY8Y4

Cheers

James
[image: Charms.jpeg]
__
OpenStack Development Mailing 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] summit schedule + pads

[James Page]

Hi Charmers

The Ocata Design Summit is upon us; we have fishbowl sessions on Wednesday
afternoon, and workrooms first thing in Friday morning:


https://www.openstack.org/summit/barcelona-2016/summit-schedule/global-search?t=Charms

I've created pads for the fishbowl sessions:

  https://etherpad.openstack.org/p/BCN-charms-fb-2
  https://etherpad.openstack.org/p/BCN-charms-fb-1

We'll use these to guide the discussion and document outcomes for each of
the topics we need to discuss.

I expect to use the workroom time to spike on some of the topics discussed
on Wednesday.

All contributors are welcome to participate; I expect that a few developers
associated with SDN and Storage integrations are here this week - this is a
great opportunity to catchup with the rest of the OpenStack charms team to
find out about plans for the next development cycle so please come along!

Look forward to seeing you all this week.

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] master branches open for development

[James Page]

Hi All

Following on from yesterdays charm release (see [0]), master branches are
now open for general development across the OpenStack Charms.

Thanks again to everyone who contributed to the 16.10 charm release!

Cheers

James

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

[openstack-dev] [charms] 16.10 release feature freeze

[James Page]

Hi Charmers

Just a reminder that as of the end of yesterday, we're in feature freeze
for the 16.10 charm release in two weeks time;  if you have a compelling
feature that you feel should be considered, please email openstack-dev with
a request for a freeze exception with details of the change (and preferably
a link to the review(s) as well).

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 day - Thursday 22nd September

[James Page]

Hi Team

We running up towards feature freeze on the 29th of September for our charm
release mid October.

So that we have an accurate view of bugs across the OpenStack Charms in
advance of that date, I'm proposing we have a bug day next Thursday (22nd
September).

Anyone is welcome to participate - we'll co-ordinate via the
#openstack-charms IRC channel - objective for the day is a) triage new
untouched bugs b) re-touch on any outstanding bugs and c) squash as many as
possible on the day!

This view is probably the best way to find bug work:

  https://bugs.launchpad.net/~openstack-charmers/+packagebugs

Looking forward to squashing as many bugs as possible!

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]Running two haproxy-using units on same machine?

[James Page]

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

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

On Wed, 14 Sep 2016 at 10:03 Neil Jerram <n...@tigera.io> wrote:

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

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

[James Page]

Hi Neil

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

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

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

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

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

Cheers

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

[openstack-dev] [charms] PTL candidacy

[James Page]

Hi

I would like to announce my candidacy for PTL of the OpenStack Charms
project (see [0]).

I'm the incumbent and first PTL of this project, which joined the OpenStack
project this year;  Right now we have around 30 charms for deploying
various parts of OpenStack, with an active core team 100% populated by
Canonical.

We're slowly incubating contribution from outside of this team - this cycle
I want to focus on changing that; specifically I think we have shortcomings
in engaging new developers, as getting into OpenStack charm development can
be high cost - the route to testing your charm change prior to submission
currently presents various options, and I want to focus on ensuring that
anyone with a reasonably specified machine can get started deploying
OpenStack and hacking on the OpenStack charms, enabling both end-users and
developers to have a better start in using and understanding the OpenStack
Charms.

I will continue to drive cross charm initiatives; specifically I think
Python 3 support is a key objective during the Ocata cycle, and we should
aim
to have that in place as early in cycle as possible.

I also look forward to working collaboratively with other deployment
projects
within the OpenStack project.

I look forward to helping steer the project during the Ocata cycle, and
helping to incubate the developer and user community around the OpenStack
Charms!

Cheers

James

[0] https://review.openstack.org/368678
__
OpenStack Development Mailing 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] [puppet] today was a bad day for CI

[James Page]

On Fri, 9 Sep 2016 at 01:17 Emilien Macchi  wrote:
[...]

> 3) Disable Ironic testing on Ubuntu. Packages are broken in recent
> Newton upgrade. They are working on it.
>

Ironic packaging issue fixed and released to newton-updates; that will
teach me to spend a morning tidying up old bugs :).


> 4) Enable br_netfilter kernel module on Ubuntu.
> See https://bugs.launchpad.net/cloud-archive/+bug/1621651
> Even if it's not critical, it's a nice-to-have because it removed the
> ERROR that we had in neutron logs. We'll see how the bug report evolve
> and maybe remove this workaround.
>

I've moved this to:

  https://bugs.launchpad.net/cloud-archive/+bug/1621854

as its a separate issue to the os-vif version problem (see below).

6) Disable linuxbridge on scenario003 for Ubuntu
> Also see https://bugs.launchpad.net/cloud-archive/+bug/1621651


os-vif updated to 1.2.1 and released to newton-updates; not detected by our
version checker as its was not in upper-constraints until recently.
__
OpenStack Development Mailing 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] [requirements][FFE] global-requirements update to positional to 1.1.1

[James Page]

On Wed, 7 Sep 2016 at 14:30 Ian Cordasco  wrote:
[...]

> https://review.openstack.org/366631
> >
> > The combination of oslo.context 2.9.0 + positional 1.0.1 (which is the
> > current minimum requirement) results in various unit test failures in
> > barbican, related to parsing of request headers in generated contexts
> > for unit testing. Updating to 1.1.1 resolves this issue.
>
> So I take it someone has verified that the request headers used in the
> faked(?) contexts in these tests will never be seen in the real world
> then? I looked at the tests that James linked in the barbican channel
> when they were looking for help debugging this and those looked like
> *functional* tests, not unit tests. That doesn't give me any
> confidence that this is *just* a testing issue.
>
> > This is specifically affecting barbican and RDO testing (from discussion
> > and the review).
>
> I believe this is also affecting Ubuntu's backing of Newton-3, but
> James can correct me if I'm wrong.
>

We're unblocked by upgrading to positional 1.1.1 (the CI build failure was
detected a week or so ago, but with b3 also arriving and it not being
entirely obvious what the problem was its taken a while to figure out);
I've enforced this as a versioned package dependency for oslo.context, so
upgrades from mitaka will get the right version as well.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [oslo.context][requirements][ffe] newton - positional 1.1.1 minimum requirement

[James Page]

On Wed, 7 Sep 2016 at 14:51 Ian Cordasco  wrote:

> Hey James!
>
> There's already a discussion about this with the [requirements] and
> [ffe] tags by Matthew Thode. Could we centralize the discussion on
> that thread please?
>

Of course - missed that whilst eating lunch!
__
OpenStack Development Mailing 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] out next week/PTL cover

[James Page]

Hi

I'm out of contact from everything electronic next week; back on the 22nd
August.

David Ames (thankyou!) will be covering any Charms PTL related matters in
my absence and generally keeping the wheels on development.

Cheers

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

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

[James Page]

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

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

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

Re: [openstack-dev] [release] Re: [Neutron][L2GW] Mitaka release of L2 Gateway now available

[James Page]

Hi Ihar

On Mon, 8 Aug 2016 at 10:37 Ihar Hrachyshka  wrote:
[...]

> Any update on re-tagging the mitaka release of networking-l2gw with the
> > correct semantic version?  I'm working on packaging updates for Debian
> > and Ubuntu, and don't really want to push in 2016.1.0, only to have to
> > then bump the epoch (versioning semantic in Debian for dealing with
> > changes in versioning that result in out of order versions) again once
> > the next semantically versioned release comes out.
> >
>
> (Hey, neutron release liaison here.)
>

Hey!


> I was thinking we will stick to the (unfortunate) versioning for the
> subproject for the time of Mitaka. But I am happy to switch versioning if
> it makes someone’s life easier. Though I would like to hear a confirmation
> on that from l2gw folks first. (I added some cores to CC.)
>

1.0.0 -> 2016.1.0 -> 3.0.0 is the trick here as 3.0.0 < 2016.1.0; its
possible but I'd rather avoid the epochs in packaging if possible (I might
just skip 2016.1.0 and use a 1.0.0+git snapshot version instead to avoid
that situation).

So I can be flexible, but I suspect that this versioning inconsistency will
cause other deployment types issues as well.


>
> > Also, what are networking-l2gw's plans for Newton?  I also manage the
> > packaging of vmware-nsx, which amongst other things, depends on
> > networking-l2gw so it would be nice to have a co-ordinated release of
> > networking-l2gw, vmware-nsx (and networking-sfc and tap-as-a-service -
> > but I'll start another thread on that).
>
> Note that neither vmware-nsx nor taas is part of neutron stadium, and as
> such are not managed by neutron-release team. You would need to coordinate
> with them separately.
>

OK - I missed they are not part of neutron stadium ([0]); I'll hookup with
those teams individually (already in contact with the vmware-nsx team
anyway).

There was a thread on SFC lately asking for Mitaka release. I guess we
> don’t have any stable branches so far for the subproject.


Yeah - started a different thread on that one.

Cheers

James

[0]
http://docs.openstack.org/developer/neutron/stadium/sub_projects.html#official-sub-project-list
__
OpenStack Development Mailing 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] [networking-sfc] Newton release plans?

[James Page]

Hi Networking SFC team

I'm trying to get a view on a few Neutron related projects with the
objective of lining up a release in Ubuntu and Debian alongside OpenStack
Newton of vmware-nsx, networking-l2gw, networking-sfc and tap-as-a-service.

What are your plans for Newton? I can push snapshots into Debian/Ubuntu
during development, but it would be nice to know at what point in time
networking-sfc will release a version for Newton so we don't end up with a
dangling snapshot of networking-sfc after the release of Ubuntu 16.10 and
OpenStack Newton.

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] [release] Re: [Neutron][L2GW] Mitaka release of L2 Gateway now available

[James Page]

Hi Carl

On Thu, 19 May 2016 at 21:51 Carl Baldwin  wrote:

> On Thu, May 19, 2016 at 7:09 AM, Doug Hellmann 
> wrote:
> > We have the same issue with version numbers regressing no matter when we
> > cut the next release, so it's up to the team. It might be easier to deal
> > with now while it's fresh in our minds.
> >
> > I would like to update the instructions that were followed to give
> > better information about version numbers. Can someone point me to the
> > documentation that was used for the release process?
>
> Hi, they are here [1].  Built from here [2].
>
> Carl
>

Any update on re-tagging the mitaka release of networking-l2gw with the
correct semantic version?  I'm working on packaging updates for Debian and
Ubuntu, and don't really want to push in 2016.1.0, only to have to then
bump the epoch (versioning semantic in Debian for dealing with changes in
versioning that result in out of order versions) again once the next
semantically versioned release comes out.

Also, what are networking-l2gw's plans for Newton?  I also manage the
packaging of vmware-nsx, which amongst other things, depends on
networking-l2gw so it would be nice to have a co-ordinated release of
networking-l2gw, vmware-nsx (and networking-sfc and tap-as-a-service - but
I'll start another thread on that).

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] [juju charms] How to configure glance charm for specific cnider backend?

[James Page]

Hi Andrey

On Wed, 3 Aug 2016 at 14:35 Andrey Pavlov  wrote:

> Instead of adding one more relation to glance, I can relate my charm to
> new relation 'cinder-volume-service'
>

almost


>
> So there is no more changes in the glance charm.
> And additional in my charm will be -
>
> metadata.yaml -
>
>
>
>
> *subordinate: trueprovides:  image-backend:interface: cinderscope:
> container*
>

Almost - the interface type should be something like 'glance-backend'
matching the type of the container scoped interface we'd need to add to the
glance charm.

provides:
  image-backend:
interface: glance-backend
scope: container

The glance charm needs to interrogate the data presented by the subordinate
charm - I'd suggest one of the data items is 'cinder-backend=True|False' in
which case the glance charm can then set the required configuration option
in the glance-api.conf file (instead of doing that via a relation to cinder
as you proposed in your original changes to glance).


> and then I can relate my charm to glance (and my charm will be installed
> in the same container as glance, so I can configure OS)
> *juju add-relation glance:cinder-volume-service
> scaleio-openstack:image-backend*
>
> This option works for me - I don't need to add something to glance config.
> I'm only need to add files to /etc/glance/rootwrap.d/
> and this option allows to do it.
>

I think the experience would be something like:

  *juju add-relation glance:image-backend  scaleio-openstack:image-backend*

based on my feedback above.  A relation to cinder might not be required
at-all if all glance needs to know is 'use cinder' rather than any other
additional data such as the location of the cinder-api services etc..

As you state - the scaleio-openstack charm can install the required filters
to /etc/glance/rootwrap.d - which is great as it moves the scaleio specific
bits into a specific charm for scaleio (which I like), rather than
overloading and increasing the complexity of the core glance charm.


> I've made additional review - https://review.openstack.org/#/c/350565/
>

Looking today -  I think we can refine things via the review if the overall
design intent is agreed here.

Thanks for your work on this feature!

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] [juju charms] How to configure glance charm for specific cnider backend?

[James Page]

On Tue, 2 Aug 2016 at 16:54 Andrey Pavlov  wrote:

> James, thank you for your answer.
>

No problem.

I'll file bug to glance - but in current releases glance-charm have to
> do it himself, right?
>

We should be able to add the required bits using an Ubuntu SRU - lets raise
the bug and see exactly what needs to be done, and then we can decide
whether the charm workaround is still required.

I'm not sure that I'm correctly understand your question.
> I suppose that deployment will have glance and cinder on different
> machines.
>

yes - principle charms should typically be deployed in their own units, as
the assume ownership over the filesystem.


> Also there will be one relation between cinder and glance to configure
> glance to store images in cinder.
>

ack

Other steps are optional -
> If cinder is used specific backend that needs additional configuration
> - then it can be done via storage-backend relation (from subordinate
> charm).
> If this backend needs to configure glances' filters or glance's config
> - then it should be done via any subordinate charm to glance (but
> glance doesn't have such relations now).
>

No - we'd need to add a container scoped 'image-backend' relation to
glance, allowing a subordinate to be deployed with glance to install the
required rootwrap configuration, dependencies etc...

You next email covers that - so I'll respond on that there.
__
OpenStack Development Mailing 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] [juju charms] How to configure glance charm for specific cnider backend?

[James Page]

Hi Andrey

On Tue, 2 Aug 2016 at 15:59 Andrey Pavlov  wrote:

> I need to add glance support via storing images in cinder instead of
> local files.
> (This works only from Mitaka version due to glance-store package)
>

OK


> First step I've made here -
> https://review.openstack.org/#/c/348336/
> This patchset adds ability to relate glance-charm to cinder-charm
> (it's similar to ceph/swift relations)
>

Looks like a good start, I'll comment directly on the review with any
specific comments.


> And also it configures glance's rootwrap - original glance package
> doesn't have such code
> (
>   I think that this is a bug in glance-common package - cinder and
> nova can do it themselves.
>   And if someone point me to bugtracker - I will file the bug there.
> )
>

Sounds like this should be in the glance package:

  https://bugs.launchpad.net/ubuntu/+source/glance/+filebug

 or use:

  ubuntu-bug glance-common

on an installed system.


> But main question is about additional configurations' steps -
> Some cinder backends need to store additional files in
> /etc/glance/rootwrap.d/ folder.
> I have two options to implement this -
> 1) relate my charm to glance:juju-info (it will be run on the same
> machine as glance)
> and do all work in this hook in my charm.
> 2) add one more relation to glance - like
> 'storage-backend:cinder-backend' in cinder.
> And write code in a same way - with ability to pass config options.
>

> I prefer option 2. It's more logical and more general. It will allow
> to configure any cinder's backend.
>

+1 the subordinate approach in cinder (and nova) works well; lets ensure
the semantics on the relation data mean its easy to restart the glance
services from the subordinate service if need be.

Taking this a step further, it might also make sense to have the relation
to cinder on the subordinate charm and pass up the data item to configure
glance to use cinder from the sub - does that make sense in this context?

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

[James Page]

Hi All

As an approved project, we need to provide some ideas for a project mascot
for the Charms project (see [0]).

Some suggestions as discussed on IRC:

1) cobra ('[snake] charming openstack') - which aligns with the Juju logo a
little.
2) kraken ('many armed animal managing openstack') - but I think that falls
into mythical creatures so its probably excluded so maybe octopus instead?

It would be nice to have one or two more ideas - any suggestions?

Cheers

James

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

[openstack-dev] [charms] 16.07 release feature freeze today

[James Page]

Hi All

A (somewhat) late reminder that the feature freeze for the 16.07 charm
release at the end of the month is today; any outstanding feature reviews
need to be fully tested, reviewed and landed by 0800 UTC on the 15th July
(which is the end of the day for those on the west coast of the US).

This has been discussed a-lot in channel (#openstack-charms) - however need
to remember to notify the world as well!

Bug fixes only from tomorrow until the 28th please!

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] Juju Charm Usability/Functionality Enhancements

[James Page]

Hi James

On Wed, 6 Jul 2016 at 18:52 James Beedy  wrote:

> I've a few things I want to bring up concerning usability/functionality in
> nova-cloud-controller and openstack-dashboard.
>
> 1. Request-timeout configurability for openstack-dashboard.
> - Everyone who accesses horizon asks me for this. I think it would be
> smart to set the timeout to the keystone token session timeout value.
> - I've filed a feature request/bug, and proposed a merge for this in
> the past, to no avail. This is a must for usability, and so simple to add.
> What gives?
>

visibility of merges across a large number of charms in launchpad was never
good so things did get missed; I've had a dig but can't find either a bug
or a merge against the old launchpad bzr branches; this sounds like a
useful feature - it would be helpful if you could raise a bug and then we
can workout how that fits into the next 3 months of charm delivery.


> 2. 'cross_az_attach=True'
> - Without "cross_az_attach=True" under the cinder context in
> nova.conf, live migration across availability_zones, alongside a handful of
> other critical ops fail.
> - This is a critical config param, the absence of which has blocked me
> on multiple levels for a long time now.
> - I've previously filed a bug/feature request for this, and also have
> proposed a merge that adds this functionality.
> - This is critical. ATTN HERE ASAP, PLEASE!
>

Already on my list to review this bug:


https://bugs.launchpad.net/charms/+source/nova-cloud-controller/+bug/1599289

again I can't find a merge on Launchpad (see [1]) but we'll see if we can
fit this into the next 7 days of dev prior to the feature freeze for the
16.07 charm release at the end of the month.

Cheers

James

[1]
https://code.launchpad.net/~openstack-charmers-archive/charms/trusty/nova-cloud-controller/next/+merges
__
OpenStack Development Mailing 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] [Charm][Congress] Upstreaming JuJu Charm for Openstack Congress

[James Page]

Hi Bryan

On Tue, 5 Jul 2016 at 21:21 SULLIVAN, BRYAN L  wrote:

> I've been working in the OPNFV (https://wiki.opnfv.org/) on a JuJu Charm
> to install the OpenStack Congress service on the OPNFV reference platform.
> This charm should be useful for anyone that wants to install Congress for
> use with an OpenStack deployment, using the JuJu tool. I want to get the
> charm upstreamed as an official openstack.org git repo similar to the
> other repos for JuJu Charms for OpenStack services. I participate in the
> Congress team in OpenStack, who don't know the process for getting this
> charm upstreamed into an OpenStack repo, so I am reaching out to anyone on
> this list for help.
>

I can help you with that as I did most of the project-config changes for
the original move of OpenStack charms to git/gerrit a few months back.


> I have been working with gnuoy on #juju and narindergupta on #opnfv-joid
> on this. The charm has been tested and used to successfully install
> Congress on the OPNFV Colorado release (Mitaka-based, re OpenStack). While
> there are some features we need to continue to work on (e.g. Horizon
> integration), the charm is largely complete and stable. We are currently
> integrating it into the OPNFV CI/CD system through which it will be
> regularly/automatically tested in any OPNFV JuJu-based deployment (with
> this charm, Congress will become a default service deployed in OPNFV thru
> JuJu).
>

That all sounds awesome; it would also be great to get that system doing
testing of reviews and providing feedback to proposed changes; we can cover
some of that using Canonical CI (you'll notice that feeding back on reviews
on the charms already being developed under git/gerrit), but having other
3rd party CI systems provide feedback would also be great!.

Any pointers on how to get started toward creating an OpenStack git repo
> for this are appreciated.
>

https://review.openstack.org/#/c/323716/ is probably a good start; this was
for the hacluster charm which got missed during the original migration.

You can add an additional field to the gerrit/projects.yaml entry to detail
the repository to do a one-time import from:

 upstream: https://github.com/gnuoy/charm-congress


Lets make sure we get any outstanding changes merged into that repository
first, or we can use your git repo for the one-time import if that's easier
for now.

I'd really love to have congress as part of the OpenStack Charms project
(we're currently working towards official project status at the moment) but
I'd also like to ensure that you're engaged directly with reviews and
changes to the congress charm specifically, so I think its worth having a
slight different ACL configuration that includes the core charm acl config,
but also adds an additional charms-congress-core group with permissions to
Code-Review: +2 and Workflow: +1 for congress charm repository.

Does that make sense? you can reach out to me in #openstack-charms to
discuss in more detail if you like.

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] inclusion of charm-helpers (LGPL licensed)

[James Page]

Hi Billy

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

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

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


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

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

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

[James Page]

Hi All

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

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

Thoughts? ideas?

Cheers

James

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

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

[James Page]

Hi

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

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

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

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

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

Cheers

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

[openstack-dev] [charms] Renaming openvswitch-odl -> openvswitch

[James Page]

Hi All

The current openvswitch-odl charm is designed for use with
nova-compute/neutron-gateway and the odl-controller charm, but it declares
and configures OVS in such a way that I think it has broader applicability
than just OpenDayLight; specifically it looks like it would also work with
ONOS which configures the OVS manager in exactly the same way as for ODL.

I'd like to proposed renaming the openvswitch-odl charm to just openvswitch
to support this generalisation of its use.

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

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

[James Page]

Hi All

tl;dr Juju is a great way of deploying OpenStack, and we'd like the
OpenStack Charms for Juju to become a official OpenStack Project

read on if you want the full details

Juju [0] is a service modelling tool that's been around since about 2010;
developed primarily by Canonical, Juju takes a high level approach to
modelling services and the relations between them (think cinder,
neutron-api, nova-cloud-controller), with the details on exactly how each
of those services is installed, configured, scaled-up, scaled-down, HA'ed
etc.. implemented by a charm for each of the services that form part of a
model;  Juju uses underlying providers (responsible for managing compute,
storage and network resources) to translate the model onto actual machine
resources - in the context of OpenStack, the MAAS (metal-as-a-service [1])
provider is used to deploy an OpenStack model, using the OpenStack Charms,
to a combination of physical servers and LXD containers running on those
servers.

The OpenStack Charms have been around for about the same time as Juju; I
think the first release we supported was OpenStack Diablo, and we've
updated, redesigned and re-factored the charms to support every OpenStack
release on Ubuntu since then.

The OpenStack Charms are a core part of the Ubuntu OpenStack teams approach
to distributing OpenStack on Ubuntu (we use them for all of our deployment
and testing CI, as well as for deploying production OpenStack Clouds at
Canonical's customers). As a result when OpenStack releases we've always
had aligned support in Ubuntu and the OpenStack charms for the latest
release.

The OpenStack charms (26 of them including some things not specifically
OpenStack such as Ceph, Percona XtraDB Cluster and RabbitMQ) are written in
Python; the code base has evolved a-lot over the years (once upon a time
they where bash scripts), as has the approach to writing best practice
charms, and we expect new OpenStack charms to take a slightly different
approach to charm authoring which should make writing a new OpenStack charm
much more lightweight (see [3]).

We migrated development to OpenStack project infrastructure (from its
original home in Launchpad and Bazaar branches) around 4 months ago at the
request of the TC from our original request to be formally recognised as an
OpenStack project; we now have some history that's readily re-viewable so
I've restored our request to become a formal OpenStack project:

 https://review.openstack.org/224797

The community of developers around the charms is not as diverse as I would
like, but we've had a number of contributions from developers at SDN and
storage vendors (who are also maintaining charms for their own solutions)
as well as contribution from CloudBase for enabling support for Microsoft
Hyper-V in a Juju deployed OpenStack Cloud (Juju and MAAS can deploy
WIndows machines as well).

We have some outstanding work to consolidate developer and user
documentation around the OpenStack charms, which the team currently expect
to complete in the next few months.

Cheers

James

[0] https://jujucharms.com/
[1] https;//maas.ubuntu.com/
[2] https://jujucharms.com/openstack
[3]
https://github.com/openstack-charmers/openstack-community/blob/master/openstack-api-charm-creation-guide.md
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc] supporting Go

[James Page]

On Mon, 9 May 2016 at 19:32 Monty Taylor  wrote:
[...]

> [> The point here though, is that the versions of Python that OpenStack
> > has traditionally supported have been directly tied to what the Linux
> > distributions carry in their repositories (case in point, Python 2.6
> > was dropped from most things as soon as RHEL7 was available with Python
> > 2.7). With Go, there might need to be similar restrictions.
>
> Since this is a forward-facing thing, I think starting with the version
> that's in xenial is probably fine for today, yeah? That will be the
> version of go that will get installed in the gate starting with this cycle.
>

Apologies for commenting late on this thread - I needed to catchup with the
Go maintainer in Ubuntu (CC'ed) to get things straight from an Ubuntu
perspective.

a) Distribution of Go based projects in Ubuntu

tl;dr - we've been dealing with distribution of large Go projects in Ubuntu
for a number of years - so no problem if OpenStack wants to support Go as
an official language

Ubuntu supports at least three large Go codebases in archive as of Xenial -
Juju, LXD and Snappy are all written in Go, and as a result we've had a
focus on how to support them for end-users over the last few years.

As Monty points out, Golang 1.6 is the released version of Go in Xenial
(and its also installable for Trusty - "apt-get install golang-1.6-go");
that said the way the packaging has been done, its possible to introduce
newer golang versions without breaking the existing Go based packages in
the Ubuntu archive at any point in time;   The three Canonical projects in
archive are using 1.6 as a baseline for compatibility to make things a
little easier to manage; 1.6 will remain as the default Go version, but
newer versions may be introduced in parallel.

In terms of where code for dependencies of projects sits, Ubuntu has taken
a flexible stance on this - for components where version alignment is good
and there is good reason to want to identify the versions being used across
a number of packages, a separate golang-XXX package is produced - this
allows the Ubuntu Security team to monitor for CVE's, allowing for more
effective security support. A good example of this is the go.crypto
package.  For dependencies used by a single project, or where there is not
alignment with the packaged golang-XXX version, we're continuing to use the
version embedded by the consuming project.

The Debian toolchain around Go packages helps with managing this by adding
'Built-Using' fields to all Go binary packages that depend on separate
golang-XXX packages - which means that the archive keeps track of what was
used to produce a particular binary package.  This allows the distro to
easily analyse what needs rebuilding when a shared golang-XXX package is
fixed/updated in some way, as well as letting us deal with things like
transitions between Go versions (the golang package version is also
embedded in this data).

Shared library support is coming in Ubuntu (and Debian) for Go; however we
think its something that adds value to the distributor (avoiding rebuilds
for fully statically linked binaries) rather than the developer (esp in the
context of security management).  Oh and its still really new...

b) General technical feedback on Go development in the context of OpenStack

Note that I'm not a Go developer, but have been observing Go development
across a number of large Go codebases - these are things I've seen that
help both the development team and the distributors of their work.

i) Use godeps for dependency management

This is used across Juju, LXD and Snappy to manage dependencies at specific
commits/revisions and has proved invaluable.

ii) Don't embedded your dependencies in your VCS repository

Ideally when you cut a release artefact, bundle up the dependencies at this
point in time using godeps.

iii) Agree baseline versions

For each OpenStack release agree a baseline golang version, and common
version alignment on dependencies where appropriate.
__
OpenStack Development Mailing 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] [kolla] Gate precheck job failed due to minimum kernel version on ubuntu 14.04

[James Page]

On Sun, 8 May 2016 at 15:58 Monty Taylor  wrote:

> On 05/08/2016 03:45 AM, Steve Kowalik wrote:
> > On 08/05/16 08:11, lương hữu tuấn wrote:
> >> Hi,
> >>
> >> @Robert: I was successful to update the kernel without change the image.
> >
> > But that was Robert's point entirely. Installing the kernel will work
> > fine, but it does not get you running that kernel -- also like Robert
> > said, you need to change the image to run a different kernel than what
> > it has installed.
> >
>
> We will be changing our images this cycle to Xenial from Trusty. I do
> not believe we have any intention of installing backported wily kernels
> in our trusty images, as what we want to test on them is Trusty.
>
> However, the Xenial transition should be happening soon enough - so
> things that need a newer kernel this release can happily just require
> Xenial images for testing.
>
> I think the question of why/how kolla grew a dependency on a newer
> kernel than what trusty has is worth checking. As of right now, trusty
> kernels are the newest thing supported in the gate.
>

Probably worth noting that trusty does provide hardware enablement
(sometimes referred to as HWE) kernels from newer Ubuntu releases in
archive; however they are not used as the base for Ubuntu Cloud Images
(which just use the release kernel version for 14.04 which is 3.13) and
evidently the trusty images in gate.
__
OpenStack Development Mailing 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] Mitaka, Xenial, OVS Firewall Driver, DPDK, VXLAN and Provider Networks

[James Page]

Hi Thiago
On Sat, 27 Feb 2016 at 23:58 Martinx - ジェームズ 
wrote:
[...]

However, I am curious about the following scenarios:
>
>  Will be possible to use, at the same time (same Network and Compute nodes
> / Host Aggregate):
>
>  1- Regular OVS bridges without DPDK for VXLAN Networks, with
> OVS-Firewall-Driver and;
>
>  2- OVS powered by DPDK for Provider Networks only ( without any firewall,
> current case anyway, due to
> https://bugs.launchpad.net/neutron/+bug/1531205).
>
> ?
>
>  I have NFV Instances that are also, DPDK L2 Bridges running on KVM Guest
> / VirtIO, that are physically wired using Provider Networks (flat and
> vlans).
>
>  So, for the Instance's vNICs (eth1 and eth2) that are used as a L2
> bridge, I don't want any kind of ovs-firewall (I'm not affected by LP
> #1531205 on this case) and I want OVS+DPDK under it but, for SSH into the
> Instance to manage it (via its eth0), it is still using regular VXLAN with
> Security Groups - OVS-Firewall from now on (no need for DPDK under eth0 /
> VXLAN).
>
>  I'm curious about this specially because the OVS Ubuntu package, makes
> use of Debian's Alternatives subsystem, and we need to choose one OVS
> (default), or another (with DPDK), via "update-alternatives", so, will be
> possible to select OVS with DPDK but, use regular bridges with it as well
> (for VXLAN networks)?
>

We're shipping two binaries due to the baseline CPU requirement for DPDK
being above the general baseline in Ubuntu; the DPDK enabled binary
supports all of the things that the vanilla binary does + DPDK.


>  If yes, how to create a VXLAN network with regular OVS and another
> FLAT/VLAN network with OVS+DPDK ?
>

Not sure whether a mixed mode openvswitch deployment is possible on a
single compute node - I can see how to switch between netdev and system
based bridges in the agent configuration, but that applies at the agent
level, not to specific bridges.

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] [puppet] [ansible] [docs] Packaging changes about to land for Ubuntu + Neutron/Mitaka

[James Page]

Hi Folks

We're about to push the next set of updates into the mitaka-proposed area
of the Ubuntu Cloud Archive; these include changes to three neutron agent
packages which will have impact on end-users and documentation as well as
puppet modules, ansible playbooks, chef cookbooks etc...

1) Package renames

neutron-plugin-openvswitch-agent -> neutron-openvswitch-agent
neutron-plugin-linuxbridge-agent -> neutron-linuxbridge-agent
neutron-plugin-sriov-agent -> neutron-sriov-agent

Transitional packages are included for upgrades (so the old package names
will still work), but the name of each service no longer includes '-plugin'.

https://bugs.launchpad.net/bugs/1548244
https://bugs.launchpad.net/bugs/1321257

2) Dropping of ml2_conf.ini on config-file path for agents

Last cycle we included both the ml2_conf.ini and associate agent ini file
for each daemon as startup arguments to help upgraders deal with the
transition to agent ini files; ml2_conf.ini has now been dropped.

https://bugs.launchpad.net/bugs/1527005

Regards

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] [networking-ovs-dpdk]

[James Page]

Hi All

Reading through this thread I thought participants might be interested to
know that Ubuntu now provides a DPDK enabled Open vSwitch package in Ubuntu
15.10 and for Ubuntu 14.04 using the Liberty UCA; you can use it as follows:

   sudo add-apt-repository cloud-archive:liberty  # not required for 15.10
   sudo apt-get update
   sudo apt-get install openvswitch-switch-dpdk
   sudo update-alternatives --set
ovs-vswitchd /usr/lib/openvswitch-switch-dpdk/ovs-vswitchd-dpdk
   sudo service openvswitch-switch restart

DPDK configuration is passed through OVS using
/etc/default/openvswitch-switch (read for details).  The dpdk package also
provides some basic configuration mechanisms for hugepages and binding
networking adapters to userspace in /etc/dpdk.

This is a first packaging release and is experimental - please do provide
feedback on what you do and don't like about it...

On Wed, Nov 18, 2015 at 6:12 AM, Prathyusha Guduri <
prathyushaconne...@gmail.com> wrote:

> Thanks a lot Sean, that was helpful.
>
> Changing the target from ivshmem to native-linuxapp removed the error and
> it doesn't hang at creating external bridge anymore.
> All processes(nova-api, neutron, ovs-vswitchd, etc) did start.
>
> Thanks,
> Prathyusha
>
> On Tue, Nov 17, 2015 at 7:57 PM, Mooney, Sean K 
> wrote:
>
>> We mainly test with 2M hugepages not 1G however our ci does use 1G pages.
>>
>> We recently noticed a different but unrelated related issue with using
>> the ivshmem target when building dpdk.
>>
>> (https://bugs.launchpad.net/networking-ovs-dpdk/+bug/1517032)
>>
>>
>>
>> Instead of modifying dpdk can you try
>>
>> Changing the default dpdk build target to x86_64-native-linuxapp-gcc.
>>
>>
>>
>> This can be done by  adding
>>
>>
>>
>> RTE_TARGET=x86_64-native-linuxapp-gcc to the local.conf
>>
>> And removing the following file to force a rebuild
>> “/opt/stack/ovs/BUILD_COMPLETE”
>>
>>
>>
>> I agree with your assessment though this appears to be a timing issue in
>> dpdk 2.0
>>
>>
>>
>>
>>
>>
>>
>> *From:* Prathyusha Guduri [mailto:prathyushaconne...@gmail.com]
>> *Sent:* Tuesday, November 17, 2015 1:42 PM
>> *To:* OpenStack Development Mailing List (not for usage questions)
>> *Subject:* Re: [openstack-dev] [networking-ovs-dpdk]
>>
>>
>>
>> Here is stack.sh log -
>>
>>
>> 2015-11-17 13:38:50.010 | Loading uio module
>> 2015-11-17 13:38:50.028 | Loading DPDK UIO module
>> 2015-11-17 13:38:50.038 | starting ovs db
>> 2015-11-17 13:38:50.038 | binding nics
>> 2015-11-17 13:38:50.039 | starting vswitchd
>> 2015-11-17 13:38:50.190 | sudo RTE_SDK=/opt/stack/DPDK-v2.0.0
>> RTE_TARGET=build /opt/stack/DPDK-v2.0.0/tools/dpdk_nic_bind.py -b igb_uio
>> :07:00.0
>> 2015-11-17 13:38:50.527 | sudo ovs-vsctl --no-wait --may-exist add-port
>> br-eth1 dpdk0 -- set Interface dpdk0 type=dpdk
>> 2015-11-17 13:38:51.671 | Waiting for ovs-vswitchd to start...
>> 2015-11-17 13:38:52.685 | Waiting for ovs-vswitchd to start...
>> 2015-11-17 13:38:53.702 | Waiting for ovs-vswitchd to start...
>> 2015-11-17 13:38:54.720 | Waiting for ovs-vswitchd to start...
>> 2015-11-17 13:38:55.733 | Waiting for ovs-vswitchd to start...
>> 2015-11-17 13:38:56.749 | Waiting for ovs-vswitchd to start...
>> 2015-11-17 13:38:57.768 | Waiting for ovs-vswitchd to start...
>> 2015-11-17 13:38:58.787 | Waiting for ovs-vswitchd to start...
>> 2015-11-17 13:38:59.802 | Waiting for ovs-vswitchd to start...
>> 2015-11-17 13:39:00.818 | Waiting for ovs-vswitchd to start...
>> 2015-11-17 13:39:01.836 | Waiting for ovs-vswitchd to start...
>> 2015-11-17 13:39:02.849 | Waiting for ovs-vswitchd to start...
>> 2015-11-17 13:39:03.866 | Waiting for ovs-vswitchd to start...
>> 2015-11-17 13:39:04.884 | Waiting for ovs-vswitchd to start...
>> 2015-11-17 13:39:05.905 | Waiting for ovs-vswitchd to start...
>> 2015-11-17 13:39:06.923 | Waiting for ovs-vswitchd to start...
>> 2015-11-17 13:39:07.937 | Waiting for ovs-vswitchd to start...
>> 2015-11-17 13:39:08.956 | Waiting for ovs-vswitchd to start...
>> 2015-11-17 13:39:09.973 | Waiting for ovs-vswitchd to start...
>> 2015-11-17 13:39:10.988 | Waiting for ovs-vswitchd to start...
>> 2015-11-17 13:39:12.004 | Waiting for ovs-vswitchd to start...
>> 2015-11-17 13:39:13.022 | Waiting for ovs-vswitchd to start...
>> 2015-11-17 13:39:14.040 | Waiting for ovs-vswitchd to start...
>> 2015-11-17 13:39:15.060 | Waiting for ovs-vswitchd to start...
>> 2015-11-17 13:39:16.073 | Waiting for ovs-vswitchd to start...
>> 2015-11-17 13:39:17.089 | Waiting for ovs-vswitchd to start...
>> 2015-11-17 13:39:18.108 | Waiting for ovs-vswitchd to start...
>> 2015-11-17 13:39:19.121 | Waiting for ovs-vswitchd to start...
>> 2015-11-17 13:39:20.138 | Waiting for ovs-vswitchd to start...
>> 2015-11-17 13:39:21.156 | Waiting for ovs-vswitchd to start...
>> 2015-11-17 13:39:22.169 | Waiting for ovs-vswitchd to start...
>> 2015-11-17 13:39:23.185 | Waiting for ovs-vswitchd to start...
>>
>>
>>
>> On Tue, Nov 17, 2015 at 6:50 PM, 

Re: [openstack-dev] [nova][infra] Getting a bleeding edge libvirt gate job running

[James Page]

Hi Markus

On Tue, Nov 17, 2015 at 7:10 PM, Markus Zoeller  wrote:

> Background
> ==
> The blueprint [1] wants to utilize the *virtlogd* logging deamon from
> libvirt. Among others to solve bug [2], one of our oldest ones. The
> funny part is, that this libvirt feature is still in development. This
> was a trigger to see if we can create a gate job which utilizes the
> latest, bleeding edge, version of libvirt to test such features. We
> discussed it shortly in IRC [3] (tonyb, bauzas, markus_z) and wanted to
> get some feedback here. The summary of the idea is:
> * Create a custom repo which contains the latest libvirt version
> * Enhance Devstack so that it can point to a custom repo to install
>   the built libvirt packages
> * Have a nodepool image which is compatible with the libvirt packages
> * In case of [1]: check if tempest needs further/changed tests
>
> Open questions
> ==
> * Is already someone working on something like that and I missed it?
> * If 'no', is there already a repo which contains the very latest
>   libvirt builds which we can utilize?
>

What are your requirements for libvirt and qemu?  The Liberty UCA for
Ubuntu has the following versions:

  libvirt: 1.2.16
  qemu: 2.3

if that's useful these can be added to any Ubuntu 14.04 system using:

  sudo add-apt-repository cloud-archive:liberty

versions will be updated during Xenial development to later releases which
will be backported to 14.04 as part of the Mitaka UCA.
__
OpenStack Development Mailing 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] [networking-ovs-dpdk]

[James Page]

Hi Sean

On Wed, Nov 18, 2015 at 12:30 PM, Mooney, Sean K 
wrote:

> Hi james
>
> Yes we are planning on testing the packaged release to see if it is
> compatible with our ml2 driver and the
>
> Changes we are submitting upstream. If it is we will add a use binary flag
> to our devstack plugin to skip the
>
> Compilation step and use that instead on 15.10 or 14.04
> cloud-archive:liberty
>

Excellent.


> As part of your packaging did ye fix pciutils to correctly report the
> unused drivers when an interface is bound
>
> The dpdk driver? Also does it support both igb_uio and/or vfio-pci drivers
> for dpdk interface?
>

Re pcituils, we've not done any work in that area - can you give an example
of what you would expect?

The dpdk package supports both driver types in /etc/dpdk/interfaces - when
you declare an adapter for use, you get to specify the module you want to
use as well; we're relying the in-tree kernel drivers (uio-pci-generic and
vfio-pci) right now.


>
>
> Anyway yes I hope to check it out and seeing what ye have done. When
> ovs-dpdk starts getting packaged in more operating systems
>
> We will probably swap our default to the binary install though we will
> keep the source install option as it allows us to work on new features
>
> Before they are packaged and to have better performance.
>

That sounds sensible; re 'better performance' - yeah we do have to baseline
the optimizations at compile time right now (ssse3 only right now) , but I
really hope that does change so that we can move to a runtime CPU feature
detection model, allowing the best possible performance through the
packages we have in Ubuntu (or any other distribution for that matter).
__
OpenStack Development Mailing 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] OpenStack Liberty RC1 for Ubuntu 14.04 LTS and Ubuntu 15.10

[James Page]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi All

The Ubuntu OpenStack Engineering team is pleased to announce the
general availability of the first release candidates for the OpenStack
Liberty release in Ubuntu 15.10 development and for Ubuntu 14.04 LTS
via the Ubuntu Cloud Archive.

Further release candidates will be pushed to the archives as and when
they appear.

Ubuntu 14.04 LTS
- 

You can enable the Ubuntu Cloud Archive for OpenStack Liberty on
Ubuntu 14.04 installations by running the following commands (make
sure you have an up-to-date software-properties-common package first):

  sudo add-apt-repository cloud-archive:liberty
  sudo apt-get update

The Ubuntu Cloud Archive for Liberty includes updates for Nova,
Glance, Keystone, Neutron, Cinder, Swift, Horizon, Ceilometer, Heat,
Designate, Barbican, Manila, Ironic, Trove and Sahara; Ceph (0.94.3),
RabbitMQ (3.5.4), QEMU (2.3), libvirt (1.2.16) and OpenvSwitch (2.4.0)
backports from Ubuntu 15.10 development have also been provided.

You can checkout the full list of packages and versions at [0].

Ubuntu 15.10 (Wily) development
- ---

No extra steps required; just start installing OpenStack!

Reporting bugs
- --

Any issues please report bugs using the 'ubuntu-bug' tool:

  sudo ubuntu-bug nova-conductor

this will ensure that bugs get logged in the right place in Launchpad
- - and come poke any of my team (zul, coreycb, gnuoy, thedac, ddellav
or beisner) in #ubuntu-server if something is particularly annoying or
broken…

Finally - thank you to everyone who’s made OpenStack Liberty RC1 a
reality - and have fun!

Cheers

James

[0]
http://reqorts.qa.ubuntu.com/reports/ubuntu-server/cloud-archive/liberty
_versions.html

- -- 
James Page
Ubuntu and Debian Developer
james.p...@ubuntu.com
jamesp...@debian.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWDm1kAAoJEL/srsug59jDDO8QAIiv82Z7MiOdssAiN1jktbCE
6etKZE4mM2CqF91t1NYDNkjGbQvEYfFI1PpNrSd0HmLuybkMR0XEQj07oPhTgdJd
HUFvXwJBPzsPa2mBer5WylQz4RAuVBfdIanjvgAa4My/SvoLFDFjeSqXj0sYSBgC
VyGPdpk6c5NwkzaxsAYL7TB/BWGFzDWeht9YF4wNyvxzGQOhyMkxRvQ2VMRUMxHt
6z8iR+vSENoHzrV0UPt4wTG8L51ZkXv+TaC8pXZTEtSWTGjaOxEa0YMjX5I/bNwX
y3VkuOmoXn+6lshBNJrri8Mr/KtwrWAZ/+UnwT8GmwbPVQ49tdCd0hFC5LRBC7cR
fneEcGBcOxJ4ftzJP5HOz3ZnFH7szvSAfmPrdDCDvuN0bpCHuCbi6dPAjse3MqVp
LIKNWPSD1BEzPUONF4y+/9iIpEEPHt6ehxBu/i9i0fLt4/KYd51GuR+rl/ZvQjn4
G2tnTEuKn+2znT2D+Y2LyQgEZlIThewZJFUuTq5s+B3KhZ0orCuvRvY0qJMyHS0A
TA1XGxTEOp5DZVzVy0/rCyp5V316u//a4lSPHuP+1aneV2q7T3CkafjgNScG/P8h
wAg0clhe5vWeMMDlgooBEsOYak+AFObdtojpDTaVmtfEbUbwpRZ77/SnhWm7pBlA
M8C8gWQojDXLHD7Cox1s
=CPST
-END PGP SIGNATURE-

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

Re: [openstack-dev] Debian already using Python 3.5: please gate on that

[James Page]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 18/06/15 21:44, Jeremy Stanley wrote:
 Based on that, I am confident in sticking with our plan of gating
 using
 3.4 for now and keeping an eye on the 3.5 packages being built
 by Debian and Canonical.
 Unless we shift platforms and go back to special-casing Py3K jobs,
 I expect to see us testing the N release cycle on Python 3.5 in
 Ubuntu 16.04 LTS but probably not prior unless someone steps up to
 make it happen differently.

That sounds reasonable to me; I spoke with the Python maintainers in
our Foundations teams (one of whom also maintains Python in Debian)
and the expectation is that they will start doing working this cycle
(15.10) but I think its realistic that 16.04 would be the target for a
default python 3 switch.

As Thomas points out, we have 3.5 in Debian experimental and Ubuntu
Wily; at some point in time, Debian/Ubuntu will start doing rebuild
testing with these newer versions - we'll feed any bugs/fixes back
upstream so hopefully when we get to the 16.04/3.5 testing enablement,
it will all *just work*.

- -- 
James Page
Ubuntu and Debian Developer
james.p...@ubuntu.com
jamesp...@debian.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJVhBq5AAoJEL/srsug59jDnQ8P/RMbWz2goTHrWZA/+yzpwtPG
GucjSbG8YIPfJFWiAnyOaW3eh+XMrisFvS2QFn+7VBPhrJYZiiTBXAU8rAGZ7sgS
q2EGmgzkFXLt/Zsw6ej/3E7cZFTqDOB8mT/9cqvxjsLSZ9ulaOEh02BUJJz+Idez
FwEUY9Y0mYmzMLgGQpvDGGox9JlnwzhS4EbSKIafE4+8fzscnyWbVYvnpCXm4Rkb
jVupr4isdvdOK/oKog/1CgnjU1WFkBIJxMSl2X7aoSt9gAp4u+6sAVdON50hL6JQ
/TEbJIHahtSskmvzw0HMhdYr3XrkVf92RvqGXsbH2Ce/UoMCocqxqedQ8sp0R98u
inICxqCoEdjQYMFUJ8QsaYQXaMuQNkKdKYzTPInNCFKxsIqyuDSzJAEe/EyfgRuD
Yyt76eEbRoFBtVGCcMbEGby/AAbkMWdRx7hmFpHDLh7VKbTTDwtB83+3qppx5Mia
Tz1MTxtd9ggAf/PDRJmbr3y51FXbx4J8e4DNJXI3DNG7Lqakmhx7c8lf7n2tyfBb
EBckPcGGEGc5cisVLBdrmVlREVNVM2gTb9Z5Is/Lqgm0n336/fTOmFcduA/litBK
EbyYERjhCPuCHPCEF/jYVCzTREJM/S/2Vm5hraVjDaMYqu6O9gysze2pkTuP4L51
Ew8I7sRfTKrLdZFzeU/x
=8N/+
-END 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