Re: [openstack-dev] Deprecation warnings considered harmful?
On Mar 15, 2015, at 7:35 AM, Duncan Thomas duncan.tho...@gmail.com wrote: On 13 March 2015 at 17:36, Doug Hellmann d...@doughellmann.com mailto:d...@doughellmann.com wrote: I wish we, as a community, were less obsessed with creating so many hacking rules. These are really minor changes and it's going to be a relatively short-lived issue that could just be fixed once. If there's a regression, fixing *that* won't be hard or take long. Ok, this comment has peaked my interest again, since I hold pretty much the exact opposite view and am a well known fan of hacking checks. My logic is: - Hacking checks point out the error for most submitters before review, saving reviewer time and CI cycles, and increasing the comfort level of the submitter (for most people, a -1 feels harsh/negative) - Hacking checks don't slip up and miss one because they are reviewing at 1am the night before the deadline - Regressions hurt, and not all of our code is covered by unit tests / CI - Debugging the output of a hacking check is many times faster than debugging a unit test, even for simple failures (and work is underway to may this even faster) - Hacking checks that are left around for migrations like this even a few cycles longer than they are needed have zero cost. As long as nobody type 'oslo.foo' then they never need even know of their existence. We can be really lazy about removing them with no harm at all. My comment was based on the observation that we have gone farther than I think is helpful with the checks, because we’ve started holding up other work until new checks can be implemented. That means we’re placing a higher priority on building our own tools than on building the thing we set out to build in the first place. When I updated tempest to use the graduated libraries instead of incubated code I did most of the work with a few calls to “sed -i”. I also didn’t have to wait for the hacking check to be implemented before I could start the cleanup/graduation work, which means now the work in tempest is *done* and I can move on to other work. Sometimes adding automation helps because of the need for an ongoing check, but in this case I don’t think it is warranted because of the nature of the change. If we successfully remove the namespace package next cycle and a regression is introduced before then, then broken imports just won’t work and the reason will be clearly stated in the error message Python gives. The problem is both easy to diagnose and easy to fix. We don’t need another check for that. Doug Am I missing something? I am a general proponent of 'write hacking checks for any mechanical code change'. We've seen definite benefits from this approach and few to no downsides that I'm aware of. __ OpenStack Development Mailing 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][horizon][infra] oslo.policy in django-openstack-auth fails with stable/juno global requirement check
Hi Oslo team, I am working on adopting the graduated oslo.policy in django-openstack-auth [1] but I have a question on how to migrate openstack.common.policy to oslo.policy in libraries which have no stable branch. django-openstack-auth has no stable branches as other python-*client. stable/juno global-requirements requries django_openstack_auth=1.1.7,!=1.1.8,=1.1.9, and the development is for 1.1.10 or 1.2.x, so I first thought it is no problem. However, in the review of [1], gate-tempest-dsvm-neutron-src-django_openstack_auth-juno fails with the error that oslo.policy is not in global-requirements in stable/juno. Is it a problem in the infra side? Or is it a thing we should avoid? Any advise will be appreciated. [1] https://review.openstack.org/#/c/164420/ Thanks, 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
Re: [openstack-dev] [nova] will instance action deprecate in feature
2015-03-11 15:57 GMT+08:00 Qiao, Liyong liyong.q...@intel.com: Hi all will instance action deprecate in feature since we have notify mechanism now? Currently, nova have instance action and instance event action to record specify actions performed on a instances. For some enterprise user, they may need to compute the latency when they perform an action on an instance. I check instance action only record the start time but no finish time. Instance action event have start time and finish time. But for 1 instance action , there may be several instance action event, so there is no necessary to check all instance action event, we only care about the action time itself, so a finished time is necessary to added into instance action. I made a patch to add finish time of instance action in [1](but need to fix unit test issue), I wonder if it is worthy to Spend time on debug unit test issue? Since I remember that instance action will be deprecated soon. Hi, Eli, Do you have any reference about 'deprecation' you said? [1] https://review.openstack.org/162910 Best Regards, Eli(Li Yong) Qiao. __ OpenStack Development Mailing 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! --- Lingxian Kong __ OpenStack Development Mailing 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] how safe is it to change NoAuthMiddlewareBase?
On Sat, 28 Feb 2015 09:51:27 -0700 Jay Pipes jaypi...@gmail.com wrote: On 02/26/2015 04:27 AM, Sean Dague wrote: In trying to move the flavor manage negative tests out of Tempest and into the Nova functional tree, I ran into one set of tests which are permissions checking. Basically that a regular user isn't allowed to do certain things. In (nearly) all our tests we use auth_strategy=noauth which takes you to NoAuthMiddlewareBase instead of to keystone. That path makes you an admin regardless of what credentials you send in - https://github.com/openstack/nova/blob/master/nova/api/openstack/auth.py#L56-L59 What I'd like to do is to change this so that if you specify user_id='admin' then is_admin is set true, and it's not true otherwise. That has a bunch of test fall out, because up until this point most of the test users are things like 'fake', which would regress to non admin. About 25% of the api samples tests fail in such a change, so they would need to be fixed. Taking a step back... what exactly is the purpose of the API samples functional tests? If the purpose of these tests has anything to do with validating some policy thing, then I suppose it's worth changing the auth middleware to support non-adminness. But, Historically I think its been a couple of reasons - to generate api samples for documentation purposes - to do more thorough testing of Nova that previously should have gone into tempest (but everything is moving back now right?) but writing tempests tests has been seen as too hard a postponed until after the Nova change has merged and then the intent has been lost. I don't think the API samples test purpose has anything to do with that (I think the purpose of the API samples tests is fuzzy, at best, actually). So, I'd just leave them as-is and not change anything at all. If we're moving stuff over from tempest to nova we definitely need to keep tracking of what has been done and what we need to do. Eg we need to find out what state we're in first. Definitely have picked up lots of issues in the past with the functional tests that the unitests have missed. Chris Best, -jay __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Deprecation warnings considered harmful?
On 13 March 2015 at 17:36, Doug Hellmann d...@doughellmann.com wrote: I wish we, as a community, were less obsessed with creating so many hacking rules. These are really minor changes and it's going to be a relatively short-lived issue that could just be fixed once. If there's a regression, fixing *that* won't be hard or take long. Ok, this comment has peaked my interest again, since I hold pretty much the exact opposite view and am a well known fan of hacking checks. My logic is: - Hacking checks point out the error for most submitters before review, saving reviewer time and CI cycles, and increasing the comfort level of the submitter (for most people, a -1 feels harsh/negative) - Hacking checks don't slip up and miss one because they are reviewing at 1am the night before the deadline - Regressions hurt, and not all of our code is covered by unit tests / CI - Debugging the output of a hacking check is many times faster than debugging a unit test, even for simple failures (and work is underway to may this even faster) - Hacking checks that are left around for migrations like this even a few cycles longer than they are needed have zero cost. As long as nobody type 'oslo.foo' then they never need even know of their existence. We can be really lazy about removing them with no harm at all. Am I missing something? I am a general proponent of 'write hacking checks for any mechanical code change'. We've seen definite benefits from this approach and few to no downsides that I'm aware of. __ OpenStack Development Mailing 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] Deprecation warnings considered harmful?
+2. I think the having checks are helpful. If they aren't removed it does Leelee harm. Jay On Mar 15, 2015 6:39 AM, Duncan Thomas duncan.tho...@gmail.com wrote: On 13 March 2015 at 17:36, Doug Hellmann d...@doughellmann.com wrote: I wish we, as a community, were less obsessed with creating so many hacking rules. These are really minor changes and it's going to be a relatively short-lived issue that could just be fixed once. If there's a regression, fixing *that* won't be hard or take long. Ok, this comment has peaked my interest again, since I hold pretty much the exact opposite view and am a well known fan of hacking checks. My logic is: - Hacking checks point out the error for most submitters before review, saving reviewer time and CI cycles, and increasing the comfort level of the submitter (for most people, a -1 feels harsh/negative) - Hacking checks don't slip up and miss one because they are reviewing at 1am the night before the deadline - Regressions hurt, and not all of our code is covered by unit tests / CI - Debugging the output of a hacking check is many times faster than debugging a unit test, even for simple failures (and work is underway to may this even faster) - Hacking checks that are left around for migrations like this even a few cycles longer than they are needed have zero cost. As long as nobody type 'oslo.foo' then they never need even know of their existence. We can be really lazy about removing them with no harm at all. Am I missing something? I am a general proponent of 'write hacking checks for any mechanical code change'. We've seen definite benefits from this approach and few to no downsides that I'm aware of. __ OpenStack Development Mailing 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] [cinder]Request to to revisit this patch
I agree with Walt that reverting this is the right answer. Please make sure to have your ci running as well for liberty. Jay On Mar 4, 2015 2:30 AM, Zhangni zhan...@huawei.com wrote: Hi Mike, Jay, and Walter, Please revisit this patch https://review.openstack.org/#/c/151959/ and don’t revert this, thank you very much! I think it’s apposite to merge the SDSHypervisor driver in cinder first, and next to request nova to add a new libvirt volume driver. Meanwhile nova side always ask whether the driver is merged into Cinder, please see my comments in nova spec https://review.openstack.org/#/c/130919/, thank you very much! Best regards ZhangNi __ OpenStack Development Mailing 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] [oslo][horizon][infra] oslo.policy in django-openstack-auth fails with stable/juno global requirement check
Excerpts from Akihiro Motoki's message of 2015-03-16 01:25:08 +0900: Hi Oslo team, I am working on adopting the graduated oslo.policy in django-openstack-auth [1] but I have a question on how to migrate openstack.common.policy to oslo.policy in libraries which have no stable branch. django-openstack-auth has no stable branches as other python-*client. stable/juno global-requirements requries django_openstack_auth=1.1.7,!=1.1.8,=1.1.9, and the development is for 1.1.10 or 1.2.x, so I first thought it is no problem. However, in the review of [1], gate-tempest-dsvm-neutron-src-django_openstack_auth-juno fails with the error that oslo.policy is not in global-requirements in stable/juno. Is it a problem in the infra side? Or is it a thing we should avoid? Any advise will be appreciated. All libraries should have stable branches going forward because we are capping requirements in the stable branches. See https://review.openstack.org/#/c/155072/ for details. Doug [1] https://review.openstack.org/#/c/164420/ Thanks, 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
Re: [openstack-dev] [neutron] Generic question about synchronizing neutron agent on compute node with DB
On 14 March 2015 at 11:19, Sławek Kapłoński sla...@kaplonski.pl wrote: Hello, I'm using ovs agents with L2 population mechanism in ML2 plugin. I noticed that sometimes agents don't receive proper RPC to add new vxlan tunnel openflow rules and then vxlan network between some compute nodes not working. I'm now using still havana release but want to upgrade to Juno. I was checking Juno code in l2 population mech driver and ovs plugin and I didn't find anything like periodic check if openflow rules are proper set or maybe resynced. Maybe it would be also good idea to add something like that to ovs agent? It would surely be a good idea to add some form of reliability into communications between server and agents. So far there are still several instances where the server sends a fire and forget notification to the agent, and does not take any step to ensure the state change associated with that notification has been actually applied to the agent. This applies also to some messages from the agent side, such as status change notifications. This is something that can be beneficial any neutron implementation which depends on one or more agents, not just for those using the ovs/linux bridge agents with the l2-population driver. Salvatore -- Pozdrawiam / Best regards Sławek Kapłoński sla...@kaplonski.pl Dnia piątek, 13 marca 2015 11:18:28 YAMAMOTO Takashi pisze: However, I briefly looked through the L2 agent code and didn't see a periodic task to resync the port information to protect from a neutron server that failed to send a notification because it crashed or lost its amqp connection. The L3 agent has a period sync routers task that helps in this regard. Maybe another neutron developer more familiar with the L2 agent can chime in here if I'm missing anything. i don't think you are missing anything. periodic sync would be a good improvement. YAMAMAOTO Takashi __ OpenStack Development Mailing 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] Generic question about synchronizing neutron agent on compute node with DB
The L2 agent, for instance, has a logic to perform full synchronisations with the server. These happens in two cases: 1) upon agent restart, as some messages from the server side might have gone lost 2) whenever a failure is detected on the agent side (this is probably a bit too conservative). Salvatore On 14 March 2015 at 10:51, Leo Y minh...@gmail.com wrote: Hello Rossella, I meant to something different, to less conventional changes. Right now, the network topology state is stored in neutron DB and each compute node knows about it by using neutron API per-request. Node knows means that neutron agents have this data stored in in-memory structures. In a case this synchronization is broken due a bug in software or (un)intentional change in neutron DB, I'd like to understand if the re-synchronization is possible. Right now, I know that L3 agent (I'm not sure if its working for all L3 agents) has periodic task that refreshes NIC information from neutron server. However, L2 agents don't have this mechanic. I don't know about agents that implement SDN. So, I'm looking to learn how the current neutron implementation deals with that problem. On Fri, Mar 13, 2015 at 10:52 AM, Rossella Sblendido rsblend...@suse.com wrote: On 03/07/2015 01:10 PM, Leo Y wrote: What happens when neutron DB is updated to change network settings (e.g. via Dashboard or manually) when there are communication sessions opened in compute nodes. Does it influence those sessions? When the update is propagated to compute nodes? Hi Leo, when you say change network settings I think you mean a change in the security group, is my assumption correct? In that case the Neutron server will notify all the L2 agent (they reside on each compute node) about the change. There are different kind of messages that the Neutron server sends depending on the type of the update, security_groups_rule_updated, security_groups_member_updated, security_groups_provider_updated. Each L2 agent will process the message and apply the required modification on the host. In the default implementation we use iptables to implement security group, so the update consists in some modifications of the iptables rules. Regarding the existing connections in the compute nodes they might not be affected by the change, which is a problem already discussed in this mail thread [1] and there's a patch in review to fix that [2]. Hope that answers your question. cheers, Rossella [1] http://lists.openstack.org/pipermail/openstack-dev/2014-October/049055.html [2] https://review.openstack.org/#/c/147713/ On 03/13/2015 04:10 AM, Kevin Benton wrote: Yeah, I was making a bad assumption for the l2 and l3. Sorry about that. It sounds like we don't have any protection against servers failing to send notifications. On Mar 12, 2015 7:41 PM, Assaf Muller amul...@redhat.com mailto:amul...@redhat.com wrote: - Original Message - However, I briefly looked through the L2 agent code and didn't see a periodic task to resync the port information to protect from a neutron server that failed to send a notification because it crashed or lost its amqp connection. The L3 agent has a period sync routers task that helps in this regard. The L3 agent periodic sync is only if the full_sync flag was turned on, which is a result of an error. Maybe another neutron developer more familiar with the L2 agent can chime in here if I'm missing anything. i don't think you are missing anything. periodic sync would be a good improvement. YAMAMAOTO Takashi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing 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:
Re: [openstack-dev] [Glance] Proposal to change Glance meeting time.
+1 for consistent time On 14/03/15 10:11, Nikhil Komawar wrote: Here's what it looks like so far:- 1400UTC: 3 votes (all core reviewers) 1500UTC: 5 votes (one core reviewer) Both: 4 votes (all core reviewers) Let's wait another couple days to see if more people respond. I have a feeling that the weight is slightly tilted towards 1400UTC based on a few assumptions about the past activity of those participants, their cross project inputs, etc. Thanks, -Nikhil *From:* Mikhail Fedosin mfedo...@mirantis.com *Sent:* Friday, March 13, 2015 3:07 PM *To:* OpenStack Development Mailing List (not for usage questions) *Subject:* Re: [openstack-dev] [Glance] Proposal to change Glance meeting time. Both options are good, it's a little better at 1500 UTC. +1 consistent time. On Fri, Mar 13, 2015 at 9:23 PM, Steve Lewis steve.le...@rackspace.com mailto:steve.le...@rackspace.com wrote: +1 consistent time +1 for 1500 UTC since that has come up. On 09/03/15 09:07, Nikhil Komawar wrote: So, the new proposal is: Glance meetings [1] to be conducted weekly on Thursdays at 1400UTC [2] on #openstack-meeting-4 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Cheers Best regards, Fei Long Wang (王飞龙) -- Senior Cloud Software Engineer Tel: +64-48032246 Email: flw...@catalyst.net.nz Catalyst IT Limited Level 6, Catalyst House, 150 Willis Street, Wellington -- __ OpenStack Development Mailing 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] IPAM reference driver status and other stuff
Thanks for the update Carl! I spent some time trying to make the refactored base plugin class with the IPAM driver. I have been partially successful. The results are so far in [1] (it's a patch that applies on top of Pavel's topmost patch); this patch will be soon split into smaller patch which I will apply to gerrit reviews in flight. I have some additional comments inline, but I would like to raise some technical points which might need attention * the ML2 plugin overrides several methods from the base db class. From what I gather from unit tests results, we have not yet refactored it. I think to provide users something usable in Kilo we should ensure the ML2 plugin at least works with the IPAM driver. * the current refactoring has ipam-driver-enabled and non-ipam-driver-enabled version of some API operations. While this the less ugly way to introduce the driver and keeping at the same time the old logic, it adds quite a bit of code duplication. I wonder if there is any effort we can make without too much yak shaving to reduce that code duplication, because in this conditions I suspect it would a hard sell to the Neutron core team. Have a nice one, Salvatore [1] https://gist.github.com/salv-orlando/22e524979fe7e2d18d2d On 14 March 2015 at 17:52, Carl Baldwin c...@ecbaldwin.net wrote: Here is an update from our discussion this morning in IRC [1]. The discussion involved mainly Pavel, Salvatore, and me. We first discussed testing the integration of Salvatore's work [2] on the reference driver with Pavel's work to load a driver [3] and refactor the db_base_plugin [4]. Pavel will continue the integration efforts which he has already begun. The final patch [4] makes the reference driver the default IPAM in Neutron so that it is being run in the check queue. At some point before this patch merges, that will be moved to a new patch so that merging this patch will not make the new IPAM driver the default in Neutron. From a unit test perspective, it is important that we test both code with and without the IPAM driver, as we should strive to be as close as possible to 100% code coverage - in particular since the refactoring, in its current form adds quite a bit of code to neutron.db.db_base_plugin_v2 (possibly with a non negligible amount of duplicated logic). Pavel's final patch [4] will merge when the tests pass with the driver as default. In order to avoid raising some eyebrows, it might be worth mentioning that I think you meant to write that the patch will be *ready to merge* when the tests pass with the IPAM driver as default! We hope to hit this point soon. At that point, we will create a non-voting job to run the new IPAM driver as default on all new patches. This will give us many more test runs to work out bugs for the Kilo release and will help us to gauge the eventual readiness of the new driver to become the default IPAM in Neutron. This latter step will not happen until the Liberty time frame. The goal for Liberty should be to deprecate the baked-in IPAM logic, aiming at its removal for M. Non-voting jobs are useful, but mostly for the people interested in it. Other contributors tend to ignore what does not cause them a build failure. So - in my opinion - the idea should be that as soon as we're confident the IPAM driver is reliable enough, we'll switch it on either on the mysql or the postgres job. In Kilo, the new IPAM driver will only support greenfield deployments and will not support using multiple drivers simultaneously. There will be no migration from the old to the new until Liberty. I will leave this decision to the rest of the community, but I believe that a data migration script, similar to the one that was done for ML2, should be doable in a fairly easy way. However, a migration plan is required in order to eventually deprecate and remove the baked-in IPAM solution. We will continue to evaluate use cases around using multiple drivers in the same deployment (e.g. ability to set the driver per subnet or support some sort of flavors). At the point that the non-voting check job is stable, it will be moved to voting. When the new driver graduates to be the default driver in Neutron, the separate gate check job will no longer be necessary and will be removed. Please let me know if I left out any significant detail. Carl [1] http://eavesdrop.openstack.org/irclogs/%23openstack-neutron/%23openstack-neutron.2015-03-13.log at 2015-03-13T15:08:15 [2] https://review.openstack.org/#/c/150485/ [3] https://review.openstack.org/#/c/147479/ [4] https://review.openstack.org/#/c/153236/ On Mon, Mar 9, 2015 at 4:44 AM, Salvatore Orlando sorla...@nicira.com wrote: Aloha everybody! This is another long email, so here's the summary for people with 5-minute or less attention span: The IPAM reference driver is almost ready [1]. Unfortunately letting the driver doing allocation pools required a few major changes, so
Re: [openstack-dev] [neutron] Generic question about synchronizing neutron agent on compute node with DB
Hello, Dnia niedziela, 15 marca 2015 17:45:05 Salvatore Orlando pisze: On 14 March 2015 at 11:19, Sławek Kapłoński sla...@kaplonski.pl wrote: Hello, I'm using ovs agents with L2 population mechanism in ML2 plugin. I noticed that sometimes agents don't receive proper RPC to add new vxlan tunnel openflow rules and then vxlan network between some compute nodes not working. I'm now using still havana release but want to upgrade to Juno. I was checking Juno code in l2 population mech driver and ovs plugin and I didn't find anything like periodic check if openflow rules are proper set or maybe resynced. Maybe it would be also good idea to add something like that to ovs agent? It would surely be a good idea to add some form of reliability into communications between server and agents. So far there are still several instances where the server sends a fire and forget notification to the agent, and does not take any step to ensure the state change associated with that notification has been actually applied to the agent. This applies also to some messages from the agent side, such as status change notifications. Maybe good idea for the beginning could be to implement some periodic task called from agent to check db config and compare it with real state on host? What do You think? Or maybe I'm competly wrong with such idea and it should be done in different way? This is something that can be beneficial any neutron implementation which depends on one or more agents, not just for those using the ovs/linux bridge agents with the l2-population driver. Probably yes, but I had this problem only with this l2-population driver so far and that's why I wrote about it :) -- Pozdrawiam / Best regards Sławek Kapłoński sla...@kaplonski.pl Salvatore -- Pozdrawiam / Best regards Sławek Kapłoński sla...@kaplonski.pl Dnia piątek, 13 marca 2015 11:18:28 YAMAMOTO Takashi pisze: However, I briefly looked through the L2 agent code and didn't see a periodic task to resync the port information to protect from a neutron server that failed to send a notification because it crashed or lost its amqp connection. The L3 agent has a period sync routers task that helps in this regard. Maybe another neutron developer more familiar with the L2 agent can chime in here if I'm missing anything. i don't think you are missing anything. periodic sync would be a good improvement. YAMAMAOTO Takashi __ OpenStack Development Mailing 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] [Ironic] proposing rameshg87 to ironic-core
Ramakrishnan, Congratulations! I owe you a lot :) Naohiro. From: Devananda van der Veen [mailto:devananda@gmail.com] Sent: Friday, March 13, 2015 1:06 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Ironic] proposing rameshg87 to ironic-core Without further ado, and since everyone (even though some haven't replied here) has +1'd this, and since we could really use ramesh's +2's in the run up to Kilo-3 and feature freeze, even without the customary waiting/voting period being completely satisfied (after all, when we all agree, why wait a week?), I'd like to officially welcome him to the core team. -Devananda On Tue, Mar 10, 2015 at 10:03 AM David Shrewsbury shrewsbury.d...@gmail.commailto:shrewsbury.d...@gmail.com wrote: +1 On Mar 9, 2015, at 6:03 PM, Devananda van der Veen devananda@gmail.commailto:devananda@gmail.com wrote: Hi all, I'd like to propose adding Ramakrishnan (rameshg87) to ironic-core. He's been consistently providing good code reviews, and been in the top five active reviewers for the last 90 days and top 10 for the last 180 days. Two cores have recently approached me to let me know that they, too, find his reviews valuable. Furthermore, Ramakrishnan has made significant code contributions to Ironic over the last year. While working primarily on the iLO driver, he has also done a lot of refactoring of the core code, touched on several other drivers, and maintains the proliantutils library on stackforge. All in all, I feel this demonstrates a good and growing knowledge of the codebase and architecture of our project, and feel he'd be a valuable member of the core team. Stats, for those that want them, are below the break. Best Regards, Devananda http://stackalytics.com/?release=allmodule=ironic-groupuser_id=rameshg87 http://russellbryant.net/openstack-stats/ironic-reviewers-90.txt http://russellbryant.net/openstack-stats/ironic-reviewers-180.txt __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.orgmailto: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: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
Re: [openstack-dev] [neutron] Generic question about synchronizing neutron agent on compute node with DB
Hi slawek, may be you're hitting this l2pop bug : https://bugs.launchpad.net/neutron/+bug/1372438 On Sun, Mar 15, 2015 at 11:37 PM, Sławek Kapłoński sla...@kaplonski.pl wrote: Hello, Dnia niedziela, 15 marca 2015 17:45:05 Salvatore Orlando pisze: On 14 March 2015 at 11:19, Sławek Kapłoński sla...@kaplonski.pl wrote: Hello, I'm using ovs agents with L2 population mechanism in ML2 plugin. I noticed that sometimes agents don't receive proper RPC to add new vxlan tunnel openflow rules and then vxlan network between some compute nodes not working. I'm now using still havana release but want to upgrade to Juno. I was checking Juno code in l2 population mech driver and ovs plugin and I didn't find anything like periodic check if openflow rules are proper set or maybe resynced. Maybe it would be also good idea to add something like that to ovs agent? It would surely be a good idea to add some form of reliability into communications between server and agents. So far there are still several instances where the server sends a fire and forget notification to the agent, and does not take any step to ensure the state change associated with that notification has been actually applied to the agent. This applies also to some messages from the agent side, such as status change notifications. Maybe good idea for the beginning could be to implement some periodic task called from agent to check db config and compare it with real state on host? What do You think? Or maybe I'm competly wrong with such idea and it should be done in different way? This is something that can be beneficial any neutron implementation which depends on one or more agents, not just for those using the ovs/linux bridge agents with the l2-population driver. Probably yes, but I had this problem only with this l2-population driver so far and that's why I wrote about it :) -- Pozdrawiam / Best regards Sławek Kapłoński sla...@kaplonski.pl Salvatore -- Pozdrawiam / Best regards Sławek Kapłoński sla...@kaplonski.pl Dnia piątek, 13 marca 2015 11:18:28 YAMAMOTO Takashi pisze: However, I briefly looked through the L2 agent code and didn't see a periodic task to resync the port information to protect from a neutron server that failed to send a notification because it crashed or lost its amqp connection. The L3 agent has a period sync routers task that helps in this regard. Maybe another neutron developer more familiar with the L2 agent can chime in here if I'm missing anything. i don't think you are missing anything. periodic sync would be a good improvement. YAMAMAOTO Takashi __ OpenStack Development Mailing 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] is it possible to microversion a static class method?
2015-03-13 19:10 GMT+08:00 Sean Dague s...@dague.net: On 03/13/2015 02:55 AM, Chris Friesen wrote: On 03/12/2015 12:13 PM, Sean Dague wrote: On 03/12/2015 02:03 PM, Chris Friesen wrote: Hi, I'm having an issue with microversions. The api_version() code has a comment saying This decorator MUST appear first (the outermost decorator) on an API method for it to work correctly I tried making a microversioned static class method like this: @wsgi.Controller.api_version(2.4) # noqa @staticmethod def _my_func(req, foo): and pycharm highlighted the api_version decorator and complained that This decorator will not receive a callable it may expect; the built-in decorator returns a special object. Is this a spurious warning from pycharm? The pep8 checks don't complain. If I don't make it static, then pycharm suggests that the method could be static. *API method* This is not intended for use by methods below the top controller level. If you want conditionals lower down in your call stack pull the request version out yourself and use that. Both the original spec and doc/source/devref/api_microversions.rst contain text talking about decorating a private method. The latter gives this example: @api_version(2.1, 2.4) def _version_specific_func(self, req, arg1): pass @api_version(min_version=2.5) #noqa def _version_specific_func(self, req, arg1): pass def show(self, req, id): common stuff self._version_specific_func(req, foo) common stuff It's entirely possible that such a private method might not need to reference self, and could therefore be static, so I think it's a valid question. That's a doc bug, we should change it. Actually it is not a bug. It's controversial point in the spec, but finally that was keep in the spec. http://specs.openstack.org/openstack/nova-specs/specs/kilo/approved/api-microversions.html The discussion at line 268 https://review.openstack.org/#/c/127127/7/specs/kilo/approved/api-microversions.rst -Sean -- Sean Dague http://dague.net __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] is it possible to microversion a static class method?
So ultimately I think this is a style issue rather than a technical one. I think there are situations where one way looks clearer than another the other way does. Sorry I can't get around to putting up a couple of examples, ATM but to be clear there is no difference in the end result (no different side effects etc) On Mon, Mar 16, 2015 at 12:21 PM, Alex Xu sou...@gmail.com wrote: 2015-03-16 9:48 GMT+08:00 Alex Xu sou...@gmail.com: 2015-03-13 19:10 GMT+08:00 Sean Dague s...@dague.net: On 03/13/2015 02:55 AM, Chris Friesen wrote: On 03/12/2015 12:13 PM, Sean Dague wrote: On 03/12/2015 02:03 PM, Chris Friesen wrote: Hi, I'm having an issue with microversions. The api_version() code has a comment saying This decorator MUST appear first (the outermost decorator) on an API method for it to work correctly I tried making a microversioned static class method like this: @wsgi.Controller.api_version(2.4) # noqa @staticmethod def _my_func(req, foo): and pycharm highlighted the api_version decorator and complained that This decorator will not receive a callable it may expect; the built-in decorator returns a special object. Is this a spurious warning from pycharm? The pep8 checks don't complain. If I don't make it static, then pycharm suggests that the method could be static. *API method* This is not intended for use by methods below the top controller level. If you want conditionals lower down in your call stack pull the request version out yourself and use that. Both the original spec and doc/source/devref/api_microversions.rst contain text talking about decorating a private method. The latter gives this example: @api_version(2.1, 2.4) def _version_specific_func(self, req, arg1): pass @api_version(min_version=2.5) #noqa def _version_specific_func(self, req, arg1): pass def show(self, req, id): common stuff self._version_specific_func(req, foo) common stuff It's entirely possible that such a private method might not need to reference self, and could therefore be static, so I think it's a valid question. That's a doc bug, we should change it. Actually it is not a bug. It's controversial point in the spec, but finally that was keep in the spec. http://specs.openstack.org/openstack/nova-specs/specs/kilo/approved/api-microversions.html The discussion at line 268 https://review.openstack.org/#/c/127127/7/specs/kilo/approved/api-microversions.rst Submit a patch for devref https://review.openstack.org/164555 Let see whether we can get agreement -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 Development Mailing 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] is it possible to microversion a static class method?
2015-03-16 9:48 GMT+08:00 Alex Xu sou...@gmail.com: 2015-03-13 19:10 GMT+08:00 Sean Dague s...@dague.net: On 03/13/2015 02:55 AM, Chris Friesen wrote: On 03/12/2015 12:13 PM, Sean Dague wrote: On 03/12/2015 02:03 PM, Chris Friesen wrote: Hi, I'm having an issue with microversions. The api_version() code has a comment saying This decorator MUST appear first (the outermost decorator) on an API method for it to work correctly I tried making a microversioned static class method like this: @wsgi.Controller.api_version(2.4) # noqa @staticmethod def _my_func(req, foo): and pycharm highlighted the api_version decorator and complained that This decorator will not receive a callable it may expect; the built-in decorator returns a special object. Is this a spurious warning from pycharm? The pep8 checks don't complain. If I don't make it static, then pycharm suggests that the method could be static. *API method* This is not intended for use by methods below the top controller level. If you want conditionals lower down in your call stack pull the request version out yourself and use that. Both the original spec and doc/source/devref/api_microversions.rst contain text talking about decorating a private method. The latter gives this example: @api_version(2.1, 2.4) def _version_specific_func(self, req, arg1): pass @api_version(min_version=2.5) #noqa def _version_specific_func(self, req, arg1): pass def show(self, req, id): common stuff self._version_specific_func(req, foo) common stuff It's entirely possible that such a private method might not need to reference self, and could therefore be static, so I think it's a valid question. That's a doc bug, we should change it. Actually it is not a bug. It's controversial point in the spec, but finally that was keep in the spec. http://specs.openstack.org/openstack/nova-specs/specs/kilo/approved/api-microversions.html The discussion at line 268 https://review.openstack.org/#/c/127127/7/specs/kilo/approved/api-microversions.rst Submit a patch for devref https://review.openstack.org/164555 Let see whether we can get agreement -Sean -- Sean Dague http://dague.net __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo][horizon][infra] oslo.policy in django-openstack-auth fails with stable/juno global requirement check
Thanks Doug, It is a good direction to have the stable branches for all libraries. It seems better that I wait for adopting oslo.policy in django-openstack-auth. In the current infra, a library specified in LIBS_FROM_GIT will be installed even if its version does not match global-requirement (for example, even if global-requirement requires =1.1.9, dev version of library which is newer than 1.1.9 will be installed and leads to global-requirement failure. It seems the version check is not so easy and seems better to wait stable/ branches are created Akihiro 2015-03-16 1:45 GMT+09:00 Doug Hellmann d...@doughellmann.com: Excerpts from Akihiro Motoki's message of 2015-03-16 01:25:08 +0900: Hi Oslo team, I am working on adopting the graduated oslo.policy in django-openstack-auth [1] but I have a question on how to migrate openstack.common.policy to oslo.policy in libraries which have no stable branch. django-openstack-auth has no stable branches as other python-*client. stable/juno global-requirements requries django_openstack_auth=1.1.7,!=1.1.8,=1.1.9, and the development is for 1.1.10 or 1.2.x, so I first thought it is no problem. However, in the review of [1], gate-tempest-dsvm-neutron-src-django_openstack_auth-juno fails with the error that oslo.policy is not in global-requirements in stable/juno. Is it a problem in the infra side? Or is it a thing we should avoid? Any advise will be appreciated. All libraries should have stable branches going forward because we are capping requirements in the stable branches. See https://review.openstack.org/#/c/155072/ for details. Doug [1] https://review.openstack.org/#/c/164420/ Thanks, 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 -- Akihiro Motoki amot...@gmail.com __ OpenStack Development Mailing 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] [Horizon][DOA] Extending OpenStack Auth for new mechanisms (websso, kerberos, k2k etc)
Hi All, Please note when reading this that I have no real knowledge of django so it is very possible I'm overlooking something obvious. ### Issue Django OpenStack Auth (DOA) has always been tightly coupled to the notion of a username and password. As keystone progresses and new authentication mechanisms become available to the project we need a way to extend DOA to keep up with it. However the basic processes of DOA are going to be much the same, it still needs to fetch an unscoped token, list available projects and handle rescoping and this is too much for every extension mechanism to reimplement. There is also a fairly tight coupling between how DOA populates the request and sets up a User object that we don't really want to reuse. There are a couple of authentication mechanisms that are currently being proposed that are requiring this ability immediately. * websso: https://review.openstack.org/136178 * kerberos: https://review.openstack.org/#/c/153910/ (patchset 2). and to a certain extent: * k2k: https://review.openstack.org/159910 Enabling and using these different authentication mechanisms is going to need to be configured by an admin at deployment time. Given that we want to share the basic scoping/rescoping logic between these projects I can essentially see two ways to enable this. ### Proposal 1 - Add plugins to DOA The easiest way I can see of doing this is to add a plugin model to the existing DOA structure. The initial differentiating component for all these mechanisms is the retrieval of an unscoped token. We can take the existing DOA structure and simply make that part pluggable and add interfaces to that plugin as required in the future. Review: https://review.openstack.org/#/c/153910/ Pros: * Fairly simple and extensible as required. * Small plugin interface. Cons: * Ignores that django already has an authentication plugin system. * Doesn't work well for adding views that run these backends. ### Proposal 2 - Make the existing DOA subclassable. The next method is to essentially re-use the existing Django authentication module architecture. We can extract into a base class all the current logic around token handling and develop new modules around that. Review: https://review.openstack.org/#/c/164071/ An example of using it: https://github.com/jamielennox/django-openstack-auth-kerberos Pros: * Reusing Django concepts. * Seems easier to handle adding of views. Cons: * DOA has to start worrying about public interfaces. ### Required reviews: Either way I think these two reviews are going to be required to make this work: * Redirect to login page: https://review.openstack.org/#/c/153174/ - If we want apache modules to start handling parts of auth we need to mount those at dedicated paths, we can't put kerberos login at / * Additional auth urls: https://review.openstack.org/#/c/164068/ - We need to register additional views so that we can handle the output of these apache modules and call the correct authenticate() parameters. ### Conclusion Essentially either of these could work and both will require some tweaking and extending to be useful in all situations. However I am kind of passing through on DOA and Django and would like someone with more experience in the field to comment on what feels more correct or any issues they see arising with the different approaches. Either way I think a clear approach on extensibility would be good before committing to any of the kerberos, websso and k2k definitions. Please let me know an opinion as there are multiple patches that will depend upon it. Thanks, Jamie __ OpenStack Development Mailing 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 CI Infrastructure
Hello, OpenStack dev members, Is there any problem on Nova CI Infrastructure? Here is my submitted link. https://review.openstack.org/#/c/156126/ I don't know why my patch does not execute all tests. Is it ok to review my patch?? Thanks Kwonho __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
