Re: [openstack-dev] [Mistral] Changing "expression" delimiters in Mistral DSL

[Steven Hardy]

On Thu, Feb 19, 2015 at 12:24:14PM +0600, Renat Akhmerov wrote:
>Guys,
>I really appreciate the input of you all.
>We decided that ideally we need to agree on that syntax within days, not
>weeks or months. But anyway, since we started this discussion yesterday I
>just want to give us extra 1-2 days to play with all these thoughts in our
>heads.
>Just one additional maybe a little bit crazy idea to the pile wea**ve
>already made:
>What if we officially allow more than one delimiter syntax? Why stick to
>just one?

Because consistency is a good thing, it aids readability, reduces developer
confusion, encourages consistent style, etc, etc.

If you've ever worked on a perl codebase of any size, I'm sure you'll
appreciate the zen of python:

"There should be one, and preferably only one obvious way to do it"

My 0.02 :)

Steve

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

Re: [openstack-dev] Pluggable Auth for clients and where should it go

[Chmouel Boudjnah]

On Wed, Feb 18, 2015 at 8:54 PM, Dean Troyer  wrote:

> I think one thing needs to be clarified...what you are talking about is
> utilizing keystoneclient's auth plugins in neutronclient.  Phrasing it as
> 'novaclient parity' reinforces the old notion that novaclient is the model
> for doing things.  It is no longer that...and maybe not even the right
> example of how to use auth plugins even though jamielennox did most of that
> work.
>

and FYI jamie has a serie of excellent articles about keystone's pluggable
auth on his blog: http://www.jamielennox.net/

Chmouel
__
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][ipv6] dhcp stateful

[Andreas Scheuring]

Hi, 
I was playing around with the various dhcp/radvd options of neutron.
Very helpful was the matrix [1] that describes the combinations of ra
and adress mode that can be configured.

For dhcpv6-stateful (ra & adress mode) it says: "VM obtains IPv6 address
from dnsmasq using DHCPv6 stateful and optional info from dnsmasq using
DHCPv6 stateful" [1] --> My assumption was that IP adresses and prefix
are assigned via dnsmasq. 

But going this way, my instances got the right IP-Adress (great) but
always the subnetmask /128, although I configured /64. Dumping the
traffic and having a look at dnsmasq logs the dhcp process from solicit
to reply worked fine.

I was using rhel7 for guest and host and dnsmasq 2.68.

I googled around and found some hints, that dhcpv6 does not support
prefix delegation. Seems like that it is the job of the radvd daemon
[2][3][4]


Is that true? And if so, what's the use case of configuring
dhcpv6-stateful for ra and address mode?






[1]
http://specs.openstack.org/openstack/neutron-specs/specs/juno/ipv6-radvd-ra.html#rest-api-impact

[2] https://lists.isc.org/pipermail/dhcp-users/2012-May/015446.html
[3]
http://serverfault.com/questions/528387/sending-netmask-and-gateway-route-with-dhcp-for-ipv6
[4]
https://supportforums.cisco.com/document/116221/part-1-implementing-dhcpv6-stateful-dhcpv6

-- 
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-dev] [neutron] [ovs-dev] [PATCH 8/8] [RFC] ovn: Start work on design Documentation.

[Miguel Ángel Ajo]

Thank you Ben!,  

Cross posting [1] to openstack list /neutron.


[1] http://benpfaff.org/~blp/dist-docs. 

On Thursday, 19 de February de 2015 at 09:13, Ben Pfaff wrote:

> On Thu, Feb 19, 2015 at 12:12:26AM -0800, Ben Pfaff wrote:
> > This commit adds preliminary design documentation for Open Virtual Network,
> > or OVN, a new OVS-based project to add support for virtual networking to
> > OVS, initially with OpenStack integration.
> > 
> > This initial design has been influenced by many people, including (in
> > alphabetical order) Aaron Rosen, Chris Wright, Jeremy Stribling,
> > Justin Pettit, Ken Duda, Madhu Venugopal, Martin Casado, Pankaj Thakkar,
> > Russell Bryant, and Teemu Koponen. All blunders, however, are due to my
> > own hubris.
> > 
> > Signed-off-by: Ben Pfaff mailto:b...@nicira.com)>
> 
> I've posted the rendered version of the documentation following this
> commit at http://benpfaff.org/~blp/dist-docs. You probably want to look
> at the ovn* manpages, especially ovn-architecture(7), ovn(5), and
> ovn-nb(5).
> ___
> dev mailing list
> d...@openvswitch.org (mailto:d...@openvswitch.org)
> http://openvswitch.org/mailman/listinfo/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] [kolla][tripleo] Call for developers/contributors for kolla-k3

[Steven Dake (stdake)]

Hey folks,

I’d like to invite the broader OpenStack community to participate in developing 
milestone #3 of Kolla – a Project to Containerize the deployment of OpenStack.  
This is a major refactoring of Kolla to make it viable for use by projects such 
as TripleO or Fuel.

We have an aggressive set of features the core team has identified it wants to 
develop.  Our deadline for development is March 19th.  Theoretically we could 
slip into early April, but the idea is to synchronize our schedule with the 
broader OpenStack project’s release schedule.  We have approximately 4-6 weeks 
to finish our development described out in the below blueprint.

The set of features the core team has identified we want to develop is 
described in this specification:

https://github.com/stackforge/kolla/blob/master/specs/containerize-openstack.rst

I have decomposed the specification in to specific work items.  Most of the 
blueprints will take between 4 and 20 hours of work individually.  If your keen 
to learn about containers or the future of deployment architectures in 
OpenStack, please come and join in our development.  We do our development in 
the #tripleo channel on IRC using the standard OpenStack review and development 
process.

The decomposed blueprints are here:

https://blueprints.launchpad.net/kolla

Come pick one out and start developing today :)

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

Re: [openstack-dev] [Fuel] [UI] Sorting and filtering of node list

[Vitaly Kramskikh]

I think all these operations for nodes (grouping, sorting, filtering) can
be done on the backend, but we can do it completely on the UI side and
shouldn't wait for backend implementation. We can switch to it after it
becomes available.

2015-02-17 19:44 GMT+07:00 Sergey Vasilenko :

> +1, sorting is should be...
>
> Paginating may be too, but not activated by default.
>
>
> /sv
>
>
>
> __
> 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
>
>


-- 
Vitaly Kramskikh,
Fuel UI Tech Lead,
Mirantis, Inc.
__
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] [Mistral] Changing "expression" delimiters in Mistral DSL

[Nikolay Makhotkin]

Hi !

>From those three I'd choose only <{ ... }>, it looks better for YAML while
'%' sign looks foreign for YAML. Moreover, it needs extra spaces for
writing expressions:

Compare:
1. <%$.var + 1%>
2. <% $.var + 1 %>
3. <{$.var + 1}>

One more point from me: We can't do things just beacuse it is familiar with
N things and it should be so.


Best Regards,
Nikolay
__
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] [nova] The strange case of osapi_compute_unique_server_name_scope

[Matthew Booth]

Nova contains a config variable osapi_compute_unique_server_name_scope.
Its help text describes it pretty well:

When set, compute API will consider duplicate hostnames invalid within
the specified scope, regardless of case. Should be empty, "project" or
"global".

So, by default hostnames are not unique, but depending on this setting
they could be unique either globally or in the scope of a project.

Ideally a unique constraint would be enforced by the database but,
presumably because this is a config variable, that isn't the case here.
Instead it is enforced in code, but the code which does this predictably
races. My first attempt to fix this using the obvious SQL solution
appeared to work, but actually fails in MySQL as it doesn't support that
query structure[1][2]. SQLite and PostgreSQL do support it, but they
don't support the query structure which MySQL supports. Note that this
isn't just a syntactic thing. It looks like it's still possible to do
this if we compound the workaround with a second workaround, but I'm
starting to wonder if we'd be better fixing the design.

First off, do we need this config variable? Is anybody actually using
it? I suspect the answer's going to be yes, but it would be extremely
convenient if it's not.

Assuming this configurability is required, is there any way we can
instead use it to control a unique constraint in the db at service
startup? This would be something akin to a db migration. How do we
manage those?

Related to the above, I'm not 100% clear on which services run this
code. Is it possible for different services to have a different
configuration of this variable, and does that make sense? If so, that
would preclude a unique constraint in the db.

Thanks,

Matt

[1] Which has prompted me to get the test_db_api tests running on MySQL.
See this series if you're interested:
https://review.openstack.org/#/c/156299/

[2] For specifics, see my ramblings here:
https://review.openstack.org/#/c/141115/7/nova/db/sqlalchemy/api.py,cm
line 2547
-- 
Matthew Booth
Red Hat Engineering, Virtualisation Team

Phone: +442070094448 (UK)
GPG ID:  D33C3490
GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490

__
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] Libguestfs: possibility not to use it, even when installed ?

[Matthew Booth]

On 18/02/15 18:23, Raphael Glon wrote:
> Hi,
> 
> This is about review:
> https://review.openstack.org/#/c/156633/
> 
> 1 line, can be controversial
> 
> Its purpose is to add the possibility not to use libguestfs for data
> injection in nova, even when installed.
> 
> Not discussing about the fact that libguestfs should be preferred over
> fuse mounts for data injection as much as possible because mounts are
> more subject to causing security issues (and already have in the past
> nova releases).
> 
> However, there are a lot of potential cases when libguestfs won't be
> usable for data injection
> 
> This was the case here (fixed):
> https://bugzilla.redhat.com/show_bug.cgi?id=984409
> 
> I entcountered a similar case more recently on powerkvm 2.1.0 (defect
> with the libguestfs)
> 
> So just saying it could be good adding a simple config flag (set to True
> by default, to keep the current behaviour untouched) to force nova not
> using libguestfs without having to uninstall it and thus prevent other
> users on the host from using it.

A big -1 to this. You seem to be saying that there were bugs in a
library, which were fixed. News at 11. This isn't a realistic way to
manage a large software stack.

Matt
-- 
Matthew Booth
Red Hat Engineering, Virtualisation Team

Phone: +442070094448 (UK)
GPG ID:  D33C3490
GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490

__
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] [swift] On Object placement

[Christian Schwede]

Hello Jonathan,

On 18.02.15 18:13, Halterman, Jonathan wrote:
>>> 1. Swift should allow authorized services to place a given number
>>> of object replicas onto a particular rack, and onto separate
>>> racks.
>> 
>> This is already possible if you use zones and regions in your ring 
>> files. For example, if you have 2 racks, you could assign one zone
>> to each of them and Swift places at least one replica on each
>> rack.
>> 
>> Because Swift takes care of the device weight you could also ensure
>> that a specific rack gets two copies, and another rack only one.
> 
> Presumably a deployment would/should match the DC layout, where
> racks could correspond to Azs.

yes, that makes a lot of sense (to assign zones to racks), because in
this case you can ensure that there aren't multiple replicas stored
within the same rack. You can still access your data if a rack goes down
(power, network, maintenance).

>> However, this is only true as long as all primary nodes are
>> accessible. If Swift stores data on a handoff node this data might
>> be written to a different node first, and moved to the primary node
>> later on.
>> 
>> Note that placing objects on other than the primary nodes (for
>> example using an authorized service you described) will only store
>> the data on these nodes until the replicator moves the data to the
>> primary nodes described by the ring. As far as I can see there is
>> no way to ensure that an authorized service can decide where to
>> place data, and that this data stays on the selected nodes. That
>> would require a fundamental change within Swift.
> 
> So - how can we influence where data is stored? In terms of
> placement based on a hash ring, I¹m thinking of perhaps restricting
> the placement of an object to a subset of the ring based on a zone.
> We can still hash an object somewhere on the ring, for the purposes
> of controlling locality, we just want it to be within (or without) a
> particular zone. Any ideas?

You can't (at least not from the client side). The ring determines the
placement and if you have more zones (or regions) than replicas you
can't ensure an object replica is stored within a determined rack. Even
if you store it on a handoff node it will be moved to the primary node
sooner or later.
Determining that an object is stored in a specific zone is not possible
with the current architecture; you can only discover in which zone it
will be placed finally (based on the ring).

What you could do (especially if you have more racks than replicas) is
to use storage policies and only assign three racks to each policy, and
splitting them into three zones (if you store three replicas).
For example, let's assume you have 5 racks, then you create 5 storage
policies (SP) with the following assignment:

Rack
SP  1   2   3   4   5
0   x   x   x
1   x   x   x
2   x   x   x
3   x   x   x
4   x   x   x

Doing this you can ensure the following:
- Data is distributed somehow evenly across the cluster (if you use the
storage policies also evenly distributed)
- From a given SP you can ensure that a replica is stored in a specific
rack; and because a SP is assigned to a container you can determine the
SP based on the container metadata (name SP0 "rack_1_2_3" and so on to
make it even more simpler for the application to determine the racks).

That could help in your case?


>>> 2. Swift should allow authorized services and administrators to
>>> learn which racks an object resides on, along with endpoints.
>> 
>> You already mentioned the endpoint middleware, though it is
>> currently not protected and unauthenticated access is allowed if
>> enabled.
> 
> This is good to know. We still need to learn which rack an object
> resides on though. This information is important in determining
> whether a swift object resides on the same rack as a VM.

Well, that information is available using the /endpoint middleware? You
know the server IPs in a rack, and compare that to the output from the
endpoint middleware.

>> You could easily add another small middleware in the pipeline to
>> check authentication and grant or deny access to /endpoints based
>> on the authentication. You can also get the node (and disk) if you
>> have access to the ring files. There is a tool included in the
>> Swift source code called "swift-get-nodes"; however you could
>> simply reuse existing code to include it in your projects.
> 
> I¹m guessing this would not work for in cloud services?

Do you mean public cloud services? You always need access to the storage
servers itself to access objects directly, and these should be
accessible only by an internal, protected network (and only the proxy
servers should have access to that network).

Christian

__
OpenStack Development Mailing List (not

[openstack-dev] [Fuel]Adding compute node on existing environment

[Foss Geek]

Dear All,

I have Openstack HA environment (all are physical machine) deployed using
Fuel 5.1. I want to bring one more compute node in VM(VM is running in
vCenter and configured 4 nic).

How to deploy a compute node in VM and bring this to existing openstack
environment?

Any help.

-- 
Thanks & Regards
E-Mail: thefossg...@gmail.com
IRC: neophy
Blog : http://lmohanphy.livejournal.com/
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] Libguestfs: possibility not to use it, even when installed ?

[Daniel P. Berrange]

On Wed, Feb 18, 2015 at 07:23:52PM +0100, Raphael Glon wrote:
> Hi,
> 
> This is about review:
> https://review.openstack.org/#/c/156633/
> 
> 1 line, can be controversial
> 
> Its purpose is to add the possibility not to use libguestfs for data
> injection in nova, even when installed.
> 
> Not discussing about the fact that libguestfs should be preferred over fuse
> mounts for data injection as much as possible because mounts are more
> subject to causing security issues (and already have in the past nova
> releases).
> 
> However, there are a lot of potential cases when libguestfs won't be usable
> for data injection
> 
> This was the case here (fixed):
> https://bugzilla.redhat.com/show_bug.cgi?id=984409
> 
> I entcountered a similar case more recently on powerkvm 2.1.0 (defect with
> the libguestfs)
> 
> So just saying it could be good adding a simple config flag (set to True by
> default, to keep the current behaviour untouched) to force nova not using
> libguestfs without having to uninstall it and thus prevent other users on
> the host from using it.

The bug you quote above was easily fixed. If you have problems with
powerkvm then file a bug about them so they can be investigated &
fixed too. Just disabling its use is simply not at all helpful as the
alternative impl is horribly insecure against malicious disk images
which can cause host kernel crash.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

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

Re: [openstack-dev] [Mistral] Changing "expression" delimiters in Mistral DSL

[Alexander Tivelkov]

​Folks,  one more thing to consider: the next big release of yaql (1.0,
coming really soon) will get support of curly brac​es (by default - to
initialise dictionaries in the following way:

v0.2/v0.3 syntax: dict(key1=>value1, key2=>value2)

v1 syntax: {key1=>value1, key2=>value2} (the old syntax works in v1 as well)


So, {} will become a valid yaql expression (empty dict). I believe it is
not a big deal to parse that correctly and differentiate between outer
markup and an expression contained within, however statements like <{{}}>
may be a little ugly.

--
Regards,
Alexander Tivelkov

On Thu, Feb 19, 2015 at 1:13 PM, Nikolay Makhotkin 
wrote:

> Hi !
>
> From those three I'd choose only <{ ... }>, it looks better for YAML while
> '%' sign looks foreign for YAML. Moreover, it needs extra spaces for
> writing expressions:
>
> Compare:
> 1. <%$.var + 1%>
> 2. <% $.var + 1 %>
> 3. <{$.var + 1}>
>
> One more point from me: We can't do things just beacuse it is familiar
> with N things and it should be so.
>
>
> Best Regards,
> Nikolay
>
> __
> 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] Libguestfs: possibility not to use it, even when installed ?

[Richard W.M. Jones]

On Wed, Feb 18, 2015 at 07:23:52PM +0100, Raphael Glon wrote:
> I entcountered a similar case more recently on powerkvm 2.1.0
> (defect with the libguestfs)

What's the actual bug?  We've worked hard, with IBM, to make
libguestfs work on POWER 7 and POWER 8 systems.  I have full access to
those systems through Red Hat.  If there's a new bug I'm sure we'll be
able to fix it.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html

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

[openstack-dev] Error Enabling Federation Extension

[Akshik DBK]

im getting “Target WSGI script ‘/var/www/cgi-bin/keystone/main’ cannot be 
loaded as Python module”while configuring federation for keystone any help
[info] [client 10.10.10.12] mod_wsgi (pid=25248, process=’keystone’, 
application=’10.1.193.250:5000|’): Loading WSGI script 
‘/var/www/cgi-bin/keystone/main’.[error] [client 10.10.10.12] mod_wsgi 
(pid=25248): Target WSGI script ‘/var/www/cgi-bin/keystone/main’ cannot be 
loaded as Python module.[error] [client 10.10.10.12] mod_wsgi (pid=25248): 
Exception occurred processing WSGI script 
‘/var/www/cgi-bin/keystone/main’.[error] [client 10.10.10.12] Traceback (most 
recent call last):[error] [client 10.10.10.12] File 
“/var/www/cgi-bin/keystone/main”, line 21, in[error] [client 10.10.10.12] 
config.configure()[error] [client 10.10.10.12] File 
“/usr/lib/python2.7/dist-packages/keystone/common/config.py”, line 694, in 
configure[error] [client 10.10.10.12] help=’Do not monkey-patch threading 
system modules.’))[error] [client 10.10.10.12] File 
“/usr/lib/python2.7/dist-packages/oslo/config/cfg.py”, line 1579, in 
__inner[error] [client 10.10.10.12] result = f(self, *args, **kwargs)[error] 
[client 10.10.10.12] File 
“/usr/lib/python2.7/dist-packages/oslo/config/cfg.py”, line 1731, in 
register_cli_opt[error] [client 10.10.10.12] raise 
ArgsAlreadyParsedError(“cannot register CLI option”)[error] [client 
10.10.10.12] ArgsAlreadyParsedError: arguments already parsed: cannot register 
CLI option  
   __
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] The root-cause for IRC private channels (was Re: [all][tc] Lets keep our community open, lets fight for it)

[Kuvaja, Erno]

> -Original Message-
> From: Clark Boylan [mailto:cboy...@sapwetik.org]
> Sent: Tuesday, February 17, 2015 6:06 PM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] The root-cause for IRC private channels (was
> Re: [all][tc] Lets keep our community open, lets fight for it)
> 
> On Tue, Feb 17, 2015, at 09:32 AM, Stefano Maffulli wrote:
> > Changing the subject since Flavio's call for openness was broader than
> > just private IRC channels.
> >
> > On Tue, 2015-02-17 at 10:37 +, Daniel P. Berrange wrote:
> > > If cases of bad community behaviour, such as use of passwd protected
> > > IRC channels, are always primarily dealt with via further private
> > > communications, then we are denying the voters the information they
> > > need to hold people to account. I can understand the desire to avoid
> > > publically shaming people right away, because the accusations may be
> > > false, or may be arising from a simple mis-understanding, but at
> > > some point genuine issues like this need to be public. Without this
> > > we make it difficult for contributors to make an informed decision
> > > at future elections.
> >
> > You got my intention right: I wanted to understand better what lead
> > some people to create a private channel, what were their needs. For
> > that objective, having an accusatory tone won't go anywhere and
> > instead I needed to provide them a safe place to discuss and then I
> > would report back in the open.
> >
> > So far, I've only received comments in private from only one person,
> > concerned about public logging of channels without notification. I
> > wished the people hanging out on at least one of such private channels
> > would provide more insights on their choice but so far they have not.
> >
> > Regarding the "why" at least one person told me they prefer not to use
> > official openstack IRC channels because there is no notification if a
> > channel is being publicly logged. Together with freenode not
> > obfuscating host names, and eavesdrop logs available to any spammer,
> > one person at least is concerned that private information may leak.
> > There may also be legal implications in Europe, under the Data
> > Protection Directive, since IP addresses and hostnames can be
> > considered sensitive data. Not to mention the casual dropping of
> > emails or phone numbers in public+logged channels.
> >
> > I think these points are worth discussing. One easy fix this person
> > suggests is to make it default that all channels are logged and write
> > a warning on wiki/IRC page. Another is to make the channel bot
> > announce whether the channel is logged. Cleaning up the hostname
> > details on join/parts from eavesdrop and put the logs behind a login
> > (to hide them from spam harvesters).
> >
> > Thoughts?
> >
> It is worth noting that just about everything else is logged too. Git repos 
> track
> changes individuals have made, this mailing list post will be publicly 
> available,
> and so on. At the very least I think the assumption should be that any
> openstack IRC channel is logged and since assumptions are bad we should be
> explicit about this. I don't think this means we require all channels 
> actually be
> logged, just advertise than many are and any can be (because really any
> individual with freenode access can set up public logging).
> 
> I don't think we should need to explicitly cleanup our logs. Mostly because
> any individual can set up public logs that are not sanitized.
> Instead IRC users should use tools like cloaks or Tor to get the level of
> obfuscation and security that they desire. Freenode has docs for both, see
> https://freenode.net/faq.shtml#cloaks and
> https://freenode.net/irc_servers.shtml#tor
> 
> Hope this helps,
> Clark

Hi Clark,

Sorry to say, but the above is totally irrelevant regarding the current 
legislation.
The legal system does not care individual assumptions like "everybody should 
know we are breaking law here". What comes to individuals setting up such 
services, the responsibility of those records are on that individual and that 
individual could potentially get off the hook quite easy by claiming not 
knowing. What comes to OpenStack Foundation doing such activity, one could 
argue how far that "but we did not know"-attitude carries in court.

[1] The Directive is based on the 1980 OECD "Recommendations of the Council 
Concerning guidelines Governing the Protection of Privacy and Trans-Border 
Flows of Personal Data."

These recommendations are founded on seven principles, since enshrined in EU 
Directive 94/46/EC:

Notice: subjects whose data is being collected should be given notice of 
such collection.
Purpose: data collected should be used only for stated purpose(s) and for 
no other purposes.
Consent: personal data should not be disclosed or shared with third parties 
without consent from its subject(s).
Security: once collected, personal data should be kept safe and secure f

Re: [openstack-dev] [keystone] [trusts] [all] How trusts should work by design?

[Alexander Makarov]

@Renat, They are conceptually different:
- regular tokens are created for the owner of addressed resource
- trust scoped tokens are for trustees and have some security restrictions.
The case is about disallowing a trustee to aquire a regular token allowing
him anything the trustor is allowed. It'd be an exploit.

On Thu, Feb 19, 2015 at 9:01 AM, Renat Akhmerov 
wrote:

