Re: [openstack-dev] [all] PTL/TC candidate workflow proposal for next elections

2015-08-22 Thread Anita Kuno 
On 08/21/2015 11:02 PM, Joshua Hesketh wrote:
> I'm struggling to think of a way this might help enable discussions between
> nominees and voters about their platforms. Since the tooling will send out
> the nomination announcements the only real noise that is reduced is the
> "nomination confirmed" type emails.
> 
> While I think this sounds really neat, I'm not convinced that it'll
> actually reduce noise on the mailing list if that was the goal. I realise
> the primary goal is to help the election officials, but perhaps we can
> achieve both of these by a separate mailing list for both nomination
> announcements and also platform discussions? This could be a first step and
> then once we have the tooling to confirm a nominees validity we could
> automate that first announcement email still.

Separate repo, separate mailing list, the thing I think we agree on is
separation.

I personally didn't want to get into the tussle that is having a
separate mailing list so thought up separate repo as something that is
different enough it didnt' have a past history of needing to drag in
prior arguments.

It is up to the officials but I definitely agree that tooling/workflow
needs to be adjusted to address the increase in volume of candidates
that will need to be tended to during the upcoming election cycle.

Thanks,
Anita.


> 
> Just a thought anyway.
> 
> Cheers,
> Josh
> 
> On Sat, Aug 22, 2015 at 5:44 AM, Anita Kuno  wrote:
> 
>> On 08/21/2015 03:37 PM, Jeremy Stanley wrote:
>>> On 2015-08-21 14:32:50 -0400 (-0400), Anita Kuno wrote:
 Personally I would recommend that the election officials have
 verification permissions on the proposed repo and the automation
 step is skipped to begin with as a way of expediting the repo
 creation. Getting the workflow in place in enough time that
 potential candidates can familiarize themselves with the change,
 is of primary importance I feel. Automation can happen after the
 workflow is in place.
>>>
>>> Agreed, I'm just curious what our options actually are for
>>> automating the confirmation research currently performed. It's
>>> certainly not a prerequisite for using the new repo/workflow in a
>>> manually-driven capacity in the meantime.
>>>
>>
>> Fair enough. I don't want to answer the question myself as I feel it's
>> best for the response to come from current election officials.
>>
>> Thanks Jeremy,
>> Anita.
>>
>> __
>> 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

Re: [openstack-dev] [all] PTL/TC candidate workflow proposal for next elections

2015-08-22 Thread Anita Kuno 
On 08/22/2015 04:35 PM, Maish Saidel-Keesing wrote:
> +1 To what Joshua said.
> 
> I would also like to understand what is the goal we are trying to
> accomplish by moving this to a repo and submitting a CR and what does
> this solve or improve on the current way we are doing things?

The point when I proposed this workflow last release cycle was to make
the election officials job possible to complete with certainty all
candidates had been acknowledged rather than lost in the noise while
still being able to do the other daily activities the election officials
have to accomplish while being election officials.

Noise on the mailing list? Wasn't a concern for me then and isn't now,
as an interested observer. Making sure the officials can have confidence
in their work? Very important.

Thanks,
Anita.
> 
> Will it reduce noise? marginally (IMHO).
> 
> Maish
> 
> On 08/22/15 06:02, Joshua Hesketh wrote:
>> I'm struggling to think of a way this might help enable discussions
>> between nominees and voters about their platforms. Since the tooling
>> will send out the nomination announcements the only real noise that is
>> reduced is the "nomination confirmed" type emails.
>>
>> While I think this sounds really neat, I'm not convinced that it'll
>> actually reduce noise on the mailing list if that was the goal. I
>> realise the primary goal is to help the election officials, but
>> perhaps we can achieve both of these by a separate mailing list for
>> both nomination announcements and also platform discussions? This
>> could be a first step and then once we have the tooling to confirm a
>> nominees validity we could automate that first announcement email still.
>>
>> Just a thought anyway.
>>
>> Cheers,
>> Josh
>>
>> On Sat, Aug 22, 2015 at 5:44 AM, Anita Kuno > > wrote:
>>
>> On 08/21/2015 03:37 PM, Jeremy Stanley wrote:
>> > On 2015-08-21 14:32:50 -0400 (-0400), Anita Kuno wrote:
>> >> Personally I would recommend that the election officials have
>> >> verification permissions on the proposed repo and the automation
>> >> step is skipped to begin with as a way of expediting the repo
>> >> creation. Getting the workflow in place in enough time that
>> >> potential candidates can familiarize themselves with the change,
>> >> is of primary importance I feel. Automation can happen after the
>> >> workflow is in place.
>> >
>> > Agreed, I'm just curious what our options actually are for
>> > automating the confirmation research currently performed. It's
>> > certainly not a prerequisite for using the new repo/workflow in a
>> > manually-driven capacity in the meantime.
>> >
>>
>> Fair enough. I don't want to answer the question myself as I feel
>> it's
>> best for the response to come from current election officials.
>>
>> Thanks Jeremy,
>> Anita.
>>
> 
> 
> 
> 
> __
> 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] I am pleased to propose two new Neutron API/DB/RPC core reviewers!

2015-08-22 Thread Doug Wiegley 
New guys have to plan the liberty summit get together, right? :)

Doug


> On Aug 22, 2015, at 2:06 PM, Kyle Mestery  wrote:
> 
> It's been over a week, so I'd like to welcome Brandon and Russell to the 
> API/DB/RPC team in Neutron!
> 
> Kyle
> 
>> On Wed, Aug 12, 2015 at 6:45 AM, Kyle Mestery  wrote:
>> It gives me great pleasure to propose Russell Bryant and Brandon Logan as 
>> core reviewers in the API/DB/RPC area of Neutron. Russell and Brandon have 
>> both been incredible contributors to Neutron for a while now. Their 
>> expertise has been particularly helpful in the area they are being proposed 
>> in. Their review stats [1] place them both comfortably in the range of 
>> existing Neutron core reviewers. I expect them to continue working with all 
>> community members to drive Neutron forward for the rest of Liberty and into 
>> Mitaka.
>> 
>> Existing DB/API/RPC core reviewers (and other Neutron core reviewers), 
>> please vote +1/-1 for the addition of Russell and Brandon.
>> 
>> Thanks!
>> Kyle
>> 
>> [1] http://stackalytics.com/report/contribution/neutron-group/90
> 
> __
> 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] [all][release] ACL for library-release team for release:managed projects

2015-08-22 Thread Doug Hellmann 
Excerpts from Dmitry Tantsur's message of 2015-08-22 16:12:44 +0200:
> 2015-08-22 0:25 GMT+02:00 Davanum Srinivas :
> 
> > Folks,
> >
> > In the governance repo a number of libraries are marked with
> > release:managed tag:
> >
> > http://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml
> >
> > However, some of these libraries do not have appropriate ACL in the
> > project:config repo:
> >
> > http://git.openstack.org/cgit/openstack-infra/project-config/tree/gerrit/acls/openstack
> >
> > For example a quick scan shows that the following repos are marked
> > release:managed and do not have the right ACL:
> > python-kiteclient
> > python-designateclient
> > python-ironic-inspector-client
> >
> 
> This patch
> https://github.com/openstack/governance/commit/ecd007e1a21f00828bde49b7dbd3b9ff41b7b18b
> incorrectly added release:managed to python-ironic-inspector-client. It's
> not that I'm against switching to managed releases, but it's not the case
> now (just like for ironic-inspector itself).
> 
> What is a general policy: should we aim for becoming managed or should I
> just drop the wrong tag? Is the procedure for the former outlined somewhere?

It's up to you. The neutron team has us managing some of their
repositories, and not others. If you're comfortable creating releases
yourself, the simplest thing to do is remove the tag. If you'd like to
be included in the release summaries at the end of a cycle, we should
get the ACLs set up properly to let the release team take over creating
the tags. The process for requesting tags under that process is
documented in
http://git.openstack.org/cgit/openstack/releases/tree/README.rst if you
want to review that before making a decision.

Doug

> 
> Thanks!
> 
> > python-manilaclient
> > os-client-config
> > automaton
> > python-zaqarclient
> >
> > So PTL's, either please fix the governance repo to remove release:managed
> > or add appropriate ACL in the project-config repo as documented in:
> > http://docs.openstack.org/infra/manual/creators.html#creation-of-tags
> >
> > Thanks,
> > Dims
> >
> > --
> > 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
> >
> >
> 

__
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][release] ACL for library-release team for release:managed projects

2015-08-22 Thread Doug Hellmann 
Excerpts from Ben Swartzlander's message of 2015-08-21 22:38:59 -0400:
> 
> On 08/21/2015 06:25 PM, Davanum Srinivas wrote:
> > Folks,
> >
> > In the governance repo a number of libraries are marked with 
> > release:managed tag:
> > http://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml
> >
> > However, some of these libraries do not have appropriate ACL in the 
> > project:config repo:
> > http://git.openstack.org/cgit/openstack-infra/project-config/tree/gerrit/acls/openstack
> >
> > For example a quick scan shows that the following repos are marked 
> > release:managed and do not have the right ACL:
> > python-kiteclient
> > python-designateclient
> > python-ironic-inspector-client
> > python-manilaclient
> > os-client-config
> > automaton
> > python-zaqarclient
> >
> > So PTL's, either please fix the governance repo to remove 
> > release:managed or add appropriate ACL in the project-config repo as 
> > documented in:
> > http://docs.openstack.org/infra/manual/creators.html#creation-of-tags
> >
> 
> 
> I'm an offender here (python-manilaclient). I'm happy to make this 
> change but how do I find out about the "library-release" group and the 
> process for pushing tags? Currently I just do it, and I'm happy to move 
> to a more "managed" method but I'd like to know how library releases are 
> managed before I make this change.

The process is documented in the README within the releases repository:

http://git.openstack.org/cgit/openstack/releases/tree/README.rst

We made this change a while back, and I apparently missed some gerrit
ACL files at the time.

Doug

__
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] I am pleased to propose two new Neutron API/DB/RPC core reviewers!

2015-08-22 Thread Edgar Magana 
Welcome to the team!

Cheers,

Edgar


On Aug 22, 2015, at 1:10 PM, Kyle Mestery 
mailto:mest...@mestery.com>> wrote:

It's been over a week, so I'd like to welcome Brandon and Russell to the 
API/DB/RPC team in Neutron!

Kyle

On Wed, Aug 12, 2015 at 6:45 AM, Kyle Mestery 
mailto:mest...@mestery.com>> wrote:
It gives me great pleasure to propose Russell Bryant and Brandon Logan as core 
reviewers in the API/DB/RPC area of Neutron. Russell and Brandon have both been 
incredible contributors to Neutron for a while now. Their expertise has been 
particularly helpful in the area they are being proposed in. Their review stats 
[1] place them both comfortably in the range of existing Neutron core 
reviewers. I expect them to continue working with all community members to 
drive Neutron forward for the rest of Liberty and into Mitaka.

Existing DB/API/RPC core reviewers (and other Neutron core reviewers), please 
vote +1/-1 for the addition of Russell and Brandon.

Thanks!
Kyle

[1] http://stackalytics.com/report/contribution/neutron-group/90

__
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] I am pleased to propose two new Neutron API/DB/RPC core reviewers!

2015-08-22 Thread Madhusudhan Kandadai 
Congrats Brandon and Russel.
On Aug 22, 2015 13:37, "Miguel Lavalle"  wrote:

> Congrats to Russel and Blogan!
>
> On Sat, Aug 22, 2015 at 3:06 PM, Kyle Mestery  wrote:
>
>> It's been over a week, so I'd like to welcome Brandon and Russell to the
>> API/DB/RPC team in Neutron!
>>
>> Kyle
>>
>> On Wed, Aug 12, 2015 at 6:45 AM, Kyle Mestery 
>> wrote:
>>
>>> It gives me great pleasure to propose Russell Bryant and Brandon Logan
>>> as core reviewers in the API/DB/RPC area of Neutron. Russell and Brandon
>>> have both been incredible contributors to Neutron for a while now. Their
>>> expertise has been particularly helpful in the area they are being proposed
>>> in. Their review stats [1] place them both comfortably in the range of
>>> existing Neutron core reviewers. I expect them to continue working with all
>>> community members to drive Neutron forward for the rest of Liberty and into
>>> Mitaka.
>>>
>>> Existing DB/API/RPC core reviewers (and other Neutron core reviewers),
>>> please vote +1/-1 for the addition of Russell and Brandon.
>>>
>>> Thanks!
>>> Kyle
>>>
>>> [1] http://stackalytics.com/report/contribution/neutron-group/90
>>>
>>
>>
>> __
>> 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

Re: [openstack-dev] [neutron] I am pleased to propose two new Neutron API/DB/RPC core reviewers!

2015-08-22 Thread Miguel Lavalle 
Congrats to Russel and Blogan!

On Sat, Aug 22, 2015 at 3:06 PM, Kyle Mestery  wrote:

> It's been over a week, so I'd like to welcome Brandon and Russell to the
> API/DB/RPC team in Neutron!
>
> Kyle
>
> On Wed, Aug 12, 2015 at 6:45 AM, Kyle Mestery  wrote:
>
>> It gives me great pleasure to propose Russell Bryant and Brandon Logan as
>> core reviewers in the API/DB/RPC area of Neutron. Russell and Brandon have
>> both been incredible contributors to Neutron for a while now. Their
>> expertise has been particularly helpful in the area they are being proposed
>> in. Their review stats [1] place them both comfortably in the range of
>> existing Neutron core reviewers. I expect them to continue working with all
>> community members to drive Neutron forward for the rest of Liberty and into
>> Mitaka.
>>
>> Existing DB/API/RPC core reviewers (and other Neutron core reviewers),
>> please vote +1/-1 for the addition of Russell and Brandon.
>>
>> Thanks!
>> Kyle
>>
>> [1] http://stackalytics.com/report/contribution/neutron-group/90
>>
>
>
> __
> 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] [all] PTL/TC candidate workflow proposal for next elections

2015-08-22 Thread Maish Saidel-Keesing 

+1 To what Joshua said.

I would also like to understand what is the goal we are trying to 
accomplish by moving this to a repo and submitting a CR and what does 
this solve or improve on the current way we are doing things?


Will it reduce noise? marginally (IMHO).

Maish

On 08/22/15 06:02, Joshua Hesketh wrote:
I'm struggling to think of a way this might help enable discussions 
between nominees and voters about their platforms. Since the tooling 
will send out the nomination announcements the only real noise that is 
reduced is the "nomination confirmed" type emails.


While I think this sounds really neat, I'm not convinced that it'll 
actually reduce noise on the mailing list if that was the goal. I 
realise the primary goal is to help the election officials, but 
perhaps we can achieve both of these by a separate mailing list for 
both nomination announcements and also platform discussions? This 
could be a first step and then once we have the tooling to confirm a 
nominees validity we could automate that first announcement email still.


Just a thought anyway.

Cheers,
Josh

On Sat, Aug 22, 2015 at 5:44 AM, Anita Kuno > wrote:


On 08/21/2015 03:37 PM, Jeremy Stanley wrote:
> On 2015-08-21 14:32:50 -0400 (-0400), Anita Kuno wrote:
>> Personally I would recommend that the election officials have
>> verification permissions on the proposed repo and the automation
>> step is skipped to begin with as a way of expediting the repo
>> creation. Getting the workflow in place in enough time that
>> potential candidates can familiarize themselves with the change,
>> is of primary importance I feel. Automation can happen after the
>> workflow is in place.
>
> Agreed, I'm just curious what our options actually are for
> automating the confirmation research currently performed. It's
> certainly not a prerequisite for using the new repo/workflow in a
> manually-driven capacity in the meantime.
>

Fair enough. I don't want to answer the question myself as I feel it's
best for the response to come from current election officials.

Thanks Jeremy,
Anita.



__
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] I am pleased to propose two new Neutron API/DB/RPC core reviewers!

2015-08-22 Thread Kyle Mestery 
It's been over a week, so I'd like to welcome Brandon and Russell to the
API/DB/RPC team in Neutron!

Kyle

On Wed, Aug 12, 2015 at 6:45 AM, Kyle Mestery  wrote:

> It gives me great pleasure to propose Russell Bryant and Brandon Logan as
> core reviewers in the API/DB/RPC area of Neutron. Russell and Brandon have
> both been incredible contributors to Neutron for a while now. Their
> expertise has been particularly helpful in the area they are being proposed
> in. Their review stats [1] place them both comfortably in the range of
> existing Neutron core reviewers. I expect them to continue working with all
> community members to drive Neutron forward for the rest of Liberty and into
> Mitaka.
>
> Existing DB/API/RPC core reviewers (and other Neutron core reviewers),
> please vote +1/-1 for the addition of Russell and Brandon.
>
> Thanks!
> Kyle
>
> [1] http://stackalytics.com/report/contribution/neutron-group/90
>
__
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] netaddr and abbreviated CIDR format

2015-08-22 Thread Sean M. Collins 
On August 22, 2015 11:58:03 AM EDT, Monty Taylor  wrote:
>On 08/21/2015 03:33 PM, Jay Pipes wrote:
>> On 08/21/2015 02:34 PM, Sean M. Collins wrote:
>>> So - the tl;dr is that I don't think that we should accept inputs
>like
>>> the following:
>>>
>>> x   -> 192
>>> x/y -> 10/8
>>> x.x/y   -> 192.168/16
>>> x.x.x/y -> 192.168.0/24
>>>
>>> which are equivalent to::
>>>
>>> x.0.0.0/y   -> 192.0.0.0/24
>>> x.0.0.0/y   -> 10.0.0.0/8
>>> x.x.0.0/y   -> 192.168.0.0/16
>>> x.x.x.0/y   -> 192.168.0.0/24
>> 
>> Agreed completely.
>
>++
>
>
>__
>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

I've got a proof of concept patch for netaddr, I'll be reaching out to the 
netaddr devs and use it to spur discussion.

https://github.com/sc68cal/netaddr/commit/7ccbfe40fe6be66228601977ded74781cf5cffd9


-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.__
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][bgpvpn] Service Plugin vs Service driver

2015-08-22 Thread Kevin Benton 
>I am in favor not to go for a least common denominator approach with the
bgpvpn API. The API should cover the use case commonly acknowledged as
useful and which are supported by at least one of the existing back-ends,
with the aim to have various back-ends to grow in support coverage.

So then what is the goal of the bgpvpn project if every vendor-specific
feature will be allowed through? Rather than being a generic way to setup
BGP VPNs, it sounds to me like it will just become an HTTP proxy with
Keystone authentication to vendor APIs.
On Aug 21, 2015 11:26 PM, "Jan Scheurich" 
wrote:

> Hi all,
>
> I am in favor not to go for a least common denominator approach with the
> bgpvpn API. The API should cover the use case commonly acknowledged as
> useful and which are supported by at least one of the existing back-ends,
> with the aim to have various back-ends to grow in support coverage.
>
> Not supported features of the API could either be rejected by drivers, or
> a fallback behavior can be specified on API level in case a specific
> non-vital
> attribute is not supported by a backend (e.g. in the case of the RD).
>
> My preference would be to stick to the provider framework and to allow
> most backend-specific drivers to profit from the boilerplate code in the
> service plugin.
>
> BTW: The ODL plugin is planned to support both Network and Router
> association and the RD attribute will not be a mandatory attribute for
> the ODL back-end.
>
> Regards,
> Jan
>
>
> Mathieu Rohon Wed, 19 Aug 2015 06:46:45 -0700
> Hi,
>
> thanks for your reply irena and salvatore.
>
> Currently, we're targeting 4 backends : bagpipe (the ref impelmentations
> compatible with other ref implementations of neutron), ODL, contrail and
> nuage.
> Contrail and bagpipe work with networks attachments to a bgpvpn connection,
> while ODL and Nuage work with routers attachments. We even start thinking
> about port attachments [1]
> Moreover, ODL needs a RD attribute that won't be supported by other
> backends.
>
> I think that each backend should be able to manage each kind of attachment
> in the future, depending on the will of the backend dev team. But in a
> firts step, we have to manage the capacity of each backend.
>
> So, indeed, the managment of attachments to a bgpvpn connection through the
> use of extensions will expose backend capacity. And I agree that it's not
> the good way, since when moving from one cloud to another, the API will
> change depending on the backend.
>
> So I see two ways to solve this issue :
> 1-In first releases, backends that don't support a feature will through a
> '"NotImplemented" exception when the feature will be called through the
> API; We still have an inconsistent API, but hopefully, this gone be
> temporary.
> 2-reducing the scope of the spec [2] and having less compatible backends,
> and a smaller community for the bgpvpn project.
>
> [1]https://blueprints.launchpad.net/bgpvpn/+spec/port-association
> [2]https://review.openstack.org/#/c/177740/
>
> regards,
>
> Mathieu
>
>
> __
> 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] [nova] feedback from the ops mid cycle summit

2015-08-22 Thread Tim Bell 
> -Original Message-
> From: melanie witt [mailto:melwi...@gmail.com]
> Sent: 21 August 2015 02:02
> To: OpenStack Development Mailing List (not for usage questions)
> 
> Subject: [openstack-dev] [nova] feedback from the ops mid cycle summit
> 
> Hi Everyone,
> 
> I attended the ops mid cycle summit on Tuesday and Wednesday and here
> are brief notes on the feedback I heard related to nova. Please feel free to
> add your comments or correct me if I got anything wrong.
> 
> 
> Large Deployments Session [1]:
...
> - Cells v2 not coming along as quickly as expected. Cells v1 issues around
> compat between versions, understood it's not supported but it's been a
> problem
> - Hierarchical multi-tenancy isn't yet supported (quotas)
> 

The current status of the HMT work is that it is awaiting reviews 
(https://blueprints.launchpad.net/nova/+spec/nested-quota-driver-api). It was 
not accepted for an exception for Liberty.

It would be great if we can get the HMT function merged the next release (as 
some big operators and partner networks are very interested to delegate this 
function to their user communities) but I do not know if this is on the 
priority list for Nova.

Tim

> 
> Upgrades Session Report:
> - Good linking of features to documentation is important
> - Inter-service changes are important to call out
> - Flavor migration is an example of something done well
> 
> 
> Other general notes:
> - Event capture is a choice between two bad options
> - Information divided between events and logs. Have to capture both or you
> lose the whole picture
> - Hard to trace RPC calls
> - Race conditions with scheduling and quotas
> - The state of Nova and NUMA is not understood
> - Glance v2 is not being used. From what I understand, we can't move to it
> because images created by v1 can't be read by v2, for example?
> 
> 
> All of the etherpads from the event are linked here:
> https://etherpad.openstack.org/p/PAO-ops-meetup
> 
> 
> Thanks,
> -melanie (irc: melwitt)
> 
> 
> [1] https://etherpad.openstack.org/p/PAO-ops-large-deployments
> [2] https://review.openstack.org/#/c/196812/


__
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] netaddr and abbreviated CIDR format

2015-08-22 Thread Monty Taylor 
On 08/21/2015 03:33 PM, Jay Pipes wrote:
> On 08/21/2015 02:34 PM, Sean M. Collins wrote:
>> So - the tl;dr is that I don't think that we should accept inputs like
>> the following:
>>
>> x   -> 192
>> x/y -> 10/8
>> x.x/y   -> 192.168/16
>> x.x.x/y -> 192.168.0/24
>>
>> which are equivalent to::
>>
>> x.0.0.0/y   -> 192.0.0.0/24
>> x.0.0.0/y   -> 10.0.0.0/8
>> x.x.0.0/y   -> 192.168.0.0/16
>> x.x.x.0/y   -> 192.168.0.0/24
> 
> Agreed completely.

++


__
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] [nova][cinder] Extending attached disks

2015-08-22 Thread Jay Bryant 
Taylor,

I am adding some IBMers who are also looking into making this work. PowerVC
has a solution hacked into place but we are working on getting a more
general solution implemented for Mitaka. Hoping we can all work together to
get a solution in place.

Will you be in Tokyo? If so, it would be good to have a plan together to
discuss there.

Gerald and Sam,

Can you guys join the OpenStack dev mailing list and continue the
discussion?

Thanks!
Jay

On Fri, Aug 21, 2015 at 8:20 PM  wrote:

> For RBDs it IS as simple as making calls to virsh after an attached volume
> is extended. I've done it half a dozen time with no intermediate steps and
> it works. I'd love to test it more robustly, obviously, but unfortunately I
> got bigger fish to fry with BAU.
>
> iSCSI might involve more work, I acknowledge that, but there is nothing
> wrong with putting the framework in place now and throwing an "unsupported
> volume type" error message if we haven't worked out the best method for
> doing this for a particular type.
>
> The way I see it, the only ones that are going to cause us problems are
> ones that require the host to suspend the disk prior to operating on it. In
> other words if the notification to the host can't be done atomically, that
> could definitely cause issues.
>
> However, all the examples I have seem implemented in OpenStack volumes
> thus far (iSCSI, RDB) are either atomic or no notification required (in the
> case of RBD). Even Multipath is atomic (granted, it's multiple chained
> atomic operations, but still, they won't be left in an irrecoverable
> failure state).
>
> Yes, the page you linked does warn about the issue when there is no path
> the device, however I think that if you're trying to resize a volume the
> compute node can't connect to, you got bigger problems (that is to say,
> throwing an error here is perfectly reasonable).
>
> Regards,
>
> Taylor Bertie
> Enterprise Support Infrastructure Engineer
>
> Mobile +64 27 952 3949
> Phone +64 4 462 5030
> Email taylor.ber...@solnet.co.nz
>
> Solnet Solutions Limited
> Level 12, Solnet House
> 70 The Terrace, Wellington 6011
> PO Box 397, Wellington 6140
>
> www.solnet.co.nz
>
>
> -"Walter A. Boring IV"  wrote: -
> To: openstack-dev@lists.openstack.org
> From: "Walter A. Boring IV" 
> Date: 2015-08-22 7:13
> Subject: Re: [openstack-dev] [nova][cinder] Extending attached disks
>
> This isn't as simple as making calls to virsh after an attached volume
> is extended on the cinder backend, especially when multipath is involved.
> You need the host system to understand that the volume has changed size
> first, or virsh will really never see it.
>
> For iSCSI/FC volumes you need to issue a rescan on the bus (iSCSI
> session, FC fabric),  and then when multipath is involved, it gets quite
> a bit more complex.
>
> This lead to one of the sticking points with doing this at all, is
> because when cinder extends the volume, it needs to tell nova that it
> has happened, and the nova (or something on the compute node), will have
> to issue the correct commands in sequence for it all to work.
>
> You'll also have to consider multi-attached volumes as well, which adds
> yet another wrinkle.
>
> A good quick source of some of the commands and procedures that are
> needed you can see here:
>
> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/5/html/Online_Storage_Reconfiguration_Guide/online-logical-units.html
>
>
> You can see that volumes with multipath requires a lot of hand holding
> to be done correctly.  It's non trivial.  I see this as being very error
> prone, and any failure
> in the multipath process could lead to big problems :(
>
> Walt
> > Hi everyone,
> >
> > Apologises for the duplicate send, looks like my mail client doesn't
> create very clean HTML messages. Here is the message in plain-text. I'll
> make sure to send to the list in plain-text from now on.
> >
> > In my current pre-production deployment we were looking for a method to
> live extend attached volumes to an instance. This was one of the
> requirements for deployment. I've worked with libvirt hypervisors before so
> it didn't take long to find a workable solution. However I'm not sure how
> transferable this will be across deployment models. Our deployment model is
> using libvirt for nova and ceph for backend storage. This means obviously
> libvirt is using rdb to connect to volumes.
> >
> > Currently the method I use is:
> >
> > - Force cinder to run an extend operation.
> > - Tell Libvirt that the attached disk has been extended.
> >
> > It would be worth discussing if this can be ported to upstream such that
> the API can handle the leg work, rather than this current manual method.
> >
> > Detailed instructions.
> > You will need: volume-id of volume you want to resize,
> hypervisor_hostname and instance_name from instance volume is attached to.
> >
> > Example: extending volume f9fa66ab-b29a-40f6-b4f4-e9c64a155738 attached
> to instance-000

Re: [openstack-dev] [all][release] ACL for library-release team for release:managed projects

2015-08-22 Thread Dmitry Tantsur 
2015-08-22 0:25 GMT+02:00 Davanum Srinivas :

> Folks,
>
> In the governance repo a number of libraries are marked with
> release:managed tag:
>
> http://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml
>
> However, some of these libraries do not have appropriate ACL in the
> project:config repo:
>
> http://git.openstack.org/cgit/openstack-infra/project-config/tree/gerrit/acls/openstack
>
> For example a quick scan shows that the following repos are marked
> release:managed and do not have the right ACL:
> python-kiteclient
> python-designateclient
> python-ironic-inspector-client
>

This patch
https://github.com/openstack/governance/commit/ecd007e1a21f00828bde49b7dbd3b9ff41b7b18b
incorrectly added release:managed to python-ironic-inspector-client. It's
not that I'm against switching to managed releases, but it's not the case
now (just like for ironic-inspector itself).

What is a general policy: should we aim for becoming managed or should I
just drop the wrong tag? Is the procedure for the former outlined somewhere?

Thanks!


> python-manilaclient
> os-client-config
> automaton
> python-zaqarclient
>
> So PTL's, either please fix the governance repo to remove release:managed
> or add appropriate ACL in the project-config repo as documented in:
> http://docs.openstack.org/infra/manual/creators.html#creation-of-tags
>
> Thanks,
> Dims
>
> --
> 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
>
>


-- 
--
-- Dmitry Tantsur
--
__
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] netaddr and abbreviated CIDR format

2015-08-22 Thread shihanzhang 
there was another patch [1] fix the invalid CIDR for subnet.
 
thanks,
   hanzhang, shi


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


At 2015-08-22 03:33:26, "Jay Pipes"  wrote:
>On 08/21/2015 02:34 PM, Sean M. Collins wrote:
>> So - the tl;dr is that I don't think that we should accept inputs like
>> the following:
>>
>> x   -> 192
>> x/y -> 10/8
>> x.x/y   -> 192.168/16
>> x.x.x/y -> 192.168.0/24
>>
>> which are equivalent to::
>>
>> x.0.0.0/y   -> 192.0.0.0/24
>> x.0.0.0/y   -> 10.0.0.0/8
>> x.x.0.0/y   -> 192.168.0.0/16
>> x.x.x.0/y   -> 192.168.0.0/24
>
>Agreed completely.
>
>Best,
>-jay
>
>__
>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] Expected cli behavior when ovs-agent is down

2015-08-22 Thread shihanzhang 
hi Vikas Choudhary, when ovs-agent service recover(ovs-agent process restart), 
the dhcp port will not re-binding successfully?





At 2015-08-22 14:26:08, "Vikas Choudhary"  wrote:

Hi Everybody,


I want to discuss on https://bugs.launchpad.net/neutron/+bug/1348589.This is 
there for more than a year and no discussion i could find on this.


Scenario:
ovs-agent is down and then a network and subnet under this newly created 
network are created using cli. No error visible to user, but following 
irregularities are found.


Discrepancies:
1. neutron port-show  shows:
 binding:vif_type  | binding_failed
2. Running "ovs-ofctl dump-flows br-tun", no of-flow got added
3. Running "ovs-vsctl show br-int", no tag for dhcp-port. 


neutron db will have all the attributes required to retry vif binding.My query 
is when should we trigger this rebinding.Two approaches i could think of are:
1> At neutron server restart, for all ports with vif_type as  "binding_failed" 
plugins/ml2/drivers/mech_agent.bind_port can be invoked as a sync up activity.


2> In neutron port update api, 
http://developer.openstack.org/api-ref-networking-v2-ext.html , could be 
enhanced to receive vif binding related options also and then eventually 
plugins/ml2/drivers/mech_agent.bind_port can be invoked.Corresponding changes 
will be made to 'port update cli' also.


Please suggest.__
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][SR-IOV]How to assign VF to a VM?

2015-08-22 Thread Moshe Levi 
Vxlan is not supported in SR-IOV and flat network should work from Kilo see 
commit[1]

Like I said you need to check your physical_device_mappings is correct can you 
post your
Did you put your agent config in /etc/neutron/conf.d/neutron-sriov-nic-agent?
So on the compute node you should do the following:
Create - /etc/neutron/conf.d/neutron-sriov-nic-agent/ml2_sriov.conf
And put the content
[securitygroup]
firewall_driver = neutron.agent.firewall.NoopFirewallDriver
[sriov_nic]
physical_device_mappings = physnet1:eth1
This will make only the agent to use firewall_driver = 
neutron.agent.firewall.NoopFirewallDriver
Also make sure physical_device_mappings is configure correctly

Please Note that the physnet1 in physical_device_mappings should be also 
appears in the nova.conf
pci_passthrough_whitelist = 
{"address":"*:0a:00.*","physical_network":"physnet1"}

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


From: 于洁 [mailto:16189...@qq.com]
Sent: Saturday, August 22, 2015 5:47 AM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: [openstack-dev] 回复： [Neutron][SR-IOV]How to assign VF to a VM?

Thanks Moshe,
Referring to https://wiki.openstack.org/wiki/SR-IOV-Passthrough-For-Networking, 
it has the note:
Note:SR-IOV agent only work with NoopFirewallDriver when Security Groups are 
enabled, but you can still use other firewall_driver for other Agents by 
updating their conf with the requested firewall driver.
So I think linux.iptables_firewall.OVSHybridIptabl maybe not the issue.

[root@compute ~]# ps -ef|grep neutron-sriov
root 28672 26639  0 22:45 pts/000:00:00 grep --color=auto neutron-sriov
neutron  30891 1  0 05:21 ?00:01:41 /usr/bin/python2 
/usr/bin/neutron-sriov-nic-agent --config-file 
/usr/share/neutron/neutron-dist.conf --config-file /etc/neutron/neutron.conf 
--config-dir /etc/neutron/conf.d/neutron-sriov-nic-agent --config-file 
/etc/neutron/plugins/ml2/ml2_conf_sriov.ini --log-file 
/var/log/neutron/sriov-nic-agent.log

I will have a try of vlan and vxlan.

Thank you,
Yu


-- 原始邮件 --
发件人: "Moshe Levi";mailto:mosh...@mellanox.com>>;
发送时间: 2015年8月21日(星期五) 下午5:15
收件人: "OpenStack Development Mailing List (not for usage 
questions)"mailto:openstack-dev@lists.openstack.org>>;
 
"openstack-operators"mailto:openstack-operat...@lists.openstack.org>>;
主题: Re: [openstack-dev] [Neutron][SR-IOV]How to assign VF to a VM?

The problem is the sriov mechanism drive failed to bind the port.

For the log I see that you are working with agent_required=True, but the device 
mapping is empty {u'devices': 0, u'device_mappings': {}
Please check the agent configuration file see that you have the following
[securitygroup]
firewall_driver = neutron.agent.firewall.NoopFirewallDriver
[sriov_nic]
physical_device_mappings = physnet1:eth1
exclude_devices =

also can you send the output of “ps �Cef | grep neutron-sriov-nic-agent” 
command?



From: 于洁 [mailto:16189...@qq.com]
Sent: Friday, August 21, 2015 12:01 PM
To: openstack-operators 
mailto:openstack-operat...@lists.openstack.org>>;
 openstack-dev 
mailto:openstack-dev@lists.openstack.org>>
Subject: [openstack-dev] [Neutron][SR-IOV]How to assign VF to a VM?

Hi all,

I try to configure SRIOV on OpenStack Kilo referring the information below.
http://www.qlogic.com/solutions/Documents/UsersGuide_OpenStack_SR-IOV.pdf
https://wiki.openstack.org/wiki/SR-IOV-Passthrough-For-Networking

Until creating port it works well. But after creating VM using the port created 
before, it was in the state of ERROR. Below is the port information:
neutron port-show 620187c5-b4ac-4aca-bdeb-96205503344d
+---+--+
| Field | Value 
   |
+---+--+
| admin_state_up| True  
   |
| allowed_address_pairs |   
   |
| binding:host_id   | compute   
   |
| binding:profile   | {"pci_slot": ":09:11.5", "physical_network": 
"external", "pci_vendor_info": "8086:1520"} |
| binding:vif_details   | {}
   |
| binding:vif_type  | binding_failed
   |
| binding:vnic_type | direct
   |
| device_id | baab9ba5-80e8-45f7-b86a-8ac3ce8ba944  
   |
| de