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

[Korzeniewski, Artur]

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

From: Miguel Angel Ajo Pelayo [mailto:majop...@redhat.com]
Sent: Wednesday, November 29, 2017 8:47 PM
To: OpenStack Development Mailing List (not for usage questions) 

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

"+1" I know, I'm not active, but I care about neutron, and slaweq is a great 
contributor.

On Nov 29, 2017 8:37 PM, "Ihar Hrachyshka" 
> wrote:
YES, FINALLY.

On Wed, Nov 29, 2017 at 11:29 AM, Kevin Benton 
> wrote:
> +1! ... even though I haven't been around. :)
>
> On Wed, Nov 29, 2017 at 1:21 PM, Miguel Lavalle 
> > wrote:
>>
>> Hi Neutron Team,
>>
>> I want to nominate Slawek Kaplonski (irc: slaweq) to Neutron core. Slawek
>> has been an active contributor to the project since the Mitaka cycle. He has
>> been instrumental in the development of the QoS capabilities in Neutron,
>> becoming the lead of the sub-team focused on that set of features. More
>> recently, he has collaborated in the implementation of OVO and is an active
>> participant in the CI sub-team. His number of code reviews during the Queens
>> cycle is on par with the leading core members of the team:
>> http://stackalytics.com/?module=neutron
>>
>> In my opinion, his efforts are highly valuable to the team and we will be
>> very lucky to have him as a fully voting core.
>>
>> I will keep this nomination open for a week as customary,
>>
>> Thank you,
>>
>> Miguel
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: 
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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

Re: [openstack-dev] [neutron] - Neutron team social in Atlanta on Thursday

[Korzeniewski, Artur]

+1

From: Kevin Benton [mailto:ke...@benton.pub]
Sent: Friday, February 17, 2017 8:19 PM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [neutron] - Neutron team social in Atlanta on Thursday

Hi all,

I'm organizing a Neutron social event for Thursday evening in Atlanta somewhere 
near the venue for dinner/drinks. If you're interested, please reply to this 
email with a "+1" so I can get a general count for a reservation.

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

Re: [openstack-dev] [Neutron] Neutron team social event in Barcelona

[Korzeniewski, Artur]

+1

From: Oleg Bondarev [mailto:obonda...@mirantis.com]
Sent: Monday, October 17, 2016 9:52 AM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [Neutron] Neutron team social event in Barcelona

+1

On Mon, Oct 17, 2016 at 10:23 AM, Jakub Libosvar 
> wrote:
+1


On 14/10/2016 20:30, Miguel Lavalle wrote:
Dear Neutrinos,

I am organizing a social event for the team on Thursday 27th at 19:30.
After doing some Google research, I am proposing Raco de la Vila, which
is located in Poblenou: http://www.racodelavila.com/en/index.htm. The
menu is here: http://www.racodelavila.com/en/carta-racodelavila.htm

It is easy to get there by subway from the Summit venue:
https://goo.gl/maps/HjaTEcBbDUR2. I made a reservation for 25 people
under 'Neutron' or "Miguel Lavalle". Please confirm your attendance so
we can get a final count.

Here's some reviews:
https://www.tripadvisor.com/Restaurant_Review-g187497-d1682057-Reviews-Raco_De_La_Vila-Barcelona_Catalonia.html

Cheers

Miguel

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


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

__
OpenStack Development Mailing 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][ovo] Need help to understand the exception of NeutronSyntheticFieldMultipleForeignKeys

[Korzeniewski, Artur]

Hi,
So in the first place, you do not need the multiple foreign keys in Flavor db 
use case. 
You can only declare flavor_id and service_profile_id in 
FlavorServiceProfileBinding object, since the relationships ('flavor' and 
'service_profile') is not used anywhere, only ids.

Secondly, nobody right now is working on improving the situation. I have two 
ideas how to fix it:
The example:
{
'network_id': 'id', 
'agent_id': id
}

1) add a name of object to the value ('id' i.e.)
{
'network_id': 'Network.id', 
'agent_id': 'Agent.id'
}
It would be kind of complicated to get this used in [1], where the foreign keys 
are accessed

2) get deeper structure like:
{
'Network': {'network_id': 'id'},
'Agent': {'agent_id': id}
}
It looks better, because you just add proper foreign key under the related 
object name. Then you can proceed without any issues in [1], just grab the 
proper object name value as dictionary of single foreign key, you can check the 
[2] to see how it should look like for second option.

Regards,
Artur

[1] 
https://github.com/openstack/neutron/blob/9.0.0.0b2/neutron/objects/base.py#L433
[2] https://review.openstack.org/#/c/357207
-Original Message-
From: taget [mailto:qiaoliy...@gmail.com] 
Sent: Thursday, August 18, 2016 5:08 AM
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Cc: Qiao, Liyong <liyong.q...@intel.com>; Bhatia, Manjeet S 
<manjeet.s.bha...@intel.com>; Korzeniewski, Artur <artur.korzeniew...@intel.com>
Subject: [neutron][ovo] Need help to understand the exception of 
NeutronSyntheticFieldMultipleForeignKeys

hi neutron ovo hacker:

Recently I am working on neutron OVO blue print, and found there are some 
blocking (slow progress) issues when tring to add new object to Neutron.

When I try to add Flavor related object on [1], I need to add 2 foreign_keys to 
FlavorServiceProfileBinding :

flavor_id: Flavor.id
service_profile_id: ServiceProfile.id

For ServiceProfile and Flavor object, FlavorServiceProfileBinding is a 
synthetic_fields, we refer FlavorServiceProfileBinding in [2], but in currently 
object base implementation, we only allow synthetic_fields to only have 1 
foreignkeys[3].

can anyone help to clarify this? or give some guide on how to overcome [1]? If 
there's anyone who working on to fix it too?


P. S There are other use case for multiple foreign keys [4]
[1]https://review.openstack.org/#/c/306685/6/neutron/db/flavor/models.py@45
[2]https://github.com/openstack/neutron/blob/9.0.0.0b2/neutron/db/flavors_db.py#L86
[3]https://github.com/openstack/neutron/blob/9.0.0.0b2/neutron/objects/base.py#L429-L430
[4]https://review.openstack.org/#/c/307964/20/neutron/objects/router.py@33

-- 
Best Regards,
Eli Qiao (乔立勇), Intel OTC.

__
OpenStack Development Mailing 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][upgrades] Bi-weekly upgrades work status. 8/2/2016

[Korzeniewski, Artur]

Hi Neutrinos,
As we are progressing with object implementation for neutron database 
resources, I would like to summarize the status.

Please find the etherpad as up-to-date work status on object progress, TODOs/In 
progress/Done items:
https://etherpad.openstack.org/p/newton-ovo-progress
This etherpad should collect all the work that need to be done to address the 
objectification. Please add any items that you see are missing.

1. Object implementation
Since last report, we have manage to merge following patches:
- Allow unique keys to be used with get_object 
https://review.openstack.org/322024
- objects: loading synthetic fields from defined ORM relationships. 
https://review.openstack.org/334380
- objects: better apply filters for objects/db/api/get_object query. 
https://review.openstack.org/334381
- objects: Add update_fields method in base class. 
https://review.openstack.org/337539
- objects: Add RBAC to Subnet OVO https://review.openstack.org/337634
- objects: Adjust Subnet fields, add tenant_id and segment_id 
https://review.openstack.org/331009
- objects: introduce NetworkPortSecurity object 
https://review.openstack.org/327257
- trunk: avoid redundant refetch of subports on create 
https://review.openstack.org/348396
- tests: enable test_get_objects_queries_constant for trunk ports 
https://review.openstack.org/348378

Please check for following patches that are still under review:
- Introduces ovo objects for security groups https://review.openstack.org/284738
- objects: forbid updates for project_id field for subnets 
https://review.openstack.org/#/c/347787
- SUPER WIP OVO port object https://review.openstack.org/253641
- objects: expose database model for NeutronDbObject instances 
https://review.openstack.org/#/c/348279
- objects: remove support for multiple db models in from_db_object 
https://review.openstack.org/#/c/348271
- WIP: get_subnet(s), update, delete converted in db_base_plugin - 
https://review.openstack.org/#/c/321001/
- devref: docs about how to use NeutronDbObject. 
https://review.openstack.org/336518
- Print out specific filter that failed in object filtering unit test 
https://review.openstack.org/#/c/347884/


2. About object integration in neutron base code:
Tenant_id to project_id approach in objects:
For object implementation, we expose both project_id and tenant_id, but only 
the project_id is regular field in object 'fields' property. The tenant_id is 
declared (in automated manner for every object that has project_id [3]) as 
read-only value, available in to_dict() and in dictionary access to the objects 
fields. It does not appear in obj_to_primitive() method, so for example the 
tenant_id would not be sent over the RPC callback wire.
Currently, we are performing the automated translation from tenant_id to 
project_id when fetching the data from DB [4]. When the tenant_id column would 
be renamed into project_id, it would not have any effect on object 
implementation, the [4] would be not used and can be removed, but from object 
user perspective, nothing will change. There still will be tenant_id access [3] 
so we will be backward compatible.
When talking about REST API to OVO passing filters, we should be able to handle 
both tenant_id and project_id for filtering. Current approach is to translate 
the tenant_id to project_id in filters before passing it to get_objects() 
method [5][6]

REST API filtering:
I have encounter the problem when passing any random string as filters from 
REST API to get_objects OVO implementation [7]. At object layer, we do not 
accept unknown filters and errors out. The general approach should be to handle 
it at API level, to pass to plugins only valid filters. Current way to handle 
it is to remove all unknown filters in DB layer, just before passing the 
filters to get_objects() (work TBD).

Extensions and object implementation:
Replacing direct access to DB by OVO means that every extension fields should 
be declared in object definition, in order to include the data in the object 
structure and fetch the data from DB . In-tree extensions can be done in using 
OVO, like synthetic field, field that is loaded from other place in DB than 
current object DB model.
That situation can be extremely difficult for out of tree plugins/drivers that 
are extending the neutron resource like port, subnet, network. Since dropping 
the support for them is not possible, we will have DB model as an object field 
and we will pass it in make__dict and extension functions, just like 
it is done today. [10][11]

Returning all object fields for QoS and trunk port in REST API:
Current implementation for QoS and trunk port API is returning all object 
fields in REST API [8][9]. We need to limit the info return to the API 
consumer, because the internal data is leaking like revision number of DB 
state. This work is TBD.

Circular import issue:
To break the circular dependency when implementing the OVO in db classes that 
are having the model and mixin 

[openstack-dev] [neutron][api] Passing random filters on neutron API calls

[Korzeniewski, Artur]

Hi all,
During integration of Subnet OVO into db code get_subnet/update_subnet/delete 
[1], I have found and issue in API behavior and strict object implementation 
for NeutronDbObject base class.

The issue is that on REST API level, you can pass random filters and it will 
not affect the result set.
But in object implementation, we are checking if filters passed to get_objects 
is valid field declared in object. If it does not exists, we error out [2]:
"Invalid input for operation: 'admin_state_up' is not supported for filtering."

So the question is: should we return error from object to API level that filter 
passed in GET request is invalid?
In my opinion we should not allow random strings to be passed as filters...


Regards,
Artur Korzeniewski
IRC: korzen

[1] https://review.openstack.org/#/c/321001
[2] 
http://logs.openstack.org/01/321001/11/check/gate-neutron-dsvm-api/98d056e/console.html#_2016-07-27_14_47_10_906641

__
OpenStack Development Mailing 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][upgrades] Bi-weekly upgrades work status. 7/11/2016

[Korzeniewski, Artur]

Hi,
Starting another round of bi-weekly update presented once in a 3-week time 
period.

Let's kick it:


1.   We are still working on porting existing resources to use OVO
What was merged:

-  objects: Introduce the DNSNameServer OVO in the code: 
https://review.openstack.org/326477

-  Refactor NetworkDhcpAgentBinding: https://review.openstack.org/328452

Still a hot topic for reviews:

-  Introduces ovo objects for security groups 
https://review.openstack.org/284738

-  objects: Adjust Subnet fields, add tenant_id and segment_id 
https://review.openstack.org/331009

-  objects: Add RBAC to Subnet OVO https://review.openstack.org/337634

-  objects: Add update_fields method in base class. 
https://review.openstack.org/337539

-  objects: better apply filters for objects/db/api/get_object query. 
https://review.openstack.org/334381

-  objects: loading synthetic fields from defined ORM relationships. 
https://review.openstack.org/334380

-  Allow unique keys to be used with get_object 
https://review.openstack.org/322024


During integration of subnet object, new requirement has been identified - 
increasing the number of objects should not influence on number of queries to 
DB. Current implementation of objects in neutron handles relationship by 
loading each required subobject with another query. But when using query 
formatting from common_db_mixin code, there is no need to load the related 
object (called synthetic fields in NeutronDbObject), since they are already 
fetch with main object. The patch


During integration of subnet object, I have found a requirement to use only one 
sql query with usage of side-loaded relationship objects, in order to fulfill 
the performance goals and not to query the DB too often when number of 
resources is increasing.
This means, when we load the object with standard sql query using 
common_db_mixin code, there is no need to load the related object (called 
synthetic fields in NeutronDbObject), since they are already fetch with main 
object.

Please remember the port object, which is still in WIP phase:

-  SUPER WIP OVO port object https://review.openstack.org/253641

Besides the above resources, we have other database models ported to OVO in 
review queue:

-  Flavor and Service Profile to OVO 
https://review.openstack.org/306685/

-  Service Type to OVO https://review.openstack.org/304322

-  DistributedVirtualRouter mac address to OVO 
https://review.openstack.org/304873

-  Agent to OVO https://review.openstack.org/297887

-  objects: introduce NetworkPortSecurity object 
https://review.openstack.org/327257

-  Add OVO for dns Objects https://review.openstack.org/334695

-  Introduce OVO for quotas https://review.openstack.org/338625

Also an important requirement for introducing objects is refactoring to break 
the circular dependency issue, patches:

-  Refactoring Agent DB model https://review.openstack.org/330870/

-  Also the blueprint: https://bugs.launchpad.net/neutron/+bug/1597913

Regarding API test coverage and support for sorting/pagination, following 
changes are on stage:

-  Document sorting/pagination extension existence: 
https://review.openstack.org/330058/

-  Added API extensions to detect sorting/pagination features 
https://review.openstack.org/329474/

-  Enable sorting and pagination by default: 
https://review.openstack.org/329481/

-  https://review.openstack.org/330482/
Please review the above patches.


2.   Grenade multinode gate status

a.   Experimental job for LinuxBridge: https://review.openstack.org/336793

b.  Make gate-grenade-dsvm-neutron-dvr-multinode voting: 
https://review.openstack.org/#/c/336116






===



Team info:

Upgrades Subteam has the weekly meetings on Mondays, 3PM UTC, wiki page: 
https://wiki.openstack.org/wiki/Meetings/Neutron-Upgrades-Subteam



New patches are generally tracked under the following topic: 
https://review.openstack.org/#/q/topic:bp/adopt-oslo-versioned-objects-for-db

Cheers,
Artur




















__
OpenStack Development Mailing 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][upgrades] Bi-weekly upgrades work status. 6/2/2016

[Korzeniewski, Artur]

Hi Neutrinos,

I would like to start the first bi-weekly upgrades work report.



TLDR:

In order to inform community what is going on in upgrades field, we would like 
to start bi-weekly reporting. We would like to show progress in database 
resource transition to Oslo VersionedObjects. Also list of code refactoring 
places will be provided. Community members can take a look at the list and see 
if their work is not conflicting with upgrades effort.



General approach:

During Mitaka release cycle, we have started the journey to port database 
resources to Oslo VersionedObject (OVO). As first, we have chosen the Port, 
Subnet and Network resources. As the process is very complicated, we have 
divided the work to first define interface object, and then work on integration 
patches in core Neutron code. The NeutronDbObject base class is still evolving, 
and we have spent the Mitaka release cycle on working on solid base, in order 
to reuse the code for all derived classes.

We are still working on basic OVO integration, so any help in getting the work 
done would be appreciated. For detailed info, please take a look at below list.

We would like to finish already started patches, priority has the Port, Subnet 
and Network objects. If you want to contribute and port new objects to OVO, 
please prepare object implementation and some usage in core Neutron code. In 
order to see which object is already covered, please take a look at below list 
of existing patches.





I would like to remind that agreed approach at Design Summit in Austin was, 
that every new resource added to neutron should have OVO implemented. Please 
comply, and core reviewers please take care of this requirements in patches you 
review.





The effort to move all database resources to Oslo VersionedObject will 
contribute to block offline contracting migration in Ocata release. In Newton 
cycle we would like to have our last offline data migration.





Objects merged:

Subnetpool https://review.openstack.org/275789

Subnet https://review.openstack.org/264273

Port extension: Allowed address pairs https://review.openstack.org/268274/

Port extension: Extra DHCP opt https://review.openstack.org/273072/

Port extension: Port allowed address pairs https://review.openstack.org/268274

Port extension: Port security https://review.openstack.org/292178

OVO for VLAN aware VMs: https://review.openstack.org/310410





Objects under review:

Network https://review.openstack.org/269658

Port https://review.openstack.org/253641

Port extension: security groups https://review.openstack.org/284738

Agent  https://review.openstack.org/297887

Route, RoutePort and RouterRoute https://review.openstack.org/307964

DistributedVirtualRouter mac address https://review.openstack.org/304873/

Service Type: https://review.openstack.org/304322

Flavor and Service Profile https://review.openstack.org/306685





Integration patches merged:

Integrate the port allowed address pairs VersionedObject in Neutron 
https://review.openstack.org/287756

Integrate the Extra Dhcp Opt VersionedObject in Neutron 
https://review.openstack.org/285397



Integration patches Under development:

Subnet OVO https://review.openstack.org/321001

Identified usages of Subnet:
* main integration with db_base_plugin and ml2 plugin
* DHCP RPC usage
* IPAM usage
* dvr_mac_db.py
* l3_db.py
* extraroute_db.py

Subnetpool usage: https://review.openstack.org/300056

Replace plugin class for address scope ovo https://review.openstack.org/308005





Testing:

The API tests for sorting/pagination has been added for port and network

https://review.openstack.org/306272

https://review.openstack.org/320980

More tests are needed for resources that use sorting/pagination on API level.

Testing in gate has been covered in multinode Grenade jobs, one for legacy 
scenario, and the other DVR.





Improvements for NeutronDbObject:
* Merged: objects: support advanced criteria for get_objects: 
https://review.openstack.org/300055
* Merged: Standard attributes are automagically added to all relevant 
neutron resources in object's base class
* objects: stop using internal _context attribute 
https://review.openstack.org/283616
* Allow unique keys to be used with get_object 
https://review.openstack.org/322024
* qos: support advanced sorting/pagination criteria 
https://review.openstack.org/318251/





TODOs:
1.   Help in review and code development for already existing patches.
2.   Add integration patches for objects: network, port, router, agent, 
service type...
3.   Add more API tests for resources: subnets, routers, all the resource 
supporting sorting/pagination on API level
4.   Add usages of SQLAlchemy decorator classes (MAC Address, IP Address, 
CIDR) in SQL schema.
5.   Improve Grenade coverage for DHCP, L3 and DVR upgrade tests.
6.   Add objects for not yet covered database 

Re: [openstack-dev] [neutron][ovo] NeutronDbObject concurrency issues

[Korzeniewski, Artur]

Hi Ilya,
Thanks for investigating the concurrency issue. It is indeed a problem from 
multithreaded neutron-server point of view.

Regarding the opt.2, there is ongoing work to add the revision number[1] to 
main neutron resources (port, network, subnet...) This is connected to spec [2] 
and Launchpad bug [3]: push all object changes as AMQP notifications. I think 
[1] is implementing part of your idea about version number. If version number 
will be added to standard attributes table, it will automagically appear as a 
new field in object.

What is left to be done in opt.2 is to handle situation when object is trying 
to update the state and the revision is not the latest. Then, the object should 
before update() fetch the current state and try to merge the requested changes 
to the current state of the object, and then apply it in the DB. Also it would 
send the newest object state via AMQP notification, obsoleting the previous 
configuration.

We can also check how nova is handling the concurrency issue in their OVO usage 
model.

Regards,
Artur
IRC: korzen

[1] https://review.openstack.org/#/c/303966/11
[2] https://review.openstack.org/#/c/225995
[3] https://bugs.launchpad.net/neutron/+bug/1516195

-Original Message-
From: Ilya Chukhnakov [mailto:ichukhna...@mirantis.com] 
Sent: Thursday, May 12, 2016 8:26 PM
To: OpenStack Development Mailing List 
Subject: [openstack-dev] [neutron][ovo] NeutronDbObject concurrency issues

Hi everyone.

I’ve recently found that straightforward use of NeutronDbObject is prone to 
concurrency-related problems.

I’ve submitted a patch set [3] with some tests to show that without special 
treatment using NeutronDbObject could lead to unexpected results.

Further patch sets will provide acquire_object/acquire_objects contextmanager 
methods to the NeutronDbObject class. These methods are to be used in place of 
get_object/get_objects whenever the user intends to make changes to the object.
These methods would start an autonested_transaction.

There are (at least) two potential options for the implementation:

1. Based on the DB locks (e.g. SELECT FOR UPDATE/SqlAlchemy with_for_update).

   pros:
 - the object is guaranteed to not be changed while within the context

   cons:
 - prone to deadlocks ([1] and potentially when locking multiple objects)

2. Lock-free CAS based on object version counter. Can use SqlAlchemy version
   counter [2] or add our own. If conflicting changes are detected upon exiting
   the context (i.e. version counter held differs from the one in the DB), will
   raise OSLO RetryRequest exception.

   pros:
 - does not require locking

   cons:
 - require an additional field in the models

While opt.2 only prevents the conflicting changes, but does not guarantee that 
the object does not change while within the context, opt.1 may seem 
preferential. But even with opt.1 the user should not expect that the changes 
made to the object while within the context will get to the database as the 
autonested_transaction could fail on flush/commit.

So I’d like to hear others’ opinion on the problem and which of the two 
implementation options would be preferred? Or maybe someone has a better idea.

[1] 
https://wiki.openstack.org/wiki/OpenStack_and_SQLAlchemy#MySQLdb_.2B_eventlet_.3D_sad
[2] http://docs.sqlalchemy.org/en/rel_0_9/orm/versioning.html

[3] https://review.openstack.org/#/c/315705/

--
Thanks,
Ilya
__
OpenStack Development Mailing 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] Social at the summit

[Korzeniewski, Artur]

Sign me up :)

Artur
IRC: korzen

-Original Message-
From: Darek Smigiel [mailto:smigiel.dari...@gmail.com] 
Sent: Monday, April 25, 2016 7:19 PM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [neutron] Social at the summit

Count me in!
Will be good to meet all you guys!

Darek (dasm) Smigiel

> On Apr 25, 2016, at 12:13 PM, Doug Wiegley  
> wrote:
> 
> 
>> On Apr 25, 2016, at 12:01 PM, Ihar Hrachyshka  wrote:
>> 
>> WAT???
>> 
>> It was never supposed to be core only. Everyone is welcome!
> 
> +2
> 
> irony intended.
> 
> Socials are not controlled by gerrit ACLs.  :-)
> 
> doug
> 
>> 
>> Sent from my iPhone
>> 
>>> On 25 Apr 2016, at 11:56, Edgar Magana  wrote:
>>> 
>>> Would you extend it to ex-cores?
>>> 
>>> Edgar
>>> 
>>> 
>>> 
>>> 
 On 4/25/16, 10:55 AM, "Kyle Mestery"  wrote:
 
 Ihar, Henry and I were talking and we thought Thursday night makes sense 
 for a Neutron social in Austin. If others agree, reply on this thread and 
 we'll find a place.
 
 Thanks!
 Kyle
 
 ___
 ___ OpenStack Development Mailing List (not for usage 
 questions)
 Unsubscribe: 
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> 
>>> __ OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: 
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 
>> _
>> _ OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: 
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> __
>  OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

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

Re: [openstack-dev] [nova][neutron][upgrade] Grenade multinode partial upgrade - Nova metadata failure

[Korzeniewski, Artur]

Hi,
I have re-spin the grenade multimode dvr config [1].

In my understanding, this job would install multinode environment, with L3 
agent and metadata agent running on subnode.
Also to take advantage of this setup:
a) Grenade tests should create DVR router as resource,
b) the Tempest smoke tests should interact with DVR feature.

When a) and b) would not use the DVR feature, we would have DVR-aware setup 
configured, but no real interaction with DVR done.
By default, Grenade jobs are launching the tempest smoke tests only, and no 
full tempest suit.

To avoid having 2 jobs running Grenade multinode setup, we can enable only the 
DVR one in check queue.
To have proper interaction with DVR feature, we can adjust the Grenade tests 
and tempest smoke suit.

Regards,
Artur Korzeniewski
IRC: korzen

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

From: Armando M. [mailto:arma...@gmail.com]
Sent: Monday, February 22, 2016 6:01 PM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [nova][neutron][upgrade] Grenade multinode partial 
upgrade - Nova metadata failure



On 22 February 2016 at 08:52, Ihar Hrachyshka 
> wrote:
Armando M. > wrote:


On 22 February 2016 at 04:56, Ihar Hrachyshka 
> wrote:
Sean M. Collins > wrote:

Armando M. wrote:
Now that the blocking issue has been identified, I filed project-config
change [1] to enable us to test the Neutron Grenade multinode more
thoroughly.

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


Indeed - I want to profusely thank everyone that I reached out to during
these past months when I got stuck on this. Ihar, Matt K, Kevin B,
Armando - this is a huge win.

--
Sean M. Collins

Thanks everyone to make that latest push. We are almost there!..

I guess the next steps are:
- monitoring the job for a week, making sure it’s stable enough (comparing 
failure rate to non-partial grenade job?);

Btw, the job trend is here:

http://grafana.openstack.org/dashboard/db/neutron-failure-rate?panelId=6

I'd prefer to wait a little longer. Depending on how things go we may want to 
make it not until N opens up.

Agreed.

- if everything goes fine, propose project-config change to make it voting;
- propose governance patch to enable rolling-upgrade tag for neutron repo (I 
believe not for *aas repos though?).

I guess with that we would be able to claim victory for the basic 'server vs. 
agent’ part of rolling scenario. Right?

Follow up steps would probably be:
- look at enabling partial job for DVR flavour;

That should be only instrumental to see how sane DVR during upgrades is, and 
proceed in tweaking the existing grenade-multi job in the check queue to be 
dvr-aware. In other words: I personally wouldn't want to see two grenade jobs 
in the gate.

Ack, that would be the end goal. There still may be some short time when both 
are in gate.

- proceed on objectification of neutron db layer to open doors for later mixed 
server versions in the same cluster.

Anything I missed?

Also, what do we do with non-partial flavour of the job? Is it staying?

What job are you talking about exactly?

gate-grenade-dsvm-neutron

It’s not ‘partial’ in that we don’t run mixed versions of components during 
tempest run. It only covers that new code can run using old configuration 
files, and that alembic migrations apply correctly for some limited number of 
so called ‘long standing’ resources like instances created on the ‘old’ side of 
grenade.

Yes, that is staying. Especially considering that's part of the integrate gate 
on a bunch of other projects. We'll reconsider what to do, once we strengthen 
our rolling upgrade story.



Ihar

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

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

Re: [openstack-dev] [nova][neutron][upgrade] Grenade multinode partial upgrade

[Korzeniewski, Artur]

I have submitted patch for DVR Grenade multinode job:
https://review.openstack.org/#/c/250215

Without DVR upgrade - we won't be able to tell if L3 upgrade is working.
What is left to be done, it is the DVR support in Grenade.
DVR has the multinode job, but I do not see DVR in grenade - creation of DVR 
router should be done in Grenade scripts.

Regards,
Artur  

-Original Message-
From: Sean M. Collins [mailto:s...@coreitpro.com] 
Sent: Wednesday, November 25, 2015 9:03 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [nova][neutron][upgrade] Grenade multinode partial 
upgrade

On Wed, Nov 25, 2015 at 02:31:26PM EST, Armando M. wrote:
> So we fail before even attempting an upgrade?

Yeah I think so, I think we were failing at step 3 of Artur's list, creating 
the resources.

> It looks like we're testing 7.0.1.dev114, shouldn't we test from 7.0.0?

I think Grenade checks out stable/liberty - so that's probably a version string 
generated from the tip of stable/liberty 

> I am really confused, I should probably stop asking questions and do 
> some homework :)

No please keep asking - I think we're all learning things here. I'm certainly 
no expert.

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

Re: [openstack-dev] [nova][neutron][upgrade] Grenade multinode partial upgrade

[Korzeniewski, Artur]

I have run the multimode grenade job twice:
Failed: [1] 
http://logs.openstack.org/69/143169/60/experimental/gate-grenade-dsvm-neutron-multinode/bf6bae1/
Success: [2] 
http://logs.openstack.org/69/143169/60/experimental/gate-grenade-dsvm-neutron-multinode/7c05ff0/

The [1] failed because it couldn't ssh to VM. The connectivity issue happened 
during resource creation phase - even before upgrade.

Regards,
Artur

-Original Message-
From: Sean M. Collins [mailto:s...@coreitpro.com] 
Sent: Wednesday, November 25, 2015 5:42 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [nova][neutron][upgrade] Grenade multinode partial 
upgrade

The first run for the multinode grenade job completed.

http://logs.openstack.org/35/187235/11/experimental/gate-grenade-dsvm-neutron-multinode/011124b/logs/

I'm still getting my bearings in the grenade log output, but if I understand it 
correctly, after upgrading Neutron, when spawning a new instance we do not get 
successful connectivity. The odd part is we see the failure twice. Once when 
upgrading Nova[1], then once when upgrading Cinder[2]. I would have thought 
Grenade would have exited after just failing the first time. It did do a call 
to worlddump.

The odd part is that the first failure is a little strange - it pings then 
sleeps until it successfully gets a packet back. Which it does - but then it 
does a call to worlddump. Odd?

Anyway, then it goes on to upgrade cinder, then tries to create an instance and 
ssh in, then it fails and grenade exits completely.

I'll continue digging through the logs to see exactly why we don't get 
connectivity. I see some interesting warnings in the L3 agent log about 
cleaning up a non-existent router[3], which may be the culprit.

[1]: 
http://logs.openstack.org/35/187235/11/experimental/gate-grenade-dsvm-neutron-multinode/011124b/logs/grenade.sh.txt.gz#_2015-11-23_20_34_06_742

[2]: 
http://logs.openstack.org/35/187235/11/experimental/gate-grenade-dsvm-neutron-multinode/011124b/logs/grenade.sh.txt.gz#_2015-11-23_21_45_15_133

[3]: 
http://logs.openstack.org/35/187235/11/experimental/gate-grenade-dsvm-neutron-multinode/011124b/logs/old/screen-q-l3.txt.gz?level=WARNING
--
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

Re: [openstack-dev] [nova][neutron][upgrade] Grenade multinode partial upgrade

[Korzeniewski, Artur]

Yes, this file is complete fine. The Grenade is running smoke test before 
resource creation.
The workflow is like this:
1. Install old devstack on main and subnode 
2. Run tempest smoke
3. Create resources
4. Verify resources
5. Shutdown the services
6. Verify if shutdown does not affect the resources
7. Spin new devstack on main node, subnode stays in old version without any 
touch.
8. Upgrade the services - start the new code on main node
9. Run tempest smoke tests on upgraded main node - it in theory should validate 
if we are cross-version compatible (N and N+1)
10. Verify resources
11. Shutdown

The successful steps are in log:
http://logs.openstack.org/69/143169/60/experimental/gate-grenade-dsvm-neutron-multinode/7c05ff0/logs/grenade.sh.summary.txt.gz



Regards,
Artur

-Original Message-
From: Sean M. Collins [mailto:s...@coreitpro.com] 
Sent: Wednesday, November 25, 2015 7:03 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [nova][neutron][upgrade] Grenade multinode partial 
upgrade

On Wed, Nov 25, 2015 at 12:53:56PM EST, Armando M. wrote:
> On 25 November 2015 at 09:49, Sean M. Collins  wrote:
> 
> > Yeah looks like I read it wrong - the failure occurred during the 
> > initial resource creation phase, based on comparing the logs that 
> > Artur posted.
> >
> 
> I see. I got confused by this:
> 
> http://logs.openstack.org/69/143169/60/experimental/gate-grenade-dsvm-
> neutron-multinode/bf6bae1/logs/testr_results.html.gz
> 
> Look at the timestamp, it's from 2 days ago.

No, that's correct. It's just taken me 2 days to get around to writing an 
e-mail about all this :)

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

Re: [openstack-dev] [nova][neutron][upgrade] Grenade multinode partial upgrade

[Korzeniewski, Artur]

From what I understand – the Sean case did not get to upgrade [1]– it has ended 
after creating the VM and trying to ping/ssh it.
So we do not have restart logs of q-agt and no logs in new [2]

The subnode will have only ‘old’ logs because the grenade multimode scenario 
assumes that subnode will not be upgraded – that’s why we will be able to test 
RPC versioning new server talking to old compute/q-agt version.

[1] 
http://logs.openstack.org/35/187235/11/experimental/gate-grenade-dsvm-neutron-multinode/011124b/logs/grenade.sh.summary.txt.gz
[2] 
http://logs.openstack.org/35/187235/11/experimental/gate-grenade-dsvm-neutron-multinode/011124b/logs/new/

For sanity I’m attaching my runs of multimode grenade job:

Failed the same way Sean’s one: 
http://logs.openstack.org/69/143169/60/experimental/gate-grenade-dsvm-neutron-multinode/bf6bae1/

Success:  
http://logs.openstack.org/69/143169/60/experimental/gate-grenade-dsvm-neutron-multinode/7c05ff0/

Regards,
Artur

From: Armando M. [mailto:arma...@gmail.com]
Sent: Wednesday, November 25, 2015 6:30 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [nova][neutron][upgrade] Grenade multinode partial 
upgrade



On 25 November 2015 at 08:42, Sean M. Collins 
> wrote:
The first run for the multinode grenade job completed.

http://logs.openstack.org/35/187235/11/experimental/gate-grenade-dsvm-neutron-multinode/011124b/logs/

I'm still getting my bearings in the grenade log output, but if I
understand it correctly, after upgrading Neutron, when spawning a new
instance we do not get successful connectivity. The odd part is we see
the failure twice. Once when upgrading Nova[1], then once when upgrading
Cinder[2]. I would have thought Grenade would have exited after just
failing the first time. It did do a call to worlddump.

The odd part is that the first failure is a little strange - it pings
then sleeps until it successfully gets a packet back. Which it does -
but then it does a call to worlddump. Odd?

Anyway, then it goes on to upgrade cinder, then tries to create an
instance and ssh in, then it fails and grenade exits completely.

I'll continue digging through the logs to see exactly why we don't get
connectivity. I see some interesting warnings in the L3 agent log about
cleaning up a non-existent router[3], which may be the culprit.

[1]: 
http://logs.openstack.org/35/187235/11/experimental/gate-grenade-dsvm-neutron-multinode/011124b/logs/grenade.sh.txt.gz#_2015-11-23_20_34_06_742

[2]: 
http://logs.openstack.org/35/187235/11/experimental/gate-grenade-dsvm-neutron-multinode/011124b/logs/grenade.sh.txt.gz#_2015-11-23_21_45_15_133

[3]: 
http://logs.openstack.org/35/187235/11/experimental/gate-grenade-dsvm-neutron-multinode/011124b/logs/old/screen-q-l3.txt.gz?level=WARNING

Good stuff Sean.

A question:

if the workflow is: upgrade server first, run some connectivity tests to then 
proceed to upgrading the rest to then re-run tempest, where's the log of the 
new server?

All I can see is this one:

http://logs.openstack.org/35/187235/11/experimental/gate-grenade-dsvm-neutron-multinode/011124b/logs/old/screen-q-svc.txt.gz

And I see no restart in it.

On the subnode (compute), I only see 'old' logs.

http://logs.openstack.org/35/187235/11/experimental/gate-grenade-dsvm-neutron-multinode/011124b/logs/subnode-2/old/

Thoughts?


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

Re: [openstack-dev] [neutron][upgrade] new 'all things upgrade' subteam

[Korzeniewski, Artur]

Mon 15 UTC works for me too.
Was there the first meeting on past Monday? 
Or are we starting on Monday 23rd November?

-Original Message-
From: Akihiro Motoki [mailto:amot...@gmail.com] 
Sent: Wednesday, November 18, 2015 4:04 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron][upgrade] new 'all things upgrade' subteam

I missed this mailing thread. Thanks for coordinating the effort!
Mon 1500UTC works for me too.

2015-11-18 23:36 GMT+09:00 Ihar Hrachyshka :
> Thanks everyone for responses.
>
> It seems like Mon 15:00 UTC works for all of us, so I pushed the 
> following patch to book #openstack-meeting-2 room weekly:
>
> https://review.openstack.org/246949
>
> Ihar
>
>
> Rossella Sblendido  wrote:
>
>> Hi Ihar,
>>
>> same for me, all options are ok!
>>
>> cheers,
>>
>> Rossella
>>
>> On 11/12/2015 11:00 PM, Martin Hickey wrote:
>>>
>>> Hi Ihar,
>>>
>>> Any of those options would suit me, thanks.
>>>
>>> Cheers,
>>> Martin
>>>
>>>
>>>
>>>
>>> From:   Ihar Hrachyshka 
>>> To: "OpenStack Development Mailing List (not for usage questions)"
>>>  
>>> Date:   12/11/2015 21:39
>>> Subject:Re: [openstack-dev] [neutron][upgrade] new 'all things
>>>  upgrade'   subteam
>>>
>>>
>>>
>>> Artur  wrote:
>>>
 My TZ is UTC +1:00.
 Do we have any favorite day? Maybe Tuesday?
>>>
>>>
>>> I believe Tue is already too packed with irc meetings to be 
>>> considered (we
>>>
>>> have, for the least, main neutron meetings and neutron-drivers 
>>> meetings there).
>>>
>>> We have folks in US and Central Europe and Russia and Japan… I 
>>> believe the
>>>
>>> best time would be somewhere around 13:00 to 15:00 UTC (that time 
>>> would still be ‘before midnight' for Japan; afternoon for Europe, 
>>> and morning for
>>>
>>> US East Coast).
>>>
>>> I have checked neutron meetings at [1], and I see that we have 13:00 
>>> UTC slots free for all days; 14:00 UTC slot available for Thu; and 
>>> 15:00 UTC slots for Mon and Fri (I don’t believe we want to have it on Fri 
>>> though).
>>> Also overall Mondays are all free.
>>>
>>> Should I create a doodle for those options? Or are there any 
>>> alternative suggestions?
>>>
>>> [1]:
>>> http://git.openstack.org/cgit/openstack-infra/irc-meetings/tree/meet
>>> ings
>>>
>>> Ihar
>>>
>>>
>>> 
>>> __ OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>> 
>>> __ OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>> _
>> _ OpenStack Development Mailing 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] [nova][neutron][upgrade] Grenade multinode partial upgrade

[Korzeniewski, Artur]

Thanks Sean D. for explanation!

I’ve taken a look into old Russell patches, and it seems that the 
project-config was already modified by him:

Add check-grenade-dsvm-partial-ncpu-neutron: (project-config)

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

Add check-grenade-dsvm-partial-ncpu-neutron-dvr (project-config)

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



Another 2 patches are introducing the Neutron partial job to devstack-gate

Add partial-ncpu-neutron grenade mode (devstack-gate)

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

Add partial-ncpu-neutron-dvr grenade mode (devstack-gate)

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

I haven’t tested that yet, but it looks like it does the job.

Also, there is still one patch in Devstack needed for L3 agent separate 
start/stop:

Separate start/stop control of the Neutron L3 agent. (Devstack)

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

From what Sean D. talked about, following patches should not be resurrected:

Support partial upgrades of Neutron in DVR mode: (Grenade)

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

 Support partial Neutron upgrades. (Grenade)

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

In order to test the RPC right, we should be able to decouple the neutron 
server from its agents – L2, L3, DHCP and metadata agents.
Current scenario will let us to test :

1.   Legacy:

a.   Controller & network node: neutron server, L2, L3, Metadata and DHCP 
agents

b.  Compute node: L2 agent.

2.   DVR:

a.   Controller & network node: neutron server, L2, L3, Metadata and DHCP 
agents

b.  Compute node: L2, L3, Metadata(?) agents

We can start with current scenario, but this does not guarantee us to test of 
DHCP RPC.

The ideal upgrade scenario should look like this:

1.   Legacy:

a.   Controller node: neutron server

b.  Network node: L2, L3, Metadata and DHCP server

c.   Compute node: L2 agent

2.   DVR:

a.   Controller node: neutron server

b.  Network node: L2, L3, Metadata and DHCP server

c.   Compute node: L2, L3 and Metadata agent

The job still to be done in order to fully test partial upgrades:

-  Decouple the DHCP and metadata agent from devstack neutron restart

-  Look through the grenade Neutron code in order to identify if we are 
creating the all the resources critical to test the upgrades

-  Debug, debug, debug…

Regards,
Artur
From: Armando M. [mailto:arma...@gmail.com]
Sent: Friday, November 13, 2015 9:37 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [nova][neutron][upgrade] Grenade multinode partial 
upgrade



On 13 November 2015 at 11:46, Sean Dague 
> wrote:
On 11/13/2015 01:16 PM, Sean M. Collins wrote:
> On Fri, Nov 13, 2015 at 07:42:12AM EST, Sean Dague wrote:
>> Ok, I top responded with the details of the job, honestly I think it's
>> just a project-config change to get up and running, and then hacking at
>> the bugs that fall out.
>
> Thanks - that was super helpful.
>
> I'm thinking of working on the following on Monday:
>
> 1) capture that somewhere in the upgrade docs we're putting together in 
> neutron's devref
>
> 2) Adding the stanza to project-config to get grenade running for
> Neutron
>
> 3) Take a look at the patches that Armando linked a couple emails back
> in this thread.

I don't think that any of the patches listed there are needed. This was
part of the reason I -2ed that direction in the last cycle. It required
a separate special code path for partial upgrade setup which was very
synthetic (and honestly kind of confusing to debug).

I don't disagree. I didn't meant to imply 'resume the patches', I was only 
providing the backdrop.


The new approach means if you did upgrade for the all-in-one case, and
you did multinode setup with worker processes on the subnode, you just
make a config where you do them both at the same time, and you have
partial upgrade.

-Sean

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

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

[openstack-dev] [nova][neutron][upgrade] Grenade multinode partial upgrade

[Korzeniewski, Artur]

Hi Sean,
I'm interested in introducing to Neutron the multinode partial upgrade job in 
Grenade.

Can you explain how multinode is currently working in Grenade and how Nova is 
doing the partial upgrade?

Regards,
Artur Korzeniewski
IRC: korzen

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

Re: [openstack-dev] [neutron][upgrade] new 'all things upgrade' subteam

[Korzeniewski, Artur]

My TZ is UTC +1:00.
Do we have any favorite day? Maybe Tuesday?
It is good idea to have at least 0,5h sync each week.

Regards,
Artur

From: Anna Kamyshnikova [mailto:akamyshnik...@mirantis.com]
Sent: Wednesday, November 11, 2015 10:43 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron][upgrade] new 'all things upgrade' subteam

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] Neutron Social Meetup in Tokyo

[Korzeniewski, Artur]

Hi,
Please count me in also. I’ll be happy to meet with you folks!

Regards,
Artur

From: Sukhdev Kapur [mailto:sukhdevka...@gmail.com]
Sent: Tuesday, October 27, 2015 2:32 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron] Neutron Social Meetup in Tokyo

Hey Akihiro,

Thanks for arranging this. I did not see any link to RSVP.
I would love to attend this event - please add me to the list.

Thanks
-Sukhdev


On Fri, Oct 23, 2015 at 9:23 AM, Akihiro Motoki 
> wrote:
Hi Neutron folks,

We are pleased to announce Neutron social meet-up in Tokyo.
Thanks Takashi and Hirofumi for the big help.

I hope many of you will be there and enjoy the time.
If you have made RSVP, don't miss it!
We recommend  to join the beginning, but come and join us even if you
arrive late.



Thursday, Oct 29 19:00-22:00
Hokkaido (北海道 品川インターシティー店)

Location:
https://www.google.com/maps/d/edit?mid=zBFFkY6dvVno.kOTkyNjZ2oU0=sharing
5th floor at the "shop and restaurant building" (between A and B buildings).
It is at the opposite side of JR Shinagawa Station from the Summit side.)

Approximately it costs ~5000 (Japanese) Yen depending on the number of
folks who join.
Note that we have no sponsors.

If you have any trouble in reaching there or some question, reach me
@ritchey98 on Twitter.



See you in Tokyo!
Akihiro

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

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

[openstack-dev] [neutron] Neutron rolling upgrade - are we there yet?

[Korzeniewski, Artur]

Hi all,
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.


1.  RPC versioning

a.  It is already implemented in Neutron.

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.

c.  Possible unit/functional tests to catch RPC version incompatibilities 
between RPC revisions.

d.  TODO: Multi-node Grenade job to have rolling upgrades covered in CI.

2.  Message content versioning - versioned objects

a.  TODO: implement Oslo Versionobject in Mitaka cycle. The interesting 
entities to be implemented: network, subnet, port, security groups...

b.  Will OVO have impact on vendor plugins?

c.  Be strict on changes in version objects in code review, any change in 
object structure should increment the minor (backward-compatible) or major 
(breaking change) RPC version.

d.  Indirection API - message from newer format should be translated to 
older version by neutron server.

3.  Database migration

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

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.

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.

I have performed the manual Kilo to Liberty upgrade, both in operational manner 
and in code review of the RPC APIs. All is working fine.
We can have some discussion on cross-project session [7] or we can also review 
any issues with Neutron upgrade in Friday's unplugged session [8].

Sources:
[1] http://www.danplanet.com/blog/2015/10/05/upgrades-in-nova-rpc-apis/
[2] http://www.danplanet.com/blog/2015/10/06/upgrades-in-nova-objects/
[3] 
http://www.danplanet.com/blog/2015/10/07/upgrades-in-nova-database-migrations/
[4] 
https://github.com/openstack/neutron/blob/master/doc/source/devref/rpc_callbacks.rst
[5] 
http://www.danplanet.com/blog/2015/06/26/upgrading-nova-to-kilo-with-minimal-downtime/
[6] 
https://github.com/openstack/neutron-specs/blob/master/specs/liberty/online-schema-migrations.rst
[7] https://etherpad.openstack.org/p/mitaka-cross-project-session-planning
[8] https://etherpad.openstack.org/p/mitaka-neutron-unplugged-track

Regards,
Artur Korzeniewski
IRC: korzen

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

[openstack-dev] Merging DVR-HA into Liberty release

[Korzeniewski, Artur]

Hi Code Reviewers,
I would like to ask if DVR-HA patches can be merged into Liberty release:

https://bugs.launchpad.net/neutron/+bug/1365473

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

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

The proper patches has been implemented, the reviews has been addressed, the 
patches are working and all found issues has been fixed.

Would it be possible to merge it into Liberty release?

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

[openstack-dev] [neutron][dvr] DVR L2 agent is removing the br-int OVS flows

[Korzeniewski, Artur]

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

Re: [openstack-dev] [neutron][dvr][ha] DVR-HA router is not working.

[Korzeniewski, Artur]

I have checked that:
1) the router_gateway is configured properly on network node (in namespace and 
in OVS), but the port is not reported as UP to controller node. Also, the ARP 
is not performed so no-one from external network is aware of the gateway 
address. When I ping from the GW to external host, the host knows where the GW 
IP is and can ping back.

2) The distributed snat port is created in namespace and IP is configured, but 
port is not reported as UP to controller, and there is no connectivity with 
other VMs inside the tenant network, maybe the port is not configured properly 
in OVS…

Regards,
Artur

From: Assaf Muller [mailto:amul...@redhat.com]
Sent: Wednesday, August 12, 2015 4:09 PM
To: OpenStack Development Mailing List (not for usage questions); 
adolfo.dua...@hp.com
Subject: Re: [openstack-dev] [neutron][dvr][ha] DVR-HA router is not working.

Adding the author of the patches. This reinforces the need to hold on merging 
these patches until they have an in-tree integration test.

On Tue, Aug 11, 2015 at 4:13 PM, Korzeniewski, Artur 
artur.korzeniew...@intel.commailto:artur.korzeniew...@intel.com wrote:
Hi,
I’ve been playing around with DVR-HA patches [1][2], have them applied on 
Mondays master branch.
The problem is that the dvr-ha router is not working with SNAT and floating ips.

My setup:
Devstack-34 – all in one (controller, compute, DVR agent, DHCP node)
Devstack-35 – compute node and DVR agent
Devstack-36 – network node (SNAT)
Devstack-37 – network node 2 (SNAT)

External interface (router_gateway) is down for created dvr-ha router. The snat 
port (router_centralized_snat) is also down after connecting the tenant network.
I’m not sure where is the problem, can someone look at the logs and point me 
the place where to look for the answer why the ports are not reported as UP?
Add default gateway for DVR-HA router, log from active network node: 
http://pastebin.com/S7rYpDns
Add default gateway for DVR-HA router, log from neutron server node: 
http://pastebin.com/WpcV1g09

The external gateway IP is not reachable from external network, and VMs are not 
able to ping default gateway  (10.2.2.1)…
I have to add, that on the same setup the usual DVR router is working fine 
(hosted on the same network node)

[1] https://review.openstack.org/#/c/196893
[2] https://review.openstack.org/#/c/143169

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:unsubscribehttp://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[openstack-dev] [neutron][dvr][ha] DVR-HA router is not working.

[Korzeniewski, Artur]

Hi,
I've been playing around with DVR-HA patches [1][2], have them applied on 
Mondays master branch.
The problem is that the dvr-ha router is not working with SNAT and floating ips.

My setup:
Devstack-34 - all in one (controller, compute, DVR agent, DHCP node)
Devstack-35 - compute node and DVR agent
Devstack-36 - network node (SNAT)
Devstack-37 - network node 2 (SNAT)

External interface (router_gateway) is down for created dvr-ha router. The snat 
port (router_centralized_snat) is also down after connecting the tenant network.
I'm not sure where is the problem, can someone look at the logs and point me 
the place where to look for the answer why the ports are not reported as UP?
Add default gateway for DVR-HA router, log from active network node: 
http://pastebin.com/S7rYpDns
Add default gateway for DVR-HA router, log from neutron server node: 
http://pastebin.com/WpcV1g09

The external gateway IP is not reachable from external network, and VMs are not 
able to ping default gateway  (10.2.2.1)...
I have to add, that on the same setup the usual DVR router is working fine 
(hosted on the same network node)

[1] https://review.openstack.org/#/c/196893
[2] https://review.openstack.org/#/c/143169

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

Re: [openstack-dev] [neutron][dvr] Removing fip namespace when restarting L3 agent.

[Korzeniewski, Artur]

Bug submitted:
https://bugs.launchpad.net/neutron/+bug/1482521

Thanks,
Artur

From: Oleg Bondarev [mailto:obonda...@mirantis.com]
Sent: Thursday, August 6, 2015 5:18 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron][dvr] Removing fip namespace when 
restarting L3 agent.



On Thu, Aug 6, 2015 at 5:23 PM, Korzeniewski, Artur 
artur.korzeniew...@intel.commailto:artur.korzeniew...@intel.com wrote:
Thanks Kevin for that hint.
But it does not resolve the connectivity problem, it is just not removing the 
namespace when it is asked to.
The real question is, why do we invoke the 
/neutron/neutron/agent/l3/dvr_fip_ns.py FipNamespace.delete() method in the 
first place?

I’ve captured the traceback for this situation:
2015-08-06 06:35:28.469 DEBUG neutron.agent.linux.utils [-] Unable to access 
/opt/openstack/data/neutron/external/pids/8223e12e-837b-49d4-9793-63603fccbc9f.pid
 from (pid=70216) get_value_from_file 
/opt/openstack/neutron/neutron/agent/linux/utils.py:222
2015-08-06 06:35:28.469 DEBUG neutron.agent.linux.utils [-] Unable to access 
/opt/openstack/data/neutron/external/pids/8223e12e-837b-49d4-9793-63603fccbc9f.pid
 from (pid=70216) get_value_from_file 
/opt/openstack/neutron/neutron/agent/linux/utils.py:222
2015-08-06 06:35:28.469 DEBUG neutron.agent.linux.external_process [-] No 
process started for 8223e12e-837b-49d4-9793-63603fccbc9f from (pid=70216) 
disable /opt/openstack/neutron/neutron/agent/linux/external_process.py:113
Traceback (most recent call last):
 File /usr/local/lib/python2.7/dist-packages/eventlet/queue.py, line 117, in 
switch
self.greenlet.switch(value)
  File /usr/local/lib/python2.7/dist-packages/eventlet/greenthread.py, line 
214, in main
result = function(*args, **kwargs)
  File /usr/local/lib/python2.7/dist-packages/oslo_service/service.py, line 
612, in run_service
service.start()
  File /opt/openstack/neutron/neutron/service.py, line 233, in start
self.manager.after_start()
  File /opt/openstack/neutron/neutron/agent/l3/agent.py, line 641, in 
after_start
self.periodic_sync_routers_task(self.context)
  File /opt/openstack/neutron/neutron/agent/l3/agent.py, line 519, in 
periodic_sync_routers_task
self.fetch_and_sync_all_routers(context, ns_manager)
  File /opt/openstack/neutron/neutron/agent/l3/namespace_manager.py, line 91, 
in __exit__
self._cleanup(_ns_prefix, ns_id)
  File /opt/openstack/neutron/neutron/agent/l3/namespace_manager.py, line 
140, in _cleanup
ns.delete()
  File /opt/openstack/neutron/neutron/agent/l3/dvr_fip_ns.py, line 147, in 
delete
raise TypeError(ss)
TypeError: ss

It seems that the fip namespace is not processed at startup of L3 agent, and 
the cleanup is removing the namespace…
It is also removing the interface to local dvr router connection so… VM has no 
internet access with floating IP:
Command: ['ip', 'netns', 'exec', 'fip-8223e12e-837b-49d4-9793-63603fccbc9f', 
'ip', 'link', 'del', u'fpr-fe517b4b-d']

If the interface inside the fip namespace is not deleted, the VM has full 
internet access without any downtime.

Ca we consider it a bug? I guess it is something in startup/full-sync logic 
since the log is saying:
/opt/openstack/data/neutron/external/pids/8223e12e-837b-49d4-9793-63603fccbc9f.pid

I think yes, we can consider it a bug. Can you please file one? I can take and 
probably fix it.


And after finishing the sync loop, the fip namespace is deleted…

Regards,
Artur

From: Kevin Benton [mailto:blak...@gmail.commailto:blak...@gmail.com]
Sent: Thursday, August 6, 2015 7:40 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron][dvr] Removing fip namespace when 
restarting L3 agent.

Can you try setting the following to False:
https://github.com/openstack/neutron/blob/dc0944f2d4e347922054bba679ba7f5d1ae6ffe2/etc/l3_agent.ini#L97

On Wed, Aug 5, 2015 at 3:36 PM, Korzeniewski, Artur 
artur.korzeniew...@intel.commailto:artur.korzeniew...@intel.com wrote:
Hi all,
During testing of Neutron upgrades, I have found that restarting the L3 agent 
in DVR mode is causing the VM network downtime for configured floating IP.
The lockdown is visible when pinging the VM from external network, 2-3 pings 
are lost.
The responsible place in code is:
DVR: destroy fip ns: fip-8223e12e-837b-49d4-9793-63603fccbc9f from (pid=156888) 
delete /opt/openstack/neutron/neutron/agent/l3/dvr_fip_ns.py:164

Can someone explain why the fip namespace is deleted? Can we workout the 
situation, when there is no downtime of VM access?

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:unsubscribehttp://openstack-dev-requ...@lists.openstack.org

Re: [openstack-dev] [neutron][dvr] Removing fip namespace when restarting L3 agent.

[Korzeniewski, Artur]

Thanks Kevin for that hint.
But it does not resolve the connectivity problem, it is just not removing the 
namespace when it is asked to.
The real question is, why do we invoke the 
/neutron/neutron/agent/l3/dvr_fip_ns.py FipNamespace.delete() method in the 
first place?

I’ve captured the traceback for this situation:
2015-08-06 06:35:28.469 DEBUG neutron.agent.linux.utils [-] Unable to access 
/opt/openstack/data/neutron/external/pids/8223e12e-837b-49d4-9793-63603fccbc9f.pid
 from (pid=70216) get_value_from_file 
/opt/openstack/neutron/neutron/agent/linux/utils.py:222
2015-08-06 06:35:28.469 DEBUG neutron.agent.linux.utils [-] Unable to access 
/opt/openstack/data/neutron/external/pids/8223e12e-837b-49d4-9793-63603fccbc9f.pid
 from (pid=70216) get_value_from_file 
/opt/openstack/neutron/neutron/agent/linux/utils.py:222
2015-08-06 06:35:28.469 DEBUG neutron.agent.linux.external_process [-] No 
process started for 8223e12e-837b-49d4-9793-63603fccbc9f from (pid=70216) 
disable /opt/openstack/neutron/neutron/agent/linux/external_process.py:113
Traceback (most recent call last):
 File /usr/local/lib/python2.7/dist-packages/eventlet/queue.py, line 117, in 
switch
self.greenlet.switch(value)
  File /usr/local/lib/python2.7/dist-packages/eventlet/greenthread.py, line 
214, in main
result = function(*args, **kwargs)
  File /usr/local/lib/python2.7/dist-packages/oslo_service/service.py, line 
612, in run_service
service.start()
  File /opt/openstack/neutron/neutron/service.py, line 233, in start
self.manager.after_start()
  File /opt/openstack/neutron/neutron/agent/l3/agent.py, line 641, in 
after_start
self.periodic_sync_routers_task(self.context)
  File /opt/openstack/neutron/neutron/agent/l3/agent.py, line 519, in 
periodic_sync_routers_task
self.fetch_and_sync_all_routers(context, ns_manager)
  File /opt/openstack/neutron/neutron/agent/l3/namespace_manager.py, line 91, 
in __exit__
self._cleanup(_ns_prefix, ns_id)
  File /opt/openstack/neutron/neutron/agent/l3/namespace_manager.py, line 
140, in _cleanup
ns.delete()
  File /opt/openstack/neutron/neutron/agent/l3/dvr_fip_ns.py, line 147, in 
delete
raise TypeError(ss)
TypeError: ss

It seems that the fip namespace is not processed at startup of L3 agent, and 
the cleanup is removing the namespace…
It is also removing the interface to local dvr router connection so… VM has no 
internet access with floating IP:
Command: ['ip', 'netns', 'exec', 'fip-8223e12e-837b-49d4-9793-63603fccbc9f', 
'ip', 'link', 'del', u'fpr-fe517b4b-d']

If the interface inside the fip namespace is not deleted, the VM has full 
internet access without any downtime.

Ca we consider it a bug? I guess it is something in startup/full-sync logic 
since the log is saying:
/opt/openstack/data/neutron/external/pids/8223e12e-837b-49d4-9793-63603fccbc9f.pid

And after finishing the sync loop, the fip namespace is deleted…

Regards,
Artur

From: Kevin Benton [mailto:blak...@gmail.com]
Sent: Thursday, August 6, 2015 7:40 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron][dvr] Removing fip namespace when 
restarting L3 agent.

Can you try setting the following to False:
https://github.com/openstack/neutron/blob/dc0944f2d4e347922054bba679ba7f5d1ae6ffe2/etc/l3_agent.ini#L97

On Wed, Aug 5, 2015 at 3:36 PM, Korzeniewski, Artur 
artur.korzeniew...@intel.commailto:artur.korzeniew...@intel.com wrote:
Hi all,
During testing of Neutron upgrades, I have found that restarting the L3 agent 
in DVR mode is causing the VM network downtime for configured floating IP.
The lockdown is visible when pinging the VM from external network, 2-3 pings 
are lost.
The responsible place in code is:
DVR: destroy fip ns: fip-8223e12e-837b-49d4-9793-63603fccbc9f from (pid=156888) 
delete /opt/openstack/neutron/neutron/agent/l3/dvr_fip_ns.py:164

Can someone explain why the fip namespace is deleted? Can we workout the 
situation, when there is no downtime of VM access?

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:unsubscribehttp://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

[openstack-dev] [neutron][dvr] Removing fip namespace when restarting L3 agent.

[Korzeniewski, Artur]

Hi all,
During testing of Neutron upgrades, I have found that restarting the L3 agent 
in DVR mode is causing the VM network downtime for configured floating IP.
The lockdown is visible when pinging the VM from external network, 2-3 pings 
are lost.
The responsible place in code is:
DVR: destroy fip ns: fip-8223e12e-837b-49d4-9793-63603fccbc9f from (pid=156888) 
delete /opt/openstack/neutron/neutron/agent/l3/dvr_fip_ns.py:164

Can someone explain why the fip namespace is deleted? Can we workout the 
situation, when there is no downtime of VM access?

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