Re: [openstack-dev] [kuryr] Nominate Kirill Zaitsev as kuryr-tempest-core reviewer

[Gal Sagie]

+1

On Tue, Jul 4, 2017 at 12:28 PM, Daniel Mellado 
wrote:

> Hi Team,
>
> I wanted to nominate Kirill for kuryr-tempest-core reviewer. He's been a
> great help from start both contributing and reviewing.
>
> Please voice your support or concerns if any
>
> Best!
>
> Daniel
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Best Regards ,

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

Re: [openstack-dev] [Dragonflow] Nominating Xiao Hong Hui for core of Dragonflow

[Gal Sagie]

+1

On Thu, Feb 9, 2017 at 12:16 PM, Omer Anson  wrote:

> Hello,
>
> I would like to nominate Xiao Hong Hui as a core reviewer for Dragonflow.
>
> Since he has joined, Xiao has helped move the project forwards with
> important commits and very helpful reviews. He has shown great knowledge in
> Dragonflow, Openstack, and python.
>
> Please voice your opinion. If there are no objections by the weekly
> meeting on the 13th Feb., I will add him to the core list.
>
> Thanks,
> Omer.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Best Regards ,

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

Re: [openstack-dev] [kuryr] Ocata cycle ending and proposing new people as Kuryr cores

[Gal Sagie]

+1 for both.

On Sun, Jan 15, 2017 at 9:05 AM, Irena Berezovsky 
wrote:

>
>
> On Fri, Jan 13, 2017 at 6:49 PM, Antoni Segura Puimedon <
> celeb...@gmail.com> wrote:
>
>> Hi fellow kuryrs!
>>
>> We are getting close to the end of the Ocata and it is time to look back
>> and appreciate the good work all the contributors did. I would like to
>> thank you all for the continued dedication and participation in gerrit, the
>> weekly meetings, answering queries on IRC, etc.
>>
>> I also want to propose two people that I think will help us a lot as core
>> contributors in the next cycles.
>>
>> For Kuryr-lib and kuryr-libnetwork I want to propose Liping Mao. Liping
>> has been contributing a lot of since Mitaka, not just in code but in
>> reviews catching important details and fixing bugs. It is overdue that he
>> gets to help us even more!
>>
>> +1
>
>> For Kuryr-kubernetes I want to propose Ilya Chukhnakov. Ilya got into
>> Kuryr at the end of the Newton cycle and has done a wonderful job in the
>> Kubernetes integration contributing heaps of code and being an important
>> part of the design discussions and patches. It is also time for him to
>> start approving patches :-)
>>
>> +1
>
>>
>> Let's have the votes until next Friday (unless enough votes are cast
>> earlier).
>>
>> Regards,
>>
>> Toni
>>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Best Regards ,

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

[openstack-dev] [Kuryr][Dragonflow] - PTL Non Candacy

[Gal Sagie]

Hello all,

I would like to announce that i will not be running for projects Kuryr or
Dragonflow
PTL.

I believe that both projects shows great value and progress compared to the
time they exists
mostly thanks to the great communities actively working on both of them.

I also strongly believe that the PTL position is one that should be
alternating given there is
a good candidate and i believe there are some great candidates for both
projects.

I will of course still stay involved in both projects and excited to see
what the next
release is going to bring.

Thanks for everyone that closely helped and contributed and lets keep up on
making
OpenStack great together.

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

[openstack-dev] [Dragonflow] - Design summit rooms allocation

[Gal Sagie]

Hello all,

I have opened the following etherpad in order to brainstorm topics and
sessions
for Barcelona summit:

https://etherpad.openstack.org/p/dragonflow-barcelona

Feel free to edit/add anything you would like to discuss about.

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

Re: [openstack-dev] [Kuryr] Proposing vikasc for kuryr-libnetwork core

[Gal Sagie]

The entire core team voted +1.
I have added Vikas to Kuryr core team, Congrats and keep up the good work

Thanks
Gal.

On Thu, Aug 18, 2016 at 7:56 PM, Mohammad Banikazemi  wrote:

> +1
> Vikas has been working on various aspects of Kuryr with dedication for
> some time. So yes it's about time :)
>
> Best,
>
> Mohammad
>
>
> [image: Inactive hide details for Antoni Segura Puimedon ---08/16/2016
> 05:55:48 PM---Hi Kuryrs, I would like to propose Vikas Choudhary]Antoni
> Segura Puimedon ---08/16/2016 05:55:48 PM---Hi Kuryrs, I would like to
> propose Vikas Choudhary for the core team for the
>
> From: Antoni Segura Puimedon 
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Date: 08/16/2016 05:55 PM
> Subject: [openstack-dev] [Kuryr] Proposing vikasc for kuryr-libnetwork
> core
> --
>
>
>
> Hi Kuryrs,
>
> I would like to propose Vikas Choudhary for the core team for the
> kuryr-libnetwork subproject. Vikas has kept submitting patches and reviews
> at a very good rhythm in the past cycle and I believe he will help a lot to
> move kuryr forward.
>
> I would also like to propose him for the core team for the
> kuryr-kubernetes subproject since he has experience in the day to day work
> with kubernetes and can help with the review and refactoring of the
> prototype upstreaming.
>
> Regards,
>
> Antoni Segura Puimedon
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Best Regards ,

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

[openstack-dev] [Kuryr] - Design summit rooms allocation

[Gal Sagie]

Hello all,

We need to decide on the number of rooms we need for the design summit.
I have started the below etherpad so we can all brainstorm the sessions we
would like
to conduct (and who is going to chair them):

https://etherpad.openstack.org/p/kuryr-barcelona

(For the Austin summit we had 1 fishbowl room, 5 working sessions and
Friday half day)

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

Re: [openstack-dev] [Kuryr] Proposing vikasc for kuryr-libnetwork core

[Gal Sagie]

+1 , Vikas has been doing a great work on the project and is a good
addition to the team.


On Wed, Aug 17, 2016 at 12:54 AM, Antoni Segura Puimedon  wrote:

> Hi Kuryrs,
>
> I would like to propose Vikas Choudhary for the core team for the
> kuryr-libnetwork subproject. Vikas has kept submitting patches and reviews
> at a very good rhythm in the past cycle and I believe he will help a lot to
> move kuryr forward.
>
> I would also like to propose him for the core team for the
> kuryr-kubernetes subproject since he has experience in the day to day work
> with kubernetes and can help with the review and refactoring of the
> prototype upstreaming.
>
> Regards,
>
> Antoni Segura Puimedon
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Best Regards ,

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

[openstack-dev] [Dragonflow] - No IRC Meeting Today (1/8/2016)

[Gal Sagie]

Hello All,

Due to some members not able to attend today's meeting, we will cancel it
and
continue the meetings the week after.

If you need an update regarding anything, feel free to stop by
#openstack-dragonflow

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

[openstack-dev] [Kuryr] - Addition of Fuxi as a subproject

[Gal Sagie]

Hello everyone,

The following is a governance request to add project Fuxi as a storage
solution part
for Kuryr (part of Kuryr deliverable) [1]

I hope this can lead to other initiatives that want to work on drivers and
glue code that
connects containers orchestration engines and OpenStack projects.
(For example i believe a Keystone driver for Kubernetes can also be started
as a sub
project)

Please feel free to share your opinions/comments in the mailing list or in
the patch review.

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


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

[openstack-dev] [Kuryr][Magnum] - Kuryr nested containers and Magnum Integration

[Gal Sagie]

Hello all,

I am writing this out to provide awareness and hopefully get some work
started
on the above topic.

We have merged a spec about supporting nested containers and integration
with Magnum
some time ago [1] , Fawad (CCed) led this spec.

We are now seeking for volunteers to start implementing this on both Kuryr
and the needed
parts in Magnum.

Vikas (CCed) volunteered in the last IRC meeting [2] to start and split
this work into sub-tasks
so it will be easier to share, anyone else that is interested to join this
effort is more then welcome to join in and contact Vikas.
I do know several other people showed interest to work on this so i hope we
can pull everyone
together in this thread, or online at IRC.

Thanks
Gal.

[1] https://review.openstack.org/#/c/269039/
[2]
http://eavesdrop.openstack.org/meetings/kuryr/2016/kuryr.2016-06-20-14.00.html
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Dragonflow] - No IRC meeting today (06/13)

[Gal Sagie]

Hello all,

Sorry for the late notice but we will not have an IRC meeting today.
We will continue the IRC meetings next week.

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

Re: [openstack-dev] [Neutron] neutron-lib and dependencies in neutron reference implementation

[Gal Sagie]

For example references to the various different agents which are an
implementation details to me

On Wed, Jun 8, 2016 at 8:51 PM, Henry Gessau  wrote:

> Gal Sagie  wrote:
> > Hello all,
> >
> > I have recently came across some missing constants in neutron-lib and
> sent
> > a patch but i wanted to try and understand the scope of the lib.
> >
> > I see that the Neutron lib consist of many definitions which are actually
> > part of the reference implementation and are not really "generic" Neutron
> > parts.
>
> Can you give specific examples of 'not really generic' constants?
>
> > I am wondering if this is the right approach, especially since i think an
> > end goal is to split between the two (some day..)
> >
> > My suggestion would be to at least split these two in the neutron-lib,
> but maybe
> > i miss understood the scope of the lib
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Best Regards ,

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

[openstack-dev] [Neutron] neutron-lib and dependencies in neutron reference implementation

[Gal Sagie]

Hello all,

I have recently came across some missing constants in neutron-lib and sent
a patch but
i wanted to try and understand the scope of the lib.

I see that the Neutron lib consist of many definitions which are actually
part of the reference
implementation and are not really "generic" Neutron parts.

I am wondering if this is the right approach, especially since i think an
end goal is to split
between the two (some day..)

My suggestion would be to at least split these two in the neutron-lib, but
maybe
i miss understood the scope of the lib

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

[openstack-dev] [Kuryr] - IRC Meeting time change

[Gal Sagie]

Hello Everyone,

Just wanted to let you all know we changed our even biweekly IRC meeting
time.
It is now one hour earlier.

The new meeting time is *every even Monday at 14:00 UTC in
#openstack-meeting-4*
You can see the changing patch here [1]

Thanks
Gal.

[1] https://review.openstack.org/#/c/319739/2
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [magnum][kuryr] Nested containers networking

[Gal Sagie]

Hi Hongbin,

Thank you for starting this thread.
The person that is going to work on this integration is Fawad (CC'ed) and
hopefully others will help
him (We have another person from Huawei that showed intrest in working on
this).

I think Fawad, given that he is the primary person working on this should
be Kuryr liaison for this integration
and it could help alot if he has a contact in Magnum that can work with him
on that closely.
I can also serve as the coordinator between these efforts given that Fawad
is too busy.

The first task in my view is to start describing the action items for this
integration, split the work and address
any unknown issues during this process.

I think that design wise things are pretty close (Fawad, please correct me
if there are any open issues)
and we are just waiting to start the work (and solve any issues as they
come)

Thanks
Gal.


On Mon, May 23, 2016 at 6:35 PM, Hongbin Lu  wrote:

> Hi Kuryr team,
>
>
>
> I want to start this ML to sync up the latest status of the nested
> container networking implementation. Could I know who is implementing this
> feature in Kuryr side and how Magnum team could help in this efforts? In
> addition, I wonder if it makes sense to establish cross-project liaisons
> between Kuryr and Magnum. Magnum relies on Kuryr to implement several
> important features so I think it is helpful to setup a communication
> channel between both teams. Thoughts?
>
>
>
> Best regards,
>
> Hongbin
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Best Regards ,

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

[openstack-dev] [Infra][Kuryr] New sub projects created

[Gal Sagie]

Hello all,

We have created the following repositories  as part of Kuryr:

https://github.com/openstack?utf8=%E2%9C%93&query=kuryr

Would love if anyone from Infra that has access can allow kuryr-core team to
also be able to review/merge code in these new repositories.

Would also love if the TC can approve Kuryr deliverables as reflected by
this change
in this following patch:

https://review.openstack.org/#/c/314057/


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

[openstack-dev] [Dragonflow] - IRC Meeting time

[Gal Sagie]

Hello All,

During the summit we received feedback that many people from the US time
zone
would like to attend our IRC meetings.

Our current time is 0900 UTC which is good for Europe/Israel/China where
most
of our contributors come from.

If you are in the US and would like to participate in our IRC meeting,
please propose
a time on Monday that best fit you (please keep in mind it should be as
early as possible
for us all to be able to attend as well)

If we see there is a good enough interest we will start doing alternating
IRC meetings.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Dragonflow] - No IRC Meeting (5/9)

[Gal Sagie]

Hello Everyone,

We will not have an IRC meeting in the upcoming Monday (5/9), we will
continue doing IRC
meeting in our regular time the week after.

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

[openstack-dev] [Infra][Kuryr] - Sub repositories

[Gal Sagie]

Hello all,

Following the summit discussions and after summit checking we decided its
better for us
to try a sub repositories model for Kuryr (better for packaging and
requirement/dependencies management).

We would like to create additional sub repositories under Kuryr and i was
wondering if the correct
process would be to just create different new projects following [1] and
then update
the governance repository for Kuryr (attaching all these projects as
deliverable of Kuryr).

Or is there a better/simpler method to do this?


Thanks
Gal.

[1] http://docs.openstack.org/infra/manual/creators.html
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][tc] Neutron stadium evolution from Austin

[Gal Sagie]

Maybe it can help if instead of trying to define criteria to which projects
dont fit into
the stadium, try to define in your spec what IT IS, and for what purpose
its there.


On Mon, May 2, 2016 at 8:53 PM, Kyle Mestery  wrote:

> On Mon, May 2, 2016 at 12:22 PM, Armando M.  wrote:
> >
> >
> > On 30 April 2016 at 14:24, Fawad Khaliq  wrote:
> >>
> >> Hi folks,
> >>
> >> Hope everyone had a great summit in Austin and got back safe! :)
> >>
> >> At the design summit, we had a Neutron stadium evolution session, which
> >> needs your immediate attention as it will impact many stakeholders of
> >> Neutron.
> >
> >
> > It's my intention to follow up with a formal spec submission to
> > neutron-specs as soon as I recover from the trip. Then you'll have a more
> > transparent place to voice your concern.
> >
> >>
> >>
> >> To summarize for everyone, our Neutron leadership made the following
> >> proposal for the “greater-good” of Neutron to improve and reduce burden
> on
> >> the Neutron PTL and core team to avoid managing more Neutron drivers:
> >
> >
> > It's not just about burden. It's about consistency first and foremost.
> >
> >>
> >>
> >> Quoting the etherpad [1]
> >>
> >> "No request for inclusion are accepted for projects focussed solely on
> >> implementations and/or API extensions to non-open solutions."
> >
> >
> > By the way, this was brought forward and discussed way before the
> Summit. In
> > fact this is already implemented at the Neutron governance level [1].
> >
> >>
> >> To summarize for everyone what this means is that all Neutron drivers,
> >> which implement non open source networking backends are instantly out
> of the
> >> Neutron stadium and are marked as "unofficial/unsupported/remotely
> >> affiliated" and rest are capable of being tagged as
> "supported/official”.
> >
> >
> > Totally false.
> >
> > All this means is that these projects do not show up in list [1] (minus
> [2],
> > which I forgot): ie. these projects are the projects the Neutron team
> > vouches for. Supportability is not a property tracked by this list. You,
> > amongst many, should know that it takes a lot more than being part of a
> list
> > to be considered a supported solution, and I am actually even surprised
> that
> > you are misled/misleading by bringing 'support' into this conversation.
> >
> > [1] http://governance.openstack.org/reference/projects/neutron.html
> > [2] https://review.openstack.org/#/c/309618/
> >
> >>
> >>
> >> This eliminates all commercial Neutron drivers developed for many
> service
> >> providers and enterprises who have deployed OpenStack successfully with
> >> these drivers. It’s unclear how the OpenStack Foundation will
> communicate
> >> its stance with all the users but clearly this is a huge set back for
> >> OpenStack and Neutron. Neutron will essentially become closed to all
> >> existing, non-open drivers, even if these drivers have been compliant
> with
> >> Neutron API for years and users have them deployed in production,
> forcing
> >> users to re-evaluate their options.
> >
> >
> > Again, totally false.
> >
> > The Neutron team will continue to stand behind the APIs and integration
> > mechanisms in a way that made the journey of breaking down the codebase
> as
> > we know it today possible. Any discussion of evolving these has been done
> > and will be done in the open and with the support of all parties
> involved,
> > non-open solutions included.
> >
> >>
> >>
> >> Furthermore, this proposal will erode confidence in Neutron and
> OpenStack,
> >> and destroy much of the value that the community has worked so hard to
> build
> >> over the years.
> >>
> >>
> >> As a representative and member of the OpenStack community and maintainer
> >> of a Neutron driver (since Grizzly), I am deeply disappointed and
> disagree
> >> with this statement [2]. Tossing out all the non-open solutions is not
> in
> >> the best interest of the end user companies that have built working
> >> OpenStack clusters. This proposal will lead OpenStack end users who
> deployed
> >> different drivers to think twice about OpenStack communities’
> commitment to
> >> deliver solutions they need. Furthermore, this proposal punishes
> OpenStack
> >> companies who developed commercial backend drivers to help end users
> bring
> >> up OpenStack clouds.
> >
> >
> > What? Now you're just spreading FUD.
> >
> > What is being discussed in that etherpad is totally in line with [1],
> which
> > you approved and stood behind, by the way! No-one is breaking anything,
> > we're simply better reflecting what initiatives the Neutron core team is
> > supposed to be accountable for and, as a result, empower the individual
> core
> > teams of those vendor drivers. I appreciate there might be a gap in
> where to
> > describe the effort of these initiatives in [2], but I believe there's
> > something like the marketplace [3] that's better suited for what you're
> > after. IMO, [2] was never intended to be that place, and I stand
> 

[openstack-dev] [Kuryr] - Austin Design Summit

[Gal Sagie]

Hello everyone,

We have split our design summit sessions into topics (and sub topics) for
each session
Please review the topics and agenda here:

https://etherpad.openstack.org/p/kuryr-design-summit

This is still a tentative schedule/agenda, so if you have any
ideas/comments on that agenda
or want to add more topics/points for the written subjects please feel free
to do so, we will
finalize the schedule hopefully one week before the summit.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron][Dragonflow] - Austin Design Summit

[Gal Sagie]

Hello everyone,

We have started writing an agenda for our design summit sessions,
please feel free to raise ideas/comments/questions in the following
etherpad:

https://etherpad.openstack.org/p/dragonflow-design-summit

If you are a user/operator and would like to raise questions regarding our
road map
or/and our current deployments and testing, please attend our fishbowl
session, we are more
then welcome to share every information we have. (including control/data
plane performance
testing we are concluding soon)

Hope to see you all there!
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Openstack-operators] - Containers Sessions in Austin Ops@Summit

[Gal Sagie]

Hello all,

We are going to have two sessions in the ops summit about containers
deployment with
OpenStack. (Monday, probably going to be 4:40-6:10)

In order to make these sessions useful i think the most important topic
that i want
to tackle is feedback from operators running OpenStack and containers (Bare
metal, nested containers with/without Magnum, with/without Kuryr).

Problems, use cases, networking strategy, storage, combining bare metal and
Openstack, multi tenancy networking, Kubernetes, Mesos, Swarm and more..

If you are deploying OpenStack with containers or thinking about it, or
designing solutions for
such use cases please add topics and challenges you would like to discuss
in the following etherpad:
===

https://etherpad.openstack.org/p/austin-ops-containers



Understanding use cases/challenges and real world deployments will greatly
help prioritise
tasks and features in containers related OpenStack projects, your
cooperation is appreciated.

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

Re: [openstack-dev] [magnum][kuryr] Shared session in design summit

[Gal Sagie]

All these slots are fine with me, added Kuryr team as CC to make sure most
can attend any of these times.



On Wed, Mar 30, 2016 at 5:12 PM, Hongbin Lu  wrote:

> Gal,
>
>
>
> Thursday 4:10 – 4:50 conflicts with a Magnum workroom session, but we can
> choose from:
>
> · 11:00 – 11:40
>
> · 11:50 – 12:30
>
> · 3:10 – 3:50
>
>
>
> Please let us know if some of the slots don’t work well with your schedule.
>
>
>
> Best regards,
>
> Hongbin
>
>
>
> *From:* Gal Sagie [mailto:gal.sa...@gmail.com]
> *Sent:* March-30-16 2:00 AM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [magnum][kuryr] Shared session in design
> summit
>
>
>
> Anything you pick is fine with me, Kuryr fishbowl session is on
> Thursday 4:10 - 4:50, i personally
>
> think the Magnum integration is important enough and i dont mind using
> this time for the session as well.
>
>
>
> Either way i am also ok with the 11-11:40 and the 11:50-12:30 sessions or
> the 3:10-3:50
>
>
>
> On Tue, Mar 29, 2016 at 11:32 PM, Hongbin Lu 
> wrote:
>
> Hi all,
>
>
>
> As discussed before, our team members want to establish a shared session
> between Magnum and Kuryr. We expected a lot of attendees in the session so
> we need a large room (fishbowl). Currently, Kuryr has only 1 fishbowl
> session, and they possibly need it for other purposes. A solution is to
> promote one of the Magnum fishbowl session to be the shared session, or
> leverage one of the free fishbowl slot. The schedule is as below.
>
>
>
> Please vote your favorite time slot:
> http://doodle.com/poll/zuwercgnw2uecs5y .
>
>
>
> Magnum fishbowl session:
>
> · 11:00 - 11:40 (Thursday)
>
> · 11:50 - 12:30
>
> · 1:30 - 2:10
>
> · 2:20 - 3:00
>
> · 3:10 - 3:50
>
>
>
> Free fishbowl slots:
>
> · 9:00 – 9:40 (Thursday)
>
> · 9:50 – 10:30
>
> · 3:10 – 3:50 (conflict with Magnum session)
>
> · 4:10 – 4:50 (conflict with Magnum session)
>
> · 5:00 – 5:40 (conflict with Magnum session)
>
>
>
> Best regards,
>
> Hongbin
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
>
> --
>
> Best Regards ,
>
> The G.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Best Regards ,

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

Re: [openstack-dev] [magnum][kuryr] Shared session in design summit

[Gal Sagie]

Anything you pick is fine with me, Kuryr fishbowl session is on
Thursday 4:10 - 4:50, i personally
think the Magnum integration is important enough and i dont mind using this
time for the session as well.

Either way i am also ok with the 11-11:40 and the 11:50-12:30 sessions or
the 3:10-3:50

On Tue, Mar 29, 2016 at 11:32 PM, Hongbin Lu  wrote:

> Hi all,
>
>
>
> As discussed before, our team members want to establish a shared session
> between Magnum and Kuryr. We expected a lot of attendees in the session so
> we need a large room (fishbowl). Currently, Kuryr has only 1 fishbowl
> session, and they possibly need it for other purposes. A solution is to
> promote one of the Magnum fishbowl session to be the shared session, or
> leverage one of the free fishbowl slot. The schedule is as below.
>
>
>
> Please vote your favorite time slot:
> http://doodle.com/poll/zuwercgnw2uecs5y .
>
>
>
> Magnum fishbowl session:
>
> · 11:00 - 11:40 (Thursday)
>
> · 11:50 - 12:30
>
> · 1:30 - 2:10
>
> · 2:20 - 3:00
>
> · 3:10 - 3:50
>
>
>
> Free fishbowl slots:
>
> · 9:00 – 9:40 (Thursday)
>
> · 9:50 – 10:30
>
> · 3:10 – 3:50 (conflict with Magnum session)
>
> · 4:10 – 4:50 (conflict with Magnum session)
>
> · 5:00 – 5:40 (conflict with Magnum session)
>
>
>
> Best regards,
>
> Hongbin
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Best Regards ,

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

[openstack-dev] Gal Sagie candidacy for the TC

[Gal Sagie]

Hello All,

I have been working on OpenStack for the past year, currently the PTL of two
projects part of the big-tent: Dragonflow and Kuryr and contributing to OVN and
to Neutron core.

The past year is by no doubt the best year of my career, working with
the community
and doing so openly for 100% of my time has been a great experience.
I fell in love with the OpenStack way and i keep trying to promote
open communities by being
a speaker at Numerous summits, arranging meetups, writing a blog about the
projects and overall trying to raise awareness for working open source
both internally
at my organization and externally.

I would love to contribute and be part of the TC to share my vision
for the road ahead
with the rest of the TC members and help drive it together with all the
projects that make OpenStack what it is.

The following points describe my high level vision and what i will
pursue in the next
year:

1) Containers and OpenStack - i think this intersection is a crucial
part for the
   future of OpenStack, more and more workloads are turning into
containers and this
   in my view will only increase.
   enabling containers engines and OpenStack to work together will be
crucial for
   future deployments, this is one of the reason project Kuryr was
started and its my
   goal to make sure we align a mixed OpenStack containers strategy
for all major
   projects and future projects.

   I am already trying to arrange a containers session at the Ops
summit in Austin
   in order to better understand these environments and their challenges and i
   believe OpenStack flexibility can show real value to these environments.

2) Big-Tent, Users/Operators - I am all in favor of removing barriers
for innovation
   and being more on the allowing side then dismissing, but i feel the
picture of
   OpenStack as a whole for users and operators is not clear enough.
   Big number of projects, big number of configuration options and a
very hard time
   deploying OpenStack.

   Grouping projects and interests together and delegating responsibility is
   important, Neutron big-stadium is a good initiative but it didn't
work as planned
   and i hope to tackle this area both for the project teams but even
more importantly for
   the users and deployers, we need to define quality better and we
need to present
   a better overall picture of what OpenStack is and how its best and
simplest deployed.

3) Hybrid Cloud - This is an area OpenStack can show alot of value, it
spans across many
   areas like networking, storage, compute, backup and disaster
recovery, orchestration
   and more.
   I hope to try and work with the TC members and the project teams to raise
   awareness for hybrid and multi site enablement in all areas of
OpenStack, rather its
   federation or centralized orchestration we need to solve use cases
that are becoming
   more and more relevant.

4) Application in the middle - i think its important to understand our
users use cases
   and to me, OpenStack users are also the applications that run on top of it.
   Bridging the gap between the infrastructure and the application
needs helps prioritize
   and deliver better features for our projects and i hope to help in
that direction.


I plan to work with project teams to raise awareness for the above points
i dont believe in intervention, i think the TC role is to be a guiding
and helping body that
represent the community voice rather then an enforcer and i plan to keep doing
things this way.

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

[openstack-dev] [Kuryr] - IRC Meeting canceled today

[Gal Sagie]

Hello all,

Since there is a number of members that cant attend the IRC meeting today
we will
cancel it.

Sorry for the late announcement.

I have updated the agenda for the meeting, lets postpone the same agenda
for the meeting next week.

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

[openstack-dev] [Neutron][Dragonflow] IRC Meeting tomorrow (3/28) - 0900 UTC

[Gal Sagie]

Hello All,

We will have an IRC meeting tomorrow (Monday, 3/28) at 0900 UTC
in #openstack-meeting-4

Please review the expected meeting agenda here:
https://wiki.openstack.org/wiki/Meetings/Dragonflow

You can view last meeting action items and logs here:
*http://eavesdrop.openstack.org/meetings/dragonflow/2016/dragonflow.2016-03-21-08.59.html
*

Please update the agenda if you have any subject you would like to discuss
about.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Kuryr] - Austin design summit sessions

[Gal Sagie]

Hello all,

We have started this etherpad [1] in order to asses the number of sessions
needed
for Kuryr.

We have received 5 work sessions and 1 fishbowl session. [2]
Lets brainstorm and propose more ideas on the etherpad and start splitting
the
subjects to sessions with priorities.

Anyone that wish to volunteer and lead a specific session is more then
welcome
to propose him/her self on the etherpad.

[1] https://etherpad.openstack.org/p/kuryr-design-summit
[2]
http://lists.openstack.org/pipermail/openstack-dev/2016-March/089467.html
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Kuryr] Clarification of expanded mission statement

[Gal Sagie]

Hi Russell,

Thanks for starting this thread, i have been wanting to do so myself.

First, to me Kuryr is much more then just providing a "libnetwork driver"
or a "CNI driver"
in the networking part.

Kuryr goal (to me at least) is to simplify orchestration, management and
performance
and avoid vendor lock-in by providing these drivers but also being able to
expose and enhance additional
policy level features that OpenStack has but are lacking in COEs, We are
also looking at easier
deployment and packaging and providing additional value with features that
make things more efficient and address issues
operators/users are facing (like attaching to existing Neutron networks).

We see our selfs operating both on OpenStack projects, helping with
features needed for this integration but
also in any other project (like Kubernetes / Docker) if this will make more
sense and show better value.

The plan is to continue this with storage, we will have to examine things
and decide where is the best
place to locate them the pros and cons.
I personally don't want to run and start implementing things at other
communities and under other
governance model unless they make much more sense and show better value for
the overall solution.
So my initial reaction is that we can show a lot of value in the storage
part as part of OpenStack Kuryr and hence
the mission statement change.

There are many features that i believe we can work in that are currently
lacking and we will
need to examine them one by one and keep doing the design and spec process
open with the community
so everyone can review and judge the value.
The last thing i am going to do is drive to re-implement things that are
already there and in good enough shape,
none of us have the need or time to do that :)

In the storage area i see the plugins (and not just for Kubernetes), i see
the persistent and re-using of storage
parts as being interesting to start with.
Another area that i included as storage is mostly disaster recovery and
backup, i think we can bring a lot of value
to containers deployments by leveraging projects like Smaug and Freezer
which offer application backups
and recovery.
I really prefer we do this thinking process together as a community and i
already talked with some people that showed
interest in some of these features.

My intention was to first get the TC approval to explore this area and make
sure it doesnt conflict and
only then start working on defining the details again with the broad
community, openly just like we do
everything else.


On Fri, Mar 18, 2016 at 10:12 PM, Fox, Kevin M  wrote:

> I'd assume a volume plugin for cinder support and/or a volume plugin for
> manila support?
>
> Either would be useful.
>
> Thanks,
> Kevin
> --
> *From:* Russell Bryant [rbry...@redhat.com]
> *Sent:* Friday, March 18, 2016 4:59 AM
> *To:* OpenStack Development Mailing List (not for usage questions);
> gal.sa...@gmail.com
> *Subject:* [openstack-dev] [Kuryr] Clarification of expanded mission
> statement
>
> The Kuryr project proposed an update to its mission statement and I agreed
> to start a ML thread seeking clarification on the update.
>
> https://review.openstack.org/#/c/289993
>
> The change expands the current networking focus to also include storage
> integration.
>
> I was interested to learn more about what work you expect to be doing.  On
> the networking side, it's clear to me: a libnetwork plugin, and now perhaps
> a CNI plugin.  What specific code do you expect to deliver as a part of
> your expanded scope?  Will that code be in Kuryr, or be in upstream
> projects?
>
> If you don't know yet, that's fine.  I was just curious what you had in
> mind.  We don't really have OpenStack projects that are organizing around
> contributing to other upstreams, but I think this case is fine.
>
> --
> Russell Bryant
>



