Re: [openstack-dev] [neutron] - Neutron team social in Atlanta on Thursday

[Carlos Gonçalves]

+1

On Mon, Feb 20, 2017 at 9:17 AM, Kevin Benton  wrote:

> No problem. Keep sending in RSPVs if you haven't already.
>
> On Mon, Feb 20, 2017 at 2:59 AM, Furukawa, Yushiro <
> y.furukaw...@jp.fujitsu.com> wrote:
>
>> +1
>>
>>
>>
>> Sorry for late, Kevin!!
>>
>>
>>
>> 
>>
>>   Yushiro Furukawa
>>
>>
>>
>> *From:* Kevin Benton [mailto:ke...@benton.pub]
>>
>>
>>
>> Hi all,
>>
>>
>>
>> I'm organizing a Neutron social event for Thursday evening in Atlanta
>> somewhere near the venue for dinner/drinks. If you're interested, please
>> reply to this email with a "+1" so I can get a general count for a
>> reservation.
>>
>>
>>
>> Cheers,
>>
>> Kevin Benton
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Congress][Fuel] Fuel plugin for installing Congress

[Carlos Gonçalves]

Hi Serg,

This is great news! On behalf of the OPNFV Doctor team, thank you Fuel@Opnfv
team for this effort!
We will certainly test it out as soon as possible, and we'll provide
feedback.

Cheers,
Carlos


On Mon, Jan 16, 2017 at 8:33 PM, Serg Melikyan 
wrote:

> I'd like to introduce you fuel plugin for installing and configuring
> Congress for Fuel [0].
>
> This plugin was developed by Fuel@Opnfv [1] Community in order to be
> included to the next release of the Fuel@Opnfv - Danube. We believe
> that this plugin might be helpful not only for us but also for general
> OpenStack community and decided to continue development of the plugin
> in the OpenStack Community.
>
> Please join us in the development of the Congress plugin, your
> feedback is greatly appreciated.
>
> P.S. Right now core team includes Fedor Zhadaev - original developer
> of the plugin, and couple of developers from Fuel@Opnfv including me.
> We considered adding congress-core to the list but decided to see
> amount of interest and feedback first from Congress team.
>
> References:
> [0] http://git.openstack.org/cgit/openstack/fuel-plugin-congress/
> [1] https://wiki.opnfv.org/display/Fuel/
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Ocata Design Summit ideas kick-off

[Carlos Gonçalves]

Hi Armando,

I'm not sure whether the team has already scheduled sessions for the design
summit.

I've added a topic to the list -- the usual suspect: discussion on status
and admin_state_up resource states...
I hope we can make to discuss their current behavior and expectations as
well as next steps being documentation the least we have to do.

Thanks,
Carlos



On Wed, Sep 28, 2016 at 2:41 AM, Armando M.  wrote:

> Hi folks,
>
> The summit is less than a month away and it's the time of the year where
> we need to plan for design summit sessions.
>
> This time we are going for 10 fishbowl sessions, plus Friday [0].
>
> We will break down sessions in three separate tracks as we did the last
> two summits. Each track will have its own theme and more details will be
> provided in due course.
>
> I started etherpad [1] to collect inputs and ideas. Please start
> brainstorming! I'll reach out to the driver team members individually to
> work out a more formal agenda once we get some ideas off the ground.
>
> Cheers,
> Armando
>
> [0] http://lists.openstack.org/pipermail/openstack-dev/2016-
> September/103851.html
> [1] https://etherpad.openstack.org/p/ocata-neutron-summit-ideas
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron] Change of ownership in Traffic Steering blueprint

[Carlos Gonçalves]

Hi all,

As the original author of the Traffic Steering blueprint [1] while I worked
for Instituto de Telecomunicacoes, I would like to appoint Igor Cardoso (in
CC) as the new owner if no one opposes to it. Igor will continue carrying
the blueprint proposal and its development onward targeting the Kilo
release [2]. I will still be working closely but now as a reviewer.

Igor is about to finish his Master thesis on the topic Network
Infraestructure Control for Virtual Campuses in University of Aveiro,
Portugal. During these past months, Igor gained much experience on
OpenStack deployment and development, focusing on extending Neutron as part
of his studies. As a Researcher at Instituto de Telecomunicacoes, he will
continue taking the traffic steering work further.

Igor and I will be attending the OpenStack Summit in Paris. Any questions
or suggestions you may have, please feel free to poke us. In the meantime
you can also reach us by email or IRC (nicknames igordcard and cgoncalves).


Cheers,
Carlos Goncalves

[1]
https://review.openstack.org/#/q/topic:bp/traffic-steering-abstraction,n,z
[2] https://wiki.openstack.org/wiki/Neutron/AdvancedServices/JunoPlan
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] Specs repository update and the way forward

