Re: [openstack-dev] [tripleo] [neutron] Current containerized neutron agents introduce a significant regression in the dataplane

[Armando M.]

On 13 February 2018 at 14:02, Brent Eagles  wrote:

> 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.
>
>
There's quite a bit to unpack here: are you suggesting that running these
services in HA configuration doesn't help either with the data plane being
gone after a stop/restart? Ultimately this boils down to where the state is
persisted, and while certain agents rely on namespaces and processes whose
ephemeral nature is hard to persist, enough could be done to allow for a
non-disruptive bumping of the afore mentioned services.

Thanks,
Armando


> 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
>
>
__
OpenStack Development Mailing 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] cycle highlights for sub-projects

[Armando M.]

On 2 February 2018 at 13:33, Armando M.  wrote:

> Hi neutrinos,
>
> RC1 is fast approaching and this time we can add highlights to the release
> files [1]. If I can ask you anyone interested in contributing to the
> highlights: please review [2].
>
> Miguel and I will make sure they are compiled correctly. We have time
> until Feb 9 to get this done.
>

> Many thanks,
> Armando
>
> [1] http://lists.openstack.org/pipermail/openstack-dev/
> 2017-December/125613.html
> [2] https://review.openstack.org/#/c/540476/
>


Reminder before we cut RC1 by EOB today.

Cheers,
Armando
__
OpenStack Development Mailing 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] [neutron] cycle highlights for sub-projects

[Armando M.]

Hi neutrinos,

RC1 is fast approaching and this time we can add highlights to the release
files [1]. If I can ask you anyone interested in contributing to the
highlights: please review [2].

Miguel and I will make sure they are compiled correctly. We have time until
Feb 9 to get this done.

Many thanks,
Armando

[1]
http://lists.openstack.org/pipermail/openstack-dev/2017-December/125613.html
[2] https://review.openstack.org/#/c/540476/
__
OpenStack Development Mailing 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][lbaas][neutron-lbaas][octavia] Announcing the deprecation of neutron-lbaas and neutron-lbaas-dashboard

[Armando M.]

On 31 January 2018 at 09:50, Michael Johnson  wrote:

> Today we are announcing the start of the deprecation cycle for
> neutron-lbaas and neutron-lbaas-dashboard. As part of the neutron
> stadium evolution [1], neutron-lbaas was identified as a project that
> should spin out of neutron and become its own project. The
> specification detailing this process was approved [2] during the
> newton OpenStack release cycle.
>
> OpenStack load balancing no longer requires deep access into the
> neutron code base and database. All of the required networking
> capabilities are now available via stable APIs. This change de-couples
> the load balancing release versioning from the rest of the OpenStack
> deployment. Since Octavia uses stable APIs when interacting with other
> OpenStack services, you can run a different version of Octavia in
> relation to your OpenStack cloud deployment.
>
> Per OpenStack deprecation policy, both projects will continue to
> receive support and bug fixes during the deprecation cycle, but no new
> features will be added to either project. All future feature
> enhancements will now occur on the Octavia project(s) [3].
>
> We are not announcing the end of the deprecation cycle at this time,
> but it will follow OpenStack policy of at least two release cycles
> prior to retirement. This means that the first release that these
> projects could be retired would be the “T” OpenStack release cycle.
>
> We have created a Frequently Asked Questions (FAQ) wiki page to help
> answer additional questions you may have about this process:
> https://wiki.openstack.org/wiki/Neutron/LBaaS/Deprecation
>
> For more information or if you have additional questions, please see
> the following resources:
>
> The FAQ: https://wiki.openstack.org/wiki/Neutron/LBaaS/Deprecation
>
> The Octavia documentation: https://docs.openstack.org/octavia/latest/
>
> Reach out to us via IRC on the Freenode IRC network, channel
> #openstack-lbaas
>
> Weekly Meeting: 20:00 UTC on Wednesdays in #openstack-lbaas on the
> Freenode IRC network.
>
> Sending email to the OpenStack developer mailing list: openstack-dev
> [at] lists [dot] openstack [dot] org. Please prefix the subject with
> '[openstack-dev][Octavia]'
>
> Thank you for your support and patience during this transition,
>
> Michael Johnson
> Octavia PTL
>

What a milestone! Thanks for your leadership throughout this journey!

Cheers,
Armando


>
> [1] http://specs.openstack.org/openstack/neutron-specs/specs/
> newton/neutron-stadium.html
> [2] http://specs.openstack.org/openstack/neutron-specs/specs/
> newton/kill-neutron-lbaas.html
> [3] https://governance.openstack.org/tc/reference/projects/octavia.html
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][neutron-lib]Service function defintion files

[Armando M.]

On 29 December 2017 at 11:00, Ian Wells  wrote:

> On 28 December 2017 at 06:57, CARVER, PAUL  wrote:
>
>> It was a gating criteria for stadium status. The idea was that the for a
>> stadium project the neutron team would have review authority over the API
>> but wouldn't necessarily review or be overly familiar with the
>> implementation.
>>
>> A project that didn't have it's API definition in neutron-lib could do
>> anything it wanted with its API and wouldn't be a neutron subproject
>> because the neutron team wouldn't necessarily know anything at all about it.
>>
>> For a neutron subproject there would at least theoretically be members of
>> the neutron team who are familiar with the API and who ensure some sort of
>> consistency across APIs of all neutron subprojects.
>>
>> This is also a gating criteria for publishing API documentation on
>> api.openstack.org vs publishing somewhere else. Again, the idea being
>> that the neutron team would be able, at least in some sense, to "vouch for"
>> the OpenStack networking APIs, but only for "official" neutron stadium
>> subprojects.
>>
>> Projects that don't meet the stadium criteria, including having api-def
>> in neutron-lib, are "anything goes" and not part of neutron because no one
>> from the neutron team is assumed to know anything about them. They may work
>> just fine, it's just that you can't assume that anyone from neutron has
>> anything to do with them or even knows what they do.
>>
>
> OK - that makes logical sense, though it does seem that it would tie
> specific versions of every service in that list to a common version of
> neutron-lib as a byproduct, so it would be impossible to upgrade LBaaS
> without also potentially having to upgrade bgpvpn, for instance.  I don't
> know if that was the intention, but I wouldn't have expected it.
>

It was intentional and was meant to help stabilize/sync up the core (of
neutron) with the subprojects. Without it it would be practically
impossible for a downstream consumer to figure out what works with which.
As a side effect, the lack of well thought out API versioning in Neutron
means we can't quite introduce breaking changes in the API and that means
we'll probably never bump the neutron-lib's major version.


> --
> Ian.
>
> __
> OpenStack Development Mailing 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] [neutron][neutron-lib]Service function defintion files

[Armando M.]

On 27 December 2017 at 18:56, Ian Wells  wrote:

> Hey,
>
> Can someone explain how the API definition files for several service
> plugins ended up in neutron-lib?  I can see that they've been moved there
> from the plugins themselves (e.g. networking-bgpvpn has
> https://github.com/openstack/neutron-lib/commit/
> 3d3ab8009cf435d946e206849e85d4bc9d149474#diff-
> 11482323575c6bd25b742c3b6ba2bf17) and that there's a stadium element to
> it judging by some earlier commits on the same directory, but I don't
> understand the reasoning why such service plugins wouldn't be
> self-contained - perhaps someone knows the history?
>

This was done as part of the stadium effort [1,2]. The rationale being that
changes and/or new proposals for API definitions would be located in
neutron-lib (same for client extensions but in neutronclient) so that they
would be overseen by the neutron-drivers team to provide a level of
consistency across projects included in the stadium.

HTH
Armando

[1]
https://specs.openstack.org/openstack/neutron-specs/specs/newton/neutron-stadium.html
[2]
https://docs.openstack.org/neutron/latest/contributor/stadium/governance.html


> Thanks,
> --
> Ian.
>
> __
> OpenStack Development Mailing 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] [neutron] performance issue between virtual networks

[Armando M.]

On 27 December 2017 at 05:39, Kim-Norman Sahm  wrote:

> Hi,
>
> i've detected a performance issue by accessing an floating ip in a
> different openstack network (same tenant).
>
> example:
> i have one tenant with two internal networks.
> each network has its own vrouter which is connectet to the extnet.
> the physical network infrastructure is 10Gbit/s.
>
>  networkA
>VM1 --|   extnet
>  ||vrouter1||
>VM2 --|  |
> |---ext
>  networkB   |
>VM3 --|  |
>  ||vrouter2||
>VM4 --|
>
> VM1 -> VM2  ~8,6Gbit/s
> VM3 -> VM4  ~8,6GBit/s
> VM1 -> vrouter1 ~8.6GBit/s
> VM4 -> vrouter2 ~8,6GBit/s
> vrouter1 -> vrouter2 ~8,6Gbits
> VM1 -> VM4  ~2,5GBit/s
> VM1 -> vrouter2 ~2,5Gbit/s
>
> detected with iperf3
> it's an openstack newton environment with openvswitch 2.6.1
> VXLAN mtu is 8950 and 9000 for physical interfaces
>
> does anybody has an idea what could be the cause of the performance
> issue?
>

Is the router distributed?


>
> Best regards
> Kim
>
> __
> OpenStack Development Mailing 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] [neutron][networking-ovn] Stable branch maintainers for networking-ovn

[Armando M.]

On 20 December 2017 at 00:27, Miguel Angel Ajo Pelayo 
wrote:

> If we could have one member from networking-ovn on the
> neutron-stable-maint team that would be great. That means the member would
> have to be trusted not to handle neutron-patches when not knowing what he's
> doing, and of course, follow the stable guidelines, which are absolutely
> important. But I believe everybody takes the role seriously.
>

It'll still take two +2 to push a patch in, and the oversight from more
seasoned stable reviewers is still there to assist more inexperienced ones.
Aside from the occasional lag, I don't believe that backports linger as
much as they used to, but with the help of the dashboard and the initiative
of the individual project maintainers velocity should increase. To be
honest, I am not sure why we didn't do that before, similar review rights
apply to things like specs reviews and neutron-lib changes. As for your
concern about people stepping out of their own turf, I honestly don't
believe that's a problem in reality, and even if it was, I always encourage
people to reach out on IRC or other means.

I don't have admin rights to the neutron-stable-maint team, fo that someone
has to nudge Ihar :)

HTH
Armando

[1] https://docs.openstack.org/project-team-guide/stable-branches.html


>
> If that's not a reasonable solution, then I'd vote for the specific stable
> maintainers instead. But we need something to help us handle issues quicker
> and at
> the same time, in a controlled manner.
>
> Best,
> Miguel Ángel.
>
> On Tue, Dec 19, 2017 at 5:48 PM Armando M.  wrote:
>
>> On 19 December 2017 at 08:21, Lucas Alvares Gomes 
>> wrote:
>>
>>> Hi all,
>>>
>>> Just sending this email to try to understand the model for stable branch
>>> maintenance in networking-ovn (potentially other neutron drivers too).
>>>
>>> Right now, only members of the ``neutron-stable-maint`` gerrit group are
>>> able to approve patches for the stable branches; this can cause some delays
>>> when fixing things (e.g [0]) because we don't have any member in that group
>>> that is also a ``networking-ovn-core`` member. So, sometimes we have to go
>>> around and ping people to take a look at the patches and it kinda sucks.
>>>
>>
>> We had a Gerrit dashboard that helped stable reviewers stay on top of
>> things [1], but it looks like it doesn't seem to work anymore. My
>> suggestion would be to look into that as the lack of visibility might be
>> the source of the recent delay.
>>
>> [1] https://docs.openstack.org/neutron/latest/
>> contributor/dashboards/index.html#gerrit-dashboards
>>
>>
>>> Is there any reason why things are set up in that way ?
>>>
>>> I was wondering if it would make sense to create a new group to help
>>> maintaining the stable branches in networking-ovn. The new group could
>>> include some of the core members willing to do the work +
>>> ``neutron-stable-maint`` as a subgroup. Is that reasonable, what you think
>>> about it?
>>>
>>
>> Rather than create yet another group(s), it makes sense to have an
>> individual from each neutron project participate in the
>> neutron-stable-maint team (whose admin rights I think are held by Ihar as
>> neutron member), for those of whom have actually an interest in reviewing
>> stable patches :)
>>
>> HTH
>> Armando
>>
>>
>>> [0] https://review.openstack.org/#/c/523623/
>>>
>>> Cheers,
>>> Lucas
>>>
>>> 
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
>>> unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
>> unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][networking-ovn] Stable branch maintainers for networking-ovn

[Armando M.]

On 19 December 2017 at 08:21, Lucas Alvares Gomes 
wrote:

> Hi all,
>
> Just sending this email to try to understand the model for stable branch
> maintenance in networking-ovn (potentially other neutron drivers too).
>
> Right now, only members of the ``neutron-stable-maint`` gerrit group are
> able to approve patches for the stable branches; this can cause some delays
> when fixing things (e.g [0]) because we don't have any member in that group
> that is also a ``networking-ovn-core`` member. So, sometimes we have to go
> around and ping people to take a look at the patches and it kinda sucks.
>

We had a Gerrit dashboard that helped stable reviewers stay on top of
things [1], but it looks like it doesn't seem to work anymore. My
suggestion would be to look into that as the lack of visibility might be
the source of the recent delay.

[1]
https://docs.openstack.org/neutron/latest/contributor/dashboards/index.html#gerrit-dashboards


> Is there any reason why things are set up in that way ?
>
> I was wondering if it would make sense to create a new group to help
> maintaining the stable branches in networking-ovn. The new group could
> include some of the core members willing to do the work +
> ``neutron-stable-maint`` as a subgroup. Is that reasonable, what you think
> about it?
>

Rather than create yet another group(s), it makes sense to have an
individual from each neutron project participate in the
neutron-stable-maint team (whose admin rights I think are held by Ihar as
neutron member), for those of whom have actually an interest in reviewing
stable patches :)

HTH
Armando


> [0] https://review.openstack.org/#/c/523623/
>
> Cheers,
> Lucas
>
> __
> OpenStack Development Mailing 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] [neutron] Stepping down from core

[Armando M.]

Hi neutrinos,

To some of you this email may not come as a surprise.

During the past few months my upstream community engagements have been more
and more sporadic. While I tried hard to stay committed and fulfill my core
responsibilities I feel like I failed to retain the level of quality and
consistency that I would have liked ever since I stepped down from being
the Neutron PTL back at the end of Ocata.

I stated many times when talking to other core developers that being core
is a duty rather than a privilege, and I personally feel like it's way
overdue for me to recognize on the mailing list that it's the time that I
state officially my intention to step down due to other commitments.

This does not mean that I will disappear tomorrow. I'll continue to be on
neutron IRC channels, support the neutron team, being the release liasion
for Queens, participate at meetings, and be open to providing feedback to
anyone who thinks my opinion is still valuable, especially when dealing
with the neutron quirks for which I might be (git) blamed :)

Cheers,
Armando
__
OpenStack Development Mailing 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] Propose Slawek Kaplonski for Neutron core

[Armando M.]

On 29 November 2017 at 12:27, Korzeniewski, Artur <
artur.korzeniew...@intel.com> wrote:

> +1 from me 😉, (even though my vote does not count)
>
> I know Slawek since Tokyo summit and I’m impressed of his knowledge and
> hands-on experience to improve Neutron quality and functionality!
>
> It is great to see him joining the core reviewers team!
>
> Congrats Sławek!
>

Rock On


>
>
> *From:* Miguel Angel Ajo Pelayo [mailto:majop...@redhat.com]
> *Sent:* Wednesday, November 29, 2017 8:47 PM
> *To:* OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>
> *Subject:* Re: [openstack-dev] [Neutron] Propose Slawek Kaplonski for
> Neutron core
>
>
>
> "+1" I know, I'm not active, but I care about neutron, and slaweq is a
> great contributor.
>
>
>
> On Nov 29, 2017 8:37 PM, "Ihar Hrachyshka"  wrote:
>
> YES, FINALLY.
>
> On Wed, Nov 29, 2017 at 11:29 AM, Kevin Benton  wrote:
> > +1! ... even though I haven't been around. :)
> >
> > On Wed, Nov 29, 2017 at 1:21 PM, Miguel Lavalle 
> wrote:
> >>
> >> Hi Neutron Team,
> >>
> >> I want to nominate Slawek Kaplonski (irc: slaweq) to Neutron core.
> Slawek
> >> has been an active contributor to the project since the Mitaka cycle.
> He has
> >> been instrumental in the development of the QoS capabilities in Neutron,
> >> becoming the lead of the sub-team focused on that set of features. More
> >> recently, he has collaborated in the implementation of OVO and is an
> active
> >> participant in the CI sub-team. His number of code reviews during the
> Queens
> >> cycle is on par with the leading core members of the team:
> >> http://stackalytics.com/?module=neutron
> >>
> >> In my opinion, his efforts are highly valuable to the team and we will
> be
> >> very lucky to have him as a fully voting core.
> >>
> >> I will keep this nomination open for a week as customary,
> >>
> >> Thank you,
> >>
> >> Miguel
> >>
> >> 
> __
> >> OpenStack Development Mailing List (not for usage questions)
> >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >
> >
> > 
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing 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][infra][zuul][zuulv3][horizon][neutron] project-specific release job templates

[Armando M.]

On 24 October 2017 at 13:13, Jeremy Stanley  wrote:

> On 2017-10-24 11:31:56 -0700 (-0700), Armando M. wrote:
> [...]
> > the work on neutron-lib is slowly progressing but it's not close enough
> to
> > allow us to break the dependency that requires neutron sub-projects to
> add
> > neutron to the list of required-projects (which I believe the sort of the
> > error in the release pipeline stems from).
> [...]
>
> It's not entirely clear to me what about a Neutron plug-in would
> actually require the neutron source installed just to be able to
> generate a tarball (or wheel) or build sphinx docs. Couldn't that be
> solved even if things like installation or unit testing still
> continue to need neutron?
>

Jeremy and I talked about this in [1].

To sum it up: the necessity of neutron for plugins is primarily for testing
and installation to the best of my knowledge. Other coupling tied to bash
scripts that control gate jobs could be easily addressed if it gets in the
way. Therefore, should we move away from tox for release specific tasks,
it's entirely possible to drop the custom project definition.

I hope I represented the conversation correctly!

[1]
http://eavesdrop.openstack.org/irclogs/%23openstack-infra/latest.log.html#t2017-10-24T23:06:35


> --
> Jeremy Stanley
>
> __
> OpenStack Development Mailing 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] [release][infra][zuul][zuulv3][horizon][neutron] project-specific release job templates

[Armando M.]

On 24 October 2017 at 10:35, Doug Hellmann  wrote:

> Excerpts from Jeremy Stanley's message of 2017-10-24 15:05:34 +:
> > On 2017-10-24 09:42:25 -0400 (-0400), Doug Hellmann wrote:
> > [...]
> > > It looks like the publish-to-pypi-neutron template modifies
> > > publish-to-pypi by adding openstack/neutron to the
> required-repositories
> > > list for the release-openstack-python job. That repository was also at
> > > some point added directly to the release-openstack-python job. So
> > > technically the extension via the template is not needed. The same
> > > applies to publish-to-pypi-horizon.
> > [...]
> >
> > Both are stop-gap solutions and I think either is fine in the short
> > term to get us through the bulk of the release request backlog.
> > Longer term we want to have neither of those. Python projects should
> > be able to build sdists/wheels[1], documentation[2] and release
> > notes[3] without tox (a behavior change which significantly
> > complicates preinstalling source code from other projects, so best
> > if their release jobs simply don't rely on doing that at all).
> >
> > > As we find other projects with more dependencies, we're going to
> > > end up with more custom templates.
> > [...]
> >
> > If we do, this only accelerates the need for something like a
> > community goal for fixing this in those respective Python
> > plugin/extension projects.
>
> Right. I know the neutron team has been working on their library system
> for quite a while. Maybe someone can report on the progress there?
>

the work on neutron-lib is slowly progressing but it's not close enough to
allow us to break the dependency that requires neutron sub-projects to add
neutron to the list of required-projects (which I believe the sort of the
error in the release pipeline stems from).


>
> I don't know if the horizon team is working on that (I'm just uninformed
> about what they're doing). So maybe someone from that team can comment?
>
> >
> > > One alternative to keeping multiple variants, and defining more in
> > > the future, is to add required-repositories to the
> release-openstack-python
> > > job directly, as we discover they are needed. Of course that means
> > > we will clone repositories for some jobs that don't actually use
> > > them. I don't know how big of an issue that really is, but the issue
> > > of not knowing which instances of a job actually need a particular
> > > dependency seems like more of a justification for keeping separate
> > > templates than any runtime savings we would have by skipping a
> > > couple of extra calls to git clone.
> > [...]
> >
> > Well, in this case you're talking about Zuul needing to calculate
> > merge states for the neutron and horizon repos and then push these
> > into every build of the affected jobs, which is no small amount of
> > overhead on its own given the size of those particular repos. Also,
> > once the tox-siblings role[4] is back in action (likely later this
> > week?) Zuul will go back to preinstalling any required-projects from
> > source into tox virtualenvs for these jobs, which is quite a bit
> > more overhead still at that point.
>
> Yes, we don't want that, so I think that means we want to retain the
> multiple project templates for the short-term.


> >
> > [1] http://git.openstack.org/cgit/openstack/governance/commit/?
> id=2678231
> > [2] http://git.openstack.org/cgit/openstack/governance/commit/?
> id=2c0cdd2
> > [3] http://git.openstack.org/cgit/openstack/governance/commit/?
> id=df438a7
> > [4] http://git.openstack.org/cgit/openstack-infra/zuul-jobs/
> tree/roles/tox-siblings
>
> __
> OpenStack Development Mailing 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] [neutron][vpnaas] pike rc

[Armando M.]

On 8 August 2017 at 14:21, Takashi Yamamoto  wrote:

> On Wed, Aug 9, 2017 at 12:35 AM, Armando M.  wrote:
> >
> >
> > On 8 August 2017 at 02:34, Akihiro Motoki  wrote:
> >>
> >> I proposed a project-config patch to allow us to release neutron-vpnaas.
> >> https://review.openstack.org/#/c/491670/
> >> There is a missing configuration when neutron-vpnaas was pushed out
> >> from the neutron stadium.
> >> Once the patch is merged and -release group are setup, we can release
> >> neutron-vpnaas by ourselves.
> >
> >
> > Is this strictly necessary? I don't see these in other gerrit ACLs
> > (irrespective of whether they are part of neutron or not). My
> understanding
> > is that the release can be fully managed by the openstack release team
> once
> > a patch like [1] is posted to the openstack/releases project.
> >
> > [1] https://review.openstack.org/#/c/491429/
>
> my understanding is it's necessary for hosted projects
> because they are not managed by openstack/releases.
> unlike neutron-vpnaas, networking-hyperv is an official project. [2]
>
> [2] https://github.com/openstack/governance/commit/
> c84d0a702f536a43324212f803e0a43a640c9b56
>
>
Yes, I ended up picking up a bad example, fault of my stale knowledge of
the governance repo.


> >
> >
> >>
> >>
> >> Akihiro
> >>
> >> 2017-08-08 10:46 GMT+09:00 Takashi Yamamoto :
> >> > hi,
> >> >
> >> > can anyone with an appropriate permission create a stable/pike
> >> > and pike rc1 for neutron-vpnaas?
> >> >
> >> > stable/pike
> >> > 11.0.0.0rc1
> >> > openstack/neutron-vpnaas
> >> > 8278615c1f35f98447a3f9692a78ab45e90ee8c6
> >> >
> >> > thank you.
> >> >
> >> >
> >> > 
> __
> >> > OpenStack Development Mailing List (not for usage questions)
> >> > Unsubscribe:
> >> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >> 
> __
> >> OpenStack Development Mailing List (not for usage questions)
> >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> >
> > 
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing 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][ptl] tools for creating new releases

[Armando M.]

On 8 August 2017 at 06:30, Doug Hellmann  wrote:

> We realized recently that we haven't publicized some of the tools
> in the releases repository very well. One tool that will be useful
> this week as you prepare your release candidates is the 'new-release'
> command, which edits a deliverable file to add a new release from
> HEAD of the given branch, automatically computing the next verison
> number based on the inputs.
>
> Use the ``venv`` tox environment to run the tool, like this:
>
>$ tox -e venv -- new-release SERIES DELIVERABLE TYPE
>
> The SERIES value should be the release series, such as "pike".
>
> The DELIVERABLE value should be the deliverable name, such as
> "oslo.config" or "cinder".
>
> The TYPE value should be one of "bugfix", "feature", "major",
> "milestone", or "rc".
>
> If the most recent release of cinder during the pike series is
> 11.0.0.0b3 then running:
>
>$ tox -e venv -- new-release pike cinder rc
>
> detects that this is the first release candidate and updates the
> file deliverables/pike/cinder.yaml with the new release 11.0.0.0rc1
> and instructions to create a new stable branch at that tag.
>
> There are some more details in the README.rst file in the releases
> repository, and as usual you'll find us in #openstack-release if you
> have questions.
>

I tried it and it works like a charm, though I noticed some harmless side
effects in that changes [1] in my patch showed up unsolicited.

Cheers,
Armando

[1]
https://review.openstack.org/#/c/491560/1/deliverables/pike/networking-bgpvpn.yaml@7



>
> Doug
>
> __
> OpenStack Development Mailing 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] [neutron][vpnaas] pike rc

[Armando M.]

On 8 August 2017 at 02:34, Akihiro Motoki  wrote:

> I proposed a project-config patch to allow us to release neutron-vpnaas.
> https://review.openstack.org/#/c/491670/
> There is a missing configuration when neutron-vpnaas was pushed out
> from the neutron stadium.
> Once the patch is merged and -release group are setup, we can release
> neutron-vpnaas by ourselves.
>

Is this strictly necessary? I don't see these in other gerrit ACLs
(irrespective of whether they are part of neutron or not). My understanding
is that the release can be fully managed by the openstack release team once
a patch like [1] is posted to the openstack/releases project.

[1] https://review.openstack.org/#/c/491429/



>
> Akihiro
>
> 2017-08-08 10:46 GMT+09:00 Takashi Yamamoto :
> > hi,
> >
> > can anyone with an appropriate permission create a stable/pike
> > and pike rc1 for neutron-vpnaas?
> >
> > stable/pike
> > 11.0.0.0rc1
> > openstack/neutron-vpnaas
> > 8278615c1f35f98447a3f9692a78ab45e90ee8c6
> >
> > thank you.
> >
> > 
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron] RC1 week

[Armando M.]

Hi neutrinos,

Today RC week starts [0] and I have prepared release patch [1]. For the
project you're liasion, please review the patch for accuracy and make sure
we tag RC1/create a stable branch with the git commit hash you are OK with.

Many thanks,
Armando

[0] https://releases.openstack.org/pike/schedule.html#p-rc1
[1] https://review.openstack.org/#/c/491560/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] [requirements][ptls] HELP! Thawing the requirements repo

[Armando M.]

On 6 August 2017 at 23:33, Akihiro Motoki  wrote:

> 2017-08-07 11:59 GMT+09:00 Tony Breeds :
> > Hi All,
> > So as you all know we've frozen the requirements repo and it will
> > stay frozen until after all the cycle-with-milestones projects have
> > stable/pike branches.  That's pretty normal.
> >
> > The last couple of cycles we've seen issues with projects that crate
> > stable/pike branches *after* we've thawed/re-opened requirements repo
> > for $next_release.
> >
> > What happens is those projects are still stabilising for pike but
> > getting requirements updates for queens.  When they *do* branch for pike
> > they quickly get a proposal-bot change which seems to take things
> > backwards.  This bad for (at least) a couple of reasons.
> >
> > 1. Those projects are testing against the wrong requirements
> > 2. You end up with a patch release for $project that radically changes
> > the requirements for $project.
>
> Yeah, totally agree the above.
>
> >
> > So I need some help identifying which projects are going to fall into
> > this scenario.  The easy to identify ones are cycle-trailing and we can
> > easily cope with that by as there are only 4 of them.  My instinct tells
> > me that many of the neutron (stadium?) and horizon-plugin projects will
> > fall into this boat.
>
> I think neutron stadium and horizon plugin projects with
> cycle-with-intermediary are potentially affected.
> They tends to ship a final release (and cut a stable branch if necessary).
>
> I think we can easily list such projects for official projects.
> It is not easy to do it for hosted projects as we don't know their
> release models.
> Do we want to take care of hosted projects?
>
>
> The following is about official projects.
>
> According to the release repo, there is no *official* neutron stadium
> projects with cycle-with-intermediary release model.
> networking-hyperv (of the winstackers project) adopts
> cycle-with-intermediary model and it looks affected.
>
> Grepping the release deliverables, *official* horizon plugin projects
> with cycle-with-intermediary models are:
>
> $ grep release-model `grep -l horizon-plugin deliverables/pike/*.yaml`
> | grep -v cycle-with-milestones | cut -d : -f 1
> deliverables/pike/cloudkitty-dashboard.yaml
> deliverables/pike/ironic-ui.yaml
> deliverables/pike/karbor-dashboard.yaml
> deliverables/pike/magnum-ui.yaml
> deliverables/pike/manila-ui.yaml
> deliverables/pike/monasca-ui.yaml
> deliverables/pike/senlin-dashboard.yaml
> deliverables/pike/solum-dashboard.yaml
> deliverables/pike/tacker-horizon.yaml
> deliverables/pike/vitrage-dashboard.yaml
> deliverables/pike/watcher-dashboard.yaml
> deliverables/pike/zun-ui.yaml
>
>
> In addition, regarding neutron stadium projects and horizon plugin
> projects,
> they also need to update the branch (from master to stable/pike) of
> neutron or horizon repo
> as they installs neutron or horizon using tox_install.sh
> (in addition to the branch of requirements repo).
> This needs to happen just after stable/pike branch of neutron or
> horizon is created.
>

The switch to cycle-with-milestone [1] for all projects under neutron
governance (except neutron-lib and ovsdbapp that are libraries) was done
with the explicit intent of avoiding the overdue cut of stable branches for
the current release, which may lead to the exact problem that Tony stated
here.

[1] https://review.openstack.org/#/c/437699/


>
> Thanks,
> Akihiro
>
> > Once we know the scope of the affected projects we can work out how to
> > thaw the requirements repo with minimum impact.  The alternative is to
> > have the requirements repo frozen for > 1 month which no one wants.
> >
> > Yours Tony.
> >
> > 
> __
> > OpenStack Development Mailing 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] [neutron] Do we still support core plugin not based on the ML2 framework?

[Armando M.]

On 22 June 2017 at 17:24, Édouard Thuleau  wrote:

> Hi Armando,
>
> I did not opened any bug report. But if a core plugin implements only
> the NeutronPluginBaseV2 interface [1] and not the NeutronDbPluginV2
> interface [2], most of the service plugins of that list will be
> initialized without any errors (only the timestamp plugin fails to
> initialize because it tries to do DB stuff in its constructor [3]).
> And all API extensions of that service plugins are listed as supported
> but none of them works. Resources are not extended (tag, revision,
> auto-allocate) or some API extensions returns 404
> (network-ip-availability or flavors).
>
> What I proposed, is to improve all that service plugins of that list
> to be able to support pluggable backend drivers (thanks to the Neutron
> service driver mechanism [4]) and uses by default a driver based on
> the Neutron DB(like it's implemented actually). That will permits core
> plugin which not implements the Neutron DB model to provide its own
> driver. But until all service plugins will be fixed, I proposed a
> workaround to disable them.
>

I would recommend against the workaround of disabling them because of the
stated rationale.

Can you open a bug report, potentially when you're ready to file a fix (or
enable someone else to take ownership of the fix)? This way we can have a
more effective conversation either on the bug report or code review.

Thanks,
Armando


>
> [1] https://github.com/openstack/neutron/blob/master/neutron/
> neutron_plugin_base_v2.py#L30
> [2] https://github.com/openstack/neutron/blob/master/neutron/
> db/db_base_plugin_v2.py#L124
> [3] https://github.com/openstack/neutron/blob/master/neutron/
> services/timestamp/timestamp_plugin.py#L32
> [4] https://github.com/openstack/neutron/blob/master/neutron/
> services/service_base.py#L27
>
> Édouard.
>
> On Thu, Jun 22, 2017 at 12:29 AM, Armando M.  wrote:
> >
> >
> > On 21 June 2017 at 17:40, Édouard Thuleau 
> wrote:
> >>
> >> Hi,
> >>
> >> @Chaoyi,
> >> I don't want to change the core plugin interface. But I'm not sure we
> >> are talking about the same interface. I had a very quick look into the
> >> tricycle code and I think it uses the NeutronDbPluginV2 interface [1]
> >> which implements the Neutron DB model. Our Contrail Neutron plugin
> >> implements the NeutronPluginBaseV2 interface [2]. Anyway,
> >> NeutronDbPluginV2 is inheriting from NeutronPluginBaseV2 [3].
> >> Thanks for the pointer to the stadium paragraph.
> >
> >
> > Is there any bug report that captures the actual error you're facing?
> Out of
> > the list of plugins that have been added to that list over time, most
> work
> > just exercising the core plugin API, and we can look into the ones that
> > don't to figure out whether we overlooked some design abstractions during
> > code review.
> >
> >>
> >>
> >> @Kevin,
> >> Service plugins loaded by default are defined in a contant list [4]
> >> and I don't see how I can remove a default service plugin to be loaded
> >> [5].
> >>
> >> [1]
> >> https://github.com/openstack/tricircle/blob/master/
> tricircle/network/central_plugin.py#L128
> >> [2]
> >> https://github.com/Juniper/contrail-neutron-plugin/blob/
> master/neutron_plugin_contrail/plugins/opencontrail/
> contrail_plugin_base.py#L113
> >> [3]
> >> https://github.com/openstack/neutron/blob/master/neutron/
> db/db_base_plugin_v2.py#L125
> >> [4]
> >> https://github.com/openstack/neutron/blob/master/neutron/
> plugins/common/constants.py#L43
> >> [5]
> >> https://github.com/openstack/neutron/blob/master/neutron/
> manager.py#L190
> >>
> >> Édouard.
> >>
> >> On Wed, Jun 21, 2017 at 11:22 AM, Kevin Benton 
> wrote:
> >> > Why not just delete the service plugins you don't support from the
> >> > default
> >> > plugins dict?
> >> >
> >> > On Wed, Jun 21, 2017 at 1:45 AM, Édouard Thuleau
> >> > 
> >> > wrote:
> >> >>
> >> >> Ok, we would like to help on that. How we can start?
> >> >>
> >> >> I think the issue I raise in that thread must be the first point to
> >> >> address and my second proposition seems to be the correct one. What
> do
> >> >> you think?
> >> >> But it will needs some time and not sure we'll be able to fix all
> >> >> service plugins loaded by default before the next Pike rel

Re: [openstack-dev] [neutron] Do we still support core plugin not based on the ML2 framework?

[Armando M.]

On 21 June 2017 at 17:40, Édouard Thuleau  wrote:

> Hi,
>
> @Chaoyi,
> I don't want to change the core plugin interface. But I'm not sure we
> are talking about the same interface. I had a very quick look into the
> tricycle code and I think it uses the NeutronDbPluginV2 interface [1]
> which implements the Neutron DB model. Our Contrail Neutron plugin
> implements the NeutronPluginBaseV2 interface [2]. Anyway,
> NeutronDbPluginV2 is inheriting from NeutronPluginBaseV2 [3].
> Thanks for the pointer to the stadium paragraph.
>

Is there any bug report that captures the actual error you're facing? Out
of the list of plugins that have been added to that list over time, most
work just exercising the core plugin API, and we can look into the ones
that don't to figure out whether we overlooked some design abstractions
during code review.


>
> @Kevin,
> Service plugins loaded by default are defined in a contant list [4]
> and I don't see how I can remove a default service plugin to be loaded
> [5].
>
> [1] https://github.com/openstack/tricircle/blob/master/
> tricircle/network/central_plugin.py#L128
> [2] https://github.com/Juniper/contrail-neutron-plugin/blob/
> master/neutron_plugin_contrail/plugins/opencontrail/
> contrail_plugin_base.py#L113
> [3] https://github.com/openstack/neutron/blob/master/neutron/
> db/db_base_plugin_v2.py#L125
> [4] https://github.com/openstack/neutron/blob/master/neutron/
> plugins/common/constants.py#L43
> [5] https://github.com/openstack/neutron/blob/master/neutron/
> manager.py#L190
>
> Édouard.
>
> On Wed, Jun 21, 2017 at 11:22 AM, Kevin Benton  wrote:
> > Why not just delete the service plugins you don't support from the
> default
> > plugins dict?
> >
> > On Wed, Jun 21, 2017 at 1:45 AM, Édouard Thuleau <
> edouard.thul...@gmail.com>
> > wrote:
> >>
> >> Ok, we would like to help on that. How we can start?
> >>
> >> I think the issue I raise in that thread must be the first point to
> >> address and my second proposition seems to be the correct one. What do
> >> you think?
> >> But it will needs some time and not sure we'll be able to fix all
> >> service plugins loaded by default before the next Pike release.
> >>
> >> I like to propose a workaround until all default service plugins will
> >> be compatible with non-DB core plugins. We can continue to load that
> >> default service plugins list but authorizing a core plugin to disable
> >> it completely with a private attribut on the core plugin class like
> >> it's done for bulk/pagination/sorting operations.
> >>
> >> Of course, we need to add the ability to report any regression on
> >> that. I think unit tests will help and we can also work on a
> >> functional test based on a fake non-DB core plugin.
> >>
> >> Regards,
> >> Édouard.
> >>
> >> On Tue, Jun 20, 2017 at 12:09 AM, Kevin Benton 
> wrote:
> >> > The issue is mainly developer resources. Everyone currently working
> >> > upstream
> >> > doesn't have the bandwidth to keep adding/reviewing the layers of
> >> > interfaces
> >> > to make the DB optional that go untested. (None of the projects that
> >> > would
> >> > use them run a CI system that reports results on Neutron patches.)
> >> >
> >> > I think we can certainly accept patches to do the things you are
> >> > proposing,
> >> > but there is no guarantee that it won't regress to being DB-dependent
> >> > until
> >> > there is something reporting results back telling us when it breaks.
> >> >
> >> > So it's not that the community is against non-DB core plugins, it's
> just
> >> > that the people developing those plugins don't participate in the
> >> > community
> >> > to ensure they work.
> >> >
> >> > Cheers
> >> >
> >> >
> >> > On Mon, Jun 19, 2017 at 2:15 AM, Édouard Thuleau
> >> > 
> >> > wrote:
> >> >>
> >> >> Oops, sent too fast, sorry. I try again.
> >> >>
> >> >> Hi,
> >> >>
> >> >> Since Mitaka release, a default service plugins list is loaded when
> >> >> Neutron
> >> >> server starts [1]. That list is not editable and was extended with
> few
> >> >> services
> >> >> [2]. But all of them rely on the Neutron DB model.
> >> >>
> >> >> If a core driver is not based on the ML2 core plugin framework or not
> >> >> based on
> >> >> the 'neutron.db.models_v2' class, all that service plugins will not
> >> >> work.
> >> >>
> >> >> So my first question is Does Neutron still support core plugin not
> >> >> based
> >> >> on ML2
> >> >> or 'neutron.db.models_v2' class?
> >> >>
> >> >> If yes, I would like to propose two solutions:
> >> >> - permits core plugin to overload the service plugin class by it's
> own
> >> >> implementation and continuing to use the actual Neutron db based
> >> >> services
> >> >> as
> >> >> default.
> >> >> - modifying all default plugin service to use service plugin driver
> >> >> framework [3], and set the actual Neutron db based implementation as
> >> >> default driver for services. That permits to core drivers not based
> on
> >> >> the
> >> >> Neutron DB to specify a driver. We can s

Re: [openstack-dev] [neutron] Do we still support core plugin not based on the ML2 framework?

[Armando M.]

On 20 June 2017 at 00:09, Kevin Benton  wrote:

> The issue is mainly developer resources. Everyone currently working
> upstream doesn't have the bandwidth to keep adding/reviewing the layers of
> interfaces to make the DB optional that go untested. (None of the projects
> that would use them run a CI system that reports results on Neutron
> patches.)
>
> I think we can certainly accept patches to do the things you are
> proposing, but there is no guarantee that it won't regress to being
> DB-dependent until there is something reporting results back telling us
> when it breaks.
>
> So it's not that the community is against non-DB core plugins, it's just
> that the people developing those plugins don't participate in the community
> to ensure they work.
>
> Cheers
>

> On Mon, Jun 19, 2017 at 2:15 AM, Édouard Thuleau <
> edouard.thul...@gmail.com> wrote:
>
>> Oops, sent too fast, sorry. I try again.
>>
>> Hi,
>>
>> Since Mitaka release, a default service plugins list is loaded when
>> Neutron
>> server starts [1]. That list is not editable and was extended with few
>> services
>> [2]. But all of them rely on the Neutron DB model.
>>
>> If a core driver is not based on the ML2 core plugin framework or not
>> based on
>> the 'neutron.db.models_v2' class, all that service plugins will not work.
>>
>
>
>> So my first question is Does Neutron still support core plugin not based
>> on ML2
>> or 'neutron.db.models_v2' class?
>>
>> If yes, I would like to propose two solutions:
>> - permits core plugin to overload the service plugin class by it's own
>> implementation and continuing to use the actual Neutron db based services
>> as
>> default.
>> - modifying all default plugin service to use service plugin driver
>> framework [3], and set the actual Neutron db based implementation as
>> default driver for services. That permits to core drivers not based on the
>> Neutron DB to specify a driver. We can see that solution was adopted in
>> the
>> networking-bgpvpn project, where can find two abstract driver classes,
>> one for
>> core driver based on Neutron DB model [4] and one used by core driver not
>> based
>> on the DB [5] as the Contrail driver [6].
>>
>
I think we're missing the the fundamental premise behind the introduction
of this map, which is that the addition of plugins to this list is done
only on the basis of the fact that the plugin being added introduces
functionality that's orthogonal to core plugins, and as such should work
with any, and not depend on internals of the core plugin implementation.

If something does break, it should be treated as a bug, rather than
allowing overloading this, because that's goes against the main rationale
for it being hard-coded.


>
>> [1] https://github.com/openstack/neutron/commit/aadf2f30f84dff3d
>> 85f380a7ff4e16dbbb0c6bb0#diff-9169a6595980d19b2649d5bedfff05ce
>> [2] https://github.com/openstack/neutron/blob/master/neutron/plu
>> gins/common/constants.py#L43
>> [3] https://github.com/openstack/neutron/blob/master/neutron/ser
>> vices/service_base.py#L27
>> [4] https://github.com/openstack/networking-bgpvpn/blob/master/n
>> etworking_bgpvpn/neutron/services/service_drivers/driver_api.py#L226
>> [5] https://github.com/openstack/networking-bgpvpn/blob/master/n
>> etworking_bgpvpn/neutron/services/service_drivers/driver_api.py#L23
>> [6] https://github.com/Juniper/contrail-neutron-plugin/blob/mast
>> er/neutron_plugin_contrail/plugins/opencontrail/networking_
>> bgpvpn/contrail.py#L36
>>
>> Regards,
>> Édouard.
>>
>> On Mon, Jun 19, 2017 at 10:47 AM, Édouard Thuleau
>>  wrote:
>> > Hi,
>> > Since Mitaka release [1], a default service plugins list is loaded
>> > when Neutron server starts. That list is not editable and was extended
>> > with few services [2]. But none of th
>> >
>> > [1] https://github.com/openstack/neutron/commit/aadf2f30f84dff3d
>> 85f380a7ff4e16dbbb0c6bb0#diff-9169a6595980d19b2649d5bedfff05ce
>> > [2] https://github.com/openstack/neutron/blob/master/neutron/plu
>> gins/common/constants.py#L43
>>
>> 
>> __
>> 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] [release][barbican][congress][designate][neutron][zaqar] missing pike-2 milestone releases

[Armando M.]

On 9 June 2017 at 06:36, Doug Hellmann  wrote:

> We have several projects with deliverables following the
> cycle-with-milestones release model without pike 2 releases. Please
> check the list below and prepare those release requests as soon as
> possible. Remember that this milestone is date-based, not feature-based,
> so unless your gate is completely broken there is no reason to wait to
> tag the milestone.
>
> Doug
>
> barbican
> congress
> designate-dashboard
> designate
> networking-bagpipe
> networking-bgpvpn
> networking-midonet
> networking-odl
> networking-ovn
> networking-sfc
> neutron-dynamic-routing
> neutron-fwaas
> neutron
>

I was waiting on the PTL ack [1], we should be good to go now.

[1] https://review.openstack.org/#/c/471414/


> zaqar-ui
> zaqar
>
> __
> OpenStack Development Mailing 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] [nova] [glance] [cinder] [neutron] - Global Request ID progress

[Armando M.]

On 6 June 2017 at 04:49, Sean Dague  wrote:

> Some good progress has been made so far on Global Request ID work in the
> core IaaS layer, here is where we stand.
>
> STATUS
>
> oslo.context / oslo.middleware - everything DONE
>
> devstack logging additional global_request_id - DONE
>
> cinder:
> - client supports global_request_id - DONE
> - Cinder calls Nova with global_request_id - TODO (waiting on Novaclient
> release)
> - Cinder calls Glance with global_request_id - TODO
>
> neutron:
> - client supports global_request_id - IN PROGRESS (this landed,
> released, but the neutron client release had to be blocked for unrelated
> issues).
>

The ban has been reverted [1] so this should be DONE (again)

[1] https://review.openstack.org/#/c/470047/


> - Neutron calls Nova with global_request_id - TODO (waiting on
> Novaclient release)
>
> nova:
> - Convert to oslo.middleware (to accept global_request_id) - DONE
> - client supports global_request_id - IN PROGRESS (waiting for release
> here - https://review.openstack.org/#/c/471323/)
> - Nova calls cinder with global_request_id - DONE
> - Nova calls neutron with global_request_id - TODO (waiting on working
> neutronclient release)
> - Nova calls Glance with global request id - IN PROGRESS (review needs
> final +2 here https://review.openstack.org/#/c/467242/)
>
> glance:
> - client supports global_request_id - DONE
> - Glance supports setting global_request_id - IN REVIEW
> (https://review.openstack.org/#/c/468443/) *(some debate on this).
>
>
> Everything except the last glance change is uncontroversial, and it's
> just mechanics and project management to get things through in the
> correct order.
>
>
> The Glance support for global_request_id has hit a bump in the review
> process as there is a concern that it's changing the API. Though from an
> end user perspective that's not happening, it's just changing which
> field things get logged into. We'll see if we can work through that.
>
> -Sean
>
> --
> Sean Dague
> http://dague.net
>
> __
> OpenStack Development Mailing 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] [nova][vlan trunking] Guest networking configuration for vlan trunk

[Armando M.]

On 24 May 2017 at 08:53, Robert Li (baoli)  wrote:

> Hi Kevin,
>
>
>
> In that case, I will start working on it. Should this be considered a RFE
> or a regular bug?
>

There have been discussions in the past about this [1]. The conclusion of
the discussion was: Nova should have everything it needs to expose trunk
details to guest via the metadata API/config drive and at this stage
nothing is required from the neutron end (and hence there's no point in
filing a Neutron RFE).

While notifying trunk changes to nova require a simple minor enhancement in
neutron, it seems premature to go down that path when there's no nova
scaffolding yet. Someone should then figure out how the guest itself gets
notified of trunk changes so that it can rearrange its networking stack.
That might as well be left to some special sauce added to the guest image,
though no meaningful discussion has taken place on how to crack this
particular nut.

HTH
Armando

[1] https://bugs.launchpad.net/neutron/+bug/1631371


>
> Thanks,
>
> Robert
>
>
>
> On 5/23/17, 12:12 AM, "Kevin Benton"  wrote:
>
>
>
> I think we just need someone to volunteer to do the work to expose it as
> metadata to the VM in Nova.
>
>
>
> On May 22, 2017 1:27 PM, "Robert Li (baoli)"  wrote:
>
> Hi Levi,
>
>
>
> Thanks for the info. I noticed that support in the nova code, but was
> wondering why something similar is not available for vlan trunking.
>
>
>
> --Robert
>
>
>
>
>
> On 5/22/17, 3:34 PM, "Moshe Levi"  wrote:
>
>
>
> Hi Robert,
>
> The closes thing that I know about is tagging of SR-IOV physical
> function’s VLAN tag to guests see [1]
>
> Maybe you can leverage the same mechanism to config vlan trunking in guest.
>
>
>
> [1] - https://specs.openstack.org/openstack/nova-specs/specs/
> ocata/implemented/sriov-pf-passthrough-neutron-port-vlan.html
>
>
>
>
>
> *From:* Robert Li (baoli) [mailto:ba...@cisco.com]
> *Sent:* Monday, May 22, 2017 8:49 PM
> *To:* openstack-dev@lists.openstack.org
> *Subject:* [openstack-dev] [nova][vlan trunking] Guest networking
> configuration for vlan trunk
>
>
>
> Hi,
>
>
>
> I’m trying to find out if there is support in nova (in terms of metadata
> and cfgdrive) to configure vlan trunking in the guest. In the ‘CLI usage
> example’ provided in this wiki https://wiki.openstack.org/
> wiki/Neutron/TrunkPort, it indicates:
>
>
>
> # The typical cloud image will auto-configure the first NIC (eg. eth0)
> only and not the vlan interfaces (eg. eth0.VLAN-ID).
>
> ssh VM0-ADDRESS sudo ip link add link eth0 name eth0.101 type vlan id 101
>
>
>
> I’d like to understand why the support of configuring vlan interfaces in
> the guest is not added. And should it be added?
>
>
>
> Thanks,
>
> Robert
>
>
> __
> OpenStack Development Mailing 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] [neutron][heat] - making Neutron more friendly for orchestration

[Armando M.]

On 19 May 2017 at 14:54, Clark Boylan  wrote:

> On Fri, May 19, 2017, at 02:03 PM, Kevin Benton wrote:
> > I split this conversation off of the "Is the pendulum swinging on PaaS
> > layers?" thread [1] to discuss some improvements we can make to Neutron
> > to
> > make orchestration easier.
> >
> > There are some pain points that heat has when working with the Neutron
> > API.
> > I would like to get them converted into requests for enhancements in
> > Neutron so the wider community is aware of them.
> >
> > Starting with the port/subnet/network relationship - it's important to
> > understand that IP addresses are not required on a port.
> >
> > >So knowing now that a Network is a layer-2 network segment and a Subnet
> > is... effectively a glorified DHCP address pool
> >
> > Yes, a Subnet controls IP address allocation as well as setting up
> > routing
> > for routers, which is why routers reference subnets instead of networks
> > (different routers can route for different subnets on the same network).
> > It
> > essentially dictates things related to L3 addressing and provides
> > information for L3 reachability.
>
> One thing that is odd about this is when creating a router you specify
> the gateway information using a network which is l2 not l3. Seems like
> it would be more correct to use a subnet rather than a network there?
>

I think this is due the way external networks ended up being modeled in
neutron. I suppose we could have allowed the user to specify a subnet, so
long that it fell in the bucket of subnets that belong to a router:external
network.


>
> Clark
>
> __
> OpenStack Development Mailing 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] [neutron] multi-site forum discussion

[Armando M.]

On 12 May 2017 at 11:47, Morales, Victor  wrote:

> Armando,
>
>
>
> I noticed that Tricircle is mentioned there.  Shouldn’t be better to
> extend its current functionality or what are the things that are missing
> there?
>

Tricircle aims at coordinating independent neutron systems that exist in
separated openstack deployments. Making Neutron cell-aware will work in the
context of the same openstack deployment.


>
>
> Regards,
>
> Victor Morales
>
>
>
> *From: *"Armando M." 
> *Reply-To: *"OpenStack Development Mailing List (not for usage
> questions)" 
> *Date: *Friday, May 12, 2017 at 1:06 PM
> *To: *"OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> *Subject: *[openstack-dev] [neutron] multi-site forum discussion
>
>
>
> Hi folks,
>
>
>
> At the summit we had a discussion on how to deploy a single neutron system
> across multiple geographical sites [1]. You can find notes of the
> discussion on [2].
>
>
>
> One key requirement that came from the discussion was to make Neutron more
> Nova cells friendly. I filed an RFE bug [3] so that we can move this
> forward on Lauchpad.
>
>
>
> Please, do provide feedback in case I omitted some other key takeaway.
>
>
>
> Thanks,
>
> Armando
>
>
>
> [1] https://www.openstack.org/summit/boston-2017/summit-
> schedule/events/18757/neutron-multi-site
>
> [2] https://etherpad.openstack.org/p/pike-neutron-multi-site
>
> [3] https://bugs.launchpad.net/neutron/+bug/1690425
>
> __
> OpenStack Development Mailing 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] [neutron]

[Armando M.]

Hi folks,

At the summit we had a discussion on how to expand get-me-a-network [1]. A
few main points were collected during the session:

* Make get-me-a-network work with Horizon;
* Make get-me-a-network able to auto-assign floating IPs;
* Make get-me-a-network able to work with any network topology;
* Make get-me-a-network able to deal with NetworkAmbiguous error.

Link to bug reports [2,3,4,5] are below to move these forward on
Launchpad. Please,
do provide feedback in case I omitted some other key takeaway.

Thanks,
Armando

[1] https://etherpad.openstack.org/p/pike-neutron-gman
[2] https://bugs.launchpad.net/horizon/+bug/1690433
[3] https://bugs.launchpad.net/neutron/+bug/1042049
[4] https://bugs.launchpad.net/neutron/+bug/1690438
[5] https://bugs.launchpad.net/neutron/+bug/1690439
__
OpenStack Development Mailing 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] [neutron] diagnostics

[Armando M.]

Hi folks,

At the summit we had a forum session [1] to gather feedback on the current
diagnostics proposal [2] and help the neutron developer team drive the
first implementation of the API proposal.

Two main points were brought for discussion:

1) which diagnostics checks to provide to start with;
2) how to implement such checks.

Reachability seems to be on the top of the list, ie. the ability to
establish connectivity between two endpoints. The other one was to be
friendly to operators, in that they may not necessarily want to write
python code in order to add more checks to the platform. The idea is to
define on a set of variables to be exposed to the check function and let
this be written in any language of choice.

Please, do provide feedback in case I omitted some other key takeaway.

Thanks,
Armando

[1] https://etherpad.openstack.org/p/pike-neutron-diagnostics
[2]
http://specs.openstack.org/openstack/neutron-specs/specs/pike/diagnostics.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] [neutron] multi-site forum discussion

[Armando M.]

Hi folks,

At the summit we had a discussion on how to deploy a single neutron system
across multiple geographical sites [1]. You can find notes of the
discussion on [2].

One key requirement that came from the discussion was to make Neutron more
Nova cells friendly. I filed an RFE bug [3] so that we can move this
forward on Lauchpad.

Please, do provide feedback in case I omitted some other key takeaway.

Thanks,
Armando

[1]
https://www.openstack.org/summit/boston-2017/summit-schedule/events/18757/neutron-multi-site
[2] https://etherpad.openstack.org/p/pike-neutron-multi-site
[3] https://bugs.launchpad.net/neutron/+bug/1690425
__
OpenStack Development Mailing 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] keeping on top of neutron reviews

[Armando M.]

On 20 April 2017 at 17:20, Kevin Benton  wrote:

> Thanks! Do you have the link to where that script lives? It would be good
> to have it in the neutron devref.
>

It's here:

https://docs.openstack.org/developer/neutron/devref/
effective_neutron.html#code-review



>
> On Thu, Apr 20, 2017 at 9:23 AM, Rossella Sblendido 
> wrote:
>
>> Hi all,
>>
>> I'd like to remind that there's a dashboard that it's populated every
>> day showing patches that are fixes for high/critical bugs, approved
>> blueprints and RFE. You can find it here [1] under "Gerrit Dashboard
>> links"
>>
>> cheers,
>>
>> Rossella
>>
>> [1] http://status.openstack.org/reviews/
>>
>> On 04/18/2017 12:45 AM, Kevin Benton wrote:
>> > Hello Neutron reviewers,
>> >
>> > Please keep an eye on the review links
>> > in https://docs.openstack.org/developer/neutron/dashboards/index.html
>> as
>> > part of your review routine.
>> >
>> > I went through and reviewed a lot of old patches over the weekend so if
>> > we keep on top of that list it shouldn't get out of hand.
>> >
>> > Cheers,
>> > Kevin Benton
>> >
>> >
>> > 
>> __
>> > 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
>> >
>>
>> 
>> __
>> 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] [neutron][networking-l2gw] openstack vtep setup missing docs

[Armando M.]

On 4 April 2017 at 07:53, Saverio Proto  wrote:

> Hello Armando,
>
> I managed to implement the L2GW setup purely in software, without an
> hardware appliance.
>
> I documented in the README file, please look at this review
> https://review.openstack.org/453209


Nice job!


>
>
> I have a question: do we have a name for this node where the actually
> bridging happens between a VXLAN tenant network and a physical L2 network ?
> Is it okay to call it the l2gw agent ?
>

Historically this was called l2gw agent (node). You can find references in
[1,2]


>
> The l2gw plugin it self runs on the controller, so also the
> neutron-l2gw-plugin agent runs on the controller.
>
> I think it necessary to clarify this naming, because before trying the
> software I did the mistake of thinking that the neutron-l2gw-agent had
> to run on the switch where the actual briding happens.
>

The l2gw agent uses solely OVSDB to interact to the server and as such it
can run anywhere. In fact, in Arista's POC video [3] (credit to Sukhdev),
the demo setup shows this in more details.

Cheers,
Armando

[1]
https://github.com/openstack/networking-l2gw/blob/master/doc/source/images/L2GW_deployment.png
[2]
https://github.com/openstack/networking-l2gw/blob/master/specs/kilo/l2-gateway-api-implementation.rst
[3] https://www.youtube.com/watch?v=WpilpgPnYrE


>
> thank you
>
> Saverio
>
>
>
>
> On 30/03/17 18:40, Armando M. wrote:
> >
> >
> > On 30 March 2017 at 08:47, Saverio Proto  > <mailto:saverio.pr...@switch.ch>> wrote:
> >
> > Hello,
> >
> > I am trying to use the neutron l2gw plugin, but I am not using a bare
> > metal switch to bridge.
> >
> > I am using a server with Openvswitch.
> >
> >
> > I am not aware of any effort to implement L2GW purely in software, in
> > fact this was one key missing pieces that prevented the project to have
> > CI solely dealt with the upstream infra resources. Perhaps OVN may come
> > to the rescue here, I recall at some point the team was looking at the
> > L2GW API.
> >
> > Thanks,
> > Armando
> >
> >
> >
> > Following this documentation:
> >
> > http://networkop.co.uk/blog/2016/05/21/neutron-l2gw/
> > <http://networkop.co.uk/blog/2016/05/21/neutron-l2gw/>
> >
> > At one point there is this command:
> >
> > sudo vtep-bootstrap L5 10.0.0.5 192.168.91.21 --no_encryption
> >
> > This vtep-bootstrap is specific for Cumulux Linux
> >
> > Anybody has documentation with normal vtep-ctl commands ?
> >
> > So far on the Ubuntu server I did the following:
> >
> > apt-get install openvswitch-vtep
> > ovsdb-tool create /etc/openvswitch/vtep.db
> > /usr/share/openvswitch/vtep.ovsschema
> >
> > Anyone has more complete documentation ?
> >
> > I did not understand if the vtep-openvswitch controlled by the l2gw
> > plugin will make vxlan tunnels to all the compute nodes, to bridge
> the
> > tenant network with a physical l2 network ? Or all this traffic has
> to
> > pass to the network node also because the vtep openvswitch is not
> able
> > to talk to the compute nodes ?
> >
> > thank you
> >
> > Saverio
> >
> >
> > --
> > SWITCH
> > Saverio Proto, Peta Solutions
> > Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland
> > phone +41 44 268 15 15, direct +41 44 268 1573
> > saverio.pr...@switch.ch <mailto:saverio.pr...@switch.ch>,
> > http://www.switch.ch
> >
> > http://www.switch.ch/stories
> >
> > 
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > <http://openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe>
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > <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
> >
>
>
> --
> SWITCH
> Saverio Proto, Peta Solutions
> Werdstrasse 2, P.O. Box

Re: [openstack-dev] [neutron][networking-l2gw] openstack vtep setup missing docs

[Armando M.]

On 30 March 2017 at 08:47, Saverio Proto  wrote:

> Hello,
>
> I am trying to use the neutron l2gw plugin, but I am not using a bare
> metal switch to bridge.
>
> I am using a server with Openvswitch.
>

I am not aware of any effort to implement L2GW purely in software, in fact
this was one key missing pieces that prevented the project to have CI
solely dealt with the upstream infra resources. Perhaps OVN may come to the
rescue here, I recall at some point the team was looking at the L2GW API.

Thanks,
Armando


>
> Following this documentation:
>
> http://networkop.co.uk/blog/2016/05/21/neutron-l2gw/
>
> At one point there is this command:
>
> sudo vtep-bootstrap L5 10.0.0.5 192.168.91.21 --no_encryption
>
> This vtep-bootstrap is specific for Cumulux Linux
>
> Anybody has documentation with normal vtep-ctl commands ?
>
> So far on the Ubuntu server I did the following:
>
> apt-get install openvswitch-vtep
> ovsdb-tool create /etc/openvswitch/vtep.db
> /usr/share/openvswitch/vtep.ovsschema
>
> Anyone has more complete documentation ?
>
> I did not understand if the vtep-openvswitch controlled by the l2gw
> plugin will make vxlan tunnels to all the compute nodes, to bridge the
> tenant network with a physical l2 network ? Or all this traffic has to
> pass to the network node also because the vtep openvswitch is not able
> to talk to the compute nodes ?
>
> thank you
>
> Saverio
>
>
> --
> SWITCH
> Saverio Proto, Peta Solutions
> Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland
> phone +41 44 268 15 15, direct +41 44 268 1573
> saverio.pr...@switch.ch, http://www.switch.ch
>
> http://www.switch.ch/stories
>
> __
> OpenStack Development Mailing 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] [neutron][networking-l2gw] database tables for neutron l2gw plugin

[Armando M.]

On 30 March 2017 at 08:08, Saverio Proto  wrote:

> Hello,
>
> I am testing the neutron l2gw in our staging env.
>
> Because I cant redeploy everything, to retry the installation of the
> l2gw, to clean the database I drop the following tables from the neutron
> database:
>
> drop table physical_ports;
> drop table physical_locators;
> drop table physical_switches;
> drop table logical_switches;
> drop table ucast_macs_remotes;
> drop table ucast_macs_locals;
> drop table vlan_bindings;
> drop table pending_ucast_macs_remotes;
> drop table l2gatewayinterfaces;
> drop table l2gatewaydevices;
> drop table l2gatewayconnections;
> drop table l2gateways;
> drop table l2gw_alembic_version;
>
> I would strongly suggest to have a common prefix like l2gw_ for all the
> tables that belong to the same neutron plugin.
>
> How can I figure out if I missed a table without reading all the code ?
>

There's no written rule to prefix tables with formal labels. IMO it would
largely fail as a rule in practice even if we wrote one down. Have you
considered taking a backup of your DB prior to the migration so that you
can restore from it?

Thanks,
Armando


> Thank you
>
> Saverio
>
>
>
> --
> SWITCH
> Saverio Proto, Peta Solutions
> Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland
> phone +41 44 268 15 15, direct +41 44 268 1573
> saverio.pr...@switch.ch, http://www.switch.ch
>
> http://www.switch.ch/stories
>
> __
> OpenStack Development Mailing 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] Is there some way to run specific unittest in neutron?

[Armando M.]

On 22 March 2017 at 22:19, Sam  wrote:

> Hi all,
>
> I'm working on neutron, I add some code into ovs_neutron_agent.py, and I
> extend test_ovs_neutron_agent.py.
>
> Is there some way to run test_ovs_neutron_agent.py or run related module
> only?
>
> Thank you.
>

You should find your answer in [1].

[1]
https://docs.openstack.org/developer/neutron/devref/development.environment.html#running-individual-tests


>
> __
> OpenStack Development Mailing 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] [neutron] - adjusting Monday IRC meeting time and drivers meeting time

[Armando M.]

On 22 March 2017 at 21:39, Armando M.  wrote:

>
>
> On 21 March 2017 at 02:00, Kevin Benton  wrote:
>
>> Hi everyone,
>>
>> The recent DST switch has caused several conflicts for the Monday IRC
>> meeting time and the drivers meeting time.
>>
>> I am going to adjust the Monday meeting time to 1 hour earlier[1] and the
>> drivers meeting time to 6 hours earlier to (1600 UTC).
>>
>> The Monday meeting will now be on openstack-meeting-4 to work around
>> other conflicts!
>>
>> https://review.openstack.org/447961
>>
>
> I would have liked some discussion before approving this, I am afraid I
> can make neither meetings on a regular basis.
>

Proposed revert in [1] to give time and opportunity to comment on whether
the new time works for the majority of folks.

[1] https://review.openstack.org/#/c/448886/


>
>
>>
>> Cheers,
>> Kevin Benton
>>
>> 
>> __
>> 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

Re: [openstack-dev] [neutron] - adjusting Monday IRC meeting time and drivers meeting time

[Armando M.]

On 21 March 2017 at 02:00, Kevin Benton  wrote:

> Hi everyone,
>
> The recent DST switch has caused several conflicts for the Monday IRC
> meeting time and the drivers meeting time.
>
> I am going to adjust the Monday meeting time to 1 hour earlier[1] and the
> drivers meeting time to 6 hours earlier to (1600 UTC).
>
> The Monday meeting will now be on openstack-meeting-4 to work around other
> conflicts!
>
> https://review.openstack.org/447961
>

I would have liked some discussion before approving this, I am afraid I can
make neither meetings on a regular basis.


>
> Cheers,
> Kevin Benton
>
> __
> OpenStack Development Mailing 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] [neutron] [infra] Depends-on tag effect

[Armando M.]

On 8 March 2017 at 07:39, Hirofumi Ichihara  wrote:

>
>
> On 2017/03/08 23:59, Andreas Jaeger wrote:
>
>> On 2017-03-08 15:40, ZZelle wrote:
>>
>>> Hi,
>>>
>>> iiuc, neutron uses a released version of neutron-lib not neutron-lib
>>> master ... So the change should depends on a change in requirements repo
>>> incrementing neutron-lib version
>>>
>> This is documented also at - together with some other caveats:
>>
>> https://docs.openstack.org/infra/manual/developers.html#limi
>> tations-and-caveats
>>
> Thank you for the pointer. I understand.


You can do the reverse as documented in [1]: i.e. file a dummy patch
against neutron-lib that pulls in both neutron's and neutron-lib changes.
One example is [2]

[1] https://docs.openstack.org/developer/neutron-lib/review-guidelines.html
[2] https://review.openstack.org/#/c/386846/


>
> Hirofumi
>
>
>
>>
>> Note a depends-on requirements won't work either - you really need to
>> release it. Or you need to change the test to pull neutron-lib from
>> source,
>>
>> Andreas
>>
>>> On Wed, Mar 8, 2017 at 3:16 PM, Hirofumi Ichihara
>>> >> > wrote:
>>>
>>>  Hi,
>>>
>>>  I thought that we can post neutron patch depending on neutron-lib
>>>  patch under review.
>>>  However, I saw it doesn't work[1, 2]. In the patches, neutron
>>>  patch[1] has Depends-on tag with neutron-lib patch[2] but the pep8
>>>  and unit test fails because the test doesn't use the neutron-lib
>>> patch.
>>>
>>>  Please correct me if it's my misunderstanding.
>>>
>>>  [1]: https://review.openstack.org/#/c/424340/
>>>  
>>>  [2]: https://review.openstack.org/#/c/424868/
>>>  
>>>
>>>  Thanks,
>>>  Hirofumi
>>>
>>>
>>>
>>>  ___
>>> ___
>>>  OpenStack Development Mailing List (not for usage questions)
>>>  Unsubscribe:
>>>  openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>>  >> 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.op
>>> enstack.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] [neutron][sfc][release] stable/ocata version

[Armando M.]

On 5 March 2017 at 23:24, Ihar Hrachyshka  wrote:

> With https://review.openstack.org/#/c/437699/ in, stadium projects
> will no longer have any other option but to follow the common
> schedule. That change is new for Pike+ so we may still see some issues
> with Ocata release process.
>

The stable branch for Ocata is being cut in [1]. Everything else that
targets Pike is a go.

[1] https://review.openstack.org/#/c/439200/


> Ihar
>
> On Sun, Mar 5, 2017 at 8:03 PM, Jeffrey Zhang 
> wrote:
> > Add [release] tag in subject.
> >
> > Do not follow the OpenStack release schedule will cause lots of issues.
> Like
> > requirements changes, patches is merged which should not be merged into
> > stable.
> >
> > It also may break the deploy project release schedule( like Kolla will
> not
> > be
> > released until sfc release ocata branch and tag ).
> >
> > I hope sfc team could follow the OpenStack release schedule, even though
> it
> > may
> > cause some cherry-pick, but it is safer and how OpenStack project live.
> >
> >
> > On Sun, Mar 5, 2017 at 3:44 PM, Gary Kotton  wrote:
> >>
> >> Please note that things are going to start to get messy now – there are
> >> changes in neutron that break master and these will affect the cutting
> of
> >> the stable version. One example is https://review.openstack.org/441654
> >>
> >>
> >>
> >> So I suggest cutting a stable ASAP and then cherrypicking patches
> >>
> >>
> >>
> >> From: Gary Kotton 
> >> Reply-To: OpenStack List 
> >> Date: Sunday, March 5, 2017 at 9:36 AM
> >>
> >>
> >> To: OpenStack List 
> >> Subject: Re: [openstack-dev] [neutron][sfc] stable/ocata version
> >>
> >>
> >>
> >> Thanks!
> >>
> >>
> >>
> >> From: Jeffrey Zhang 
> >> Reply-To: OpenStack List 
> >> Date: Sunday, March 5, 2017 at 9:12 AM
> >> To: OpenStack List 
> >> Subject: Re: [openstack-dev] [neutron][sfc] stable/ocata version
> >>
> >>
> >>
> >> This is talked in [0]. sfc team said
> >>
> >>
> >>
> >> > we will pull a stable/ocata branch around end of Feb or early March
> the
> >> > latest.
> >>
> >>
> >>
> >> [0]
> >> http://lists.openstack.org/pipermail/openstack-dev/2017-Febr
> uary/112580.html
> >>
> >>
> >>
> >> On Sun, Mar 5, 2017 at 3:01 PM, Gary Kotton  wrote:
> >>
> >> Hi,
> >>
> >> We are pretty blocked at the moment with our gating on stable/ocata.
> This
> >> is due to the fact that there is no networking-sfc version tagged for
> ocata.
> >>
> >> Is there any ETA for this?
> >>
> >> Thanks
> >>
> >> Gary
> >>
> >>
> >>
> >>
> >> 
> __
> >> 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
> >>
> >>
> >>
> >>
> >>
> >> --
> >>
> >> Regards,
> >>
> >> Jeffrey Zhang
> >>
> >> Blog: http://xcodest.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
> >>
> >
> >
> >
> > --
> > Regards,
> > Jeffrey Zhang
> > Blog: http://xcodest.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
> >
>
> __
> OpenStack Development Mailing 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] [neutron] networking-ofagent officially

[Armando M.]

Hi neutrinos,

As stated a while back [1], it's about time to pull the trigger on the
retirement of networking-ofagent. Please find the retirement patches
available at [2]. Users of this repo must use the neutron OVS agent with
of_interface set to native to retain the same level of capability.

Cheers,
Armando

[1] http://lists.openstack.org/pipermail/openstack-dev/
2016-September/104676.html
[2] https://review.openstack.org/#/q/topic:ofagent+status:open
__
OpenStack Development Mailing 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] [neutron] Ocata postmortem

[Armando M.]

Hi folks,

Now that Ocata is officially releases, I'd like to get a moment of your
time to double check our postmortem document [1], and provide as much
information as you can on the state of work assigned to you or work you
have been involved with during the Ocata timeframe.

Your old PTL and consumers/watchers of our project will be immensely
grateful.

Cheers,
Armando

[1] https://review.openstack.org/#/c/425990/
__
OpenStack Development Mailing 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] Alternative approaches for L3 HA

[Armando M.]

On 13 February 2017 at 23:23, Kosnik, Lubosz 
wrote:

> So from my perspective I can tell that problem is completely in
> architecture and even without something outside of Neutron we cannot solve
> that.
> Two releases ago I started to work on hardening that feature but all my
> ideas was killed by Armando and Assaf. The decided that adding outside
> dependency will open the doors for a new bugs from dependencies into
> Neutron [1].
>

I am pretty sure it wasn't our intentions to 'kill' your ideas, but
otherwise set you on the right path for fixing the bug. I still believe
that a complete and robust L3 HA solution cannot be built solely with
Neutron alone, and that's what I was trying to say with the comment
referenced below.


>
> You need to know that there are two outstanding bugs in this feature.
> There is a internal and outside connectivity split brain. [2] this patch
> made by me is “fixing” part of the problem. It allows you specify
> additional tests to verify connectivity from router to GW.
> Also there is a problem with connectivity between network nodes. It’s more
> problematic and like you said it’s unsolvable in my opinion without using
> external mechanism.
>
> If there will be any need to help with anything I would love to help with
> sharing my knowledge about this feature and what exactly is not working. If
> anyone needs any help with anything about this please ping me on email or
> IRC.
>
> [1] https://bugs.launchpad.net/neutron/+bug/1375625/comments/31
> [2] https://review.openstack.org/#/c/273546/
>
> Lubosz
>
> On Feb 13, 2017, at 4:10 AM, Anna Taraday 
> wrote:
>
> To avoid dependency of data plane on control plane it is possible to
> deploy a separate key-value storage cluster on data plane side, using the
> same network nodes.
> I'm proposing to make some changes to enable experimentation in this
> field, we are yet to come up with any other concrete solution.
>
> On Mon, Feb 13, 2017 at 2:01 PM  wrote:
>
>> Hi,
>>
>>
>>
>>
>>
>> We also operate using Juno with the VRRP HA implementation and at had to
>> patch through several bugs before getting to the Mitaka release.
>>
>> An pluggable, drop-in alternative would be highly appreciated. However
>> our experience has been that the decoupling of VRRP from the control plane
>> is actually a benefit as when the control plane is down the traffic is not
>> affected.
>>
>> In a solution where the L3 HA implementation becomes tied to the
>> availability of the control plane (etcd cluster or any other KV store) then
>> an operator would have to account for extra failure scenarios for the KV
>> store which would affect multiple routers than the outage of a single L3
>> node which is the case we usually have to account now.
>>
>>
>>
>>
>>
>> Just my $.02
>>
>>
>>
>> Cristian
>>
>>
>>
>> *From:* Anna Taraday [mailto:akamyshnik...@mirantis.com]
>> *Sent:* Monday, February 13, 2017 11:45 AM
>> *To:* OpenStack Development Mailing List (not for usage questions)
>> *Subject:* Re: [openstack-dev] [Neutron] Alternative approaches for L3 HA
>>
>>
>>
>> In etcd for each HA router we can store key which will identify which
>> agent is active. L3 agents will "watch" this key.
>> All these tools have leader election mechanism which can be used to get
>> agent which is active for current HA router.
>>
>>
>>
>> On Mon, Feb 13, 2017 at 7:02 AM zhi  wrote:
>>
>> Hi, we are using L3 HA in our production environment now. Router
>> instances communicate to each other by VRRP protocol. In my opinion,
>> although VRRP is a control plane thing, but the real VRRP traffic is using
>> data plane nic so that router namespaces can not talk to each other
>> sometimes when the  data plan is busy. If we were used etcd (or other),
>> does every router instance register one "id" in etcd ?
>>
>>
>>
>>
>>
>> Thanks
>>
>> Zhi Chang
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
>> unsubscribe
>> 
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> --
>>
>> Regards,
>> Ann Taraday
>>
>> _
>>
>> Ce message et ses pieces jointes peuvent contenir des informations 
>> confidentielles ou privilegiees et ne doivent donc
>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu 
>> ce message par erreur, veuillez le signaler
>> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
>> electroniques etant susceptibles d'alteration,
>> Orange decline toute responsabilite si ce message a ete altere, deforme ou 
>> falsifie. Merci.
>>
>> This message and its attachments may contain confidential or privileged 
>> information that may be protected by law;
>> they should not b

Re: [openstack-dev] [release][all] HELP NEEDED: test failures blocking requirements ocata branch and opening of pike

[Armando M.]

On 9 February 2017 at 05:16, Doug Hellmann  wrote:

> Excerpts from Doug Hellmann's message of 2017-02-08 23:54:06 -0500:
> > The patch to update the XStatic package versions [1] is blocked by a
> > patch to remove nova-docker from the requirements project sync list [2],
> > which is in turn running into issues in the
> > gate-grenade-dsvm-neutron-multinode-ubuntu-xenial job [3].
> >
> > We need some folks who understand these tests and the related
> > projects (nova, cinder, and neutron based on a cursory review of
> > the failed tests) to help with debugging and fixes.
> >
> > Doug
> >
> > [1] https://review.openstack.org/#/c/429753
> > [2] https://review.openstack.org/#/c/431221
> > [3] http://logs.openstack.org/21/431221/1/gate/gate-grenade-
> dsvm-neutron-multinode-ubuntu-xenial/67dd8a4/logs/grenade.sh.txt.gz
> >
>
> These patches landed overnight, so we are ready to proceed. It's not
> clear if there was a fix involved or just the magic of recheck, so if
> you had a hand in helping please post details.
>
>
I had a look at this one but I am baffled by some of the log outputs.
Requests for spawning faulty instances never make to nova-compute service,
but there's no clear smoking gun as to why this happens. I was looking for
oom-kills, but there was no sign of it either.


> Doug
>
> __
> OpenStack Development Mailing 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] [All] IRC Mishaps

[Armando M.]

On 9 February 2017 at 07:43, Morales, Victor 
wrote:

> One  of my favorites is the usage of #undo command during the meetings for
> fixing a quick copy & paste link.  Should be necessary to include more
> information in this wiki entry[1]
>

Yes, I can't count the number of times during a meeting I typed:

#link v
#undo

...that reminds I should get a better keyboard.


>
> Victor Morales
> irc: electrocucaracha
>
> [1] https://wiki.openstack.org/wiki/UsingIRC
>
> From: Rob C 
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Date: Thursday, February 9, 2017 at 6:57 AM
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Subject: Re: [openstack-dev] [All] IRC Mishaps
>
> #startmeeting in the wrong channel
>
> #startmeeting in the right channel but at the wrong time
>
> #startmeeting in the right channel and at the right time but someone else
> already started it
>
> I'm basically a pro at meetings.
>
> On Thu, Feb 9, 2017 at 1:14 AM, Lana Brindley 
> wrote:
>
>> On 09/02/17 06:36, Kendall Nelson wrote:
>> > Hello All!
>> >
>> > So I am sure we've all seen it: people writing terminal commands into
>> our project channels, misusing '/' commands, etc. But have any of you
>> actually done it?
>> >
>> > If any of you cores, ptls or other upstanding members of our wonderful
>> community have had one of these embarrassing experiences please reply! I am
>> writing an article for the SuperUser trying to make us all seem a little
>> more human to people new to the community and new to using IRC. It can be
>> scary asking questions to such a large group of smart people and its even
>> more off putting when we make mistakes in front of them.
>> >
>> > So please share your stories!
>>
>> What about the one where you're conducting a private conversation in one
>> window, and watching a group chat in another one, and then drop some deeply
>> personal (or embarrassing!) content in the group chat instead the PM ;)
>>
>> L
>>
>> --
>> Lana Brindley
>> Technical Writer
>> Rackspace Cloud Builders Australia
>> http://lanabrindley.com
>>
>>
>> 
>> __
>> 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] [neutron] [stadium] subprojects on independent release cycle

[Armando M.]

On 8 February 2017 at 09:13, Thomas Morin  wrote:

> Hi Armando,
>
> As far as networking-bgpvpn and networking-bagpipe are concerned, the plan
> is to do like we've been doing for the past 2 releases, which is to cut a
> branch and make a release not too far after Openstack.
> The date of March 10th looks reasonable as a target, and we'll stick to
> that.
>
>
Excellent,

thanks for the update.

Cheers,
Armando

Best,
>
> -Thomas
>
>
>
> On 2 February 2017 at 16:09, Armando M.  wrote:
>
>> Hi neutrinos,
>>
>> I have put a number of patches in the merge queue for a few sub-projects.
>> We currently have a number of these that are on an independent release
>> schedule. In particular:
>>
>>- networking-bagpipe
>>- networking-bgpvpn
>>- networking-midonet
>>- networking-odl
>>- networking-sfc
>>
>> Please make sure that between now and March 10th [1], you work to prepare
>> at least one ocata release that works with neutron's [2] and cut a stable
>> branch before than. That would incredibly help consumers who are interested
>> in assembling these bits together and start testing ocata as soon as it's
>> out.
>>
>> Your collaboration is much appreciated.
>>
>> Many thanks,
>> Armando
>>
>
> Hi neutrinos,
>
> I did not hear anything back from the liaisons of the above mentioned
> project over the past few days. Can you clarify your plans for cutting an
> Ocata release?
>
> Thanks,
> Armando
>
>
>> [1] https://releases.openstack.org/ocata/schedule.html
>> [2] https://review.openstack.org/#/c/428474/
>>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] [stadium] subprojects on independent release cycle

[Armando M.]

On 2 February 2017 at 16:09, Armando M.  wrote:

> Hi neutrinos,
>
> I have put a number of patches in the merge queue for a few sub-projects.
> We currently have a number of these that are on an independent release
> schedule. In particular:
>
>- networking-bagpipe
>- networking-bgpvpn
>- networking-midonet
>- networking-odl
>- networking-sfc
>
> Please make sure that between now and March 10th [1], you work to prepare
> at least one ocata release that works with neutron's [2] and cut a stable
> branch before than. That would incredibly help consumers who are interested
> in assembling these bits together and start testing ocata as soon as it's
> out.
>
> Your collaboration is much appreciated.
>
> Many thanks,
> Armando
>

Hi neutrinos,

I did not hear anything back from the liaisons of the above mentioned
project over the past few days. Can you clarify your plans for cutting an
Ocata release?

Thanks,
Armando


> [1] https://releases.openstack.org/ocata/schedule.html
> [2] https://review.openstack.org/#/c/428474/
>
__
OpenStack Development Mailing 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] [neutron] [stadium] subprojects on independent release cycle

[Armando M.]

Hi neutrinos,

I have put a number of patches in the merge queue for a few sub-projects.
We currently have a number of these that are on an independent release
schedule. In particular:

   - networking-bagpipe
   - networking-bgpvpn
   - networking-midonet
   - networking-odl
   - networking-sfc

Please make sure that between now and March 10th [1], you work to prepare
at least one ocata release that works with neutron's [2] and cut a stable
branch before than. That would incredibly help consumers who are interested
in assembling these bits together and start testing ocata as soon as it's
out.

Your collaboration is much appreciated.

Many thanks,
Armando

[1] https://releases.openstack.org/ocata/schedule.html
[2] https://review.openstack.org/#/c/428474/
__
OpenStack Development Mailing 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] [neutron] Drivers meeting cancelled today

[Armando M.]

Hi,

With the release coming up, it's best to spend the time to polish what we
have.

Sorry for the short notice.

Thanks,
Armando
__
OpenStack Development Mailing 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] [gate] [all] openstack services footprint lead to oom-kill in the gate

[Armando M.]

On 2 February 2017 at 13:36, Ihar Hrachyshka  wrote:

> On Thu, Feb 2, 2017 at 7:44 AM, Matthew Treinish 
> wrote:
> > Yeah, I'm curious about this too, there seems to be a big jump in Newton
> for
> > most of the project. It might not a be a single common cause between
> them, but
> > I'd be curious to know what's going on there.
>
> Both Matt from Nova as well as me and Armando suspect
> oslo.versionedobjects. Pattern of memory consumption raise somewhat
> correlates with the level of adoption for the library, at least in
> Neutron. That being said, we don't have any numbers, so at this point
> it's just pointing fingers into Oslo direction. :) Armando is going to
> collect actual memory profile.
>

I'll do my best, but I can't guarantee I can come up with something in time
for RC.


>
> Ihar
>
> __
> OpenStack Development Mailing 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] [infra] [gate] [all] openstack services footprint lead to oom-kill in the gate

[Armando M.]

On 2 February 2017 at 13:34, Ihar Hrachyshka  wrote:

> The BadStatusLine error is well known:
> https://bugs.launchpad.net/nova/+bug/1630664


That's the one! I knew it I had seen it in the past!


>
>
> Now, it doesn't mean that the root cause of the error message is the
> same, and it may as well be that lowering the number of workers
> triggered it. All I am saying is we saw that error in the past.
>
> Ihar
>
> On Thu, Feb 2, 2017 at 1:07 PM, Kevin Benton  wrote:
> > This error seems to be new in the ocata cycle. It's either related to a
> > dependency change or the fact that we put Apache in between the services
> > now. Handling more concurrent requests than workers wasn't an issue
> before.
> >
> > It seems that you are suggesting that eventlet can't handle concurrent
> > connections, which is the entire purpose of the library, no?
> >
> > On Feb 2, 2017 13:53, "Sean Dague"  wrote:
> >>
> >> On 02/02/2017 03:32 PM, Armando M. wrote:
> >> >
> >> >
> >> > On 2 February 2017 at 12:19, Sean Dague  >> > <mailto:s...@dague.net>> wrote:
> >> >
> >> > On 02/02/2017 02:28 PM, Armando M. wrote:
> >> > >
> >> > >
> >> > > On 2 February 2017 at 10:08, Sean Dague  >> > <mailto:s...@dague.net>
> >> > > <mailto:s...@dague.net <mailto:s...@dague.net>>> wrote:
> >> > >
> >> > > On 02/02/2017 12:49 PM, Armando M. wrote:
> >> > > >
> >> > > >
> >> > > > On 2 February 2017 at 08:40, Sean Dague  >> > <mailto:s...@dague.net> <mailto:s...@dague.net
> >> > <mailto:s...@dague.net>>
> >> > > > <mailto:s...@dague.net <mailto:s...@dague.net>
> >> > <mailto:s...@dague.net <mailto:s...@dague.net>>>> wrote:
> >> > > >
> >> > > > On 02/02/2017 11:16 AM, Matthew Treinish wrote:
> >> > > > 
> >> > > > > 
> >> > > > >
> >> > > > > We definitely aren't saying running a single worker
> is
> >> > how
> >> > > we recommend people
> >> > > > > run OpenStack by doing this. But it just adds on to
> >> > the
> >> > > differences between the
> >> > > > > gate and what we expect things actually look like.
> >> > > >
> >> > > > I'm all for actually getting to the bottom of this,
> but
> >> > > honestly real
> >> > > > memory profiling is needed here. The growth across
> >> > projects
> >> > > probably
> >> > > > means that some common libraries are some part of
> this.
> >> > The
> >> > > ever growing
> >> > > > requirements list is demonstrative of that. Code reuse
> >> > is
> >> > > good, but if
> >> > > > we are importing much of a library to get access to a
> >> > couple of
> >> > > > functions, we're going to take a bunch of memory
> weight
> >> > on that
> >> > > > (especially if that library has friendly auto imports
> in
> >> > top level
> >> > > > __init__.py so we can't get only the parts we want).
> >> > > >
> >> > > > Changing the worker count is just shuffling around
> deck
> >> > chairs.
> >> > > >
> >> > > > I'm not familiar enough with memory profiling tools in
> >> > python
> >> > > to know
> >> > > > the right approach we should take there to get this
> down
> >> > to
> >> > > individual
> >> > > > libraries / objects that are containing all our
> memory.
> >> > Anyone
> >> > > more
> >> > > > skilled here able to help lead the way?
> >> > > >
> >> > > >
> >> > > > From what I hea

Re: [openstack-dev] [infra] [gate] [all] openstack services footprint lead to oom-kill in the gate

[Armando M.]

On 2 February 2017 at 12:50, Sean Dague  wrote:

> On 02/02/2017 03:32 PM, Armando M. wrote:
> >
> >
> > On 2 February 2017 at 12:19, Sean Dague  > <mailto:s...@dague.net>> wrote:
> >
> > On 02/02/2017 02:28 PM, Armando M. wrote:
> > >
> > >
> > > On 2 February 2017 at 10:08, Sean Dague  s...@dague.net>
> > > <mailto:s...@dague.net <mailto:s...@dague.net>>> wrote:
> > >
> > > On 02/02/2017 12:49 PM, Armando M. wrote:
> > > >
> > > >
> > > > On 2 February 2017 at 08:40, Sean Dague  <mailto:s...@dague.net> <mailto:s...@dague.net
> > <mailto:s...@dague.net>>
> > > > <mailto:s...@dague.net <mailto:s...@dague.net>
> > <mailto:s...@dague.net <mailto:s...@dague.net>>>> wrote:
> > > >
> > > > On 02/02/2017 11:16 AM, Matthew Treinish wrote:
> > > > 
> > > > > 
> > > > >
> > > > > We definitely aren't saying running a single worker is
> how
> > > we recommend people
> > > > > run OpenStack by doing this. But it just adds on to the
> > > differences between the
> > > > > gate and what we expect things actually look like.
> > > >
> > > > I'm all for actually getting to the bottom of this, but
> > > honestly real
> > > > memory profiling is needed here. The growth across
> projects
> > > probably
> > > > means that some common libraries are some part of this.
> The
> > > ever growing
> > > > requirements list is demonstrative of that. Code reuse is
> > > good, but if
> > > > we are importing much of a library to get access to a
> > couple of
> > > > functions, we're going to take a bunch of memory weight
> > on that
> > > > (especially if that library has friendly auto imports in
> > top level
> > > > __init__.py so we can't get only the parts we want).
> > > >
> > > > Changing the worker count is just shuffling around deck
> > chairs.
> > > >
> > > > I'm not familiar enough with memory profiling tools in
> > python
> > > to know
> > > > the right approach we should take there to get this down
> to
> > > individual
> > > > libraries / objects that are containing all our memory.
> > Anyone
> > > more
> > > > skilled here able to help lead the way?
> > > >
> > > >
> > > > From what I hear, the overall consensus on this matter is to
> > determine
> > > > what actually caused the memory consumption bump and how to
> > > address it,
> > > > but that's more of a medium to long term action. In fact, to
> me
> > > this is
> > > > one of the top priority matters we should talk about at the
> > > imminent PTG.
> > > >
> > > > For the time being, and to provide relief to the gate,
> should we
> > > want to
> > > > lock the API_WORKERS to 1? I'll post something for review
> > and see how
> > > > many people shoot it down :)
> > >
> > > I don't think we want to do that. It's going to force down the
> > eventlet
> > > API workers to being a single process, and it's not super
> > clear that
> > > eventlet handles backups on the inbound socket well. I
> > honestly would
> > > expect that creates different hard to debug issues, especially
> > with high
> > > chatter rates between services.
> > >
> > >
> > > I must admit I share your fear, but out of the tests that I have
> > > executed so far in [1,2,3], the house didn't burn in a fire. I am
> > > looking for other ways to have a substantial memory saving with a
> > > relatively quick and dirty fix, but coming up empty handed thus
> far.
> > >

Re: [openstack-dev] [infra] [gate] [all] openstack services footprint lead to oom-kill in the gate

[Armando M.]

On 2 February 2017 at 12:19, Sean Dague  wrote:

> On 02/02/2017 02:28 PM, Armando M. wrote:
> >
> >
> > On 2 February 2017 at 10:08, Sean Dague  > <mailto:s...@dague.net>> wrote:
> >
> > On 02/02/2017 12:49 PM, Armando M. wrote:
> > >
> > >
> > > On 2 February 2017 at 08:40, Sean Dague  s...@dague.net>
> > > <mailto:s...@dague.net <mailto:s...@dague.net>>> wrote:
> > >
> > > On 02/02/2017 11:16 AM, Matthew Treinish wrote:
> > > 
> > > > 
> > > >
> > > > We definitely aren't saying running a single worker is how
> > we recommend people
> > > > run OpenStack by doing this. But it just adds on to the
> > differences between the
> > > > gate and what we expect things actually look like.
> > >
> > > I'm all for actually getting to the bottom of this, but
> > honestly real
> > > memory profiling is needed here. The growth across projects
> > probably
> > > means that some common libraries are some part of this. The
> > ever growing
> > > requirements list is demonstrative of that. Code reuse is
> > good, but if
> > > we are importing much of a library to get access to a couple of
> > > functions, we're going to take a bunch of memory weight on that
> > > (especially if that library has friendly auto imports in top
> level
> > > __init__.py so we can't get only the parts we want).
> > >
> > > Changing the worker count is just shuffling around deck chairs.
> > >
> > > I'm not familiar enough with memory profiling tools in python
> > to know
> > > the right approach we should take there to get this down to
> > individual
> > > libraries / objects that are containing all our memory. Anyone
> > more
> > > skilled here able to help lead the way?
> > >
> > >
> > > From what I hear, the overall consensus on this matter is to
> determine
> > > what actually caused the memory consumption bump and how to
> > address it,
> > > but that's more of a medium to long term action. In fact, to me
> > this is
> > > one of the top priority matters we should talk about at the
> > imminent PTG.
> > >
> > > For the time being, and to provide relief to the gate, should we
> > want to
> > > lock the API_WORKERS to 1? I'll post something for review and see
> how
> > > many people shoot it down :)
> >
> > I don't think we want to do that. It's going to force down the
> eventlet
> > API workers to being a single process, and it's not super clear that
> > eventlet handles backups on the inbound socket well. I honestly would
> > expect that creates different hard to debug issues, especially with
> high
> > chatter rates between services.
> >
> >
> > I must admit I share your fear, but out of the tests that I have
> > executed so far in [1,2,3], the house didn't burn in a fire. I am
> > looking for other ways to have a substantial memory saving with a
> > relatively quick and dirty fix, but coming up empty handed thus far.
> >
> > [1] https://review.openstack.org/#/c/428303/
> > [2] https://review.openstack.org/#/c/427919/
> > [3] https://review.openstack.org/#/c/427921/
>
> This failure in the first patch -
> http://logs.openstack.org/03/428303/1/check/gate-tempest-
> dsvm-neutron-full-ubuntu-xenial/71f42ea/logs/screen-n-
> api.txt.gz?level=TRACE#_2017-02-02_19_14_11_751
> looks exactly like I would expect by API Worker starvation.
>

Not sure I agree on this one, this has been observed multiple times in the
gate already [1] (though I am not sure there's a bug for it), and I don't
believe it has anything to do with the number of API workers, unless not
even two workers are enough.

[1]
http://logstash.openstack.org/#dashboard/file/logstash.json?query=message%3A%5C%22('Connection%20aborted.'%2C%20BadStatusLine(%5C%22''%5C%22%2C)%5C%22



> -Sean
>
> --
> Sean Dague
> http://dague.net
>
> __
> OpenStack Development Mailing 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] [infra] [gate] [all] openstack services footprint lead to oom-kill in the gate

[Armando M.]

On 2 February 2017 at 10:08, Sean Dague  wrote:

> On 02/02/2017 12:49 PM, Armando M. wrote:
> >
> >
> > On 2 February 2017 at 08:40, Sean Dague  > <mailto:s...@dague.net>> wrote:
> >
> > On 02/02/2017 11:16 AM, Matthew Treinish wrote:
> > 
> > > 
> > >
> > > We definitely aren't saying running a single worker is how we
> recommend people
> > > run OpenStack by doing this. But it just adds on to the
> differences between the
> > > gate and what we expect things actually look like.
> >
> > I'm all for actually getting to the bottom of this, but honestly real
> > memory profiling is needed here. The growth across projects probably
> > means that some common libraries are some part of this. The ever
> growing
> > requirements list is demonstrative of that. Code reuse is good, but
> if
> > we are importing much of a library to get access to a couple of
> > functions, we're going to take a bunch of memory weight on that
> > (especially if that library has friendly auto imports in top level
> > __init__.py so we can't get only the parts we want).
> >
> > Changing the worker count is just shuffling around deck chairs.
> >
> > I'm not familiar enough with memory profiling tools in python to know
> > the right approach we should take there to get this down to
> individual
> > libraries / objects that are containing all our memory. Anyone more
> > skilled here able to help lead the way?
> >
> >
> > From what I hear, the overall consensus on this matter is to determine
> > what actually caused the memory consumption bump and how to address it,
> > but that's more of a medium to long term action. In fact, to me this is
> > one of the top priority matters we should talk about at the imminent PTG.
> >
> > For the time being, and to provide relief to the gate, should we want to
> > lock the API_WORKERS to 1? I'll post something for review and see how
> > many people shoot it down :)
>
> I don't think we want to do that. It's going to force down the eventlet
> API workers to being a single process, and it's not super clear that
> eventlet handles backups on the inbound socket well. I honestly would
> expect that creates different hard to debug issues, especially with high
> chatter rates between services.
>

I must admit I share your fear, but out of the tests that I have executed
so far in [1,2,3], the house didn't burn in a fire. I am looking for other
ways to have a substantial memory saving with a relatively quick and dirty
fix, but coming up empty handed thus far.

[1] https://review.openstack.org/#/c/428303/
[2] https://review.openstack.org/#/c/427919/
[3] https://review.openstack.org/#/c/427921/


>
> -Sean
>
> --
> Sean Dague
> http://dague.net
>
> __
> OpenStack Development Mailing 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] [infra] [gate] [all] openstack services footprint lead to oom-kill in the gate

[Armando M.]

On 2 February 2017 at 08:40, Sean Dague  wrote:

> On 02/02/2017 11:16 AM, Matthew Treinish wrote:
> 
> > 
> >
> > We definitely aren't saying running a single worker is how we recommend
> people
> > run OpenStack by doing this. But it just adds on to the differences
> between the
> > gate and what we expect things actually look like.
>
> I'm all for actually getting to the bottom of this, but honestly real
> memory profiling is needed here. The growth across projects probably
> means that some common libraries are some part of this. The ever growing
> requirements list is demonstrative of that. Code reuse is good, but if
> we are importing much of a library to get access to a couple of
> functions, we're going to take a bunch of memory weight on that
> (especially if that library has friendly auto imports in top level
> __init__.py so we can't get only the parts we want).
>
> Changing the worker count is just shuffling around deck chairs.
>
> I'm not familiar enough with memory profiling tools in python to know
> the right approach we should take there to get this down to individual
> libraries / objects that are containing all our memory. Anyone more
> skilled here able to help lead the way?
>

>From what I hear, the overall consensus on this matter is to determine what
actually caused the memory consumption bump and how to address it, but
that's more of a medium to long term action. In fact, to me this is one of
the top priority matters we should talk about at the imminent PTG.

For the time being, and to provide relief to the gate, should we want to
lock the API_WORKERS to 1? I'll post something for review and see how many
people shoot it down :)

Thanks for your feedback!
Cheers,
Armando


>
> -Sean
>
> --
> Sean Dague
> http://dague.net
>
> __
> OpenStack Development Mailing 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] [neutron] [release] misleading release notes

[Armando M.]

Hi,

There is something puzzling about release notes. I don't see 8.0.0 [1], and
it looks like features released in Mitaka are being advertised as Newton
features [2]. For instance, [3] 'Agent availability zones' shows as a
Newton feature when I am pretty positive that it went in Mitaka [4].

I suspect what happens is that someone revises the content at a later date
and reno associated the last timestamp of the release note with release
where the change has been made?

I don't see other projects' release notes broken this way so we must be
doing something wrong. It would be good to have guidance from the release
team.

Thanks,
Armando

[1] http://docs.openstack.org/releasenotes/neutron/mitaka.html
[2] http://docs.openstack.org/releasenotes/neutron/newton.html#id5
[3] http://docs.openstack.org/releasenotes/neutron/newton.html#id6
[4] https://review.openstack.org/#/c/204436/
__
OpenStack Development Mailing 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] [infra] [gate] [all] openstack services footprint lead to oom-kill in the gate

[Armando M.]

Hi,

[TL;DR]: OpenStack services have steadily increased their memory
footprints. We need a concerted way to address the oom-kills experienced in
the openstack gate, as we may have reached a ceiling.

Now the longer version:


We have been experiencing some instability in the gate lately due to a
number of reasons. When everything adds up, this means it's rather
difficult to merge anything and knowing we're in feature freeze, that adds
to stress. One culprit was identified to be [1].

We initially tried to increase the swappiness, but that didn't seem to
help. Then we have looked at the resident memory in use. When going back
over the past three releases we have noticed that the aggregated memory
footprint of some openstack projects has grown steadily. We have the
following:

   - Mitaka
  - neutron: 1.40GB
  - nova: 1.70GB
  - swift: 640MB
  - cinder: 730MB
  - keystone: 760MB
  - horizon: 17MB
  - glance: 538MB
   - Newton
   - neutron: 1.59GB (+13%)
  - nova: 1.67GB (-1%)
  - swift: 779MB (+21%)
  - cinder: 878MB (+20%)
  - keystone: 919MB (+20%)
  - horizon: 21MB (+23%)
  - glance: 721MB (+34%)
   - Ocata
  - neutron: 1.75GB (+10%)
  - nova: 1.95GB (%16%)
  - swift: 703MB (-9%)
  - cinder: 920MB (4%)
  - keystone: 903MB (-1%)
  - horizon: 25MB (+20%)
  - glance: 740MB (+2%)

Numbers are approximated and I only took a couple of samples, but in a
nutshell, the majority of the services have seen double digit growth over
the past two cycles in terms of the amount or RSS memory they use.

Since [1] is observed only since ocata [2], I imagine that's pretty
reasonable to assume that memory increase might as well be a determining
factor to the oom-kills we see in the gate.

Profiling and surgically reducing the memory used by each component in each
service is a lengthy process, but I'd rather see some gate relief right
away. Reducing the number of API workers helps bring the RSS memory down
back to mitaka levels:

   - neutron: 1.54GB
   - nova: 1.24GB
   - swift: 694MB
   - cinder: 778MB
   - keystone: 891MB
   - horizon: 24MB
   - glance: 490MB

However, it may have other side effects, like longer execution times, or
increase of timeouts.

Where do we go from here? I am not particularly fond of stop-gap [4], but
it is the one fix that most widely address the memory increase we have
experienced across the board.

Thanks,
Armando

[1] https://bugs.launchpad.net/neutron/+bug/1656386
[2]
http://logstash.openstack.org/#/dashboard/file/logstash.json?query=message:%5C%22oom-killer%5C%22%20AND%20tags:syslog
[3]
http://logs.openstack.org/21/427921/1/check/gate-tempest-dsvm-neutron-full-ubuntu-xenial/82084c2/
[4] https://review.openstack.org/#/c/427921
__
OpenStack Development Mailing 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][neutron] bot bumping patches off gate queue

[Armando M.]

On 1 February 2017 at 07:29, Ihar Hrachyshka  wrote:

> Hi all,
>
> lately I see the requirements bot proposing new rebases for its
> patches (and bumping existing patch sets from the gate queue) every
> second hour, at least for Neutron [1], which makes it impossible to
> land the patches, and which only makes gate pre-release situation
> worse. On top of that, the proposed rebases don't really add anything
> material to the sync patch, no new version changes and such.
>
> I think we had some guards against such behavior before, so I wonder
> if they were broken or removed lately? Any plans to fix that?
>
> It would be nice to be able to land the update before RC1 is cut off,
> but at this point, it does not seem realistic.
>
> [1] https://review.openstack.org/#/c/423645/
>
>
Let's stop merging until the bot proposal change lands. That ought to stop
the spurious rebase!

Hard times require hard measures!!


> Thanks for help,
> Ihar
>
> __
> OpenStack Development Mailing 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] [neutron] Neutron CI team meeting

[Armando M.]

On 31 January 2017 at 14:47, Morales, Victor 
wrote:

> Howdy,
>
> First of all, thanks for the creation of this space to discuss about
> shouldn’t be something common(in an utopia) but it’s part of our daily
> duties.  I’m not sure if this is the right venue but I discovered today
> that the current implementation of the job for coverage[1] only valides the
> creation of the report and it doesn’t guarantee that the code coverage
> percentage drops (we’re relying on code reviewers to avoid that).  I’m
> wondering if we could propose something to openstack-infra for enabling a
> threshold on the gates.
>

Excellent point. I'll add an open agenda on the meeting page so that people
can bring this type of feedback.


>
> Regards,
> Victor Morales
> irc: electrocucaracha
>
> [1] https://github.com/openstack-infra/project-config/blob/
> master/jenkins/jobs/python-jobs.yaml#L17
>
>
> PS: Congrats Ihar for your new role
>
>
>
> From:  "Armando M." 
> Reply-To:  "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Date:  Tuesday, January 31, 2017 at 1:47 PM
> To:  "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Subject:  [openstack-dev] [neutron] Neutron CI team meeting
>
>
> Hi folks,
>
> Recently [1], a new meeting has been setup to give the neutron team a
> dedicated time to discuss any upstream CI matter (gate issues, testing
> strategies, etc), as well as an overflow space to be used after the main
> team meeting section [3]. Kudos to Ihar
>  for being our first chair.
>
> Needless to say, attendance is welcome.
>
> Cheers,
> Armando
>
> [1] https://review.openstack.org/#/c/426311/
> [2] https://wiki.openstack.org/wiki/Meetings/NeutronCI
> [3] https://wiki.openstack.org/wiki/Network/Meetings#Bugs_and_Gate_issues
> __
> OpenStack Development Mailing 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] [neutron] Neutron CI team meeting

[Armando M.]

Hi folks,

Recently [1], a new meeting has been setup to give the neutron team a
dedicated time to discuss any upstream CI matter (gate issues, testing
strategies, etc), as well as an overflow space to be used after the main
team meeting section [3]. Kudos to Ihar for being our first chair.

Needless to say, attendance is welcome.

Cheers,
Armando

[1] https://review.openstack.org/#/c/426311/
[2] https://wiki.openstack.org/wiki/Meetings/NeutronCI
[3] https://wiki.openstack.org/wiki/Network/Meetings#Bugs_and_Gate_issues
__
OpenStack Development Mailing 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] Ocata Feature Freeze

[Armando M.]

On 26 January 2017 at 12:53, Dariusz Śmigiel 
wrote:

> Dear Neutrinos,
> Feature Freeze day arrived! Ocata-3 has been released, so it means
> that no new features will be allowed to current release... The only
> patches approved to be merged should be: release critical or gate
> blocker.
> All outstanding features, that would need to be landed into Ocata,
> will need to receive "Feature Freeze Exception" status.
>
> From now on, we have one week till RC1.
> Please double check release notes and make sure everything is in order.
>
> Thanks,
> Dariusz
> your Release Liaison
>

Dasm, thanks for the details provided. Let me also add that:

You can find milestone deliverables at [1].

Between now and the official release date (week of Feb 20th, calendar [2]
for more details), we will be busy with the following:

   - cleaning up release notes [3]
   - handling release tasks [4]
   - squashing doc bugs [5]
   - dealing with gate failures [6]
   - apply for FFE on the ocata postmortem [7]
   - for pending efforts that get a FFE granted, there's time until we cut
   an RC1 [8]
   - Pike-1 opens up as soon as RC1 is cut [9] (which I took the liberty to
   seed based on reasonable expectations of the progress we can make on
   outstanding efforts)
   - if you find a RC critical bug, please file it and add bug tag
   'ocata-rc-potential' [10]
   - If you are a subproject maintainer, please check [11], switch to
   release mindset and get ready to prepare an Ocata release.

Be mindful of what you approve for merge (e.g. patches containing DB
migration need special attention), and double check whether it's aimed at
making RC1 solid/complete. If not, please refrain from putting it in the
gate queue, and most of all, *recheck* mindfully.

Many thanks for your help, and when in doubt, reach out!

Cheers,
Armando

[1] https://releases.openstack.org/ocata/index.html
[2] https://releases.openstack.org/ocata/schedule.html
[3] http://docs.openstack.org/releasenotes/neutron/unreleased.html
[4] http://docs.openstack.org/developer/neutron/policies/rel
ease-checklist.html
[5] https://bugs.launchpad.net/neutron/+bugs?field.tag=doc
[6] https://bugs.launchpad.net/neutron/+bugs?field.status%3A
list=NEW&field.status%3Alist=CONFIRMED&field.tag=gate-failure
[7] https://review.openstack.org/#/c/425990
[8] https://launchpad.net/neutron/+milestone/ocata-rc1
[9] https://launchpad.net/neutron/+milestone/pike-1
[10] https://bugs.launchpad.net/neutron/+bugs/?field.tag=ocata-rc-potential
[11] https://review.openstack.org/#/c/389397/
__
OpenStack Development Mailing 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] PTL Candidacy

[Armando M.]

On 24 January 2017 at 12:46, Jeremy Stanley  wrote:

> On 2017-01-24 10:51:39 -0800 (-0800), Ihar Hrachyshka wrote:
> > On Tue, Jan 24, 2017 at 12:50 AM, Kevin Benton  wrote:
> > > I'm on board with getting visibility into the drivers with
> improvements to
> > > driverlog, etc. What I'm uncertain of is providing much in the lines of
> > > 'validation'. Core reviewers don't frequently have access to the
> hardware or
> > > software required to validate these drivers so we can't be sure if the
> > > features really are working as expected.
> > >
> > > If validation is as flexible as you highlighted in the email, we can at
> > > least get it to a point where all recent CI runs are linkable from
> driverlog
> > > and people can see recent tempest runs. I don't foresee the Neutron
> team
> > > getting to a point soon where we vouch for certain drivers though just
> > > because it is so hard to keep up with their changes (even ignoring
> changes
> > > in the vendor hardware itself).
> >
> > Good point. We may guide plugins and drivers on how to set up CI; we
> > may help Foundation to set up Marketplace in such a way that would
> > allow to automatically consume test artifacts from driver owners; we
> > may provide guidance to Foundation about which features are more
> > important to reflect that in Marketplace; but I would hope we don't
> > put the Neutron team on the hook to validate each driver, or even
> > police CI owners to produce consumable results. (The stick in the
> > latter case would be driver not showing up in Marketplace, or showing
> > up with no feature support information.)
>
> I guess the question I have is who, then, can tell our
> operators/users what Neutron drivers are reasonably supported? It
> sounds like you're saying Neutron developers are not well-placed to
> determine that, which leaves us with these other options:
>
> A. Have the OpenStack Foundation as maintainers of the Marketplace
>decide which Neutron drivers are usable (they don't really staff
>for this purpose so would be throwing darts I think)
>
> B. Trust the driver authors to declare whether they're supported and
>what features they provide (maybe that works better than I
>expect?)
>
> C. Identify another party with a vested interest in validating
>driver support (a board of operators from different organizations
>maybe?)
>
> D. Provide links/aggregation of QA/CI and let the consumers attempt
>to divine supportability for themselves (seems a bit downstream
>hostile)
>
> Are any of those options preferable?
>

Even though I am not the one running, I am replying here because I feel
compelled as outgoing PTL and member of the core team to help the soon PTL
elect through this process.

In my opinion, the first thing to address is to lay down the foundations
for an objective comparison across drivers. The neutron team is obviously
best position in doing that. This was started with how we chose to organize
the neutron project, what quality criteria mattered for the team, and how
qualifying neutron features can be tracked across releases (e.g. still work
in progress in [1]).

Only after we have these solid foundations in place, we can go about the
effort of tracking the wider ecosystem of neutron plugins, and identify who
is best positioned to keep that snapshot accurate over time.

My 2c
Armando

[1] https://review.openstack.org/#/c/318192/


> --
> Jeremy Stanley
>
> __
> OpenStack Development Mailing 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] [neutron] PTL Candidacy

[Armando M.]

Hi neutrinos,

No, it's not what you might be thinking...I am just delighted to see two
excellent candidates willing to take the reins of the project going forward
[1,2].

I couldn't hope for more enthusiasm; best of luck to both candidates and
anyone else who is going to step up! This is exciting!

Cheers,
Armando

[1] https://review.openstack.org/#/c/423552/
[2] https://review.openstack.org/#/c/424500/
__
OpenStack Development Mailing 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] grenade failures in the gate

[Armando M.]

On 23 January 2017 at 13:50, Jeremy Stanley  wrote:

> On 2017-01-23 13:38:58 -0800 (-0800), Armando M. wrote:
> > We spotted [1] in the gate. Please wait for its resolution until pushing
> > patches into the merge queue.
>
> https://review.openstack.org/424323 seems to be the fix, and will
> hopefully merge shortly along with its dependency (they're at the
> top of the gate pipeline now as I write this).
>

Yes, that's the one. It looks like we're out of the woods...for now!

Cheers,
Armando


> --
> Jeremy Stanley
>
> __
> OpenStack Development Mailing 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] [neutron] grenade failures in the gate

[Armando M.]

Hi neutrinos,

We spotted [1] in the gate. Please wait for its resolution until pushing
patches into the merge queue.

Thanks,
Armando

[1] https://bugs.launchpad.net/neutron/+bug/1658806
__
OpenStack Development Mailing 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] (dis)Continuation of Neutron VPNaaS

[Armando M.]

On 19 January 2017 at 13:41, Bruno L  wrote:

> Hi,
>
> November last year the Neutron team has announced that VPN as a Service
> will be no longer part of Neutron[1].
>
> We run a public cloud based in New Zealand called Catalyst Cloud[2]. Our
> customers find the VPN service extremely useful to integrate their cloud
> tenant's with on-premise infrastructure or even other clouds. We have
> almost one hundred VPNs that were established by customers using it.
>
> While customers could run a compute instance with something like VyOS,
> they are used to the convenience of having a service managed by us that is
> easy to consume via the APIs or dashboard. It would be a step back for us
> to discontinue VPNaaS.
>
> As a result, we are interested in picking up the development of VPNaaS and
> keeping it alive. If like us, you are an organisation that sees value in
> VPNaaS, please get in touch with me to discuss how we can collaborate on it.
>
> As a first step, we would like to ensure that it continue to pass CI and
> it is free of major bugs. Then, we would like to address some of the points
> raised in the VPNaaS scorecard[3] to bring it up to standard with other
> Neutron services. We don't envisage introducing new features during this
> period, but rather focus on stability and maturity.
>
> Could someone from the Neutron team please help us with the questions
> below?
> 1) What would be the process to transfer ownership of the project?
>

Hi Bruno,

That's great to hear. If you have dev resources who are ready to jump in
Gerrit, please point me to their IRCs and Gerrit accounts and I am happy to
engage with them directly. Yamamoto and I have still core rights on the
repo and work on pushing fixes on an occasional basis. Once your devs feel
more confident, we can definitely talk about adding them to the
neutron-vpnaas core team.


> 2) Until we bring it up to standard, would we need to maintain it as a
> separate project, or as part of Neutron?
>

My suggestion is to focus on the technical aspect of things before worrying
about the governance change. Those typically can happen only in certain
time windows of the release and with the Ocata release approaching feature
freeze, we definitely need to postpone the governance discussion until Pike
opens up.

Thanks,
Armando (irc:armax)


> Cheers,
> Bruno
>
> [1] http://lists.openstack.org/pipermail/openstack-dev/2016-
> November/107384.html
> [2] http://catalyst.net.nz/catalyst-cloud
> [3] http://specs.openstack.org/openstack/neutron-specs/specs
> /stadium/ocata/neutron-vpnaas.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

Re: [openstack-dev] [neutron] Confusion around the complexity

[Armando M.]

On 13 January 2017 at 15:01, Clint Byrum  wrote:

> Excerpts from Armando M.'s message of 2017-01-13 11:39:33 -0800:
> > On 13 January 2017 at 10:47, Clint Byrum  wrote:
> >
> > > Excerpts from Joshua Harlow's message of 2017-01-12 22:38:46 -0800:
> > > > Kevin Benton wrote:
> > > > > If you don't want users to specify network details, then use the
> get me
> > > > > a network extension or just have them boot to a public (or other
> > > > > pre-created) network.
> > > > >
> > > > > In your thought experiment, why is your iPhone app developer not
> just
> > > > > using a PaaS that handles instance scaling, load balancing and HA?
> Why
> > > > > would he/she want to spend time managing security updates and log
> > > > > rotation for an operating system running inside another program
> > > > > pretending to be hardware? Different levels of abstraction solve
> > > > > different use cases.
> > > >
> > > > Fair point, probably mr/mrs iPhone app developer should be doing
> that.
> > > >
> > >
> > > I totally disagree. If PaaS was the answer, they'd all be using PaaS.
> > >
> > > Maybe some day, but that's no excuse for having an overly complex story
> > > for the base. I totally appreciate that "Get me a network" is an effort
> > > to address this. But after reading docs on it, I actually have no idea
> > > how it works or how to make use of it (I do have a decent understanding
> > > of how to setup a default subnetpool as an operator).
> > >
> >
> > I'd be happy to improve the docs, but your feedback is not very
> actionable.
> > Any chance you can elaborate on what you're struggling with?
> >
>
> The docs I found are all extremely Neutron-centric. I was told later
> on IRC that once the default subnet pool is setup, Nova would do some
> magic to tell neutron to allocate a subnet from that pool to the user
> when they create an instance.


> Basically, the docs I found were not at all user-centric. They were
> Neutron-centric and they didn't really explain why, as an operator, I'd
> want to allocate a subnet pool. I mean, they do, but because I don't
> really know if I have that problem or what it is, I just wasn't able
> to grasp where this was going. It tells me to go ahead and list default
> subnet pools, and then pass --nic=net-id=$ID from that. Super confusing
> and not really any more friendly than before.
>
>
If you are referring to [1], I wouldn't expect anything less, it's the
OpenStack networking guide after all.


> So what I want is the story from the user's perspective. Something like:
>
> "Without this extension, your users will need to do these steps in order
> to boot servers with networking:..."
>
> and then
>
> "With this extension, your users will not need to perform those steps,
> and the default subnet pools that you setup will be automatically
> allocated to users upon their first server boot."
>

Problem statement from the user's point of view is typically left to the
specs [2,3].
I am sure one can argue that the content there may not be well written or
organized, but it was enough for getting the nova and the neutron team to
have a mutual understanding and agreement on how to design, implement and
test the feature.

>From what I hear, there is a gap in the networking guide in that the
rationale behind the feature is missing. I suppose we can fill that up, and
thus I filed [4].

Thanks.

[1]
http://docs.openstack.org/newton/networking-guide/config-auto-allocation.html
[2]
http://specs.openstack.org/openstack/neutron-specs/specs/mitaka/get-me-a-network.html
[3]
http://specs.openstack.org/openstack/nova-specs/specs/newton/implemented/get-me-a-network.html
[4] https://bugs.launchpad.net/openstack-manuals/+bug/1656447


> __
> OpenStack Development Mailing 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] [neutron] Confusion around the complexity

[Armando M.]

On 13 January 2017 at 10:47, Clint Byrum  wrote:

> Excerpts from Joshua Harlow's message of 2017-01-12 22:38:46 -0800:
> > Kevin Benton wrote:
> > > If you don't want users to specify network details, then use the get me
> > > a network extension or just have them boot to a public (or other
> > > pre-created) network.
> > >
> > > In your thought experiment, why is your iPhone app developer not just
> > > using a PaaS that handles instance scaling, load balancing and HA? Why
> > > would he/she want to spend time managing security updates and log
> > > rotation for an operating system running inside another program
> > > pretending to be hardware? Different levels of abstraction solve
> > > different use cases.
> >
> > Fair point, probably mr/mrs iPhone app developer should be doing that.
> >
>
> I totally disagree. If PaaS was the answer, they'd all be using PaaS.
>
> Maybe some day, but that's no excuse for having an overly complex story
> for the base. I totally appreciate that "Get me a network" is an effort
> to address this. But after reading docs on it, I actually have no idea
> how it works or how to make use of it (I do have a decent understanding
> of how to setup a default subnetpool as an operator).
>

I'd be happy to improve the docs, but your feedback is not very actionable.
Any chance you can elaborate on what you're struggling with?

Thanks,
Armando


>
> __
> OpenStack Development Mailing 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] [neutron] Confusion around the complexity

[Armando M.]

On 12 January 2017 at 15:07, Armando M.  wrote:

>
>
> On 12 January 2017 at 14:46, Joshua Harlow  wrote:
>
>> So I don't want to start to much of a flame-war and am really just trying
>> to understand things that may be beyond me (so treat me nicely, ha).
>>
>> The basic question that I've been wondering revolves around the following
>> kind of 'thought experiment' that asks something along the lines of:
>>
>> """
>> If I am a user of openstack, say I'm an iphone developer, trying to get
>> my 'game' and associated 'game APIs' setup in a manner that is HA (say
>> fronted by a load-balancer), using my custom image, secure and visible to
>> either an intranet or to the large internet then what is the steps I would
>> have to do when interacting with openstack to accomplish this and what
>> would the provider of openstack have to give to me as endpoints to make
>> this possible.
>> """
>>
>> One of the obvious ones is nova and glance, and the API and usage there
>> feels pretty straightforward as is (isn't really relevant to this
>> conversation anyway). The one that feels bulky and confusing (at least for
>> me) is the things I'd have to do in neutron to create and/or select
>> networks, create and/or select subnets, create and/or select ports and
>> so-on...
>
>
>> As a supposed iphone developer (dev/ops, yadayada) just trying to get
>> his/her game to market why would I really want to know about selecting
>> networks, create and/or selecting subnets, create and/or selecting ports
>> and so-on...
>>
>> It may just be how it is, but I'd like to at least ask if others are
>> really happy with the interactions/steps (I guess we could/maybe we should
>> ask similar questions around various other projects as well?); if I'm just
>> an outlier that's ok, at least I asked :-P
>>
>
> Answering your question in a nutshell is very hard, but I'll try
> nonetheless.
>
> I bet that if you think really hard, complications may arise even when
> dealing with images and compute resources. That's because, in the most
> trivial cases you are not thinking about the services that your image must
> provide (and if so you may start injecting user-data into your boot phase)
> or performance requirements you may have (and if so, you may want your
> hypervisors to provide certain optimizations).
>
> IMO, the networking case is inherently complex because the network
> architecture required by a non trivial application is itself complex, in
> that you may need tiers of security, you need to HA, etc. In the most
> trivial case where you just want a single endpoint to which you can talk
> to, there's get-me-a-network [1,2]. You can fire boot a VM on of top of a
> auto-provisioned network topology and off you go. To get external access
> you're only left with a floating IP association, but that's only one API
> call away.
>
> Cheers,
> Armando
>
> [1] https://specs.openstack.org/openstack/neutron-specs/specs/
> liberty/get-me-a-network.html
> [2] http://docs.openstack.org/newton/networking-guide/
> config-auto-allocation.html
>

Forgot to add the nova-side of the spec:

http://specs.openstack.org/openstack/nova-specs/specs/newton/implemented/get-me-a-network.html


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

Re: [openstack-dev] [neutron] Confusion around the complexity

[Armando M.]

On 12 January 2017 at 14:46, Joshua Harlow  wrote:

> So I don't want to start to much of a flame-war and am really just trying
> to understand things that may be beyond me (so treat me nicely, ha).
>
> The basic question that I've been wondering revolves around the following
> kind of 'thought experiment' that asks something along the lines of:
>
> """
> If I am a user of openstack, say I'm an iphone developer, trying to get my
> 'game' and associated 'game APIs' setup in a manner that is HA (say fronted
> by a load-balancer), using my custom image, secure and visible to either an
> intranet or to the large internet then what is the steps I would have to do
> when interacting with openstack to accomplish this and what would the
> provider of openstack have to give to me as endpoints to make this possible.
> """
>
> One of the obvious ones is nova and glance, and the API and usage there
> feels pretty straightforward as is (isn't really relevant to this
> conversation anyway). The one that feels bulky and confusing (at least for
> me) is the things I'd have to do in neutron to create and/or select
> networks, create and/or select subnets, create and/or select ports and
> so-on...


> As a supposed iphone developer (dev/ops, yadayada) just trying to get
> his/her game to market why would I really want to know about selecting
> networks, create and/or selecting subnets, create and/or selecting ports
> and so-on...
>
> It may just be how it is, but I'd like to at least ask if others are
> really happy with the interactions/steps (I guess we could/maybe we should
> ask similar questions around various other projects as well?); if I'm just
> an outlier that's ok, at least I asked :-P
>

Answering your question in a nutshell is very hard, but I'll try
nonetheless.

I bet that if you think really hard, complications may arise even when
dealing with images and compute resources. That's because, in the most
trivial cases you are not thinking about the services that your image must
provide (and if so you may start injecting user-data into your boot phase)
or performance requirements you may have (and if so, you may want your
hypervisors to provide certain optimizations).

IMO, the networking case is inherently complex because the network
architecture required by a non trivial application is itself complex, in
that you may need tiers of security, you need to HA, etc. In the most
trivial case where you just want a single endpoint to which you can talk
to, there's get-me-a-network [1,2]. You can fire boot a VM on of top of a
auto-provisioned network topology and off you go. To get external access
you're only left with a floating IP association, but that's only one API
call away.

Cheers,
Armando

[1]
https://specs.openstack.org/openstack/neutron-specs/specs/liberty/get-me-a-network.html
[2]
http://docs.openstack.org/newton/networking-guide/config-auto-allocation.html


>
> -Josh
>
> __
> OpenStack Development Mailing 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] [neutron] Neutron Pike PTG

[Armando M.]

Hi neutrinos,

The time for the PTG is approaching and if you are wondering about topics
and various agenda arrangements, you should consider the PTG more like a
mid-cycle on steroids: each project will be working on its own agenda,
usually via etherpads, and publish updates over the ML, up until and during
the week of the PTG.

Therefore, do not expect any published agenda, beyond a daily map of where
teams will be gathering in which rooms. We also need to work out on how to
arrange cross-projects conversations. Please expect to learn more from the
team organizers.

For now, please start collecting ideas on [2]. Once we got critical mass on
[2], I'll work with the drivers team to finalize and sanitize a more formal
agenda, which will then be published on a new etherpad (TBD). For those who
cannot participate in person to the event, we will provide a mid-cycle
report.

Cheers,
Armando

[1] https://www.openstack.org/ptg/
[2] https://etherpad.openstack.org/p/neutron-ptg-pike
__
OpenStack Development Mailing 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] [neutron] networking-sfc stable/newton branch broken

[Armando M.]

Hi,

Please have a look at [1]. The branch has been broken for some time now.

Thanks,
Armando

[1]
https://review.openstack.org/#/q/status:open+project:openstack/networking-sfc+branch:stable/newton
__
OpenStack Development Mailing 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] [neutron] PTL nominations deadline and non-candidacy

[Armando M.]

Hi neutrinos,

The PTL nomination week is fast approaching [0], and as you might have
guessed by the subject of this email, I am not planning to run for Pike. If
I look back at [1], I would like to think that I was able to exercise the
influence on the goals I set out with my first self-nomination [2].

That said, when it comes to a dynamic project like neutron one can't never
claim to be *done done* and for this reason, I will continue to be part of
the neutron core team, and help the future PTL drive the next stage of the
project's journey.

I must admit, I don't write this email lightly, however I feel that it is
now the right moment for me to step down, and give someone else the
opportunity to grow in the amazing role of neutron PTL! I have certainly
loved every minute of it!

Cheers,
Armando

[0] https://releases.openstack.org/ocata/schedule.html
[1] https://review.openstack.org/#/q/project:openstack/elect
ion+owner:armando-migliaccio
[2] https://review.openstack.org/#/c/223764/
__
OpenStack Development Mailing 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] [neutron] Team and drivers meetings

[Armando M.]

Hi neutrinos,

A reminder that from this week on it is business as usual. Therefore the
calendar for team and drivers meetings is back up and running.

Cheers,
Armando
__
OpenStack Development Mailing 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] [neutron] team meeting calendar

[Armando M.]

Hi folks,

Due to the holiday period we'll cancel the following meeting occurrences:

Dec 26
Jan 3

We'll meet again on Jan 9.

Happy holidays!
Armando
__
OpenStack Development Mailing 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] [neutron] drivers meeting calendar

[Armando M.]

Hi folks,

Due to the holiday period we'll cancel the following meeting occurrences:

Dec 22
Dec 29
Jan 5

We'll meet again on Jan 12.

Happy holidays!
Armando
__
OpenStack Development Mailing 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] multinode CI jobs in the gate

[Armando M.]

On 18 December 2016 at 12:28, John Schwarz  wrote:

> Hey,
>
> There is already an experimental job called
> "gate-tempest-dsvm-neutron-dvr-ha-multinode-full-ubuntu-xenial-nv"
> (which was added by [1]).
>
> However, the job is currently a "one dvr_snat nodes, two dvr nodes"
> deployment (instead of the "two dvr_snat nodes, one dvr node" that it
> should be in order to make L3HA work there). The patch which makes the
> final transition is being worked on in [2], and it's ready to be
> merged afaik. Once it merges, we'll have a DVR+HA gate in the
> experimental queue.
>

Excellent! thanks for the update, John!

Cheers,
Armando


>
> John.
>
> [1]: https://review.openstack.org/#/c/383742/
> [2]: https://review.openstack.org/#/c/383827/
>
> On Fri, Dec 16, 2016 at 2:23 AM, Armando M.  wrote:
> > Hi Neutrinos,
> >
> > Infra patch proposed in [1] got me thinking again about what we shall do
> > when it comes to multinode testing in the gate and how to focus our
> testing
> > and CI efforts upstream going forward. My line of thinking has always
> been
> > that multinode resources should be devoted to configurations whose
> coverage
> > fully benefit from the inherent nature of the distributed deployment, and
> > that means giving priority to DVR+HA and demote other configurations that
> > use centralized routing.
> >
> > I know that some of you in team have worked on this, but I am a bit
> behind
> > on the latest status update. Any good soul willing to bring a strapped
> (for
> > time) PTL up to speed?
> >
> > Cheers,
> > Armando
> >
> > [1] https://review.openstack.org/#/c/411263/
> >
> > 
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
>
>
> --
> John Schwarz,
> Senior Software Engineer,
> Red Hat.
>
> __
> OpenStack Development Mailing 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] [neutron] multinode CI jobs in the gate

[Armando M.]

Hi Neutrinos,

Infra patch proposed in [1] got me thinking again about what we shall do
when it comes to multinode testing in the gate and how to focus our testing
and CI efforts upstream going forward. My line of thinking has always been
that multinode resources should be devoted to configurations whose coverage
fully benefit from the inherent nature of the distributed deployment, and
that means giving priority to DVR+HA and demote other configurations that
use centralized routing.

I know that some of you in team have worked on this, but I am a bit behind
on the latest status update. Any good soul willing to bring a strapped (for
time) PTL up to speed?

Cheers,
Armando

[1] https://review.openstack.org/#/c/411263/
__
OpenStack Development Mailing 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] [neutron] proposing Ryan Tidwell and Nate Johnston as service LTs

[Armando M.]

 Hi neutrinos,

I would like to propose Ryan and Nate as the go-to fellows for
service-related patches.

Both are core in their repos of focus, namely neutron-dynamic-routing and
neutron-fwaas, and have a good understanding of the service framework, the
agent framework and other bits and pieces. At this point, entrusting them
with the responsibility is almost a formality.

Cheers,
Armando

[1] https://review.openstack.org/#/c/411536/
__
OpenStack Development Mailing 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] [architecture][api][Nova][Neutron][Cinder] nova-compute's architecture/API

[Armando M.]

On 16 December 2016 at 00:01, Clint Byrum  wrote:

> So, I've been quietly ranting in hallways about this for a while. I may
> be way way off base here. I want to kick the discussion off, so I've
> submitted a proposal to the arch-wg about it. Please if you're interested
> in how Nova/Neutron/Cinder interact with nova-compute, I think it might
> be worthwhile to read it and get it into a factual state, so the arch-wg
> can do a deeper analysis. Please do rip it to shreds in comments, and
> feel free to revise it and add more details. Thanks very much!
>
> https://review.openstack.org/411527
>
>
Noted! I'll bring this up at the next team meeting. Thanks for spearheading
this!


Cheers,
Armando

__
> OpenStack Development Mailing 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] [neutron] proposing Miguel Lavalle as neutron core and Brian Haley as L3 Lt

[Armando M.]

Hi neutrinos,

Miguel Lavalle has been driving the project forward consistently and
reliably. I would like to propose him to be entrusted with +2/+A rights in
the areas he's been most prolific, which are L3 and DHCP.

At the same time, I'd like to propose Brian Haley as our next Chief L3
Officer. Both of them have worked with Carl Baldwin extensively and that
can only be a guarantee of quality.

Cheers,
Armando

[1] https://review.openstack.org/#/c/411531/
__
OpenStack Development Mailing 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] Proposing Abhishek Raut as neutronclient core

[Armando M.]

On 15 December 2016 at 09:50, Akihiro Motoki  wrote:

> +1
>

Welcome to the team Abhishek!


>
> 2016-12-14 10:22 GMT+09:00 Armando M. :
>
>> Hi folks,
>>
>> Abhishek Raut's recent involvement in OSC and python-neutronclient has
>> helped moving a few efforts along in the right direction. I would like to
>> suggest we double down on core firepower for the neutronclient repo
>> alongside Akihiro [1].
>>
>> This not only will help speed up our transition to OSC CLI, but also
>> improve the number of folks who can effectively liasion with the OSC team,
>> and look after the needs of neutron's client repo.
>>
>> Many thanks,
>> Armando
>>
>> [1] https://review.openstack.org/#/c/410485/
>>
>> 
>> __
>> 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

[openstack-dev] [neutron] drivers meeting cancellation today

[Armando M.]

Hi folks,

Due to conflicts, we are unable to host the drivers meeting today.

Apologies for the short notice.

Thanks,
Armando
__
OpenStack Development Mailing 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] [neutron] Proposing Abhishek Raut as neutronclient core

[Armando M.]

Hi folks,

Abhishek Raut's recent involvement in OSC and python-neutronclient has
helped moving a few efforts along in the right direction. I would like to
suggest we double down on core firepower for the neutronclient repo
alongside Akihiro [1].

This not only will help speed up our transition to OSC CLI, but also
improve the number of folks who can effectively liasion with the OSC team,
and look after the needs of neutron's client repo.

Many thanks,
Armando

[1] https://review.openstack.org/#/c/410485/
__
OpenStack Development Mailing 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] trunk api performance and scale measurments

[Armando M.]

On 8 December 2016 at 20:55, Armando M.  wrote:

>
>
> On 5 December 2016 at 07:59, Bence Romsics 
> wrote:
>
>> Hi,
>>
>> I measured how the new trunk API scales with lots of subports. You can
>> find the results here:
>>
>> https://wiki.openstack.org/wiki/Neutron_Trunk_API_Performance_and_Scaling
>>
>> Hope you find it useful. There are several open ends, let me know if
>> you're interested in following up some of them.
>>
>
> I looked into [1] a little bit as it bothered me :)
>
> Here's my findings:
>
>
>- openstack port list is slower than neutron port-list as it looks
>like the command goes to Nova first [2], which is where the overhead comes
>from.
>- when you have subports the port-list response gets bigger because of
>the bigger response due to the trunk-details extension.
>- However, the bulk of the time is spent in [3], when building the
>payload for a port involved as a parent port. In no other case you will see
>the overhead as in no other case the loop over subports is executed.
>
> The hook should be optimized!
>

Follow up: Kevin and I put together a couple of patches [1,2] to fix and
validate how to speed up the lookup. We'll dig into why sqlalchemy is
acting differently when listing ports with or without filters, but this
should do for now.

Cheers,
Armando

[1] https://review.openstack.org/#/c/409267/
[2] https://review.openstack.org/#/c/408983/


> [1] https://wiki.openstack.org/wiki/Neutron_Trunk_API_Performanc
> e_and_Scaling#surprise_effect_on_filtered_port_listings
> [2] http://paste.openstack.org/show/591882/
> [3] https://github.com/openstack/neutron/blob/master/
> neutron/services/trunk/plugin.py#L42
>
>
>> Cheers,
>> Bence Romsics
>>
>> 
>> __
>> 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

Re: [openstack-dev] [neutron] trunk api performance and scale measurments

[Armando M.]

On 5 December 2016 at 07:59, Bence Romsics  wrote:

> Hi,
>
> I measured how the new trunk API scales with lots of subports. You can
> find the results here:
>
> https://wiki.openstack.org/wiki/Neutron_Trunk_API_Performance_and_Scaling
>
> Hope you find it useful. There are several open ends, let me know if
> you're interested in following up some of them.
>

I looked into [1] a little bit as it bothered me :)

Here's my findings:


   - openstack port list is slower than neutron port-list as it looks like
   the command goes to Nova first [2], which is where the overhead comes from.
   - when you have subports the port-list response gets bigger because of
   the bigger response due to the trunk-details extension.
   - However, the bulk of the time is spent in [3], when building the
   payload for a port involved as a parent port. In no other case you will see
   the overhead as in no other case the loop over subports is executed.

The hook should be optimized!

Cheers,
Armando

[1] https://wiki.openstack.org/wiki/Neutron_Trunk_API_
Performance_and_Scaling#surprise_effect_on_filtered_port_listings
[2] http://paste.openstack.org/show/591882/
[3]
https://github.com/openstack/neutron/blob/master/neutron/services/trunk/plugin.py#L42


> Cheers,
> Bence Romsics
>
> __
> OpenStack Development Mailing 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] [neutron] broken rally gate

[Armando M.]

On 8 December 2016 at 16:40, Armando M.  wrote:

> Hi folks
>
> Chasing down why [1] accidentally broke rally. Please do not recheck, and
> the failure is persistent.
>
> Thanks,
> Armando
>
> [1] https://review.openstack.org/#/c/408020
>

https://review.openstack.org/#/c/408870/ should bring sanity back into the
world.
__
OpenStack Development Mailing 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] [neutron] broken rally gate

[Armando M.]

Hi folks

Chasing down why [1] accidentally broke rally. Please do not recheck, and
the failure is persistent.

Thanks,
Armando

[1] https://review.openstack.org/#/c/408020
__
OpenStack Development Mailing 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] Vlan aware VMs or trunking

[Armando M.]

On 7 December 2016 at 04:02, Vasyl Saienko  wrote:

> Armando, Kevin,
>
> Thanks for your comments.
>
> To be more clear we are trying to use neutron trunks implementation with
> baremetal servers (Ironic). Baremetal servers are plugged to Tor (Top of
> the Rack) switch. User images are spawned directly onto hardware.
>
Ironic uses Neutron ML2 drivers to plug baremetal servers to Neutron
> networks (it looks like changing vlan on the port to segmentation_id from
> Neutron network, scenario 1 in the attachment). Ironic works with VLAN
> segmentation only for now, but some vendors ML2 like arista allows to use
> VXLAN (in this case VXLAN to VLAN mapping is created on the switch.).
> Different users may have baremetal servers connected to the same ToR switch.
>
> By trying to apply current neutron trunking model leads to the following
> errors:
>
> *Scenario 2: single user scenario, create VMs with trunk and non-trunk
> ports.*
>
>- User create two networks:
>net-1: (provider:segmentation_id: 100)
>net-2: (provider:segmentation_id: 101)
>
>- User create 1 trunk port
>port0 - parent port in net-1
>port1 - subport in net-2 and define user segmentation_id: 300
>
>- User boot VMs:
>BM1: with trunk (connected to ToR Fa0/1)
>BM4: in net-2 (connected to ToR Fa0/4)
>
>- VLAN on the switch are configured as follow:
>Fa0/1 - trunk, native 100, allowed vlan 300
>Fa0/4 - access vlan 101
>
> *Problem:* BM1 has no access BM4 on net-2
>
>
> *Scenario 3: multiple user scenario, create VMs with trunk.*
>
>- User1 create two networks:
>net-1: (provider:segmentation_id: 100)
>net-2: (provider:segmentation_id: 101)
>
>- User2 create two networks:
>net-3: (provider:segmentation_id: 200)
>net-4: (provider:segmentation_id: 201)
>
>- User1 create 1 trunk port
>port0 - parent port in net-1
>port1 - subport in net-2 and define user segmentation_id: 300
>
>- User2 create 1 trunk port
>port0 - parent port in net-3
>port1 - subport in net-4 and define user segmentation_id: 300
>
>- User1 boot VM:
>BM1: with trunk (connected to ToR Fa0/1)
>
>- User2 boot VM:
>BM4: with trunk (connected to ToR Fa0/4)
>
>- VLAN on the switch are configured as follow:
>Fa0/1 - trunk, native 100, allowed vlan 300
>Fa0/4 - trunk, native 200, allowed vlan 300
>
> *Problem:* User1 BM1 has access to User2 BM4 on net-2, Conflict in VLAN
> mapping provider vlan 101 should be mapped to user vlan 300, and provider
> vlan 201 should be also mapped to vlan 300
>
>
> Making segmentation_id on trunk subport optional and inheriting it from
> port network segmentation_id solves such problems.
> According to original spec both segmentation_type and segmentation_id are
> optional [0].
>
> Does Neutron/Nova place information about user's VLAN onto instance via
> network metadata?
>
> Reference:
> [0] https://review.openstack.org/#/c/308521/1/specs/newton/
> vlan-aware-vms.rst@118
>

Ah, I was actually going to add the following:

Whether segmentation type and segmentation ID are mandatory or not depends
on the driver in charge of the trunk. This is because for use cases like
Ironic, as you wonder, these details may be inferred by the underlying
network, as you point out.

However, we have not tackled the Ironic use case just yet, for the main
reason that ironic spec [1] is still WIP. So as far as newton is concerned,
Ironic is not on the list of supported use cases for vlan-aware-vms, yet
[2]. The reason why we have not tackled it yet is that there's the
'nuisance' in that a specific driver is known to the trunk plugin only at
the time a parent port is bound and we hadn't come up with a clean and
elegant way to developer a validator that took into account of it. I'll
file a bug report to make sure this won't fall through the cracks. It'll be
tagged with 'trunk'.

[1] https://review.openstack.org/#/c/277853/
[2]
https://github.com/openstack/neutron/blob/master/neutron/services/trunk/rules.py#L215

Cheers,
Armando


>
> Thanks in advance,
> Vasyl Saienko
>
> On Tue, Dec 6, 2016 at 7:08 PM, Armando M.  wrote:
>
>>
>>
>> On 6 December 2016 at 08:49, Vasyl Saienko  wrote:
>>
>>> Hello Neutron Community,
>>>
>>>
>>> I've found that nice feature vlan-aware-vms was implemented in Newton
>>> [0].
>>> However the usage of this feature for regular users is impossible,
>>> unless I'm missing something.
>>>
>>> As I understood correctly it should work in the following way:
>>>
>>>1. It is possible to group neut

Re: [openstack-dev] [Neutron][Dynamic Routing] Plans for scenario testing?

[Armando M.]

On 6 December 2016 at 14:44, Tidwell, Ryan  wrote:

> This is at the top of my list to look at. I've been thinking a lot about
> how to implement some tests. For instance, do we need to actually stand up
> a BGP peer of some sort to peer neutron with and assert the announcements
> somehow? Or should we assume that Ryu works properly and make sure we have
> solid coverage of the driver interface somehow. I'm open to suggestions as
> to how to approach this.
>

Thomas Morin et al have had a few ideas and put together [1]. There are
some similarities between the efforts. Something worth mulling over on.

Cheers,
Armando

[1] https://review.openstack.org/#/c/396967/


>
> -Ryan
>
> -Original Message-
> From: Assaf Muller [mailto:as...@redhat.com]
> Sent: Tuesday, December 06, 2016 2:36 PM
> To: OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>
> Subject: [openstack-dev] [Neutron][Dynamic Routing] Plans for scenario
> testing?
>
> Hi all,
>
> General query - Is there anyone in the Dynamic Routing community that is
> planning on contributing a scenario test? As far as I could tell, none of
> the current API tests would fail if, for example, the BGP agent was not
> running. Please correct me if I'm wrong.
>
> Thank you.
>
> __
> OpenStack Development Mailing 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] [Neutron][Dynamic Routing] Plans for scenario testing?

[Armando M.]

On 6 December 2016 at 14:36, Assaf Muller  wrote:

> Hi all,
>
> General query - Is there anyone in the Dynamic Routing community that
> is planning on contributing a scenario test? As far as I could tell,
> none of the current API tests would fail if, for example, the BGP
> agent was not running. Please correct me if I'm wrong.
>

You are correct, I am working with Ryan to figure this gap out as
identified in [1]

[1] https://review.openstack.org/#/c/389397/15/specs/stadium/ocata.rst@105


>
> Thank you.
>
> __
> OpenStack Development Mailing 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] [neutron] Vlan aware VMs or trunking

[Armando M.]

On 6 December 2016 at 08:49, Vasyl Saienko  wrote:

> Hello Neutron Community,
>
>
> I've found that nice feature vlan-aware-vms was implemented in Newton [0].
> However the usage of this feature for regular users is impossible, unless
> I'm missing something.
>
> As I understood correctly it should work in the following way:
>
>1. It is possible to group neutron ports to trunks.
>2. When trunk is created parent port should be defined:
>Only one port can be parent.
>segmentation of parent port is set as native or untagged vlan on the
>trunk.
>3. Other ports may be added as subports to existing trunk.
>When subport is added to trunk *segmentation_type* and *segmentation_id
>*should be specified.
>segmentation_id of subport is set as allowed vlan on the trunk
>
> Non-admin user do not know anything about *segmentation_type* and
> *segmentation_id.*
>

Segmentation type and ID are used to multiplex/demultiplex traffic in/out
of the guest associated to a particular trunk. Aside the fact that the only
supported type is VLAN at the moment (if ever), the IDs are user provided
to uniquely identify the traffic coming in/out of the trunked networks so
that it can reach the appropriate vlan interface within the guest. The
documentation [1] is still in flight, but it clarifies this point.

HTH
Armando

[1] https://review.openstack.org/#/c/361776


> So it is strange that those fields are mandatory when subport is added to
> trunk. Furthermore they may conflict with port's network segmentation_id
> and type. Why we can't inherit segmentation_type and segmentation_id from
> network settings of subport?
>
> References:
> [0] https://blueprints.launchpad.net/neutron/+spec/vlan-aware-vms
> [1] https://review.openstack.org/#/c/361776/15/doc/networking-gu
> ide/source/config-trunking.rst
> [2] https://etherpad.openstack.org/p/trunk-api-dump-newton
>
> Thanks in advance,
> Vasyl Saienko
>
> __
> OpenStack Development Mailing 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] [neutron] trunk api performance and scale measurments

[Armando M.]

On 5 December 2016 at 08:07, Jay Pipes  wrote:

> On 12/05/2016 10:59 AM, Bence Romsics wrote:
>
>> Hi,
>>
>> I measured how the new trunk API scales with lots of subports. You can
>> find the results here:
>>
>> https://wiki.openstack.org/wiki/Neutron_Trunk_API_Performance_and_Scaling
>>
>> Hope you find it useful. There are several open ends, let me know if
>> you're interested in following up some of them.
>>
>
> Great info in there, Ben, thanks very much for sharing!


Bence,

Thanks for the wealth of information provided, I was looking forward to it!
The results of the experimentation campaign makes me somewhat confident
that trunk feature design is solid, or at least that is what it looks like!
I'll look into why there is a penalty on port-list, because that's
surprising for me too.

I also know that the QE team internally at HPE has done some perf testing
(though I don't have results publicly available yet), but what I can share
at this point is:

   - They also disabled l2pop to push the boundaries of trunk deployments;
   - They disabled OVS firewall (though for reasons orthogonal to
   scalability limits introduced by the functionality);
   - They flipped back to ovsctl interface, as it turned out to be one of
   components that introduced some *penalty*. Since you use native
   interface, it'd be nice to see what happens if you flipped this switch too;
   - RPC timeout of 300.

On a testbed of 3 controllers and 7 computes, this is at high level what
they found out the following:

   - 100 trunks, with 1900 subports took about 30 mins with no errors;
   - 500 subports take about 1 min to bind to a trunk;
   - Booting a VM on trunk with 100 subports takes as little as 15 seconds
   to successful ping. Trunk goes from BUILD -> ACTIVE within 60 seconds of
   booting the VM;
   - Scaling to 700 VM's incrementally on trunks with 100 initial subports
   is constant (e.g. booting time stays set at ~15 seconds).

I believe Ryan Tidwell may have more on this.

Cheers,
Armando


>
> -jay
>
>
> __
> OpenStack Development Mailing 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] [all][tc] Allowing Teams Based on Vendor-specific Drivers

[Armando M.]

On 30 November 2016 at 02:23, Kevin Benton  wrote:

> >I'll let someone from the Neutron team fill in the details behind their 
> >decision,
> because I don't want to misrepresent them.
>
> I can shed a bit of light on this since I'm a core and had been working
> for a driver vendor at the time of the split. There were a few areas of
> contention:
>
> * Releases and stable branches:
> Vendors develop features for their driver and want them available to all
> of their customers immediately after they do their own QA. Additionally,
> they want them available to the customers running security-only and even
> EOL branches. This obviously violates the release process for upstream
> openstack stuff, so terrible, terrible things were done to apply patches to
> these old branches at customer sites.
>

This is actually a good point worth emphasising because this might have
been unique to our situation at the time: there was an infra patch applied
to all neutron stadium projects that modified gerrit ACLs so that stable
backports would be under the control of the neutron-stable-main team.

Because of the example that Kevin described, members of the team were faced
with the paradox of having to either turn a blind eye, or try to fight the
battle of educating contributors and fixing the 'malpractice' at the root.
Now irrespective of whether the openstack stable policy is deemed too rigid
by some or not, we started to observe that within the same governance we
had individual initiatives behaving totally differently, so differently
that some of us started to wonder what the stadium was for, what was the
point of it, and whether it was misused as a marketing tool.

That's when I came up with the proposal of defining the neutron stadium as
a list of projects that behave consistently and adhere to a common set of
agreed principles, such as common backporting strategies, testing
procedures, including our ability to claim the entire technology stack to
be fully open and completely exercised with upstream infra resources: a
list of projects that any member of the neutron core team should be able to
stand behind and support it without too many ideological clashes.

It's been a long journey and we're almost at the end of it. The neutron
core team has been very supportive of this journey. Now I am not sure
whether they did that just to make me happy and will undo all of it when I
step down :) but I genuinely think it has been a great effort that allowed
us to improve what we've been building by means of setting ourselves
achievable and measurable goals.


>
> * Pass-through drivers:
> In response to the issue above, many vendors ended up creating
> 'vendor-lib' or an HTTP/RPC API to which their Neutron in-tree driver would
> just pass every call with as little logic as possible. When drivers went
> this direction, we could never tell their current functioning state because
> we were always one vendor release (of either vendor-lib or vendor HTTP API)
> away from them breaking something.
>
> IIRC there was a design session in the summit about Cinder having this
> problem. They were trying to determine how thin a driver was allowed to be
> before the cores would refuse to accept it. I don't think they reached a
> consensus on what the limit is or if there should even be a limit.
>
> * Changes impossible to judge for cores:
> For the logic changes that do occur in tree, cores could only really tell
> if they looked like correct python and appeared to do something sane at a
> very high level. Judging if the change even worked was entirely dependent
> on a good 3rd-party CI response. Judging things like backwards
> compatibility with older vendor backends was completely out of the question
> because no vendor offered a full matrix CI test with every version of their
> product. So reviewing driver changes became somewhat of a rubber stamping
> process that many were not interested in and/or comfortable doing.
>
>
> >I hope I'm not the only one who thinks drivers are important?
>
> Of course we care about drivers (see neutron-lib effort). However, it
> wasn't clear what the point of having them in tree was when cores couldn't
> reason about the changes or even try them without special-purpose hardware.
> How do you foresee the drivers improving if we bring them back in tree?
>
> On Tue, Nov 29, 2016 at 11:08 AM, Doug Hellmann 
> wrote:
>
>> Excerpts from Zane Bitter's message of 2016-11-29 12:36:03 -0500:
>> > On 29/11/16 10:28, Doug Hellmann wrote:
>> > > Excerpts from Chris Friesen's message of 2016-11-29 09:09:17 -0600:
>> > >> On 11/29/2016 08:03 AM, Doug Hellmann wrote:
>> > >>> I'll rank my preferred solutions, because I don't actually like any
>> of
>> > >>> them.
>> > >>
>> > >> Just curious...what would you "actually like"?
>> > >>
>> > >> Chris
>> > >>
>> > >
>> > > My preference is to have teams just handle the drivers voluntarily,
>> > > without needing to make it a rule or provide a way to have teams
>> > > that only work on

Re: [openstack-dev] [all][tc] Allowing Teams Based on Vendor-specific Drivers

[Armando M.]

On 29 November 2016 at 10:08, Doug Hellmann  wrote:

