Open Stack

Hi folks


I think this thread is still mixing topics. I feel we can archive 1000 mails :P
so let me name it and let me write my thought on this.


[Topic1] Nova parity priority

I do understand concern and this is highest priority.
However, group based policy effort won't slower this effort.


Because most skilled developers such as  Mark, Oleg and Carl are
working hard for this making happen.
I'm also trying to POC non-DVR approach such as
migrating nova-network directly to the neutron. (Sorry, this is off
topic, but if you are interested in this,
https://docs.google.com/presentation/d/12w28HhNpLltSpA6pJvKWBiqeEusaI-NM-OZo8HNyH2w/edit#slide=id.p
is my thought )

Even if codes for GBP and Nova parity is really independent, so it
won't conflict.
Note that if you have any task item related with nova parity work, plz ping me.

[Topic2] Neutron community decision making process

I'm super lazy guy, so I'll be very disappointed the code i write rejected..
( http://openstackreactions.enovance.com/2013/09/when-my-patch-get-2/ )

We are discussing this spec for couple of releases…
IMO, we should have voting process such as IETF or let PTL make final
decision like TTX saying.

[Topic3] Group based policy specs

I'm not jumped in this one. I have already shared my thought on this.
This is still "extension" proposal. so we should let user choose use
this or not.
If it is proven for wide use, then we can discuss making it for core API.

I'm also working on another extension spec. It is deferred for next
release, (http://openstackreactions.enovance.com/2014/04/getting-told-that-this-feature-will-not-be-accepted-before-next-release/
)

but if you have any interest on this plz ping me

http://docs-draft.openstack.org/12/93112/16/check/gate-neutron-specs-docs/afb346d/doc/build/html/specs/juno/security_group_action.html
http://docs-draft.openstack.org/12/93112/16/check/gate-neutron-specs-docs/afb346d/doc/build/html/specs/juno/security_group_for_network.html

[Topic4] Where we develop group based policy stuffs. And generally,
service related stuffs.

I do remember the LBaaS new project meeting at the Summit. I remember
someone says "I don't trust neutron makes this feature make it working
in Juno timeframe.".  I guess he was right..

We should have a new project for service related stuffs.
( http://openstackreactions.enovance.com/2013/11/when-a-new-openstack-project-announce-itself/
)


Best
Nachi

2014-08-07 19:23 GMT+09:00 Thierry Carrez <thierry at openstack.org>:
> Armando M. wrote:
>> This thread is moving so fast I can't keep up!
>>
>> The fact that troubles me is that I am unable to grasp how we move
>> forward, which was the point of this thread to start with. It seems we
>> have 2 options:
>>
>> - We make GBP to merge as is, in the Neutron tree, with some minor
>> revision (e.g. naming?);
>> - We make GBP a stackforge project, that integrates with Neutron in some
>> shape or form;
>>
>> Another option, might be something in between, where GBP is in tree, but
>> in some sort of experimental staging area (even though I am not sure how
>> well baked this idea is).
>>
>> Now, as a community we all need make a decision; arguing about the fact
>> that the blueprint was approved is pointless.
>
> I agree with you: it is possible to change your mind on a topic and
> revisit past decisions. In past OpenStack history we did revert merged
> commits and remove existing functionality because we felt it wasn't that
> much of a great idea after all. Here we are talking about making the
> right decision *before* the final merging and shipping into a release,
> which is kind of an improvement. The spec system was supposed to help
> limit such cases, but it's not bullet-proof.
>
> In the end, if there is no consensus on that question within the Neutron
> project (and I hear both sides have good arguments), our governance
> gives the elected Neutron PTL the power to make the final call. If the
> disagreement is between projects (like if Nova disagreed with the
> Neutron decision), then the issue could be escalated to the TC.
>
> Regards,
>
> --
> Thierry Carrez (ttx)
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev