Re: [openstack-dev] [neutron][alembic] Upgrade of db with alembic migration script

[Anna Kamyshnikova]

Hi!

I've posted comment on your change. please check this out. I think I've
seen the similar issue on https://review.openstack.org/#/c/283802.

On Mon, Jul 4, 2016 at 11:54 PM, Sławek Kapłoński 
wrote:

> Hello,
>
> I'm working on patch to add QoS ingress bandwidth limit to Neutron
> currently: https://review.openstack.org/303626 and I have small problem
> with db upgrade with alembic.
> Problem description:
> In qos_bandwidth_limit_rules table now there is foreign key
> "qos_policy_id" with unique constraint.
> I need to add new column called "direction" to this table and then remove
> unique constraint for qos_policy_id. At the end I need to add new unique
> constraint to pair (direction, qos_policy_id).
> To do that I need to:
> 1. remove qos_policy_id foreign key
> 2. remove unique constraint for qos_policy_id (because it is not removed
> automatically)
> 3. add new column
> 4. add new unique constraint
>
> Points 3 and 4 are easy and there is no problem with it.
>
> Problem is with point 2 (remove unique constraint)
> To remove qos_policy_id fk I used function:
> neutron.db.migration.migration.remove_fks_from_table() and it is working
> fine but it's not removing unique constraint.
> I made some modification to this function:
> https://review.openstack.org/#/c/303626/21/neutron/db/migration/__init__.py
> and this modifications works fine for mysql but in pgsql this unique
> constraint is not removed so after all there is two constraints in table
> and this is wrong.
>
> I'm not expert in pgsql and alembic. Maybe someone with bigger
> experience can look on it and help me how to do such migration script?
>
> Thx in advance for any help.
>
> --
> Best regards / Pozdrawiam
> Sławek Kapłoński
> sla...@kaplonski.pl
>
>
> __
> OpenStack Development Mailing 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 Kamyshnikova
Mirantis, Inc
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [openstack-ansible] L3HA problem

[Anna Kamyshnikova]

Version 1.2.13 is reliable.

On Wed, Jun 22, 2016 at 8:40 PM, Assaf Muller  wrote:

> On Wed, Jun 22, 2016 at 12:02 PM, fabrice grelaud
>  wrote:
> >
> > Le 22 juin 2016 à 17:35, fabrice grelaud 
> a
> > écrit :
> >
> >
> > Le 22 juin 2016 à 15:45, Assaf Muller  a écrit :
> >
> > On Wed, Jun 22, 2016 at 9:24 AM, fabrice grelaud
> >  wrote:
> >
> > Hi,
> >
> > we deployed our openstack infrastructure with your « exciting » project
> > openstack-ansible (mitaka 13.1.2) but we have some problems with L3HA
> after
> > create router.
> >
> > Our infra (closer to the doc):
> > 3 controllers nodes (with bond0 (br-mgmt, br-storage), bond1 (br-vxlan,
> > br-vlan))
> > 2 compute nodes (same for network)
> >
> > We create an external network (vlan type), an internal network (vxlan
> type)
> > and a router connected to both networks.
> > And when we launch an instance (cirros), we can’t receive an ip on the
> vm.
> >
> > We have:
> >
> > root@p-osinfra03-utility-container-783041da:~# neutron
> > l3-agent-list-hosting-router router-bim
> >
> +--+---++---+--+
> > | id   | host
> > | admin_state_up | alive | ha_state |
> >
> +--+---++---+--+
> > | 3c7918e5-3ad6-4f82-a81b-700790e3c016 |
> > p-osinfra01-neutron-agents-container-f1ab9c14 | True   | :-)   |
> > active   |
> > | f2bf385a-f210-4dbc-8d7d-4b7b845c09b0 |
> > p-osinfra02-neutron-agents-container-48142ffe | True   | :-)   |
> > active   |
> > | 55350fac-16aa-488e-91fd-a7db38179c62 |
> > p-osinfra03-neutron-agents-container-2f6557f0 | True   | :-)   |
> > active   |
> >
> +--+---++---+—+
> >
> > I know, i got a problem now because i should have :-) active, :-)
> standby,
> > :-) standby… Snif...
> >
> > root@p-osinfra01-neutron-agents-container-f1ab9c14:~# ip netns
> > qrouter-eeb2147a-5cc6-4b5e-b97c-07cfc141e8e6
> > qdhcp-0ba266fb-15c4-4566-ae88-92d4c8fd2036
> >
> > root@p-osinfra01-neutron-agents-container-f1ab9c14:~# ip netns exec
> > qrouter-eeb2147a-5cc6-4b5e-b97c-07cfc141e8e6 ip a sh
> > 1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group
> > default
> >link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> >inet 127.0.0.1/8 scope host lo
> >   valid_lft forever preferred_lft forever
> >inet6 ::1/128 scope host
> >   valid_lft forever preferred_lft forever
> > 2: ha-4a5f0287-91@if6:  mtu 1450 qdisc
> > pfifo_fast state UP group default qlen 1000
> >link/ether fa:16:3e:c2:67:a9 brd ff:ff:ff:ff:ff:ff
> >inet 169.254.192.1/18 brd 169.254.255.255 scope global ha-4a5f0287-91
> >   valid_lft forever preferred_lft forever
> >inet 169.254.0.1/24 scope global ha-4a5f0287-91
> >   valid_lft forever preferred_lft forever
> >inet6 fe80::f816:3eff:fec2:67a9/64 scope link
> >   valid_lft forever preferred_lft forever
> > 3: qr-44804d69-88@if9:  mtu 1450 qdisc
> > pfifo_fast state UP group default qlen 1000
> >link/ether fa:16:3e:a5:8c:f2 brd ff:ff:ff:ff:ff:ff
> >inet 192.168.100.254/24 scope global qr-44804d69-88
> >   valid_lft forever preferred_lft forever
> >inet6 fe80::f816:3eff:fea5:8cf2/64 scope link
> >   valid_lft forever preferred_lft forever
> > 4: qg-c5c7378e-1d@if12:  mtu 1500 qdisc
> > pfifo_fast state UP group default qlen 1000
> >link/ether fa:16:3e:b6:4c:97 brd ff:ff:ff:ff:ff:ff
> >inet 147.210.240.11/23 scope global qg-c5c7378e-1d
> >   valid_lft forever preferred_lft forever
> >inet 147.210.240.12/32 scope global qg-c5c7378e-1d
> >   valid_lft forever preferred_lft forever
> >inet6 fe80::f816:3eff:feb6:4c97/64 scope link
> >   valid_lft forever preferred_lft forever
> >
> > Same result on infra02 and infra03, qr and qg interfaces have the same
> ip,
> > and ha interfaces the address 169.254.0.1.
> >
> > If we stop 2 neutron agent containers (p-osinfra02, p-osinfra03) and we
> > restart the first (p-osinfra01), we can reboot the instance and we got an
> > ip, a floating ip and we can access by ssh from internet to the vm.
> (Note:
> > after few time, we loss our connectivity too).
> >
> > But if we restart the two containers, we got a ha_state to « standby »
> until
> > the three become « active » and finally we have the problem again.
> >
> > The three routers on infra 01/02/03 are seen as master.
> >
> > If we ping from our instance to the router (internal network
> 192.168.100.4
> > to 192.168.100.254) we can see some ARP Request
> > ARP, 

Re: [openstack-dev] [openstack-ansible] L3HA problem

[Anna Kamyshnikova]

Keepalived 1.2.7 is bad version. Please, see comments in this bug
https://bugs.launchpad.net/neutron/+bug/1497272. I suggest you to try one
of the latest version of Keepalived.

On Wed, Jun 22, 2016 at 5:03 PM, fabrice grelaud <
fabrice.grel...@u-bordeaux.fr> wrote:

> Hi,
>
> keepalived 1:1.2.7-1ubuntu
>
>
> Le 22 juin 2016 à 15:41, Anna Kamyshnikova <akamyshnik...@mirantis.com> a
> écrit :
>
> Hi!
>
> What Keepalived version is used?
>
> On Wed, Jun 22, 2016 at 4:24 PM, fabrice grelaud <
> fabrice.grel...@u-bordeaux.fr> wrote:
>
>> Hi,
>>
>> we deployed our openstack infrastructure with your « exciting » project
>> openstack-ansible (mitaka 13.1.2) but we have some problems with L3HA after
>> create router.
>>
>> Our infra (closer to the doc):
>> 3 controllers nodes (with bond0 (br-mgmt, br-storage), bond1 (br-vxlan,
>> br-vlan))
>> 2 compute nodes (same for network)
>>
>> We create an external network (vlan type), an internal network (vxlan
>> type) and a router connected to both networks.
>> And when we launch an instance (cirros), we can’t receive an ip on the vm.
>>
>> We have:
>>
>> root@p-osinfra03-utility-container-783041da:~# neutron
>> l3-agent-list-hosting-router router-bim
>>
>> +--+---++---+--+
>> | id   | host
>>  | admin_state_up | alive | ha_state |
>>
>> +--+---++---+--+
>> | 3c7918e5-3ad6-4f82-a81b-700790e3c016 |
>> p-osinfra01-neutron-agents-container-f1ab9c14 | True   | :-)   |
>> active   |
>> | f2bf385a-f210-4dbc-8d7d-4b7b845c09b0 |
>> p-osinfra02-neutron-agents-container-48142ffe | True   | :-)   |
>> active   |
>> | 55350fac-16aa-488e-91fd-a7db38179c62 |
>> p-osinfra03-neutron-agents-container-2f6557f0 | True   | :-)   |
>> active   |
>>
>> +--+---++---+—+
>>
>> I know, i got a problem now because i should have :-) active, :-)
>> standby, :-) standby… Snif...
>>
>> root@p-osinfra01-neutron-agents-container-f1ab9c14:~# ip netns
>> qrouter-eeb2147a-5cc6-4b5e-b97c-07cfc141e8e6
>> qdhcp-0ba266fb-15c4-4566-ae88-92d4c8fd2036
>>
>> root@p-osinfra01-neutron-agents-container-f1ab9c14:~# ip netns exec
>> qrouter-eeb2147a-5cc6-4b5e-b97c-07cfc141e8e6 ip a sh
>> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group
>> default
>> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
>> inet 127.0.0.1/8 scope host lo
>>valid_lft forever preferred_lft forever
>> inet6 ::1/128 scope host
>>valid_lft forever preferred_lft forever
>> 2: ha-4a5f0287-91@if6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc
>> pfifo_fast state UP group default qlen 1000
>> link/ether fa:16:3e:c2:67:a9 brd ff:ff:ff:ff:ff:ff
>> inet 169.254.192.1/18 brd 169.254.255.255 scope global ha-4a5f0287-91
>>valid_lft forever preferred_lft forever
>> inet 169.254.0.1/24 scope global ha-4a5f0287-91
>>valid_lft forever preferred_lft forever
>> inet6 fe80::f816:3eff:fec2:67a9/64 scope link
>>valid_lft forever preferred_lft forever
>> 3: qr-44804d69-88@if9: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc
>> pfifo_fast state UP group default qlen 1000
>> link/ether fa:16:3e:a5:8c:f2 brd ff:ff:ff:ff:ff:ff
>> inet 192.168.100.254/24 scope global qr-44804d69-88
>>valid_lft forever preferred_lft forever
>> inet6 fe80::f816:3eff:fea5:8cf2/64 scope link
>>valid_lft forever preferred_lft forever
>> 4: qg-c5c7378e-1d@if12: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc
>> pfifo_fast state UP group default qlen 1000
>> link/ether fa:16:3e:b6:4c:97 brd ff:ff:ff:ff:ff:ff
>> inet 147.210.240.11/23 scope global qg-c5c7378e-1d
>>valid_lft forever preferred_lft forever
>> inet 147.210.240.12/32 scope global qg-c5c7378e-1d
>>valid_lft forever preferred_lft forever
>> inet6 fe80::f816:3eff:feb6:4c97/64 scope link
>>valid_lft forever preferred_lft forever
>>
>> Same result on infra02 and infra03, qr and qg interfaces have the same
>> ip, and ha interfaces the address 169.254.0.1.
>>
>> If we stop 2 neutron agent containers (p-osinfra02, p-osin

Re: [openstack-dev] [openstack-ansible] L3HA problem

[Anna Kamyshnikova]

Hi!

What Keepalived version is used?

On Wed, Jun 22, 2016 at 4:24 PM, fabrice grelaud <
fabrice.grel...@u-bordeaux.fr> wrote:

> Hi,
>
> we deployed our openstack infrastructure with your « exciting » project
> openstack-ansible (mitaka 13.1.2) but we have some problems with L3HA after
> create router.
>
> Our infra (closer to the doc):
> 3 controllers nodes (with bond0 (br-mgmt, br-storage), bond1 (br-vxlan,
> br-vlan))
> 2 compute nodes (same for network)
>
> We create an external network (vlan type), an internal network (vxlan
> type) and a router connected to both networks.
> And when we launch an instance (cirros), we can’t receive an ip on the vm.
>
> We have:
>
> root@p-osinfra03-utility-container-783041da:~# neutron
> l3-agent-list-hosting-router router-bim
>
> +--+---++---+--+
> | id   | host
>  | admin_state_up | alive | ha_state |
>
> +--+---++---+--+
> | 3c7918e5-3ad6-4f82-a81b-700790e3c016 |
> p-osinfra01-neutron-agents-container-f1ab9c14 | True   | :-)   |
> active   |
> | f2bf385a-f210-4dbc-8d7d-4b7b845c09b0 |
> p-osinfra02-neutron-agents-container-48142ffe | True   | :-)   |
> active   |
> | 55350fac-16aa-488e-91fd-a7db38179c62 |
> p-osinfra03-neutron-agents-container-2f6557f0 | True   | :-)   |
> active   |
>
> +--+---++---+—+
>
> I know, i got a problem now because i should have :-) active, :-) standby,
> :-) standby… Snif...
>
> root@p-osinfra01-neutron-agents-container-f1ab9c14:~# ip netns
> qrouter-eeb2147a-5cc6-4b5e-b97c-07cfc141e8e6
> qdhcp-0ba266fb-15c4-4566-ae88-92d4c8fd2036
>
> root@p-osinfra01-neutron-agents-container-f1ab9c14:~# ip netns exec
> qrouter-eeb2147a-5cc6-4b5e-b97c-07cfc141e8e6 ip a sh
> 1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group
> default
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> inet 127.0.0.1/8 scope host lo
>valid_lft forever preferred_lft forever
> inet6 ::1/128 scope host
>valid_lft forever preferred_lft forever
> 2: ha-4a5f0287-91@if6:  mtu 1450 qdisc
> pfifo_fast state UP group default qlen 1000
> link/ether fa:16:3e:c2:67:a9 brd ff:ff:ff:ff:ff:ff
> inet 169.254.192.1/18 brd 169.254.255.255 scope global ha-4a5f0287-91
>valid_lft forever preferred_lft forever
> inet 169.254.0.1/24 scope global ha-4a5f0287-91
>valid_lft forever preferred_lft forever
> inet6 fe80::f816:3eff:fec2:67a9/64 scope link
>valid_lft forever preferred_lft forever
> 3: qr-44804d69-88@if9:  mtu 1450 qdisc
> pfifo_fast state UP group default qlen 1000
> link/ether fa:16:3e:a5:8c:f2 brd ff:ff:ff:ff:ff:ff
> inet 192.168.100.254/24 scope global qr-44804d69-88
>valid_lft forever preferred_lft forever
> inet6 fe80::f816:3eff:fea5:8cf2/64 scope link
>valid_lft forever preferred_lft forever
> 4: qg-c5c7378e-1d@if12:  mtu 1500 qdisc
> pfifo_fast state UP group default qlen 1000
> link/ether fa:16:3e:b6:4c:97 brd ff:ff:ff:ff:ff:ff
> inet 147.210.240.11/23 scope global qg-c5c7378e-1d
>valid_lft forever preferred_lft forever
> inet 147.210.240.12/32 scope global qg-c5c7378e-1d
>valid_lft forever preferred_lft forever
> inet6 fe80::f816:3eff:feb6:4c97/64 scope link
>valid_lft forever preferred_lft forever
>
> Same result on infra02 and infra03, qr and qg interfaces have the same ip,
> and ha interfaces the address 169.254.0.1.
>
> If we stop 2 neutron agent containers (p-osinfra02, p-osinfra03) and we
> restart the first (p-osinfra01), we can reboot the instance and we got an
> ip, a floating ip and we can access by ssh from internet to the vm. (Note:
> after few time, we loss our connectivity too).
>
> But if we restart the two containers, we got a ha_state to « standby »
> until the three become « active » and finally we have the problem again.
>
> The three routers on infra 01/02/03 are seen as master.
>
> If we ping from our instance to the router (internal network 192.168.100.4
> to 192.168.100.254) we can see some ARP Request
> ARP, Request who-has 192.168.100.254 tell 192.168.100.4, length 28
> ARP, Request who-has 192.168.100.254 tell 192.168.100.4, length 28
> ARP, Request who-has 192.168.100.254 tell 192.168.100.4, length 28
>
> And on the compute node we see all these frames on the various interfaces
> tap / vxlan-89 / br-vxlan / bond1.vxlanvlan / bond1 / em2 but nothing back.
>
> We also have on ha interface, on each router, the VRRP communication
> (heartbeat packets over a hidden project network that connects all ha
> routers 

Re: [openstack-dev] [Openstack-dev] scaling nova kvm and neutron l3-ha and ml2+openvswitch

[Anna Kamyshnikova]

Hi!

Recently I performed scale testing of Neutron L3 HA Liberty. Test plan and
test results can be found
http://docs.openstack.org/developer/performance-docs/index.html.

On Tue, May 24, 2016 at 3:21 PM, Tobias Urdin 
wrote:

> Hello,
>
> (I didn't have any luck with this question on the openstack-operators
> list so I'm throwing it out here to see if I can catch anyone, according
> to Assaf he knew a couple of you devs running a similar environment, if
> not feel free to do what you please with this email hehe)
>
> I'm gonna give it a try here and see if anybody has a similar setup that
> could answer some questions about scaling.
> We are running Liberty with Nova with KVM and Neutron L3 HA and
> ML2+Openvswitch.
>
> * How many nova instances do you have?
> * How many nova compute nodes do you have?
> * How many neutron nodes do you have? (Network nodes that is hosting l3
> agents, dhcp agents, openvswitch-plugin etc)
> * What is your overall thought on the management ability on Openvswitch?
> * What issue have you had related to scaling, performance etc?
>
> Thankful for any data, I'm trying to give my employer real world usage
> information on a similar setup.
> Feel free to answer me privately if you prefer but I'm sure more people
> here are curious if you want to share :)
>
> Best regards
> Tobias
>
>
> __
> OpenStack Development Mailing 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 Kamyshnikova
Mirantis, Inc
__
OpenStack Development Mailing 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] Getting rid of lazy init for engine facade

[Anna Kamyshnikova]

Roman, thanks a lot for guidelines! I've updated the change and removed
configure_db parameter.

On Wed, May 11, 2016 at 4:58 PM, Roman Podoliaka <rpodoly...@mirantis.com>
wrote:

> Hi Anna,
>
> Thank you for working on this in Neutron!
>
> EngineFacade is initialized lazily internally - you don't have to do
> anything for that in Neutron (you *had to* with "old" EngineFacade -
> this is the boiler plate your patch removes).
>
> I believe, you should be able to call configure(...) unconditionally
> as soon as you have parsed the config files. Why do you want to
> introduce a new conditional?
>
> Moreover, if you only have connections to one database (unlike Nova,
> which also has Cells databases), you don't need to call configure() at
> all - EngineFacade will read the values of config options registered
> by oslo.db on the first attempt to get a session / connection.
>
> Thanks,
> Roman
>
> On Wed, May 11, 2016 at 4:41 PM, Anna Kamyshnikova
> <akamyshnik...@mirantis.com> wrote:
> > Hi guys!
> >
> > I'm working on adoption of new engine facade from oslo.db for Neutron
> [1].
> > This work requires us to get rid of lazy init for engine facade. [2] I
> > propose change [3] that adds configure_db parameter which is False by
> > default, so if work with db will be required configure_db=True should be
> > passed manually.
> >
> > NOTE: this will affect all external repos depending on Neutron!
> >
> > I'm considering making this argument mandatory to force every project
> > depending on this function explicitly make a decision there.
> >
> > I want to encourage reviewers to take a look at this change and l'm
> looking
> > forward all suggestions.
> >
> > [1] - https://bugs.launchpad.net/neutron/+bug/1520719
> > [2] -
> >
> http://specs.openstack.org/openstack/oslo-specs/specs/kilo/make-enginefacade-a-facade.html
> > [3] - https://review.openstack.org/#/c/312393/
> >
> > --
> > Regards,
> > Ann Kamyshnikova
> > Mirantis, Inc
> >
> >
> __
> > OpenStack Development Mailing List (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 Kamyshnikova
Mirantis, Inc
__
OpenStack Development Mailing List (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] Getting rid of lazy init for engine facade

[Anna Kamyshnikova]

Hi guys!

I'm working on adoption of new engine facade from oslo.db for Neutron [1].
This work requires us to get rid of lazy init for engine facade. [2] I
propose change [3] that adds configure_db parameter which is False by
default, so if work with db will be required configure_db=True should be
passed manually.

*NOTE: *this will affect all external repos depending on Neutron!

I'm considering making this argument mandatory to force every project
depending on this function explicitly make a decision there.

I want to encourage reviewers to take a look at this change and l'm looking
forward all suggestions.

[1] - https://bugs.launchpad.net/neutron/+bug/1520719
[2] -
http://specs.openstack.org/openstack/oslo-specs/specs/kilo/make-enginefacade-a-facade.html
[3] - https://review.openstack.org/#/c/312393/

-- 
Regards,
Ann Kamyshnikova
Mirantis, Inc
__
OpenStack Development Mailing 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] L3 HA testing on scale

[Anna Kamyshnikova]

Unfortunately, I won't attend summit in Austin, that is why I decided to
present these results in the mailing list instead.

On Tue, Apr 19, 2016 at 7:29 PM, Edgar Magana <edgar.mag...@workday.com>
wrote:

> Is there any session presenting these results during the Summit? It will
> be awesome to have a session on this. I could extend the invite to the Ops
> Meet-up. We have a section on lighting talks where the team will be very
> intesreted in learning from your testing.
>
> Edgar
>
> From: Anna Kamyshnikova <akamyshnik...@mirantis.com>
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Date: Tuesday, April 19, 2016 at 5:30 AM
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Subject: Re: [openstack-dev] [Neutron] L3 HA testing on scale
>
> >I would definitely like to see how these results are effected by
> >https://review.openstack.org/#/c/305774/ but understandably 49
> >physical nodes are hard to come by.
>
> Yes, I'm planning to check how situation will change with all recent
> fixes, but I will be able to do this in May or later.
>
> >About testing on scale it’s not so problematic because of the Cloud For
> All project.
> >Here [1] you can request for a multi node cluster which you can use to
> >perform tests. Exact requirements are specified on that website.
>
> [1] http://osic.org
>
> Thanks for pointing this!
>
> >It's a great report, thanks for sharing that! Do you plan to run similar
> >scale tests on other scenarios e.g. dvr?
>
> Thanks! I have testing L3 HA + DVR in plans.
>
> P. S.
>
> I've updated environment description in report with some details.
>
> On Tue, Apr 19, 2016 at 12:52 PM, Rossella Sblendido <rsblend...@suse.com>
> wrote:
>
>>
>>
>> On 04/18/2016 04:15 PM, Anna Kamyshnikova wrote:
>> > Hi guys!
>> >
>> > As a developer I use Devstack or multinode OpenStack installation (4-5
>> > nodes) for work, but these are "abstract" environments, where you are
>> > not able to perform some scenarios as your machine is not powerful
>> > enough. But it is really important to understand the issues that real
>> > deployments have.
>> >
>> > Recently I've performed testing of L3 HA on the scale environment 49
>> > nodes (3 controllers, 46 computes) Fuel 8.0. On this environment I ran
>> > shaker and rally tests and also performed some
>> > manual destructive scenarios. I think that this is very important to
>> > share these results. Ideally, I think that we should collect statistics
>> > for different configurations each release to compare and check it to
>> > make sure that we are heading the right way.
>> >
>> > The results of shaker and rally tests [1]. I put detailed report in
>> > google doc [2]. I would appreciate all comments on these results.
>>
>> It's a great report, thanks for sharing that! Do you plan to run similar
>> scale tests on other scenarios e.g. dvr?
>>
>> Rossella
>>
>> >
>> > [1] - http://akamyshnikova.github.io/neutron-benchmark-results/
>> > [2]
>> > -
>> https://docs.google.com/a/mirantis.com/document/d/1TFEUzRRlRIt2HpsOzFh-RqWwgTzJPBefePPA0f0x9uw/edit?usp=sharing
>> >
>> > Regards,
>> > Ann Kamyshnikova
>> > Mirantis, Inc
>> >
>> >
>> >
>> __
>> > OpenStack Development Mailing List (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 Kamyshnikova
> Mirantis, Inc
>
> __
> OpenStack Development Mailing 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 Kamyshnikova
Mirantis, Inc
__
OpenStack Development Mailing 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] L3 HA testing on scale

[Anna Kamyshnikova]

>I would definitely like to see how these results are effected by
>https://review.openstack.org/#/c/305774/ but understandably 49
>physical nodes are hard to come by.

Yes, I'm planning to check how situation will change with all recent fixes,
but I will be able to do this in May or later.

>About testing on scale it’s not so problematic because of the Cloud For
All project.
>Here [1] you can request for a multi node cluster which you can use to
>perform tests. Exact requirements are specified on that website.

[1] http://osic.org

Thanks for pointing this!

>It's a great report, thanks for sharing that! Do you plan to run similar
>scale tests on other scenarios e.g. dvr?

Thanks! I have testing L3 HA + DVR in plans.

P. S.

I've updated environment description in report with some details.

On Tue, Apr 19, 2016 at 12:52 PM, Rossella Sblendido <rsblend...@suse.com>
wrote:

>
>
> On 04/18/2016 04:15 PM, Anna Kamyshnikova wrote:
> > Hi guys!
> >
> > As a developer I use Devstack or multinode OpenStack installation (4-5
> > nodes) for work, but these are "abstract" environments, where you are
> > not able to perform some scenarios as your machine is not powerful
> > enough. But it is really important to understand the issues that real
> > deployments have.
> >
> > Recently I've performed testing of L3 HA on the scale environment 49
> > nodes (3 controllers, 46 computes) Fuel 8.0. On this environment I ran
> > shaker and rally tests and also performed some
> > manual destructive scenarios. I think that this is very important to
> > share these results. Ideally, I think that we should collect statistics
> > for different configurations each release to compare and check it to
> > make sure that we are heading the right way.
> >
> > The results of shaker and rally tests [1]. I put detailed report in
> > google doc [2]. I would appreciate all comments on these results.
>
> It's a great report, thanks for sharing that! Do you plan to run similar
> scale tests on other scenarios e.g. dvr?
>
> Rossella
>
> >
> > [1] - http://akamyshnikova.github.io/neutron-benchmark-results/
> > [2]
> > -
> https://docs.google.com/a/mirantis.com/document/d/1TFEUzRRlRIt2HpsOzFh-RqWwgTzJPBefePPA0f0x9uw/edit?usp=sharing
> >
> > Regards,
> > Ann Kamyshnikova
> > Mirantis, Inc
> >
> >
> >
> __
> > OpenStack Development Mailing List (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 Kamyshnikova
Mirantis, Inc
__
OpenStack Development Mailing List (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] L3 HA testing on scale

[Anna Kamyshnikova]

Hi guys!

As a developer I use Devstack or multinode OpenStack installation (4-5
nodes) for work, but these are "abstract" environments, where you are not
able to perform some scenarios as your machine is not powerful enough. But
it is really important to understand the issues that real deployments have.

Recently I've performed testing of L3 HA on the scale environment 49 nodes
(3 controllers, 46 computes) Fuel 8.0. On this environment I ran shaker and
rally tests and also performed some manual destructive scenarios. I think
that this is very important to share these results. Ideally, I think that
we should collect statistics for different configurations each release to
compare and check it to make sure that we are heading the right way.

The results of shaker and rally tests [1]. I put detailed report in google
doc [2]. I would appreciate all comments on these results.

[1] - http://akamyshnikova.github.io/neutron-benchmark-results/
[2] -
https://docs.google.com/a/mirantis.com/document/d/1TFEUzRRlRIt2HpsOzFh-RqWwgTzJPBefePPA0f0x9uw/edit?usp=sharing

Regards,
Ann Kamyshnikova
Mirantis, Inc
__
OpenStack Development Mailing 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 Hirofumi Ichihara to Neutron Core Reviewer Team

[Anna Kamyshnikova]

+1

On Fri, Apr 8, 2016 at 12:49 PM, Miguel Angel Ajo Pelayo <
majop...@redhat.com> wrote:

>
>
> On Fri, Apr 8, 2016 at 11:28 AM, Ihar Hrachyshka 
> wrote:
>
>> Kevin Benton  wrote:
>>
>> I don't know if my vote counts in this area, but +1!
>>>
>>
>> What the gentleman said ^, +1.
>
>
> "me too ^" , +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
>>
>
>
> __
> OpenStack Development Mailing 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 Kamyshnikova
Mirantis, Inc
__
OpenStack Development Mailing 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][db]Why can't I see ports which belongs router's gateway?

[Anna Kamyshnikova]

Hi!

How do you try to get details about it? I don't have any problems with
that, see http://paste.openstack.org/show/486069/

On Fri, Feb 5, 2016 at 12:49 PM, Zhi Chang  wrote:

> hi, all.
> Neutron will create a port when setting router gateway to a router.
> This port's device_owner is "network:router_gateway". And, I can see this
> port in db.
>
> But, why cmd says "Unable to find port with name xxx" when I want to
> get the detail info about this port?
>
> Does there some special reasons?
>
> 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 Kamyshnikova
Mirantis, Inc
__
OpenStack Development Mailing 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][db]Why can't I see ports whichbelongs router's gateway?

[Anna Kamyshnikova]

This seems strange, do you use admin user to run the command?

On Fri, Feb 5, 2016 at 1:57 PM, Zhi Chang <chang...@unitedstack.com> wrote:

> Hi, thanks for your reply.
>
> In my db, data is right. But when I run cmd, data is empty. see:
> http://paste.openstack.org/show/486072/
>
> Thanks
> Zhi Chang
> -- Original --
> *From: * "Anna Kamyshnikova"<akamyshnik...@mirantis.com>;
> *Date: * Fri, Feb 5, 2016 06:29 PM
> *To: * "OpenStack Development Mailing List (not for usage questions)"<
> openstack-dev@lists.openstack.org>;
> *Subject: * Re: [openstack-dev] [neutron][db]Why can't I see ports
> whichbelongs router's gateway?
>
> Hi!
>
> How do you try to get details about it? I don't have any problems with
> that, see http://paste.openstack.org/show/486069/
>
> On Fri, Feb 5, 2016 at 12:49 PM, Zhi Chang <chang...@unitedstack.com>
> wrote:
>
>> hi, all.
>> Neutron will create a port when setting router gateway to a router.
>> This port's device_owner is "network:router_gateway". And, I can see this
>> port in db.
>>
>> But, why cmd says "Unable to find port with name xxx" when I want to
>> get the detail info about this port?
>>
>> Does there some special reasons?
>>
>> 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 Kamyshnikova
> Mirantis, Inc
>
> __
> OpenStack Development Mailing 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 Kamyshnikova
Mirantis, Inc
__
OpenStack Development Mailing 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] L3-HA - Solution for GW not pingable issue bug/1365461

[Anna Kamyshnikova]

Hi!

This is great that you look into this issue! I think that first solution
looks more solid, my concern here is how does this will affect the
performance?

On Thu, Jan 21, 2016 at 12:12 PM, Lubosz Kosnik 
wrote:

> He neutrinos,
>
> Currently I'm working on this bug [1]. Almost one year ago Yoni Shafrir
> prepared a patch to fix this issue but he got in review information that
> this solution must be changed because it's using only one script to check
> the GW availability and because of that it cannot be used in multi tenat
> environment.
> I tooked his code and was trying to upgrade that code to support multiple
> scripts but I was designed separate solution for that.
> I would like to know what do you think about this solution.
>
> 1. Add bash script generator to neutron/agent/linux/keepalived.py
> 2. There will be one script per one keepalived instance per node
> 3. There are two possible solutions for checking is everything is working
> OK. Script will verify:
> a. That all interfaces are up - internal router interfaces in
> namespace, external interface taken from neutron configuration file and
> also br-tun/br-int interfaces.
> b. That GW is pingable from router NS - there is only one problem what
> if GW is not configured in router already - plus we could ping other
> network node or other server which IP is specified in some configuration.
>
> That solution will also fix this issue [2].
> I would hear from you what do you think about that two possible solutions
> and what do you think about whole solution at all.
>
> Cheers,
> Lubosz (diltram) Kosnik
>
> [1] https://bugs.launchpad.net/neutron/+bug/1365461
> [2] https://bugs.launchpad.net/neutron/+bug/1375625
>
> __
> OpenStack Development Mailing 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 Kamyshnikova
Mirantis, Inc
__
OpenStack Development Mailing 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] InvalidRequestError: This session is in 'prepared' state; no further SQL can be emitted within this transaction.

[Anna Kamyshnikova]

Hi!

Can you point what mechanism driver is this or the piece of code that give
this error?

On Mon, Jan 11, 2016 at 11:58 AM, Koteswar  wrote:

> Hi All,
>
>
>
> In my mechanism driver, I am reading/writing into sql db in a fixed
> interval looping call. Sometimes I get the following error when I stop and
> start neutron server
>
> InvalidRequestError: This session is in 'prepared' state; no further SQL
> can be emitted within this transaction.
>
>
>
> I am using context.session.query() for add, delete, update and get. Please
> help me if any one resolved an issue like this.
>
>
>
> Full trace is as follows:
>
> 2016-01-06 15:33:21.799 [01;31mERROR neutron.plugins.ml2.managers
> [[01;36mreq-d940a1b6-253a-43d2-b5ff-6c784c8a520f [00;36madmin
> 83b5358da62a407f88155f447966356f[01;31m] [01;35m[01;31mMechanism driver
> 'hp' failed in create_port_precommit[00m
>
> [01;31m2016-01-06 15:33:21.799 TRACE neutron.plugins.ml2.managers
> [01;35m[00mTraceback (most recent call last):
>
> [01;31m2016-01-06 15:33:21.799 TRACE neutron.plugins.ml2.managers
> [01;35m[00m  File "/opt/stack/neutron/neutron/plugins/ml2/managers.py",
> line 394, in _call_on_drivers
>
> [01;31m2016-01-06 15:33:21.799 TRACE neutron.plugins.ml2.managers
> [01;35m[00mgetattr(driver.obj, method_name)(context)
>
> [01;31m2016-01-06 15:33:21.799 TRACE neutron.plugins.ml2.managers
> [01;35m[00m  File
> "/usr/local/lib/python2.7/dist-packages/baremetal_network_provisioning/ml2/mechanism_hp.py",
> line 67, in create_port_precommit
>
> [01;31m2016-01-06 15:33:21.799 TRACE neutron.plugins.ml2.managers
> [01;35m[00mraise e
>
> [01;31m2016-01-06 15:33:21.799 TRACE neutron.plugins.ml2.managers
> [01;35m[00mInvalidRequestError: This session is in 'prepared' state; no
> further SQL can be emitted within this transaction.
>
> [01;31m2016-01-06 15:33:21.799 TRACE neutron.plugins.ml2.managers
> [01;35m[00m
>
> 2016-01-06 15:33:21.901 [01;31mERROR neutron.api.v2.resource
> [[01;36mreq-d940a1b6-253a-43d2-b5ff-6c784c8a520f [00;36madmin
> 83b5358da62a407f88155f447966356f[01;31m] [01;35m[01;31mcreate failed[00m
>
> [01;31m2016-01-06 15:33:21.901 TRACE neutron.api.v2.resource
> [01;35m[00mTraceback (most recent call last):
>
> [01;31m2016-01-06 15:33:21.901 TRACE neutron.api.v2.resource [01;35m[00m
> File "/opt/stack/neutron/neutron/api/v2/resource.py", line 83, in resource
>
> [01;31m2016-01-06 15:33:21.901 TRACE neutron.api.v2.resource
> [01;35m[00mresult = method(request=request, **args)
>
> [01;31m2016-01-06 15:33:21.901 TRACE neutron.api.v2.resource [01;35m[00m
> File "/usr/local/lib/python2.7/dist-packages/oslo_db/api.py", line 146, in
> wrapper
>
> [01;31m2016-01-06 15:33:21.901 TRACE neutron.api.v2.resource
> [01;35m[00mectxt.value = e.inner_exc
>
> [01;31m2016-01-06 15:33:21.901 TRACE neutron.api.v2.resource [01;35m[00m
> File "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line
> 195, in __exit__
>
> [01;31m2016-01-06 15:33:21.901 TRACE neutron.api.v2.resource
> [01;35m[00msix.reraise(self.type_, self.value, self.tb)
>
> [01;31m2016-01-06 15:33:21.901 TRACE neutron.api.v2.resource [01;35m[00m
> File "/usr/local/lib/python2.7/dist-packages/oslo_db/api.py", line 136, in
> wrapper
>
> [01;31m2016-01-06 15:33:21.901 TRACE neutron.api.v2.resource
> [01;35m[00mreturn f(*args, **kwargs)
>
> [01;31m2016-01-06 15:33:21.901 TRACE neutron.api.v2.resource [01;35m[00m
> File "/opt/stack/neutron/neutron/api/v2/base.py", line 516, in create
>
> [01;31m2016-01-06 15:33:21.901 TRACE neutron.api.v2.resource
> [01;35m[00mobj = do_create(body)
>
> [01;31m2016-01-06 15:33:21.901 TRACE neutron.api.v2.resource [01;35m[00m
> File "/opt/stack/neutron/neutron/api/v2/base.py", line 498, in do_create
>
> [01;31m2016-01-06 15:33:21.901 TRACE neutron.api.v2.resource
> [01;35m[00mrequest.context, reservation.reservation_id)
>
> [01;31m2016-01-06 15:33:21.901 TRACE neutron.api.v2.resource [01;35m[00m
> File "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line
> 195, in __exit__
>
> [01;31m2016-01-06 15:33:21.901 TRACE neutron.api.v2.resource
> [01;35m[00msix.reraise(self.type_, self.value, self.tb)
>
> [01;31m2016-01-06 15:33:21.901 TRACE neutron.api.v2.resource [01;35m[00m
> File "/opt/stack/neutron/neutron/api/v2/base.py", line 491, in do_create
>
> [01;31m2016-01-06 15:33:21.901 TRACE neutron.api.v2.resource
> [01;35m[00mreturn obj_creator(request.context, **kwargs)
>
> [01;31m2016-01-06 15:33:21.901 TRACE neutron.api.v2.resource [01;35m[00m
> File "/usr/local/lib/python2.7/dist-packages/oslo_db/api.py", line 146, in
> wrapper
>
> [01;31m2016-01-06 15:33:21.901 TRACE neutron.api.v2.resource
> [01;35m[00mectxt.value = e.inner_exc
>
> [01;31m2016-01-06 15:33:21.901 TRACE neutron.api.v2.resource [01;35m[00m
> File "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line
> 195, in __exit__
>
> [01;31m2016-01-06 15:33:21.901 TRACE neutron.api.v2.resource
> [01;35m[00m

Re: [openstack-dev] [neutron][taas] neutron ovs-agent deletes taas flows

[Anna Kamyshnikova]

Sorry, that I don't see this earlier. Yes, cookies have integer values, so
we won't be able to set string there. May be we can have a reserved integer
cookie value for a project like all "1".

I won't support idea of modifying cleanup logic not to drop 0x0 cookies.
During implementation of graceful restart it was not dropped at first, but
I get rid of it  as having a lot of flows not related to anything was not
desirable, so we should try to avoid it here, too.

On Wed, Dec 16, 2015 at 7:46 AM, Soichi Shigeta <
shigeta.soi...@jp.fujitsu.com> wrote:

>
>o) An idea to fix:
>>
>>   1. Set "taas" stamp(*) to taas flows.
>>   2. Modify the cleanup logic in ovs-agent not to delete entries
>>  stamped as "taas".
>>
>>   * Maybe a static string.
>> If we need to use a string which generated dynamically
>> (e.g. uuid), API to interact with ovs-agent is required.
>>
>>
>   Last week I proposed to set a static string (e.g. "taas") as cookie
>   of flows created by taas agent.
>
>   But I found that the value of a cookie should not be a string,
>   but an integer.
>
>   At line 187 in
> "neutron/neutron/plugins/ml2/drivers/openvswitch/agent/ovs_neutron_agent.py":
>   self.agent_uuid_stamp = uuid.uuid4().int & UINT64_BITMASK
>
>   In case of we set an integer value to cookie, coordination
>   (reservation of range) is required to avoid conflict of cookies with
>   other neutron sub-projects.
>
>   As an alternative (*** short term ***) solution, my idea is:
>   Modify the clean up logic in ovs agent not to delete flows whose
>   "cookie = 0x0".
>   Because old flows created by ovs agent have an old stamp, "cookie =
>   0x0" means it was created by other than ovs agent.
>
>   # But, this idea has a disadvantage:
> If there are flows which have been created by older version of ovs
> agent, they can not be cleaned.
>
>
> ---
>  Soichi Shigeta
>
>
>
>
> __
> OpenStack Development Mailing 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 Kamyshnikova
Mirantis, Inc
__
OpenStack Development Mailing 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][upgrade] new 'all things upgrade' subteam

[Anna Kamyshnikova]

All options sound good, but 15 UTC on Monday and Friday have
some overlapping with my local meetings, but I'll try to handle this
somehow if it suits for others.

On Fri, Nov 13, 2015 at 7:29 AM, Sean M. Collins  wrote:

> Monday sounds good to me. 1500 utc sounds good too.
> --
> Sean M. Collins
>
> __
> OpenStack Development Mailing 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 Kamyshnikova
Mirantis, Inc
__
OpenStack Development Mailing 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][upgrade] new 'all things upgrade' subteam

[Anna Kamyshnikova]

Great news! Thanks Ihar!

I'm interested in working on this :) My TZ is UTC+3:00.

On Wed, Nov 11, 2015 at 12:14 AM, Martin Hickey 
wrote:

> I am interested too and will be available to the subteam.
>
> On Tue, Nov 10, 2015 at 9:03 PM, Sean M. Collins 
> wrote:
>
>> I'm excited. I plan on attending and being part of the subteam. I think
>> the tags that Dan Smith recently introduced could be our deliverables,
>> where this subteam focuses on working towards Neutron being tagged with
>> these tags.
>>
>> https://review.openstack.org/239771 - Introduce assert:supports-upgrade
>> tag
>>
>> https://review.openstack.org/239778 - Introduce
>> assert:supports-rolling-upgrade tag
>> --
>> Sean M. Collins
>>
>> __
>> OpenStack Development Mailing List (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 Kamyshnikova
Mirantis, Inc
__
OpenStack Development Mailing 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][db][migration] Neutron db migration by python scripts

[Anna Kamyshnikova]

You can create new migration using "neutron-db-manage revision -m 'desc'
--expand/--contract" depends in what changes do you want to do in migration
expand - add something, contract - delete or modify.
 More information -
http://docs.openstack.org/developer/neutron/devref/alembic_migrations.html

On Tue, Nov 3, 2015 at 1:52 PM, Zhi Chang  wrote:

> Hi, all
> Now, I should make some database model definitions if I want to
> upgrade db. And a database migration script will generated when I run 
> "neutron-db-manage
> revision -m "description of revision" --autogenerate". The database will
> upgraded when run "neutron-db-manage upgrade head".
> I want to upgrade db and I plan to write db migration scripts manually
> instead of change database model definitions. Is there some ways to realize
> it?
> Does anyone have some good ideas?
>
> 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 Kamyshnikova
Mirantis, Inc
__
OpenStack Development Mailing 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][db][migration] Neutron db migrationby python scripts

[Anna Kamyshnikova]

Do you have the lasted code of Neutron? Change [1] that allows this was
merged on the 22d of October.

[1] -
https://github.com/openstack/neutron/commit/9d069c48aed3a087c5c51366c8e70b29f339e794

On Tue, Nov 3, 2015 at 2:10 PM, Zhi Chang <chang...@unitedstack.com> wrote:

> Thanks for your reply.
>  There is an error when I run migration cmd:
>
> stack@devstack:~/neutron/neutron/db/migration$ neutron-db-manage revision
> -m 'desc' --contract
> usage: neutron-db-manage [-h] [--config-dir DIR] [--config-file PATH]
>  [--core_plugin CORE_PLUGIN] [--nosplit_branches]
>  [--service SERVICE] [--split_branches]
>  [--subproject SUBPROJECT] [--version]
>  [--database-connection DATABASE_CONNECTION]
>  [--database-engine DATABASE_ENGINE]
>
>  {current,history,branches,check_migration,upgrade,downgrade,stamp,revision}
>  ...
> neutron-db-manage: error: unrecognized arguments: --contract
>
>
> ------ Original --
> *From: * "Anna Kamyshnikova"<akamyshnik...@mirantis.com>;
> *Date: * Tue, Nov 3, 2015 07:03 PM
> *To: * "OpenStack Development Mailing List (not for usage questions)"<
> openstack-dev@lists.openstack.org>;
> *Subject: * Re: [openstack-dev] [Neutron][db][migration] Neutron db
> migrationby python scripts
>
> You can create new migration using "neutron-db-manage revision -m 'desc'
> --expand/--contract" depends in what changes do you want to do in migration
> expand - add something, contract - delete or modify.
>  More information -
> http://docs.openstack.org/developer/neutron/devref/alembic_migrations.html
>
> On Tue, Nov 3, 2015 at 1:52 PM, Zhi Chang <chang...@unitedstack.com>
> wrote:
>
>> Hi, all
>> Now, I should make some database model definitions if I want to
>> upgrade db. And a database migration script will generated when I run 
>> "neutron-db-manage
>> revision -m "description of revision" --autogenerate". The database will
>> upgraded when run "neutron-db-manage upgrade head".
>> I want to upgrade db and I plan to write db migration scripts
>> manually instead of change database model definitions. Is there some ways
>> to realize it?
>> Does anyone have some good ideas?
>>
>> 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 Kamyshnikova
> Mirantis, Inc
>
> __
> OpenStack Development Mailing 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 Kamyshnikova
Mirantis, Inc
__
OpenStack Development Mailing 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] Returning of HEAD files?

[Anna Kamyshnikova]

Ihar, Mark thank you for your comments!

Change [1] is ready, so we can land it in Neutron. For subprojects it will
be up to them to have HEAD files or not - tests won't fail, just warning
message will be shown.

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

On Fri, Oct 9, 2015 at 8:16 PM, Mark McClain  wrote:

>
> There are pros and cons for both approaches, but overall, I don’t see how
> the former justify having HEAD files and the complexity to handle them in
> code and in file system.
>
>
> The HEAD file is a clear winner when gate load is high and there are
> competing migrations.  As you pointed out PEP8 will detect the problem, but
> not fast enough to cause a ripple in the changes behind it in the gate.
> The ripple causes resources to be wasted adding to the load, so the git
> merge conflict was the best compromise we developed.
>
> mark
>
> __
> OpenStack Development Mailing 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 Kamyshnikova
Mirantis, Inc
__
OpenStack Development Mailing 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] HenryG addition to the Neutron Drivers team

[Anna Kamyshnikova]

Congratulations Henry!

On Wed, Oct 21, 2015 at 8:49 AM, Kevin Benton  wrote:

> Excellent addition! Remember everyone, if the feature you want doesn't
> make it into Neutron, it's now Henry's fault. :)
>
> On Tue, Oct 20, 2015 at 8:14 PM, Armando M.  wrote:
>
>> Hi folks,
>>
>> Henry has been instrumental in many areas of the projects and his crazy
>> working hours makes even Kevin and I bow in awe.
>>
>> Jokes aside, I would like to announce HenryG as a new member of the
>> Neutron Drivers team.
>>
>> Having a propension to attendance, and desire to review of RFEs puts you
>> on the right foot to join the group, whose members are rotated regularly so
>> that everyone is given the opportunity to grow, and no-one burns out.
>>
>> The team [1] meets regularly on Tuesdays [2], and anyone is welcome to
>> attend.
>>
>> Please, join me in welcome Henry to the team.
>>
>> Cheers,
>> Armando
>>
>> [1]
>> http://docs.openstack.org/developer/neutron/policies/neutron-teams.html#drivers-team
>> [2] https://wiki.openstack.org/wiki/Meetings/NeutronDrivers
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> 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
>
>


-- 
Regards,
Ann Kamyshnikova
Mirantis, Inc
__
OpenStack Development Mailing 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 rolling upgrade - are we there yet?

[Anna Kamyshnikova]

Thanks a lot for bringing up this theme! I'm interested in working on online
data migration in Mitaka.

3.  Database migration

a.  Online schema migration was done in Liberty release, any work left
to do?

The work here is finished. The only thing is that I'm aware of is some
extra tests https://review.openstack.org/#/c/220091/. But this needs some
Alembic changes. All main functionality is implemented.

b.  TODO: Online data migration to be introduced in Mitaka cycle.

i. Online data
migration can be done during normal operation on the data.

   ii. There should be
also the script to invoke the data migration in the background.

c.  Currently the contract phase is doing the data migration. But since
the contract phase should be run offline, we should move the data migration
to preceding step. Also the contract phase should be blocked if there is
still relevant data in removed entities.

i. Contract phase
can be executed online, if there is all new code running in setup.

d.  The other strategy is to not drop tables, alter names or remove the
columns from the DB – what’s in, it’s in. We should put more attention on
code reviews, merge only additive changes and avoid questionable DB
modification.

Unfortunately sometimes we may need such changes, despite we always tried
to avoid it. As plugins were moved out of Neutron it can be easier now, but
I'm still not sure we can have restriction.

e.  The Neutron server should be updated first, in order to do data
translation between old format into new schema. When doing this, we can be
sure that old data would not be inserted into old DB structures.

On Wed, Oct 14, 2015 at 9:27 PM, Dan Smith  wrote:

> > I would like to gather all upgrade activities in Neutron in one place,
> > in order to summarizes the current status and future activities on
> > rolling upgrades in Mitaka.
>
> Glad to see this work really picking up steam in other projects!
>
> > b.  TODO: To have the rolling upgrade we have to implement the RPC
> > version pinning in conf.
> >
> > i. I’m not a big
> > fan of this solution, but we can work out better idea if needed.
>
> I'll just point to this:
>
>   https://review.openstack.org/#/c/233289/
>
> and if you go check the logs for the partial-ncpu job, you'll see
> something like this:
>
>   nova.compute.rpcapi  Automatically selected compute RPC version 4.5
> from minimum service version 2
>
> I think that some amount of RPC pinning is probably going to be required
> for most people in most places, given our current model. But I assume
> the concern is around requiring this to be a manual task the operators
> have to manage. The above patch is the first step towards nova removing
> this as something the operators have to know anything about.
>
> --Dan
>
> __
> OpenStack Development Mailing 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 Kamyshnikova
Mirantis, Inc
__
OpenStack Development Mailing 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][db]Neutron db revision fails

[Anna Kamyshnikova]

Have you made changes in db models? There result should be:

akamyshnikova@akamyshnikova:/opt/stack/neutron$
.tox/py27/bin/neutron-db-manage --config-file /etc/neutron/neutron.conf
--config-file /etc/neutron/plugins/ml2/ml2_conf.ini revision -m 'test'
--autogenerate
  Running revision for neutron ...
No handlers could be found for logger "neutron.quota"
INFO  [alembic.runtime.migration] Context impl MySQLImpl.
INFO  [alembic.runtime.migration] Will assume non-transactional DDL.
INFO  [alembic.autogenerate.compare] Detected added column 'flavors.test'
  Generating
/opt/stack/neutron/neutron/db/migration/alembic_migrations/versions/mitaka/expand/7a277e40970_test.py
... done
  OK

If this does not help make sure that all migrations applied, try to
recreate database: drop it, run upgrade head and  revision -m 'test'
--autogenerate one more time.

On Mon, Oct 12, 2015 at 10:32 AM, Zhi Chang <chang...@unitedstack.com>
wrote:

> Ok. Everything looks right when I run command "neutron-db-manage
> --config-file /etc/neutron/neutron.conf --config-file
> /etc/neutron/plugins/ml2/ml2_conf.ini revision -m "Just For Test"
> --autogenerate"
>
> Output:
>   Running revision for neutron ...
> No handlers could be found for logger "neutron.quota"
> INFO  [alembic.runtime.migration] Context impl MySQLImpl.
> INFO  [alembic.runtime.migration] Will assume non-transactional DDL.
>   OK
>
> Where is the new migration script?
>
> Thx
> Zhi Chang
>
>
> -- Original --
> *From: * "Anna Kamyshnikova"<akamyshnik...@mirantis.com>;
> *Date: * Mon, Oct 12, 2015 03:19 PM
> *To: * "OpenStack Development Mailing List (not for usage questions)"<
> openstack-dev@lists.openstack.org>;
> *Subject: * Re: [openstack-dev] [Neutron][db]Neutron db revision fails
>
> You should use neutron-db-manage --config-file /etc/neutron/neutron.conf
> --config-file /etc/neutron/plugins/ml2/ml2_conf.ini revision -m "Just For
> Test"" --autogenerate. Make changes in db models and then run this command
> - migration will be generated automatically.
>
> On Mon, Oct 12, 2015 at 7:02 AM, Zhi Chang <chang...@unitedstack.com>
> wrote:
>
>> Thanks for your reply. What should I do if I want to create a new
>> migration script?
>>
>> Thanks
>> Zhi Chang
>>
>>
>> -- Original --
>> *From: * "Vikram Choudhary"<viks...@gmail.com>;
>> *Date: * Mon, Oct 12, 2015 12:22 PM
>> *To: * "OpenStack Development Mailing List (not for usage questions)"<
>> openstack-dev@lists.openstack.org>;
>> *Subject: * Re: [openstack-dev] [Neutron][db]Neutron db revision fails
>>
>>
>> Hi Zhi,
>>
>> We already have a defect logged for this issue.
>>
>> https://bugs.launchpad.net/neutron/+bug/1503342
>>
>> Thanks
>> Vikram
>> On Oct 12, 2015 8:10 AM, "Zhi Chang" <chang...@unitedstack.com> wrote:
>>
>>> Hi, everyone.
>>> I install a devstack from the latest code. But there is an error
>>> when I create a db migration script. My migration shell is:
>>> "neutron-db-manage --config-file /etc/neutron/neutron.conf
>>> --config-file /etc/neutron/plugins/ml2/ml2_conf.ini revision -m "Just For
>>> Test""
>>> The error shows:
>>>   Running revision for neutron ...
>>>   FAILED: Multiple heads are present; please specify the head
>>> revision on which the new revision should be based, or perform a merge.
>>>
>>> Does my method wrong? Could someone helps me?
>>>
>>> Thx
>>> 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
>>>
>>>
>> __
>> OpenStack Development Mailing 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 Kamyshnikova
> Mirantis, Inc
>
> __
> OpenStack Development Mailing 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 Kamyshnikova
Mirantis, Inc
__
OpenStack Development Mailing 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][db]Neutron db revision fails

[Anna Kamyshnikova]

You should use neutron-db-manage --config-file /etc/neutron/neutron.conf
--config-file /etc/neutron/plugins/ml2/ml2_conf.ini revision -m "Just For
Test"" --autogenerate. Make changes in db models and then run this command
- migration will be generated automatically.

On Mon, Oct 12, 2015 at 7:02 AM, Zhi Chang  wrote:

> Thanks for your reply. What should I do if I want to create a new
> migration script?
>
> Thanks
> Zhi Chang
>
>
> -- Original --
> *From: * "Vikram Choudhary";
> *Date: * Mon, Oct 12, 2015 12:22 PM
> *To: * "OpenStack Development Mailing List (not for usage questions)"<
> openstack-dev@lists.openstack.org>;
> *Subject: * Re: [openstack-dev] [Neutron][db]Neutron db revision fails
>
>
> Hi Zhi,
>
> We already have a defect logged for this issue.
>
> https://bugs.launchpad.net/neutron/+bug/1503342
>
> Thanks
> Vikram
> On Oct 12, 2015 8:10 AM, "Zhi Chang"  wrote:
>
>> Hi, everyone.
>> I install a devstack from the latest code. But there is an error when
>> I create a db migration script. My migration shell is:
>> "neutron-db-manage --config-file /etc/neutron/neutron.conf
>> --config-file /etc/neutron/plugins/ml2/ml2_conf.ini revision -m "Just For
>> Test""
>> The error shows:
>>   Running revision for neutron ...
>>   FAILED: Multiple heads are present; please specify the head
>> revision on which the new revision should be based, or perform a merge.
>>
>> Does my method wrong? Could someone helps me?
>>
>> Thx
>> 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
>>
>>
> __
> OpenStack Development Mailing 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 Kamyshnikova
Mirantis, Inc
__
OpenStack Development Mailing List (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] Returning of HEAD files?

[Anna Kamyshnikova]

Some time ago we merged change [1] that removes HEADS file. Validation of
migration revisions using HEADS file was replaced with pep8. This allows us
to avoid merge conflicts that appeared every time a new migration was
merged.

The problem was pointed by Kevin Benton as the original idea of HEAD file
[2] was not only to validate revisions, so as not to allow outdated changes
go into merge queue, that could be very important for the end of the cycle
when a lot of patches get approved.

I introduced change [3] that returns HEAD files, but this time they are
created per branch, so that will reduce merge conflicts a bit.

I understand that it was better to ask at the first time when [1] was on
review, should we have HEAD files and merge conflicts or not, but I want to
ask it now: Should I continue work on [3] or we are not expecting to have
problems with big merge queues?


[1] - https://review.openstack.org/#/c/227319/
[2] -
https://github.com/openstack/neutron/commit/36d85f831ae8eb21383806261bfc4c3d53dd1929
[3] - https://review.openstack.org/#/c/232607/

-- 
Regards,
Ann Kamyshnikova
Mirantis, Inc
__
OpenStack Development Mailing 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] New cycle started. What are you up to, folks?

[Anna Kamyshnikova]

I can' say that I have any great plans for this cycle, but I would like
look into L3 HA (L3 HA + DVR) feature, probably some bugfixes in this area
and online data migration as logical continuation of online migration
support that was done in Liberty.

On Tue, Oct 6, 2015 at 8:34 PM, Ihar Hrachyshka  wrote:

> > On 06 Oct 2015, at 19:10, Thomas Goirand  wrote:
> >
> > On 10/01/2015 03:45 PM, Ihar Hrachyshka wrote:
> >> Hi all,
> >>
> >> I talked recently with several contributors about what each of us plans
> for the next cycle, and found it’s quite useful to share thoughts with
> others, because you have immediate yay/nay feedback, and maybe find
> companions for next adventures, and what not. So I’ve decided to ask
> everyone what you see the team and you personally doing the next cycle, for
> fun or profit.
> >>
> >> That’s like a PTL nomination letter, but open to everyone! :) No
> commitments, no deadlines, just list random ideas you have in mind or in
> your todo lists, and we’ll all appreciate the huge pile of awesomeness no
> one will ever have time to implement even if scheduled for Xixao release.
> >>
> >> To start the fun, I will share my silly ideas in the next email.
> >>
> >> Ihar
> >
> > Could we have oslo-config-generator flat neutron.conf as a release goal
> > for Mitaka as well? The current configuration layout makes it difficult
> > for distributions to catch-up with working by default config.
>
> Good idea. I think we had some patches for that. I will try to keep it on
> my plate for M.
>
> 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 Kamyshnikova
Mirantis, Inc
__
OpenStack Development Mailing 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] How to add vendor specific db tables in neutron

[Anna Kamyshnikova]

Hi!

Probably in your vendor repo is missing change that will allow
neutron-db-manage to find the alembic migrations

automatically if this project is installed. See examples of such
changes in networking-cisco [1] and vmware-nsx [2].


[1] - https://review.openstack.org/214403

[2] - https://review.openstack.org/214413


On Thu, Aug 27, 2015 at 11:36 AM, bharath bhar...@brocade.com wrote:

 Hi ,


 I need to add a vendor specific db tables in neutron but vendor specific
 are no more allowed in the neutron. Tables need to be added to vendor
 repo itself.
 So i created alembic versioning in vendor repo. and added new tables
 under vendor repo.
 But i am not seeing tables getting created while stacking the devstack.

 So how to trigger the tables creation in vendor repo?


 Thanks,
 bharath




 __
 OpenStack Development Mailing 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 Kamyshnikova
Mirantis, Inc
__
OpenStack Development Mailing 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] How to add vendor specific db tables in neutron

[Anna Kamyshnikova]

In external.py are stored names of table that was already created in
Neutron, but then there models were moved to vendor repos. So adding new
names in external.py won't help you.

On Thu, Aug 27, 2015 at 1:05 PM, bharath bhar...@brocade.com wrote:

 Hi,

 Liberty code freeze is September 1st. But i have to add a vendor
 specific table for liberty release . As Vendor specific alembic
 support in neutron is  seems to be still under progress. Can i
 simply add tables names in external.py under alembic_migration  and
 push it upstream and implement actual tables later in vendor repo?

 Thanks, bharath




 On Thursday 27 August 2015 03:06 PM, Ihar Hrachyshka wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 On 08/27/2015 10:36 AM, bharath wrote:

 Hi ,


 I need to add a vendor specific db tables in neutron but vendor
 specific are no more allowed in the neutron. Tables need to be
 added to vendor repo itself. So i created alembic versioning in
 vendor repo. and added new tables under vendor repo. But i am not
 seeing tables getting created while stacking the devstack.

 So how to trigger the tables creation in vendor repo?

 http://docs.openstack.org/developer/neutron/devref/alembic_migrations.ht
 ml#indepedent-sub-project-tables

 Ihar
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v2

 iQEcBAEBCAAGBQJV3tohAAoJEC5aWaUY1u57H+kH/jLD1bkLrwRoOVCi+rmonV+g
 fuU15mritbUWag3dyg64GRMjGQ/aRFoP5D9HjATkSAa0wb7H5UlbAGfsE2PqHtrR
 MOJ9l7ldJ1tAb5JS8Pti60uE0zEqv4dBEF2SmoXxRw88kN1WvUaiBtovBuIsfxwB
 pm+3MIZH8AEBnBYIwnsTdU59lMPJgDKdfCU8WlgpewM5rxrtBAHANkrr+wCHYH2l
 BfUgY+3mu+k4vKzravmgf29dDw8kzc68qXb+Z8IfyWbqadSoc8PhVke5DBf4utAw
 tzqHGUpIHHBPUq0zLM6wwJsIJLAX33glJ00Sl8JeIMjh8RN/qZASZWOi+1CI9hc=
 =zne4
 -END PGP SIGNATURE-

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



 __
 OpenStack Development Mailing 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 Kamyshnikova
Mirantis, Inc
__
OpenStack Development Mailing 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][dvr] DVR L2 agent is removing the br-int OVS flows

[Anna Kamyshnikova]

I pushed change for that case https://review.openstack.org/215596.

On Fri, Aug 21, 2015 at 2:45 PM, Anna Kamyshnikova 
akamyshnik...@mirantis.com wrote:

 Hi, Artur!

 Thanks, for bringing this up! I missed that. I push change for that in a
 short time.

 On Fri, Aug 21, 2015 at 1:35 PM, Korzeniewski, Artur 
 artur.korzeniew...@intel.com wrote:

 Hi all,

 After merging the “Graceful ovs-agent restart”[1] (great work BTW!), I’m
 seeing in DVR L2 agent code place where flows on br-int is removed in old
 style:



 File
 /neutron/plugins/ml2/drivers/openvswitch/agent/ovs_dvr_neutron_agent.py

 200 def setup_dvr_flows_on_integ_br(self):

 201 '''Setup up initial dvr flows into br-int'''

 202 if not self.in_distributed_mode():

 203 return

 204

 205 LOG.info(_LI(L2 Agent operating in DVR Mode with MAC %s),

 206  self.dvr_mac_address)

 207 # Remove existing flows in integration bridge

 208 self.int_br.delete_flows()



 This is kind of bummer when seeing the effort to preserve the flows in
 [1].

 This should not affect VM network access, since the br-tun is configured
 properly and br-int is in learning mode.



 Should this be fixed in Liberty cycle?



 This is something similar to submitted bug:
 https://bugs.launchpad.net/neutron/+bug/1436156



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



 Regards,

 Artur Korzeniewski

 

 Intel Technology Poland sp. z o.o.

 KRS 101882

 ul. Slowackiego 173, 80-298 Gdansk



 __
 OpenStack Development Mailing 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 Kamyshnikova
 Mirantis, Inc




-- 
Regards,
Ann Kamyshnikova
Mirantis, Inc
__
OpenStack Development Mailing 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][dvr] DVR L2 agent is removing the br-int OVS flows

[Anna Kamyshnikova]

Hi, Artur!

Thanks, for bringing this up! I missed that. I push change for that in a
short time.

On Fri, Aug 21, 2015 at 1:35 PM, Korzeniewski, Artur 
artur.korzeniew...@intel.com wrote:

 Hi all,

 After merging the “Graceful ovs-agent restart”[1] (great work BTW!), I’m
 seeing in DVR L2 agent code place where flows on br-int is removed in old
 style:



 File
 /neutron/plugins/ml2/drivers/openvswitch/agent/ovs_dvr_neutron_agent.py

 200 def setup_dvr_flows_on_integ_br(self):

 201 '''Setup up initial dvr flows into br-int'''

 202 if not self.in_distributed_mode():

 203 return

 204

 205 LOG.info(_LI(L2 Agent operating in DVR Mode with MAC %s),

 206  self.dvr_mac_address)

 207 # Remove existing flows in integration bridge

 208 self.int_br.delete_flows()



 This is kind of bummer when seeing the effort to preserve the flows in [1].

 This should not affect VM network access, since the br-tun is configured
 properly and br-int is in learning mode.



 Should this be fixed in Liberty cycle?



 This is something similar to submitted bug:
 https://bugs.launchpad.net/neutron/+bug/1436156



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



 Regards,

 Artur Korzeniewski

 

 Intel Technology Poland sp. z o.o.

 KRS 101882

 ul. Slowackiego 173, 80-298 Gdansk



 __
 OpenStack Development Mailing 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 Kamyshnikova
Mirantis, Inc
__
OpenStack Development Mailing 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] I am pleased to propose two new Neutron API/DB/RPC core reviewers!

[Anna Kamyshnikova]

+1 for both

On Wed, Aug 12, 2015 at 5:04 PM, Edgar Magana edgar.mag...@workday.com
wrote:

 +1 and +1

 Great addition to the team!

 Edgar

 From: Kyle Mestery
 Reply-To: OpenStack Development Mailing List (not for usage questions)
 Date: Wednesday, August 12, 2015 at 6:45 AM
 To: OpenStack Development Mailing List (not for usage questions)
 Subject: [openstack-dev] [neutron] I am pleased to propose two new
 Neutron API/DB/RPC core reviewers!

 It gives me great pleasure to propose Russell Bryant and Brandon Logan as
 core reviewers in the API/DB/RPC area of Neutron. Russell and Brandon have
 both been incredible contributors to Neutron for a while now. Their
 expertise has been particularly helpful in the area they are being proposed
 in. Their review stats [1] place them both comfortably in the range of
 existing Neutron core reviewers. I expect them to continue working with all
 community members to drive Neutron forward for the rest of Liberty and into
 Mitaka.

 Existing DB/API/RPC core reviewers (and other Neutron core reviewers),
 please vote +1/-1 for the addition of Russell and Brandon.

 Thanks!
 Kyle

 [1] http://stackalytics.com/report/contribution/neutron-group/90

 __
 OpenStack Development Mailing 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 Kamyshnikova
Mirantis, Inc
__
OpenStack Development Mailing 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] Plethora of dbase migration questions...

[Anna Kamyshnikova]

Hi, Paul!

This messages is OK. May be you can put a change on review in WIP status,
that I will be able to check what is going on? I never have such problems
with migrations in neutron-vpnaas repo. May be the problem is that database
is already upgraded, was database cleaned before you run neutron-db-manage
upgrade head?

On Tue, Jul 7, 2015 at 11:35 PM, Paul Michali p...@michali.net wrote:

 Well, I can run the upgrade command, but it doesn't seem to be processing
 my new migration file. I have tried using upgrade with 'head', and with the
 HEAD file set to the previous version and to the new version. In both
 cases, I get these info messages twice: Context impl MySWLImpl. and Will
 assume non-transactional DDL. I put a import pdb; pdb.set_trace() in my
 migration file, but it never reaches that.

 What am I possibly missing?

 Regards,

 PCM


 On Tue, Jul 7, 2015 at 4:04 PM Paul Michali p...@michali.net wrote:

 I found the issue. The upgrade is looking for config to have [database]
 section and connection definition. If I use /etc/neutron/neutron.conf, then
 the neutron-db-manage runs.



 On Tue, Jul 7, 2015 at 3:38 PM Paul Michali p...@michali.net wrote:

 I have that change in the neutron repo that is being used with by this
 neutron-vpnaas repo.

 On Tue, Jul 7, 2015 at 3:12 PM Mike Bayer mba...@redhat.com wrote:



 On 7/7/15 1:28 PM, Paul Michali wrote:

 HEAD, head, 24f28869838b (my new file) all say the same thing. :(


  On Tue, Jul 7, 2015 at 12:34 PM Salvatore Orlando sorla...@nicira.com
 wrote:

 possibly I was wrong in mixing up git  alembic.
 It should be upgrade head - lowercase.

  If that doesn't work there might some other issue lurking.

  Salvatore

 On 7 July 2015 at 17:44, Paul Michali p...@michali.net wrote:

 Salvatore,

  I changed head to the version before my new one, and then tried to
 upgrade and I see this:
   neutron-db-manage --config-file
 /opt/stack/neutron/etc/neutron.conf --service vpnaas upgrade HEAD
 Traceback (most recent call last):
   File /usr/local/bin/neutron-db-manage, line 10, in module
 sys.exit(main())
   File /opt/stack/neutron/neutron/db/migration/cli.py, line 238, in
 main
 CONF.command.func(config, CONF.command.name)
   File /opt/stack/neutron/neutron/db/migration/cli.py, line 105, in
 do_upgrade
 run_sanity_checks(config, revision)
   File /opt/stack/neutron/neutron/db/migration/cli.py, line 229, in
 run_sanity_checks
 script_dir.run_env()
   File /usr/local/lib/python2.7/dist-packages/alembic/script.py,
 line 390, in run_env
 util.load_python_file(self.dir, 'env.py')
   File /usr/local/lib/python2.7/dist-packages/alembic/util.py, line
 243, in load_python_file
 module = load_module_py(module_id, path)
   File /usr/local/lib/python2.7/dist-packages/alembic/compat.py,
 line 79, in load_module_py
 mod = imp.load_source(module_id, path, fp)
   File
 /opt/stack/neutron-vpnaas/neutron_vpnaas/db/migration/alembic_migrations/env.py,
 line 86, in module
 run_migrations_online()
   File
 /opt/stack/neutron-vpnaas/neutron_vpnaas/db/migration/alembic_migrations/env.py,
 line 67, in run_migrations_online
 engine = session.create_engine(neutron_config.database.connection)
   File
 /usr/local/lib/python2.7/dist-packages/oslo_db/sqlalchemy/engines.py,
 line 112, in create_engine
 url = sqlalchemy.engine.url.make_url(sql_connection)
   File
 /usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/url.py, line
 186, in make_url
 return _parse_rfc1738_args(name_or_url)
   File
 /usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/url.py, line
 235, in _parse_rfc1738_args
 Could not parse rfc1738 URL from string '%s' % name)
 sqlalchemy.exc.ArgumentError: Could not parse rfc1738 URL from string
 ''

  Any ideas what is wrong here?


 I'm going to guess this is the issue fixed by
 https://review.openstack.org/#/c/194197/






  On Tue, Jul 7, 2015 at 10:05 AM Paul Michali p...@michali.net wrote:


  Yes, I wasn't using the --service option, so I suspect that is why
 my down_version was wrong.  In talking with Akihiro, I added a check to
 PEP8 and made sure that it fails if head is wrong. It is:
 https://review.openstack.org/#/c/199082/
 https://review.openstack.org/#/c/199082/ (of course that failed
 py27 - I've got to see if there was some recent breakage in vpn repo,
 again).

  Regarding the migration, one of the new columns may be None, but
 there must be at least one IP version entry (there is an existing test 
 in
 VPN for using a router w/o an external IP set). Since the new code will
 rely on these new fields, I'd like to populate them as part of the
 migration. I think it would be more complicated to handle during 
 operation.

  Does anyone have examples of how to do queries of objects, from
 the migration upgrade() code?


  Regards,

  PCM

  On Tue, Jul 7, 2015 at 9:02 AM Akihiro Motoki amot...@gmail.com
 wrote:

  2015-07-07 21:39 GMT+09:00 Henry Gessau  ges...@cisco.com
 ges...@cisco.com:

  On Tue, 

Re: [openstack-dev] [Neutron] Proposing Rossella Sblendido for the Control Plane core team

[Anna Kamyshnikova]

Congratulations Rossella!

On Sat, Jun 20, 2015 at 1:50 AM, Kevin Benton blak...@gmail.com wrote:

 It's been a week with no negative feedback. Welcome to the team Rossella!

 On Mon, Jun 15, 2015 at 2:53 AM, Oleg Bondarev obonda...@mirantis.com
 wrote:

 +1

 On Mon, Jun 15, 2015 at 12:14 PM, Ihar Hrachyshka ihrac...@redhat.com
 wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 No doubt +1.

 On 06/12/2015 09:44 PM, Kevin Benton wrote:
  Hello!
 
  As the Lieutenant of the built-in control plane[1], I would like
  Rossella Sblendido to be a member of the control plane core
  reviewer team.
 
  Her review stats are in line with other cores[2] and her feedback
  on patches related to the agents has been great. Additionally, she
  has been working quite a bit on the blueprint to restructure the L2
  agent code so she is very familiar with the agent code and the APIs
  it leverages.
 
  Existing cores that have spent time working on the reference
  implementation (agents and AMQP code), please vote +1/-1 for her
  addition to the team. Aaron, Gary, Assaf, Maru, Kyle, Armando, Carl
  and Oleg; you have all been reviewing things in these areas
  recently so I would like to hear from you specifically.
 
  1.
  http://docs.openstack.org/developer/neutron/policies/core-reviewers.ht
 ml#core-review-hierarchy
 http://docs.openstack.org/developer/neutron/policies/core-reviewers.html#core-review-hierarchy
 
 
 2. http://stackalytics.com/report/contribution/neutron-group/30
 
  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
 
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v2

 iQEcBAEBCAAGBQJVfpdmAAoJEC5aWaUY1u574skIAOm15mNKujH3X3XSpwtmy+V4
 cWNvjYZy0lCG2lbyAwGwgQD0Ybs88/RKOZPPpu9gugAuWcFQRHMSMcsahaTLcH5B
 6imK0tEUUn2HdCd9522kEWtf7Hkpux6p5TLQQo2tucvIBQohJuU42EidfKs9Peat
 ed/2kiXm+TGRSnZHAYwzJIrttux3ntTLQeTvElo+4vUQEQJNwm8eguXiAPENEjr9
 7Ou3TgnYeLXsfVopHXNV+jtkHDr92giB4joODqwc8RNDKE2+dhaqDxCrXq6ksYq7
 RFiyVy1qve394ebP0Ta0dq6LKmAYZCnRC9i928GSK5RvQBvcnJRiyFGIgtn4Qu0=
 =59av
 -END PGP SIGNATURE-


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



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




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




-- 
Regards,
Ann Kamyshnikova
Mirantis, Inc
__
OpenStack Development Mailing 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 Ann Kamyshnikova for the API DB core reviewer team

[Anna Kamyshnikova]

Thanks! It is a great honor and huge responsibility that I'll try to fit in.
On Jun 18, 2015 8:42 PM, Paul Michali p...@michali.net wrote:

 Congratulations Ann!

 On Thu, Jun 18, 2015 at 12:22 PM Edgar Magana edgar.mag...@workday.com
 wrote:

 Congratulations Ann and welcome to the team!

 Edgar




 On 6/18/15, 8:56 AM, Henry Gessau ges...@cisco.com wrote:

 It has been a week and feedback has been positive and supportive of
 Ann's nomination.  Welcome to the Neutron DB core reviewer team, Ann.
 
 --
 Henry
 
 On Thu, Jun 11, 2015, Henry Gessau ges...@cisco.com wrote:
  As one of the Lieutenants [1] for the API and DB areas under the PTL,
 I would
  like to propose Ann Kamyshnikova as a member of the Neutron API and DB
 core
  reviewer team.
 
  Ann has been a long time contributor in Neutron showing expertise
 particularly
  in database matters. She has also worked with and contributed code to
 the
  oslo.db and sqlalchemy/alembic projects. Ann was a critical
 contributor to the
  Neutron database healing effort that was completed in the Juno cycle.
 
  Her deep knowledge of databases and backends, and her expertise with
 oslo.db,
  sqlalchemy and alembic will be very important in this area. Ann is a
 trusted
  member of our community and her review stats [2][3][4] place her
 comfortably
  with other Neutron core reviewers. She consistently catches database
 issues
  early when patches are submitted for review, and shows dedication to
 helping
  developers understand and perfect their database-related changes.
 
  Existing Neutron core reviewers from the API and DB area of focus,
 please vote
  +1/-1 for the addition of Ann to the core reviewer team. Specifically,
 I'm
  looking for votes from Akihiro (co-Lieutenant), Mark, Maru, Armando
 and Carl.
 
 
  [1]
 
 http://docs.openstack.org/developer/neutron/policies/core-reviewers.html#adding-or-removing-core-reviewers
  [2]
 
 https://review.openstack.org/#/q/reviewer:%22Ann+Kamyshnikova+%253Cakamyshnikova%2540mirantis.com%253E%22,n,z
  [3] http://stackalytics.com/report/contribution/neutron-group/90
  [4] http://stackalytics.com/?user_id=akamyshnikovametric=marks
 
 
 

 __
 OpenStack Development Mailing List (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][db] online schema upgrades

[Anna Kamyshnikova]

On Wed, Jun 17, 2015 at 8:23 PM, Mike Bayer mba...@redhat.com wrote:



 On 6/17/15 12:40 PM, Ihar Hrachyshka wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 On 06/17/2015 11:27 AM, Anna Kamyshnikova wrote:

  Ihar, thanks for bringing this up!

 This is very interesting and I think it worth trying. I'm +1 on
 that and want to participate in this work.


  Awesome.


  In fact a lot *not strict* migrations are removed with
 juno_initial, so I hope it won't be so hard for now to apply
 stricter rules for migration. But what is the plan for those
 migrations that are *not strict* now?

  Still, we have several live data migrations from Juno to Kilo:

 - - 14be42f3d0a5_default_sec_group_table.py: populates db with default
 security groups;

 - - 16cdf118d31d_extra_dhcp_options_ipv6_support.py: populates
 extraqdhcpopts with default ip_version = 4;

 - - 2d2a8a565438_hierarchical_binding.py: populates db with
 port_binding_levels objects, then drops old tables;

 - - 35a0f3365720_add_port_security_in_ml2.py: port security field is
 populated with True for ports and networks;

 - - 034883111f_remove_subnetpool_allow_overlap.py: drops allow_overlap
 column from subnetpools: probably unused so we can be ok with it?..

 In any case, the plan for existing migration rules is: don't touch
 them. Their presence in N release just indicates that we cannot get
 online db migration in N+1. That's why we should adopt strict rules
 the earlier the better, so that opportunity does not slip to N+X where
 X is too far.

 The patches currently in review that look suspicious in this regard are:
 - - I4ff7db0f5fa12b0fd1c6b10318e9177fde0210d7: moves data from one table
 into another;
 - - Iecb3e168a805fc5f3d59d894c3f0d9298505e872: fills new columns with
 default server values (why is it even needed?..);
 - - Icde55742aa78ed995bac0896c01c80c9d28aa0cf: alter_column(). Not sure
 we are ok with it;
 - - I66b3ee8c2f9fa6f04b9e89dc49d1a3d277d63191: probably not an issue
 though since it touches existing live data impact rule?


 I made a list of migrations from juno- kilo that are non expansive or do
 data migrations:

 *these contain drop column:*

  034883111f_remove_subnetpool_allow_overlap.py
 2d2a8a565438_hierarchical_binding.py

  *these contain drop table:*

  28c0ffb8ebbd_remove_mlnx_plugin.py
 2b801560a332_remove_hypervneutronplugin_tables.py
 408cfbf6923c_remove_ryu_plugin.py
 57086602ca0a_scrap_nsx_adv_svcs_models.py

  *these contain data migrations:*

  14be42f3d0a5_default_sec_group_table.py
 16cdf118d31d_extra_dhcp_options_ipv6_support.py
 2b801560a332_remove_hypervneutronplugin_tables.py
 2d2a8a565438_hierarchical_binding.py
 35a0f3365720_add_port_security_in_ml2.py

  *Example of failure:*

  
 neutron/db/migration/alembic_migrations/versions/2d2a8a565438_hierarchical_binding.py
 - drops the following columns:

  op.drop_constraint(fk_name_dvr[0], 'ml2_dvr_port_bindings',
 'foreignkey')
 op.drop_column('ml2_dvr_port_bindings', 'cap_port_filter')
 op.drop_column('ml2_dvr_port_bindings', 'segment')
 op.drop_column('ml2_dvr_port_bindings', 'driver')

  op.drop_constraint(fk_name[0], 'ml2_port_bindings', 'foreignkey')
 op.drop_column('ml2_port_bindings', 'driver')
 op.drop_column('ml2_port_bindings', 'segment')

 which then causes a failure in Juno:

 OperationalError: (OperationalError) (1054, Unknown column
 'ml2_port_bindings_1.driver' in 'field list')


In M release we will be able to create kilo_initial migration that will
hide all these migrations(juno - kilo), so I as there is nothing we can do
we won't touch them as Ihar said. The problem about migrations that are on
review is more serious, as we should adopt strict rules as early as
possible and all core reviewer should be aware about that.

To Ihar's list of migrations on review  I can add :
I3426b13eede8bfa29729cf3efea3419fb91175c4 - insert some data,
I9cf36e1fd3a009c175e0d475af407a30f4e5c408 (almost ready to be merged!) -
drop tables.
And there are a lot changes with altering columns. One is merged in
neutron-vpnaas.
So we should decide these things quickly.







  (the list can be incomplete)


  I think that we should try to use Alembic as much we could as Mike
 is going to support us in that and we have time to make some change
 in Alembic directly.

  Yes, sure, I'm looking forward to see Mike's proposal in public.


  We should undoubtedly plan this work for M release because there
 will be some issues that will appear in the process.


  Sure.

 Ihar
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v2

 iQEcBAEBCAAGBQJVgaL4AAoJEC5aWaUY1u57oZgH/34pgV7AqOiq4XnWOOmQ9HA9
 jL+8E9jv8pUSW3X4v0Rm5mDuWJyWscrgy61Om+sWsmqBFAmm/gmLWm+NNADbYM5e
 6hsoaO5WmuvRc03MwIwsa0NEgfPc8EhT5JiZmYRjOBc85ZCs6+UOKUHBAI2EVTg8
 t8YKdTdzxlrZQEOng1lbsUQYkHnNUZTbsREnpangfaHXBk3xmilH/ebGsz3CRUCe
 OBrpp6q8N7mgZgK/UQKb04eS5bCna7eVmv6q7PvIO0SlYhhDbrL3+dv/SZpqQWZ/
 Hek2Oig0IYyPygVrGc4BpT9MIaKisGoxXMn1rRB2g8us8jM58VyzqgXwEH2H4Aw=
 =TqHb
 -END

Re: [openstack-dev] [neutron][db] online schema upgrades

[Anna Kamyshnikova]

Ihar, thanks for bringing this up!

This is very interesting and I think it worth trying. I'm +1 on that and
want to participate in this work.

In fact a lot *not strict* migrations are removed with juno_initial, so I
hope it won't be so hard for now to apply stricter rules for migration. But
what is the plan for those migrations that are *not strict* now?

I think that we should try to use Alembic as much we could as Mike is going
to support us in that and we have time to make some change in Alembic
directly.

We should undoubtedly plan this work for M release because there will be
some issues that will appear in the process.

On Tue, Jun 16, 2015 at 6:58 PM, Mike Bayer mba...@redhat.com wrote:



 On 6/16/15 11:41 AM, Ihar Hrachyshka wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 - - instead of migrating data with alembic rules, migrate it in runtime.
 There should be a abstraction layer that will make sure that data is
 migrated into new schema fields and objects, while preserving data
 originally stored in 'old' schema elements.

 That would allow old neutron-server code to run against new schema (it
 will just ignore new additions); and new neutron-server code to
 gradually migrate data into new columns/fields/tables while serving user
 s.

 Hi Ihar -

 I was in the middle of writing a spec for neutron online schema
 migrations, which maintains expand / contract workflow but also maintains
 Alembic migration scripts.   As I've stated many times in the past, there
 is no reason to abandon migration scripts, while there are many issues
 related to abandoning the notion of the database in a specific versioned
 state as well as the ability to script any migrations whatsoever.   The
 spec amends Nova's approach and includes upstream changes to Alembic such
 that both approaches can be supported using the same codebase.

 - mike




 __
 OpenStack Development Mailing 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 Kamyshnikova
Mirantis, Inc
__
OpenStack Development Mailing List (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] L3 agent rescheduling issue

[Anna Kamyshnikova]

Hi, neutrons!

Some time ago I discovered a bug for l3 agent rescheduling [1]. When there
are a lot of resources and agent_down_time is not big enough neutron-server
starts marking l3 agents as dead. The same issue has been discovered and
fixed for DHCP-agents. I proposed a change similar to those that were done
for DHCP-agents. [2]

There is no unified opinion on this bug and proposed change, so I want to
ask developers whether it worth to continue work on this patch or not.

[1] - https://bugs.launchpad.net/neutron/+bug/1440761
[2] - https://review.openstack.org/171592

-- 
Regards,
Ann Kamyshnikova
Mirantis, Inc
__
OpenStack Development Mailing 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] [Nutron] Extending database schema from 3rd-party plugin

[Anna Kamyshnikova]

Hi, Alexey

In fact alembic has autogenerate option, so if you created the model you
can use something like neutron-db-manage --config-file
/etc/neutron/neutron.conf --config-file
/etc/neutron/plugins/ml2/ml2_conf.ini revision --autogenerate and alembic
will create missing script itself. If you have some problems or questions
about it, you can ask me directly via IRC (akamyshnikova) or an email.


On Wed, May 13, 2015 at 12:41 AM, Kevin Benton blak...@gmail.com wrote:

 If you have a pretty simple schema that isn't tightly integrated into
 the broader neutron schema, you could could always just resort to
 detecting of the schema during your ml2 driver initialization and just
 create the schema with SQL statements right then.

 The advantage to that approach is that you don't have to worry about
 messing with the deployed alembic scripts.
 The disadvantage is that it's not managed by alembic, so you would
 have to manually handle upgrades yourself.

 On Tue, May 12, 2015 at 10:42 AM, Alexey I. Froloff ra...@raorn.name
 wrote:
  Greetings!
 
  I am developing ML2 type/mech plugin for some very special
  environment.  Because this environment is very special (using
  addressing based on physical hypervisor location), it will be
  separate package, I don't plan to alter Neutron code.  And this
  plugin needs to store some information in Neutron database.  Not
  altering existing tables, but adding couple.
 
  I'm not very good with alembic (better say not good at all),
  maybe someone can enlight me, if this possible at all and how to
  make it with minimal damage.  I am writing this plugin for Kilo
  release, and this installation is supposed to be further updated
  to next OpenStack releases.
 
  --
  Regards,--
  Sir Raorn.   --- https://plus.google.com/+AlexeyFroloff
 
 
 __
  OpenStack Development Mailing List (not for usage questions)
  Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 



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




-- 
Regards,
Ann Kamyshnikova
Mirantis, Inc
__
OpenStack Development Mailing List (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] Dropped downgrade support from migration scripts

[Anna Kamyshnikova]

Hello neutrons,

I would like to notify all developers that all downgrades was removed from
migration scripts [1]. So, if you have a change on review with a migration
you have to submit another patch set with updated migration.

This work was done according approved cross-project spec [2].

[1] - https://review.openstack.org/165740
[2] - https://review.openstack.org/152337

-- 
Regards,
Ann Kamyshnikova
Mirantis, Inc
__
OpenStack Development Mailing List (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] What does default [] for flat_networks means?

[Anna Kamyshnikova]

I worked on bug [1] and pushed change request [2] and I got Ryu CI check
failing [5], because flat_networks is not set in config. For vlan networks
empty list in 'network_vlan_ranges' means that no physical networks are
allowed [3], for flat networks there is only help string for config option
[4] and it seems that similar behaviour is expected there too. So, my
question is what should be done in this case?  Should default be changed to
'*' or should some changes be done on devstack side?

[1] - https://bugs.launchpad.net/neutron/+bug/1424548
[2] - https://review.openstack.org/160842
[3] -
https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/drivers/type_vlan.py#L175
[4] -
https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/drivers/type_flat.py#L32
[5] -
http://180.37.183.32/ryuci/42/160842/5/check/check-tempest-dsvm-ofagent/005e5e2/logs/devstacklog.txt.gz
__
OpenStack Development Mailing List (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] check-grenade-dsvm-neutron failure

[Anna Kamyshnikova]

Hello everyone!

A change has been merged yesterday [1] that propose default security group
table to Neutron. It passed all checks well. But now from time to time I
see that check-grenade-dsvm-neutron fails on db upgrade as it has more than
one default security group in one tenant. Having more than one default
security group is not expected behavior and I'm really curious how does it
sometimes happen. I filed a bug about this [2] for Tempest at this moment.

[1] - https://review.openstack.org/142101
[2] - https://bugs.launchpad.net/tempest/+bug/1416294

Regards,
Ann Kamyshnikova
__
OpenStack Development Mailing 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] UniqueConstraint for name and tenant_id in security group

[Anna Kamyshnikova]

Looking at all comments it seems that existing change is reasonable. I will
update it with link to this thread.

Thanks!

Regards,
Ann Kamyshnikova

On Sat, Dec 13, 2014 at 1:15 AM, Rochelle Grober rochelle.gro...@huawei.com
 wrote:





 Morgan Fainberg [mailto:morgan.fainb...@gmail.com] *on* Friday, December
 12, 2014 2:01 PM wrote:
 On Friday, December 12, 2014, Sean Dague s...@dague.net wrote:

 On 12/12/2014 01:05 PM, Maru Newby wrote:
 
  On Dec 11, 2014, at 2:27 PM, Sean Dague s...@dague.net wrote:
 
  On 12/11/2014 04:16 PM, Jay Pipes wrote:
  On 12/11/2014 04:07 PM, Vishvananda Ishaya wrote:
  On Dec 11, 2014, at 1:04 PM, Jay Pipes jaypi...@gmail.com wrote:
  On 12/11/2014 04:01 PM, Vishvananda Ishaya wrote:
 
  On Dec 11, 2014, at 8:00 AM, Henry Gessau ges...@cisco.com wrote:
 
  On Thu, Dec 11, 2014, Mark McClain m...@mcclain.xyz wrote:
 
  On Dec 11, 2014, at 8:43 AM, Jay Pipes jaypi...@gmail.com
  mailto:jaypi...@gmail.com wrote:
 
  I'm generally in favor of making name attributes opaque, utf-8
  strings that
  are entirely user-defined and have no constraints on them. I
  consider the
  name to be just a tag that the user places on some resource. It
  is the
  resource's ID that is unique.
 
  I do realize that Nova takes a different approach to *some*
  resources,
  including the security group name.
 
  End of the day, it's probably just a personal preference whether
  names
  should be unique to a tenant/user or not.
 
  Maru had asked me my opinion on whether names should be unique
 and I
  answered my personal opinion that no, they should not be, and if
  Neutron
  needed to ensure that there was one and only one default security
  group for
  a tenant, that a way to accomplish such a thing in a race-free
  way, without
  use of SELECT FOR UPDATE, was to use the approach I put into the
  pastebin on
  the review above.
 
 
  I agree with Jay.  We should not care about how a user names the
  resource.
  There other ways to prevent this race and Jay’s suggestion is a
  good one.
 
  However we should open a bug against Horizon because the user
  experience there
  is terrible with duplicate security group names.
 
  The reason security group names are unique is that the ec2 api
  supports source
  rule specifications by tenant_id (user_id in amazon) and name, so
  not enforcing
  uniqueness means that invocation in the ec2 api will either fail or
 be
  non-deterministic in some way.
 
  So we should couple our API evolution to EC2 API then?
 
  -jay
 
  No I was just pointing out the historical reason for uniqueness, and
  hopefully
  encouraging someone to find the best behavior for the ec2 api if we
  are going
  to keep the incompatibility there. Also I personally feel the ux is
  better
  with unique names, but it is only a slight preference.
 
  Sorry for snapping, you made a fair point.
 
  Yeh, honestly, I agree with Vish. I do feel that the UX of that
  constraint is useful. Otherwise you get into having to show people UUIDs
  in a lot more places. While those are good for consistency, they are
  kind of terrible to show to people.
 
  While there is a good case for the UX of unique names - it also makes
 orchestration via tools like puppet a heck of a lot simpler - the fact is
 that most OpenStack resources do not require unique names.  That being the
 case, why would we want security groups to deviate from this convention?

 Maybe the other ones are the broken ones?

 Honestly, any sanely usable system makes names unique inside a
 container. Like files in a directory. In this case the tenant is the
 container, which makes sense.

 It is one of many places that OpenStack is not consistent. But I'd
 rather make things consistent and more usable than consistent and less.



 +1.



 More consistent and more usable is a good approach. The name uniqueness
 has prior art in OpenStack - keystone keeps project names unique within a
 domain (domain is the container), similar usernames can't be duplicated in
 the same domain. It would be silly to auth with the user ID, likewise
 unique names for the security group in the container (tenant) makes a lot
 of sense from a UX Perspective.



 *[Rockyg] +1*

 *Especially when dealing with domain data that are managed by Humans,
 human visible unique is important for understanding *and* efficiency.
 Tenant security is expected to be managed by the tenant admin, not some
 automated “robot admin” and as such needs to be clear , memorable and
 seperable between instances.  Unique names is the most straightforward (and
 easiest to enforce) way do this for humans. Humans read differentiate
 alphanumerics, so that should be the standard differentiator when humans
 are expected to interact and reason about containers.*



 --Morgan

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

Re: [openstack-dev] [Neutron] UniqueConstraint for name and tenant_id in security group

[Anna Kamyshnikova]

Thanks everyone for sharing yours opinion! I will create a separate change
with another option that was suggested.

Yes, I'm currently working on this bug
https://bugs.launchpad.net/neutron/+bug/1194579.



On Fri, Dec 12, 2014 at 2:41 PM, Ihar Hrachyshka ihrac...@redhat.com
wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA512

 On 12/12/14 00:05, Mathieu Gagné wrote:
  We recently had an issue in production where a user had 2
  default security groups (for reasons we have yet to identify).

 This is probably the result of the race condition that is discussed in
 the thread: https://bugs.launchpad.net/neutron/+bug/1194579
 /Ihar
 -BEGIN PGP SIGNATURE-
 Version: GnuPG/MacGPG2 v2.0.22 (Darwin)

 iQEcBAEBCgAGBQJUitR/AAoJEC5aWaUY1u57VggIALzdTLHnO7Fr8gKlWPS7Uu+o
 Su9KV41td8Epzs3pNsGYkH2Kz4T5obAneCORUiZl7boBpAJcnMm3Jt9K8YnTCVUy
 t4AbfIxSrTD7drHf3HoMoNEDrSntdnpTHoGpG+idNpFjc0kjBjm81W3y14Gab0k5
 5Mw/jV8mdnB6aRs5Zhari50/04X8SZeDpQNgBHL5kY40CZ+sUtS4C8OKfj7OEAuW
 LNmkHgDAtwewbNdluntbSdLGVjyl/F9s+21HoajqBcGNhH8ZHpAr4hphMbZv8lBY
 iAD2tztxvkacYaGduBFh6bewxVNGaUJBWmmc2xqHAXXbDP3d9aOk5q0wHK3SPQY=
 =TDwc
 -END PGP SIGNATURE-

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

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

[openstack-dev] [Neutron] UniqueConstraint for name and tenant_id in security group

[Anna Kamyshnikova]

Hello everyone!

In neutron there is a rather old bug [1] about adding uniqueness for
security group name and tenant id. I found this idea reasonable and started
working on fix for this bug [2]. I think it is good to add a
uniqueconstraint because:

1) In nova there is such constraint for security groups
https://github.com/openstack/nova/blob/stable/juno/nova/db/sqlalchemy/migrate_repo/versions/216_havana.py#L1155-L1157.
So I think that it is rather disruptive that it is impossible to create
security group with the same name in nova, but possible in neutron.
2) Users get confused having security groups with the same name.

In comment for proposed change Assaf Muller and Maru Newby object for such
solution and suggested another option, so I think we need more eyes on this
change.

I would like to ask you to share your thoughts on this topic.

[1] - https://bugs.launchpad.net/neutron/+bug/1194579
[2] - https://review.openstack.org/135006
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Tempest basic

[Anna Kamyshnikova]

Hi!

Try nosetests -sv tempest.scenario.test_minimum_basic

Regards,
Ann


On Wed, Nov 19, 2014 at 12:16 PM, Vineet Menon mvineetme...@gmail.com
wrote:

 Hi,

 I'm trying to run a single tempest test on openstack but things aren't
 working as expected.

 My pwd is tempest root.

 This is what I'm trying to do, 'nosetests -v
 tempest.scenario.test_minimum_basic.py', but it throws error.
 I tried 'nosetests -v tempest/scenario/test_minimum_basic.py' as well, but
 again errors are being thrown.

 I'm following '
 https://docs.google.com/presentation/d/1M3XhAco_0u7NZQn3Gz53z9VOHHrkQBzEs5gt43ZvhOc/edit#slide=id.gcc7522_3_13'
 presentation as guide.


 Regards,

 Vineet Menon


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


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

[openstack-dev] [Neutron] Test verifying that models are in sync with migrations landed

[Anna Kamyshnikova]

Hi everyone!

I want to bring to everyone's attention that now Neutron has test that
checks that migrations create the same scheme that mentioned in models.
Docs with explanation of its usage are shown here [1].

Now this is unittest, but it is expected to be moved to functional [2].
Anyway if you have migration in your change, you can expect jobs
gate-neutron-python26, gate-neutron-python27 (now) and
check-neutron-dsvm-functional (when [2] lands) to fail if you did something
wrong in it.

If you have some questions about usage I am available on irc
(akamyshnikova) and via email.

[1] - http://docs.openstack.org/developer/neutron/devref/db_layer.html
[2] - https://review.openstack.org/126175

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

[openstack-dev] [neutron] Requirements freeze exception for testscenarios, oslotest, psycopg2, MySQL-python

[Anna Kamyshnikova]

I'd like to request a requirements freeze exception for testscenarios,
oslotest, psycopg2 and MySQL-python for tests
- https://review.openstack.org/76520

This test provides verification of models with migrations synchronization
which is important to have in Juno -
https://bugs.launchpad.net/neutron/+bug/1346444
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][db] Need help resolving a strange error with db connections in tests

[Anna Kamyshnikova]

This is implementing ModelsMigrationsSync test from oslo [1]. For running
it locally on Postgres you have to do the following things (it is mentioned
in comments to test):

For the opportunistic testing you need to set up a db named
'openstack_citest' with user 'openstack_citest' and password
'openstack_citest' on localhost.
The test will then use that db and user/password combo to run the tests.

For PostgreSQL on Ubuntu this can be done with the following commands::

sudo -u postgres psql
postgres=# create user openstack_citest with createdb login password
  'openstack_citest';
postgres=# create database openstack_citest with owner
   openstack_citest;

For MySQL on Ubuntu this can be done with the following commands::

mysql -u root
create database openstack_citest;
grant all privilleges on openstack_citest.* to
 openstack_citest@localhost identified by 'opensatck_citest';

As I said this error appeared only three weeks ago, although I'm working on
this test since 29 of April, it passed Jenkins in August without any
problems. Postgres is available there.

[1] -
https://github.com/openstack/oslo.db/blob/master/oslo/db/sqlalchemy/test_migrations.py#L277

On Fri, Sep 12, 2014 at 12:28 PM, Kevin Benton blak...@gmail.com wrote:

 Can you explain a bit about that test? I'm having trouble reproducing it.
 On the system (upstream Jenkins) that it's failing on, is postgres
 available with that database?

 On Thu, Sep 11, 2014 at 7:07 AM, Anna Kamyshnikova 
 akamyshnik...@mirantis.com wrote:

 Hello everyone!

 I'm working on implementing test in Neutron that checks that models are
 synchronized with database state [1] [2]. This is very important change as
 during Juno cycle big changes of database structure were done.

 I was working on it for rather long time but about three weeks ago
 strange error appeared [3], using AssertionPool shows [4]. The problem is
 that somehow there are more than one connection to database from each test.
 I tried to use locks from lockutils, but it didn’t help. On db meeting we
 decided to add TestCase just for one Ml2 plugin for starters, and then
 continue working on this strange error, that is why there are two change
 requests [1] and [2]. But I found out that somehow even one testcase fails
 with the same error [5] from time to time.

 I’m asking for any suggestions that could be done in this case. It is
 very important to get at least [1] merged in Juno.

 [1] - https://review.openstack.org/76520

 [2] - https://review.openstack.org/120040

 [3] - http://paste.openstack.org/show/110158/

 [4] - http://paste.openstack.org/show/110159/

 [5] -
 http://logs.openstack.org/20/76520/68/check/gate-neutron-python27/63938f9/testr_results.html.gz

 Regards,

 Ann



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




 --
 Kevin Benton

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


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

[openstack-dev] [neutron][db] Need help resolving a strange error with db connections in tests

[Anna Kamyshnikova]

Hello everyone!

I'm working on implementing test in Neutron that checks that models are
synchronized with database state [1] [2]. This is very important change as
during Juno cycle big changes of database structure were done.

I was working on it for rather long time but about three weeks ago strange
error appeared [3], using AssertionPool shows [4]. The problem is that
somehow there are more than one connection to database from each test. I
tried to use locks from lockutils, but it didn’t help. On db meeting we
decided to add TestCase just for one Ml2 plugin for starters, and then
continue working on this strange error, that is why there are two change
requests [1] and [2]. But I found out that somehow even one testcase fails
with the same error [5] from time to time.

I’m asking for any suggestions that could be done in this case. It is very
important to get at least [1] merged in Juno.

[1] - https://review.openstack.org/76520

[2] - https://review.openstack.org/120040

[3] - http://paste.openstack.org/show/110158/

[4] - http://paste.openstack.org/show/110159/

[5] -
http://logs.openstack.org/20/76520/68/check/gate-neutron-python27/63938f9/testr_results.html.gz

Regards,

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

[openstack-dev] [Neutron] Note on alembic migrations autogeneration

[Anna Kamyshnikova]

Hi everyone!

I want to pay attention for all people who use alembic --autogeneration for
creating migrations from models. Creation of foreign keys is not fully
implemented [1] so you should check carefully that your migration contain
all foreign keys your tables need.

Also I want to ask developers, who creates migrations to check that your
migration works correctly for upgrade-downgrade-upgrade cycle.

[1] -
http://alembic.readthedocs.org/en/latest/tutorial.html#auto-generating-migrations

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

Re: [openstack-dev] [Neutron] Gap 0 (database migrations) closed!

[Anna Kamyshnikova]

Hello everyone!

I would like to bring the next two points to everybody's attention:

1) As Henry mentioned if you add new migration you should make it
unconditional. Conditional migrations should not be merged since now.

2) If you add some new models you should ensure that module containing it
is imported in /neutron/db/migration/models/head.py.

The second point in important for testing which I hope will be merged soon:
https://review.openstack.org/76520.

Regards,
Ann



On Wed, Jul 16, 2014 at 5:54 AM, Kyle Mestery mest...@mestery.com wrote:

 On Tue, Jul 15, 2014 at 5:49 PM, Henry Gessau ges...@cisco.com wrote:
  I am happy to announce that the first (zero'th?) item in the Neutron Gap
  Coverage[1] has merged[2]. The Neutron database now contains all tables
 for
  all plugins, and database migrations are no longer conditional on the
  configuration.
 
  In the short term, Neutron developers who write migration scripts need
 to set
migration_for_plugins = ['*']
  but we will soon clean up the template for migration scripts so that
 this will
  be unnecessary.
 
  I would like to say special thanks to Ann Kamyshnikova and Jakub
 Libosvar for
  their great work on this solution. Also thanks to Salvatore Orlando and
 Mark
  McClain for mentoring this through to the finish.
 
  [1]
 
 https://wiki.openstack.org/wiki/Governance/TechnicalCommittee/Neutron_Gap_Coverage
  [2] https://review.openstack.org/96438
 
 This is great news! Thanks to everyone who worked on this particular
 gap. We're making progress on the other gaps identified in that plan,
 I'll send an email out once Juno-2 closes with where we're at.

 Thanks,
 Kyle

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

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

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

Re: [openstack-dev] Promoting healing script to scheme migration script?

[Anna Kamyshnikova]

Hi,

Here is a link to WIP healing script https://review.openstack.org/96438.
The idea on which it is based on is shown in this spec
https://review.openstack.org/95738.

Regards,
Ann


On Mon, Jun 9, 2014 at 7:07 PM, Johannes Erdfelt johan...@erdfelt.com
wrote:

 On Mon, Jun 09, 2014, Jakub Libosvar libos...@redhat.com wrote:
  I'd like to get some opinions on following idea:
 
  Because currently we have (thanks to Ann) WIP of healing script capable
  of changing database scheme by comparing tables in the database to
  models in current codebase, I started to think whether it could be used
  generally to db upgrades instead of generating migration scripts.

 Do you have a link to these healing scripts?

  If I understand correctly the purpose of migration scripts used to be to:
  1) separate changes according plugins
  2) upgrade database scheme
  3) migrate data according the changed scheme
 
  Since we dropped on conditional migrations, we can cross out no.1).
  The healing script is capable of doing no.2) without any manual effort
  and without adding migration script.
 
  That means if we will decide to go along with using script for updating
  database scheme, migration scripts will be needed only for data
  migration (no.3)) which are from my experience rare.
 
  Also other benefit would be that we won't need to store all database
  models from Icehouse release which we probably will need in case we want
  to heal database in order to achieve idempotent Icehouse database
  scheme with Juno codebase.
 
  Please share your ideas and reveal potential glitches in the proposal.

 I'm actually working on a project to implement declarative schema
 migrations for Nova using the existing model we currently maintain.

 The main goals for our project are to reduce the amount of work
 maintaining the database schema but also to reduce the amount of
 downtime during software upgrades by doing schema changes online (where
 possible).

 I'd like to see what other haves done and are working on the future so
 we don't unnecessarily duplicate work :)

 JE


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

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

[openstack-dev] [Neutron] Unifying DB schema

[Anna Kamyshnikova]

Hello everyone!

Earlier topic of unconditional migrations was discussed  in emails by me
and Salvatore. On summit there was a small meeting on which was discussed
this topic and some others. I haven't participated in this meeting but
member of my team Eugene was there instead of me and told me what was
decided to do.

The idea is to create some methods that will check current table state:
 - if it exists or not
 -  if all necessary changes have been made or not.
(All changes are checked from the very beginning till Icehouse)

I was inspired of this idea and make some notes about that. They are shown
there
https://docs.google.com/document/d/10p6JKIQf_rymBuNeOywjHiv53cRTfz5kBg8LeUCeykI/edit?usp=sharingand
a test change that will show  how this is going to work
https://review.openstack.org/93690.

The organizer of all this work is Henry Gessau. Now he is working on bp on
this topic.

I look forward to any comments about my notes and my test changes.

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

Re: [openstack-dev] [Neutron] Consistency between models and migrations

[Anna Kamyshnikova]

Hi!

It is nice to see so careful attention for my change requests. In fact they
are related the same topic that Johannes mentioned. The idea of this is
described there
https://blueprints.launchpad.net/neutron/+spec/db-sync-models-with-migrations
.

Problems that mentioned in https://review.openstack.org/#/c/82073/
https://review.openstack.org/#/c/80518/ were discovered with the help of
this test https://review.openstack.org/74081 that I adopted for Neutron
https://review.openstack.org/76520. It helps to find a lot of bugs in
Neutron database and models. Now as this change
https://review.openstack.org/74081 is going to move to oslo.db all of this
work is frozen.

Regards,
Ann



On Tue, May 20, 2014 at 9:02 AM, Johannes Erdfelt johan...@erdfelt.comwrote:

 On Tue, May 20, 2014, Collins, Sean sean_colli...@cable.comcast.com
 wrote:
  I've been looking at two reviews that Ann Kamyshnikova has proposed
 
  https://review.openstack.org/#/c/82073/
 
  https://review.openstack.org/#/c/80518/
 
  I think the changes are fundamentally a Good Thing™  - they appear to
  reduce the differences between the database models and their
  corresponding migrations – as well as fixing differences in the
  generated DDL between Postgres and MySQL.
 
  The only thing I'm concerned about, is how to prevent these
  inconsistencies from sneaking into the codebase in the future. The
  one review that fixes ForeignKey constraints that are missing a name
  argument which ends up failing to create indexes in Postgres – I can
  see myself repeating that mistake, it's very subtle.
 
  Should we have some sort of HACKING for database models and
  migrations? Are these problems subtle enough that they warrant
  changes to SQLAlchemy/Alembic?

 On the Nova side of things, there has been similar concerns.

 There is a nova-spec that is proposing adding a unit test to check the
 schema versus the model:

 https://review.openstack.org/#/c/85325/

 This should work, but I think the underlying problem is DRY based. We
 should not need to declare a schema in a model and then a set of
 imperative tasks to get to that point. All too often they get
 unsynchronized.

 I informally proposed a different solution, moving schema migrations to
 a declarative model. I wrote a proof of concept to show how something
 like this would work:

 https://github.com/jerdfelt/muscle

 We already have a model written (but need some fixes to make it accurate
 wrt to existing migrations), we should be able to emit ALTER TABLE
 statements based on the existing schema to bring it into line with the
 model.

 This also has the added benefit of allowing certain schema migrations to
 be done online, while services are still running. This can significantly
 reduce downtime during deploys (a big concern for large deployments of
 Nova).

 There are some corner cases that do cause problems (renaming columns,
 changing column types, etc). Those can either remain as traditional
 migrations and/or discouraged.

 Data migrations would still remain with sqlalchemy-migrate/alembic, but
 there have some proposals about solving that problem too.

 JE


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

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

Re: [openstack-dev] [Neutron] Database migrations meeting at summit

[Anna Kamyshnikova]

Hi!

It is great idea to organize such meeting. Unfortunately I can't
participate in it as I'm not going to summit, but members of my team Oleg
Bondarev and Eugene Nikanorov will be there. They should be up to speed on
my current developments. I hope that they will be able to come to meeting
and discuss problems that I faced.

Also I added commit messages to my test change requests for unconditional
migrations topic. It will help to understand what options I tried to
research in them.

Regards,
Ann


On Thu, May 8, 2014 at 11:57 PM, Henry Gessau ges...@cisco.com wrote:

 Several developers are working on different aspects of Neutron DB
 migration.
 I thought it would be good to have a meeting at the summit where we can
 discuss the issues and come closer to converging on a solution.

 I was thinking maybe a time on Tuesday or Thursday afternoon would work. I
 have created an etherpad [1] where I have tried to accumulate the emails,
 bugs, bps and code proposals. If you are interested in meeting please add
 your name to the etherpad.

 Also please add any missing notes/references to the etherpad.

 [1] https://etherpad.openstack.org/p/neutron-db-migrations

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

Re: [openstack-dev] [Neutron] Run migrations for service plugins every time

[Anna Kamyshnikova]

Salvatore,

Thanks for your answer. I was on holidays, so I clearly read your response
just now.

As I understand from your comments there is no reason for me to continue
working on making migrations run unconditionally for service plugins.
Making all migrations run unconditionally based on current state of
database will be rather long process, because I'll have to find out which
tables are in database for each plugin and then create migration that will
recreate them, if they won't exist.

While I was working on this change https://review.openstack.org/87935 I
researched different opportunities how to check database state without
breaking offline migrations. The only suggestion is to use op.execute() and
SQL statement 'CREATE TABLE IF NOT EXIST'. The problem with that is that if
table uses enum type it can't be done for PostgreSQL. I described this
problem in earlier mail with topic 'Fix migration that breaks Grenade jobs'

If we won't care about offline migrations this could be done by rerunning
some migrations or recreating some tables, if running the whole migration
is not reliable.

Regards,
Ann


On Wed, Apr 30, 2014 at 6:03 PM, Salvatore Orlando sorla...@nicira.comwrote:

 Anna,

 It's good to see progress being made on this blueprint.
 I have some comments inline.

 Also, I would recommend keeping in mind the comments Mark had regarding
 migration generation and plugin configuration in hist post on the email
 thread I started.

 Salvatore


 On 30 April 2014 14:16, Anna Kamyshnikova akamyshnik...@mirantis.comwrote:

 Hi everyone!

 I'm working on blueprint
 https://blueprints.launchpad.net/neutron/+spec/neutron-robust-db-migrations.
 This topic was discussed earlier by Salvatore in ML thread Migrations,
 service plugins and Grenade jobs. I'm researching how to make migrations
 for service plugins run unconditionally. In fact it is enough to change
 should_run method for migrations -  to make it return True if this
 migration is for service plugin
 https://review.openstack.org/#/c/91323/1/neutron/db/migration/__init__.py
 .


 I think running migrations unconditionally for service plugins is an
 advancement but not yet a final solution.
 I would insist on the path you've been pursuing of running unconditionally
 all migrations. We should strive to solve the issues you found there so far


 It is almost working except for conflicts of VNPaaS service plugin with
 Brocade and Nuage plugins http://paste.openstack.org/show/77946/.
 1) Migration for Brocade plugin fails, because 2c4af419145b_l3_support
 doesn't run (it adds necessary table 'routers') It can be fixed by adding
 Brocade plugin to list migration_for_plugins in 2c4af419145b_l3_support.

 2) Migration for Nuage plugin fails, because e766b19a3bb_nuage_initial
 runs after 52ff27f7567a_support_for_vpnaas, and there is no necessary table
 'routers'.  It can be fixed by adding Nuage plugin to list
 migration_for_plugins in 2c4af419145b_l3_support and removing addition of
 these tables in e766b19a3bb_nuage_initial.

 I noticed that too in the past.
 However there are two aspects to this fix. The one you're mentioning is
 for fixing migrations in new deployments; on the other hand migrations
 should be fixed also for existing deployments. This kind of problem seems
 to me more concerning the work for removing schema auto-generation. Indeed
 the root problem here is probably that l3 schemas for these two plugins are
 being created only because of schema auto-generation.

 Also I researched opportunity to make all migrations run unconditionally,
 but this could not be done as there is going to be a lot of conflicts
 http://paste.openstack.org/show/77902/. Mostly this conflicts take place
 in initial migrations for core plugins as they create basical tables that
 was created before. For example, mlnx_initial create tables securitygroups,
 securitygroupportbindings, networkdhcpagentbindings, portbindingports that
 were already created in 3cb5d900c5de_securitygroups,
 4692d074d587_agent_scheduler, 176a85fc7d79_add_portbindings_db migrations.
 Besides I was thinking about 'making migrations smart' - to make them check
 whether all necessary migrations has been run or not, but the main problem
 about that is we need to store information about applied migrations, so
 this should have been planned from the very beginning.


 I agree that just changing migrations to run unconditionally is not a
 viable solution.
 Rather than changing the existing migration path, I was thinking more
 about adding corrective unconditional migrations to make the database
 state the same regardless of the plugin configuration. The difficult part
 here is that these migrations would need to be smart enough to understand
 whether a previous migration was executed or skipped; this might also break
 offline migrations (but perhaps this might be tolerable).

 I look forward for any suggestions or thoughts on this topic.

 Regards, Ann

[openstack-dev] [Neutron] Run migrations for service plugins every time

[Anna Kamyshnikova]

Hi everyone!

I'm working on blueprint
https://blueprints.launchpad.net/neutron/+spec/neutron-robust-db-migrations.
This topic was discussed earlier by Salvatore in ML thread Migrations,
service plugins and Grenade jobs. I'm researching how to make migrations
for service plugins run unconditionally. In fact it is enough to change
should_run method for migrations -  to make it return True if this
migration is for service plugin
https://review.openstack.org/#/c/91323/1/neutron/db/migration/__init__.py.
It is almost working except for conflicts of VNPaaS service plugin with
Brocade and Nuage plugins http://paste.openstack.org/show/77946/.
1) Migration for Brocade plugin fails, because 2c4af419145b_l3_support
doesn't run (it adds necessary table 'routers') It can be fixed by adding
Brocade plugin to list migration_for_plugins in 2c4af419145b_l3_support.
2) Migration for Nuage plugin fails, because e766b19a3bb_nuage_initial runs
after 52ff27f7567a_support_for_vpnaas, and there is no necessary table
'routers'.  It can be fixed by adding Nuage plugin to list
migration_for_plugins in 2c4af419145b_l3_support and removing addition of
these tables in e766b19a3bb_nuage_initial.

Also I researched opportunity to make all migrations run unconditionally,
but this could not be done as there is going to be a lot of conflicts
http://paste.openstack.org/show/77902/. Mostly this conflicts take place in
initial migrations for core plugins as they create basical tables that was
created before. For example, mlnx_initial create tables securitygroups,
securitygroupportbindings, networkdhcpagentbindings, portbindingports that
were already created in 3cb5d900c5de_securitygroups,
4692d074d587_agent_scheduler, 176a85fc7d79_add_portbindings_db migrations.
Besides I was thinking about 'making migrations smart' - to make them check
whether all necessary migrations has been run or not, but the main problem
about that is we need to store information about applied migrations, so
this should have been planned from the very beginning.

I look forward for any suggestions or thoughts on this topic.

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

[openstack-dev] [Neutron] Fix migration that breaks Grenade jobs

[Anna Kamyshnikova]

Hello everyone!

I'm working on fixing bug 1307344. I found out solution that will fix
Grenade jobs and will work for online and offline migartions.
https://review.openstack.org/87935 But I faced the problem that Metering
usage won't be fixed as we need to create 2 tables (meteringlabels,
meteringlabelrules). I tried to create both in patch set #7 but it won't
work for offline migration. In fact to fix Grenade it is enough to create
meteringlabels table, that is done in my change in the last patch set #8. I
want to ask reviewers to take a look at this change and suggest something
or approve it. I'm available on IRC(akamyshnikova) or by email.

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

Re: [openstack-dev] Neutron Migrations, service plugins and Grenade jobs

[Anna Kamyshnikova]

Hello everyone!

I would like to try to solve this problem. I registered blueprint on this
topic
https://blueprints.launchpad.net/neutron/+spec/neutron-robust-db-migrationsand
I'm going to experiment with options to solve this. I'm welcome any
suggestions and ready to talk about it via IRC (akamyshnikova).

Regards
Ann


On Mon, Apr 14, 2014 at 9:39 PM, Sean Dague s...@dague.net wrote:

 On 04/14/2014 12:46 PM, Eugene Nikanorov wrote:
  Hi Salvatore,
 
  The described problem could be even worse if vendor drivers are
 considered.
  Doesn't #1 require that all DB tables are named differently? Otherwise
  it seems that user can't be sure in DB schema even if all tables are
  present.
 
  I think the big part of the problem is that we need to support both
  online and offline migrations. Without the latter things could be a
  little bit simpler.
 
  Also it seems to me that problem statement should be changed to the
  following:
  One need to migrate from (Config1, MigrationID1) to (Config2,
  MigrationID2), and currently our code only accounts for MigrationIDs.
  We may consider amending DB with configuration metadata, at least that
  will allow to run migration code with full knowledge of what happened
  before (if online mode is considered).
  In offline mode that will require providing old and current
 configurations.
 
  That was just thinking aloud, no concrete proposals yet.

 The root issue really is Migrations *must* be global, and config
 invariant. That's the design point in both sqlalchemy-migrate and
 alembic. The fact that there is one global migrations table per
 database, with a single value in it, is indicative of this fact.

 I think that design point got lost somewhere along the way, and folks
 assumed migrations were just a way to change schemas. They are much more
 constrained than that.

 It does also sound like the data model is going to need some serious
 reconsidering given what's allowed to be changed at the plugin or vendor
 driver model. Contrast this with Nova, were virt drivers don't get to
 define persistant data that's unique to them (only generic data that
 they fit into the grander nova model).

 The one time we had a driver which needed persistent data (baremetal) it
 managed it's own database entirely.

 -Sean

 --
 Sean Dague
 Samsung Research America
 s...@dague.net / sean.da...@samsung.com
 http://dague.net


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


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

[openstack-dev] [tempest] Bluiprint for improvement neutron test coverage

[Anna Kamyshnikova]

Hello!

I'm amoung people who are working on improvement neutron test coverage.
Over work is cooperating on etherpad page
https://etherpad.openstack.org/p/icehouse-summit-qa-neutron. Meanwhile some
reviewers ask for blueprint or bug report to be associated with change.
That's why I created this blueprint
https://blueprints.launchpad.net/tempest/+spec/improve-neutron-test-coverage.
So everybody who has the same questions can use link to this blueprint in
his commit message (partially implement bp: improve-neutron-test-coverage).
It is not necessary if you has good progress on your change and do not want
to change commit message. This also could help to avoid duplication in work
that sometimes happens.

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

Re: [openstack-dev] [tempest] negative tests

[Anna Kamyshnikova]

Hello!

I'm working on creating tests in tempest according to this etherpad page
https://etherpad.openstack.org/p/icehouse-summit-qa-neutron.

Here is mentioned that we should be add negative tests, for example, for
floating ips, but as I understand (according to comment to
https://bugs.launchpad.net/bugs/1262113) negative tests will be added
automatically. In this case, is work on such tests as
- Negative: create a floating ip specifying a non public network
- Negative: create a floating ip specifying a floating ip address out of
the external network subnet range

- Negative: create a floating ip specifying a floating ip address that is
in use

- Negative: create / update a floating ip address specifying an invalid
internal port

- Negative: create / update a floating ip address specifying an internal
port with no ip address

- Negative: create / update a floating ip with an internal port with
multiple ip addresses, specifying an invalid

- Negative create /assciate a floating ip with an internal port with
multiple ip addresses, when the ip address

- Negative: delete an invalid floating ip

- Negative: show non existing floating ip
 needed or not?

Ann.


On Mon, Dec 23, 2013 at 2:56 PM, Sean Dague s...@dague.net wrote:

 Please take this to a public list

 On 12/23/2013 03:42 AM, Anna Kamyshnikova wrote:
  Hello!
 
  I'm working on creating tests in tempest according to this etherpad
  page https://etherpad.openstack.org/p/icehouse-summit-qa-neutron.
 
  Here is mentioned that we should be add negative tests, for example, for
  floating ips, but as I understand (according to your comment
  to https://bugs.launchpad.net/bugs/1262113) negative tests will be added
  automatically. In this case, is work on such tests as
  - Negative: create a floating ip specifying a non public network
  - Negative: create a floating ip specifying a floating ip address out of
  the external network subnet range
 
  - Negative: create a floating ip specifying a floating ip address that
  is in use
 
  - Negative: create / update a floating ip address specifying an invalid
  internal port
 
  - Negative: create / update a floating ip address specifying an internal
  port with no ip address
 
  - Negative: create / update a floating ip with an internal port with
  multiple ip addresses, specifying an invalid
 
  - Negative create /assciate a floating ip with an internal port with
  multiple ip addresses, when the ip address
 
  - Negative: delete an invalid floating ip
 
  - Negative: show non existing floating ip
 
   needed or not?
 
  Ann.


 --
 Sean Dague
 http://dague.net


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