> Hi,
>
>
> > On 18 Feb 2015, at 23:54, Nikolay Makhotkin 
> wrote:
> >
> > Nova client's CLI parameter 'bypass_url' helps me. The client's API also
> has 'management_url' attribute, if this one is specified - the client
> doesn't reauthenticate. Also the most of clients have 'endpoint' argument,
> so client doesn't make extra call to keystone to retrieve new token and
> service_catalog.
> >
> > Thank you for clarification!
>
>
> I want to say an additional “thank you” from me for helping us solve this
> problem that’s been around for a while.
>
> And just a small conceptual question: in my understanding since trust
> chaining has already landed this kind of reauthentication doesn’t make a
> lot of sense to me. Isn’t trust chaining supposed to mean that trust-scoped
> tokens a regular tokens should be considered equal? Or we should still
> assume that trust scoped tokens are sort of limited? If yes then how
> exactly they must be understood?
>
>
> Thanks!
>
> Renat Akhmerov
> @ Mirantis Inc.
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Kind Regards,
Alexander Makarov,
Senoir Software Developer,

Mirantis, Inc.
35b/3, Vorontsovskaya St., 109147, Moscow, Russia

Tel.: +7 (495) 640-49-04
Tel.: +7 (926) 204-50-60

Skype: MAKAPOB.AJIEKCAHDP
__
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] Error Enabling Federation Extension

[Marek Denis]

Hi Akshik,

Could you give some more details about the steps you did for configuring 
federation as well as the environment you are using?


Is it devstack? What version of Keystone do you use?

Thanks,
Marek


On 19.02.2015 12:52, Akshik DBK wrote:
im getting “Target WSGI script ‘/var/www/cgi-bin/keystone/main’ cannot 
be loaded as Python module”

while configuring federation for keystone any help

[info] [client 10.10.10.12] mod_wsgi (pid=25248, process=’keystone’, 
application=’10.1.193.250:5000|’): Loading WSGI script 
‘/var/www/cgi-bin/keystone/main’.
[error] [client 10.10.10.12] mod_wsgi (pid=25248): Target WSGI script 
‘/var/www/cgi-bin/keystone/main’ cannot be loaded as Python module.
[error] [client 10.10.10.12] mod_wsgi (pid=25248): Exception occurred 
processing WSGI script ‘/var/www/cgi-bin/keystone/main’.

[error] [client 10.10.10.12] Traceback (most recent call last):
[error] [client 10.10.10.12] File “/var/www/cgi-bin/keystone/main”, 
line 21, in

[error] [client 10.10.10.12] config.configure()
[error] [client 10.10.10.12] File 
“/usr/lib/python2.7/dist-packages/keystone/common/config.py”, line 
694, in configure
[error] [client 10.10.10.12] help=’Do not monkey-patch threading 
system modules.’))
[error] [client 10.10.10.12] File 
“/usr/lib/python2.7/dist-packages/oslo/config/cfg.py”, line 1579, in 
__inner

[error] [client 10.10.10.12] result = f(self, *args, **kwargs)
[error] [client 10.10.10.12] File 
“/usr/lib/python2.7/dist-packages/oslo/config/cfg.py”, line 1731, in 
register_cli_opt
[error] [client 10.10.10.12] raise ArgsAlreadyParsedError(“cannot 
register CLI option”)
[error] [client 10.10.10.12] ArgsAlreadyParsedError: arguments already 
parsed: cannot register CLI option



__
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][neutron] Passthrough of PF's from SR-IOV capable devices.

[Steve Gordon]

- Original Message -
> From: "Irena Berezovsky" 
> To: "OpenStack Development Mailing List (not for usage questions)" 
> ,
> 
> On Thu, Feb 5, 2015 at 9:01 PM, Steve Gordon  wrote:
> 
> > - Original Message -
> > > From: "Przemyslaw Czesnowicz" 
> > > To: "OpenStack Development Mailing List (not for usage questions)" <
> > openstack-dev@lists.openstack.org>
> > >
> > > Hi
> > >
> > > > 1) If the device is a "normal" PCI device, but is a network card, am I
> > > > still able to
> > > > take advantage of the advanced syntax added circa Juno to define the
> > > > relationship between that card and a given physical network so that the
> > > > scheduler can place accordingly (and does this still use the ML2 mech
> > > > drvier for
> > > > SR-IOV even though it's a "normal" device.
> > >
> > > Actually libvirt won't allow using "normal" PCI devices for network
> > > interfaces into VM.
> > > Following error is thrown by libvirt 1.2.9.1:
> > > libvirtError: unsupported configuration: Interface type hostdev is
> > currently
> > > supported on SR-IOV Virtual Functions only
> > >
> > > I don't know why libvirt prohibits that. But we should prohibit that on
> > > Openstack side as well.
> >
> > This is true for hostdev"> style configuration, "normal" PCI devices are
> > still valid in Libvirt for passthrough using  though. The former
> > having been specifically created for handling passthrough of VFs, the
> > latter being the more generic passthrough functionality and what was used
> > with the original PCI passthrough functionality introduced circa Havana.
> >
> > I guess what I'm really asking in this particular question is what is the
> > intersection of these two implementations - if any, as on face value it
> > seems that to passthrough a physical PCI device I must use the older syntax
> > and thus can't have the scheduler be aware of its external network
> > connectivity.
> >
> Support for "normal" PCI device passthrough for networking in SR-IOV like
> way will require new VIF Driver support for hostdev style device guest XML
> being created and some call invocation to set MAC address and VLAN tag.
> 
> >
> > > > 2) There is no functional reason from a Libvirt/Qemu perspective that I
> > > > couldn't
> > > > pass through a PF to a guest, and some users have expressed surprise
> > to me
> > > > when they have run into this check in the Nova driver. I assume in the
> > > > initial
> > > > implementation this was prevented to avoid a whole heap of fun
> > additional
> > > > logic
> > > > that is required if this is allowed (e.g. check that no VFs from the PF
> > > > being
> > > > requested are already in use, remove all the associated VFs from the
> > pool
> > > > when
> > > > assigning the PF, who gets allowed to use PFs versus VFs etc.). Am I
> > > > correct here
> > > > or is there another reason that this would be undesirable to allow in
> > > > future -
> > > > assuming such checks can also be designed - that I am missing?
> > > >
> > > I think that is correct. But even if the additional logic was
> > implemented  it
> > > wouldn't work because of how libvirt behaves currently.
> >
> > Again though, in the code we have a distinction between a physical device
> > (as I was asking about in Q1) and a physical function (as I am asking about
> > in Q2) and similarly whether libvirt allows or not depends on how you
> > configure in the guest XML. Though I wouldn't be surprised on the PF case
> > if it is in fact not allowed in Libvirt (even with ) it is again
> > important to consider this distinctly separate from passing through the
> > physical device case which we DO allow currently in the code I'm asking
> > about.
> >
> I think what you suggest is not difficult to support, but current (since
> Juno) PCI device passthrough  for networking is all about SR-IOV PCI device
> passthrough. As I mentioned, to support  "normal" PCI device will require
> libvirt VIF Driver adjustment. I think its possible to make this work with
> existing neutron ML2 SRIOV Mechanism Driver.

Understood, was just trying to understand if there was an explicit reason *not* 
to do this. How should we track this, keep adding to 
https://etherpad.openstack.org/p/kilo_sriov_pci_passthrough ?

Thanks,

Steve

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

Re: [openstack-dev] [nova] release request for python-novaclient

[Matt Riedemann]

On 2/12/2015 6:55 PM, Michael Still wrote:

This was discussed in the nova meeting this morning. In that meeting
we declared ourselves unwedged and ready to do a release, and I said
I'd do that today.

On reflection, I want to recant just a little -- I think its a bad
idea for me to do a release on a Friday. So, I'll do this early next
week instead.

Michael

On Wed, Feb 11, 2015 at 8:51 AM, Joe Gordon  wrote:



On Mon, Feb 9, 2015 at 7:55 PM, Michael Still  wrote:


The previous policy is that we do a release "when requested" or when a
critical bug fix merges. I don't see any critical fixes awaiting
release, but I am not opposed to a release.

The reason I didn't do this yesterday is that Joe wanted some time to
pin the stable requirements, which I believe he is still working on.
Let's give him some time unless this is urgent.



So to move this forward, lets just pin novaclient on stable branches. so the
longer term pin all the reqs isn't blocking this.

Icehouse already has a cap, so we just need to wait for the juno cap to
land:

https://review.openstack.org/154680




Michael

On Tue, Feb 10, 2015 at 2:45 PM, melanie witt  wrote:

On Feb 6, 2015, at 8:17, Matt Riedemann 
wrote:


We haven't done a release of python-novaclient in awhile (2.20.0 was
released on 2014-9-20 before the Juno release).

It looks like there are some important feature adds and bug fixes on
master so we should do a release, specifically to pick up the change for
keystone v3 support [1].

So can this be done now or should this wait until closer to the Kilo
release (library releases are cheap so I don't see why we'd wait).


Thanks for bringing this up -- there are indeed a lot of important
features and fixes on master.

I agree we should do a release as soon as possible, and I don't think
there's any reason to wait until closer to Kilo.

melanie (melwitt)






__
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





--
Rackspace Australia

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




__
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







This was ready to go as of Monday. Can we really only have the PTL do 
this release?  As far as I know, any core on python-novaclient should be 
able to do this if they have a GPG key to launchpad, then they just need 
to push the tagged release per [1].  There is some launchpad bug cleanup 
and blueprint stuff to handle which is done in scripts somewhere [2], so 
maybe that's what holds this up?


[1] http://docs.openstack.org/infra/manual/drivers.html#tagging-a-release
[2] https://wiki.openstack.org/wiki/ReleaseTeam/How_To_Release

--

Thanks,

Matt Riedemann


__
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] [Ironic] *ED states strike back

[Dmitry Tantsur]

Hi everyone!

On one of our meetings [1] we agreed on keeping *ED states (DELETED, 
INSPECTED, CLEANED, etc) as no-ops for now. Since then, however, the 
inspection patch [2] got several comments from cores requesting removal 
of INSPECTED state. That was done by Nisha.


Today we decided to approve [2] and bring the discussion here. We can 
always add the state later, and blocking this patch again would be a bit 
unfair IMO. We'll create a follow-up to [2] if we decide that we need 
INSPECTED state.


So now, are we keeping/adding these *ED states to our state machine? I 
personally agree with what was discussed on the meeting, namely:

1. Keep *ED states
2. Make them no-ops, so that code that does INSPECTING -> MANAGEABLE 
right now will do INSPECTING -> INSPECTED -> MANAGEABLE instead.


Having INSPECTED is also useful for distinguish between OOB case (when 
inspect_hardware returns after having everything done) and in-band case 
(when inspect_hardware returns after initializing inspection). We could 
use return value of inspect_hardware being INSPECTING or INSPECTED.


WDYT?

Dmitry.

[1] 
http://eavesdrop.openstack.org/meetings/ironic/2015/ironic.2015-02-09-17.00.log.html 
starting 17:47

[2] https://review.openstack.org/#/c/147857/

__
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] [devstack] [Cinder-GlusterFS CI] centos7 gate job abrupt failures

[Deepak Shetty]

Hi clarkb, fungi,
   As discussed in
http://eavesdrop.openstack.org/irclogs/%23openstack-infra/%23openstack-infra.2015-02-19.log
( 2015-02-19T14:51:46 onwards), I am starting this thread to track the
abrupt job failures seen on cinder-glusterfs CI job in the recent past.

A small summary of the things that happened until now ...

For some reason we are seeing the centos7 glusterfs CI job getting
aborted/killed either by Java exception
or the build getting aborted due to timeout.

*1) 
**https://jenkins07.openstack.org/job/check-tempest-dsvm-full-glusterfs-centos7/35/consoleFull

- due to hudson Java exception*

*2)
https://jenkins07.openstack.org/job/check-tempest-dsvm-full-glusterfs-centos7/34/consoleFull

- due to build timeout*


For a list of all job failures, see

https://jenkins07.openstack.org/job/check-tempest-dsvm-full-glusterfs-centos7/

Most of the failures are of type #1

As a result of whcih the cinder-glusterfs CI job was removed ...
https://review.openstack.org/#/c/157213/

Per the discussion on IRC (see link above), fungi graciously agreed to
debug this as it looks like happening on the 'rax' provider. Thanks fungi
and clarkb :)

Hoping to root cause this soon and get the cinder-glusterfs CI job back
online soon.

thanx,
deepak
__
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] Match network topology in DB vs. network topology in nodes

[Kazuhiro Miyashita]

1. Query neutron data from DB
2. Discover to which computation node it belongs

you can query port's information with neutron command.
like "neutron port-list -c id -c device_owner" and find device_owner ==
compute:* ports.

and also find compute node witch port(and instance) deployed on.

you can find "instance id" and "vm host which instance deployed on"  and
 "network that port belongs to" and "vlan id from network(if you use vlan)"

3. In that node, access internal data and compare it with one that I read
from DB

I don't know how to get internal data of neutron agent directly. but you
can get peripheral information
from compute node.

like, access vm host with ssh(sshpass) and get flow information(ex:
ovs-ofctl dump-flows br-int) and ,
meta information  from ovs-db and iptables which security group and
security group rule's
instance.



2015-02-19 0:42 GMT+09:00 Leo Y :

> Hello,
>
> I am looking for a way to match information about network topology (such
> as interface+port or routing) that is stored in neutron DB vs. actual
> information that is known by the neutron agent(s) in the computation node.
>
> I like to do it in one of the following ways:
>
> Way #1:
>
> 1. Query neutron data from DB
> 2. Discover to which computation node it belongs
> 3. In that node, access internal data and compare it with one that I read
> from DB
>
> Way #2:
> 1. For each computation node, access internal data
> 2. Find this data in DB and verify that it match
>
> I don't know how I can access "internal data of neutron agent(s)" in the
> computation node. I would appreciate any help and advise.
>
> I am not sure if it is possible, to read a neutron data from DB and
> discover to which computation node it belongs. Please, advise if it is
> possible.
> --
> Regards,
> LeonidY
> -
> I enjoy the massacre of ads. This sentence will slaughter ads without a
> messy bloodbath
>
> __
> 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] [Ironic] *ED states strike back

[John Villalovos]

Can the *ED states be optional?  If a state would be a NO-OP, then don't
use it.  But if it is useful then use it.

It seems ugly to me to just have two 'change state' calls to move it
through the *ED state.

If an *ED state needs to be added later I think it could be added without
too much difficulty and the code will be cleaner without having 'no-op'
states.

WDYT?

John

On Thu, Feb 19, 2015 at 7:25 AM, Dmitry Tantsur  wrote:

> Hi everyone!
>
> On one of our meetings [1] we agreed on keeping *ED states (DELETED,
> INSPECTED, CLEANED, etc) as no-ops for now. Since then, however, the
> inspection patch [2] got several comments from cores requesting removal of
> INSPECTED state. That was done by Nisha.
>
> Today we decided to approve [2] and bring the discussion here. We can
> always add the state later, and blocking this patch again would be a bit
> unfair IMO. We'll create a follow-up to [2] if we decide that we need
> INSPECTED state.
>
> So now, are we keeping/adding these *ED states to our state machine? I
> personally agree with what was discussed on the meeting, namely:
> 1. Keep *ED states
> 2. Make them no-ops, so that code that does INSPECTING -> MANAGEABLE right
> now will do INSPECTING -> INSPECTED -> MANAGEABLE instead.
>
> Having INSPECTED is also useful for distinguish between OOB case (when
> inspect_hardware returns after having everything done) and in-band case
> (when inspect_hardware returns after initializing inspection). We could use
> return value of inspect_hardware being INSPECTING or INSPECTED.
>
> WDYT?
>
> Dmitry.
>
> [1] http://eavesdrop.openstack.org/meetings/ironic/2015/
> ironic.2015-02-09-17.00.log.html starting 17:47
> [2] https://review.openstack.org/#/c/147857/
>
> __
> 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] [Openstack-operators] Resources owned by a project/tenant are not cleaned up after that project is deleted from keystone

[Ian Cordasco]

On 2/2/15, 15:41, "Morgan Fainberg"  wrote:

>
>On February 2, 2015 at 1:31:14 PM, Joe Gordon (joe.gord...@gmail.com)
>wrote:
>
>
>
>On Mon, Feb 2, 2015 at 10:28 AM, Morgan Fainberg
> wrote:
>
>I think the simple answer is "yes". We (keystone) should emit
>notifications. And yes other projects should listen.
>
>The only thing really in discussion should be:
>
>1: soft delete or hard delete? Does the service mark it as orphaned, or
>just delete (leave this to nova, cinder, etc to discuss)
>
>2: how to cleanup when an event is missed (e.g rabbit bus goes out to
>lunch).
>
>
>
>
>
>
>I disagree slightly, I don't think projects should directly listen to the
>Keystone notifications I would rather have the API be something from a
>keystone owned library, say keystonemiddleware. So something like this:
>
>
>from keystonemiddleware import janitor
>
>
>keystone_janitor = janitor.Janitor()
>keystone_janitor.register_callback(nova.tenant_cleanup)
>
>
>keystone_janitor.spawn_greenthread()
>
>
>That way each project doesn't have to include a lot of boilerplate code,
>and keystone can easily modify/improve/upgrade the notification mechanism.
>
>
>
>
>
>
>
>
>
>
>
>Sure. I’d place this into an implementation detail of where that actually
>lives. I’d be fine with that being a part of Keystone Middleware Package
>(probably something separate from auth_token).
>
>
>—Morgan
>

I think my only concern is what should other projects do and how much do
we want to allow operators to configure this? I can imagine it being
preferable to have safe (without losing much data) policies for this as a
default and to allow operators to configure more destructive policies as
part of deploying certain services.


>
> 
>
>
>
>--Morgan
>
>Sent via mobile
>
>> On Feb 2, 2015, at 10:16, Matthew Treinish  wrote:
>>
>>> On Mon, Feb 02, 2015 at 11:46:53AM -0600, Matt Riedemann wrote:
>>> This came up in the operators mailing list back in June [1] but given
>>>the
>>> subject probably didn't get much attention.
>>>
>>> Basically there is a really old bug [2] from Grizzly that is still a
>>>problem
>>> and affects multiple projects.  A tenant can be deleted in Keystone
>>>even
>>> though other resources in other projects are under that project, and
>>>those
>>> resources aren't cleaned up.
>>
>> I agree this probably can be a major pain point for users. We've had to
>>work around it
>> in tempest by creating things like:
>>
>> 
>http://git.openstack.org/cgit/openstack/tempest/tree/tempest/cmd/cleanup_s
>ervice.py 
>service.py>
>> and
>> 
>http://git.openstack.org/cgit/openstack/tempest/tree/tempest/cmd/cleanup.p
>y 
>py>
>>
>> to ensure we aren't dangling resources after a run. But, this doesn't
>>work in
>> all cases either. (like with tenant isolation enabled)
>>
>> I also know there is a stackforge project that is attempting something
>>similar
>> here:
>>
>> http://git.openstack.org/cgit/stackforge/ospurge/
>>
>> It would be much nicer if the burden for doing this was taken off users
>>and this
>> was just handled cleanly under the covers.
>>
>>>
>>> Keystone implemented event notifications back in Havana [3] but the
>>>other
>>> projects aren't listening on them to know when a project has been
>>>deleted
>>> and act accordingly.
>>>
>>> The bug has several people saying "we should talk about this at the
>>>summit"
>>> for several summits, but I can't find any discussion or summit sessions
>>> related back to the bug.
>>>
>>> Given this is an operations and cross-project issue, I'd like to bring
>>>it up
>>> again for the Vancouver summit if there is still interest (which I'm
>>> assuming there is from operators).
>>
>> I'd definitely support having a cross-project session on this.
>>
>>>
>>> There is a blueprint specifically for the tenant deletion case but it's
>>> targeted at only Horizon [4].
>>>
>>> Is anyone still working on this? Is there sufficient interest in a
>>> cross-project session at the L summit?
>>>
>>> Thinking out loud, even if nova doesn't listen to events from
>>>keystone, we
>>> could at least have a periodic task that looks for instances where the
>>> tenant no longer exists in keystone and then take some action (log a
>>> warning, shutdown/archive/, reap, etc).
>>>
>>> There is also a spec for L to transfer instance ownership [5] which
>>>could
>>> maybe come into play, but I wouldn't depend on it.
>>>
>>> [1] 
>http://lists.openstack.org/pipermail/openstack-operators/2014-June/004559.
>html 
>.html>
>>> [2] https://bugs.launchpad.net/nova/+bug/967832
>>> [3] 
>https://blueprints.launchpad.net/keystone/+spec/notifications
>
>>> [4] 
>https://blueprints.launchpad.net/horizon/+spec/tenant-deletion
>

[openstack-dev] Communication is illegal in the EU (was: The root-cause for IRC private channels)

[Jeremy Stanley]

On 2015-02-19 12:12:30 + (+), Kuvaja, Erno wrote:
[...]
> [3] The data protection rules are applicable not only when the
> controller is established within the EU, but whenever the
> controller uses equipment situated within the EU in order to
> process data. (art. 4) Controllers from outside the EU, processing
> data in the EU, will have to follow data protection regulation. In
> principle, any online business trading with EU citizens would
> process some personal data and would be using equipment in the EU
> to process the data (i.e. the customer's computer). As a
> consequence, the website operator would have to comply with the
> European data protection rules. The directive was written before
> the breakthrough of the Internet, and to date there is little
> jurisprudence on this subject.
[...]

Setting aside the fact that none of the machines our project is
officially maintaining are located in the EU, and the fact that we
are not a business and have no customers, this argument is drifting
into absurd territory.

By extension your assertions would apply to our mailing lists, our
code review system, our source code repositories... sorry, but no. I
assume if the EU wants it can instead forbid EU citizens from
participating in this project? I think this is getting rapidly off
topic and should probably be moved to
legal-disc...@lists.openstack.org instead if you wish to continue
such a debate.
-- 
Jeremy Stanley

__
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] Zuul failure

[Manickam, Kanagaraj]

Hi,

Following error is being reported by zuul and any one facing this issue ?

zuul is failing with "No valid host was found. There are not enough hosts 
available"  for https://review.openstack.org/#/c/153999/.
I tried twice to build this patch and same error is reported. I think this 
error is something to do with zuul test environment.

How to overcome this issue? Any help is appreciated . Thanks.

Regards
Kanagaraj M

__
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] [Fuel] Additional user account in the OpenStack for fetching OpenStack workloads

[Andrew Woodward]

We should assume that the admin credentials are already invalid. We have
some possible options that I can think of

Create an additional user. The risk here is that it will be deleted,
disabled or re-keyed as the same with admin.
Use the existing service accounts (nova, neutron, keystone, cinder) (this
is the plan for removing deps on ~/openrc)


> The questions are:
>
>1. Is anybody have feature, which also requires additional OpenStack
>user?
>
> moving from admin / openrc back to service accounts

>
>1. We need only readonly access for fetching workloads. But if anybody
>want to use this user for other tasks, we can grant required rights to the
>user. Should we create user with full access or restrict them to readonly
>access?
>
> read only would be preferred, we should have the least amount of access
possible to complete the snooping. It reduces attack surfaces

>
>1. Is the credentials of user should be the same for all environments?
>
> I would attempt to keep them unique per env

>
>1. Where the best place for storing credentials of the user? DB or
>yaml?
>
> It will have to be sent to the yaml in order to get the deployment task to
create it, but you will also want to store it in the db.

>
>1. Should we have UI for changing credentials?
>
> Yes, we should probably be able to change the credential, however I could
see it being postponed untill 7.0

>
>1. May be we should use 'admin' user credentials and just notify in
>the UI if credentials are not valid and we can't collect workloads?
>
> We can and should consider the admin credentials invalid and should not
use them

Please, share your thoughts.
>



On Tue, Feb 10, 2015 at 3:02 AM, Alexander Kislitsky <
akislit...@mirantis.com> wrote:

> Folks,
>
> We are collecting OpenStack workloads stats. For authentication in the
> keystone we are using admin user credentials from Nailgun. Credentials can
> be changed directly in the OpenStack and we will loose possibility of
> fetching information.
>
> This issue can be fixed by creation additional user account:
>
>1. I propose to generate additional user credentials after master node
>is installed and store it into master_node_settings table in the Nailgun.
>2. Add abstraction layer into
>
> https://github.com/stackforge/fuel-web/blob/master/nailgun/nailgun/statistics/utils.py#L47
>for creating additional user in the OpenStack if it isn't exists.
>
> But this additional user can be useful for other purposes and may be we
> should save credentials in other place (settings.yaml for example). And may
> be creation of the additional user should be implemented outside of stats
> collecting feature and may be outside of Nailgun.
>
> Please share your thoughts on this.
>
> __
> 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
>
>


-- 
Andrew
Mirantis
Fuel community ambassador
Ceph community
__
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] [Fuel]Adding compute node on existing environment

[Andrew Woodward]

Neophy,

You need to connect at least one nic to the Admin PXE network that is used
by the fuel master, The other nics will need to be connected to their
respective network counterparts that the physical nodes have.

For vmware, you guest needs to use e1000 nic type if you are going to use
neutron (ovs). The vswitches must have all three security options set to
permissive.

On Thu, Feb 19, 2015 at 2:51 AM, Foss Geek  wrote:

> Dear All,
>
> I have Openstack HA environment (all are physical machine) deployed using
> Fuel 5.1. I want to bring one more compute node in VM(VM is running in
> vCenter and configured 4 nic).
>
> How to deploy a compute node in VM and bring this to existing openstack
> environment?
>
> Any help.
>
> --
> Thanks & Regards
> E-Mail: thefossg...@gmail.com
> IRC: neophy
> Blog : http://lmohanphy.livejournal.com/
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Andrew
Mirantis
Fuel community ambassador
Ceph community
__
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] [keystone] [trusts] [all] How trusts should work by design?

[Renat Akhmerov]

> On 19 Feb 2015, at 18:32, Alexander Makarov  wrote:
> 
> @Renat, They are conceptually different:
> - regular tokens are created for the owner of addressed resource
> - trust scoped tokens are for trustees and have some security restrictions.
> The case is about disallowing a trustee to aquire a regular token allowing 
> him anything the trustor is allowed. It'd be an exploit.


Alexander,

Thanks for explanations. I kind of get the general idea, yes. What is best 
source where we could go and read in details about that? The only page I was 
able to find is https://wiki.openstack.org/wiki/Keystone/Trusts 
 but it would be nice if 
something more tutorial-like existed.

Renat Akhmerov
@ Mirantis Inc.

__
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] [nova][vmware] HA and image caching

[Matthew Booth]

I was discussing the problems of configuring active/passive HA earlier
where the active and passive nodes have a different `host` configured.
There are lots of problems, as I've mentioned before, but Gary pointed
out that it probably affects image cache management, too. This had the
potential for unsubtle breakage, so I decided to check it out in a bit
more detail. The bug is real, but fortunately doesn't delete anything
(which is itself a bug):

  storage_users.register_storage_use(CONF.instances_path, CONF.host)
  nodes = storage_users.get_storage_users(CONF.instances_path)

This bit of code assumes shared storage between different nova nodes
which access the same images. We don't have that, so `nodes` above is
going to contain only the current node.

  filters = {'deleted': False,
 'soft_deleted': True,
 'host': nodes}
  filtered_instances = objects.InstanceList.get_by_filters(context,
   filters, expected_attrs=[], use_slave=True)

We're getting a list of instances which were created by the current node
only.

  self.driver.manage_image_cache(context, filtered_instances)

Which we're passing to the driver.

So, the driver is only going to consider images attached to instances
which were created by the current node. The effect of this is that just
after a switchover, cache management will not consider any instances,
and therefore nothing will be expired. This is still bad, but it's not
going to delete users' stuff.

Incidentally, I remain convinced that we can safely configure
active/passive HA if we configure all nodes with the same `host`. That
way we wouldn't have to worry about all these edge cases, and we
wouldn't need to eventually create a cleanup job to consolidate all
instances running on a single hypervisor to have the same 'host'.

Matt
-- 
Matthew Booth
Red Hat Engineering, Virtualisation Team

Phone: +442070094448 (UK)
GPG ID:  D33C3490
GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490

__
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] [Ironic] *ED states strike back

[Ruby Loo]

I think that if there is a use case for an *ED state, then we should have
it. And if we have one *ED state, I think it makes sense (and is
consistent) to have them for all the active states.

If we have *ED states, I would prefer that we add them in when the active
state is added. So add ING, ED, FAIL. If a particular
driver has nothing it wants to do in an *ED state, it can cause a
transition from the *ED state to the passive/stable state.

I don't want the *ED states to be optional because that puts the onus on
the developer that needs the *ED state, to add it in (assuming they are
aware that this is possible) and put in whatever plumbing might be needed.
Which may mean that they'd have to modify code in another driver, that
didn't need *ED in the first place. (If an *ED state is added, all drivers
using that active state should handle the *ED state too because it is in
the state machine and I'd rather not complicate things by having state-ING
-> state-ED -> stable-state and state-ING -> stable-state.

--ruby
__
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] release request for python-novaclient

[Thierry Carrez]

Matt Riedemann wrote:
> This was ready to go as of Monday. Can we really only have the PTL do
> this release?  As far as I know, any core on python-novaclient should be
> able to do this if they have a GPG key to launchpad, then they just need
> to push the tagged release per [1].

The way python-novaclient is set up in gerrit, only nova-release can
push tags:

https://review.openstack.org/#/admin/projects/openstack/python-novaclient,access

Current membership is:
https://review.openstack.org/#/admin/groups/147,members

-- 
Thierry Carrez (ttx)

__
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][firewall] Updating spoofing rules when launching a VM

[Nader Lahouti]

Hi,

I have been using openstack in multi-node setup - pre stable/juno release -
and recently updated the setup to stable/juno and noticed after launching
an instance, spoofing rules on all compute nodes are getting updated,
whereas updating spoofing rules only on the compute node the instance is
launched.

The neutron code base that I'm using and seeing that behavior is:
--
commit d7645ee1e2fc0565b74c4b1d5e5c038330249d7e
Merge: dbeaa70 7cd3d0c
Author: Jenkins 
Date:   Wed Feb 11 12:16:20 2015 +

Merge "Decrease rpc timeout after agent receives SIGTERM" into
stable/juno
--
Has behavior of updating firewall rules after launching a VM, been changed
with stable/juno?

Thanks in advance for your reply.

Nader.
__
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] [magnetodb] Weekly meetings

[Andrey Ostapenko]

Hi, magnetians!

Just to remind that our IRC weekly meetings are held every week on
Thursdays 14:00 UTC at #magnetodb on Freenode. Please join.
Meeting agenda:
https://wiki.openstack.org/wiki/MagnetoDB/WeeklyMeetingAgenda
If you have an item to share, please add it to agenda.

Andrey Ostapenko
__
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] [all][oslo] Dealing with database connection sharing issues

[Ben Nemec]

Hi,

Mike Bayer recently tracked down an issue with database errors in Cinder
to a single database connection being shared over multiple processes.
This is not something that should happen, and it turns out to cause
intermittent failures in the Cinder volume service.  Full details can be
found in the bug here: https://bugs.launchpad.net/cinder/+bug/1417018
and his mailing list thread here:
http://lists.openstack.org/pipermail/openstack-dev/2015-February/057184.html

The question we're facing is what to do about it.  There's quite a lot
of discussion on https://review.openstack.org/#/c/156725 and in
http://eavesdrop.openstack.org/irclogs/%23openstack-oslo/%23openstack-oslo.2015-02-18.log
starting at 2015-02-18T21:38:12  but I'll try to summarize it here.

On the plus side, we have a way to detect this sort of thing in oslo.db.
That's what Mike's change 156725 is about.  On the minus side,
recovering from this in oslo.db is papering over a legitimate problem in
the calling service, and a lot of the discussion has been around how to
communicate that to the calling service.  A few options that have been
mentioned:

1) Leave the linked change as-is, with a warning logged that will
hopefully be seen and prompt a fix in the service.

The concerns raised with this is that the warning log level is a very
operator-visible thing and there's nothing an operator can do to fix
this other than pester the developers.  Also, it seems developers tend
to ignore logs, so it's unlikely they'll pick up on it themselves.

Note that while the errors resulting from this situation are
intermittent, the actual situation happens on every start up of
cinder-volume, so these messages will always be logged as it stands today.

2) Change the log message to debug.

This is the developer-focused log level, but as noted above developers
tend to ignore logs and it will be very easy for the message to get lost
in the debug noise.  This option would likely require someone to go
specifically looking for the error to find it.

3) Make the error a hard failure.

Rather than hide the error by recovering, fail immediately when it's
detected.  This has the problem of making all the existing Cinder code
(and any other services with the same problem) in the wild incompatible
with any new releases of oslo.db, but it's about the only way to make
sure the error will be addressed now and in any future occurrences.

4) Leave the bug alone for now and just log a message so we can find out
how widespread this problem actually is.

At the moment we only know it exists in Cinder, but due to the way the
service code works it's quite possible other projects have the same
problem and don't know it yet.

5) Allow this sort of connection sharing to continue for a deprecation
period with apppropriate logging, then make it a hard failure.

This would provide services time to find and fix any sharing problems
they might have, but would delay the timeframe for a final fix.

6-ish) Fix oslo-incubator service.py to close all file descriptors after
forking.

This is a best practice anyway so it's something we intend to pursue,
but it's probably more of a long-term fix because it will take some work
to implement and make sure it doesn't break existing services.  It also
papers over the problem and according to Mike is basically a slower and
messier alternative to his current proposed change, so it's probably a
tangential change to avoid this in the future as opposed to a solution.

If you've made it this far, thank you and please provide thoughts on the
options presented above. :-)

-Ben

__
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] [keystone] [trusts] [all] How trusts should work by design?

[Alexander Makarov]

@Renat, I like the idea. For now we have a spec:
https://github.com/openstack/keystone-specs/blob/master/api/v3/identity-api-v3-os-trust-ext.rst
It's consiedered to be enough but as for me it lacks TL;DR section :)

On Thu, Feb 19, 2015 at 8:15 PM, Renat Akhmerov 
wrote:

>
> On 19 Feb 2015, at 18:32, Alexander Makarov  wrote:
>
> @Renat, They are conceptually different:
> - regular tokens are created for the owner of addressed resource
> - trust scoped tokens are for trustees and have some security restrictions.
> The case is about disallowing a trustee to aquire a regular token allowing
> him anything the trustor is allowed. It'd be an exploit.
>
>
> Alexander,
>
> Thanks for explanations. I kind of get the general idea, yes. What is best
> source where we could go and read in details about that? The only page I
> was able to find is https://wiki.openstack.org/wiki/Keystone/Trusts but
> it would be nice if something more tutorial-like existed.
>
> Renat Akhmerov
> @ Mirantis Inc.
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Kind Regards,
Alexander Makarov,
Senoir Software Developer,

Mirantis, Inc.
35b/3, Vorontsovskaya St., 109147, Moscow, Russia

Tel.: +7 (495) 640-49-04
Tel.: +7 (926) 204-50-60

Skype: MAKAPOB.AJIEKCAHDP
__
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] release request for python-novaclient

[Michael Still]

Sorry, I dropped the ball here. This is now released.

As promised last week in the nova meeting I've checked the docs on the
wiki for releases
(https://wiki.openstack.org/wiki/Nova/Client_Release_Process) and
fixed some small errors. I'll look at adding John Garbutt and Matt
Riedemann to the novaclient release group now.

Michael

On Fri, Feb 20, 2015 at 2:12 AM, Matt Riedemann
 wrote:
>
>
> On 2/12/2015 6:55 PM, Michael Still wrote:
>>
>> This was discussed in the nova meeting this morning. In that meeting
>> we declared ourselves unwedged and ready to do a release, and I said
>> I'd do that today.
>>
>> On reflection, I want to recant just a little -- I think its a bad
>> idea for me to do a release on a Friday. So, I'll do this early next
>> week instead.
>>
>> Michael
>>
>> On Wed, Feb 11, 2015 at 8:51 AM, Joe Gordon  wrote:
>>>
>>>
>>>
>>> On Mon, Feb 9, 2015 at 7:55 PM, Michael Still  wrote:


 The previous policy is that we do a release "when requested" or when a
 critical bug fix merges. I don't see any critical fixes awaiting
 release, but I am not opposed to a release.

 The reason I didn't do this yesterday is that Joe wanted some time to
 pin the stable requirements, which I believe he is still working on.
 Let's give him some time unless this is urgent.

>>>
>>> So to move this forward, lets just pin novaclient on stable branches. so
>>> the
>>> longer term pin all the reqs isn't blocking this.
>>>
>>> Icehouse already has a cap, so we just need to wait for the juno cap to
>>> land:
>>>
>>> https://review.openstack.org/154680
>>>
>>>

 Michael

 On Tue, Feb 10, 2015 at 2:45 PM, melanie witt 
 wrote:
>
> On Feb 6, 2015, at 8:17, Matt Riedemann 
> wrote:
>
>> We haven't done a release of python-novaclient in awhile (2.20.0 was
>> released on 2014-9-20 before the Juno release).
>>
>> It looks like there are some important feature adds and bug fixes on
>> master so we should do a release, specifically to pick up the change
>> for
>> keystone v3 support [1].
>>
>> So can this be done now or should this wait until closer to the Kilo
>> release (library releases are cheap so I don't see why we'd wait).
>
>
> Thanks for bringing this up -- there are indeed a lot of important
> features and fixes on master.
>
> I agree we should do a release as soon as possible, and I don't think
> there's any reason to wait until closer to Kilo.
>
> melanie (melwitt)
>
>
>
>
>
>
>
> __
> 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
>



 --
 Rackspace Australia


 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>>
>>>
>>>
>>> __
>>> 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
>>>
>>
>>
>>
>
> This was ready to go as of Monday. Can we really only have the PTL do this
> release?  As far as I know, any core on python-novaclient should be able to
> do this if they have a GPG key to launchpad, then they just need to push the
> tagged release per [1].  There is some launchpad bug cleanup and blueprint
> stuff to handle which is done in scripts somewhere [2], so maybe that's what
> holds this up?
>
> [1] http://docs.openstack.org/infra/manual/drivers.html#tagging-a-release
> [2] https://wiki.openstack.org/wiki/ReleaseTeam/How_To_Release
>
> --
>
> Thanks,
>
> Matt Riedemann
>
>
>
> __
> 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



-- 
Rackspace Australia

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

[openstack-dev] Call for mentors - Upstream Training, Google Summer of Code, Outreachy (AKA OPW) [all]

[Stefano Maffulli]

Hello folks

we have a bunch of upcoming initiatives to help out new contributors to
OpenStack and we need mentors willing to help newcomers go from zero to
(at least) one merged patch.

OpenStack has always been a welcoming community despite being complex to
navigate for new contributors. If you remember your first patch you know
what I mean :) If you want to spare a fellow colleague some of that
pain, consider adding your name to this wiki page:

 https://wiki.openstack.org/wiki/Mentors

I and other volunteers will be contacting you to help in the specific
programs mentioned in the subject.

Thanks,
stef


__
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] The strange case of osapi_compute_unique_server_name_scope

[Jay Pipes]

On 02/19/2015 05:18 AM, Matthew Booth wrote:

Nova contains a config variable osapi_compute_unique_server_name_scope.
Its help text describes it pretty well:

When set, compute API will consider duplicate hostnames invalid within
the specified scope, regardless of case. Should be empty, "project" or
"global".

So, by default hostnames are not unique, but depending on this setting
they could be unique either globally or in the scope of a project.

Ideally a unique constraint would be enforced by the database but,
presumably because this is a config variable, that isn't the case here.
Instead it is enforced in code, but the code which does this predictably
races. My first attempt to fix this using the obvious SQL solution
appeared to work, but actually fails in MySQL as it doesn't support that
query structure[1][2]. SQLite and PostgreSQL do support it, but they
don't support the query structure which MySQL supports. Note that this
isn't just a syntactic thing. It looks like it's still possible to do
this if we compound the workaround with a second workaround, but I'm
starting to wonder if we'd be better fixing the design.

First off, do we need this config variable? Is anybody actually using
it? I suspect the answer's going to be yes, but it would be extremely
convenient if it's not.

Assuming this configurability is required, is there any way we can
instead use it to control a unique constraint in the db at service
startup? This would be something akin to a db migration. How do we
manage those?

Related to the above, I'm not 100% clear on which services run this
code. Is it possible for different services to have a different
configuration of this variable, and does that make sense? If so, that
would preclude a unique constraint in the db.


Is there a bug that you are attempting to fix here? If not, I'd suggest 
just leaving this code as it is...


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-dev] [ironic] Ironic 2014.2.1 released

[Adam Gandelman]

Hello-

The Ironic team is pleased to announce the release of the 2014.2.1 stable
Juno release.  This release contains a number of backported fixes that have
accrued in our stable branch since the release of 2014.2. These updates to
Juno are intended to be low risk with no intentional
regressions or API changes. The list of bugs, tarballs and other milestone
information for this release may be found on Launchpad:

https://bugs.launchpad.net/ironic/+milestone/2014.2.1

Note that Ironic is not included in the set of 2014.2 projects that receive
scheduled point releases by the stable maintenance team. This release comes
separate from those coordinated point releases.

Thanks,
Adam
__
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] [Fuel]Adding compute node on existing environment

[Foss Geek]

Hi xarses,

As you said, I changed  nic type from vmxnet3 to e1000 and set security
policy to permissive for all the networks. Now I am able to successfully
deploy VM as additional compute node in existing openstack environment.

Thanks for you time!

-- 
Thanks & Regards
E-Mail: thefossg...@gmail.com
IRC: neophy
Blog : http://lmohanphy.livejournal.com/



On Thu, Feb 19, 2015 at 10:40 PM, Andrew Woodward  wrote:

> Neophy,
>
> You need to connect at least one nic to the Admin PXE network that is used
> by the fuel master, The other nics will need to be connected to their
> respective network counterparts that the physical nodes have.
>
> For vmware, you guest needs to use e1000 nic type if you are going to use
> neutron (ovs). The vswitches must have all three security options set to
> permissive.
>
> On Thu, Feb 19, 2015 at 2:51 AM, Foss Geek  wrote:
>
>> Dear All,
>>
>> I have Openstack HA environment (all are physical machine) deployed using
>> Fuel 5.1. I want to bring one more compute node in VM(VM is running in
>> vCenter and configured 4 nic).
>>
>> How to deploy a compute node in VM and bring this to existing openstack
>> environment?
>>
>> Any help.
>>
>> --
>> Thanks & Regards
>> E-Mail: thefossg...@gmail.com
>> IRC: neophy
>> Blog : http://lmohanphy.livejournal.com/
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> Andrew
> Mirantis
> Fuel community ambassador
> Ceph community
>
> __
> 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] [Keystone] Deprecation of Eventlet deployment in Kilo (Removal for "M"-release)

[Morgan Fainberg]

The Keystone development team is planning to deprecate deployment of Keystone 
under Eventlet during the Kilo cycle. Support for deploying under eventlet will 
be dropped as of the “M”-release of OpenStack.

The reasoning behind this move is multifaceted but the core of the reasons are 
as follows:

Keystone relies on apache/web-server modules to handle federated identity 
(validation of SAML, etc) and similar SSO type authentication (Kerberos).
Eventlet has proven problematic when it comes to workloads within Keystone, 
notably that a number of actions cannot yield (either due to lacking in 
Eventlet, or that the dependent library uses C-bindings that eventlet is not 
able to work with).
Keystone has recommended (for multiple cycles) deploying Keystone under apache 
instead of eventlet. In the gate we primarily test all new development under 
Apache/mod_wsgi deployments. 
Most deployers I’ve discussed keystone deployment with are either already on 
httpd+mod_wsgi or looking to move that direction (for support of features such 
as federated auth).
The review to finalize the deprecation is: 
https://review.openstack.org/#/c/157495/ (Please only provide comments on 
deprecation, verbiage can be modified separately from the actual act of 
deprecation).

Please comment on the review or in reply to this Email.

Thanks,
—Morgan

-- 
Morgan Fainberg__
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] release request for python-novaclient

[Terry Wilson]

> Sorry, I dropped the ball here. This is now released.

Unfortunately, the new novaclient release ended up completely breaking the 
neutron gate. The v1_1 deprecation broke our (voting) pylint test: 
https://jenkins04.openstack.org/job/gate-neutron-pylint/1383/console

2015-02-19 18:37:06.932 | Module neutron.notifiers.nova
2015-02-19 18:37:06.932 | No name 'client' in module 'novaclient.v1_1' 
(no-name-in-module)
2015-02-19 18:37:06.932 | No name 'contrib' in module 
'novaclient.v1_1'(no-name-in-module)
2015-02-19 18:37:06.932 | Module neutron.plugins.cisco.l3.service_vm_lib
2015-02-19 18:37:06.932 | No name 'client' in module 'novaclient.v1_1' 
(no-name-in-module)


Terry

__
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] [nova] release request for python-novaclient

[Andrey Kurilin]

Imo, neutron has wrong usage of novaclient.
https://review.openstack.org/#/c/152907/ should fix this issue.

On Thursday, February 19, 2015, Terry Wilson > wrote:

> > Sorry, I dropped the ball here. This is now released. Unfortunately, the
> new novaclient release ended up completely breaking the neutron gate. The
> v1_1 deprecation broke our (voting) pylint test:
> https://jenkins04.openstack.org/job/gate-neutron-pylint/1383/console
> 2015-02-19 18:37:06.932 |  Module neutron.notifiers.nova 2015-02-19
> 18:37:06.932 |  No name 'client' in module 'novaclient.v1_1' (
> no-name-in-module) 2015-02-19 18:37:06.932 |  No name 'contrib' in module
> 'novaclient.v1_1' (no-name-in-module 2015-02-19 18:37:06.932 |  Module
> neutron.plugins.cisco.l3.service_vm_lib 2015-02-19 18:37:06.932 |  No name
> 'client' in module 'novaclient.v1_1' no-name-in-module Terry
> __
> OpenStack Development Mailing List (not for usage questions) Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Best regards,
Andrey Kurilin.
__
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] release request for python-novaclient

[melanie witt]

On Feb 19, 2015, at 11:52, Terry Wilson  wrote:

> Unfortunately, the new novaclient release ended up completely breaking the 
> neutron gate. The v1_1 deprecation broke our (voting) pylint test: 
> https://jenkins04.openstack.org/job/gate-neutron-pylint/1383/console
> 
> 2015-02-19 18:37:06.932 | Module neutron.notifiers.nova
> 2015-02-19 18:37:06.932 | No name 'client' in module 'novaclient.v1_1' 
> (no-name-in-module)
> 2015-02-19 18:37:06.932 | No name 'contrib' in module 
> 'novaclient.v1_1'(no-name-in-module)
> 2015-02-19 18:37:06.932 | Module neutron.plugins.cisco.l3.service_vm_lib
> 2015-02-19 18:37:06.932 | No name 'client' in module 'novaclient.v1_1' 
> (no-name-in-module)

Hi Terry,

Sorry to hear about this. I looked into this and the problem is pylint can't 
parse the backward-compatibility we have for the v1_1 deprecation:

https://review.openstack.org/#/c/149006/13/novaclient/v1_1/__init__.py,cm

The actual code should work but pylint static checking will fail to follow it. 
So far, the options I see to handle it are to either patch 
s/novaclient.v1_1/novaclient.v2/ in neutron or suppress the specific pylint 
check that's failing (if it's not too broad).

Do you find either of these options acceptable, or have another idea?

Thanks,
melanie (melwitt)






signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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] release request for python-novaclient

[Michael Still]

I can do another release if needed once we've landed a fix, although
it sounds like this can be fixed in neutron?

Michael

On Fri, Feb 20, 2015 at 7:33 AM, melanie witt  wrote:
> On Feb 19, 2015, at 11:52, Terry Wilson  wrote:
>
>> Unfortunately, the new novaclient release ended up completely breaking the 
>> neutron gate. The v1_1 deprecation broke our (voting) pylint test: 
>> https://jenkins04.openstack.org/job/gate-neutron-pylint/1383/console
>>
>> 2015-02-19 18:37:06.932 |  Module neutron.notifiers.nova [0m
>> 2015-02-19 18:37:06.932 |  No name 'client' in module 'novaclient.v1_1' ( 
>> no-name-in-module)
>> 2015-02-19 18:37:06.932 |  No name 'contrib' in module 'novaclient.v1_1' 
>> (no-name-in-module )
>> 2015-02-19 18:37:06.932 |  Module neutron.plugins.cisco.l3.service_vm_lib
>> 2015-02-19 18:37:06.932 |  No name 'client' in module 'novaclient.v1_1'  ( 
>> no-name-in-module )
>
> Hi Terry,
>
> Sorry to hear about this. I looked into this and the problem is pylint can't 
> parse the backward-compatibility we have for the v1_1 deprecation:
>
> https://review.openstack.org/#/c/149006/13/novaclient/v1_1/__init__.py,cm
>
> The actual code should work but pylint static checking will fail to follow 
> it. So far, the options I see to handle it are to either patch 
> s/novaclient.v1_1/novaclient.v2/ in neutron or suppress the specific pylint 
> check that's failing (if it's not too broad).
>
> Do you find either of these options acceptable, or have another idea?
>
> Thanks,
> melanie (melwitt)
>
>
>
>
>
> __
> 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
>



-- 
Rackspace Australia

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

Re: [openstack-dev] [all][oslo] Dealing with database connection sharing issues

[Doug Hellmann]

On Thu, Feb 19, 2015, at 01:09 PM, Ben Nemec wrote:
> Hi,
> 
> Mike Bayer recently tracked down an issue with database errors in Cinder
> to a single database connection being shared over multiple processes.
> This is not something that should happen, and it turns out to cause
> intermittent failures in the Cinder volume service.  Full details can be
> found in the bug here: https://bugs.launchpad.net/cinder/+bug/1417018
> and his mailing list thread here:
> http://lists.openstack.org/pipermail/openstack-dev/2015-February/057184.html
> 
> The question we're facing is what to do about it.  There's quite a lot
> of discussion on https://review.openstack.org/#/c/156725 and in
> http://eavesdrop.openstack.org/irclogs/%23openstack-oslo/%23openstack-oslo.2015-02-18.log
> starting at 2015-02-18T21:38:12  but I'll try to summarize it here.
> 
> On the plus side, we have a way to detect this sort of thing in oslo.db.
> That's what Mike's change 156725 is about.  On the minus side,
> recovering from this in oslo.db is papering over a legitimate problem in
> the calling service, and a lot of the discussion has been around how to
> communicate that to the calling service.  A few options that have been
> mentioned:
> 
> 1) Leave the linked change as-is, with a warning logged that will
> hopefully be seen and prompt a fix in the service.
> 
> The concerns raised with this is that the warning log level is a very
> operator-visible thing and there's nothing an operator can do to fix
> this other than pester the developers.  Also, it seems developers tend
> to ignore logs, so it's unlikely they'll pick up on it themselves.
> 
> Note that while the errors resulting from this situation are
> intermittent, the actual situation happens on every start up of
> cinder-volume, so these messages will always be logged as it stands
> today.
> 
> 2) Change the log message to debug.
> 
> This is the developer-focused log level, but as noted above developers
> tend to ignore logs and it will be very easy for the message to get lost
> in the debug noise.  This option would likely require someone to go
> specifically looking for the error to find it.
> 
> 3) Make the error a hard failure.
> 
> Rather than hide the error by recovering, fail immediately when it's
> detected.  This has the problem of making all the existing Cinder code
> (and any other services with the same problem) in the wild incompatible
> with any new releases of oslo.db, but it's about the only way to make
> sure the error will be addressed now and in any future occurrences.
> 
> 4) Leave the bug alone for now and just log a message so we can find out
> how widespread this problem actually is.
> 
> At the moment we only know it exists in Cinder, but due to the way the
> service code works it's quite possible other projects have the same
> problem and don't know it yet.
> 
> 5) Allow this sort of connection sharing to continue for a deprecation
> period with apppropriate logging, then make it a hard failure.
> 
> This would provide services time to find and fix any sharing problems
> they might have, but would delay the timeframe for a final fix.
> 
> 6-ish) Fix oslo-incubator service.py to close all file descriptors after
> forking.
> 
> This is a best practice anyway so it's something we intend to pursue,
> but it's probably more of a long-term fix because it will take some work
> to implement and make sure it doesn't break existing services.  It also
> papers over the problem and according to Mike is basically a slower and
> messier alternative to his current proposed change, so it's probably a
> tangential change to avoid this in the future as opposed to a solution.
> 
> If you've made it this far, thank you and please provide thoughts on the
> options presented above. :-)

I'm not sure why 6 is "slower", can someone elaborate on that?

Doug

> 
> -Ben
> 
> __
> 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] release request for python-novaclient

[Dan Smith]

> I can do another release if needed once we've landed a fix, although
> it sounds like this can be fixed in neutron?

It's just pylint being silly, from the sound of it. I don't think there
is anything we need to do in novaclient, since the transition adapter
works. Either convince neutron pylint not to care, or just convert the
uses in neutron to v2.

--Dan



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

Re: [openstack-dev] Error Enabling Federation Extension

[Akshik DBK]

Hi,i followed 
http://docs.openstack.org/developer/keystone/configure_federation.html, im 
using icehouse on ubuntu 12.04

From: aks...@outlook.com
To: openstack-dev@lists.openstack.org
Subject: Error Enabling Federation Extension
Date: Thu, 19 Feb 2015 17:22:36 +0530




im getting “Target WSGI script ‘/var/www/cgi-bin/keystone/main’ cannot be 
loaded as Python module”while configuring federation for keystone any help
[info] [client 10.10.10.12] mod_wsgi (pid=25248, process=’keystone’, 
application=’10.1.193.250:5000|’): Loading WSGI script 
‘/var/www/cgi-bin/keystone/main’.[error] [client 10.10.10.12] mod_wsgi 
(pid=25248): Target WSGI script ‘/var/www/cgi-bin/keystone/main’ cannot be 
loaded as Python module.[error] [client 10.10.10.12] mod_wsgi (pid=25248): 
Exception occurred processing WSGI script 
‘/var/www/cgi-bin/keystone/main’.[error] [client 10.10.10.12] Traceback (most 
recent call last):[error] [client 10.10.10.12] File 
“/var/www/cgi-bin/keystone/main”, line 21, in[error] [client 10.10.10.12] 
config.configure()[error] [client 10.10.10.12] File 
“/usr/lib/python2.7/dist-packages/keystone/common/config.py”, line 694, in 
configure[error] [client 10.10.10.12] help=’Do not monkey-patch threading 
system modules.’))[error] [client 10.10.10.12] File 
“/usr/lib/python2.7/dist-packages/oslo/config/cfg.py”, line 1579, in 
__inner[error] [client 10.10.10.12] result = f(self, *args, **kwargs)[error] 
[client 10.10.10.12] File 
“/usr/lib/python2.7/dist-packages/oslo/config/cfg.py”, line 1731, in 
register_cli_opt[error] [client 10.10.10.12] raise 
ArgsAlreadyParsedError(“cannot register CLI option”)[error] [client 
10.10.10.12] ArgsAlreadyParsedError: arguments already parsed: cannot register 
CLI option  
   __
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] [stable][requirements] External dependency caps introduced in 499db6b

[Joe Gordon]

On Wed, Feb 18, 2015 at 7:14 AM, Doug Hellmann 
wrote:

>
>
> On Wed, Feb 18, 2015, at 10:07 AM, Donald Stufft wrote:
> >
> > > On Feb 18, 2015, at 10:00 AM, Doug Hellmann 
> wrote:
> > >
> > >
> > >
> > > On Tue, Feb 17, 2015, at 03:17 PM, Joe Gordon wrote:
> > >> On Tue, Feb 17, 2015 at 4:19 AM, Sean Dague  wrote:
> > >>
> > >>> On 02/16/2015 08:50 PM, Ian Cordasco wrote:
> >  On 2/16/15, 16:08, "Sean Dague"  wrote:
> > 
> > > On 02/16/2015 02:08 PM, Doug Hellmann wrote:
> > >>
> > >>
> > >> On Mon, Feb 16, 2015, at 01:01 PM, Ian Cordasco wrote:
> > >>> Hey everyone,
> > >>>
> > >>> The os-ansible-deployment team was working on updates to add
> support
> > >>> for
> > >>> the latest version of juno and noticed some interesting version
> > >>> specifiers
> > >>> introduced into global-requirements.txt in January. It
> introduced some
> > >>> version specifiers that seem a bit impossible like the one for
> > >>> requests
> > >>> [1]. There are others that equate presently to pinning the
> versions of
> > >>> the
> > >>> packages [2, 3, 4].
> > >>>
> > >>> I understand fully and support the commit because of how it
> improves
> > >>> pretty much everyone’s quality of life (no fires to put out in
> the
> > >>> middle
> > >>> of the night on the weekend). I’m also aware that a lot of the
> > >>> downstream
> > >>> redistributors tend to work from global-requirements.txt when
> > >>> determining
> > >>> what to package/support.
> > >>>
> > >>> It seems to me like there’s room to clean up some of these
> > >>> requirements
> > >>> to
> > >>> make them far more explicit and less misleading to the human eye
> (even
> > >>> though tooling like pip can easily parse/understand these).
> > >>
> > >> I think that's the idea. These requirements were generated
> > >> automatically, and fixed issues that were holding back several
> > >>> projects.
> > >> Now we can apply updates to them by hand, to either move the lower
> > >> bounds down (as in the case Ihar pointed out with stevedore) or
> clean
> > >>> up
> > >> the range definitions. We should not raise the limits of any Oslo
> > >> libraries, and we should consider raising the limits of
> third-party
> > >> libraries very carefully.
> > >>
> > >> We should make those changes on one library at a time, so we can
> see
> > >> what effect each change has on the other requirements.
> > >>
> > >>>
> > >>> I also understand that stable-maint may want to occasionally
> bump the
> > >>> caps
> > >>> to see if newer versions will not break everything, so what is
> the
> > >>> right
> > >>> way forward? What is the best way to both maintain a stable
> branch
> > >>> with
> > >>> known working dependencies while helping out those who do so
> much work
> > >>> for
> > >>> us (downstream and stable-maint) and not permanently pinning to
> > >>> certain
> > >>> working versions?
> > >>
> > >> Managing the upper bounds is still under discussion. Sean pointed
> out
> > >> that we might want hard caps so that updates to stable branch were
> > >> explicit. I can see either side of that argument and am still on
> the
> > >> fence about the best approach.
> > >
> > > History has shown that it's too much work keeping testing
> functioning
> > > for stable branches if we leave dependencies uncapped. If
> particular
> > > people are interested in bumping versions when releases happen,
> it's
> > > easy enough to do with a requirements proposed update. It will
> even run
> > > tests that in most cases will prove that it works.
> > >
> > > It might even be possible for someone to build some automation
> that did
> > > that as stuff from pypi released so we could have the best of both
> > > worlds. But I think capping is definitely something we want as a
> > > project, and it reflects the way that most deployments will
> consume this
> > > code.
> > >
> > > -Sean
> > >
> > > --
> > > Sean Dague
> > > http://dague.net
> > 
> >  Right. No one is arguing the very clear benefits of all of this.
> > 
> >  I’m just wondering if for the example version identifiers that I
> gave in
> >  my original message (and others that are very similar) if we want
> to make
> >  the strings much simpler for people who tend to work from them
> (i.e.,
> >  downstream re-distributors whose jobs are already difficult
> enough). I’ve
> >  offered to help at least one of them in the past who maintains all
> of
> >  their distro’s packages themselves, but they refused so I’d like to
> help
> >  them anyway possible. Especially if any of them chime in as this
> being
> >  something that would be helpful.
> > >>>
> > >>> Ok, your links got kind of scrambled. Can you next time p

Re: [openstack-dev] [neutron][ipv6] dhcp stateful

[Robert Li (baoli)]

My guess is that your dhcp client running inside the VM set up the subnet
mask as /128. Dhcpv6 doesn¹t provide prefix length, but the client system
sometime adds the net mask based on the link type. Some of the dhcp
clients use a script to configure the interface, and I think you can use
/64 if your link is ethernet.

‹Robert

On 2/19/15, 4:27 AM, "Andreas Scheuring" 
wrote:

>Hi, 
>I was playing around with the various dhcp/radvd options of neutron.
>Very helpful was the matrix [1] that describes the combinations of ra
>and adress mode that can be configured.
>
>For dhcpv6-stateful (ra & adress mode) it says: "VM obtains IPv6 address
>from dnsmasq using DHCPv6 stateful and optional info from dnsmasq using
>DHCPv6 stateful" [1] --> My assumption was that IP adresses and prefix
>are assigned via dnsmasq.
>
>But going this way, my instances got the right IP-Adress (great) but
>always the subnetmask /128, although I configured /64. Dumping the
>traffic and having a look at dnsmasq logs the dhcp process from solicit
>to reply worked fine.
>
>I was using rhel7 for guest and host and dnsmasq 2.68.
>
>I googled around and found some hints, that dhcpv6 does not support
>prefix delegation. Seems like that it is the job of the radvd daemon
>[2][3][4]
>
>
>Is that true? And if so, what's the use case of configuring
>dhcpv6-stateful for ra and address mode?
>
>
>
>
>
>
>[1]
>http://specs.openstack.org/openstack/neutron-specs/specs/juno/ipv6-radvd-r
>a.html#rest-api-impact
>
>[2] https://lists.isc.org/pipermail/dhcp-users/2012-May/015446.html
>[3]
>http://serverfault.com/questions/528387/sending-netmask-and-gateway-route-
>with-dhcp-for-ipv6
>[4]
>https://supportforums.cisco.com/document/116221/part-1-implementing-dhcpv6
>-stateful-dhcpv6
>
>-- 
>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

Re: [openstack-dev] [nova] release request for python-novaclient

[melanie witt]

On Feb 19, 2015, at 12:48, Dan Smith  wrote:

> Either convince neutron pylint not to care, or just convert the
> uses in neutron to v2.

In pylint, E0611 is the check which could be disabled to ignore this case.

http://pylint-messages.wikidot.com/messages:e0611

melanie (melwitt)






signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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] [stable][requirements] External dependency caps introduced in 499db6b

[Doug Hellmann]

On Thu, Feb 19, 2015, at 03:59 PM, Joe Gordon wrote:
> On Wed, Feb 18, 2015 at 7:14 AM, Doug Hellmann 
> wrote:
> 
> >
> >
> > On Wed, Feb 18, 2015, at 10:07 AM, Donald Stufft wrote:
> > >
> > > > On Feb 18, 2015, at 10:00 AM, Doug Hellmann 
> > wrote:
> > > >
> > > >
> > > >
> > > > On Tue, Feb 17, 2015, at 03:17 PM, Joe Gordon wrote:
> > > >> On Tue, Feb 17, 2015 at 4:19 AM, Sean Dague  wrote:
> > > >>
> > > >>> On 02/16/2015 08:50 PM, Ian Cordasco wrote:
> > >  On 2/16/15, 16:08, "Sean Dague"  wrote:
> > > 
> > > > On 02/16/2015 02:08 PM, Doug Hellmann wrote:
> > > >>
> > > >>
> > > >> On Mon, Feb 16, 2015, at 01:01 PM, Ian Cordasco wrote:
> > > >>> Hey everyone,
> > > >>>
> > > >>> The os-ansible-deployment team was working on updates to add
> > support
> > > >>> for
> > > >>> the latest version of juno and noticed some interesting version
> > > >>> specifiers
> > > >>> introduced into global-requirements.txt in January. It
> > introduced some
> > > >>> version specifiers that seem a bit impossible like the one for
> > > >>> requests
> > > >>> [1]. There are others that equate presently to pinning the
> > versions of
> > > >>> the
> > > >>> packages [2, 3, 4].
> > > >>>
> > > >>> I understand fully and support the commit because of how it
> > improves
> > > >>> pretty much everyone’s quality of life (no fires to put out in
> > the
> > > >>> middle
> > > >>> of the night on the weekend). I’m also aware that a lot of the
> > > >>> downstream
> > > >>> redistributors tend to work from global-requirements.txt when
> > > >>> determining
> > > >>> what to package/support.
> > > >>>
> > > >>> It seems to me like there’s room to clean up some of these
> > > >>> requirements
> > > >>> to
> > > >>> make them far more explicit and less misleading to the human eye
> > (even
> > > >>> though tooling like pip can easily parse/understand these).
> > > >>
> > > >> I think that's the idea. These requirements were generated
> > > >> automatically, and fixed issues that were holding back several
> > > >>> projects.
> > > >> Now we can apply updates to them by hand, to either move the lower
> > > >> bounds down (as in the case Ihar pointed out with stevedore) or
> > clean
> > > >>> up
> > > >> the range definitions. We should not raise the limits of any Oslo
> > > >> libraries, and we should consider raising the limits of
> > third-party
> > > >> libraries very carefully.
> > > >>
> > > >> We should make those changes on one library at a time, so we can
> > see
> > > >> what effect each change has on the other requirements.
> > > >>
> > > >>>
> > > >>> I also understand that stable-maint may want to occasionally
> > bump the
> > > >>> caps
> > > >>> to see if newer versions will not break everything, so what is
> > the
> > > >>> right
> > > >>> way forward? What is the best way to both maintain a stable
> > branch
> > > >>> with
> > > >>> known working dependencies while helping out those who do so
> > much work
> > > >>> for
> > > >>> us (downstream and stable-maint) and not permanently pinning to
> > > >>> certain
> > > >>> working versions?
> > > >>
> > > >> Managing the upper bounds is still under discussion. Sean pointed
> > out
> > > >> that we might want hard caps so that updates to stable branch were
> > > >> explicit. I can see either side of that argument and am still on
> > the
> > > >> fence about the best approach.
> > > >
> > > > History has shown that it's too much work keeping testing
> > functioning
> > > > for stable branches if we leave dependencies uncapped. If
> > particular
> > > > people are interested in bumping versions when releases happen,
> > it's
> > > > easy enough to do with a requirements proposed update. It will
> > even run
> > > > tests that in most cases will prove that it works.
> > > >
> > > > It might even be possible for someone to build some automation
> > that did
> > > > that as stuff from pypi released so we could have the best of both
> > > > worlds. But I think capping is definitely something we want as a
> > > > project, and it reflects the way that most deployments will
> > consume this
> > > > code.
> > > >
> > > > -Sean
> > > >
> > > > --
> > > > Sean Dague
> > > > http://dague.net
> > > 
> > >  Right. No one is arguing the very clear benefits of all of this.
> > > 
> > >  I’m just wondering if for the example version identifiers that I
> > gave in
> > >  my original message (and others that are very similar) if we want
> > to make
> > >  the strings much simpler for people who tend to work from them
> > (i.e.,
> > >  downstream re-distributors whose jobs are already difficult
> > enough). I’ve
> > >  offered to help at least one of them

[openstack-dev] [neutron] New version of python-neutronclient release: 2.3.11

[Kyle Mestery]

The Neutron team is proud to announce the release of the latest version of
python-neutronclient. This release includes the following bug fixes and
improvements:

3e5c6ba Updated from global requirements
a774e84 Add unit tests for agentscheduler related commands
069b14c Fix for incorrect parameter in user-id error message in shell.py
57adb7f Fix CSV formatting of fixed_ips field in port-list command
0be3b62 Implement LBaaS object model v2
3d6769c Fix typo in test_cli20_agentschedulers filename
e1633ed Add ip_version to extra dhcp opts
59d7564 Skip None id when getting security_group_ids
6f7cd14 Reverse order of tests to avoid incompatibility
b0923a3 Utility method for boolean argument
68fc402 Split base function of v2_0.Client into a separate class
2dce00b Updated from global requirements
51d2a23 Add parser options for port-update and port-create
5b1c45a Add floating-ip-address to floatingip-create
845f461 Fix KeyError when filtering SG rule listing
30bd81c Updated from global requirements
86fede6 Remove unreachable code from test_cli20 class
cb5d462 Parse provider network attributes in net_create
78b6310 Parameter support both id and name
096fd1b Add '--router:external' option to 'net-create'
aed3faf Fix TypeError for six.text_type
d6e40b5 Add Python 3 classifiers
4fa57fe Namespace of arguments is incorrectly used
4beadef Fix True/False to accept Camel and Lower case
799e288 Use adapter from keystoneclient
5822d61 Use requests_mock instead of mox
4b181cd Updated from global requirements
04a0ec8 firewall policy update for a rule is not working
0560f85 Fix columns setup base on csv formatter
187c36c Correct the bash completion of CLI
2f23623 Workflow documentation is now in infra-manual
62063c1 Fix issues with Unicode compatibility for Py3

For more details on the release, please see the git log history in the
release notes in the LP page here:

https://launchpad.net/python-neutronclient/+milestone/2.3.11

Please report any bugs in LP.

Thanks!
Kyle
__
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] [Cinder-GlusterFS CI] centos7 gate job abrupt failures

[Jeremy Stanley]

On 2015-02-19 17:03:49 +0100 (+0100), Deepak Shetty wrote:
[...]
> For some reason we are seeing the centos7 glusterfs CI job getting
> aborted/ killed either by Java exception or the build getting
> aborted due to timeout.
[...]
> Hoping to root cause this soon and get the cinder-glusterfs CI job
> back online soon.

I manually reran the same commands this job runs on an identical
virtual machine and was able to reproduce some substantial
weirdness.

I temporarily lost remote access to the VM around 108 minutes into
running the job (~17:50 in the logs) and the out of band console
also became unresponsive to carriage returns. The machine's IP
address still responded to ICMP ping, but attempts to open new TCP
sockets to the SSH service never got a protocol version banner back.
After about 10 minutes of that I went out to lunch but left
everything untouched. To my excitement it was up and responding
again when I returned.

It appears from the logs that it runs well past the 120-minute mark
where devstack-gate tries to kill the gate hook for its configured
timeout. Somewhere around 165 minutes in (18:47) you can see the
kernel out-of-memory killer starts to kick in and kill httpd and
mysqld processes according to the syslog. Hopefully this is enough
additional detail to get you a start at finding the root cause so
that we can reenable your job. Let me know if there's anything else
you need for this.

[1] http://fungi.yuggoth.org/tmp/logs.tar
-- 
Jeremy Stanley

__
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] release request for python-novaclient

[Terry Wilson]

- Original Message -
> On Feb 19, 2015, at 11:52, Terry Wilson  wrote:
> 
> > Unfortunately, the new novaclient release ended up completely breaking the
> > neutron gate. The v1_1 deprecation broke our (voting) pylint test:
> > https://jenkins04.openstack.org/job/gate-neutron-pylint/1383/console
> > 
> > 2015-02-19 18:37:06.932 | Module neutron.notifiers.nova[0m
> > 2015-02-19 18:37:06.932 | No name 'client' in module 'novaclient.v1_1'
> > (no-name-in-module)
> > 2015-02-19 18:37:06.932 | No name 'contrib' in module
> > 'novaclient.v1_1'(no-name-in-module)
> > 2015-02-19 18:37:06.932 | Module neutron.plugins.cisco.l3.service_vm_lib
> > 2015-02-19 18:37:06.932 | No name 'client' in module 'novaclient.v1_1'
> > (no-name-in-module)
> 
> Hi Terry,
> 
> Sorry to hear about this. I looked into this and the problem is pylint can't
> parse the backward-compatibility we have for the v1_1 deprecation:
> 
> https://review.openstack.org/#/c/149006/13/novaclient/v1_1/__init__.py,cm
> 
> The actual code should work but pylint static checking will fail to follow
> it. So far, the options I see to handle it are to either patch
> s/novaclient.v1_1/novaclient.v2/ in neutron or suppress the specific pylint
> check that's failing (if it's not too broad).
> 
> Do you find either of these options acceptable, or have another idea?

We've currently just disabled the pylint gate tests, and I've posted a patch 
for neutron to resolve the issue. Looks like there was a similar patch already 
up for review as well, though it only catches one of our uses of novaclient. 
There's still a bit of an issue that there is no version-neutral way to import 
the 'contrib' stuff like there is for 'client'. So:

from novaclient.v1_1.contrib import server_external_events

has to become

from novaclient.v2.contrib import server_external_events

which doesn't work on previous versions of novaclient. It's possible to hack 
around it using importutils, but it's pretty ugly.

Terry

__
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] New version of python-neutronclient release: 2.3.11

[Edgar Magana]

Kudos!

Edgar

From: Kyle Mestery mailto:mest...@mestery.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Thursday, February 19, 2015 at 1:35 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: [openstack-dev] [neutron] New version of python-neutronclient release: 
2.3.11

The Neutron team is proud to announce the release of the latest version of 
python-neutronclient. This release includes the following bug fixes and 
improvements:

3e5c6ba Updated from global requirements
a774e84 Add unit tests for agentscheduler related commands
069b14c Fix for incorrect parameter in user-id error message in shell.py
57adb7f Fix CSV formatting of fixed_ips field in port-list command
0be3b62 Implement LBaaS object model v2
3d6769c Fix typo in test_cli20_agentschedulers filename
e1633ed Add ip_version to extra dhcp opts
59d7564 Skip None id when getting security_group_ids
6f7cd14 Reverse order of tests to avoid incompatibility
b0923a3 Utility method for boolean argument
68fc402 Split base function of v2_0.Client into a separate class
2dce00b Updated from global requirements
51d2a23 Add parser options for port-update and port-create
5b1c45a Add floating-ip-address to floatingip-create
845f461 Fix KeyError when filtering SG rule listing
30bd81c Updated from global requirements
86fede6 Remove unreachable code from test_cli20 class
cb5d462 Parse provider network attributes in net_create
78b6310 Parameter support both id and name
096fd1b Add '--router:external' option to 'net-create'
aed3faf Fix TypeError for six.text_type
d6e40b5 Add Python 3 classifiers
4fa57fe Namespace of arguments is incorrectly used
4beadef Fix True/False to accept Camel and Lower case
799e288 Use adapter from keystoneclient
5822d61 Use requests_mock instead of mox
4b181cd Updated from global requirements
04a0ec8 firewall policy update for a rule is not working
0560f85 Fix columns setup base on csv formatter
187c36c Correct the bash completion of CLI
2f23623 Workflow documentation is now in infra-manual
62063c1 Fix issues with Unicode compatibility for Py3

For more details on the release, please see the git log history in the release 
notes in the LP page here:

https://launchpad.net/python-neutronclient/+milestone/2.3.11

Please report any bugs in LP.

Thanks!
Kyle
__
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] [stable][requirements] External dependency caps introduced in 499db6b

[Adam Gandelman]

This creates a bit of a problem for downstream (packagers and probably
others)  Shipping a requirements.txt with explicit pins will end up
producing an egg with a requires.txt that reflects those pins, unless there
is some other magic planned that I'm not aware of.  I can't speak for all
packaging flavors, but I know debian packaging interacts quite closely with
things like requirements.txt and resulting egg's requires.txt to determine
appropriate system-level package dependencies.  This would require a lot of
tedious work on packagers part to get something functional.

What if its flipped? How about keeping requirements.txt with the caps, and
using that as input to produce something like requirements.gate that passed
to 'pip install --no-deps'  on our slaves?  We'd end up installing and
using the explicit pinned requirements while the services/libraries
themselves remain flexible.  This might the issue Doug pointed out, where
requirements updates across projects are not synchronized.

Adam



On Thu, Feb 19, 2015 at 12:59 PM, Joe Gordon  wrote:

>
>
> On Wed, Feb 18, 2015 at 7:14 AM, Doug Hellmann 
> wrote:
>
>>
>>
>> On Wed, Feb 18, 2015, at 10:07 AM, Donald Stufft wrote:
>> >
>> > > On Feb 18, 2015, at 10:00 AM, Doug Hellmann 
>> wrote:
>> > >
>> > >
>> > >
>> > > On Tue, Feb 17, 2015, at 03:17 PM, Joe Gordon wrote:
>> > >> On Tue, Feb 17, 2015 at 4:19 AM, Sean Dague  wrote:
>> > >>
>> > >>> On 02/16/2015 08:50 PM, Ian Cordasco wrote:
>> >  On 2/16/15, 16:08, "Sean Dague"  wrote:
>> > 
>> > > On 02/16/2015 02:08 PM, Doug Hellmann wrote:
>> > >>
>> > >>
>> > >> On Mon, Feb 16, 2015, at 01:01 PM, Ian Cordasco wrote:
>> > >>> Hey everyone,
>> > >>>
>> > >>> The os-ansible-deployment team was working on updates to add
>> support
>> > >>> for
>> > >>> the latest version of juno and noticed some interesting version
>> > >>> specifiers
>> > >>> introduced into global-requirements.txt in January. It
>> introduced some
>> > >>> version specifiers that seem a bit impossible like the one for
>> > >>> requests
>> > >>> [1]. There are others that equate presently to pinning the
>> versions of
>> > >>> the
>> > >>> packages [2, 3, 4].
>> > >>>
>> > >>> I understand fully and support the commit because of how it
>> improves
>> > >>> pretty much everyone’s quality of life (no fires to put out in
>> the
>> > >>> middle
>> > >>> of the night on the weekend). I’m also aware that a lot of the
>> > >>> downstream
>> > >>> redistributors tend to work from global-requirements.txt when
>> > >>> determining
>> > >>> what to package/support.
>> > >>>
>> > >>> It seems to me like there’s room to clean up some of these
>> > >>> requirements
>> > >>> to
>> > >>> make them far more explicit and less misleading to the human
>> eye (even
>> > >>> though tooling like pip can easily parse/understand these).
>> > >>
>> > >> I think that's the idea. These requirements were generated
>> > >> automatically, and fixed issues that were holding back several
>> > >>> projects.
>> > >> Now we can apply updates to them by hand, to either move the
>> lower
>> > >> bounds down (as in the case Ihar pointed out with stevedore) or
>> clean
>> > >>> up
>> > >> the range definitions. We should not raise the limits of any Oslo
>> > >> libraries, and we should consider raising the limits of
>> third-party
>> > >> libraries very carefully.
>> > >>
>> > >> We should make those changes on one library at a time, so we can
>> see
>> > >> what effect each change has on the other requirements.
>> > >>
>> > >>>
>> > >>> I also understand that stable-maint may want to occasionally
>> bump the
>> > >>> caps
>> > >>> to see if newer versions will not break everything, so what is
>> the
>> > >>> right
>> > >>> way forward? What is the best way to both maintain a stable
>> branch
>> > >>> with
>> > >>> known working dependencies while helping out those who do so
>> much work
>> > >>> for
>> > >>> us (downstream and stable-maint) and not permanently pinning to
>> > >>> certain
>> > >>> working versions?
>> > >>
>> > >> Managing the upper bounds is still under discussion. Sean
>> pointed out
>> > >> that we might want hard caps so that updates to stable branch
>> were
>> > >> explicit. I can see either side of that argument and am still on
>> the
>> > >> fence about the best approach.
>> > >
>> > > History has shown that it's too much work keeping testing
>> functioning
>> > > for stable branches if we leave dependencies uncapped. If
>> particular
>> > > people are interested in bumping versions when releases happen,
>> it's
>> > > easy enough to do with a requirements proposed update. It will
>> even run
>> > > tests that in most cases will prove that it works.
>> > >
>> > > It might even be possible for someo

Re: [openstack-dev] [ovs-dev] [PATCH 8/8] [RFC] ovn: Start work on design ocumentation.

[Ben Pfaff]

[moving this conversation to openstack-dev because it's more
interesting there and that avoids crossposting to a subscribers-only
list]

On Thu, Feb 19, 2015 at 10:57:02AM +0100, Miguel ??ngel Ajo wrote:
>I specially liked the VIF port lifecycle, looks good to me, Ionly miss 
> some  
> ???port_security??? concepts we have in neutron, which I guess could have 
> been  
> deliberately omitted for a start.
> 
>In neutron we have something called security groups, and every port
> belongs to 1 or more security groups.  Each security group has a list of
> rules to control traffic at port level in a very fine grained fashion 
> (ingress/egress
> protocol/flags/etc???   remote_ip/mask or security_group ID)
> 
> I guess we could build  render security_group ID to multiple IPs for each 
> port,
> but then we will miss the ingress/egress and protocol flags (like type  of 
> protocol,
> ports, etc.. [1])
> 
> Also, be aware, that not having security group ID references from neutron,
> when lot???s of ports go to the same security group we end up with an 
> exponential
> growth of rules / OF entries per port, we solved this in the server<->agent
> communication for the reference OVS solution by keeping a lists of IPs  
> belonging to security group IDs, and then, separately having the  
> references from the rules.

Thanks a lot for the comment.

We aim to fully support security groups in OVN.  The current documents
don't capture that intent.  (That's partly because we're planning to
implement them in terms of some new "connection tracking" code for OVS
that's still in the process of getting committed, and partly because I
haven't fully thought them through yet.)

My initial reaction is that we can implement security groups as
another action in the ACL table that is similar to "allow" but in
addition permits reciprocal inbound traffic.  Does that sound
sufficient to you?

Is the exponential explosion due to cross-producting, that is, because
you have, say, n1 source addresses and n2 destination addresses and so
you need n1*n2 flows to specify all the combinations?  We aim to solve
that in OVN by giving the CMS direct support for more sophisticated
matching rules, so that it can say something like:

ip.src in {, , , ...} && ip.dst in {, , , ...}
&& (tcp.src in {80, 443, 8080} || tcp.dst in {80, 443, 8080})

and let OVN implement it in OVS via the "conjunctive match" feature
recently added, which is like a set membership match but more
powerful.  It might still be nice to support lists of IPs (or
whatever), since these lists could still recur in a number of
circumstances, but my guess is that this will help a lot even without
that.

Thoughts?

__
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]??[ovs-dev] [PATCH 8/8] [RFC] ovn: Start work on design Documentation.

[Ben Pfaff]

Thanks.  It looks like openstack-dev only accepts posts from
subscribers, so I've followed up to your more detailed feedback only
on that list.  For anyone following along at home, here's an archives
link:
http://lists.openstack.org/pipermail/openstack-dev/2015-February/057376.html

On Thu, Feb 19, 2015 at 10:38:03AM +0100, Miguel ??ngel Ajo wrote:
> Thank you Ben!,  
> 
> Cross posting [1] to openstack list /neutron.
> 
> 
> [1] http://benpfaff.org/~blp/dist-docs. 
> 
> On Thursday, 19 de February de 2015 at 09:13, Ben Pfaff wrote:
> 
> > On Thu, Feb 19, 2015 at 12:12:26AM -0800, Ben Pfaff wrote:
> > > This commit adds preliminary design documentation for Open Virtual 
> > > Network,
> > > or OVN, a new OVS-based project to add support for virtual networking to
> > > OVS, initially with OpenStack integration.
> > > 
> > > This initial design has been influenced by many people, including (in
> > > alphabetical order) Aaron Rosen, Chris Wright, Jeremy Stribling,
> > > Justin Pettit, Ken Duda, Madhu Venugopal, Martin Casado, Pankaj Thakkar,
> > > Russell Bryant, and Teemu Koponen. All blunders, however, are due to my
> > > own hubris.
> > > 
> > > Signed-off-by: Ben Pfaff mailto:b...@nicira.com)>
> > 
> > I've posted the rendered version of the documentation following this
> > commit at http://benpfaff.org/~blp/dist-docs. You probably want to look
> > at the ovn* manpages, especially ovn-architecture(7), ovn(5), and
> > ovn-nb(5).
> > ___
> > dev mailing list
> > d...@openvswitch.org (mailto:d...@openvswitch.org)
> > http://openvswitch.org/mailman/listinfo/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] release request for python-novaclient

[Andrey Kurilin]

Neutron should not depend on versioning implementation in novaclient.

There is get_contrib_module function in
https://review.openstack.org/#/c/152569/9/novaclient/client.py , which
should help to renounce the use of direct import of versioning stuff of
novaclient, but now, imo, we should use workaround like
https://review.openstack.org/#/c/152907/

On Fri, Feb 20, 2015 at 12:38 AM, Terry Wilson  wrote:

>
>
> - Original Message -
> > On Feb 19, 2015, at 11:52, Terry Wilson  wrote:
> >
> > > Unfortunately, the new novaclient release ended up completely breaking
> the
> > > neutron gate. The v1_1 deprecation broke our (voting) pylint test:
> > > https://jenkins04.openstack.org/job/gate-neutron-pylint/1383/console
> > >
> > > 2015-02-19 18:37:06.932 | Module neutron.notifiers.nova[0m
> > > 2015-02-19 18:37:06.932 | No name 'client' in module 'novaclient.v1_1'
> > > (no-name-in-module)
> > > 2015-02-19 18:37:06.932 | No name 'contrib' in module
> > > 'novaclient.v1_1'(no-name-in-module)
> > > 2015-02-19 18:37:06.932 | Module
> neutron.plugins.cisco.l3.service_vm_lib
> > > 2015-02-19 18:37:06.932 | No name 'client' in module 'novaclient.v1_1'
> > > (no-name-in-module)
> >
> > Hi Terry,
> >
> > Sorry to hear about this. I looked into this and the problem is pylint
> can't
> > parse the backward-compatibility we have for the v1_1 deprecation:
> >
> >
> https://review.openstack.org/#/c/149006/13/novaclient/v1_1/__init__.py,cm
> >
> > The actual code should work but pylint static checking will fail to
> follow
> > it. So far, the options I see to handle it are to either patch
> > s/novaclient.v1_1/novaclient.v2/ in neutron or suppress the specific
> pylint
> > check that's failing (if it's not too broad).
> >
> > Do you find either of these options acceptable, or have another idea?
>
> We've currently just disabled the pylint gate tests, and I've posted a
> patch for neutron to resolve the issue. Looks like there was a similar
> patch already up for review as well, though it only catches one of our uses
> of novaclient. There's still a bit of an issue that there is no
> version-neutral way to import the 'contrib' stuff like there is for
> 'client'. So:
>
> from novaclient.v1_1.contrib import server_external_events
>
> has to become
>
> from novaclient.v2.contrib import server_external_events
>
> which doesn't work on previous versions of novaclient. It's possible to
> hack around it using importutils, but it's pretty ugly.
>
> Terry
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Best regards,
Andrey Kurilin.
__
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] [ovs-dev] [PATCH 8/8] [RFC] [neutron] ovn: Start work on design ocumentation.

[Kyle Mestery]

[Adding neutron tag to subject, comments below.]

On Thu, Feb 19, 2015 at 3:55 PM, Ben Pfaff  wrote:

> [moving this conversation to openstack-dev because it's more
> interesting there and that avoids crossposting to a subscribers-only
> list]
>
> On Thu, Feb 19, 2015 at 10:57:02AM +0100, Miguel ??ngel Ajo wrote:
> >I specially liked the VIF port lifecycle, looks good to me, Ionly
> miss some
> > ???port_security??? concepts we have in neutron, which I guess could
> have been
> > deliberately omitted for a start.
> >
> >In neutron we have something called security groups, and every port
> > belongs to 1 or more security groups.  Each security group has a list of
> > rules to control traffic at port level in a very fine grained fashion
> (ingress/egress
> > protocol/flags/etc???   remote_ip/mask or security_group ID)
> >
> > I guess we could build  render security_group ID to multiple IPs for
> each port,
> > but then we will miss the ingress/egress and protocol flags (like type
> of protocol,
> > ports, etc.. [1])
> >
> > Also, be aware, that not having security group ID references from
> neutron,
> > when lot???s of ports go to the same security group we end up with an
> exponential
> > growth of rules / OF entries per port, we solved this in the
> server<->agent
> > communication for the reference OVS solution by keeping a lists of IPs
> > belonging to security group IDs, and then, separately having the
> > references from the rules.
>
> Thanks a lot for the comment.
>
> We aim to fully support security groups in OVN.  The current documents
> don't capture that intent.  (That's partly because we're planning to
> implement them in terms of some new "connection tracking" code for OVS
> that's still in the process of getting committed, and partly because I
> haven't fully thought them through yet.)
>
> My initial reaction is that we can implement security groups as
> another action in the ACL table that is similar to "allow" but in
> addition permits reciprocal inbound traffic.  Does that sound
> sufficient to you?
>
> Is the exponential explosion due to cross-producting, that is, because
> you have, say, n1 source addresses and n2 destination addresses and so
> you need n1*n2 flows to specify all the combinations?  We aim to solve
> that in OVN by giving the CMS direct support for more sophisticated
> matching rules, so that it can say something like:
>
> ip.src in {, , , ...} && ip.dst in {, , , ...}
> && (tcp.src in {80, 443, 8080} || tcp.dst in {80, 443, 8080})
>
> and let OVN implement it in OVS via the "conjunctive match" feature
> recently added, which is like a set membership match but more
> powerful.  It might still be nice to support lists of IPs (or
> whatever), since these lists could still recur in a number of
> circumstances, but my guess is that this will help a lot even without
> that.
>
> Thoughts?
>
> This all sounds really good to me Ben. I look forward to seeing the
connection tracking code land and some design details on the security
groups aspects of OVN published once that happens!

Thanks,
Kyle


> __
> 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] What's Up Doc? Feb 19 2015

[Anne Gentle]

Here's the news from doc land.

Install Guides are no longer publishing to docs.openstack.org/trunk. They
are published only to a release such as docs.openstack.org/juno or
docs.openstack.org/icehouse. Also this patch removes the Debian Install
Guide until the instructions are fixed so that users can have a working
install upon completion. [1]

API docs now officially in the attic and all docs.openstack.org/api/ links
now redirect to the API reference at
http://developer.openstack.org/api-ref.html.

We really want to ensure that driver documents get streamlined this
release. The specification is at https://review.openstack.org/#/c/133372/.
Paging Arkady Kanevsky, please examine that review so we can find a path
forward to improve driver docs across multiple projects.

We've merged 89 patches in the last week across all the docs repos.

Much gratitude to the bug triaging efforts this past week, looks like at
least 50 doc bugs were triaged this week. Thank you!

With over 500 doc bugs, we are still very much behind in fixing doc bugs,
especially those that come in from DocImpact automation. If you've had a
patch land with DocImpact, please follow up on the doc bug in
http://bugs.launchpad.net/openstack-manuals to at least triage it and
hopefully fix it. Find us in #openstack-doc if you can't figure out which
docs should be impacted.

We really need a way to indicate which OpenStack version introduces each of
these two things:
- Ceilometer meters: The team is doing a great job of documenting their
reference information; however, some meters aren't available until the Kilo
release. Yet we don't have a way to indicate which meters are available in
which release (like we do with say, the Configuration Reference.) Also, the
meters don't have descriptions associated with them in the code itself, so
doc updates are manual currently. Ideally we'd throw some automation at the
problem.
- API Extensions: For the Compute and Identity APIs we have always
recognized that our doc tool doesn't output any indicator of which release
the extension is available in. [2]

Any and all ideas are welcomed!

Thanks,
Anne

1. https://review.openstack.org/#/c/157037/
2. https://bugs.launchpad.net/openstack-api-site/+bug/1423716
__
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] Prefix delegation using dibbler client

[Robert Li (baoli)]

Hi Kyle, Ihar,

It looks promising to have our patch upstreamed. Please take a look at this 
pull request 
https://github.com/tomaszmrugalski/dibbler/pull/26#issuecomment-75144912. Most 
importantly, Tomek asked if it’s sufficient to have the code up in his master 
branch. I guess you guys may be able to help answer that question since I’m not 
familiar with openstack release process.

Cheers,
Robert

On 2/13/15, 12:16 PM, "Kyle Mestery" 
mailto:mest...@mestery.com>> wrote:

On Fri, Feb 13, 2015 at 10:57 AM, John Davidge (jodavidg) 
mailto:jodav...@cisco.com>> wrote:
Hi Ihar,

To answer your questions in order:

1. Yes, you are understanding the intention correctly. Dibbler doesn¹t
currently support client restart, as doing so causes all existing
delegated prefixes to be released back to the PD server. All subnets
belonging to the router would potentially receive a new cidr every time a
subnet is added/removed.

2. Option 2 cannot be implemented using the current version of dibbler,
but it can be done using the version we have modified. Option 3 could
possibly be done with the current version of dibbler, but with some major
limitations - only one single router namespace would be supported.

Once the dibbler changes linked below are reviewed and finalised we will
only need to merge a single patch into the upstream dibbler repo. No
further patches are anticipated.

Yes, you are correct that dibbler is not needed unless prefix delegation
is enabled by the deployer. It is intended as an optional feature that can
be easily disabled (and probably will be by default). A test to check for
the correct dibbler version would certainly be necessary.

Testing in the gate will be an issue until the new version of dibbler is
merged and packaged in the various distros. I¹m not sure if there is a way
to avoid this problem, unless we have devstack install from our updated
repo while we wait.

To me, this seems like a pretty huge problem. We can't expect distributions to 
package side-changes to upstream projects. The correct way to solve this 
problem is to work to get the changes required in the dependent packages 
upstream into those projects first (dibbler, in this case), and then propose 
the changes into Neutron to make use of those changes. I don't see how we can 
proceed with this work until the issues around dibbler has been resolved.

John Davidge
OpenStack@Cisco




On 13/02/2015 16:01, "Ihar Hrachyshka" 
mailto:ihrac...@redhat.com>> wrote:

>-BEGIN PGP SIGNED MESSAGE-
>Hash: SHA1
>
>Thanks for the write-up! See inline.
>
>On 02/13/2015 04:34 PM, Robert Li (baoli) wrote:
>> Hi,
>>
>> while trying to integrate dibbler client with neutron to support
>> PD, we countered a few issues with the dibbler client (and server).
>> With a neutron router, we have the qg-xxx interface that is
>> connected to the public network, on which a dhcp server is running
>> on the delegating router. For each subnet with PD enabled, a router
>> port will be created in the neutron router. As a result, a new PD
>> request will be sent that asks for a prefix from the delegating
>> router. Keep in mind that the subnet is added into the router
>> dynamically.
>>
>> We thought about the following options:
>>
>> 1. use a single dibbler client to support the above requirement.
>> This means, the client should be able to accept new requests on the
>> fly either through configuration reload or other interfaces.
>> Unfortunately, dibbler client doesn¹t support it.
>
>Sorry for my ignorance on PD implementation (I will definitely look at
>it the next week), but what does this entry above mean? Do you want a
>single dibbler instance running per router serving all subnets plugged
>into it? And you want to get configuration updates when a new subnet
>is plugged in, or removed from the router?
>
>If that's the case, why not just restarting the client?
>
>> 2. start a dibbler client per subnet. All of the dibbler clients
>> will be using the same outgoing interface (which is the qg-xxx
>> interface). Unfortunately, dibbler client uses /etc/dibbler and
>> /var/lib/dibbler for its state (in which it saves duid file, pid
>> file, and other internal states). This means it can only support
>> one client per network node. 3. run a single dibbler client that
>> requests a smaller prefix (say /56) and splits it among the subnets
>> with PD enabled (neutron subnet requires /64). Depending on the
>> neutron router setup, this may result in significant waste of
>> prefixes.
>
>Just to understand all options at the table: can we implement ^^
>option with stock dibbler?
>
>>
>> Given the significant drawback with 3, we are left with 1 and 2.
>> After looking at the dibbler source code, we found that 2 is easier
>> to achieve for now by making some small changes in the dibbler
>> code. In the long run, we think option 1 is better.
>>
>> The changes we made to the linux dibbler client code, and the
>> dibbler server code can be found in here:
>> https://github.c

Re: [openstack-dev] [stable][requirements] External dependency caps introduced in 499db6b

[Joe Gordon]

On Thu, Feb 19, 2015 at 1:48 PM, Adam Gandelman  wrote:

> This creates a bit of a problem for downstream (packagers and probably
> others)  Shipping a requirements.txt with explicit pins will end up
> producing an egg with a requires.txt that reflects those pins, unless there
> is some other magic planned that I'm not aware of.  I can't speak for all
> packaging flavors, but I know debian packaging interacts quite closely with
> things like requirements.txt and resulting egg's requires.txt to determine
> appropriate system-level package dependencies.  This would require a lot of
> tedious work on packagers part to get something functional.
>
> What if its flipped? How about keeping requirements.txt with the caps, and
> using that as input to produce something like requirements.gate that passed
> to 'pip install --no-deps'  on our slaves?  We'd end up installing and
> using the explicit pinned requirements while the services/libraries
> themselves remain flexible.  This might the issue Doug pointed out, where
> requirements updates across projects are not synchronized.
>
>
Switching them to requirements.txt and requirements.gate works for me. If a
simple renaming makes things better, then great!

As for Doug's comment, yes we need to work something out to overwrite
requirements.gate, under your proposed naming, with global requirments


> Adam
>
>
>
> On Thu, Feb 19, 2015 at 12:59 PM, Joe Gordon 
> wrote:
>
>>
>>
>> On Wed, Feb 18, 2015 at 7:14 AM, Doug Hellmann 
>> wrote:
>>
>>>
>>>
>>> On Wed, Feb 18, 2015, at 10:07 AM, Donald Stufft wrote:
>>> >
>>> > > On Feb 18, 2015, at 10:00 AM, Doug Hellmann 
>>> wrote:
>>> > >
>>> > >
>>> > >
>>> > > On Tue, Feb 17, 2015, at 03:17 PM, Joe Gordon wrote:
>>> > >> On Tue, Feb 17, 2015 at 4:19 AM, Sean Dague  wrote:
>>> > >>
>>> > >>> On 02/16/2015 08:50 PM, Ian Cordasco wrote:
>>> >  On 2/16/15, 16:08, "Sean Dague"  wrote:
>>> > 
>>> > > On 02/16/2015 02:08 PM, Doug Hellmann wrote:
>>> > >>
>>> > >>
>>> > >> On Mon, Feb 16, 2015, at 01:01 PM, Ian Cordasco wrote:
>>> > >>> Hey everyone,
>>> > >>>
>>> > >>> The os-ansible-deployment team was working on updates to add
>>> support
>>> > >>> for
>>> > >>> the latest version of juno and noticed some interesting version
>>> > >>> specifiers
>>> > >>> introduced into global-requirements.txt in January. It
>>> introduced some
>>> > >>> version specifiers that seem a bit impossible like the one for
>>> > >>> requests
>>> > >>> [1]. There are others that equate presently to pinning the
>>> versions of
>>> > >>> the
>>> > >>> packages [2, 3, 4].
>>> > >>>
>>> > >>> I understand fully and support the commit because of how it
>>> improves
>>> > >>> pretty much everyone’s quality of life (no fires to put out in
>>> the
>>> > >>> middle
>>> > >>> of the night on the weekend). I’m also aware that a lot of the
>>> > >>> downstream
>>> > >>> redistributors tend to work from global-requirements.txt when
>>> > >>> determining
>>> > >>> what to package/support.
>>> > >>>
>>> > >>> It seems to me like there’s room to clean up some of these
>>> > >>> requirements
>>> > >>> to
>>> > >>> make them far more explicit and less misleading to the human
>>> eye (even
>>> > >>> though tooling like pip can easily parse/understand these).
>>> > >>
>>> > >> I think that's the idea. These requirements were generated
>>> > >> automatically, and fixed issues that were holding back several
>>> > >>> projects.
>>> > >> Now we can apply updates to them by hand, to either move the
>>> lower
>>> > >> bounds down (as in the case Ihar pointed out with stevedore) or
>>> clean
>>> > >>> up
>>> > >> the range definitions. We should not raise the limits of any
>>> Oslo
>>> > >> libraries, and we should consider raising the limits of
>>> third-party
>>> > >> libraries very carefully.
>>> > >>
>>> > >> We should make those changes on one library at a time, so we
>>> can see
>>> > >> what effect each change has on the other requirements.
>>> > >>
>>> > >>>
>>> > >>> I also understand that stable-maint may want to occasionally
>>> bump the
>>> > >>> caps
>>> > >>> to see if newer versions will not break everything, so what is
>>> the
>>> > >>> right
>>> > >>> way forward? What is the best way to both maintain a stable
>>> branch
>>> > >>> with
>>> > >>> known working dependencies while helping out those who do so
>>> much work
>>> > >>> for
>>> > >>> us (downstream and stable-maint) and not permanently pinning to
>>> > >>> certain
>>> > >>> working versions?
>>> > >>
>>> > >> Managing the upper bounds is still under discussion. Sean
>>> pointed out
>>> > >> that we might want hard caps so that updates to stable branch
>>> were
>>> > >> explicit. I can see either side of that argument and am still
>>> on the
>>> > >> fence about the best appro

[openstack-dev] [cinder] Proposals for Liberty Summit

[Mike Perez]

Proposals for the fishbowl, working and sprint sessions with the block
storage project Cinder can be submitted now:

https://etherpad.openstack.org/p/cinder-liberty-proposed-sessions

On April 27th, we will be discussing these together in the Cinder IRC
meeting [1]. This will allow time to set things in the official summit
schedule.

[1] - https://wiki.openstack.org/wiki/CinderMeetings

--
Mike Perez

__
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] New version of python-neutronclient release: 2.3.11

[Joe Gordon]

And this just broke icehouse jobs. Which means devstack-gate is broken.

http://logs.openstack.org/53/157553/1/check/check-tempest-dsvm-full-icehouse/6c63b71//logs/devstacklog.txt.gz#_2015-02-19_22_21_21_419
http://git.openstack.org/cgit/openstack/requirements/tree/global-requirements.txt?h=stable/icehouse#n89

On Thu, Feb 19, 2015 at 1:35 PM, Kyle Mestery  wrote:

> The Neutron team is proud to announce the release of the latest version of
> python-neutronclient. This release includes the following bug fixes and
> improvements:
>
> 3e5c6ba Updated from global requirements
> a774e84 Add unit tests for agentscheduler related commands
> 069b14c Fix for incorrect parameter in user-id error message in shell.py
> 57adb7f Fix CSV formatting of fixed_ips field in port-list command
> 0be3b62 Implement LBaaS object model v2
> 3d6769c Fix typo in test_cli20_agentschedulers filename
> e1633ed Add ip_version to extra dhcp opts
> 59d7564 Skip None id when getting security_group_ids
> 6f7cd14 Reverse order of tests to avoid incompatibility
> b0923a3 Utility method for boolean argument
> 68fc402 Split base function of v2_0.Client into a separate class
> 2dce00b Updated from global requirements
> 51d2a23 Add parser options for port-update and port-create
> 5b1c45a Add floating-ip-address to floatingip-create
> 845f461 Fix KeyError when filtering SG rule listing
> 30bd81c Updated from global requirements
> 86fede6 Remove unreachable code from test_cli20 class
> cb5d462 Parse provider network attributes in net_create
> 78b6310 Parameter support both id and name
> 096fd1b Add '--router:external' option to 'net-create'
> aed3faf Fix TypeError for six.text_type
> d6e40b5 Add Python 3 classifiers
> 4fa57fe Namespace of arguments is incorrectly used
> 4beadef Fix True/False to accept Camel and Lower case
> 799e288 Use adapter from keystoneclient
> 5822d61 Use requests_mock instead of mox
> 4b181cd Updated from global requirements
> 04a0ec8 firewall policy update for a rule is not working
> 0560f85 Fix columns setup base on csv formatter
> 187c36c Correct the bash completion of CLI
> 2f23623 Workflow documentation is now in infra-manual
> 62063c1 Fix issues with Unicode compatibility for Py3
>
> For more details on the release, please see the git log history in the
> release notes in the LP page here:
>
> https://launchpad.net/python-neutronclient/+milestone/2.3.11
>
> Please report any bugs in LP.
>
> Thanks!
> Kyle
>
> __
> 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] New version of python-neutronclient release: 2.3.11

[Joe Gordon]

neutronclient is requiring a keystone client that is way too new for
icehouse. 2.3.11 was released (And breaks with semver), but icehouse has a
limit of <2.4. So global-requirements for icehouse needs to be fixed.

2015-02-19 22:21:21.419

| ERROR: openstackclient.shell Exception raised:
(python-keystoneclient 0.11.2
(/usr/local/lib/python2.7/dist-packages),
Requirement.parse('python-keystoneclient>=1.1.0'),
set(['python-neutronclient']))


Note: I am not pushing the patch to fix this myself, we need more
people who are able to monitor and fix these types of issues.


On Thu, Feb 19, 2015 at 3:35 PM, Joe Gordon  wrote:

> And this just broke icehouse jobs. Which means devstack-gate is broken.
>
>
> http://logs.openstack.org/53/157553/1/check/check-tempest-dsvm-full-icehouse/6c63b71//logs/devstacklog.txt.gz#_2015-02-19_22_21_21_419
>
> http://git.openstack.org/cgit/openstack/requirements/tree/global-requirements.txt?h=stable/icehouse#n89
>
> On Thu, Feb 19, 2015 at 1:35 PM, Kyle Mestery  wrote:
>
>> The Neutron team is proud to announce the release of the latest version
>> of python-neutronclient. This release includes the following bug fixes and
>> improvements:
>>
>> 3e5c6ba Updated from global requirements
>> a774e84 Add unit tests for agentscheduler related commands
>> 069b14c Fix for incorrect parameter in user-id error message in shell.py
>> 57adb7f Fix CSV formatting of fixed_ips field in port-list command
>> 0be3b62 Implement LBaaS object model v2
>> 3d6769c Fix typo in test_cli20_agentschedulers filename
>> e1633ed Add ip_version to extra dhcp opts
>> 59d7564 Skip None id when getting security_group_ids
>> 6f7cd14 Reverse order of tests to avoid incompatibility
>> b0923a3 Utility method for boolean argument
>> 68fc402 Split base function of v2_0.Client into a separate class
>> 2dce00b Updated from global requirements
>> 51d2a23 Add parser options for port-update and port-create
>> 5b1c45a Add floating-ip-address to floatingip-create
>> 845f461 Fix KeyError when filtering SG rule listing
>> 30bd81c Updated from global requirements
>> 86fede6 Remove unreachable code from test_cli20 class
>> cb5d462 Parse provider network attributes in net_create
>> 78b6310 Parameter support both id and name
>> 096fd1b Add '--router:external' option to 'net-create'
>> aed3faf Fix TypeError for six.text_type
>> d6e40b5 Add Python 3 classifiers
>> 4fa57fe Namespace of arguments is incorrectly used
>> 4beadef Fix True/False to accept Camel and Lower case
>> 799e288 Use adapter from keystoneclient
>> 5822d61 Use requests_mock instead of mox
>> 4b181cd Updated from global requirements
>> 04a0ec8 firewall policy update for a rule is not working
>> 0560f85 Fix columns setup base on csv formatter
>> 187c36c Correct the bash completion of CLI
>> 2f23623 Workflow documentation is now in infra-manual
>> 62063c1 Fix issues with Unicode compatibility for Py3
>>
>> For more details on the release, please see the git log history in the
>> release notes in the LP page here:
>>
>> https://launchpad.net/python-neutronclient/+milestone/2.3.11
>>
>> Please report any bugs in LP.
>>
>> Thanks!
>> Kyle
>>
>> __
>> 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] [Glance] [all] glance_store release 0.1.11

[Nikhil Komawar]

The glance_store release management team is pleased to announce:
glance_store version 0.1.11 has been released on Thursday Feb 19th around 
23.40 UTC.

For more information, please find the details at:

https://launchpad.net/glance-store/v0/v0.1.11

Please report the issues through launchpad:

https://bugs.launchpad.net/glance-store


Thanks,
-Nikhil
__
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] [Keystone] Deprecation of Eventlet deployment in Kilo (Removal for "M"-release)

[Robert Collins]

On 20 February 2015 at 08:32, Morgan Fainberg  wrote:
> The Keystone development team is planning to deprecate deployment of
> Keystone under Eventlet during the Kilo cycle. Support for deploying under
> eventlet will be dropped as of the “M”-release of OpenStack.

\o/

-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] [neutron] New version of python-neutronclient release: 2.3.11

[Henry Gessau]

The fix: https://review.openstack.org/157606

On Thu, Feb 19, 2015, Joe Gordon  wrote:
> neutronclient is requiring a keystone client that is way too new for icehouse.
> 2.3.11 was released (And breaks with semver), but icehouse has a limit
> of <2.4. So global-requirements for icehouse needs to be fixed.
> 
> 2015-02-19 22:21:21.419 
> 
>  | ERROR: openstackclient.shell Exception raised: (python-keystoneclient 
> 0.11.2 (/usr/local/lib/python2.7/dist-packages), 
> Requirement.parse('python-keystoneclient>=1.1.0'), 
> set(['python-neutronclient']))
> 
> 
> Note: I am not pushing the patch to fix this myself, we need more people who
> are able to monitor and fix these types of issues.
> 
> 
> On Thu, Feb 19, 2015 at 3:35 PM, Joe Gordon  > wrote:
> 
> And this just broke icehouse jobs. Which means devstack-gate is broken.
> 
> 
> http://logs.openstack.org/53/157553/1/check/check-tempest-dsvm-full-icehouse/6c63b71//logs/devstacklog.txt.gz#_2015-02-19_22_21_21_419
> 
> http://git.openstack.org/cgit/openstack/requirements/tree/global-requirements.txt?h=stable/icehouse#n89
> 
> On Thu, Feb 19, 2015 at 1:35 PM, Kyle Mestery  > wrote:
> 
> The Neutron team is proud to announce the release of the latest
> version of python-neutronclient. This release includes the following
> bug fixes and improvements:
> 
> 3e5c6ba Updated from global requirements
> a774e84 Add unit tests for agentscheduler related commands
> 069b14c Fix for incorrect parameter in user-id error message in 
> shell.py
> 57adb7f Fix CSV formatting of fixed_ips field in port-list command
> 0be3b62 Implement LBaaS object model v2
> 3d6769c Fix typo in test_cli20_agentschedulers filename
> e1633ed Add ip_version to extra dhcp opts
> 59d7564 Skip None id when getting security_group_ids
> 6f7cd14 Reverse order of tests to avoid incompatibility
> b0923a3 Utility method for boolean argument
> 68fc402 Split base function of v2_0.Client into a separate class
> 2dce00b Updated from global requirements
> 51d2a23 Add parser options for port-update and port-create
> 5b1c45a Add floating-ip-address to floatingip-create
> 845f461 Fix KeyError when filtering SG rule listing
> 30bd81c Updated from global requirements
> 86fede6 Remove unreachable code from test_cli20 class
> cb5d462 Parse provider network attributes in net_create
> 78b6310 Parameter support both id and name
> 096fd1b Add '--router:external' option to 'net-create'
> aed3faf Fix TypeError for six.text_type
> d6e40b5 Add Python 3 classifiers
> 4fa57fe Namespace of arguments is incorrectly used
> 4beadef Fix True/False to accept Camel and Lower case
> 799e288 Use adapter from keystoneclient
> 5822d61 Use requests_mock instead of mox
> 4b181cd Updated from global requirements
> 04a0ec8 firewall policy update for a rule is not working
> 0560f85 Fix columns setup base on csv formatter
> 187c36c Correct the bash completion of CLI
> 2f23623 Workflow documentation is now in infra-manual
> 62063c1 Fix issues with Unicode compatibility for Py3
> 
> For more details on the release, please see the git log history in the
> release notes in the LP page here:
> 
> https://launchpad.net/python-neutronclient/+milestone/2.3.11
> 
> Please report any bugs in LP.
> 
> Thanks!
> Kyle
> 
> 
> __
> 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] [Fuel] Cache for packages on master node

[Andrew Woodward]

There where some questions regarding direction for this on the fuel meeting
today. Can you elaborate on the status?

On Thu, Feb 12, 2015 at 12:01 PM, Andrew Woodward  wrote:

>
>
> On Thu, Feb 12, 2015 at 3:59 AM, Tomasz Napierala  > wrote:
>
>>
>> > On 10 Feb 2015, at 23:02, Andrew Woodward  wrote:
>> >
>> > previously we used squid in 3.0 and before. The main problem is that
>> the deployment would proceeded even if not all the packages where cached or
>> even available on the remote. This often lead to broken deployments that
>> where hard to debug and a waste of alot of time. This _MUST_ be resolved or
>> we will re-introduce this horrible work flow that we had placed all the
>> packages on the system for to begin with.
>>
>> Anyway we need to ensure our QA is run against fresh mirror, that would
>> prevent a lot of problems. We also think about how situation in the field
>> can differ from our labs and QA infra - there might be differences indeed.
>>
>> > I think we need to add a requirements that we need to be able to:
>> > a) pre-populate the cacher
>> > b) we need to not start the deployment until we either have every
>> package in the chache (eiew) or at least know every package is reachable
>> currently (or allow the user to select either as a deployment criteria)
>>
>> This sounds for me like creating local mirror ;) We don’t want to do this.
>> We are thinking about mirror verification tool, it was mentioned by
>> eifferent guys already. Do you really think we should prepopulate cache?
>
>
> by pre-populate, I mean that we need to start some form of task that can
> be started to create a repo/mirror of the packages we know we need for the
> installation. The source of where this would be built from could be an ISO,
> or equally any other mirror site. The user should be able to use this as a
> base population for the packages. If the mirror is incomplete this should
> be OK also as long as the user is told that their nodes will attempt to get
> the remaining packages from the internet. The task should be able to be run
> at any time, and if desired the user would be able to make the deployment
> require it to finish first.
>
> so yes, we need both a repo/mirror like now, with a passthrough that might
> use a squid proxy to help with multiple access. Keep in mind that the squid
> proxy would have to work with the virtual router for nodes bp [1]
>
>
>> I hink first node deployment will fetch a lot of packages, and other
>> nodes will be easier. Once we have prototype, we will see some number.
>>
>
> The first OS install will fetch packages, then later the fist of each roll
> will fetch different packages, it's possible we could get all the way to
> compute and fail there because we cant get a package. I can personally
> promise that without something else this will have problems with this the
> same as we did before with 3.0 (I could run two squid layers one in my host
> and one on my fuel vm and still have problems (usually cache misses)). When
> this occurs the result is terrible, hard for not fuel people to realize,
> and you will end up restarting the whole deployment. the user experience
> (UX) from this is horrible. We need the tools to prevent this from
> occurring at all.
>
>
>> Regards,
>> --
>> Tomasz 'Zen' Napierala
>> Sr. OpenStack Engineer
>> tnapier...@mirantis.com
>>
>>
>>
>>
>>
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> [1]
> https://blueprints.launchpad.net/fuel/+spec/virtual-router-for-env-nodes
>
>
> --
> Andrew
> Mirantis
> Fuel community ambassador
> Ceph community
>



-- 
Andrew
Mirantis
Fuel community ambassador
Ceph community
__
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] [nova] Temporary freeze on API changes

[Christopher Yeoh]

Hi,

The Nova API subgroup is planning on releasing V2.1 on Monday (changing its
status from experimental to CURRENT) and merging the first patch which uses
microversions on top of 2.1 on the Wednesday.

In the meantime we'd appreciate it if reviewers did not +A any patchset
which changes the REST API (as it potentially means we'd have to sync
changes to 2.1 as well. Any future api changes should only be applied to
the v2.1/v3 tree and use the microversions mechanism.

When https://review.openstack.org/#/c/140313/ is merged, that will signal
that microversions
is enabled and we are open for patches to v2.1 microversions. At this point
no changes should be accepted to the old v2 api code and anything to the
v2.1 code base should be done using the microversions mechanism.

There is devref docs on how to use microversions either merged or working
its way through gerrit.

Regards,

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

[openstack-dev] [OpenStack-Dev] [gate tests] Cinder drivers being set up as jobs in infra

[John Griffith]

Hey Everyone,

Anteaya was kind enough to ask in the Cinder channel about some tests
that were added to the gate for SheepDog [1].  I would like to know
why there's no process for the projects that are impacted by these
changes to have input?  At the very least if someone is adding test
requirements against the Cinder project for example it should have
votes on the review from Cinder Core members.

Nobody on the Cinder team seems to have had any information regarding
this change (or the Ceph config that was added for that matter).  It
seems odd to me that I hear discussions about the burden on infra
resources regarding the number of projects in OpenStack and what's
taking place there but then at the same time that group merges things
like this?  If there have been discussions with the Cinder PTL in
these cases then forgive me, I wasn't aware and I'll just move along.

My other question is, why is anybody setting up and maintaining their
own CI system?  Couldn't I just setup a stackforge project that
deploys my software in an Instance and push it to infra as well?
Doesn't this seem a bit wrong to anybody else, using Foundation
resources for my own gain?

Also, I think it creates some confusion; we either have a reference
implementation or we don't.  If somebody wants to propose changing
what the reference implementation is that's fine but that should be
handled by the affected project not by a change submitted to the infra
projects.

I've actually been of the opinion that devstack and our internal gate
is bloated with plugins and options and should actually be scaled
down.  We should certainly provide mechanisms for any plugin to be
configured via devstack for example but I don't think the code belongs
"in" devstack; it should be externally maintained in my opinion... but
that's a whole separate rant I suppose.

Thanks,
John

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

__
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] qemu-img disk corruption bug to patch or not?

[Tony Breeds]

Hi all,
In September I started working on a simple (but controvertial) fix in 
nova[1]
to avoid some disk corruption issues.  John kindly ran with a similar fix to 
cinder[2].
John's review ended up in merge conflict so I tried my own version [3].

While (trying) to add workarounds to nova (and cinder) upstream qemu-img was
fixed.  A tracking page for distros was maintained [4].  At the nova mid-cycle
it was decided that enough distros had the fix that juno and kilo would mostly
be unaffected.

So my question is pretty simple.  Does Cinder want/need the fix?  If so I'll
work on knocking [3] into shape if not I'll abandon it.

Yours Tony.

[1] https://review.openstack.org/123957
[2] https://review.openstack.org/141259
[3] https://review.openstack.org/143575
[4] https://wiki.openstack.org/wiki/Bug1368815


pgpMyKZJwgZGo.pgp
Description: PGP 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

Re: [openstack-dev] [OpenStack-Dev] [gate tests] Cinder drivers being set up as jobs in infra

[Clark Boylan]

On Thu, Feb 19, 2015, at 04:38 PM, John Griffith wrote:
> Hey Everyone,
> 
> Anteaya was kind enough to ask in the Cinder channel about some tests
> that were added to the gate for SheepDog [1].  I would like to know
> why there's no process for the projects that are impacted by these
> changes to have input?  At the very least if someone is adding test
> requirements against the Cinder project for example it should have
> votes on the review from Cinder Core members.
I approved this change. The only project directly affected is the
sheepdog devstack plugin. They are testing that the plugin works. I
don't understand why this is a problem. This test was not added to
Cinder.
> 
> Nobody on the Cinder team seems to have had any information regarding
> this change (or the Ceph config that was added for that matter).  It
> seems odd to me that I hear discussions about the burden on infra
> resources regarding the number of projects in OpenStack and what's
> taking place there but then at the same time that group merges things
> like this?  If there have been discussions with the Cinder PTL in
> these cases then forgive me, I wasn't aware and I'll just move along.
Again this change did not affect Cinder. Not sure why this is
problematic. There is a second change,
https://review.openstack.org/#/c/153868, that has not been approved that
would run this test against Cinder, but a project-config core reviewer
reached out to Cinder before approving that change. This appears to be
what you would like to see so thats good.

The ceph job was added in https://review.openstack.org/#/c/147559/ and a
quick scan of comments does show it to have had positive votes from a
Cinder core.
> 
> My other question is, why is anybody setting up and maintaining their
> own CI system?  Couldn't I just setup a stackforge project that
> deploys my software in an Instance and push it to infra as well?
> Doesn't this seem a bit wrong to anybody else, using Foundation
> resources for my own gain?
For open source projects that don't require special hardware we have
wanted more people to cooperate with Infra to run tests upstream. Third
party CI is a great solution for when you cannot redistribute certain
pieces of software or specific hardware is required. But in general if
it is open source and we can test it in our clouds then we would at
least like to talk about doing it that way.

There are some rough edges with that particularly if you don't want
things to gate or be similar to gating due to clean check. Basically we
need a way to report results back to Gerrit as a user other than Jenkins
so that the Jenkins results are still used for gating (there are
probably other alternatives too but the second account method is in
development).
> 
> Also, I think it creates some confusion; we either have a reference
> implementation or we don't.  If somebody wants to propose changing
> what the reference implementation is that's fine but that should be
> handled by the affected project not by a change submitted to the infra
> projects.
> 
> I've actually been of the opinion that devstack and our internal gate
> is bloated with plugins and options and should actually be scaled
> down.  We should certainly provide mechanisms for any plugin to be
> configured via devstack for example but I don't think the code belongs
> "in" devstack; it should be externally maintained in my opinion... but
> that's a whole separate rant I suppose.
> 
> Thanks,
> John
> 
> [1]: https://review.openstack.org/#/c/154605/
> 
Hope this helps clarify things.

Clark

__
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][oslo] Dealing with database connection sharing issues

[Joshua Harlow]

Doug Hellmann wrote:


On Thu, Feb 19, 2015, at 01:09 PM, Ben Nemec wrote:

Hi,

Mike Bayer recently tracked down an issue with database errors in Cinder
to a single database connection being shared over multiple processes.
This is not something that should happen, and it turns out to cause
intermittent failures in the Cinder volume service.  Full details can be
found in the bug here: https://bugs.launchpad.net/cinder/+bug/1417018
and his mailing list thread here:
http://lists.openstack.org/pipermail/openstack-dev/2015-February/057184.html

The question we're facing is what to do about it.  There's quite a lot
of discussion on https://review.openstack.org/#/c/156725 and in
http://eavesdrop.openstack.org/irclogs/%23openstack-oslo/%23openstack-oslo.2015-02-18.log
starting at 2015-02-18T21:38:12  but I'll try to summarize it here.

On the plus side, we have a way to detect this sort of thing in oslo.db.
That's what Mike's change 156725 is about.  On the minus side,
recovering from this in oslo.db is papering over a legitimate problem in
the calling service, and a lot of the discussion has been around how to
communicate that to the calling service.  A few options that have been
mentioned:

1) Leave the linked change as-is, with a warning logged that will
hopefully be seen and prompt a fix in the service.

The concerns raised with this is that the warning log level is a very
operator-visible thing and there's nothing an operator can do to fix
this other than pester the developers.  Also, it seems developers tend
to ignore logs, so it's unlikely they'll pick up on it themselves.

Note that while the errors resulting from this situation are
intermittent, the actual situation happens on every start up of
cinder-volume, so these messages will always be logged as it stands
today.

2) Change the log message to debug.

This is the developer-focused log level, but as noted above developers
tend to ignore logs and it will be very easy for the message to get lost
in the debug noise.  This option would likely require someone to go
specifically looking for the error to find it.

3) Make the error a hard failure.

Rather than hide the error by recovering, fail immediately when it's
detected.  This has the problem of making all the existing Cinder code
(and any other services with the same problem) in the wild incompatible
with any new releases of oslo.db, but it's about the only way to make
sure the error will be addressed now and in any future occurrences.

4) Leave the bug alone for now and just log a message so we can find out
how widespread this problem actually is.

At the moment we only know it exists in Cinder, but due to the way the
service code works it's quite possible other projects have the same
problem and don't know it yet.

5) Allow this sort of connection sharing to continue for a deprecation
period with apppropriate logging, then make it a hard failure.

This would provide services time to find and fix any sharing problems
they might have, but would delay the timeframe for a final fix.

6-ish) Fix oslo-incubator service.py to close all file descriptors after
forking.

This is a best practice anyway so it's something we intend to pursue,
but it's probably more of a long-term fix because it will take some work
to implement and make sure it doesn't break existing services.  It also
papers over the problem and according to Mike is basically a slower and
messier alternative to his current proposed change, so it's probably a
tangential change to avoid this in the future as opposed to a solution.

If you've made it this far, thank you and please provide thoughts on the
options presented above. :-)


I'm not sure why 6 is "slower", can someone elaborate on that?


Whether it's slower or not I put up:

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

It's still not fully functional (something is not quite right with it 
still...) but it will close any potentially left open file descriptors.




Doug


-Ben

__
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

[openstack-dev] [qa] Tempest Bug triage

[GHANSHYAM MANN]

All,
As we all know, bug triage rotation really helps us to respond Tempest bugs
as quick as possible and keep bug count low.

Thanks for signing up in bug triage rotation.

To continue the same strategy and keeping good progress on bugs, we need
more volunteers to sign-up for coming weeks.

People who want to help in bug triage, feel free to put your name in
https://etherpad.openstack.org/p/qa-bug-triage-rotation


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

Re: [openstack-dev] [OpenStack-Dev] [gate tests] Cinder drivers being set up as jobs in infra

[John Griffith]

On Thu, Feb 19, 2015 at 5:59 PM, Clark Boylan  wrote:
>
>
> On Thu, Feb 19, 2015, at 04:38 PM, John Griffith wrote:
>> Hey Everyone,
>>
>> Anteaya was kind enough to ask in the Cinder channel about some tests
>> that were added to the gate for SheepDog [1].  I would like to know
>> why there's no process for the projects that are impacted by these
>> changes to have input?  At the very least if someone is adding test
>> requirements against the Cinder project for example it should have
>> votes on the review from Cinder Core members.
> I approved this change. The only project directly affected is the
> sheepdog devstack plugin. They are testing that the plugin works. I
> don't understand why this is a problem. This test was not added to
> Cinder.

I suppose that's fair, the bigger question I have though is where we
set the allocation of resources?

>>
>> Nobody on the Cinder team seems to have had any information regarding
>> this change (or the Ceph config that was added for that matter).  It
>> seems odd to me that I hear discussions about the burden on infra
>> resources regarding the number of projects in OpenStack and what's
>> taking place there but then at the same time that group merges things
>> like this?  If there have been discussions with the Cinder PTL in
>> these cases then forgive me, I wasn't aware and I'll just move along.
> Again this change did not affect Cinder. Not sure why this is
> problematic. There is a second change,
> https://review.openstack.org/#/c/153868, that has not been approved that
> would run this test against Cinder, but a project-config core reviewer
> reached out to Cinder before approving that change. This appears to be
> what you would like to see so thats good.

Yes, thank you for pointing that out, that is in fact more relevant to
my concerns.

>
> The ceph job was added in https://review.openstack.org/#/c/147559/ and a
> quick scan of comments does show it to have had positive votes from a
> Cinder core.

Indeed, we have core representation from Redhat and I fully trust his
judgement here.  The issue isn't so much if the add is "ok" but more
along the lines of what I mentioned earlier regarding use of
resources.  Maybe I've interpreted things incorrectly and there is no
resource issue with infra; in which case I was way off base and again
I should butt out.

>>
>> My other question is, why is anybody setting up and maintaining their
>> own CI system?  Couldn't I just setup a stackforge project that
>> deploys my software in an Instance and push it to infra as well?
>> Doesn't this seem a bit wrong to anybody else, using Foundation
>> resources for my own gain?
> For open source projects that don't require special hardware we have
> wanted more people to cooperate with Infra to run tests upstream. Third
> party CI is a great solution for when you cannot redistribute certain
> pieces of software or specific hardware is required. But in general if
> it is open source and we can test it in our clouds then we would at
> least like to talk about doing it that way.

Fair enough, I wasn't aware that this was the direction we had taken.
I certainly agree with the need for other ways to help out Open Source
projects.  My only concern in this case was that I know there has been
a lot of work by first Duncan and now Mike to try and keep track of
and communicate driver testing efforts.  This sort of came out of
nowhere for me personally and a number of other people on the Cinder
team.  If nothing else it would just be good to know what efforts are
in progress.  For the record I have no issue with the SheepDog driver
(well assuming it's up to date now; it had fallen pretty far behind as
of Juno).  That's the sort of thing that I think does impact Cinder,
verifying the project is actually active in Cinder, that there's some
visible maintenance and that it actually "works".  Granted that would
be sorted out soon enough just by the process itself I suppose.

>
> There are some rough edges with that particularly if you don't want
> things to gate or be similar to gating due to clean check. Basically we
> need a way to report results back to Gerrit as a user other than Jenkins
> so that the Jenkins results are still used for gating (there are
> probably other alternatives too but the second account method is in
> development).

The points you made above are probably the biggest thing that bothered
me here and the fact that you're already working on it... well then
good enough.  My problem here is signal to noise ratio when conducting
reviews; I rely heavily on the "Jenkins" table to use as a filter.

>>
>> Also, I think it creates some confusion; we either have a reference
>> implementation or we don't.  If somebody wants to propose changing
>> what the reference implementation is that's fine but that should be
>> handled by the affected project not by a change submitted to the infra
>> projects.
>>
>> I've actually been of the opinion that devstack and our internal gate
>> is blo

[openstack-dev] [nova] gate is fubar (again)

[Matt Riedemann]

The novaclient 2.21 release had a bug in some bash completion code that 
blows up the voting devstack cells job that runs exercises.  The bug 
tracking the novaclient issue is:


https://bugs.launchpad.net/nova/+bug/1423695

We're blocking the 2.21 release in global-requirements to get master 
unblocked:


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

Then we're doing a revert of a change for bash completion in novaclient 
to at least workaround the bug on trunk novaclient code:


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

That, however, is blocked on icehouse being blocked due to the 
neutronclient 2.3.11 release today which was uncapped on stable/icehouse 
global-requirements, so we have this bug:


https://bugs.launchpad.net/python-neutronclient/+bug/1423753

There is a cap proposed for stable/icehouse:

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

But that's blocked on some other requirements weirdness, looks like a 
problem with openstackclient version requirements and other caps in 
stable/icehouse.


Regarding the novaclient change, the plan is to get either the devstack 
cells exercise job voting on novaclient changes again (which it was at 
some point prior to the 2.21 release and should have caught this 
problem), or get a functional test in novaclient that hits the bash 
completion problem - then we can revert the revert and make that work 
with the current code on master.


I might have missed something but figured it'd be good to get this out 
so people are aware that things are busted, again.


--

Thanks,

Matt Riedemann


__
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] [os-ansible-deployment] Changes in the "os-ansible-deployment" project

[Kevin Carter]

Hello all,

Over the past few weeks the os-ansible-deployment team has been working on 
getting the repository (https://github.com/stackforge/os-ansible-deployment) 
into a more community friendly state. For anyone who’s look at the project in 
the past and thought it was too Rackspace specific I’m here to announce that 
we’ve fixed that. The project has been De-Rackspace’d and Genericized while 
maintaining the reference architecture and intent. As of today, we’ve fully 
excised all of Rackspace Private Cloud specific roles and playbooks and have 
converted the remaining roles and playbooks into ones using Ansible best 
practices. We still have a lot of work to do but the project is growing in 
capability and scale and we’re eager to begin working more with the greater 
OpenStack community on what we think will be an asset to Operators and 
Developers alike. If you have an interest in Ansible, LXC containers, and/or 
deployments from source we’d love to have you join our community.

Weekly meetings: https://wiki.openstack.org/wiki/Meetings/openstack-ansible
IRC channel: #openstack-ansible

Thank you again to everyone who’s contributed so far and we look forward to 
seeing you online.

—

Kevin



signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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] [ovs-dev] [PATCH 8/8] [RFC] [neutron] ovn: Start work on design ocumentation.

[Kevin Benton]

Yes, if there is an action similar to the 'RELATED' and 'ESTABLISHED'
keywords, then that should be adequate to replace the iptables solution
that we have now.

You are correct about the reason behind the explosion of rules. In security
groups, we allow the source/dest field to be a reference to a security
group. That was resulting in one security group rule turning into N
iptables rules, where N was the number of IPs in the security group. This
was resolved using IP sets. If OVN supports the set syntax you described,
that should achieve parity on that front as well.


On Thu, Feb 19, 2015 at 2:15 PM, Kyle Mestery  wrote:

> [Adding neutron tag to subject, comments below.]
>
> On Thu, Feb 19, 2015 at 3:55 PM, Ben Pfaff  wrote:
>
>> [moving this conversation to openstack-dev because it's more
>> interesting there and that avoids crossposting to a subscribers-only
>> list]
>>
>> On Thu, Feb 19, 2015 at 10:57:02AM +0100, Miguel ??ngel Ajo wrote:
>> >I specially liked the VIF port lifecycle, looks good to me, Ionly
>> miss some
>> > ???port_security??? concepts we have in neutron, which I guess could
>> have been
>> > deliberately omitted for a start.
>> >
>> >In neutron we have something called security groups, and every port
>> > belongs to 1 or more security groups.  Each security group has a list of
>> > rules to control traffic at port level in a very fine grained fashion
>> (ingress/egress
>> > protocol/flags/etc???   remote_ip/mask or security_group ID)
>> >
>> > I guess we could build  render security_group ID to multiple IPs for
>> each port,
>> > but then we will miss the ingress/egress and protocol flags (like type
>> of protocol,
>> > ports, etc.. [1])
>> >
>> > Also, be aware, that not having security group ID references from
>> neutron,
>> > when lot???s of ports go to the same security group we end up with an
>> exponential
>> > growth of rules / OF entries per port, we solved this in the
>> server<->agent
>> > communication for the reference OVS solution by keeping a lists of IPs
>> > belonging to security group IDs, and then, separately having the
>> > references from the rules.
>>
>> Thanks a lot for the comment.
>>
>> We aim to fully support security groups in OVN.  The current documents
>> don't capture that intent.  (That's partly because we're planning to
>> implement them in terms of some new "connection tracking" code for OVS
>> that's still in the process of getting committed, and partly because I
>> haven't fully thought them through yet.)
>>
>> My initial reaction is that we can implement security groups as
>> another action in the ACL table that is similar to "allow" but in
>> addition permits reciprocal inbound traffic.  Does that sound
>> sufficient to you?
>>
>> Is the exponential explosion due to cross-producting, that is, because
>> you have, say, n1 source addresses and n2 destination addresses and so
>> you need n1*n2 flows to specify all the combinations?  We aim to solve
>> that in OVN by giving the CMS direct support for more sophisticated
>> matching rules, so that it can say something like:
>>
>> ip.src in {, , , ...} && ip.dst in {, , , ...}
>> && (tcp.src in {80, 443, 8080} || tcp.dst in {80, 443, 8080})
>>
>> and let OVN implement it in OVS via the "conjunctive match" feature
>> recently added, which is like a set membership match but more
>> powerful.  It might still be nice to support lists of IPs (or
>> whatever), since these lists could still recur in a number of
>> circumstances, but my guess is that this will help a lot even without
>> that.
>>
>> Thoughts?
>>
>> This all sounds really good to me Ben. I look forward to seeing the
> connection tracking code land and some design details on the security
> groups aspects of OVN published once that happens!
>
> Thanks,
> Kyle
>
>
>> __
>> 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
>
>


-- 
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

Re: [openstack-dev] [all][oslo] Dealing with database connection sharing issues

[Mike Bayer]

Doug Hellmann  wrote:

>> 5) Allow this sort of connection sharing to continue for a deprecation
>> period with apppropriate logging, then make it a hard failure.
>> 
>> This would provide services time to find and fix any sharing problems
>> they might have, but would delay the timeframe for a final fix.
>> 
>> 6-ish) Fix oslo-incubator service.py to close all file descriptors after
>> forking.
>> 
> 
> I'm not sure why 6 is "slower", can someone elaborate on that?

So, option “A”, they call engine.dispose() the moment they’re in a fork, the 
activity upon requesting a connection from the pool is: look in pool, no 
connections present, create a connection and return it.

Option “5”, the way the patch is right now to auto-invalidate on detection of 
new fork, the activity upon requesting a connection is from the pool is: look 
in pool, connection present, check that os.pid() matches what we’ve associated 
with the connection record, if not, we raise an exception indicating “invalid”, 
this is immediately caught, sets the connection record as “invalid”, the 
connection record them immediately disposes that file descriptor, makes a new 
connection and returns that.

Option “6”, the new fork starts, the activity upon requesting a connection from 
the pool is: look in pool, connection present, perform the oslo.db “ping” 
event, ping event emits “SELECT 1” to the MySQLdb driver, driver attempts to 
emit this statement on the socket, socket communication fails, MySQLdb converts 
to an exception, exception is raised, SQLAlchemy catches the exception, sends 
it to a parser to determine the nature of the exception, we see that it’s a 
“disconnect” exception, we set the “invalidate” flag on the exception, we 
re-raise, oslo.db’s exc_filters then catch the exception, more string parsers 
get involved, we determine we need to raise an oslo.db.DBDisconnect exception, 
we raise that, the “SELECT 1” ping handler catches that, we then emit “SELECT 
1” again so that it reconnects, we then hit the connection record that’s in 
“invalid” state so it knows to reconnect, it reconnects and the “SELECT 1” 
continues on the new connection and we start up.

So essentially option “5” (the way the gerrit is right now) has a subset of the 
components of “6”; “6” has the additional steps of: emit a doomed statement on 
the closed socket, then when it fails raise / catch / parse / reraise / catch / 
parse / reraise that exception.   Option “5” just has, check the pid, raise / 
catch an exception.

IMO the two options are: “5”, check the pid and recover or “3” make it a hard 
failure.
 
__
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][oslo] Dealing with database connection sharing issues

[Mike Bayer]

Joshua Harlow  wrote:

> Doug Hellmann wrote:
>> On Thu, Feb 19, 2015, at 01:09 PM, Ben Nemec wrote:
>>> Hi,
>>> 
>>> Mike Bayer recently tracked down an issue with database errors in Cinder
>>> to a single database connection being shared over multiple processes.
>>> This is not something that should happen, and it turns out to cause
>>> intermittent failures in the Cinder volume service.  Full details can be
>>> found in the bug here: https://bugs.launchpad.net/cinder/+bug/1417018
>>> and his mailing list thread here:
>>> http://lists.openstack.org/pipermail/openstack-dev/2015-February/057184.html
>>> 
>>> The question we're facing is what to do about it.  There's quite a lot
>>> of discussion on https://review.openstack.org/#/c/156725 and in
>>> http://eavesdrop.openstack.org/irclogs/%23openstack-oslo/%23openstack-oslo.2015-02-18.log
>>> starting at 2015-02-18T21:38:12  but I'll try to summarize it here.
>>> 
>>> On the plus side, we have a way to detect this sort of thing in oslo.db.
>>> That's what Mike's change 156725 is about.  On the minus side,
>>> recovering from this in oslo.db is papering over a legitimate problem in
>>> the calling service, and a lot of the discussion has been around how to
>>> communicate that to the calling service.  A few options that have been
>>> mentioned:
>>> 
>>> 1) Leave the linked change as-is, with a warning logged that will
>>> hopefully be seen and prompt a fix in the service.
>>> 
>>> The concerns raised with this is that the warning log level is a very
>>> operator-visible thing and there's nothing an operator can do to fix
>>> this other than pester the developers.  Also, it seems developers tend
>>> to ignore logs, so it's unlikely they'll pick up on it themselves.
>>> 
>>> Note that while the errors resulting from this situation are
>>> intermittent, the actual situation happens on every start up of
>>> cinder-volume, so these messages will always be logged as it stands
>>> today.
>>> 
>>> 2) Change the log message to debug.
>>> 
>>> This is the developer-focused log level, but as noted above developers
>>> tend to ignore logs and it will be very easy for the message to get lost
>>> in the debug noise.  This option would likely require someone to go
>>> specifically looking for the error to find it.
>>> 
>>> 3) Make the error a hard failure.
>>> 
>>> Rather than hide the error by recovering, fail immediately when it's
>>> detected.  This has the problem of making all the existing Cinder code
>>> (and any other services with the same problem) in the wild incompatible
>>> with any new releases of oslo.db, but it's about the only way to make
>>> sure the error will be addressed now and in any future occurrences.
>>> 
>>> 4) Leave the bug alone for now and just log a message so we can find out
>>> how widespread this problem actually is.
>>> 
>>> At the moment we only know it exists in Cinder, but due to the way the
>>> service code works it's quite possible other projects have the same
>>> problem and don't know it yet.
>>> 
>>> 5) Allow this sort of connection sharing to continue for a deprecation
>>> period with apppropriate logging, then make it a hard failure.
>>> 
>>> This would provide services time to find and fix any sharing problems
>>> they might have, but would delay the timeframe for a final fix.
>>> 
>>> 6-ish) Fix oslo-incubator service.py to close all file descriptors after
>>> forking.
>>> 
>>> This is a best practice anyway so it's something we intend to pursue,
>>> but it's probably more of a long-term fix because it will take some work
>>> to implement and make sure it doesn't break existing services.  It also
>>> papers over the problem and according to Mike is basically a slower and
>>> messier alternative to his current proposed change, so it's probably a
>>> tangential change to avoid this in the future as opposed to a solution.
>>> 
>>> If you've made it this far, thank you and please provide thoughts on the
>>> options presented above. :-)
>> 
>> I'm not sure why 6 is "slower", can someone elaborate on that?
> 
> Whether it's slower or not I put up:
> 
> https://review.openstack.org/#/c/157608
> 
> It's still not fully functional (something is not quite right with it 
> still...) but it will close any potentially left open file descriptors.

I think that should be in place as well.   oslo.db’s check and this activity 
are not mutually exclusive.

My concern is that we put mechanisms in place which make everything work out 
but do it all in a slow and foolish way. The way openstack apps try to 
recover from everything tends to lead to this, e.g. things are configured wrong 
but nobody notices, things just run terribly.  Example.  We set HAProxy to time 
out in 90 seconds, even though the connections are pooled and are expected to 
live idle as long as 60 minutes.   The application logs hundreds of “connection 
closed” errors, all of which are recovered from by detecting them with our 
“SELECT 1” handler and reconnecting.   The app r

Re: [openstack-dev] [Keystone] Deprecation of Eventlet deployment in Kilo (Removal for "M"-release)

[Mike Bayer]

Morgan Fainberg  wrote:

> The Keystone development team is planning to deprecate deployment of Keystone 
> under Eventlet during the Kilo cycle. Support for deploying under eventlet 
> will be dropped as of the “M”-release of OpenStack.
> 
> The reasoning behind this move is multifaceted but the core of the reasons 
> are as follows:
> 
>   • Keystone relies on apache/web-server modules to handle federated 
> identity (validation of SAML, etc) and similar SSO type authentication 
> (Kerberos).
>   • Eventlet has proven problematic when it comes to workloads within 
> Keystone, notably that a number of actions cannot yield (either due to 
> lacking in Eventlet, or that the dependent library uses C-bindings that 
> eventlet is not able to work with).
>   • Keystone has recommended (for multiple cycles) deploying Keystone 
> under apache instead of eventlet. In the gate we primarily test all new 
> development under Apache/mod_wsgi deployments. 
>   • Most deployers I’ve discussed keystone deployment with are either 
> already on httpd+mod_wsgi or looking to move that direction (for support of 
> features such as federated auth).
> The review to finalize the deprecation is: 
> https://review.openstack.org/#/c/157495/ (Please only provide comments on 
> deprecation, verbiage can be modified separately from the actual act of 
> deprecation).
> 
> Please comment on the review or in reply to this Email.

+1 dropping eventlet.



__
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][oslo] Dealing with database connection sharing issues

[Carl Baldwin]

On Thu, Feb 19, 2015 at 7:45 PM, Mike Bayer  wrote:
> So, option “A”, they call engine.dispose() the moment they’re in a fork, the 
> activity upon requesting a connection from the pool is: look in pool, no 
> connections present, create a connection and return it.

FWIW, this is what Neutron does:

https://github.com/openstack/neutron/blob/c9713d09/neutron/wsgi.py#L104

Carl

__
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][lbaas]Topics and possible fomats for LBaaS in OpenStack/Vancouver

[Doug Wiegley]

Hi all,

I requested a session for future lbaas features and prioritizing (and attaching 
contributors to those features.)  Assuming that happens, I started an etherpad 
here, starting with Sam’s info:

https://etherpad.openstack.org/p/lbaas-vancouver-planning 


Thanks,
doug



> On Feb 18, 2015, at 12:53 PM, Samuel Bercovici  wrote:
> 
> Hi Everyone,
>  
> Based on the last IRC, I thought we could start a discussion on ML on topics 
> and then maybe on how we want to discuss durin the summit.
> Follows some items we may wish to discuss:
> 1.   LBaaS API additions (assuming TLS and L7 will be there):
> a.   L3 based traffic routing – LB, listener, pool selection based on 
> source IP network classes
> b.  TLS phase 2:
>i.  Client 
> side re-encryption
>  ii.  Client 
> certificates
> c.   Service Insertion models (in addition to proxy based)
>i.  
> Transparent mode
> d.  Object sharing (yes/no)
>i.  Pools
> e.  Monitoring APIs
>i.  
> Integration with Ceilometer
> f.Batch updates – create a full configuration graph and control when 
> it get scheduled
> 2.   Quota support (ex: max number of LBs, listeners, TLS certificates, 
> etc.)
> 3.   HEAT integration
> 4.   Horizon Support
> 5.   LBaaS API extensions – ability to add “experimental and vendor APIs”
>  
> Regards,
> -Sam.
>  
>  
> __
> 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] [cinder] qemu-img disk corruption bug to patch or not?

[John Griffith]

On Thu, Feb 19, 2015 at 5:53 PM, Tony Breeds  wrote:
> Hi all,
> In September I started working on a simple (but controvertial) fix in 
> nova[1]
> to avoid some disk corruption issues.  John kindly ran with a similar fix to 
> cinder[2].
> John's review ended up in merge conflict so I tried my own version [3].
>
> While (trying) to add workarounds to nova (and cinder) upstream qemu-img was
> fixed.  A tracking page for distros was maintained [4].  At the nova mid-cycle
> it was decided that enough distros had the fix that juno and kilo would mostly
> be unaffected.
>
> So my question is pretty simple.  Does Cinder want/need the fix?  If so I'll
> work on knocking [3] into shape if not I'll abandon it.
>
> Yours Tony.
>
> [1] https://review.openstack.org/123957
> [2] https://review.openstack.org/141259
> [3] https://review.openstack.org/143575
> [4] https://wiki.openstack.org/wiki/Bug1368815

Hi Tony,

Thanks for sending this out, and for the complete summary.  I'm
inclined to lean towards working the option for Cinder personally.
Granted it looks like the update is in the distro packages to fix
this, but I'm wondering about backport and cases for installs that are
on say 12.04?  Maybe that's not an issue?

Anybody else have thoughts on this?

Thanks,
John

__
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] New version of python-neutronclient release: 2.3.11

[Matt Riedemann]

On 2/19/2015 6:06 PM, Henry Gessau wrote:

The fix: https://review.openstack.org/157606

On Thu, Feb 19, 2015, Joe Gordon  wrote:

neutronclient is requiring a keystone client that is way too new for icehouse.
2.3.11 was released (And breaks with semver), but icehouse has a limit
of <2.4. So global-requirements for icehouse needs to be fixed.

2015-02-19 22:21:21.419 

 | ERROR: openstackclient.shell Exception raised: (python-keystoneclient 0.11.2 
(/usr/local/lib/python2.7/dist-packages), 
Requirement.parse('python-keystoneclient>=1.1.0'), set(['python-neutronclient']))


Note: I am not pushing the patch to fix this myself, we need more people who
are able to monitor and fix these types of issues.


On Thu, Feb 19, 2015 at 3:35 PM, Joe Gordon mailto:joe.gord...@gmail.com>> wrote:

 And this just broke icehouse jobs. Which means devstack-gate is broken.

 
http://logs.openstack.org/53/157553/1/check/check-tempest-dsvm-full-icehouse/6c63b71//logs/devstacklog.txt.gz#_2015-02-19_22_21_21_419
 
http://git.openstack.org/cgit/openstack/requirements/tree/global-requirements.txt?h=stable/icehouse#n89

 On Thu, Feb 19, 2015 at 1:35 PM, Kyle Mestery mailto:mest...@mestery.com>> wrote:

 The Neutron team is proud to announce the release of the latest
 version of python-neutronclient. This release includes the following
 bug fixes and improvements:

 3e5c6ba Updated from global requirements
 a774e84 Add unit tests for agentscheduler related commands
 069b14c Fix for incorrect parameter in user-id error message in 
shell.py
 57adb7f Fix CSV formatting of fixed_ips field in port-list command
 0be3b62 Implement LBaaS object model v2
 3d6769c Fix typo in test_cli20_agentschedulers filename
 e1633ed Add ip_version to extra dhcp opts
 59d7564 Skip None id when getting security_group_ids
 6f7cd14 Reverse order of tests to avoid incompatibility
 b0923a3 Utility method for boolean argument
 68fc402 Split base function of v2_0.Client into a separate class
 2dce00b Updated from global requirements
 51d2a23 Add parser options for port-update and port-create
 5b1c45a Add floating-ip-address to floatingip-create
 845f461 Fix KeyError when filtering SG rule listing
 30bd81c Updated from global requirements
 86fede6 Remove unreachable code from test_cli20 class
 cb5d462 Parse provider network attributes in net_create
 78b6310 Parameter support both id and name
 096fd1b Add '--router:external' option to 'net-create'
 aed3faf Fix TypeError for six.text_type
 d6e40b5 Add Python 3 classifiers
 4fa57fe Namespace of arguments is incorrectly used
 4beadef Fix True/False to accept Camel and Lower case
 799e288 Use adapter from keystoneclient
 5822d61 Use requests_mock instead of mox
 4b181cd Updated from global requirements
 04a0ec8 firewall policy update for a rule is not working
 0560f85 Fix columns setup base on csv formatter
 187c36c Correct the bash completion of CLI
 2f23623 Workflow documentation is now in infra-manual
 62063c1 Fix issues with Unicode compatibility for Py3

 For more details on the release, please see the git log history in the
 release notes in the LP page here:

 https://launchpad.net/python-neutronclient/+milestone/2.3.11

 Please report any bugs in LP.

 Thanks!
 Kyle

 
__
 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



That's busted by other things at the moment, it sounds like the solution 
starts here:


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

--

Thanks,

Matt Riedemann


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-req

[openstack-dev] Bug related to nova boot (Opinion State)

[Rattenpal Amandeep]

 Hi Team

Please discuss the bug given below:

https://bugs.launchpad.net/python-novaclient/+bug/1415319

Is it a bug ? the bug is left for discussion.

Thanks,
Amandeep
Mail to: rattenpal.amand...@tcs.com 

=-=-=
Notice: The information contained in this e-mail
message and/or attachments to it may contain 
confidential or privileged information. If you are 
not the intended recipient, any dissemination, use, 
review, distribution, printing or copying of the 
information contained in this e-mail message 
and/or attachments to it are strictly prohibited. If 
you have received this communication in error, 
please notify us by reply e-mail or telephone and 
immediately and permanently delete the message 
and any attachments. Thank you


__
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] [nova] [pythona-novaclient] Bug related to nova boot (Opinion State)

[Rattenpal Amandeep]

Hi Team

Please discuss the bug given below:

https://bugs.launchpad.net/python-novaclient/+bug/1415319

Is it a bug ? the bug is left for discussion.

Thanks,
Amandeep
Mail to: rattenpal.amand...@tcs.com   
=-=-=
Notice: The information contained in this e-mail
message and/or attachments to it may contain 
confidential or privileged information. If you are 
not the intended recipient, any dissemination, use, 
review, distribution, printing or copying of the 
information contained in this e-mail message 
and/or attachments to it are strictly prohibited. If 
you have received this communication in error, 
please notify us by reply e-mail or telephone and 
immediately and permanently delete the message 
and any attachments. Thank you


__
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] [ironic]

[Ganapathy, Sandhya]

Hi All,

I would like to discuss the Chassis Discovery Tool Blueprint - 
https://review.openstack.org/#/c/134866/

The blueprint suggests Hardware enrollment and introspection for properties at 
the Chassis layer. Suitable for micro-servers that have an active chassis to 
query for details.
Initially, the idea was proposed as an API change at the Ironic layer. We found 
many complexities such as interaction with conductor and the point of nodes in 
a chassis being mapped to different conductors.
So, decision was taken to keep it as a separate tool above the Ironic API 
layer.  It is a generic tool that can be plugged in for specific hardware.

There are different opinions from the community on this and it will be good to 
come to a consensus.

I have also added the topic as an agenda in the Ironic IRC meeting.

Thanks,
Sandhya
__
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] [lbaas] Querries Regarding Health Monitor parameter in loadbalancer

[Rattenpal Amandeep]

 Hi Team

As per V2 API specification load balancer healthmonitor has a parameter "type" 
which can not be parsed by JSON parser.
 So, it must be replaced by "healthmonitor_type" as per the OpenDayLight Bug-
( https://bugs.opendaylight.org/show_bug.cgi?id=1674 )

I reported a bug related to this 
(https://bugs.launchpad.net/neutron/+bug/1415336 ) 
Should i make changes on the health monitor parameter ..?

Thanks
Amandeep
Mail to: rattenpal.amand...@tcs.com 
=-=-=
Notice: The information contained in this e-mail
message and/or attachments to it may contain 
confidential or privileged information. If you are 
not the intended recipient, any dissemination, use, 
review, distribution, printing or copying of the 
information contained in this e-mail message 
and/or attachments to it are strictly prohibited. If 
you have received this communication in error, 
please notify us by reply e-mail or telephone and 
immediately and permanently delete the message 
and any attachments. Thank you


__
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] [stable][requirements] External dependency caps introduced in 499db6b

[Adam Gandelman]

Its more than just the naming.  In the original proposal, requirements.txt
is the compiled list of all pinned deps (direct and transitive), while
requirements.in reflects what people will actually use.  Whatever is in
requirements.txt affects the egg's requires.txt. Instead, we can keep
requirements.txt unchanged and have it still be the canonical list of
dependencies, while
reqiurements.out/requirements.gate/requirements.whatever is an upstream
utility we produce and use to keep things sane on our slaves.

Maybe all we need is:

* update the existing post-merge job on the requirements repo to produce a
requirements.txt (as it does now) as well the compiled version.

* modify devstack in some way with a toggle to have it process dependencies
from the compiled version when necessary

I'm not sure how the second bit jives with the existing devstack
installation code, specifically with the libraries from git-or-master but
we can probably add something to warm the system with dependencies from the
compiled version prior to calling pip/setup.py/etc

Adam



On Thu, Feb 19, 2015 at 2:31 PM, Joe Gordon  wrote:

>
>
> On Thu, Feb 19, 2015 at 1:48 PM, Adam Gandelman  wrote:
>
>> This creates a bit of a problem for downstream (packagers and probably
>> others)  Shipping a requirements.txt with explicit pins will end up
>> producing an egg with a requires.txt that reflects those pins, unless there
>> is some other magic planned that I'm not aware of.  I can't speak for all
>> packaging flavors, but I know debian packaging interacts quite closely with
>> things like requirements.txt and resulting egg's requires.txt to determine
>> appropriate system-level package dependencies.  This would require a lot of
>> tedious work on packagers part to get something functional.
>>
>> What if its flipped? How about keeping requirements.txt with the caps,
>> and using that as input to produce something like requirements.gate that
>> passed to 'pip install --no-deps'  on our slaves?  We'd end up installing
>> and using the explicit pinned requirements while the services/libraries
>> themselves remain flexible.  This might the issue Doug pointed out, where
>> requirements updates across projects are not synchronized.
>>
>>
> Switching them to requirements.txt and requirements.gate works for me. If
> a simple renaming makes things better, then great!
>
> As for Doug's comment, yes we need to work something out to overwrite
> requirements.gate, under your proposed naming, with global requirments
>
>
>> Adam
>>
>>
>>
>> On Thu, Feb 19, 2015 at 12:59 PM, Joe Gordon 
>> wrote:
>>
>>>
>>>
>>> On Wed, Feb 18, 2015 at 7:14 AM, Doug Hellmann 
>>> wrote:
>>>


 On Wed, Feb 18, 2015, at 10:07 AM, Donald Stufft wrote:
 >
 > > On Feb 18, 2015, at 10:00 AM, Doug Hellmann 
 wrote:
 > >
 > >
 > >
 > > On Tue, Feb 17, 2015, at 03:17 PM, Joe Gordon wrote:
 > >> On Tue, Feb 17, 2015 at 4:19 AM, Sean Dague 
 wrote:
 > >>
 > >>> On 02/16/2015 08:50 PM, Ian Cordasco wrote:
 >  On 2/16/15, 16:08, "Sean Dague"  wrote:
 > 
 > > On 02/16/2015 02:08 PM, Doug Hellmann wrote:
 > >>
 > >>
 > >> On Mon, Feb 16, 2015, at 01:01 PM, Ian Cordasco wrote:
 > >>> Hey everyone,
 > >>>
 > >>> The os-ansible-deployment team was working on updates to add
 support
 > >>> for
 > >>> the latest version of juno and noticed some interesting
 version
 > >>> specifiers
 > >>> introduced into global-requirements.txt in January. It
 introduced some
 > >>> version specifiers that seem a bit impossible like the one for
 > >>> requests
 > >>> [1]. There are others that equate presently to pinning the
 versions of
 > >>> the
 > >>> packages [2, 3, 4].
 > >>>
 > >>> I understand fully and support the commit because of how it
 improves
 > >>> pretty much everyone’s quality of life (no fires to put out
 in the
 > >>> middle
 > >>> of the night on the weekend). I’m also aware that a lot of the
 > >>> downstream
 > >>> redistributors tend to work from global-requirements.txt when
 > >>> determining
 > >>> what to package/support.
 > >>>
 > >>> It seems to me like there’s room to clean up some of these
 > >>> requirements
 > >>> to
 > >>> make them far more explicit and less misleading to the human
 eye (even
 > >>> though tooling like pip can easily parse/understand these).
 > >>
 > >> I think that's the idea. These requirements were generated
 > >> automatically, and fixed issues that were holding back several
 > >>> projects.
 > >> Now we can apply updates to them by hand, to either move the
 lower
 > >> bounds down (as in the case Ihar pointed out with stevedore)
 or clean
 > >>> up
 > >> the

Re: [openstack-dev] [nova] release request for python-novaclient

[melanie witt]

On Feb 19, 2015, at 13:38, Terry Wilson  wrote:

> We've currently just disabled the pylint gate tests, and I've posted a patch 
> for neutron to resolve the issue. Looks like there was a similar patch 
> already up for review as well, though it only catches one of our uses of 
> novaclient. There's still a bit of an issue that there is no version-neutral 
> way to import the 'contrib' stuff like there is for 'client'. So:
> 
> from novaclient.v1_1.contrib import server_external_events
> 
> has to become
> 
> from novaclient.v2.contrib import server_external_events
> 
> which doesn't work on previous versions of novaclient. It's possible to hack 
> around it using importutils, but it's pretty ugly.

Thanks, Terry. I'm glad you brought up the lack of version-neutral way to 
import 'contrib' modules. That's something we'll look to improve.

melanie (melwitt)






signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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] gate is fubar (again)

[melanie witt]

On Feb 19, 2015, at 17:54, Matt Riedemann  wrote:

> Regarding the novaclient change, the plan is to get either the devstack cells 
> exercise job voting on novaclient changes again (which it was at some point 
> prior to the 2.21 release and should have caught this problem), or get a 
> functional test in novaclient that hits the bash completion problem - then we 
> can revert the revert and make that work with the current code on master.

I have put up a review to reinstate the devstack cells exercise job on 
novaclient: https://review.openstack.org/#/c/157661/

And I think jogo is already working on functional tests that would cover this, 
if not the bash completion then the volume-attach functionality (technically 
the volume-attach succeeds but the call made by the bash completion cache write 
fails).

> I might have missed something but figured it'd be good to get this out so 
> people are aware that things are busted, again.

Thanks for writing this up.

melanie (melwitt)






signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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] [ovs-dev] [PATCH 8/8] [RFC] [neutron] ovn: Start work on design ocumentation.

[Ben Pfaff]

Thanks for both of those bits of information.

I've added an "allow-related" action for v3.

On Thu, Feb 19, 2015 at 06:38:46PM -0800, Kevin Benton wrote:
> Yes, if there is an action similar to the 'RELATED' and 'ESTABLISHED'
> keywords, then that should be adequate to replace the iptables solution
> that we have now.
> 
> You are correct about the reason behind the explosion of rules. In security
> groups, we allow the source/dest field to be a reference to a security
> group. That was resulting in one security group rule turning into N
> iptables rules, where N was the number of IPs in the security group. This
> was resolved using IP sets. If OVN supports the set syntax you described,
> that should achieve parity on that front as well.
> 
> 
> On Thu, Feb 19, 2015 at 2:15 PM, Kyle Mestery  wrote:
> 
> > [Adding neutron tag to subject, comments below.]
> >
> > On Thu, Feb 19, 2015 at 3:55 PM, Ben Pfaff  wrote:
> >
> >> [moving this conversation to openstack-dev because it's more
> >> interesting there and that avoids crossposting to a subscribers-only
> >> list]
> >>
> >> On Thu, Feb 19, 2015 at 10:57:02AM +0100, Miguel ??ngel Ajo wrote:
> >> >I specially liked the VIF port lifecycle, looks good to me, Ionly
> >> miss some
> >> > ???port_security??? concepts we have in neutron, which I guess could
> >> have been
> >> > deliberately omitted for a start.
> >> >
> >> >In neutron we have something called security groups, and every port
> >> > belongs to 1 or more security groups.  Each security group has a list of
> >> > rules to control traffic at port level in a very fine grained fashion
> >> (ingress/egress
> >> > protocol/flags/etc???   remote_ip/mask or security_group ID)
> >> >
> >> > I guess we could build  render security_group ID to multiple IPs for
> >> each port,
> >> > but then we will miss the ingress/egress and protocol flags (like type
> >> of protocol,
> >> > ports, etc.. [1])
> >> >
> >> > Also, be aware, that not having security group ID references from
> >> neutron,
> >> > when lot???s of ports go to the same security group we end up with an
> >> exponential
> >> > growth of rules / OF entries per port, we solved this in the
> >> server<->agent
> >> > communication for the reference OVS solution by keeping a lists of IPs
> >> > belonging to security group IDs, and then, separately having the
> >> > references from the rules.
> >>
> >> Thanks a lot for the comment.
> >>
> >> We aim to fully support security groups in OVN.  The current documents
> >> don't capture that intent.  (That's partly because we're planning to
> >> implement them in terms of some new "connection tracking" code for OVS
> >> that's still in the process of getting committed, and partly because I
> >> haven't fully thought them through yet.)
> >>
> >> My initial reaction is that we can implement security groups as
> >> another action in the ACL table that is similar to "allow" but in
> >> addition permits reciprocal inbound traffic.  Does that sound
> >> sufficient to you?
> >>
> >> Is the exponential explosion due to cross-producting, that is, because
> >> you have, say, n1 source addresses and n2 destination addresses and so
> >> you need n1*n2 flows to specify all the combinations?  We aim to solve
> >> that in OVN by giving the CMS direct support for more sophisticated
> >> matching rules, so that it can say something like:
> >>
> >> ip.src in {, , , ...} && ip.dst in {, , , ...}
> >> && (tcp.src in {80, 443, 8080} || tcp.dst in {80, 443, 8080})
> >>
> >> and let OVN implement it in OVS via the "conjunctive match" feature
> >> recently added, which is like a set membership match but more
> >> powerful.  It might still be nice to support lists of IPs (or
> >> whatever), since these lists could still recur in a number of
> >> circumstances, but my guess is that this will help a lot even without
> >> that.
> >>
> >> Thoughts?
> >>
> >> This all sounds really good to me Ben. I look forward to seeing the
> > connection tracking code land and some design details on the security
> > groups aspects of OVN published once that happens!
> >
> > Thanks,
> > Kyle
> >
> >
> >> __
> >> 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
> >
> >
> 
> 
> -- 
> Kevin Benton

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscr

Re: [openstack-dev] [cinder] qemu-img disk corruption bug to patch or not?

[Philipp Marek]

> > In September I started working on a simple (but controvertial) fix in 
> > nova[1]
> > to avoid some disk corruption issues.  John kindly ran with a similar fix 
> > to cinder[2].
> > John's review ended up in merge conflict so I tried my own version [3].
> Thanks for sending this out, and for the complete summary.  I'm
> inclined to lean towards working the option for Cinder personally.
> Granted it looks like the update is in the distro packages to fix
> this, but I'm wondering about backport and cases for installs that are
> on say 12.04?  Maybe that's not an issue?
> 
> Anybody else have thoughts on this?
Potentially corrupted images are bad; depending on the affected data it 
might only be diagnosed some time after installation, so IMO the fix is 
needed.

Only a minor issue: I'd like to see it have a check for the qemu version, 
and only then kick in.


Regards,

Phil


-- 
: Ing. Philipp Marek
: LINBIT | Your Way to High Availability
: DRBD/HA support and consulting http://www.linbit.com :

DRBD® and LINBIT® are registered trademarks of LINBIT, Austria.

__
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] qemu-img disk corruption bug to patch or not?

[Tony Breeds]

On Fri, Feb 20, 2015 at 07:27:33AM +0100, Philipp Marek wrote:

> Potentially corrupted images are bad; depending on the affected data it 
> might only be diagnosed some time after installation, so IMO the fix is 
> needed.

Sure but there is a (potentially hefty) performance impact.
 
> Only a minor issue: I'd like to see it have a check for the qemu version, 
> and only then kick in.

That dosn't work as $distro may have a qemu 2.0.x that has the fix backported.
That's why the workarounds group was created.  You specify the safe default and
if a distributor knows it's package is safe it can alter the default.

At some point you can invert that or remove the option altogether.

Yours Tony.


pgpT3f8GWB3Kv.pgp
Description: PGP 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