[Carlos Gonçalves]

On 12 Jun 2014, at 15:00, Carlos Gonçalves m...@cgoncalves.pt wrote:

 Is there any web page where all approved blueprints are being published to? 
 Jenkins builds such pages I’m looking for but they are linked to each 
 patchset individually (e.g., 
 http://docs-draft.openstack.org/77/92477/6/check/gate-neutron-specs-docs/f05cc1d/doc/build/html/).
  In addition, listing BPs currently under reviewing and linking to its 
 review.o.o page could potentially draw more attention/awareness to what’s 
 being proposed to Neutron (and other OpenStack projects).

Kyle? :-)

Thanks,
Carlos Goncalves___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova][neutron][NFV] Mid cycle sprints

[Carlos Gonçalves]

I’ve added Joao Soares (Portugal Telecom) and myself (Instituto de 
Telecomunicacoes) to https://wiki.openstack.org/wiki/Sprints/ParisJuno2014 for 
a Neutron and NFV meetup.
Please add yourselves as well so that we can have a better idea of who’s 
showing interest in participating.

Thanks,
Carlos Goncalves

On 17 Jun 2014, at 18:20, Sylvain Afchain sylvain.afch...@enovance.com wrote:

 Hi,
 
 +1 for Paris, since a mid-cycle sprint is already being hosted and organised 
 by eNovance :)
 
 Sylvain
 
 - Original Message -
 From: Dmitry mey...@gmail.com
 To: OpenStack Development Mailing List (not for usage questions) 
 openstack-dev@lists.openstack.org
 Sent: Sunday, June 15, 2014 3:40:43 PM
 Subject: Re: [openstack-dev] [Nova][neutron][NFV] Mid cycle sprints
 
 +1 for Paris/Lisbon
 
 On Sun, Jun 15, 2014 at 4:27 PM, Gary Kotton gkot...@vmware.com wrote:
 
 
 On 6/14/14, 1:05 AM, Anita Kuno ante...@anteaya.info wrote:
 
 On 06/13/2014 05:58 PM, Carlos Gonçalves wrote:
 Let me add to what I've said in my previous email, that Instituto de
 Telecomunicacoes and Portugal Telecom are also available to host and
 organize a mid cycle sprint in Lisbon, Portugal.
 
 Please let me know who may be interested in participating.
 
 Thanks,
 Carlos Goncalves
 
 On 13 Jun 2014, at 10:45, Carlos Gonçalves m...@cgoncalves.pt wrote:
 
 Hi,
 
 I like the idea of arranging a mid cycle for Neutron in Europe
 somewhere in July. I was also considering inviting folks from the
 OpenStack NFV team to meet up for a F2F kick-off.
 
 I did not know about the sprint being hosted and organised by eNovance
 in Paris until just now. I think it is a great initiative from eNovance
 even because it¹s not being focused on a specific OpenStack project.
 So, I'm interested in participating in this sprint for discussing
 Neutron and NFV. Two more people from Instituto de Telecomunicacoes and
 Portugal Telecom have shown interested too.
 
 Neutron and NFV team members, who¹s interested in meeting in Paris, or
 if not available on the date set by eNovance in other time and place?
 
 Thanks,
 Carlos Goncalves
 
 On 13 Jun 2014, at 08:42, Sylvain Bauza sba...@redhat.com wrote:
 
 Le 12/06/2014 15:32, Gary Kotton a écrit :
 Hi,
 There is the mid cycle sprint in July for Nova and Neutron. Anyone
 interested in maybe getting one together in Europe/Middle East around
 the same dates? If people are willing to come to this part of the
 world I am sure that we can organize a venue for a few days. Anyone
 interested. If we can get a quorum then I will be happy to try and
 arrange things.
 Thanks
 Gary
 
 
 
 Hi Gary,
 
 Wouldn't it be more interesting to have a mid-cycle sprint *before*
 the Nova one (which is targeted after juno-2) so that we could discuss
 on some topics and make a status to other folks so that it would allow
 a second run ?
 
 There is already a proposal in Paris for hosting some OpenStack
 sprints, see https://wiki.openstack.org/wiki/Sprints/ParisJuno2014
 
 -Sylvain
 
 
 
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 
 
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 Neutron already has two sprints scheduled:
 https://wiki.openstack.org/wiki/Sprints
 
 Those sprints are both in the US. It is a very long way to travel. If
 there are a group of people that can get together in Europe then it would
 be great.
 
 
 Thanks,
 Anita.
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] Specs repository update and the way forward

[Carlos Gonçalves]

You can see formatted versions (HTML) once Jenkins finishes building.
Open the gate-neutron-specs-docs link provided by Jenkins and browse to the 
blueprint you want to read.

Carlos Goncalves

On 13 Jun 2014, at 04:36, YAMAMOTO Takashi yamam...@valinux.co.jp wrote:

 Since Juno-1 is about to close, I wanted to give everyone an update on
 Neutron's usage of the specs repository. These are observations from
 using this since a few weeks before the Summit. I thought it would be
 good to share with the broader community to see if other projects
 using spec repositories had similar thoughts, and I also wanted to
 share this info for BP submitters and reviewers.
 
 it would be better if there's an easy way for reviewers to
 see formatted versions of specs rather than raw *.rst, especially
 for diagrams.  does other project have such a machinary?
 
 YAMAMOTO Takashi
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][group-based-policy] GP mapping driver

[Carlos Gonçalves]

Hi Sumit,

My concern was related to sharing common configuration information not
between GP drivers but configurations between GP and ML2 (and any other
future plugins). When both are enabled, users need to configure drivers
information (e.g., endpoint, username, password) twice, when applicable
(e.g., when using ODL for ML2 and GP). A common configuration file here
could help, yes.

Thanks,
Carlos Goncalves

On Thu, Jun 12, 2014 at 6:05 PM, Sumit Naiksatam sumitnaiksa...@gmail.com
wrote:

 Hi Carlos,

 I noticed that the point you raised here had not been followed up. So
 if I understand correctly, your concern is related to sharing common
 configuration information between GP drivers, and ML2 mechanism
 drivers (when used in the mapping)? If so, would a common
 configuration file  shared between the two drivers help to address
 this?

 Thanks,
 ~Sumit.

 On Tue, May 27, 2014 at 10:33 AM, Carlos Gonçalves m...@cgoncalves.pt
 wrote:
  Hi,
 
  On 27 May 2014, at 15:55, Mohammad Banikazemi m...@us.ibm.com wrote:
 
  GP like any other Neutron extension can have different implementations.
 Our
  idea has been to have the GP code organized similar to how ML2 and
 mechanism
  drivers are organized, with the possibility of having different drivers
 for
  realizing the GP API. One such driver (analogous to an ML2 mechanism
 driver
  I would say) is the mapping driver that was implemented for the PoC. I
  certainly do not see it as the only implementation. The mapping driver is
  just the driver we used for our PoC implementation in order to gain
  experience in developing such a driver. Hope this clarifies things a bit.
 
 
  The code organisation adopted to implement the PoC for the GP is indeed
 very
  similar to the one ML2 is using. There is one aspect I think GP will hit
  soon if it continues to follow with its current code base where multiple
  (policy) drivers will be available, and as Mohammad putted it as being
  analogous to an ML2 mech driver, but are independent from ML2’s. I’m
  unaware, however, if the following problem has already been brought to
  discussion or not.
 
  From here I see the GP effort going, besides from some code refactoring,
 I'd
  say expanding the supported policy drivers is the next goal. With that
 ODL
  support might next. Now, administrators enabling GP ODL support will
 have to
  configure ODL data twice (host, user, password) in case they’re using
 ODL as
  a ML2 mech driver too, because policy drivers share no information
 between
  ML2 ones. This can become more troublesome if ML2 is configured to load
  multiple mech drivers.
 
  With that said, if it makes any sense, a different implementation should
 be
  considered. One that somehow allows mech drivers living in ML2 umbrella
 to
  be extended; BP [1] [2] may be a first step towards that end, I’m
 guessing.
 
  Thanks,
  Carlos Gonçalves
 
  [1]
 
 https://blueprints.launchpad.net/neutron/+spec/neutron-ml2-mechanismdriver-extensions
  [2] https://review.openstack.org/#/c/89208/
 
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova][neutron][NFV] Mid cycle sprints

[Carlos Gonçalves]

Let me add to what I've said in my previous email, that Instituto de 
Telecomunicacoes and Portugal Telecom are also available to host and organize a 
mid cycle sprint in Lisbon, Portugal.

Please let me know who may be interested in participating.

Thanks,
Carlos Goncalves

On 13 Jun 2014, at 10:45, Carlos Gonçalves m...@cgoncalves.pt wrote:

 Hi,
 
 I like the idea of arranging a mid cycle for Neutron in Europe somewhere in 
 July. I was also considering inviting folks from the OpenStack NFV team to 
 meet up for a F2F kick-off.
 
 I did not know about the sprint being hosted and organised by eNovance in 
 Paris until just now. I think it is a great initiative from eNovance even 
 because it’s not being focused on a specific OpenStack project. So, I'm 
 interested in participating in this sprint for discussing Neutron and NFV. 
 Two more people from Instituto de Telecomunicacoes and Portugal Telecom have 
 shown interested too.
 
 Neutron and NFV team members, who’s interested in meeting in Paris, or if not 
 available on the date set by eNovance in other time and place?
 
 Thanks,
 Carlos Goncalves
 
 On 13 Jun 2014, at 08:42, Sylvain Bauza sba...@redhat.com wrote:
 
 Le 12/06/2014 15:32, Gary Kotton a écrit :
 Hi,
 There is the mid cycle sprint in July for Nova and Neutron. Anyone 
 interested in maybe getting one together in Europe/Middle East around the 
 same dates? If people are willing to come to this part of the world I am 
 sure that we can organize a venue for a few days. Anyone interested. If we 
 can get a quorum then I will be happy to try and arrange things.
 Thanks
 Gary
 
 
 
 Hi Gary,
 
 Wouldn't it be more interesting to have a mid-cycle sprint *before* the Nova 
 one (which is targeted after juno-2) so that we could discuss on some topics 
 and make a status to other folks so that it would allow a second run ?
 
 There is already a proposal in Paris for hosting some OpenStack sprints, see 
 https://wiki.openstack.org/wiki/Sprints/ParisJuno2014
 
 -Sylvain
 
 
 
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova][neutron][NFV] Mid cycle sprints

[Carlos Gonçalves]

Yes, that is true but both are being hosted in the USA. Gary started the email 
thread proposing another sprint but in Europe/Middle East for Nova and Neutron. 
Plus, I also proposed adding the the OpenStack NFV team to the party :-)

On 13 Jun 2014, at 23:05, Anita Kuno ante...@anteaya.info wrote:

 On 06/13/2014 05:58 PM, Carlos Gonçalves wrote:
 Let me add to what I've said in my previous email, that Instituto de 
 Telecomunicacoes and Portugal Telecom are also available to host and 
 organize a mid cycle sprint in Lisbon, Portugal.
 
 Please let me know who may be interested in participating.
 
 Thanks,
 Carlos Goncalves
 
 On 13 Jun 2014, at 10:45, Carlos Gonçalves m...@cgoncalves.pt wrote:
 
 Hi,
 
 I like the idea of arranging a mid cycle for Neutron in Europe somewhere in 
 July. I was also considering inviting folks from the OpenStack NFV team to 
 meet up for a F2F kick-off.
 
 I did not know about the sprint being hosted and organised by eNovance in 
 Paris until just now. I think it is a great initiative from eNovance even 
 because it’s not being focused on a specific OpenStack project. So, I'm 
 interested in participating in this sprint for discussing Neutron and NFV. 
 Two more people from Instituto de Telecomunicacoes and Portugal Telecom 
 have shown interested too.
 
 Neutron and NFV team members, who’s interested in meeting in Paris, or if 
 not available on the date set by eNovance in other time and place?
 
 Thanks,
 Carlos Goncalves
 
 On 13 Jun 2014, at 08:42, Sylvain Bauza sba...@redhat.com wrote:
 
 Le 12/06/2014 15:32, Gary Kotton a écrit :
 Hi,
 There is the mid cycle sprint in July for Nova and Neutron. Anyone 
 interested in maybe getting one together in Europe/Middle East around the 
 same dates? If people are willing to come to this part of the world I am 
 sure that we can organize a venue for a few days. Anyone interested. If 
 we can get a quorum then I will be happy to try and arrange things.
 Thanks
 Gary
 
 
 
 Hi Gary,
 
 Wouldn't it be more interesting to have a mid-cycle sprint *before* the 
 Nova one (which is targeted after juno-2) so that we could discuss on some 
 topics and make a status to other folks so that it would allow a second 
 run ?
 
 There is already a proposal in Paris for hosting some OpenStack sprints, 
 see https://wiki.openstack.org/wiki/Sprints/ParisJuno2014
 
 -Sylvain
 
 
 
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 
 
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 Neutron already has two sprints scheduled:
 https://wiki.openstack.org/wiki/Sprints
 
 Thanks,
 Anita.
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] Specs repository update and the way forward

[Carlos Gonçalves]

Thank you for the update, Kyle.

I was sceptical about this move at first but hopefully I was wrong. The specs 
repository indeed eases a lot of the work from a submitter and reviewer point 
of view.

Is there any web page where all approved blueprints are being published to? 
Jenkins builds such pages I’m looking for but they are linked to each patchset 
individually (e.g., 
http://docs-draft.openstack.org/77/92477/6/check/gate-neutron-specs-docs/f05cc1d/doc/build/html/).
 In addition, listing BPs currently under reviewing and linking to its 
review.o.o page could potentially draw more attention/awareness to what’s being 
proposed to Neutron (and other OpenStack projects).

Thanks,
Carlos Goncalves

On 11 Jun 2014, at 18:25, Kyle Mestery mest...@noironetworks.com wrote:

 tl;dr: The specs repository has been great to work with. As a
 reviewer, it makes reviews easier. As PTL, it makes tracking easier as
 well.
 
 Since Juno-1 is about to close, I wanted to give everyone an update on
 Neutron's usage of the specs repository. These are observations from
 using this since a few weeks before the Summit. I thought it would be
 good to share with the broader community to see if other projects
 using spec repositories had similar thoughts, and I also wanted to
 share this info for BP submitters and reviewers.
 
 Overall, the spec repository has been great as a tool to consolidate
 where new ideas are documented and made into something we can merge
 and move forward with. Using gerrit for this has been great. We've
 merged a good amount of specs [1], and the process of hooking these to
 Launchpad for milestone tracking has been straightforward. As the PTL
 of Neutron, I've found the specs repository helps me out immensely,
 the workflow is great.
 
 One of the things I've noticed is that sometimes it's hard to get
 submitters to respond to feedback on the specs repository. If you look
 at our current queue of open BPs [2], we have a lot which are waiting
 for feedback from submitters. I don't know how to address this issue,
 any feedback appreciated here.
 
 Secondly, with so many open BPs, it's unlikely that all of these will
 make Juno. With what we already have approved and being worked, a lot
 of these will likely slide to the K release. At some point in the
 next few weeks, I may start going through some and marking them as
 such.
 
 So, to summarize, I'm very happy with the workflow from the specs repository.
 
 Thanks for reading!
 Kyle
 
 [1] 
 https://review.openstack.org/#/q/status:merged+project:openstack/neutron-specs,n,z
 [2] 
 https://review.openstack.org/#/q/status:open+project:openstack/neutron-specs,n,z
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [infra] *urgent* Jenkins keeps verifying non-stop

[Carlos Gonçalves]

Hi,

Could someone from the infra team check what's happening to Jenkins here
https://review.openstack.org/#/c/92477/? It keeps re-verifying the change
over and over for no apparent reason.

Thanks,
Carlos Goncalves
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [infra] *urgent* Jenkins keeps verifying non-stop

[Carlos Gonçalves]

I was able to broke the loop by uploading a new patchset to Gerrit.
Infra team, could you please clean the mess caused by Jenkins on Gerrit, please?

Thanks,
Carlos Goncalves

On 19 May 2014, at 07:54, Carlos Gonçalves m...@cgoncalves.pt wrote:

 Hi,
 
 Could someone from the infra team check what's happening to Jenkins here 
 https://review.openstack.org/#/c/92477/? It keeps re-verifying the change 
 over and over for no apparent reason.
 
 Thanks,
 Carlos Goncalves
 

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [infra] *urgent* Jenkins keeps verifying non-stop

[Carlos Gonçalves]

Thanks, James!


On Mon, May 19, 2014 at 9:40 PM, James E. Blair jebl...@openstack.orgwrote:

 Jerry Xinyu Zhao xyzje...@gmail.com writes:

  Better send to infra's list too.
 
 
 
  On Mon, May 19, 2014 at 10:06 AM, Yi Sun beyo...@gmail.com wrote:
 
  More info, I add a follow up comment on an old change set, and then it
  happened.
  Yi
 
 
  On Mon, May 19, 2014 at 2:49 AM, Carlos Gonçalves m...@cgoncalves.pt
 wrote:
 
  I was able to broke the loop by uploading a new patchset to Gerrit.
  Infra team, could you please clean the mess caused by Jenkins on
 Gerrit,
  please?
 
  Thanks,
  Carlos Goncalves
 
  On 19 May 2014, at 07:54, Carlos Gonçalves m...@cgoncalves.pt wrote:
 
  Hi,
 
  Could someone from the infra team check what's happening to Jenkins
 here
  https://review.openstack.org/#/c/92477/? It keeps re-verifying the
  change over and over for no apparent reason.
 
  Thanks,
  Carlos Goncalves

 Thanks.  There was a problem with a behavioral change in the new Gerrit
 and our clean-check implementation in Zuul.  This change and its
 dependency have merged so we don't expect this to happen again:

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

 I manually removed the comments from that change.  Sorry for the
 inconvenience.

 -Jim

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][chaining][policy] Port-oriented Network service chaining

[Carlos Gonçalves]

Hi Kanzhe,

First off, thank you for showing interest in discussing this proposal!

I’m not fully sure if I understood your point. Could you elaborate a bit more 
on the L1, L2, L3 part?

Regarding the traffic steering API, as I see it the Neutron port is the virtual 
counterpart of the network interface and would allow L1, L2 and L3 steering 
within OpenStack.  Within a single OpenStack deployment I think the Neutron 
port abstraction might be enough. Nevertheless in the API data model proposal 
we have the service function end
point abstraction which can (eventually) be mapped to something else than a 
Neutron port (e.g., remote IP).

Thanks,
Carlos Goncalves

On 15 Apr 2014, at 02:07, Kanzhe Jiang kan...@gmail.com wrote:

 Hi Carlos,
 
 This is Kanzhe. We discussed your port-based SFC on the Neutron advanced 
 service IRC.
 I would like to reach out to you to discuss a bit more.
 
 As you know, Neutron port is a logic abstraction for network interfaces with 
 a MAC and IP address. However, network services could be used at different 
 layers, L3, L2, or L1. In L3 case, each service interface could be easily 
 mapped to a Neutron port. However, in the other two cases, there won't be a 
 corresponding Neutron port. In your proposal, you mentioned DPI service. What 
 is your thought?
 
 Neutron doesn't have traffic steering API. Is Neutron port the right 
 abstraction to introduce traffic steering API? Or May Neutron need separate 
 abstraction for such?
 
 Love to discuss more!
 Kanzhe
 
 
 On Tue, Mar 25, 2014 at 3:59 PM, Carlos Gonçalves m...@cgoncalves.pt wrote:
 Hi,
 
 Most of the advanced services and group policy sub-team members who attended 
 last week’s meeting should remember I promised to start a drafting proposal 
 regarding network service chaining. This week I got to start writing a 
 document which is accessible here: 
 https://docs.google.com/document/d/1Bk1e8-diE1VnzlbM8l479Mjx2vKliqdqC_3l5S56ITU
 
 It should not be considered a formal blueprint as it yet requires large 
 discussion from the community wrt the validation (or sanity if you will) of 
 the proposed idea.
 
 I will be joining the advanced service IRC meeting tomorrow, and the group 
 policy IRC meeting thursday, making myself available to answer any questions 
 you may have. In the meantime you can also start discussing in this email 
 thread or commenting in the document.
 
 Thanks,
 Carlos Goncalves
 
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] OpenStack VM Import/Export

[Carlos Gonçalves]

Might be of help to you to know that glance-pythonclient provides an 
‘image-download’ option.
Also, 
https://blueprints.launchpad.net/horizon/+spec/download-images-and-snapshots

On 07 Apr 2014, at 08:06, Saju M sajup...@gmail.com wrote:

 Hi,
 
 Amazon provides option to Import/Export VM.
 http://aws.amazon.com/ec2/vm-import/
 
 does OpenStack has same feature ?
 Have anyone started to implement this in Openstack ?. If yes, Please point me 
 to the blueprint. I would like to work on that.
 
 
 Regards
 Saju Madhavan
 +91 09535134654
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron][chaining][policy] Port-oriented Network service chaining

[Carlos Gonçalves]

Hi,

Most of the advanced services and group policy sub-team members who attended 
last week’s meeting should remember I promised to start a drafting proposal 
regarding network service chaining. This week I got to start writing a document 
which is accessible here: 
https://docs.google.com/document/d/1Bk1e8-diE1VnzlbM8l479Mjx2vKliqdqC_3l5S56ITU

It should not be considered a formal blueprint as it yet requires large 
discussion from the community wrt the validation (or sanity if you will) of the 
proposed idea.

I will be joining the advanced service IRC meeting tomorrow, and the group 
policy IRC meeting thursday, making myself available to answer any questions 
you may have. In the meantime you can also start discussing in this email 
thread or commenting in the document.

Thanks,
Carlos Goncalves

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][policy] Integrating network policies and network services

[Carlos Gonçalves]

Inline comments.

On 15 Mar 2014, at 15:06, Kanzhe Jiang kan...@gmail.com wrote:

 On Fri, Mar 14, 2014 at 3:18 PM, Mohammad Banikazemi m...@us.ibm.com wrote:
 1- This fits ok with the policy model we had developed earlier where the 
 policy would get defined between a source and a destination policy endpoint 
 group. The chain could be instantiated at the time the policy gets defined. 
 (More questions on the instantiation below marked as 1.a and 1.b.) How would 
 that work in a contract based model for policy? At the time a contract is 
 defined, it's producers and consumers are not defined yet. Would we postpone 
 the instantiation of the service chain to the time a contract gets a producer 
 and at least a consumer?
 
 In a contract based model, we can add a state attribute to the service chain. 
 Once a contract is defined, a corresponding chain could be defined without 
 insertion contexts. The chain state is pending. I assume the producer and 
 consumers can be used to derive the source and destination insertion contexts 
 for the chain. Once a contract gets producer and a consumer, the chain can 
 then be instantiated. When new consumers are added, the chain would verify if 
 the new context can be supported before updating the existing contexts. If 
 all producer and consumers are removed from a contract, the chain provider 
 deletes all service instances in the chain.

Exactly. I was about to suggest the same.
 3- For the service chain creation, I am sure there are good reasons for 
 requiring a specific provider for a given chain of services but wouldn't it 
 be possible to have a generic chain provider which would instantiate each 
 service in the chain using the required provider for each service (e.g., 
 firewall or loadbalancer service) and with setting the insertion contexts for 
 each service such that the chain gets constructed as well? I am sure I am 
 ignoring some practical requirements but is it worth rethinking the current 
 approach? 
 
 
 Service Chaining often means a form of traffic steering. Depending on how the 
 steering is done, the capabilities of different providers differ. Different 
 provider may define different context of individual service in the chain. For 
 example, a bump-in-the-wire service can be inserted as a virtual wire or L3 
 next hop. So it will be hard to define a generic chain provider.  

I’m partially with Mohammad on this.

For what I’ve understood from the service chaining proposal, there would be 
different service chain provider implementations with each one restricting to a 
statically defined and limited number of services for chaining (please correct 
me if I’m mistaken). This is, and taking the “Firewall-VPN-ref-Chain” service 
chain provider from the document as example, users would be limited to creating 
chains “firewall - VPN” (and I’m not even considering the restrictiveness of 
service providers) but not “VPN - firewall”, or introducing a LB in the middle.

My rough understanding on chaining, in a broad term, would be to firstly 
support generic L2/L3 chaining, and not restricting to Neutron services (FWaaS, 
LBaaS, VPNaaS) if that is the case, but should also be valid for them as they 
can be reached via network ports as well.

Last week during the advanced services meeting I presented the following use 
case. DPI (Deep Packet Inspection) is an example of a absent Neutron service as 
of now. Users wanting to run a DPI instance in OpenStack would have to create a 
virtual machine and run it there which is fine. Now, in case they want to 
filter inbound traffic from a (public) network, traffic should be steered first 
to the VM running the DPI and then to the final destination. Currently in 
OpenStack it is not possible to configure this and I don’t see how in the 
proposed BP it would be. It was given the example of a DPI, but it can be 
virtually any service type and service implementation. Sure users wouldn’t get 
all the fancy APIs OpenStack providers instantiate and configure services.

Does any of this even make any sense? :-)

On a side note, it may be worth watching one of the two OpenContrail’s videos 
demonstrating their approach on service chain:
- 
http://opencontrail.org/videogallery/elastic-ssl-vpn-service-over-contrail-for-secure-mobile-connectivity/
- 
http://opencontrail.org/videogallery/dynamic-and-elastic-anti-ddos-service-through-contrail-and-ddos-secure/

Thanks,
Carlos Goncalves

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][FWaaS] Rescheduling this week's IRC meeting

[Carlos Gonçalves]

Hi Sumit,

As you being the chairman of the FWaaS meetings, I’d just like to bring to your 
attention in case you’ve missed it that yesterday’s meeting did not get 
recorded by ‘openstack’ MeetBot (my guess is that it was offline?), so there’s 
no logs or minutes archived if someone’s looking for it.

Here’s a kind of minutes of the yesterday's meeting (sincere apologies if you 
feel this is intrusive):

18:07:59  SumitNaiksatam #startmeeting Networking FWaaS
18:08:21  SumitNaiksatam #info the primary agenda for today was the two main 
patches we have in review as of today
18:08:34  SumitNaiksatam #info service insertion and STF
18:10:26  SumitNaiksatam #topic Service Insertion and Firewall
18:10:44  SumitNaiksatam #link https://review.openstack.org/#/c/62599
19:25:12  SumitNaiksatam #action follow up meeting with markmcclain after 
regular neutron IRC on monday
19:25:48  SumitNaiksatam #endmeeting

Thanks,
Carlos Goncalves

On 25 Feb 2014, at 23:49, Sumit Naiksatam sumitnaiksa...@gmail.com wrote:

 Hi, On account of the ongoing RSA conference, some members of our
 neutron firewall sub-team will not be able to attend this Wednesday's
 IRC. So we will have the meeting on Feb 28th (Friday) at 1800 UTC on:
 #openstack-meeting
 
 Hope you can attend.
 
 Thanks,
 ~Sumit.
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron][policy] Blueprint document

[Carlos Gonçalves]

Hi all,

As the blueprint document is write-protected, the “See revision history” option 
is greyed out for viewers-only making it difficult to keep track of changes. 
Hence, and if there is no way as a viewer to see the revision history, could 
someone add me to the document please? My Google ID is carlos.ei.goncalves.

Thanks,
Carlos Goncalves


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Group Policy questions

[Carlos Gonçalves]

Hi,

Firstly, I would like to thank you all for your replies!

I am very much interested in taking some kind of participation on this subject, 
especially on service chain. I’m a entry-level guy on Neutron, but you can 
count on me to discuss and develop these BPs. Besides BP documents, I’ve been 
reading meeting logs and reviewing patches on Gerrit hoping to have a better 
understanding on where the group stands as of now.

My nickname on IRC is (surprise, surprise!) ‘cgoncalves’.

Thanks,
Carlos Goncalves

On 17 Feb 2014, at 07:10, Sumit Naiksatam sumitnaiksa...@gmail.com wrote:

 Hi, Apologies for chiming in late on this. Yes, we have been
 incubating the service insertion and chaining features [2] for some
 time now. The plan was to have a FW-VPN chain working by Icehouse
 release. Towards that end the first step was to introduce the notion
 of a service insertion context which forms the foundation for the
 service chain resource. The following patch aims to address the
 service insertion context:
 https://review.openstack.org/#/c/62599/
 
 and we hope to get the above merged into Icehouse. However, it does
 not seem like we will be able to land the service chaining in
 Icehouse. That said we are hoping to introduce WIP patches soon that
 will implement the ideas so far discussed.
 
 We had regular IRC meetings earlier on the topic of advanced
 services, but we suspended those temporarily so as not to distract
 from the Neutron stabilization and parity work underway in Icehouse.
 We hope to get back to those meetings once the critical bugs and
 features slated for Icehouse are out of the way.
 
 Per your question in the context of the Group Policy work, these two
 features are indeed complementary. As pointed out in this thread, one
 of the options for rendering the Groups Policies is on top of
 elemental Neutron abstractions as service chains expressed in [2].
 Also as pointed out in another email thread, we will specifically
 touch on this topic in the upcoming Group Policy meetings.
 
 Thanks,
 ~Sumit.
 
 
 
 On Wed, Feb 12, 2014 at 10:21 AM, Stephen Wong s3w...@midokura.com wrote:
 Hi Carlos,
 
 
 On Wed, Feb 12, 2014 at 9:37 AM, Carlos Gonçalves m...@cgoncalves.pt
 wrote:
 
 Hi,
 
 I've a couple of questions regarding the ongoing work on Neutron Group
 Policy proposed in [1].
 
 1. One of the described actions is redirection to a service chain. How do
 you see BPs [2] and [3] addressing service chaining? Will this BP implement
 its own service chaining mechanism enforcing traffic steering or will it
 make use of, and thus depending on, those BPs?
 
 
We plan to support both specifying Neutron native service chain
 (reference [2] from your email below) as the object to 'redirect' traffic to
 as well as actually setting an ordered chain of services specified directly
 via the 'redirect' list. In the latter case we would need the plugins to
 perform traffic steering across these services.
 
 
 2. In the second use case presented in the BP document, Tired application
 with service insertion/chaining, do you consider that the two firewalls
 entities can represent the same firewall instance or two running and
 independent instances? In case it's a shared instance, how would it support
 multiple chains? This is, HTTP(s) traffic from Inet group would be
 redirected to the firewall and then passes through the ADC; traffic from App
 group with destination DB group would also be redirected to the very same
 firewall instance, although to a different destination group as the chain
 differs.
 
 
We certainly do not restrict users from setting the same firewall
 instance on two different 'redirect' list - but at this point, since the
 group-policy project has no plan to perform actual configurations for the
 services, it is therefore the users' responsibility to set the rules
 correctly on the firewall instance such that the correct firewall rules will
 be applied for traffic from group A - B as well as group C - D.
 
 - Stephen
 
 
 
 Thanks.
 
 Cheers,
 Carlos Gonçalves
 
 [1]
 https://blueprints.launchpad.net/neutron/+spec/group-based-policy-abstraction
 [2]
 https://blueprints.launchpad.net/neutron/+spec/neutron-services-insertion-chaining-steering
 [3]
 https://blueprints.launchpad.net/neutron/+spec/nfv-and-network-service-chain-implementation
 
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http

[openstack-dev] [Neutron] Group Policy questions

[Carlos Gonçalves]

Hi,

I’ve a couple of questions regarding the ongoing work on Neutron Group Policy 
proposed in [1].

1. One of the described actions is redirection to a service chain. How do you 
see BPs [2] and [3] addressing service chaining? Will this BP implement its own 
service chaining mechanism enforcing traffic steering or will it make use of, 
and thus depending on, those BPs?

2. In the second use case presented in the BP document, “Tired application with 
service insertion/chaining”, do you consider that the two firewalls entities 
can represent the same firewall instance or two running and independent 
instances? In case it’s a shared instance, how would it support multiple 
chains? This is, HTTP(s) traffic from Inet group would be redirected to the 
firewall and then passes through the ADC; traffic from App group with 
destination DB group would also be redirected to the very same firewall 
instance, although to a different destination group as the chain differs.

Thanks.

Cheers,
Carlos Gonçalves

[1] 
https://blueprints.launchpad.net/neutron/+spec/group-based-policy-abstraction
[2] 
https://blueprints.launchpad.net/neutron/+spec/neutron-services-insertion-chaining-steering
[3] 
https://blueprints.launchpad.net/neutron/+spec/nfv-and-network-service-chain-implementation

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev