Re: [openstack-dev] [neutron] change in argument type for allocate_partially_specified_segment

[Anna Taraday]

I pushed https://review.openstack.org/#/c/425023 as one of approaches.

On Wed, Jan 25, 2017 at 10:29 AM Anna Taraday <akamyshnik...@mirantis.com>
wrote:

> Thanks for bringing this up!
>
> I was assuming that from Ocata everyone should switch from usage 'old'
> TunnelTypeDriver to updated one.
>
> Revering both back to session means reverting all refactor and this is not
> in line with enginefacade work and as I remember some of OVO patches we
> waiting for this refactor too.
>
> I we can duplicate methods or we can check type of the argument if session
> or context and proceed differently. I will push patch for this ASAP.
>
> On Wed, Jan 25, 2017 at 2:15 AM Ihar Hrachyshka <ihrac...@redhat.com>
> wrote:
>
>> Hi Anna,
>>
>> I see that as part of [1], we changed the argument type for the $subj
>> function from session to context. Sadly, it turns out we still call it
>> with a session from the 'old' TunnelTypeDriver. I suspect the same
>> issue may affect allocate_fully_specified_segment.
>>
>> I assume that means all 'old' tunnel type drivers are broken. Should
>> we fix it by duplicating those two functions for old and new cases
>> too? Or should we revert both of them back to session? (I assume the
>> former, since the latter is not in line with enginefacade work.)
>>
>> [1]
>> https://review.openstack.org/#/c/398873/10/neutron/plugins/ml2/drivers/helpers.py
>>
>> Thanks in advance,
>> Ihar
>>
> --
> Regards,
> Ann Taraday
>
-- 
Regards,
Ann Taraday
__
OpenStack Development Mailing 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] change in argument type for allocate_partially_specified_segment

[Anna Taraday]

Thanks for bringing this up!

I was assuming that from Ocata everyone should switch from usage 'old'
TunnelTypeDriver to updated one.

Revering both back to session means reverting all refactor and this is not
in line with enginefacade work and as I remember some of OVO patches we
waiting for this refactor too.

I we can duplicate methods or we can check type of the argument if session
or context and proceed differently. I will push patch for this ASAP.

On Wed, Jan 25, 2017 at 2:15 AM Ihar Hrachyshka  wrote:

> Hi Anna,
>
> I see that as part of [1], we changed the argument type for the $subj
> function from session to context. Sadly, it turns out we still call it
> with a session from the 'old' TunnelTypeDriver. I suspect the same
> issue may affect allocate_fully_specified_segment.
>
> I assume that means all 'old' tunnel type drivers are broken. Should
> we fix it by duplicating those two functions for old and new cases
> too? Or should we revert both of them back to session? (I assume the
> former, since the latter is not in line with enginefacade work.)
>
> [1]
> https://review.openstack.org/#/c/398873/10/neutron/plugins/ml2/drivers/helpers.py
>
> Thanks in advance,
> Ihar
>
-- 
Regards,
Ann Taraday
__
OpenStack Development Mailing 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 projects that use Alembic] Absence of pk on alembic_version table

[Anna Taraday]

Change against master merged.
Backport for Newton - https://review.openstack.org/#/c/419320/

On Tue, Jan 24, 2017 at 7:44 PM Davanum Srinivas <dava...@gmail.com> wrote:

> Cool. Then i'd support a backport when the review against master
> merges. Thanks Ann and Kirill.
>
> -- Dims
>
> On Tue, Jan 24, 2017 at 10:33 AM, Anna Taraday
> <akamyshnik...@mirantis.com> wrote:
> > Nope, this won't be necessary.
> >
> > 0.8.10 - allows us to create pk on alembic_version table automatically,
> but
> > only for new deployments.
> >
> > I propose manually add pk on this table if it is not existing.
> >
> > On Tue, Jan 24, 2017 at 7:25 PM Davanum Srinivas <dava...@gmail.com>
> wrote:
> >>
> >> Ann,
> >>
> >> Don't you still need alembic>=0.8.10 to be present?
> >>
> >> -- Dims
> >>
> >> On Tue, Jan 24, 2017 at 10:05 AM, Anna Taraday
> >> <akamyshnik...@mirantis.com> wrote:
> >> > We do not backport db changes, but if the existing migration does not
> >> > work
> >> > in certain circumstances, should not we fix it to make it work if it
> is
> >> > possible?
> >> > This will allow to deploy new deployments with Newton code on Galera.
> >> >
> >> > On Tue, Jan 24, 2017 at 6:45 PM Davanum Srinivas <dava...@gmail.com>
> >> > wrote:
> >> >>
> >> >> Please see
> >> >>
> >> >>
> http://docs.openstack.org/project-team-guide/stable-branches.html#review-guidelines
> >> >>
> >> >> On Tue, Jan 24, 2017 at 9:34 AM, Davanum Srinivas <dava...@gmail.com
> >
> >> >> wrote:
> >> >> > Newton is already shipped!
> >> >> >
> >> >> > -- Dims
> >> >> >
> >> >> > On Tue, Jan 24, 2017 at 9:23 AM, Kirill Proskurin
> >> >> > <kprosku...@mirantis.com> wrote:
> >> >> >> Galera only supported since Ocata?
> >> >> >>
> >> >> >> On Tue, Jan 24, 2017 at 4:30 PM, Davanum Srinivas
> >> >> >> <dava...@gmail.com>
> >> >> >> wrote:
> >> >> >>>
> >> >> >>> Kirill,
> >> >> >>>
> >> >> >>> "If OS wants support Galera, it needs to comply with the Galera
> >> >> >>> requirements" <<< This is true for master/ocata NOT Newton.
> >> >> >>>
> >> >> >>> Ihar's response is perfectly acceptable thing to do for Newton in
> >> >> >>> the
> >> >> >>> community to highlight the possibility of this situation.
> >> >> >>> Downstream
> >> >> >>> folks can do what they need/have to do for Newton.
> >> >> >>>
> >> >> >>> Thanks,
> >> >> >>> Dims
> >> >> >>>
> >> >> >>> On Tue, Jan 24, 2017 at 4:49 AM, Kirill Proskurin
> >> >> >>> <kprosku...@mirantis.com> wrote:
> >> >> >>> > HI!
> >> >> >>> >
> >> >> >>> > Thing is, running Galera without enforcing it very bad idea for
> >> >> >>> > production
> >> >> >>> > use. Permissive mode was added more or less for testing
> purposes,
> >> >> >>> > running
> >> >> >>> > real production with it is dangerous, since it's not enforcing
> >> >> >>> > the
> >> >> >>> > mandatory
> >> >> >>> > Galera requirement, one of them is a "All tables must have a
> >> >> >>> > primary
> >> >> >>> > key".
> >> >> >>> > You cant disable a single check, you could only disable them
> all
> >> >> >>> > and
> >> >> >>> > this
> >> >> >>> > could lead to some serious problems, like data loss or
> >> >> >>> > corruption.
> >> >> >>> >
> >> >> >>> > If OS wants support Galera, it needs to comply with the Galera
> >> >> >>> > requirements.
> >> >> >>> >
> >> >> >>> > On Mon, Jan 23, 2017 at 9:59 PM, Ihar Hrachyshka

Re: [openstack-dev] [neutron] change in argument type for allocate_partially_specified_segment

[Anna Taraday]

OK, this makes sense. Thanks for clarification!