-- 
Best Regards ,

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

[openstack-dev] [Kuryr] PTL Candidacy for Gal Sagie

[Gal Sagie]

I would like to propose my candidacy for Kuryr PTL position.

Kuryr has only recently joined OpenStack big-tent and i would like to
receive the official trust of the community and continue serving as the
PTL for a full release cycle.

I think that Kuryr serve an important role in current OpenStack eco-system
and solve new problems that many users are facing starting to deploy
containers environments mixed with OpenStack.

Kuryr is a relatively new project but i am proud to say that we already have
a very diverse community and feel that we operate openly and advancing in
the
right direction.
I would like us to keep doing that and advance even faster in the next
cycle, I
have and will continue to devote time to bring more new contributors and
users
into Kuryr.

Kuryr is at first a team effort, me and Toni (apuimedo) from Midokura are
doing
this together all the way from the start and hopefully continue so in the
future.
I would also like to thank all the great people and contributors helping and
working together with us on Kuryr, you guys are doing great job!

My goals for Kuryr to the next release are:

* Stability, Test coverage and benchmarking - This is important for every
  project but especially for Kuryr that is facing and working with models
and
  frameworks that are experimental and changing quite often.
  As more users considering deploying Kuryr, our quality assurance become
more
  and more critical but also our advantage over existing solutions.

* Kubernetes Integration - This effort has already started and we already
have
  what seems to be a good design and a POC implementation of this, i would
like
  us to keep that great work from Antoni Segura Puimedon, Irena Berezovsky,
  Taku Fukushima and Jaume Devesa.
  We also need to start looking at providing extra enhancement and policy
to the
  deployments, working together with the Kubernetes and Neutron communities
to
  accomplish this.

* Magnum and Nested containers - We have a great spec and proposal for this
  done by Fawad Khaliq and i hope to soon be able to bring more interested
resources
  to work on this with him and hopefully myself as well.
  To me, the goal is for Kuryr to be the default Magnum networking driver
and
  this is one big step in this direction which we do openly with the Magnum
team.

* Operators / users - I would like for us to be more involved and
responsive for
  users needs and requirements, Mike Spreitzer from IBM is helping us drive
this effort.
  I am working on providing more reference architecture of such mixed
environments
  which will help us prioritize and find the best use cases to focus on.
  I am also working internally in Huawei trying to bring these operational
requirements.

  I think packaging and Kolla integration are major part of this effort and
makes the
  process of deploying Kuryr simple and easy, we need to continue all the
good work that
  was done on this front and add support for more and more existing Neutron
plugins

* Containers storage - My plan is to expand Kuryr mission statement to also
bridge between
  containers orchestration engines and models and the various storage and
backup projects
  in OpenStack to provide simplified management and extra added value
features for
  containers deployment.
  I hope that we will start these discussions, designs and work during the
next
  release and do it hand in hand with all of these projects.

* Added value features - Like being able to attach to existing
networks/ports,
  a very use full feature for production use cases that i hear is needed
quite a lot and is being
  implemented by Mohammad Banikazemi.
  We need to identify any other feature that simplify and improve
containers networking
  and work to provide it.

* Increase visibility - Put focus on providing more documentation, blog
posts and arrange
  meetups and talks for all of us to spread the word about Kuryr.
  I feel that operational documentation is very important for our first
users.

* New contributors - I personally hope that more companies (like RedHat and
Mirantis) will
  join our effort and share their vision with us in order to provide a
better solution
  to the community.
  I am also working on more active involvement from Huawei and hopefully
from other
  companies just as well.

Thanks and feel free to email me with any question,

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

[openstack-dev] [Neutron][Dragonflow] IRC Meeting tomorrow (3/14) - 0900 UTC

[Gal Sagie]

Hello All,

We will have an IRC meeting tomorrow (Monday, 3/14) at 0900 UTC
in #openstack-meeting-4

I personally will not be able to attend, Eran Gampel will chair it instead.

Please review the expected meeting agenda here:
https://wiki.openstack.org/wiki/Meetings/Dragonflow

You can view last meeting action items and logs here:
http://eavesdrop.openstack.org/meetings/dragonflow/2016/dragonflow.2016-03-07-09.00.html

Please update the agenda if you have any subject you would like to discuss
about.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Kuryr] IRC Meeting tomorrow (3/14) - 1500 UTC

[Gal Sagie]

Hello All

We will have an IRC meeting tomorrow (3/14) at 1500UTC
in #openstack-meeting-4

Please review the expected meeting agenda here:
https://wiki.openstack.org/wiki/Meetings/Kuryr

You can view last meeting action items and logs here:
http://eavesdrop.openstack.org/meetings/kuryr/2016/kuryr.2016-03-08-03.01.html

Please update the agenda if you have any subject you would like to discuss
about.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Kuryr] IRC Meeting Tuesday (3/8) - 0300 UTC

[Gal Sagie]

Hello All

We will have an IRC meeting in Tuesday (3/8) at 0300 UTC
in #openstack-meeting-4

Please review the expected meeting agenda here:
https://wiki.openstack.org/wiki/Meetings/Kuryr

You can view last meeting action items and logs here:
http://eavesdrop.openstack.org/meetings/kuryr/2016/kuryr.2016-02-29-15.01.html

Please update the agenda if you have any subject you would like to discuss
about.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron][Dragonflow] IRC Meeting tomorrow (3/7) - 0900 UTC

[Gal Sagie]

Hello All,

We will have an IRC meeting tomorrow (Monday, 3/7) at 0900 UTC
in #openstack-meeting-4

I personally will not be able to attend, Eran Gampel will chair it instead.

Please review the expected meeting agenda here:
https://wiki.openstack.org/wiki/Meetings/Dragonflow

You can view last meeting action items and logs here:
http://eavesdrop.openstack.org/meetings/dragonflow/2016/dragonflow.2016-02-29-09.00.html

Please update the agenda if you have any subject you would like to discuss
about.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron][Dragonflow] IRC Meeting tomorrow (2/29) - 0900 UTC

[Gal Sagie]

Hello All,

We will have an IRC meeting tomorrow (Monday, 2/29) at 0900 UTC
in #openstack-meeting-4

Please review the expected meeting agenda here:
https://wiki.openstack.org/wiki/Meetings/Dragonflow

You can view last meeting action items and logs here:
http://eavesdrop.openstack.org/meetings/dragonflow/2016/dragonflow.2016-02-22-09.00.html

Please update the agenda if you have any subject you would like to discuss
about.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Kuryr] IRC Meeting tomorrow (2/29) - 1500 UTC

[Gal Sagie]

Hello All

We will have an IRC meeting tomorrow (Monday, 2/29) at 1500 UTC
in #openstack-meeting-4

Please review the expected meeting agenda here:
https://wiki.openstack.org/wiki/Meetings/Kuryr

You can view last meeting action items and logs here:
http://eavesdrop.openstack.org/meetings/kuryr/2016/kuryr.2016-02-23-03.00.html

Please update the agenda if you have any subject you would like to discuss
about.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] - DVR L3 data plane performance results and scenarios

[Gal Sagie]

Hi Swami,

Any luck on this? we plan to share our results soon and want to see we
cover all cases
and tests results are good

On Fri, Feb 19, 2016 at 7:49 PM, Vasudevan, Swaminathan (PNB Roseville) <
swaminathan.vasude...@hpe.com> wrote:

> Hi Gal Sagie,
>
> Let me try to pull in the data and will provide you the information.
>
> Thanks
>
> Swami
>
>
>
> *From:* Gal Sagie [mailto:gal.sa...@gmail.com]
> *Sent:* Thursday, February 18, 2016 9:36 PM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Cc:* Yuli Stremovsky; Shlomo Narkolayev; Eran Gampel
> *Subject:* Re: [openstack-dev] [Neutron] - DVR L3 data plane performance
> results and scenarios
>
>
>
> Hi Swami,
>
>
>
> Thanks for the reply, is there any detailed links that describe this that
> we can look at?
>
>
>
> (Of course that having results without the full setup (hardware/ NIC, CPU
> and threads for OVS and so on..) details
>
> and without the full scenario details is a bit hard, regardless however i
> hope it will give us at least
>
> an estimation where we are at)
>
>
>
> Thanks
>
> Gal.
>
>
>
> On Thu, Feb 18, 2016 at 9:34 PM, Vasudevan, Swaminathan (PNB Roseville) <
> swaminathan.vasude...@hpe.com> wrote:
>
> Hi Gal Sagie,
>
> Yes there was some performance results on DVR that we shared with the
> community during the Liberty summit in Vancouver.
>
>
>
> Also I think there was a performance analysis that was done by Oleg
> Bondarev on DVR during the Paris summit.
>
>
>
> We have done lot more changes to the control plane to improve the scale
> and performance in DVR during the Mitaka cycle and will be sharing some
> performance results in the upcoming summit.
>
>
>
> Definitely we can align on our approach and have all those results
> captured in the upstream for the reference.
>
>
>
> Please let me know if you need any other information.
>
>
>
> Thanks
>
> Swami
>
>
>
> *From:* Gal Sagie [mailto:gal.sa...@gmail.com]
> *Sent:* Thursday, February 18, 2016 6:06 AM
> *To:* OpenStack Development Mailing List (not for usage questions); Eran
> Gampel; Shlomo Narkolayev; Yuli Stremovsky
> *Subject:* [openstack-dev] [Neutron] - DVR L3 data plane performance
> results and scenarios
>
>
>
> Hello All,
>
>
>
> We have started to test Dragonflow [1] data plane L3 performance and was
> wondering
>
> if there is any results and scenarios published for the current Neutron DVR
>
> that we can compare and learn the scenarios to test.
>
>
>
> We mostly want to validate and understand if our results are accurate and
> also join the
>
> community in defining base standards and scenarios to test any solution
> out there.
>
>
>
> For that we also plan to join and contribute to openstack-performance [2]
> efforts which to me
>
> are really important.
>
>
>
> Would love any results/information you can share, also interested in
> control plane
>
> testing and API stress tests (either using Rally or not)
>
>
>
> Thanks
>
> Gal.
>
>
>
> [1]
> http://docs.openstack.org/developer/dragonflow/distributed_dragonflow.html
>
> [2] https://github.com/openstack/performance-docs
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
>
> --
>
> Best Regards ,
>
> The G.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Best Regards ,

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

[openstack-dev] [Kuryr] Now part of OpenStack big-tent

[Gal Sagie]

Hello Everyone,

Just wanted to update you that Kuryr [1] was officially accepted yesterday
as a
big tent project.

We are currently facing some interesting challenges and times and if you
are running containers in OpenStack in mixed environments you most certainly
want to look and examine Kuryr.

We are holding a weekly IRC meeting [2] which is alternating between time
zones
so you have no excuse :) everyone are welcome!

We want to help and solve more challenges in the realm of containers
networking
deployments in OpenStack and if you are deploying this either in
development or
in production we would love to hear your experience and the problems you
are facing
and try to help you manage this better, feel free to share!

[1] https://wiki.openstack.org/wiki/Kuryr
[2] https://wiki.openstack.org/wiki/Meetings/Kuryr
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [dragonflow] db consistency progress

[Gal Sagie]

Hi Li Ma,

Great job on this!

I think Rally is the correct way to test something like that, what you
could use to check the end to end
solution is try to restart the DF DB server for timeouts during API
configurations.

At this point of time, i think this is really advance testing and i
wouldn't bother too much right now,
we need to make everything else more stable and then get back to this.



On Wed, Feb 24, 2016 at 4:31 PM, Li Ma  wrote:

> Hi all, today I submitted the working patch for review:
>
> https://review.openstack.org/#/c/282290/
>
> I tested it by invoking many concurrent API calls to update a given
> Neutron object, both for standalone and clustering of MySQL. The result is
> that no reported bugs about inconsistency were triggered.
>
> At the current stage, I'd like to discuss about testing. I think it needs
> to be tested at the gate by fullstack or rally. However, due to the
> uncertainty of the problem, even without this patch, the bug is not always
> triggered. How to make sure the test cases are reliable is the problem here.
>
> Any thoughts? Thanks a lot.
>
> --
>
> Li Ma (Nick)
> Email: skywalker.n...@gmail.com
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Best Regards ,

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

Re: [openstack-dev] [Kuryr] will we use os-vif in kuryr

[Gal Sagie]

Yes, the intention from the start was to see if we can converge and use
os-vif
and i certainly see us using it.


On Thu, Feb 18, 2016 at 12:32 PM, Daniel P. Berrange 
wrote:

> On Thu, Feb 18, 2016 at 09:01:35AM +, Liping Mao (limao) wrote:
> > Hi Kuryr team,
> >
> > I see couple of commits to add support for vif plug.
> > https://review.openstack.org/#/c/280411/
> > https://review.openstack.org/#/c/280878/
> >
> > Do we have plan to use os-vif?
> > https://github.com/openstack/os-vif
>
> FYI, we're trying reasonably hard to *not* make any assumptions about
> what compute or network services are using os-vif. ie, we want os-vif
> as a framework to be usable from Nova, or any other compute manager,
> and likewise be usable from Neutron or any other network manager.
> Obviously the actual implementations may be different, but the general
> os-vif framework tries to be agnostic.
>
> Regards,
> Daniel
> --
> |: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/
> :|
> |: http://libvirt.org  -o- http://virt-manager.org
> :|
> |: http://autobuild.org   -o- http://search.cpan.org/~danberr/
> :|
> |: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc
> :|
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Best Regards ,

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

[openstack-dev] [Neutron][Dragonflow] IRC Meeting tomorrow (2/22) - 0900 UTC

[Gal Sagie]

Hello All,

We will have an IRC meeting tomorrow (Monday, 2/22) at 0900 UTC
in #openstack-meeting-4

Please review the expected meeting agenda here:
https://wiki.openstack.org/wiki/Meetings/Dragonflow

You can view last meeting action items and logs here:
http://eavesdrop.openstack.org/meetings/dragonflow/2016/dragonflow.2016-02-15-09.00.html

Please update the agenda if you have any subject you would like to discuss
about.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [kolla] discussion about core reviewer limitations by company

[Gal Sagie]

I think setting these limits is wrong, some companies have more overall
representation then others.
The core reviewer job should be on a personal basis and not on a company
basis, i think the PTL of each project needs
to make sure the diversity and the community voice is heard in each project
and the correct path is taken even if
many (or even if all) of the cores are from the same company.
If you really want to set limits then i would go with something like 2
cores from the same company cannot +2 the same patch, but
again i am against such things personally..

Disclaimer: i am not personally involved in Kolla or know how things are
running there.

On Sat, Feb 20, 2016 at 7:09 PM, Steven Dake (stdake) 
wrote:

> Hey folks,
>
> Mirantis has been developing a big footprint in the core review team, and
> Red Hat already has a big footprint in the core review team.  These are all
> good things, but I want to avoid in the future a situation in which one
> company has a majority of core reviewers.  Since core reviewers set policy
> for the project, the project could be harmed if one company has such a
> majority.  This is one reason why project diversity is so important and has
> its own special snowflake tag in the governance repository.
>
> I'd like your thoughts on how to best handle this situation, before I
> trigger  a vote we can all agree on.
>
> I was thinking of something simple like:
> "1 company may not have more then 33% of core reviewers.  At the
> conclusion of PTL elections, the current cycle's 6 months of reviews
> completed will be used as a metric to select the core reviewers from that
> particular company if the core review team has shrunk as a result of
> removal of core reviewers during the cycle."
>
> Thoughts, comments, questions, concerns, etc?
>
> Regards,
> -steve
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Best Regards ,

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

Re: [openstack-dev] [Neutron] - DVR L3 data plane performance results and scenarios

[Gal Sagie]

Hi Swami,

Thanks for the reply, is there any detailed links that describe this that
we can look at?

(Of course that having results without the full setup (hardware/ NIC, CPU
and threads for OVS and so on..) details
and without the full scenario details is a bit hard, regardless however i
hope it will give us at least
an estimation where we are at)

Thanks
Gal.

On Thu, Feb 18, 2016 at 9:34 PM, Vasudevan, Swaminathan (PNB Roseville) <
swaminathan.vasude...@hpe.com> wrote:

> Hi Gal Sagie,
>
> Yes there was some performance results on DVR that we shared with the
> community during the Liberty summit in Vancouver.
>
>
>
> Also I think there was a performance analysis that was done by Oleg
> Bondarev on DVR during the Paris summit.
>
>
>
> We have done lot more changes to the control plane to improve the scale
> and performance in DVR during the Mitaka cycle and will be sharing some
> performance results in the upcoming summit.
>
>
>
> Definitely we can align on our approach and have all those results
> captured in the upstream for the reference.
>
>
>
> Please let me know if you need any other information.
>
>
>
> Thanks
>
> Swami
>
>
>
> *From:* Gal Sagie [mailto:gal.sa...@gmail.com]
> *Sent:* Thursday, February 18, 2016 6:06 AM
> *To:* OpenStack Development Mailing List (not for usage questions); Eran
> Gampel; Shlomo Narkolayev; Yuli Stremovsky
> *Subject:* [openstack-dev] [Neutron] - DVR L3 data plane performance
> results and scenarios
>
>
>
> Hello All,
>
>
>
> We have started to test Dragonflow [1] data plane L3 performance and was
> wondering
>
> if there is any results and scenarios published for the current Neutron DVR
>
> that we can compare and learn the scenarios to test.
>
>
>
> We mostly want to validate and understand if our results are accurate and
> also join the
>
> community in defining base standards and scenarios to test any solution
> out there.
>
>
>
> For that we also plan to join and contribute to openstack-performance [2]
> efforts which to me
>
> are really important.
>
>
>
> Would love any results/information you can share, also interested in
> control plane
>
> testing and API stress tests (either using Rally or not)
>
>
>
> Thanks
>
> Gal.
>
>
>
> [1]
> http://docs.openstack.org/developer/dragonflow/distributed_dragonflow.html
>
> [2] https://github.com/openstack/performance-docs
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Best Regards ,

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

[openstack-dev] [Neutron] - DVR L3 data plane performance results and scenarios

[Gal Sagie]

Hello All,

We have started to test Dragonflow [1] data plane L3 performance and was
wondering
if there is any results and scenarios published for the current Neutron DVR
that we can compare and learn the scenarios to test.

We mostly want to validate and understand if our results are accurate and
also join the
community in defining base standards and scenarios to test any solution out
there.

For that we also plan to join and contribute to openstack-performance [2]
efforts which to me
are really important.

Would love any results/information you can share, also interested in
control plane
testing and API stress tests (either using Rally or not)

Thanks
Gal.

[1]
http://docs.openstack.org/developer/dragonflow/distributed_dragonflow.html
[2] https://github.com/openstack/performance-docs
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Kuryr] - IRC Meeting (2/23) - 0300 UTC (#openstack-meeting-4)

[Gal Sagie]

Hello All,

We will have an IRC meeting on 2/23 at 0300 UTC
in #openstack-meeting-4

Please review the expected meeting agenda here:
https://wiki.openstack.org/wiki/Meetings/Kuryr

You can view last meeting action items and logs here:
http://eavesdrop.openstack.org/meetings/kuryr/2016/kuryr.2016-02-15-15.00.html

Please update the agenda if you have any subject you would like to discuss
about.

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

[openstack-dev] [Kuryr] IRC Meeting today (2/15) - 1500 UTC

[Gal Sagie]

Hello All

We will have an IRC meeting today (Monday, 2/15) at 1500 UTC
in #openstack-meeting-4

Please review the expected meeting agenda here:
https://wiki.openstack.org/wiki/Meetings/Kuryr

You can view last meeting action items and logs here:
http://eavesdrop.openstack.org/meetings/kuryr/2016/kuryr.2016-02-09-03.00.html

Please update the agenda if you have any subject you would like to discuss
about.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron][Dragonflow] IRC Meeting today (2/15) - 0900 UTC

[Gal Sagie]

Hello All,

We will have an IRC meeting today (Monday, 2/15) at 0900 UTC
in #openstack-meeting-4

Please review the expected meeting agenda here:
https://wiki.openstack.org/wiki/Meetings/Dragonflow

You can view last meeting action items and logs here:
*http://eavesdrop.openstack.org/meetings/dragonflow/2016/dragonflow.2016-02-01-09.00.html
*

Please update the agenda if you have any subject you would like to discuss
about.


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

[openstack-dev] Octavia (LBaaS) license question

[Gal Sagie]

Hello All,

I recently started looking at Octavia and i noticed it uses HAProxy as its
reference
implementation.
I also noticed that HAProxy is GPL license so i am wondering how is this
working?

Just interested to know if there is a special exemption ?

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

Re: [openstack-dev] [Neutron] Distributed Multicast and IGMP Support in Dragonflow

[Gal Sagie]

This is a work we are doing in Dragonflow and is relatively simple to
implement leveraging
Dragonflow current infrastructure and reactive local controller.

This will significantly reduce duplicating packets for IGMP aware VMs. and
hence
reduce multicast load.

We would love to help and bring this API to Neutron core, anyone that is
interested
is welcome to check the spec Omer published.  feel free to join us in our
next IRC
channel where we would talk about this design.

Thanks
Gal.

On Wed, Feb 10, 2016 at 4:59 PM, Omer Anson 
wrote:

> Hello,
>
> We're in the process of adding IGMP and multicast support to
> Dragonflow[1]. The
> added feature will route multicast packets only to relevant and registered
> VMs,
> compute nodes, and handle IGMP packets.
>
> This feature has some configuration parameters for subnets and router
> interfaces.
> Some of these parameters are, e.g. if the subnet supports multicast, and
> the
> Query Interval of the router.
>
> Is anyone else working on such a feature? Are there any specific parameters
> that should be included, in addition to multicast enable/disable on
> subnets,
> and the parameters in Section 8 in [2]?
>
> Thanks,
> Omer Anson.
>
> [1] https://review.openstack.org/#/c/278400/
> [2] https://tools.ietf.org/html/rfc3376
>
>
>
> -
>
> This email and any files transmitted and/or attachments with it are
> confidential and proprietary information of
> Toga Networks Ltd., and intended solely for the use of the individual or
> entity to whom they are addressed.
> If you have received this email in error please notify the system manager.
> This message contains confidential
> information of Toga Networks Ltd., and is intended only for the individual
> named. If you are not the named
> addressee you should not disseminate, distribute or copy this e-mail.
> Please notify the sender immediately
> by e-mail if you have received this e-mail by mistake and delete this
> e-mail from your system. If you are not
> the intended recipient you are notified that disclosing, copying,
> distributing or taking any action in reliance on
> the contents of this information is strictly prohibited.
>
>
> 
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Best Regards ,

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

Re: [openstack-dev] [Kuryr] IRC Meeting tomorrow (2/9) - 0300 UTC

[Gal Sagie]

As Mike spotted, the date for the meeting is February 9!!
and not the 8th in the original email

Thanks for the correction!


On Mon, Feb 8, 2016 at 5:44 PM, Gal Sagie  wrote:

> Hello All,
>
> We will have an IRC meeting tomorrow (Tuesday, 2/8) at 0300 UTC
> in #openstack-meeting-4
>
> Please review the expected meeting agenda here:
> https://wiki.openstack.org/wiki/Meeting
> <https://wiki.openstack.org/wiki/Meetings/Dragonflow>s/Kuryr
>
> You can view last meeting action items and logs here:
>
> http://eavesdrop.openstack.org/meetings/kuryr/2016/kuryr.2016-02-01-15.00.html
>
> It will also be useful to view the meeting we had last week in
> #openstack-kuryr regarding
> Kubernetes integration:
>
>
> http://eavesdrop.openstack.org/irclogs/%23openstack-kuryr/%23openstack-kuryr.2016-02-03.log.html
>
> Please update the agenda if you have any subject you would like to discuss
> about.
>
>


-- 
Best Regards ,

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

[openstack-dev] [Kuryr] IRC Meeting tomorrow (2/8) - 0300 UTC

[Gal Sagie]

Hello All,

We will have an IRC meeting tomorrow (Tuesday, 2/8) at 0300 UTC
in #openstack-meeting-4

Please review the expected meeting agenda here:
https://wiki.openstack.org/wiki/Meeting
s/Kuryr

You can view last meeting action items and logs here:
http://eavesdrop.openstack.org/meetings/kuryr/2016/kuryr.2016-02-01-15.00.html

It will also be useful to view the meeting we had last week in
#openstack-kuryr regarding
Kubernetes integration:

http://eavesdrop.openstack.org/irclogs/%23openstack-kuryr/%23openstack-kuryr.2016-02-03.log.html

Please update the agenda if you have any subject you would like to discuss
about.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][tc] Proposal: Separate design summits from OpenStack conferences

[Gal Sagie]

If you compare the number of people that come to mid-cycles with the number
of people that come
to the summit and attend the design summit, i am sure (without knowing
exact numbers) that there is a big difference
in favor of the design summit.

I also think that its important that users/operators meet and discuss their
use cases and problems with the developers
this is the only chance to really do this on large open scale.

I dont think splitting the two is a good idea.

Maybe the solution is to split the design summits  sessions into mini
smaller sessions and delegate responsibility,
hopefully smaller teams can achieve better more focused milestones.
(From my small 2 summits experience, usually the last day with the open
talks is the most efficient one)

Another thing we need to get better at are "virtual sprints" working
groups, i think that we still need to see
how to make these work more efficiently but i have a feeling they can be
efficient with certain responsibility
from the people attending.

Gal


On Mon, Feb 8, 2016 at 5:42 AM, Michael Still  wrote:

> On Mon, Feb 8, 2016 at 1:51 AM, Monty Taylor  wrote:
>
> [snip]
>
>
>> Fifth - if we do this, the real need for the mid-cycles we currently have
>> probably goes away since the summit week can be a legit wall-to-wall work
>> week.
>>
>
> [snip]
>
> Another reply to a specific point...
>
> I disagree strongly here, at least in the Nova case. I feel Nova has been
> getting along much better and generally pulling in the same direction for
> the last few releases. I think one of the things we did to get there is the
> mid-cycles, which gave us more time to sync on the overall direction of
> Nova, as well as ensuring we start being honest at this point in the
> release cycle about what we're going to get done before we ship.
>
> For Nova at least its really important to have an approximately milestone
> 2 check point where we can decide what to defer and what to focus on.
> Otherwise we end up back in a place where we release a mish mash of half
> finished features.
>
> Michael
>
> --
> Rackspace Australia
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Best Regards ,

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

[openstack-dev] [Neutron][Dragonflow] - IRC Meeting Canceled (2/8)

[Gal Sagie]

Hello all,

Since many members (and also myself) cant make it for tomorrows meeting,
we have decided to cancel it.

For any urgent matters, feel free to send your question to the mailing list.

We will have a meeting next week (2/15) as usual.

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

Re: [openstack-dev] [Neutron] Evolving the stadium concept

[Gal Sagie]

Armando,

I think that contributing and innovating in Dragonflow to implement Neutron
in an open way and serve as an  alternative and as an example
for distributed networking patterns IS driving Neutron forward, i am very
sad that you fail to see this and try to pick to
my review/patches count.

Beside the big over head i devote to Dragonflow, due to the fact that it
really runs as an open source project, i also help and contribute
as much as i can to OVN and of course my efforts in Kuryr, which to me
solves a critical and important thing for Neutron and for OpenStack
in mixed containers environments.
(And the rest of the time that i try to devote to Neutron and other
sub-projects, currently still under Neutron big-stadium)

Of course that all of this in addition to my efforts and success to
convince and assist in bringing more people
and more companies to contribute in an open way with the community in many
areas in Neutron (some you are familiar with like the border gateway and
l2gateway others that you are not..),
both internally and externally, writing blogs/arranging meetups to promote
and extend some
of the above projects visibility and Neutron as such.

Believe me that i truly am passionate about Neutron, OpenStack and open
source and try my best to help and
contribute when ever i can and many times not due to my "Job requirement",
i apologise that this is
not enough for you, there is only a limited amount of hours in a day :)

However, i truly believe that Dragonflow, and ANY other true open source
implementation of Neutron helps move
Neutron forward and i hope to continue do so either as Neutron big-stadium,
as a big-tent project or as something else.

As i have talked with Russell and explained, to me the Big Stadium was/is a
way to keep Networking related projects "near"
the group of people that has the best context to review / help and comment,
its obviously not working and thats fine, lets
try something different...


On Thu, Feb 4, 2016 at 8:18 PM, Armando M.  wrote:

>
>
> On 4 February 2016 at 04:05, Gal Sagie  wrote:
>
>> Hi Assaf,
>>
>> I think that if we define a certain criteria we need to make sure that it
>> applies to everyone equally.
>> and it is well understood.
>>
>
> I must admit I am still waking up and going through the entire logs etc.
> However I cannot help but point out that one criteria that Russell and
> other TC people are behind (me included) is the significant 'team overlap'
> (and I would add it to be for a prolonged amount of time). This doesn't
> mean just drop the accidental bug fix or enhancement to enable the
> subproject to work with Neutron or address the odd regression that sneaks
> in from time to time, but it means driving Neutron forward so that it is
> beneficial for the project as a whole.
>
> If you look at yourself, can you candidly say that you are making an
> impact to the core of Neutron? You seem you have dropped off the radar in
> the Mitaka timeframe, and haven't made a lasting impact in the Liberty
> timeframe. I applaud your Kuryr initiative and your specs proposals, but
> both are not enough to warrant Dragonflow for inclusion.
>
> If the team overlap changes, then great, we'll reassess.
>
> That said, I'll continue my discussion on the patch...
>
>
>> I have contributed and still am to both OVN and Dragonflow and hope to
>> continue do so in the future,
>> i want to see both of these solutions become a great production grade
>> open source alternatives.
>>
>> I have less experience in open source and in this community from most of
>> you, but from what i saw users
>> do take these things into consideration, its hard for a new user and even
>> not so new to understand the possibilities correctly
>> specially if we cant even define them ourselves
>>
>> Instead of spending time on technology and on solving the problems for
>> our users we are concentrating
>> on this conversation, we haven't even talked about production maturity,
>> feature richness and stability as you say
>> and by doing this move, we are signaling something else for our users
>> without actually discussing about all the
>> former ourselves.
>>
>> I will be ok with what ever the Neutron team decide on this, as they can
>> define the criteria as they please.
>> Just shared my opinion on this process and my disappointment from it as
>> someone who values open source
>> a lot.
>>
>> Gal.
>>
>>
>> On Thu, Feb 4, 2016 at 11:31 AM, Assaf Muller  wrote:
>>
>>> On Thu, Feb 4, 2016 at 10:20 AM, Assaf Muller 
>>> wrote:
>>> > On Thu, Feb 4, 2016 at 8:33 AM, Gal Sagie  wrote:
>>> >> As i have c

Re: [openstack-dev] [Neutron] Evolving the stadium concept

[Gal Sagie]

Hi Assaf,

I think that if we define a certain criteria we need to make sure that it
applies to everyone equally.
and it is well understood.
I have contributed and still am to both OVN and Dragonflow and hope to
continue do so in the future,
i want to see both of these solutions become a great production grade open
source alternatives.

I have less experience in open source and in this community from most of
you, but from what i saw users
do take these things into consideration, its hard for a new user and even
not so new to understand the possibilities correctly
specially if we cant even define them ourselves

Instead of spending time on technology and on solving the problems for our
users we are concentrating
on this conversation, we haven't even talked about production maturity,
feature richness and stability as you say
and by doing this move, we are signaling something else for our users
without actually discussing about all the
former ourselves.

I will be ok with what ever the Neutron team decide on this, as they can
define the criteria as they please.
Just shared my opinion on this process and my disappointment from it as
someone who values open source
a lot.

Gal.


On Thu, Feb 4, 2016 at 11:31 AM, Assaf Muller  wrote:

> On Thu, Feb 4, 2016 at 10:20 AM, Assaf Muller  wrote:
> > On Thu, Feb 4, 2016 at 8:33 AM, Gal Sagie  wrote:
> >> As i have commented on the patch i will also send this to the mailing
> list:
> >>
> >> I really dont see why Dragonflow is not part of this list, given the
> >> criteria you listed.
> >>
> >> Dragonflow is fully developed under Neutron/OpenStack, no other
> >> repositories. It is fully Open source and already have a community of
> people
> >> contributing and interest from various different companies and OpenStack
> >> deployers. (I can prepare the list of active contributions and of
> interested
> >> parties) It also puts OpenStack Neutron APIs and use cases as first
> class
> >> citizens and working on being an integral part of OpenStack.
> >>
> >> I agree that OVN needs to be part of the list, but you brought up this
> >> criteria in regards to ODL, so: OVN like ODL is not only Neutron and
> >> OpenStack and is even running/being implemented on a whole different
> >> governance model and requirements to it.
> >>
> >> I think you also forgot to mention some other projects as well that are
> >> fully open source with a vibrant and diverse community, i will let them
> >> comment here by themselves.
> >>
> >> Frankly this approach disappoints me, I have honestly worked hard to
> make
> >> Dragonflow fully visible and add and support open discussion and follow
> the
> >> correct guidelines to work in a project. I think that Dragonflow
> community
> >> has already few members from various companies and this is only going to
> >> grow in the near future. (in addition to deployers that are considering
> it
> >> as a solution)  we also welcome anyone that wants to join and be part
> of the
> >> process to step in, we are very welcoming
> >>
> >> I also think that the correct way to do this is to actually add as
> reviewers
> >> all lieutenants of the projects you are now removing from Neutron big
> >> stadium and letting them comment.
> >>
> >> Gal.
> >
> > I understand you see 'Dragonflow being part of the Neutron stadium'
> > and 'Dragonflow having high visibility' as tied together. I'm curious,
> > from a practical perspective, how does being a part of the stadium
> > give Dragonflow visibility? If it were not a part of the stadium and
> > you had your own PTL etc, what specifically would change so that
> > Dragonflow would be less visible. Currently I don't understand why
> > being a part of the stadium is good or bad for a networking project,
> > or why does it matter. Looking at Russell's patch, it's concerned with
> > placing projects (e.g. ODL, OVN, Dragonflow) either in or out of the
> > stadium and the criteria for doing so, I'm just asking how do you
> > (Gal) perceive the practical effect of that decision.
>
> Allow me to expand:
> It seems to me like there is no significance to who is 'in or out'.
> However, people, including potential customers, look at the list of
> the Neutron stadium and deduce that project X is better than Y because
> X is in but Y is out, and *that* in itself is the value of being in or
> out, even though it has no meaning. Maybe we should explain what
> exactly does it mean being in or out. It's just a governance decision,
> it do

Re: [openstack-dev] [Neutron] Evolving the stadium concept

[Gal Sagie]

As i have commented on the patch i will also send this to the mailing list:

I really dont see why Dragonflow is not part of this list, given the
criteria you listed.

Dragonflow is fully developed under Neutron/OpenStack, no other
repositories. It is fully Open source and already have a community of
people contributing and interest from various different companies and
OpenStack deployers. (I can prepare the list of active contributions and of
interested parties) It also puts OpenStack Neutron APIs and use cases as
first class citizens and working on being an integral part of OpenStack.

I agree that OVN needs to be part of the list, but you brought up this
criteria in regards to ODL, so: OVN like ODL is not only Neutron and
OpenStack and is even running/being implemented on a whole different
governance model and requirements to it.

I think you also forgot to mention some other projects as well that are
fully open source with a vibrant and diverse community, i will let them
comment here by themselves.

Frankly this approach disappoints me, I have honestly worked hard to make
Dragonflow fully visible and add and support open discussion and follow the
correct guidelines to work in a project. I think that Dragonflow community
has already few members from various companies and this is only going to
grow in the near future. (in addition to deployers that are considering it
as a solution)  we also welcome anyone that wants to join and be part of
the process to step in, we are very welcoming

I also think that the correct way to do this is to actually add as
reviewers all lieutenants of the projects you are now removing from Neutron
big stadium and letting them comment.

Gal.

On Wed, Feb 3, 2016 at 11:48 PM, Russell Bryant  wrote:

> On 11/30/2015 07:56 PM, Armando M. wrote:
> > I would like to suggest that we evolve the structure of the Neutron
> > governance, so that most of the deliverables that are now part of the
> > Neutron stadium become standalone projects that are entirely
> > self-governed (they have their own core/release teams, etc).
>
> After thinking over the discussion in this thread for a while, I have
> started the following proposal to implement the stadium renovation that
> Armando originally proposed in this thread.
>
> https://review.openstack.org/#/c/275888
>
> --
> Russell Bryant
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Best Regards ,

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

Re: [openstack-dev] [Magnum] New Core Reviewers

[Gal Sagie]

Not part of Magnum team, but Egor is a great help for Kuryr as well and is
a great addition in my eyes

On Mon, Feb 1, 2016 at 7:00 PM, Davanum Srinivas  wrote:

> +1 from me!
>
> On Mon, Feb 1, 2016 at 9:58 AM, Adrian Otto 
> wrote:
> > Magnum Core Team,
> >
> > I propose Ton Ngo (Tango) and Egor Guz (eghobo) as new Magnum Core
> Reviewers. Please respond with your votes.
> >
> > Thanks,
> >
> > Adrian Otto
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> --
> Davanum Srinivas :: https://twitter.com/dims
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Best Regards ,

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

Re: [openstack-dev] [Neutron] Integrating physical appliance into virtual infrastructure

[Gal Sagie]

There is a project that aims at solving your use cases (at least from a
general view)
Its called L2GW and uses OVSDB Hardware VTEP schema (which is supported by
many physical appliances for switching capabilities)

Some information: https://wiki.openstack.org/wiki/Neutron/L2-GW

There are also other possible solutions, depending what you are trying to
do and what is the physical applicance job.



On Mon, Feb 1, 2016 at 3:44 PM, Vijay Venkatachalam <
vijay.venkatacha...@citrix.com> wrote:

> Hi ,
>
>
>
> How to integrate a physical appliance into the virtual OpenStack
> infrastructure (with L2 population)? Can you please point me to any
> relevant material.
>
>
>
> We want to add the capability to “properly” schedule the port on the
> physical appliance, so that the rest of the virtual infrastructure knows
> that a new port is scheduled in the physical appliance.  How to do this?
>
>
>
> We manage the appliance through a middleware. Today, when it creates a
> neutron port, that is to be hosted on the physical appliance, the port is
> dangling.  Meaning, the virtual infrastructure does not know where this
> port is hosted/implemented. How to fix this?
>
>
>
> Also, we want the physical appliance plugged into L2 population mechanism.
> Looks like the L2 population driver is distributing L2 info to all virtual
> infrastructure nodes where a neutron agent is running. Can we leverage this
> framework? We don’t want to run the neutron agent in the physical
> appliance, can it run in the middle ware?
>
>
>
> Thanks,
>
> Vijay V.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Best Regards ,

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

[openstack-dev] [Kuryr] IRC Meeting - Monday (2/1) 1500 UTC (#openstack-meeting-4)

[Gal Sagie]

Hello All,

We are going to have an IRC Meeting tomorrow (2/1) at 1500 UTC
in #openstack-meeting-4

The meeting agenda can be seen here [1].
We are going to focus most of the meeting on the Kubernetes-Kuryr
integration.
You can view the logs from our specific Kuryr-Kubernetes integration IRC
meeting [2]

Please come with some modeling ideas, i think this topic will take most of
the time.

I would also like us to discuss about Fawad spec about Magnum-Kuryr
integration. [3]
and nested containers support.

I have CCed Adrian/Danyeon from the Magnum team here, hopefully you guys
can provide some feedback as well.

Thanks and see you there!
Gal.

[1] https://wiki.openstack.org/wiki/Meetings/Kuryr
[2]
http://eavesdrop.openstack.org/meetings/kuryr/2016/kuryr.2016-01-26-15.03.log.html
[3] https://review.openstack.org/#/c/269039/3
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron][Dragonflow] IRC Meeting tommorrow (1/2) - 0900 UTC (#openstack-meeting-4)

[Gal Sagie]

Hello All,

We will have an IRC meeting tomorrow (Monday, 1/2) at 0900 UTC
in #openstack-meeting-4

Please review the expected meeting agenda here:
https://wiki.openstack.org/wiki/Meetings/Dragonflow

We are going to have a busy meeting, many new specs/design, i have put
the links to all specs in the agenda page above, please try to review them
before
the meeting.

You can view last meeting action items and logs here:
http://eavesdrop.openstack.org/meetings/dragonflow/2016/dragonflow.2016-01-25-09.00.html

Please update the agenda if you have any subject you would like to discuss
about.


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

Re: [openstack-dev] [Kuryr] IRC Meeting - Tuesday (1/26) 0300 UTC (#openstack-meeting-4)

[Gal Sagie]

Hi Jaume,

Not sure what is the problem, we are doing alternating meetings now, but
maybe
we switched the weeks as we didn't have a meeting at holidays week
(Christmas).

I am usually trying to send email at least a day before to the mailing
list, next week the meeting is
happening at Monday (1500 UTC)


On Wed, Jan 27, 2016 at 10:42 AM, Jaume Devesa  wrote:

> Hi Gal,
>
> I missed the mail and the meeting...
>
> I imported the ics file[1] from eavesdrop site before Christmas and since
> January it seems the schedule and the reality are switched.
>
> Can it be that the calendar has to be updated, or it is because I am
> completely
> unable to deal with organization tools?
>
> Regards,
>
>
> [1]: http://eavesdrop.openstack.org/calendars/kuryr-team-meeting.ics
>
> On Mon, 25 Jan 2016 13:51, Gal Sagie wrote:
> > Hello All,
> >
> > We are going to have an IRC meeting tomorrow.
> >
> > I have updated the agenda for the upcoming meeting [1]
> > Please review and add any additional topics you might want to cover.
> >
> > Last meeting action items can be seen here [2]
> >
> > Thanks and see you there!
> >
> > [1] https://wiki.openstack.org/wiki/Meetings/Kuryr
> > [2] *
> http://eavesdrop.openstack.org/meetings/kuryr/2016/kuryr.2016-01-18-15.02.html
> > <
> http://eavesdrop.openstack.org/meetings/kuryr/2016/kuryr.2016-01-18-15.02.html
> >*
>
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> --
> Jaume Devesa
> Software Engineer at Midokura
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Best Regards ,

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

Re: [openstack-dev] [kuryr] Does Kuryr support multi-tenant

[Gal Sagie]

Hi Liping Mao,

The question is what you mean by multi-tenancy, if you mean that different
tenants each control their own bare-metal
server then Kuryr already support this. (by tenant credential configuration)

If what i think you mean, and thats running multi tenants on the same
bare-metal then the problem
here is that Docker and Kubernetes doesnt support something like that
either (mostly for security reasons) and
the networking is just part of it (Which is what Kuryr focus on).
For this, you usually pick with what Magnum offer and thats running
containers inside tenant VMs.

However, there are some interesting technologies and open source projects
which enable
something like that and we are evaluating them, its definitely a long term
goal for us.



On Tue, Jan 26, 2016 at 5:06 AM, Liping Mao (limao)  wrote:

> Thanks Mohammad for your clear explanation.
> Do we have any way or roadmap or idea to support kuryr in multi-tenant in
> bare metal servers now?
>
> Thanks.
>
> Regards,
> Liping Mao
>
>
> From: Mohammad Banikazemi 
> Reply-To: OpenStack List 
> Date: 2016年1月26日 星期二 上午2:35
> To: OpenStack List 
> Subject: Re: [openstack-dev] [kuryr] Does Kuryr support multi-tenant
>
> Considering that the underlying container technology is not multi-tenant
> (as of now), your observation is correct in that all neutron resources are
> made for a single tenant. Until Docker supports multi tenancy, we can
> possibly use network options and/or wrappers for docker/swarm clients to
> achieve some kind of multi tenancy support. Having said that, I should add
> that as of now we do not have such a feature in Kuryr.
>
> Best,
>
> Mohammad
>
>
> [image: Inactive hide details for "Liping Mao (limao)" ---01/25/2016
> 06:39:44 AM---Hi Kuryr guys, I'm a new bee in kuryr, and using de]"Liping
> Mao (limao)" ---01/25/2016 06:39:44 AM---Hi Kuryr guys, I'm a new bee in
> kuryr, and using devstack to try kuryr now, I notice when I use kur
>
> From: "Liping Mao (limao)" 
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Date: 01/25/2016 06:39 AM
> Subject: [openstack-dev] [kuryr] Does Kuryr support multi-tenant
> --
>
>
>
> Hi Kuryr guys,
>
> I’m a new bee in kuryr, and using devstack to try kuryr now, I notice when
> I use kuryr to create network/port for container, the resources are in
> “admin”.
> Do kuryr support multi-tenant now? For example, if I want try kuryr in
> demo tenant, how can I do this?
>
> Thanks for your help and any help would be appreciated.
>
> Regards,
> Liping Mao
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Best Regards ,

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

[openstack-dev] [Kuryr] IRC Meeting - Tuesday (1/26) 0300 UTC (#openstack-meeting-4)

[Gal Sagie]

Hello All,

We are going to have an IRC meeting tomorrow.

I have updated the agenda for the upcoming meeting [1]
Please review and add any additional topics you might want to cover.

Last meeting action items can be seen here [2]

Thanks and see you there!

[1] https://wiki.openstack.org/wiki/Meetings/Kuryr
[2] 
*http://eavesdrop.openstack.org/meetings/kuryr/2016/kuryr.2016-01-18-15.02.html
*
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron][Dragonflow] IRC Meeting tomorrow (25/1) - 0900 UTC

[Gal Sagie]

Hello All,

We will have an IRC meeting tomorrow (Monday, 25/4) at 0900 UTC
in #openstack-meeting-4

Please review the expected meeting agenda here:
https://wiki.openstack.org/wiki/Meetings/Dragonflow

You can view last meeting action items and logs here:
http://eavesdrop.openstack.org/meetings/dragonflow/2016/dragonflow.2016-01-18-08.00.html

Please update the agenda if you have any subject you would like to discuss
about.


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

[openstack-dev] [Neutron][Dragonflow] - Status Update and Meetups in China

[Gal Sagie]

Hello Everyone,

We are just back from a week in China where we met with various local
community
members to discuss about Dragonflow roadmap and design.
We will have a nice number of people from different companies joining us on
the development
of Dragonflow and some are planning to deploy it.

We discussed the following areas which we are going to tackle by April:

1. *Neutron-DF DB Consistency* - This is a problem that most plugins /
other controllers have
today, how to make sure that the Neutron DB is fully synced with the
plugin/solution DB/view of
things.
This problem has many parts into it and i think we came up with a
pretty good plan for it, I will
write about it once the design is in review.

2. *Selective Proactive -  * Dragonflow has local controller at each
compute node, but these
controllers don't need to know the entire virtual topology, the idea to
sync only relevant
information based on the local ports and actual topology, we are going
to have this by
end of April.

3. *Pub/Sub mechanism* - This design is in review process [1] , hope to get
your comments

4. *Scale Testing* -  We received a lab and HW equipment to perform real
scale testing, we will
publish the results once we have them, we are going to focus on data
plane performance /
control plane and DB

5. *Distributed DNAT* - We already have spec for this merged [2], this is
going to be implemented
 as part of Mitaka using OVS flows only.

6. *Broadcast/Multicast traffic* - This is a pain full problem as discussed
also in this mailing list, we
have a nice idea how to solve this in Dragonflow and plan to publish a
spec for this soon.

Feel free to join our IRC channel #openstack-dragonflow or our weekly IRC
meeting [3]
Or send back any questions you might have

Thanks
Gal.

[1] https://review.openstack.org/#/c/263733/
[2]
http://docs.openstack.org/developer/dragonflow/specs/distributed_dnat.html
[3] https://wiki.openstack.org/wiki/Meetings/Dragonflow
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] BGP Dynamic Routing Development Going Forward

[Gal Sagie]

The real question that needs to be asked (at least for me) is how this
feature can work with other plugins/ML2 drivers
that are not the reference implementation.

How hard (possible) it is to take the API part (or maybe even the agent)
and use that in another Neutron implementation.
Then focus on which ever option that works best to achieve this.

I personally think that if the long term goal is to have this in a separate
repo then this should happen right now.
"We will do this later" just won't work, it will be harder and it will just
not happen (or it will cause a lot of pain to people
that started deploying this)
At least thats my opinion, of course it depends a lot on the people who
actually work on this...

Gal.

On Sat, Jan 23, 2016 at 2:15 AM, Vikram Choudhary  wrote:

> I agree with Armando and feel option 2 would be viable if we really want
> to deliver this feature in Mitaka time frame. Adding a new stadium project
> invites more work and can be done in N release.
>
> Thanks
> Vikram
> On Jan 22, 2016 11:47 PM, "Armando M."  wrote:
>
>>
>>
>> On 22 January 2016 at 08:57, Tidwell, Ryan  wrote:
>>
>>> I wanted to raise the question of whether to develop BGP dynamic routing
>>> in the Neutron repo or spin it out to as a stadium project.  This question
>>> has been raised recently on reviews and in offline discussions.  For those
>>> unfamiliar with this work, BGP efforts in Neutron entail admin-only API’s
>>> for configuring and propagating BGP announcements of next-hops for floating
>>> IP’s, tenant networks, and host routes for each compute port when using
>>> DVR.  As we are getting late in the Mitaka cycle, I would like to be sure
>>> there is consensus on the approach for Mitaka.  As I see it, we have 3
>>> courses of action:
>>>
>>> 1. Continue with development in the main repo without any intention of
>>> spinning out to a stadium project
>>>
>>> 2. Continue on the current development course for Mitaka while targeting
>>> a spin-out to a stadium project during the N cycle
>>>
>>> 3. Spin out to a stadium project immediately
>>>
>>>
>>>
>>> Each has pros and cons.  This question seems to have arisen while
>>> looking at the sheer amount code being proposed, its place in the Neutron
>>> model, and questioning whether we really want to bring that code into
>>> Neutron.  As such, continuing with option 1 definitely requires us to come
>>> to some consensus.  Let me be clear that I’m not opposed to any of these
>>> options, I’m simply looking for some guidance.  With that said, if the end
>>> game is a stadium project I do question whether #2 makes sense.
>>>
>>
>> Not sure if you followed the latest discussion on [1,2] ([1] capturing
>> the latest events). Delivering something production worthy goes a lot more
>> beyond simply posting code upstream. We, as a community, have promised to
>> deliver BGP capabilities for many cycles, and failed so far. Choosing 3 is
>> clearly going to defer this to N or even O because of the amount of effort
>> required to set it all up (release, docs, testing, etc). Option 2, as
>> painful as it may sound, gives us the ability to get immediate access to
>> all that's required to deliver something to users so that they can play
>> with it at the end of Mitaka if they choose to. In the meantime that will
>> give us some breathing room to get ready as soon as N opens up.
>>
>> I am operating under the assumption that what you guys have been working
>> on is close to being functionally complete. If we don't even have that,
>> then we're in trouble no matter which option we choose and we can defer
>> this yet again :/
>>
>> Having said that, we can all agree that option #1 is not what we all
>> want. Just to be clear, I am in favor of #2.
>>
>> Cheers,
>> Armando
>>
>> [1] https://review.openstack.org/#/c/268727/
>> [2] https://review.openstack.org/#/c/268726/
>>
>>
>>>
>>>
>>> -Ryan
>>>
>>>
>>>
>>> https://review.openstack.org/#/c/201621/
>>>
>>> https://review.openstack.org/#/q/topic:bp/bgp-dynamic-routing
>>>
>>>
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Best Regards ,

The G.

[openstack-dev] [Neutron][Dragonflow] - IRC Meeting Cancelled (1/11)

[Gal Sagie]

Hello All,

Just wanted to let everyone know that we wont have a Dragonflow IRC meeting
next week (Monday, 1/11)

We will continue with the meetings the week after (1/18)

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

[openstack-dev] [Kuryr] IRC Meeting - Monday (1/4) 1500 UTC (#openstack-meeting-4)

[Gal Sagie]

Hello All,

The first Kuryr IRC meeting of this year is going to take place tomorrow :)

I have updated the agenda for the upcoming meeting [1]
Please review and add any additional topics you might want to cover.

Last meeting action items can be seen here [2]

See you there!

[1] https://wiki.openstack.org/wiki/Meetings/Kuryr
[2]
http://eavesdrop.openstack.org/meetings/kuryr/2015/kuryr.2015-12-29-03.01.html

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

[openstack-dev] [Neutron][Dragonflow] IRC Meeting tomorrow (1/4) - 0900 UTC

[Gal Sagie]

Hello All,

We will have an IRC meeting tomorrow (Monday, 1/4) at 0900 UTC
in #openstack-meeting-4

Please review the expected meeting agenda here:
https://wiki.openstack.org/wiki/Meetings/Dragonflow

You can view last meeting action items and logs here:
http://eavesdrop.openstack.org/meetings/dragonflow/2015/dragonflow.2015-12-28-09.00.html

Please update the agenda if you have any subject you would like to discuss
about.

We would like to hear from anyone that wishes to attend the meetings but
cant
due to time zone differences, if you would like to attend please let us
know and we will
consider adding alternating meeting time.

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

[openstack-dev] [Neutron][Dragonflow] Security Groups Design for Scale

[Gal Sagie]

Hello all,

We are iterating on a design document for Security Groups implementation
in Dragonflow. [1]

This design leverage the fact that Dragonflow distribute policy level
abstraction
to the local controllers and has Security Group as a first class citizen.

The design tries to tackle the challenges of Security groups deployment at
scale
both for the data plane performance but also for the control plane
performance (keeping
the number of OVS flows to minimum - one per security rule and not needing
to recompile
security group flows on VMs additions/deletions/updates)

You are also invited to read a blog post [2] i wrote about it, similar to
the spec.

We would like to hear your comments/ideas/opinions, please
let us know if you find anything invalid in the proposed solution.

Thanks
Gal

[1] https://review.openstack.org/#/c/261903/
[2]
http://galsagie.github.io/sdn/openstack/ovs/dragonflow/2015/12/28/dragonflow-security-groups/
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Kuryr] Progress Update and Kubernetes Integration

[Gal Sagie]

Hello everyone,

Just wanted to give you all some progress update at what we have been doing
in Kuryr,
We conducted an IRC meeting today, you can see the logs here [1]

1) We got Docker pluggable IPAM support in Kuryr thanks to Vikas Choudhary,
there
   are still some small points to address but most of the code is already
merged.
   I plan to write a blog post about it describing the mechanism

2) Mohammad Banikazemi verified Kuryr works with Docker Swarm seamlessly
   and we are compatible with latest Docker libnetwork

3) We have fullstack job running in the gate, basically these tests are
running with a
working Openstack environment with Kuryr deployed and using Neutron
client and
Docker python client to simulate different scenarios and test Kuryr
functionality
in addition to our unit tests.

4) We have Rally job running, we plan to contribute Docker plugin to Rally
and have
some of the above tests run benchmarking operation, i think this is a
very important
goal as it will also help us benchmark different Neutron backends and
solutions
in terms of containers networking and let users/operators have better
comparison
between their different options.

5) We are working on packaging for Kuryr (Thanks to Jaume Devesa for that)

6) We are working on investigating using Linux CAPABILITIES rather then
using
rootwrap or running as root for Kuryr (Thanks to Antoni Segura Puimedon)

We also decided to give Kubernetes integration higher priority and are now
brain storming
design options to integrate Kubernetes and Kuryr which means integrating
Kubernetes with Neutron (OpenStack networking abstraction).
If you have any idea in that area or done something similar (or in the
middle of doing it)
Please share it in this Etherpad [2].
Our goal is to expose the different ways to do this to the user and find
the best common
method.

We are also starting to approach the Kuryr-Magnum integration and nested
containers and
hope to achieve some progress on this by the end of the release.

Thanks everyone that contribute and help, its greatly appreciated by all of
us!
If you would like to join , feel free to step in our IRC channel at
freenode #openstack-kuryr
Join the IRC meeting [3] or just email me with any question/idea.

Thanks
Gal.

[1]
http://eavesdrop.openstack.org/meetings/kuryr/2015/kuryr.2015-12-29-03.01.html
[2] https://etherpad.openstack.org/p/kuryr_k8s
[3] https://wiki.openstack.org/wiki/Meetings/Kuryr
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] [Dragonflow] Atomic update doesn't work with etcd-driver

[Gal Sagie]

Hi Li Ma,

I haven't investigated the root problem yet as i seen it at the end of day
yesterday.
However if you look at this test : https://review.openstack.org/#/c/261997/
 it verify that the correct number of flows
are installed after a clean devstack process.

What i noticed with this patch is that devstack stack process finish
successfully, but the controller
had a repeating exception and not all the flows were configured.
I verified it happens few times to make sure.

Hopefully when the patch merge we will have gate test that check this kind
of scenario.
I am not sure what is the problem root cause, but we will need to
investigate it as
maybe its hiding another bug that isn't directly related to that patch.

Gal.


On Tue, Dec 29, 2015 at 4:06 AM, Li Ma  wrote:

> Hi Gal, you reverted this patch [1] due to the broken pipeline. Could
> you provide some debug information or detailed description? When I run
> my devstack, I cannot reproduce the sync problem.
>
> [1]
> https://github.com/openstack/dragonflow/commit/f83dd5795d54e1a70b8bdec1e6dd9f7815eb6546
>
> --
>
> Li Ma (Nick)
> Email: skywalker.n...@gmail.com
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Best Regards ,

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

Re: [openstack-dev] [Neutron] [Dragonflow] Support configuration of DB clusters

[Gal Sagie]

Hi Li Ma,

I think its a good idea.
I suggest for first stage, pass the CONF as optional parameter in addition
to the db_ip and db_port.
This way you will have minimum code changes at first patch.

If we see its working ok, we can later remove db_ip and db_port and adjust
the other
drivers in another patch.

Thanks
Gal.


On Mon, Dec 28, 2015 at 9:48 AM, Li Ma  wrote:

> My intention is to pass db-host-list (maybe it is defined in the conf
> file) to db backend drivers. I find that there's '**args' available
> [1], but it seems not working due to [2].
>
> I suggest to use a simpler method to allow user-defined configuration that
> is
> removing db_ip and db_port parameters and directly passing cfg.CONF
> object to db backend driver.
>
> In db_api.py, it should be:
> def initialize(self, config):
> self.config = config
>
> In api_nb.py, it should be:
> def initialize(self):
> self.driver.initialize(cfg.CONF) <-- from oslo_config
>
> As a result, let db backend developers choose which parameter to use.
>
> [1]
> https://github.com/openstack/dragonflow/blob/master/dragonflow/db/db_api.py#L21
> [2]
> https://github.com/openstack/dragonflow/blob/master/dragonflow/db/api_nb.py#L74-L75
>
> On Mon, Dec 28, 2015 at 9:12 AM, shihanzhang 
> wrote:
> >
> > good suggestion！
> >
> >
> > At 2015-12-25 19:07:10, "Li Ma"  wrote:
> >>Hi all, currently, we only support db_ip and db_port in the
> >>configuration file. Some DB SDK supports clustering, like Zookeeper.
> >>You can specify a list of nodes when client application starts to
> >>connect to servers.
> >>
> >>I'd like to implement this feature, specifying ['ip1:port',
> >>'ip2:port', 'ip3:port'] list in the configuration file. If only one
> >>server exists, just set it to ['ip1:port'].
> >>
> >>Any suggestions?
> >>
> >>--
> >>
> >>Li Ma (Nick)
> >>Email: skywalker.n...@gmail.com
> >>
>
> >>__
> >>OpenStack Development Mailing List (not for usage questions)
> >>Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> >
> >
> >
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
>
>
> --
>
> Li Ma (Nick)
> Email: skywalker.n...@gmail.com
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Best Regards ,

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

[openstack-dev] [Neutron][Dragonflow] - IRC Meeting today (12/28) - 0900 UTC

[Gal Sagie]

Hello All,

We will have an IRC meeting today (Monday, 12/28) at 0900 UTC
in #openstack-meeting-4

Please review the expected meeting agenda here:
https://wiki.openstack.org/wiki/Meetings/Dragonflow

You can view last meeting action items and logs here:
http://eavesdrop.openstack.org/meetings/dragonflow/2015/dragonflow.2015-12-21-09.00.html


Please update the agenda if you have any subject you would like to discuss
about.

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

Re: [openstack-dev] [Neutron] [Dragonflow] Support configuration of DB clusters

[Gal Sagie]

Hi Li Ma,

This approach makes sense to me, i was also thinking about the ability for
the user to specify additional
arguments and parameters to the DB driver.
Feel free to register a bug and work on that.

Thanks
Gal.

On Fri, Dec 25, 2015 at 1:07 PM, Li Ma  wrote:

> Hi all, currently, we only support db_ip and db_port in the
> configuration file. Some DB SDK supports clustering, like Zookeeper.
> You can specify a list of nodes when client application starts to
> connect to servers.
>
> I'd like to implement this feature, specifying ['ip1:port',
> 'ip2:port', 'ip3:port'] list in the configuration file. If only one
> server exists, just set it to ['ip1:port'].
>
> Any suggestions?
>
> --
>
> Li Ma (Nick)
> Email: skywalker.n...@gmail.com
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Best Regards ,

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

Re: [openstack-dev] [OpenStack-dev][Neutron] Is there a tool of generating network topology?

[Gal Sagie]

Depends what you mean "Network topology" , Horizon UI has virtual network
topology
graph/diagram.
If you mean the physical topology, thats a bit harder but i remember there
was a talk
proposal for the previous summit on that area (i think garyk (CCed) was one
of the proposed talkers so maybe
he can shade some more light on this)

On Tue, Dec 22, 2015 at 6:36 AM, Hong Hui Xiao  wrote:

> Hi,
>
> I remember there was discussion about it. I have these[1-2] in my
> bookmark, maybe they are what you want.
>
> [1]
> http://leoh0.github.io/blog/2015/04/03/draw-openstack-l2-network-architecture-automatically/
> [2] https://github.com/larsks/neutron-diag
>
> ---
> Hong Hui Xiao(肖宏辉)
>
>
> - Original message -
> From: Gareth 
> To: OpenStack Development Mailing List 
> Cc:
> Subject: [openstack-dev] [OpenStack-dev][Neutron] Is there a tool of
> generating network topology?
> Date: Tue, Dec 22, 2015 12:28 PM
>
> Hi, networking guys,
>
> For example, we could use it to generate a png file or print ascii in
> command line. Is there something like this?
>
> --
> Gareth
>
> Cloud Computing, OpenStack, Distributed Storage, Fitness, Basketball
> OpenStack contributor, kun_huang@freenode
> My promise: if you find any spelling or grammar mistakes in my email
> from Mar 1 2013, notify me
> and I'll donate $1 or ￥1 to an open organization you specify.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Best Regards ,

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

[openstack-dev] [Kuryr] IRC Meeting - Monday 1500 UTC (#openstack-meeting-4)

[Gal Sagie]

Hello All,

I have updated the agenda for the upcoming Kuryr IRC meeting [1]
Please review and add any additional topics you might want to cover.

Last meeting action items can be seen here [2]

I personally wont be able to attend the meeting and we expect low
participant volume
due to holidays but apuimedo still suppose to come :)

[1] https://wiki.openstack.org/wiki/Meetings/Kuryr
[2]
http://eavesdrop.openstack.org/meetings/kuryr/2015/kuryr.2015-12-15-03.00.html
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron][Dragonflow] - IRC Meeting tomorrow (12/21) - 0900 UTC

[Gal Sagie]

Hello All,

We will have an IRC meeting tomorrow (Monday, 12/21) at 0900 UTC
in #openstack-meeting-4

Please review the expected meeting agenda here:
https://wiki.openstack.org/wiki/Meetings/Dragonflow

You can view last meeting action items and logs here:
http://eavesdrop.openstack.org/meetings/dragonflow/2015/dragonflow.2015-12-14-09.00.html


Please update the agenda if you have any subject you would like to discuss
about.

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

[openstack-dev] [Magnum][Kuryr] Help with using docker-python client in gate

[Gal Sagie]

Hello Everyone,

We are trying to add some gate testing for Kuryr and hopefully convert
these also to Rally
plugins.

What i am facing in the gate right now is this:
I configure the docker client:

self.docker_client = docker.Client(
base_url='unix://var/run/docker.sock')

And call this:
self.docker_client.create_network(name='fakenet', driver='kuryr')

This works locally, and i also tried to run this code with a different user

But on the gate this fails:
http://logs.openstack.org/79/258379/5/check/gate-kuryr-dsvm-fullstack-nv/f46ebdb/

2-17 05:22:16.900

| 2015-12-17 05:22:16.851 | 2015-12-17 05:22:16.902

| 2015-12-17 05:22:16.852 | {0}
kuryr.tests.fullstack.test_network.NetworkTest.test_create_delete_network
[0.093287s] ... FAILED2015-12-17 05:22:16.934

| 2015-12-17 05:22:16.854 | 2015-12-17 05:22:16.935

| 2015-12-17 05:22:16.855 | Captured traceback:2015-12-17 05:22:16.935

| 2015-12-17 05:22:16.856 | ~~~2015-12-17 05:22:16.935

| 2015-12-17 05:22:16.857 | Traceback (most recent call
last):2015-12-17 05:22:16.935

| 2015-12-17 05:22:16.859 |   File
"kuryr/tests/fullstack/test_network.py", line 27, in
test_create_delete_network2015-12-17 05:22:16.936

| 2015-12-17 05:22:16.860 |
self.docker_client.create_network(name='fakenet',
driver='kuryr')2015-12-17 05:22:16.936

| 2015-12-17 05:22:16.861 |   File
"/opt/stack/new/kuryr/.tox/fullstack/local/lib/python2.7/site-packages/docker/utils/decorators.py",
line 35, in wrapper2015-12-17 05:22:16.936

| 2015-12-17 05:22:16.862 | return f(self, *args,
**kwargs)2015-12-17 05:22:16.936

| 2015-12-17 05:22:16.864 |   File
"/opt/stack/new/kuryr/.tox/fullstack/local/lib/python2.7/site-packages/docker/api/network.py",
line 28, in create_network2015-12-17 05:22:16.936

| 2015-12-17 05:22:16.865 | res = self._post_json(url,
data=data)2015-12-17 05:22:16.937

| 2015-12-17 05:22:16.866 |   File
"/opt/stack/new/kuryr/.tox/fullstack/local/lib/python2.7/site-packages/docker/client.py",
line 166, in _post_json2015-12-17 05:22:16.937

| 2015-12-17 05:22:16.867 | return self._post(url,
data=json.dumps(data2), **kwargs)2015-12-17 05:22:16.937

| 2015-12-17 05:22:16.870 |   File
"/opt/stack/new/kuryr/.tox/fullstack/local/lib/python2.7/site-packages/docker/client.py",
line 107, in _post2015-12-17 05:22:16.937

| 2015-12-17 05:22:16.871 | return self.post(url,
**self._set_request_timeout(kwargs))2015-12-17 05:22:16.937

| 2015-12-17 05:22:16.873 |   File
"/opt/stack/new/kuryr/.tox/fullstack/local/lib/python2.7/site-packages/requests/sessions.py",
line 511, in post2015-12-17 05:22:16.937

| 2015-12-17 05:22:16.874 | return self.request('POST', url,
data=data, json=json, **kwargs)2015-12-17 05:22:16.938

[openstack-dev] [Kuryr] IRC Meeting - Tuesday 0300 UTC (12/15)

[Gal Sagie]

Hello All,

I have updated the agenda for the upcoming Kuryr IRC meeting [1]
Please review and add any additional topics you might want to cover.

Also please go over last meeting action items [2] , there are still patches
(IPAM)
that are looking for review love :)

Since this is the week we do the meeting in an alternating time, i won't be
able to attend
(and i believe toni won't be able to as well)
Taku/banix please run the meeting.

banix, would love if you can update regarding the team/peoples going to work
on testing/CI for Kuryr, i think this is a top priority for us at this
cycle.

[1] https://wiki.openstack.org/wiki/Meetings/Kuryr
[2]
http://eavesdrop.openstack.org/meetings/kuryr/2015/kuryr.2015-12-07-15.00.html
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron][Dragonflow] - IRC Meeting tomorrow (12/14) - 0900 UTC

[Gal Sagie]

Hello All,

We will have an IRC meeting tomorrow (Monday, 12/14) at 0900 UTC
in #openstack-meeting-4

Please review the expected meeting agenda here:
https://wiki.openstack.org/wiki/Meetings/Dragonflow

You can view last meeting action items and logs here:
http://eavesdrop.openstack.org/meetings/dragonflow/2015/dragonflow.2015-12-07-08.59.html

Please update the agenda if you have any subject you would like to discuss
about.

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

[openstack-dev] [Neutron][Dragonflow] - Documentation

[Gal Sagie]

Hello All,

We have recently uploaded a big amount of documents and diagrams to
Dragonflow
repository in order to expose what we are doing and make it as simple as we
can for new
contributors and users to start using Dragonflow.

I have created a wiki page for Dragonflow [1].

Some recommended documents:

- Dragonflow mission statement and high level architecture [2]
- Dragonflow pluggable DB architecture [3]
- Dragonflow Distributed DHCP implementation [4]
- Dragonflow OpenFlow Pipeline explained [5]

If you are both new or familiar with the project, i think you will find
these
interesting to read.

[1] https://wiki.openstack.org/wiki/Dragonflow
[2]
http://docs.openstack.org/developer/dragonflow/distributed_dragonflow.html
[3] http://docs.openstack.org/developer/dragonflow/pluggable_db.html
[4] http://docs.openstack.org/developer/dragonflow/distributed_dhcp.html
[5] http://docs.openstack.org/developer/dragonflow/pipeline.html
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Kuryr] Testing, Rally and Wiki

[Gal Sagie]

Hi Boris,

The way i envision it, is for this to first implement Docker resources
(networks, containers) which are deployed
in a mixed OpenStack environments and use Kuryr to plug their network.
Then we can create some scenarios to benchmark and test these mixed
environments with Kuryr or with Magnum and Kuryr.

Open for any other suggestions/ideas.

Gal.

On Fri, Dec 11, 2015 at 1:22 AM, Boris Pavlovic  wrote:

> Hi Gal,
>
>
>> We are also working on combining Rally testing with Kuryr and for that we
>> are going to
>> introduce Docker context plugin and client and other parts that are
>> probably needed by other projects (like Magnum)
>> I think it would be great if we can combine forces on this.
>
>
> What this context is going to do?
>
>
> Best regards,
> Boris Pavlovic
>
> On Thu, Dec 10, 2015 at 6:11 AM, Gal Sagie  wrote:
>
>> Hello everyone,
>>
>> As some of you have already noticed one of the top priorities for Kuryr
>> this cycle is to get
>> our CI and gate testing done.
>>
>> I have been working on creating the base for adding integration tests
>> that will run
>> in the gate in addition to our unit tests and functional testing.
>>
>> If you would like to join and help this effort, please stop by
>> #openstack-kuryr or email
>> me back.
>>
>> We are also working on combining Rally testing with Kuryr and for that we
>> are going to
>> introduce Docker context plugin and client and other parts that are
>> probably needed by other projects (like Magnum)
>> I think it would be great if we can combine forces on this.
>>
>> I have also created Kuryr Wiki:
>> https://wiki.openstack.org/wiki/Kuryr
>>
>> Feel free to edit and add needed information.
>>
>>
>> Thanks all
>> Gal.
>>
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Best Regards ,

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

[openstack-dev] [Kuryr] Testing, Rally and Wiki

[Gal Sagie]

Hello everyone,

As some of you have already noticed one of the top priorities for Kuryr
this cycle is to get
our CI and gate testing done.

I have been working on creating the base for adding integration tests that
will run
in the gate in addition to our unit tests and functional testing.

If you would like to join and help this effort, please stop by
#openstack-kuryr or email
me back.

We are also working on combining Rally testing with Kuryr and for that we
are going to
introduce Docker context plugin and client and other parts that are
probably needed by other projects (like Magnum)
I think it would be great if we can combine forces on this.

I have also created Kuryr Wiki:
https://wiki.openstack.org/wiki/Kuryr

Feel free to edit and add needed information.


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

[openstack-dev] [openstack-infra] Using Neutron client in the gate

[Gal Sagie]

Hello All,

I would like to run some "fullstack" integration tests for Kuryr and run
them in
the gate.
For the tests i would like to use the Neutron client for communicating with
the
working devstack Neutron service.

What is the best way to instantiate the client in terms of auth_url and
credentials ?
(I saw 'secretadmin' is used as admin password, but wondered if using hard
coded
args is the best approach)

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

Re: [openstack-dev] [openstack-infra] Functional tests in the gate

[Gal Sagie]

Thanks for the answer Andrey,

In the post_test_hook of this, you run the ec2-api functional tests.
What i am asking, is how to prevent these tests from running in
gate-X-python27 for example (which they will
obviously fail as they need a working devstack to run)

Maybe i am not understanding something fundamental here.

Gal.

On Sun, Dec 6, 2015 at 6:56 PM, Andrey Pavlov  wrote:

> For example -
> https://github.com/openstack-infra/project-config/blob/master/jenkins/jobs/ec2-api.yaml#L45
>
> this job has next lines:
>   export DEVSTACK_GATE_TEMPEST=1
>   export DEVSTACK_GATE_TEMPEST_NOTESTS=1
> first line tells to install tempest
> and second tells that job should not run it
>
> and then 'post_test_hook' defines commands to run.
>
> On Sun, Dec 6, 2015 at 7:06 PM, Gal Sagie  wrote:
>
>> Hello all,
>>
>> I want to write functional tests that will run in the gate but only after
>> a devstack
>> environment has finished.
>> Basically i want to interact with a working enviorment, but i don't want
>> the tests that i write
>> to fail the python27 gate tests.
>>
>> (I guess like the Neutron full stack tests, but i haven't found how to do
>> it yet)
>>
>> Can anyone please direct me to an example / or help me figure out how to
>> achieve this?
>>
>> Thanks
>> Gal.
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> Kind regards,
> Andrey Pavlov.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Best Regards ,

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

[openstack-dev] [openstack-infra] Functional tests in the gate

[Gal Sagie]

Hello all,

I want to write functional tests that will run in the gate but only after a
devstack
environment has finished.
Basically i want to interact with a working enviorment, but i don't want
the tests that i write
to fail the python27 gate tests.

(I guess like the Neutron full stack tests, but i haven't found how to do
it yet)

Can anyone please direct me to an example / or help me figure out how to
achieve this?

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

Re: [openstack-dev] [Neutron] Evolving the stadium concept

[Gal Sagie]

To me, and i could got it wrong, the stadium means two main things: (At
this point in time)

1) Remove/ease the burden of OpenStack governance and extra job for
projects/drivers that implement Neutron and are "relatively small"
This saves the projects that just want to implement Neutron to be
managed with the same infrastructure but not deal
with a lot of extra stuff (That same extra stuff you are complaining
about and i totally understand where you coming from..)

2) Be able to set a standard of "quality" (and this needs to be better
defined) for all the drivers that implement Neutron, and
also set a standard for development process (specs, bugs, priorities,
CI, testing)

With this definition, it first means to me, as Russell suggested, that
Kuryr should be an independent project.
Regarding Dragonflow and Octavia i am not sure yet but lean to the same
conclusion as Russell.

In order to solve some of the problems you mention, I suggest the following:

1) Define a set of responsibilities/guidelines for the sub-projects
lieutenants in order to comply with the "quality" standard
If they fail to do it with no good explanation for X cycles, the
project should be removed from the stadium.

2) As suggested, delegate and increase the team size that is responsible to
verify and help these projects with the extra work.
I am sure there are people willing to volunteer and help with these
tasks, and test periods could be applied for trust issues.
I believe we all want to see Neutron and OpenStack succeed.

I dont see how just moving this work to the TC or any other centralized
group in OpenStack is going to help, i think we
want to strive to group common work to parents projects, especially in this
case (in my opinion anyway).

I think this can be very handy when we will want our processes (at least in
the Neutron world) to be similar and
complimenting.

Just the way i see things right now..

Gal.




On Tue, Dec 1, 2015 at 9:10 AM, Armando M.  wrote:

