Re: [openstack-dev] [tripleo] Proposing Bob Fournier as core reviewer

[Brent Eagles]

+1

Cheers,
Brent

On Mon, Oct 22, 2018 at 7:06 AM Saravanan KR  wrote:

> +1
>
> Regards,
> Saravanan KR
> On Fri, Oct 19, 2018 at 5:53 PM Juan Antonio Osorio Robles
>  wrote:
> >
> > Hello!
> >
> >
> > I would like to propose Bob Fournier (bfournie) as a core reviewer in
> > TripleO. His patches and reviews have spanned quite a wide range in our
> > project, his reviews show great insight and quality and I think he would
> > be a addition to the core team.
> >
> > What do you folks think?
> >
> >
> > Best Regards
> >
> >
> >
> >
> __
> > OpenStack Development Mailing 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] [tripleo] Proposing Marius Cornea core on upgrade bits

[Brent Eagles]

+1 !!!

On Fri, Apr 20, 2018 at 9:42 AM, Brad P. Crochet  wrote:

> +1 from me!
>
> On Fri, Apr 20, 2018 at 8:04 AM Yolanda Robla Mota 
> wrote:
>
>> +1, Marius has been a great help
>>
>> On Thu, Apr 19, 2018 at 7:01 PM, Emilien Macchi 
>> wrote:
>>
>>> Greetings,
>>>
>>> As you probably know mcornea on IRC, Marius Cornea has been contributing
>>> on TripleO for a while, specially on the upgrade bits.
>>> Part of the quality team, he's always testing real customer scenarios
>>> and brings a lot of good feedback in his reviews, and quite often takes
>>> care of fixing complex bugs when it comes to advanced upgrades scenarios.
>>> He's very involved in tripleo-upgrade repository where he's already
>>> core, but I think it's time to let him +2 on other tripleo repos for the
>>> patches related to upgrades (we trust people's judgement for reviews).
>>>
>>> As usual, we'll vote!
>>>
>>> Thanks everyone for your feedback and thanks Marius for your hard work
>>> and involvement in the project.
>>> --
>>> Emilien Macchi
>>>
>>> 
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
>>> unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>>
>> --
>>
>> Yolanda Robla Mota
>>
>> Principal Software Engineer, RHCE
>>
>> Red Hat
>>
>> 
>>
>> C/Avellana 213
>>
>> Urb Portugal
>>
>> yrobl...@redhat.comM: +34605641639
>> 
>> 
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
>> unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
> --
> Brad P. Crochet, RHCA, RHCE, RHCVA, RHCDS
> Principal Software Engineer
> (c) 704.236.9385
>
>
> __
> OpenStack Development Mailing 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] [tripleo] [neutron] Current containerized neutron agents introduce a significant regression in the dataplane

[Brent Eagles]

Hi,

The neutron agents are implemented in such a way that key functionality is
implemented in terms of haproxy, dnsmasq, keepalived and radvd
configuration. The agents manage instances of these services but, by
design, the parent is the top-most (pid 1).

On baremetal this has the advantage that, while control plane changes
cannot be made while the agents are not available, the configuration at the
time the agents were stopped will work (for example, VMs that are restarted
can request their IPs, etc). In short, the dataplane is not affected by
shutting down the agents.

In the TripleO containerized version of these agents, the supporting
processes (haproxy, dnsmasq, etc.) are run within the agent's container so
when the container is stopped, the supporting processes are also stopped.
That is, the behavior with the current containers is significantly
different than on baremetal and stopping/restarting containers effectively
breaks the dataplane. At the moment this is being considered a blocker and
unless we can find a resolution, we may need to recommend running the L3,
DHCP and metadata agents on baremetal.

Cheers,

Brent Eagles
Daniel Alvarez
__
OpenStack Development Mailing 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] Nominate chem and matbu for tripleo-core !

[Brent Eagles]

On Thu, Nov 9, 2017 at 5:14 AM, Marios Andreou  wrote:

> Hello fellow owls,
>
> I would like to nominate (and imo these are both long overdue already):
>
> Sofer Athlan Guyot (chem)  and
>
> Mathieu Bultel (matbu)
>
> to tripleo-core. They have both made many many core contributions to the
> upgrades & updates over the last 3 cycles touching many of the tripleo
> repos (tripleo-heat-templates, tripleo-common, python-tripleoclient,
> tripleo-ci, tripleo-docs and others tripleo-quickstart/extras too unless am
> mistaken).
>
> IMO their efforts and contributions are invaluable for the upgrades squad
> (and beyond - see openstack overcloud config download for example) and we
> will be very lucky to have them as fully voting cores.
>
> Please vote with +1 or -1 for either or both chem and matbu - I'll keep it
> open for a week as customary,
>
> thank you,
>
> marios
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
​+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] [tripleo] Proposing John Fulton core on TripleO

[Brent Eagles]

On Wed, Nov 8, 2017 at 6:54 PM, Giulio Fidente  wrote:

> Hi,
>
> I would like to propose John Fulton core on TripleO.
>
> I think John did an awesome work during the Pike cycle around the
> integration of ceph-ansible as a replacement for puppet-ceph, for the
> deployment of Ceph in containers.
>
> I think John has good understanding of many different parts of TripleO
> given that the ceph-ansible integration has been a complicated effort
> involving changes in heat/tht/mistral workflows/ci and last but not
> least, docs and he is more recently getting busier with reviews outside
> his main comfort zone.
>
> I am sure John would be a great addition to the team and I welcome him
> first to tune into radioparadise with the rest of us when joining #tripleo
>
> Feedback is welcomed!
> --
> Giulio Fidente
> GPG KEY: 08D733BA
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

​+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] [tripleo][networking] Organizing the networking squad

[Brent Eagles]

On Mon, Oct 16, 2017 at 2:44 PM, Harald Jensas <hjen...@redhat.com> wrote:

> Include me as well Brent.
>
>
> //
> Harald
>
> On 16 Oct 2017 3:41 p.m., "Saravanan KR" <skram...@redhat.com> wrote:
>
> Thanks for initiating Brent. Yes, I would participate in the networking
> squad.
>
> Regards,
> Saravanan KR
>
> On Mon, Oct 16, 2017 at 6:43 PM, Brent Eagles <beag...@redhat.com> wrote:
> > Hi,
> >
> > On Tue, Oct 10, 2017 at 10:55 AM, Brent Eagles <beag...@redhat.com>
> wrote:
> >>
> >> Hi all,
> >>
> >> The list of TripleO squads includes a "networking squad". In previous
> >> cycles, coordinating outside of IRC and email conversations seemed
> >> unnecessary as there were only a few contributors and a small number of
> >> initiatives. However, with future container related work, increased
> usage of
> >> ansible, ongoing efforts like routed networks and NFV, os-net-config
> related
> >> issues, and the increasing number of backends and networking related
> >> services being added to TripleO, the world of TripleO networking seems
> >> increasingly busy. I propose that we start organizing properly with
> periodic
> >> sync-ups and coordinating efforts via etherpad (or similar) as well as
> >> reporting into the weekly tripleo meeting.
> >>
> >> Cheers,
> >>
> >> Brent
> >
> >
> > This was initially not directed at anyone in particular but I've added
> > possible interested parties to this thread in case it gets lost in the
> > noise! Please reply if you are interested in participating in the
> networking
> > squad. Proposed first orders of business are:
> >
> >  - establish the squad's scope
> >  - agree on whether we need a scheduled sync up meeting and if so, sort
> out
> > a meeting time time
> >  - outline initial areas of interest and concern and action items
> >
> > Cheers,
> >
> > Brent
>
>
​Thanks for the replies everyone!​

The squad has a status etherpad! See
https://etherpad.openstack.org/p/tripleo-networking-squad-status. It is
very sparse for now as we are just getting organized, but I've added a
visually grepped list of blueprints that seem likely related as an
illustration of just how much is planned or underway!

I'll be reaching out to you all over the next few days to try and
coordinate a meeting time. As always, timezones may prove a challenge but
we should be able to sort something out.

Thanks again for your interest and participation!

Cheers,

Brent
__
OpenStack Development Mailing 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] [tripleo][networking] Organizing the networking squad

[Brent Eagles]

​Hi,​

On Tue, Oct 10, 2017 at 10:55 AM, Brent Eagles <beag...@redhat.com> wrote:

> Hi all,
>
> The list of TripleO squads includes a "networking squad". In previous
> cycles, coordinating outside of IRC and email conversations seemed
> unnecessary as there were only a few contributors and a small number of
> initiatives. However, with future container related work, increased usage
> of ansible, ongoing efforts like routed networks and NFV, os-net-config
> related issues, and the increasing number of backends and networking
> related services being added to TripleO, the world of TripleO networking
> seems increasingly busy. I propose that we start organizing properly with
> periodic sync-ups and coordinating efforts via etherpad (or similar) as
> well as reporting into the weekly tripleo meeting.
>
> Cheers,
>
> Brent
>

This was initially not directed at anyone in particular but I've added
possible interested parties to this thread in case it gets lost in the
noise! Please reply if you are interested in participating in the
networking squad. Proposed first orders of business are:

 - establish the squad's scope
 - agree on whether we need a scheduled sync up meeting and if so, sort out
a meeting time time
 - outline initial areas of interest and concern and action items

Cheers,

Brent
__
OpenStack Development Mailing 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] [tripleo][networking] Organizing the networking squad

[Brent Eagles]

Hi all,

The list of TripleO squads includes a "networking squad". In previous
cycles, coordinating outside of IRC and email conversations seemed
unnecessary as there were only a few contributors and a small number of
initiatives. However, with future container related work, increased usage
of ansible, ongoing efforts like routed networks and NFV, os-net-config
related issues, and the increasing number of backends and networking
related services being added to TripleO, the world of TripleO networking
seems increasingly busy. I propose that we start organizing properly with
periodic sync-ups and coordinating efforts via etherpad (or similar) as
well as reporting into the weekly tripleo meeting.

Cheers,

Brent
__
OpenStack Development Mailing 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] [tripleo] Proposing Saravanan KR core

[Brent Eagles]

On Fri, Jul 21, 2017 at 12:31 PM, Emilien Macchi  wrote:

> Saravanan KR has shown an high level of expertise in some areas of
> TripleO, and also increased his involvement over the last months:
> - Major contributor in DPDK integration
> - Derived parameter works
> - and a lot of other things like improving UX and enabling new
> features to improve performances and networking configurations.
>
> I would like to propose Saravanan part of TripleO core and we expect
> his particular focus on t-h-t, os-net-config and tripleoclient for now
> but we hope to extend it later.
>
> As usual, we'll vote :-)
> Thanks,
> --
> Emilien Macchi
>
>
​+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] [tripleo] Proposing Bogdan Dobrelya core on TripleO / Containers

[Brent Eagles]

On Fri, Jul 21, 2017 at 12:25 PM, Emilien Macchi  wrote:

> Hi,
>
> Bogdan (bogdando on IRC) has been very active in Containerization of
> TripleO and his quality of review has increased over time.
> I would like to give him core permissions on container work in TripleO.
> Any feedback is welcome as usual, we'll vote as a team.
>
> Thanks,
> --
> Emilien Macchi
>

​+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] [tripleo] weekly meetings on #tripleo

[Brent Eagles]

+1 for giving it a try.

On Wed, Jul 5, 2017 at 2:26 PM, Emilien Macchi  wrote:

> After reading http://lists.openstack.org/pipermail/openstack-dev/2017-
> June/118899.html
> - we might want to collect TripleO's community feedback on doing
> weekly meetings on #tripleo instead of #openstack-meeting-alt.
>
> I see some direct benefits:
> - if you come up late in meetings, you could easily read backlog in
> #tripleo
> - newcomers not aware about the meeting channel wouldn't have to search
> for it
> - meeting would maybe get more activity and we would expose the
> information more broadly
>
> Any feedback on this proposal is welcome before we make any change (or
> not).
>
> Thanks,
> --
> Emilien Macchi
>
> __
> OpenStack Development Mailing 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] [tripleo] proposing Alex Schultz tripleo-core in all projects

[Brent Eagles]

On Fri, Jul 7, 2017 at 3:09 PM, Emilien Macchi  wrote:

> Alex has demonstrated high technical and community skills in TripleO -
> where he's already core on THT, instack-undercloud, and puppet-tripleo
> - but also very involved in other repos.
> I propose that we extend his core status to all TripleO projects and
> of course trust him (like we trust all core members) to review patches
> were we feel confortable with.
>
> He has shown an high interest in reviewed other TripleO projects and I
> think he would be ready for this change.
> As usual, this is an open proposal, any feedback is welcome.
>
> Thanks,
> --
> Emilien Macchi
>
>
​+1. Yes, please!​
__
OpenStack Development Mailing 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] [TripleO] Propose Attila Darazs and Gabriele Cerami for tripleo-ci core

[Brent Eagles]

On Wed, Mar 15, 2017 at 1:14 PM, John Trowbridge  wrote:

> Both Attila and Gabriele have been rockstars with the work to transition
> tripleo-ci to run via quickstart, and both have become extremely
> knowledgeable about how tripleo-ci works during that process. They are
> both very capable of providing thorough and thoughtful reviews of
> tripleo-ci patches.
>
> On top of this Attila has greatly increased the communication from the
> tripleo-ci squad as the liason, with weekly summary emails of our
> meetings to this list.
>
> - trown
>

​+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] [tripleo] propose Alex Schultz core on tripleo-heat-templates

[Brent Eagles]

On Mon, Mar 13, 2017 at 12:00 PM, Emilien Macchi  wrote:

> Hi,
>
> Alex is already core on instack-undercloud and puppet-tripleo.
> His involvement and knowledge in TripleO Heat Templates has been very
> appreciated over the last months and I think we can give him +2 on
> this project.
>
> As usual, feel free to vote -1/+1 on this proposal.
>
> Thanks,
> --
> Emilien Macchi
> ​
>

​+1 indeed.​
__
OpenStack Development Mailing 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] [tripleo] Fwd: TripleO mascot - how can I help your team?

[Brent Eagles]

Hi all,

Not that it matters one way or the other, Carlos's comment reminded me of
some trivia regarding owl eye color that I had read recently:

https://owlpedia.wordpress.com/2015/08/06/why-do-owls-have-different-colour-eyes/

On Mon, Mar 13, 2017 at 6:16 AM, Carlos Camacho Gonzalez <
ccama...@redhat.com> wrote:

> Hey!
>
> Yeahp I think most owls have yellow/orange eyes, this can be a good thing
> to try.
>
> Cheers,
> Carlos
>
> On Fri, Mar 10, 2017 at 8:53 PM, Dan Sneddon  wrote:
>
>> On 03/10/2017 08:26 AM, Heidi Joy Tretheway wrote:
>> > Hi TripleO team,
>> >
>> > Here’s an update on your project logo. Our illustrator tried to be as
>> > true as possible to your original, while ensuring it matched the line
>> > weight, color palette and style of the rest. We also worked to make sure
>> > that three Os in the logo are preserved. Thanks for your patience as we
>> > worked on this! Feel free to direct feedback to me.
>> >
>> >
>> > 
>> __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe: openstack-dev-requ...@lists.op
>> enstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>>
>> This is a huge improvement! Some of the previous drafts looked more like
>> a generic bird and less like an owl.
>>
>> I have a suggestion on how this might be more owl-like. If you look at
>> real owl faces [1], you will see that their eyes are typically yellow,
>> and they often have a white circle around the eyes (black pupil, yellow
>> eye, black/white circle of feathers). I think that we could add a yellow
>> ring around the black pupil, and possibly accentuate the ears (since
>> owls often have white tufts on their ears).
>>
>> I whipped up a quick example of what I'm talking about, it's attached
>> (hopefully it will survive the mailing list).
>>
>> [1] - https://www.google.com/search?q=owl+face=isch=u=univ
>>
>> --
>> Dan Sneddon |  Senior Principal OpenStack Engineer
>> dsned...@redhat.com |  redhat.com/openstack
>> dsneddon:irc|  @dxs:twitter
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing 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] [tripleo] Fwd: TripleO mascot - how can I help your team?

[Brent Eagles]

On Fri, Mar 10, 2017 at 12:56 PM, Heidi Joy Tretheway <
heidi...@openstack.org> wrote:

> Hi TripleO team,
>
> Here’s an update on your project logo. Our illustrator tried to be as true
> as possible to your original, while ensuring it matched the line weight,
> color palette and style of the rest. We also worked to make sure that three
> Os in the logo are preserved. Thanks for your patience as we worked on
> this! Feel free to direct feedback to me.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
Nice! It feels like a refinement, not a departure.

Cheers,

Brent
__
OpenStack Development Mailing 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] [tripleo] Fwd: TripleO mascot - how can I help your team?

[Brent Eagles]

Hi,

FWIW, I prefer the existing logo. There are several valid practical reasons
why it would be good to keep it, but I also just like it better.

On Mon, Feb 13, 2017 at 11:08 PM, Emilien Macchi  wrote:

