Re: [openstack-dev] [Policy][Group-based Policy] Audio stream for GBP Design Session in Paris

[Mandeep Dhami]

As no one was online, I closed the webex session.

On Tue, Nov 4, 2014 at 10:07 AM, Mandeep Dhami 
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 
> 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

[Mandeep Dhami]

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

[Mandeep Dhami]

Got it. So we will be discussing this in the 2PM meeting today. Correct?

Regards,
Mandeep

On Mon, Oct 27, 2014 at 10:02 AM, Kyle Mestery  wrote:

> On Mon, Oct 27, 2014 at 11:48 AM, Mandeep Dhami 
> wrote:
> > 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?
> >
> Per my email to the list recently [1], the weekly rotating Neutron
> meeting is now an on-demand agenda, rather than a rollup of sub-team
> status. I'm saying this particular topic (advanced services spinout)
> will be discussed in Paris, and it's worth adding it to the weekly
> Neutron meeting [2] agenda in the on-demand section. This is a pretty
> large topic with many interested parties, thus the attention in the
> broader neutron meeting.
>
> Thanks,
> Kyle
>
> [1]
> http://lists.openstack.org/pipermail/openstack-dev/2014-October/048328.html
> [2] https://wiki.openstack.org/wiki/Network/Meetings
>
> > Regards,
> > Mandeep
> >
> >
> > On Mon, Oct 27, 2014 at 6:56 AM, Kyle Mestery 
> wrote:
> >>
> >> On Mon, Oct 27, 2014 at 12:15 AM, Sumit Naiksatam
> >>  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)
> >> >  wrote:
> >> >> Hi Doug:
> >> >>
> >> >> On 10/26/14, 6:01 PM, "Doug Wiegley"  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
>

Re: [openstack-dev] [Neutron][LBaaS][Octavia] Octavia's API becoming spun out LBaaS

[Mandeep Dhami]

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

> On Mon, Oct 27, 2014 at 12:15 AM, Sumit Naiksatam
>  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)
> >  wrote:
> >> Hi Doug:
> >>
> >> On 10/26/14, 6:01 PM, "Doug Wiegley"  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" 
> 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 w

Re: [openstack-dev] [neutron][policy] Group-based Policy next steps

[Mandeep Dhami]

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

Re: [openstack-dev] [neutron][policy] Group-based Policy next steps

[Mandeep Dhami]

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

[Mandeep Dhami]

+1

I agree that this is a good idea.

Regards,
Mandeep





On Thu, Aug 28, 2014 at 10:13 AM, Jay Pipes  wrote:

> On 08/28/2014 12:50 PM, Michael Still wrote:
>
>> On Thu, Aug 28, 2014 at 6:53 AM, Daniel P. Berrange 
>> 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] [infra] [neutron] [tc] Neutron Incubator workflow

[Mandeep Dhami]

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  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] Author tags

[Mandeep Dhami]

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

> On Wed, Aug 27, 2014 at 8:24 AM, Gary Kotton  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] [neutron] Incubator concerns from packaging perspective

[Mandeep Dhami]

+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 
wrote:

>
> On Aug 23, 2014, at 5:36 PM, Maru Newby  wrote:
>
> >
> > On Aug 23, 2014, at 4:06 AM, Sumit Naiksatam 
> wrote:
> >
> >> On Thu, Aug 21, 2014 at 7:28 AM, Kyle Mestery 
> wrote:
> >>> On Thu, Aug 21, 2014 at 5:12 AM, Ihar Hrachyshka 
> 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  > > 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 coul

Re: [openstack-dev] [neutron] Spec exceptions are closed, FPF is August 21

[Mandeep Dhami]

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.  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  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 
>> 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 
>>> wrote:
>>>
>>>> On Thu, Jul 31, 2014 at 7:11 AM, Yuriy Taraday 
>>>> wrote:
>>>> > On Wed, Jul 30, 2014 at 11:52 AM, Kyle Mestery 
>>>> 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? N

Re: [openstack-dev] [neutron] Spec exceptions are closed, FPF is August 21

[Mandeep Dhami]

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

> On Thu, Jul 31, 2014 at 7:11 AM, Yuriy Taraday 
> wrote:
> > On Wed, Jul 30, 2014 at 11:52 AM, Kyle Mestery 
> 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

Re: [openstack-dev] [neutron] Spec exceptions are closed, FPF is August 21

[Mandeep Dhami]

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  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][policy] Bridging the 2-group gap in group policy

[Mandeep Dhami]

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 
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  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] Specs approved for Juno-3 and exceptions

[Mandeep Dhami]

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  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 > <mailto:sgor...@redhat.com>> wrote:
>>
>> - Original Message -
>>  > From: "Jay Pipes" 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
>> appro

Re: [openstack-dev] [neutron] [not-only-neutron] How to Contribute upstream in OpenStack Neutron

[Mandeep Dhami]

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

> On 25 July 2014 20:05, Stefano Maffulli  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

[Mandeep Dhami]

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

> On Fri, Jul 25, 2014 at 4: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?
> >
> 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 
> wrote:
> >>
> >> - Original Message -
> >> > From: "Jay Pipes" 
> >> > 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

Re: [openstack-dev] [Neutron] Specs approved for Juno-3 and exceptions

[Mandeep Dhami]

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

> - Original Message -
> > From: "Jay Pipes" 
> > 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

Re: [openstack-dev] [Neutron] Seeking opinions on scope of code refactoring...

[Mandeep Dhami]

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)  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  wrote:
>
> Paul,
>
> On Fri, May 23, 2014 at 8:24 AM, Paul Michali (pcm)  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
>

Re: [openstack-dev] [neutron][group-based-policy] Should we revisit the priority of group-based policy?

[Mandeep Dhami]

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  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] Network tomography

[Mandeep Dhami]

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?

[Mandeep Dhami]

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.  wrote:

> On 22 May 2014 13:59, Mandeep Dhami  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 the

Re: [openstack-dev] [neutron][group-based-policy] Should we revisit the priority of group-based policy?

[Mandeep Dhami]

OK.


On Thu, May 22, 2014 at 5:13 PM, Maru Newby  wrote:

>
> On May 22, 2014, at 4:35 PM, Mandeep Dhami 
> 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  wrote:
> > On May 22, 2014, at 1:59 PM, Mandeep Dhami 
> 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

Re: [openstack-dev] [neutron][group-based-policy] Should we revisit the priority of group-based policy?

[Mandeep Dhami]

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

> On May 22, 2014, at 1:59 PM, Mandeep Dhami 
> 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
>

Re: [openstack-dev] [Neutron] Core API refactoring

[Mandeep Dhami]

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?

[Mandeep Dhami]

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.  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
> than GP

Re: [openstack-dev] [Neutron] Core API refactoring

[Mandeep Dhami]

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

> Some comments inline,
>
> Salvatore
>
> On 21 May 2014 15:23, Mandeep Dhami  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 ch

Re: [openstack-dev] [Neutron] Core API refactoring

[Mandeep Dhami]

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

[Mandeep Dhami]

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

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

[Mandeep Dhami]

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

> Some comments inline.
>
> Salvatore
>
>
> On 19 May 2014 20:32, sridhar basam  wrote:
>
>>
>>
>>
>> On Mon, May 19, 2014 at 1:30 PM, Jay Pipes  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

Re: [openstack-dev] [Neutron] Core API refactoring

[Mandeep Dhami]

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

[openstack-dev] [Neutron] Core API refactoring

[Mandeep Dhami]

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

Re: [openstack-dev] [Neutron] ServiceVM IRC meeting minutes May 6 (was Re: [Neutron] ServiceVM IRC meeting(May 6 Tuesday 5:00(AM)UTC-))

[Mandeep Dhami]

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

> 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  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" 
> 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  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 Yamahata 
> > >
> > >___
> > >OpenStack-dev mailing list
> > >OpenStack-dev@lists.openstack.org
> > >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> --
> Isaku Yamahata 
>
> ___
> 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

[Mandeep Dhami]

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

[Mandeep Dhami]

I second the conf.d model.

Regards,
Mandeep


On Sun, May 4, 2014 at 10:13 AM, John Dickinson  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.  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  wrote:
> >>
> >> On May 2, 2014, at 7:39 AM, Sean Dague  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-d

Re: [openstack-dev] [Neutron] review hour?

[Mandeep Dhami]

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  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 
> wrote:
> > On 21/04/14 18:29, Kyle Mestery wrote:
> >> On Mon, Apr 21, 2014 at 9:38 AM, mar...@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=20140421&p1=137&p2=179&p3=136&p4=37&p5=166&p6=248&p7=196&p8=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?

[Mandeep Dhami]

+1


On Mon, Apr 21, 2014 at 8:54 AM, mar...@redhat.com wrote:

> On 21/04/14 18:29, Kyle Mestery wrote:
> > On Mon, Apr 21, 2014 at 9:38 AM, mar...@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=20140421&p1=137&p2=179&p3=136&p4=37&p5=166&p6=248&p7=196&p8=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] Updates to the template for Neutron BPs

[Mandeep Dhami]

Got it. Thanks.

Regards,
Mandeep


On Sun, Apr 20, 2014 at 11:49 PM, Mike Scherbakov
wrote:

> 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  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 
>> wrote:
>>
>>> 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
>>>>>  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 p

Re: [openstack-dev] [neutron] Updates to the template for Neutron BPs

[Mandeep Dhami]

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

> Yes, thanks, that's exactly what I was looking for!
>
>
> On Mon, Apr 21, 2014 at 12:03 AM, Kyle Mestery 
> wrote:
>
>> On Sat, Apr 19, 2014 at 5:11 PM, Mike Scherbakov
>>  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] Interest in discussing vendor plugins for L3 services?

[Mandeep Dhami]

I would be interested as well (UTC-8).

Regards,
Mandeep



On Wed, Feb 12, 2014 at 8:18 AM, Eugene Nikanorov
wrote:

> I'd be interested too.
>
> Thanks,
> Eugene.
>
>
> On Wed, Feb 12, 2014 at 7:51 PM, Carl Baldwin  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  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