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

2015-04-27 Thread Flavio Percoco

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.

Note that I've emphasized comunication and not a very specific plan
towards quality. The reason being that I believe that a good
communication between the TC and the rest of the community will help
with defining those guidelines I mentioned before and a good workflow
that would help projects to improve their quality and that would also
help developers to improve their experience in the community.

Staying out of the way of projects sounds exciting but we still need
to be almost-silent observers/actors in project's lifes to make sure the
right people/projects are talking to each other.

I'm a big believer in collaboration and I think that we should strive
for it as much as possible and the TC should be there to help.

This all will improve the quality of our projects in the long run as
we'll be developing experiences that will be available for other
projects to consume.

That was from a TC perspective. Now, from a project perspective, I
believe the TC needs to be vigilant and ensure that projects have all
the tools and resources to be productive and independent. This goes
along with what I said above. New groups have been born that should
help improving different areas - API WG, for example - and these
groups need to communicate with the rest of the community. We sould
encourage folks from different projects to be part of these groups and
contribute.  Pretty much like we encourage folks to be part of Oslo,
or at the very least follow its developments.

Thanks for reading,
Flavio

--
@flaper87
Flavio Percoco


pgpJQHL6bMxfr.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] Gerrit currently down

2015-04-27 Thread 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


Re: [openstack-dev] [fuel][plugin] What should go in environment_config.yaml when no additional attributes are desired in the Fuel Web UI?

2015-04-27 Thread 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.orghttp://projectcalico.org) 
e...@projectcalico.orgmailto: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:unsubscribehttp://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] Need more suggestion about nova-scheduler patch/147048

2015-04-27 Thread 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 chenrui.m...@gmail.com 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


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

2015-04-27 Thread 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] [nova][python-novaclient] microversion implementation on client side

2015-04-27 Thread 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 sou...@gmail.com wrote:
 2015-04-24 18:15 GMT+08:00 Andrey Kurilin akuri...@mirantis.com:
 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 sou...@gmail.com wrote:



 2015-04-24 17:24 GMT+08:00 Andrey Kurilin akuri...@mirantis.com:

 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 sou...@gmail.com 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. user use nova client command line. I think command line should
 support version discover. 

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

2015-04-27 Thread 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 s...@dague.net 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 rbtcoll...@hp.com
Distinguished Technologist
HP Converged Cloud

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


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

2015-04-27 Thread 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] RegionOne vs. regionOne

2015-04-27 Thread Morgan Fainberg


 On Apr 27, 2015, at 14:35, Christopher Aedo ca...@mirantis.com wrote:
 
 On Mon, Apr 27, 2015 at 10:52 AM, Sean M. Collins s...@coreitpro.com 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

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

2015-04-27 Thread Dolph Mathews
On Mon, Apr 27, 2015 at 6:46 AM, Ajaya Agrawal ajku@gmail.com wrote:

 On Mon, Apr 27, 2015 at 6:05 AM, Jamie Lennox jamielen...@redhat.com
  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 german.eichber...@hp.com
  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
 

 __
 

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

2015-04-27 Thread 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


Re: [openstack-dev] Navigating the ever changing OpenStack codebase

2015-04-27 Thread 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


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

2015-04-27 Thread 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


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

2015-04-27 Thread 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


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

2015-04-27 Thread 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


[openstack-dev] Navigating the ever changing OpenStack codebase

2015-04-27 Thread 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


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

2015-04-27 Thread 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] [cinder] Is there any way to put the driver backend error message to the horizon

2015-04-27 Thread 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:unsubscribemailto: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] Gerrit restarted due to the internal issues

2015-04-27 Thread 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

2015-04-27 Thread Sergey Lukjanov
Gerrit has been restarted and it works ok now.

On Mon, Apr 27, 2015 at 8:25 AM, Andreas Jaeger a...@suse.com 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


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

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

2015-04-27 Thread 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 name --tenant-id 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 

Re: [openstack-dev] ERROR: openstackclient.shell Exception raised: python-keystoneclient 1.4.0

2015-04-27 Thread Alan Pevec
 This is a problem of dependency resolution rather than an issue of 
 keystoneclient specifically. You can see that glanceclient has a cap on 
 keystoneclient that the installed version doesn't meet.

python-keystoneclient=1.1.0,1.4.0 is requirement on
python-glanceclient stable/kilo branch,
while python-keystoneclient 1.4.0 is master. Are you using stable/kilo
or master devstack?
Problem is that openstackclient stable/kilo is missing requirements
caps so if installed earlier it will pull latest published on pypi
which is out of bounds for Kilo. https://review.openstack.org/174341
should fix that


Cheers,
Alan

__
OpenStack Development Mailing 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

2015-04-27 Thread 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] [neutron] Need guidance - functional tests and rootwrap

2015-04-27 Thread 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
http://logs.openstack.org/15/168115/29/check/check-neutron-vpnaas-dsvm-functional-sswan/c857bcd/console.html.gz#_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 
http://logs.openstack.org/15/168115/29/check/check-neutron-vpnaas-dsvm-functional-sswan/c857bcd/console.html.gz#_2015-04-24_15_19_15_499
| 2015-04-24 15:19:15.467 | OS_SUDO_TESTING=12015-04-24 15:19:15.499
http://logs.openstack.org/15/168115/29/check/check-neutron-vpnaas-dsvm-functional-sswan/c857bcd/console.html.gz#_2015-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
http://logs.openstack.org/15/168115/29/check/check-neutron-vpnaas-dsvm-functional-sswan/c857bcd/console.html.gz#_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
http://logs.openstack.org/15/168115/29/check/check-neutron-vpnaas-dsvm-functional-sswan/c857bcd/console.html.gz#_2015-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
http://logs.openstack.org/15/168115/29/check/check-neutron-vpnaas-dsvm-functional-sswan/c857bcd/console.html.gz#_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
http://logs.openstack.org/15/168115/29/check/check-neutron-vpnaas-dsvm-functional-sswan/c857bcd/console.html.gz#_2015-04-24_15_19_18_537
| 2015-04-24 15:19:18.490 | Exit code: 222015-04-24 15:19:18.537
http://logs.openstack.org/15/168115/29/check/check-neutron-vpnaas-dsvm-functional-sswan/c857bcd/console.html.gz#_2015-04-24_15_19_18_537
| 2015-04-24 15:19:18.492 | Stdin: 2015-04-24 15:19:18.537
http://logs.openstack.org/15/168115/29/check/check-neutron-vpnaas-dsvm-functional-sswan/c857bcd/console.html.gz#_2015-04-24_15_19_18_537
| 2015-04-24 15:19:18.493 | Stdout: 2015-04-24 15:19:18.537
http://logs.openstack.org/15/168115/29/check/check-neutron-vpnaas-dsvm-functional-sswan/c857bcd/console.html.gz#_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 g...@inodes.org 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 ihrac...@redhat.com 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 neutron, where devstack is 

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

2015-04-27 Thread Erlon Cruz
Alex,

Any scratch of the solution you plan to propose?

On Mon, Apr 27, 2015 at 5:57 AM, liuxinguo liuxin...@huawei.com 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] [cinder] cinder support matrix, chap support?

2015-04-27 Thread Jordan Pittier
Hi,
Isn't CHAP iscsi-specific ?

Jordan

On Mon, Apr 27, 2015 at 2:41 PM, Dave Walker em...@daviey.com 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

2015-04-27 Thread 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


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

2015-04-27 Thread 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 not know, but I surely would 
like 

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

2015-04-27 Thread Davanum Srinivas
@ttx, +1 from me.

-- dims

On Mon, Apr 27, 2015 at 8:19 AM, Thierry Carrez thie...@openstack.org 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

2015-04-27 Thread 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


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

2015-04-27 Thread 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] [cinder] cinder support matrix, chap support?

2015-04-27 Thread Erlon Cruz
Yes

On Mon, Apr 27, 2015 at 9:49 AM, Jordan Pittier jordan.pitt...@scality.com
wrote:

 Hi,
 Isn't CHAP iscsi-specific ?

 Jordan

 On Mon, Apr 27, 2015 at 2:41 PM, Dave Walker em...@daviey.com 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] [Neutron][Keystone] [Nova] How to validate teanant-id for admin operation

2015-04-27 Thread Ajaya Agrawal
On Mon, Apr 27, 2015 at 6:05 AM, Jamie Lennox jamielen...@redhat.com
 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 german.eichber...@hp.com
  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.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development 

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

2015-04-27 Thread 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

2015-04-27 Thread 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] [all] Question for the TC candidates

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

2015-04-27 Thread 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 by glance-core it's outrageous 
to 

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

2015-04-27 Thread Nikhil Komawar
Thanks Geoff. Added some notes and questions.

-Nikhil


From: Geoff Arnold 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


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

2015-04-27 Thread 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 zbit...@redhat.com wrote:
 
  On 24/04/15 19:02, Joe Gordon wrote:
 
 
 
  On Mon, Apr 20, 2015 at 5:54 AM, Flavio Percoco fla...@redhat.com
  mailto:fla...@redhat.com 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] [openstack][nova] Does anyone use Zookeeper, Memcache Nova ServiceGroup Driver ?

2015-04-27 Thread 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] [all] Question for the TC candidates

2015-04-27 Thread 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


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

2015-04-27 Thread 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


[openstack-dev] [api] Missing meetings this week

2015-04-27 Thread 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] [Neutron] Bump the RPC version required for port_update - AgentNotifierApi

2015-04-27 Thread Armando M.
On 27 April 2015 at 09:09, Rossella Sblendido rsblend...@suse.com 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] Navigating the ever changing OpenStack codebase

2015-04-27 Thread 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] [Neutron] A big tent home for Neutron backend code

2015-04-27 Thread 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


Re: [openstack-dev] [Neutron] [Nova] [Cinder] [tc] Should Openstack project maintained by core team keep only API/DB in the future?

2015-04-27 Thread loy wolfe
On Fri, Apr 24, 2015 at 9:13 PM, Kyle Mestery mest...@mestery.com wrote:
 On Fri, Apr 24, 2015 at 4:06 AM, loy wolfe loywo...@gmail.com 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 mest...@mestery.com wrote:
 
 
  On Thu, Apr 23, 2015 at 1:31 PM, Fox, Kevin M kevin@pnnl.gov
  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 analogy with nova that doesn't build and
  deliver
  KVM, we can say that Neutron doesn't build or deliver OVS. It builds a
  driver and an agent which manage OVS, just 

[openstack-dev] install custom middleware via devstack

2015-04-27 Thread 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 http://ir.linkedin.com/in/taleghani
__
OpenStack Development Mailing 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

2015-04-27 Thread 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


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

2015-04-27 Thread 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] [Keystone][Glance] Hierarchical multitenancy and Glance?

2015-04-27 Thread 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 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
nikhil.koma...@rackspace.com wrote:
 
 Thanks Geoff. Added some notes and questions.
 
 -Nikhil
 
 
 From: Geoff Arnold 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


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

2015-04-27 Thread 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 nikhil.koma...@rackspace.com 
 wrote:
 
 Thanks Geoff. Added some notes and questions.
 
 -Nikhil
 
 
 From: Geoff Arnold 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


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

2015-04-27 Thread Armando M.
On 27 April 2015 at 18:16, YAMAMOTO Takashi yamam...@valinux.co.jp wrote:

  On 27 April 2015 at 09:09, Rossella Sblendido rsblend...@suse.com
 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] [Neutron] Bump the RPC version required for port_update - AgentNotifierApi

2015-04-27 Thread YAMAMOTO Takashi
 On 27 April 2015 at 09:09, Rossella Sblendido rsblend...@suse.com 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] [all] Question for the TC candidates

2015-04-27 Thread Armando M.
On 23 April 2015 at 09:14, Chris Dent chd...@redhat.com 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][LBaaS] Why do we need to select subnet when creating a pool?

2015-04-27 Thread 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 wanjing...@hotmail.com
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] [nova] Required data migrations in Kilo, need Turbo Hipster tests updated

2015-04-27 Thread 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] [release] python-ceilometerclient 1.0.14

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

2015-04-27 Thread 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 ideas to the list before KVM Forum starts.
 
 
 PANEL DISCUSSIONS
 
 If you are proposing a panel discussion, please make sure that 

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

2015-04-27 Thread 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] [Neutron] Bump the RPC version required for port_update - AgentNotifierApi

2015-04-27 Thread 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


[openstack-dev] [release] python-keystoneclient 1.3.1

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

2015-04-27 Thread Ian Cordasco
On 4/27/15, 05:39, Kuvaja, Erno kuv...@hp.com 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 
http://specs.openstack.org/openstack/glance-specs/specs/kilo/catalog-inde
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 anyone really would expect us to)
which means new plugins can be created 

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

2015-04-27 Thread 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


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

2015-04-27 Thread Ed Leafe
On Apr 27, 2015, at 9:20 AM, Jay Pipes jaypi...@gmail.com 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] [Infra][Cinder] get voting permissions for Infortrend 3rd-party CI

2015-04-27 Thread 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


[openstack-dev] [release] keystonemiddleware 1.5.1

2015-04-27 Thread 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/
http://tarballs.openstack.org/python-keystoneclientkeystonemiddleware
* https://pypi.python.org/pypi/
https://pypi.python.org/pypi/python-keystoneclientkeystonemiddleware

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] [puppet] Weekly meeting #33

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

2015-04-27 Thread 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] [heat] Kubernetes AutoScaling with Heat AutoScalingGroup and Ceilometer

2015-04-27 Thread 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] [all] Question for the TC candidates

2015-04-27 Thread 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


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

2015-04-27 Thread 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 sha...@redhat.com 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


Re: [openstack-dev] Navigating the ever changing OpenStack codebase

2015-04-27 Thread 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 kevin.mitch...@rackspace.com
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

2015-04-27 Thread 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] Navigating the ever changing OpenStack codebase

2015-04-27 Thread 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] [heat] Stack/Resource updated_at conventions

2015-04-27 Thread 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


[openstack-dev] [Infra] Meeting Tuesday April 28th at 19:00 UTC

2015-04-27 Thread 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] [Manila] Mount automation using Zeroconf

2015-04-27 Thread 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 clinton.kni...@netapp.com
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.org
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


[openstack-dev] RegionOne vs. regionOne

2015-04-27 Thread 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


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

2015-04-27 Thread 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


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

2015-04-27 Thread 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


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

2015-04-27 Thread 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 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 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 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 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
 
 
 

 __
 OpenStack Development Mailing 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

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

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

2015-04-27 Thread Joe Gordon
On Fri, Apr 24, 2015 at 5:19 PM, Zane Bitter zbit...@redhat.com wrote:

 On 24/04/15 20:00, Joe Gordon wrote:



 On Fri, Apr 24, 2015 at 4:35 PM, Fox, Kevin M kevin@pnnl.gov
 mailto:kevin@pnnl.gov 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
 mailto: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 fla...@redhat.com
 mailto:fla...@redhat.com 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 off
 and it's time for it to show some results. The current problem
 seems
 to be that many people want the project but no one wants to 

Re: [openstack-dev] RegionOne vs. regionOne

2015-04-27 Thread 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] [Zaqar] Call for adoption (or exclusion?)

2015-04-27 Thread Joe Gordon
On Fri, Apr 24, 2015 at 5:05 PM, Zane Bitter zbit...@redhat.com wrote:

 On 24/04/15 19:02, Joe Gordon wrote:



 On Mon, Apr 20, 2015 at 5:54 AM, Flavio Percoco fla...@redhat.com
 mailto:fla...@redhat.com 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 and effort spent on the project not
 worth it. It's been more than 2 years since we kicked the project off
 

[openstack-dev] [Neutron][LBaaS] Why do we need to select subnet when creating a pool?

2015-04-27 Thread 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


[openstack-dev] [chef] Openstack-Chef has officially moved to this mailing list

2015-04-27 Thread 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/ 
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


Re: [openstack-dev] RegionOne vs. regionOne

2015-04-27 Thread Christopher Aedo
On Mon, Apr 27, 2015 at 10:52 AM, Sean M. Collins s...@coreitpro.com 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] [glance] Why no DB index on sort parameters

2015-04-27 Thread 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 nikhil.koma...@rackspace.com
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 fla...@redhat.com 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 fla...@redhat.com 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 mba...@redhat.com mailto:mba...@redhat.com
 Sent: Tuesday, April 21, 2015 9:45 AM
 To: openstack-dev@lists.openstack.org
mailto: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://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 
 
__
 OpenStack 

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

2015-04-27 Thread 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


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

2015-04-27 Thread Tripp, Travis S



On 4/27/15, 05:39, Kuvaja, Erno kuv...@hp.com 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 ian.corda...@rackspace.com 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