Re: [openstack-dev] [neutron] enriching port binding extension API dictionaries with key-values

[Andreas Scheuring]

Kevin, you're right. My use case is that the plugin enriches the vif
binding information. The value is generated along the ml2 agents
configuration files (the name of the interface to plug the port to).
There's no input coming from the user via API.

Irina, thanks for clarification. binding:vif_details is exactly what I
need!

Thanks, Andreas
(IRC: scheuran)

On Fr, 2015-06-26 at 11:18 -0600, Kevin Benton wrote:
> That bug is about adding things that the user can pass to the port. I
> think Andreas is just talking about passing data to Nova that his ML2
> plugin generates. The key difference would be that adding key/value
> pairs to the port API that the user populates would be exposing
> implementation details to users.
> 
> 
> An ML2 driver adding data to the binding information that a Nova VIF
> driver leverages shouldn't be a problem because the user API
> interaction wouldn't change.
> 
> On Fri, Jun 26, 2015 at 8:14 AM, Neil Jerram
>  wrote:
> Hi Andreas,
> 
> On 26/06/15 14:04, Andreas Scheuring wrote:
> Hi together,
> for a new ml2 plugin I would like to pass over some
> data from neutron to
> nova on port creation and update (exploiting port
> binding extension
> [1]). For my prototype I thought of using one of the
> following response
> dictionaries to add my information:
> 
> - binding:vif_details
> - binding:profile
> 
> The API ref describes these attributes (port create /
> port update - both
> response) as dictionaries, but without restricting the
> key-value pairs
> or naming a defined number [1].
> 
> I've also seen some other ml2 plugins enriching those
> fields with unique
> data. So I assuming this is not considered as an API
> change, isn't it?
> 
> Important: It's only about the response. The input
> comes from a
> configuration file.
> 
> 
> Thanks
> 
> 
> [1]
> http://developer.openstack.org/api-ref-networking-v2-ext.html
> 
> I think the discussion at [1] is broadly in the same area, so
> you might find some relevant input there.
> 
> Neil
> 
> 
> [1] https://bugs.launchpad.net/neutron/+bug/1460222
> 
> 
> 
> __
> 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
> 
> 
> 
> 
> 
> -- 
> Kevin Benton
> __
> 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

-- 
Andreas
(IRC: scheuran)



__
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] [QOS] Request for Additional QoS capabilities

[Adam Lawson]

If fwaas code is at the router level, it would seem that null routing might
be one method of handling ddos, making fwaas a potentially suitable
program. Qos seems to address quality issues rather than focusing on
protection from unauthorized or malicious traffic whether that traffic
originates from the inside or externally. That seems again, to me, as a
fwaas-centric function.

Just my two cents. ;)
On Jun 28, 2015 6:19 PM, "John Joyce (joycej)"  wrote:

>  Gal:
>
>  I am also slow to jump between this and other work so I think I
> should be the one apologizing.  I think we are receptive to any of the
> approaches QoS, FWaaS or Security Groups.  I am not an expert on FWaaS but
> from a quick look it seemed like the FWaaS granularity was at the router
> level.  We would want this per neutron port (e.g. per VM port although
> don’t want to limit the possibility for this be per container or per bare
> metal port).   Allowing an aggregate across all ports of the VM would be
> very nice,  but not a strict requirement.   Do you see this as an issue
> going the FWaaS route?   Have you been making any headway getting it in
> there?
>
>  One detailed comment after looking through the reviews.   Would there
> be any issue in adding a “reject-with-tcp-reset” option?
>
> The DDOS coming from a VM could be due to a virus within the VM our
> maybe just an overly aggressive tenant.  I know the team that runs our
> cloud offering has experienced an excessive connection requests coming from
> a VM.   I can try to get the exact scenario that triggered this.   The net
> is that all tenants on that host can be affected,  especially with an OVS
> based vswitch.
>
>  John
>
>
>
>
>
>
>
>
>
>
>
> *From:* Gal Sagie [mailto:gal.sa...@gmail.com]
> *Sent:* Tuesday, June 23, 2015 2:43 PM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Cc:* lionel.zer...@huawei.com; Derek Chamorro (dechamor); Eran Gampel
> *Subject:* Re: [openstack-dev] [Neutron] [QOS] Request for Additional QoS
> capabilities
>
>
>
> Hi John,
>
>
>
> Sorry for the delayed response as i was on vacation with no internet
> connection (you don't know how much
>
> you miss it until you don't have it).
>
>
>
> The work in terms of coding is pretty much done for the reference
> implementation.
>
> We initially tried to push it as a security group extension but there is a
> strong objection
>
> to change the security group API, so FWaaS can be next best candidate if
> we can find support
>
> or other uses of this (like your use case)
>
> (Of course that work will need to be added for supporting the connection
> limit, we tried
>
> to  tackle brute force prevention which i personally see as a more
> concerning attack vector internally)
>
>
>
> Out of curiosity can you describe scenarios of DDoS attacking from an
> internal VM ?
>
> I would assume most DDoS will happen from external traffic or a combine
> attack from various internal
>
> VM's (and then this might no longer fit as a QoS)
>
>
>
> But if you feel this belongs in QoS this can certainly be added on top of
> the framework as Miguel suggested.
>
>
>
> Thanks
>
> Gal.
>
>
>
> On Fri, Jun 19, 2015 at 12:39 AM, John Joyce (joycej) 
> wrote:
>
> Gal:
>
>   I had seen the brute force blueprint and noticed how close the use
> case was.  Can you tell me the current status of the work?  Do you feel
> confident it can get into Liberty?  Ideally, we think this fits better with
> QoS.  Also I don’t think of it as providing FWaaS as we see that all VMs
> would be protected by this when enabled, but maybe that is just
> terminology.   We think these protections are critical so we are more
> concerned with having the ability to protect against these cases than the
> specific API or service it falls under.  Yes we would be interested in
> working together to get this pushed through.
>
>
> John
>
>
>
> *From:* Gal Sagie [mailto:gal.sa...@gmail.com]
> *Sent:* Wednesday, June 17, 2015 12:45 PM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Cc:* lionel.zer...@huawei.com; Derek Chamorro (dechamor); Eran Gampel
> *Subject:* Re: [openstack-dev] [Neutron] [QOS] Request for Additional QoS
> capabilities
>
>
>
> Hi John,
>
>
>
> We were trying to push a very similar spec to enhance the security group
> API, we covered both DDoS case
>
> and another use case for brute force prevention (We did a research to
> identify common protocols login behaviour
>
> in order to identify brute force attacks using iptables) and even some UI
> work
>
>
>
> You can view the specs and implementations here:
>
> 1) https://review.openstack.org/#/c/184243/
>
> 2) https://review.openstack.org/#/c/154535/
>
> 3) https://review.openstack.org/#/c/151247/
>
> 4) https://review.openstack.org/#/c/161207/
>
>
>
> The spec didn't got approved as there is a strong opinion to keep the
> security group API compatible with Amazon.
>
> I think this and your request fits much more into the FWaaS and if thi

[openstack-dev] [all]deprecating [test-]requirements-PYN.txt

[Robert Collins]

Hi, so we're nearly ready to deprecate the python-version-specific
requirements files. Once we have infra's requirements cross checking
jobs all copacetic again, we should be able to move forward.

There isn't a specific spec for this in pbr, and I wanted to get some
broad input into the manner of the deprecation.

As a reminder, for context, we have several bits of context to consider.

Firstly, we're aligning with upstream packaging precepts, so we want
to remove all non-deployment-specific usage of requirements.txt and
similar files.

Secondly, the Python version specific files are incompatible with
universal wheels, which are desirable because our infrastructure only
knows how to build one wheel when a tag is made, and its less
redundant downloads for users with multiple python versions.

Thirdly, we can't do any backwards incompatible changes in pbr without
breaking any existing users of $thing. Because we're a setup_requires,
and setuptools can't handle version dependencies of setup_requires. So
whatever we do will affect all stable branches immediately, in all
gate jobs.

I think we should do three things:
 - error if universal builds are requested and python versioned
requirements files are present.
 - warn on stdout if versioned requirements files are present
 - start reflecting the 'test' extra into tests_require in the setup_kwargs

The downside of this is that it will warn indefinitely for existing
stable branches. But I think that that is tolerable. If its not, we
could write a timestamp somewhere and only warn once/day, but I think
that that is likely to lead to confusion, not clarity.

-Rob
-- 
Robert Collins 
Distinguished Technologist
HP Converged Cloud

__
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] Any other downstream developers having problems with pbr?

[Robert Collins]

On 26 June 2015 at 23:01, Matthew Booth  wrote:
> I wrote this:
>
> https://review.openstack.org/#/c/195983/1/tools/de-pbr.py,cm
>
> Ideally we'd fix PBR, but this seems to be expected behaviour. Thoughts?

Hi Matt, thanks for raising this. We've had very mixed results trying
to figure out what issues distribution packagers are having with pbr -
we have a couple of mechanisms already for them:
 - you can tag - a tagged commit has the version of the tag
 - you can use PBR_VERSION (per
http://docs.openstack.org/developer/pbr/packagers.html)

The error you complain about in that review is saying that that config
file specifies a version number that *cannot* be satisfied.

Versions have to increase, they can't go backwards. There are several
things that could combine to create this contradiction: for instance,
say you have two commits, B the most recent commit and A the commit
before it. There's also a tag 2014.1.4 that points at A.

B cannot have a version lower than 2014.1.5: because if B had a
version of 2014.1.4, the tag pointing at A would be false. If B had a
version of 2014.1.4a1 or anything like that, B would have a lower
version than A.

But the config file in nova at the time this error was raised says
'The version of the next release WILL BE 2014.1.4'. Thus PBR has been
given contradictory instructions, and throws its hands up in the air.

We could perhaps instead just *ignore* setup.cfg's version line. That
would mean that you'd get 2014.1.5, but this would be very surprising
to folk that have been putting versions in setup.cfg, so we didn't do
that. I don't know if that would solve the issue you were having.

We could remove the version = line from setup.cfg's across the board,
and Doug and Thierry are considering that.

The pbr team (loosely oslo+infra) are very open to discussion about
the right way to do things, for both upstream and packagers, and would
welcome a bug report describing any confusing or problematic situation
you might find yourself in in future.

I know of two important bits of work at the moment; firstly I've
promised to write up a spec about making pbr suitable for use in some
of the Python packaging tools [virtualenv and pip specifically], which
will involve being able to ship sdists that have no setup_requires. I
believe this will be attractive to distribution packagers as well.
Secondly, some folk are interested in supporting local version
segments in the PEP-440 version string - I'm keen on that too, but it
needs (IMNSHO) to align in with the Nova/Cinder etc 'vendor version'
feature from their config files - we should consolidate that logic
into pbr, as its really got nothing to do with any one API server per
se.

-Rob


-- 
Robert Collins 
Distinguished Technologist
HP Converged Cloud

__
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] [cinder] Need help from folks working on Dell, Storpool and Infortrend drivers

[Sheng Bo Hou]

Hi everyone,

For folks who are working on Dell, Storpool and Infortrend drivers:
I have got a new patch for https://review.openstack.org/#/c/180873. There 
is a change about how to implement the method update_migrated_volume for 
each driver.
The code needs to return the final values for the key _name_id and 
provider_location. I have changed accordingly in your driver, but I am no 
100% sure of the precision, so I need your reviews on the changes about 
your driver. If there is any comment, tell me how to change it. You can 
take the implementation for Storwize as a reference.
First, check if the rename works the same for both the 'available' or 
'in-use' volumes. It is possible to handle differently.
Then check if the rename is successful, it may return different _name_id 
and provider_location values.
There is an explanation about the update_migrated_volume in 
https://review.openstack.org/#/c/180873/67/cinder/volume/driver.py

Thank you.

Best wishes,
Vincent Hou (侯胜博)

Staff Software Engineer, Open Standards and Open Source Team, Emerging 
Technology Institute, IBM China Software Development Lab

Tel: 86-10-82450778 Fax: 86-10-82453660
Notes ID: Sheng Bo Hou/China/IBM@IBMCNE-mail: sb...@cn.ibm.com 
Address:3F Ring, Building 28 Zhongguancun Software Park, 8 Dongbeiwang 
West Road, Haidian District, Beijing, P.R.C.100193
地址:北京市海淀区东北旺西路8号中关村软件园28号楼环宇大厦3层 邮编：100193
__
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] For those interested in reading distributed systems papers

[Joshua Harlow]

Since I found this classes site useful and thought others might also...

https://courses.engr.illinois.edu/cs525/sched.htm (it even appears 
actively in use! since openstack is mentioned in some slides and papers!)


It has a bunch of papers which IMHO are relevant to openstack (and 
various other neat distributed systems slides/papers and links...), nice 
stuff around scheduling, P2P algorithms, reliability...


Good fun weekend reading :-P

-Josh

__
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] [QOS] Request for Additional QoS capabilities

[John Joyce (joycej)]

Gal:
 I am also slow to jump between this and other work so I think I should be 
the one apologizing.  I think we are receptive to any of the approaches QoS, 
FWaaS or Security Groups.  I am not an expert on FWaaS but from a quick look it 
seemed like the FWaaS granularity was at the router level.  We would want this 
per neutron port (e.g. per VM port although don’t want to limit the possibility 
for this be per container or per bare metal port).   Allowing an aggregate 
across all ports of the VM would be very nice,  but not a strict requirement.   
Do you see this as an issue going the FWaaS route?   Have you been making any 
headway getting it in there?
 One detailed comment after looking through the reviews.   Would there be 
any issue in adding a “reject-with-tcp-reset” option?
The DDOS coming from a VM could be due to a virus within the VM our maybe 
just an overly aggressive tenant.  I know the team that runs our cloud offering 
has experienced an excessive connection requests coming from a VM.   I can try 
to get the exact scenario that triggered this.   The net is that all tenants on 
that host can be affected,  especially with an OVS based vswitch.
 John





From: Gal Sagie [mailto:gal.sa...@gmail.com]
Sent: Tuesday, June 23, 2015 2:43 PM
To: OpenStack Development Mailing List (not for usage questions)
Cc: lionel.zer...@huawei.com; Derek Chamorro (dechamor); Eran Gampel
Subject: Re: [openstack-dev] [Neutron] [QOS] Request for Additional QoS 
capabilities

Hi John,

Sorry for the delayed response as i was on vacation with no internet connection 
(you don't know how much
you miss it until you don't have it).

The work in terms of coding is pretty much done for the reference 
implementation.
We initially tried to push it as a security group extension but there is a 
strong objection
to change the security group API, so FWaaS can be next best candidate if we can 
find support
or other uses of this (like your use case)
(Of course that work will need to be added for supporting the connection limit, 
we tried
to  tackle brute force prevention which i personally see as a more concerning 
attack vector internally)

Out of curiosity can you describe scenarios of DDoS attacking from an internal 
VM ?
I would assume most DDoS will happen from external traffic or a combine attack 
from various internal
VM's (and then this might no longer fit as a QoS)

But if you feel this belongs in QoS this can certainly be added on top of the 
framework as Miguel suggested.

Thanks
Gal.

On Fri, Jun 19, 2015 at 12:39 AM, John Joyce (joycej) 
mailto:joy...@cisco.com>> wrote:
Gal:
  I had seen the brute force blueprint and noticed how close the use case 
was.  Can you tell me the current status of the work?  Do you feel confident it 
can get into Liberty?  Ideally, we think this fits better with QoS.  Also I 
don’t think of it as providing FWaaS as we see that all VMs would be protected 
by this when enabled, but maybe that is just terminology.   We think these 
protections are critical so we are more concerned with having the ability to 
protect against these cases than the specific API or service it falls under.  
Yes we would be interested in working together to get this pushed through.

John

From: Gal Sagie [mailto:gal.sa...@gmail.com]
Sent: Wednesday, June 17, 2015 12:45 PM
To: OpenStack Development Mailing List (not for usage questions)
Cc: lionel.zer...@huawei.com; Derek Chamorro 
(dechamor); Eran Gampel
Subject: Re: [openstack-dev] [Neutron] [QOS] Request for Additional QoS 
capabilities

Hi John,

We were trying to push a very similar spec to enhance the security group API, 
we covered both DDoS case
and another use case for brute force prevention (We did a research to identify 
common protocols login behaviour
in order to identify brute force attacks using iptables) and even some UI work

You can view the specs and implementations here:
1) https://review.openstack.org/#/c/184243/
2) https://review.openstack.org/#/c/154535/
3) https://review.openstack.org/#/c/151247/
4) https://review.openstack.org/#/c/161207/

The spec didn't got approved as there is a strong opinion to keep the security 
group API compatible with Amazon.
I think this and your request fits much more into the FWaaS and if this is 
something you would like to work together on and push
i can help and align the above code to use FWaaS.

Feel free to contact me if you have any question

Thanks
Gal.



On Wed, Jun 17, 2015 at 6:58 PM, John Joyce (joycej) 
mailto:joy...@cisco.com>> wrote:
Hello everyone:
  I would like to test the waters on some new functionality we think is 
needed to protect OpenStack deployments from some overload situations due to an 
excessive user or DDOS scenario.   We wrote this up in the style of an RFE.   
Please

Re: [openstack-dev] [ceilometer] virtual mid-cycle planning

[Chris Dent]

On Sun, 28 Jun 2015, Nadya Shakhat wrote:


What is the workflow of adding a new topic? I suggest to add it to both [1]
and [2].


Very good question and great idea. I agree that both is the way to go,
but I would suggest that we keep the entry on the voting page[2] as just
a title and make the addition on the agenda page[1] be in whatever form
is useful. Including description, open questions and leader/initiator is
all great if we know that information but I think for a lot of these
topics there's a general sense of "we need to talk about this topic" and
that's about it. Where we know the details we should put them, where we
don't we will figure it out later.

We don't want to get in the situation where we are avoiding topics that
are vague because those are the ones we most need to talk about.


[1] https://etherpad.openstack.org/p/ceilometer-liberty-midcycle-agenda
[2] https://etherpad.openstack.org/p/ceilometer-liberty-midcycle.


--
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermore.com/tanks/cdent

__
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] [ceilometer] virtual mid-cycle planning

[Nadya Shakhat]

Chris,
What is the workflow of adding a new topic? I suggest to add it to both [1]
and [2]. Also it may be useful to add more items for each topic like
description, open questions, leader. It may help to understand what should
be discussed and who is an initiator. What do you think?

[1] https://etherpad.openstack.org/p/ceilometer-liberty-midcycle-agenda
[2] https://etherpad.openstack.org/p/ceilometer-liberty-midcycle.

On Fri, Jun 26, 2015 at 7:09 PM, Chris Dent  wrote:

> On Fri, 26 Jun 2015, Chris Dent wrote:
>
>  Please provide your input soon. We will close the voting at the end
>> of Wednesday, July 3rd and will be posting a proposed schedule soon
>> thereafter. Note that due to time constraints the mid-cycle could
>> happen as soon as the following Monday, July 6th.
>>
>
> Sigh, I can't read my calendar. The voting will stop at the end
> of Wednesday, July 1st.
>
>
> --
> Chris Dent tw:@anticdent freenode:cdent
> https://tank.peermore.com/tanks/cdent
>
> __
> 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] grenade with external plugins for the big tent - how to use

[Chris Dent]

On Thu, 11 Jun 2015, Sean Dague wrote:


And... you should be good to go. Additional questions on moving forward,
or clarifications in the documentation, can be handled on this thread or
in the #openstack-qa channel.


I finally got started on this today but am having some issues,
likely because I am trying to do too many things at once.

I started extracting ceilometer from devstack into its own plugin.
This is working in local tests.

It revealed that it would likely be problematic without there also being
a grenade plugin. So I started that too.

Questions:

* Is it necessary for the plugins to merge to master before testing
  can completely or is there a clean way to reference the plugins
  before they have merged?

* How do branches come into play in any of this, if at all?

* Are there particular issues that come up with projects like
  Ceilometer where the goal is to move an existing project out of
  both devstack and grenade?

Links to the various related reviews below. I'm sure I've gotten
parts wrong and missed bits, but I figured I'd get starting points
in place and iterate.

There is quite a stack of interdependent patches making this go,
they can all be found by starting at the devstack change which
removes ceilometer

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

The other patches are:

* The actual devstack plugin for ceilo:
  https://review.openstack.org/#/c/196384/

* Setting the plugins in project config:
  https://review.openstack.org/#/c/196446/

* The start of the grenade plugin:
  https://review.openstack.org/#/c/196441/

* Removing ceilometer from grenade:
  https://review.openstack.org/#/c/196448/

Thanks!
--
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermore.com/tanks/cdent

__
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] [puppet] weekly meeting #40

[Emilien Macchi]

Hi everyone,

Here's an initial agenda for our weekly meeting next Tuesday at 1500 UTC
in #openstack-meeting-4:

https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20150630

Please add additional items you'd like to discuss.
-- 
Emilien Macchi



signature.asc
Description: OpenPGP digital signature
__
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] (no subject)

[Fox, Kevin M]

App catalog needs ubiquity. Needs to be sumple for op to install
__
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] QoS code sprint

[Vikram Choudhary]

Thanks for arranging this Miguel. Looking forward to contribute in the best
way we can 😀
On 26-Jun-2015 3:33 pm, "Miguel Angel Ajo"  wrote:

>
> Hi everybody,
>
> Next week, from Tue (Jul 29th) to Thu (Jun 2nd), a few of us will be
> physically [1] attending the neutron QoS coding sprint in Ra'anana (Israel)
> @ the Red Hat office.
>
> And a few others have expressed their will to join us remotely
> (Thanks!!) :)
>
> I guess a reasonable format for the sprint is in the form of short
> meetings followed by coding hours.
>
> We thought it was good to sync with others during the first day on the
> neutron meeting (Tue / Jul 29th, 14:00 UTC #openstack-meeting) about any
> progress, blockers or doubts, so we have requested a timeslot for it :)
>
>  All the other days, we also plan to sync on #openstack-neutron @
> ~14:00 UTC with the remote participants.
>
> TL;DR ...
>
> In an effort to collaborate I'm extending [1] to include the list of
> patches we're working on,
> please list any of them missing in there.
>
> Since we live in different timezones I believe we can let others
> address small/nit/not big structural changes which may need discussion by
> the people on other timezones, and we can use a locking mechanism with the
> etherpad+#openstack-neutron to say who's working in a patch.
>
> By the way, I think the value of gathering is that we can all be
> together to discuss and iterate very quickly, so during the Israel working
> hours I believe we may (generally) prioritize the people physically
> attending the sprint to work on patches to avoid blocking on depending
> parts.
>
>
> Thanks everybody, and sorry for the long message :)
>
>
> [1] https://etherpad.openstack.org/p/neutron-liberty-qos-code-sprint
>
>
>
>
__
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] [devstack] [swift] [ceilometer] installing ceilometermiddleware

[Chris Dent]

On Sat, 27 Jun 2015, Chris Dent wrote:


* What code should be calling and hosting install_ceilometermiddleware?

 Since it is lib/swift that is using it, there makes some sense?
 Especially since it already has a relatively long block of
 configuration instruction.


I've put up a devstack review for this change:

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

--
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermore.com/tanks/cdent

__
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] [cinder][oslo] Locks for create from volume/snapshot

[Duncan Thomas]

We need mutual exclusion for several operations. Whether that is done by
entity queues, locks, state based locking at the api later, or something
else, we need mutual exclusion.

Our current api does not lend itself to looser consistency, and I struggle
to come up with a sane api that does - nobody doing an operation on a
volume  wants it to happen maybe, at some time...
On 28 Jun 2015 07:30, "Avishay Traeger"  wrote:

> Do we really need any of these locks?  I'm sure we could come up with some
> way to remove them, rather than make them distributed.
>
> On Sun, Jun 28, 2015 at 5:07 AM, Joshua Harlow 
> wrote:
>
>> John Griffith wrote:
>>
>>>
>>>
>>> On Sat, Jun 27, 2015 at 11:47 AM, Joshua Harlow >> > wrote:
>>>
>>> Duncan Thomas wrote:
>>>
>>> We are working on some sort of distributed replacement for the
>>> locks in
>>> cinder, since file locks are limiting our ability to do HA. I'm
>>> afraid
>>> you're unlikely to get any traction until that work is done.
>>>
>>> I also have a concern that some backend do not handle load well,
>>> and so
>>> benefit from the current serialisation. It might be necessary to
>>> push
>>> this lock down into the driver and allow each driver to choose
>>> it's
>>> locking model for snapshots.
>>>
>>>
>>> IMHO (and I know this isn't what everyone thinks) but I'd rather
>>> have cinder (and other projects) be like this from top gear (
>>> https://www.youtube.com/watch?v=xnWKz7Cthkk ) where that toyota
>>> truck is virtually indestructible vs. trying to be a
>>> high-maintenance ferrari (when most openstack projects do a bad job
>>> of trying to be one). So, maybe for a time (and I may regret saying
>>> this) we could consider focusing on reliability, consistency, being
>>> the toyota vs. handling some arbitrary amount of load (trying to be
>>> a ferrari).
>>>
>>> Also I'd expect/think operators would rather prefer a toyota at this
>>> stage of openstack :) Ok enough analogies, ha.
>>>
>>>
>>> ​Well said Josh, I guess I've been going about this all wrong by not
>>> using the analogies :)​
>>>
>>
>> Exactly!! IMHO should be the new 'openstack mantra, built from
>> components/projects that survive like a toyota truck' haha. Part 2 (
>> https://www.youtube.com/watch?v=xTPnIpjodA8) and part 3 (
>> https://www.youtube.com/watch?v=kFnVZXQD5_k) are funny/interesting also
>> :-P
>>
>> Now we just need openstack to be that reliable and tolerant of
>> failures/calamities/...
>>
>>
>>>
>>> -Josh
>>>
>>>
>>> On 27 Jun 2015 06:18, "niuzhenguo" >> 
>>> >>
>>>
>>> wrote:
>>>
>>>  Hi folks,
>>>
>>>  __ __
>>>
>>>  Currently we use a lockfile to protect the create
>>> operations from
>>>  concurrent delete the source volume/snapshot, we use
>>> exclusive
>>>
>>>  locks on both delete and create sides which will ensure
>>> that:
>>>
>>>  __ __
>>>
>>>  __1.__If a create of VolA from snap/VolB is in progress,
>>> any delete
>>>  requests for snap/VolB will wait until the create is
>>> complete.
>>>
>>>  __2.__If a delete of snap/VolA is in progress, any create
>>> from
>>>  snap/VolA will wait until snap/VolA delete is complte.
>>>
>>>  __ __
>>>
>>>  but, the exclusive locks will also result in:
>>>
>>>  __ __
>>>
>>>  __3.__If a create of VolA from snap/VolB is inprogress, any
>>> other
>>>  create requests from snap/VolB will wait until the create is
>>>  complete. 
>>>
>>>  __ __
>>>
>>>  So the create operations from same volume/snapshot can not
>>> process
>>>  on parallel, please reference bp [1].
>>>
>>>  I’d like to change the current filelock or introduce a new
>>> lock to
>>>  oslo.concurrency.
>>>
>>>  __ __
>>>
>>>  Proposed change:
>>>
>>>  Add exclusive(write) locks for delete operations and
>>> shared(read)
>>>  locks for create operations, to ensure that create from
>>>  volume/snapshot
>>>
>>>  can work on parallel and protect create operations from
>>> concurrent
>>>  delete the source volume/snapshot.
>>>
>>>  __ __
>>>
>>>  I’d like to get what’s your suggestions, thanks in
>>> advance.
>>>
>>>  __ __
>>>
>>>  [1]
>>> https://blueprints.launchpad.net/cinder/+spec/enhance-locks
>>>
>>>  __ __
>>>
>>>  __ __
>>>
>>>  -zhenguo
>>>
>>

Re: [openstack-dev] [neutron] enriching port binding extension API dictionaries with key-values

[Irena Berezovsky]

Hi Andreas,

On Fri, Jun 26, 2015 at 4:04 PM, Andreas Scheuring <
scheu...@linux.vnet.ibm.com> wrote:

> Hi together,
> for a new ml2 plugin I would like to pass over some data from neutron to
> nova on port creation and update (exploiting port binding extension
> [1]). For my prototype I thought of using one of the following response
> dictionaries to add my information:
>
> - binding:vif_details
> - binding:profile
>
> The API ref describes these attributes (port create / port update - both
> response) as dictionaries, but without restricting the key-value pairs
> or naming a defined number [1].
>
binding:profile is an input dictionary, that should tell neutron how to
bind the port.
binding:vif_details is an output dictionary that should provide nova  (or
other) with enough details to plug the port properly.

>
> I've also seen some other ml2 plugins enriching those fields with unique
> data. So I assuming this is not considered as an API change, isn't it?
>
> Important: It's only about the response. The input comes from a
> configuration file.
>
>
> Thanks
>
>
> [1] http://developer.openstack.org/api-ref-networking-v2-ext.html
>
>
> --
> Andreas
> (IRC: scheuran)
>
>
>
> __
> 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] [Magnum] Survey

[P Rivera]

Hello All Magnum Developers, Users, and Fans:

Please take a few moments to complete our OpenStack / Magnum survey.
Your feedback is appreciated!:
http://goo.gl/forms/W6ggrLiYFv

Thank you,
-Perry Rivera
 OpenStack / Magnum

__
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