> Team, I've got this email from Heidi.
>
> I see 3 options :
>
> 1. Keep existing logo: http://tripleo.org/_static/tripleo_owl.svg .
>
> 2. Re-design a new logo that "meets" OpenStack "requirements".
>
> 3. Pick-up the one proposed (see below).
>
>
> Personally, I would vote for keeping our existing logo (1.) unless someone
> has time to create another one or if the team likes the proposed one.
>
> The reason why I want to keep our logo is because our current logo was
> created by TripleO devs, we like it and we already have tee-shirts and
> other goodies with it. I don't see any good reason to change it.
>
> Discussion is open and we'll vote as a team.
>
> Thanks,
>
> Emilien.
>
> -- Forwarded message --
> From: Heidi Joy Tretheway 
> Date: Mon, Feb 13, 2017 at 8:27 PM
> Subject: TripleO mascot - how can I help your team?
> To: Emilien Macchi 
>
>
> Hi Emilien,
>
> I’m following up on the much-debated TripleO logo. I’d like to help your
> team reach a solution that makes them happy but still fits within the
> family of logos we’re using at the PTG and going forward. Here’s what our
> illustrators came up with, which hides an “O” shape in the owl (face and
> wing arcs).
>
> https://www.dropbox.com/sh/qz45miiiam3caiy/AAAzPGYEZRMGH6Otid3bLfHFa?dl=0
> At this point, I don’t have quorum from your team (I got a lot of
> conflicting feedback, most of which was “don’t like” but not actionable for
> the illustrators to make a revision). At the PTG, we’ll have mascot
> stickers and signage for all teams except for Ironic and TripleO, since
> we’re still waiting on your teams to make a final decision.
>
> May I recommend that your team choose one person (or a small group of no
> more than three) to finalize this? I was able to work through all of
> Swift’s issues with just a quick 15-minute chat with John Dickinson and I’d
> like to believe we can solve this for TripleO as well.
>
> We know some of your team has expressed concern over retiring the existing
> mascot. It’s not our intention to make anyone “get rid of” a beloved icon.
> Your team can certainly print it on vintage items like shirts and stickers.
> But for official channels like the website, we need a logo to represent
> TripleO that’s cohesive with the rest of the set.
>
> Perhaps when you’re face to face with your team at the PTG, you can
> discuss and hopefully render a final decision to either accept this as a
> logo, or determine a few people willing to make any final changes with me?
>
> Thanks in advance for your help!
>
>
> [image: photo]
> *Heidi Joy Tretheway*
> Senior Marketing Manager, OpenStack Foundation
> 503 816 9769 | Skype: heidi.tretheway
> 
> 
>   
>
>
>
>
>
>
> --
> Emilien Macchi
>
> __
> OpenStack Development Mailing 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] [TripleO] Proposing Dmitry Tantsur and Alex Schultz as instack-undercloud cores

[Brent Eagles]

On Tue, Jan 31, 2017 at 12:32 PM, Ben Nemec  wrote:

> In the spirit of all the core team changes, here are a couple more I'd
> like to propose.
>
> Dmitry has been very helpful reviewing in instack-undercloud for a long
> time so this is way overdue.  I'm also going to propose that he be able to
> +2 anything Ironic-related in TripleO since that is his primary area of
> expertise.
>
> Alex has ramped up quickly on TripleO and has also been helping out with
> instack-undercloud quite a bit.  He's already core for the puppet modules,
> and a lot of the changes to instack-undercloud these days are primarily in
> the puppet manifest so it's not a huge stretch to add him.
>
> As usual, TripleO cores please vote and/or provide comments.  Thanks.
>
> -Ben
>
>
​+1!

Cheers,​

Brent
__
OpenStack Development Mailing 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] [tripleo] Feature Freeze Exception request for octavia-services-integration

[Brent Eagles]

Hi,

I'd like to request a feature freeze exception for patches submitted
against the octavia-services-integration blueprint (
https://blueprints.launchpad.net/tripleo/+spec/octavia-service-integration).
The service will not be deployed by default and is not currently part of
scenario testing so should have little impact on other services. Basic
configuration of the services is a first step in preparing for fully
functional Octavia integration (
https://blueprints.launchpad.net/tripleo/+spec/octavia-support) and
production readiness. Also, as a fully functional Octavia deployment
introduces some new issues of what can be done during deployment, having
the basic services easily deployable allows contributors and other
interested parties to better evaluate, discuss, develop and test solutions.

Cheers,

Brent Eagles
__
OpenStack Development Mailing 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] [TripleO] Proposing Sergey (Sagi) Shnaidman for core on tripleo-ci

[Brent Eagles]

On Tue, Jan 24, 2017 at 1:33 PM, Juan Antonio Osorio 
wrote:

> Sagi (sshnaidm on IRC) has done significant work in TripleO CI (both
> on the current CI solution and in getting tripleo-quickstart jobs for
> it); So I would like to propose him as part of the TripleO CI core team.
>
> I think he'll make a great addition to the team and will help move CI
> issues forward quicker.
>
> Best Regards,
>
>
>
> --
> Juan Antonio Osorio R.
> jaosorior
>
>
​+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] [tripleo] Update TripleO core members

[Brent Eagles]

On Mon, Jan 23, 2017 at 3:33 PM, Emilien Macchi  wrote:

> Greeting folks,
>
> I would like to propose some changes in our core members:
>
> - Remove Jay Dobies who has not been active in TripleO for a while
> (thanks Jay for your hard work!).
> - Add Flavio Percoco core on tripleo-common and tripleo-heat-templates
> docker bits.
> - Add Steve Backer on os-collect-config and also docker bits in
> tripleo-common and tripleo-heat-templates.
>
> Indeed, both Flavio and Steve have been involved in deploying TripleO
> in containers, their contributions are very valuable. I would like to
> encourage them to keep doing more reviews in and out container bits.
>
> As usual, core members are welcome to vote on the changes.
>
> Thanks,
> --
> Emilien Macchi
>
>
​+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] [tripleo] Proposing Alex Schultz core on puppet-tripleo

[Brent Eagles]

On Thu, Dec 1, 2016 at 7:03 PM, James Slagle  wrote:

> On Thu, Dec 1, 2016 at 5:26 PM, Emilien Macchi  wrote:
> > Team,
> >
> > Alex Schultz (mwhahaha on IRC) has been active on TripleO since a few
> > months now.  While he's very active in different areas of TripleO, his
> > reviews and contributions on puppet-tripleo have been very useful.
> > Alex is a Puppet guy and also the current PTL of Puppet OpenStack. I
> > think he perfectly understands how puppet-tripleo works. His
> > involvement in the project and contributions on puppet-tripleo deserve
> > that we allow him to +2 puppet-tripleo.
> >
> > Thanks Alex for your involvement and hard work in the project, this is
> > very appreciated!
> >
> > As usual, I'll let the team to vote about this proposal.
>
> +1
>
>
​+1 indeed!​
__
OpenStack Development Mailing 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] [TripleO] Proposing Julie Pichon for tripleo core

[Brent Eagles]

On Tue, Nov 22, 2016 at 1:31 PM, Dougal Matthews  wrote:

> Hi all,
>
> I would like to propose we add Julie (jpich) to the TripleO core team for
> python-tripleoclient and tripleo-common. This nomination is based partially
> on review stats[1] and also my experience with her reviews and
> contributions.
>
> Julie has consistently provided thoughtful and detailed reviews since the
> start of the Newton cycle. She has made a number of contributions which
> improve the CLI and has been extremely helpful with other tasks that don't
> often get enough attention (backports, bug triaging/reporting and improving
> our processes[2]).
>
> I think she will be a valuable addition to the review team
>
> Dougal
>

​+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] [tripleo] Is it time to reconsider how we configure OVS bridges in the overcloud?

[Brent Eagles]

Hi Dan,

On Thu, Nov 10, 2016 at 1:25 PM, Dan Sneddon  wrote:

> ​
>
> Brent,
>
> Thanks for taking the time to analyze this situation. I see a couple of
> potential issues with the topology you are suggesting.
>
> First of all, what about the scenario where a system has only 2x10Gb
> NICs, and the operator wishes to bond these together on a single
> bridge? If we require separate bridges for Neutron than we do for the
> control plane, then it would be impossible to configure a system with
> only 2 NICs in a fault-tolerant way.
>

Unless I'm missing something, I think this would be similar to the single
NIC case. In the case where there is only bond, it would be bridged to the
main overcloud bridge (e.g. br-ctl) and any bridges for external traffic
(e.g. br-ex) would be patched to that. The fault tolerance of the bond
would still be available to all. The cost would be whatever extra overhead
the br-ex->br-ctl patch ports incur.


>
> Second, there will be a large percentage of users who already have a
> shared br-ex that wish to upgrade. Do we tell them that due to an
> architectural change, they now must redeploy a new cloud with a new
> topology to use the latest version?
>

> So while I would be on-board with changing our default for new
> installations, I don't think that relieves us of the responsibility to
> figure out how to handle the edge cases where a separate bridge is not
> feasible.
> ​
>


> --
> Dan Sneddon |  Senior Principal OpenStack Engineer
>
>
​This is a very good and important point. Migration could be a pain. If it
is a bridge that neutron uses, it manipulates them pretty quickly after
startup. However, if an update would only write the ifcfg changes and
require a rebooting for them to take affect, then that might take care of
that. Probably more problematic is the other IPs that are assigned to the
"main" bridge. If it's keying on the bridge name then that becomes a
problem. If it's the IP, then it should follow the bridge. There is also
the danger of any other number of dependencies or tooling that might need
updating. The bright spot is that neutron's config wouldn't actually
change. In short, it would probably be doable, but I find myself feeling
that I wouldn't recommend it unless it was absolutely necessary and/or fit
some kind of scenario that we had worked out was extremely low risk and
tested heavily.

Cheers,

Brent
__
OpenStack Development Mailing 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] [tripleo] possible backports for stable/newton

[Brent Eagles]

Hi Alan,

On Wed, Nov 9, 2016 at 6:10 AM, Alan Pevec  wrote:

> > Since our cherry picks don't seem to be considered equivalents by git
> > (probably because of modified commit messages)
>
> I'd like to understand why is that, do you have an example?
> It should work when recommendation[*] is followed.
>
> Cheers,
> Alan
>

​I was referring to running git log with the --cherry-pick option. e.g. git
log --cherry-pick --no-merge origin/stable/newton..origin/master​

The docs for git imply that if the cherry-picks were equivalent patches
they would be removed from the log. Could be I'm misunderstanding what the
intent of that git feature is. I haven't tested if it does what *I* think
it does with a identical cherry-pick (i.e. no change to the commit message).

Cheers,

Brent
__
OpenStack Development Mailing 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] [tripleo] Is it time to reconsider how we configure OVS bridges in the overcloud?

[Brent Eagles]

Hi all,


A recent critical issue that has come up that has compelled me to propose
reconsidering our default and OVS based network configuration examples :

https://bugs.launchpad.net/tripleo/+bug/1640812 - Network connectivity lost
on node reboot

I've been thinking about it for awhile, but you could say this bug was the
"last straw".

While the precise root cause of this issue is still in question, part of
the problem is that the overcloud nodes communicate with the undercloud and
each other through an OVS bridge which is also used by the overcloud
neutron service for external network traffic. For several valid reasons,
neutron sets the OVS bridge fail_mode to secure (details in respective man
pages, etc, etc). This mode is stored persistently so when the system is
rebooted, the bridge is recreated with the secure fail_mode in place,
blocking network traffic - including DHCP - until something comes along and
starts setting up flow rules to allow traffic to flow.  Without an IP
address, the node is effectively "unplugged". For some reason this isn't
happening 100% of the time on the current version of CentOS (7.2), but
seems to be pretty much 100% on RHEL 7.3.

It raises the question if it is valid for neutron to modify an OVS bridge
that it *did not create* in a fundamental way like this. If so, it implies
a contract between the deployer and neutron that the deployer can make "no
assumptions" about what will happen with the bridge once neutron has been
configured to access it. If this implied contract is valid, required and
acceptable, then bridges used for neutron should not be used for anything
else. The implications with respect to tripleo is that we should reconsider
how we use OVS bridges for network configuration in the overcloud. For
example, in single NIC situations, instead of having:

(triple configured)
- eth0
  - br-ex -used for control plane access, internal api, management,
external, etc. also neutron is configured to use this for the external
traffic e.g. dataplane in our defaults, which is why the fail_mode gets
altered

(neutron configured)

- br-int
- br-tun

To something like:
(triple configured)
- eth0
 - br-ctl - used as br-ex is currently used except neutron knows nothing
about it.
- br-ex -patched to br-ctl - ostensibly for external traffic and this is
what neutron in the overcloud is configured to use
(neutron configured)
- br-int
- br-tun

(In all cases, neutron configures patches, etc. between bridges *it knows
about* as needed. That is, in the second case, tripleo would configure the
patch between br-ctl and br-ex)

At the cost of an extra bridge (ovs bridge to ovs bridge with patch ports
is allegedly cheap btw) we get:
 1. an independently configured bridge for overcloud traffic insulates
non-tenant node traffic against changes to neutron, including upgrades,
neutron bugs, etc.
 2. insulates neutron from changes to the underlying network that it
doesn't "care" about.
 3. In OVS only environments, the difference between a single nic
environment and one where there is a dedicated nic for external traffic is,
instead of a patch port from br-ctl to br-ex, it is directly connected to
the nic for the external traffic.

Even without the issue that instigated this message, I think that this is a
change worth considering.


Cheers,


Brent
__
OpenStack Development Mailing 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] [tripleo] proposing Michele Baldessari part of core team

[Brent Eagles]

On Fri, Nov 4, 2016 at 3:10 PM, Emilien Macchi  wrote:

> MIchele Baldessari (bandini on IRC) has consistently demonstrated high
> levels of contributions in TripleO projects, specifically in High
> Availability area where's he's for us a guru (I still don't understand
> how pacemaker works, but hopefully he does).
>
> He has done incredible work on composable services and also on
> improving our HA configuration by following reference architectures.
> Always here during meetings, and on #tripleo to give support to our
> team, he's a great team player and we are lucky to have him onboard.
> I believe he would be a great core reviewer on HA-related work and we
> expect his review stats to continue improving as his scope broadens
> over time.
>
> As usual, feedback is welcome and please vote for this proposal!
>
> Thanks,
> --
> Emilien Macchi
>
>
​+1 ​indeed
__
OpenStack Development Mailing 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] [tripleo] possible backports for stable/newton

[Brent Eagles]

Hi Michele, vous autres,

On Thu, Nov 3, 2016 at 4:50 AM, Michele Baldessari <mich...@acksyn.org>
wrote:

> Hi Brent ;)
>
> On Thu, Nov 03, 2016 at 01:20:12AM -0230, Brent Eagles wrote:
> > puppet-tripleo
> >
> > https://review.openstack.org/#/c/389583/ Set redis file descriptor limit
> > when run via pacemaker
>
> Yes, this one I will backport this week.
>
> > https://review.openstack.org/#/c/380414/ Only run ceilometer::db::sync
> on
> > bootstrap node
> > https://review.openstack.org/#/c/386042/ pacemaker/mysql: wait step 2 to
> > remove default accounts
> >
> > tripleo-heat-templates
> >
> > https://review.openstack.org/#/c/380979/ Change rabbitmq queues HA mode
> > from ha-all to ha-exactly
>
> We decided against it in the end. We merged it for Ocata and will
> implement it only there (i.e. we thought it was a bit too risky this
> close to the release)
>
> > https://review.openstack.org/#/c/381869/ Include redis/mongo hiera when
> > using pacemaker
> > https://review.openstack.org/#/c/387266/ Enable proxy headers parsing
> for
> > Neutron (not sure about this one... there are similar patches that landed
> > to stable/newton so maybe)
> > https://review.openstack.org/#/c/385058/ Remove duplicate metadata keys
> > from nova-api.yaml (probably not critical - the big related bug was the
> > worker count = 0 thing for nova)
>
> regards,
> Michele
>

​Thanks Michele! With respect to the other patches, I'll set the backports
up and make sure the original authors are added as reviewers. If you feel
they shouldn't be backported, just nix them on gerrit.

Cheers,

Brent​
__
OpenStack Development Mailing 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] [tripleo] possible backports for stable/newton

[Brent Eagles]

Hi all,

​After forgetting to backport something to stable newton (thanks Emilien
and Alex!), I felt it worthwhile to check for patches that may have been
missed. Since our cherry picks don't seem to be considered equivalents by
git (probably because of modified commit messages), I resorted to
cross-checking git logs. That is to say, I may have missed some. While all
of these refer to bugs, not all of these are marked backport potential.
That being said, a few look like backporting might have been intended or
appropriate. If they look familiar, please revisit.
​
puppet-tripleo

https://review.openstack.org/#/c/389583/ Set redis file descriptor limit
when run via pacemaker
https://review.openstack.org/#/c/380414/ Only run ceilometer::db::sync on
bootstrap node
https://review.openstack.org/#/c/386042/ pacemaker/mysql: wait step 2 to
remove default accounts

tripleo-heat-templates

https://review.openstack.org/#/c/372635/ Use correct password for keystone
bootstrap
https://review.openstack.org/#/c/380979/ Change rabbitmq queues HA mode
from ha-all to ha-exactly
​ (this one was abandoned, possibly to deal with a depends-on problem with
patch ordering - afaict the dependency has merged so this could be
'unabandoned')
https://review.openstack.org/#/c/381869/ Include redis/mongo hiera when
using pacemaker
https://review.openstack.org/#/c/387266/ Enable proxy headers parsing for
Neutron (not sure about this one... there are similar patches that landed
to stable/newton so maybe)
https://review.openstack.org/#/c/385058/ Remove duplicate metadata keys
from nova-api.yaml (probably not critical - the big related bug was the
worker count = 0 thing for nova)


Cheers,

Brent
__
OpenStack Development Mailing 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] [tripleo][ci] Temporary increase for the OVB undercloud instance memory

[Brent Eagles]

Hi,

On Thu, Sep 22, 2016 at 1:48 PM, James Slagle 
wrote:

> On Thu, Sep 22, 2016 at 10:36 AM, Gabriele Cerami 
> wrote:
> > Hi,
> >
> > As reported on this bug
> >
> > https://bugs.launchpad.net/tripleo/+bug/1626483
> >
> > HA gate and periodic jobs for master and sometimes newton started to
> > fail for errors related to memory shortage. Memory on undercloud
> > instance was increased to 8G less than a month ago, so the problem
> > needs a different approach to be solved.
> >
> > We have some solutions in store. However, with the release date so
> > close, I don't think it's time for this kind of changes. So I thought
> > it could be a good compromise to temporarily increase the undercloud
> > instance memory to 12G, just for this week, unless there's a rapid way
> > to reduce memory footprint for heat-engine (usually the biggest memory
> > consumer on the undercloud instance)
> >
> > Any other ideas ?
>
> The OOM error in the bug is from overcloud-controller-0, not the
> undercloud. The overcloud nodes in OVB are still at 6GB. I think it
> would be reasonable to increase those to 8GB as well.
>
> I also noticed that there are 4 neutron-server processes despite
> having NeutronWorkers: 1 in
> https://github.com/openstack-infra/tripleo-ci/blob/master/
> test-environments/worker-config.yaml.
> If we can get that down to 1, looks like that might save around 270MB.
>
> It also looks like there are 2 nova-api workers despite having
> NovaWorkers: 1. Is that normal? Getting rid of one of them would save
> around another 140MB.
>
> --
> -- James Slagle
> --


​In the case of neutron and some of the other worker settings, we can try
using 0 instead of 1. ​

​This should prevent the spawning of a separate worker processes for
anything that is going on. IIRC, neutron server itself spawns separate API
and RPC workers.

​FWIW, I don't think '0' works for nova though. I think if you do that it
leaves it unset and it will use the service default.​

Cheers,

Brent
__
OpenStack Development Mailing 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] [tripleo] composable roles team

[Brent Eagles]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 05/01/2016 08:01 PM, Emilien Macchi wrote:



>> If a feature can't land without disruption, then why not using a
>> special branch to be merged once the feature is complete ?
> 
> The problem is that during our work, some people will update the 
> manifests, and it will affect us, since we're copy/pasting the
> code somewhere else (in puppet-tripleo), that's why we might need
> some outstanding help from the team, to converge to the new model. 
> I know asking that is tough, but if we want to converge quickly,
> we need to make the adoption accepted by everyone. One thing we can
> do, is asking our reviewer team to track the patches that will need
> some work, and the composable team can help in the review process.
> 
> The composable roles is a feature that we all wait, having the
> help from our contributors will really save us time.

s/wait/want/ I expect.

Well said. I understand the reservations on the -1 for non-composable
role patches. It *does* feel a bit strong, but in the end I think it's
just being honest. The likelihood that a patch on tht is going to land
"as is" prior to the merge of the related composable role changes
seems really unlikely. I for one, am willing to do what I can to help
anyone who has had their patch pre-empted during this period get their
patch refactored/ported once the comp-roles thing has settled down.

Cheers,

Brent

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJXJ5KpAAoJEIXWptqvFlBWmA8P/1dBlsCNYIqOHBBWxzEnLM41
gP/K+UsGFHaXj86yOdus5gp58/JFX9KJ+mqr0Yi/8ail+h+t0yjgcCXLlp6HUTKo
7OtNfAzPMDeDkquB5R7WREJfLdtP7tVpBsd0Ezs00y5ZDUuDk/J0waleQFtAKUjr
Xiip2y/e8tZMdWa0gvp/q+kWJ3v+YhAnl9PNQMCeIGf/IwDQrTNYvDTIChLx6dud
g7tWfH+ej6nL/ty8UM4R3ac94ZyZLrxprShbdpAh798kYhrR1WPju+hmBgln8rlx
fcTzXq8b428QzCmNKFeKuNmP32yXjOCZlEi2/NijfiR7nFY6sLvh7ROIODiwmzx8
fPSb1W8bLqIijeAUy2YpZFfvbe+NZdn2iIHjseS6Yu4D85NakUunkrBJEpbnCy8L
26N9ShseHbVRckpMSyxEyi+jJfJcCp4FzR26SUFUamPcusMQVlBDQlhOh/8lr/Lq
frhxcYCn45JZ/R2pc3PS2HnRapmvM/TLxdFhbteUFMcEXBT4dvdQPcQdqH1Kx/Yw
S5C+1CESRMGH2KpqghHaMNnySYHFHYQNmCKEVfJjERGbI/U5dEEogIUuzHXHQlYV
kL83XvMh6gGHfRwbmeTOLsrR86c8+u3vaE5PzHPxQ3IBseezmRYiN2fmNclYsg8B
LvyHYCRNvOcj1y8gr0Yr
=obJ6
-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] [Neutron] Newton blueprints call for action

[Brent Eagles]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi Armando,

On 05/04/16 01:13 AM, Armando M. wrote:
> Hi Neutrinos,
> 
> During today's team meeting [0], we went through the current
> milestone workload [1].
> 
> This is mostly made of Mitaka backlog items, amongst which we
> discussed two blueprints [2, 3]. These two efforts had their spec
> approved during the Mitaka timeframe, but code lagged behind, and
> hence got deferred [4].
> 
> I would like to understand if these need new owners (both assignees
> and approvers). Code submitted [5,6] has not been touched in a
> while, and whilst I appreciate people have been busy focussing on
> Mitaka (myself included), the Newton master branch has been open
> for a while.
> 
> With this email I would like to appeal to the people in CC to
> report back their interest in continuing working on these items in
> their respective capacities, and/or the wider community, in case
> new owners need to be identified.
> 
> I look forward to hearing back, hoping we can find the right
> resources to resume progress, and bring these important
> requirements to completion in time for Newton.
> 
> Many thanks, Armando

As it happens, I've been tasked to work on TripleO as a general
contributor with a networking focus. For better or worse, the database
related work was the only thing on my early radar and I will shepherd
that along as needed, but I won't be able to commit to the larger bits
of the remaining work.

While we could wait for summit to hand off, I think it would be better
for someone who is looking to take over ownership of all or some of
the pieces to sync up with Bence, myself, and Songming ASAP.

Cheers,

Brent

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJXBRpyAAoJEIXWptqvFlBWIHgQAL3e+HjvDXvziee1oLfkz/kT
DIghPQoqZg+oLJYmezoa4ixzNY53pE/EtkTxCtXrmEfbvwCqNWkgNWqTKm4nGe1J
Uv1HFpdrUtg9j7bS9bIPRKQKaWr9nkNUJZPL5fjIs467WWQP0e6YbigVgoJQRYXi
t/o5ZKgRKp8DOW+bqjXvQvM69WXq9iyH7KmjVfbJ2o3NeoFOmPTlXtAunbp33xj4
6MuFH4USJZS11x0IgIiaCZHJS+RWfDdxI+4ONCqQ1lYkrLp9wl8XNznQzum60wFU
jhjJcaRtfdbMHmRd72//QVeIlX9VA6b5q36a/adPxbKrD2XTd4pntJ86dnU0aQFJ
sriJRk3KlD0IMDMS+rRsKz7EyJJP+9b5zlWCzX0V+1zNlcB6eiowOmo3QUQrFBQT
O50KS9YC7ef0EMWE6kikxyK8AxZ1Hjcm3eM50mShU+eCI/JPgkHeRQX+Z16RBybj
xhEBgRIvLS7bH8c6vqjIgmLQ1zxQ3EPR440Zpi0rw3rChP/lugYYQpcjXDfVFWED
gwe+RQvevj4tJeVjXG662DMuzmjy/cM2nNLZm3AZsaASkR73/M+Qmy53Y22T+T2o
VVcbOsK2+1Y8JFAVZguUib9pQ/z8DgBKs4+rfWiV4mzBAGwVIxePiNDiQ1kQU/Z0
3kUfgrNS0CgmE/nmg05x
=7kzU
-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

[openstack-dev] [nova][neutron][SR-IOV] Hardware changes and shifting PCI addresses

[Brent Eagles]

Hi,

I was recently informed of a situation that came up when an engineer
added an SR-IOV nic to a compute node that was hosting some guests that
had VFs attached. Unfortunately, adding the card shuffled the PCI
addresses causing some degree of havoc. Basically, the PCI addresses
associated with the previously allocated VFs were no longer valid. 

I tend to consider this a non-issue. The expectation that hosts have
relatively static hardware configuration (and kernel/driver configs for
that matter) is the price you pay for having pets with direct hardware
access. That being said, this did come as a surprise to some of those
involved and I don't think we have any messaging around this or advice
on how to deal with situations like this.

So what should we do? I can't quite see altering OpenStack to deal with
this situation (or even how that could work). Has anyone done any
research into this problem, even if it is how to recover or extricate
a guest that is no longer valid? It seems that at the very least we
could use some stern warnings in the docs.

Cheers,

Brent


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

Re: [openstack-dev] [Nova][Neutron] Cross-project coordination

[Brent Eagles]

Hi,

On Thu, May 07, 2015 at 10:03:30PM +, Sean M. Collins wrote:
 On Wed, Apr 22, 2015 at 06:41:58PM EDT, Jay Pipes wrote:
  Agreed. I'm hoping that someone in the Nova community -- note, this does 
  not need to be a Nova core contributor -- can step up to the plate and 
  serve in this critical role.
 
 Hi,
 
 I've put together a section on the wiki,
 
 https://wiki.openstack.org/wiki/CrossProjectLiaisons#Inter-project_Liaisons
 
 We still need a Nova liaison to sign up, to help me with the Nova/Neutron
 cross project effort. If you are interested, please reply and replace
 the Volunteer Needed sections in the table!

I volunteer! I've modified the wiki accordingly.

Cheers,

Brent


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

Re: [openstack-dev] [Nova][Neutron] out-of-tree plugin for Mech driver/L2 and vif_driver

[Brent Eagles]

Hi all,

On Wed, Mar 04, 2015 at 10:52:10AM -0330, Brent Eagles wrote:
 Hi all,

snip/
 
  Thanks Maxime. I've made some updates to the etherpad.
  (https://etherpad.openstack.org/p/nova_vif_plug_script_spec)
  I'm going to start some proof of concept work these evening. If I get
  anything worth reading, I'll put it up as a WIP/Draft review. Whatever
  state it is in I will be pushing up bits and pieces to github.
  
  https://github.com/beagles/neutron_hacking vif-plug-script
  https://github.com/beagles/nova vif-plug-script
  
  Cheers,
  
  Brent

snip/

The proof-of-concept hacking progressed to the point where I was able to
use the hacked up version of the ML2 OVS driver to trigger a test
plug/unplug script, achieving connectiving with a test VM. With the
exception of some boneheaded assumptions, things went reasonably well. I
will squash the commits and post WIP patches on gerrit tomorrow.

In my opinion, the big question now is what to do about rootwrap. The
current proof-of-concept does *not* use it because of the
sudo-stripping-environment variable issue. Environment variables can be
passed in on the command line and the 'Env' rootwrap filter employed,
but I don't know what is more workable from a deployment/3rd party
integration point of view: use rootwrap and require rootwrap filters be
added at deploy time; or don't use rootwrap from within nova and leave
it up to the plug script/executable. If rootwrap isn't used when
executing the plug script, the plug script itself could still use
rootwrap. Thoughts?

Cheers,

Brent


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

Re: [openstack-dev] [Nova][Neutron] out-of-tree plugin for Mech driver/L2 and vif_driver

[Brent Eagles]

Hi all,

On Wed, Feb 18, 2015 at 04:12:11PM -0330, Brent Eagles wrote:
 Hi,

snip/

 Thanks Maxime. I've made some updates to the etherpad.
 (https://etherpad.openstack.org/p/nova_vif_plug_script_spec)
 I'm going to start some proof of concept work these evening. If I get
 anything worth reading, I'll put it up as a WIP/Draft review. Whatever
 state it is in I will be pushing up bits and pieces to github.
 
 https://github.com/beagles/neutron_hacking vif-plug-script
 https://github.com/beagles/nova vif-plug-script
 
 Cheers,
 
 Brent

I had made several updates to the nova vif-plug-script branch over the
past few days, but at some point I goofed and did a rebase when I didn't
want to and messed up the branch. To keep things from getting messier, I
deleted and reconstructed the branch based on the current master. This
will only impact you if you had actually pulled the branch down (which I
suspect is a very small to zero-length list of people). My apologies if
this causes you inconvenience.

Also, the Nova spec repo is open for L now. Unless anyone objects, I
would like to cleanup the etherpad contents and submit the spec for
review feedback.

Cheers,

Brent



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

Re: [openstack-dev] [Nova][Neutron] out-of-tree plugin for Mech driver/L2 and vif_driver

[Brent Eagles]

Hi,

On 18/02/2015 1:53 PM, Maxime Leroy wrote:
 Hi Brent,

snip/

 Thanks for your help on this feature. I have just created a channel
 irc: #vif-plug-script-support to speak about it.
 I think it will help to synchronize effort on vif_plug_script
 development. Anyone is welcome on this channel!
 
 Cheers,
 Maxime

Thanks Maxime. I've made some updates to the etherpad.
(https://etherpad.openstack.org/p/nova_vif_plug_script_spec)
I'm going to start some proof of concept work these evening. If I get
anything worth reading, I'll put it up as a WIP/Draft review. Whatever
state it is in I will be pushing up bits and pieces to github.

https://github.com/beagles/neutron_hacking vif-plug-script
https://github.com/beagles/nova vif-plug-script

Cheers,

Brent




signature.asc
Description: OpenPGP digital 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] [Nova][Neutron] out-of-tree plugin for Mech driver/L2 and vif_driver

[Brent Eagles]

Hi Maxime, Neil,

On 16/01/2015 1:39 PM, Maxime Leroy wrote:
 On Wed, Jan 14, 2015 at 6:16 PM, Neil Jerram neil.jer...@metaswitch.com 
 wrote:
 Maxime Leroy maxime.le...@6wind.com writes:

 Ok, thank you for the details. I will look how to implement this feature.

 Hi Maxime,

 Did you have time yet to start looking at this?  My team now has a use
 case that could be met by using vif_plug_script, so I would be
 happy to help with writing the spec for that.  Would that be of interest
 to you?

 Thanks,
 Neil
 
 Hi Neil,
 
 I have planned to look later how to implement this new feature.
 As we are in feature freeze for Nova and Neutron, there is no hurry right now.
 
 I think we need to have these 2 news specs ready before the next summit.
 
 Of course, any help is welcome ! ;)
 I have just created an etherpad to write the spec for Nova:
 https://etherpad.openstack.org/p/nova_vif_plug_script_spec
 Feel free to modify it.
 
 Thanks,
 
 Maxime

I want to get the ball rolling on this ASAP so, I've started on this as
well and will be updating the etherpad accordingly. I'm also keen to get
W.I.P./P.O.C. patches to go along with it. I'll notify on the mailing
list (and direct so you don't miss it ;)) as soon as I've completed a
reasonable first swipe through the spec (which should be in the next day
or so).

Cheers,

Brent




signature.asc
Description: OpenPGP digital 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] [Nova][Neutron] Thoughts on the nova-neutron interface

[Brent Eagles]

 for interacting
with Nova. All of the Nova notification interactions can be handled there
and we can add new API components designed for Nova's use (e.g. syncing
data, etc). Does anyone have any objections to that approach?



I think we should be leaning the other way, actually - working out what a
generic service - think a container management service, or an edge network
service - would want to ask when it wanted to connect to a virtual network,
and making an Neutron interface that supports that properly *without* being
tailored to Nova.  The requirements are similar in all cases, so it's not
clear that a generic interface would be any more complex.

Notifications on data changes in Neutron to prevent orphaning is another
example of a repeating pattern.  It's probably the same for any service
that binds to Neutron, but right now Neutron has Nova-specific code in it.
Broadening the scope, it's also likely the same in Cinder, and in fact it's
also pretty similar to the problem you get when you delete a project in
Keystone and all your resources get orphaned.  Is a Nova-Neutron specific
solution the right thing to do?


I have reservations. It all depends on what it is going to do. Referring 
to it as nova-centric might also be a distraction. As part of scoping 
out the work for refactoring the nova.network.neutronv2.API code (you 
all know about that, right?), I discussed refactoring the neutronclient 
to make it more usable as client library with several people. This 
refactoring would prioritize nova's requirements when making changes, 
but the changes would still be generally usable. Instead of approaching 
this directly, I decided to start by wrapping the client in nova - 
working around shortcomings and rationalizing the API somewhat. I always 
saw this eventually being pushed out of nova into an independent client 
library and in cases where the neutron API itself is being worked 
around, relevant changes made in the neutron API itself. In that sense 
it is not unlike what Salvatore proposes but the approach is different 
and ultimately not nova-specific at all.


Cheers,

Brent Eagles


__
OpenStack Development Mailing 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] pci pass through turing complete config options?

[Brent Eagles]

Hi,

On 28/10/2014 10:39 AM, Sean Dague wrote:

On 10/28/2014 08:31 AM, Daniel P. Berrange wrote:


snip


I don't think that is really very extensible for the future to drop the
key name. We've already extended the info we record here at least once,
and I expect we'd want to add more fields later. It is also makes it
less clear to the user - it is very easy to get confused about vendor
vs product IDs if we leave out the name.


If we really need that level of arbitrary complexity and future name
values we should then just:

pci_passthrough_cfg = /etc/nova/pci_pass.yaml

And build fully nested structures over there.

Doing multi level nesting inside of .ini format files is just kind of gross.

-Sean


The PCI whitelist mechanism needs to be extensible and for the sake of 
expediency the existing whitelist mechanism was modified to add the 
fields it has now. There has been discussion that the current mechanism 
is either insufficient or simply completely undesirable for the PCI 
passthrough use cases and the current approach was an interim solution. 
Unless the current situation is completely untenable and simply must go, 
is this a good opportunity to revisit previous discussions and proposals 
before devising alternatives?


Cheers,

Brent

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova][Neutron][Technical Committee] nova-network - Neutron. Throwing a wrench in the Neutron gap analysis

[Brent Eagles]

On Wed, Aug 06, 2014 at 01:40:28PM +0800, Tom Fifield wrote:
snip/
 While DB migrations are running things like the nova metadata service
 can/will misbehave - and user code within instances will be affected.
 Thats arguably VM downtime.
 
 OTOH you could define it more narrowly as 'VMs are not powered off' or
 'VMs are not stalled for more than 2s without a time slice' etc etc -
 my sense is that most users are going to be particularly concerned
 about things for which they have to *do something* - e.g. VMs being
 powered off or rebooted - but having no network for a short period
 while vifs are replugged and the overlay network re-establishes itself
 would be much less concerning.
 
 I think you've got it there, Rob - nicely put :)
 
 In many cases the users I've spoken to who are looking for a live path out
 of nova-network on to neutron are actually completely OK with some API
 service downtime (metadata service is an API service by their definition).
 A little 'glitch' in the network is also OK for many of them.
 
 Contrast that with the original proposal in this thread (snapshot VMs in
 old nova-network deployment, store in Swift or something, then launch VM
 from a snapshot in new Neutron deployment) - it is completely unacceptable
 and is not considered a migration path for these users.
 
 
 Regards,
 
 
 Tom

I've thought about this off and on since it was brought up at summit. I
have some concerns about expectations. While I could probably rattle on,
I'll stick to the two for now.

- We need to be clear with expectations with connection resets and other
  odd connection behavior. There are some nice little gotchas for some
  applications when an IP address is moved depending on how connection
  is being used. Floating IPs could be interesting as well as
  nova-network and neutron differ quite a bit in how they are
  implemented. The ultimate effect on running applications will of
  course depend on whether or not they can handle things of that nature.
  Apps designed for failover, stale connections, etc, will probably fare
  better than those that are not. Apps designed for cattle vms probably
  will do okay too. I imagine pets will be higher risk and interestingly
  enough, they seem to be a more likely target use case. I suppose this
  falls under the category of glitch, but the pessimist (realist?) in
  me is having a hard time that some deployments are going to run into
  problems... which is a nice segue into the next concern.

- I wonder about uncommunicated expectations with migration rollback in
  case of the all gone to hell, we need to put it back situation. We
  have been talking about migrating a live VM from nova-network to
  neutron, but what about the way back? Are new VM boots going to be
  prevented until an all-clear is given to prevent orphans if
  nova-network needs to be put back in place? Or are we saying it is a
  never look back type of deal? Has this  been discussed and all
  worked out and I just missed it? This concerns me a great deal because
  cannot imagine any of the admins I've ever worked with doing something
  without a failsafe backup to known good state whether the end up
  needing it or not.

I'm not convinced that these have been thoroughly considered, nor are
they addressable in the very near future. I also am *deeply* concerned
that placing significant focus on this PRIOR to achieving parity with
nova-network both in function and stability jeopardizes all. That is not
to diminish the efforts of those that have already contributed heavily
in this area. However, this work is all for nothing if we haven't
covered the necessary gaps so that the users have something to migrate
*to*. 

Cheers,

Brent

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [nova][neutron] Networks without subnets

[Brent Eagles]

Hi,

A bug titled Creating quantum L2 networks (without subnets) doesn't
work as expected (https://bugs.launchpad.net/nova/+bug/1039665) was
reported quite some time ago. Beyond the discussion in the bug report,
there have been related bugs reported a few times.

* https://bugs.launchpad.net/nova/+bug/1304409
* https://bugs.launchpad.net/nova/+bug/1252410
* https://bugs.launchpad.net/nova/+bug/1237711
* https://bugs.launchpad.net/nova/+bug/1311731
* https://bugs.launchpad.net/nova/+bug/1043827

BZs on this subject seem to have a hard time surviving. The get marked
as incomplete or invalid, or in the related issues, the problem NOT
related to the feature is addressed and the bug closed. We seem to dance
around actually getting around to implementing this. The multiple
reports show there *is* interest in this functionality but at the moment
we are without an actual implementation.

At the moment there are multiple related blueprints:

* https://review.openstack.org/#/c/99873/ ML2 OVS: portsecurity
  extension support
* https://review.openstack.org/#/c/106222/ Add Port Security
  Implementation in ML2 Plugin
* https://review.openstack.org/#/c/97715 NFV unaddressed interfaces

The first two blueprints, besides appearing to be very similar, propose
implementing the port security extension currently employed by one of
the neutron plugins. It is related to this issue as it allows a port to
be configured indicating it does not want security groups to apply. This
is relevant because without an address, a security group cannot be
applied and this is treated as an error. Being able to specify
skipping the security group criteria gets us a port on the network
without an address, which is what happens when there is no subnet.

The third approach is, on the face of it, related in that it proposes an
interface without an address. However, on review it seems that the
intent is not necessarily inline with the some of the BZs mentioned
above. Indeed there is text that seems to pretty clearly state that it
is not intended to cover the port-without-an-IP situation. As an aside,
the title in the commit message in the review could use revising.

In order to implement something that finally implements the
functionality alluded to in the above BZs in Juno, we need to settle on
a blueprint and direction. Barring the happy possiblity of a resolution
beforehand, can this be made an agenda item in the next Nova and/or
Neutron meetings?

Cheers,

Brent

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Informal meeting before SR-IOV summit presentation

[Brent Eagles]

On 09/05/14 04:21 PM, Sandhya Dasu (sadasu) wrote:

Thanks for all your replies.

Thanks for the great inputs on how to frame the discussion in the etherpad
so it becomes easier for people to get on board. We will add author indent
to track the source of the changes. Will work on cleaning that up.

Regarding the session itself, as you probably know, there was an attempt
in Icehouse to get the sr-iov work going. We found that the time allotted
for the session was not sufficient to get to all the use cases and discuss
alternate views.

This time around we want to be better prepared and so would like to keep
only a couple of open times for the actual session. Hence, the request for
the early meeting.

How does Monday 1pm sound?

Thanks,
Sandhya


That time is good with me.

Cheers,

Brent


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Informal meeting before SR-IOV summit presentation

[Brent Eagles]

On Thu, May 08, 2014 at 08:40:01PM +, Robert Li (baoli) wrote:

 On 5/8/14, 4:33 PM, Steve Gordon sgor...@redhat.com wrote:

snip FWIW, it is nice to keep the author of a particular indent
level in the message /snip

  Dan Smith d...@danplanet.com wrote:
  What would be the purpose of doing that before the session? IMHO, a
  large part of being able to solve this problem is getting everyone up to
  speed on what this means, what the caveats are, and what we're trying to
  solve. If we do some of that outside the scope of the larger audience, I
  expect we'll get less interaction (or end up covering it again) in the
  session.
 
  That said, if there's something I'm missing that needs to be resolved
  ahead of time, then that's fine, but I expect the best plan is to just
  keep the discussion to the session. Afterwards, additional things can be
  discussed in a one-off manner, but getting everyone on the same page is
  largely the point of having a session in the first place IMHO.
 
 Right, in spite of my previous response...looking at the etherpad there
 is nothing there to frame the discussion at the moment:
 
 https://etherpad.openstack.org/p/juno-nova-sriov-support
 
 I think populating this should be a priority rather than organizing
 another session/meeting?
 
 Steve

 This is the one that Irena created:
 https://etherpad.openstack.org/p/pci_passthrough_cross_project

Since the juno etherpad now contains the contents of the other, it seems
that someone has cut and pasted. Nice. I think we can frame the
discussion topics a little more clearly prior to the session though, so
maybe a brief gathering for that purpose would be useful?

One goal might be (as I think Dan alludes to) to provide some background
and details so the participants of the session can engage in
constructive dialogue. Dan provides a good outline:

 - Introduction - get up to speed

   What is the most effective way to outline for this particular
   audience so that they can participate?

 - What the caveats are.

   Are these our use cases? In a matter of speaking they are. One of
   them is also a question that needs answering.

 - What are we trying to solve?
   B. C. D. and E.?

   IMO, if there things we don't agree on at the moment, it is perfectly
   fine and probably preferable to present the problem and the alternate
   views (albeit objectively and evenly) in the session. Walking in with
   unresolved questions and walking out with the same questions is kind
   of a fail. Walking out with new unresolved questions is, IMO,
   fine... and probably likely ;)

 - We probably need to get to the what we are going to do for Juno
   question for this to be a good win. This could be satisfy use case X
   and Y and might be distressingly underwhelming or
   overambitious... this is something else that we might want to talk
   about as having some idea of what we want to accomplish vis-a-vis use
   cases and why, a prioritization, etc. is something that could be
   brought up in a session and discussed.

In any case, it goes without saying that coming away from the session
with something actionable and acceptable to the community is the
ultimate objective. A really strong understanding of what is needed for
acceptable nova blueprints for SRIOV (and why we haven't gotten there
yet maybe) would be super!

If getting together to further prepare for the session is something of
interest, I am free on Monday starting late morning. The rest of my
schedule is resolving, but I have firm commitments on mid-afternoon
Tuesday and Wednesday and will not be available then.

Cheers,

Brent

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][qa] test_network_basic_ops and the FloatingIPChecker control point

[Brent Eagles]

Salvatore Orlando wrote:

Before starting this post I confess I did not read with the required level
of attention all this thread, so I apologise for any repetition.

I just wanted to point out that floating IPs in neutron are created
asynchronously when using the l3 agent, and I think this is clear to
everybody.
So when the create floating IP call returns, this does not mean the
floating IP has actually been wired, ie: IP configured on qg-interface and
SNAT/DNAT rules added.

Unfortunately, neutron lacks a concept of operational status for a floating
IP which would tell clients, including nova (it acts as a client wrt nova
api), when a floating IP is ready to be used. I started work in this
direction, but it has been suspended now for a week. If anybody wants to
take over and deems this a reasonable thing to do, it will be great.


Unless somebody picks it up before I get from the break, I'd like to 
discuss this further with you.



I think neutron tests checking connectivity might return more meaningful
failure data if they would gather the status of the various components
which might impact connectivity.
These are:
- The floating IP
- The router internal interface
- The VIF port
- The DHCP agent


I agree wholeheartedly. In fact, I think if we are going to rely on 
timeouts for pass/fail we need to do more for post-mortem details.



Collecting info about the latter is very important but a bit trickier. I
discussed with Sean and Maru that it would be great for a starter, grep the
console log to check whether the instance obtained an IP.
Other things to consider would be:
- adding an operational status to a subnet, which would express whether the
DHCP agent is in sync with that subnet (this information won't make sense
for subnets with dhcp disabled)
- working on a 'debug' administrative API which could return, for instance,
for each DHCP agent the list of configured networks and leases.


Interesting!


Regarding timeouts, I think it's fair for tempest to define a timeout and
ask that everything from VM boot to Floating IP wiring completes within
that timeout.

Regards,
Salvatore


I would agree. It would be impossible to have reasonable automated 
testing otherwise.


Cheers,

Brent

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][qa] test_network_basic_ops and the FloatingIPChecker control point

[Brent Eagles]

Hi,

Yair Fried wrote:

I would also like to point out that, since Brent used compute.build_timeout as 
the timeout value
***It takes more time to update FLIP in nova DB, than for a VM to build***

Yair


Agreed. I think that's an extremely important highlight of this 
discussion. Propagation of the floating IP is definitely bugged. In the 
small sample of logs (2) that I checked, the floating IP assignment 
propagated in around 10 seconds for test_network_basic_ops, but in the 
cross tenant connectivity test it took somewhere around 1 minute for the 
first assignment and something over 3 (otherwise known as 
simply-too-long-to-find-out). Even if the querying of once a second were 
excessive - which I do not feel strong enough about to say is anything 
other than a *possible* contributing factor - it should not take that long.


Cheers,

Brent

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron][qa] test_network_basic_ops and the FloatingIPChecker control point

[Brent Eagles]

Hi,

Yair and I were discussing a change that I initiated and was 
incorporated into the test_network_basic_ops test. It was intended as a 
configuration control point for floating IP address assignments before 
actually testing connectivity. The question we were discussing was 
whether this check was a valid pass/fail criteria for tests like 
test_network_basic_ops.


The initial motivation for the change was that test_network_basic_ops 
had a less than 50/50 chance of passing in my local environment for 
whatever reason. After looking at the test, it seemed ridiculous that it 
should be failing. The problem is that more often than not the data that 
was available in the logs all pointed to it being set up correctly but 
the ping test for connectivity was timing out. From the logs it wasn't 
clear that the test was failing because neutron did not do the right 
thing, did not do it fast enough, or is something else happening?  Of 
course if I paused the test for a short bit between setup and the checks 
to manually verify everything the checks always passed. So it's a timing 
issue right?


Two things: adding more timeout to a check is as appealing to me as 
gargling glass AND I was less annoyed that the test was failing as I 
was that it wasn't clear from reading logs what had gone wrong. I tried 
to find an additional intermediate control point that would split 
failure modes into two categories: neutron is too slow in setting things 
up and neutron failed to set things up correctly. Granted it still is 
adding timeout to the test, but if I could find a control point based on 
settling so that if it passed, then there is a good chance that if the 
next check failed it was because neutron actually screwed up what it was 
trying to do.


Waiting until the query on the nova for the floating IP information 
seemed a relatively reasonable, if imperfect, settling criteria before 
attempting to connect to the VM. Testing to see if the floating IP 
assignment gets to the nova instance details is a valid test and, 
AFAICT, missing from the current tests. However, Yair has the reasonable 
point that connectivity is often available long before the floating IP 
appears in the nova results and that it could be considered invalid to 
use non-network specific criteria as pass/fail for this test.


In general, the validity of checking for the presence of a floating IP 
in the server details is a matter of interpretation. I think it is a 
given that it must be tested somewhere and that if it causes a test to 
fail then it is as valid a failure than a ping failing. Certainly I have 
seen scenarios where an IP appears, but doesn't actually work and others 
where the IP doesn't appear (ever, not just in really long while) but 
magically works. Both are bugs. Which is more appropriate to tests like 
test_network_basic_ops?


Currently, the polling interval for the checks in the gate should be 
tuned. They are borrowing other polling configuration and I can see it 
is ill-advised. It is currently polling at an interval of a second and 
if the intent is to wait for the entire system to settle down before 
proceeding then polling nova that quickly is too often. It simply 
increases the load while we are waiting to adapt to a loaded system. For 
example in the course of a three minute timeout, the floating IP check 
polled nova for server details 180 times.


All this aside it is granted that checking for the floating IP in the 
nova instance details is imperfect in itself. There is nothing that 
assures that the presence of that information indicates that the 
networking backend is done its work.


Comments, suggestions, queries, foam bricks?

Cheers,

Brent

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] Creating recipes for mimicking behavior of nova-networking network managers.

[Brent Eagles]

On 12/09/2013 04:05 PM, Brent Eagles wrote:

On 12/04/2013 07:56 PM, Tom Fifield wrote:

On 05/12/13 01:14, Brent Eagles wrote:

Hi,


 snip 


I think that's a great idea.

What kind of format would you like to see the recepies in?

Regards,

Tom


I think a wiki is the right way to start. It will allow us to include
diagrams and access other online content fairly easily. Other
suggestions are welcome of course!

Cheers,

Brent


FWIW: I stoked a wiki with some content from network manager 
descriptions if it makes a reasonable starting point.


https://wiki.openstack.org/wiki/NovaNetNeutronRecipes

Cheers,

Brent


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron] Creating recipes for mimicking behavior of nova-networking network managers.

[Brent Eagles]

Hi,

As part of the Icehouse nova-networking parity effort, we need to 
describe how nova-networking managers work and how the behavior is 
mapped to neutron. The benefits are:


1. It aides migration: deployers who are nova-network savvy can see how 
functionality maps from one to the other.


2. It aides implementation: if we cannot provide a mapping, there is a 
breakage in parity and it needs to be addressed somehow.


3. It aides testing (and debugging): by illuminating points where the 
implementations differ, it makes it easier to design and implement tests 
that can be expected to function the same for each networking 
implementation.


4. It aides acceptance: at some point, the proverbial *we* are going to 
decide whether neutron is ready to replace nova. The existence of 
working recipes is a pretty strong set of acceptance criteria.  Another 
way to look at it is that the recipes are essentially a high level 
description of how to go about manually testing parity.


5. It aides support and documentation efforts: nearly any point in the 
openstack user spectrum (casual experimenter to hard-core 
developer/implementer) who has anything to do with legacy deployments or 
parity itself will benefit from having these recipes on hand. NOT to 
mention the rtfm option when somebody asks I'm using FlatManager in 
nova-network and want to do the same in neutron, how does that work? (I 
love being able to write rtfm, don't you?)


Sounds great!?! Cool! Do you want to help or know someone who does (or 
should - third-person volunteering not discouraged!)? We need 
nova-networking savvy and neutron savvy folks alike, though you need not 
necessarily be both at the same time.


As some of the aforementioned benefits are directly relevant to the 
Icehouse development cycle AND the holiday season is upon us, it is 
important to get the ball rolling ASAP. To be specific, working recipes 
are most valuable if they are available for Icehouse-2 (see reasons 2, 3 
and most importantly 4).


Please respond if interested, want to volunteer someone or have comments 
and suggestions.


Cheers,

Brent

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev