Re: [openstack-dev] [Policy][Group-based Policy] Audio stream for GBP Design Session in Paris
Use this webex meeting for Audio streaming: https://cisco.webex.com/ciscosales/j.php?MTID=m210c77f6f51a6f313a7d130d19ee3e4d Topic: GBP Design Session Date: Tuesday, November 4, 2014 Time: 12:15 pm, Europe Time (Amsterdam, GMT+01:00) Meeting Number: 205 658 563 Meeting Password: gbp On Mon, Nov 3, 2014 at 5:48 PM, Gregory Lebovitz gregory.i...@gmail.com wrote: Hey all, I'm participating remotely this session. Any plan for audio stream of Tuesday's session? I'll happily offer a GoToMeeting, if needed. Would someone be willing to scribe discussion in #openstack-gbp channel? -- Open industry-related email from Gregory M. Lebovitz ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Policy][Group-based Policy] Audio stream for GBP Design Session in Paris
As no one was online, I closed the webex session. On Tue, Nov 4, 2014 at 10:07 AM, Mandeep Dhami dh...@noironetworks.com wrote: Use this webex meeting for Audio streaming: https://cisco.webex.com/ciscosales/j.php?MTID=m210c77f6f51a6f313a7d130d19ee3e4d Topic: GBP Design Session Date: Tuesday, November 4, 2014 Time: 12:15 pm, Europe Time (Amsterdam, GMT+01:00) Meeting Number: 205 658 563 Meeting Password: gbp On Mon, Nov 3, 2014 at 5:48 PM, Gregory Lebovitz gregory.i...@gmail.com wrote: Hey all, I'm participating remotely this session. Any plan for audio stream of Tuesday's session? I'll happily offer a GoToMeeting, if needed. Would someone be willing to scribe discussion in #openstack-gbp channel? -- Open industry-related email from Gregory M. Lebovitz ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][LBaaS][Octavia] Octavia's API becoming spun out LBaaS
Hi Kyle: Are you scheduling an on-demand meeting, or are you proposing that the agenda for next neutron meeting include this as an on-demand item? Regards, Mandeep On Mon, Oct 27, 2014 at 6:56 AM, Kyle Mestery mest...@mestery.com wrote: On Mon, Oct 27, 2014 at 12:15 AM, Sumit Naiksatam sumitnaiksa...@gmail.com wrote: Several people have been requesting that we resume the Advanced Services' meetings [1] to discuss some of the topics being mentioned in this thread. Perhaps it might help people to have a focussed discussion on the topic of advanced services' spin-out prior to the design summit session [2] in Paris. So I propose that we resume our weekly IRC meetings starting this Wednesday (Oct 29th), 17.30 UTC on #openstack-meeting-3. Given how important this is to Neutron in general, I would prefer NOT to see this discussed in the Advanced Services meeting, but rather in the regular Neutron meeting. These are the types of things which need broader oversight and involvement. Lets please discuss this in the regular Neutron meeting, which is an on-demand meeting format, rather than in a sub-team meeting. Thanks, ~Sumit. [1] https://wiki.openstack.org/wiki/Meetings/AdvancedServices [2] http://kilodesignsummit.sched.org/event/8a0b7c1d64883c08286e4446e163f1a6#.VE3Ukot4r4y On Sun, Oct 26, 2014 at 7:55 PM, Sridar Kandaswamy (skandasw) skand...@cisco.com wrote: Hi Doug: On 10/26/14, 6:01 PM, Doug Wiegley do...@a10networks.com wrote: Hi Brandon, 4. I brought this up now so that we can decide whether we want to discuss it at the advanced services spin out session. I don't see the harm in opinions being discussed before the summit, during the summit, and more thoroughly after the summit. I agree with this sentiment. I¹d just like to pull-up to the decision level, and if we can get some consensus on how we move forward, we can bring a concrete plan to the summit instead of 40 minutes of Kumbaya. We love each other. Check. Things are going to change sometime. Check. We might spin-out someday. Check. Now, let¹s jump to the interesting part. 3. The main reason a spin out makes sense from Neutron is that the scope for Neutron is too large for the attention advances services needs from the Neutron Core. If all of advanced services spins out, I see that There is merit here, but consider the sorts of things that an advanced services framework should be doing: - plugging into neutron ports, with all manner of topologies - service VM handling - plugging into nova-network - service chaining - applying things like security groups to services Š this is all stuff that Octavia is talking about implementing itself in a basically defensive manner, instead of leveraging other work. And there are specific reasons for that. But, maybe we can at least take steps to not be incompatible about it. Or maybe there is a hierarchy of Neutron - Services - LB, where we¹re still spun out, but not doing it in a way that we have to re-implement the world all the time. It¹s at least worth a conversation or three. In total agreement and I have heard these sentiments in multiple conversations across multiple players. It would be really fruitful to have a constructive conversation on this across the services, and there are enough similar issues to make this worthwhile. Thanks Sridar Thanks, Doug On 10/26/14, 6:35 PM, Brandon Logan brandon.lo...@rackspace.com wrote: Good questions Doug. My answers are as follows: 1. Yes 2. Some time after Kilo (same as I don't know when) 3. The main reason a spin out makes sense from Neutron is that the scope for Neutron is too large for the attention advances services needs from the Neutron Core. If all of advanced services spins out, I see that repeating itself within an advanced services project. More and more advanced services will get added in and the scope will become too large. There would definitely be benefits to it though, but I think we would end up being right where we are today. 4. I brought this up now so that we can decide whether we want to discuss it at the advanced services spin out session. I don't see the harm in opinions being discussed before the summit, during the summit, and more thoroughly after the summit. Yes the brunt of the time will not be spent on the API, but since it seemed like an opportunity to kill two birds with one stone, I figured it warranted a discussion. Thanks, Brandon On Sun, 2014-10-26 at 23:15 +, Doug Wiegley wrote: Hi all, Before we get into the details of which API goes where, I¹d like to see us answer the questions of: 1. Are we spinning out? 2. When? 3. With or without the rest of advanced services? 4. Do we want to wait until we (the royal ³we² of ³the Neutron team²) have had the Paris summit discussions on vendor split-out and adv. services spinout
Re: [openstack-dev] [neutron][policy] Group-based Policy next steps
I agree with Kevin. Any option in-tree or in-incubator would need core review time, and they are already oversubscribed with nova parity issues (for Juno). So the only option to continue collaboration on experimenting with policy based networking on current openstack is on stackforge (option 5). So the summary is: We develop in stackforge for Juno code, and that we should keep our options open and review this as a community again during the Kilo conference. Regards, Mandeep On Thu, Sep 11, 2014 at 10:02 AM, Kevin Benton blak...@gmail.com wrote: Thanks. This is good writeup. Of course this all assumes there is consensus that we should proceed with GBP, that we should continue by iterating the currently proposed design and code, and that GBP should eventually become part of Neutron. These assumptions may still be the real issues :-( . Unfortunately I think this is the real root cause. Most of the people that worked on GBP definitely want to see it merged into Neutron and is in general agreement there. However, some of the other cores disagreed and now GBP is sitting in limbo. IIUC, this thread was started to just get GBP to some location where it can be developed on and tested that isn't a big string of rejected gerrit patches. Does the above make some sense? What have I missed? Option 1 is great, but I don't see how the same thing that happened in Juno would be avoided. Option 2 is also good, but that idea didn't seem to catch on. If this option is on the table, this seems like the best way to go. Option 3 sounded like it brought up a lot of tooling (gerrit) issues with regard to how the merging workflow would work. Option 4 is unknown until the incubator details are hashed out. Option 5 is stackforge. I see this as a better place just to do what is already being done right now. You're right that patches would occur without core reviewers, but that's essentially what's happening now since nothing is getting merged. On Thu, Sep 11, 2014 at 7:57 AM, Robert Kukura kuk...@noironetworks.com wrote: On 9/10/14, 6:54 PM, Kevin Benton wrote: Being in the incubator won't help with this if it's a different repo as well. Agreed. Given the requirement for GBP to intercept API requests, the potential couplings between policy drivers, ML2 mechanism drivers, and even service plugins (L3 router), and the fact Neutron doesn't have a stable [service] plugin API, along with the goal to eventually merge GBP into Neutron, I'd rank the options as follows in descending order: 1) Merge the GBP patches to the neutron repo early in Kilo and iterate, just like we had planned for Juno ;-) . 2) Like 1, but with the code initially in a preview subtree to clarify its level of stability and support, and to facilitate packaging it as an optional component. 3) Like 1, but merge to a feature branch in the neutron repo and iterate there. 4) Develop in an official neutron-incubator repo, with neutron core reviews of each GBP patch. 5) Develop in StackForge, without neutron core reviews. Here's how I see these options in terms of the various considerations that have come up during this discussion: * Options 1, 2 and 3 most easily support whatever coupling is needed with the rest of Neutron. Options 4 and 5 would sometimes require synchronized changes across repos since dependencies aren't in terms of stable interfaces. * Options 1, 2 and 3 provide a clear path to eventually graduate GBP into a fully supported Neutron feature, without loss of git history. Option 4 would have some hope of eventually merging into the neutron repo due to the code having already had core reviews. With option 5, reviewing and merging a complete GBP implementation from StackForge into the neutron repo would be a huge effort, with significant risk that reviewers would want design changes not practical to make at that stage. * Options 1 and 2 take full advantage of existing review, CI, packaging and release processes and mechanisms. All the other options require extra work to put these in place. * Options 1 and 2 can easily make GBP consumable by early adopters through normal channels such as devstack and OpenStack distributions. The other options all require the operator or the packager to pull GBP code from a different source than the base Neutron code. * Option 1 relies on the historical understanding that new Neutron extension APIs are not initially considered stable, and incompatible changes can occur in future releases. Options 2, 3 and 4 make this explicit. Option 5 really has nothing to do with Neutron. * Option 5 allows rapid iteration by the GBP team, without waiting for core review. This is essential during experimentation and prototyping, but at least some participants consider the GBP implementation to be well beyond that phase. * Options 3, 4, and 5 potentially decouple the GBP release schedule from the Neutron release schedule. With options 1
Re: [openstack-dev] [neutron][policy] Group-based Policy next steps
I agree. Also, as this does not preclude using the incubator when it is ready, this is a good way to start iterating on implementation in parallel with those issues being addressed by the community. In my view, the issues raised around the incubator were significant enough (around packaging, handling of updates needed for horizon/heat/celiometer, handling of multiple feature branches, etc) that we we will probably need a design session in paris before a consensus will emerge around a solution for the incubator structure/usage. And if you are following the thread on nova for 'Averting the Nova crisis ...', the final consensus might actually BE to use separate stackforge project for plugins anyways, and in that case we will have a head start ;-) Regards, Mandeep - On Thu, Sep 4, 2014 at 10:59 PM, Prasad Vellanki prasad.vella...@oneconvergence.com wrote: Sumit Thanks for initiating this and also good discussion today on the IRC. My thoughts are that it is important to make this available to potential users and customers as soon as possible so that we can get the necessary feedback. Considering that the neutron cores and community are battling nova parity and stability now, I would think it would be tough to get any time for incubator or neutron feature branch any time soon. I would think it would be better to move GBP into stackforge and then look at incubator or neutron feature branch when available. prasadv On Wed, Sep 3, 2014 at 9:07 PM, Sumit Naiksatam sumitnaiksa...@gmail.com wrote: Hi, There's been a lot of lively discussion on GBP a few weeks back and we wanted to drive forward the discussion on this a bit more. As you might imagine, we're excited to move this forward so more people can try it out. Here are the options: * Neutron feature branch: This presumably allows the GBP feature to be developed independently, and will perhaps help in faster iterations. There does seem to be a significant packaging issue [1] with this approach that hasn’t been completely addressed. * Neutron-incubator: This allows a path to graduate into Neutron, and will be managed by the Neutron core team. That said, the proposal is under discussion and there are still some open questions [2]. * Stackforge: This allows the GBP team to make rapid and iterative progress, while still leveraging the OpenStack infra. It also provides option of immediately exposing the existing implementation to early adopters. Each of the above options does not preclude moving to the other at a later time. Which option do people think is more preferable? (We could also discuss this in the weekly GBP IRC meeting on Thursday: https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy) Thanks! [1] http://lists.openstack.org/pipermail/openstack-dev/2014-August/044283.html [2] http://lists.openstack.org/pipermail/openstack-dev/2014-August/043577.html ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] [neutron] Specs for K release
+1 I agree that this is a good idea. Regards, Mandeep On Thu, Aug 28, 2014 at 10:13 AM, Jay Pipes jaypi...@gmail.com wrote: On 08/28/2014 12:50 PM, Michael Still wrote: On Thu, Aug 28, 2014 at 6:53 AM, Daniel P. Berrange berra...@redhat.com wrote: On Thu, Aug 28, 2014 at 11:51:32AM +, Alan Kavanagh wrote: How to do we handle specs that have slipped through the cracks and did not make it for Juno? Rebase the proposal so it is under the 'kilo' directory path instead of 'juno' and submit it for review again. Make sure to keep the ChangeId line intact so people see the history of any review comments in the earlier Juno proposal. Yes, but... I think we should talk about tweaking the structure of the juno directory. Something like having proposed, approved, and implemented directories. That would provide better signalling to operators about what we actually did, what we thought we'd do, and what we didn't do. I think this would be really useful. -jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Author tags
T hese should all be comment changes, so there should be no impact. While I agree that it is late for J3, IMO this is the type of change (minor/comment only) that should be OK J4 rather than wait for Kilo. On Wed, Aug 27, 2014 at 7:25 AM, Kyle Mestery mest...@mestery.com wrote: On Wed, Aug 27, 2014 at 8:24 AM, Gary Kotton gkot...@vmware.com wrote: Hi, A few cycles ago the Nova group decided to remove @author from copyright statements. This is due to the fact that this information is stored in git. After adding a similar hacking rule to Neutron it has stirred up some debate. Does anyone have any reason to for us not to go ahead with https://review.openstack.org/#/c/112329/. Thanks Gary My main concern is around landing a change like this during feature freeze week, I think at best this should land at the start of Kilo. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [infra] [neutron] [tc] Neutron Incubator workflow
Also note that one of the features of the incubator is that it can be packaged/released independently (like python-neutronclient) and a feature branch is not designed for that workflow. Regards, Mandeep On Wed, Aug 27, 2014 at 4:55 PM, Jeremy Stanley fu...@yuggoth.org wrote: On 2014-08-27 16:05:36 -0700 (-0700), Joe Gordon wrote: We have feature branches? How do we use them? I am not even sure if feature branches were evaluated as an option when the incubator was proposed. Keystone's new API used a feature branch, the EC work in Swift did, so did the Gearman integration for Zuul... however it's also an option not to be taken lightly and comes with its own set of unique challenges. -- Jeremy Stanley ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] Incubator concerns from packaging perspective
+1 I agree with Pradeep and Doug that a new namespace makes for a better structure for packaging and usage. Regards, Mandeep - On Mon, Aug 25, 2014 at 11:30 AM, Doug Hellmann d...@doughellmann.com wrote: On Aug 23, 2014, at 5:36 PM, Maru Newby ma...@redhat.com wrote: On Aug 23, 2014, at 4:06 AM, Sumit Naiksatam sumitnaiksa...@gmail.com wrote: On Thu, Aug 21, 2014 at 7:28 AM, Kyle Mestery mest...@mestery.com wrote: On Thu, Aug 21, 2014 at 5:12 AM, Ihar Hrachyshka ihrac...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 20/08/14 18:28, Salvatore Orlando wrote: Some comments inline. Salvatore On 20 August 2014 17:38, Ihar Hrachyshka ihrac...@redhat.com mailto:ihrac...@redhat.com wrote: Hi all, I've read the proposal for incubator as described at [1], and I have several comments/concerns/suggestions to this. Overall, the idea of giving some space for experimentation that does not alienate parts of community from Neutron is good. In that way, we may relax review rules and quicken turnaround for preview features without loosing control on those features too much. Though the way it's to be implemented leaves several concerns, as follows: 1. From packaging perspective, having a separate repository and tarballs seems not optimal. As a packager, I would better deal with a single tarball instead of two. Meaning, it would be better to keep the code in the same tree. I know that we're afraid of shipping the code for which some users may expect the usual level of support and stability and compatibility. This can be solved by making it explicit that the incubated code is unsupported and used on your user's risk. 1) The experimental code wouldn't probably be installed unless explicitly requested, and 2) it would be put in a separate namespace (like 'preview', 'experimental', or 'staging', as the call it in Linux kernel world [2]). This would facilitate keeping commit history instead of loosing it during graduation. Yes, I know that people don't like to be called experimental or preview or incubator... And maybe neutron-labs repo sounds more appealing than an 'experimental' subtree in the core project. Well, there are lots of EXPERIMENTAL features in Linux kernel that we actively use (for example, btrfs is still considered experimental by Linux kernel devs, while being exposed as a supported option to RHEL7 users), so I don't see how that naming concern is significant. I think this is the whole point of the discussion around the incubator and the reason for which, to the best of my knowledge, no proposal has been accepted yet. I wonder where discussion around the proposal is running. Is it public? The discussion started out privately as the incubation proposal was put together, but it's now on the mailing list, in person, and in IRC meetings. Lets keep the discussion going on list now. In the spirit of keeping the discussion going, I think we probably need to iterate in practice on this idea a little bit before we can crystallize on the policy and process for this new repo. Here are few ideas on how we can start this iteration: * Namespace for the new repo: Should this be in the neutron namespace, or a completely different namespace like neutron labs? Perhaps creating a separate namespace will help the packagers to avoid issues of conflicting package owners of the namespace. I don’t think there is a technical requirement to choose a new namespace. Python supports sharing a namespace, and packaging can support this feature (see: oslo.*). If the point of the incubator is to signal to deployers that the code isn’t fully supported, you may want to use a different namespace for the python/system packages as well. Doug * Dependency on Neutron (core) repository: We would need to sort this out so that we can get UTs to run and pass in the new repo. Can we set the dependency on Neutron milestone releases? We already publish tar balls for the milestone releases, but I am not sure we publish these as packages to pypi. If not could we start doing that? With this in place, the incubator would always lag the Neutron core by at the most one milestone release. Given that it is possible to specify a dependency as a branch/hash/tag in a git repo [1], I’m not sure it’s worth figuring out how to target tarballs. Master branch of the incubation repo could then target the master branch of the Neutron repo and always be assured of being current, and then released versions could target milestone tags or released versions. 1: http://pip.readthedocs.org/en/latest/reference/pip_install.html#git * Modules overlapping with the Neutron (core) repository: We could initially start with the features that required very little or no changes to the Neutron core, to avoid getting into the issue of blocking on
Re: [openstack-dev] [neutron] Spec exceptions are closed, FPF is August 21
Hi Armando: If a core-reviewer puts a -2, there must be a good reason for it I agree. The problem is that after the initial issue identified in the initial -2 review has been fixed, and the patch updated, it (sometimes) happens that we can not get the original reviewer to re-review that update for weeks - creating the type of issues identified in this thread. I would agree that if this was a one-off scenarios, we should handling this as a specific case as you suggest. Unfortunately, this is not a one-off instance, and hence my request for clearer guidelines from PTL for such cases. Regards, Mandeep On Thu, Jul 31, 2014 at 3:54 PM, Armando M. arma...@gmail.com wrote: It is not my intention debating, pointing fingers and finding culprits, these issues can be addressed in some other context. I am gonna say three things: 1) If a core-reviewer puts a -2, there must be a good reason for it. If other reviewers blindly move on as some people seem to imply here, then those reviewers should probably not review the code at all! My policy is to review all the code I am interested in/I can, regardless of the score. My -1 may be someone's +1 (or vice versa), so 'trusting' someone else's vote is the wrong way to go about this. 2) If we all feel that this feature is important (which I am not sure it was being marked as 'low' in oslo, not sure how it was tracked in Neutron), there is the weekly IRC Neutron meeting to raise awareness, since all cores participate; to the best of my knowledge we never spoke (or barely) of the rootwrap work. 3) If people do want this work in Juno (Carl being one of them), we can figure out how to make one final push, and assess potential regression. We 'rushed' other features late in cycle in the past (like nova/neutron event notifications) and if we keep this disabled by default in Juno, I don't think it's really that risky. I can work with Carl to give the patches some more love. Armando On 31 July 2014 15:40, Rudra Rugge ru...@contrailsystems.com wrote: Hi Kyle, I also agree with Mandeep's suggestion of putting a time frame on the lingering -2 if the addressed concerns have been taken care of. In my experience also a sticky -2 detracts other reviewers from reviewing an updated patch. Either a time-frame or a possible override by PTL (move to -1) would help make progress on the review. Regards, Rudra On Thu, Jul 31, 2014 at 2:29 PM, Mandeep Dhami dh...@noironetworks.com wrote: Hi Kyle: As -2 is sticky, and as there exists a possibility that the original core might not get time to get back to re-reviewing his, do you think that there should be clearer guidelines on it's usage (to avoid what you identified as dropping of the balls)? Salvatore had a good guidance in a related thread [0], do you agree with something like that? I try to avoid -2s as much as possible. I put a -2 only when I reckon your patch should never be merged because it'll make the software unstable or tries to solve a problem that does not exist. -2s stick across patches and tend to put off other reviewers. [0] http://lists.openstack.org/pipermail/openstack-dev/2014-July/041339.html Or do you think that 3-5 days after an update that addresses the issues identified in the original -2, we should automatically remove that -2? If this does not happen often, this process does not have to be automated, just an exception that the PTL can exercise to address issues where the original reason for -2 has been addressed and nothing new has been identified? On Thu, Jul 31, 2014 at 11:25 AM, Kyle Mestery mest...@mestery.com wrote: On Thu, Jul 31, 2014 at 7:11 AM, Yuriy Taraday yorik@gmail.com wrote: On Wed, Jul 30, 2014 at 11:52 AM, Kyle Mestery mest...@mestery.com wrote: and even less possibly rootwrap [3] if the security implications can be worked out. Can you please provide some input on those security implications that are not worked out yet? I'm really surprised to see such comments in some ML thread not directly related to the BP. Why is my spec blocked? Neither spec [1] nor code (which is available for a really long time now [2] [3]) can get enough reviewers' attention because of those groundless -2's. Should I abandon these change requests and file new ones to get some eyes on my code and proposals? It's just getting ridiculous. Let's take a look at timeline, shall we? I share your concerns here as well, and I'm sorry you've had a bad experience working with the community here. Mar, 25 - first version of the first part of Neutron code is published at [2] Mar, 28 - first reviewers come and it gets -1'd by Mark because of lack of BP (thankful it wasn't -2 yet, so reviews continued) Apr, 1 - Both Oslo [5] and Neturon [6] BPs are created; Apr, 2 - first version of the second part of Neutron code is published at [3]; May, 16 - first version of Neutron spec is published at [1]; May, 19
Re: [openstack-dev] [neutron] Spec exceptions are closed, FPF is August 21
Hi Kyle: As -2 is sticky, and as there exists a possibility that the original core might not get time to get back to re-reviewing his, do you think that there should be clearer guidelines on it's usage (to avoid what you identified as dropping of the balls)? Salvatore had a good guidance in a related thread [0], do you agree with something like that? I try to avoid -2s as much as possible. I put a -2 only when I reckon your patch should never be merged because it'll make the software unstable or tries to solve a problem that does not exist. -2s stick across patches and tend to put off other reviewers. [0] http://lists.openstack.org/pipermail/openstack-dev/2014-July/041339.html Or do you think that 3-5 days after an update that addresses the issues identified in the original -2, we should automatically remove that -2? If this does not happen often, this process does not have to be automated, just an exception that the PTL can exercise to address issues where the original reason for -2 has been addressed and nothing new has been identified? On Thu, Jul 31, 2014 at 11:25 AM, Kyle Mestery mest...@mestery.com wrote: On Thu, Jul 31, 2014 at 7:11 AM, Yuriy Taraday yorik@gmail.com wrote: On Wed, Jul 30, 2014 at 11:52 AM, Kyle Mestery mest...@mestery.com wrote: and even less possibly rootwrap [3] if the security implications can be worked out. Can you please provide some input on those security implications that are not worked out yet? I'm really surprised to see such comments in some ML thread not directly related to the BP. Why is my spec blocked? Neither spec [1] nor code (which is available for a really long time now [2] [3]) can get enough reviewers' attention because of those groundless -2's. Should I abandon these change requests and file new ones to get some eyes on my code and proposals? It's just getting ridiculous. Let's take a look at timeline, shall we? I share your concerns here as well, and I'm sorry you've had a bad experience working with the community here. Mar, 25 - first version of the first part of Neutron code is published at [2] Mar, 28 - first reviewers come and it gets -1'd by Mark because of lack of BP (thankful it wasn't -2 yet, so reviews continued) Apr, 1 - Both Oslo [5] and Neturon [6] BPs are created; Apr, 2 - first version of the second part of Neutron code is published at [3]; May, 16 - first version of Neutron spec is published at [1]; May, 19 - Neutron spec gets frozen by Mark's -2 (because Oslo BP is not approved yet); May, 21 - first part of Neutron code [2] is found generally OK by reviewers; May, 21 - first version of Oslo spec is published at [4]; May, 29 - a version of the second part of Neutron code [3] is published that later raises only minor comments by reviewers; Jun, 5 - both parts of Neutron code [2] [3] get frozen by -2 from Mark because BP isn't approved yet; Jun, 23 - Oslo spec [4] is mostly ironed out; Jul, 8 - Oslo spec [4] is merged, Neutron spec immediately gets +1 and +2; Jul, 20 - SAD kicks in, no comments from Mark or anyone on blocked change requests; Jul, 24 - in response to Kyle's suggestion I'm filing SAD exception; Jul, 31 - I'm getting final decision as follows: Your BP will extremely unlikely get to Juno. Do you see what I see? Code and spec is mostly finished in May (!) where the mostly part is lack of reviewers because of that Mark's -2. And 1 month later when all bureaucratic reasons fall off nothing happens. Don't think I didn't try to approach Mark. Don't think I didn't approach Kyle on this issue. Because I did. But nothing happens and another month passes by and I get You know, may be later general response. Noone (but those who knew about it originally) even looks at my code for 2 months already because Mark doesn't think (I hope he did think) he should lift -2 and I'm getting why not wait another 3 months? What the hell is that? You don't want to land features that doesn't have code 2 weeks before Juno-3, I get that. My code has almost finished code by 3.5 months before that! And you're considering to throw it to Kilo because of some mystical issues that must've been covered in Oslo spec [4] and if you like it they can be covered in Neutron spec [1] but you have to let reviewers see it! I don't think that Mark's actions (lack of them, actually) are what's expected from core reviewer. No reaction to requests from developer whose code got frozen by his -2. No reaction (at least no visible one) to PTL's requests (and Kyle assured me he made those). Should we consider Mark uncontrollable and unreachable? Why does he have -2 right in the first place then? So how should I overcome his inaction? I can recreate new change requests and hope he won't just -2 them with no comment at all. But that would be just a sign of total failure of our shiny bureaucracy. I have reached out a few times to
Re: [openstack-dev] [neutron][policy] Bridging the 2-group gap in group policy
Hi Ryan: As I stated in the patch review, the suggestion to use a profiled API like IETF/CCITT is indeed very interesting. As a profiled API has not been tried with any neutron model before, and as there is no existing design pattern/best practices for how best to structure that, my recommendation is to create a new patch (dependent on this patch) to try that experiment. That patch will also clarify what is meant you mean by a profiled API and how that might interact with other openstack services like Heat and Horizon. Regards, Mandeep - On Wed, Jul 30, 2014 at 11:13 AM, Hemanth Ravi hemanthrav...@gmail.com wrote: Hi, Adding this CLI command seems to be a good way to provide support for the second model. This can be submitted as a new review patch to work through the approaches to implement this. I suggest the current CLI patch [1] be reviewed for the existing spec and completed. Ryan, would it possible for you to start a new review submit for the new command(s). Could you also provide any references for profiled API in IETF, CCITT. Thanks, -hemanth [1] https://review.openstack.org/#/c/104013 On Tue, Jul 29, 2014 at 3:16 PM, Ryan Moats rmo...@us.ibm.com wrote: As promised in Monday's Neutron IRC minutes [1], this mail is a trip down memory lane looking at the history of the Neutron GP project.. The original GP google doc [2] included specifying policy via both a produce/consume 1-group approach and as a link between two groups. There was an email thread [3] that discussed the relationship between these models early on, but that discussion petered out and during a later IRC meeting [4] the concept of contracts were added, but without changing the basic use case requirements from the original document. A followup meeting [5] began the discussion of how to express the original model from the contract data model but that discussion doesn't appear to have been completed either. The PoC in Atlanta raised a set of issues [6],[7] around the complexity of the resulting PoC code. The good news is that having looked through the proposed GP code commits (links to which can be found at [8) I believe that folks that want to be able to specify policies via the 2-group approach (and yes, I'm one of them) can have that without changing the model encoded in those commits. Rather, it can be done via the WiP CLI code commit by providing a profiled API - this is a technique used by the IETF, CCITT, etc. to allow a rich API to be consumed in common ways. In this case, what I'm envisioning is something like neutron policy-apply [policy rule] [src group] [destination group] in this case, the CLI would perform the contract creation for the policy rule, and assigning the proper produce/consume edits to the specified source and destination groups. Note: this is in addition to the CLI providing direct access to the underlying data model. I believe that this is the simplest way to bridge the gap and provide support to folks who want to specify policy as something between two groups. Ryan Moats (regXboi) References: [1] http://eavesdrop.openstack.org/meetings/networking/2014/networking.2014-07-28-21.02.log.txt [2] https://docs.google.com/document/d/1ZbOFxAoibZbJmDWx1oOrOsDcov6Cuom5aaBIrupCD9E/edit# [3] http://lists.openstack.org/pipermail/openstack-dev/2013-December/022150.html [4] http://eavesdrop.openstack.org/meetings/networking_policy/2014/networking_policy.2014-02-27-19.00.log.html [5] http://eavesdrop.openstack.org/meetings/networking_policy/2014/networking_policy.2014-03-20-19.00.log.html [6] http://lists.openstack.org/pipermail/openstack-dev/2014-May/035661.html [7] http://eavesdrop.openstack.org/meetings/networking_policy/2014/networking_policy.2014-05-22-18.01.log.html [8] https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] Spec exceptions are closed, FPF is August 21
Also, can I recommend that to avoid last minute rush of all the code in Juno-3 (and then clogging up the gate at that time), we work as a team to re-review patches that have addressed all previously identified issues? For example, the for the GBP plugin, the first series of patches have been updated to address all issues that were identified, and doing re-review/merge now would reduce the load near the end of the cycle. Regards, Mandeep - On Wed, Jul 30, 2014 at 10:52 AM, Kyle Mestery mest...@mestery.com wrote: I wanted to send an email to let everyone know where we're at in the Juno cycle. We're hitting our stride in Juno-3 development now, and we have a lot of BPs targeted [1]. Due to this, I'm not going to approve any more spec exceptions other than possibly flavors [2] and even less possibly rootwrap [3] if the security implications can be worked out. The reality is, we're severely oversubscribed as it is, and we won't land even half of the approved BPs in Juno-3. Also, for people with BPs approved for Juno-3, remember Neutron is observing the Feature Proposal Freeze [4], which is August 21. Any BP without code proposed by then will be deferred to Kilo. As always, the dates for the Juno release can be found on the wiki here [5]. Thanks! Kyle [1] https://launchpad.net/neutron/+milestone/juno-3 [2] https://review.openstack.org/#/c/102723/ [3] https://review.openstack.org/#/c/93889/ [4] https://wiki.openstack.org/wiki/FeatureProposalFreeze [5] https://wiki.openstack.org/wiki/NeutronJunoProjectPlan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] [not-only-neutron] How to Contribute upstream in OpenStack Neutron
Wow! These are the exact questions that I have struggled with. Thanks for stating them so clearly. Regards, Mandeep - On Sat, Jul 26, 2014 at 11:02 AM, Luke Gorrie l...@snabb.co wrote: On 25 July 2014 20:05, Stefano Maffulli stef...@openstack.org wrote: Indeed, communication is key. I'm not sure how you envision to implement this though. We do send a message to first time contributors[1] to explain them how the review process works and give them very basic suggestions on how to react to comments (including what to do if things seem stuck). The main issue here though is that few people read emails, it's a basic fact of life. That welcome message does seem to do a really good job of setting expectations. Can you explain more what you have in mind? Here are some other topics that seem to take some time to develop a mental model of: How quickly and how often should you revise your patchset after a -1? (Is it better to give the community a week or so to collectively comment? Or should you revise ASAP after every negative review?) How do you know if your change is likely to merge? (If you have had 15 rounds of -1 votes and the last milestone deadline is a few days away, should you relax because your code is so thoroughly reviewed or should you despair because it should have been merged by now?) In the final days before a merge deadline, would it be rude to poke the person responsible for merging, or would it be negligent not to? How do you decide which IRC meetings to attend? (For meetings that occur at difficult times outside of working hours in your timezone, when are you expected to attend them? Is it okay to focus on email/informal communication if that suits you better and gets the job done?) If you're new to the project and you don't know anybody, who can you ask about this stuff? ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Specs approved for Juno-3 and exceptions
Thanks Jay. I agree with your position on it, and that is exactly what I would expect as the process in a collaborative community. That feels like the right way ;-) Unfortunately, there have been situations where we have had to ask a reviewer multiple times to re-review the code (after issues identified in a previous review have been addressed). Then you struggle between am I pestering the reviewer vs. what more can we do/needs to be done, please help us understand - and absence of that feedback leads to discouragement for new contributors and piling up of patches for the big deluge near the cut-off deadlines. My suggestion was to deal with outliers like that. If there was a clear guideline, that facilitated the smooth flow of patches and an automated reminder that did not make the person asking for reviews feel that he/she is pestering, that might help. Or maybe if we update infra to report on avg. number of days that a negative review was not re-reviewed after a new patch, we could just address the outliers when we see them. Just an idea to address the outliers, not the normal flow. Regards, Mandeep - On Sat, Jul 26, 2014 at 10:19 AM, Jay Pipes jaypi...@gmail.com wrote: On 07/25/2014 05:48 PM, Mandeep Dhami wrote: Thanks for the deck Jay, that is very helpful. Also, would it help the process by having some clear guidelines/expectations around review time as well? In particular, if you have put a -1 or -2, and the issues that you have identified have been addressed by an update (or at least the original author thinks that he has addressed your concern), is it reasonable to expect that you will re-review in a reasonable time? This way, the updates can either proceed, or be rejected, as they are being developed instead of accumulating in a backlog that we then try to get approved on the last day of the cut-off? Guilty as charged, Mandeep. :( If I have failed to re-review something in a timely manner, please don't hesitate to either find me on IRC or send me an email saying hey, don't forget about XYZ. People get behind on reviews and sometimes things slip the mind. A gentle reminder is all that is needed, usually. As for a hard number of days before sending an email notification, that might be possible, but it's not like we all have our vacation reminders linked in to Gerrit ;) I think a more personal email or IRC request for specific reviews is more appropriate. Best, -jay On Fri, Jul 25, 2014 at 12:50 PM, Steve Gordon sgor...@redhat.com mailto:sgor...@redhat.com wrote: - Original Message - From: Jay Pipes jaypi...@gmail.com mailto:jaypi...@gmail.com To: openstack-dev@lists.openstack.org mailto:openstack-dev@lists.openstack.org On 07/24/2014 10:05 AM, CARVER, PAUL wrote: Alan Kavanagh wrote: If we have more work being put on the table, then more Core members would definitely go a long way with assisting this, we cant wait for folks to be reviewing stuff as an excuse to not get features landed in a given release. We absolutely can and should wait for folks to be reviewing stuff properly. A large number of problems in OpenStack code and flawed design can be attributed to impatience and pushing through code that wasn't ready. I've said this many times, but the best way to get core reviews on patches that you submit is to put the effort into reviewing others' code. Core reviewers are more willing to do reviews for someone who is clearly trying to help the project in more ways than just pushing their own code. Note that, Alan, I'm not trying to imply that you are guilty of the above! :) I'm just recommending techniques for the general contributor community who are not on a core team (including myself!). I agree with all of the above, I do think however there is another un-addressed area where there *may* be room for optimization - which is how we use the earlier milestones. I apologize in advance because this is somewhat tangential to Alan's points but I think it is relevant to the general frustration around what did/didn't get approved in time for the deadline and ultimately what will or wont get reviewed in time to make the release versus being punted to Kilo or even further down the road. We land very, very, little in terms of feature work in the *-1 and *-2 milestones in each release (and this is not just a Neutron thing). Even though we know without a doubt that the amount of work currently approved for J-3 is not realistic we also know that we will land significantly more features in this milestone than the other two that have already been and gone, which to my way of thinking is actually kind of backwards to the ideal situation. What is unclear to me however is how much
Re: [openstack-dev] [Neutron] Specs approved for Juno-3 and exceptions
Thanks for the deck Jay, that is very helpful. Also, would it help the process by having some clear guidelines/expectations around review time as well? In particular, if you have put a -1 or -2, and the issues that you have identified have been addressed by an update (or at least the original author thinks that he has addressed your concern), is it reasonable to expect that you will re-review in a reasonable time? This way, the updates can either proceed, or be rejected, as they are being developed instead of accumulating in a backlog that we then try to get approved on the last day of the cut-off? Regards, Mandeep On Fri, Jul 25, 2014 at 12:50 PM, Steve Gordon sgor...@redhat.com wrote: - Original Message - From: Jay Pipes jaypi...@gmail.com To: openstack-dev@lists.openstack.org On 07/24/2014 10:05 AM, CARVER, PAUL wrote: Alan Kavanagh wrote: If we have more work being put on the table, then more Core members would definitely go a long way with assisting this, we cant wait for folks to be reviewing stuff as an excuse to not get features landed in a given release. We absolutely can and should wait for folks to be reviewing stuff properly. A large number of problems in OpenStack code and flawed design can be attributed to impatience and pushing through code that wasn't ready. I've said this many times, but the best way to get core reviews on patches that you submit is to put the effort into reviewing others' code. Core reviewers are more willing to do reviews for someone who is clearly trying to help the project in more ways than just pushing their own code. Note that, Alan, I'm not trying to imply that you are guilty of the above! :) I'm just recommending techniques for the general contributor community who are not on a core team (including myself!). I agree with all of the above, I do think however there is another un-addressed area where there *may* be room for optimization - which is how we use the earlier milestones. I apologize in advance because this is somewhat tangential to Alan's points but I think it is relevant to the general frustration around what did/didn't get approved in time for the deadline and ultimately what will or wont get reviewed in time to make the release versus being punted to Kilo or even further down the road. We land very, very, little in terms of feature work in the *-1 and *-2 milestones in each release (and this is not just a Neutron thing). Even though we know without a doubt that the amount of work currently approved for J-3 is not realistic we also know that we will land significantly more features in this milestone than the other two that have already been and gone, which to my way of thinking is actually kind of backwards to the ideal situation. What is unclear to me however is how much of this is a result of difficulty identifying and approving less controversial/more straightforward specifications quickly following summit (keeping in mind this time around there was arguably some additional delay as the *-specs repository approach was bedded down), an unavoidable result of human nature being to *really* push when there is a *hard* deadline to beat, or just that these earlier milestones are somewhat impacted from fatigue from the summit (I know a lot of people also try to take some well earned time off around this period + of course many are still concentrated on stabilization of the previous release). As a result it's unclear whether there is anything concrete that can be done to change this but I thought I would bring it up in case anyone else has any bright ideas! [SNIP] We ought to (in my personal opinion) be supplying core reviewers to at least a couple of OpenStack projects. But one way or another we need to get more capabilities reviewed and merged. My personal top disappointments are with the current state of IPv6, HA, and QoS, but I'm sure other folks can list lots of other capabilities that they're really going to be frustrated to find lacking in Juno. I agree with you. It's not something that is fixable overnight, or by a small group of people, IMO. It's something that needs to be addressed by the core project teams, acting as a group in order to reduce review wait times and ensure that there is responsiveness, transparency and thoroughness to the review (code as well as spec) process. I put together some slides recently that have some insights and (hopefully) some helpful suggestions for both doing and receiving code reviews, as well as staying sane in the era of corporate agendas. Perhaps folks will find it useful: http://bit.ly/navigating-openstack-community As an aside this is a very well put together deck, thanks for sharing! -Steve ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Specs approved for Juno-3 and exceptions
What would be a good guideline for timely manner? I would recommend something like 2-3 days unless the reviewer is on vacation or is indisposed. Is it possible to update gerrit/jenkins to send reminders to reviewers in such a scenario? Regards, Mandeep - On Fri, Jul 25, 2014 at 3:14 PM, Kyle Mestery mest...@mestery.com wrote: On Fri, Jul 25, 2014 at 4:48 PM, Mandeep Dhami dh...@noironetworks.com wrote: Thanks for the deck Jay, that is very helpful. Also, would it help the process by having some clear guidelines/expectations around review time as well? In particular, if you have put a -1 or -2, and the issues that you have identified have been addressed by an update (or at least the original author thinks that he has addressed your concern), is it reasonable to expect that you will re-review in a reasonable time? This way, the updates can either proceed, or be rejected, as they are being developed instead of accumulating in a backlog that we then try to get approved on the last day of the cut-off? I agree, if someone puts a -2 on a patch stressing an issue and the committer has resolved those issues, the -2 should also be resolved in a timely manner. If the issue can't be resolved in the review itself, as this wiki page [1] indicates, the issue should be moved to the mailing list. Thanks, Kyle [1] https://wiki.openstack.org/wiki/CodeReviewGuidelines Regards, Mandeep On Fri, Jul 25, 2014 at 12:50 PM, Steve Gordon sgor...@redhat.com wrote: - Original Message - From: Jay Pipes jaypi...@gmail.com To: openstack-dev@lists.openstack.org On 07/24/2014 10:05 AM, CARVER, PAUL wrote: Alan Kavanagh wrote: If we have more work being put on the table, then more Core members would definitely go a long way with assisting this, we cant wait for folks to be reviewing stuff as an excuse to not get features landed in a given release. We absolutely can and should wait for folks to be reviewing stuff properly. A large number of problems in OpenStack code and flawed design can be attributed to impatience and pushing through code that wasn't ready. I've said this many times, but the best way to get core reviews on patches that you submit is to put the effort into reviewing others' code. Core reviewers are more willing to do reviews for someone who is clearly trying to help the project in more ways than just pushing their own code. Note that, Alan, I'm not trying to imply that you are guilty of the above! :) I'm just recommending techniques for the general contributor community who are not on a core team (including myself!). I agree with all of the above, I do think however there is another un-addressed area where there *may* be room for optimization - which is how we use the earlier milestones. I apologize in advance because this is somewhat tangential to Alan's points but I think it is relevant to the general frustration around what did/didn't get approved in time for the deadline and ultimately what will or wont get reviewed in time to make the release versus being punted to Kilo or even further down the road. We land very, very, little in terms of feature work in the *-1 and *-2 milestones in each release (and this is not just a Neutron thing). Even though we know without a doubt that the amount of work currently approved for J-3 is not realistic we also know that we will land significantly more features in this milestone than the other two that have already been and gone, which to my way of thinking is actually kind of backwards to the ideal situation. What is unclear to me however is how much of this is a result of difficulty identifying and approving less controversial/more straightforward specifications quickly following summit (keeping in mind this time around there was arguably some additional delay as the *-specs repository approach was bedded down), an unavoidable result of human nature being to *really* push when there is a *hard* deadline to beat, or just that these earlier milestones are somewhat impacted from fatigue from the summit (I know a lot of people also try to take some well earned time off around this period + of course many are still concentrated on stabilization of the previous release). As a result it's unclear whether there is anything concrete that can be done to change this but I thought I would bring it up in case anyone else has any bright ideas! [SNIP] We ought to (in my personal opinion) be supplying core reviewers to at least a couple of OpenStack projects. But one way or another we need to get more capabilities reviewed and merged. My personal top disappointments are with the current state of IPv6, HA, and QoS, but I'm sure other folks can list lots of other capabilities that they're really going to be frustrated to find lacking in Juno
Re: [openstack-dev] [neutron] Network tomography
Hi Artem: Can you provide reference to that network tomography work? I would be interested in a follow up. In a vendor specific plugin, I have used LLDPs for link discovery using LLDPs (and by transitivity, the ToR discovery), but I did not build a more complete topology view since neutron does not actually have abstractions for working on physical network entities except for the host network interfaces and the segments that they are connected to (all other network entities are for the logical network built using neutron APIs or for supporting that logical network). Regards, Mandeep ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron][group-based-policy] Should we revisit the priority of group-based policy?
Thanks Paul. Feedback like this, from actual users of neutron in large deployments, is the very reason why I feel so strongly that we need to keep this a high priority work item. Regards, Mandeep On Fri, May 23, 2014 at 9:28 AM, CARVER, PAUL pc2...@att.com wrote: Mohammad Banikazemi wrote: in Atlanta the support was overwhelmingly positive in my opinion. I just wanted to make sure this does not get lost in our discussions. Absolutely. I hadn’t been following the group policy discussions prior to the summit but I was very impressed with what I saw and heard. to in particular discuss the possibility of making the code less tightly coupled with Neutron core. +1 to making it less tightly coupled (although I haven’t been inside the code to have an opinion on how tightly coupled it is now) Let’s keep in mind OSI-like layers and well defined interfaces between them. Coming from a hardware networking background I find it very convenient to think in terms of ports, networks, subnets and routers. Those concepts should continue to be basic building blocks of software defined networks. The layer 4+ stuff should be added on top with clean interfaces that don’t entangle functionality up and down the stack. Strict OSI layer compliance has never been a great success, but the general concept has been very useful for a long time All the most painful protocols for a network person to deal with are the ones like SIP where clean separation of layers was indiscriminately violated. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Seeking opinions on scope of code refactoring...
My preferences: For where, I'd go with Gary's recommendation (A) for two reasons (1) Consistency and (2) I don't think it will create any boilerplate requirements since the abstract class provides the default implementation. For naming, I'd prefer to go with ML2 terminology for two reasons (1) Again Consistency, and (2) it is then clear what actions are happening within a transaction or outside of it. With a validation function no transaction fence is implied by it's name - but for any validation that depends on what currently exists in the database, these transaction semantics are important. Regards, Mandeep On Fri, May 23, 2014 at 4:25 PM, Paul Michali (pcm) p...@cisco.com wrote: Thanks for the comment Carl. See @PCM inline PCM (Paul Michali) MAIL …..…. p...@cisco.com IRC ……..… pcm_ (irc.freenode.com) TW ………... @pmichali GPG Key … 4525ECC253E31A83 Fingerprint .. 307A 96BB 1A4C D2C7 931D 8D2D 4525 ECC2 53E3 1A83 On May 23, 2014, at 6:09 PM, Carl Baldwin c...@ecbaldwin.net wrote: Paul, On Fri, May 23, 2014 at 8:24 AM, Paul Michali (pcm) p...@cisco.com wrote: Hi, I’m working on a task for a BP to separate validation from persistence logic in L3 services code (VPN currently), so that providers can override/extend the validation logic (before persistence). So I’ve separated the code for one of the create APIs, placed the default validation into an ABC class (as a non-abstract method) that the service drivers inherit from, and modified the plugin to invoke the validation function in the service driver, before doing the persistence step. The flow goes like this… def create_vpnservice(self, context, vpnservice): driver = self._get_driver_for_vpnservice(vpnservice) driver.validate_create_vpnservice(context, vpnservice) super(VPNDriverPlugin, self).create_vpnservice(context, vpnservice) driver.apply_create_vpnservice(context, vpnservice) If the service driver has a validation routine, it’ll be invoked, otherwise, the default method in the ABC for the service driver will be called and will handle the “baseline” validation. I also renamed the service driver method that is used for applying the changes to the device driver as apply_* instead of using the same name as is used for persistence (e.g. create_vpnservice - apply_create_vpnservice). The questions I have is… 1) Should I create new validation methods A) for every create (and update?) API (regardless of whether they currently have any validation logic, B) for resources that have some validation logic already, or C) only for resources where there are providers with different validation needs? I was thinking (B), but would like to hear peoples’ thoughts. I think B. C may leave a little too much inconsistency. A feels like extra boiler-plate. Would there be any benefit to creating a higher level abstraction for the create/update API calls? I'm not suggesting you do so but if you did then you could add a validation method to that interface with a default pass. Otherwise, I'd stick with B until there is a need for more. @PCM Yeah, there is somewhat of an abstraction. In VPN, for the service drivers, they all inherit from an ABC. For the apply, there are already abstract methods in the ABC, so that the service driver is forced to provide a function (of course it is inconsistent currently - they are there for VPN services, but not for IPSec connections, which are provided in the service driver). For the validation, I was creating methods in the ABC, with implementations, but not abstract, so that the service driver could provide a function, if it wanted to extend or override (and call super, if desired), or leave it out and the base class function would be used. So, I guess it’s at two points, the validate and apply methods, where we should probably be consistent with providing base class methods for all that present in the service driver. 2) I’ve added validation_* and modified the other service driver call to apply_*. Should I instead, use the ML2 terminology of pre commit_* and post commit_*? I personally favor the former, as it is more descriptive of what is happening in the methods, but I understand the desire for consistency with other code. I'm on the fence. ML2 is not where I'm most familiar and I don't know the history behind that design. Without considering ML2 and consistency, I think I like your terminology better. @PCM I’m in the same camp. I don’t know ML2 well, and I like the explicit terminology. It *seems* like ML2 is dealing with this all at the same level of abstraction (pre-commit, commit, post-commit all for the same plugin or driver), whereas with L3 services, it is at two levels (validate at service driver and then plugin, commit at plugin, apply at service driver only). I guess I can leave it and see what happens at review…I have some asbestos here somewhere. 3) Should I create validation methods
Re: [openstack-dev] [neutron][group-based-policy] Should we revisit the priority of group-based policy?
Maru's concerns are that: 1. It is large 2. It is complex And Armando's related concerns are: 3. Could dev/review cycles be better spent on refactoring 4. If refactored neutron was available, would a simpler option become more viable Let me address them in that order. 1. Re: It is large Group policy has an ambitious goal - provide devop teams with policy based controls that are usable at scale and with automation (say a higher governance layer like Congress). The fact that meeting a large challenge requires more code is natural. We understand that challenge, and that is why we did a prototype (as PoC that was demonstrated on the summit). And based on that learning we are incrementally creating patches for building the group based policy. Just because a task is large, we as neutron can not shy away from building it. That will only drive people who need it out side neutron (as we are seeing with the frustration that the LBaaS team had because they have a requirement that is large as well). 2. Re: It is complex Complexity depends on the context. Our goal was to make the end-user's life simpler (and more automated). To achieve some of that simplicity, we required a little more complexity in the implementation. We decide to make that arbitrage - a little higher complexity in implementation to allow for simpler usage. But we were careful and did not want to impose that complexity on every use case - hence a lot of that is optional (and exercised only if the use case needs it). Unfortunately the model, has to model all of it so as it not add complexity later in upgrade and backward compatibility issues. We choose to do architecture upfront, and then implement it incrementally. The team came up with the model currently in model based on that review and evaluation all the proposals in the document that you refer. It is easy to make general comments, but unless you participate in the process and sign up to writing the code, those comments are not going to help with solving the original problem. And this _is_ open-source. If you disagree, please write code and the community can decide for itself as to what model is actually simple to use for them. Curtailing efforts from other developers just because their engineering trade-offs are different from what you believe your use-case needs is not why we like open source. We enjoy the mode where different developers try different things, we experiment, and the software evolves to what the user demands. Or maybe, multiple models live in harmony. Let the users decide that. 3. Re: Could dev/review cycles be better spent on refactoring I think that most people agree that policy control is an important feature that fundamentally improves neutron (by solving the automation and scale issues). In a large project, multiple sub-projects can, and for a healthy project should, work in parallel. I understand that the neutron core team is stretched. But we still need to be able to balance the needs of today (paying off the technical debt/existing-issues by doing refactoring) with needs of tomorrow (new features like GP and LBaaS). GP effort was started in Havana, and now we are trying to get this in Juno. I think that is reasonable and a long enough cycle for a high priority project to be able to get some core attention. Again I refer to LBaaS experience, as they struggled with very similar issues. 4. Re: If refactored neutron was available, would a simpler option become more viable We would love to be able to answer that question. We have been trying to understand the refactoring work to understand this (see another ML thread) and we are open to understanding your position on that. We will call the ad-hoc meeting that you suggested and we would like to understand the refactoring work that might be reused for simpler policy implementation. At the same time, we would like to build on what is available today, and when the required refactored neutron becomes available (say Juno or K-release), we are more than happy to adapt to it at that time. Serializing all development around an effort that is still in inception phase is not a good solution. We are looking forward to participating in the core refactoring work, and based on the final spec that come up with, we would love to be able to eventually make the policy implementation simpler. Regards, Mandeep On Thu, May 22, 2014 at 11:44 AM, Armando M. arma...@gmail.com wrote: I would second Maru's concerns, and I would also like to add the following: We need to acknowledge the fact that there are certain architectural aspects of Neutron as a project that need to be addressed; at the summit we talked about the core refactoring, a task oriented API, etc. To me these items have been neglected far too much over the past and would need a higher priority and a lot more attention during the Juno cycle. Being stretched as we are I wonder if dev/review cycles wouldn't be better spent devoting more time to these efforts rather
Re: [openstack-dev] [Neutron] Core API refactoring
OK On Thu, May 22, 2014 at 7:36 AM, Collins, Sean sean_colli...@cable.comcast.com wrote: On Wed, May 21, 2014 at 10:47:16PM EDT, Mandeep Dhami wrote: The update from Sean seem to suggest to me that we needed blueprints only if the public API changes, and not for design changes that are internal to neutron. There was no statement in my e-mail that made that suggestion. My e-mail was only an attempt to try and help provide context for what was discussed at the summit. I dislike having people put words in my mouth, and you also seem to continue to insinuate that things are not done in the open, with everyone having a chance to participate. I believe this is a serious charge, and I do not appreciate being publicly accused of this. -- Sean M. Collins ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron][group-based-policy] Should we revisit the priority of group-based policy?
each patch needs to receive core reviewer attention and that subsequent patches incorporate their feedback. At least two core neutron members were involved in creating the PoC, and at least two more cores were involved in reviews at various times. In addition to them, senior developers from at least seven networking companies were involved in developing this code. I concede that this code was on github for a few weeks, as that made the prototyping faster and allowed us to fail faster, but it was open and reviewed with the team above (and with the cores in that team). Based on our learning from that prototype activity, and feedback of those cores, we are upstreaming the improved production code to gerrit. All that involvement from the neutron core reviewers was critical in keeping the larger PoC team above focused on neutron norms and expectations from design and code. On Thu, May 22, 2014 at 4:03 PM, Maru Newby ma...@redhat.com wrote: On May 22, 2014, at 1:59 PM, Mandeep Dhami dh...@noironetworks.com wrote: Maru's concerns are that: 1. It is large 2. It is complex As per the discussion in the irc meeting today, I hope it is clear now that eventual size and complexity are not real issue. Rather, I am concerned at how we get there. I keep talking about 'iterating in the open', and want to make it clear what I mean by this. It involves proposing a reviewable patch to openstack gerrit, working with reviewers to get the patch merged, and then incorporating their feedback into the overall design to drive the implementation of future patches. 'Iterating in the open' does not imply working outside of gerrit to create a monolithic codebase that needs to be manually decomposed into reviewable chunks at the end. I understand that this may be an effective way to create a POC, but it is not an effective way to produce code that can be merged into Neutron. Core reviewers have a mandate to ensure the quality of every patch, and their feedback is likely to have an impact on subsequent implementation. And Armando's related concerns are: 3. Could dev/review cycles be better spent on refactoring 4. If refactored neutron was available, would a simpler option become more viable Let me address them in that order. 1. Re: It is large Group policy has an ambitious goal - provide devop teams with policy based controls that are usable at scale and with automation (say a higher governance layer like Congress). The fact that meeting a large challenge requires more code is natural. We understand that challenge, and that is why we did a prototype (as PoC that was demonstrated on the summit). And based on that learning we are incrementally creating patches for building the group based policy. Just because a task is large, we as neutron can not shy away from building it. That will only drive people who need it out side neutron (as we are seeing with the frustration that the LBaaS team had because they have a requirement that is large as well). Again, the amount of code is not the problem. How code is introduced into the tree, and how the design is socialized (both with developers and users), _is_ of critical importance. Neutron is not alone in requiring an 'iterate in the open' approach - it is a characteristic common to many open source projects. 2. Re: It is complex Complexity depends on the context. Our goal was to make the end-user's life simpler (and more automated). To achieve some of that simplicity, we required a little more complexity in the implementation. We decide to make that arbitrage - a little higher complexity in implementation to allow for simpler usage. But we were careful and did not want to impose that complexity on every use case - hence a lot of that is optional (and exercised only if the use case needs it). Unfortunately the model, has to model all of it so as it not add complexity later in upgrade and backward compatibility issues. We choose to do architecture upfront, and then implement it incrementally. Doing upfront architecture is fine, so long as the architecture also evolves in response to feedback from the review process in gerrit. Similarly, incremental implementation is not enough - it needs to happen in gerrit. And to be clear, the tool is not the critical factor. When I say gerrit, I mean that each patch needs to receive core reviewer attention and that subsequent patches incorporate their feedback. The team came up with the model currently in model based on that review and evaluation all the proposals in the document that you refer. It is easy to make general comments, but unless you participate in the process and sign up to writing the code, those comments are not going to help with solving the original problem. And this _is_ open-source. If you disagree, please write code and the community can decide for itself as to what model is actually simple to use for them. Curtailing efforts
Re: [openstack-dev] [neutron][group-based-policy] Should we revisit the priority of group-based policy?
OK. On Thu, May 22, 2014 at 5:13 PM, Maru Newby ma...@redhat.com wrote: On May 22, 2014, at 4:35 PM, Mandeep Dhami dh...@noironetworks.com wrote: each patch needs to receive core reviewer attention and that subsequent patches incorporate their feedback. At least two core neutron members were involved in creating the PoC, and at least two more cores were involved in reviews at various times. In addition to them, senior developers from at least seven networking companies were involved in developing this code. I concede that this code was on github for a few weeks, as that made the prototyping faster and allowed us to fail faster, but it was open and reviewed with the team above (and with the cores in that team). Based on our learning from that prototype activity, and feedback of those cores, we are upstreaming the improved production code to gerrit. All that involvement from the neutron core reviewers was critical in keeping the larger PoC team above focused on neutron norms and expectations from design and code. The feedback from reviewers needs to be provided on openstack infrastructure rather than outside it so that it is both visible to all reviewers (not just those directly involved) and that an enduring history of the process is retained. These requirements were not met in working in github on the POC, regardless of your protestations of how 'open' that work was and of who was involved. This isn't to suggest that out-of-tree prototyping isn't useful - of course it is. But I think it important to recognize that out-of-tree development is unlikely to be an effective way to develop code that can be easily merged to Neutron, and that the project can ill-afford the additional review cost it is likely to impose. As such, and as was agreed to in the irc meeting this morning, the way forward is to recognize that the POC is best considered a prototype useful in informing efforts to iterate in the open. m. On Thu, May 22, 2014 at 4:03 PM, Maru Newby ma...@redhat.com wrote: On May 22, 2014, at 1:59 PM, Mandeep Dhami dh...@noironetworks.com wrote: Maru's concerns are that: 1. It is large 2. It is complex As per the discussion in the irc meeting today, I hope it is clear now that eventual size and complexity are not real issue. Rather, I am concerned at how we get there. I keep talking about 'iterating in the open', and want to make it clear what I mean by this. It involves proposing a reviewable patch to openstack gerrit, working with reviewers to get the patch merged, and then incorporating their feedback into the overall design to drive the implementation of future patches. 'Iterating in the open' does not imply working outside of gerrit to create a monolithic codebase that needs to be manually decomposed into reviewable chunks at the end. I understand that this may be an effective way to create a POC, but it is not an effective way to produce code that can be merged into Neutron. Core reviewers have a mandate to ensure the quality of every patch, and their feedback is likely to have an impact on subsequent implementation. And Armando's related concerns are: 3. Could dev/review cycles be better spent on refactoring 4. If refactored neutron was available, would a simpler option become more viable Let me address them in that order. 1. Re: It is large Group policy has an ambitious goal - provide devop teams with policy based controls that are usable at scale and with automation (say a higher governance layer like Congress). The fact that meeting a large challenge requires more code is natural. We understand that challenge, and that is why we did a prototype (as PoC that was demonstrated on the summit). And based on that learning we are incrementally creating patches for building the group based policy. Just because a task is large, we as neutron can not shy away from building it. That will only drive people who need it out side neutron (as we are seeing with the frustration that the LBaaS team had because they have a requirement that is large as well). Again, the amount of code is not the problem. How code is introduced into the tree, and how the design is socialized (both with developers and users), _is_ of critical importance. Neutron is not alone in requiring an 'iterate in the open' approach - it is a characteristic common to many open source projects. 2. Re: It is complex Complexity depends on the context. Our goal was to make the end-user's life simpler (and more automated). To achieve some of that simplicity, we required a little more complexity in the implementation. We decide to make that arbitrage - a little higher complexity in implementation to allow for simpler usage. But we were careful and did not want to impose that complexity on every use case - hence a lot of that is optional (and exercised only if the use case needs
Re: [openstack-dev] [neutron][group-based-policy] Should we revisit the priority of group-based policy?
Hi Armando: Those are good points. I will let Bob Kukura chime in on the specifics of how we intend to do that integration. But if what you see in the prototype/PoC was our final design for integration with Neutron core, I would be worried about that too. That specific part of the code (events/notifications for DHCP) was done in that way just for the prototype - to allow us to experiment with the part that was new and needed experimentation, the APIs and the model. That is the exact reason that we did not initially check the code to gerrit - so that we do not confuse the review process with the prototype process. But we were requested by other cores to check in even the prototype code as WIP patches to allow for review of the API parts. That can unfortunately create this very misunderstanding. For the review, I would recommend not the WIP patches, as they contain the prototype parts as well, but just the final patches that are not marked WIP. If you such issues in that part of the code, please DO raise that as that would be code that we intend to upstream. I believe Bob did discuss the specifics of this integration issue with you at the summit, but like I said it is best if he represents that side himself. Regards, Mandeep On Thu, May 22, 2014 at 8:19 PM, Armando M. arma...@gmail.com wrote: On 22 May 2014 13:59, Mandeep Dhami dh...@noironetworks.com wrote: Maru's concerns are that: 1. It is large 2. It is complex And Armando's related concerns are: 3. Could dev/review cycles be better spent on refactoring 4. If refactored neutron was available, would a simpler option become more viable This is not what I meant to say, and if this was the message that came across I apologize for the confusion; let me rephrase: After looking (and relooking) at the initial patches proposed I started to question why the GP plugin functionality was so tightly integrated with the Neutron core functionality; even though I might guess the thinking process, I wonder if such tight coupling was the result of design decisions made without thoroughly considering alternative approaches. Without going too much into details during this email, I can see in the above mentioned patches that lots of plumbing code (like Nova and dhcp notifiers handling code) is put in place to make direct calls to core plugin methods: this spills implementation details across multiple parts of the project; it's fragile because it's prone to ripple effects due to lack of proper encapsulation: if a change is made in the plugin API or its implementation, the whole thing needs to be looked at, end-to-end: this does not scale from a human perspective (probably only a handful of people can really say that they know the Neutron codebase inside-out), it is difficult to maintain, it is difficult to test, it is difficult to extend. etc etc. Instead, I was advocating for an approach where GP and Neutron Core integrate via (a well defined and stable) REST API, or similar (more abstracted) mechanisms; this has obvious benefits because the two become suddenly loosely coupled: a change done in the way Neutron deals with DHCP messages is not going to have any effect to how the GP plugin create resources. Also, any potential refactoring of the Neutron Core will not cause the GP team to take the burden of bringing the current implementation forward. This is why I was proposing that we talk about the introduction of integration hooks, should they (or lack thereof) have been the culprit of such an initial design approach. Please, take my comments as initial reviews to the above patches, if you will :) To be constructive, as a core reviewer who should suggest alternatives, I would invite the people reading this thread to have a look at [1] and [2]: these were introduced by RAX to their cut of Neutron, having in mind exactly what I have been saying: adding functionality with zero impact to existing code. If something along those lines can be achieved, then this would be very beneficial for the progress of the GP effort as it transitions and evolves into/within Neutron, IMO. Having said that, I am making these points without particular reference to the complexity of the GP model being proposed, or the approach being taken to introduce it to the tree. Even though I share some of Maru's points, good architecture and design principles in software development should be followed wherever possible and irrespective of the domain where such development occur. Many thanks, Armando [1] - https://github.com/roaet/wafflehaus [2] - https://github.com/roaet/wafflehaus.neutron Let me address them in that order. 1. Re: It is large Group policy has an ambitious goal - provide devop teams with policy based controls that are usable at scale and with automation (say a higher governance layer like Congress). The fact that meeting a large challenge requires more code is natural. We understand
Re: [openstack-dev] [Neutron] Core API refactoring
Hi Sean: While the APIs might not be changing*, I suspect that there are significant design decisions being made**. These changes are probably more significant than any new feature being discussed. As a community, are we expected to document these design changes and review these changes as well? I am still trying to figure out what Neutron's review standards are. On one hand, I am seeing code review comments that reject a patch for cosmetic changes (like a name change from what was in the reviewed blueprint), to having an attitude that something as core and central to neutron as refactoring and a major API update to v3 not needing a design document/review. It is my opinion, and my recommendation, that the proposed changes be documented and reviewed by same standard that we have for other features. * I believe that v3 API is being introduced and chnages are being made, but I might have mis-understood. ** I was under the impression that in addition to the Pecan updates, there was going to be refactoring to use taskflow as well. And that I expect to have significant control flow impact, and that is what I really wanted to review. Regards, mandeep On Wed, May 21, 2014 at 6:52 AM, Collins, Sean sean_colli...@cable.comcast.com wrote: On Tue, May 20, 2014 at 05:18:57PM EDT, Mandeep Dhami wrote: Renewing the thread, is there a blueprint for this refactoring effort? In the email thread till now, we have just had an etherpad link. I would like to get more deeply involved in design/implementation and review of these changes and I get a feeling that not being able to attend the Atlanta summit is going to be a significant barrier to participation in this critical effort. It is possible there is a misconception here: refactoring the API core does not mean changing the APIs that are presented to the user. We are in the process of replacing a homegrown WSGI with Pecan to make the WSGI layer of Neutron cleaner and easier to create API extensions. http://pecan.readthedocs.org/en/latest/index.html -- Sean M. Collins ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Core API refactoring
Hi Salvatore: Comments inline as well This is a bit obscure to me. I read it as you're hinting the core team or part of it has double standards. In that case I would invite you to clarify. Last week, I had requested reference to a design document for neutron refactoring work. As this is a critical change, I wanted to understand what was being proposed (and hopefully contribute to it's implementation). The only feedback I received was about the etherpad of the meeting, and I was hoping for more. I re-requested it again, yesterday, just in case my request had got buried under all summit related email that everyone was so busy with last week. The update from Sean seem to suggest to me that we needed blueprints only if the public API changes, and not for design changes that are internal to neutron. My comments were meant to extol the virtue of creating a design document, and reviewing all significant design changes, even for updates that do not change the public API. In that context, I was trying to make a point that reviews should be prioritized by importance/impact to the project and not based on any other criteria (like, say a delta difference from previous spec - something which would be triggered by a simple name change - and something that thought that I had seen in a review just that very day). When I sent that email I did not know who was working it, there was no aspersion cast or implied. The only mention of core was in something as core and central to neutron as refactoring ... and I never mentioned the core team. If you are working on it, I apologize if it came across that way to you. At the same time, I am not comfortable with the conclusion that you drew about my intentions. I am happy to address this face-to-face if that helps (or hangout to hangout) - I am not that adroit with emails and I worry that my response may again be misunderstood. I am not entirely sure what kind of v3 APIs you're referring to. My understanding was that there was a proposal for a V3 API. But based on Mark Mclain's response to this thread that is probably now slated for K-release. I don't see a mandatory relationship between pecan and taskflow. I don't see a relationship either. I, simplistically, put all the following issues in the refactoring bucket: 1. Paste + stuff = Pecan 2. V2 = V3 3. Taskflow 4. Cleaning up of distributes locks No relationship between them is necessarily implied (either in design or in timing). I figured that any refactoring effort will have to design solution for each of them and then weigh priority based on effort/risk/impact/value of each of those changes. I suspect that there are more - that was just what I understood to be urgent or important. There was a session discussing the possibility of having a task based interaction between the front end and the backend - taskflow would be a candidate task manager solution there. But from what I gathered this was orthogonal to the Pecan effort, which is merely a replacement of the home-grown wsgi framework neutron is running today. I understand. Regards, Mandeep On Wed, May 21, 2014 at 4:02 PM, Salvatore Orlando sorla...@nicira.comwrote: Some comments inline, Salvatore On 21 May 2014 15:23, Mandeep Dhami dh...@noironetworks.com wrote: Hi Sean: While the APIs might not be changing*, I suspect that there are significant design decisions being made**. These changes are probably more significant than any new feature being discussed. As a community, are we expected to document these design changes and review these changes as well? I am still trying to figure out what Neutron's review standards are. On one hand, I am seeing code review comments that reject a patch for cosmetic changes (like a name change from what was in the reviewed blueprint), to having an attitude that something as core and central to neutron as refactoring and a major API update to v3 not needing a design document/review. This is a bit obscure to me. I read it as you're hinting the core team or part of it has double standards. In that case I would invite you to clarify. It is my opinion, and my recommendation, that the proposed changes be documented and reviewed by same standard that we have for other features. As for any other change requiring a blueprint, they will obviously be submitted to neutron-specs and reviewed; as long as they're not there, they do not exist. * I believe that v3 API is being introduced and chnages are being made, but I might have mis-understood. I am not entirely sure what kind of v3 APIs you're referring to. I think no changes to existing subnet/router/floating IPs APIs and object models have been proposed so far. Anyway, I was not at the summit either, so my information might not be accurate. ** I was under the impression that in addition to the Pecan updates, there was going to be refactoring to use taskflow as well. And that I expect to have
Re: [openstack-dev] [Neutron] Core API refactoring
Renewing the thread, is there a blueprint for this refactoring effort? In the email thread till now, we have just had an etherpad link. I would like to get more deeply involved in design/implementation and review of these changes and I get a feeling that not being able to attend the Atlanta summit is going to be a significant barrier to participation in this critical effort. Regards, Mandeep On Thu, May 15, 2014 at 10:48 AM, Mandeep Dhami dh...@noironetworks.comwrote: Thanks for the link, Fawad. I had actually seen the etherpad, but I was hoping that there was a design document backing it up. Regards, Mandeep On Thu, May 15, 2014 at 10:15 AM, Fawad Khaliq fa...@plumgrid.com wrote: Hi Mandeep, You can find discussion/details in the etherpad link[1]. [1] https://etherpad.openstack.org/p/refactoring-the-neutron-core Thanks, Fawad Khaliq (m) +1 408.966.2214 On Thu, May 15, 2014 at 9:40 AM, Mandeep Dhami dh...@noironetworks.comwrote: Hi: I am not at the conference this week, but it is my understanding that there was a proposal for neutron core API refactoring discussed yesterday. I am trying to catch up with that discussion, is there a formal design description or blueprint that I can review? Thanks, Mandeep - ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][neutron][mysql] IMPORTANT: MySQL Galera does *not* support SELECT ... FOR UPDATE
On a side note, I'm rather ignorant on python frameworks for distributed
coordination... concoord?
Is zookeper something that should be ruled out because of language
restrictions?
I have not used zookeeper, so there might be reasons to use it where we
have to write java code,
but as long as zookeeper is added as a package dependency (apt-get/yum
install zookeeper),
with a python front-end* the language should not matter.
* (like kazoo? I will need to investigate)
Regards,
Mandeep
On Mon, May 19, 2014 at 3:26 PM, Salvatore Orlando sorla...@nicira.comwrote:
Some comments inline.
Salvatore
On 19 May 2014 20:32, sridhar basam sridhar.ba...@gmail.com wrote:
On Mon, May 19, 2014 at 1:30 PM, Jay Pipes jaypi...@gmail.com wrote:
Stackers,
On Friday in Atlanta, I had the pleasure of moderating the database
session at the Ops Meetup track. We had lots of good discussions and heard
important feedback from operators on DB topics.
For the record, I would not bring this point up so publicly unless I
believed it was a serious problem affecting a large segment of users. When
doing an informal survey of the users/operators in the room at the start of
the session, out of approximately 200 people in the room, only a single
person was using PostgreSQL, about a dozen were using standard MySQL
master/slave replication, and the rest were using MySQL Galera clustering.
So, this is a real issue for a large segment of the operators -- or at
least the ones at the session. :)
We are one of those operators that use Galera for replicating our mysql
databases. We used to see issues with deadlocks when having multiple mysql
writers in our mysql cluster. As a workaround we have our haproxy
configuration in an active-standby configuration for our mysql VIP.
I seem to recall we had a lot of the deadlocks happen through Neutron.
When we go through our Icehouse testing, we will redo our multimaster mysql
setup and provide feedback on the issues we see.
The SELECT... FOR UPDATE issue is going to be a non trivial one for
neutron as well. Some components, like IPAM, heavily rely on it.
However, Neutron is a lot more susceptible to deadlock problems than nova
because it does not implement at the moment a retry mechanism.
This is something which should be added during the Juno release cycle
regardless of all the other enhancement currently being planned, such as
task oriented operations.
thanks,
Sridhar
Peter Boros, from Percona, was able to provide some insight on MySQL
Galera topics, and one issue came up that is likely the cause of a lot of
heartache for operators who use MySQL Galera (or Percona XtraDB Cluster).
We were discussing whether people had seen deadlock issues [1] when
using MySQL Galera in their deployment, and were brainstorming on why
deadlocks might be seen. I had suggested that perhaps Nova's use of
autoincrementing primary keys may have been the cause. Peter pretty quickly
dispatched that notion, saying that Galera automatically handles
autoincrementing keys using managed innodb_autoincrement_increment and
innodb_autoincrement_offset config options.
I think at that point I mentioned that there were a number of places
that were using the SELECT ... FOR UPDATE construct in Nova (in SQLAlchemy,
it's the with_lockmode('update') modification of the query object). Peter
promptly said that was a problem. MySQL Galera does not support SELECT ...
FOR UPDATE, since it has no concept of cross-node locking of records and
results are non-deterministic.
So... what to do?
For starters, some information on the use of with_lockmode() in Nova and
Neutron...
Within Nova, there are actually only a few places where
with_lockmode('update') is used. Unfortunately, the use of
with_lockmode('update') is in the quota code, which tends to wrap largish
blocks of code within the Nova compute execution code.
Within Neutron, however, the use of with_lockmode('update') is all over
the place. There are 44 separate uses of it in 11 different files.
I will report on a separate thread on this, so that we can have an
assessment of where locking statements are used and why.
We have a number of options:
I thin option 0 should be to rework/redesign the code, where possible, to
avoid DB-level locking at all.
1) Stop using MySQL Galera for databases of projects that contain
with_lockmode('update')
This looks hideous, but I am afraid this is what all people wishing to
deploy Icehouse should consider doing.
2) Put a big old warning in the docs somewhere about the problem of
potential deadlocks or odd behaviour with Galera in these projects
3) For Nova and Neutron, remove the use of with_lockmode('update') and
instead use a coarse-grained file lock or a distributed lock manager for
those areas where we need deterministic reads or quiescence.
We had an attempt at implementing a sort of distributed lock for neutron:
Re: [openstack-dev] [Neutron] Core API refactoring
Thanks for the link, Fawad. I had actually seen the etherpad, but I was hoping that there was a design document backing it up. Regards, Mandeep On Thu, May 15, 2014 at 10:15 AM, Fawad Khaliq fa...@plumgrid.com wrote: Hi Mandeep, You can find discussion/details in the etherpad link[1]. [1] https://etherpad.openstack.org/p/refactoring-the-neutron-core Thanks, Fawad Khaliq (m) +1 408.966.2214 On Thu, May 15, 2014 at 9:40 AM, Mandeep Dhami dh...@noironetworks.comwrote: Hi: I am not at the conference this week, but it is my understanding that there was a proposal for neutron core API refactoring discussed yesterday. I am trying to catch up with that discussion, is there a formal design description or blueprint that I can review? Thanks, Mandeep - ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] ServiceVM IRC meeting minutes May 6 (was Re: [Neutron] ServiceVM IRC meeting(May 6 Tuesday 5:00(AM)UTC-))
I think that might an issue of access to google docs from China (in general, not an issue specific to this document). On Wed, May 7, 2014 at 8:05 PM, Isaku Yamahata isaku.yamah...@gmail.comwrote: Hi. The document is - public on the web - anyone can comment So I don't think it's due to setting of google-doc. On Wed, May 07, 2014 at 09:31:49PM +0800, neutrondev neutron...@163.com wrote: hello, Is there anyone may kindly send me the content of this meeting, i can not visit docs.google.com in China. url: https://docs.google.com/presentation/d/14dvV3S9Eph2z-auk34I_Ftld-lHA3VMoyNWAPRTeWgE/edit?usp=sharing many thanks! At 2014-05-06 14:54:09,Isaku Yamahata isaku.yamah...@gmail.com wrote: Here's the minute. The May 13 will be skipped. The next meeting is on May 20. bmelanda, hareesh, if you have items for session agenda, please update ether and replay this mail. AGREED: unconference Monday 5pm- at the summit ACTION: whoever goes to the unconference board and secure the room ACTION: yamahata update the etherpad for the session ACTION: bmelanda, hareeshpc update session adgenda in etherpad ACTION: bmelanda, yamahata add terminology https://wiki.openstack.org/wiki/ServiceVM/terminology for convergence LINK: https://etherpad.openstack.org/p/servicevm LINK: https://wiki.openstack.org/wiki/ServiceVM/terminology LINK: https://wiki.openstack.org/wiki/ServiceVM lots of short-term gap-filler discussion thanks, Isaku Yamahata On Fri, May 02, 2014 at 02:01:31PM +0900, Isaku Yamahata isaku.yamah...@gmail.com wrote: Hi. This is a reminder mail for the servicevm IRC meeting May 6, 2014 Tuesdays 5:00(AM)UTC- #openstack-meeting on freenode (May 13 will be skipped due to design summit) * design summit plan - unconference * status update * new project planning - project name code name: virtue, ginie, jeeve,... topic name: servicevm, hosting device,... - design API/model - way to review: gerrit or google-doc? - design strategy * open discussion -- Isaku Yamahata isaku.yamah...@gmail.com -- Isaku Yamahata isaku.yamah...@gmail.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Isaku Yamahata isaku.yamah...@gmail.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][ml2] Etherpad for the design session on Modular L2 Agents
Thanks Mohammad, this is sorely needed. I will update ether pad for our needs. Regards, Mandeep On Tue, May 6, 2014 at 7:01 PM, Mohammad Banikazemi m...@us.ibm.com wrote: Thanks for the suggestion. That's what I plan to do next (barring other possible suggestions). While the sharing is limited in some cases, it appears to be significant in other cases (e.g., the ovs and the mlnx agents). Best, Mohammad [image: Inactive hide details for yamamoto---05/06/2014 08:24:18 PM--- Please note that I have created an etherpad for the Modular L2]yamamoto---05/06/2014 08:24:18 PM--- Please note that I have created an etherpad for the Modular L2 Agent session at [1]. From: yamam...@valinux.co.jp (YAMAMOTO Takashi) To: openstack-dev@lists.openstack.org, Date: 05/06/2014 08:24 PM Subject: Re: [openstack-dev] [Neutron][ml2] Etherpad for the design session on Modular L2 Agents -- Please note that I have created an etherpad for the Modular L2 Agent session at [1]. It relates to one of the three topics that are to be discussed during the Modular Layer2 Agent design session scheduled for Thursday 11:50am-12:30pm [2]. Please update the etherpad and/or use the ML or contact me if you have any comments/suggestions/criticism. (I have also asked several people who have worked on the agents and/or expressed interest in this topic individually for their input.) can you pick a few existing agents (eg. ovs and lb) and prototype a modular agent to demonstrate how much of the code can be shared by this effort? YAMAMOTO Takashi Thanks, -Mohammad [1] https://etherpad.openstack.org/p/juno-neutron-modular-l2-agent [2] http://junodesignsummit.sched.org/event/4205f2c4084e8a0c3bd8d420803ddf02#.U2k7RdyZpjI ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] explanations on the current state of config file handling
I second the conf.d model. Regards, Mandeep On Sun, May 4, 2014 at 10:13 AM, John Dickinson m...@not.mn wrote: To add some color, Swift supports both single conf files and conf.d directory-based configs. See http://docs.openstack.org/developer/swift/deployment_guide.html#general-service-configuration . The single config file pattern is quite useful for simpler configurations, but the directory-based ones becomes especially useful when looking at cluster configuration management tools--stuff that auto-generates and composes config settings (ie non hand-curated configs). For example, the conf.d configs can support each middleware config or background daemon process in a separate file. Or server settings in one file and common logging settings in another. (Also, to answer before it's asked [but I don't want to derail the current thread], I'd be happy to look at oslo config parsing if it supports the same functionality.) --John On May 4, 2014, at 9:49 AM, Armando M. arma...@gmail.com wrote: If the consensus is to unify all the config options into a single configuration file, I'd suggest following what the Nova folks did with [1], which I think is what Salvatore was also hinted. This will also help mitigate needless source code conflicts that would inevitably arise when merging competing changes to the same file. I personally do not like having a single file with gazillion options (the same way I hate source files with gazillion LOC's but I digress ;), but I don't like a proliferation of config files either. So I think what Mark suggested below makes sense. Cheers, Armando [1] - https://github.com/openstack/nova/blob/master/etc/nova/README-nova.conf.txt On 2 May 2014 07:09, Mark McClain mmccl...@yahoo-inc.com wrote: On May 2, 2014, at 7:39 AM, Sean Dague s...@dague.net wrote: Some non insignificant number of devstack changes related to neutron seem to be neutron plugins having to do all kinds of manipulation of extra config files. The grenade upgrade issue in neutron was because of some placement change on config files. Neutron seems to have *a ton* of config files and is extremely sensitive to their locations/naming, which also seems like it ends up in flux. We have grown in the number of configuration files and I do think some of the design decisions made several years ago should probably be revisited. One of the drivers of multiple configuration files is the way that Neutron is currently packaged [1][2]. We’re packaged significantly different than the other projects so the thinking in the early years was that each plugin/service since it was packaged separately needed its own config file. This causes problems because often it involves changing the init script invocation if the plugin is changed vs only changing the contents of the init script. I’d like to see Neutron changed to be a single package similar to the way Cinder is packaged with the default config being ML2. Is there an overview somewhere to explain this design point? Sadly no. It’s a historical convention that needs to be reconsidered. All the other services have a single config config file designation on startup, but neutron services seem to need a bunch of config files correct on the cli to function (see this process list from recent grenade run - http://paste.openstack.org/show/78430/ note you will have to horiz scroll for some of the neutron services). Mostly it would be good to understand this design point, and if it could be evolved back to the OpenStack norm of a single config file for the services. +1 to evolving into a more limited set of files. The trick is how we consolidate the agent, server, plugin and/or driver options or maybe we don’t consolidate and use config-dir more. In some cases, the files share a set of common options and in other cases there are divergent options [3][4]. Outside of testing the agents are not installed on the same system as the server, so we need to ensure that the agent configuration files should stand alone. To throw something out, what if moved to using config-dir for optional configs since it would still support plugin scoped configuration files. Neutron Servers/Network Nodes /etc/neutron.d neutron.conf (Common Options) server.d (all plugin/service config files ) service.d (all service config files) Hypervisor Agents /etc/neutron neutron.conf agent.d (Individual agent config files) The invocations would then be static: neutron-server —config-file /etc/neutron/neutron.conf —config-dir /etc/neutron/server.d Service Agents: neutron-l3-agent —config-file /etc/neutron/neutron.conf —config-dir /etc/neutron/service.d Hypervisors (assuming the consolidates L2 is finished this cycle): neutron-l2-agent —config-file /etc/neutron/neutron.conf —config-dir /etc/neutron/agent.d
Re: [openstack-dev] [neutron] Updates to the template for Neutron BPs
Just for clarification. Jenkins link in the description puts the generated HTML in the section Juno approved specs even tho' the blueprint is still being reviewed. Am I looking at the right link? Regards, Mandeep On Sun, Apr 20, 2014 at 10:54 PM, Mike Scherbakov mscherba...@mirantis.comwrote: Yes, thanks, that's exactly what I was looking for! On Mon, Apr 21, 2014 at 12:03 AM, Kyle Mestery mest...@noironetworks.comwrote: On Sat, Apr 19, 2014 at 5:11 PM, Mike Scherbakov mscherba...@mirantis.com wrote: Hi Kyle, I built template and it looks awesome. We are considering to use same approach for Fuel. My assumption is that spec will be on review for a negotiation time, which is going to be quite a while. In my opinion, it is not always very convenient to read spec in gerrit. Agreed, though for some specs, this is actually an ok way to do reviews. Did you guys have any thoughts on auto-build these specs into html on every patch upload? So we could go somewhere and see built results, without a requirement to fetch neutron-specs, and run tox? The possible drawback is that reader won't see gerrit comments.. I followed what Nova was going and committed code into openstack-infra/config which allows for some jenkins jobs to run when we commit to the neutron-specs gerrit. [1]. As an example, look at this commit here [2]. If you look at the latest Jenkins run, you'll see a link which takes you to an HTML generated document [3] which you can review in lieu of the raw restructured text in gerrit. That will actually generate all the specs in the repository, so you'll see the Example Spec along with the Nuage one I used for reference here. Hope that helps! Kyle [1] https://review.openstack.org/#/c/88069/ [2] https://review.openstack.org/#/c/88690/ [3] http://docs-draft.openstack.org/90/88690/3/check/gate-neutron-specs-docs/fe4282a/doc/build/html/ Thanks, On Sat, Apr 19, 2014 at 12:08 AM, Kyle Mestery mest...@noironetworks.com wrote: Hi folks: I just wanted to let people know that we've merged a few patches [1] to the neutron-specs repository over the past week which have updated the template.rst file. Specifically, Nachi has provided some instructions for using Sphinx diagram tools in lieu of asciiflow.com. Either approach is fine for any Neutron BP submissions, but Nachi's patch has some examples of using both approaches. Bob merged a patch which shows an example of defining REST APIs with attribute tables. Just an update for anyone proposing BPs for Juno at the moment. Thanks! Kyle [1] https://review.openstack.org/#/q/status:merged+project:openstack/neutron-specs,n,z ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Mike Scherbakov #mihgen ___ 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 -- Mike Scherbakov #mihgen ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] Updates to the template for Neutron BPs
Got it. Thanks. Regards, Mandeep On Sun, Apr 20, 2014 at 11:49 PM, Mike Scherbakov mscherba...@mirantis.comwrote: That's because spec was proposed to the juno/ folder. Look at https://raw.githubusercontent.com/openstack/neutron-specs/master/doc/source/index.rst, if spec is in juno/ folder, then contents shows it as approved one. Once merged, it means approved, right? So it is going to be Ok after merge. Though a better reminding than just draft in the url could be required if many start to mess it up... On Mon, Apr 21, 2014 at 10:43 AM, Kevin Benton blak...@gmail.com wrote: Yes. It shows up in the approved section since it's just a build of the patch as-is. The link is titled gate-neutron-specs-docs in the message from Jenkins. -- Kevin Benton On Sun, Apr 20, 2014 at 11:37 PM, Mandeep Dhami dh...@noironetworks.comwrote: Just for clarification. Jenkins link in the description puts the generated HTML in the section Juno approved specs even tho' the blueprint is still being reviewed. Am I looking at the right link? Regards, Mandeep On Sun, Apr 20, 2014 at 10:54 PM, Mike Scherbakov mscherba...@mirantis.com wrote: Yes, thanks, that's exactly what I was looking for! On Mon, Apr 21, 2014 at 12:03 AM, Kyle Mestery mest...@noironetworks.com wrote: On Sat, Apr 19, 2014 at 5:11 PM, Mike Scherbakov mscherba...@mirantis.com wrote: Hi Kyle, I built template and it looks awesome. We are considering to use same approach for Fuel. My assumption is that spec will be on review for a negotiation time, which is going to be quite a while. In my opinion, it is not always very convenient to read spec in gerrit. Agreed, though for some specs, this is actually an ok way to do reviews. Did you guys have any thoughts on auto-build these specs into html on every patch upload? So we could go somewhere and see built results, without a requirement to fetch neutron-specs, and run tox? The possible drawback is that reader won't see gerrit comments.. I followed what Nova was going and committed code into openstack-infra/config which allows for some jenkins jobs to run when we commit to the neutron-specs gerrit. [1]. As an example, look at this commit here [2]. If you look at the latest Jenkins run, you'll see a link which takes you to an HTML generated document [3] which you can review in lieu of the raw restructured text in gerrit. That will actually generate all the specs in the repository, so you'll see the Example Spec along with the Nuage one I used for reference here. Hope that helps! Kyle [1] https://review.openstack.org/#/c/88069/ [2] https://review.openstack.org/#/c/88690/ [3] http://docs-draft.openstack.org/90/88690/3/check/gate-neutron-specs-docs/fe4282a/doc/build/html/ Thanks, On Sat, Apr 19, 2014 at 12:08 AM, Kyle Mestery mest...@noironetworks.com wrote: Hi folks: I just wanted to let people know that we've merged a few patches [1] to the neutron-specs repository over the past week which have updated the template.rst file. Specifically, Nachi has provided some instructions for using Sphinx diagram tools in lieu of asciiflow.com. Either approach is fine for any Neutron BP submissions, but Nachi's patch has some examples of using both approaches. Bob merged a patch which shows an example of defining REST APIs with attribute tables. Just an update for anyone proposing BPs for Juno at the moment. Thanks! Kyle [1] https://review.openstack.org/#/q/status:merged+project:openstack/neutron-specs,n,z ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Mike Scherbakov #mihgen ___ 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 -- Mike Scherbakov #mihgen ___ 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 -- Kevin Benton ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Mike Scherbakov #mihgen ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] review hour?
+1 On Mon, Apr 21, 2014 at 8:54 AM, mar...@redhat.com mandr...@redhat.comwrote: On 21/04/14 18:29, Kyle Mestery wrote: On Mon, Apr 21, 2014 at 9:38 AM, mar...@redhat.com mandr...@redhat.com wrote: Hi, I think both PTL candidates mentioned process improvements wrt contributions and reviews in their candidacy announcements. As a new Neutron dev I have seen that it is easy for reviews to go unnoticed, especially when they are stand-alone bug fixes that aren't part of a particular blueprint group (and so aren't discussed/highlighted at the various sub-team meetings). Of course this is also compounded by a seemingly heavy backlog of reviews. I realise that all core/non-core devs are doing as much as they can and though more cores will help, it takes a long time to develop people into this role. I was wondering if a 'review hour' would help. This is something Lucas Gomez told me about; the Ironic core team has a weekly hour slot in which they discuss x number of reviews and approve or -1 them. Besides getting reviews cleared quicker, it also opens the process up. It will allow new contributors to (more quickly) learn about the kinds of things core reviewers look for in a patch and also give real-time feedback (e.g. could just use #openstack-neutron for discussion during the hour). I feel that this could have an impact on the review backlog even if this only tackling the oldest 5 reviews for example. Do any of the core devs think this would be a good thing, and do you think you have the time for it? This is an interesting idea Marios, thanks for proposing it! Are you saying we should have a Review Hour on IRC, where we walk through XX number of reviews as a team? That's an interesting idea actually, and I'd be in favor of something like this. We could rotate timeslots so as to get everyone on the team (both core and non-core) a chance to participate. Can you attend our weekly meeting today [1] where we can discuss this as a team? Thanks very much for responding Kyle, I was worried about my message sounding 'complainy' - I will try my best to attend the meeting today, though it is at midnight here (CET +1hrs) so I typically only get to catch up on the logs. Depending on whether others think setting up the irc review hour is a good idea, one side effect would be that we then have a second 'neutron meeting' slot during the week (even if this is only for reviews). If we pick this time carefully we could even alternate between 'weekly meeting' and 'review meeting' to make it easier for folks in Europe to join the weekly meeting (and make it less harsh for people in Asia Pacific who have to get up very early for the current slot [1]). Though this is of course just speculation and I'm really getting ahead of myself (I was going to include this last thought in my original email but it was already long enough) thanks, marios [1] [1] http://www.timeanddate.com/worldclock/meetingtime.html?iso=20140421p1=137p2=179p3=136p4=37p5=166p6=248p7=196p8=47 Thanks! Kyle [1] https://wiki.openstack.org/wiki/Network/Meetings thanks, marios ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] review hour?
If scaling becomes the issue, you can always do review at sub-team level with at least two cores in each review meeting (say neutron-parity, ML2, Services, LBaaS, etc). But probably best to start with one meeting and hit that scale issue first. Regards, Mandeep On Mon, Apr 21, 2014 at 9:20 AM, Akihiro Motoki amot...@gmail.com wrote: Hi, Previously Neutron team had ReviewDays [1] and core members made themselves focus on reviews and be available on IRC channel one or more day(s) of each week (as possible as they can). The number of neutron reviews has increased compared to that time and I am afraid one or two days reviews cannot deal with neutron reviews, but the similar mechanism might work to make things better. [1] https://wiki.openstack.org/wiki/Neutron/ReviewDays On Tue, Apr 22, 2014 at 12:54 AM, mar...@redhat.com mandr...@redhat.com wrote: On 21/04/14 18:29, Kyle Mestery wrote: On Mon, Apr 21, 2014 at 9:38 AM, mar...@redhat.com mandr...@redhat.com wrote: Hi, I think both PTL candidates mentioned process improvements wrt contributions and reviews in their candidacy announcements. As a new Neutron dev I have seen that it is easy for reviews to go unnoticed, especially when they are stand-alone bug fixes that aren't part of a particular blueprint group (and so aren't discussed/highlighted at the various sub-team meetings). Of course this is also compounded by a seemingly heavy backlog of reviews. I realise that all core/non-core devs are doing as much as they can and though more cores will help, it takes a long time to develop people into this role. I was wondering if a 'review hour' would help. This is something Lucas Gomez told me about; the Ironic core team has a weekly hour slot in which they discuss x number of reviews and approve or -1 them. Besides getting reviews cleared quicker, it also opens the process up. It will allow new contributors to (more quickly) learn about the kinds of things core reviewers look for in a patch and also give real-time feedback (e.g. could just use #openstack-neutron for discussion during the hour). I feel that this could have an impact on the review backlog even if this only tackling the oldest 5 reviews for example. Do any of the core devs think this would be a good thing, and do you think you have the time for it? This is an interesting idea Marios, thanks for proposing it! Are you saying we should have a Review Hour on IRC, where we walk through XX number of reviews as a team? That's an interesting idea actually, and I'd be in favor of something like this. We could rotate timeslots so as to get everyone on the team (both core and non-core) a chance to participate. Can you attend our weekly meeting today [1] where we can discuss this as a team? Thanks very much for responding Kyle, I was worried about my message sounding 'complainy' - I will try my best to attend the meeting today, though it is at midnight here (CET +1hrs) so I typically only get to catch up on the logs. Depending on whether others think setting up the irc review hour is a good idea, one side effect would be that we then have a second 'neutron meeting' slot during the week (even if this is only for reviews). If we pick this time carefully we could even alternate between 'weekly meeting' and 'review meeting' to make it easier for folks in Europe to join the weekly meeting (and make it less harsh for people in Asia Pacific who have to get up very early for the current slot [1]). Though this is of course just speculation and I'm really getting ahead of myself (I was going to include this last thought in my original email but it was already long enough) thanks, marios [1] [1] http://www.timeanddate.com/worldclock/meetingtime.html?iso=20140421p1=137p2=179p3=136p4=37p5=166p6=248p7=196p8=47 Thanks! Kyle [1] https://wiki.openstack.org/wiki/Network/Meetings thanks, marios ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Interest in discussing vendor plugins for L3 services?
I would be interested as well (UTC-8). Regards, Mandeep On Wed, Feb 12, 2014 at 8:18 AM, Eugene Nikanorov enikano...@mirantis.comwrote: I'd be interested too. Thanks, Eugene. On Wed, Feb 12, 2014 at 7:51 PM, Carl Baldwin c...@ecbaldwin.net wrote: Paul, I'm interesting in joining the discussion. UTC-7. Any word on when this will take place? Carl On Mon, Feb 3, 2014 at 3:19 PM, Paul Michali p...@cisco.com wrote: I'd like to see if there is interest in discussing vendor plugins for L3 services. The goal is to strive for consistency across vendor plugins/drivers and across service types (if possible/sensible). Some of this could/should apply to reference drivers as well. I'm thinking about these topics (based on questions I've had on VPNaaS - feel free to add to the list): How to handle vendor specific validation (e.g. say a vendor has restrictions or added capabilities compared to the reference drivers for attributes). Providing client feedback (e.g. should help and validation be extended to include vendor capabilities or should it be delegated to server reporting?) Handling and reporting of errors to the user (e.g. how to indicate to the user that a failure has occurred establishing a IPSec tunnel in device driver?) Persistence of vendor specific information (e.g. should new tables be used or should/can existing reference tables be extended?). Provider selection for resources (e.g. should we allow --provider attribute on VPN IPSec policies to have vendor specific policies or should we rely on checks at connection creation for policy compatibility?) Handling of multiple device drivers per vendor (e.g. have service driver determine which device driver to send RPC requests, or have agent determine what driver requests should go to - say based on the router type) If you have an interest, please reply to me and include some days/times that would be good for you, and I'll send out a notice on the ML of the time/date and we can discuss. Looking to hearing form you! PCM (Paul Michali) MAIL p...@cisco.com IRCpcm_ (irc.freenode.net) TW@pmichali GPG key4525ECC253E31A83 Fingerprint 307A 96BB 1A4C D2C7 931D 8D2D 4525 ECC2 53E3 1A83 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
