Re: [openstack-dev] [Keystone][Glance] Hierarchical multitenancy and Glance?

[Tripp, Travis S]

Thanks, I’ll have to read! Do you have a quick summary on what role domains are 
intended to play in this?  Has the following statement been decided?


  1.  Domains may be modified to exist as top-level projects, or they may still 
exist solely as containers for users with the project hierarchy remaining 
separate.


From: Geoff Arnold mailto:ge...@geoffarnold.com>>
Reply-To: OpenStack List 
mailto:openstack-dev@lists.openstack.org>>
Date: Tuesday, April 28, 2015 at 12:10 AM
To: OpenStack List 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [Keystone][Glance] Hierarchical multitenancy and 
Glance?

Use cases:
https://wiki.openstack.org/wiki/HierarchicalMultitenancy

Blueprints:
(Kilo):
https://blueprints.launchpad.net/keystone/+spec/hierarchical-multitenancy
https://blueprints.launchpad.net/keystone/+spec/reseller
(Liberty):
https://blueprints.launchpad.net/nova/+spec/multiple-level-user-quota-management
https://blueprints.launchpad.net/nova/+spec/nested-quota-driver-api
(Pending):
https://blueprints.launchpad.net/horizon/+spec/hierarchical-projects
https://blueprints.launchpad.net/horizon/+spec/inherited-roles

As for adoption, it’s hard to say. The HMT work in Keystone was a necessary 
starting point, but in order to create a complete solution we really need the 
corresponding changes in Nova (quotas), Glance (resource visibility), Horizon 
(UI scoping), and probably Ceilometer (aggregated queries). We (Cisco) are 
planning to kick off a Stackforge project to knit all of these things together 
into a complete “reseller” federation system. I’m assuming that there will be 
other system-level compositions of the various pieces.

Geoff

On Apr 27, 2015, at 9:48 PM, Tripp, Travis S 
mailto:travis.tr...@hp.com>> wrote:

Geoff,

Getting a spec on HMT would be helpful, as Nikhil mentioned.

As a general question, what it the current adoption of domains / vs
hierarchical projects? Is there a wiki or something that highlights what
the desired path forward is with regard to domains?

Thanks,
Travis

On 4/27/15, 7:16 PM, "Geoff Arnold" 
mailto:ge...@geoffarnold.com>> wrote:

Good points. I¹ll add some details. I¹m sure the Reseller guys will have
some comments.

Geoff

On Apr 27, 2015, at 3:32 PM, Nikhil Komawar
mailto:nikhil.koma...@rackspace.com>> wrote:

Thanks Geoff. Added some notes and questions.

-Nikhil


From: Geoff Arnold mailto:ge...@geoffarnold.com>>
Sent: Monday, April 27, 2015 5:50 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [Keystone][Glance] Hierarchical multitenancy
and   Glance?

In preparation for Vancouver, I¹ve been looking for blueprints and
design summit discussions involving the application of the Keystone
hierarchical multitenancy work to other OpenStack projects. One obvious
candidate is Glance, where, for example, we might want domain-local
resource visibility as a default. Despite my searches, I wasn¹t able to
find anything. Did I miss something obvious?

I¹ve added a paragraph to
https://etherpad.openstack.org/p/liberty-glance-summit-topics to make
sure it doesn¹t get overlooked.

Cheers,

Geoff

_
_
OpenStack Development Mailing 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 Development Mailing 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] [Keystone][Glance] Hierarchical multitenancy and Glance?

[Geoff Arnold]

Use cases:
https://wiki.openstack.org/wiki/HierarchicalMultitenancy 


Blueprints:
(Kilo):
https://blueprints.launchpad.net/keystone/+spec/hierarchical-multitenancy 

https://blueprints.launchpad.net/keystone/+spec/reseller 

(Liberty):
https://blueprints.launchpad.net/nova/+spec/multiple-level-user-quota-management
 

https://blueprints.launchpad.net/nova/+spec/nested-quota-driver-api 

(Pending):
https://blueprints.launchpad.net/horizon/+spec/hierarchical-projects 

https://blueprints.launchpad.net/horizon/+spec/inherited-roles 


As for adoption, it’s hard to say. The HMT work in Keystone was a necessary 
starting point, but in order to create a complete solution we really need the 
corresponding changes in Nova (quotas), Glance (resource visibility), Horizon 
(UI scoping), and probably Ceilometer (aggregated queries). We (Cisco) are 
planning to kick off a Stackforge project to knit all of these things together 
into a complete “reseller” federation system. I’m assuming that there will be 
other system-level compositions of the various pieces.

Geoff

> On Apr 27, 2015, at 9:48 PM, Tripp, Travis S  wrote:
> 
> Geoff,
> 
> Getting a spec on HMT would be helpful, as Nikhil mentioned.
> 
> As a general question, what it the current adoption of domains / vs
> hierarchical projects? Is there a wiki or something that highlights what
> the desired path forward is with regard to domains?
> 
> Thanks,
> Travis
> 
> On 4/27/15, 7:16 PM, "Geoff Arnold"  wrote:
> 
>> Good points. I¹ll add some details. I¹m sure the Reseller guys will have
>> some comments.
>> 
>> Geoff
>> 
>>> On Apr 27, 2015, at 3:32 PM, Nikhil Komawar
>>>  wrote:
>>> 
>>> Thanks Geoff. Added some notes and questions.
>>> 
>>> -Nikhil
>>> 
>>> 
>>> From: Geoff Arnold 
>>> Sent: Monday, April 27, 2015 5:50 PM
>>> To: OpenStack Development Mailing List (not for usage questions)
>>> Subject: [openstack-dev] [Keystone][Glance] Hierarchical multitenancy
>>> and   Glance?
>>> 
>>> In preparation for Vancouver, I¹ve been looking for blueprints and
>>> design summit discussions involving the application of the Keystone
>>> hierarchical multitenancy work to other OpenStack projects. One obvious
>>> candidate is Glance, where, for example, we might want domain-local
>>> resource visibility as a default. Despite my searches, I wasn¹t able to
>>> find anything. Did I miss something obvious?
>>> 
>>> I¹ve added a paragraph to
>>> https://etherpad.openstack.org/p/liberty-glance-summit-topics to make
>>> sure it doesn¹t get overlooked.
>>> 
>>> Cheers,
>>> 
>>> Geoff
>>> 
>>> _
>>> _
>>> OpenStack Development Mailing 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 Development Mailing 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] [Fuel] Speed Up RabbitMQ Recovering

[Zhou Zheng Sheng / 周征晟]

Hello,

I using Fuel 6.0.1 and find that RabbitMQ recover time is long after
power failure. I have a running HA environment, then I reset power of
all the machines at the same time. I observe that after reboot it
usually takes 10 minutes for RabittMQ cluster to appear running
master-slave mode in pacemaker. If I power off all the 3 controllers and
only start 2 of them, the downtime sometimes can be as long as 20 minutes.

I have a little investigation and find out there are some possible causes.

1. MySQL Recovery Takes Too Long [1] and Blocking RabbitMQ Clustering in
Pacemaker

The pacemaker resource p_mysql start timeout is set to 475s. Sometimes
MySQL-wss fails to start after power failure, and pacemaker would wait
475s before retry starting it. The problem is that pacemaker divides
resource state transitions into batches. Since RabbitMQ is master-slave
resource, I assume that starting all the slaves and promoting master are
put into two different batches. If unfortunately starting all RabbitMQ
slaves are put in the same batch as MySQL starting, even if RabbitMQ
slaves and all other resources are ready, pacemaker will not continue
but just wait for MySQL timeout.

I can re-produce this by hard powering off all the controllers and start
them again. It's more likely to trigger MySQL failure in this way. Then
I observe that if there is one cloned mysql instance not starting, the
whole pacemaker cluster gets stuck and does not emit any log. On the
host of the failed instance, I can see a mysql resource agent process
calling the sleep command. If I kill that process, the pacemaker comes
back alive and RabbitMQ master gets promoted. In fact this long timeout
is blocking every resource from state transition in pacemaker.

This maybe a known problem of pacemaker and there are some discussions
in Linux-HA mailing list [2]. It might not be fixed in the near future.
It seems in generally it's bad to have long timeout in state transition
actions (start/stop/promote/demote). There maybe another way to
implement MySQL-wss resource agent to use a short start timeout and
monitor the wss cluster state using monitor action.

I also find a fix to improve MySQL start timeout [3]. It shortens the
timeout to 300s. At the time I sending this email, I can not find it in
stable/6.0 branch. Maybe the maintainer needs to cherry-pick it to
stable/6.0 ?

[1] https://bugs.launchpad.net/fuel/+bug/1441885
[2] http://lists.linux-ha.org/pipermail/linux-ha/2014-March/047989.html
[3] https://review.openstack.org/#/c/171333/


2. RabbitMQ Resource Agent Breaks Existing Cluster

Read the code of the RabbitMQ resource agent, I find it does the
following to start RabbitMQ master-slave cluster.
On all the controllers:
(1) Start Erlang beam process
(2) Start RabbitMQ App (If failed, reset mnesia DB and cluster state)
(3) Stop RabbitMQ App but do not stop the beam process

Then in pacemaker, all the RabbitMQ instances are in slave state. After
pacemaker determines the master, it does the following.
On the to-be-master host:
(4) Start RabbitMQ App (If failed, reset mnesia DB and cluster state)
On the slaves hosts:
(5) Start RabbitMQ App (If failed, reset mnesia DB and cluster state)
(6) Join RabbitMQ cluster of the master host

As far as I can understand, this process is to make sure the master
determined by pacemaker is the same as the master determined in RabbitMQ
cluster. If there is no existing cluster, it's fine. If it is run after
power failure and recovery, it introduces the a new problem.

After power recovery, if some of the RabbitMQ instances reach step (2)
roughly at the same time (within 30s which is hard coded in RabbitMQ) as
the original RabbitMQ master instance, they form the original cluster
again and then shutdown. The other instances would have to wait for 30s
before it reports failure waiting for tables, and be  reset to a
standalone cluster.

In RabbitMQ documentation [4], it is also mentioned that if we shutdown
RabbitMQ master, a new master is elected from the rest of slaves. If we
continue to shutdown nodes in step (3), we reach a point that the last
node is the RabbitMQ master, and pacemaker is not aware of it. I can see
there is code to bookkeeping a "rabbit-start-time" attribute in
pacemaker to record the most long lived instance to help pacemaker
determine the master, but it does not cover the case mentioned above. A
recent patch [5] checks existing "rabbit-master" attribute but it
neither cover the above case.

So in step (4), pacemaker determines a different master which was a
RabbitMQ slave last time. It would wait for its original RabbitMQ master
for 30s and fail, then it gets reset to a standalone cluster. Here we
get some different clusters, so in step (5) and (6), it is likely to
report error in log saying timeout waiting for tables or fail to merge
mnesia database schema, then the those instances get reset. You can
easily re-produce the case by hard resetting power of all the controllers.

As you can see, if you

Re: [openstack-dev] [glance] Call to action, revisit CIS state

[Tripp, Travis S]

>On 4/27/15, 05:39, "Kuvaja, Erno"  wrote:
>
>>The spec bluntly states that
>>there is no security impact from the implementation
>> and the concerns should have been brought up so reviewers would have had
>>better chance to catch possible threats.
>>
>> 
>>I would like you to look back into those two specs and the comments, look
>>back into the implementation and raise any urgent concerns and please
>>lets try to have good and healthy base for discussion in the Vancouver
>>Summit how we will continue
>> forward from this!
>> 
>>


Any thoughts on improving security are always welcome.  As you¹ll find in
the original service spec, in the comments on it, and in the code,
security was one of the number one topics with the CIS service. Getting
input on this was a driving reason to initially target a single OpenStack
service (Glance). Security was also discussed in all three of the summit
discussions leading to the creation of this service (pre-Kilo virtual
summit, Kilo summit, Kilo mini-summit). Without security, this becomes an
admin only service of limited interest and could be done completely
outside of OpenStack as a native, possibly proprietary plugin to Elastic
Search itself. In that scenario, it also would not have any input from the
community and would not provide benefit to the broader community.

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


On 4/27/15, 10:52 AM, "Ian Cordasco"  wrote:



>
>There¹s a slight problem with this though. We load the plugins dynamically
>https://github.com/openstack/glance/blob/582f8563e866f167ae1de1a2309c1a1e2
>4
>84442a/glance/common/utils.py#L735 (as anyone really would expect us to)
>which means new plugins can be created for any service that is willing to
>create one and install it properly. With that done, we /could/ have CIS
>become a centralized Elasticsearch API in OpenStack as managed by Glance.
>
>The solution that seems obvious for this is to disallow plugins to declare
>their index name (using PluginClass.get_index_name) but I don¹t think that
>warrants an RC3 or will necessarily make it into 2015.1.1.


Thank you Ian for your continued thoughtful reviews. As Kamil pointed out,
the index name also is a point of customization for deployers that might
be using their elastic search cluster for multiple indexes.  If they want
to change the index for any reason such as avoiding collisions, this
allows that flexibility.


>If CIS is going to become a fully supported (or non-experimental) Glance
>API in Liberty, I think we should really make sure that it is a service
>that can only create documents for Glance. Since the API is Experimental,
>I think it¹s safe to say the API for the Plugins will be considered
>experimental and so removing get_index_name from plugin classes will not
>break the world.


I have a summit session proposed on discussing the catalog index service
at the summit and I specifically want to cover the scope and logistics of
it moving forward. This includes discussing whether or not it should be
proposed as its own project or if it might make sense for it to move to
its own repo as part of the glance project for technical and logistical
concerns. I¹ve started populating the linked discussion etherpad for that
session proposal with a few thoughts. There appears to be another highly
related session from Stuart, Flavio, and Brian that should be logically
arranged so that the timing / coordination between the two sessions makes
sense.


__
OpenStack Development Mailing 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][Glance] Hierarchical multitenancy and Glance?

[Tripp, Travis S]

Geoff,

Getting a spec on HMT would be helpful, as Nikhil mentioned.

As a general question, what it the current adoption of domains / vs
hierarchical projects? Is there a wiki or something that highlights what
the desired path forward is with regard to domains?

Thanks,
Travis

On 4/27/15, 7:16 PM, "Geoff Arnold"  wrote:

>Good points. I¹ll add some details. I¹m sure the Reseller guys will have
>some comments.
>
>Geoff
>
>> On Apr 27, 2015, at 3:32 PM, Nikhil Komawar
>> wrote:
>> 
>> Thanks Geoff. Added some notes and questions.
>> 
>> -Nikhil
>> 
>> 
>> From: Geoff Arnold 
>> Sent: Monday, April 27, 2015 5:50 PM
>> To: OpenStack Development Mailing List (not for usage questions)
>> Subject: [openstack-dev] [Keystone][Glance] Hierarchical multitenancy
>>and   Glance?
>> 
>> In preparation for Vancouver, I¹ve been looking for blueprints and
>>design summit discussions involving the application of the Keystone
>>hierarchical multitenancy work to other OpenStack projects. One obvious
>>candidate is Glance, where, for example, we might want domain-local
>>resource visibility as a default. Despite my searches, I wasn¹t able to
>>find anything. Did I miss something obvious?
>> 
>> I¹ve added a paragraph to
>>https://etherpad.openstack.org/p/liberty-glance-summit-topics to make
>>sure it doesn¹t get overlooked.
>> 
>> Cheers,
>> 
>> Geoff
>> 
>>_
>>_
>> OpenStack Development Mailing 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 Development Mailing 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] Required data migrations in Kilo, need Turbo Hipster tests updated

[Joshua Hesketh]

On 4/23/15 11:41 PM, Dan Smith wrote:

That change works on the dataset. However I was referring to the
db/object api (which I have no real knowledge of) that it should be able
to get_by_uuid unmigrated instances and in my case I got the traceback
given in that paste. It's possible I'm just using the API incorrectly.

You should be able to pull migrated or unmigrated instances, yes. The
tests for the flavor stuff do this (successfully) at length. The
traceback you have seems like a half-migrated instance, where there is a
non-null flavor column on the instance_extra record, which shouldn't be
possible. The line numbers also don't match master, so I'm not sure
exactly what you're running.

If you can track down where in your dataset that is hitting and maybe
figure out what is going on, we can surely address it, but the current
tests cover all the cases I can think of at the moment.

Any chance you're tripping over something that was a casualty of
previous failures here?
I suspect I did manage to create an instance in between the two states 
when trying to set up my tests. Your fix works fine now, thanks.





Oh yes, we want that restriction, but a way around it for instances that
may be stuck or just testing purposes could be useful.

Yeah, as long as we're clear about the potential for problems if they
run --force on a moving target...


Yep. If this could get reviewed+merged that'd be great. I need this for 
turbo-hipster to sanely step through the migrate part.


Cheers,
Josh



--Dan

__
OpenStack Development Mailing 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] install custom middleware via devstack

[AliReza Taleghani]

Hi
I'm working on a custom middleware which will place on swift-proxy
pipeline, just before the latest proxy-logging.

how can I force devstack to install my middleware just as I run ./stack.sh?
#The point is that I'm looking for a mature and standard to do it, so I'm
not going to just edit the stack.sh and Embed some scripts to manually
handle the case! but as I mentioned I would like the learn the best case...



Sincerely,
Ali R. Taleghani
@linkedIn 
__
OpenStack Development Mailing 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] [Nova] [Cinder] [tc] Should Openstack project maintained by core team keep only API/DB in the future?

[loy wolfe]

On Fri, Apr 24, 2015 at 9:13 PM, Kyle Mestery  wrote:
> On Fri, Apr 24, 2015 at 4:06 AM, loy wolfe  wrote:
>>
>> It's already away from the original thread, so I start this new one,
>> also with some extra tag because I think it touch some corss-project
>> area.
>>
>> Original discuss and reference:
>> http://lists.openstack.org/pipermail/openstack-dev/2015-April/062384.html
>>
>> https://review.openstack.org/#/c/176501/1/specs/liberty/reference-split.rst
>>
>> Background summary:
>> All in-tree implementation would be splitted from Openstack
>> networking, leaving Neutron as a naked "API/DB" platform, with a list
>> of out-tree implementation git repos, which are not maintained by core
>> team any more, but may be given a nominal "big tent" under the
>> Openstack umbrella.
>>
>
> I'm not sure what led you to this discussion, but it's patently incorrect.
> We're going to split the in-tree reference implementation into a separate
> git repository. I have not said anything about the current core revewier
> team not being responsible for that. It's natural to evolve to a core
> reviewer team which cares deeply about that, vs. those who care deeply about
> the DB/API layer. This is exactly what happened when we split out the
> advanced services.

Thanks for the simple explanation Kyle.

But today Neutron is already composed with many separate sub-teams:
ML2, L3, VPN/LBaas/Fw, etc, while each sub-team is responsible for
their own API/DB definition along with their implementations. So
what's the goal of the upcoming split: other standalone L2/L3-Core
API/DB teams, together with existing ML2 and L3 plugin/agent
implementation teams? Should we also split advanced service team with
API/DB and implementation team, and do they also need equal footing on
external 3rd SDN controllers?

It's not important whether a project team is nominally one of
openstack, under the big tent/stadium of Neutron as discussed in the
weekly meeting. Positioning is the key: Are existing built-in
ML2+OVS/LB SDN solution only used for concept proving in the future,
or continuously ensured as the native delivery ready for production
deployment? If a dedicated API/DB team has to co-ordinate so many
external 3rd SDN controllers besides the native built-in SDN, how can
it evolve with rapid feature growing?

Best Regards.

>
>>
>> Motivation: a) Smaller core team only focus on the in-tree API/DB
>> definition, released from concrete controlling function
>> implementation; b) If there is official implementation inside Neutron,
>> 3rd external SDN controller would face the competition.
>>
>> I'm not sure whether it's exactly what cloud operators want the
>> Openstack to deliver. Do they want a off-the-shelf package, or just a
>> framework and have to take the responsibility of integrating with
>> other external controlling projects? A analogy with Linux that only
>> kernel without any device driver has no use at all.
>>
>
> We're still going to deliver ML2+OVS/LB+[DHCP, L3, metadata] agents for
> Liberty. I'm not sure where your incorrect assumption on what we're going to
> deliver is coming from.
>
>>
>> There are already many debates about nova-network to Neutron parity.
>> If largely used OVS and LB driver is out of tree and has to be
>> integrated separately by customers, how do those they migrate from
>> nova network? Standalone SDN controller has steep learning curve, and
>> a lot of users don't care which one is better of ODL vs. OpenContrail
>> to be integrated, they just want Openstack package easy to go by
>> default in tree implementation,  and are ready to drive all kinds of
>> opensource or commercial backends.
>>
>
> Do you realize that ML2 is plus the L2 agent is an SDN controller already?
>
>>
>> BTW: +1 to henry and mathieu, that indeed Openstack is not responsible
>> projects of switch/router/fw, but it should be responsible for
>> scheduling, pooling, and driving of those backends, which is the same
>> case with Nova/Cinder scheduler and compute/volume manager. These
>> controlling functions shouldn't be classified as backends in Neutron
>> and be splitted out of tree.
>
>
>>
>> Regards
>>
>>
>> On Fri, Apr 24, 2015 at 2:37 AM, Kyle Mestery  wrote:
>> >
>> >
>> > On Thu, Apr 23, 2015 at 1:31 PM, Fox, Kevin M 
>> > wrote:
>> >>
>> >> Yeah. In the end, its what git repo the source for a given rpm you
>> >> install
>> >> comes from. Ops will not care that neutron-openvswitch-agent comes from
>> >> repo
>> >> foo.git instead of bar.git.
>> >>
>> >
>> >
>> > That's really the tl;dr of the proposed split.
>> >
>> > Thanks,
>> > Kyle
>> >
>> >>
>> >> Thanks,
>> >> Kevin
>> >> 
>> >> From: Armando M. [arma...@gmail.com]
>> >> Sent: Thursday, April 23, 2015 9:10 AM
>> >> To: OpenStack Development Mailing List (not for usage questions)
>> >> Subject: Re: [openstack-dev] [Neutron] A big tent home for Neutron
>> >> backend
>> >> code
>> >>
>> 
>> >>> I agree with henry here.
>> >>> Armando, If we use your 

[openstack-dev] [puppet] creating a rubygems mirror for OpenStack

[Emilien Macchi]

Hi,

All Puppet OpenStack jobs (lint, syntax, unit and beaker) are quite
often affected by rubygems.org downtimes and make all jobs failing
randomly because it can't download some gems during the bootstrap.
This is something that really affect our CI and we would really
appreciate openstack-infra's help!

It came up on IRC we could use the existing Pypi mirror nodes to add
rubygems and have rubygems.openstack.org or something like this).

I created a story here: https://storyboard.openstack.org/#!/story/2000247

And a patch here in system-config with all Puppet code:
https://review.openstack.org/#/c/178026/

Thank you for your time,
-- 
Emilien Macchi



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

Re: [openstack-dev] TC Candidacy

[Qiao, Liyong]

+1

BR, Eli(Li Yong)Qiao

From: David Lyle [mailto:dkly...@gmail.com]
Sent: Thursday, April 23, 2015 8:57 AM
To: OpenStack Development Mailing List
Subject: [openstack-dev] TC Candidacy

I'm announcing my candidacy for the Technical Committee elections.

I have been contributing to OpenStack since Grizzly primarily in Horizon. I 
have also had the privilege to serve as Horizon PTL since Icehouse.

Why I'm running:

I believe there should be broader representation on the TC. We are growing the 
OpenStack ecosystem. Let's make sure horizontal teams and diverse parts of the 
ecosystem are represented more directly. I understand concerns of scaling were 
the reason for moving from the TC made up of all PTLs (I question that 
assertion), but the sacrifice so far has been diversity. I feel current TC 
members are exceptionally capable and take a broad viewpoint, but there are 
limits of how well that works. Let's represent broader swaths of our ecosystem 
in the technical leadership.

I think growing the OpenStack ecosystem is fantastic. As a developer and the 
PTL of a project that tries to span across most of that ecosystem it also 
worries me a bit too. I think we need to focus on how the newer and older parts 
of our ecosystem work together. How do we manage all the horizontal needs this 
introduces without going to the extremes of just scaling existing horizontal 
efforts because that won't work. And pushing all horizontal work on the 
individual projects is not appropriate because that yields chaos.

Finally, I believe the TC needs to be more active in guiding overall direction 
of OpenStack and problem resolution. I'm not suggesting a dictatorship of 
course. But let's set a direction, overall release goals for OpenStack and help 
enable and drive them.

I'm really proud to be a part of the OpenStack developer community, but I think 
we're facing some real challenges. We need to address some primary issues or 
this community will struggle to remain the vibrant, supportive place it is now.

Thank you,
David

__
OpenStack Development Mailing 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] Why do we need to select subnet when creating a pool?

[Brandon Logan]

I'm assuming you are using LBaaS V2.  With that assumption, I'm not sure how 
you are having to select subnet on the pool.  It's not supposed to be a field 
at all on the pool object.  subnet_id is required on the member object right 
now, but that's something I and others think should just be optional, and if 
not specified then it's assumed that member can be reached with whatever has 
already been setup.?  Another option is pool could get a subnet_id field in the 
future and all members that are created without subnet_id are assumed to be on 
the pool's subnet_id, but I'm getting ahead of myself and this has no bearing 
on your current issue.


Could you tell me how you are making your requests? CLI? REST directly?


From: Wanjing Xu 
Sent: Monday, April 27, 2015 12:57 PM
To: OpenStack Development Mailing List not for usage questions
Subject: [openstack-dev] [Neutron][LBaaS] Why do we need to select subnet when 
creating a pool?

So when I use Haproxy for LBaaS for Juno, there is a subnet mandatary field 
that I need to fill in when creating a pool, and later on when I add members, I 
can use a different subnet(or simply just enter the ip of the member), when 
adding vip, I can still select a third subnet.  So what is the usage of the 
first subnet that I used to create pool?  There is no port created for this 
pool subnet.  I can see that a port is created for the vip subnet that the 
loadbalancer instance is binding to.

Regards!

Wanjing Xu
__
OpenStack Development Mailing 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] Bump the RPC version required for port_update - AgentNotifierApi

[Armando M.]

On 27 April 2015 at 18:16, YAMAMOTO Takashi  wrote:

> > On 27 April 2015 at 09:09, Rossella Sblendido 
> wrote:
> >
> >> Hello all,
> >>
> >> I am working at the blueprint "Restructure the L2 agent" [1] .
> >> One of the work item of this blueprint is to modify the port_update
> >> message to include the attributes of the ports that were modified. This
> >> is implemented in this patch [2] .
> >>
> >> The client side of the RPC is in AgentNotifierApi , the server side is
> >> implemented in the L2 agent. A problem arises since now the vendor
> >> plugins are out of the tree. If they use a custom L2 agent (like for
> >> example the Ryu plugin) when the patch is merged they will get an
>
> fwiw, it's ofagent, not ryu plugin.
>
> >> UnsupportedVersion error if the version is not bumped in their agent
> too.
> >>
> >
> > Could the server fall back and keep on using the old version of the API?
> I
> > think that would make for a much nicer experience, especially in face of
> > upgrades. Is this not possible? If it is, then the in vs out matter is
> not
> > really an issue and out-of-tree code can reflect the change in API at
> their
> > own pace.
>
> while it's indeed nicer, it's difficult as port_update is
> an async call (cast) and does not wait for errors
> including UnsupportedVersion.
>

Then, let's figure out how to change it!


>
> YAMAMOTO Takashi
>
> >
> > Cheers,
> > Armando
> >
> >
> >>
> >> I am writing this email as heads up and also to ask a question. The
> >> port_update signature on the server side is like this:
> >>
> >> def port_update(self, context, **kwargs)
> >>
> >> kwargs is used, no specific parameter is specified. If a new key is
> >> added like in this case, the minor version of the RPC should be bumped
> >> anyway? I think so.
> >>
> >> cheers,
> >>
> >> Rossella
> >>
> >> [1] https://blueprints.launchpad.net/neutron/+spec/restructure-l2-agent
> >> [2] https://review.openstack.org/#/c/155223
> >>
> >>
> __
> >> OpenStack Development Mailing List (not for usage questions)
> >> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] Question for the TC candidates

[Armando M.]

On 23 April 2015 at 09:14, Chris Dent  wrote:

>
> This might be a bit presumptuous, but why not give it a try...
>
> This cycle's TC elections didn't come with a set of prepackaged
> questions and though the self-nomination messages have included some
> very interesting stuff I think it would be useful to get answers
> from the candidates on at least one topical but open-ended
> question. Maybe other people have additional questions they think
> are important but this one is the one that matters to me and also
> captures the role that I wish the TC filled more strongly. Here's
> the preamble:
>
> There are lots of different ways to categorize the various
> stakeholders in the OpenStack community, no list is complete. For
> the sake of this question the people I'm concerned with are the
> developers, end-users and operators of OpenStack: the individuals
> who are actively involved with it on a daily basis. I'm intentionally
> leaving out things like "the downstream".
>
> There are many different ways to define "quality". For the sake of
> this question feel free to use whatever definition you like but take
> it as given that "quality" needs to be improved.
>
> Here's the question:
>
> What can and should the TC at large, and you specifically, do to ensure
> quality improves for the developers, end-users and operators of
> OpenStack as a full system, both as a project being developed and a
> product being used?


I am possibly the latest candidate to respond to this thread...what a lousy
candidate that I am! :)

Without incurring the risk of becoming incredibly verbose, and trying to
keep this discussion down to earth, one thing I would like to see happen is
addressing the sort of quality that can be qualitatively measured on an
ongoing basis. For instance, to date we cannot tell at any given time (and
without support of downstream tools) whether certain key operations (like
VM boot) have degraded because of a specific change (if there is, as a
developer I'd be keen to learn how to take advantage of it, but that's
another discussion)!

For instance, when I was at VMware and in charge of 3rd party CI, I
designed a small mechanism to track the mobile average of test run times
that would tell a developer the impact of his/her change to the overall
performance of the system (single devstack). For instance, in change [1],
the VMware CI reported back 94.32% faster than the average run time. That
clearly meant that the change had no negative impact to the operations that
involved the VMware plugin for Neutron. Had that number been 150%, that
would have alerted a reviewer and triggered further analysis.

That number is obviously a coarse grained way of capturing quality, and may
have its own flaws but I found it incredibly useful and I would like to see
something along those lines be implemented in Zuul.

Anyhow, I hope you get the gist, should you want to know more, I guess
you'd have to vote for me :P

Cheers,
Armando

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


>
>
> --
> Chris Dent tw:@anticdent freenode:cdent
> https://tank.peermore.com/tanks/cdent
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Bump the RPC version required for port_update - AgentNotifierApi

[YAMAMOTO Takashi]

> On 27 April 2015 at 09:09, Rossella Sblendido  wrote:
> 
>> Hello all,
>>
>> I am working at the blueprint "Restructure the L2 agent" [1] .
>> One of the work item of this blueprint is to modify the port_update
>> message to include the attributes of the ports that were modified. This
>> is implemented in this patch [2] .
>>
>> The client side of the RPC is in AgentNotifierApi , the server side is
>> implemented in the L2 agent. A problem arises since now the vendor
>> plugins are out of the tree. If they use a custom L2 agent (like for
>> example the Ryu plugin) when the patch is merged they will get an

fwiw, it's ofagent, not ryu plugin.

>> UnsupportedVersion error if the version is not bumped in their agent too.
>>
> 
> Could the server fall back and keep on using the old version of the API? I
> think that would make for a much nicer experience, especially in face of
> upgrades. Is this not possible? If it is, then the in vs out matter is not
> really an issue and out-of-tree code can reflect the change in API at their
> own pace.

while it's indeed nicer, it's difficult as port_update is
an async call (cast) and does not wait for errors
including UnsupportedVersion.

YAMAMOTO Takashi

> 
> Cheers,
> Armando
> 
> 
>>
>> I am writing this email as heads up and also to ask a question. The
>> port_update signature on the server side is like this:
>>
>> def port_update(self, context, **kwargs)
>>
>> kwargs is used, no specific parameter is specified. If a new key is
>> added like in this case, the minor version of the RPC should be bumped
>> anyway? I think so.
>>
>> cheers,
>>
>> Rossella
>>
>> [1] https://blueprints.launchpad.net/neutron/+spec/restructure-l2-agent
>> [2] https://review.openstack.org/#/c/155223
>>
>> __
>> OpenStack Development Mailing 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] [Keystone][Glance] Hierarchical multitenancy and Glance?

[Geoff Arnold]

Good points. I’ll add some details. I’m sure the Reseller guys will have some 
comments.

Geoff

> On Apr 27, 2015, at 3:32 PM, Nikhil Komawar  
> wrote:
> 
> Thanks Geoff. Added some notes and questions.
> 
> -Nikhil
> 
> 
> From: Geoff Arnold 
> Sent: Monday, April 27, 2015 5:50 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: [openstack-dev] [Keystone][Glance] Hierarchical multitenancy and 
>   Glance?
> 
> In preparation for Vancouver, I’ve been looking for blueprints and design 
> summit discussions involving the application of the Keystone hierarchical 
> multitenancy work to other OpenStack projects. One obvious candidate is 
> Glance, where, for example, we might want domain-local resource visibility as 
> a default. Despite my searches, I wasn’t able to find anything. Did I miss 
> something obvious?
> 
> I’ve added a paragraph to 
> https://etherpad.openstack.org/p/liberty-glance-summit-topics to make sure it 
> doesn’t get overlooked.
> 
> Cheers,
> 
> Geoff
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

Re: [openstack-dev] [Neutron] Bump the RPC version required for port_update - AgentNotifierApi

[Armando M.]

On 27 April 2015 at 09:09, Rossella Sblendido  wrote:

> Hello all,
>
> I am working at the blueprint "Restructure the L2 agent" [1] .
> One of the work item of this blueprint is to modify the port_update
> message to include the attributes of the ports that were modified. This
> is implemented in this patch [2] .
>
> The client side of the RPC is in AgentNotifierApi , the server side is
> implemented in the L2 agent. A problem arises since now the vendor
> plugins are out of the tree. If they use a custom L2 agent (like for
> example the Ryu plugin) when the patch is merged they will get an
> UnsupportedVersion error if the version is not bumped in their agent too.
>

Could the server fall back and keep on using the old version of the API? I
think that would make for a much nicer experience, especially in face of
upgrades. Is this not possible? If it is, then the in vs out matter is not
really an issue and out-of-tree code can reflect the change in API at their
own pace.

Cheers,
Armando


>
> I am writing this email as heads up and also to ask a question. The
> port_update signature on the server side is like this:
>
> def port_update(self, context, **kwargs)
>
> kwargs is used, no specific parameter is specified. If a new key is
> added like in this case, the minor version of the RPC should be bumped
> anyway? I think so.
>
> cheers,
>
> Rossella
>
> [1] https://blueprints.launchpad.net/neutron/+spec/restructure-l2-agent
> [2] https://review.openstack.org/#/c/155223
>
> __
> OpenStack Development Mailing 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] A big tent home for Neutron backend code

[Armando M.]

>
>
> Any project that fails to meet the criteria later can be dropped at any
> time.  For example, if some repo is clearly unmaintained, it can be
> removed.
>

If we open the door to excluding projects down the road, then wouldn't we
need to take into account some form of 3rd party CI validation as part of
the criteria to 'ensure quality' (or lack thereof)? Would you consider that
part of the inclusion criteria too?


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

[openstack-dev] [openstack][nova] Does anyone use Zookeeper, Memcache Nova ServiceGroup Driver ?

[Vilobh Meshram]

Hi,

Does anyone use Zookeeper[1], Memcache[2] Nova ServiceGroup Driver ?

If yes how has been your experience with it. It was noticed that most of
the deployment try to use the default Database driver[3]. Any experiences
with Zookeeper, Memcache driver will be helpful.

-Vilobh

[1]
https://github.com/openstack/nova/blob/master/nova/servicegroup/drivers/zk.py
[2]
https://github.com/openstack/nova/blob/master/nova/servicegroup/drivers/mc.py
[3]
https://github.com/openstack/nova/blob/master/nova/servicegroup/drivers/db.py
__
OpenStack Development Mailing 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] Navigating the ever changing OpenStack codebase

[Jeremy Stanley]

On 2015-04-27 17:38:25 -0500 (-0500), Kevin L. Mitchell wrote:
> Unfortunately, there's one problem with that: you can't tell tox to use
> a virtualenv that you've built.  We need this capability at present, so
> we have to run tests using run_tests.sh instead of tox :(  I have an
> issue open on tox to address this need, but haven't seen any movement on
> that; so until then, I have to oppose the removal of run_tests.sh…
> despite how much *I'd* like to see it bite the dust!

Bug report is https://bitbucket.org/hpk42/tox/issue/153 for those
following along. I agree that's unfortunate, though a (likely
suboptimal) workaround is to have tox create the virtualenv, then do
whatever you need to modify it, then don't have tox recreate it on a
subsequent run of your tests.
-- 
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] Navigating the ever changing OpenStack codebase

[Clint Byrum]

Excerpts from Kevin L. Mitchell's message of 2015-04-27 15:38:25 -0700:
> On Mon, 2015-04-27 at 21:42 +, Jeremy Stanley wrote:
> > I consider it an unfortunate oversight that those files weren't
> > deleted a very, very long time ago.
> 
> Unfortunately, there's one problem with that: you can't tell tox to use
> a virtualenv that you've built.  We need this capability at present, so
> we have to run tests using run_tests.sh instead of tox :(  I have an
> issue open on tox to address this need, but haven't seen any movement on
> that; so until then, I have to oppose the removal of run_tests.sh…
> despite how much *I'd* like to see it bite the dust!

Err.. you can just run the commands in tox.ini in the venv of your
choice. You don't need run_tests.sh for that.

__
OpenStack Development Mailing 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] [Zaqar] Call for adoption (or exclusion?)

[Clint Byrum]

Excerpts from Joe Gordon's message of 2015-04-27 10:36:57 -0700:
> On Fri, Apr 24, 2015 at 5:05 PM, Zane Bitter  wrote:
> 
> > On 24/04/15 19:02, Joe Gordon wrote:
> >
> >>
> >>
> >> On Mon, Apr 20, 2015 at 5:54 AM, Flavio Percoco  >> > wrote:
> >>
> >> Greetings,
> >>
> >> I'd like my first action as Zaqar's PTL to be based on reflections and
> >> transparency with regards to what our past has been, to what our
> >> present is and to what our future could be as a project and community.
> >> Therefore, I'm sending this call for adoption and support before
> >> taking other actions (also mentioned below).
> >>
> >> The summit is very close and the Zaqar team is looking forward to it.
> >>
> >> The upcoming summit represents an important opportunity for Zaqar to
> >> integrate with other projects. In the previous summits - since
> >>
> >>
> >> I get integration with Horizon etc. But to use the SQS/SNS analogy how
> >> would say Nova integrate with Zaqar?
> >>
> >
> > Speaking very generally, anything where it makes sense for Nova to tell
> > the user - or, more importantly, the application - when something is
> > happening. The cloud can't afford to be making synchronous calls to the
> > client-side, and applications may not be able to afford missing the
> > notifications, so a reliable, asynchronous transport like Zaqar is a good
> > candidate.
> >
> > So examples might be:
> >  - Hey, your resize is done
> >  - Hey, your [re]build is done
> >  - Hey, your VM rebooted
> >  - Hey, your VM disappeared
> >
> > Now, this is not to presuppose that having Nova put messages directly into
> > Zaqar is the correct design. It may be that it's better to have some other
> > service (Ceilometer?) collect some or all of those notifications and handle
> > putting them into Zaqar (though the reliability would be a concern).
> > Certainly EC2 seems to funnel all this stuff to CloudWatch, although other
> > services like S3, CloudFormation & Auto Scaling deliver notifications to
> > SNS directly. There is some integration work either way though, to produce
> > the notification.
> >
> > Obviously there's less integration to do for a project like Nova that only
> > produces notifications than there would be for those that could actually
> > consume notifications. Heat would certainly like to use these notifications
> > to reduce the amount of polling we do of the APIs (and ditch it altogether
> > if reliability is guaranteed). But if we can get both ends integrated then
> > the *user* can start doing really interesting things like:
> >
> 
> This is one of the bigger questions for me, as a nova developer. What would
> integration look like from Nova's POV.  I am a little weary of adding yet
> another API when we have so much trouble with our existing ones.
> Especially the notification based API.
> 

It seems to me like there's no need for Nova to do anything except keep
sending notifications. The service that is needed is the one that
exposes appropriate notifications to end-users, and it would have an API
which would work something like


POST /subscriptions
Auth-Things: go-here

{ "topic": "compute",
  "subject": [{"id": "12346566789"}],
  "destination": {"driver": "zaqar", "args": {"queue-id": "id-of-zaqar-inbox"}} 
}

Domain/Tenant is implied from auth details, and off to the races,
a filter is added and some notification-bus-aware workers receive the
fanout of notifications, passing applicable messages into the configured
driver. Drivers could be zaqar, or logstash, or SMTP inboxes, or whatever.
Point being, Nova wouldn't care, as long as its notifications can be
transformed into the output of a driver that the cloud operator has made
available. This would solve Heat's use case, and would probably be useful
for infra's nodepool if it were on the clouds we use since we could wait
for messages instead of polling the server list.

I've heard tell this might be something that could be built on top of,
or split out from, ceilometer, since it already sort of has to do this
to facilitate billing. Anyway, bottom line, if there aren't any users
willing to put resources into building it, then this has probably just
been a fun exercise in crystal ball gazing for now.

__
OpenStack Development Mailing 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] [api] Missing meetings this week

[Everett Toews]

Hi All,

I’ll be out the next few days and will be missing our meetings. Specifically 
the cross-project meeting [1] and our API WG meeting [2].

On the plus side I got to my action items from the last meeting and “froze” the 
3 guidelines up for review and proposed a cross-project session [3] (row 22). I 
also booked some time for us in the working group sessions at the summit.

Thanks,
Everett

[1] https://wiki.openstack.org/wiki/Meetings/CrossProjectMeeting
[2] https://wiki.openstack.org/wiki/Meetings/API-WG
[3] 
https://docs.google.com/spreadsheets/d/1vCTZBJKCMZ2xBhglnuK3ciKo3E8UMFo5S5lmIAYMCSE/edit#gid=827503418


__
OpenStack Development Mailing 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] [heat] Stack/Resource updated_at conventions

[Zane Bitter]

On 27/04/15 13:38, Steven Hardy wrote:

On Mon, Apr 27, 2015 at 04:46:20PM +0100, Steven Hardy wrote:

AFAICT there's two options:

1. Update the stack.Stack so we store "now" at every transition (e.g in
state_set)

2. Stop trying to explicitly control updated_at, and just allow the oslo
TimestampMixin to do it's job and update updated_at every time the DB model
is updated.


Ok, at the risk of answering my own question, there's a third option, which
is to output an event for all stack transitions, not only resource
transitions.  This appears to be the way the CFN event API works AFAICS.


My recollection was that in CFN events were always about a particular 
resource. That may have been wrong, or they may have changed it. In any 
event (uh, no pun intended), I think this option is preferable to 
options 1 & 2.


When we first implemented this stuff we only operated on one resource at 
a time, there was no way to cancel an update, &c. It was a simpler world ;)



I guess the event would have a dummy OS::Heat::Stack type and then you


That's too hacky IMHO, I think we should have a more solid way of 
distinguishing resource events from stack events. OS::Heat::Stack is a 
type of resource already, after all. Arguably they should come from 
separate endpoints, to avoid breaking clients until we get to a v2 API.



could find the most recent transition to e.g UPDATE_IN_PROGRESS in the
events and use that as a marker so you only list results after that event?


Even that is not valid in a distributed system. For convergence we're 
planning to have a UUID associated with each update. We should reuse 
that to connect events with particular update traversals.


cheers,
Zane.

__
OpenStack Development Mailing 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] Navigating the ever changing OpenStack codebase

[Kevin L. Mitchell]

On Mon, 2015-04-27 at 21:42 +, Jeremy Stanley wrote:
> I consider it an unfortunate oversight that those files weren't
> deleted a very, very long time ago.

Unfortunately, there's one problem with that: you can't tell tox to use
a virtualenv that you've built.  We need this capability at present, so
we have to run tests using run_tests.sh instead of tox :(  I have an
issue open on tox to address this need, but haven't seen any movement on
that; so until then, I have to oppose the removal of run_tests.sh…
despite how much *I'd* like to see it bite the dust!
-- 
Kevin L. Mitchell 
Rackspace


__
OpenStack Development Mailing 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-scheduler] Scheduler sub-group (gantt) meeting agenda 4/28

[Dugger, Donald D]

Meeting on #openstack-meeting at 1500 UTC (9:00AM MDT)

1) Liberty specs (tracking page - https://wiki.openstack.org/wiki/Gantt/liberty 
)
2) Vancouver design summit - more thoughts?
3) Opens


--
Don Dugger
"Censeo Toto nos in Kansa esse decisse." - D. Gale
Ph: 303/443-3786


__
OpenStack Development Mailing 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][Glance] Hierarchical multitenancy and Glance?

[Nikhil Komawar]

Thanks Geoff. Added some notes and questions.

-Nikhil


From: Geoff Arnold 
Sent: Monday, April 27, 2015 5:50 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [Keystone][Glance] Hierarchical multitenancy and   
Glance?

In preparation for Vancouver, I’ve been looking for blueprints and design 
summit discussions involving the application of the Keystone hierarchical 
multitenancy work to other OpenStack projects. One obvious candidate is Glance, 
where, for example, we might want domain-local resource visibility as a 
default. Despite my searches, I wasn’t able to find anything. Did I miss 
something obvious?

I’ve added a paragraph to 
https://etherpad.openstack.org/p/liberty-glance-summit-topics to make sure it 
doesn’t get overlooked.

Cheers,

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

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

Re: [openstack-dev] [all] Question for the TC candidates

[Chris Dent]

On Mon, 27 Apr 2015, Doug Hellmann wrote:


I believe all of the posts were on the main OpenStack foundation blog
under the "technical committee" tag [1], and they also went to
planet.openstack.org for folks who subscribe to the entire community
feed.


Ah. Some things about that:

* in the right sidebar, under categories, there is no "category" for
  the "tag" "technical-committee"
* assuming the blog is up to date there were three postings in that
  tag last year, and none so far this year
* there are some posts from this year, but they didn't get the tag


The only way I've been able to get any sense of what the TC might be
up to is by watching the governance project on gerrit and that tends
to be too soon and insufficiently summarized and thus a fair bit of
work to separate the details from the destinations.


I think we chose blog posts for their relative permanence, and
retweetability. Maybe we should post to the mailing list instead,
if the contributor community follows the list more regularly than
blogs?


I think on a blog is a great idea, but my point with above and the
earlier message is either that the blogging is not happening or I'm not
finding it. The impression I got from your earlier message was that
summaries from the meetings were being produced. The TC met more than
three times in 2014, yes? So either something is amiss with linking
up the blog posts or the summaries aren't happening.

I think it would be great if there were weekly or montly summaries. They
can go to whatever medium is deemed appropriate but it is critical that
new folk are able to find them.

_Summaries_ are critical as it is important that the information is
digested and contextualized so its relevance can be more clear. I
know that I can read the IRC logs but I suspect most people don't
want to make the time for that.

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

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

[openstack-dev] [kolla] Alternating Meeting Schedules - Doodle poll inside

[Steven Dake (stdake)]

Hi,

We would like to expand the core team and developers that can participate.  Our 
current 2000 UTC meeting time is not ideal for APAC participants.

I am considering moving the meeting to alternating schedules of 1600 UTC and 
200 UTC.  If you would like to attend the Kolla IRC meeting please fill out the 
short doodle poll:

https://doodle.com/y2kideusi85zm7gh

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

[openstack-dev] [all] Dependency management summit sessions

[Robert Collins]

Hi, so  -

https://libertydesignsummit.sched.org/event/4da45ec1390dadcfc1d8a73decbf3f19#.VT6urd_va00

Is an ops track session about dependencies - focusing on the
operational side (mysql, mongo, rabbit etc). I'd love to have some
developer centric folk in the room, though I'll be doing my best to
capture the ops constraints. My hope is to have a really clear story
about what we can and should depend on, and the cost of non-boring
tech, for our operators.

On 16 April 2015 at 22:32, Sean Dague  wrote:
...
> Possibly, the devil is in the details. Also it means it won't play nice
> with manual pip installs before / after, which are sometimes needed.
>
> Mostly I find it annoying that pip has no global view, so all tools that
> call it have to construct their own global view and only ever call pip
> once to get a right answer. It feels extremely fragile. It's also not
> clear to me how easy it's going to be to debug.

We don't need to do that. I've put some expanded thoughts together here:

https://rbtcollins.wordpress.com/2015/04/28/dealing-with-deps-in-openstack/

I *think* that avoids the omg refactor-devstack thing, at the cost of
a small additional feature in pip.

Thierry says we're going to slot this into
https://libertydesignsummit.sched.org/event/da0f31eddd0def88c6c51fb131fe87bd#.VT6v1N_va00
or the followup after lunch - I'd like to pin it down more than that,
if we can.

-Rob


-- 
Robert Collins 
Distinguished Technologist
HP Converged Cloud

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

[openstack-dev] [Keystone][Glance] Hierarchical multitenancy and Glance?

[Geoff Arnold]

In preparation for Vancouver, I’ve been looking for blueprints and design 
summit discussions involving the application of the Keystone hierarchical 
multitenancy work to other OpenStack projects. One obvious candidate is Glance, 
where, for example, we might want domain-local resource visibility as a 
default. Despite my searches, I wasn’t able to find anything. Did I miss 
something obvious?

I’ve added a paragraph to 
https://etherpad.openstack.org/p/liberty-glance-summit-topics to make sure it 
doesn’t get overlooked.

Cheers,

Geoff
__
OpenStack Development Mailing 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] Navigating the ever changing OpenStack codebase

[Jeremy Stanley]

On 2015-04-27 17:07:56 -0400 (-0400), Ronald Bradford wrote:
[...]
> Specifically, the following two code snippets have become SOP (Standard
> Operating Procedure) jumping around VMs and projects and I suspect if you
> are a developer of this project, something you are very familiar with.
[...]
> python tools/install_venv.py
> source .venv/bin/activate
> 
> ./run_tests.sh
[...]

Not in my experience--common wisdom for the ~2.5 years I've been
involved has been to use tox. It's how we run these tests in gate
jobs, so if a developer is running in a different way they're likely
to encounter all sorts of inconsistencies between their local
results and what the CI eventually reports for a proposed change.

> it not longer exists in this project.
[...]

I consider it an unfortunate oversight that those files weren't
deleted a very, very long time ago.

> So I've solved how to run tests the new way, took longer to write
> this email. Still none the wiser how to run my code in a developer
> virtual environment.

When you use tox, it creates a virtualenv for each testenv in the
envlist from the tox.ini in the repo. You can find these virtualenvs
in the .tox directory after it runs, and can activate and update
them as needed. The documentation for tox is also quite
comprehensive (and linked from the wiki article you were quoting):

http://testrun.org/tox/

Or, you can activate the env and run testr manually (for projects
using it, which is most of them now) as mentioned in the "Writing
Tests for testr" wiki article for testr you linked in your message:

https://wiki.openstack.org/wiki/Testr#Writing_Tests_for_testr

-- 
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] [Neutron][Keystone] [Nova] How to validate teanant-id for admin operation

[Dolph Mathews]

On Mon, Apr 27, 2015 at 6:46 AM, Ajaya Agrawal  wrote:

> On Mon, Apr 27, 2015 at 6:05 AM, Jamie Lennox 
>  wrote:
> >Not to speak for Brant, but i think the confusion here is why you are
> doing this. From my perspective you should never be in >a position where
> the admin has to enter a raw project id like that.
>
> Sometimes you have to do just that. For e.g. adding a member to an image
> in glance. Glance does not verify whether the member being added is a valid
> project_id.
>
> >I think the problem here is the assumption of an all powerful admin user,
> and i'd encourage you to change your policy files to >scrap that idea.
> If there is no powerful admin user then how do you deal with situations
> where a cloud user deletes a project and there are resources(vm, network,
> block, image) tied to this project across components.
>

OpenStack itself should be cleaning up after itself in this scenario.

  https://bugs.launchpad.net/keystone/+bug/967832


http://lists.openstack.org/pipermail/openstack-dev/2015-February/055811.html


>
> Cheers,
> Ajaya
>
>
>
>>
>> - Original Message -
>> > From: "German Eichberger" 
>> > To: "OpenStack Development Mailing List (not for usage questions)" <
>> openstack-dev@lists.openstack.org>
>> > Sent: Saturday, 25 April, 2015 8:55:23 AM
>> > Subject: Re: [openstack-dev] [Neutron][Keystone] [Nova] How to validate
>> teanant-id for admin operation
>> >
>> >
>> >
>> > Hi Brant,
>> >
>> >
>> >
>> > Sorry, for being confusing earlier. We have operations an
>> > administrator/operator is performing on behalf of a user, e.g. “Create
>> > Loadbalancer X for user tenant-id 123”. Now we are not checking the
>> > tenant-id and are wondering how to make the operation more robust with
>> > kesyone’s help.
>> >
>> >
>> >
>> > Thanks,
>> >
>> > German
>>
>>
>>
>> I think the problem here is the assumption of an all powerful admin user,
>> and i'd encourage you to change your policy files to scrap that idea. A
>> role is granted on a project and this project is mentioned in the token. If
>> there is some role that is provided that lets you perform operations
>> outside of the project id specified in that token please file a bug and i'd
>> consider marking it a security issue.
>>
>> The X-Service-Token concept will allow for the combination of a user
>> token and a service token to authenticate an action, so the user can ask
>> for an action to be performed on it's behalf via a service - and in which
>> case the user's project id is communicated via the token.
>>
>> In lieu of all this the quick answer is no. If you are taking a project
>> id from the command line and you want to validate its existence then you
>> have to ask keystone, but you should always be getting this information
>> from a token.
>>
>> Jamie
>>
>> >
>> > From: Brant Knudson [mailto:b...@acm.org]
>> > Sent: Friday, April 24, 2015 11:43 AM
>> > To: OpenStack Development Mailing List (not for usage questions)
>> > Subject: Re: [openstack-dev] [Neutron][Keystone] [Nova] How to validate
>> > teanant-id for admin operation
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > On Fri, Apr 24, 2015 at 11:53 AM, Eichberger, German <
>> > german.eichber...@hp.com > wrote:
>> >
>> > All,
>> >
>> > Following up from the last Neutron meeting:
>> >
>> > If Neutron is performing an operation as an admin on behalf of a user
>> that
>> > user's tenant-id (or project-id) isn't validated - in particular an
>> admin
>> > can mistype and create object on behalf of non existent users. I am
>> > wondering how other projects (e.g. Nova) deal with that and if there is
>> some
>> > API support in keystone to save us a round trip (e.g. authenticate
>> admin +
>> > validate additional user-id).
>> >
>> >
>> >
>> >
>> >
>> > Not to long ago we got support in the auth_token middleware for a
>> "service"
>> > token in addition to the user's token. The user token is sent in the
>> > x-auth-token header and the service token is sent in the
>> x-service-token,
>> > and then fields from both tokens are available to the application
>> (e.g., the
>> > user project is in HTTP_X_PROJECT_ID and the service token roles are in
>> > HTTP_X_SERVICE_ROLES). So you could potentially have a policy rule on
>> the
>> > server for the operation that required the service token to have the
>> > 'service' role, and what neutron could do is send the original user
>> token in
>> > x-auth-token and send its own token as the service token. This seems to
>> be
>> > what you're asking for here.
>> >
>> >
>> > - Brant
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > Thanks,
>> > German
>> >
>> >
>> __
>> > OpenStack Development Mailing 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] Navigating the ever changing OpenStack codebase

[Ronald Bradford]

Hi All,

I have recently become involved in OpenStack development. After installing
a few devstacks (and buying some H/W for my own physical cloud) I settled
into learning, reviewing and debugging the Python OpenStack Client (seemed
an easy access point). I even published a blog post just 7 days ago on my
experiences of Python Virtual Environments (something I was not yet
familiar with. Python being about 10+ on my list of known languages) at
http://ronaldbradford.com/blog/inconsistent-messaging-for-openstackclient-2015-04-20/.
Since then I've been debugging the code and preparing to write some test
cases for what I consider is a small bug, and understand how to work on
making a contribution to that.

Specifically, the following two code snippets have become SOP (Standard
Operating Procedure) jumping around VMs and projects and I suspect if you
are a developer of this project, something you are very familiar with.

git clone git://git.openstack.org/openstack/python-openstackclient
cd python-openstackclient
python tools/install_venv.py
source .venv/bin/activate

./run_tests.sh



Today I went to pickup where I left off last week and I find with an
updated code base and run_tests.sh didn't work. Infact it not longer exists
in this project. See https://review.openstack.org/#/c/177066/

I also found that tools/install_venv.py also gone, see
https://review.openstack.org/#/c/177086/

So, I'm back to knowing almost nil about running tests and debugging my own
code in under a week.

While I appreciate the OpenStack codebase is a growing and evolving project
and I'm still a relative newbie, I'm a little lost in the traceability and
the audibility of a structural change (in other words, how you run unit
tests and setup virtual environments).  I suspect I'm missing something in
the information flow.

I'm on a few mailing lists, in a few IRC rooms, but I found this out by
looking at commit messages at
https://git.openstack.org/cgit/openstack/python-openstackclient/.  I am
unfamiliar with what is the best place for looking at information to remain
informed.

run_tests.sh is a great example where there was no deprecation message and
there is indeed no backward compatibility.  i.e. a run_test.sh that states:
"Run tox instead".  This would at least not catch newbies off guard as much
when reading various documentation.

I also am lead to believe each project is self-governed (which is great as
it doesn't hobble projects by decision making) but that also leads to
different approaches on different projects. You don't want each project to
become siloed and difficult to navigate between them.  There was a choice
many years ago to standardize on Python. There are choices on coding
standards. Does this exist for testing too?

As somebody new to OpenStack code base and willing to contribute, even the
"How to Contribute" (https://wiki.openstack.org/wiki/How_To_Contribute
) while helpful is a lot to tackle. This next step to getting to know the
code, and I've not found a great source for this. I found it better to just
get stuck in downloading, reading and running it.  I looked back and came
across this link I did read some time ago --
http://docs.openstack.org/developer/cinder/devref/development.environment.html


Anybody able to provide recommendations for the new developer in the OS
space I would greatly appreciate it.

Having written this email draft I have delved into reading more about
testing. I started with the projects HACKING.rst which lead to
https://wiki.openstack.org/wiki/Testr and now
https://wiki.openstack.org/wiki/Testing. I should point out the last link
specifically states.

run_tests.sh

There is an older convention, as follows. Most projects have a shell
script, named "run_tests.sh", that runs the unit tests of that project.  ...

So I've solved how to run tests the new way, took longer to write this
email. Still none the wiser how to run my code in a developer virtual
environment.

Regards

Ronald
__
OpenStack Development Mailing 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] Question for the TC candidates

[Doug Hellmann]

Excerpts from Richard Raseley's message of 2015-04-27 12:55:11 -0700:
> Doug Hellmann wrote:
> > I think we chose blog posts for their relative permanence, and
> > retweetability. Maybe we should post to the mailing list instead,
> > if the contributor community follows the list more regularly than
> > blogs?
> 
> I like blog posts for the reasons you mentioned.
> 
> Perhaps sending a message to the list with the link to the post (or some 
> semi-regular digest) would bridge the gap?

I would have to go back and check, but I'm pretty sure the posts were
highlighted in Stef's community newsletter email. Not that we couldn't
do something similar here, but I wouldn't want this email list to turn
into an RSS mirror. Maybe we need to publicize the fact that those posts
are going up in general, rather than each individual post.

Doug

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

Re: [openstack-dev] [Neutron] A big tent home for Neutron backend code

[Russell Bryant]

On 04/22/2015 02:19 PM, Russell Bryant wrote:
> a) Adopt these as repositories under the Neutron project team.
> 
> In this case, I would see them operating with their own review teams as
> they do today to avoid imposing additional load on the neutron-core or
> neutron-specs-core teams.  However, by being a part of the Neutron team,
> the backend team would submit to oversight by the Neutron PTL.
> 
> There are some other details to work out to ensure expectations are
> clearly set for everyone involved.  If this is the path that makes
> sense, we can work through those as a next step.

Based on the feedback on this thread so far, this seems like the best
choice.  I said I'd come back with some more proposed details, so here
we are.  Let me know what seems off or missing here.


1) Process

The process for proposing the move of a repo into openstack/ and under
the Neutron project is to propose a patch to the openstack/governance
repository.  For example, if I were proposing moving networking-ovn, I
would add the following entry under Neutron in reference/projects.yaml:

- repo: openstack/networking-ovn
  tags:
- name: release:independent

For more information about the release:independent tag (and other
currently defined tags) see:

http://governance.openstack.org/reference/tags/

The Neutron PTL must approve the change.  The TC clarified that once a
project has been approved (Neutron in this case), the project can add
additional repos without needing TC approval as long as the added
repositories are within the existing approved scope of the project.


http://git.openstack.org/cgit/openstack/governance/commit/?id=321a020cbcaada01976478ea9f677ebb4df7bd6d


2) Responsibilities

All affected repositories already have their own review teams.  The
sub-team working on the sub-project is entirely responsible for
day-to-day development.  That includes reviews, bug tracking, and
working on testing.

By being included, the project accepts oversight by the TC as a part of
being in OpenStack, and also accepts oversight by the Neutron PTL.


3) Criteria

As mentioned before, the Neutron PTL must approve the inclusion of each
additional repository under the Neutron project.  I suggest that the
primary criteria used should be the same as what the TC uses for new
OpenStack projects, at least where it makes sense:

http://governance.openstack.org/reference/new-projects-requirements.html

One detail that I expect might be controversial is around maturity.  I
think it's important that we recognize and embrace that from the very
beginning of many projects, they are indeed "one of us", even if it's
early in the development process.  We should *not* be using that as
entry criteria into what's considered OpenStack.

Instead, we should be looking to define project metadata to help people
understand what things are, including their features, limitations, and
maturity level.  The tags system being used by the TC is intended to
address this at an OpenStack-wide level.  Some additional work could be
done specific to Neutron, just with a page that lists backends and
information about them.

Any project that fails to meet the criteria later can be dropped at any
time.  For example, if some repo is clearly unmaintained, it can be removed.

-- 
Russell Bryant

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

[openstack-dev] [barbican] Storing and retrieving secrets.

[Christopher N Solis]

Hello.
I have a question concerning the creation and retrieval of a secret.

I used the orders resource to request a key to be generated of type
text/plain.
However, I cannot retrieve it of type text/plain. It appears I can only
retrieve it of
type octet-stream.

I just wanted to clarify this is the correct functionality?
I can understand why this is the implemented route but just want to make
sure it's
not possible to retrieve a secret of type text/plain when generated by
barbican
using the orders resource.

Thank You.

Regards,

  CHRIS SOLIS__
OpenStack Development Mailing 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] RegionOne vs. regionOne

[Morgan Fainberg]

> On Apr 27, 2015, at 14:35, Christopher Aedo  wrote:
> 
>> On Mon, Apr 27, 2015 at 10:52 AM, Sean M. Collins  wrote:
>> Oh, I should actually mention which way I think we should go with.
>> 
>> RegionOne should be the convention.
> 
> This came up in January[1][2] relating to case sensitivity in MySQL,
> Keystone and TripleO, and there's a bug noted[3] as well.
> 
> I'm in support of RegionOne as the convention and haven't seen anyone
> else speak out against it.
> 
> [1]http://lists.openstack.org/pipermail/openstack-dev/2015-January/053966.html
> [2]http://lists.openstack.org/pipermail/openstack-dev/2015-January/053889.html
> [3]https://bugs.launchpad.net/keystone/+bug/1400589
> 

There is also a proposed cross-project session on normalizing the keystone 
catalog (at the summit in Vancouver). This fits into that discussion nicely. 

--Morgan
Sent via mobile

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

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

Re: [openstack-dev] [all] Question for the TC candidates

[Richard Raseley]

Doug Hellmann wrote:

I think we chose blog posts for their relative permanence, and
retweetability. Maybe we should post to the mailing list instead,
if the contributor community follows the list more regularly than
blogs?


I like blog posts for the reasons you mentioned.

Perhaps sending a message to the list with the link to the post (or some 
semi-regular digest) would bridge the gap?


Regards,

Richard

__
OpenStack Development Mailing 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] Question for the TC candidates

[Doug Hellmann]

Excerpts from Chris Dent's message of 2015-04-27 17:32:12 +0100:
> On Mon, 27 Apr 2015, Doug Hellmann wrote:
> 
> > For outgoing communication, during Kilo (and possibly Juno) we tried
> > blogging meeting summaries. Did folks notice? Were the posts useful?
> 
> Is there a TC specific blog place of interest? I sometimes stumble
> on blog postings from people I know are TC people but I'm not sure if
> they are speaking in-their-position-as. And there is the governance
> category on the "The OpenStack Blog" with subjects that begin
> "OpenStack Technical Committee Update:", but the last one of those
> that I can find is from February, so I assume you must mean
> somewhere else?
> 
> Where do you mean?

I believe all of the posts were on the main OpenStack foundation blog
under the "technical committee" tag [1], and they also went to
planet.openstack.org for folks who subscribe to the entire community
feed.

> 
> The only way I've been able to get any sense of what the TC might be
> up to is by watching the governance project on gerrit and that tends
> to be too soon and insufficiently summarized and thus a fair bit of
> work to separate the details from the destinations.

I think we chose blog posts for their relative permanence, and
retweetability. Maybe we should post to the mailing list instead,
if the contributor community follows the list more regularly than
blogs?

Doug

[1] http://www.openstack.org/blog/tag/technical-committee/

__
OpenStack Development Mailing 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] [glance] Why no DB index on sort parameters

[Jay Pipes]

At the very least, an index on the default sort column (created_at) 
would be appropriate, IMO.


Best,
-jay

On 04/27/2015 01:42 PM, Rushi Agrawal wrote:

Now that raises a question: do we really need sorting based on arbitrary
keys in our API (e.g. listing images, volumes, instances)? If we have
this feature in our API, we're bound to run into problems by creating or
not creating indexes, at large volumes -- hurts our motive to be
easily-implementable for clouds of all sizes.

-Rushi

On 23 April 2015 at 20:40, Nikhil Komawar mailto:nikhil.koma...@rackspace.com>> wrote:

Messing with indices is not a good idea to do iteratively.  Indexing
large data sets is a really expensive operation and should be done
carefully and consistently. Changing around indices is only going to
make things unstable.

Thanks,
-Nikhil


From: Flavio Percoco mailto:fla...@redhat.com>>
Sent: Thursday, April 23, 2015 7:52 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [glance] Why no DB index on sort parameters

On 21/04/15 14:55 +, Nikhil Komawar wrote:
 >Rally is great overall however, we need good EXPLAIN examples on
real world data. Smaller deployments might benefit from a simple
sample performance analysis however, larger data sets can have
impacts on areas that you never expect.
 >
 >A spec means that we document the indices proposed in the code
base, based on all of the use cases. The way I look at it, a patch
is needed anyways and it (rally gate job) would get attention from
reviewers when the patch is proposed.

Yes, I believe we need both. However, I'd probably just start with
something smaller and see how it behaves before going with big data
sets.

I'm not saying we don't need tests with proper data sets, I'm saying
that I'd probably start with smaller ones. As Mike already mentioned
in his email, there's an impact in writes and we can see that from
Rally tests, AFAICT.

The spec can come later, IMHO.

Cheers,
Flavio

 >
 >
 >From: Flavio Percoco mailto:fla...@redhat.com>>
 >Sent: Tuesday, April 21, 2015 10:48 AM
 >To: OpenStack Development Mailing List (not for usage questions)
 >Subject: Re: [openstack-dev] [glance] Why no DB index on sort
parameters
 >
 >On 21/04/15 14:39 +, Nikhil Komawar wrote:
 >>This is a good idea. We recently removed a unique constraint that
may result
 >>into some queries being very slow especially those that involve
"name"
 >>property. I would recommend sketching out a spec that identifies
potential full
 >>table scans especially for queries that join over
image_properties table.
 >>
 >>
 >>We should discuss there what other use cases look like rather
than smaller
 >>feedback on the ML.
 >
 >More thatn a spec, I'd be interested in seeing the patch with the
 >change up and the results reported in Rally.
 >
 >I guess we'll need a spec anyway, although I'd probably be ok with a
 >good bug report here.
 >
 >/me *shrugs*
 >Flavio
 >
 >>
 >>
 >>Thanks,
 >>-Nikhil
 
>>━━━
 >>From: Mike Bayer mailto:mba...@redhat.com>>
 >>Sent: Tuesday, April 21, 2015 9:45 AM
 >>To: openstack-dev@lists.openstack.org

 >>Subject: Re: [openstack-dev] [glance] Why no DB index on sort
parameters
 >>
 >>
 >>
 >>On 4/21/15 2:47 AM, Ajaya Agrawal wrote:
 >>
 >>Hi All,
 >>
 >>I see that glance supports arbitrary sort parameters and the
default is
 >>"created_at" while listing images. Is there any reason why we
don't have
 >>index over these fields? If we have an index over these
fields then we
 >>would avoid a full table scan to do sorting. IMO at least the
created_at
 >>field should have an index on it.
 >>
 >>just keep in mind that more indexes will place a performance
penalty on INSERT
 >>statements, particularly at larger volumes.  I have no idea if
that is
 >>important here but something to keep in mind.
 >>
 >>
 >>
 >>
 >>
 >>
 >>Cheers,
 >>Ajaya
 >>
 >>
 >>
 >>
__
 >>OpenStack Development Mailing 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] RegionOne vs. regionOne

[Christopher Aedo]

On Mon, Apr 27, 2015 at 10:52 AM, Sean M. Collins  wrote:
> Oh, I should actually mention which way I think we should go with.
>
> RegionOne should be the convention.

This came up in January[1][2] relating to case sensitivity in MySQL,
Keystone and TripleO, and there's a bug noted[3] as well.

I'm in support of RegionOne as the convention and haven't seen anyone
else speak out against it.

[1]http://lists.openstack.org/pipermail/openstack-dev/2015-January/053966.html
[2]http://lists.openstack.org/pipermail/openstack-dev/2015-January/053889.html
[3]https://bugs.launchpad.net/keystone/+bug/1400589

__
OpenStack Development Mailing 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] change jenkins CI to distinguish different types of failures?

[Jeremy Stanley]

On 2015-04-27 11:38:09 -0600 (-0600), Chris Friesen wrote:
[...]
> In circumstances like this I wonder if it might make sense to have Jenkins
> "abstain" rather than mark it -1.  We could then have a job that went around
> and re-ran Jenkins tests for cases where it "abstained" previously.
[...]

In a Jenkinsless future, this may be possible. At the moment, we're
using Jenkins and its status reporting is effectively limited to
"SUCCESS" and "FAILURE." We're going to need something which can
provide a finer-grained result (the current plans around non-Jenkins
job workers leave us open to this possibility).

Also, some of our projects actually ARE test frameworks, so for
changes proposed to those we definitely want failures of that
framework to be reported as failures of the jobs testing them. It
may be a little tough to differentiate between these cases.

Further, reviewers want to rely on job results to know whether the
change works. If the CI merely abstained from reporting when it
didn't get a chance to run the job to completion, there's no
indication of whether that job would have worked. We could try to
solve this by automatically requeuing the jobs which hit this
condition, but it leaves us open to a rather nasty problem for which
we'd need a separate release valve: if the test framework itself is
broken and not simply experiencing an intermittent problem, we'd
requeue and run all jobs using it in an infinite loop consuming all
our resources and effectively starving out worker availability for
other jobs which aren't broken.
-- 
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] [chef] Openstack-Chef has officially moved to this mailing list

[JJ Asghar]

Hey everyone!

Per moving to the OpenStack namespace[1] the OpenStack Chef community has moved 
from our Google Group[2] to this mailing list. 

This is just a notification to the wider audience that this has happened.

-JJ Asghar

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

[2]: https://groups.google.com/forum/#!forum/opscode-chef-openstack__
OpenStack Development Mailing 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] Why do we need to select subnet when creating a pool?

[Wanjing Xu]

So when I use Haproxy for LBaaS for Juno, there is a subnet mandatary field 
that I need to fill in when creating a pool, and later on when I add members, I 
can use a different subnet(or simply just enter the ip of the member), when 
adding vip, I can still select a third subnet.  So what is the usage of the 
first subnet that I used to create pool?  There is no port created for this 
pool subnet.  I can see that a port is created for the vip subnet that the 
loadbalancer instance is binding to.
Regards!
Wanjing Xu__
OpenStack Development Mailing 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] RegionOne vs. regionOne

[Sean M. Collins]

Oh, I should actually mention which way I think we should go with.

RegionOne should be the convention.

-- 
Sean M. Collins

__
OpenStack Development Mailing 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] [Manila] Mount automation using Zeroconf

[Luis Pabon]

Hi Clinton,
  I think there are two main parts that are needed to automatically mount 
Manila shares.  One is the share discovery model, and the other is enabling the 
virtual machine to mount the share.  I think the only benefit to using zeroconf 
would be as a standard way to broadcast availability of a network share 
regardless of protocol.  Manila could broadcast the availability of a share by 
using a name like _manila_nfs, _manila_cifs, _manila_gluster, etc.  Although, 
even with zeroconf, the virtual machine still requires an agent to be able to 
attach the share for use.  I think the real benefit of using zeroconf is its 
simplicity.

There could still be other methods we can investigate.  For example (don't kill 
me for this ;-)), have a Manila YP NIS service for NFS shares?

- Luis



 
- Original Message -
From: "Clinton Knight" 
To: "OpenStack Development Mailing List (not for usage questions)" 

Sent: Wednesday, April 22, 2015 3:29:50 PM
Subject: [openstack-dev] [Manila] Mount automation using Zeroconf

Hello, Manila-philes. 

Back in Paris we started talking about Manila mount automation, whereby file 
shares could be automatically mounted on clients, and this will likely be a 
topic in Vancouver. So in order to have an informed discussion at the summit, 
I'd like to explore a few things beforehand. 

Besides brute force approaches like SSH or PsExec, one of the community 
suggestions was to use Zeroconf (aka Bonjour)[1]. Zeroconf sounds attractive on 
the surface, but it seems to have a number of limitations: 

* No standard way to specify local mount point 
* Additional setup required to work beyond the 'local' domain 
* Custom software needed on clients to mount advertised shares 
* Same issues with network connectivity as any other mount automation solution 

Does anyone have a clearer idea how Zeroconf might satisfy the need for Manila 
mount automation? 

Thanks, 
Clinton Knight 
Manila core team 

[1] http://en.wikipedia.org/wiki/Zero-configuration_networking 


__
OpenStack Development Mailing 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] [Zaqar] Call for adoption (or exclusion?)

[Joe Gordon]

On Fri, Apr 24, 2015 at 5:19 PM, Zane Bitter  wrote:

> On 24/04/15 20:00, Joe Gordon wrote:
>
>>
>>
>> On Fri, Apr 24, 2015 at 4:35 PM, Fox, Kevin M > > wrote:
>>
>> Notification might be a good way to integrate with nova. Individual
>> tenants might want to do things as vm's come up/down, etc. Right
>> now, you need a privileged pipe into rabbit. Forwarding them to
>> Zaqar, per tenant queue's could solve the problem.
>>
>>
>> Right now you can poll the nova API. Or tenants can use any number of
>> monitoring tools.  How does zaqar better then the alternatives?
>>
>
> So, a couple of points about that:
>
>  1) Polling sucks.
>  2) If a bunch of things are going to get polled, at least collect them
> together so there is *one* thing to optimise for massive polling load.
> (Zaqar is this thing - you have to poll it too atm.)
>  3) Long-polling and WebSockets suck a lot less than polling. If you
> already collected all the polling in one place, it's really easy to make
> the switch as soon as you implement them in that one place.
>  4) If you don't have a common place to poll, then you can't use the
> events as triggers for other services in OpenStack (without writing custom
> polling code for every endpoint in every API - which is pretty much what
> Heat does now, but that work doesn't extend automatically to Mistral,
> Congress, &c. in the way that Zaqar notifications could.)
>
> Also, APIs tend to only return the current status. You could miss events
> if you just poll the API, whereas if the events are dispatched to a durable
> queue and you just poll the queue for events, that problem goes away.


>
>  FWIW, I think there are some really neat use cases for amazon SQS, that
>> presumably Zaqar would fit as well. Cases such as
>> https://aws.amazon.com/articles/1464
>>
>
> Bingo, this is where it starts to get really interesting.
>

Instead of asking the community to come up with reasons to integrate with
Zaqar, I think it would be more effective if the Zaqar team came up with
one or two use cases they want to support that require integration with
other projects and go from there. Turn this abstract call for adoption into
a more narrow but concrete proposal for X and Y to integrate with Zaqar to
support a specific use case.


>
> cheers,
> Zane.
>
>
>> Thanks,
>> Kevin
>>
>> 
>> *From:* Joe Gordon [joe.gord...@gmail.com
>> ]
>> *Sent:* Friday, April 24, 2015 4:02 PM
>> *To:* OpenStack Development Mailing List (not for usage questions)
>> *Subject:* Re: [openstack-dev] [Zaqar] Call for adoption (or
>> exclusion?)
>>
>>
>>
>> On Mon, Apr 20, 2015 at 5:54 AM, Flavio Percoco > > wrote:
>>
>> Greetings,
>>
>> I'd like my first action as Zaqar's PTL to be based on
>> reflections and
>> transparency with regards to what our past has been, to what our
>> present is and to what our future could be as a project and
>> community.
>> Therefore, I'm sending this call for adoption and support before
>> taking other actions (also mentioned below).
>>
>> The summit is very close and the Zaqar team is looking forward
>> to it.
>>
>> The upcoming summit represents an important opportunity for Zaqar
>> to
>> integrate with other projects. In the previous summits - since
>>
>>
>> I get integration with Horizon etc. But to use the SQS/SNS analogy
>> how would say Nova integrate with Zaqar?
>>
>> Icehouse's - we've been collecting feedback from the community.
>> We've
>> worked on addressing the many use-cases, we've worked on
>> addressing
>> the concerns raised by the community and we've also kept moving
>> towards reaching the project's goals.
>>
>> As you all know, the project has gone through many ups and downs.
>> We've had some "failures" in the past and we've also had
>> successes, as
>> a project and as a team. Nevertheless, we've got to the point
>> where it
>> doesn't make much sense to keep pushing new features to the
>> project
>> until it gains adoption. Therefore, I'd like to take advantage
>> of the
>> workshop slots and invite people from other projects to help
>> us/guide
>> us through a hacking session on their projects so we can help
>> with the
>> adoption. The current adoption of Zaqar consist in:
>>
>> - 1 company reachingunning it in production
>> - 1 planning to do it soon
>> - RDO support
>>
>> Unfortunately, the above is certainly not enough for a project to
>> succeed and it makes the time and effort spent on the project not
>> worth it. It's been more than 2 years since we kicked the
>> project o

Re: [openstack-dev] [glance] Why no DB index on sort parameters

[Rushi Agrawal]

Now that raises a question: do we really need sorting based on arbitrary
keys in our API (e.g. listing images, volumes, instances)? If we have this
feature in our API, we're bound to run into problems by creating or not
creating indexes, at large volumes -- hurts our motive to be
easily-implementable for clouds of all sizes.

-Rushi

On 23 April 2015 at 20:40, Nikhil Komawar 
wrote:

> Messing with indices is not a good idea to do iteratively.  Indexing large
> data sets is a really expensive operation and should be done carefully and
> consistently. Changing around indices is only going to make things unstable.
>
> Thanks,
> -Nikhil
>
> 
> From: Flavio Percoco 
> Sent: Thursday, April 23, 2015 7:52 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [glance] Why no DB index on sort parameters
>
> On 21/04/15 14:55 +, Nikhil Komawar wrote:
> >Rally is great overall however, we need good EXPLAIN examples on real
> world data. Smaller deployments might benefit from a simple sample
> performance analysis however, larger data sets can have impacts on areas
> that you never expect.
> >
> >A spec means that we document the indices proposed in the code base,
> based on all of the use cases. The way I look at it, a patch is needed
> anyways and it (rally gate job) would get attention from reviewers when the
> patch is proposed.
>
> Yes, I believe we need both. However, I'd probably just start with
> something smaller and see how it behaves before going with big data
> sets.
>
> I'm not saying we don't need tests with proper data sets, I'm saying
> that I'd probably start with smaller ones. As Mike already mentioned
> in his email, there's an impact in writes and we can see that from
> Rally tests, AFAICT.
>
> The spec can come later, IMHO.
>
> Cheers,
> Flavio
>
> >
> >
> >From: Flavio Percoco 
> >Sent: Tuesday, April 21, 2015 10:48 AM
> >To: OpenStack Development Mailing List (not for usage questions)
> >Subject: Re: [openstack-dev] [glance] Why no DB index on sort parameters
> >
> >On 21/04/15 14:39 +, Nikhil Komawar wrote:
> >>This is a good idea. We recently removed a unique constraint that may
> result
> >>into some queries being very slow especially those that involve "name"
> >>property. I would recommend sketching out a spec that identifies
> potential full
> >>table scans especially for queries that join over image_properties table.
> >>
> >>
> >>We should discuss there what other use cases look like rather than
> smaller
> >>feedback on the ML.
> >
> >More thatn a spec, I'd be interested in seeing the patch with the
> >change up and the results reported in Rally.
> >
> >I guess we'll need a spec anyway, although I'd probably be ok with a
> >good bug report here.
> >
> >/me *shrugs*
> >Flavio
> >
> >>
> >>
> >>Thanks,
> >>-Nikhil
>
> >>━━━
> >>From: Mike Bayer 
> >>Sent: Tuesday, April 21, 2015 9:45 AM
> >>To: openstack-dev@lists.openstack.org
> >>Subject: Re: [openstack-dev] [glance] Why no DB index on sort parameters
> >>
> >>
> >>
> >>On 4/21/15 2:47 AM, Ajaya Agrawal wrote:
> >>
> >>Hi All,
> >>
> >>I see that glance supports arbitrary sort parameters and the default
> is
> >>"created_at" while listing images. Is there any reason why we don't
> have
> >>index over these fields? If we have an index over these fields then
> we
> >>would avoid a full table scan to do sorting. IMO at least the
> created_at
> >>field should have an index on it.
> >>
> >>just keep in mind that more indexes will place a performance penalty on
> INSERT
> >>statements, particularly at larger volumes.  I have no idea if that is
> >>important here but something to keep in mind.
> >>
> >>
> >>
> >>
> >>
> >>
> >>Cheers,
> >>Ajaya
> >>
> >>
> >>
> >>
> __
> >>OpenStack Development Mailing 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
> >
> >
> >--
> >@flaper87
> >Flavio Percoco
> >
> >__
> >OpenStack Development Mailing List (not for usage questions)
> >Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> --
> @flaper87
> Flavio Percoco
>
> 

Re: [openstack-dev] [heat] Stack/Resource updated_at conventions

[Steven Hardy]

On Mon, Apr 27, 2015 at 04:46:20PM +0100, Steven Hardy wrote:
> AFAICT there's two options:
> 
> 1. Update the stack.Stack so we store "now" at every transition (e.g in
> state_set)
> 
> 2. Stop trying to explicitly control updated_at, and just allow the oslo
> TimestampMixin to do it's job and update updated_at every time the DB model
> is updated.

Ok, at the risk of answering my own question, there's a third option, which
is to output an event for all stack transitions, not only resource
transitions.  This appears to be the way the CFN event API works AFAICS.

I guess the event would have a dummy OS::Heat::Stack type and then you
could find the most recent transition to e.g UPDATE_IN_PROGRESS in the
events and use that as a marker so you only list results after that event?

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

[openstack-dev] change jenkins CI to distinguish different types of failures?

[Chris Friesen]

Hi,

I was recently hit with a couple of Jenkins -1 votes due to underlying failures 
in the test framework which never even completed the installation of the test 
framework.


In circumstances like this I wonder if it might make sense to have Jenkins 
"abstain" rather than mark it -1.  We could then have a job that went around and 
re-ran Jenkins tests for cases where it "abstained" previously.


I think it would make sense for Jenkins to only vote -1 if it actually ran the 
tests and hit failures (as opposed to failing to run the test at all).


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] [Infra] Meeting Tuesday April 28th at 19:00 UTC

[Elizabeth K. Joseph]

Hi everyone,

The OpenStack Infrastructure (Infra) team is having our next weekly
meeting on Tuesday April 28th, at 19:00 UTC in #openstack-meeting

Meeting agenda available here:
https://wiki.openstack.org/wiki/Meetings/InfraTeamMeeting (anyone is
welcome to to add agenda items)

Everyone interested in infrastructure and process surrounding
automated testing and deployment is encouraged to attend.

In case you missed it or would like a refresher, meeting logs and
minutes from our last meeting are available here:

Minutes: 
http://eavesdrop.openstack.org/meetings/infra/2015/infra.2015-04-21-19.01.html
Minutes (text):
http://eavesdrop.openstack.org/meetings/infra/2015/infra.2015-04-21-19.01.txt
Log: 
http://eavesdrop.openstack.org/meetings/infra/2015/infra.2015-04-21-19.01.log.html

-- 
Elizabeth Krumbach Joseph || Lyz || pleia2

__
OpenStack Development Mailing 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] [Zaqar] Call for adoption (or exclusion?)

[Joe Gordon]

On Fri, Apr 24, 2015 at 5:05 PM, Zane Bitter  wrote:

> On 24/04/15 19:02, Joe Gordon wrote:
>
>>
>>
>> On Mon, Apr 20, 2015 at 5:54 AM, Flavio Percoco > > wrote:
>>
>> Greetings,
>>
>> I'd like my first action as Zaqar's PTL to be based on reflections and
>> transparency with regards to what our past has been, to what our
>> present is and to what our future could be as a project and community.
>> Therefore, I'm sending this call for adoption and support before
>> taking other actions (also mentioned below).
>>
>> The summit is very close and the Zaqar team is looking forward to it.
>>
>> The upcoming summit represents an important opportunity for Zaqar to
>> integrate with other projects. In the previous summits - since
>>
>>
>> I get integration with Horizon etc. But to use the SQS/SNS analogy how
>> would say Nova integrate with Zaqar?
>>
>
> Speaking very generally, anything where it makes sense for Nova to tell
> the user - or, more importantly, the application - when something is
> happening. The cloud can't afford to be making synchronous calls to the
> client-side, and applications may not be able to afford missing the
> notifications, so a reliable, asynchronous transport like Zaqar is a good
> candidate.
>
> So examples might be:
>  - Hey, your resize is done
>  - Hey, your [re]build is done
>  - Hey, your VM rebooted
>  - Hey, your VM disappeared
>
> Now, this is not to presuppose that having Nova put messages directly into
> Zaqar is the correct design. It may be that it's better to have some other
> service (Ceilometer?) collect some or all of those notifications and handle
> putting them into Zaqar (though the reliability would be a concern).
> Certainly EC2 seems to funnel all this stuff to CloudWatch, although other
> services like S3, CloudFormation & Auto Scaling deliver notifications to
> SNS directly. There is some integration work either way though, to produce
> the notification.
>
> Obviously there's less integration to do for a project like Nova that only
> produces notifications than there would be for those that could actually
> consume notifications. Heat would certainly like to use these notifications
> to reduce the amount of polling we do of the APIs (and ditch it altogether
> if reliability is guaranteed). But if we can get both ends integrated then
> the *user* can start doing really interesting things like:
>

This is one of the bigger questions for me, as a nova developer. What would
integration look like from Nova's POV.  I am a little weary of adding yet
another API when we have so much trouble with our existing ones.
Especially the notification based API.


>
>  - Hey Zaqar, give me a new queue/topic/whatever
>  - Hey Mistral, run this workflow when you see a message on this topic
>  - Hey Nova, send a message to this topic whenever my VM reboots
>
> Bam, user-defined workflow triggered on VM reboot. (Super easy to set up
> in a Heat template BTW ;)
>
> It gets even cooler when there are multiple producers and consumers:
> imagine that Ceilometer alarms and all other kinds of notifications in
> OpenStack are produced this way, and that SNS-style notifications, Heat
> autoscaling events and Mistral workflows can all be triggered by them. And
> of course if the logic available in the workflow isn't sufficient, the user
> can always insert their own conditioning logic running in a VM (future:
> container), since the flow is through a user-facing messaging system.
>
> I wrote a blog post earlier today about why all this is needed:
>
> http://www.zerobanana.com/archive/2015/04/24#a-vision-for-openstack
>
> tl;dr: many applications being written now and even more in the future
> will expect to be able to interact with their own infrastructure and will
> go to proprietary clouds if we don't provide an open source alternative.
>
> cheers,
> Zane.
>
>  Icehouse's - we've been collecting feedback from the community. We've
>> worked on addressing the many use-cases, we've worked on addressing
>> the concerns raised by the community and we've also kept moving
>> towards reaching the project's goals.
>>
>> As you all know, the project has gone through many ups and downs.
>> We've had some "failures" in the past and we've also had successes, as
>> a project and as a team. Nevertheless, we've got to the point where it
>> doesn't make much sense to keep pushing new features to the project
>> until it gains adoption. Therefore, I'd like to take advantage of the
>> workshop slots and invite people from other projects to help us/guide
>> us through a hacking session on their projects so we can help with the
>> adoption. The current adoption of Zaqar consist in:
>>
>> - 1 company reachingunning it in production
>> - 1 planning to do it soon
>> - RDO support
>>
>> Unfortunately, the above is certainly not enough for a project to
>> succeed and it makes the time a

[openstack-dev] RegionOne vs. regionOne

[Sean M. Collins]

Hi,

Currently we have some parts of OpenStack that use "regionOne" while
others use "RegionOne"

Now, I know that "consistency is the hobgoblin of little minds"[1], but
I think in this situation it's worth going through and settling on one
way. I've pushed a patch to the install guide fixing the convention, and
will go through and fix other instances.


[1]: https://www.brainyquote.com/quotes/quotes/r/ralphwaldo136909.html
-- 
Sean M. Collins

__
OpenStack Development Mailing 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] [heat] Stack/Resource updated_at conventions

[Steven Hardy]

On Mon, Apr 27, 2015 at 04:45:10PM +, Randall Burt wrote:
> 2 sounds right to me, but does the in-memory representation get updated or 
> are we forced into a refetch at every change?

Yeah, we probably would be, digging some more there's historical context
here:

https://bugs.launchpad.net/heat/+bug/1193269

AFAICT the fix for that bug introduced the behavior I'm now trying to
avoid, but is actually correct, if the objective is to remain consistent
with the CFN "LastUpdatedTime", which says "The time the stack was last
updated".

My comments about suspend/resume etc were actually incorrect, we only store
updated_at on the transistion to UPDATE_COMPLETE.

Any other ideas of where we can expose the timestamp associated with the
transition to UPDATE_IN_PROGRESS, which is the info I need?

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] [Infra][Cinder] get voting permissions for Infortrend 3rd-party CI

[Mike Perez]

On 03:42 Apr 27, Ryan.Chiang(江明哲) wrote:
> Dear Sirs,

https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers#When_thirdparty_CI_voting_will_be_required.3F

-- 
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] [glance] Call to action, revisit CIS state

[Ian Cordasco]

On 4/27/15, 05:39, "Kuvaja, Erno"  wrote:

>Hi all,
> 
>As you probably know CIS was expanded from Juno metadefs work this cycle
>based on spec [1] provided. The implementation was merged in quite a rush
>just before feature freeze.
> 
>During the spec review [2] for client functionality for CIS it came to
>our attention that the implementation exposes Elasticsearch perhaps too
>openly via it’s API (namely the creation of datasets allows API consumer
>uploading arbitrary
> files via the create request).
> 
>Call to action: Please review the CIS functionality again for security
>threats and bring them up so we can form a plan if we need to address
>those and request RC3 before release.
> 
>I have couple of major concerns about this workflow:
>1) 
>I was shocked after reading following statement from the client spec
>review discussion: “””During the Kilo release, we - by we I mean the team
>responsible for implementing the CIS - have discussed such scenario, that
>exposing Elasticsearch
> capabilities to the user consuming the CIS API can bring some serious
>security impact.””” This discussion nor the scenario was never brought to
>attention of the wider Glance community. The spec bluntly states that
>there is no security impact from the implementation
> and the concerns should have been brought up so reviewers would have had
>better chance to catch possible threats.
>2) 
>“””Would like to also address your concern that proposed shape of spec
>allows user to upload arbitrary documents to Elasticsearch (ES is the
>engine used under the hood, we should rather talk about uploading
>documents to CIS service)
> which are not related to Glance in any way (images & metadefs in current
>implementation).””” “””Personally I don't think that discussion about IF
>is a valid topic, because we've already implemented backend for CIS at
>the Glance side and you cannot say A without
> saying B.””” As long as the code is developed under the Glance project
>and reviewed by glance-core it’s outrageous to claim that possible issues
>are not related to Glance in any way. Discussion about if the API is
>implemented by the spec and fits to the mission
> statement is really valid at this point and needs to be thoroughly
>discussed. We need to find the root cause of this attitude and fix it
>before it damages the relationships within the community in a way that
>cannot be fixed.
>3) 
>We had two huge pieces of code merging in at the very end of the
>development cycle Artifacts and CIS and the pressure to merge them in
>(unfortunately not review but merge) was high. On the artifacts side we
>had pretty open discussion
> about the state, the concerns and plans of timelines address those
>concerns. With CIS we unfortunately did not have this openness. Was it
>reflection of 1 & 2 or something else, I do not know, but I surely would
>like to.
> 
>I would like you to look back into those two specs and the comments, look
>back into the implementation and raise any urgent concerns and please
>lets try to have good and healthy base for discussion in the Vancouver
>Summit how we will continue
> forward from this! As Stable Branch Liaison I would really like to know
>what we (and who that we are) are supporting for next couple of cycles,
>as glance-core I would like to know any concerns about used technology or
>implementation people might have and as
> Glance community member I’d like to see us working together towards
>these things and definitely not have these “we” vs. “them”/”you”
>discussions anymore. Bluntly if we need to split the team, let’s do it
>officially, there is room under big tent for every group
> who wants to be with themselves.
> 
>Best Regards,
>Erno
> 
>[1] 
>http://specs.openstack.org/openstack/glance-specs/specs/kilo/catalog-index
>-service.html 
>x-service.html>
>[2] https://review.openstack.org/#/c/173718/
> 
>

I’m admittedly one of the people who read what was in the client
specification and became very nervous. The portion under “Proposed Change”
that discusses how the glance client is going to create a document in
CIS/Elasticsearch does not make reference to the fact that the indices
will be validated by CIS. The code that implements CIS’s endpoints is
actually relatively small (in terms of lines of code). I quickly scanned
the controller portion and found that we reject anything that isn’t a
registered index: 
https://github.com/openstack/glance/blob/582f8563e866f167ae1de1a2309c1a1e24
84442a/glance/search/api/v0_1/search.py#L136 At a glance this seems great.
We only have one index defined by the plugins
https://github.com/openstack/glance/tree/582f8563e866f167ae1de1a2309c1a1e24
84442a/glance/search/plugins (“glance”) and two document types.

There’s a slight problem with this though. We load the plugins dynamically
https://github.com/openstack/glance/blob/582f8563e866f167ae1de1a2309c1a1e24
84442a/glance/common/utils.py#L735 (as 

[openstack-dev] [puppet] Weekly meeting #33

[Emilien Macchi]

Hi,

Tomorrow is our weekly meeting.
Please look at the agenda [1].

Feel free to bring new topics and reviews/bugs if needed.
Also, if you had any action, make sure you can give a status during the
meeting or in the etherpad directly.

See you tomorrow,

[1]
https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20150428
-- 
Emilien Macchi



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

Re: [openstack-dev] COMMERCIAL: [heat] Stack/Resource updated_at conventions

[Randall Burt]

2 sounds right to me, but does the in-memory representation get updated or are 
we forced into a refetch at every change?

On Apr 27, 2015, at 10:46 AM, Steven Hardy  wrote:

> Hi all,
> 
> I've been looking into $subject recently, I raised this bug:
> 
> https://bugs.launchpad.net/heat/+bug/1448155
> 
> Basically we've got some historically weird and potentially inconsistent
> behavior around updated_at, and I'm trying to figure out the best way to
> proceed.
> 
> Now, we selectively update updated_at only on the transition to
> UPDATE_COMPLETE, where we store the time that we moved into
> UPDATE_IN_PROGRESS.  During the update, there's no way to derive the
> time we started the update.
> 
> Also, we inconsistently store the time associated with the transition into
> IN_PROGRESS for suspend, resume, snapshot, restore and check actions (even
> though many of these don't modify the stack definition).
> 
> The reason I need this is the hook/breakpoint API - the only way to detect
> if you've hit a breakpoint is via events, and to detect you've hit a hook
> during multiple sequential updates (some of which may fail or time out with
> hooks pending), you need to filter the events to only consider those with a
> timestamp newer than the transition of the stack to the update IN_PROGRESS.
> 
> AFAICT there's two options:
> 
> 1. Update the stack.Stack so we store "now" at every transition (e.g in
> state_set)
> 
> 2. Stop trying to explicitly control updated_at, and just allow the oslo
> TimestampMixin to do it's job and update updated_at every time the DB model
> is updated.
> 
> What are peoples thoughts?  Either will solve my problem, but I'm leaning
> towards (2) as the cleanest and most technically correct solution.
> 
> Similar problems exist for resource.Resource AFAICT.
> 
> 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


__
OpenStack Development Mailing 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] [release] keystonemiddleware 1.5.1

[Morgan Fainberg]

The Keystone development team is happy to announce the 1.5.1 release of
keystonemiddleware. Barring any last minute bugs, this release will be the
keystonemiddleware release that coincides with the Kilo release of
OpenStack.

This release can be installed from the following locations:
* http://tarballs.openstack.org/
keystonemiddleware
* https://pypi.python.org/pypi/
keystonemiddleware

Detailed changes in this release:
https://launchpad.net/keystonemiddleware/+milestone/1.5.1
__
OpenStack Development Mailing 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] [release] python-keystoneclient 1.3.1

[Morgan Fainberg]

The Keystone development team is happy to announce the 1.3.1 release of
python-keystoneclient. Barring any last minute bugs, this release will be
the keystoneclient release that coincides with the Kilo release of
OpenStack.

This release can be installed from the following locations:
* http://tarballs.openstack.org/python-keystoneclient
* https://pypi.python.org/pypi/python-keystoneclient

Detailed changes in this release:
https://launchpad.net/python-keystoneclient/+milestone/1.3.1
__
OpenStack Development Mailing 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] Question for the TC candidates

[Chris Dent]

On Mon, 27 Apr 2015, Doug Hellmann wrote:


For outgoing communication, during Kilo (and possibly Juno) we tried
blogging meeting summaries. Did folks notice? Were the posts useful?


Is there a TC specific blog place of interest? I sometimes stumble
on blog postings from people I know are TC people but I'm not sure if
they are speaking in-their-position-as. And there is the governance
category on the "The OpenStack Blog" with subjects that begin
"OpenStack Technical Committee Update:", but the last one of those
that I can find is from February, so I assume you must mean
somewhere else?

Where do you mean?

The only way I've been able to get any sense of what the TC might be
up to is by watching the governance project on gerrit and that tends
to be too soon and insufficiently summarized and thus a fair bit of
work to separate the details from the destinations.

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

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

[openstack-dev] [heat] Kubernetes AutoScaling with Heat AutoScalingGroup and Ceilometer

[Rabi Mishra]

Hi All,

Deploying Kubernetes(k8s) cluster on any OpenStack based cloud for container 
based workload is a standard deployment pattern. However, auto-scaling this 
cluster based on load would require some integration between k8s OpenStack 
components. While looking at the option of leveraging Heat ASG to achieve 
autoscaling, I came across few requirements that the list can discuss and 
arrive at the best possible solution.

A typical k8s deployment scenario on OpenStack would be as below.

- Master (single VM)
- Minions/Nodes (AutoScalingGroup)

AutoScaling of the cluster would involve both scaling of minions/nodes and 
scaling Pods(ReplicationControllers). 

1. Scaling Nodes/Minions:

We already have utilization stats collected at the hypervisor level, as 
ceilometer compute agent polls the local libvirt daemon to acquire performance 
data for the local instances/nodes. Also, Kubelet (running on the node) 
collects the cAdvisor stats. However, cAdvisor stats are not fed back to the 
scheduler at present and scheduler uses a simple round-robin method for 
scheduling.

Req 1: We would need a way to push stats from the kubelet/cAdvisor to 
ceilometer directly or via the master(using heapster). Alarms based on these 
stats can then be used to scale up/down the ASG. 

There is an existing blueprint[1] for an inspector implementation for docker 
hypervisor(nova-docker). However, we would probably require an agent running on 
the nodes or master and send the cAdvisor or heapster stats to ceilometer. I've 
seen some discussions on possibility of leveraging keystone trusts with 
ceilometer client. 

Req 2: Autoscaling Group is expected to notify the master that a new node has 
been added/removed. Before removing a node the master/scheduler has to mark 
node as 
unschedulable. 

Req 3: Notify containers/pods that the node would be removed for them to stop 
accepting any traffic, persist data. It would also require a cooldown period 
before the node removal. 

Both requirement 2 and 3 would probably require generating scaling event 
notifications/signals for master and containers to consume and probably some 
ASG lifecycle hooks.  


Req 4: In case of too many 'pending' pods to be scheduled, scheduler would 
signal ASG to scale up. This is similar to Req 1. 
 

2. Scaling Pods

Currently manual scaling of pods is possible by resizing 
ReplicationControllers. k8s community is working on an abstraction, 
AutoScaler[2] on top of ReplicationController(RC) that provides intention/rule 
based autoscaling. There would be a requirement to collect cAdvisor/Heapster 
stats to signal the AutoScaler too. Probably this is beyond the scope of 
OpenStack.

Any thoughts and ideas on how to realize this use-case would be appreciated.


[1] 
https://review.openstack.org/gitweb?p=openstack%2Fceilometer-specs.git;a=commitdiff;h=6ea7026b754563e18014a32e16ad954c86bd8d6b
[2] 
https://github.com/GoogleCloudPlatform/kubernetes/blob/master/docs/proposals/autoscaling.md

Regards,
Rabi Mishra


__
OpenStack Development Mailing 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] Bump the RPC version required for port_update - AgentNotifierApi

[Russell Bryant]

On 04/27/2015 12:09 PM, Rossella Sblendido wrote:
> Hello all,
> 
> I am working at the blueprint "Restructure the L2 agent" [1] .
> One of the work item of this blueprint is to modify the port_update
> message to include the attributes of the ports that were modified. This
> is implemented in this patch [2] .
> 
> The client side of the RPC is in AgentNotifierApi , the server side is
> implemented in the L2 agent. A problem arises since now the vendor
> plugins are out of the tree. If they use a custom L2 agent (like for
> example the Ryu plugin) when the patch is merged they will get an
> UnsupportedVersion error if the version is not bumped in their agent too.
> 
> I am writing this email as heads up and also to ask a question. The
> port_update signature on the server side is like this:
> 
> def port_update(self, context, **kwargs)
> 
> kwargs is used, no specific parameter is specified. If a new key is
> added like in this case, the minor version of the RPC should be bumped
> anyway? I think so.

Yes, if a new parameter is added, the minor version should be bumped.

IMO, it should just be done in Neutron and the backend repos will have
to deal with it.  Ideally there is CI in place that catches the API
change and they will adapt quickly.  That's just the reality of having
the repos split up like this.

The alternative is to implement a "version_cap" option in Neutron that
lets an administrator set a max version of messages allowed to be sent.
 Nova has a set of options like this for use during live upgrades.  The
client side has to check to see if it's allowed to send the newest
version and if not, it falls back to an older version it knows how to
send.  This adds complexity for both development and operations, so it'd
be better to avoid it unless really necessary.

-- 
Russell Bryant

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

Re: [openstack-dev] [all] Question for the TC candidates

[Ed Leafe]

On Apr 27, 2015, at 9:20 AM, Jay Pipes  wrote:

> = Have a monthly "Feedback from Operators" conversation =
> 
> Dedicate part or all of one TC IRC meeting time per month to discuss operator 
> feedback. Invite the operator community to come and tell us what has 
> improved, what needs improving, and how the TC can find advocates in the 
> contributor community to sponsor bugs and blueprints that operators need 
> worked on.

+1!

-- Ed Leafe







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] [puppet] Moving forward with puppet-keystone CI (beaker tests)

[Martin Mágr]

On 04/22/2015 08:03 PM, Emilien Macchi wrote:

* shell testing: yes because it's the way we wrote our providers.
We don't necessary need to shell out, but instead implement resources 
for Serverspec which will use openstackclient to test Keystone/Nova/... 
resources. I'm currently in process of merging Serverspec tests I made 
and will submit patches as soon as I will have something working. What I 
have currently is just Serverspec resource for testing INI file content, 
but openstackclient Serverspec resources are next on my TODO list.


Regards,
Martin

--

Martin Mágr

IRC nick: mmagr / para
Freenode channels: #openstack-dev, #packstack-dev, #puppet-openstack, #rdo, 
#rdo-puppet


__
OpenStack Development Mailing 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] Bump the RPC version required for port_update - AgentNotifierApi

[Rossella Sblendido]

Hello all,

I am working at the blueprint "Restructure the L2 agent" [1] .
One of the work item of this blueprint is to modify the port_update
message to include the attributes of the ports that were modified. This
is implemented in this patch [2] .

The client side of the RPC is in AgentNotifierApi , the server side is
implemented in the L2 agent. A problem arises since now the vendor
plugins are out of the tree. If they use a custom L2 agent (like for
example the Ryu plugin) when the patch is merged they will get an
UnsupportedVersion error if the version is not bumped in their agent too.

I am writing this email as heads up and also to ask a question. The
port_update signature on the server side is like this:

def port_update(self, context, **kwargs)

kwargs is used, no specific parameter is specified. If a new key is
added like in this case, the minor version of the RPC should be bumped
anyway? I think so.

cheers,

Rossella

[1] https://blueprints.launchpad.net/neutron/+spec/restructure-l2-agent
[2] https://review.openstack.org/#/c/155223

__
OpenStack Development Mailing 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] [heat] Stack/Resource updated_at conventions

[Steven Hardy]

Hi all,

I've been looking into $subject recently, I raised this bug:

https://bugs.launchpad.net/heat/+bug/1448155

Basically we've got some historically weird and potentially inconsistent
behavior around updated_at, and I'm trying to figure out the best way to
proceed.

Now, we selectively update updated_at only on the transition to
UPDATE_COMPLETE, where we store the time that we moved into
UPDATE_IN_PROGRESS.  During the update, there's no way to derive the
time we started the update.

Also, we inconsistently store the time associated with the transition into
IN_PROGRESS for suspend, resume, snapshot, restore and check actions (even
though many of these don't modify the stack definition).

The reason I need this is the hook/breakpoint API - the only way to detect
if you've hit a breakpoint is via events, and to detect you've hit a hook
during multiple sequential updates (some of which may fail or time out with
hooks pending), you need to filter the events to only consider those with a
timestamp newer than the transition of the stack to the update IN_PROGRESS.

AFAICT there's two options:

1. Update the stack.Stack so we store "now" at every transition (e.g in
state_set)

2. Stop trying to explicitly control updated_at, and just allow the oslo
TimestampMixin to do it's job and update updated_at every time the DB model
is updated.

What are peoples thoughts?  Either will solve my problem, but I'm leaning
towards (2) as the cleanest and most technically correct solution.

Similar problems exist for resource.Resource AFAICT.

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] KVM Forum 2015 Call for Participation

[Daniel P. Berrange]

A friendly reminder that KVM Forum 2015 accepts proposal submissions
until this coming Friday.

Thanks on behalf of the KVM Forum 2015 Program Committee.

Daniel

On Wed, Mar 18, 2015 at 09:51:31AM +, Daniel P. Berrange wrote:
> =
> KVM Forum 2015: Call For Participation
> August 19-21, 2015 - Sheraton Seattle - Seattle, WA
> 
> (All submissions must be received before midnight May 1, 2015)
> =
> 
> KVM is an industry leading open source hypervisor that provides an ideal
> platform for datacenter virtualization, virtual desktop infrastructure,
> and cloud computing.  Once again, it's time to bring together the
> community of developers and users that define the KVM ecosystem for
> our annual technical conference.  We will discuss the current state of
> affairs and plan for the future of KVM, its surrounding infrastructure,
> and management tools.  Mark your calendar and join us in advancing KVM.
> http://events.linuxfoundation.org/events/kvm-forum/
> 
> This year, the KVM Forum is moving back to North America.  We will be
> colocated with the Linux Foundation's LinuxCon North America, CloudOpen
> North America, ContainerCon and Linux Plumbers Conference events.
> Attendees of KVM Forum will also be able to attend a shared hackathon
> event with Xen Project Developer Summit on August 18, 2015.
> 
> We invite you to lead part of the discussion by submitting a speaking
> proposal for KVM Forum 2015.
> http://events.linuxfoundation.org/cfp
> 
> 
> Suggested topics:
> 
> KVM/Kernel
> * Scaling and optimizations
> * Nested virtualization
> * Linux kernel performance improvements
> * Resource management (CPU, I/O, memory)
> * Hardening and security
> * VFIO: SR-IOV, GPU, platform device assignment
> * Architecture ports
> 
> QEMU
> 
> * Management interfaces: QOM and QMP
> * New devices, new boards, new architectures
> * Scaling and optimizations
> * Desktop virtualization and SPICE
> * Virtual GPU
> * virtio and vhost, including non-Linux or non-virtualized uses
> * Hardening and security
> * New storage features
> * Live migration and fault tolerance
> * High availability and continuous backup
> * Real-time guest support
> * Emulation and TCG
> * Firmware: ACPI, UEFI, coreboot, u-Boot, etc.
> * Testing
> 
> Management and infrastructure
> 
> * Managing KVM: Libvirt, OpenStack, oVirt, etc.
> * Storage: glusterfs, Ceph, etc.
> * Software defined networking: Open vSwitch, OpenDaylight, etc.
> * Network Function Virtualization
> * Security
> * Provisioning
> * Performance tuning
> 
> 
> ===
> SUBMITTING YOUR PROPOSAL
> ===
> Abstracts due: May 1, 2015
> 
> Please submit a short abstract (~150 words) describing your presentation
> proposal.  Slots vary in length up to 45 minutes.  Also include in your
> proposal
> the proposal type -- one of:
> - technical talk
> - end-user talk
> 
> Submit your proposal here:
> http://events.linuxfoundation.org/cfp
> Please only use the categories "presentation" and "panel discussion"
> 
> You will receive a notification whether or not your presentation proposal
> was accepted by May 29, 2015.
> 
> Speakers will receive a complimentary pass for the event.  In the instance
> that your submission has multiple presenters, only the primary speaker for a
> proposal will receive a complementary event pass.  For panel
> discussions, all
> panelists will receive a complimentary event pass.
> 
> TECHNICAL TALKS
> 
> A good technical talk should not just report on what has happened over
> the last year; it should present a concrete problem and how it impacts
> the user and/or developer community.  Whenever applicable, focus on
> work that needs to be done, difficulties that haven't yet been solved,
> and on decisions that other developers should be aware of.  Summarizing
> recent developments is okay but it should not be more than a small
> portion of the overall talk.
> 
> END-USER TALKS
> 
> One of the big challenges as developers is to know what, where and how
> people actually use our software.  We will reserve a few slots for end
> users talking about their deployment challenges and achievements.
> 
> If you are using KVM in production you are encouraged submit a speaking
> proposal.  Simply mark it as an end-user talk.  As an end user, this is a
> unique opportunity to get your input to developers.
> 
> HANDS-ON / BOF SESSIONS
> 
> We will reserve some time for people to get together and discuss
> strategic decisions as well as other topics that are best solved within
> smaller groups.
> 
> These sessions will be announced during the event.  If you are interested
> in organizing such a session, please add it to the list at
> 
>http://www.linux-kvm.org/page/KVM_Forum_2015_BOF
> 
> Let people you think might be interested know about it, and encourage
> them to add their names to the wiki page as well.  Please try to
> add your ide

[openstack-dev] [release] python-ceilometerclient 1.0.14

[gordon chung]

We are jazzed to announce the (KIlo) release of:

python-ceilometerclient 1.0.14: OpenStack Telemetry API Client Library

For more details, please see the git log history below and:

    https://launchpad.net/python-ceilometerclient/+milestone/1.0.14

Please report issues through launchpad:

    https://bugs.launchpad.net/python-ceilometerclient

Changes in python-ceilometerclient 1.0.13..1.0.14
-

651350f support specify user-id when create sample and alarm
94a6317 add in missing options
801f4b3 Add timeout for keystoneclient session
e1439f5 add region_name to auth plugin parameters
7d7e4b8 ceilometerclient insecure argument no longer works
5a3697d fix client docstring
2f238c6 Set auth_plugin in __init__
95c631b update README.rst to help release process
ca1316f ceilometerclient fails with keystone v3 auth
f2b4473 Fixes bug with Client function not setting up SSL params
09bcf5c Support unicode for alarm
40d7913 Enable specified project_id in CLI commands
98a33de Updated from global requirements
acaad55 alarm: Use new gnocchi aggregation API
1c485dd update defaultbranch

Diffstat (except docs and test files)
-

.gitreview                              |   2 +
README.rst                              |  16 +++-
ceilometerclient/client.py              |  80 ++
ceilometerclient/common/utils.py        |   4 +-
ceilometerclient/shell.py               |   4 +-
ceilometerclient/v2/shell.py            | 144 +++-
requirements.txt                        |  12 +--
test-requirements.txt                   |   2 +-
14 files changed, 320 insertions(+), 87 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index bfafab6..22d73a6 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -7,3 +7,3 @@ iso8601>=0.1.9
-oslo.i18n>=1.3.0  # Apache-2.0
-oslo.serialization>=1.2.0               # Apache-2.0
-oslo.utils>=1.2.0                       # Apache-2.0
+oslo.i18n>=1.5.0,<1.6.0  # Apache-2.0
+oslo.serialization>=1.4.0,<1.5.0               # Apache-2.0
+oslo.utils>=1.4.0,<1.5.0                       # Apache-2.0
@@ -11 +11 @@ PrettyTable>=0.7,<0.8
-python-keystoneclient>=1.1.0
+python-keystoneclient>=1.1.0,<1.4.0
@@ -13,2 +13,2 @@ requests>=2.2.0,!=2.4.0
-six>=1.7.0
-stevedore>=1.1.0  # Apache-2.0
+six>=1.9.0
+stevedore>=1.3.0,<1.4.0  # Apache-2.0
diff --git a/test-requirements.txt b/test-requirements.txt
index 6dffed5..882cebb 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -10 +10 @@ mock>=1.0
-oslosphinx>=2.2.0  # Apache-2.0
+oslosphinx>=2.5.0,<2.6.0  # Apache-2.0


cheers,
gord
  
__
OpenStack Development Mailing 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] [glance] Call to action, revisit CIS state

[Kuvaja, Erno]

Thanks for your response Kamil,

I think the first lesson learnt (again) is when there is >=1 non-native 
speakers involved make sure you understand the message as it's meant to, not as 
it has been written or you apprehend it. I'm happy I did not write what I had 
in my mind at Thu night or Fri morning but slept over the weekend as that 0 to 
v1 happened in no time.

All when revisiting the topic, please leave the edge off and lets ensure we 
have great Kilo release as intended. Still it's not too late to test the RC and 
make sure we don't have anything that needs panic fixing before final.


-  Erno

From: Rykowski, Kamil [mailto:kamil.rykow...@intel.com]
Sent: 27 April 2015 13:10
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [glance] Call to action, revisit CIS state

Hi,

I'm responsible for the spec for supporting CIS in the glanceclient, as well as 
the comments which brought some fuss, so would like to clarify some things.


1)  That's right - following scenario hasn't been included at the `Security 
Impact` section. That's because there is no real security impact here and I 
probably should rephrase the sentence to better match the current 
implementation status of the CIS. The user which is using the CIS API is not 
able to read/write any data from the cluster except from images and metadefs. 
He can't just ask for any resource type stored there and expect the results. 
Here is the quote from the spec comments:

"""Right now any access to resources stored outside of index name `glance` and 
document type `image` and `metadef` is forbidden by CIS. User is only allowed 
to play with documents which are registered within CIS."""

Additionally there is an RBAC implemented, but it has been well described in 
the original spec, so I won't repeat it here.

2)   """Would like to also address your concern that proposed shape of spec 
allows user to upload arbitrary documents to Elasticsearch (ES is the engine 
used under the hood, we should rather talk about uploading documents to CIS 
service) which are not related to Glance in any way (images & metadefs in 
current implementation).""" - The meaning of this sentence is (should be) not 
that storing arbitrary documents at CIS is not an issue of Glance. It says 
about uploading documents outside of the Glance mission (that's what I meant by 
"not related to Glance") which is prohibited by the CIS.

I would like to make it clear once more - the CIS doesn't allow the API 
consumer to operate on any data except Glance images and metadefinitions. CIS 
is not just exposing "raw" Elasticsearch capabilities, but it provides strict 
boundaries - using policy checks, RBAC and namespace protection (index/type in 
the Elasticsearch world) of what can be stored within it and what can be 
retrieved from it.

From: Kuvaja, Erno [mailto:kuv...@hp.com]
Sent: Monday, April 27, 2015 12:39 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [glance] Call to action, revisit CIS state

Hi all,

As you probably know CIS was expanded from Juno metadefs work this cycle based 
on spec [1] provided. The implementation was merged in quite a rush just before 
feature freeze.

During the spec review [2] for client functionality for CIS it came to our 
attention that the implementation exposes Elasticsearch perhaps too openly via 
it's API (namely the creation of datasets allows API consumer uploading 
arbitrary files via the create request).

Call to action: Please review the CIS functionality again for security threats 
and bring them up so we can form a plan if we need to address those and request 
RC3 before release.

I have couple of major concerns about this workflow:

1)  I was shocked after reading following statement from the client spec 
review discussion: """During the Kilo release, we - by we I mean the team 
responsible for implementing the CIS - have discussed such scenario, that 
exposing Elasticsearch capabilities to the user consuming the CIS API can bring 
some serious security impact.""" This discussion nor the scenario was never 
brought to attention of the wider Glance community. The spec bluntly states 
that there is no security impact from the implementation and the concerns 
should have been brought up so reviewers would have had better chance to catch 
possible threats.

2)  """Would like to also address your concern that proposed shape of spec 
allows user to upload arbitrary documents to Elasticsearch (ES is the engine 
used under the hood, we should rather talk about uploading documents to CIS 
service) which are not related to Glance in any way (images & metadefs in 
current implementation).""" """Personally I don't think that discussion about 
IF is a valid topic, because we've already implemented backend for CIS at the 
Glance side and you cannot say A without saying B.""" As long as the code is 
developed under the Glance project and reviewed 

Re: [openstack-dev] [Zaqar] Call for adoption (or exclusion?)

[Flavio Percoco]

On 24/04/15 09:32 +1200, Fei Long Wang wrote:



On 24/04/15 06:02, Richard Raseley wrote:

Flavio Percoco wrote:

I think getting operators to adopt it is key to getting other openstack
projects to also adopt it. There is something of a chicken and the egg
problem
with the integration. Some of the projects you will want to integrate
the most
with are already considered pretty stable and may not want to rewrite
working
bits to target a service thats hard for ops to deploy. It makes their
service
hard to deploy too.

Getting into RDO and Ubuntu will go a long way there. Getting into
Packstack
and other deployment tools even further.


I don't fully agree with the above. The problem on waiting for
operators to adopt it is that they might actually not have a reason to
do it, which doesn't mean the project is useless. Each operator will
decide what services they want to provide.


The needs of operators are a reflection of the needs of their users.

I don't want to use the word 'useless', because it has a clear
negative connotation - and I don't think Zaqar is 'useless'. Let's
instead discuss 'utility'.

The utility of any solution or product is completely subjective, and
solely based upon the underlying requirements. If real operators with
real requirements do not view a particular solution as having utility
for them - then it doesn't.

You are correct in that there is a bit of a bootstrapping problem, but
I strongly feel like the answer to that is continuing to listen to,
and test against, the market (the architects and operators).

Build a minimally viable product that (a) has clear messaging and use
cases (b) is easy to deploy and configure and (c) doesn't demand deep
integration into an existing cloud and operators will start deploying,
testing, and providing feedback. This will create the right feedback
cycle and help in validating (or completely demolishing) assumptions
on what users actually need.

With regard to '(b)' above, it doesn't appear that there any any
Puppet modules to assist with the installation and configuration of
Zaqar. If you're interested, let's chat in Vancouver to see if I can
help in get a basic set out there.


Awesome, thank you for the support. I believe the puppet work is one of
our goals in Liberty, so please pop in #openstack-zaqar and let's have a
talk.


I'm very interested in chatting in Vancouver. FWIW, we do have partial
support for puppet. It's partial because, well, it's not complete yet.
I started it with basically now knowledge of how puppet manifest's
work and Jason took it over and started contributing to it.
Unfortunately, it's not done yet.

https://github.com/jasontclark/puppet-zaqar

Thanks for the feedback,
Flavio


Regards,

Richard Raseley

SysOps Engineer
Puppet Labs

__

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


--
Cheers & Best regards,
Fei Long Wang (王飞龙)
--
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
--


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


--
@flaper87
Flavio Percoco


pgpb4eZjytsQU.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] [all] Question for the TC candidates

[Jay Pipes]

Chris, apologies for the late reply. No real excuse other than I wanted 
to hear what the other candidates had to say and listen a bit before I 
responded.


On 04/23/2015 12:14 PM, Chris Dent wrote:

Here's the question:

What can and should the TC at large, and you specifically, do to ensure
quality improves for the developers, end-users and operators of
OpenStack as a full system, both as a project being developed and a
product being used?


Broad question :)

I think there's a couple things we (the TC) could do to improve the 
quality of OpenStack for developers:


= Focus on the public APIs =

No surprise here, but I'm a bit proponent of improving the consistency, 
usability, and documentation of our public APIs. I say "public APIs" 
because while I love the fact that the API working group has thus far 
focused on the RESTful APIs, I also think we should put some focus on 
non-RESTful APIs, like our notification message format, our RPC APIs 
(not currently public, but perhaps should be especially when things like 
the Nova scheduler are fully broken out).


The REST APIs are the first impression our community makes to our 
developer community. It should be a good impression. The guidance of the 
API working group should continue, and I think that we should also begin 
to produce recommendations for cleaning up the *existing* APIs of the 
OpenStack projects.


= Start a working group for building applications on top of OpenStack =

We have the "Win the Enterprise" working group. IMHO, we would do well 
to have a "Win the Future" working group that focuses on *modern* cloud 
application architecture and needs, and not legacy stuff.


Such a working group would be responsible for building a modern, 
distributed application reference that would use the various OpenStack 
APIs for infrastructure and platform management. It would showcase what 
can be done with and on OpenStack deployments.


And for operators of OpenStack, here's a couple ideas on things the TC 
could do to improve the quality of OpenStack for our operator community:


= Have a monthly "Feedback from Operators" conversation =

Dedicate part or all of one TC IRC meeting time per month to discuss 
operator feedback. Invite the operator community to come and tell us 
what has improved, what needs improving, and how the TC can find 
advocates in the contributor community to sponsor bugs and blueprints 
that operators need worked on.


= Develop a set of "operator:XXX" tags =

One big idea in the big tent initiative is to have more fine-grained 
tags that describe useful information to specific audiences. The TC can 
have a process (survey?) that gathers operator feedback on specific tags 
as they are applied to particular projects. For instance, we might work 
with the operator community to come up with a definition of a 
"operator:scales-to-100-nodes" (totally random example) that would apply 
to projects that the operator community verifies work at that particular 
scale. Have the operator community vote on whether various projects in 
the OpenStack code namespace have been deployed at that particular scale 
by the operator.


Anyway, those a just a few ideas. I'm looking forward to listening to 
new ideas from the newly elected TC members (regardless of whether I'm 
given the opportunity to be one of them ;)


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

Re: [openstack-dev] [all] Question for the TC candidates

[Flavio Percoco]

On 27/04/15 08:46 -0400, Doug Hellmann wrote:

Excerpts from Flavio Percoco's message of 2015-04-27 08:52:01 +0200:

On 23/04/15 17:14 +0100, Chris Dent wrote:
>
>This might be a bit presumptuous, but why not give it a try...
>
>This cycle's TC elections didn't come with a set of prepackaged
>questions and though the self-nomination messages have included some
>very interesting stuff I think it would be useful to get answers
>from the candidates on at least one topical but open-ended
>question. Maybe other people have additional questions they think
>are important but this one is the one that matters to me and also
>captures the role that I wish the TC filled more strongly. Here's
>the preamble:
>
>There are lots of different ways to categorize the various
>stakeholders in the OpenStack community, no list is complete. For
>the sake of this question the people I'm concerned with are the
>developers, end-users and operators of OpenStack: the individuals
>who are actively involved with it on a daily basis. I'm intentionally
>leaving out things like "the downstream".
>
>There are many different ways to define "quality". For the sake of
>this question feel free to use whatever definition you like but take
>it as given that "quality" needs to be improved.
>
>Here's the question:
>
>What can and should the TC at large, and you specifically, do to ensure
>quality improves for the developers, end-users and operators of
>OpenStack as a full system, both as a project being developed and a
>product being used?

Thanks for bringing this up, Chris.

First and foremost, sorry for my late answer. I just got back from a
trip w/ limited internet access.

With the latest changes in governance model, I believe we need to be
very observant of the changes happening in our community. As I
mentioned in my candidacy, new projects will start showing up and
they'll want to join the OpenStack organization. While this is
amazing, we need to have a "scalable" - yes, hard to do - way to guide
those projects whenever it's needed.

Therefore, I believe one thing we need to do is improve the
communication between the TC and the commuity. I've heard a couple of
times from members in our that it's sometimes hard to communicate with
the TC and most of the times, it's not clear for them when certain
topics should/shouldn't involve the TC. This, to me, is cause by a
lack of communication between the TC and the community. Either we're
failing to explain what the TC is there for or the communication
channels between the TC and the rest of the community are not good
enough.


I often say that most issues, even apparently technical issues, are
caused by bad communication.  So, I'm concerned that there are
members of the community who don't know how to communicate with the
TC. The best way to reach the entire committee is to email this
list (openstack-dev) using "[tc]" in the subject line of your
message.

Regarding subjects where the TC should or should not be involved, I
think the safest thing to do is ask. We would at least at that point
help clarify who should be resolving a particular issue if we think it
isn't the TC.


This is exactly what concerns me and I think it's not clear to the
overall community. By improving this communication, we will also help
improving projects, the overall community and the developer's
experience.



For outgoing communication, during Kilo (and possibly Juno) we tried
blogging meeting summaries. Did folks notice? Were the posts useful?


I noticed and they were useful for me. Did others notice?

Flavio

--
@flaper87
Flavio Percoco


pgppRJp763HdY.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] [neutron] Need guidance - functional tests and rootwrap

[Paul Michali]

I just checked with another run and the log shows that the vpnaas.filters
file is indeed in the .tox area. So, still stumped as to why the rootwrap
daemon is looking for the config file in /etc/neutron/rootwrap.d/

Any ideas?

PCM


On Mon, Apr 27, 2015 at 7:21 AM Paul Michali  wrote:

> The latter. If you look at Jenkins results for 168115, it shows that there
> is an invalid config file at /etc/neutron/rootwrap.conf. However, it should
> be accessing
> /opt/stack/new/neutron-vpnaas/.tox/dsvm-functional-sswan/etc/neutron/rootwrap.conf.
>
> The deploy_rootwrap.sh call in tox.ini should place the files in the .tox
> area (it does locally), and the OS_ROOTWRAP_CMD (and
> OS_ROOTWRAP_DAEMON_CMD) are set to these areas as well. It just seems that
> the rootwrap daemon is not using the right file.
>
> In the latest run, I dumped out environment variables, which show this:
>
> 2015-04-24 15:19:15.499 
> 
>  | 2015-04-24 15:19:15.466 | OS_ROOTWRAP_DAEMON_CMD=sudo 
> /opt/stack/new/neutron-vpnaas/.tox/dsvm-functional-sswan/bin/neutron-rootwrap-daemon
>  
> /opt/stack/new/neutron-vpnaas/.tox/dsvm-functional-sswan/etc/neutron/rootwrap.conf2015-04-24
>  15:19:15.499 
> 
>  | 2015-04-24 15:19:15.467 | OS_SUDO_TESTING=12015-04-24 15:19:15.499 
> 
>  | 2015-04-24 15:19:15.469 | OS_ROOTWRAP_CMD=sudo 
> /opt/stack/new/neutron-vpnaas/.tox/dsvm-functional-sswan/bin/neutron-rootwrap 
> /opt/stack/new/neutron-vpnaas/.tox/dsvm-functional-sswan/etc/neutron/rootwrap.conf
>
>
> I have added a test case in the module that is failing that shows the
> value of cfg.CONF.AGENT.root_helper_daemon. It shows:
>
> sudo
> /opt/stack/new/neutron-vpnaas/.tox/dsvm-functional-sswan/bin/neutron-rootwrap-daemon
> /opt/stack/new/neutron-vpnaas/.tox/dsvm-functional-sswan/etc/neutron/rootwrap.conf
>
> Is that correct?
>
> When the test cases run, there is this error:
>
> 2015-04-24 15:19:18.536 
> 
>  | 2015-04-24 15:19:18.486 | 2015-04-24 15:19:17.986 31628 INFO 
> oslo_rootwrap.client [-] Spawned new rootwrap daemon process with 
> pid=316672015-04-24 15:19:18.536 
> 
>  | 2015-04-24 15:19:18.487 | 2015-04-24 15:19:18.470 31628 ERROR 
> neutron.agent.linux.utils [-] 2015-04-24 15:19:18.536 
> 
>  | 2015-04-24 15:19:18.489 | Command: ['neutron-vpn-netns-wrapper', 
> '--mount_paths=/etc:/var/lib/neutron/vpnaas/func-8f1b728c-6eca-4042-9b6b-6ef66ab9352a/etc,/var/run:/var/lib/neutron/vpnaas/func-8f1b728c-6eca-4042-9b6b-6ef66ab9352a/var/run',
>  '--cmd=nofiltercommand']2015-04-24 15:19:18.537 
> 
>  | 2015-04-24 15:19:18.490 | Exit code: 222015-04-24 15:19:18.537 
> 
>  | 2015-04-24 15:19:18.492 | Stdin: 2015-04-24 15:19:18.537 
> 
>  | 2015-04-24 15:19:18.493 | Stdout: 2015-04-24 15:19:18.537 
> 
>  | 2015-04-24 15:19:18.495 | Stderr: 2015-04-24 15:19:18.456 31727 ERROR 
> neutron_vpnaas.services.vpn.common.netns_wrapper [-] Incorrect configuration 
> file: /etc/neutron/rootwrap.conf
>
> Now, there is a vpnaas.filters file that I copy into the rootwrap.d area, 
> using this command in the tox.ini:
>
> cp {toxinidir}/etc/neutron/rootwrap.d/vpnaas.filters 
> {envdir}/etc/neutron/rootwrap.d/
>
> The file has the neutorn-vpn-netns-wrapper entry in it. Maybe the copy is 
> failing?
>
> Regards,
>
> PCM
>
>
> On Sun, Apr 26, 2015 at 9:39 PM Angus Lees  wrote:
>
>> The tox.ini entry for dsvm-fullstack sets OS_ROOTWRAP_CMD=sudo
>> {envbindir}/neutron-rootwrap {envdir}/etc/neutron/rootwrap.conf (and
>> something similar for rootwrap-daemon).
>>
>> Is this the answer you were looking for, or are you saying
>> OS_ROOTWRAP_CMD doesn't appear to be honoured in your case?
>>
>>  - Gus

Re: [openstack-dev] [oslo] eventlet 0.17.3 is now fully Python 3 compatible

[Victor Stinner]

Hi,

> Keystone client version of the middleware is deprecated and only receiving 
> minimal security updates. This code is unlikely to see any real changes due 
> it its deprecation and frozen state.
>
> We are evaluating how to remove it from the client lib. 

I wrote a patch to remove keystoneclient.middleware:

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

We may discuss the removal there. Are you aware of an application still relying 
on keystoneclient.middleware.

Victor

__
OpenStack Development Mailing 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] Policy rules are killed by the context admin check

[Sylvain Bauza]

Le 23/04/2015 09:10, Sylvain Bauza a écrit :



Le 23 avr. 2015 04:49, "Alex Xu" > a écrit :

>
>
>
> 2015-04-23 6:55 GMT+08:00 Matt Riedemann >:

>>
>>
>>
>> On 4/22/2015 8:32 AM, Sylvain Bauza wrote:
>>>
>>> Hi,
>>>
>>> By discussing on a specific bug [1], I just discovered that the admin
>>> context check which was done at the DB level has been moved to the API
>>> level thanks to the api-policy-v3 blueprint [2]
>>>
>>> That behaviour still leads to a bug if the operator wants to change an
>>> endpoint policy by leaving it end-user but still continues to be 
denied

>>> because of that, as it will forbid any non-admin user to call the
>>> methods (even if authorize() grants the request)
>>>
>>> I consequently opened a bug [3] for this but I'm also concerned about
>>> the backportability of that and why it shouldn't fixed in v2.0 too.
>>>
>>> Releasing the check by removing it sounds an acceptable change, as it
>>> fixes a bug without changing the expected behaviour [4]. The impact of
>>> the change sounds also minimal with a very precise scope (ie. 
leave the

>>> policy rules work as they are expected) [5]
>>>
>>> Folks, thoughts ?
>>>
>>> -Sylvain
>>>
>>> [1] https://bugs.launchpad.net/nova/+bug/1447084
>>> [2]
>>> 
https://review.openstack.org/#/q/project:openstack/nova+branch:master+topic:bp/v3-api-policy,n,z

>>>
>>> [3] https://bugs.launchpad.net/nova/+bug/1447164
>>> [4]
>>> 
https://wiki.openstack.org/wiki/APIChangeGuidelines#Generally_Considered_OK

>>> "Fixing a bug so that a request which resulted in an error response
>>> before is now successful"
>>> [5] https://wiki.openstack.org/wiki/StableBranch#Stable_branch_policy
>>>
>>> 
__

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


>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>> I don't disagree, see bug 1168488 from way back in grizzly.
>>
>> The only thing would be we'd have to make sure the default rule is 
admin for any v2 extensions which are enforcing an admin context today.

>
>
> Agree, if we want to fix those for v2, we need make sure the default 
rule is admin.

>
> And do you mean [3] want to fix this for v2 both in Kilo and Liberty?
>
> For liberty, we can do that, but I think we will switch to v2.1 very 
soon. Not sure it is still worth to do that.

>
> For kilo, some of api is pretty easy to fix by just removing 
'require_admin_context()'. But there still have many of policy patches 
didn't merged into the master yet. like:
> 
https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/nova-api-policy-final-part,n,z
> 
https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/v3-api-policy,n,z
> 
https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:remove_qutoa_hardcode_permission,n,z
> 
https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:remove_quotaclass_hardcode_permission,n,z

>
> Should we back-port them all?

Wrt all the necessary backports, I'm eventually rather in favor of an 
opportunistic approach and only backport what has been reported as a 
bug, ie. [1]


That has also the benefit of not proposing a stable patch which was 
not cherry-picked (like providing an elevated context), which I 
disapprove.


-Sylvain



Just a follow-up on that, I'm proposing a change to the approved spec to 
match that discussion :

https://review.openstack.org/177764

Basically, the idea is not to backport all of the efforts, just make 
sure that default policies are admin-only for the corresponding API 
endpoints that call DB API methods which are decorated by 
require_admin_context()


-Sylvain


>
>>
>>
>> --
>>
>> 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 Development Mailing 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:unsu

Re: [openstack-dev] [cinder] cinder support matrix, chap support?

[Erlon Cruz]

Yes

On Mon, Apr 27, 2015 at 9:49 AM, Jordan Pittier 
wrote:

> Hi,
> Isn't CHAP iscsi-specific ?
>
> Jordan
>
> On Mon, Apr 27, 2015 at 2:41 PM, Dave Walker  wrote:
>
>> Hi,
>>
>> Recently I have been curious as to which Cinder drivers support
>> authentication. It seems that only a subset do.  I wondered, is this
>> something that would be useful on the CinderSupportMatrix wiki page?
>>
>> Thanks
>>
>> --
>> Kind Regards,
>> Dave Walker
>>
>> __
>> OpenStack Development Mailing 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] [cinder] cinder support matrix, chap support?

[Jordan Pittier]

Hi,
Isn't CHAP iscsi-specific ?

Jordan

On Mon, Apr 27, 2015 at 2:41 PM, Dave Walker  wrote:

> Hi,
>
> Recently I have been curious as to which Cinder drivers support
> authentication. It seems that only a subset do.  I wondered, is this
> something that would be useful on the CinderSupportMatrix wiki page?
>
> Thanks
>
> --
> Kind Regards,
> Dave Walker
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] Question for the TC candidates

[Doug Hellmann]

Excerpts from Flavio Percoco's message of 2015-04-27 08:52:01 +0200:
> On 23/04/15 17:14 +0100, Chris Dent wrote:
> >
> >This might be a bit presumptuous, but why not give it a try...
> >
> >This cycle's TC elections didn't come with a set of prepackaged
> >questions and though the self-nomination messages have included some
> >very interesting stuff I think it would be useful to get answers
> >from the candidates on at least one topical but open-ended
> >question. Maybe other people have additional questions they think
> >are important but this one is the one that matters to me and also
> >captures the role that I wish the TC filled more strongly. Here's
> >the preamble:
> >
> >There are lots of different ways to categorize the various
> >stakeholders in the OpenStack community, no list is complete. For
> >the sake of this question the people I'm concerned with are the
> >developers, end-users and operators of OpenStack: the individuals
> >who are actively involved with it on a daily basis. I'm intentionally
> >leaving out things like "the downstream".
> >
> >There are many different ways to define "quality". For the sake of
> >this question feel free to use whatever definition you like but take
> >it as given that "quality" needs to be improved.
> >
> >Here's the question:
> >
> >What can and should the TC at large, and you specifically, do to ensure
> >quality improves for the developers, end-users and operators of
> >OpenStack as a full system, both as a project being developed and a
> >product being used?
> 
> Thanks for bringing this up, Chris.
> 
> First and foremost, sorry for my late answer. I just got back from a
> trip w/ limited internet access.
> 
> With the latest changes in governance model, I believe we need to be
> very observant of the changes happening in our community. As I
> mentioned in my candidacy, new projects will start showing up and
> they'll want to join the OpenStack organization. While this is
> amazing, we need to have a "scalable" - yes, hard to do - way to guide
> those projects whenever it's needed.
> 
> Therefore, I believe one thing we need to do is improve the
> communication between the TC and the commuity. I've heard a couple of
> times from members in our that it's sometimes hard to communicate with
> the TC and most of the times, it's not clear for them when certain
> topics should/shouldn't involve the TC. This, to me, is cause by a
> lack of communication between the TC and the community. Either we're
> failing to explain what the TC is there for or the communication
> channels between the TC and the rest of the community are not good
> enough.

I often say that most issues, even apparently technical issues, are
caused by bad communication.  So, I'm concerned that there are
members of the community who don't know how to communicate with the
TC. The best way to reach the entire committee is to email this
list (openstack-dev) using "[tc]" in the subject line of your
message.

Regarding subjects where the TC should or should not be involved, I
think the safest thing to do is ask. We would at least at that point
help clarify who should be resolving a particular issue if we think it
isn't the TC.

For outgoing communication, during Kilo (and possibly Juno) we tried
blogging meeting summaries. Did folks notice? Were the posts useful?

Doug

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

[openstack-dev] [cinder] cinder support matrix, chap support?

[Dave Walker]

Hi,

Recently I have been curious as to which Cinder drivers support
authentication. It seems that only a subset do.  I wondered, is this
something that would be useful on the CinderSupportMatrix wiki page?

Thanks

--
Kind Regards,
Dave Walker
__
OpenStack Development Mailing 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] Proposed Liberty release schedule

[Davanum Srinivas]

@ttx, +1 from me.

-- dims

On Mon, Apr 27, 2015 at 8:19 AM, Thierry Carrez  wrote:
> Thierry Carrez wrote:
>> [...]
>> In summary, here is the proposed Liberty "common" schedule:
>>
>> liberty-1: June 25th
>> liberty-2: July 30th
>> liberty-3: September 3rd
>> final release: October 15th
>>
>> Let me know if you see issues with it, like crazy holidays somewhere
>> that would ruin it.
>
> No feedback, so I'm planning to officialize it this week after the TC
> and Cross-project meeting. Speak now or forever hold your peace !
>
> --
> 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



-- 
Davanum Srinivas :: https://twitter.com/dims

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

Re: [openstack-dev] [all] Proposed Liberty release schedule

[Thierry Carrez]

Thierry Carrez wrote:
> [...]
> In summary, here is the proposed Liberty "common" schedule:
> 
> liberty-1: June 25th
> liberty-2: July 30th
> liberty-3: September 3rd
> final release: October 15th
> 
> Let me know if you see issues with it, like crazy holidays somewhere
> that would ruin it.

No feedback, so I'm planning to officialize it this week after the TC
and Cross-project meeting. Speak now or forever hold your peace !

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

Re: [openstack-dev] [glance] Call to action, revisit CIS state

[Rykowski, Kamil]

Hi,

I'm responsible for the spec for supporting CIS in the glanceclient, as well as 
the comments which brought some fuss, so would like to clarify some things.


1)  That's right - following scenario hasn't been included at the `Security 
Impact` section. That's because there is no real security impact here and I 
probably should rephrase the sentence to better match the current 
implementation status of the CIS. The user which is using the CIS API is not 
able to read/write any data from the cluster except from images and metadefs. 
He can't just ask for any resource type stored there and expect the results. 
Here is the quote from the spec comments:

"""Right now any access to resources stored outside of index name `glance` and 
document type `image` and `metadef` is forbidden by CIS. User is only allowed 
to play with documents which are registered within CIS."""

Additionally there is an RBAC implemented, but it has been well described in 
the original spec, so I won't repeat it here.

2)   """Would like to also address your concern that proposed shape of spec 
allows user to upload arbitrary documents to Elasticsearch (ES is the engine 
used under the hood, we should rather talk about uploading documents to CIS 
service) which are not related to Glance in any way (images & metadefs in 
current implementation).""" - The meaning of this sentence is (should be) not 
that storing arbitrary documents at CIS is not an issue of Glance. It says 
about uploading documents outside of the Glance mission (that's what I meant by 
"not related to Glance") which is prohibited by the CIS.

I would like to make it clear once more - the CIS doesn't allow the API 
consumer to operate on any data except Glance images and metadefinitions. CIS 
is not just exposing "raw" Elasticsearch capabilities, but it provides strict 
boundaries - using policy checks, RBAC and namespace protection (index/type in 
the Elasticsearch world) of what can be stored within it and what can be 
retrieved from it.

From: Kuvaja, Erno [mailto:kuv...@hp.com]
Sent: Monday, April 27, 2015 12:39 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [glance] Call to action, revisit CIS state

Hi all,

As you probably know CIS was expanded from Juno metadefs work this cycle based 
on spec [1] provided. The implementation was merged in quite a rush just before 
feature freeze.

During the spec review [2] for client functionality for CIS it came to our 
attention that the implementation exposes Elasticsearch perhaps too openly via 
it's API (namely the creation of datasets allows API consumer uploading 
arbitrary files via the create request).

Call to action: Please review the CIS functionality again for security threats 
and bring them up so we can form a plan if we need to address those and request 
RC3 before release.

I have couple of major concerns about this workflow:

1)  I was shocked after reading following statement from the client spec 
review discussion: """During the Kilo release, we - by we I mean the team 
responsible for implementing the CIS - have discussed such scenario, that 
exposing Elasticsearch capabilities to the user consuming the CIS API can bring 
some serious security impact.""" This discussion nor the scenario was never 
brought to attention of the wider Glance community. The spec bluntly states 
that there is no security impact from the implementation and the concerns 
should have been brought up so reviewers would have had better chance to catch 
possible threats.

2)  """Would like to also address your concern that proposed shape of spec 
allows user to upload arbitrary documents to Elasticsearch (ES is the engine 
used under the hood, we should rather talk about uploading documents to CIS 
service) which are not related to Glance in any way (images & metadefs in 
current implementation).""" """Personally I don't think that discussion about 
IF is a valid topic, because we've already implemented backend for CIS at the 
Glance side and you cannot say A without saying B.""" As long as the code is 
developed under the Glance project and reviewed by glance-core it's outrageous 
to claim that possible issues are not related to Glance in any way. Discussion 
about if the API is implemented by the spec and fits to the mission statement 
is really valid at this point and needs to be thoroughly discussed. We need to 
find the root cause of this attitude and fix it before it damages the 
relationships within the community in a way that cannot be fixed.

3)  We had two huge pieces of code merging in at the very end of the 
development cycle Artifacts and CIS and the pressure to merge them in 
(unfortunately not review but merge) was high. On the artifacts side we had 
pretty open discussion about the state, the concerns and plans of timelines 
address those concerns. With CIS we unfortunately did not have this openness. 
Was it reflection of 1 & 2 or something else, I do n

Re: [openstack-dev] [cinder] Is there any way to put the driver backend error message to the horizon

[Erlon Cruz]

Alex,

Any scratch of the solution you plan to propose?

On Mon, Apr 27, 2015 at 5:57 AM, liuxinguo  wrote:

>  Thanks for your suggestion, George. But when I looked into
> python-cinderclient (not very deep), I can not find the “wrapper around the
> python-cinderclient” you have mentioned.
>
> Could you please give me a little more hint to find the “wrapper”?
>
>
>
> Thanks,
>
> Liu
>
>
>
>
>
> *发件人:* George Peristerakis [mailto:gperi...@redhat.com]
> *发送时间:* 2015年4月13日 23:22
> *收件人:* OpenStack Development Mailing List (not for usage questions)
> *主题:* Re: [openstack-dev] [cinder] Is there any way to put the driver
> backend error message to the horizon
>
>
>
> Hi Lui,
>
> I'm not familiar with the error you are trying to show, but Here's how
> Horizon typically works. In the case of cinder, we have a wrapper around
> the python-cinderclient which if the client sends a exception with a valid
> message, by default Horizon will display the exception message. The message
> can also be overridden in the translation file. So a good start is to look
> in python-cinderclient and see if you could produce a more meaningful
> message.
>
>
> Cheers.
> George
>
> On 10/04/15 06:16 AM, liuxinguo wrote:
>
> Hi,
>
>
>
> When we create a volume in the horizon, there may occurrs some errors at the 
> driver
>
> backend, and the in horizon we just see a "error" in the volume status.
>
>
>
> So is there any way to put the error information to the horizon so users can 
> know what happened exactly just from the horizon?
>
> Thanks,
>
> Liu
>
>
>
>
>
>
>  __
>
> OpenStack Development Mailing List (not for usage questions)
>
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][Keystone] [Nova] How to validate teanant-id for admin operation

[Ajaya Agrawal]

On Mon, Apr 27, 2015 at 6:05 AM, Jamie Lennox 
 wrote:
>Not to speak for Brant, but i think the confusion here is why you are
doing this. From my perspective you should never be in >a position where
the admin has to enter a raw project id like that.

Sometimes you have to do just that. For e.g. adding a member to an image in
glance. Glance does not verify whether the member being added is a valid
project_id.

>I think the problem here is the assumption of an all powerful admin user,
and i'd encourage you to change your policy files to >scrap that idea.
If there is no powerful admin user then how do you deal with situations
where a cloud user deletes a project and there are resources(vm, network,
block, image) tied to this project across components.

Cheers,
Ajaya



>
> - Original Message -
> > From: "German Eichberger" 
> > To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> > Sent: Saturday, 25 April, 2015 8:55:23 AM
> > Subject: Re: [openstack-dev] [Neutron][Keystone] [Nova] How to validate
> teanant-id for admin operation
> >
> >
> >
> > Hi Brant,
> >
> >
> >
> > Sorry, for being confusing earlier. We have operations an
> > administrator/operator is performing on behalf of a user, e.g. “Create
> > Loadbalancer X for user tenant-id 123”. Now we are not checking the
> > tenant-id and are wondering how to make the operation more robust with
> > kesyone’s help.
> >
> >
> >
> > Thanks,
> >
> > German
>
>
>
> I think the problem here is the assumption of an all powerful admin user,
> and i'd encourage you to change your policy files to scrap that idea. A
> role is granted on a project and this project is mentioned in the token. If
> there is some role that is provided that lets you perform operations
> outside of the project id specified in that token please file a bug and i'd
> consider marking it a security issue.
>
> The X-Service-Token concept will allow for the combination of a user token
> and a service token to authenticate an action, so the user can ask for an
> action to be performed on it's behalf via a service - and in which case the
> user's project id is communicated via the token.
>
> In lieu of all this the quick answer is no. If you are taking a project id
> from the command line and you want to validate its existence then you have
> to ask keystone, but you should always be getting this information from a
> token.
>
> Jamie
>
> >
> > From: Brant Knudson [mailto:b...@acm.org]
> > Sent: Friday, April 24, 2015 11:43 AM
> > To: OpenStack Development Mailing List (not for usage questions)
> > Subject: Re: [openstack-dev] [Neutron][Keystone] [Nova] How to validate
> > teanant-id for admin operation
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > On Fri, Apr 24, 2015 at 11:53 AM, Eichberger, German <
> > german.eichber...@hp.com > wrote:
> >
> > All,
> >
> > Following up from the last Neutron meeting:
> >
> > If Neutron is performing an operation as an admin on behalf of a user
> that
> > user's tenant-id (or project-id) isn't validated - in particular an admin
> > can mistype and create object on behalf of non existent users. I am
> > wondering how other projects (e.g. Nova) deal with that and if there is
> some
> > API support in keystone to save us a round trip (e.g. authenticate admin
> +
> > validate additional user-id).
> >
> >
> >
> >
> >
> > Not to long ago we got support in the auth_token middleware for a
> "service"
> > token in addition to the user's token. The user token is sent in the
> > x-auth-token header and the service token is sent in the x-service-token,
> > and then fields from both tokens are available to the application (e.g.,
> the
> > user project is in HTTP_X_PROJECT_ID and the service token roles are in
> > HTTP_X_SERVICE_ROLES). So you could potentially have a policy rule on the
> > server for the operation that required the service token to have the
> > 'service' role, and what neutron could do is send the original user
> token in
> > x-auth-token and send its own token as the service token. This seems to
> be
> > what you're asking for here.
> >
> >
> > - Brant
> >
> >
> >
> >
> >
> >
> >
> > Thanks,
> > German
> >
> >
> __
> > OpenStack Development Mailing 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.opensta

Re: [openstack-dev] [neutron] Need guidance - functional tests and rootwrap

[Paul Michali]

The latter. If you look at Jenkins results for 168115, it shows that there
is an invalid config file at /etc/neutron/rootwrap.conf. However, it should
be accessing
/opt/stack/new/neutron-vpnaas/.tox/dsvm-functional-sswan/etc/neutron/rootwrap.conf.

The deploy_rootwrap.sh call in tox.ini should place the files in the .tox
area (it does locally), and the OS_ROOTWRAP_CMD (and
OS_ROOTWRAP_DAEMON_CMD) are set to these areas as well. It just seems that
the rootwrap daemon is not using the right file.

In the latest run, I dumped out environment variables, which show this:

2015-04-24 15:19:15.499

| 2015-04-24 15:19:15.466 | OS_ROOTWRAP_DAEMON_CMD=sudo
/opt/stack/new/neutron-vpnaas/.tox/dsvm-functional-sswan/bin/neutron-rootwrap-daemon
/opt/stack/new/neutron-vpnaas/.tox/dsvm-functional-sswan/etc/neutron/rootwrap.conf2015-04-24
15:19:15.499 

| 2015-04-24 15:19:15.467 | OS_SUDO_TESTING=12015-04-24 15:19:15.499

| 2015-04-24 15:19:15.469 | OS_ROOTWRAP_CMD=sudo
/opt/stack/new/neutron-vpnaas/.tox/dsvm-functional-sswan/bin/neutron-rootwrap
/opt/stack/new/neutron-vpnaas/.tox/dsvm-functional-sswan/etc/neutron/rootwrap.conf


I have added a test case in the module that is failing that shows the value
of cfg.CONF.AGENT.root_helper_daemon. It shows:

sudo
/opt/stack/new/neutron-vpnaas/.tox/dsvm-functional-sswan/bin/neutron-rootwrap-daemon
/opt/stack/new/neutron-vpnaas/.tox/dsvm-functional-sswan/etc/neutron/rootwrap.conf

Is that correct?

When the test cases run, there is this error:

2015-04-24 15:19:18.536

| 2015-04-24 15:19:18.486 | 2015-04-24 15:19:17.986 31628 INFO
oslo_rootwrap.client [-] Spawned new rootwrap daemon process with
pid=316672015-04-24 15:19:18.536

| 2015-04-24 15:19:18.487 | 2015-04-24 15:19:18.470 31628 ERROR
neutron.agent.linux.utils [-] 2015-04-24 15:19:18.536

| 2015-04-24 15:19:18.489 | Command: ['neutron-vpn-netns-wrapper',
'--mount_paths=/etc:/var/lib/neutron/vpnaas/func-8f1b728c-6eca-4042-9b6b-6ef66ab9352a/etc,/var/run:/var/lib/neutron/vpnaas/func-8f1b728c-6eca-4042-9b6b-6ef66ab9352a/var/run',
'--cmd=nofiltercommand']2015-04-24 15:19:18.537

| 2015-04-24 15:19:18.490 | Exit code: 222015-04-24 15:19:18.537

| 2015-04-24 15:19:18.492 | Stdin: 2015-04-24 15:19:18.537

| 2015-04-24 15:19:18.493 | Stdout: 2015-04-24 15:19:18.537

| 2015-04-24 15:19:18.495 | Stderr: 2015-04-24 15:19:18.456 31727
ERROR neutron_vpnaas.services.vpn.common.netns_wrapper [-] Incorrect
configuration file: /etc/neutron/rootwrap.conf

Now, there is a vpnaas.filters file that I copy into the rootwrap.d
area, using this command in the tox.ini:

cp {toxinidir}/etc/neutron/rootwrap.d/vpnaas.filters
{envdir}/etc/neutron/rootwrap.d/

The file has the neutorn-vpn-netns-wrapper entry in it. Maybe the copy
is failing?

Regards,

PCM


On Sun, Apr 26, 2015 at 9:39 PM Angus Lees  wrote:

> The tox.ini entry for dsvm-fullstack sets OS_ROOTWRAP_CMD=sudo
> {envbindir}/neutron-rootwrap {envdir}/etc/neutron/rootwrap.conf (and
> something similar for rootwrap-daemon).
>
> Is this the answer you were looking for, or are you saying OS_ROOTWRAP_CMD
> doesn't appear to be honoured in your case?
>
>  - Gus
>
> On Sat, 25 Apr 2015 at 00:45 Ihar Hrachyshka  wrote:
>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA256
>>
>> On 04/24/2015 04:02 PM, Ihar Hrachyshka wrote:
>> > On 04/24/2015 03:48 PM, Paul Michali wrote:
>> >> Hi, I'm floundering a bit, and could use some guidance on
>> >> this...
>> >
>> >> For the neutron-vpnaas repo, I am trying to modify the
>> >> functional jobs (dsvm-functional and dsvm-functional-sswan) to
>> >> act in a similar manner to neutr

[openstack-dev] [glance] Call to action, revisit CIS state

[Kuvaja, Erno]

Hi all,

As you probably know CIS was expanded from Juno metadefs work this cycle based 
on spec [1] provided. The implementation was merged in quite a rush just before 
feature freeze.

During the spec review [2] for client functionality for CIS it came to our 
attention that the implementation exposes Elasticsearch perhaps too openly via 
it's API (namely the creation of datasets allows API consumer uploading 
arbitrary files via the create request).

Call to action: Please review the CIS functionality again for security threats 
and bring them up so we can form a plan if we need to address those and request 
RC3 before release.

I have couple of major concerns about this workflow:

1)  I was shocked after reading following statement from the client spec 
review discussion: """During the Kilo release, we - by we I mean the team 
responsible for implementing the CIS - have discussed such scenario, that 
exposing Elasticsearch capabilities to the user consuming the CIS API can bring 
some serious security impact.""" This discussion nor the scenario was never 
brought to attention of the wider Glance community. The spec bluntly states 
that there is no security impact from the implementation and the concerns 
should have been brought up so reviewers would have had better chance to catch 
possible threats.

2)  """Would like to also address your concern that proposed shape of spec 
allows user to upload arbitrary documents to Elasticsearch (ES is the engine 
used under the hood, we should rather talk about uploading documents to CIS 
service) which are not related to Glance in any way (images & metadefs in 
current implementation).""" """Personally I don't think that discussion about 
IF is a valid topic, because we've already implemented backend for CIS at the 
Glance side and you cannot say A without saying B.""" As long as the code is 
developed under the Glance project and reviewed by glance-core it's outrageous 
to claim that possible issues are not related to Glance in any way. Discussion 
about if the API is implemented by the spec and fits to the mission statement 
is really valid at this point and needs to be thoroughly discussed. We need to 
find the root cause of this attitude and fix it before it damages the 
relationships within the community in a way that cannot be fixed.

3)  We had two huge pieces of code merging in at the very end of the 
development cycle Artifacts and CIS and the pressure to merge them in 
(unfortunately not review but merge) was high. On the artifacts side we had 
pretty open discussion about the state, the concerns and plans of timelines 
address those concerns. With CIS we unfortunately did not have this openness. 
Was it reflection of 1 & 2 or something else, I do not know, but I surely would 
like to.

I would like you to look back into those two specs and the comments, look back 
into the implementation and raise any urgent concerns and please lets try to 
have good and healthy base for discussion in the Vancouver Summit how we will 
continue forward from this! As Stable Branch Liaison I would really like to 
know what we (and who that we are) are supporting for next couple of cycles, as 
glance-core I would like to know any concerns about used technology or 
implementation people might have and as Glance community member I'd like to see 
us working together towards these things and definitely not have these "we" vs. 
"them"/"you" discussions anymore. Bluntly if we need to split the team, let's 
do it officially, there is room under big tent for every group who wants to be 
with themselves.

Best Regards,
Erno

[1] 
http://specs.openstack.org/openstack/glance-specs/specs/kilo/catalog-index-service.html
[2] https://review.openstack.org/#/c/173718/

__
OpenStack Development Mailing 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][plugin] What should go in environment_config.yaml when no additional attributes are desired in the Fuel Web UI?

[Emma Gordon (projectcalico.org)]

Thanks Evgeniy.

From: Evgeniy L [mailto:e...@mirantis.com]
Sent: 24 April 2015 16:39
To: OpenStack Development Mailing List (not for usage questions)
Cc: Joe Marshall
Subject: Re: [openstack-dev] [fuel][plugin] What should go in 
environment_config.yaml when no additional attributes are desired in the Fuel 
Web UI?

Hi Emma,

If you don't need additional elements on UI, just create 
"environment_config.yaml" with
"{}" value for "attributes" key, i.e. "attributes: {}"

Thanks,

On Fri, Apr 24, 2015 at 6:03 PM, Emma Gordon 
(projectcalico.org) 
mailto:e...@projectcalico.org>> wrote:
The fuel plugin wiki 
https://wiki.openstack.org/wiki/Fuel/Plugins#environment_config.yaml describes 
the required syntax for declaring (in the environment_config.yaml file) 
additional attributes that should appear under the Settings tab of the Fuel Web 
UI. If the only requirement is to have the check box to enable the plugin, but 
no additional attributes, what should go in this file?

I’ve tried not having such a file, leaving it empty, and various variants of 
None/””/[] after ‘attributes:’, but all result in the plugin failing to build – 
the latter due to failing the test_check_env_config_attrs_fail_if_none test in 
https://github.com/stackforge/fuel-plugins/blob/master/fuel_plugin_builder/fuel_plugin_builder/tests/test_validator_v1.py.
 Is it not permitted to have no attributes? Or, if that is a reasonable use 
case, should that test not exist?

Thanks,
Emma

__
OpenStack Development Mailing 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][python-novaclient] microversion implementation on client side

[John Garbutt]

I see these changes as really important.

We need to establish good patterns other SDKs can copy.

On 24 April 2015 at 12:05, Alex Xu  wrote:
> 2015-04-24 18:15 GMT+08:00 Andrey Kurilin :
>> >When user execute cmd without --os-compute-version. The nova client
>> > should discover the nova server >supported version. Then cmd choice the
>> > latest version supported both by client and server.
>>
>> In that case, why X-Compute-API-Version can accept "latest" value? Also,
>> such discovery will require extra request to API side for every client call.
>>
>
> I think it is convenient for some case. like give user more easy to try nova
> api by some code access the nova api directly. Yes, it need one more extra
> request. But if without discover, we can't ensure the client support server.
> Maybe client too old for server even didn't support the server's min
> version. For better user experience, I think it worth to discover the
> version. And we will call keystone each nova client cli call, so it is
> acceptable.

We might need to extend the API to make this easier, but I think we
need to come up with a simple and efficient pattern here.


Case 1:
Existing python-novaclient calls, now going to v2.1 API

We can look for the transitional entry of computev21, as mentioned
above, but it seems fair to assume v2.1 and v2.0 are accessed from the
same service catalog entry of "compute", by default (eventually).

Lets be optimistic about what the cloud supports, and request "latest"
version from v2.1.

If its a v2.0 only API endpoint, we will not get back a version header
with the response, we could error out if the user requested v2.x
min_version via the CLI parameters.

In most cases, we get the latest return values, and all is well.


Case 2:
User wants some info they know was added to the response in a specific
microversion

We can request "latest" and error out if we don't get a new enough
version to meet the user's min requirement.


Case 3:
Adding support for a new request added in a microversion

We could just send "latest" and assume the new functionality, then
raise an error when you get bad request (or similar), and check the
version header to see if that was the cause of the problem, so we can
say why it failed.

If its supported, everything just works.

If the user requests a specific version before it was supported, we
should error out as not supported, I guess?

In a way it would be cleaner if we had a way for the client to say
"latest but requires 2.3", so you get a bad version request if your
minimum requirement is not respected, so its much clearer than
miss-interpreting random errors that you might generate. But I guess
its not totally required here.


Would all that work? It should avoid an extra API call to discover the
specific version we have available.

>> >'--os-compute-version=None' can be supported, that means will return the
>> > min version of server supported.
>>
>> From my point of view '--os-compute-version=None' is equal to not
>> specified value. Maybe, it would be better to accept value "min" for
>> os-compute-version option.
>
> I think '--os-compute-version=None' means not specified version request
> header when send api request to server. The server behavior is if there
> isn't value specified, the min version will be used.

--os-compte-version=v2 means no version specified I guess?

Can we go back to the use cases here please?
What do the users need here and why?


>> >3. if the microversion non-supported, but user call cmd with
>> > --os-compute-version, this should return failed.
>>
>> Imo, it should be implemented on API side(return BadRequest when
>> X-Compute-API-Version header is presented in V2)

V2 is already deployed now, and doesn't do that.

No matter what happens we need to fix that.
>
> Emm I'm not sure. Because GET '/v2/' already can be used to discover
> microversion support or not. Sounds like add another way to support
> discover? And v2 api didn't return fault with some extra header, that sounds
> like behavior and back-incompatible change.

-1

We should not use the URL to detect the version.
We have other ways to do that for a good reason.

Thanks,
John



>> On Fri, Apr 24, 2015 at 12:42 PM, Alex Xu  wrote:
>>>
>>>
>>>
>>> 2015-04-24 17:24 GMT+08:00 Andrey Kurilin :

 Thank you for suggestions! I'll try modify patches as soon as possible.
>>>
>>>
>>> np, it's better waiting for more comment before you begin to update the
>>> code first. avoid you need rework again I think :)
>>>


 On Fri, Apr 24, 2015 at 6:56 AM, Alex Xu  wrote:
>
> Thanks Andrey for hard work on the microverison client support.
>
> Wrote down some my thought:
>
> I also agreed we will have only one endpoint 'compute'. Hope we can
> switch v2.1 export as '/v2' in the api-paste.conf as default very soon~
>
> let's say what expected after we only have v2.1 in the world first:
>
> There are two cases for use nova client.
> 1. 

Re: [openstack-dev] [Neutron][Keystone] [Nova] How to validate teanant-id for admin operation

[Salvatore Orlando]

I believe German is referring to the case where a user performs an
operation on behalf of some other project to whom it bears no relationship.
In this case the user performing the operation authenticates with keystone
with a project_id which is not the one for which the operation is being
performed.

This happens in project like neutron, where a 'tenant_id' parameter can be
included in the request body.
In CLI terms this is done in the following way:

neutron net-create  --tenant-id 

Note that --tenant-id here is not the usual '--os-tenant-id' parameter.
Therefore it is not sent to keystone for validation and authentication.
Keystone just authenticates the admin user with its own project. Neutron
then lets 'admin' users do everything with anything, including creating
networks and other objects for other tenants, which to neutron are just
plain strings.

For instance:

salvatore@ubuntu:~/devstack$ neutron net-create --tenant-id meh ciccio
Created a new network:
+---+--+
| Field | Value|
+---+--+
| admin_state_up| True |
| id| 60d3cfc0-1a75-4a78-920d-edc11ea3fc2d |
| name  | ciccio   |
| tenant_id | meh  |
+---+--+

Neutron is not alone in this behaviour. For instance, glance allows image
owners' to share them with a tenant which is not validated with keystone as
well:

salvatore@ubuntu:~/devstack$ glance member-create
667046ae-d8b1-4ef4-925e-a1c857fd45fa meh
salvatore@ubuntu:~/devstack$ glance member-list --image
667046ae-d8b1-4ef4-925e-a1c857fd45fa
+--+---+---+
| Image ID | Member ID | Can Share |
+--+---+---+
| 667046ae-d8b1-4ef4-925e-a1c857fd45fa | meh   |   |
+--+---+---+

On the other hand I believe keystone developers are advocating for a
behaviour like the following:

salvatore@ubuntu:~/devstack$ nova --os-project-id
4704447e0f7e48558cf15fe63341f412 boot --image
 667046ae-d8b1-4ef4-925e-a1c857fd45fa --flavor 42 --nic
net-id=5aff7242-97f6-48be-9d82-c06a28a7f1cf meh
+--++
| Property | Value
 |
+--++
| id   |
34ea6810-01a8-4cfd-b6fa-207ff9f68bac   |
| image| cirros-0.3.2-x86_64-uec
(667046ae-d8b1-4ef4-925e-a1c857fd45fa) |
| name | meh
 |
| tenant_id| 4704447e0f7e48558cf15fe63341f412
|
| user_id  | aa4cac3a2fbd43c0b90fd6ebed44d6ba
|
+--++

Which is made possible by:

salvatore@ubuntu:~/devstack$ keystone user-role-list --user admin --tenant
demo
+--+---+--+--+
|id|  name | user_id
   |tenant_id |
+--+---+--+--+
| f91adfeb71ad462db8f8f7dc1e25b97e | admin |
aa4cac3a2fbd43c0b90fd6ebed44d6ba | 4704447e0f7e48558cf15fe63341f412 |
+--+---+--+--+

I believe Neutron should move away from letting admin user 'own' the whole
system. Also, since several projects already adopt a model in which user
explicitly have roles in multiple projects, this should not be cause of any
pain for operators.
I therefore think that the solution for the problem with validation of the
--tenant-id parameter is that we need to get rid of it. From a neutron
perspective this should be done in a backward compatible way. To this aim,
we can even start thinking about versioning the API... If not we can always
add an extension that removes the tenant-id attribute... we can even call
it a "un-extension"... wouldn't that be wonderful?

Generally speaking this is not the first time this topic comes around. I
think we should now really address it, if nothing else because neutron is
disaligned with other openstack projects. As an operator it is far from
ideal that when deploying neutron you have to cons

[openstack-dev] [mistral] Cancelling today's team meeting - 04/27/2015

[Renat Akhmerov]

Team,

We decided to cancel today’s meeting because a number of key members won’t be 
able to attend.

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

Re: [openstack-dev] [cinder] Is there any way to put the driver backend error message to the horizon

[liuxinguo]

Thanks for your suggestion, George. But when I looked into python-cinderclient 
(not very deep), I can not find the “wrapper around the python-cinderclient” 
you have mentioned.
Could you please give me a little more hint to find the “wrapper”?

Thanks,
Liu


发件人: George Peristerakis [mailto:gperi...@redhat.com]
发送时间: 2015年4月13日 23:22
收件人: OpenStack Development Mailing List (not for usage questions)
主题: Re: [openstack-dev] [cinder] Is there any way to put the driver backend 
error message to the horizon

Hi Lui,

I'm not familiar with the error you are trying to show, but Here's how Horizon 
typically works. In the case of cinder, we have a wrapper around the 
python-cinderclient which if the client sends a exception with a valid message, 
by default Horizon will display the exception message. The message can also be 
overridden in the translation file. So a good start is to look in 
python-cinderclient and see if you could produce a more meaningful message.


Cheers.
George
On 10/04/15 06:16 AM, liuxinguo wrote:

Hi,



When we create a volume in the horizon, there may occurrs some errors at the 
driver

backend, and the in horizon we just see a "error" in the volume status.



So is there any way to put the error information to the horizon so users can 
know what happened exactly just from the horizon?

Thanks,

Liu






__

OpenStack Development Mailing 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] [all] End of DepFreeze, no more hold on library releases

[Thierry Carrez]

Hi everyone,

Thanks to the efforts of the Release team (special thanks to Doug
Hellmann and Sean Dague) and Jeremy Stanley from the Infra team, we
finally fixed the stable/kilo and master requirements gate. The
following freezes are therefore lifted:

- No more DepFreeze[1], master requirements updates can be proposed and
approved again with the usual rules

- New versions of libraries can be tagged as needed

We are sorry for the inconvenience caused by the extended DepFreeze
period and the temporary library ban. In order to avoid repeating such a
mess in the Liberty cycle, the QA, Infra and Release Management teams
plan to review the interaction between requirements and CI testing, as
well as its consequences on the release process, during the Friday
sprint in Vancouver.

Regards,

[1] https://wiki.openstack.org/wiki/DepFreeze

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

Re: [openstack-dev] [nova] Need more suggestion about nova-scheduler patch/147048

[John Garbutt]

Thanks for your comments on the patch I see what you are trying to do
now, I think.

However, still a bit concerned about the unit tests, but its probably
easier to discuss that in gerrit.

Thanks,
johnthetubaguy

On 24 April 2015 at 04:25, Rui Chen  wrote:
> Hi all:
>
> I'm working on the patch https://review.openstack.org/#/c/147048/ for
> bug/1408859
>
> Description of Bug:
> When the nova-scheduler can't select enough hosts for multiple creating
> instance, a NoValidHost exception was raised, but the part of hosts had been
> consumed from instance in the _schedule loop, the resource of consumed hosts
> was not reverted, it would result in the resource lacking in nova-scheduler.
>
> But now I'm in a dilemma, because the reviewers have different point
> about implementation of the patch, so I need more feedback.
>
> See patch set 36
> This is simple way, just set the 'updated' attribute of consumed host as
> None, and make use of the 'update_from_compute_node' logic to update the
> local HostState at the next scheduling request.
>
> http://git.openstack.org/cgit/openstack/nova/tree/nova/scheduler/host_manager.py#n185
>
> But like John say, it would break CachingScheduler in a refresh cycle,
> the resource of HostState would been fixed until the next periodic_tasks is
> executed.
>
> Other side, Alex and Sylvain think that it should be acceptable, because
> CachingSheduler use the out of date HostState in the cache according to the
> design, and the usage limitation had been described in class notes.
>
> I'm really really hope this patch can been merged ASAP, it has spent
> several months to review :(
>
> Please let me know your point, feel free to discuss it, thanks.
>
> Best Regards.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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

Re: [openstack-dev] [all] Gerrit currently down

[Andreas Jaeger]

Thanks to Sergey and Joshua, gerrit is up again!

All changes that were done today between around 2:50 UTC and 8:15 UTC, 
need to be requeued.


We've just run those manually for all jobs where a check event was 
missing, so this should cover all new uploads. If not, add "recheck" to 
trigger this for new uploads.


For approved changes manual action is needed: another approval vote will 
get the job directly into the gate (preferred) and "recheck" will move 
it through both check and gate,


Andreas

On 04/27/2015 07:25 AM, Andreas Jaeger wrote:

Our CI system is currently not processing any events. This means that no
new check or gate jobs get started.

Uploading new patches and reviewing is working fine.

But new patches uploaded will not get checked and patches approved will
not get gated and merge - and "recheck" will not help either.

We have to wait until somebody with root access to the CI systems can
fix the problem. Somebody from the infra team will tell you once the
systems is up and what needs to be done with any changes changed during
the downtime,



--
 Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi
  SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu,
   Graham Norton, HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126


__
OpenStack Development Mailing 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] Gerrit restarted due to the internal issues

[Sergey Lukjanov]

Hi folks,

I've just restarted review.openstack.org gerrit to fix issue with sending
events. It means that some of your patches needs to be rechecked to receive
votes from CI.

3rd party CIs maintainers, you probably should restart your Zuul service to
ensure it reconnected after gerrit restart.

Thanks.

-- 
Sincerely yours,
Sergey Lukjanov
Sahara Technical Lead
(OpenStack Data Processing)
Principal Software Engineer
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] [OpenStack-Infra] [all] Gerrit currently down

[Sergey Lukjanov]

Gerrit has been restarted and it works ok now.

On Mon, Apr 27, 2015 at 8:25 AM, Andreas Jaeger  wrote:

> Our CI system is currently not processing any events. This means that no
> new check or gate jobs get started.
>
> Uploading new patches and reviewing is working fine.
>
> But new patches uploaded will not get checked and patches approved will
> not get gated and merge - and "recheck" will not help either.
>
> We have to wait until somebody with root access to the CI systems can fix
> the problem. Somebody from the infra team will tell you once the systems is
> up and what needs to be done with any changes changed during the downtime,
>
> Andreas
> --
>  Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi
>   SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
>GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu,
>Graham Norton, HRB 21284 (AG Nürnberg)
> GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126
>
>
> ___
> OpenStack-Infra mailing list
> openstack-in...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
>



-- 
Sincerely yours,
Sergey Lukjanov
Sahara Technical Lead
(OpenStack Data Processing)
Principal Software Engineer
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