>
>
> On 30 November 2015 at 20:11, Russell Bryant  wrote:
>
>> Some additional context: there are a few proposals for additional git
>> repositories for Neutron that have been put on hold while we sort this
>> out.
>>
>> Add networking-bagpipe:
>>   https://review.openstack.org/#/c/244736/
>>
>> Add the Astara driver:
>>   https://review.openstack.org/#/c/230699/
>>
>> Add tap-as-a-service:
>>   https://review.openstack.org/#/c/229869/
>>
>> On 11/30/2015 07:56 PM, Armando M. wrote:
>> > I would like to suggest that we evolve the structure of the Neutron
>> > governance, so that most of the deliverables that are now part of the
>> > Neutron stadium become standalone projects that are entirely
>> > self-governed (they have their own core/release teams, etc). In order to
>> > denote the initiatives that are related to Neutron I would like to
>> > present two new tags that projects can choose to label themselves with:
>> >
>> >   * 'is-neutron-subsystem': this means that the project provides
>> > networking services by implementing an integral part (or parts) of
>> > an end-to-end neutron system. Examples are: a service plugin, an ML2
>> > mech driver, a monolithic plugin, an agent etc. It's something an
>> > admin has to use in order to deploy Neutron in a certain
>> configuration.
>> >   * 'use-neutron-system': this means that the project provides
>> > networking services by using a pre-deployed end-to-end neutron
>> > system as is. No modifications whatsoever.
>>
>> I just want to clarify the proposal.  IIUC, you propose splitting most
>> of what is currently separately deliverables of the Neutron team and
>> making them separate projects in terms of OpenStack governance.  When I
>> originally proposed including networking-ovn under Neutron (and more
>> generally, making room for all drivers to be included), making them
>> separate projects was one of the options on the table, but it didn't
>> seem best at the time.  For reference, that thread was here:
>>
>> http://lists.openstack.org/pipermail/openstack-dev/2015-April/062310.html
>>
>> When I was originally proposing this, I was only thinking about Neutron
>> drivers, the stuff that connects Neutron to some other system to make
>> Neutron do something.  The list has grown to include other things, as
>> well.
>>
>> I'm not sure where you propose the line to be, but for the sake of
>> discussion, let's assume every deliverable in the governance definition
>> for Neutron is under consideration for being split out with the
>> exception of neutron, neutron-specs, and python-neutronclient.  The
>> remaining deliverables are:
>>
>> dragonflow:
>> kuryr:
>> networking-ale-omniswitch:
>> networking-arista:
>> networking-bgpvpn:
>> networking-calico:
>> networking-cisco:
>> networking-fortinet:
>> networking-hpe:
>> networking-hyperv:
>> networking-infoblox:
>> networking-fujitsu:
>> networking-l2gw:
>> networking-lenovo:
>>

Re: [openstack-dev] [Neutron] Security Groups OVS conntrack support

[Gal Sagie]

Hi Fawad,

>From what i could understand from Miguel Angel Ajo, someone is working on
this integration and it
is suppose to be delivered as part of Mitaka.
I don't remember the person name, Miguel will sure update shortly.

Gal.

On Sun, Nov 22, 2015 at 7:05 PM, Fawad Khaliq  wrote:

> Folks,
>
> Is there a plan to add conntrack support to the security groups for the
> OVS driver in Mitaka cycle?
>
> My understanding is that it is being actively worked on for networking-ovn
> but no concrete plan for support in the OVS Neutron driver yet.
>
> Thanks,
> Fawad Khaliq
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Best Regards ,

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

Re: [openstack-dev] [networking-onos]: Proposing new cores for networking-onos

[Gal Sagie]

+1 for both from me

On Thu, Nov 5, 2015 at 2:53 PM, Vikram Choudhary  wrote:

> Hi All,
>
> I would like to propose Mr. Ramanjaneya Reddy Palleti and Mr. Dongfeng as
> new cores for networking-onos project. Their contribution was significant
> in the last Liberty cycle w.r.t to this project.
>
> *Facts:*
> http://stackalytics.com/?metric=loc&module=networking-onos&release=all
>
> Request existing cores to vote for this proposal.
>
> Thanks
> Vikram
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Best Regards ,

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

Re: [openstack-dev] [kuryr] mutihost networking with nova vm as docker host

[Gal Sagie]

The current OVS binding proposals are not for nested containers.
I am not sure if you are asking about that case or about the nested
containers inside a VM case.

For the nested containers, we will use Neutron solutions that support this
kind of configuration, for example
if you look at OVN you can define "parent" and "sub" ports, so OVN knows to
perform the logical pipeline in the compute host
and only perform VLAN tagging inside the VM (as Toni mentioned)

If you need more clarification you can catch me on IRC as well and we can
talk.

On Thu, Nov 5, 2015 at 8:03 AM, Vikas Choudhary 
wrote:

> Hi All,
>
> I would appreciate inputs on following queries:
> 1. Are we assuming nova bm nodes to be docker host for now?
>
> If Not:
>  - Assuming nova vm as docker host and ovs as networking plugin:
> This line is from the etherpad[1], "Eachdriver would have an
> executable that receives the name of the veth pair that has to be bound to
> the overlay" .
> Query 1:  As per current ovs binding proposals by Feisky[2]
> and Diga[3], vif seems to be binding with br-int on vm. I am unable to
> understand how overlay will work. AFAICT , neutron will configure br-tun of
> compute machines ovs only. How overlay(br-tun) configuration will happen
> inside vm ?
>
>  Query 2: Are we having double encapsulation(both at vm and
> compute)? Is not it possible to bind vif into compute host br-int?
>
>  Query3: I did not see subnet tags for network plugin being
> passed in any of the binding patches[2][3][4]. Dont we need that?
>
>
> [1]  https://etherpad.openstack.org/p/Kuryr_vif_binding_unbinding
> [2]  https://review.openstack.org/#/c/241558/
> [3]  https://review.openstack.org/#/c/232948/1
> [4]  https://review.openstack.org/#/c/227972/
>
>
> -Vikas Choudhary
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Best Regards ,

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

[openstack-dev] [Neutron][Kuryr] - Design Summit etherpad

[Gal Sagie]

Hello All,

It was great meeting everyone in the summit, it ended too fast..
We had a free design talk on Friday about Kuryr. (Thanks to everyone that
participated)

We have created this etherpad with all the related tasks:

https://etherpad.openstack.org/p/mitaka-neutron-unplugged-track-kuryr

If there is something you would like to work on, please let us know, we
have some
challenging and interesting tasks ahead of us.

Since everyone are still recovering from the summit, we will not have an
IRC Meeting
today.

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

Re: [openstack-dev] [neutron][networking-sfc] API clarification questions

[Gal Sagie]

Hi Pino,

Just one note on the order of the pipeline, shouldnt the security part be
before the service chaining (and also after)?
(Unless you only meant egress security and you still do the ingress before)

Gal.

On Wed, Oct 28, 2015 at 10:14 AM, Giuseppe (Pino) de Candia <
gdecan...@midokura.com> wrote:

> On Wed, Oct 28, 2015 at 4:20 PM, Russell Bryant 
> wrote:
>
>> I read through the proposed SFC API here:
>>
>> http://docs.openstack.org/developer/networking-sfc/api.html
>>
>> I'm looking at implementing what would be required to support this API
>> in OVN.  I have a prototype, but I had to make some pretty big
>> assumptions, so I wanted to clarify the intent of the API.
>>
>> First, does it assume that all of the neutron ports in a chain are on
>> the same Neutron network?  That keeps things simple.  If its intended to
>> allow a chain of ports on different networks, is it just required that
>> you pick ports that all have addresses routable from one port to the
>> next in the chain?  An arbitrary set of ports can't always work, so
>> there has to be some bounds around what set of ports are valid to be in
>> a chain.
>>
>
> Hi Russell,
>
> We have similarly been experimenting with a MidoNet implementation of the
> SFC API.
>
> I hope there's no restriction on the location of the Neutron ports in a
> chain.
>
> In terms of addresses, I believe the API is lacking (or we use a
> chain_parameter?) a way to indicate the service insertion model:
> - L2 - The service can accept packets sent from any MAC (service NIC in
> promiscuous mode). The MAC address may be used to identify where the packet
> came from before it entered the chain.
> - L3 -  The service expects packets to be routed to it. So the destination
> MAC of the packet must be set to the service's NIC's MAC.
>
> Any thoughts on this?
>
>
>>
>> Second, where is it expected that the match is applied?  The API for
>> creating a port chain doesn't associate the chain with a network, but
>> just matching "globally" doesn't make any sense.  If all ports are
>> expected to be on the same network, is the match applied for any traffic
>> entering that network from any port?
>>
>
> Here's what we were thinking for MidoNet:
>
> use the logical_source_port in the flow classifier: when we render the SFC
> API in MidoNet's models we will associate the chain with the source port.
>
> Our packet pipeline (for packets egressing the VM) is:
>
>1. Port Mirroring
>2. Service Chaining
>3. Filtering (Port Security, anti-spoofing, Security Groups)
>
>
> Do you think we can standardise on a single order in all implementations?
> We'd be happy to change the order if it makes sense.
>
>
>
>>
>> I'm in Tokyo this week, so if the group working on this would like to
>> talk in person, that would be great too.
>>
>
> I'd love to be included.
>
> Great topic, thanks!
>
> Pino
>
>
>>
>> --
>> Russell Bryant
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Best Regards ,

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

Re: [openstack-dev] [Neutron] Gerrit permissions and Merge rights

[Gal Sagie]

On Wed, Oct 21, 2015 at 7:37 PM, Armando M.  wrote:

>
>
> On 21 October 2015 at 04:12, Gal Sagie  wrote:
>
>> Do we also want to consider Project Kuryr part of this?
>>
>
> No, why would we?
>

[Gal] Because Kuryr is a special project which was created in order to
expose Neutron and its services to containers networking,
 its mission (at least as defined right now) is to bridge the gaps
between containers networking world and Neutron and for doing it
 it already depends on the feature/spec process of Neutron.
 That is why it make sense to me that just like the services
projects, our spec approval process will be handled
 as part of Neutron.


>
>
>> We already started sending Kuryr spec to the Neutron repository and I
>> think it would make sense to manage it
>> as part of Neutron spec process.
>>
>
> No, unless what you are asking are changes to the core. Do you have a
> reference for me to look at?
>
>
  [Gal]   I dont understand what you mean "No" here, first this spec is
sent to Mitaka:
 https://review.openstack.org/#/c/213490/

And as i mentioned above Kuryr spec process depends on Neutron
(and the specs that are sent
to Neutron core)


>> Any opinions on that?
>>
>> Gal.
>>
>> On Tue, Oct 20, 2015 at 11:10 PM, Armando M.  wrote:
>>
>>> Hi folks,
>>>
>>> During revision of the Neutron teams [1], we made clear that the
>>> neutron-specs repo is to be targeted by specs for all the Neutron projects
>>> (core + *-aas).
>>>
>>> For this reason I made sure that the neutron-specs-core team +2 right
>>> was extended to all the core teams.
>>>
>>> Be mindful, use your +2 rights with care: if you are core on a *-aas
>>> project, you should exercise that vote only for specs that pertain the
>>> project you're core of.
>>>
>>> If I could use this email as a reminder also of the core hierarchy and
>>> lieutenant system we switched to in Liberty ([3]): if you have been made
>>> core by a lieutenant of a sub-system, please use your +2/+A only within
>>> your area of comfort and reach out for help if in doubt.
>>>
>>> Reviews are always welcome though!
>>>
>>> Cheers,
>>> Armando
>>>
>>> [1] https://review.openstack.org/#/c/237180/
>>> [2] https://review.openstack.org/#/admin/groups/314,members
>>> [3]
>>> http://docs.openstack.org/developer/neutron/policies/neutron-teams.html#core-review-hierarchy
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>>
>> --
>> Best Regards ,
>>
>> The G.
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Best Regards ,

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

[openstack-dev] [Neutron][Kuryr] IRC Meeting - Canceled for next week (10/26)

[Gal Sagie]

Hello Everyone,

Just wanted to share with anyone that wasn't in the meeting this week, that
we decided
to cancel the IRC meeting on the 10/26.

See you all in the summit.

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

Re: [openstack-dev] [Neutron] Gerrit permissions and Merge rights

[Gal Sagie]

Do we also want to consider Project Kuryr part of this?
We already started sending Kuryr spec to the Neutron repository and I think
it would make sense to manage it
as part of Neutron spec process.

Any opinions on that?

Gal.

On Tue, Oct 20, 2015 at 11:10 PM, Armando M.  wrote:

> Hi folks,
>
> During revision of the Neutron teams [1], we made clear that the
> neutron-specs repo is to be targeted by specs for all the Neutron projects
> (core + *-aas).
>
> For this reason I made sure that the neutron-specs-core team +2 right was
> extended to all the core teams.
>
> Be mindful, use your +2 rights with care: if you are core on a *-aas
> project, you should exercise that vote only for specs that pertain the
> project you're core of.
>
> If I could use this email as a reminder also of the core hierarchy and
> lieutenant system we switched to in Liberty ([3]): if you have been made
> core by a lieutenant of a sub-system, please use your +2/+A only within
> your area of comfort and reach out for help if in doubt.
>
> Reviews are always welcome though!
>
> Cheers,
> Armando
>
> [1] https://review.openstack.org/#/c/237180/
> [2] https://review.openstack.org/#/admin/groups/314,members
> [3]
> http://docs.openstack.org/developer/neutron/policies/neutron-teams.html#core-review-hierarchy
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Best Regards ,

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

[openstack-dev] [Neutron] Design Summit Session - Containers Orchestration platforms Integration with Neutron

[Gal Sagie]

Hello All,

In OpenStack Tokyo summit we will have a design summit session for
containers networking
and containers orchestration engines integration with Neutron [1].

Please feel free to edit the session etherpad [2] with relevant topics, if
you are working
and have any gaps or needs from Neutron in that area, please share.

Even if we cant resolve everything in one session, i think it would be
great to at least understand
the problems and document them so we can address the needs and priorities
during the upcoming cycle.

Thanks
Gal.

[1]
http://mitakadesignsummit.sched.org/event/9be2ec1db45ea3267f811b8d35816e1c#.ViN7rLOY7CI
[2] https://etherpad.openstack.org/p/mitaka-neutron-labs-orchestration
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][networking-ovn][l3] Add/delete router interface

[Gal Sagie]

I have actually raised this issue in OVS/OVN mailing list some time ago.
(http://openvswitch.org/pipermail/dev/2015-July/058231.html)
You can read the followup discussion that went on after...

I don't see this being resolved before the summit either way, so its better
to currently disable these tests
and add the appropriate comment (and open a launchpad bug to track this)

Gal.

On Sat, Oct 17, 2015 at 5:05 AM, Chandra Sekhar Vejendla <
csvej...@us.ibm.com> wrote:

> Hello Everyone,
>
> We are currently working on a patch set to add/delete router
> interfaces in the OVN plugin. This patch was initially worked on by
> Gal Sagie (*https://review.openstack.org/#/c/206919/*
> <https://review.openstack.org/#/c/206919/>) and we took over
> to take it completion.
>
> There are bunch of gate tests that are failing as a result of this
> patch and we have fixed a few of them. What remain to be fixed are the
> following.
>
> test_dhcp6_stateless_from_os
> test_dualnet_multi_prefix_dhcpv6_stateless
> test_dualnet_multi_prefix_slaac
> test_multi_prefix_dhcpv6_stateless
> test_multi_prefix_slaac
> test_slaac_from_os
>
> The reason for the failure of these tests has got to do with the way
> OVN handles router interface. In openstack multiple subnets can be
> added to a network and for each of these subnets the router interface
> has to be explicitly configured. So for a given network there can be
> multiple router interfaces. With the current NB schema in OVN there
> can be only 1 router interface for a network.
>
> Most of the above test cases try to add multiple subnets in a network,
> configure router interfaces, do some connectivity tests and then clean
> up. When a router interface is configured for the first subnet all the
> DB tables are populated correctly, but when the router interface for
> the second subnet is created, it results in deletion of the router
> interface of the first subnet. So every time a router interface is
> configured for a subnet, it results in deletion of the previous
> subnets router interface, provided both the subnets belong to the same
> network. The test cases fail when they are trying to remove the router
> interface that has already been deleted from OVN NB.
>
> We considered an option to see if we can have a router port in
> "Logical Switch" table refer to multiple rows in the "Logical Router
> Port" table, but the router port in the schema is defined as a hard
> reference to uuid of the "Logical Router Port" table.
>
> Given that we want to demo l3 in Tokyo, should we consider disabling
> these tests until we figure out how to fix the issue ? Should i start
> a separate thread on ovs-dev to follow up on the issue?
>
> Thanks,
> Chandra
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Best Regards ,

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