On Wed, Jan 25, 2017 at 10:50 PM Ihar Hrachyshka <ihrac...@redhat.com>
wrote:

> On Tue, Jan 24, 2017 at 10:29 PM, Anna Taraday
> <akamyshnik...@mirantis.com> wrote:
> > Thanks for bringing this up!
> >
> > I was assuming that from Ocata everyone should switch from usage 'old'
> > TunnelTypeDriver to updated one.
>
> I am not sure. We haven't marked the 'old' one with any deprecation
> warnings, did we? For Ocata at least, both classes will be available
> for use. In Pike, we can look at cleaning up the old class (either
> through deprecation warning and removal in Q; or using
> NeutronLibImpact process).
>
> >
> > Revering both back to session means reverting all refactor and this is
> not
> > in line with enginefacade work and as I remember some of OVO patches we
> > waiting for this refactor too.
> >
> > I we can duplicate methods or we can check type of the argument if
> session
> > or context and proceed differently. I will push patch for this ASAP.
> >
>
> I reviewed the patch, I think it's a good path forward, thanks.
>
> Ihar
>
-- 
Regards,
Ann Taraday
__
OpenStack Development Mailing 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 team social in Atlanta on Thursday

[Anna Taraday]

+1

On Sun, Feb 19, 2017 at 11:03 AM Takashi Yamamoto 
wrote:

> +1
>
> 2017/02/18 4:21 "Kevin Benton" :
>
> Hi all,
>
> I'm organizing a Neutron social event for Thursday evening in Atlanta
> somewhere near the venue for dinner/drinks. If you're interested, please
> reply to this email with a "+1" so I can get a general count for a
> reservation.
>
> 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
>
-- 
Regards,
Ann Taraday
__
OpenStack Development Mailing List (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] Alternative approaches for L3 HA

[Anna Taraday]

Hello everyone!

In Juno in Neutron was implemented L3 HA feature based on Keepalived
(VRRP). During next cycles it was improved, we performed scale testing [1]
to find weak places and tried to fix them. The only alternative for L3 HA
with VRRP is router rescheduling performed by Neutron server, but it is
significantly slower and depends on control plane.

What issues we experienced with L3 HA VRRP?

   1. Bugs in Keepalived (bad versions) [2]
   2. Split brain [3]
   3. Complex structure (ha networks, ha interfaces) - which actually cause
   races that we were fixing during Liberty, Mitaka and Newton.

This all is not critical, but this is a bad experience and not everyone
ready (or want) to use Keepalived approach.

I think we can make things more flexible. For example, we can allow user to
use external services like etcd instead of Keepalived to synchronize
current HA state across agents. I've done several experiments and I've got
failover time comparable to L3 HA with VRRP. Tooz [4] can be used to
abstract from concrete backend. For example, it can allow us to use
Zookeeper, Redis and other backends to store HA state.

What I want to propose?

I want to bring up idea that Neutron should have some general classes for
L3 HA which will allow to use not only Keepalived but also other backends
for HA state. This at least will make it easier to try some other
approaches and compare them with existing ones.

Does this sound reasonable?

[1] -
http://docs.openstack.org/developer/performance-docs/test_results/neutron_features/index.html
[2] - https://bugs.launchpad.net/neutron/+bug/1497272
https://bugs.launchpad.net/neutron/+bug/1433172
[3] - https://bugs.launchpad.net/neutron/+bug/1375625
[4] - http://docs.openstack.org/developer/tooz/




-- 
Regards,
Ann Taraday
__
OpenStack Development Mailing 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

[Anna Taraday]

If I propose some concrete solution that will be discussion about one
solution not about making things flexible.
At first I wanted to propose some PoC for other approach, but during my
experiments I understood that we may have different approaches, but for all
of them we need pluggable HA router in Neutron.

The thing that bothers me about L3 HA - it is complex. Yes, we fixed bunch
of races and John did significant refactor, but it is still too complex. In
the end we want to use L3 HA + DVR but DVR is pretty complex by itself. We
would like to try to offload this complexity to external service to replace
management of keepalived instances and networks withing Neutron. Router
rescheduling is not really an alternative for L3 HA.

RDO with L3 HA is a great example of success, but we want to have ability
to try something else that can suit other OpenStack deployments better.

I wrote this email to understand whether community have interest in
something like this, so that it will be worth doing.

On Tue, Feb 14, 2017 at 10:20 PM Assaf Muller <as...@redhat.com> wrote:

On Fri, Feb 10, 2017 at 12:27 PM, Anna Taraday
<akamyshnik...@mirantis.com> wrote:
> Hello everyone!
>
> In Juno in Neutron was implemented L3 HA feature based on Keepalived
(VRRP).
> During next cycles it was improved, we performed scale testing [1] to find
> weak places and tried to fix them. The only alternative for L3 HA with
VRRP
> is router rescheduling performed by Neutron server, but it is
significantly
> slower and depends on control plane.
>
> What issues we experienced with L3 HA VRRP?
>
> Bugs in Keepalived (bad versions) [2]
> Split brain [3]
> Complex structure (ha networks, ha interfaces) - which actually cause
races
> that we were fixing during Liberty, Mitaka and Newton.
>
> This all is not critical, but this is a bad experience and not everyone
> ready (or want) to use Keepalived approach.
>
> I think we can make things more flexible. For example, we can allow user
to
> use external services like etcd instead of Keepalived to synchronize
current
> HA state across agents. I've done several experiments and I've got
failover
> time comparable to L3 HA with VRRP. Tooz [4] can be used to abstract from
> concrete backend. For example, it can allow us to use Zookeeper, Redis and
> other backends to store HA state.
>
> What I want to propose?
>
> I want to bring up idea that Neutron should have some general classes for
L3
> HA which will allow to use not only Keepalived but also other backends for
> HA state. This at least will make it easier to try some other approaches
and
> compare them with existing ones.
>
> Does this sound reasonable?

I understand that the intention is to add pluggability upstream so
that you could examine the viability of alternative solutions. I'd
advise instead to do the research locally, and if you find concrete
benefits to an alternative solution, come back, show your work and
have a discussion about it then. Merging extra complexity in the form
of a plug point without knowing if we're actually going to need it
seems risky.

On another note, after years of work the stability issues have largely
been resolved and L3 HA is in a good state with modern releases of
OpenStack. It's not a authoritative solution in the sense that it
doesn't cover every possible failure mode, but it covers the major
ones and in that sense better than not having any form of HA, and as
you pointed out the existing alternatives are not in a better state.
The subtext in your email is that now L3 HA is technically where we
want it, but some users are resisting adoption because of bad PR or a
bad past experience, but not for technical reasons. If that is the
case, then perhaps some good PR would be a more cost effective
investment than investigating, implementing, stabilizing and
maintaining a different backend that will likely take at least a cycle
to get merged and another 1 to 2 cycles to iron out kinks. Would you
have a critical mass of developers ready to support a pluggable L3 HA
now and in the long term?

Finally, I can share that L3 HA has been the default in RDO-land for a
few cycles now and is being used widely and successfully, in some
cases at significant scale.

>
> [1] -
>
http://docs.openstack.org/developer/performance-docs/test_results/neutron_features/index.html
> [2] - https://bugs.launchpad.net/neutron/+bug/1497272
> https://bugs.launchpad.net/neutron/+bug/1433172
> [3] - https://bugs.launchpad.net/neutron/+bug/1375625
> [4] - http://docs.openstack.org/developer/tooz/
>
>
>
>
> --
> Regards,
> Ann Taraday
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.or

Re: [openstack-dev] [Neutron] Alternative approaches for L3 HA

[Anna Taraday]

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
__
OpenStack Development Mailing 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

[Anna Taraday]

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 <cristi.ca...@orange.com> 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 <changzhi1...@gmail.com> 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 be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete 
> this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been 
> modified, changed or falsified.
> 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
>
-- 
Regards,
Ann Taraday
__
OpenStack Development Mailing 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 projects that use Alembic] Absence of pk on alembic_version table

[Anna Taraday]

We do not backport db changes, but if the existing migration does not work
in certain circumstances, should not we fix it to make it work if it is
possible?
This will allow to deploy new deployments with Newton code on Galera.

On Tue, Jan 24, 2017 at 6:45 PM Davanum Srinivas <dava...@gmail.com> wrote:

> Please see
> http://docs.openstack.org/project-team-guide/stable-branches.html#review-guidelines
>
> On Tue, Jan 24, 2017 at 9:34 AM, Davanum Srinivas <dava...@gmail.com>
> wrote:
> > Newton is already shipped!
> >
> > -- Dims
> >
> > On Tue, Jan 24, 2017 at 9:23 AM, Kirill Proskurin
> > <kprosku...@mirantis.com> wrote:
> >> Galera only supported since Ocata?
> >>
> >> On Tue, Jan 24, 2017 at 4:30 PM, Davanum Srinivas <dava...@gmail.com>
> wrote:
> >>>
> >>> Kirill,
> >>>
> >>> "If OS wants support Galera, it needs to comply with the Galera
> >>> requirements" <<< This is true for master/ocata NOT Newton.
> >>>
> >>> Ihar's response is perfectly acceptable thing to do for Newton in the
> >>> community to highlight the possibility of this situation. Downstream
> >>> folks can do what they need/have to do for Newton.
> >>>
> >>> Thanks,
> >>> Dims
> >>>
> >>> On Tue, Jan 24, 2017 at 4:49 AM, Kirill Proskurin
> >>> <kprosku...@mirantis.com> wrote:
> >>> > HI!
> >>> >
> >>> > Thing is, running Galera without enforcing it very bad idea for
> >>> > production
> >>> > use. Permissive mode was added more or less for testing purposes,
> >>> > running
> >>> > real production with it is dangerous, since it's not enforcing the
> >>> > mandatory
> >>> > Galera requirement, one of them is a "All tables must have a primary
> >>> > key".
> >>> > You cant disable a single check, you could only disable them all and
> >>> > this
> >>> > could lead to some serious problems, like data loss or corruption.
> >>> >
> >>> > If OS wants support Galera, it needs to comply with the Galera
> >>> > requirements.
> >>> >
> >>> > On Mon, Jan 23, 2017 at 9:59 PM, Ihar Hrachyshka <
> ihrac...@redhat.com>
> >>> > wrote:
> >>> >>
> >>> >> An alternative could also be, for Newton and earlier, to release a
> >>> >> note saying that operators should not run the code against ENFORCING
> >>> >> galera mode. What are the reasons to enable that mode in OpenStack
> >>> >> scope that would not allow operators to live without it for another
> >>> >> cycle?
> >>> >>
> >>> >> Ihar
> >>> >>
> >>> >> On Mon, Jan 23, 2017 at 10:12 AM, Anna Taraday
> >>> >> <akamyshnik...@mirantis.com> wrote:
> >>> >> > Hello everyone!
> >>> >> >
> >>> >> > Guys in our team faced an issue when they try to run alembic
> >>> >> > migrations
> >>> >> > on
> >>> >> > Galera with ENFORCING mode. [1]
> >>> >> >
> >>> >> > This was an issue with Alembic [2], which was quickly fixed by
> Mike
> >>> >> > Bayer
> >>> >> > (many thanks!) and new version of alembic was resealed [3].
> >>> >> > The global requirements are updated [4].
> >>> >> >
> >>> >> > I think that it is desired to fix this for Newton at least. We
> cannot
> >>> >> > bump
> >>> >> > requirements for Newton, so hot fix can be putting pk on this
> table
> >>> >> > in
> >>> >> > the
> >>> >> > first migration like proposed [5].  Any other ideas?
> >>> >> >
> >>> >> > [1] - https://bugs.launchpad.net/neutron/+bug/1655610
> >>> >> > [2] - https://bitbucket.org/zzzeek/alembic/issues/406
> >>> >> > [3] -
> >>> >> >
> >>> >> >
> http://alembic.zzzcomputing.com/en/latest/changelog.html#change-0.8.10
> >>> >> > [4] - https://review.openstack.org/#/c/423118/
> >>> >> > [5] - https://review.openstack.org/#/c/419320/
> >>> >> >
> >>> >>

[openstack-dev] [All projects that use Alembic] Absence of pk on alembic_version table

[Anna Taraday]

Hello everyone!

Guys in our team faced an issue when they try to run alembic migrations on
Galera with ENFORCING mode. [1]

This was an issue with Alembic [2], which was quickly fixed by Mike Bayer
(many thanks!) and new version of alembic was resealed [3].
The global requirements are updated [4].

I think that it is desired to fix this for Newton at least. We cannot bump
requirements for Newton, so hot fix can be putting pk on this table in the
first migration like proposed [5].  Any other ideas?

[1] - https://bugs.launchpad.net/neutron/+bug/1655610
[2] - https://bitbucket.org/zzzeek/alembic/issues/406
[3] - http://alembic.zzzcomputing.com/en/latest/changelog.html#change-0.8.10
[4] - https://review.openstack.org/#/c/423118/
[5] - https://review.openstack.org/#/c/419320/


-- 
Regards,
Ann Taraday
__
OpenStack Development Mailing 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 projects that use Alembic] Absence of pk on alembic_version table

[Anna Taraday]

Nope, this won't be necessary.

0.8.10 - allows us to create pk on alembic_version table automatically, but
only for new deployments.

I propose manually add pk on this table if it is not existing.

On Tue, Jan 24, 2017 at 7:25 PM Davanum Srinivas <dava...@gmail.com> wrote:

> Ann,
>
> Don't you still need alembic>=0.8.10 to be present?
>
> -- Dims
>
> On Tue, Jan 24, 2017 at 10:05 AM, Anna Taraday
> <akamyshnik...@mirantis.com> wrote:
> > We do not backport db changes, but if the existing migration does not
> work
> > in certain circumstances, should not we fix it to make it work if it is
> > possible?
> > This will allow to deploy new deployments with Newton code on Galera.
> >
> > On Tue, Jan 24, 2017 at 6:45 PM Davanum Srinivas <dava...@gmail.com>
> wrote:
> >>
> >> Please see
> >>
> http://docs.openstack.org/project-team-guide/stable-branches.html#review-guidelines
> >>
> >> On Tue, Jan 24, 2017 at 9:34 AM, Davanum Srinivas <dava...@gmail.com>
> >> wrote:
> >> > Newton is already shipped!
> >> >
> >> > -- Dims
> >> >
> >> > On Tue, Jan 24, 2017 at 9:23 AM, Kirill Proskurin
> >> > <kprosku...@mirantis.com> wrote:
> >> >> Galera only supported since Ocata?
> >> >>
> >> >> On Tue, Jan 24, 2017 at 4:30 PM, Davanum Srinivas <dava...@gmail.com
> >
> >> >> wrote:
> >> >>>
> >> >>> Kirill,
> >> >>>
> >> >>> "If OS wants support Galera, it needs to comply with the Galera
> >> >>> requirements" <<< This is true for master/ocata NOT Newton.
> >> >>>
> >> >>> Ihar's response is perfectly acceptable thing to do for Newton in
> the
> >> >>> community to highlight the possibility of this situation. Downstream
> >> >>> folks can do what they need/have to do for Newton.
> >> >>>
> >> >>> Thanks,
> >> >>> Dims
> >> >>>
> >> >>> On Tue, Jan 24, 2017 at 4:49 AM, Kirill Proskurin
> >> >>> <kprosku...@mirantis.com> wrote:
> >> >>> > HI!
> >> >>> >
> >> >>> > Thing is, running Galera without enforcing it very bad idea for
> >> >>> > production
> >> >>> > use. Permissive mode was added more or less for testing purposes,
> >> >>> > running
> >> >>> > real production with it is dangerous, since it's not enforcing the
> >> >>> > mandatory
> >> >>> > Galera requirement, one of them is a "All tables must have a
> primary
> >> >>> > key".
> >> >>> > You cant disable a single check, you could only disable them all
> and
> >> >>> > this
> >> >>> > could lead to some serious problems, like data loss or corruption.
> >> >>> >
> >> >>> > If OS wants support Galera, it needs to comply with the Galera
> >> >>> > requirements.
> >> >>> >
> >> >>> > On Mon, Jan 23, 2017 at 9:59 PM, Ihar Hrachyshka
> >> >>> > <ihrac...@redhat.com>
> >> >>> > wrote:
> >> >>> >>
> >> >>> >> An alternative could also be, for Newton and earlier, to release
> a
> >> >>> >> note saying that operators should not run the code against
> >> >>> >> ENFORCING
> >> >>> >> galera mode. What are the reasons to enable that mode in
> OpenStack
> >> >>> >> scope that would not allow operators to live without it for
> another
> >> >>> >> cycle?
> >> >>> >>
> >> >>> >> Ihar
> >> >>> >>
> >> >>> >> On Mon, Jan 23, 2017 at 10:12 AM, Anna Taraday
> >> >>> >> <akamyshnik...@mirantis.com> wrote:
> >> >>> >> > Hello everyone!
> >> >>> >> >
> >> >>> >> > Guys in our team faced an issue when they try to run alembic
> >> >>> >> > migrations
> >> >>> >> > on
> >> >>> >> > Galera with ENFORCING mod

Re: [openstack-dev] Fwd: Questions regardin https://review.openstack.org/#/c/289595/11/tools/database-migration-from-v1-to-v2.py

[Anna Taraday]

Hi!

I guess you hit https://bugs.launchpad.net/neutron/+bug/1503342, seems we
need to reopen it.

I can only suggest to create migration manually   "neutron-db-manage
--config-file /etc/neutron/neutron.conf revision -m "description of
revision" --contact/expand.
Then you will see path to file which was generated, you can edit this file
and add operation that you need.


On Thu, Sep 29, 2016 at 12:19 PM Alex Stafeyev  wrote:

> Hi
>
> I am trying to execute the lbaas db upgrade procedure but I have several
> question regarding this.
>
> From the patch:
>
> I moved to /neutron-lbaas/neutron_lbaas/db/migration
>
>
>  - Create a revision file
> I executed "neutron-db-manage revision -m "description of revision"
> --autogenerate"
>
> At this point I saw an error:
> ERROR [alembic.util.messaging] Multiple heads are present; please specify
> the head revision on which the new revision should be based, or perform a
> merge.
>   FAILED: Multiple heads are present; please specify the head revision on
> which the new revision should be based, or perform a merge.
> [
>  but checking history and migration  ( neutron-db-manage check_migration
> and neutron-db-manage history) I saw no error.
>
> No files seemed to be generated.
>
>  - Edit the created file and fill the content properly with this file
> This step is not clear to me ^
>  - Run alembic upgrade head
> What is the commend for that? (neutron-db-manage upgrade ? Did , fails)
>
>  - Run the migration upgrade code
> what is the best way to execute the command? ( python the_script.py?)
>
> Kind regards
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-- 
Regards,
Ann Taraday
__
OpenStack Development Mailing 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] Database field sizes and attribute "MAX_LEN" constants

[Anna Taraday]

Henry, thanks for taking care of this!

In my opinion, it is just safe to use raw values in migration, because
migration is a strict point in time.

I remember how many patches I send in havana in Neutron for fixing
synchronization issues. Usage constants everywhere can be good in this
case, but ModelMigrationSyc did such check of this for us already.

If we want to have constants everywhere, we should guarantee that they are
unchanged - have test in neutron-lib which verifies their values.


On Sat, Oct 15, 2016 at 10:41 PM Henry Gessau  wrote:

Hi neutrinos,

In Neutron many attributes are stored in database fields. The size of these
fields therefore determines the maximum length of the attribute values.

I would like to get some consistency in place around how we define the
constants and where they are used. Here are my thoughts...


1. Raw sizes in alembic migrations

In the alembic migrations which build the DB schema, we should use the raw
number value of the field size.

2. FOO_FIELD_SIZE in the sqlalchemy models

In the sqlalchemy models, we should use the _FIELD_SIZE constants
defined in neutron_lib/db/constants.py

3. Everywhere else, use FOO_FIELD_SIZE, or another constant (like
FOO_MAX_LEN)
based on FOO_FIELD_SIZE.


"Why raw numbers in alembic migrations?", you may ask. Well, we have tests
that verify that the models match the schema generated by migrations. If
both
the models and the migrations use the constants then the tests would not
detect if a patch changes the constant value.

By using raw numbers in migrations, together with our rule of not allowing
changes to existing migrations, we allow the tests to detect and fail on any
attempt to alter a FIELD_SIZE constant.

Let me know if this makes sense or if you think it's a terrible idea.

If there are no objections, I intend to submit a patch or patches to:
 - replace constants with numbers in existing migrations
 - ensure all models use the appropriate constants

Existing code uses FOO_MAX_LEN in a lot of places. In most of these places
it
would make sense to simply switch to using FOO_FIELD_SIZE. However, some
code
may be quite far removed from the DB and would look better by sticking to
FOO_MAX_LEN. I added item 3. above to allow for that.


__
OpenStack Development Mailing 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
__
OpenStack Development Mailing 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 team social event in Barcelona

[Anna Taraday]

Very nice place, I'd love to come :)
+1

On Mon, Oct 17, 2016 at 11:18 AM  wrote:

> Hello,
>
> +1
>
> --
> Sławek Kapłoński
> sla...@kaplonski.pl
>
>
> W dniu 14.10.2016 20:30, Miguel Lavalle napisał(a):
>
> > Dear Neutrinos,
> >
> > I am organizing a social event for the team on Thursday 27th at 19:30.
> > After doing some Google research, I am proposing Raco de la Vila, which
> > is located in Poblenou: http://www.racodelavila.com/en/index.htm. The
> > menu is here: http://www.racodelavila.com/en/carta-racodelavila.htm
> >
> > It is easy to get there by subway from the Summit venue:
> > https://goo.gl/maps/HjaTEcBbDUR2. I made a reservation for 25 people
> > under 'Neutron' or "Miguel Lavalle". Please confirm your attendance so
> > we can get a final count.
> >
> > Here's some reviews:
> >
> https://www.tripadvisor.com/Restaurant_Review-g187497-d1682057-Reviews-Raco_De_La_Vila-Barcelona_Catalonia.html
> >
> > Cheers
> >
> > 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
>
-- 
Regards,
Ann Taraday
__
OpenStack Development Mailing List (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-*] Refactor of segments db

[Anna Taraday]

Hello everyone!
I'm working on implementation new engine facade in Neutron. [1] We have a
number of functions that expect to get session as one the arguments.
Passing session is not correct and this prevents of usage new enginefacade
which expect context to be passed and session to be injected in current
context. And also when we use new enginefacade the concept of a
"subtransaction" is completely different. So, I made refactor patch for
Neutron [2]. As these changes affect other projects that use these
functions, I propose patches to fix them [3].
Kindly, please be aware of these changes.
[1] - https://blueprints.launchpad.net/neutron/+spec/enginefacade-switch [2]
- https://review.openstack.org/#/c/398873/
[4] -
https://review.openstack.org/#/q/message:%22Change+passing+session+to+context+in+segments+db+functions%22
-- 
Regards,
Ann Taraday
__
OpenStack Development Mailing 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] Database field sizes and attribute "MAX_LEN" constants

[Anna Taraday]

Ihar, we all adults here, but this does not save us from making silly
mistakes sometimes :(
I think that if we can protect from possible mistakes - lets do this, as
messing up with size of fields is a common issue.

On Mon, Oct 17, 2016 at 2:16 PM Ihar Hrachyshka <ihrac...@redhat.com> wrote:

> Henry Gessau <hen...@gessau.net> wrote:
>
> > Anna Taraday <akamyshnik...@mirantis.com> wrote:
> >> Henry, thanks for taking care of this!
> >>
> >> In my opinion, it is just safe to use raw values in migration, because
> >> migration is a strict point in time.
> >>
> >> I remember how many patches I send in havana in Neutron for fixing
> >> synchronization issues. Usage constants everywhere can be good in this
> >> case,
> >> but ModelMigrationSyc did such check of this for us already.
> >>
> >> If we want to have constants everywhere, we should guarantee that they
> are
> >> unchanged - have test in neutron-lib which verifies their values.
> >
> > Yes, we could have some tests, although a patch changing a constant would
> > probably also have a change to the test. :) We might need to also have a
> > prominent "Warning! Do not change this test!" comment for each test.
>
> I actually think (or hope) everyone is adult here, and will be able to
> block a patch changing a constant, even if there is no unit test written,
> especially if we put such a warning in a comment above the constants we
> know are especially unsafe to touch.
>
> But if we are still think that it’s better safe than sorry, we could have
> some tests to make that even more explicit. It just seems like a waste of
> cpu cycles when any careful reviewer can spot such an issue.
>
> Anyhow, whatever works for the goal, that I think is: making constants safe
> to use in all relevant contexts, including alembic.
>
> 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
>
-- 
Regards,
Ann Taraday
__
OpenStack Development Mailing 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] Stepping down as testing lieutenant and from the core & drivers teams

[Anna Taraday]

It was real pleasure to work with you!
Thank you for your guidance and comments, we will miss that :(
Wish you all the best!

On Tue, Nov 29, 2016 at 9:55 AM Vikram Choudhary <
vikram.choudh...@huawei.com> wrote:

> Hi Assaf,
>
> Wish you all the best for your future endeavor!
>
> Thanks
> Vikram
>
>
> -Original Message-
> From: Vasudevan, Swaminathan (PNB Roseville) [mailto:
> swaminathan.vasude...@hpe.com]
> Sent: 29 November 2016 00:35
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [neutron] Stepping down as testing lieutenant
> and from the core & drivers teams
>
> Hi Assaf,
> Sorry to hear that you are stepping down. Thanks for your contribution to
> neutron and making the test suite more stable.
> Wish you all success in your current job.
>
> Thanks
> Swami
>
> -Original Message-
> From: Assaf Muller [mailto:as...@redhat.com]
> Sent: Monday, November 28, 2016 10:59 AM
> To: OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>
> Subject: [openstack-dev] [neutron] Stepping down as testing lieutenant and
> from the core & drivers teams
>
> Hi all,
>
> For the past few months I've been gaining more responsibilities within Red
> Hat. I have less time to dedicate to personal contribution and it's had a
> considerable tole on my ability to perform my duties upstream to the degree
> of effectiveness I am satisfied with. To that end, I've decided that the
> right thing to do is to hand over my testing lieutenant responsibilities to
> Jakub Libosvar, and to step down from the core and drivers team.
>
> This is a bitter sweet moment. I'm enormously proud to see the progress
> Neutron as a platform, community and as a reference implementation have
> made over the last 3 years and I'm thrilled to have taken part in that.
> It's grown from an experiment to a ubiquitous OpenStack project with a
> proven, robust and scalable batteries-included implementation used at the
> largest retail, insurance, banking, web and telco (And more!) companies in
> the world.
> My focus will remain on OpenStack networking but my contributions will be
> indirect through my amazing team members. The people leading Quantum when I
> joined are nearly all gone and luckily we've seen a continuous influx of
> fresh talent ready to take over leadership responsibilities. I'm confident
> the wheel will keep on spinning and the project will continue stepping down
> the right path.
>
> I'll still be on IRC and I'll be working over the upcoming couple of weeks
> to hand off any specific tasks I had going on. Have fun folks.
>
> __
> OpenStack Development Mailing List (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
>
-- 
Regards,
Ann Taraday
__
OpenStack Development Mailing List (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-*] Refactor ml2/db file

[Anna Taraday]

Hello everyone!
I'm working on implementation new engine facade in Neutron. [1]   I wrote
before about refactoring segments db code, along with that refactor of
ml2/db.py [2] is also required (to pass context instead of session).
I proposed patch for Neutron and affected
projects(networking-cisco, networking-fortinet, networking-brocade,
networking-vsphere
).
[3]

Kindly, please be aware of these changes.

[1] - https://blueprints.launchpad.net/neutron/+spec/enginefacade-switch
[2] - https://review.openstack.org/#/c/404714/
[3] - https://review.openstack.org/#/q/topic:refactor_ml2db
-- 
Regards,
Ann Taraday
__
OpenStack Development Mailing 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-*] Refactor ml2/db file

[Anna Taraday]

Hi!

Please, be aware that change [1] in Neutron was merged . Cores of
networking-cisco, networking-fortinet, networking-brocade,
networking-vsphere
<https://review.openstack.org/#/projects/openstack/networking-vsphere,dashboards/default>
pay
attention for patches [2]

[1] - https://review.openstack.org/#/c/404714/
[2] - https://review.openstack.org/#/q/topic:refactor_ml2db

On Fri, Dec 9, 2016 at 1:49 PM Anna Taraday <akamyshnik...@mirantis.com>
wrote:

> Hello everyone!
> I'm working on implementation new engine facade in Neutron. [1]   I wrote
> before about refactoring segments db code, along with that refactor of
> ml2/db.py [2] is also required (to pass context instead of session).
> I proposed patch for Neutron and affected
> projects(networking-cisco, networking-fortinet, networking-brocade,
> networking-vsphere
> <https://review.openstack.org/#/projects/openstack/networking-vsphere,dashboards/default>).
> [3]
>
> Kindly, please be aware of these changes.
>
> [1] - https://blueprints.launchpad.net/neutron/+spec/enginefacade-switch
> [2] - https://review.openstack.org/#/c/404714/
> [3] - https://review.openstack.org/#/q/topic:refactor_ml2db
> --
> Regards,
> Ann Taraday
>
-- 
Regards,
Ann Taraday
__
OpenStack Development Mailing 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-*] Attention for upcoming refactoring

[Anna Taraday]

Hello everyone!

Please, note that all changes to Neutron merged.

Changes that needs to be merged for external repos:
segments db refactor -
https://review.openstack.org/#/q/status:open+branch:master+topic:segmentsdb
ml2 db refactor -
https://review.openstack.org/#/q/status:open+branch:master+topic:refactor_ml2db

Happy holidays for everyone!


On Thu, Dec 22, 2016 at 7:36 AM Russell Bryant <rbry...@redhat.com> wrote:

>
> On Wed, Dec 21, 2016 at 10:50 AM, Anna Taraday <akamyshnik...@mirantis.com
> > wrote:
>
> Hello everyone!
>
> I've got two changes with refactor of TypeDriver [1] and segments db [2]
> which is needed for implementation new engine facade [3].
>
> Reviewers of networking-cisco, networking-arista, networking-nec
> <https://review.openstack.org/#/projects/openstack/networking-nec,dashboards/default>
> , networking-midonet
> <https://review.openstack.org/#/projects/openstack/networking-midonet,dashboards/default>,
>  networking-edge-vpn, networking-bagpipe, tricircle, group-based-policy -
> pay attention for [4].
>
> Also recently merged refactor of ml2/db.py [5]. Fixes
> for networking-cisco, networking-cisco, networking-cisco - are on review [6]
>
> [1] - https://review.openstack.org/#/c/398873/
> [2] - https://review.openstack.org/#/c/406275/
> [3] - https://blueprints.launchpad.net/neutron/+spec/enginefacade-switch
> [4] - https://review.openstack.org/#/q/topic:segmentsdb
> [5] - https://review.openstack.org/#/c/404714/
> [6] -
> https://review.openstack.org/#/q/status:open++branch:master+topic:refactor_ml2db
>
>
> ​Thanks a lot for looking out for the various networking-* projects when
> working on changes like this.  It's really great to see.
>
> --
> Russell Bryant
> __
> OpenStack Development Mailing 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
__
OpenStack Development Mailing List (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-*] Attention for upcoming refactoring

[Anna Taraday]

Hello everyone!

I've got two changes with refactor of TypeDriver [1] and segments db [2]
which is needed for implementation new engine facade [3].

Reviewers of networking-cisco, networking-arista, networking-nec

, networking-midonet
,
networking-edge-vpn, networking-bagpipe, tricircle, group-based-policy
-
pay attention for [4].

Also recently merged refactor of ml2/db.py [5]. Fixes
for networking-cisco, networking-cisco, networking-cisco - are on review [6]

[1] - https://review.openstack.org/#/c/398873/
[2] - https://review.openstack.org/#/c/406275/
[3] - https://blueprints.launchpad.net/neutron/+spec/enginefacade-switch
[4] - https://review.openstack.org/#/q/topic:segmentsdb
[5] - https://review.openstack.org/#/c/404714/
[6] -
https://review.openstack.org/#/q/status:open++branch:master+topic:refactor_ml2db
-- 
Regards,
Ann Taraday
__
OpenStack Development Mailing 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] Engine facade

[Anna Taraday]

Hi!

I'm a little confused change https://review.openstack.org/#/c/452539/ is
about switching for new facade, does the master branch fails the same?

On Mon, Apr 3, 2017 at 8:35 AM Gary Kotton  wrote:

> Yes, sorry my bad for not adding it -
> http://logs.openstack.org/39/452539/2/check/gate-vmware-nsx-python27-ubuntu-xenial/14c019c/testr_results.html.gz
>
> Please see the test *test_create_port_dns_name*
>
> Thanks
>
> Gary
>
>
>
> *From: *Kevin Benton 
> *Reply-To: *OpenStack List 
> *Date: *Monday, April 3, 2017 at 12:56 AM
> *To: *OpenStack List 
> *Subject: *Re: [openstack-dev] [neutron] Engine facade
>
>
>
> Do you have a link to a traceback?
>
>
>
> On Apr 2, 2017 09:25, "Gary Kotton"  wrote:
>
> Hi,
>
> The change https://review.openstack.org/#/c/402750/ has broken the
> vmware-nsx plugin. I am not sure if this has had effect on any other
> decomposed plugins.
>
> One of the issues that we have is when we create a PortDNS object under a
> transaction we get an exception: DBReferenceError: (sqlite3.IntegrityError)
> FOREIGN KEY constraint failed [SQL: u'INSERT INTO portdnses (port_id,
> current_dns_name, current_dns_domain, previous_dns_name,
> previous_dns_domain, dns_name) VALUES (?, ?, ?, ?, ?, ?)'] [parameters:
> ('2f2039ac-e7e6-4cc3-a8a0-3298089d4afb', u'', u'', u'', u'',
> u'port-dns-name')]
>
> Any ideas?
>
> Thanks
>
> Gary
>
>
> __
> OpenStack Development Mailing List (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
>
-- 
Regards,
Ann Taraday
__
OpenStack Development Mailing 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] Engine facade

[Anna Taraday]

Hi!

This errors does not mean that foreign key usage is broken. This means that
there is a mess with transactions. As you paste small piece of trace it is
hard to say why this happen, but during my work I saw such errors and
resolve them. And probably you need to revisit your unit tests.

Please, send me email directly with links for traces, does this happen on
master branch, does it happen on one of your changes - it is hard to guess.


On Tue, Apr 4, 2017 at 11:16 AM Gary Kotton <gkot...@vmware.com> wrote:

Hi,

The problem that we have is that any foreign key usage under transactions
is now broken. An example of an exception that is raised is:



DBReferenceError: (sqlite3.IntegrityError) FOREIGN KEY constraint
failed [SQL: u'INSERT INTO neutron_nsx_firewall_section_mappings
(created_at, updated_at, neutron_id, nsx_id) VALUES (?, ?, ?, ?)']
[parameters: ('2017-04-04 06:48:25.595118', None,
'6a086bf1-b1c9-495f-bfca-810d6638e3fa',
'2563cd05-edd9-4c7f-9708-857a129e2642')]



This is a major refactor in the plugin (which I guess is part and parcel of
rolling with the punches). I am just concerned if we are the only folks
that have affected by this.

Thanks

Gary



*From: *Gary Kotton <gkot...@vmware.com>
*Reply-To: *OpenStack List <openstack-dev@lists.openstack.org>
*Date: *Monday, April 3, 2017 at 3:14 PM


*To: *OpenStack List <openstack-dev@lists.openstack.org>
*Subject: *Re: [openstack-dev] [neutron] Engine facade



Hi,

We needed to make all of those changes to just get the plugin to pass unit
tests and CI. We are still seeing lots of issues and need to look deeper.
The façade changes have caused a lot of instability issues. I am not 100%
sure why. Issues that we have seen:

1. object creation under a transaction broke

2. deleting DB entries under transaction also broke

Thanks

Gary





*From: *Anna Taraday <akamyshnik...@mirantis.com>
*Reply-To: *OpenStack List <openstack-dev@lists.openstack.org>
*Date: *Monday, April 3, 2017 at 11:53 AM
*To: *OpenStack List <openstack-dev@lists.openstack.org>
*Subject: *Re: [openstack-dev] [neutron] Engine facade



Hi!

I'm a little confused change https://review.openstack.org/#/c/452539/ is
about switching for new facade, does the master branch fails the same?



On Mon, Apr 3, 2017 at 8:35 AM Gary Kotton <gkot...@vmware.com> wrote:

Yes, sorry my bad for not adding it -
http://logs.openstack.org/39/452539/2/check/gate-vmware-nsx-python27-ubuntu-xenial/14c019c/testr_results.html.gz

Please see the test *test_create_port_dns_name*

Thanks

Gary



*From: *Kevin Benton <ke...@benton.pub>
*Reply-To: *OpenStack List <openstack-dev@lists.openstack.org>
*Date: *Monday, April 3, 2017 at 12:56 AM
*To: *OpenStack List <openstack-dev@lists.openstack.org>
*Subject: *Re: [openstack-dev] [neutron] Engine facade



Do you have a link to a traceback?



On Apr 2, 2017 09:25, "Gary Kotton" <gkot...@vmware.com> wrote:

Hi,

The change https://review.openstack.org/#/c/402750/ has broken the
vmware-nsx plugin. I am not sure if this has had effect on any other
decomposed plugins.

One of the issues that we have is when we create a PortDNS object under a
transaction we get an exception: DBReferenceError: (sqlite3.IntegrityError)
FOREIGN KEY constraint failed [SQL: u'INSERT INTO portdnses (port_id,
current_dns_name, current_dns_domain, previous_dns_name,
previous_dns_domain, dns_name) VALUES (?, ?, ?, ?, ?, ?)'] [parameters:
('2f2039ac-e7e6-4cc3-a8a0-3298089d4afb', u'', u'', u'', u'',
u'port-dns-name')]

Any ideas?

Thanks

Gary


__
OpenStack Development Mailing List (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

-- 

Regards,
Ann Taraday
__
OpenStack Development Mailing 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
__
OpenStack Development Mailing 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] stepping down from neutron core team

[Anna Taraday]

Thanks a lot for all that you've done! Wish you all the best!
On Fri, Apr 28, 2017 at 1:04 PM Miguel Angel Ajo Pelayo 
wrote:

>
> Hi everybody,
>
> Some of you already know, but I wanted to make it official.
>
> Recently I moved to work on the networking-ovn component,
> and OVS/OVN itself, and while I'll stick around and I will be available
> on IRC for any questions I'm already not doing a good work with
> neutron reviews, so...
>
> It's time to leave room for new reviewers.
>
> It's always a pleasure to work with you folks.
>
> Best regards,
> Miguel Ángel Ajo.
> __
> OpenStack Development Mailing 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
__
OpenStack Development Mailing 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] stepping down from core

[Anna Taraday]

Rossella,
It is pleasure to know you and your contribution for Neutron is remarkable
:) I wish you all the best!

On Fri, May 5, 2017 at 6:28 AM Edgar Magana 
wrote:

> Que??? Estás bien?
> Me ha sorprendido tu email.
>
> Sent from my iPhone
>
> > On May 4, 2017, at 6:55 AM, Rossella Sblendido 
> wrote:
> >
> > Hi all,
> >
> > I've moved to a new position recently and despite my best intentions I
> > was not able to devote to Neutron as much time and energy as I wanted.
> > It's time for me to move on and to leave room for new core reviewers.
> >
> > It's been a great experience working with you all, I learned a lot both
> > on the technical and on the human side.
> > I won't disappear, you will see me around in IRC, etc, don't hesitate to
> > contact me if you have any question or would like my feedback on
> something.
> >
> > ciao,
> >
> > Rossella
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >
> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openstack.org_cgi-2Dbin_mailman_listinfo_openstack-2Ddev=DwIGaQ=DS6PUFBBr_KiLo7Sjt3ljp5jaW5k2i9ijVXllEdOozc=G0XRJfDQsuBvqa_wpWyDAUlSpeMV4W1qfWqBfctlWwQ=4ETEPXXTG_yxobZ8tGP2CkB7HSll3hz5srfvMBYPSl0=U7b_viotsOSh4RtVSstF2bliq2LsKpaBRiGJRG21rmU=
> __
> OpenStack Development Mailing 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
__
OpenStack Development Mailing 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 L3 agent/Keepalived

[Anna Taraday]

Please, file a bug about that on https://bugs.launchpad.net/neutron/+bugs
with tag "l3-ha".

On Thu, Nov 30, 2017 at 6:00 AM Ajay Kalambur (akalambu) 
wrote:

> I noticed that this happens when the router HA interface shows status:
> Down what can cause the ha interface to do down
>
> Ajay
>
>
> From: Ajay Kalambur 
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Date: Wednesday, November 29, 2017 at 4:14 PM
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Subject: [openstack-dev] [neutron] Neutron L3 agent/Keepalived
>
> Hi
> I have a case where after running the system for a while I see that
> floating ip association API gets accepted and no Errors in neutron l3 logs
> But when I go into the qrouter namespace and check the qg- interface the
> floating ip is not added
> Also the keepalived.conf is not updated and SIGUP of the keepalived
> process is not done
>
> So whats the place to look in this case.  What is the flow in neutron l3
> agent who adds the floating ip to the qg- interface
> I see the router update notification received
> Key log snippet attached. As you can see SIGUP of keepalived is missing
> and also I confirmed keepalived configs are not updated
>
>
> 2017-11-29 14:32:08.883 78 DEBUG oslo_messaging._drivers.amqpdriver [-]
> received message with unique_id: b3886b998c3049e799170bb5351300d1 __call__
> /usr/lib/python2.7/site-packages/oslo_messaging/_drivers/amqpdriver.py:269
> 2017-11-29 14:32:08.885 78 DEBUG neutron.agent.l3.agent
> [req-6c505d32-2d1a-4392-8ea3-0bb888397b9e e759eebecc4648b4964d4ecf439dc0ff
> 13b4f6fb188048ba9bbf211344e3342f - - -] Got routers updated notification
> :[u'a1a59e5f-d74e-404d-a3aa-1667c4442aed'] routers_updated
> /usr/lib/python2.7/site-packages/neutron/agent/l3/agent.py:413
> 2017-11-29 14:32:08.886 78 DEBUG neutron.agent.l3.agent [-] Starting
> router update for a1a59e5f-d74e-404d-a3aa-1667c4442aed, action None,
> priority 0 _process_router_update
> /usr/lib/python2.7/site-packages/neutron/agent/l3/agent.py:487
> 2017-11-29 14:32:08.886 78 DEBUG oslo_messaging._drivers.amqpdriver [-]
> CALL msg_id: 92eb015c8c84489681b1efbe949fab8b exchange 'neutron' topic
> 'q-l3-plugin' _send
> /usr/lib/python2.7/site-packages/oslo_messaging/_drivers/amqpdriver.py:568
>
> 2017-11-29 14:32:09.571 78 DEBUG oslo_messaging._drivers.amqpdriver [-]
> received reply msg_id: 92eb015c8c84489681b1efbe949fab8b __call__
> /usr/lib/python2.7/site-packages/oslo_messaging/_drivers/amqpdriver.py:416
> 2017-11-29 14:32:09.571 78 DEBUG neutron.callbacks.manager [-] Notify
> callbacks [] for router, before_update _notify_loop
> /usr/lib/python2.7/site-packages/neutron/callbacks/manager.py:142
> 2017-11-29 14:32:09.572 78 DEBUG neutron.agent.l3.router_info [-] process
> router updates process
> /usr/lib/python2.7/site-packages/neutron/agent/l3/router_info.py:1105
> 2017-11-29 14:32:09.572 78 DEBUG neutron.agent.linux.utils [-] Running
> command (rootwrap daemon): ['ip', 'netns', 'exec',
> 'qrouter-a1a59e5f-d74e-404d-a3aa-1667c4442aed', 'find', '/sys/class/net',
> '-maxdepth', '1', '-type', 'l', '-printf', '%f '] execute_rootwrap_daemon
> /usr/lib/python2.7/site-packages/neutron/agent/linux/utils.py:105
> 2017-11-29 14:32:09.709 78 DEBUG neutron.agent.linux.utils [-] Exit code:
> 0 execute /usr/lib/python2.7/site-packages/neutron/agent/linux/utils.py:150
> 2017-11-29 14:32:09.710 78 DEBUG oslo_concurrency.lockutils [-] Lock
> "l3-agent-pd" acquired by "neutron.agent.linux.pd.sync_router" :: waited
> 0.000s inner
> /usr/lib/python2.7/site-packages/oslo_concurrency/lockutils.py:270
> 2017-11-29 14:32:09.710 78 DEBUG oslo_concurrency.lockutils [-] Lock
> "l3-agent-pd" released by "neutron.agent.linux.pd.sync_router" :: held
> 0.000s inner
> /usr/lib/python2.7/site-packages/oslo_concurrency/lockutils.py:282
> 2017-11-29 14:32:09.710 78 DEBUG neutron.agent.linux.utils [-] Running
> command (rootwrap daemon): ['ip', 'netns', 'exec',
> 'qrouter-a1a59e5f-d74e-404d-a3aa-1667c4442aed', 'find', '/sys/class/net',
> '-maxdepth', '1', '-type', 'l', '-printf', '%f '] execute_rootwrap_daemon
> /usr/lib/python2.7/site-packages/neutron/agent/linux/utils.py:105
> 2017-11-29 14:32:09.845 78 DEBUG neutron.agent.linux.utils [-] Exit code:
> 0 execute /usr/lib/python2.7/site-packages/neutron/agent/linux/utils.py:150
> 2017-11-29 14:32:09.846 78 DEBUG oslo_concurrency.lockutils [-] Acquired
> semaphore "iptables-qrouter-a1a59e5f-d74e-404d-a3aa-1667c4442aed" lock
> /usr/lib/python2.7/site-packages/oslo_concurrency/lockutils.py:212
> 2017-11-29 14:32:09.846 78 DEBUG neutron.agent.linux.utils [-] Running
> command (rootwrap daemon): ['ip', 'netns', 'exec',
> 'qrouter-a1a59e5f-d74e-404d-a3aa-1667c4442aed', 'iptables-save']
> execute_rootwrap_daemon
> /usr/lib/python2.7/site-packages/neutron/agent/linux/utils.py:105
> 2017-11-29 14:32:09.983 78 DEBUG 

Re: [openstack-dev] [Neutron] Propose Slawek Kaplonski for Neutron core

[Anna Taraday]

+1 !
Well deserved!

On Sun, Dec 3, 2017 at 1:03 PM Gary Kotton  wrote:

> +1
>
>
>
> Welcome to the team!
>
>
>
> *From: *Miguel Lavalle 
> *Reply-To: *OpenStack List 
> *Date: *Wednesday, November 29, 2017 at 9:21 PM
> *To: *OpenStack List 
> *Subject: *[openstack-dev] [Neutron] Propose Slawek Kaplonski for Neutron
> core
>
>
>
> 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
>
-- 
Regards,
Ann Taraday
__
OpenStack Development Mailing 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][stable] Stepping down from core

[Anna Taraday]

Ihar,

Neutron can not be what it is without all your work! Thank you and wish you
all the best!

On Wed, Jun 6, 2018 at 11:22 AM Andreas Scheuring <
scheu...@linux.vnet.ibm.com> wrote:

> Hi Ihar, it was always a pleasure learning from and working with you. Wish
> you all the best for your new project!
>
> ---
> Andreas Scheuring (andreas_s)
>
>
>
> On 4. Jun 2018, at 22:31, Ihar Hrachyshka  wrote:
>
> Hi neutrinos and all,
>
> As some of you've already noticed, the last several months I was
> scaling down my involvement in Neutron and, more generally, OpenStack.
> I am at a point where I feel confident my disappearance won't disturb
> the project, and so I am ready to make it official.
>
> I am stepping down from all administrative roles I so far accumulated
> in Neutron and Stable teams. I shifted my focus to another project,
> and so I just removed myself from all relevant admin groups to reflect
> the change.
>
> It was a nice 4.5 year ride for me. I am very happy with what we
> achieved in all these years and a bit sad to leave. The community is
> the most brilliant and compassionate and dedicated to openness group
> of people I was lucky to work with, and I am reminded daily how
> awesome it is.
>
> I am far from leaving the industry, or networking, or the promise of
> open source infrastructure, so I am sure we will cross our paths once
> in a while with most of you. :) I also plan to hang out in our IRC
> channels and make snarky comments, be aware!
>
> Thanks for the fish,
> 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
>
-- 
Regards,
Ann Taraday
__
OpenStack Development Mailing 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] Stepping down from core

[Anna Taraday]

Armando, you made Neutron what it is now. Thank you for all your work and
wish you all the best!

On Sun, Dec 24, 2017 at 4:16 PM reedip banerjee  wrote:

> Hi Armando,
> Its not easy to hear this news.
> But all the best of luck to you Armando for your future endeavors.
>
> Best Regards,
> Reedip
>
>
> On Sat, Dec 23, 2017 at 1:38 AM, German Eichberger <
> german.eichber...@rackspace.com> wrote:
>
>> Hi,
>>
>>
>>
>> Thanks for all the help and support over the years. Both LBaaS (Octavia)
>>  and FWaaS wouldn’t be what they are today without your leadership and
>> advice –
>>
>>
>>
>> All the best + good luck,
>>
>> German
>>
>>
>>
>> *From: *"Armando M." 
>> *Reply-To: *"OpenStack Development Mailing List (not for usage
>> questions)" 
>> *Date: *Friday, December 15, 2017 at 8:04 PM
>> *To: *"OpenStack Development Mailing List (not for usage questions)" <
>> openstack-dev@lists.openstack.org>
>> *Subject: *[openstack-dev] [neutron] Stepping down from core
>>
>>
>>
>> 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
>>
>>
>
>
> --
> Thanks and Regards,
> Reedip Banerjee
> IRC: reedip
>
>
>
>
> __
> OpenStack Development Mailing 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
__
OpenStack Development Mailing List (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] [Octavia] Multinode setup

[Anna Taraday]

Hello everyone!

I'm looking into how to run Octavia services (controller worker,
housekeeper, health manager) on several network nodes and get confused with
setup guide [1].
Is there any special config option for such case? (controller_ip_port_list
probably)
What manuals/docs/examples do we have except [2] ?

[1] -
https://docs.openstack.org/octavia/queens/contributor/guides/dev-quick-start.html
[2] -
https://github.com/openstack/octavia/blob/stable/queens/devstack/samples/multinode/local-2.conf
-- 
Regards,
Ann Taraday
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev