[openstack-dev] [networking-odl] Neutron with OpenDaylight Boron controller

[Elena Ezhova]

Hi folks,

We are trying to deploy Neutron with OpenDaylight Boron-0.5.0 controller
using DevStack (master version) on Ubuntu 14.04 and there is a number of
issues we face.

First, we tried to deploy OpenDaylight with odl-ovsdb-openstack feature
using the following local.conf [0]. In this case VMs successfully got IP
addresses and L2 connectivity was working, but there was no L3 connectivity
meaning we couldn't ping router IP from qdhcp namespace and VMs in
different subnets couldn't reach each other.
We've also tried to deploy OpenDaylight odl-ovsdb-openstack with Neutron L3
agent by enabling q-l3 and setting ODL_L3=False in local.conf, but in this
case stack.sh failed due to br-int not having been created.

After that, we were given an advice on opendaylight irc channel to use
odl-netvirt-openstack feature instead as odl-ovsdb-openstack is kind of
deprecated.
When deploying Neutron+ODL with this feature we were referencing the
NetVirt demo from the latest ODL summit [1] as well as networking-odl
DevStack guide [2] and our local.conf was looking the following way [3].
As a result, though br-int is created and when a subnet or a VM are created
corresponding tap interfaces are added, there is no L2 and L3 connectivity
and there are a lot of error in karaf logs:

   - Errors on start: http://paste.openstack.org/show/591432/
   - Logs during Neutron subnet create:
   http://paste.openstack.org/show/591437/
   - OVS ports and flows after a Neutron network with a subnet were
   created: http://paste.openstack.org/show/591642/ .
   Here it seems that not all flows had been created, for example there is
   a flow in table 51 that sends traffic to table 52 which is missing.
   - There are also tons of traces identical to ones in bug [4] which
   should have been fixed in Beryllium release.

Has someone successfully deployed operational Neutron+OpenDaylight with
NetVirt or ovsdb feature recently? If so, we would really appreciate an
example of local.conf that was used as well as any clues that point out
what we can be missing.

Thanks,
Elena

[0] http://paste.openstack.org/show/591645/
https://docs.google.com/presentation/d/1VLzRIOEptSOY1b0w4PezRIQ0gF5vx7GyLKECWXRV5mE/edit#slide=id.g17efbe8461_0_146
[2]
https://github.com/openstack/networking-odl/blob/master/devstack/README.rst
[3] http://paste.openstack.org/show/591641/
[4] https://bugs.opendaylight.org/show_bug.cgi?id=5275
__
OpenStack Development Mailing 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

[Elena Ezhova]

+1

On Fri, Oct 14, 2016 at 9:30 PM, 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

Re: [openstack-dev] Openstack Mitaka Neutron LBaaS Question

[Elena Ezhova]

Hi!

You also have to configure Octavia on your controller. The most
straightforward way would be to follow the steps that are done in Octavia
DevStack plugin
.
There is also an overview presentation

which
has some troubleshooting tips.

Thanks,
Elena

On Sat, Jul 2, 2016 at 1:24 AM, zhihao wang 
wrote:

> Dear OpenStack Dev member:
>
> May I ask you some question about neutron lbaaS?
>
> How to install the neutron LBaaS with Octavia in Mitaka?
> I followed these two guide ,but which one I should use? (My openstack is
> Mitaka , 1 controller, 2 compute nodes)
>
> https://wiki.openstack.org/wiki/Neutron/LBaaS/HowToRun  --  Ubuntu
> Packages Setup
> http://docs.openstack.org/mitaka/networking-guide/adv-config-lbaas.html
> -- Configuring LBaaS v2 with Octavia
>
> Here is what I did:
>
> pip install octavia
>
> and then :
> vim /etc/neutron/neutron.conf
> service_plugins =
> router,neutron_lbaas.services.loadbalancer.plugin.LoadBalancerPluginv2
>
> [service_providers]
> service_provider =
> LOADBALANCERV2:Octavia:neutron_lbaas.drivers.octavia.driver.OctaviaDriver:default
>
> /etc/openstack-dashboard/local_settings.py
>
>
> OPENSTACK_NEUTRON_NETWORK = {
> 'enable_lb': True
> }
>
>
> And then I restart all the neutron service and apache server
>   service neutron-server restart
>   service neutron-dhcp-agent restart
>   service neutron-metadata-agent restart
>   service neutron-l3-agent restart
>
> but and then i ran the command neutron agent-list, it return this. I am
> wondering what is wrong with this? how can I install Neutron LaaS?
>
> root@controller:~# neutron agent-list
> Unable to establish connection to http://controller:9696/v2.0/agents.json
>
>
> Please help
>
> Thanks so much
>
> Thanks
> Wally
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][VPNaaS]How to enable VPNaas in devstack ?

[Elena Ezhova]

Hi!

Just enabling the neutron-vpnaas plugin is enough, master branch will be
automatically fetched if you set RECLONE=True in your local.conf.
The "Checkout Test branches" section is outdated and should be removed from
the doc.

On Wed, Dec 2, 2015 at 12:31 PM, lichen.hangzhou 
wrote:

> hello,
>
> I have a question, can I enable vpnaas under devstack?
>
>
> https://wiki.openstack.org/wiki/Neutron/VPNaaS/HowToInstall#VPNaaS_with_Single_DevStack_and_Two_Routers
>
> ==> There is a section said :
>
>- Checkout Test branches
>
> Neutron : https://review.openstack.org/#/c/33148/
>
> Neutron client : https://review.openstack.org/#/c/29811/
>
>
> Do I must checkout neutron to change
> https://review.openstack.org/#/c/33148/ ?
> Can vpnaas work with master branch directly ?
>
> Thanks.
> -chen
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][vpnaas] VPNaaS project status

[Elena Ezhova]

Thanks for everything you've done for VPNaaS, Paul! Your help and guidance
was (and is) always very helpful.

On Thu, Nov 12, 2015 at 5:56 PM, Paul Michali  wrote:

> Neutron community,
>
> During the past several releases, while leading the VPNaaS project, I've
> seen many great enhancements and features added to the VPNaaS project by
> the community, including support for StrongSwan, Libreswan, completion of
> the project split out, functional and rally tests, endpoint groups,
> multiple local subnets, vendor drivers, etc.
>
> There is still work needed (certificate support the most important,
> followed by documentation and scale testing), but there is a solid (in my
> bias and subjective opinion :) foundation in place for people to play with
> this capability.
>
> As I mentioned to Armando at the summit, it's time for me to move on to
> other areas of Neutron, and as such, I'm stepping down as VPNaaS chair and
> wrapping up work on the project over the next few weeks. I'll still try to
> review VPNaaS commits as much as possible, and be available to advise in
> this area.
>
> Towards that end, I've updated the VPNaaS wiki page (
> https://wiki.openstack.org/wiki/Meetings/VPNaaS) to list what I think are
> outstanding work that can be done in this area, from important to wish
> items.  Meetings have transitioned to on-demand, and future meetings can
> either be done as an on-demand topic in the Neutron IRC meeting, or as an
> on-demand special meeting.
>
> I'll go through the VPNaaS bugs in Launchpad and comment on them, as to my
> opinion of importance, priority, relevance, etc.
>
> Regards,
>
> PCM (pc_m)
>
> __
> OpenStack Development Mailing 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] [Openstack] Errors in neutron-server while launching VM

[Elena Ezhova]

Rahul,

Firstly, you have to choose a database.

mysql> use neutron;
mysql> show tables;
mysql> select *  from networks;

On Fri, Oct 16, 2015 at 3:29 PM, Rahul Arora 
wrote:

> Hi Nitish,
>
> When i am trying to see table "networks" in the DB.I am not able to use
> "show tables" command to see tables.looks like it this version does not
> suppor that.
>
> List of all MySQL commands:
> Note that all text commands must be first on line and end with ';'
> ? (\?) Synonym for `help'.
> clear (\c) Clear the current input statement.
> connect   (\r) Reconnect to the server. Optional arguments are db and host.
> delimiter (\d) Set statement delimiter.
> edit  (\e) Edit command with $EDITOR.
> ego   (\G) Send command to mysql server, display result vertically.
> exit  (\q) Exit mysql. Same as quit.
> go(\g) Send command to mysql server.
> help  (\h) Display this help.
> nopager   (\n) Disable pager, print to stdout.
> notee (\t) Don't write into outfile.
> pager (\P) Set PAGER [to_pager]. Print the query results via PAGER.
> print (\p) Print current command.
> prompt(\R) Change your mysql prompt.
> quit  (\q) Quit mysql.
> rehash(\#) Rebuild completion hash.
> source(\.) Execute an SQL script file. Takes a file name as an
> argument.
> status(\s) Get status information from the server.
> system(\!) Execute a system shell command.
> tee   (\T) Set outfile [to_outfile]. Append everything into given
> outfile.
> use   (\u) Use another database. Takes database name as argument.
> charset   (\C) Switch to another charset. Might be needed for processing
> binlog with multi-byte charsets.
> warnings  (\W) Show warnings after every statement.
> nowarning (\w) Don't show warnings after every statement.
>
> For server side help, type 'help contents'
>
> mysql>
>
>
> Can you please redirect me how i can see this?
>
> --
>
> Regards
>
> Rahul Arora
>
> On Fri, Oct 16, 2015 at 3:52 PM, nithish B 
> wrote:
>
>> Hi Rahul,
>> Is the table "networks" available in the DB? Looks like it does not exist
>> and thus when neutron queries the DB, it returns the error.
>> Let me know.
>>
>> Thanks.
>> Nitish B.
>>
>> Regards,
>> Nitish B.
>>
>> On Fri, Oct 16, 2015 at 3:10 PM, Rahul Arora 
>> wrote:
>>
>>> Hi Team.
>>>
>>> I am trying to run Openstack KILO release on my Ubuntu 14.04 x86
>>> machine.I am able to run all the services.i.e glance,nova.keystone,neutron
>>> etc successfully.
>>>
>>> But when i am trying to launch VM using below command manually.
>>>
>>> *nova boot --image 8f6e2973-c048-4445-8c31-38e159c930fc --flavor m1.tiny
>>> "rahul"*
>>>
>>> I am getting below error in *neutron-server *service.
>>> =
>>>
>>>
>>> 2015-10-06 02:29:53.894 8064 TRACE neutron.api.v2.resource
>>> self.errorhandler(self, exc, value)
>>> 2015-10-06 02:29:53.894 8064 TRACE neutron.api.v2.resource   File
>>> "/usr/lib/python2.7/site-packages/MySQLdb/connections.py", line 36, in
>>> defaulterrorhandler
>>> 2015-10-06 02:29:53.894 8064 TRACE neutron.api.v2.resource raise
>>> errorclass, errorvalue
>>> 2015-10-06 02:29:53.894 8064 TRACE neutron.api.v2.resource OperationalError:
>>> (OperationalError) (1054, "Unknown column 'networks.mtu' in 'field list'")
>>> 'SELECT networks.tenant_id AS networks_tenant_id, networks.id AS
>>> networks_id, networks.name AS networks_name, networks.status AS
>>> networks_status, networks.admin_state_up AS networks_admin_state_up,
>>> networks.shared AS networks_shared, networks.mtu AS networks_mtu,
>>> networks.vlan_transparent AS networks_vlan_transparent,
>>> ipallocationpools_1.id AS ipallocationpools_1_id,
>>> ipallocationpools_1.subnet_id AS ipallocationpools_1_subnet_id,
>>> ipallocationpools_1.first_ip AS ipallocationpools_1_first_ip,
>>> ipallocationpools_1.last_ip AS ipallocationpools_1_last_ip,
>>> dnsnameservers_1.address AS dnsnameservers_1_address,
>>> dnsnameservers_1.subnet_id AS dnsnameservers_1_subnet_id,
>>> subnetroutes_1.destination AS subnetroutes_1_destination,
>>> subnetroutes_1.nexthop AS subnetroutes_1_nexthop, subnetroutes_1.subnet_id
>>> AS subnetroutes_1_subnet_id, subnets_1.tenant_id AS subnets_1_tenant_id,
>>> subnets_1.id AS subnets_1_id, subnets_1.name AS subnets_1_name,
>>> subnets_1.network_id AS subnets_1_network_id, subnets_1.subnetpool_id AS
>>> subnets_1_subnetpool_id, subnets_1.ip_version AS subnets_1_ip_version,
>>> subnets_1.cidr AS subnets_1_cidr, subnets_1.gateway_ip AS
>>> subnets_1_gateway_ip, subnets_1.enable_dhcp AS subnets_1_enable_dhcp,
>>> subnets_1.shared AS subnets_1_shared, subnets_1.ipv6_ra_mode AS
>>> subnets_1_ipv6_ra_mode, subnets_1.ipv6_address_mode AS
>>> subnets_1_ipv6_address_mode, externalnetworks_1.network_id AS
>>> externalnetworks_1_network_id \nFROM networks LEFT OUTER JOIN
>>> externalnetworks ON networks.id = externalnetworks.network_id LEFT
>>> OUTER JOIN subnets AS subnets_1 ON networks.id = subnets_1.network_id
>>> LEFT OUTER JOIN 

Re: [openstack-dev] The state of systemd _sd_notify & oslo.service in OpenStack

[Elena Ezhova]

Hi,

We used a Launchpad bug [1] to track the process of moving to graduated
oslo.service so you can refer to the list of affected projects.

_sd_notify is called when a service is launched just before a wait loop
[2], [3] so you can check projects from [1] and look for those that start
services using ServiceLauncher or ProcessLauncher.

[1] https://bugs.launchpad.net/neutron/+bug/1466851
[2]
https://github.com/openstack/oslo.service/blob/master/oslo_service/service.py#L277
[3]
https://github.com/openstack/oslo.service/blob/master/oslo_service/service.py#L503

Thanks,
Elena

On Tue, Oct 13, 2015 at 10:01 AM, Thomas Goirand  wrote:

> Hi,
>
> As oslo.service implements _sd_notify, I am deeply thinking about
> switching Debian .service files to use Type=notify instead of
> Type=simple (which is the default, and what OpenStack packages are using
> in Debian).
>
> Though I'm not sure about the state of things. Which package has
> switched to using oslo.service, and is _sd_notify always called when a
> package declares a dependency on oslo.service? Could someone confirm a
> list of projects for which I could enable Type=notify in all daemons?
>
> Cheers,
>
> Thomas Goirand (zigo)
>
> __
> OpenStack Development Mailing 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] [openstack][oslo.service] Manage of openstack services by ProcessLauncher

[Elena Ezhova]

Thank you for bringing it up, Marian!

On Mon, Aug 17, 2015 at 5:29 PM, mhorban  wrote:

> Most of openstack services use ProcessLauncher(located in oslo.services)
> to run services, fork new worker processes, reload configuration, etc.
> Initialization of services in master process usually contains opening of
> sockets, so that socket will be inherited in child processes. Then
> master(parent) process spawns(with fork call) children. Communication
> between master process and children is implemented with signals, for
> example when master process wants to shutdown children it sends SIGTERM
> signal to children, to reload children config master process sends SIGHUP
> signal.
>
> I would like to discuss three things:
>

The first two points also apply to ServiceLauncher which is used to start
services in case a number of workers is 0 or 1:


> 1. Behaviour of reloading configuration in children processes.


If a service receives SIGHUP it is restarted which implies calling stop,
reset and then start.

2. Additional way to control of master process.
>

 ServiceLauncher handles the same signals as ProcessLauncher.


> 3. Communication between master and children processes.


> 1. Behaviour of reloading configuration in children processes.
> Now we can reload processes by sending SIGHUP to master process. Master
> process reloads its own configuration and sends SIGHUP signal to children.
> When child process receives SIGHUP signal it loads config file, stops and
> starts service. During stopping-starting service new config options usually
> don't applied because there should be written a lot of code to manage
> cofiguration changes. rpodolyaka expressed idea to shutdown children during
> reloading configuration and respawn new workers. This approach frees us of
> implementing a huge amount of service-related code for reloading
> configuration of specific objects. Apache and NGINX uses the same reloading
> approach: gracefully stop children and start new child instances.
>

>From my point of view, this is a double-edged sword. On the one hand,
respawning workers would indeed free us from writing reset logic for each
service and save a lot of effort and time. On the other hand, the idea
behind using SIGHUPs was to have an ability to make changing configuration
as instantaneous and invisible to users as possible, ideally without
stopping services. If we choose not to stop services at all (i.e. getting
rid of calling stop and start on receiving SIGHUP) we'll be able to
implement flexible configuration reloading (for example, changes to the RPC
section of a config will invoke only re-initialization of RPC connections
while db connections wouldn't be affected in any way).
But this approach is really quite complex so I think we have to weight the
pros and cons before making a decision.

>
> 2. Additional way to control of master process.
> Right now we can control ProcessLauncher by sending signals to master
> process. It is the only way to manage it. The problem is that such approach
> is not platform independent. We already faced an issue: Windows doesn't
> support SIGHUP signal, so part of functionality is inaccessible in Windows
> :(. Usually process containers like ProcessLauncher could be managed by CLI
> too. What do you think about creating listening interface for incoming
> commands?
>

So, the main problem here is the lack of functionality on Windows. I see
several ways how to solve this problem:

1. Send commands to a master process like Marian suggests. As a transport
we can use sockets or pipes (need to research how are pipes implemented on
Windows).
2. Accept one of the signals available on Windows as SIGHUP. There are
quite a few of them [1], [2] but it'll still require some research on how
Windows implements signals.
3. Do nothing. The fact that oslo.service currently doesn't support SIGHUP
on Windows is documented and Windows users can simply restart a service if
they need to reload config files.


> 3. Communication between master and children processes.
> Master process uses signals to control children. Since many signals are
> not supported on some platforms I suggest to replace signal mechanism with
> pipes. Each of children will listen to input commands on one side of pipe
> and master process will write commands on the other side of pipe.
>

Pipes might be a good idea, but again we shouldn't remove handlers in
children at least for those signals that are supported on all platforms
(SIGINT and SIGTERM). There can be situations when we need to send a
termination signal to some of the workers directly.

Just my 2 cents :)



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

[1] https://docs.python.org/2/library/signal.html#signal.signal
[2] https:/

Re: [openstack-dev] [oslo] How should oslo.service handle SIGINT?

[Elena Ezhova]

@Dims,

The main advantage of having a handler is a more clean output in case a
service is killed, which means there wouldn't be a stacktrace with
KeyboardInterrupt
exception, just messages like we have in nova now (nova "Switch to
oslo.service patch" hadn't merged yet):

2015-07-21 10:46:06.765 INFO nova.openstack.common.service
[req-b65dd702-4407-4442-941b-bdb45d935cfa None None] Caught SIGINT,
stopping children
2015-07-21 10:46:06.779 INFO nova.openstack.common.service
[req-b65dd702-4407-4442-941b-bdb45d935cfa None None] Waiting on 2 children
to exit
2015-07-21 10:46:06.823 INFO nova.openstack.common.service
[req-b65dd702-4407-4442-941b-bdb45d935cfa None None] Child 14490 killed by
signal 15
2015-07-21 10:46:06.830 INFO nova.openstack.common.service
[req-b65dd702-4407-4442-941b-bdb45d935cfa None None] Child 14491 killed by
signal 15

That looks more clean than KeyboardInterrupt:
http://paste.openstack.org/show/395226/


Elena




On Mon, Jul 20, 2015 at 8:22 PM, Davanum Srinivas  wrote:

> @Elena,
>
> What are the pro's and con's of "having a handler" as this was the
> existing behavior for all the projects that picked up code from
> oslo-incubator for this behavior?
>
> -- dims
>
> On Mon, Jul 20, 2015 at 1:12 PM, Elena Ezhova 
> wrote:
> > Hi!
> >
> > Not so long ago oslo.service had a handler for SIGINT and on receiving
> this
> > signal a process killed all children with SIGTERM and exited.
> > Change [1], that added graceful shutdown on SIGTERM, removed all SIGINT
> > handlers and currently all services that consume oslo.service generate
> > KeyboardInterrupt exceptions on receiving SIGINT.
> >
> > My question is whether such behavior is what users and operators expect
> or
> > having a handler is still the preferred way?
> >
> >
> > Thanks, Elena
> >
> > [1]
> >
> https://github.com/openstack/oslo.service/commit/fa9aa6b665f75e610f2b91a7d310f6499bd71770
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
>
>
> --
> Davanum Srinivas :: https://twitter.com/dims
>
> __
> OpenStack Development Mailing 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] [oslo] How should oslo.service handle SIGINT?

[Elena Ezhova]

Hi!

Not so long ago oslo.service had a handler for SIGINT and on receiving this
signal a process killed all children with SIGTERM and exited.
Change [1], that added graceful shutdown on SIGTERM, removed all SIGINT
handlers and currently all services that consume oslo.service generate
KeyboardInterrupt exceptions on receiving SIGINT.

My question is whether such behavior is what users and operators expect or
having a handler is still the preferred way?


Thanks, Elena

[1]
https://github.com/openstack/oslo.service/commit/fa9aa6b665f75e610f2b91a7d310f6499bd71770
__
OpenStack Development Mailing 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] [oslo][service] oslo.service puplic repositiry review request

[Elena Ezhova]

Hi all,

The spec for the graduation of oslo.service [1] has merged. I created
review requests to project-config [2] and governance [3] and would really
welcome any reviews.

Thanks, Elena

[1] https://review.openstack.org/#/c/142659/9
[2] https://review.openstack.org/#/c/185324/
[3] https://review.openstack.org/#/c/185327/

On Thu, May 21, 2015 at 5:38 PM, Elena Ezhova  wrote:

> Hi, all!
>
> As the spec for the graduation of oslo.service [1] is about to merge I
> have created a public repository on github [2] with oslo.service initial
> version, which is the next step in graduation of a library according to [3].
>
> I would like to ask everyone interested to review it so we can proceed
> with the graduation process.
>
> Thanks, Elena
>
>
> [1] https://review.openstack.org/#/c/142659/9
> [2] https://github.com/eezhova/oslo.service
> [3] https://wiki.openstack.org/wiki/Oslo/CreatingANewLibrary
>
__
OpenStack Development Mailing 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] [oslo][service] oslo.service puplic repositiry review request

[Elena Ezhova]

Hi, all!

As the spec for the graduation of oslo.service [1] is about to merge I have
created a public repository on github [2] with oslo.service initial
version, which is the next step in graduation of a library according to [3].

I would like to ask everyone interested to review it so we can proceed with
the graduation process.

Thanks, Elena


[1] https://review.openstack.org/#/c/142659/9
[2] https://github.com/eezhova/oslo.service
[3] https://wiki.openstack.org/wiki/Oslo/CreatingANewLibrary
__
OpenStack Development Mailing 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] [oslo.messaging][zmq] Redundant zmq.Context creation

[Elena Ezhova]

On Fri, Jan 23, 2015 at 1:55 PM, Ilya Pekelny  wrote:

>
>
> On Fri, Jan 23, 2015 at 12:46 PM, ozamiatin 
> wrote:
>
>> IMHO It should be created once per Reactor/Client or even per driver
>> instance.
>>
>
> Per driver, sounds good.
>
Wouldn't this create regression for Neutron? The original change was
supposed to fix the bug [1], where each api-worker process got the same
copy of the Context due to its singletony nature.

>
>
>>
>> By the way (I didn't check it yet with current implementation of the
>> driver) such approach should break the IPC, because such kind of sockets
>> should be produced from the same context.
>>
>
> Please, check it. Looks like a potential bug.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
[1] https://bugs.launchpad.net/neutron/+bug/1364814
__
OpenStack Development Mailing 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] Killing connection after security group rule deletion

[Elena Ezhova]

As I found out there already is a change made by Xurong Yang that assigns
conntrack zones to ports https://review.openstack.org/#/c/118274/6
If merged, it will make connection tracking easier and will allow to add
functionality for closing connections after updating or deleting security
group rules. I will try to add this functionality basing on the existing
patch and see if it works.
I believe that the change requires attention and discussion as there are
some concerns regarding it. Perhaps somebody could take a look it?

On Fri, Oct 24, 2014 at 9:28 PM, Carl Baldwin  wrote:

> On Fri, Oct 24, 2014 at 6:17 AM, Salvatore Orlando 
> wrote:
> > Assigning a distinct ct zone to each port sounds more scalable. This
> should
> > keep the number of zones per host
>
> Agree that zones could be a good solution to this problem.  +1 to zone
> / port for scalability.  Though it will take a bit more code and
> complexity to kill the right connections than it would with zone /
> rule.
>
> > Once we identify the ports, and therefore the ct zones, then we'd still
> need
> > to find the connections matching the rules which were removed. This does
> not
> > sound like being too difficult, but it can result in searches over long
> > lists - think about an instance hosting a DB or web server.
>
> Are you thinking of listing all connections and then iterating over
> the list with some code to match it to a security group rule being
> removed/updated?  Or, map the security group rule to conntrack filter
> arguments to send to a call to conntrack -D?
>
> This could be problematic.  What if security group rules were
> redundant and an update or removal of a rule should not really affect
> any existing connections?  If all connections were compared instead
> against the set of *remaining* security group rules then this wouldn't
> be a problem.  This sounds non-trivial to me.  I'm probably thinking
> too hard about this.  ;)
>
> > The above two considerations made me suggest the idea of associating ct
> > zones with rules, but it is probably true that this can cause us to go
> > beyond the 2^16 limit.
>
> I agree we'd hit this limit.
>
> Carl
>
> ___
> 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] Killing connection after security group rule deletion

[Elena Ezhova]

Hi!

I am working on a bug "ping still working once connected even after related
security group rule is deleted" (
https://bugs.launchpad.net/neutron/+bug/1335375). The gist of the problem
is the following: when we delete a security group rule the corresponding
rule in iptables is also deleted, but the connection, that was allowed by
that rule, is not being destroyed.
The reason for such behavior is that in iptables we have the following
structure of a chain that filters input packets for an interface of an
istance:

Chain neutron-openvswi-i830fa99f-3 (1 references)
 pkts bytes target prot opt in out source
destination
0 0 DROP   all  --  *  *   0.0.0.0/0
0.0.0.0/0state INVALID /* Drop packets that are not associated
with a state. */
0 0 RETURN all  --  *  *   0.0.0.0/0
0.0.0.0/0state RELATED,ESTABLISHED /* Direct packets associated
with a known session to the RETURN chain. */
0 0 RETURN udp  --  *  *   10.0.0.3
0.0.0.0/0udp spt:67 dpt:68
0 0 RETURN all  --  *  *   0.0.0.0/0
0.0.0.0/0match-set IPv43a0d3610-8b38-43f2-8 src
0 0 RETURN tcp  --  *  *   0.0.0.0/0
0.0.0.0/0tcp dpt:22  < rule that allows ssh on port 22

184 RETURN icmp --  *  *   0.0.0.0/0
0.0.0.0/0
0 0 neutron-openvswi-sg-fallback  all  --  *  *   0.0.0.0/0
   0.0.0.0/0/* Send unmatched traffic to the fallback
chain. */

So, if we delete rule that allows tcp on port 22, then all connections that
are already established won't be closed, because all packets would satisfy
the rule:
0 0 RETURN all  --  *  *   0.0.0.0/00.0.0.0/0
 state RELATED,ESTABLISHED /* Direct packets associated with a
known session to the RETURN chain. */

I seek advice on the way how to deal with the problem. There are a couple
of ideas how to do it (more or less realistic):

   - Kill the connection using conntrack

  The problem here is that it is sometimes impossible to tell which
connection should be killed. For example there may be two instances running
in different namespaces that have the same ip addresses. As a compute
doesn't know anything about namespaces, it cannot distinguish between the
two seemingly identical connections:
 $ sudo conntrack -L  | grep "10.0.0.5"
 tcp  6 431954 ESTABLISHED src=10.0.0.3 dst=10.0.0.5
sport=60723 dport=22 src=10.0.0.5 dst=10.0.0.3 sport=22 dport=60723
[ASSURED] mark=0 use=1
 tcp  6 431976 ESTABLISHED src=10.0.0.3 dst=10.0.0.5
sport=60729 dport=22 src=10.0.0.5 dst=10.0.0.3 sport=22 dport=60729
[ASSURED] mark=0 use=1

I wonder whether there is any way to search for a connection by destination
MAC?

   - Delete iptables rule that directs packets associated with a known
   session to the RETURN chain

   It will force all packets to go through the full chain each time
and this will definitely make the connection close. But this will strongly
affect the performance. Probably there may be created a timeout after which
this rule will be restored, but it is uncertain how long should it be.

Please share your thoughts on how it would be better to handle it.

Thanks in advance,
Elena
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron] Creating resources for non-existent tenants

[Elena Ezhova]

Hi, all!

I have been looking at the bug
https://bugs.launchpad.net/neutron/+bug/1338885 and it turned out that it
is relevant not only for firewall rules but for all resources that take
tenant-is for create and update.

I need a piece of advice on a preferable way of solving the problem.

First of all, there may be two situations:

1. Neutron using Keystone

2. Neutron working without it

In the second case there is obviously nothing to be done.

But when Neutron uses Keystone, tenant-id should be checked against
existing keystone tenants. I can think of 2 ways of doing this. This may be
done either by calling keystone client directly from neutron while
preparing request body [1] or move the check to keystone middleware. In any
case, such check will be performed during each create or update operation
preventing admin from providing non-existent tenants. For now I think that
calling the keystone client from Neutron code is not the best idea and
prefer the second option. I would really appreciate recommendations about
the best way of making the check.

It still leaves the situation when an existing tenant is deleted from
keystone and its resources are left orphaned, but it is being dealt with by
[2].

Thanks,

Elena


[1]
https://github.com/openstack/neutron/blob/master/neutron/api/v2/base.py#L545

[2] https://blueprints.launchpad.net/neutron/+spec/tenant-delete
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron] network_device_mtu is not applied to VMs

[Elena Ezhova]

Hi!

I feel I need a piece of advice regarding this bug [1].

The gist of the problem is that although there is an option
network_device_mtu that can be specified in neutron.conf VMs are not
getting that mtu on their interfaces. MTU can be specified by the dhcp
agent by adding the option to dnsmasq_config_file like it’s done here [2].
So one of the solutions might be to check whether the network_device_mtu is
specified during spawning of Dnsmasq process and if it is add an option to
Dnsmasq options file.

But I am not sure whether this is something worth being fixed and if the
above-described option is the right way to fix the bug.

By the way, as I found out, MTU cannot currently be set for instances that
are running cirros, because cirros does not handle dhcp options like it’s
said in the following bug. [3]

Regards, Elena Ezhova

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

[2]
https://ask.openstack.org/en/question/12499/forcing-mtu-to-1400-via-etcneutrondnsmasq-neutronconf-per-daniels/

[3] https://bugs.launchpad.net/cirros/+bug/1301958
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron] Cross-server locking for neutron server

[Elena Ezhova]

Hello everyone!

Some recent change requests ([1], [2]) show that there is a number of
issues with locking db resources in Neutron.

One of them is initialization of drivers which can be performed
simultaneously by several neutron servers. In this case locking is
essential for avoiding conflicts which is now mostly done via using
SQLAlchemy's
with_lockmode() method, which emits SELECT..FOR UPDATE resulting in rows
being locked within a transaction. As it has been already stated by Mike
Bayer [3], this statement is not supported by Galera and, what’s more, by
Postgresql for which a lock doesn’t work in case when a table is empty.

That is why there is a need for an easy solution that would allow
cross-server locking and would work for every backend. First thing that
comes into mind is to create a table which would contain all locks acquired
by various pieces of code. Each time a code, that wishes to access a table
that needs locking, would have to perform the following steps:

1. Check whether a lock is already acquired by using SELECT lock_name FROM
cross_server_locks table.

2. If SELECT returned None, acquire a lock by inserting it into the
cross_server_locks table.

   In other case wait and then try again until a timeout is reached.

3. After a code has executed it should release the lock by deleting the
corresponding entry from the cross_server_locks table.

The locking process can be implemented by decorating a function that
performs a transaction by a special function, or as a context manager.

Thus, I wanted to ask the community whether this approach deserves
consideration and, if yes, it would be necessary to decide on the format of
an entry in cross_server_locks table: how a lock_name should be formed,
whether to support different locking modes, etc.


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

[2] https://review.openstack.org/#/c/107350/

[3]
https://wiki.openstack.org/wiki/OpenStack_and_SQLAlchemy#Pessimistic_Locking_-_SELECT_FOR_UPDATE
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [devstack] [zmq] [oslo.messaging] Running devstack with zeromq

[Elena Ezhova]

I have managed to make zmq work using matchmaker ring, but I haven't tried
it with more than one server.
There are proposed fixes for the bugs that Mehdi mentioned (
https://review.openstack.org/#/c/100236/,
https://review.openstack.org/#/c/84938/).

But in any case, if zmq really is not used by anybody, then there is no
reason to maintain it.


On Thu, Jun 19, 2014 at 5:46 PM, Sean Dague  wrote:

> On 06/19/2014 09:39 AM, Mark McLoughlin wrote:
> > On Thu, 2014-06-19 at 14:29 +0200, Mehdi Abaakouk wrote:
> >> Hi,
> >>
> >> Le 2014-06-19 00:30, Ben Nemec a écrit :
> >>> On 06/18/2014 05:45 AM, Elena Ezhova wrote:
> >>>
> >>>> So I wonder whether it is something the community is interested in
> >>>> and, if
> >>>> yes, are there any recommendations concerning possible implementation?
> >>>
> >>> I can't speak to the specific implementation, but if we're going to
> >>> keep
> >>> the zmq driver in oslo.messaging then IMHO it should be usable with
> >>> devstack, so +1 to making that work.
> >>
> >> Currently the zmq driver have a really bad test coverage, the driver is
> >> 'I think' broken since a while.
> >>
> >> Bugs like [1] or [2] let me think that nobody can use it currently.
> >>
> >> [1] https://bugs.launchpad.net/oslo.messaging/+bug/1301723
> >> [2] https://bugs.launchpad.net/oslo.messaging/+bug/1330460
> >>
> >> Also, an oslo.messaging rule is "a driver must not force to use a
> >> eventloop library",
> >> but this one heavily use eventlet. So only the eventlet executor can
> >> works with it, not the
> >> blocking one or any future executor.
> >>
> >> I guess if someone is interested in, the first step is to fix the zmq
> >> driver, remove eventlet stuffs and write unit tests for it,
> >> before trying integration, and raise bugs that should be catch by
> >> unit/functionnal testing.
> >>
> >> If nobody is interested in zmq, perhaps we should just
> >> drop/deprecated/mark_as_broken it.
> >
> > Yes, I agree with all of that. Unless the situation improves rapidly, I
> > think we should mark it as deprecated in Juno and plan to remove it in
> > K. That might seem like an overly rapid deprecation cycle, but it is
> > currently broken and unusable in Icehouse ... so no-one can be using it
> > in Icehouse.
>
> +1. No one has been maintaining zmq in the community for quite some
> time, so we should mark it as such. Much better to signal to people that
> features aren't working vs. letting them discover that on their own.
>
> -Sean
>
> --
> Sean Dague
> 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] [devstack] [zmq] [oslo.messaging] Running devstack with zeromq

[Elena Ezhova]

Hello!

I have been exploring bugs connected with using devstack with zmq [1], [2],
[3] and experimenting with various configurations in attempt to make zmq
work with projects which have moved to oslo.messaging. It turned out that
there is a number of things to fix.

Firstly, even though nova currently uses oslo.messaging, devstack still
uses nova-rpc-zmq-receiver instead of oslo-messaging-zmq-receiver when
starting zeromq receiver.

Secondly, the default matchmaker for zmq is always set as MatchmakerRedis
(which currently does not work either) and there is no opportunity to
specify anything else (e.g. MatchmakerRing) using devstack. If there was an
option to use MatchmakerRing, it would have been possible to create a
configuration file matchmaker_ring.json in etc/oslo/ directory and write
there all key-value pairs needed by zmq.

So I wonder whether it is something the community is interested in and, if
yes, are there any recommendations concerning possible implementation?


Thanks,
Elena

[1] - https://bugs.launchpad.net/devstack/+bug/1279739
[2] - https://bugs.launchpad.net/neutron/+bug/1298803
[3] - https://bugs.launchpad.net/oslo.messaging/+bug/1290772
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Neutron error using devstack

[Elena Ezhova]

If you want to use Neutron with devstack you have to add the related
settings to localrc.

Please see https://wiki.openstack.org/wiki/NeutronDevstack for detailed
instructions.
01 марта 2014 г. 22:11 пользователь "abhishek jain" 
написал:

> Hi all
>
> I have installed devstack successfully from the following link...
>
>
> http://www.linux.com/learn/tutorials/721712-intro-to-openstack-part-two-how-to-install-and-configure-openstack-on-a-server
>
> However I'm not able to run the neutron services.The error which generally
> comes after running neutron command is as follows.
>
> neutron subnet-create vxlan-net 10.100.1.0/24 --name vxlan-net
>
> You must provide a username via either --os-username or env[OS_USERNAME]
>
> ashu@ashu $ ps -ef | grep neutron
> ashu31039 30660  0 18:09 pts/25   00:00:00 grep --color=auto neutron
>
> Please help regarding this
>
> ___
> 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][QA]

[Elena Ezhova]

Hi!

I am writing API tests for binding extended attributes for ports and I
faced an issue that looks strange to me.

The problem is that when you try to create a port with empty
binding:host_id attribute the returned value depends on a plugin. For an
instance, ml2 returns an empty string ("binding:host_id": "") while for NSX
it is null ("binding:host_id": null).

Is it supposed to be this way or there should be a uniform format?

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

Re: [openstack-dev] [Cinder][Glance] OSLO update

[Elena Ezhova]

But what if I want to update some module that consists of ten or even more
files (like rpc or db) and each of these files has quite a long change log?
In that case the commit message may turn out to be really long even if only
commit ids and names are included.


On Wed, Nov 20, 2013 at 12:37 PM, Elena Ezhova  wrote:

>
> 20.11.2013, 06:18, "John Griffith" :
>
> On Mon, Nov 18, 2013 at 3:53 PM, Mark McLoughlin 
> wrote:
>
> >  On Mon, 2013-11-18 at 17:24 +, Duncan Thomas wrote:
> >>  Random OSLO updates with no list of what changed, what got fixed etc
> >>  are unlikely to get review attention - doing such a review is
> >>  extremely difficult. I was -2ing them and asking for more info, but
> >>  they keep popping up. I'm really not sure what the best way of
> >>  updating from OSLO is, but this isn't it.
> >  Best practice is to include a list of changes being synced, for example:
> >
> >https://review.openstack.org/54660
> >
> >  Every so often, we throw around ideas for automating the generation of
> >  this changes list - e.g. cinder would have the oslo-incubator commit ID
> >  for each module stored in a file in git to tell us when it was last
> >  synced.
> >
> >  Mark.
> >
> >  _
>>
>> __
>> >  OpenStack-dev mailing list
>> >  OpenStack-dev@lists.openstack.org
>> >  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> Been away on vacation so I'm afraid I'm a bit late on this... but;
>>
>> I think the point Duncan is bringing up here is that there are some
>> VERY large and significant patches coming from OSLO pulls.  The DB
>> patch in particular being over 1K lines of code to a critical portion
>> of the code is a bit unnerving to try and do a review on.  I realize
>> that there's a level of trust that goes with the work that's done in
>> OSLO and synchronizing those changes across the projects, but I think
>> a few key concerns here are:
>>
>> 1. Doing huge pulls from OSLO like the DB patch here are nearly
>> impossible to thoroughly review and test.  Over time we learn a lot
>> about real usage scenarios and the database and tweak things as we go,
>> so seeing a patch set like this show up is always a bit unnerving and
>> frankly nobody is overly excited to review it.
>>
>> 2. Given a certain level of *trust* for the work that folks do on the
>> OSLO side in submitting these patches and new additions, I think some
>> of the responsibility on the review of the code falls on the OSLO
>> team.  That being said there is still the issue of how these changes
>> will impact projects *other* than Nova which I think is sometimes
>> neglected.  There have been a number of OSLO synchs pushed to Cinder
>> that fail gating jobs, some get fixed, some get abandoned, but in
>> either case it shows that there wasn't any testing done with projects
>> other than Nova (PLEASE note, I'm not referring to this particular
>> round of patches or calling any patch set out, just stating a
>> historical fact).
>>
>> 3. We need better documentation in commit messages explaining why the
>> changes are necessary and what they do for us.  I'm sorry but in my
>> opinion the answer "it's the latest in OSLO and Nova already has it"
>> is not enough of an answer in my opinion.  The patches mentioned in
>> this thread in my opinion met the minimum requirements because they at
>> least reference the OSLO commit which is great.  In addition I'd like
>> to see something to address any discovered issues or testing done with
>> the specific projects these changes are being synced to.
>>
>> I'm in no way saying I don't want Cinder to play nice with the common
>> code or to get in line with the way other projects do things but I am
>> saying that I think we have a ways to go in terms of better
>> communication here and in terms of OSLO code actually keeping in mind
>> the entire OpenStack eco-system as opposed to just changes that were
>> needed/updated in Nova.  Cinder in particular went through some pretty
>> massive DB re-factoring and changes during Havana and there was a lot
>> of really good work there but it didn't come without a cost and the
>> benefits were examined and weighed pretty heavily.  I also think that
>> some times the indirection introduced by adding some of the
>> openstack.common code is unnecessary and in some cases makes things
>> more difficult than they should be.
>>
>>

Re: [openstack-dev] [Cinder][Glance] OSLO update

[Elena Ezhova]

20.11.2013, 06:18, "John Griffith" :

On Mon, Nov 18, 2013 at 3:53 PM, Mark McLoughlin  wrote:

>  On Mon, 2013-11-18 at 17:24 +, Duncan Thomas wrote:
>>  Random OSLO updates with no list of what changed, what got fixed etc
>>  are unlikely to get review attention - doing such a review is
>>  extremely difficult. I was -2ing them and asking for more info, but
>>  they keep popping up. I'm really not sure what the best way of
>>  updating from OSLO is, but this isn't it.
>  Best practice is to include a list of changes being synced, for example:
>
>https://review.openstack.org/54660
>
>  Every so often, we throw around ideas for automating the generation of
>  this changes list - e.g. cinder would have the oslo-incubator commit ID
>  for each module stored in a file in git to tell us when it was last
>  synced.
>
>  Mark.
>
>  _
>
> __
> >  OpenStack-dev mailing list
> >  OpenStack-dev@lists.openstack.org
> >  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> Been away on vacation so I'm afraid I'm a bit late on this... but;
>
> I think the point Duncan is bringing up here is that there are some
> VERY large and significant patches coming from OSLO pulls.  The DB
> patch in particular being over 1K lines of code to a critical portion
> of the code is a bit unnerving to try and do a review on.  I realize
> that there's a level of trust that goes with the work that's done in
> OSLO and synchronizing those changes across the projects, but I think
> a few key concerns here are:
>
> 1. Doing huge pulls from OSLO like the DB patch here are nearly
> impossible to thoroughly review and test.  Over time we learn a lot
> about real usage scenarios and the database and tweak things as we go,
> so seeing a patch set like this show up is always a bit unnerving and
> frankly nobody is overly excited to review it.
>
> 2. Given a certain level of *trust* for the work that folks do on the
> OSLO side in submitting these patches and new additions, I think some
> of the responsibility on the review of the code falls on the OSLO
> team.  That being said there is still the issue of how these changes
> will impact projects *other* than Nova which I think is sometimes
> neglected.  There have been a number of OSLO synchs pushed to Cinder
> that fail gating jobs, some get fixed, some get abandoned, but in
> either case it shows that there wasn't any testing done with projects
> other than Nova (PLEASE note, I'm not referring to this particular
> round of patches or calling any patch set out, just stating a
> historical fact).
>
> 3. We need better documentation in commit messages explaining why the
> changes are necessary and what they do for us.  I'm sorry but in my
> opinion the answer "it's the latest in OSLO and Nova already has it"
> is not enough of an answer in my opinion.  The patches mentioned in
> this thread in my opinion met the minimum requirements because they at
> least reference the OSLO commit which is great.  In addition I'd like
> to see something to address any discovered issues or testing done with
> the specific projects these changes are being synced to.
>
> I'm in no way saying I don't want Cinder to play nice with the common
> code or to get in line with the way other projects do things but I am
> saying that I think we have a ways to go in terms of better
> communication here and in terms of OSLO code actually keeping in mind
> the entire OpenStack eco-system as opposed to just changes that were
> needed/updated in Nova.  Cinder in particular went through some pretty
> massive DB re-factoring and changes during Havana and there was a lot
> of really good work there but it didn't come without a cost and the
> benefits were examined and weighed pretty heavily.  I also think that
> some times the indirection introduced by adding some of the
> openstack.common code is unnecessary and in some cases makes things
> more difficult than they should be.
>
> I'm just not sure that we always do a very good ROI investigation or
> risk assessment on changes, and that opinion applies to ALL changes in
> OpenStack projects, not OSLO specific or anything else.
>
> All of that being said, a couple of those syncs on the list are
> outdated.  We should start by doing a fresh pull for these and if
> possible add some better documentation in the commit messages as to
> the justification for the patches that would be great.  We can take a
> closer look at the changes and the history behind them and try to get
> some review progress made here.  Mark mentioned some good ideas
> regarding capturing commit ID's from synchronization pulls and I'd
> like to look into that a bit as well.
>
> Thanks,
> John
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



I see now that updating OSLO is a far more complex issue than it may seem

[openstack-dev] [Cinder][Glance] OSLO update

[Elena Ezhova]

Hello all,

I have made several patches that update modules in cinder/openstack/common
from oslo which have not been reviewed for more than a month already. My
colleague has the same problem with her patches in Glance.

Probably it's not a top priority issue, but if oslo is not updated
periodically in small bits it may become a problem in the future. What's
more, it is much easier for a developer if oslo code is consistent in all
projects.

So, I would be grateful if someone reviewed these patches:
https://review.openstack.org/#/c/48272/
https://review.openstack.org/#/c/48273/
https://review.openstack.org/#/c/52099/
https://review.openstack.org/#/c/52101/
https://review.openstack.org/#/c/53114/
https://review.openstack.org/#/c/47581/

Thanks,

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