> Excerpts from Zane Bitter's message of 2016-11-29 12:36:03 -0500:
> > On 29/11/16 10:28, Doug Hellmann wrote:
> > > Excerpts from Chris Friesen's message of 2016-11-29 09:09:17 -0600:
> > >> On 11/29/2016 08:03 AM, Doug Hellmann wrote:
> > >>> I'll rank my preferred solutions, because I don't actually like any
> of
> > >>> them.
> > >>
> > >> Just curious...what would you "actually like"?
> > >>
> > >> Chris
> > >>
> > >
> > > My preference is to have teams just handle the drivers voluntarily,
> > > without needing to make it a rule or provide a way to have teams
> > > that only work on a driver. That's not one of the options we proposed,
> > > but the results are like what we would get with option 6 (minus the
> > > precedent of the TC telling teams what code they must manage).
> >
> > I don't have a lot of background on why the driver was removed from the
> > Neutron stadium, but reading between the lines it sounds like you think
> > that Neutron made the Wrong Call, and that you would like, in order of
> > preference:
> >
> > a) Neutron to start agreeing with you; or
> > b) The TC to tell Neutron to agree with you; or
>
> I hope I'm not the only one who thinks drivers are important?
>
> I would prefer not to impose obligations on anyone. I wrote up that
> option to explore what it would look like, not because I think it's
> the best outcome.  At the same time, the current approach is actively
> harmful to the overall health of the community by pushing away
> contributors and useful contributions, especially considering the
> different responses to vendor-related issues in other teams.  And
> this does fall within the scope of issues and policies the TC is
> meant to manage.
>
> > c) To do an end run around Neutron by adding it as a separate project
>
> I wouldn't categorize that last one as an end-run. We wouldn't be
> adding the driver team to Neutron, we would be adding it to OpenStack.
> The Neutron team would have no more responsibility for the output of
> a driver team than they do anyone else.
>
> > Individual projects (like Neutron) have pretty wide latitude to add
> > repositories if they want, and are presumably closer to the issues than
> > anyone. So it seems strange that we're starting with a discussion about
> > how to override their judgement, rather than one about why we think
> > that's necessary.
>
> I did, in the original post, try to explain why I think it's necessary.
>
>   The OpenStack community wants to encourage collaboration by
>   emphasizing contributions to projects that abstract differences
>   between vendor-specific products, while still empowering vendors
>   to integrate their products with OpenStack through drivers that
>   can be consumed by the abstraction layers
>
> In addition to wanting collaboration between experts in a given
> field, projects support drivers to give deployers choices. Encouraging
> vendors to write drivers furthers both goals. It also encourages
> those same vendors to be active in the community in other ways,
> such as sponsoring events and the Foundation. Whether we achieve
> *that* goal depends on a lot of factors, and we're more successful
> with some vendors than others. Turning away contributions does not
> encourage their participation in any way I can understand.
>
> > What are the obstacles to the Neutron team agreeing to host these
> > drivers? Perhaps the TC is in a position to remove some of those
> > obstacles? That seems preferable to imposing new obligations on projects.
>
> I'll let someone from the Neutron team fill in the details behind their
> decision, because I don't want to misrepresent them.
>

I replied to Zane's initial email. I hope that provides some insight as to
why we went down the path we did.

Thanks,
Armando


>
> Doug
>
> >
> > cheers,
> > Zane.
> >
>
> __
> OpenStack Development Mailing 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] [all][tc] Allowing Teams Based on Vendor-specific Drivers

[Armando M.]

On 29 November 2016 at 09:36, Zane Bitter  wrote:

> On 29/11/16 10:28, Doug Hellmann wrote:
>
>> Excerpts from Chris Friesen's message of 2016-11-29 09:09:17 -0600:
>>
>>> On 11/29/2016 08:03 AM, Doug Hellmann wrote:
>>>
 I'll rank my preferred solutions, because I don't actually like any of
 them.

>>>
>>> Just curious...what would you "actually like"?
>>>
>>> Chris
>>>
>>>
>> My preference is to have teams just handle the drivers voluntarily,
>> without needing to make it a rule or provide a way to have teams
>> that only work on a driver. That's not one of the options we proposed,
>> but the results are like what we would get with option 6 (minus the
>> precedent of the TC telling teams what code they must manage).
>>
>
> I don't have a lot of background on why the driver was removed from the
> Neutron stadium, but reading between the lines it sounds like you think
> that Neutron made the Wrong Call, and that you would like, in order of
> preference:
>

In a nutshell: scalability. The list became huge, the core team was made in
charge of dealing with releases requests, backport requests, infra,
governance and doc changes etc. Any of those changes required a neutron
liasion vouching for them. This became untenable, distracting and defeating
the whole point of breaking down the monolithic codebase we were trying to
move away from. I (the PTL since Mitaka) personally felt that we needed to
empower the individual efforts to be in charge or their own destiny and at
the same time making sure that the neutron project as described by the
governance repo was cohesive and made sense to the eye of someone looking
at the project list.

If the eviction or exclusion of a driver caused a project and its
contributors lose their ATC status, access to horizontal teams services
(e.g. representation on docs.o.o, release.o.o), etc, I always thought that
was wrong; that should have not happened, and I hope this effort led by
Doug can fix that.

The neutron team cares about drivers, and I personally believe that are
very important to the success of the OpenStack community. That's why we
enabled the innovation by breaking them out and keeping/augmenting the
extension points provided by the core platform so that they are not stifled
by the chokepoint that the core team may represent. At the same time, I
care about quality and consistency, and I want to be proudly standing
behind the stuff I am involved in, and as such I don't want to be
erroneously associated with initiatives I (and the core team) cannot ever
have the bandwidth to deal with.


> a) Neutron to start agreeing with you; or
> b) The TC to tell Neutron to agree with you; or
> c) To do an end run around Neutron by adding it as a separate project
>
> Individual projects (like Neutron) have pretty wide latitude to add
> repositories if they want, and are presumably closer to the issues than
> anyone. So it seems strange that we're starting with a discussion about how
> to override their judgement, rather than one about why we think that's
> necessary.
>
> What are the obstacles to the Neutron team agreeing to host these drivers?
> Perhaps the TC is in a position to remove some of those obstacles? That
> seems preferable to imposing new obligations on projects.
>
> cheers,
> Zane.
>
>
> __
> OpenStack Development Mailing 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] [neutron] core and driver teams attrition

[Armando M.]

Hi Neutrinos,

By now a few of us have noticed that the neutron core and driver teams have
lost a number of very talented and experienced engineers: well...this sucks
there's no more polite way to put it!!

These engineers are the collective memory of the project, know the kinks
and gotchas of the codebase, and are very intimate with the overall
openstack machine. They leave a big void behind. It sad to see them go, but
personally I have the utmost confidence in the fact that they have groomed
other engineers to step up in a role of greater responsibility.

Ocata might be seen by some as a hiatus, and that's ok: take the time to
rest if you can, because the team is going to grow back stronger than ever,
and it will make neutron kick-ass, even more so than it already is.

You can count on it.

Happy hacking!
Armando
__
OpenStack Development Mailing 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][octavia] Neutron LBaaS governance change and Octavia to the big tent

[Armando M.]

On 1 December 2016 at 08:04, Michael Johnson  wrote:

> There are a lot more than just those three (which are under packaging
> and not neutron btw).
>
> I will start working on moving/scrubbing the bugs today.
>

At the same time, I'll be working to make sure we have a coordinated access
to lbaas backports (i.e. tweaking gerrit ACLs).

Cheers,
Armando


>
> Michael
>
> On Thu, Dec 1, 2016 at 7:30 AM, Brian Haley  wrote:
> > On 12/01/2016 08:54 AM, Ihar Hrachyshka wrote:
> >>
> >> Armando M.  wrote:
> >>
> >>> Hi folks,
> >>>
> >>> A few hours ago a governance change [1] has been approved by TC
> members.
> >>> This
> >>> means that from now on, the efforts for Load Balancing as a Service
> >>> efforts
> >>> rest officially in the hands of the Octavia PTL and the Octavia core
> >>> team.
> >>>
> >>> I will work with the help of the respective core teams to implement a
> >>> smooth
> >>> transition. My suggestion at this point is for any ML communication
> that
> >>> pertain LBaaS issues to include [octavia] tag on the email subject.
> >>>
> >>> Please do not hesitate to reach out for any questions and/or
> >>> clarifications.
> >>>
> >>> Cheers,
> >>> Armando
> >>>
> >>> [1] https://review.openstack.org/#/c/313056/
> >>
> >>
> >> Should we also move all neutron lbaas-tagged bugs to octavia in LP? And
> >> kill the
> >> ‘lbaas’ tag from doc/source/policies/bugs.rst?
> >
> >
> > Yes.  I added the lbaas bugs.rst tag removal to
> > https://review.openstack.org/#/c/404872/ already.  Can someone from
> Octavia
> > close and/or move-over any remaining lbaas bugs?  I only see three at
> > https://bugs.launchpad.net/ubuntu/+source/neutron-lbaas
> >
> > Thanks,
> >
> > -Brian
> >
> >
> > 
> __
> > OpenStack Development Mailing 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] [All][neutron-vpnaas] Finish test job transition to Ubuntu Xenial

[Armando M.]

On 1 December 2016 at 07:45, Andreas Jaeger  wrote:

> On 11/15/2016 12:30 AM, Clark Boylan wrote:
> > [...]
>
>> Just a friendly reminder that this is still happening. We will be
>> updating any jobs running on Trusty that should be running on Xenial on
>> December 6th. I have seen a few projects jump on this and start making
>> the necessary changes. Thank you for doing that!
>>
>
> The rally team has been updating jobs and neutron-vpnaas does not work for
> them since xenial now uses strongswan instead of openswan.
>
> They have disabled vpnaas now:
> https://review.openstack.org/#/c/403493/4
>
> vpnaas team, you will have to fix your setup so that your plugin works
> with Xenial! Would be great if you could do this before Tuesday - you might
> not be able to merge anything after the switch to Xenial,
>
>
I did file bug [1]. FWIW, vpnaas on strongswan works fine in xenial [2],
and if the rally teams feel like not losing vpnaas coverage, they could
switch to strongswan.

[1] https://bugs.launchpad.net/python-neutronclient/+bug/1645819
[2] https://review.openstack.org/#/c/404369/


> Andreas
> --
>  Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
>   SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
>GF: Felix Imendörffer, Jane Smithard, Graham Norton,
>HRB 21284 (AG Nürnberg)
> GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126
>
>
>
> __
> OpenStack Development Mailing 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] [all][tc] Exposing project team's metadata in README files

[Armando M.]

On 30 November 2016 at 12:16, Steve Martinelli 
wrote:

> This happened to us for keystone-specs [1]. I settled on removing the
> reference to the README.rst from the doc folder. You can do the same by
> removing [2].
>
> [1] https://review.openstack.org/#/c/402878/
> [2] https://github.com/openstack/neutron-lib/blob/
> master/doc/source/readme.rst
>

Thanks Steve, we'll follow suit!

Cheers,
Armando


>
> On Wed, Nov 30, 2016 at 2:44 PM, Armando M.  wrote:
>
>>
>>
>> On 30 November 2016 at 08:53, Michael Johnson 
>> wrote:
>>
>>> Hi Flavio,
>>>
>>> These tags don't seem to be rendering/laying out well for octavia:
>>> https://github.com/openstack/octavia/blob/master/README.rst
>>>
>>> Any pointers to get this corrected or is this part of the backend
>>> rendering work you mentioned in the keystone message above?
>>>
>>>
>> Actually I just noticed that this may break building docs locally for
>> some envs as I now get in my env:
>>
>> Warning, treated as error:
>> README.rst:None: WARNING: nonlocal image URI found:
>> http://governance.openstack.org/badges/neutron-lib.svg
>>
>> I was aware of [1], and I am unsure on the next steps. Can some advise?
>>
>> Thanks,
>> Armando
>>
>> [1] https://review.openstack.org/#/c/229951/
>>
>>
>>> Michael
>>>
>>> On Wed, Nov 30, 2016 at 1:34 AM, Flavio Percoco 
>>> wrote:
>>> > On 25/11/16 13:46 +, Amrith Kumar wrote:
>>> >>
>>> >> Flavio,
>>> >>
>>> >> I see a number of patches[1] which have been landed on this project
>>> but I
>>> >> find
>>> >> that at least the ones that were landed for Trove, and a random
>>> sampling
>>> >> of
>>> >> the others all to be different from what you proposed below[2] in one
>>> >> important aspect.
>>> >>
>>> >> In [2] you proposed a structure where the title of the document; or
>>> the
>>> >> first,
>>> >> and most prominent heading, would be the existing heading of the
>>> document,
>>> >> and
>>> >> the tags would be below that. In [2] for example, that was:
>>> >>
>>> >> "kombu - Messaging library for Python"
>>> >>
>>> >> and the tags would be in smaller font below that.
>>> >
>>> >
>>> > Hi,
>>> >
>>> > Some fixes landed yesterday to improve the badges layout. For those
>>> > interested,
>>> > here's an example of what it looks like now:
>>> >
>>> > https://github.com/openstack/keystone
>>> >
>>> > Basically, the horizontal padding was reduced to the minimum needed
>>> and the
>>> > badges width was set to the total width of the image.
>>> >
>>> > Hope this helps,
>>> > Flavio
>>> >
>>> >
>>> >> What I see in [3] the patch for Trove and the proposed example [4] is:
>>> >>
>>> >> "Team and repository tags" as the first, and most conspicuous header,
>>> and
>>> >> the
>>> >> header "Trove" below that.
>>> >>
>>> >> In some cases the second header is the same font as the "Team and
>>> >> repository
>>> >> tags" header.
>>> >>
>>> >> I think this change (these 124 changes) as proposed are not consistent
>>> >> with
>>> >> the proposal you made below, and certainly seem to be less suitable
>>> than
>>> >> that
>>> >> proposal. The end product for the four trove repositories [4], [5],
>>> [6],
>>> >> and
>>> >> [7]
>>> >>
>>> >> I think we should have a discussion on the ML whether we feel that
>>> this
>>> >> new
>>> >> structure is the appropriate one, and before some projects approve
>>> these
>>> >> changes and others don't that these be all marked WF-1.
>>> >>
>>> >> Thanks,
>>> >>
>>> >> -amrith
>>> >>
>>> >> [1] https://review.openstack.org/#/q/topic:project-badges
>>> >> [2] https://github.com/celery/kombu/blob/master/README.rst
>>> >> [3] https://review.openstack.org/#/c/402547

Re: [openstack-dev] [all][tc] Exposing project team's metadata in README files

[Armando M.]

On 30 November 2016 at 08:53, Michael Johnson  wrote:

> Hi Flavio,
>
> These tags don't seem to be rendering/laying out well for octavia:
> https://github.com/openstack/octavia/blob/master/README.rst
>
> Any pointers to get this corrected or is this part of the backend
> rendering work you mentioned in the keystone message above?
>
>
Actually I just noticed that this may break building docs locally for some
envs as I now get in my env:

Warning, treated as error:
README.rst:None: WARNING: nonlocal image URI found:
http://governance.openstack.org/badges/neutron-lib.svg

I was aware of [1], and I am unsure on the next steps. Can some advise?

Thanks,
Armando

[1] https://review.openstack.org/#/c/229951/


> Michael
>
> On Wed, Nov 30, 2016 at 1:34 AM, Flavio Percoco  wrote:
> > On 25/11/16 13:46 +, Amrith Kumar wrote:
> >>
> >> Flavio,
> >>
> >> I see a number of patches[1] which have been landed on this project but
> I
> >> find
> >> that at least the ones that were landed for Trove, and a random sampling
> >> of
> >> the others all to be different from what you proposed below[2] in one
> >> important aspect.
> >>
> >> In [2] you proposed a structure where the title of the document; or the
> >> first,
> >> and most prominent heading, would be the existing heading of the
> document,
> >> and
> >> the tags would be below that. In [2] for example, that was:
> >>
> >> "kombu - Messaging library for Python"
> >>
> >> and the tags would be in smaller font below that.
> >
> >
> > Hi,
> >
> > Some fixes landed yesterday to improve the badges layout. For those
> > interested,
> > here's an example of what it looks like now:
> >
> > https://github.com/openstack/keystone
> >
> > Basically, the horizontal padding was reduced to the minimum needed and
> the
> > badges width was set to the total width of the image.
> >
> > Hope this helps,
> > Flavio
> >
> >
> >> What I see in [3] the patch for Trove and the proposed example [4] is:
> >>
> >> "Team and repository tags" as the first, and most conspicuous header,
> and
> >> the
> >> header "Trove" below that.
> >>
> >> In some cases the second header is the same font as the "Team and
> >> repository
> >> tags" header.
> >>
> >> I think this change (these 124 changes) as proposed are not consistent
> >> with
> >> the proposal you made below, and certainly seem to be less suitable than
> >> that
> >> proposal. The end product for the four trove repositories [4], [5], [6],
> >> and
> >> [7]
> >>
> >> I think we should have a discussion on the ML whether we feel that this
> >> new
> >> structure is the appropriate one, and before some projects approve these
> >> changes and others don't that these be all marked WF-1.
> >>
> >> Thanks,
> >>
> >> -amrith
> >>
> >> [1] https://review.openstack.org/#/q/topic:project-badges
> >> [2] https://github.com/celery/kombu/blob/master/README.rst
> >> [3] https://review.openstack.org/#/c/402547/
> >> [4] https://gist.github.com/anonymous/4ccf1cc6e531bb50e78cb4d64dfe1065
> >> [5] https://gist.github.com/1f38def1c65c733b7e4cec3d07399e99
> >> [6] https://gist.github.com/2f1c6e9b800db6d4a49d46f5b0623c1d
> >> [7] https://gist.github.com/9e9e2e2ba4ecfdece7827082114f8258
> >>
> >>
> >>
> >>
> >>> -Original Message-
> >>> From: Flavio Percoco [mailto:fla...@redhat.com]
> >>> Sent: Thursday, October 13, 2016 7:07 AM
> >>> To: OpenStack Development Mailing List (not for usage questions)
> >>> 
> >>> Subject: Re: [openstack-dev] [all][tc] Exposing project team's metadata
> >>> in
> >>> README files
> >>>
> >>> On 12/10/16 11:01 -0400, Doug Hellmann wrote:
> >>> >Excerpts from Flavio Percoco's message of 2016-10-12 14:50:03 +0200:
> >>> >> Greetings,
> >>> >>
> >>> >> One of the common complains about the existing project organization
> >>> >> in the big tent is that it's difficult to wrap our heads around the
> >>> >> many projects there are, their current state (in/out the big tent),
> >>> >> their
> >>> tags, etc.
> >>> >>
> >>> >> This information is available on the governance website[0]. Each
> >>> >> official project team has a page there containing the information
> >>> >> related to the deliverables managed by that team. Unfortunately, I
> >>> >> don't think this page is checked often enough and I believe it's not
> >>> >> known
> >>> by everyone.
> >>> >>
> >>> >> In the hope that we can make this information clearer to people
> >>> >> browsing the many repos (most likely on github), I'd like to propose
> >>> >> that we include the information of each deliverable in the readme
> >>> >> file. This information would be rendered along with the rest of the
> >>> >> readme (at least on Github, which might not be our main repo but
> it's
> >>> >> the
> >>> place most humans go to to check our projects).
> >>> >>
> >>> >> Rather than duplicating this information, I'd like to find a way to
> >>> >> just "include it" in the Readme file. As far as showing the
> >>> >> "official" badge goes, I believe it'd be quite simple. We can do it
> >>>

Re: [openstack-dev] [neutron] [vpnaas] vpnaas no longer part of the neutron governance

[Armando M.]

On 27 November 2016 at 20:50, Takashi Yamamoto 
wrote:

> On Wed, Nov 16, 2016 at 11:02 AM, Armando M.  wrote:
> > Hi
> >
> > As of today, the project neutron-vpnaas is no longer part of the neutron
> > governance. This was a decision reached after the project saw a dramatic
> > drop in active development over a prolonged period of time.
> >
> > What does this mean in practice?
> >
> > From a visibility point of view, release notes and documentation will no
> > longer appear on openstack.org as of Ocata going forward.
> > No more releases will be published by the neutron release team.
> > The neutron team will stop proposing fixes for the upstream CI, if not
> > solely on a voluntary basis (e.g. I still felt like proposing [2]).
> >
> > How does it affect you, the user or the deployer?
> >
> > You can continue to use vpnaas and its CLI via the python-neutronclient
> and
> > expect it to work with neutron up until the newton
> > release/python-neutronclient 6.0.0. After this point, if you want a
> release
> > that works for Ocata or newer, you need to proactively request a release
> > [5], and reach out to a member of the neutron release team [3] for
> approval.
> > Assuming that the vpnaas CI is green, you can expect to have a working
> > vpnaas system upon release of its package in the foreseeable future.
> > Outstanding bugs and new bug reports will be rejected on the basis of
> lack
> > of engineering resources interested in helping out in the typical
> OpenStack
> > review workflow.
> > Since we are freezing the development of the neutron CLI in favor of the
> > openstack unified client (OSC), the lack of a plan to make the VPN
> commands
> > available in the OSC CLI means that at some point in the future the
> neutron
> > client CLI support for vpnaas may be dropped (though I don't expect this
> to
> > happen any time soon).
> >
> > Can this be reversed?
> >
> > If you are interested in reversing this decision, now it is time to step
> up.
> > That said, we won't be reversing the decision for Ocata. There is quite a
> > curve to ramp up to make neutron-vpnaas worthy of being classified as a
> > neutron stadium project, and that means addressing all the gaps
> identified
> > in [6]. If you are interested, please reach out, and I will work with
> you to
> > add your account to [4], so that you can drive the neutron-vpnaas agenda
> > going forward.
> >
> > Please do not hesitate to reach out to ask questions and/or
> clarifications.
>
> hi,
>
> i'm interested in working on the project.
> well, at least on the parts which is used by networking-midonet.
>

That's great to hear Yamamoto. Since you are already a neutron-core I
assume you are already intimate with the work required to strengthen the
VPNaaS project. I have added you to [4] and you can lean on me for any
changes that needs reviewing.


>
> >
> > Cheers,
> > Armando
> >
> > [1] https://review.openstack.org/#/c/392010/
> > [2] https://review.openstack.org/#/c/397924/
> > [3] https://review.openstack.org/#/admin/groups/150,members
> > [4] https://review.openstack.org/#/admin/groups/502,members
> > [5] https://github.com/openstack/releases
> > [6]
> > http://specs.openstack.org/openstack/neutron-specs/specs/
> stadium/ocata/neutron-vpnaas.html
> >
> > 
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev