date:20150814

This option can not be used in show stack call.

Regards,
Wanghua

On Fri, Aug 14, 2015 at 4:54 PM, 英哲 zengyz1...@live.cn wrote:

 Can this option be used for in show stack details call?

  Date: Fri, 14 Aug 2015 04:30:19 -0400
  From: the...@redhat.com
  To: openstack-dev@lists.openstack.org
  Subject: Re: [openstack-dev] [openstack][magnum][heat]problems for
 synchronizing stack parameters from heat

 
 
 
   Hi all,
  
   Magnum creates a stack when a bay is created and update the stack
   parameters when the bay is updated. Magnum has a periodic task
   to synchronize stack status from heat.
   And now we want to synchronize stack parameters from heat, too. But
 heat
   don't allow admin user to show stack in other tenants, so we can not
 get
   stack parameters.
 
  That's not true. You just need to pass the appropriate option,
 global_tenant, in your list call.
 
  Regards,
 
  --
  Thomas
 
 
 __
  OpenStack Development Mailing 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] [openstack][magnum][heat]problems for synchronizing stack parameters from heat

2015-08-14 Thread Thomas Herve




 We can get stacks by stack list call, but it does not provide info about
 stack parameters. If we need stack parameters, we have to use stack.get.

Yeah that part is right. I believe we consider stack parameters somewhat 
private to the user, which may be the reason they are not easily accessible. 
What do you need them for?

-- 
Thomas

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

Re: [openstack-dev] [devstack] Possible issues cryptography 1.0 and os-client-config 1.6.2

2015-08-14 Thread Chris Dent

On Fri, 14 Aug 2015, Robert Collins wrote:

The vast majority of our developers do not fix such bugs. They react
by blacklisting the proximate cause of the issue - the new release -
locally, submit a patch to openstack/requirements *sometimes* and if
we're really lucky file a bug upstream.

That sounds like a social disease.

The constraints system proactively finds and highlights to anyone
interested the same issues [presuming the issue can be shown in the
gate]. It does that via a bot that updates constraints automatically
via a periodic job.

I appreciate the value of the automation but from my standpoint in
addition to helping some aspects of the problem it also allows the
social disease to carry on. Maybe diseased is just the way things are
here, and if so, fine, we'll have to deal with it.

But I'm not going to stop popping my head up above the parapet every
now and again to say hey, let's stop allowing this to be okay
before going back to making more stuff.

Its visible: follow
https://review.openstack.org/#/q/status:open+project:openstack/requirements+branch:master+topic:openstack/requirements/constraints,n,z

Awesome, thanks for pointing this out, that will be useful.

But again: Underlying my assertion is that we don't _just_ need more
tools and automation we also need to remind ourselves of the kind of
environment that we're operating in, as humans.

I'm not against the automation of the gate side of things. Yes,
great, you and others are doing some stellar work to insure
stability. Thank you _very_ much. I'm arguing about the devstack
default.

And even then, I'm not arguing that we don't set it, rather that we
just pause a moment and think about the side effects, if any.

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

Re: [openstack-dev] [openstack][magnum][heat]problems for synchronizing stack parameters from heat

Magnum creates a stack when a bay is created and update the stack
parameters when the bay is updated. Magnum needs a periodic task to synchronize
stack status and parameters from heat to keep data consistency.

Regards,
Wanghua

On Fri, Aug 14, 2015 at 5:02 PM, Thomas Herve the...@redhat.com wrote:




  We can get stacks by stack list call, but it does not provide info about
  stack parameters. If we need stack parameters, we have to use stack.get.

 Yeah that part is right. I believe we consider stack parameters somewhat
 private to the user, which may be the reason they are not easily
 accessible. What do you need them for?

 --
 Thomas

 __
 OpenStack Development Mailing 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] [devstack] Possible issues cryptography 1.0 and os-client-config 1.6.2

2015-08-14 Thread Clint Byrum

Excerpts from Chris Dent's message of 2015-08-14 02:08:28 -0700:
On Fri, 14 Aug 2015, Robert Collins wrote:

That sounds like a social disease.

If we're good with all of the developers of OpenStack being affected,
why aren't we good with the gate's being affected?

Shouldn't everyone be forced to fix those bugs to fix the gate? It
sounds good, but we tried that, and the experiment provided _years_
of data that even when the gate is broken, only a few fix it and not on
the priority that should be garnered by something affecting nearly all
developers at once.

I'd say it's less disease, and more economic reality. We have revolving
debt in real economies for a reason. Stopping to think about the exact
source of all cash flow every time you need to incur an expense has a
massive cost in loss of focus and opportunity.

The same is true for these bugs. Yes they're real, yes more orgs should
devote developers to fixing them. But we can consider the issues caused
by external forces separately from landing code because we have the
constraints capability now. I think developers will be more productive
if they are also allowed to keep the two concerns separate. Meanwhile
we can observe how far behind we actually get because of these problems
without drawing the whole of OpenStack down with us.

But I'm not going to stop popping my head up above the parapet every
now and again to say hey, let's stop allowing this to be okay
before going back to making more stuff.

Its visible: follow
https://review.openstack.org/#/q/status:open+project:openstack/requirements+branch:master+topic:openstack/requirements/constraints,n,z

Awesome, thanks for pointing this out, that will be useful.

But again: Underlying my assertion is that we don't _just_ need more
tools and automation we also need to remind ourselves of the kind of
environment that we're operating in, as humans.

I'm not against the automation of the gate side of things. Yes,
great, you and others are doing some stellar work to insure
stability. Thank you _very_ much. I'm arguing about the devstack
default.

And even then, I'm not arguing that we don't set it, rather that we
just pause a moment and think about the side effects, if any.

Your concerns are valid and appreciated. However, I think the side
effect of not setting it is wasting developer time on a large scale. The
side effect of setting it is putting that work into a queue which an
appropriately sized subset of developers can manage.

Re: [openstack-dev] [devstack] Possible issues cryptography 1.0 and os-client-config 1.6.2

2015-08-14 Thread Robert Collins

On 14 August 2015 at 21:08, Chris Dent chd...@redhat.com wrote:

 Awesome, thanks for pointing this out, that will be useful.

 But again: Underlying my assertion is that we don't _just_ need more
 tools and automation we also need to remind ourselves of the kind of
 environment that we're operating in, as humans.

 I'm not against the automation of the gate side of things. Yes,
 great, you and others are doing some stellar work to insure
 stability. Thank you _very_ much. I'm arguing about the devstack
 default.

 And even then, I'm not arguing that we don't set it, rather that we
 just pause a moment and think about the side effects, if any.


I'm saying, at least for me, I have thought about it, and I think the
disease is in expecting everyone. Everyone (First day developer and
wizard-of-openstack-been-here-from-the-start) to all simultaneously
interact with new upstream releases.

Its not a benefit: its a massive cost. Its why developers on
proprietary platforms often try developing Open Source for a day and
then swear 'never again'.

Its why RHEL and Ubuntu LTS's are things at all.

Instability hurts our developers. It hurts our vendors (slower
development of features) and it hurts our users (longer time to get
fixes and new features).

The larger our community grows the more it hurts.

I'd like folk to really viscerally feel this. The mystified 'every
time I try to do something I have to debug a mysterious failure'
reaction that I see from folk on IRC every time something like this
happens should be making us sadmad (the opposite of
http://greendoorrelaxation.net/2015/04/23/you-are-mad-sad/). Fixing
these things directly improves the experience of *thousands* of
developers.

To put this in context, we have nearly 400 (including transitive)
dependencies including all the ones we create. We're hurting thousands
of people to help hundreds of projects /urgently/. I don't think that
makes sense.

Rather, lets help those projects gracefully: keep gentle pressure on
to upgrade, while still respecting the time of /all/ our contributors.

-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

[openstack-dev] [openstack][magnum][heat]problems for synchronizing stack parameters from heat

Hi all,

Magnum creates a stack when a bay is created and update the stack
parameters when the bay is updated. Magnum has a periodic task
to synchronize stack status from heat.
And now we want to synchronize  stack parameters from heat, too. But heat
don't allow admin user to show stack in other tenants, so we can not get
stack parameters.

I think it is necessary. Nova allows admin user to show instance in other
tenants. Neutron allow admin user to show port in other tenants. Nova uses
it to synchronize network info for instance from neutron. So can heat allow
admin user to show stack in other tenants?


Regards,
Wanghua
__
OpenStack Development Mailing 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] Proposing Gorka Eguileor for core

2015-08-14 Thread Huang Zhiteng

+1

On Fri, Aug 14, 2015 at 4:05 PM, Deepak Shetty dpkshe...@gmail.com wrote:



 On Fri, Aug 14, 2015 at 12:43 AM, Mike Perez thin...@gmail.com wrote:

 It gives me great pleasure to nominate Gorka Eguileor for Cinder core.

 Gorka's contributions to Cinder core have been much apprecated:


 https://review.openstack.org/#/q/owner:%22Gorka+Eguileor%22+project:openstack/cinder,p,0035b6410002dd11

 60/90 day review stats:

 http://russellbryant.net/openstack-stats/cinder-reviewers-60.txt
 http://russellbryant.net/openstack-stats/cinder-reviewers-90.txt

 Cinder core, please reply with a +1 for approval. This will be left
 open until August 19th. Assuming there are no objections, this will go
 forward after voting is closed.


 I am not cinder core, but +1 for Gorka to be one.
 His reviews have helped me in the past, and I particularly appreciate the
 fine grain reviews he does, which helps reduce patch iterations for the
 author

 Good luck Gorka!



 --
 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 Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




-- 
Regards
Huang Zhiteng
__
OpenStack Development Mailing 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][magnum][heat]problems for synchronizing stack parameters from heat

2015-08-14 Thread Thomas Herve



 Hi all,
 
 Magnum creates a stack when a bay is created and update the stack
 parameters when the bay is updated. Magnum has a periodic task
 to synchronize stack status from heat.
 And now we want to synchronize  stack parameters from heat, too. But heat
 don't allow admin user to show stack in other tenants, so we can not get
 stack parameters.

That's not true. You just need to pass the appropriate option, global_tenant, 
in your list call.

Regards,

-- 
Thomas

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

Re: [openstack-dev] [devstack] Possible issues cryptography 1.0 and os-client-config 1.6.2

2015-08-14 Thread Chris Dent


On Thu, 13 Aug 2015, Sean M. Collins wrote:


Do we want to make it a default to True for users of DevStack? I think
it may be worth considering since I'm not familiar with this issue
with crypto and having something that protects devs who are trying to
work on stuff and using DevStack , sounds good. Less cryptic day to
day breakage for new developers just getting started and using
DevStack is a goal I have, long term (where possible).


While I understand the practical considerations of using upper
constraints in the gate I think using them locally when doing the
dev part of using devstack has some unintended consequences that
we need to think about (assuming my implicit conclusion below is
correct).

The main issue is that it moves our use of all these libraries from
a position of participation to consumption. If we are only using
known-good constrained libs then we are not being a part of the
broader ecosystem that finds and fixes bugs in Python libraries.

That may seem a bit esoteric or idealistic but it is one of the
aspects of open source collaboration that I think is truly great:
project evolution as a result of cross-pollination.

This is not to say that I'm not sympathetic to the problem of
cryptic day to day breakage. It's a significant issue but I'm not
sure the way to fix that problem is by becoming more static.
Breakage is a bug, it needs to be visible so it can be fixed, not
masked.

All that idealism of course has to be modulated by pragmatism, but
not forgotten.

--
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] [mistral] [murano] An online YAQL evaluator

2015-08-14 Thread Renat Akhmerov

I just read this thread so decided to add my 2 cents into the collection of 
opinions.

Guys, I tried it out a couple of weeks ago (was told about it by one of my 
colleagues). This is really incredible! Especially given that you completed it 
in 24 hours :) I think as YAQL attracts more and more users it will be very 
handy tool. I am actually for improving it further.

Thanks a lot! Looking forward to switch to yaql 1.0!

Renat Akhmerov
@ Mirantis Inc.



 On 05 Aug 2015, at 04:09, Stan Lagun sla...@mirantis.com wrote:
 
 Dmitry, 
 
 yaql 1.0 has both str() and len() and much much more so there is no need to 
 support them explicitly since Mistral is going to switch to yaql 1.0 and 
 yaqluator.com http://yaqluator.com/ is going to do the same
 
 Sincerely yours,
 Stan Lagun
 Principal Software Engineer @ Mirantis
 
  mailto:sla...@mirantis.com
 On Tue, Aug 4, 2015 at 8:55 PM, Dmitri Zimine dzim...@stackstorm.com 
 mailto:dzim...@stackstorm.com wrote:
 Awesome! Really.
 
 Thank you folks for doing this. 
 
 I am so much looking forward to moving it to 1.0 with more built-in functions 
 and more power to extend it...
 
 Note that Mistral has a few extensions, like `str`, `len`, which are not in 
 the scope of evaluator.
 
 DZ 
 
 
 On Aug 2, 2015, at 12:44 PM, Stan Lagun sla...@mirantis.com 
 mailto:sla...@mirantis.com wrote:
 
 Guys, this is awesome!!!
 
 Happy to see yaql gets attention. One more initiative that you may find 
 interesting is https://review.openstack.org/#/c/159905/ 
 https://review.openstack.org/#/c/159905/
 This is an attempt to port yaql 1.0 from Python to JS so that the same can 
 be done in browser
 
 Sincerely yours,
 Stan Lagun
 Principal Software Engineer @ Mirantis
 
  mailto:sla...@mirantis.com
 On Sun, Aug 2, 2015 at 5:30 PM, Nikolay Makhotkin nmakhot...@mirantis.com 
 mailto:nmakhot...@mirantis.com wrote:
 Hi guys! 
 
 That's awesome! It is very useful for all us!
 
 -- 
 Best Regards,
 Nikolay
 
 __
 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 
 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 
 mailto:openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
 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://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
 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] [openstack][magnum][heat]problems for synchronizing stack parameters from heat

2015-08-14 Thread Clint Byrum

Excerpts from 王华's message of 2015-08-14 00:52:43 -0700:
 Hi all,
 
 Magnum creates a stack when a bay is created and update the stack
 parameters when the bay is updated. Magnum has a periodic task
 to synchronize stack status from heat.
 And now we want to synchronize  stack parameters from heat, too. But heat
 don't allow admin user to show stack in other tenants, so we can not get
 stack parameters.
 
 I think it is necessary. Nova allows admin user to show instance in other
 tenants. Neutron allow admin user to show port in other tenants. Nova uses
 it to synchronize network info for instance from neutron. So can heat allow
 admin user to show stack in other tenants?
 

This seems like a problem for trusts to solve. Why are you not using
trusts to fetch the stack _as the user_?

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

Re: [openstack-dev] [devstack] Possible issues cryptography 1.0 and os-client-config 1.6.2

2015-08-14 Thread Robert Collins

On 14 August 2015 at 20:31, Chris Dent chd...@redhat.com wrote:
On Thu, 13 Aug 2015, Sean M. Collins wrote:

Do we want to make it a default to True for users of DevStack? I think
it may be worth considering since I'm not familiar with this issue
with crypto and having something that protects devs who are trying to
work on stuff and using DevStack , sounds good. Less cryptic day to
day breakage for new developers just getting started and using
DevStack is a goal I have, long term (where possible).

While I understand the practical considerations of using upper
constraints in the gate I think using them locally when doing the
dev part of using devstack has some unintended consequences that
we need to think about (assuming my implicit conclusion below is
correct).

The main issue is that it moves our use of all these libraries from
a position of participation to consumption. If we are only using
known-good constrained libs then we are not being a part of the
broader ecosystem that finds and fixes bugs in Python libraries.

It has little effect on that at all.

That may seem a bit esoteric or idealistic but it is one of the
aspects of open source collaboration that I think is truly great:
project evolution as a result of cross-pollination.

It makes 2500 developers all hit the same problem at the same time.
Thats not cross-pollination, its a flash mob :)

This is not to say that I'm not sympathetic to the problem of
cryptic day to day breakage. It's a significant issue but I'm not
sure the way to fix that problem is by becoming more static.
Breakage is a bug, it needs to be visible so it can be fixed, not
masked.

Its visible: follow
https://review.openstack.org/#/q/status:open+project:openstack/requirements+branch:master+topic:openstack/requirements/constraints,n,z
(I don't know if you can make gerrit mail on just those reviews), and
you'll see the bot updates that tries the latest release of everything
in the gate. If it passes, we use it. If it fails, we report it as a
bug.

Fire drills are not worth the benefit of making incompatible upstream
releases be disruptive. Signal is important, stress is harmful: we
want signal without stress IMO.

-Rob

--
Robert Collins rbtcoll...@hp.com
Distinguished Technologist
HP Converged Cloud

Re: [openstack-dev] [magnum]password for registry v2

The expire time is determined by keystone. Keystone do not allow users to
change it. So it is impossible to get a token which has no expiry.

On Fri, Aug 14, 2015 at 10:42 AM, Adrian Otto adrian.o...@rackspace.com
wrote:

 You can specify the timeout when you create it, so it is possible to make
 one that effectively has no expiry.

 --
 Adrian

 On Aug 13, 2015, at 7:36 PM, 王华 wanghua.hum...@gmail.com wrote:

 Will the scoped swift trust token time out?

 Regards,
 Wanghua

 On Fri, Aug 14, 2015 at 10:11 AM, Adrian Otto adrian.o...@rackspace.com
 wrote:

 Keystone v3 trusts can be scoped to specific actions. In this case the
 node needs a valid auth token to use swift. The token can be a trust token.
 We should generate a trust token scoped to swift for a given user (project)
 and tenant. It can use a system domain account that has a role that allows
 it to CRUD objects in a particular swift storage container. Then the
 registry v2 software can use the swift trust token to access swift, but not
 other OpenStack services. Depending on the trust enforcement available in
 swift, it may even be possible to prevent creation of new swift storage
 containers. We could check to be sure.

 The scoped swift trust token can be injected into the bay master at
 creation time using cloud-init.

 --
 Adrian

 On Aug 13, 2015, at 6:46 PM, 王华 wanghua.hum...@gmail.com wrote:

 Hi hongbin,
 I have comments in line.

 Thank you.

 Regards,
 Wanghua

 On Fri, Aug 14, 2015 at 6:20 AM, Hongbin Lu hongbin...@huawei.com
 wrote:

 Hi Wanghua,



 For the question about how to pass user password to bay nodes, there are
 several options here:

 1.   Directly inject the password to bay nodes via cloud-init. This
 might be the simplest solution. I am not sure if it is OK in security
 aspect.

 2.   Inject a scoped Keystone trust to bay nodes and use it to
 fetch user password from Barbican (suggested by Adrian).

 If we use trust, who we should let user trust?  If we let user trust
 magnum, then the credential of magnum will occur in vm. I think it is
 insecure.

 3.   Leverage the solution proposed by Kevin Fox [1]. This might be
 a long-term solution.



 For the security concerns about storing credential in a config file, I
 need clarification. What is the config file? Is it a dokcer registry v2
 config file? I guess the credential stored there will be used to talk to
 swift. Is that correct? In general, it is

 The credential stored in docker registry v2 config file is used to talk
 to swift.


 insecure to store user credential inside a VM, because anyone can take a
 snapshot of the VM and boot another VM from the snapshot. Maybe storing a
 scoped credential in the config file could mitigate the security risk. Not
 sure if there is a better solution.



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



 Best regards,

 Hongbin



 *From:* 王华 [mailto:wanghua.hum...@gmail.com]
 *Sent:* August-13-15 4:06 AM
 *To:* OpenStack Development Mailing List (not for usage questions)
 *Subject:* [openstack-dev] [magnum]password for registry v2



 Hi all,



 In order to add registry v2 to bay nodes[1], authentication information
 is needed for the registry to upload and download files from swift. The
 swift storage-driver in registry now needs the parameters as described in
 [2]. User password is needed. How can we get the password?



 1. Let user pass password in baymodel-create.

 2. Use user token to get password from keystone



 Is it suitable to store user password in db?



 It may be insecure to store password in db and expose it to user in a
 config file even if the password is encrypted. Heat store user password in
 db before, and now change to keystone trust[3]. But if we use keystone
 trust, the swift storage-driver does not support it. If we use trust, we
 expose magnum user's credential in a config file, which is also insecure.



 Is there a secure way to implement this bp?



 [1] https://blueprints.launchpad.net/magnum/+spec/registryv2-in-master

 [2]
 https://github.com/docker/distribution/blob/master/docs/storage-drivers/swift.md

 [3] https://wiki.openstack.org/wiki/Keystone/Trusts



 Regards,

 Wanghua


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

Re: [openstack-dev] [openstack][magnum][heat]problems for synchronizing stack parameters from heat

We can get stacks by stack list call, but it does not provide info about
stack parameters. If we need stack parameters, we have to use stack.get.

Regards,
Wanghua

On Fri, Aug 14, 2015 at 4:30 PM, Thomas Herve the...@redhat.com wrote:



  Hi all,
 
  Magnum creates a stack when a bay is created and update the stack
  parameters when the bay is updated. Magnum has a periodic task
  to synchronize stack status from heat.
  And now we want to synchronize  stack parameters from heat, too. But heat
  don't allow admin user to show stack in other tenants, so we can not get
  stack parameters.

 That's not true. You just need to pass the appropriate option,
 global_tenant, in your list call.

 Regards,

 --
 Thomas

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

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

Re: [openstack-dev] [openstack][magnum][heat]problems for synchronizing stack parameters from heat

2015-08-14 Thread 英哲

Can this option be used for in show stack details call?

 Date: Fri, 14 Aug 2015 04:30:19 -0400
 From: the...@redhat.com
 To: openstack-dev@lists.openstack.org
 Subject: Re: [openstack-dev] [openstack][magnum][heat]problems for 
 synchronizing stack parameters from heat

  Hi all,

  Magnum creates a stack when a bay is created and update the stack
  parameters when the bay is updated. Magnum has a periodic task
  to synchronize stack status from heat.
  And now we want to synchronize  stack parameters from heat, too. But heat
  don't allow admin user to show stack in other tenants, so we can not get
  stack parameters.

 That's not true. You just need to pass the appropriate option, 
 global_tenant, in your list call.

 Regards,

 -- 
 Thomas

 __
 OpenStack Development Mailing 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] [Monasca] Minutes for Monasca mid-cycle meetup

2015-08-14 Thread Dexter Fryar

 From: ildiko.van...@ericsson.com
 To: openstack-dev@lists.openstack.org
 Date: Fri, 14 Aug 2015 12:57:27 +
 Subject: Re: [openstack-dev] [Monasca] Minutes for Monasca mid-cycle meetup

 Hi,

 I will try to join if I can, I have an overlapping meeting on Tuesdays.

 In general I think it would be really good to start a closer collaboration, 
 the componentization work in Ceilometer gives a really good opportunity as 
 Chris described.

 Best Regards,
 Ildikó

  -Original Message-
  From: Chris Dent [mailto:chd...@redhat.com]
  Sent: August 12, 2015 15:45
  To: OpenStack Development Mailing List (not for usage questions)
  Subject: Re: [openstack-dev] [Monasca] Minutes for Monasca mid-cycle meetup

  On Tue, 11 Aug 2015, Hochmuth, Roland M wrote:

   It sounds like we should connect up soon. I could attend a Ceilometer
   meeting, or you could attend the Monasca meeting which is held Tuesday
   mornings at 9:00 MST.

  I'm away this coming Tuesday, but perhaps some of the other Ceilo people 
  could show up? I've got it on my schedule to come the
  week after.

  I suspect there's a lot we can do over the long run to avoid duplicating 
  code and effort but that there will be some humps to ride over
  to different pieces (and people!) talking to one another.
  Should be fun. Looking forward to it.

  --
  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
  __
OpenStack Development Mailing 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][Puppet] Keystone V2/V3 service endpoints

2015-08-14 Thread Rich Megginson

On 08/14/2015 06:51 AM, Matthew Mosesohn wrote:

Gilles,

I already considered this when looking at another openstackclient
issue. Version 1.0.4 has almost no changes from 1.0.3, which is the
official release for Kilo. Maybe we can get this keystone URL handling
fix backported to the 1.0.X branch of openstackclient?

I think we need some sort of fix in openstacklib and/or puppet-keystone
so that v3 providers that use token auth can replace any /v2.0 in the
url with /v3, to override any settings of OS_URL or OS_AUTH_URL in ENV
or openrc.

-Matthew

On Fri, Aug 14, 2015 at 3:47 PM, Gilles Dubreuil gil...@redhat.com
mailto:gil...@redhat.com wrote:

On 14/08/15 20:45, Gilles Dubreuil wrote:

On 13/08/15 23:29, Rich Megginson wrote:
On 08/13/2015 12:41 AM, Gilles Dubreuil wrote:
Hi Matthew,

On 11/08/15 01:14, Rich Megginson wrote:
On 08/10/2015 07:46 AM, Matthew Mosesohn wrote:
Sorry to everyone for bringing up this old thread, but it
seems we may
need more openstackclient/keystone experts to settle this.

I'm referring to the comments in
https://review.openstack.org/#/c/207873/
Specifically comments from Richard Megginson and Gilles Dubreuil
indicating openstackclient behavior for v3 keystone API.

A few items seem to be under dispute:
1 - Keystone should be able to accept v3 requests at
http://keystone-server:5000/http://keystone-server:5000/
I don't think so. Keystone requires the version suffix
/v2.0 or
/v3.

Yes, if the public endpoint is set without a version then the
service
can deal with either version.

http://paste.openstack.org/raw/412819/

That is not true for the admin endpoint (authentication is
already done,
the admin services deals only with tokens), at least for now,
Keystone
devs are working on it.

I thought it worked like this - the openstack cli will infer
from the
arguments if it should do v2 or v3 auth. In the above case for v3,
since you specify the username/password, osc knows it has to use
password auth (as opposed to token auth), and since all of the
required
v3 arguments are provided (v3 api version, domains for
user/project), it
can use v3 password auth. It knows it has to use the
/v3/auth/token
path to get a token.

Similarly for v2, since it only has username/password, no v3
api or v3
domain arguments, it knows it has to use v2 password auth. It
knows it
has to use /v2.0/token to get a token.

With the puppet-keystone code, since it uses TOKEN/URL, osc
cannot infer
if it can use v2 or v3, so it requires the /v2.0 or /v3
suffix, and
the api version.

First of my apologies because I confused admin enpdoint with the
admin
service (or whatever that's dubbed).

As of Keystone v3 (not the API, the latest version of Keystone which
supports both API v2.0 and V3), the OS_AUTH_URL doesn't need the
version. That can be effectively any of the endpoints, either
the main
(or public) by default on port 5000 or the admin by default on port
35357, the third one internal pointing to either of the first
two ones.

This is a behavior at Keystone level not at the OSC. I mean OSC will
just reflect the http-api behavior.

Now the admin service, the one needed for the OS-TOKEN (used for
bootstrapping) needs a URL (OS_URL) with a version to work.

ATM, the issue with puppet keystone is that endpoints, OS_URL and
OS_AUTH_URL are walking on each others.

My latest update on this one, is that I found out while testing beaker
which is using OSC 1.0.3 is not handling OS_AUTH_URL properly.

I had been testing with OSC 1.5.1 and now latest 1.6.1 from Dolerean
repo, where the version-less URLs are working, but not with OSC 1.0.1:

# cat openrc
export OS_AUTH_URL=http://127.0.0.1:5000
export OS_USERNAME=adminv3
export OS_PASSWORD=testing
export OS_PROJECT_NAME=openstackv3
export OS_USER_DOMAIN_NAME=admin_domain
export OS_PROJECT_DOMAIN_NAME=admin_domain
export OS_IDENTITY_API_VERSION=3

# openstack endpoint list -f csv
ID,Region,Service Name,Service
Type,Enabled,Interface,URL

87b7db1b23df487bb4ec96de5aa3c271,RegionOne,keystone,identity,True,internal,http://127.0.0.1:5000;

d9b345109d8a4320ac0dd832d2532cce,RegionOne,keystone,identity,True,admin,http://127.0.0.1:35357;

f3a579a64f0241ef9aef3dc983e0fd4a,RegionOne,keystone,identity,True,public,http://127.0.0.1:5000;

# cat openrc_v2
export OS_AUTH_URL=http://[::1]:5000
export OS_USERNAME=admin
export OS_PASSWORD=a_big_secret
export OS_TENANT_NAME=openstack

# openstack endpoint list -f csv --long

Re: [openstack-dev] [cinder] Proposing Gorka Eguileor for core

2015-08-14 Thread yang, xing

+1


On 8/13/15, 3:13 PM, Mike Perez thin...@gmail.com wrote:

It gives me great pleasure to nominate Gorka Eguileor for Cinder core.

Gorka's contributions to Cinder core have been much apprecated:

https://review.openstack.org/#/q/owner:%22Gorka+Eguileor%22+project:openst
ack/cinder,p,0035b6410002dd11

60/90 day review stats:

http://russellbryant.net/openstack-stats/cinder-reviewers-60.txt
http://russellbryant.net/openstack-stats/cinder-reviewers-90.txt

Cinder core, please reply with a +1 for approval. This will be left
open until August 19th. Assuming there are no objections, this will go
forward after voting is closed.

-- 
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 Development Mailing 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][kuryr][magnum] Design Specification for Kuryr

2015-08-14 Thread Adrian Otto

The port mapping feature is the -p flag on the docker run command. It 
determines which ports in the network namespace of the container are exposed to 
the root namespace. It configures iptables rules and docker proxy capabilities 
to achieve the desired result. This feature is essential, so we must not break 
it.

In other words, this feature is what allows a network port within a container 
to be externally accessed, and on what IP address(es) and port number(s) on the 
host.

Example:

docker run -d -p 12.34.56.7:8000:80 nginx:latest

This runs the nginx container and exposes top port 80 from inside the container 
to tcp port 8000 on 12.34.56.7 on the host. Without this feature docker is 
rather useless for running network services unless you use -net host or an 
equivalent workaround. This could break a lot of tooling that depends on -p.

--
Adrian

On Aug 14, 2015, at 6:57 AM, Gal Sagie 
gal.sa...@gmail.commailto:gal.sa...@gmail.com wrote:

Hi feisky,

I think thats a great question, not because of port-mapping in particular :) 
but because
we need to think on a feature by feature basis and map all the features the 
dockers API allow which
we cannot support directly with Neutron API or its services sub-projects API.
(apuimedo, maybe we need to set this as a future task for us)

But we also need to understand the use cases for supporting these API's so we 
can address them
and give them priorities (and this is something we as a community need to 
decide how to handle).

For your question, given that we have network isolation and security from 
neutron API's and given
we have NAT support (by Neutron API and the plugins implementing the network) , 
what do you see as a use case to use the port-mapping ?

I welcome you and everyone else to raise and describe these use cases so the 
Neutron/Kuryr community can think
how to solve and help, and if needed also adjust or add extensions for support.

Thanks
Gal.


On Fri, Aug 14, 2015 at 7:28 AM, feisky 
feisk...@gmail.commailto:feisk...@gmail.com wrote:
Will Kuryr supports docker's port-mapping?



--
View this message in context: 
http://openstack.10931.n7.nabble.com/neutron-kuryr-magnum-Design-Specification-for-Kuryr-tp82256p82299.html
Sent from the Developer mailing list archive at Nabble.comhttp://Nabble.com.

__
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



--
Best Regards ,

The G.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.orgmailto: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] [swift] container DB movement to another

2015-08-14 Thread John Dickinson

There isn't currently any way to directly move a container DB from one drive to
another. As you said, the placement is based on the hash of the container name,
so you can't change that.

One thing you can do is lower the weight of the drive that is very busy. This
will cause less partitions to be placed there and lower the overall load on
that particular drive. This is not a panacea though. The load will simply move
to other hardware in the cluster. If you're lucky, then you'll have the larger
container DB on a less busy drive.

I'd strongly recommend that you deploy flash storage for accounts and
containers. This will help alleviate these sorts of problems, and it's
generally the cheapest way for an operator to resolve these sorts of problems.

If it's possible, you should see if you can get the end-user to use many
containers instead of one container. Spreading the load around the system to
more containers is a best-practice for using Swift.

Longer-term, we're talking about how to scale container resources in Swift.
This week at the Swift midcycle hackathon, we talked about some ideas on how to
transparently shard the container DBs. However, implementing it is a large
amount of work that will take a while to complete.

I hope these suggestions help.

--John

On Aug 11, 2015, at 4:38 PM, Senthil senthi...@gmail.com wrote:

Hi,

Are you currently using same disks/nodes for container and object storage ?
http://docs.openstack.org/openstack-ops/content/maintenance.html
talks about replacing storage nodes. The same instructions applies to
container db as well.You need to apply the changes to container ring and push
it out. You will be able to move container db to different server or
relocate container db to different disk

Hope it helps

Senthil

On Tue, Aug 11, 2015 at 2:39 PM, Jinkyung Hwang jinkyung.hw...@kt.com wrote:
Hello,

Is there any method to move A container DB to another container server of
different physical disk of original one ?

I have a very large container (having 70 million objects).
This container IO makes other customer's container read/write operation very
slow, so I'd like to move it to another location that is more idle.

BUT Swift URL is made with MD5 Hash and it cannot be modifiable.

How can I move the container DB ? Or is there any method to use something
like 'link' ?

It would be appreciated if you share any ideas.

Thank you

Jinkyung Hwang

이 메일은 지정된 수취인만을 위해 작성되었으며, 중요한 정보나 저작권을 포함하고 있을 수 있습니다. 어떠한 권한 없이, 본 문서에 포함된
정보의 전부 또는 일부를 무단으로 제3자에게 공개, 배포, 복사 또는 사용하는 것을 엄격히 금지합니다. 만약, 본 메일이 잘못 전송된
경우, 발신인 또는 당사에 알려주시고, 본 메일을 즉시 삭제하여 주시기 바랍니다.
This E-mail may contain confidential information and/or copyright material.
This email is intended for the use of the addressee only. If you receive this
email by mistake, please either delete it without reproducing, distributing
or retaining copies thereof or notify the sender immediately.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

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] [Keystone] [Horizon] Pagination support for Identity dashboard entities

2015-08-14 Thread Jay Pipes


On 08/14/2015 09:14 AM, Morgan Fainberg wrote:

As a quick note the api-ref you are linking to has some gaps/has not
been kept in sync with the official api specifications.

The official API specification is located at
http://specs.openstack.org/openstack/keystone-specs/ (v2 and v3 sections
at the top) and there is a known open bug to work with the docs team to
get this in sync (somehow).

Unfortunately there are a number of cases especially with the identity
backend where pagination just does not work (or works completely
unreliably) such as utilizing the ldap driver. Either a cursor must be
maintained (problematic in REST) or the results could be wildly
different every single request meaning each page is not really
guaranteed to be the next page it could be the same/show inconsistent
results. The second issue is that the pagination is not a good UX even
where it works - the simple question is: if you can filter the results
how many pages deep do you go before refining the query; think of your
use of search engines.

In light of these issues Keystone has opted for a filter / limit
(config). If the results exceed the limit there is a truncation that
occurs and it is recommended extra filtering be applied to reduce the
total number of results.

This discussion has gone around a few times, pagination in keystone is
not currently on the roadmap. In addition to the above doc bug, we
should work to better socialize this filter-over-paginate methodology.


I understand all the things you write above about the problems that 
Keystone's underlying architecture (driver-based, not always able to do 
pagination in the individual drivers). However, it really does mean that 
Keystone is the only project in OpenStack that behaves this way. All 
other services provide limit/marker paginations, AFAIK, which is 
efficient and, while not the same UX as a filtering methodology, is 
entirely compatible and complementary to filtering.


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] [kolla] Proposing Swapnil Kulkarni (coolsvap) for kolla core reviewer team

2015-08-14 Thread Jeff Peeler


On Fri, Aug 14, 2015 at 01:29:10PM +, Steven Dake (stdake) wrote:

Hi folks,

Swapnil has done a bunch of great technical work, participates heavily 
in IRC, and has contributed enormously to the implementation of Kolla.  
I’d like to see more reviews from Swapnil, but he has committed to 
doing more reviews and already has gone from something like 0 reviews 
to 90 reviews in about a month.  Count this proposal as a +1 from me.


His 90 day stats are:
http://stackalytics.com/report/contribution/kolla-group/90

The process we go to select new core reviewers is that we require a 
minimum of 3 +1 votes within a 1 week voting window.  A vote of –1 is a 
veto.  It is fine to abstain as well without any response to this 
email.  If the vote is unanimous or there is a veto vote prior to the 
end of the voting window, I’ll close voting then.


The voting is open until Friday August 21st.


+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] [cinder] Proposing Gorka Eguileor for core

2015-08-14 Thread Eric Harney

On 08/13/2015 03:13 PM, Mike Perez wrote:
 It gives me great pleasure to nominate Gorka Eguileor for Cinder core.

 Cinder core, please reply with a +1 for approval. This will be left
 open until August 19th. Assuming there are no objections, this will go
 forward after voting is closed.
 

+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] [neutron] What does being a neutron-core member mean? [WAS: Re: [neutron] I am pleased to propose two new Neutron API/DB/RPC core reviewers!]

2015-08-14 Thread Kyle Mestery

On Fri, Aug 14, 2015 at 10:00 AM, Flavio Percoco fla...@redhat.com wrote:

 On 14/08/15 10:42 -0400, Assaf Muller wrote:

 First I'd like to say that I recognize that this discussion is incredibly
 personal. Brandon and Russell, please do not be offended, but I know that
 I
 probably would be if this very public thread involved myself. That being
 said,
 please know that from my perspective this is *not* personal, rather I see
 this
 as a general discussion about the precedent that we are creating here.

 Responses in-line.

 On Fri, Aug 14, 2015 at 9:32 AM, Kyle Mestery mest...@mestery.com
 wrote:

On Fri, Aug 14, 2015 at 6:29 AM, Ihar Hrachyshka ihrac...@redhat.com
wrote:
  it feels to me that leaving neutron-core group as a meta-group
 that
includes everyone who makes significant positive impact in any of
those repos is not optimal.

  This is where I'd disagree. I think in general teams pay too much
 attention
to stats, which are incredibly easy to game. Case in point, with the
current objections people have over Brandon and Russell being
 nominated, I
could have waited 4-6 weeks and let them amass a plethora of review
 stats,
but what would the point of that have been?


 None what so ever. I think the point here is that if someone is focusing
 on
 another project then it's debatable if they should become a core in the
 Neutron
 project itself. Very simply put, if someone is a core in a subproject and
 is
 doing a fantastic job, but that person is not truly involved in the
 Neutron
 project itself, then that person becoming core in Neutron to me is
 dangerous.
 Before someone becomes core, I would like to be familiar with their
 expertise
 in Neutron so that I know if to trust their +2 or not on a given area in
 Neutron. If that person didn't really focus on Neutron then I have no way
 of
 being familiar with their expertise, thus no ability to trust them even
 if I'm
 generally a trusting person.


 I'm not really familiar with Neutron's workflow but as an outsider and
 also based on my experience from other projects, the separation of
 concerns from a review perspective is very useful. Teams that govern
 several projects are be better off giving reviewing rights to folks
 in a per-project basis rather than doing it cross-team.

 I'd go as far as saying that folks with review rights in the server
 don't necessarily need to have review rights in smaller projects. The
 reason I'm saying this is because I believe that reviewer rights is
 not a prize but a volunteer job. The moment I'm asked whether I want
 to join a reviewers team in a project, I gotta be honest with what my
 available time will allow me to do.


What you just said is what I've been trying to emphasize my entire time as
PTL: Reviewing is a duty, not a prize. The thing we're discussing here is
the issue of when to give someone +2 rights. I'm arguing in favor of a web
of trust system, which is what we have with Lieutenants. I'm also saying
that I'm a proponent of elevating folks who want to take on the duty and
letting them do that before they spend a month building up stats. This is
not an opinion shared by everyone I realize, but it's my opinion.

Like I've said in this thread, the entire system is built on trust. We as a
community need to trust more and rely on that trust. I feel as if I've
spent my PTL time trying to build that up and instill this value into the
Neutron community. The results speak for themselves at this point, but I'm
proud of what *we* as a community have built here.

Kyle


 To what I just said, I'd also add the familiarity with the code-base,
 etc.

 Just my $0.02,
 Flavio



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


__
OpenStack Development Mailing 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] What does being a neutron-core member mean? [WAS: Re: [neutron] I am pleased to propose two new Neutron API/DB/RPC core reviewers!]

2015-08-14 Thread Kyle Mestery

On Fri, Aug 14, 2015 at 9:42 AM, Assaf Muller amul...@redhat.com wrote:

 First I'd like to say that I recognize that this discussion is incredibly
 personal. Brandon and Russell, please do not be offended, but I know that I
 probably would be if this very public thread involved myself. That being
 said, please know that from my perspective this is *not* personal, rather I
 see this as a general discussion about the precedent that we are creating
 here.

 Responses in-line.

 On Fri, Aug 14, 2015 at 9:32 AM, Kyle Mestery mest...@mestery.com wrote:

 On Fri, Aug 14, 2015 at 6:29 AM, Ihar Hrachyshka ihrac...@redhat.com
 wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 Thanks a lot for the reply! I think it raises some good points here
 that I would like to clarify with other team members. I don't think
 those should interface with the current nomination run, so I spin it
 into a separate thread.


 Absolutely! I think it's super healthy to have these discussions, it's
 what healthy open source communities do. I'll answer your specific concerns
 below.


 Some comments inline.

 On 08/12/2015 07:16 PM, Kyle Mestery wrote:
  [1] http://stackalytics.com/report/contribution/neutron-group/90
 
 
  Shouldn't we use the link that shows neutron core repo
  contributions only? I think this is the right one:
 
  http://stackalytics.com/report/contribution/neutron/90
 
 
  Sure, if you want to look at only the neutron repo. I tend to
  look at people across all of our repos, which you may or may not
  agree with. I

 Neutron-core gerrit group indeed always had a vague definition. It
 worked fine before when we had just neutron and python-neutronclient
 repositories [even though client expertise stands out somewhat of
 usual server oriented development we do in neutron repo].


 Agreed. And on that note, I think it may make sense to separate out
 client merge responsibilities from server ones, as there are typically
 hardly any core reviewers for neutron who pay attention to the client at
 this point.


 Now, with successful tree split into neutron, neutron-*aas,
 networking-*, + having a separate repo for specs; now that neutron is
 really a meta-project (a big tent they say),


 Nope, it's the Neutron Stadium, the Big Tent moniker was already
 taken, so we came up with our own. ;)


 it feels to me that leaving neutron-core group as a meta-group that
 includes everyone who makes significant positive impact in any of
 those repos is not optimal.


 This is where I'd disagree. I think in general teams pay too much
 attention to stats, which are incredibly easy to game. Case in point, with
 the current objections people have over Brandon and Russell being
 nominated, I could have waited 4-6 weeks and let them amass a plethora of
 review stats, but what would the point of that have been?


 None what so ever. I think the point here is that if someone is focusing
 on another project then it's debatable if they should become a core in the
 Neutron project itself. Very simply put, if someone is a core in a
 subproject and is doing a fantastic job, but that person is not truly
 involved in the Neutron project itself, then that person becoming core in
 Neutron to me is dangerous. Before someone becomes core, I would like to be
 familiar with their expertise in Neutron so that I know if to trust their
 +2 or not on a given area in Neutron. If that person didn't really focus on
 Neutron then I have no way of being familiar with their expertise, thus no
 ability to trust them even if I'm generally a trusting person.



I'd argue the system is built on a web of trust. If you trust me, and I
trust Russell and Brandon, then you should likely trust Russell and Brandon
as well. This is EXACTLY what the Lieutenant system was meant to convey,
though I now feel like perhaps people missed this key ingredient of the new
world we find ourselves in.


 I trust both of them to merge code, they have both proven it in other
 Neutron projects (Brandon) and other OpenStack project (Russell). A month
 of collecting meaningless stats doesn't help anyone. Further, if either of
 them takes advantage of their merge responsibilities in anyway, we'll
 remove them. We're a community that is self governed and built on trust and
 integrity, breaching that will lead to extreme measures.


 Having core team members that are judged solely on how they impact the
 core repo seems to me a better approach. Fostering more focused teams
 was one of the goals of tree splits, so I think we should take that
 gerrit advantage of having multiple repos more seriously.


 I'm not disagreeing with you here, but to your point below about areas
 of focus, it's harder than it looks. We're working within the confines of
 the tools we have. I'm not saying you're incorrect in your assumption here
 at all. Going back to Russell and Brandon, if they don't start reviewing at
 a decent pace, we should remove their merge capabilities, as we should any
 core who doesn't

Re: [openstack-dev] [neutron] What does being a neutron-core member mean? [WAS: Re: [neutron] I am pleased to propose two new Neutron API/DB/RPC core reviewers!]


On 14/08/15 10:14 -0500, Kyle Mestery wrote:

On Fri, Aug 14, 2015 at 10:00 AM, Flavio Percoco fla...@redhat.com wrote:

   On 14/08/15 10:42 -0400, Assaf Muller wrote:
  
   First I'd like to say that I recognize that this discussion is

   incredibly
   personal. Brandon and Russell, please do not be offended, but I know
   that I
   probably would be if this very public thread involved myself. That
   being said,
   please know that from my perspective this is *not* personal, rather I
   see this
   as a general discussion about the precedent that we are creating here.

   Responses in-line.

   On Fri, Aug 14, 2015 at 9:32 AM, Kyle Mestery mest...@mestery.com
   wrote:

      On Fri, Aug 14, 2015 at 6:29 AM, Ihar Hrachyshka 
   ihrac...@redhat.com
      wrote:
            it feels to me that leaving neutron-core group as a
   meta-group that
          includes everyone who makes significant positive impact in any
   of
          those repos is not optimal. 

        This is where I'd disagree. I think in general teams pay too much
   attention
      to stats, which are incredibly easy to game. Case in point, with the
      current objections people have over Brandon and Russell being
   nominated, I
      could have waited 4-6 weeks and let them amass a plethora of review
   stats,
      but what would the point of that have been?


   None what so ever. I think the point here is that if someone is
   focusing on
   another project then it's debatable if they should become a core in the
   Neutron
   project itself. Very simply put, if someone is a core in a subproject
   and is
   doing a fantastic job, but that person is not truly involved in the
   Neutron
   project itself, then that person becoming core in Neutron to me is
   dangerous.
   Before someone becomes core, I would like to be familiar with their
   expertise
   in Neutron so that I know if to trust their +2 or not on a given area
   in
   Neutron. If that person didn't really focus on Neutron then I have no
   way of
   being familiar with their expertise, thus no ability to trust them even
   if I'm
   generally a trusting person.
  


   I'm not really familiar with Neutron's workflow but as an outsider and
   also based on my experience from other projects, the separation of
   concerns from a review perspective is very useful. Teams that govern
   several projects are be better off giving reviewing rights to folks
   in a per-project basis rather than doing it cross-team.

   I'd go as far as saying that folks with review rights in the server
   don't necessarily need to have review rights in smaller projects. The
   reason I'm saying this is because I believe that reviewer rights is
   not a prize but a volunteer job. The moment I'm asked whether I want
   to join a reviewers team in a project, I gotta be honest with what my
   available time will allow me to do.



What you just said is what I've been trying to emphasize my entire time as PTL:
Reviewing is a duty, not a prize. The thing we're discussing here is the issue
of when to give someone +2 rights. I'm arguing in favor of a web of trust
system, which is what we have with Lieutenants. I'm also saying that I'm a
proponent of elevating folks who want to take on the duty and letting them do
that before they spend a month building up stats. This is not an opinion shared
by everyone I realize, but it's my opinion.

Like I've said in this thread, the entire system is built on trust. We as a
community need to trust more and rely on that trust. I feel as if I've spent my
PTL time trying to build that up and instill this value into the Neutron
community. The results speak for themselves at this point, but I'm proud of
what *we* as a community have built here.


Different projects follow different rules. Some projects favor stats,
others favor enthusiasm and try to build a stronger community based on
that.

I just wanted to say that I personally favor building a web of trust
rather than relying *just* on stats!

Flavio



Kyle
 

   To what I just said, I'd also add the familiarity with the code-base,
   etc.

   Just my $0.02,
   Flavio



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


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

Re: [openstack-dev] [sahara] Proposing Ethan Gafford for the core reviewer team


On 14/08/15 09:29 -0400, Trevor McKay wrote:

Hi Telles,

you technically don't get a vote, but thanks anyway :)


Hi Trevor,

Technically, everyone gets to vote and speak up. Regardless of whether
you're a core-reviewer or not. Most of the time, non-core contributors
provide amazing feedback on what their experience has been while
receiving reviews from the nominated person.

Regardless of the comment, we as a community always welcome
contributor's opinions and encourage folks to speak up.

I knew your intentions are good but I thought it'd be a good time to
share the above so that it would work as a reminder for others as
well.

Thank you both and +1 for Ethan ;)
Flavio



Trev

On Fri, 2015-08-14 at 12:14 +, Telles Nobrega wrote:

+1

On Fri, Aug 14, 2015 at 7:11 AM Alexander Ignatov
aigna...@mirantis.com wrote:

+1

Regards,
Alexander Ignatov





 On 13 Aug 2015, at 18:29, Sergey Reshetnyak
 sreshetn...@mirantis.com wrote:

 +2

 2015-08-13 18:07 GMT+03:00 Matthew Farrellee
 m...@redhat.com:
 On 08/13/2015 10:56 AM, Sergey Lukjanov wrote:
 Hi folks,

 I'd like to propose Ethan Gafford as a
 member of the Sahara core
 reviewer team.

 Ethan contributing to Sahara for a long time
 and doing a great job on
 reviewing and improving Sahara. Here are the
 statistics for reviews
 [0][1][2] and commits [3]. BTW Ethan is
 already stable maint team core
 for Sahara.

 Existing Sahara core reviewers, please vote
 +1/-1 for the addition of
 Ethan to the core reviewer team.

 Thanks.

 [0]
 https://review.openstack.org/#/q/reviewer:%
 22Ethan+Gafford+%253Cegafford%2540redhat.com
 %253E%22,n,z
 [1]
 
http://stackalytics.com/report/contribution/sahara-group/90
 [2]
 http://stackalytics.com/?user_id=egaffordmetric=marks
 [3]
 https://review.openstack.org/#/q/owner:%
 22Ethan+Gafford+%253Cegafford%2540redhat.com
 %253E%22+status:merged,n,z

 --
 Sincerely yours,
 Sergey Lukjanov
 Sahara Technical Lead
 (OpenStack Data Processing)
 Principal Software Engineer
 Mirantis Inc.


 +1 ethan has really taken to sahara, providing
 valuable input to both development and deployments
 as well has taking on the manila integration



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

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


pgpqiDjymBWFb.pgp
Description: PGP signature
__
OpenStack

Re: [openstack-dev] [cinder] [third-party]RE: [OpenStack-Infra] ProphetStor CI account

2015-08-14 Thread Mike Perez

On 09:44 Aug 14, Rick Chen wrote:
 HI Mike:
   Sorry again, I already add email alert agent in our CI Jenkins
 server to capture each failed build result.
   [1] -
 http://lists.openstack.org/pipermail/third-party-announce/2015-June/000192.h
 tml
   [2] -
 http://lists.openstack.org/pipermail/third-party-announce/2015-June/000193.h
 tml
   Solution 1: Our Jenkins client machine is vmware machine, I already
 add snapshot revert script in the Jenkins Job script. Each git review job
 trigger the client will revert to  clean environment
 to solve this problem.
   Solution 2: I don't know whiched changed to make keystone unable to
 import pastedeploy. So I try to uninstall python-pastedeploy package in the
 local to solve some 
issue about unable to build devstack issue.
   Sorry again to disturb you.

Rick,

I looked at your CI results directory [1], but it looks like the last time this
ran was on July 28th according to the last modified dates. This should be
actively running even if you account is disabled from leaving comments, so
I can verify from the logs things are running fine again.

In addition, see Ramy's comments with issues with the CI [2].

[1] - http://download.prophetstor.com/prophetstor_ci/?C=M;O=A
[2] - 
http://lists.openstack.org/pipermail/openstack-infra/2015-August/003057.html

-- 
Mike Perez

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

Re: [openstack-dev] [neutron] What does being a neutron-core member mean? [WAS: Re: [neutron] I am pleased to propose two new Neutron API/DB/RPC core reviewers!]


On 14/08/15 10:42 -0400, Assaf Muller wrote:

First I'd like to say that I recognize that this discussion is incredibly
personal. Brandon and Russell, please do not be offended, but I know that I
probably would be if this very public thread involved myself. That being said,
please know that from my perspective this is *not* personal, rather I see this
as a general discussion about the precedent that we are creating here.

Responses in-line.

On Fri, Aug 14, 2015 at 9:32 AM, Kyle Mestery mest...@mestery.com wrote:

   On Fri, Aug 14, 2015 at 6:29 AM, Ihar Hrachyshka ihrac...@redhat.com
   wrote:
  
   it feels to me that leaving neutron-core group as a meta-group that

   includes everyone who makes significant positive impact in any of
   those repos is not optimal. 

  
   This is where I'd disagree. I think in general teams pay too much attention

   to stats, which are incredibly easy to game. Case in point, with the
   current objections people have over Brandon and Russell being nominated, I
   could have waited 4-6 weeks and let them amass a plethora of review stats,
   but what would the point of that have been?


None what so ever. I think the point here is that if someone is focusing on
another project then it's debatable if they should become a core in the Neutron
project itself. Very simply put, if someone is a core in a subproject and is
doing a fantastic job, but that person is not truly involved in the Neutron
project itself, then that person becoming core in Neutron to me is dangerous.
Before someone becomes core, I would like to be familiar with their expertise
in Neutron so that I know if to trust their +2 or not on a given area in
Neutron. If that person didn't really focus on Neutron then I have no way of
being familiar with their expertise, thus no ability to trust them even if I'm
generally a trusting person.


I'm not really familiar with Neutron's workflow but as an outsider and
also based on my experience from other projects, the separation of
concerns from a review perspective is very useful. Teams that govern
several projects are be better off giving reviewing rights to folks
in a per-project basis rather than doing it cross-team.

I'd go as far as saying that folks with review rights in the server
don't necessarily need to have review rights in smaller projects. The
reason I'm saying this is because I believe that reviewer rights is
not a prize but a volunteer job. The moment I'm asked whether I want
to join a reviewers team in a project, I gotta be honest with what my
available time will allow me to do.

To what I just said, I'd also add the familiarity with the code-base,
etc.

Just my $0.02,
Flavio



--
@flaper87
Flavio Percoco


pgpGiXIqLqCmO.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] [Keystone] [Horizon] Pagination support for Identity dashboard entities

For the identity (users and groups) backend as long as we support LDAP (and as 
side note federated users never show up in this list anyway) and with the drive 
towards pushing all user management out of keystone itself to ldap or other 
tools that do it better, I don't see pagination as something we should be 
providing. Providing an inconsistent user experience based on leaking 
underlying implementation details is something I am very against. This stance 
ensures that horizon and other tools like it will not need to know underlying 
implementation details to provide a consistent user experience. Unfortunately 
here we do need to cater to the lowest common denominator and 
filtering/searching/limiting is the clear common mechanism

With regards to resources (projects, domains, etc) since we no longer support 
using LDAP (deprecated with removal in mitaka) I have less strong feelings 
towards and wouldn't block efforts to implement if it is not already available 
(if not available this is likely a mitaka goal). 

--Morgan 

Sent via mobile

 On Aug 14, 2015, at 07:39, Jay Pipes jaypi...@gmail.com wrote:
 
 On 08/14/2015 09:14 AM, Morgan Fainberg wrote:
 As a quick note the api-ref you are linking to has some gaps/has not
 been kept in sync with the official api specifications.
 
 The official API specification is located at
 http://specs.openstack.org/openstack/keystone-specs/ (v2 and v3 sections
 at the top) and there is a known open bug to work with the docs team to
 get this in sync (somehow).
 
 Unfortunately there are a number of cases especially with the identity
 backend where pagination just does not work (or works completely
 unreliably) such as utilizing the ldap driver. Either a cursor must be
 maintained (problematic in REST) or the results could be wildly
 different every single request meaning each page is not really
 guaranteed to be the next page it could be the same/show inconsistent
 results. The second issue is that the pagination is not a good UX even
 where it works - the simple question is: if you can filter the results
 how many pages deep do you go before refining the query; think of your
 use of search engines.
 
 In light of these issues Keystone has opted for a filter / limit
 (config). If the results exceed the limit there is a truncation that
 occurs and it is recommended extra filtering be applied to reduce the
 total number of results.
 
 This discussion has gone around a few times, pagination in keystone is
 not currently on the roadmap. In addition to the above doc bug, we
 should work to better socialize this filter-over-paginate methodology.
 
 I understand all the things you write above about the problems that 
 Keystone's underlying architecture (driver-based, not always able to do 
 pagination in the individual drivers). However, it really does mean that 
 Keystone is the only project in OpenStack that behaves this way. All other 
 services provide limit/marker paginations, AFAIK, which is efficient and, 
 while not the same UX as a filtering methodology, is entirely compatible and 
 complementary to filtering.
 
 Best,
 -jay
 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [neutron][kuryr][magnum] Design Specification for Kuryr

2015-08-14 Thread Gal Sagie

Hi Adrian,

Thanks for the explanation, i agree with you that we shouldn't break
anything useful in docker, but from what i understand
(and please correct me if i am wrong) you are describing an implementation
detail of docker networking (at its default current state).

Kuryr is not an implementation of containers networking, it is meant to
allow docker networking to be
constructed using Neutron plugins and solutions.

For the point i was trying to make, lets take the simple case of connecting
containers in a host (not the nested VM case), assuming
we use with Kuryr the L2 OVS agent and L3 agent (Neutron reference
implementation) and we are able to plug
containers to a neutron network and define a floating ip to it, why would
we need port mapping? (the iptables
translation is already happening as we have NAT)

Hope that make sense, and please correct me if i am saying nonsense or i
didn't grasp the full
use case of port mapping.
But none the less, we will need to allow anything that docker allows and
keep compatibility with all the available tooling
that depends on it as you mention (and of course be flexible to use Kuryr
in the same environment with other
docker remote drivers)

Gal

On Fri, Aug 14, 2015 at 5:26 PM, Adrian Otto adrian.o...@rackspace.com
wrote:

 The port mapping feature is the -p flag on the docker run command. It
 determines which ports in the network namespace of the container are
 exposed to the root namespace. It configures iptables rules and docker
 proxy capabilities to achieve the desired result. This feature is
 essential, so we must not break it.

 In other words, this feature is what allows a network port within a
 container to be externally accessed, and on what IP address(es) and port
 number(s) on the host.

 Example:

 docker run -d -p 12.34.56.7:8000:80 nginx:latest

 This runs the nginx container and exposes top port 80 from inside the
 container to tcp port 8000 on 12.34.56.7 on the host. Without this feature
 docker is rather useless for running network services unless you use -net
 host or an equivalent workaround. This could break a lot of tooling that
 depends on -p.

 --
 Adrian

 On Aug 14, 2015, at 6:57 AM, Gal Sagie gal.sa...@gmail.com wrote:

 Hi feisky,

 I think thats a great question, not because of port-mapping in particular
 :) but because
 we need to think on a feature by feature basis and map all the features
 the dockers API allow which
 we cannot support directly with Neutron API or its services sub-projects
 API.
 (apuimedo, maybe we need to set this as a future task for us)

 But we also need to understand the use cases for supporting these API's so
 we can address them
 and give them priorities (and this is something we as a community need to
 decide how to handle).

 For your question, given that we have network isolation and security from
 neutron API's and given
 we have NAT support (by Neutron API and the plugins implementing the
 network) , what do you see as a use case to use the port-mapping ?

 I welcome you and everyone else to raise and describe these use cases so
 the Neutron/Kuryr community can think
 how to solve and help, and if needed also adjust or add extensions for
 support.

 Thanks
 Gal.


 On Fri, Aug 14, 2015 at 7:28 AM, feisky feisk...@gmail.com wrote:

 Will Kuryr supports docker's port-mapping?



 --
 View this message in context:
 http://openstack.10931.n7.nabble.com/neutron-kuryr-magnum-Design-Specification-for-Kuryr-tp82256p82299.html
 Sent from the Developer mailing list archive at Nabble.com.

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




 --
 Best Regards ,

 The G.

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




-- 
Best Regards ,

The G.
__
OpenStack Development Mailing 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] What does being a neutron-core member mean? [WAS: Re: [neutron] I am pleased to propose two new Neutron API/DB/RPC core reviewers!]

2015-08-14 Thread Russell Bryant

While this includes me, I'm really not taking this personally.  I'm
thinking about it in the general sense.

On 08/14/2015 11:03 AM, Kyle Mestery wrote:
 I'd argue the system is built on a web of trust. If you trust me, and I
 trust Russell and Brandon, then you should likely trust Russell and
 Brandon as well. This is EXACTLY what the Lieutenant system was meant to
 convey, though I now feel like perhaps people missed this key ingredient
 of the new world we find ourselves in.

This is a huge and important point.  The N to N trust model we've been
operating under doesn't scale.  Neutron is trying to move to a different
trust model that has proven to scale much further than we've been able
to do within a single OpenStack project so far.

If Kyle and others leading a section of Neutron trust me, I'm happy to
jump in and do more reviews.  If they trust me, I'd hope others not as
familiar with me or my work can trust by proxy.  The same applies to
Brandon.  I honestly don't know Brandon very well, but I have a high
level of trust for Kyle.  Kyle trusts him, so +1 from me.

Kyle has a tough role here.  It means he gives up some control, but it's
the way the project will scale.  Kyle doesn't have to develop a close
trust relationship with everyone merging code into the main neutron
repo, much less all the other repos.  He can delegate some of that.  It
only works if everyone buys into this way of thinking.

-- 
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] [neutron][kuryr][magnum] Design Specification for Kuryr

2015-08-14 Thread Adrian Otto

That's clear, thanks Gal. The feature benchmark should be parity with how the
majority of other (complete) remote drivers for libnetwork behave. From a
Magnum perspective we value consistency from an end user perspective when you
use containers on OpenStack compared to when you run them outside of an
OpenStack cloud environment.

If we offer extra features that's okay, but we do need to be careful not to to
leave feature gaps where things hat work elsewhere don't work on OpenStack. Do
we know if there are other libnetwork remote drivers that support port mapping,
or have a statement of intent to implement it? That should help guide us here.
Is it too early to know?

--
Adrian

On Aug 14, 2015, at 8:09 AM, Gal Sagie
gal.sa...@gmail.commailto:gal.sa...@gmail.com wrote:

Hi Adrian,

Thanks for the explanation, i agree with you that we shouldn't break anything
useful in docker, but from what i understand
(and please correct me if i am wrong) you are describing an implementation
detail of docker networking (at its default current state).

Kuryr is not an implementation of containers networking, it is meant to allow
docker networking to be
constructed using Neutron plugins and solutions.

For the point i was trying to make, lets take the simple case of connecting
containers in a host (not the nested VM case), assuming
we use with Kuryr the L2 OVS agent and L3 agent (Neutron reference
implementation) and we are able to plug
containers to a neutron network and define a floating ip to it, why would we
need port mapping? (the iptables
translation is already happening as we have NAT)

Hope that make sense, and please correct me if i am saying nonsense or i didn't
grasp the full
use case of port mapping.
But none the less, we will need to allow anything that docker allows and keep
compatibility with all the available tooling
that depends on it as you mention (and of course be flexible to use Kuryr in
the same environment with other
docker remote drivers)

Gal

On Fri, Aug 14, 2015 at 5:26 PM, Adrian Otto
adrian.o...@rackspace.commailto:adrian.o...@rackspace.com wrote:
The port mapping feature is the -p flag on the docker run command. It
determines which ports in the network namespace of the container are exposed to
the root namespace. It configures iptables rules and docker proxy capabilities
to achieve the desired result. This feature is essential, so we must not break
it.

In other words, this feature is what allows a network port within a container
to be externally accessed, and on what IP address(es) and port number(s) on the
host.

Example:

docker run -d -p 12.34.56.7:8000:80 nginx:latest

This runs the nginx container and exposes top port 80 from inside the container
to tcp port 8000 on 12.34.56.7 on the host. Without this feature docker is
rather useless for running network services unless you use -net host or an
equivalent workaround. This could break a lot of tooling that depends on -p.

--
Adrian

On Aug 14, 2015, at 6:57 AM, Gal Sagie
gal.sa...@gmail.commailto:gal.sa...@gmail.com wrote:

Hi feisky,

I think thats a great question, not because of port-mapping in particular :)
but because
we need to think on a feature by feature basis and map all the features the
dockers API allow which
we cannot support directly with Neutron API or its services sub-projects API.
(apuimedo, maybe we need to set this as a future task for us)

But we also need to understand the use cases for supporting these API's so we
can address them
and give them priorities (and this is something we as a community need to
decide how to handle).

For your question, given that we have network isolation and security from
neutron API's and given
we have NAT support (by Neutron API and the plugins implementing the network) ,
what do you see as a use case to use the port-mapping ?

I welcome you and everyone else to raise and describe these use cases so the
Neutron/Kuryr community can think
how to solve and help, and if needed also adjust or add extensions for support.

Thanks
Gal.

On Fri, Aug 14, 2015 at 7:28 AM, feisky
feisk...@gmail.commailto:feisk...@gmail.com wrote:
Will Kuryr supports docker's port-mapping?

--
View this message in context:
http://openstack.10931.n7.nabble.com/neutron-kuryr-magnum-Design-Specification-for-Kuryr-tp82256p82299.html
Sent from the Developer mailing list archive at Nabble.comhttp://Nabble.com.

__
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

--
Best Regards ,

The G.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:

Re: [openstack-dev] [neutron] What does being a neutron-core member mean? [WAS: Re: [neutron] I am pleased to propose two new Neutron API/DB/RPC core reviewers!]

2015-08-14 Thread Gal Sagie

I don't want to jump in where i am not suppose to, and i know everyone
saying it isn't personal, but
i have had the pleasure to work with Russell on the OVN project for the
last couple of months, i think his dedication
to the project and Neutron, his understanding of what open source community
means and his proven experience make him exactly
the type of people Neutron need. i think that for the rest he can pick up
and probably experienced enough to pick his votes.

Everyone are talking about reviews, i think there are other important
duties and not only for core reviewers, but
for every experienced person involved in Neutron and thats mentoring and
helping bringing up more people to the project  and
understand the open source way. (this is not trivial as it takes time
mentoring and not always a rewording job)

I personally have had the pleasure to receive help on various topics from
many of the core reviewers team and also trying to pass
it forward when ever i can, so thanks everyone that helped :) (don't want
to start mentioning names)

I like the Neutron community, and very happy to be part of this project,
lets help more people feel like that
and join in.

Gal.



On Fri, Aug 14, 2015 at 6:14 PM, Kyle Mestery mest...@mestery.com wrote:

 On Fri, Aug 14, 2015 at 10:00 AM, Flavio Percoco fla...@redhat.com
 wrote:

 On 14/08/15 10:42 -0400, Assaf Muller wrote:

 First I'd like to say that I recognize that this discussion is incredibly
 personal. Brandon and Russell, please do not be offended, but I know
 that I
 probably would be if this very public thread involved myself. That being
 said,
 please know that from my perspective this is *not* personal, rather I
 see this
 as a general discussion about the precedent that we are creating here.

 Responses in-line.

 On Fri, Aug 14, 2015 at 9:32 AM, Kyle Mestery mest...@mestery.com
 wrote:

On Fri, Aug 14, 2015 at 6:29 AM, Ihar Hrachyshka ihrac...@redhat.com
 
wrote:
  it feels to me that leaving neutron-core group as a
 meta-group that
includes everyone who makes significant positive impact in any of
those repos is not optimal.

  This is where I'd disagree. I think in general teams pay too much
 attention
to stats, which are incredibly easy to game. Case in point, with the
current objections people have over Brandon and Russell being
 nominated, I
could have waited 4-6 weeks and let them amass a plethora of review
 stats,
but what would the point of that have been?


 None what so ever. I think the point here is that if someone is focusing
 on
 another project then it's debatable if they should become a core in the
 Neutron
 project itself. Very simply put, if someone is a core in a subproject
 and is
 doing a fantastic job, but that person is not truly involved in the
 Neutron
 project itself, then that person becoming core in Neutron to me is
 dangerous.
 Before someone becomes core, I would like to be familiar with their
 expertise
 in Neutron so that I know if to trust their +2 or not on a given area in
 Neutron. If that person didn't really focus on Neutron then I have no
 way of
 being familiar with their expertise, thus no ability to trust them even
 if I'm
 generally a trusting person.


 I'm not really familiar with Neutron's workflow but as an outsider and
 also based on my experience from other projects, the separation of
 concerns from a review perspective is very useful. Teams that govern
 several projects are be better off giving reviewing rights to folks
 in a per-project basis rather than doing it cross-team.

 I'd go as far as saying that folks with review rights in the server
 don't necessarily need to have review rights in smaller projects. The
 reason I'm saying this is because I believe that reviewer rights is
 not a prize but a volunteer job. The moment I'm asked whether I want
 to join a reviewers team in a project, I gotta be honest with what my
 available time will allow me to do.


 What you just said is what I've been trying to emphasize my entire time as
 PTL: Reviewing is a duty, not a prize. The thing we're discussing here is
 the issue of when to give someone +2 rights. I'm arguing in favor of a web
 of trust system, which is what we have with Lieutenants. I'm also saying
 that I'm a proponent of elevating folks who want to take on the duty and
 letting them do that before they spend a month building up stats. This is
 not an opinion shared by everyone I realize, but it's my opinion.

 Like I've said in this thread, the entire system is built on trust. We as
 a community need to trust more and rely on that trust. I feel as if I've
 spent my PTL time trying to build that up and instill this value into the
 Neutron community. The results speak for themselves at this point, but I'm
 proud of what *we* as a community have built here.

 Kyle


 To what I just said, I'd also add the familiarity with the code-base,
 etc.

 Just my $0.02,
 Flavio



 --
 @flaper87
 Flavio Percoco

Re: [openstack-dev] [Keystone] [Horizon] Pagination support for Identity dashboard entities

Pagination in ldap requires holding a cursor open. You would have to map the 
requests to the same cursor each time. It costs memory and holds a client 
connected to the ldap server. In a REST api it is a bad idea. With regard to 
searching it can be done, but each query can be a different set of objects 
(order is not guaranteed). It isn't straight forward. 

To put is bluntly, we are working to push user management to the tools that are 
better at this than keystone. The LDAP servers or AD have far better tools than 
the keystone API. And federated users are managed externally as well. The SQL 
table to manage users is not a good solution and we are making strides to 
eliminate the needs for even service users to exist here. 

The question about roles and grants can be queried and appropriately 
paginated/limited/searched (again same statement about resource for 
project/domain where if it doesn't exist i wouldn't block it but it is likely a 
mitaka target). 

--Morgan

Sent via mobile

 On Aug 14, 2015, at 09:42, Fox, Kevin M kevin@pnnl.gov wrote:
 
 Surely ldap supports some form of pagination/searching natively.  If any 
 storage system of users needs to scale up to large numbers of users, its 
 ldap...
 
 Thanks,
 Kevin
 From: Timur Sufiev [tsuf...@mirantis.com]
 Sent: Friday, August 14, 2015 9:20 AM
 To: OpenStack Development Mailing List (not for usage questions)
 Subject: Re: [openstack-dev] [Keystone] [Horizon] Pagination support for 
 Identity dashboard entities
 
 Morgan,
 
 Your reasoning is perfectly fine from the Keystone point of view. Yet I 
 believe this approach is harmful for both Horizon and the whole OpenStack 
 ecosystem. 
 
 It is harmful for the ecosystem, because it breaks API uniformity in one of 
 the few areas where this uniformity could be achieved. Imagine if Nova or 
 Cinder start saying the same thing: we have too much drivers/backends to 
 provide the uniform interface for all of them, let's delegate the choice of 
 handling them differently to our consumers. It'll propagate the knowledge of 
 different backends throughout the stack and it's obviously not good.
 
 Not having pagination on Identity-Users page means that even with filtering 
 being fully supported there will be problems. At least the first time the 
 Users page with all the Users piped from production-grade LDAP through 
 Keystone is shown in Horizon, it takes a lot time to render them all (before 
 an unhappy admin had any chance to narrow the list), which eventually may 
 result in connection being dropped by some HA balancer. We did these kinds of 
 tests, the results weren't reassuring. Well, I might miss some of new Horizon 
 angularization steps, so please regard this paragraph as my personal opinion 
 - I don't think Horizon could be lighting fast on its own (i.e. without 
 additional services) with a lot of data without pagination.
 
 On Fri, Aug 14, 2015 at 6:03 PM Morgan Fainberg morgan.fainb...@gmail.com 
 wrote:
 For the identity (users and groups) backend as long as we support LDAP (and 
 as side note federated users never show up in this list anyway) and with the 
 drive towards pushing all user management out of keystone itself to ldap or 
 other tools that do it better, I don't see pagination as something we should 
 be providing. Providing an inconsistent user experience based on leaking 
 underlying implementation details is something I am very against. This 
 stance ensures that horizon and other tools like it will not need to know 
 underlying implementation details to provide a consistent user experience. 
 Unfortunately here we do need to cater to the lowest common denominator and 
 filtering/searching/limiting is the clear common mechanism
 
 With regards to resources (projects, domains, etc) since we no longer 
 support using LDAP (deprecated with removal in mitaka) I have less strong 
 feelings towards and wouldn't block efforts to implement if it is not 
 already available (if not available this is likely a mitaka goal).
 
 --Morgan
 
 Sent via mobile
 
  On Aug 14, 2015, at 07:39, Jay Pipes jaypi...@gmail.com wrote:
 
  On 08/14/2015 09:14 AM, Morgan Fainberg wrote:
  As a quick note the api-ref you are linking to has some gaps/has not
  been kept in sync with the official api specifications.
 
  The official API specification is located at
  http://specs.openstack.org/openstack/keystone-specs/ (v2 and v3 sections
  at the top) and there is a known open bug to work with the docs team to
  get this in sync (somehow).
 
  Unfortunately there are a number of cases especially with the identity
  backend where pagination just does not work (or works completely
  unreliably) such as utilizing the ldap driver. Either a cursor must be
  maintained (problematic in REST) or the results could be wildly
  different every single request meaning each page is not really
  guaranteed to be the next page it could be the same/show inconsistent
  results. The second issue is that the pagination

Re: [openstack-dev] [Keystone] [Horizon] Pagination support for Identity dashboard entities




 On Aug 14, 2015, at 12:19, Morgan Fainberg morgan.fainb...@gmail.com wrote:
 
 Pagination in ldap requires holding a cursor open. You would have to map the 
 requests to the same cursor each time. It costs memory and holds a client 
 connected to the ldap server. In a REST api it is a bad idea. With regard to 
 searching it can be done, but each query can be a different set of objects 
 (order is not guaranteed). It isn't straight forward. 
 
 To put is bluntly, we are working to push user management to the tools that 
 are better at this than keystone. The LDAP servers or AD have far better 
 tools than the keystone API. And federated users are managed externally as 
 well. The SQL table to manage users is not a good solution and we are making 
 strides to eliminate the needs for even service users to exist here. 
 
 The question about roles and grants can be queried and appropriately 
 paginated/limited/searched (again same statement about resource for 
 project/domain where if it doesn't exist i wouldn't block it but it is likely 
 a mitaka target). 
 

That is to say list all users that could have a role in keystone is not a 
good question as it highlights all the aforementioned problems. Asking for a 
list of active assignments is a reasonable answer as it is tied to a backend 
that can support what you're asking for (it isnt directly tied to identity, but 
to the assignment/role backend)

 --Morgan
 
 Sent via mobile
 
 On Aug 14, 2015, at 09:42, Fox, Kevin M kevin@pnnl.gov wrote:
 
 Surely ldap supports some form of pagination/searching natively.  If any 
 storage system of users needs to scale up to large numbers of users, its 
 ldap...
 
 Thanks,
 Kevin
 From: Timur Sufiev [tsuf...@mirantis.com]
 Sent: Friday, August 14, 2015 9:20 AM
 To: OpenStack Development Mailing List (not for usage questions)
 Subject: Re: [openstack-dev] [Keystone] [Horizon] Pagination support for 
 Identity dashboard entities
 
 Morgan,
 
 Your reasoning is perfectly fine from the Keystone point of view. Yet I 
 believe this approach is harmful for both Horizon and the whole OpenStack 
 ecosystem. 
 
 It is harmful for the ecosystem, because it breaks API uniformity in one of 
 the few areas where this uniformity could be achieved. Imagine if Nova or 
 Cinder start saying the same thing: we have too much drivers/backends to 
 provide the uniform interface for all of them, let's delegate the choice of 
 handling them differently to our consumers. It'll propagate the knowledge 
 of different backends throughout the stack and it's obviously not good.
 
 Not having pagination on Identity-Users page means that even with filtering 
 being fully supported there will be problems. At least the first time the 
 Users page with all the Users piped from production-grade LDAP through 
 Keystone is shown in Horizon, it takes a lot time to render them all (before 
 an unhappy admin had any chance to narrow the list), which eventually may 
 result in connection being dropped by some HA balancer. We did these kinds 
 of tests, the results weren't reassuring. Well, I might miss some of new 
 Horizon angularization steps, so please regard this paragraph as my personal 
 opinion - I don't think Horizon could be lighting fast on its own (i.e. 
 without additional services) with a lot of data without pagination.
 
 On Fri, Aug 14, 2015 at 6:03 PM Morgan Fainberg morgan.fainb...@gmail.com 
 wrote:
 For the identity (users and groups) backend as long as we support LDAP (and 
 as side note federated users never show up in this list anyway) and with 
 the drive towards pushing all user management out of keystone itself to 
 ldap or other tools that do it better, I don't see pagination as something 
 we should be providing. Providing an inconsistent user experience based on 
 leaking underlying implementation details is something I am very against. 
 This stance ensures that horizon and other tools like it will not need to 
 know underlying implementation details to provide a consistent user 
 experience. Unfortunately here we do need to cater to the lowest common 
 denominator and filtering/searching/limiting is the clear common mechanism
 
 With regards to resources (projects, domains, etc) since we no longer 
 support using LDAP (deprecated with removal in mitaka) I have less strong 
 feelings towards and wouldn't block efforts to implement if it is not 
 already available (if not available this is likely a mitaka goal).
 
 --Morgan
 
 Sent via mobile
 
  On Aug 14, 2015, at 07:39, Jay Pipes jaypi...@gmail.com wrote:
 
  On 08/14/2015 09:14 AM, Morgan Fainberg wrote:
  As a quick note the api-ref you are linking to has some gaps/has not
  been kept in sync with the official api specifications.
 
  The official API specification is located at
  http://specs.openstack.org/openstack/keystone-specs/ (v2 and v3 sections
  at the top) and there is a known open bug to work with the docs team to
  get this in sync (somehow).
 
  Unfortunately

Re: [openstack-dev] [Keystone] [Horizon] Pagination support for Identity dashboard entities

2015-08-14 Thread Fox, Kevin M

Surely ldap supports some form of pagination/searching natively.  If any 
storage system of users needs to scale up to large numbers of users, its ldap...

Thanks,
Kevin

From: Timur Sufiev [tsuf...@mirantis.com]
Sent: Friday, August 14, 2015 9:20 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Keystone] [Horizon] Pagination support for 
Identity dashboard entities

Morgan,

Your reasoning is perfectly fine from the Keystone point of view. Yet I believe 
this approach is harmful for both Horizon and the whole OpenStack ecosystem.

It is harmful for the ecosystem, because it breaks API uniformity in one of the 
few areas where this uniformity could be achieved. Imagine if Nova or Cinder 
start saying the same thing: we have too much drivers/backends to provide the 
uniform interface for all of them, let's delegate the choice of handling them 
differently to our consumers. It'll propagate the knowledge of different 
backends throughout the stack and it's obviously not good.

Not having pagination on Identity-Users page means that even with filtering 
being fully supported there will be problems. At least the first time the Users 
page with all the Users piped from production-grade LDAP through Keystone is 
shown in Horizon, it takes a lot time to render them all (before an unhappy 
admin had any chance to narrow the list), which eventually may result in 
connection being dropped by some HA balancer. We did these kinds of tests, the 
results weren't reassuring. Well, I might miss some of new Horizon 
angularization steps, so please regard this paragraph as my personal opinion - 
I don't think Horizon could be lighting fast on its own (i.e. without 
additional services) with a lot of data without pagination.

On Fri, Aug 14, 2015 at 6:03 PM Morgan Fainberg 
morgan.fainb...@gmail.commailto:morgan.fainb...@gmail.com wrote:
For the identity (users and groups) backend as long as we support LDAP (and as 
side note federated users never show up in this list anyway) and with the drive 
towards pushing all user management out of keystone itself to ldap or other 
tools that do it better, I don't see pagination as something we should be 
providing. Providing an inconsistent user experience based on leaking 
underlying implementation details is something I am very against. This stance 
ensures that horizon and other tools like it will not need to know underlying 
implementation details to provide a consistent user experience. Unfortunately 
here we do need to cater to the lowest common denominator and 
filtering/searching/limiting is the clear common mechanism

With regards to resources (projects, domains, etc) since we no longer support 
using LDAP (deprecated with removal in mitaka) I have less strong feelings 
towards and wouldn't block efforts to implement if it is not already available 
(if not available this is likely a mitaka goal).

--Morgan

Sent via mobile

 On Aug 14, 2015, at 07:39, Jay Pipes 
 jaypi...@gmail.commailto:jaypi...@gmail.com wrote:

 On 08/14/2015 09:14 AM, Morgan Fainberg wrote:
 As a quick note the api-ref you are linking to has some gaps/has not
 been kept in sync with the official api specifications.

 The official API specification is located at
 http://specs.openstack.org/openstack/keystone-specs/ (v2 and v3 sections
 at the top) and there is a known open bug to work with the docs team to
 get this in sync (somehow).

 Unfortunately there are a number of cases especially with the identity
 backend where pagination just does not work (or works completely
 unreliably) such as utilizing the ldap driver. Either a cursor must be
 maintained (problematic in REST) or the results could be wildly
 different every single request meaning each page is not really
 guaranteed to be the next page it could be the same/show inconsistent
 results. The second issue is that the pagination is not a good UX even
 where it works - the simple question is: if you can filter the results
 how many pages deep do you go before refining the query; think of your
 use of search engines.

 In light of these issues Keystone has opted for a filter / limit
 (config). If the results exceed the limit there is a truncation that
 occurs and it is recommended extra filtering be applied to reduce the
 total number of results.

 This discussion has gone around a few times, pagination in keystone is
 not currently on the roadmap. In addition to the above doc bug, we
 should work to better socialize this filter-over-paginate methodology.

 I understand all the things you write above about the problems that 
 Keystone's underlying architecture (driver-based, not always able to do 
 pagination in the individual drivers). However, it really does mean that 
 Keystone is the only project in OpenStack that behaves this way. All other 
 services provide limit/marker paginations, AFAIK, which is efficient and, 
 while not the same UX as a filtering methodology,

Re: [openstack-dev] [sahara] Proposing Ethan Gafford for the core reviewer team

2015-08-14 Thread Trevor McKay

Flavio,

  thanks, bad joke on my part. I work with Telles on Sahara, just poking
him in jest.  Apologies, didn't mean to create an issue on the list.

Trev

On Fri, 2015-08-14 at 17:30 +0200, Flavio Percoco wrote:
 On 14/08/15 09:29 -0400, Trevor McKay wrote:
 Hi Telles,
 
  you technically don't get a vote, but thanks anyway :)
 
 Hi Trevor,
 
 Technically, everyone gets to vote and speak up. Regardless of whether
 you're a core-reviewer or not. Most of the time, non-core contributors
 provide amazing feedback on what their experience has been while
 receiving reviews from the nominated person.
 
 Regardless of the comment, we as a community always welcome
 contributor's opinions and encourage folks to speak up.
 
 I knew your intentions are good but I thought it'd be a good time to
 share the above so that it would work as a reminder for others as
 well.
 
 Thank you both and +1 for Ethan ;)
 Flavio
 
 
 Trev
 
 On Fri, 2015-08-14 at 12:14 +, Telles Nobrega wrote:
  +1
 
  On Fri, Aug 14, 2015 at 7:11 AM Alexander Ignatov
  aigna...@mirantis.com wrote:
 
  +1
 
  Regards,
  Alexander Ignatov
 
 
 
 
 
   On 13 Aug 2015, at 18:29, Sergey Reshetnyak
   sreshetn...@mirantis.com wrote:
  
   +2
  
   2015-08-13 18:07 GMT+03:00 Matthew Farrellee
   m...@redhat.com:
   On 08/13/2015 10:56 AM, Sergey Lukjanov wrote:
   Hi folks,
  
   I'd like to propose Ethan Gafford as a
   member of the Sahara core
   reviewer team.
  
   Ethan contributing to Sahara for a long time
   and doing a great job on
   reviewing and improving Sahara. Here are the
   statistics for reviews
   [0][1][2] and commits [3]. BTW Ethan is
   already stable maint team core
   for Sahara.
  
   Existing Sahara core reviewers, please vote
   +1/-1 for the addition of
   Ethan to the core reviewer team.
  
   Thanks.
  
   [0]
   https://review.openstack.org/#/q/reviewer:%
   22Ethan+Gafford+%253Cegafford%2540redhat.com
   %253E%22,n,z
   [1]
   
  http://stackalytics.com/report/contribution/sahara-group/90
   [2]
   
  http://stackalytics.com/?user_id=egaffordmetric=marks
   [3]
   https://review.openstack.org/#/q/owner:%
   22Ethan+Gafford+%253Cegafford%2540redhat.com
   %253E%22+status:merged,n,z
  
   --
   Sincerely yours,
   Sergey Lukjanov
   Sahara Technical Lead
   (OpenStack Data Processing)
   Principal Software Engineer
   Mirantis Inc.
  
  
   +1 ethan has really taken to sahara, providing
   valuable input to both development and deployments
   as well has taking on the manila integration
  
  
  
   
  __
   OpenStack Development Mailing 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
  --
 
  Telles Nobrega
  __
  OpenStack Development Mailing 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] [kolla] Proposing Swapnil Kulkarni (coolsvap) for kolla core reviewer team

2015-08-14 Thread Harm Weites


great! +1 :)

Op 14-08-15 om 15:38 schreef Paul Bourke:
+1, Swapnil has made a ton of useful contributions and continues to do 
so :)


On 14/08/15 14:29, Steven Dake (stdake) wrote:

Hi folks,

Swapnil has done a bunch of great technical work, participates 
heavily in IRC, and has contributed enormously to the implementation 
of Kolla.  I’d like to see more reviews from Swapnil, but he has 
committed to doing more reviews and already has gone from something 
like 0 reviews to 90 reviews in about a month.  Count this proposal 
as a +1 from me.


His 90 day stats are:
http://stackalytics.com/report/contribution/kolla-group/90

The process we go to select new core reviewers is that we require a 
minimum of 3 +1 votes within a 1 week voting window. A vote of –1 is 
a veto.  It is fine to abstain as well without any response to this 
email.  If the vote is unanimous or there is a veto vote prior to the 
end of the voting window, I’ll close voting then.


The voting is open until Friday August 21st.

Thanks!
-steve



__ 


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

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



__ 


OpenStack Development Mailing 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] [Horizon] Pagination support for Identity dashboard entities

2015-08-14 Thread Henry Nash

So I was one of the keystone folks who looked at pagination (hell, I even had 
an implementation - and the framework for it still exists in keystone). 
However, I think it is true to say that there were as many people (external to 
keystone) who thought pagination was a bad idea, as thought it was a good one.  
At the time, there was a drive to answer this debate corss-project so we would 
have a new consensus (as opposed to just assume that what we did before should 
be replicated everywhere). I’m actually unclear if that happened. We then add 
the complication of federation where keystone physically does not have access 
to the users (it only knows about users who are active right now” and even 
that is pretty tenuous).

As Morgan has outlined, although there are solutions to at least the 
“traditional LDAP” backed keystone…they aren’t very pretty - and don’t sit 
easily with a REST API.

It’s really a dichotomy - we have grown up thinking that keystone can serve up 
users and groups…whereas the future of large enterprise systems (where you 
might think you need pagination) is one where keystone will probably NOT have 
access to the users.

Henry

 On 14 Aug 2015, at 20:19, Morgan Fainberg morgan.fainb...@gmail.com wrote:
 
 Pagination in ldap requires holding a cursor open. You would have to map the 
 requests to the same cursor each time. It costs memory and holds a client 
 connected to the ldap server. In a REST api it is a bad idea. With regard to 
 searching it can be done, but each query can be a different set of objects 
 (order is not guaranteed). It isn't straight forward. 
 
 To put is bluntly, we are working to push user management to the tools that 
 are better at this than keystone. The LDAP servers or AD have far better 
 tools than the keystone API. And federated users are managed externally as 
 well. The SQL table to manage users is not a good solution and we are making 
 strides to eliminate the needs for even service users to exist here. 
 
 The question about roles and grants can be queried and appropriately 
 paginated/limited/searched (again same statement about resource for 
 project/domain where if it doesn't exist i wouldn't block it but it is likely 
 a mitaka target). 
 
 --Morgan
 
 Sent via mobile
 
 On Aug 14, 2015, at 09:42, Fox, Kevin M kevin@pnnl.gov 
 mailto:kevin@pnnl.gov wrote:
 
 Surely ldap supports some form of pagination/searching natively.  If any 
 storage system of users needs to scale up to large numbers of users, its 
 ldap...
 
 Thanks,
 Kevin
 From: Timur Sufiev [tsuf...@mirantis.com mailto:tsuf...@mirantis.com]
 Sent: Friday, August 14, 2015 9:20 AM
 To: OpenStack Development Mailing List (not for usage questions)
 Subject: Re: [openstack-dev] [Keystone] [Horizon] Pagination support for 
 Identity dashboard entities
 
 Morgan,
 
 Your reasoning is perfectly fine from the Keystone point of view. Yet I 
 believe this approach is harmful for both Horizon and the whole OpenStack 
 ecosystem. 
 
 It is harmful for the ecosystem, because it breaks API uniformity in one of 
 the few areas where this uniformity could be achieved. Imagine if Nova or 
 Cinder start saying the same thing: we have too much drivers/backends to 
 provide the uniform interface for all of them, let's delegate the choice of 
 handling them differently to our consumers. It'll propagate the knowledge 
 of different backends throughout the stack and it's obviously not good.
 
 Not having pagination on Identity-Users page means that even with filtering 
 being fully supported there will be problems. At least the first time the 
 Users page with all the Users piped from production-grade LDAP through 
 Keystone is shown in Horizon, it takes a lot time to render them all (before 
 an unhappy admin had any chance to narrow the list), which eventually may 
 result in connection being dropped by some HA balancer. We did these kinds 
 of tests, the results weren't reassuring. Well, I might miss some of new 
 Horizon angularization steps, so please regard this paragraph as my personal 
 opinion - I don't think Horizon could be lighting fast on its own (i.e. 
 without additional services) with a lot of data without pagination.
 
 On Fri, Aug 14, 2015 at 6:03 PM Morgan Fainberg morgan.fainb...@gmail.com 
 mailto:morgan.fainb...@gmail.com wrote:
 For the identity (users and groups) backend as long as we support LDAP (and 
 as side note federated users never show up in this list anyway) and with the 
 drive towards pushing all user management out of keystone itself to ldap or 
 other tools that do it better, I don't see pagination as something we should 
 be providing. Providing an inconsistent user experience based on leaking 
 underlying implementation details is something I am very against. This 
 stance ensures that horizon and other tools like it will not need to know 
 underlying implementation details to provide a consistent user experience. 
 Unfortunately here we do need to cater to the

Re: [openstack-dev] [UX] [Keystone] [Horizon] Pagination support for Identity dashboard entities

2015-08-14 Thread Michael Krotscheck

I don't have a horse in the What should keystone support race. I do,
however, need to point out that any UX argument made about how a UI should
work should, at this point, ask the OpenStack UX program for help! Thus
I've changed the topic of this email to make sure Piet and the UX teams get
a chance to respond.

It feels like we have four UX assumptions, which I feel should be converted
into questions:
1- Do users want to page through search results?
2- Do users want to page through filter results? (do they use filter
results?)
3- If they want to page, do they want to be able to go back a page and/or
know their current page?
4- How much do users care about small data inconsistencies (i.e. ordering
of record sets changing from page-to-page).

Also, from personal experience, it is impossible to make a search
implementation that users, especially enterprise users, trust. I personally
blame Sharepoint for that.

Michael

On Fri, Aug 14, 2015 at 6:17 AM Morgan Fainberg morgan.fainb...@gmail.com
wrote:

 As a quick note the api-ref you are linking to has some gaps/has not been
 kept in sync with the official api specifications.

 The official API specification is located at
 http://specs.openstack.org/openstack/keystone-specs/ (v2 and v3 sections
 at the top) and there is a known open bug to work with the docs team to get
 this in sync (somehow).

 Unfortunately there are a number of cases especially with the identity
 backend where pagination just does not work (or works completely
 unreliably) such as utilizing the ldap driver. Either a cursor must be
 maintained (problematic in REST) or the results could be wildly different
 every single request meaning each page is not really guaranteed to be the
 next page it could be the same/show inconsistent results. The second
 issue is that the pagination is not a good UX even where it works - the
 simple question is: if you can filter the results how many pages deep do
 you go before refining the query; think of your use of search engines.

 In light of these issues Keystone has opted for a filter / limit (config).
 If the results exceed the limit there is a truncation that occurs and it is
 recommended extra filtering be applied to reduce the total number of
 results.

 This discussion has gone around a few times, pagination in keystone is not
 currently on the roadmap. In addition to the above doc bug, we should work
 to better socialize this filter-over-paginate methodology.

 --Morgan

 Sent via mobile

 On Aug 14, 2015, at 05:46, Timur Sufiev tsuf...@mirantis.com wrote:

 Hello, Keystone folks!

 I've just discovered an unfortunate fact that Horizon pagination for
 Tenants/Projects list that worked with Keystone v2 doesn't work with
 Keysone v3 anymore - its API call simply lacks the 'marker' and 'limit'
 parameters [1] that Horizon is relying upon. Meanwhile having looked
 through [2] and [3] I'm a bit confused: while Keystone v3 API states it
 supports [2] pagination for every kind of entities (by using 'page' and
 'per_page' parameters), the related blueprint [3] is not yet approved,
 meaning that most likely the API implementation did not make it into
 existing Keystone codebase. So I wonder whether there are some plans to
 implement pagination for Keystone API calls that list its entities?

 P.S. I'm aware of SearchLight project that tries to help Horizon with
 other OpenStack APIs (part of its mission), what I'm trying to understand
 here is are we going to have some fallback pagination mechanism for
 Horizon's Identity in a short-term/mid-term perspective.

 [1] http://developer.openstack.org/api-ref-identity-admin-v2.html
 [2] http://developer.openstack.org/api-ref-identity-v3.html
 [3] https://blueprints.launchpad.net/keystone/+spec/pagination

 __
 OpenStack Development Mailing 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] [Horizon] Pagination support for Identity dashboard entities

2015-08-14 Thread Timur Sufiev

Morgan,

Your reasoning is perfectly fine from the Keystone point of view. Yet I
believe this approach is harmful for both Horizon and the whole OpenStack
ecosystem.

It is harmful for the ecosystem, because it breaks API uniformity in one of
the few areas where this uniformity could be achieved. Imagine if Nova or
Cinder start saying the same thing: we have too much drivers/backends to
provide the uniform interface for all of them, let's delegate the choice of
handling them differently to our consumers. It'll propagate the knowledge
of different backends throughout the stack and it's obviously not good.

Not having pagination on Identity-Users page means that even with
filtering being fully supported there will be problems. At least the first
time the Users page with all the Users piped from production-grade LDAP
through Keystone is shown in Horizon, it takes a lot time to render them
all (before an unhappy admin had any chance to narrow the list), which
eventually may result in connection being dropped by some HA balancer. We
did these kinds of tests, the results weren't reassuring. Well, I might
miss some of new Horizon angularization steps, so please regard this
paragraph as my personal opinion - I don't think Horizon could be lighting
fast on its own (i.e. without additional services) with a lot of data
without pagination.

On Fri, Aug 14, 2015 at 6:03 PM Morgan Fainberg morgan.fainb...@gmail.com
wrote:

 For the identity (users and groups) backend as long as we support LDAP
 (and as side note federated users never show up in this list anyway) and
 with the drive towards pushing all user management out of keystone itself
 to ldap or other tools that do it better, I don't see pagination as
 something we should be providing. Providing an inconsistent user experience
 based on leaking underlying implementation details is something I am very
 against. This stance ensures that horizon and other tools like it will not
 need to know underlying implementation details to provide a consistent user
 experience. Unfortunately here we do need to cater to the lowest common
 denominator and filtering/searching/limiting is the clear common mechanism

 With regards to resources (projects, domains, etc) since we no longer
 support using LDAP (deprecated with removal in mitaka) I have less strong
 feelings towards and wouldn't block efforts to implement if it is not
 already available (if not available this is likely a mitaka goal).

 --Morgan

 Sent via mobile

  On Aug 14, 2015, at 07:39, Jay Pipes jaypi...@gmail.com wrote:
 
  On 08/14/2015 09:14 AM, Morgan Fainberg wrote:
  As a quick note the api-ref you are linking to has some gaps/has not
  been kept in sync with the official api specifications.
 
  The official API specification is located at
  http://specs.openstack.org/openstack/keystone-specs/ (v2 and v3
 sections
  at the top) and there is a known open bug to work with the docs team to
  get this in sync (somehow).
 
  Unfortunately there are a number of cases especially with the identity
  backend where pagination just does not work (or works completely
  unreliably) such as utilizing the ldap driver. Either a cursor must be
  maintained (problematic in REST) or the results could be wildly
  different every single request meaning each page is not really
  guaranteed to be the next page it could be the same/show inconsistent
  results. The second issue is that the pagination is not a good UX even
  where it works - the simple question is: if you can filter the results
  how many pages deep do you go before refining the query; think of your
  use of search engines.
 
  In light of these issues Keystone has opted for a filter / limit
  (config). If the results exceed the limit there is a truncation that
  occurs and it is recommended extra filtering be applied to reduce the
  total number of results.
 
  This discussion has gone around a few times, pagination in keystone is
  not currently on the roadmap. In addition to the above doc bug, we
  should work to better socialize this filter-over-paginate methodology.
 
  I understand all the things you write above about the problems that
 Keystone's underlying architecture (driver-based, not always able to do
 pagination in the individual drivers). However, it really does mean that
 Keystone is the only project in OpenStack that behaves this way. All other
 services provide limit/marker paginations, AFAIK, which is efficient and,
 while not the same UX as a filtering methodology, is entirely compatible
 and complementary to filtering.
 
  Best,
  -jay
 
 
 __
  OpenStack Development Mailing List (not for usage questions)
  Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

 __
 OpenStack Development Mailing List (not for usage

Re: [openstack-dev] [neutron][kuryr][magnum] Design Specification for Kuryr

2015-08-14 Thread Dmitry

I would suggest considering docker port mapping as a creation of an
apropriate security group's rule and also creation of something which was
never exist in Neutron before which will be responsible for port
forwarding. This feature could be useful for VMs also instead of/jointly
with using floating IPs.
What do you think?
On Aug 14, 2015 6:12 PM, Gal Sagie gal.sa...@gmail.com wrote:

 Hi Adrian,

 Thanks for the explanation, i agree with you that we shouldn't break
 anything useful in docker, but from what i understand
 (and please correct me if i am wrong) you are describing an implementation
 detail of docker networking (at its default current state).

 Kuryr is not an implementation of containers networking, it is meant to
 allow docker networking to be
 constructed using Neutron plugins and solutions.

 For the point i was trying to make, lets take the simple case of
 connecting containers in a host (not the nested VM case), assuming
 we use with Kuryr the L2 OVS agent and L3 agent (Neutron reference
 implementation) and we are able to plug
 containers to a neutron network and define a floating ip to it, why would
 we need port mapping? (the iptables
 translation is already happening as we have NAT)

 Hope that make sense, and please correct me if i am saying nonsense or i
 didn't grasp the full
 use case of port mapping.
 But none the less, we will need to allow anything that docker allows and
 keep compatibility with all the available tooling
 that depends on it as you mention (and of course be flexible to use Kuryr
 in the same environment with other
 docker remote drivers)

 Gal

 On Fri, Aug 14, 2015 at 5:26 PM, Adrian Otto adrian.o...@rackspace.com
 wrote:

 The port mapping feature is the -p flag on the docker run command. It
 determines which ports in the network namespace of the container are
 exposed to the root namespace. It configures iptables rules and docker
 proxy capabilities to achieve the desired result. This feature is
 essential, so we must not break it.

 In other words, this feature is what allows a network port within a
 container to be externally accessed, and on what IP address(es) and port
 number(s) on the host.

 Example:

 docker run -d -p 12.34.56.7:8000:80 nginx:latest

 This runs the nginx container and exposes top port 80 from inside the
 container to tcp port 8000 on 12.34.56.7 on the host. Without this feature
 docker is rather useless for running network services unless you use -net
 host or an equivalent workaround. This could break a lot of tooling that
 depends on -p.

 --
 Adrian

 On Aug 14, 2015, at 6:57 AM, Gal Sagie gal.sa...@gmail.com wrote:

 Hi feisky,

 I think thats a great question, not because of port-mapping in particular
 :) but because
 we need to think on a feature by feature basis and map all the features
 the dockers API allow which
 we cannot support directly with Neutron API or its services sub-projects
 API.
 (apuimedo, maybe we need to set this as a future task for us)

 But we also need to understand the use cases for supporting these API's
 so we can address them
 and give them priorities (and this is something we as a community need to
 decide how to handle).

 For your question, given that we have network isolation and security from
 neutron API's and given
 we have NAT support (by Neutron API and the plugins implementing the
 network) , what do you see as a use case to use the port-mapping ?

 I welcome you and everyone else to raise and describe these use cases so
 the Neutron/Kuryr community can think
 how to solve and help, and if needed also adjust or add extensions for
 support.

 Thanks
 Gal.


 On Fri, Aug 14, 2015 at 7:28 AM, feisky feisk...@gmail.com wrote:

 Will Kuryr supports docker's port-mapping?



 --
 View this message in context:
 http://openstack.10931.n7.nabble.com/neutron-kuryr-magnum-Design-Specification-for-Kuryr-tp82256p82299.html
 Sent from the Developer mailing list archive at Nabble.com.


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




 --
 Best Regards ,

 The G.

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




 --
 Best Regards ,

 The G.

 __
 OpenStack Development Mailing List (not for

[openstack-dev] [kolla] Essential that kolla developers add ideas to our upgrade-strategy blueprint

2015-08-14 Thread Steven Dake (stdake)

At the midcycle, we had only 1 session on upgrade, and we didn’t come to any 
clear consensus on how it should be handled.  I took a stab at writing what I 
think are the requirements for upgrade in this blueprint:

https://blueprints.launchpad.net/kolla/+spec/upgrade-strategy

The blueprint can be edited (yellow exclamation point) if someone thinks I 
missed some requirements.

This blueprint is in the discussion phase.  I’d like to sort out our technical 
implementation and approach – and to do that, we need to have a discussion in 
the blueprint.  Most folks are aware, but you can use the whiteboard to have a 
discussion.  Add a —ircnick after so we know who originated the idea.  I’ll 
leave the blueprint in the discussion phase until August 31st, after which 
point we have approximately 1 month to sort this problem out.

We need all the work that is necessary to do an upgrade post liberty to land in 
the source base.  Extra points for actually finishing the job on upgrade 
throughout the codebase  and within Ansible itself.  One of the major 
rationales for using containers is they make upgrade atomic – lets actually 
deliver on that!

Regards
-steve

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

Re: [openstack-dev] [cinder] [third-party]RE: [OpenStack-Infra] ProphetStor CI account

2015-08-14 Thread Rick Chen

HI Mike:
Ok, Thanks. I will refine my CI configuration to follow Ramy's
comment. I will notify you when I refine Ramy's comment.
Another my latest review log should been today:

http://download.prophetstor.com/prophetstor_ci/203895/3/check/prophetstor-ds
vm-tempest-cinder-ci/5081/


-Original Message-
From: Mike Perez [mailto:thin...@gmail.com] 
Sent: Friday, August 14, 2015 11:41 PM
To: Rick Chen rick.c...@prophetstor.com
Cc: openstack-dev@lists.openstack.org
Subject: Re: [cinder] [third-party]RE: [OpenStack-Infra] ProphetStor CI
account

On 09:44 Aug 14, Rick Chen wrote:
 HI Mike:
   Sorry again, I already add email alert agent in our CI Jenkins
server 
 to capture each failed build result.
   [1] -
 http://lists.openstack.org/pipermail/third-party-announce/2015-June/00
 0192.h
 tml
   [2] -
 http://lists.openstack.org/pipermail/third-party-announce/2015-June/00
 0193.h
 tml
   Solution 1: Our Jenkins client machine is vmware machine, I already 
 add snapshot revert script in the Jenkins Job script. Each git review job
 trigger the client will revert to  clean environment
 to solve this problem.
   Solution 2: I don't know whiched changed to make keystone unable to

 import pastedeploy. So I try to uninstall python-pastedeploy package 
 in the local to solve some
issue about unable to build devstack issue.
   Sorry again to disturb you.

Rick,

I looked at your CI results directory [1], but it looks like the last time
this ran was on July 28th according to the last modified dates. This should
be actively running even if you account is disabled from leaving comments,
so I can verify from the logs things are running fine again.

In addition, see Ramy's comments with issues with the CI [2].

[1] - http://download.prophetstor.com/prophetstor_ci/?C=M;O=A
[2] -
http://lists.openstack.org/pipermail/openstack-infra/2015-August/003057.html

--
Mike Perez


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

Re: [openstack-dev] [Neutron] neutron-lbaas code structure problem

2015-08-14 Thread Brandon Logan

?Hi Gareth,

The reason for this is because lbaas v1 is in the services/loadbalancer/drivers 
path.  This path was maintained from when neutron-lbaas was just another 
directory in the neutron repo.  Once we moved to neutron-lbaas as its own repo 
and going forward with lbaas v2, the decision was made to not maintain that 
same path for v2.  There's no reason to keep that path for v2 as v1 will be 
deprecated and eventually removed and we did not want to be stuck with that 
path.  Eventually the plugin.py module will have to be moved to the root 
directory as well from services/loadbalancer but thats a minor change.


Thanks,

Brandon


From: Gareth academicgar...@gmail.com
Sent: Thursday, August 13, 2015 9:38 PM
To: OpenStack Development Mailing List
Subject: [openstack-dev] [Neutron] neutron-lbaas code structure problem

Dear neutron guys.

[0] https://github.com/openstack/neutron-lbaas/tree/master/neutron_lbaas/drivers
[1] 
https://github.com/openstack/neutron-lbaas/tree/master/neutron_lbaas/services/loadbalancer/drivers

the codes under these two paths are 'same' (implement same things with v1 and 
v2), but why use two different code paths here?

--
Gareth

Cloud Computing, OpenStack, Distributed Storage, Fitness, Basketball
OpenStack contributor, kun_huang@freenode
My promise: if you find any spelling or grammar mistakes in my email from Mar 1 
2013, notify me
and I'll donate $1 or ?1 to an open organization you specify.
__
OpenStack Development Mailing 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] [Horizon] Pagination support for Identity dashboard entities

2015-08-14 Thread David Lyle

I understand the reasoning, but there are use cases for indexing (re:
searchlight) and auditing that are completely unsupported in keystone v3.
As from keystone, I have no way to exhaustively list who has accounts in my
cloud using OpenStack APIs. That seems like a hole that should be filled.

Not to mention API consistency, which others have already brought up.

David



On Fri, Aug 14, 2015 at 9:02 AM, Morgan Fainberg morgan.fainb...@gmail.com
wrote:

 For the identity (users and groups) backend as long as we support LDAP
 (and as side note federated users never show up in this list anyway) and
 with the drive towards pushing all user management out of keystone itself
 to ldap or other tools that do it better, I don't see pagination as
 something we should be providing. Providing an inconsistent user experience
 based on leaking underlying implementation details is something I am very
 against. This stance ensures that horizon and other tools like it will not
 need to know underlying implementation details to provide a consistent user
 experience. Unfortunately here we do need to cater to the lowest common
 denominator and filtering/searching/limiting is the clear common mechanism

 With regards to resources (projects, domains, etc) since we no longer
 support using LDAP (deprecated with removal in mitaka) I have less strong
 feelings towards and wouldn't block efforts to implement if it is not
 already available (if not available this is likely a mitaka goal).

 --Morgan

 Sent via mobile

  On Aug 14, 2015, at 07:39, Jay Pipes jaypi...@gmail.com wrote:
 
  On 08/14/2015 09:14 AM, Morgan Fainberg wrote:
  As a quick note the api-ref you are linking to has some gaps/has not
  been kept in sync with the official api specifications.
 
  The official API specification is located at
  http://specs.openstack.org/openstack/keystone-specs/ (v2 and v3
 sections
  at the top) and there is a known open bug to work with the docs team to
  get this in sync (somehow).
 
  Unfortunately there are a number of cases especially with the identity
  backend where pagination just does not work (or works completely
  unreliably) such as utilizing the ldap driver. Either a cursor must be
  maintained (problematic in REST) or the results could be wildly
  different every single request meaning each page is not really
  guaranteed to be the next page it could be the same/show inconsistent
  results. The second issue is that the pagination is not a good UX even
  where it works - the simple question is: if you can filter the results
  how many pages deep do you go before refining the query; think of your
  use of search engines.
 
  In light of these issues Keystone has opted for a filter / limit
  (config). If the results exceed the limit there is a truncation that
  occurs and it is recommended extra filtering be applied to reduce the
  total number of results.
 
  This discussion has gone around a few times, pagination in keystone is
  not currently on the roadmap. In addition to the above doc bug, we
  should work to better socialize this filter-over-paginate methodology.
 
  I understand all the things you write above about the problems that
 Keystone's underlying architecture (driver-based, not always able to do
 pagination in the individual drivers). However, it really does mean that
 Keystone is the only project in OpenStack that behaves this way. All other
 services provide limit/marker paginations, AFAIK, which is efficient and,
 while not the same UX as a filtering methodology, is entirely compatible
 and complementary to filtering.
 
  Best,
  -jay
 
 
 __
  OpenStack Development Mailing List (not for usage questions)
  Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

__
OpenStack Development Mailing 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] [UX] [Keystone] [Horizon] Pagination support for Identity dashboard entities

2015-08-14 Thread Adam Young


On 08/14/2015 12:43 PM, Michael Krotscheck wrote:

1- Do users want to page through search results?

Does not matter:  in Federation, the User list is not available.
2- Do users want to page through filter results? (do they use filter 
results?)

This is the only practical tool available for LDAP.

3- If they want to page, do they want to be able to go back a page 
and/or know their current page?
4- How much do users care about small data inconsistencies (i.e. 
ordering of record sets changing from page-to-page).



So, yeah, we could support paging for SQL.  That is becoming a 
repository for service users only.  For the use cases requested, we do 
not have the ability to implement.


__
OpenStack Development Mailing 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] [UX] [Keystone] [Horizon] Pagination support for Identity dashboard entities



 On Aug 14, 2015, at 15:10, Jay Pipes jaypi...@gmail.com wrote:
 
 On 08/14/2015 05:24 PM, Adam Young wrote:
 On 08/14/2015 12:43 PM, Michael Krotscheck wrote:
 1- Do users want to page through search results?
 Does not matter:  in Federation, the User list is not available.
 
 OK, so hobble the entire REST API for the deficiencies/architecture/reality 
 of a single authentication/identity strategy.
 
 2- Do users want to page through filter results? (do they use filter
 results?)
 This is the only practical tool available for LDAP.
 
 Again, hobble the entire API for the deficiencies and anachronisms of a 
 single identity driver.
 

The SQL driver is at best a toy and should go away. We are working diligently 
to provide the best solution for the small and large deployments and provide 
features we are regularly asked for (password lifecycle, complexity, better 
user management, etc). 

Again I will reiterate, asking for every user that could have an assignment 
is absurd. You should search for specific users if you need for find a user 
without an assignment (they can't access keystone or auth or act on OpenStack 
anyway). You should look at active assignments and we can implement pagination 
for that. 

It wont be a /users API call. 

 3- If they want to page, do they want to be able to go back a page
 and/or know their current page?
 4- How much do users care about small data inconsistencies (i.e.
 ordering of record sets changing from page-to-page).
 
 So, yeah, we could support paging for SQL.
 
 That would be great. Double bonus if this pagination API followed the 
 examples of all the other OpenStack API services and didn't invent its own 
 terms (page, per_page...).
 

I really do not want implementation details to be the cause of a massive UX 
change. Lets avoid doing that yet again in OpenStack. Asking horizon to have 
two completely different mechanisms based on what backend is following a poor 
design pattern we keep falling into where we expect the user to figure out/know 
what is different between deployments. 

 That is becoming a repository for service users only.  For the use
 cases requested, we do not have the ability to implement.
 
 Sure, but what you[1] *do* have the ability to implement is a capabilities 
 discovery REST API that would allow tools like Horizon to determine if the 
 only option available for them would be a filtering API, with no pagination 
 capabilities.
 
 It would be super awesome if Keystone had such a capabilities discovery API.
 
 Best,
 -jay
 
 [1] I don't mean *you* personally, Adam :)
 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing 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] [oslo] debugging the failures in oslo.messaging gate

2015-08-14 Thread Doug Hellmann

All patches to oslo.messaging are currently failing the 
gate-tempest-dsvm-neutron-src-oslo.messaging job because the neutron service 
dies. amuller, kevinbenton, and I spent a bunch of time looking at it today, 
and I think we have an issue introduced by some asymmetric gating between the 
two projects.

Neutron has 2 different modes for starting the RPC service, depending on the 
number of workers requested. The problem comes up with rpc_workers=0, which is 
the new default. In that mode, rather than using the ProcessLauncher, the RPC 
server is started directly in the current process. That results in wait() being 
called in a way that violates the new constraints being enforced within 
oslo.messaging after [1] landed. That patch is unreleased, so the only project 
seeing the problem is oslo.messaging. I’ve proposed a revert in [2], which 
passes the gate tests.

I have also added [3] to neutron to see if we can get the gate job to show the 
same error messages I was seeing locally (part of the trouble we’ve had with 
debugging this is the process exits quickly enough that some of the log 
messages are never being written). I’m using [4] as a patch in oslo.messaging 
that was failing before to trigger the job to get the necessary log. That patch 
should *not* be landed, since I don’t think the change it reverts is related to 
the problem, it was just handy for debugging.

The error message I see locally, “start/stop/wait must be called in the same 
thread”, is visible in this log snippet [5].

It’s not clear what the best path forward is. Obviously neutron is doing 
something with the RPC server that oslo.messaging doesn’t expect/want/like, but 
also obviously we can’t release oslo.messaging in its current state and break 
neutron. Someone with a better understanding of both neutron and oslo.messaging 
may be able to fix neutron’s use of the RPC code to avoid this case. There may 
be other users of oslo.messaging with the same ‘broken’ pattern, but IIRC 
neutron is unique in the way it runs both RPC and API services in the same 
process. To be safe, though, it may be better to log error messages instead of 
doing whatever we’re doing now to cause the process to exit. We can then set up 
a log stash search for the error message and find other applications that would 
be broken, fix them, and then switch oslo.messaging back to throwing an 
exception.

I’m going to be at the Ops summit next week, so I need to hand off debugging 
and fixing the issue to someone else on the Oslo team. We created an etherpad 
to track progress and make notes today, and all of these links are referenced 
there, too [6].

Thanks again to amuller and kevinbenton for the time they spent helping with 
debugging today!

Doug

[1] https://review.openstack.org/#/c/209043/
[2] https://review.openstack.org/#/c/213299/
[3] https://review.openstack.org/#/c/213360/
[4] https://review.openstack.org/#/c/213297/
[6] http://paste.openstack.org/show/415030/
[6] https://etherpad.openstack.org/p/wm2D6UGZbf


__
OpenStack Development Mailing 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] Proposing Gorka Eguileor for core

2015-08-14 Thread Walter A. Boring IV


+1

It gives me great pleasure to nominate Gorka Eguileor for Cinder core.

Gorka's contributions to Cinder core have been much apprecated:

https://review.openstack.org/#/q/owner:%22Gorka+Eguileor%22+project:openstack/cinder,p,0035b6410002dd11

60/90 day review stats:

http://russellbryant.net/openstack-stats/cinder-reviewers-60.txt
http://russellbryant.net/openstack-stats/cinder-reviewers-90.txt

Cinder core, please reply with a +1 for approval. This will be left
open until August 19th. Assuming there are no objections, this will go
forward after voting is closed.




__
OpenStack Development Mailing 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] Migrating existing projects in the stackforge namespace

2015-08-14 Thread James E. Blair

Hi,

As mentioned previously[1], we are retiring the stackforge/ namespace
for git repositories and creating new projects in openstack/.  This is
largely a cosmetic change and does not change the governance model for
new projects.

As part of this we want to move all of the projects that are currently
in the stackforge/ namespace into openstack/ to make it easier for them
to become official OpenStack projects in the future while reducing the
impact to the community that the current practice of sporadic renaming
causes.

To that end, I propose the following process:

1) We choose a date upon which to perform a mass migration of all
stackforge/ projects into openstack/.

I suggest either October 17 or November 7 (both Saturdays), as least
likely to interfere with the release or summit.

2) We create a wiki page for all such projects to either sign up for
that migration or indicate that they are no longer maintained.

3) Any stackforge projects that do not sign up for the migration within
a certain time are placed on the list of projects that are no longer
maintained.

4) We attempt to contact, by way of posts to the openstack-dev mailing
list, announcements at the cross project meeting, and direct emails to
the individuals who initially requested repository creation, people who
might be responsible for projects which have not responded and ensure
that they have a chance to respond.  We will freeze the list of projects
and portions of the project-config repository several days before the
migration, to facilitate creating and reviewing the necessary change.

5) On the migration date, the Infrastructure team will move all of the
projects at once.  We will generate the changes needed to do so
automatically, individual projects will not need to do anything except
approve .gitreview changes and possibly help fix any CI jobs that break
as a result of the moves.

6) For the projects that are no longer maintained, we will merge changes
to them that indicate that and make them read-only.

We will schedule a move in early September for the projects that have
already requested moves as part of becoming official OpenStack projects.
Please don't propose any more changes to move projects before the mass
migration.

While most new projects are being created directly in the openstack/
namespace, we will continue to create additional git repositories
associated with existing projects in the stackforge/ namespace so that
the constituent repositories associated with those projects are not
split across namespaces.  We will happily move those projects along with
the rest as part of the mass migration.

Please reply with any feedback or suggested improvements to this plan.
If we can achieve consensus on the approach, we will make further
announcements as to specifics soon.

Thanks,

Jim

[1] http://lists.openstack.org/pipermail/openstack-dev/2015-August/071816.html

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

Re: [openstack-dev] [Keystone] [Horizon] Pagination support for Identity dashboard entities



 On Aug 14, 2015, at 14:22, Adam Young ayo...@redhat.com wrote:
 
 On 08/14/2015 02:31 PM, David Lyle wrote:
 I understand the reasoning, but there are use cases for indexing (re: 
 searchlight) and auditing that are completely unsupported in keystone v3. As 
 from keystone, I have no way to exhaustively list who has accounts in my 
 cloud using OpenStack APIs. That seems like a hole that should be filled.
 
 Not possible.  Federation is a mapping from a remote service.
 
 We don't have the data.
 
 The only place where Keystone is likely to be holding on to users is for 
 service users.
 
 
 This is not the Keystone team being stubborn.  These are technical and 
 practical limitations based on how OpenStack is being deployed in the wild.
 
 
 LDAP does not provide sufficient tools to do pagination in a practical 
 manner.  LDAP does not guarantee ordering for query results, and there is no 
 limit and offset.  Holding a cursor open is not allowed by corporate IT.  
 
 

It also looks to be forward paging only, going back a page requires starting 
the query over. An error will require starting the query over. LDAP paging is 
meant to allow gathering of more data than server max not offset based. Order 
is not guaranteed on any restart, so it is likely to be major inconsistencies 
in what is on a page instead of minor. 

 
 
 
 
 
 Not to mention API consistency, which others have already brought up.
 
 David
 
 
 
 On Fri, Aug 14, 2015 at 9:02 AM, Morgan Fainberg morgan.fainb...@gmail.com 
 wrote:
 For the identity (users and groups) backend as long as we support LDAP (and 
 as side note federated users never show up in this list anyway) and with 
 the drive towards pushing all user management out of keystone itself to 
 ldap or other tools that do it better, I don't see pagination as something 
 we should be providing. Providing an inconsistent user experience based on 
 leaking underlying implementation details is something I am very against. 
 This stance ensures that horizon and other tools like it will not need to 
 know underlying implementation details to provide a consistent user 
 experience. Unfortunately here we do need to cater to the lowest common 
 denominator and filtering/searching/limiting is the clear common mechanism
 
 With regards to resources (projects, domains, etc) since we no longer 
 support using LDAP (deprecated with removal in mitaka) I have less strong 
 feelings towards and wouldn't block efforts to implement if it is not 
 already available (if not available this is likely a mitaka goal).
 
 --Morgan
 
 Sent via mobile
 
  On Aug 14, 2015, at 07:39, Jay Pipes jaypi...@gmail.com wrote:
 
  On 08/14/2015 09:14 AM, Morgan Fainberg wrote:
  As a quick note the api-ref you are linking to has some gaps/has not
  been kept in sync with the official api specifications.
 
  The official API specification is located at
  http://specs.openstack.org/openstack/keystone-specs/ (v2 and v3 sections
  at the top) and there is a known open bug to work with the docs team to
  get this in sync (somehow).
 
  Unfortunately there are a number of cases especially 
  with the identity
  backend where pagination just does not work (or works completely
  unreliably) such as utilizing the ldap driver. Either a 
  cursor must be
  maintained (problematic in REST) or the results could be wildly
  different every single request meaning each page is not really
  guaranteed to be the next page it could be the same/show inconsistent
  results. The second issue is that the pagination is not a good UX even
  where it works - the simple question is: if you can filter the results
  how many pages deep do you go before refining the query; think of your
  use of search engines.
 
  In light of these issues Keystone has opted for a filter / limit
  (config). If the results exceed the limit there is a truncation that
  occurs and it is recommended extra filtering be applied to reduce the
  total number of results.
 
  This discussion has gone around a few times, pagination in keystone is
  not currently on the roadmap. In addition to the above doc bug, we
  should work to better socialize this filter-over-paginate methodology.
 
  I understand all the things you write above about the problems that 
  Keystone's underlying architecture (driver-based, not always able to do 
  pagination in the individual drivers). However, it really does mean that 
  Keystone is the only project in OpenStack that behaves this way. All 
  other services provide limit/marker paginations, AFAIK, which is 
  efficient and, while not the same UX as a filtering methodology, is 
  entirely compatible and complementary to filtering.
 
  Best,
  -jay
 
  __
  OpenStack Development Mailing List (not for usage questions)
  Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

Re: [openstack-dev] [UX] [Keystone] [Horizon] Pagination support for Identity dashboard entities

2015-08-14 Thread Jay Pipes


On 08/14/2015 06:30 PM, Morgan Fainberg wrote:

On Aug 14, 2015, at 15:10, Jay Pipes jaypi...@gmail.com wrote:


On 08/14/2015 05:24 PM, Adam Young wrote:

On 08/14/2015 12:43 PM, Michael Krotscheck wrote:
1- Do users want to page through search results?

Does not matter:  in Federation, the User list is not available.


OK, so hobble the entire REST API for the deficiencies/architecture/reality of 
a single authentication/identity strategy.


2- Do users want to page through filter results? (do they use filter
results?)

This is the only practical tool available for LDAP.


Again, hobble the entire API for the deficiencies and anachronisms of a single 
identity driver.


The SQL driver is at best a toy and should go away.


And yet it is in deployments all over the world.

People said the same about MySQL. It was a toy and should go away. And 
yet, here we are, 15 years later, and MySQL is running in some of the 
world's biggest and most complex web applications. Asking for something 
to go away because you consider it a toy (a toy with better capabilities 
than other things, I might add) doesn't just make it so...


If anything, we should tell the anachronistic ActiveDirectory and LDAP 
solutions to go away ;)


 We are working diligently to provide the best solution for the small 
and large deployments and provide features we are regularly asked for 
(password lifecycle, complexity, better user management, etc).


Aren't we talking about better user management here?


Again I will reiterate, asking for every user that could have an assignment 
is absurd.


Nobody is asking for that. We are asking for list me the first page of 
users in the system, ordered by their ID (or email, or whatever). This 
is hardly absurd. In fact, it's how all other OpenStack API services 
expose pagination functionality. And it is complementary to things like 
Searchlight, not anathema to it.


 You should search for specific users if you need for find a user 
without an assignment (they can't access keystone or auth or act on 
OpenStack anyway). You should look at active assignments and we can 
implement pagination for that.


Where are you coming up with this find a user without an assignment 
use case? I've yet to hear anyone talking about this. The only use case 
that has been discussed is the (very common) one that Horizon needs to 
display a page of user account information, sorted by some key and 
filtered as needed.



It wont be a /users API call.


Why not?


3- If they want to page, do they want to be able to go back a page
and/or know their current page?
4- How much do users care about small data inconsistencies (i.e.
ordering of record sets changing from page-to-page).


So, yeah, we could support paging for SQL.


That would be great. Double bonus if this pagination API followed the examples 
of all the other OpenStack API services and didn't invent its own terms (page, 
per_page...).


I really do not want implementation details to be the cause of a massive UX 
change.


That is precisely the situation that Horizon finds itself in today: 
implementation details of Keystone's backend drivers causing Horizon to 
need to deal with Keystone like it's a special unicorn.


 Lets avoid doing that yet again in OpenStack. Asking horizon to have 
two completely different mechanisms based on what backend is following a 
poor design pattern we keep falling into where we expect the user to 
figure out/know what is different between deployments.


No, that is not at all what I said. I said that there should be a 
discovery mechanism so that **Horizon** can figure out whether it can 
use a standard get me a page of listed results user experience, or 
whether it can ONLY use a filtering strategy for the user experience...


Nobody has asked the end user to figure out what is different between 
deployments. We're talking about the dashboard here, and possibly the 
python-keystoneclient.


Best,
-jay


That is becoming a repository for service users only.  For the use
cases requested, we do not have the ability to implement.


Sure, but what you[1] *do* have the ability to implement is a capabilities 
discovery REST API that would allow tools like Horizon to determine if the only 
option available for them would be a filtering API, with no pagination 
capabilities.

It would be super awesome if Keystone had such a capabilities discovery API.

Best,
-jay

[1] I don't mean *you* personally, Adam :)

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


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

Re: [openstack-dev] [Keystone] [Horizon] Pagination support for Identity dashboard entities

2015-08-14 Thread Adam Young


On 08/14/2015 02:31 PM, David Lyle wrote:
I understand the reasoning, but there are use cases for indexing (re: 
searchlight) and auditing that are completely unsupported in keystone 
v3. As from keystone, I have no way to exhaustively list who has 
accounts in my cloud using OpenStack APIs. That seems like a hole that 
should be filled.


Not possible.  Federation is a mapping from a remote service.

We don't have the data.

The only place where Keystone is likely to be holding on to users is for 
service users.



This is not the Keystone team being stubborn.  These are technical and 
practical limitations based on how OpenStack is being deployed in the wild.



LDAP does not provide sufficient tools to do pagination in a practical 
manner.  LDAP does not guarantee ordering for query results, and there 
is no limit and offset.  Holding a cursor open is not allowed by 
corporate IT.









Not to mention API consistency, which others have already brought up.

David



On Fri, Aug 14, 2015 at 9:02 AM, Morgan Fainberg 
morgan.fainb...@gmail.com mailto:morgan.fainb...@gmail.com wrote:


For the identity (users and groups) backend as long as we support
LDAP (and as side note federated users never show up in this list
anyway) and with the drive towards pushing all user management out
of keystone itself to ldap or other tools that do it better, I
don't see pagination as something we should be providing.
Providing an inconsistent user experience based on leaking
underlying implementation details is something I am very against.
This stance ensures that horizon and other tools like it will not
need to know underlying implementation details to provide a
consistent user experience. Unfortunately here we do need to cater
to the lowest common denominator and filtering/searching/limiting
is the clear common mechanism

With regards to resources (projects, domains, etc) since we no
longer support using LDAP (deprecated with removal in mitaka) I
have less strong feelings towards and wouldn't block efforts to
implement if it is not already available (if not available this is
likely a mitaka goal).

--Morgan

Sent via mobile

 On Aug 14, 2015, at 07:39, Jay Pipes jaypi...@gmail.com
mailto:jaypi...@gmail.com wrote:

 On 08/14/2015 09:14 AM, Morgan Fainberg wrote:
 As a quick note the api-ref you are linking to has some
gaps/has not
 been kept in sync with the official api specifications.

 The official API specification is located at
 http://specs.openstack.org/openstack/keystone-specs/ (v2 and v3
sections
 at the top) and there is a known open bug to work with the docs
team to
 get this in sync (somehow).

 Unfortunately there are a number of cases especially with the
identity
 backend where pagination just does not work (or works completely
 unreliably) such as utilizing the ldap driver. Either a cursor
must be
 maintained (problematic in REST) or the results could be wildly
 different every single request meaning each page is not really
 guaranteed to be the next page it could be the same/show
inconsistent
 results. The second issue is that the pagination is not a good
UX even
 where it works - the simple question is: if you can filter the
results
 how many pages deep do you go before refining the query; think
of your
 use of search engines.

 In light of these issues Keystone has opted for a filter / limit
 (config). If the results exceed the limit there is a truncation
that
 occurs and it is recommended extra filtering be applied to
reduce the
 total number of results.

 This discussion has gone around a few times, pagination in
keystone is
 not currently on the roadmap. In addition to the above doc bug, we
 should work to better socialize this filter-over-paginate
methodology.

 I understand all the things you write above about the problems
that Keystone's underlying architecture (driver-based, not always
able to do pagination in the individual drivers). However, it
really does mean that Keystone is the only project in OpenStack
that behaves this way. All other services provide limit/marker
paginations, AFAIK, which is efficient and, while not the same UX
as a filtering methodology, is entirely compatible and
complementary to filtering.

 Best,
 -jay


__
 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

[openstack-dev] [puppet] master branch is now testing Liberty

2015-08-14 Thread Emilien Macchi

It's Friday, no fear.

Our Beaker (functional testing) jobs now deploy OpenStack Liberty using
RDO (delorean which is trunk) and Liberty-Staging (Ubuntu).
It will allow people to push features in master that are Liberty specific.

Some recommendation for our group though:
* please report on launchpad any issue you would hit because of this
change. If we see that it's too unstable and not usable, we will revert
to Kilo.
* backport everything merged in master that makes sense to live in
stable/kilo (bugfix or small features).

Have a great week-end!
-- 
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] Stackforge namespace retirement

2015-08-14 Thread James E. Blair

Fox, Kevin M kevin@pnnl.gov writes:

 What is the process for current stackforge projects to move into the
 openstack namespace then? Is it a simple request now, or a more
 complicated process?

Great question.  I have proposed a process for that in a new thread:

http://lists.openstack.org/pipermail/openstack-dev/2015-August/072140.html

-Jim

__
OpenStack Development Mailing 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] [UX] [Keystone] [Horizon] Pagination support for Identity dashboard entities

2015-08-14 Thread Jay Pipes


On 08/14/2015 05:24 PM, Adam Young wrote:

On 08/14/2015 12:43 PM, Michael Krotscheck wrote:

1- Do users want to page through search results?

Does not matter:  in Federation, the User list is not available.


OK, so hobble the entire REST API for the 
deficiencies/architecture/reality of a single authentication/identity 
strategy.



2- Do users want to page through filter results? (do they use filter
results?)

This is the only practical tool available for LDAP.


Again, hobble the entire API for the deficiencies and anachronisms of a 
single identity driver.



3- If they want to page, do they want to be able to go back a page
and/or know their current page?
4- How much do users care about small data inconsistencies (i.e.
ordering of record sets changing from page-to-page).


So, yeah, we could support paging for SQL.


That would be great. Double bonus if this pagination API followed the 
examples of all the other OpenStack API services and didn't invent its 
own terms (page, per_page...).



That is becoming a repository for service users only.  For the use
cases requested, we do not have the ability to implement.


Sure, but what you[1] *do* have the ability to implement is a 
capabilities discovery REST API that would allow tools like Horizon to 
determine if the only option available for them would be a filtering 
API, with no pagination capabilities.


It would be super awesome if Keystone had such a capabilities discovery API.

Best,
-jay

[1] I don't mean *you* personally, Adam :)

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

Re: [openstack-dev] [cinder] I have a question about openstack cinder zonemanager driver.

2015-08-14 Thread Walter A. Boring IV

Currently, The FCZM doesn't support this.   Also, from my experience 
Brocade and Cisco switches don't play well together when managing the 
same fabrics.


Walt


Hi, guys

 I am using Brocade FC switch in my OpenStack environment. I have 
a question about OpenStack cinder zonemanger driver.


I find that *[fc-zone-manager] *can only configure one zone driver. If 
I want to use two FC switches from different vendors at the same time.


One is Brocade FC switch, the other one is Cisco FC switch. Is there a 
method or solution configure two FC switch zone driver in one 
cinder.conf ?


I want them both to support Zone Manager.

**

**



__
OpenStack Development Mailing 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] [UX] [Keystone] [Horizon] Pagination support for Identity dashboard entities

On Fri, Aug 14, 2015 at 3:55 PM, Jay Pipes jaypi...@gmail.com wrote:

 On 08/14/2015 06:30 PM, Morgan Fainberg wrote:

 On Aug 14, 2015, at 15:10, Jay Pipes jaypi...@gmail.com wrote:

 On 08/14/2015 05:24 PM, Adam Young wrote:

 On 08/14/2015 12:43 PM, Michael Krotscheck wrote:
 1- Do users want to page through search results?

 Does not matter:  in Federation, the User list is not available.


 OK, so hobble the entire REST API for the
 deficiencies/architecture/reality of a single authentication/identity
 strategy.

 2- Do users want to page through filter results? (do they use filter
 results?)

 This is the only practical tool available for LDAP.


 Again, hobble the entire API for the deficiencies and anachronisms of a
 single identity driver.


 The SQL driver is at best a toy and should go away.


 And yet it is in deployments all over the world.

 People said the same about MySQL. It was a toy and should go away. And
 yet, here we are, 15 years later, and MySQL is running in some of the
 world's biggest and most complex web applications. Asking for something to
 go away because you consider it a toy (a toy with better capabilities than
 other things, I might add) doesn't just make it so...



The SQL identity backend is not providing comperable capabilities in a real
way. It is providing a very limited store for a user data. It does not
provide password complexity management, it does not allow for lockout based
on failed logins, it does not provide limits on re-use of password, it does
not provide clear user/group lifecycle management. It is not a real
identity store, it is a very limited example implementation.

These are all thing that have been regular requests of Keystone and
provided for free with the most basic LDAP installation (or FreeIPA). I am
inclined to say we should be moving towards LDAP being the identity store
by default instead of continuing to use the SQL store and do the
significant levels of enhancements needed (we have asked at midcycles and
summits and have had no one interested in doing this enhancement work). The
comparison to MySQL is incorrect, MySQL legitimately comparable featureset
to the other options and the SQL data store we are using in openstack lacks
basic identity management capabilities.


 If anything, we should tell the anachronistic ActiveDirectory and LDAP
 solutions to go away ;)

  We are working diligently to provide the best solution for the small and
 large deployments and provide features we are regularly asked for (password
 lifecycle, complexity, better user management, etc).

 Aren't we talking about better user management here?


And Keystone's APIs are very poor user management. There are tools/systems
out there that do it far better that we can leverage. FreeIPA is one such
example. The Keystone User Management API is unused in many deployments and
will not be considered for defcore because most all deployments use a
read-only mode managed by an external service.

With the new Tokenless Auth via x509 (Liberty Target) we now can eliminate
service users needing to be in SQL as well.


 Again I will reiterate, asking for every user that could have an
 assignment is absurd.


 Nobody is asking for that. We are asking for list me the first page of
 users in the system, ordered by their ID (or email, or whatever). This is
 hardly absurd. In fact, it's how all other OpenStack API services expose
 pagination functionality. And it is complementary to things like
 Searchlight, not anathema to it.


You are asking for it without being explicit about it (or may not be
aware). Asking Keystone to list users is infact list all users the Keystone
service can see assignments or not. What I've been advocating as the
alternative is to use the query active assignments API calls (and enhance
those) to show who has access to the OpenStack service. It wont be a /users
call because /users is tied to the identity subsystem that (above) isn't
part of defcore and wont be because of the aforementioned read-only and
externally managed system. The exception may be the search for a user
API I was alluding to that should be implemented/enhanced for the sake of
finding a specific user (if the user in question doesn't have an active
assignment).


  You should search for specific users if you need for find a user without
 an assignment (they can't access keystone or auth or act on OpenStack
 anyway). You should look at active assignments and we can implement
 pagination for that.

 Where are you coming up with this find a user without an assignment use
 case? I've yet to hear anyone talking about this. The only use case that
 has been discussed is the (very common) one that Horizon needs to display a
 page of user account information, sorted by some key and filtered as needed.


It wont be a /users API call.


 Why not?


See Above comment.


 3- If they want to page, do they want to be able to go back a page
 and/or know their current page?
 4- How much do users care about

Re: [openstack-dev] [cinder] Proposing Gorka Eguileor for core

2015-08-14 Thread John Griffith

On Fri, Aug 14, 2015 at 6:06 PM, Walter A. Boring IV walter.bor...@hp.com
wrote:

 +1

 It gives me great pleasure to nominate Gorka Eguileor for Cinder core.

 Gorka's contributions to Cinder core have been much apprecated:


 https://review.openstack.org/#/q/owner:%22Gorka+Eguileor%22+project:openstack/cinder,p,0035b6410002dd11

 60/90 day review stats:

 http://russellbryant.net/openstack-stats/cinder-reviewers-60.txt
 http://russellbryant.net/openstack-stats/cinder-reviewers-90.txt

 Cinder core, please reply with a +1 for approval. This will be left
 open until August 19th. Assuming there are no objections, this will go
 forward after voting is closed.



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


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

Re: [openstack-dev] [devstack] Restart openstack service

2015-08-14 Thread John Griffith

On Thu, Aug 13, 2015 at 11:01 PM, Guo, Ruijing ruijing@intel.com
wrote:

 If you can commit it to devstack, it will benefit everyone

 -Original Message-
 From: Tony Breeds [mailto:t...@bakeyournoodle.com]
 Sent: Friday, August 14, 2015 12:21 PM
 To: OpenStack Development Mailing List (not for usage questions)
 Subject: Re: [openstack-dev] [devstack] Restart openstack service

 On Fri, Aug 14, 2015 at 04:01:20AM +, Guo, Ruijing wrote:
  Yes. I like this idea to restart all services including nova, neutron,
 cinder, etc:)

 You can *probably* use

 HOST=devstack.domain ./stack-smash.sh '.*'

 to restart all the services running under devstack.

 Note my list of windows is taken from my typical run and isn't
 comprehensive

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

Is there some reason that rejoin doesn't work?  There's a rejoin.sh that
does this very thing:  crtl-a: quit in screen to terminate everything,
then you can run rejoin.sh and relaunch everything.  Of course, if you
don't use screen option then I don't know :)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [devstack] Restart openstack service

2015-08-14 Thread John Griffith

On Fri, Aug 14, 2015 at 10:03 PM, John Griffith john.griffi...@gmail.com
wrote:



 On Thu, Aug 13, 2015 at 11:01 PM, Guo, Ruijing ruijing@intel.com
 wrote:

 If you can commit it to devstack, it will benefit everyone

 -Original Message-
 From: Tony Breeds [mailto:t...@bakeyournoodle.com]
 Sent: Friday, August 14, 2015 12:21 PM
 To: OpenStack Development Mailing List (not for usage questions)
 Subject: Re: [openstack-dev] [devstack] Restart openstack service

 On Fri, Aug 14, 2015 at 04:01:20AM +, Guo, Ruijing wrote:
  Yes. I like this idea to restart all services including nova, neutron,
 cinder, etc:)

 You can *probably* use

 HOST=devstack.domain ./stack-smash.sh '.*'

 to restart all the services running under devstack.

 Note my list of windows is taken from my typical run and isn't
 comprehensive

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


 Is there some reason that rejoin doesn't work?  There's a rejoin.sh that
 does this very thing:  crtl-a: quit in screen to terminate everything,
 then you can run rejoin.sh and relaunch everything.  Of course, if you
 don't use screen option then I don't know :)

 Ohh... one thing though, be advised that by default devstack uses
non-persistent loopback files.  That means if you do a reboot, you lose
your backing store for things like Cinder and Swift and you have to
recreate them yourself; or you can modify them to be persisted.
__
OpenStack Development Mailing 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] [magnum]password for registry v2

2015-08-14 Thread Fox, Kevin M

I vote for #3. ;)

But seriously, please do help review it so we make sure everyone's use cases 
are handled ok.

Thanks,
Kevin

From: 王华 [wanghua.hum...@gmail.com]
Sent: Thursday, August 13, 2015 6:25 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [magnum]password for registry v2

Hi hongbin,
I have comments in line.

Thank you.

Regards,
Wanghua

On Fri, Aug 14, 2015 at 6:20 AM, Hongbin Lu 
hongbin...@huawei.commailto:hongbin...@huawei.com wrote:
Hi Wanghua,

For the question about how to pass user password to bay nodes, there are 
several options here:

1.   Directly inject the password to bay nodes via cloud-init. This might 
be the simplest solution. I am not sure if it is OK in security aspect.

2.   Inject a scoped Keystone trust to bay nodes and use it to fetch user 
password from Barbican (suggested by Adrian).

If we use trust, who we should let user trust?  If we let user trust magnum, 
then the credential of magnum will occur in vm. I think it is insecure.

3.   Leverage the solution proposed by Kevin Fox [1]. This might be a 
long-term solution.

For the security concerns about storing credential in a config file, I need 
clarification. What is the config file? Is it a dokcer registry v2 config file? 
I guess the credential stored there will be used to talk to swift. Is that 
correct? In general, it is
The credential stored in docker registry v2 config file is used to talk to 
swift.

insecure to store user credential inside a VM, because anyone can take a 
snapshot of the VM and boot another VM from the snapshot. Maybe storing a 
scoped credential in the config file could mitigate the security risk. Not sure 
if there is a better solution.

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

Best regards,
Hongbin

From: 王华 [mailto:wanghua.hum...@gmail.commailto:wanghua.hum...@gmail.com]
Sent: August-13-15 4:06 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [magnum]password for registry v2

Hi all,

In order to add registry v2 to bay nodes[1], authentication information is 
needed for the registry to upload and download files from swift. The swift 
storage-driver in registry now needs the parameters as described in [2]. User 
password is needed. How can we get the password?

1. Let user pass password in baymodel-create.
2. Use user token to get password from keystone

Is it suitable to store user password in db?

It may be insecure to store password in db and expose it to user in a config 
file even if the password is encrypted. Heat store user password in db before, 
and now change to keystone trust[3]. But if we use keystone trust, the swift 
storage-driver does not support it. If we use trust, we expose magnum user's 
credential in a config file, which is also insecure.

Is there a secure way to implement this bp?

[1] https://blueprints.launchpad.net/magnum/+spec/registryv2-in-master
[2] 
https://github.com/docker/distribution/blob/master/docs/storage-drivers/swift.md
[3] https://wiki.openstack.org/wiki/Keystone/Trusts

Regards,
Wanghua

__
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] [magnum]password for registry v2

2015-08-14 Thread Fox, Kevin M

Today, trusts can only be scoped to roles, not to individual files/containers. 
And its only subtractive. So you can only drop roles to restrict roles granted. 
Most OpenStack services today don't use many roles, so they are mostly all or 
nothing (only Member role for example). So Trusts usually allow way too much 
power to the Truestee. To give read access to one file in swift, you have to 
give delete access to all vm's in the tenant. Thats undesirable. Hence the 
Instance User spec.

Thanks,
Kevin


From: Adrian Otto [adrian.o...@rackspace.com]
Sent: Thursday, August 13, 2015 7:11 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [magnum]password for registry v2

Keystone v3 trusts can be scoped to specific actions. In this case the node 
needs a valid auth token to use swift. The token can be a trust token. We 
should generate a trust token scoped to swift for a given user (project) and 
tenant. It can use a system domain account that has a role that allows it to 
CRUD objects in a particular swift storage container. Then the registry v2 
software can use the swift trust token to access swift, but not other OpenStack 
services. Depending on the trust enforcement available in swift, it may even be 
possible to prevent creation of new swift storage containers. We could check to 
be sure.

The scoped swift trust token can be injected into the bay master at creation 
time using cloud-init.

--
Adrian

On Aug 13, 2015, at 6:46 PM, 王华 
wanghua.hum...@gmail.commailto:wanghua.hum...@gmail.com wrote:

Hi hongbin,
I have comments in line.

Thank you.

Regards,
Wanghua

On Fri, Aug 14, 2015 at 6:20 AM, Hongbin Lu 
hongbin...@huawei.commailto:hongbin...@huawei.com wrote:
Hi Wanghua,

For the question about how to pass user password to bay nodes, there are 
several options here:

1.   Directly inject the password to bay nodes via cloud-init. This might 
be the simplest solution. I am not sure if it is OK in security aspect.

2.   Inject a scoped Keystone trust to bay nodes and use it to fetch user 
password from Barbican (suggested by Adrian).

If we use trust, who we should let user trust?  If we let user trust magnum, 
then the credential of magnum will occur in vm. I think it is insecure.

3.   Leverage the solution proposed by Kevin Fox [1]. This might be a 
long-term solution.

For the security concerns about storing credential in a config file, I need 
clarification. What is the config file? Is it a dokcer registry v2 config file? 
I guess the credential stored there will be used to talk to swift. Is that 
correct? In general, it is
The credential stored in docker registry v2 config file is used to talk to 
swift.

insecure to store user credential inside a VM, because anyone can take a 
snapshot of the VM and boot another VM from the snapshot. Maybe storing a 
scoped credential in the config file could mitigate the security risk. Not sure 
if there is a better solution.

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

Best regards,
Hongbin

From: 王华 [mailto:wanghua.hum...@gmail.commailto:wanghua.hum...@gmail.com]
Sent: August-13-15 4:06 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [magnum]password for registry v2

Hi all,

In order to add registry v2 to bay nodes[1], authentication information is 
needed for the registry to upload and download files from swift. The swift 
storage-driver in registry now needs the parameters as described in [2]. User 
password is needed. How can we get the password?

1. Let user pass password in baymodel-create.
2. Use user token to get password from keystone

Is it suitable to store user password in db?

It may be insecure to store password in db and expose it to user in a config 
file even if the password is encrypted. Heat store user password in db before, 
and now change to keystone trust[3]. But if we use keystone trust, the swift 
storage-driver does not support it. If we use trust, we expose magnum user's 
credential in a config file, which is also insecure.

Is there a secure way to implement this bp?

[1] https://blueprints.launchpad.net/magnum/+spec/registryv2-in-master
[2] 
https://github.com/docker/distribution/blob/master/docs/storage-drivers/swift.md
[3] https://wiki.openstack.org/wiki/Keystone/Trusts

Regards,
Wanghua

__
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.orgmailto:openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

Re: [openstack-dev] [Fuel][Puppet] Keystone V2/V3 service endpoints

2015-08-14 Thread Gilles Dubreuil



On 13/08/15 23:29, Rich Megginson wrote:
 On 08/13/2015 12:41 AM, Gilles Dubreuil wrote:
 Hi Matthew,

 On 11/08/15 01:14, Rich Megginson wrote:
 On 08/10/2015 07:46 AM, Matthew Mosesohn wrote:
 Sorry to everyone for bringing up this old thread, but it seems we may
 need more openstackclient/keystone experts to settle this.

 I'm referring to the comments in
 https://review.openstack.org/#/c/207873/
 Specifically comments from Richard Megginson and Gilles Dubreuil
 indicating openstackclient behavior for v3 keystone API.


 A few items seem to be under dispute:
 1 - Keystone should be able to accept v3 requests at
 http://keystone-server:5000/http://keystone-server:5000/
 I don't think so.  Keystone requires the version suffix /v2.0 or
 /v3.

 Yes, if the public endpoint is set without a version then the service
 can deal with either version.

 http://paste.openstack.org/raw/412819/

 That is not true for the admin endpoint (authentication is already done,
 the admin services deals only with tokens), at least for now, Keystone
 devs are working on it.
 
 I thought it worked like this - the openstack cli will infer from the
 arguments if it should do v2 or v3 auth.  In the above case for v3,
 since you specify the username/password, osc knows it has to use
 password auth (as opposed to token auth), and since all of the required
 v3 arguments are provided (v3 api version, domains for user/project), it
 can use v3 password auth.  It knows it has to use the /v3/auth/token
 path to get a token.
 
 Similarly for v2, since it only has username/password, no v3 api or v3
 domain arguments, it knows it has to use v2 password auth.  It knows it
 has to use /v2.0/token to get a token.
 
 With the puppet-keystone code, since it uses TOKEN/URL, osc cannot infer
 if it can use v2 or v3, so it requires the /v2.0 or /v3 suffix, and
 the api version.
 

First of my apologies because I confused admin enpdoint with the admin
service (or whatever that's dubbed).

As of Keystone v3 (not the API, the latest version of Keystone which
supports both API v2.0 and V3), the OS_AUTH_URL doesn't need the
version. That can be effectively any of the endpoints, either the main
(or public) by default on port 5000 or the admin by default on port
35357, the third one internal pointing to either of the first two ones.

This is a behavior at Keystone level not at the OSC. I mean OSC will
just reflect the http-api behavior.

Now the admin service, the one needed for the OS-TOKEN (used for
bootstrapping) needs a URL (OS_URL) with a version to work.

ATM, the issue with puppet keystone is that endpoints, OS_URL and
OS_AUTH_URL are walking on each others.



 2 - openstackclient should be able to interpret v3 requests and append
 v3/ to OS_AUTH_URL=http://keystone-server.5000/ or rewrite the URL
 if it is set as
 OS_AUTH_URL=http://keystone-server.5000/http://keystone-server.5000/
 It does, if it can determine from the given authentication arguments if
 it can do v3 or v2.0.

 It effectively does, again, assuming the path doesn't contain a version
 number (x.x.x.x:5000)

 3 - All deployments require /etc/keystone/keystone.conf with a token
 (and not simply use openrc for creating additional endpoints, users,
 etc beyond keystone itself and an admin user)
 No.  What I said about this issue was Most people using
 puppet-keystone, and realizing Keystone resources on nodes that are not
 the Keystone node, put a /etc/keystone/keystone.conf on that node with
 the admin_token in it.

 That doesn't mean the deployment requires /etc/keystone/keystone.conf.
 It should be possible to realize Keystone resources on non-Keystone
 nodes by using ENV or openrc or other means.

 Agreed. Also keystone.conf is used only to bootstrap keystone
 installation and create admin users, etc.


 I believe it should be possible to set v2.0 keystone OS_AUTH_URL in
 openrc and puppet-keystone + puppet-openstacklib should be able to
 make v3 requests sensibly by manipulating the URL.
 Yes.  Because for the puppet-keystone resource providers, they are coded
 to a specific version of the api, and therefore need to be able to
 set/override the OS_IDENTITY_API_VERSION and the version suffix in
 the URL.

 No. To support V2 and V3, the OS_AUTH_URL must not contain any version
 in order.

 The less we deal with the version number the better!

 Additionally, creating endpoints/users/roles shouldbe possible via
 openrc alone.
 Yes.

 Yes, the openrc variables are used, if not available then the service
 token from the keystone.conf is used.

 It's not possible to write single node tests that can demonstrate this
 functionality, which is why it probably went undetected for so long.
 And since this is supported, we need tests for this.
 I'm not sure what's the issue besides the fact keystone_puppet doesn't
 generate a RC file once the admin user has been created. That is left to
 be done by the composition layer. Although we might want to integrate
 that.

 If that issue persists,

Re: [openstack-dev] [qa][devstack][keystone] Updating devstack to Identity V3

2015-08-14 Thread Ihar Hrachyshka

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 08/14/2015 08:15 AM, Jamie Lennox wrote:
 Hi all,
 
 I've been pushing for a while now to convert devstack to completely
 use the identity v3 API as we try to deprecate the v2.0 API.
 Currently all the functions in functions-common consume the v3 API
 via setting --os -identity-api-version 3 for each command to
 override the v2 default. https://review.openstack.org/#/c/186684/
 changes this by exporting OS_IDENTITY_API_VERSION=3 at the
 beginning meaning that all keystone commands will now default to
 the v3 api.
 

Recently I started to experience an 'empty service catalog' error from
neutron client when trying to execute any commands that can be fixed
by doing:

$ neutron router-list
The service catalog is empty.
$ export OS_TENANT_NAME=demo
$ neutron router-list
...proper output...

Is it somehow related to v3 work? Do we validate that clients behave
properly in devstack gate?
Ihar
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJVzcc9AAoJEC5aWaUY1u57nuoIAKO4wmLfOfG8vifHsUGqzazs
Kenuyrh+AEC1u7qNlsjnWFGKl/H2H7OT6uTD7Js6U+PW1HIif9TJdJUD2cfGSLuE
m368pN83U0QlA38vR/ubMAeXDc9E1bmCF39NSuvvE0ld7zckI7PjuFCx7FsYAknm
oZQY3LHygRXWCoEvVzO/VsW6jVwYBSWd+SE9U9Qv/lNhYo3CJaGY63z74v7nCEIK
w/YIH+KXUII1Hjho8VaJOpde0xvjXYrjyMG0UaWGy/sH92RNnNeU21C3pJYrU70O
xi4vZGY2KFXOZF3ogjuRSqDhA6aCf3Qw3bEu6SOscDxrT3YzyGByxnaSOR9vpZg=
=nT61
-END 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] [Magnum] Consistent functional test failures

2015-08-14 Thread Kai Qiang Wu

I have checked with infra team members. For two instances, 10GB each should
be OK.

So I add some steps to create magnum specific flavor(8 GB disk), instead of
use the existed devstack flavors (m1.small needs 20GB, m1.tiny can not be
used)

Magnum creates one for jenkins job and delete it when tests finished.


Thanks

Best Wishes,

Kai Qiang Wu (吴开强  Kennan）
IBM China System and Technology Lab, Beijing

E-mail: wk...@cn.ibm.com
Tel: 86-10-82451647
Address: Building 28(Ring Building), ZhongGuanCun Software Park,
 No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China
100193

Follow your heart. You are miracle!



From:   Clark Boylan cboy...@sapwetik.org
To: openstack-dev@lists.openstack.org
Date:   08/14/2015 08:05 AM
Subject:Re: [openstack-dev] [Magnum] Consistent functional test
failures



On Thu, Aug 13, 2015, at 03:13 AM, Tom Cammann wrote:
 Hi Team,

 Wanted to let you know why we are having consistent functional test
 failures in the gate.

 This is being caused by Nova returning No valid host to heat:

 2015-08-13 08:26:16.303 31543 INFO heat.engine.resource [-] CREATE:
 Server kube_minion [12ab45ef-0177-4118-9ba0-3fffbc3c1d1a] Stack
 testbay-y366b2atg6mm-kube_minions-cdlfyvhaximr-0-dufsjliqfoet
 [b40f0c9f-cb54-4d75-86c3-8a9f347a27a6]
 2015-08-13 08:26:16.303 31543 ERROR heat.engine.resource Traceback (most
 recent call last):
 2015-08-13 08:26:16.303 31543 ERROR heat.engine.resource File
 /opt/stack/new/heat/heat/engine/resource.py, line 625, in
 _action_recorder
 2015-08-13 08:26:16.303 31543 ERROR heat.engine.resource yield
 2015-08-13 08:26:16.303 31543 ERROR heat.engine.resource File
 /opt/stack/new/heat/heat/engine/resource.py, line 696, in _do_action
 2015-08-13 08:26:16.303 31543 ERROR heat.engine.resource yield
 self.action_handler_task(action, args=handler_args)
 2015-08-13 08:26:16.303 31543 ERROR heat.engine.resource File
 /opt/stack/new/heat/heat/engine/scheduler.py, line 320, in wrapper
 2015-08-13 08:26:16.303 31543 ERROR heat.engine.resource step =
 next(subtask)
 2015-08-13 08:26:16.303 31543 ERROR heat.engine.resource File
 /opt/stack/new/heat/heat/engine/resource.py, line 670, in
 action_handler_task
 2015-08-13 08:26:16.303 31543 ERROR heat.engine.resource while not
 check(handler_data):
 2015-08-13 08:26:16.303 31543 ERROR heat.engine.resource File
 /opt/stack/new/heat/heat/engine/resources/openstack/nova/server.py,
 line 759, in check_create_complete
 2015-08-13 08:26:16.303 31543 ERROR heat.engine.resource return
 self.client_plugin()._check_active(server_id)
 2015-08-13 08:26:16.303 31543 ERROR heat.engine.resource File
 /opt/stack/new/heat/heat/engine/clients/os/nova.py, line 232, in
 _check_active
 2015-08-13 08:26:16.303 31543 ERROR heat.engine.resource 'code':
 fault.get('code', _('Unknown'))
 2015-08-13 08:26:16.303 31543 ERROR heat.engine.resource
 ResourceInError: Went to status ERROR due to Message: No valid host was
 found. There are not enough hosts available., Code: 500

 And this in turn is being caused by the compute instance running out of
 disk space:

 2015-08-13 08:26:15.216 DEBUG nova.filters
 [req-e5bb52cb-387e-4638-911e-8c72aa1b6400 admin admin] Starting with 1
 host(s) get_filtered_objects /opt/stack/new/nova/nova/filters.py:70
 2015-08-13 08:26:15.217 DEBUG nova.filters
 [req-e5bb52cb-387e-4638-911e-8c72aa1b6400 admin admin] Filter
 RetryFilter returned 1 host(s) get_filtered_objects
 /opt/stack/new/nova/nova/filters.py:84
 2015-08-13 08:26:15.217 DEBUG nova.filters
 [req-e5bb52cb-387e-4638-911e-8c72aa1b6400 admin admin] Filter
 AvailabilityZoneFilter returned 1 host(s) get_filtered_objects
 /opt/stack/new/nova/nova/filters.py:84
 2015-08-13 08:26:15.217 DEBUG nova.filters
 [req-e5bb52cb-387e-4638-911e-8c72aa1b6400 admin admin] Filter RamFilter
 returned 1 host(s) get_filtered_objects
 /opt/stack/new/nova/nova/filters.py:84
 2015-08-13 08:26:15.218 DEBUG nova.scheduler.filters.disk_filter
 [req-e5bb52cb-387e-4638-911e-8c72aa1b6400 admin admin]
 (devstack-trusty-rax-dfw-4299602, devstack-trusty-rax-dfw-4299602)
 ram:5172 disk:17408 io_ops:0 instances:1 does not have 20480 MB usable
 disk, it only has 17408.0 MB usable disk. host_passes
 /opt/stack/new/nova/nova/scheduler/filters/disk_filter.py:60
 2015-08-13 08:26:15.218 INFO nova.filters
 [req-e5bb52cb-387e-4638-911e-8c72aa1b6400 admin admin] Filter DiskFilter
 returned 0 hosts

 For now a recheck seems to work about 1 in 2, so we can still land
 patches.

 The fix for this could be to clean up our Magnum devstack install more
 aggressively, which might be as simple as cleaning up the images we use,
 or get infra to provide our tests with a larger disk size. I will
 probably test out a patch today which cleans up the images we use in
 devstack to see if that helps.

It is not

Re: [openstack-dev] [Nova] [Cinder] [Glance] glance_store and glance

2015-08-14 Thread stuart . mclaren

I got zero responses on the mailing list raising a problem with Glance v2 [1].

I got zero responses on cross project meeting raising a problem with Glance v2
[2].

I'm very happy with my choice of words, because I think this hand slap on
Glance is the first time I got acknowledgement in my frustration with Glance.

I should not have to attend a Glance meeting to get someone to fix Glance v2
integration issues in Cinder.

To start, Glance should assign a cross project liaison [4] to actually respond
to integration issues in Cinder.

Having focuses on the following is not helping:

* Artifacts (I honestly don't know what this is and failed to find an
explanation that's *not* some API doc).

Hi Mike,

The original patch to extend Glance's mission to include artifacts is here:

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

The set of approvers show that this was an OpenStack-wide effort rather
than a solo run by Glance.

At the summit in Vancouver we held a session to revisit this. Around 40
people attended (including around 7 TC members) and debated artifacts
openly and with a constructive tone.

We reached out to the community for feedback and acted as best we could
on the feedback we received.

It would have been ok (if unpopular) for us to have acted unilaterally.

How would Cinder have handled this type of situation? What could/should
we have done differently? What would you suggest we do now?

* Tagging

If you mean 'metadefs' I'd tend to agree here. But, post the big tent
model, we have -- at least in one case -- kept focus by promoting proposed
non-core functionality to its own project:

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

* Role based properties [5] (who is asking for this, and why is Glance
enforcing roles?)

Protected properties are typically used for licensing, so there is a real
business/legal use case here. The public clouds I know of use them. Is the
implementation stellar? Possibly not.

This is a mess, and complete lack of focus on being what Glance was once good
at, a registry for images.

--
Mike Perez

Re: [openstack-dev] [sahara] Proposing Ethan Gafford for the core reviewer team

2015-08-14 Thread Telles Nobrega

+1

On Fri, Aug 14, 2015 at 7:11 AM Alexander Ignatov aigna...@mirantis.com
wrote:

 +1

 Regards,
 Alexander Ignatov



 On 13 Aug 2015, at 18:29, Sergey Reshetnyak sreshetn...@mirantis.com
 wrote:

 +2

 2015-08-13 18:07 GMT+03:00 Matthew Farrellee m...@redhat.com:

 On 08/13/2015 10:56 AM, Sergey Lukjanov wrote:

 Hi folks,

 I'd like to propose Ethan Gafford as a member of the Sahara core
 reviewer team.

 Ethan contributing to Sahara for a long time and doing a great job on
 reviewing and improving Sahara. Here are the statistics for reviews
 [0][1][2] and commits [3]. BTW Ethan is already stable maint team core
 for Sahara.

 Existing Sahara core reviewers, please vote +1/-1 for the addition of
 Ethan to the core reviewer team.

 Thanks.

 [0]

 https://review.openstack.org/#/q/reviewer:%22Ethan+Gafford+%253Cegafford%2540redhat.com%253E%22,n,z
 [1] http://stackalytics.com/report/contribution/sahara-group/90
 [2] http://stackalytics.com/?user_id=egaffordmetric=marks
 [3]

 https://review.openstack.org/#/q/owner:%22Ethan+Gafford+%253Cegafford%2540redhat.com%253E%22+status:merged,n,z

 --
 Sincerely yours,
 Sergey Lukjanov
 Sahara Technical Lead
 (OpenStack Data Processing)
 Principal Software Engineer
 Mirantis Inc.


 +1 ethan has really taken to sahara, providing valuable input to both
 development and deployments as well has taking on the manila integration



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

-- 
Telles Nobrega
__
OpenStack Development Mailing 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] Tragedy of the Commons (was: Possible issues cryptography 1.0 and os-client-config 1.6.2)

2015-08-14 Thread Jeremy Stanley

On 2015-08-14 10:52:55 +0100 (+0100), Chris Dent wrote:
 On Fri, 14 Aug 2015, Clint Byrum wrote:
  
  The same is true for these bugs. Yes they're real, yes more orgs
  should devote developers to fixing them.
 
 This may be the root of my concern and something that we're going
 to have to address sooner than later.
[...]

Deserves its own thread, but basically anything that isn't directly
connected to writing more patches is subject to a tragedy of the
commons in our community. Member companies are happy to donate
developers to write more code (especially if it's in service of
implementing a driver for their proprietary hardware/software or a
feature they plan to leverage in some upcoming product), but we have
too few working on anything that supports the broader project much
less free software as a whole.

There are some companies (thank you!) whose management realize it's
to their benefit to make OpenStack successful by sponsoring or
nurturing talented contributors to work on fixing bugs in neglected
core code on some of our larger projects, reviewing changes across
the board rather than just those submitted by their coworkers,
contributing to efforts like documentation, quality assurance,
translation, security, coordinating releases, backporting to stable
branches, helping run and improve our community infrastructure...

In many cases contributors _want_ to be involved in these important
efforts, but are unable to convince their employers to allow them to
spend time working on part of OpenStack which doesn't directly serve
some product roadmap. Our foundation staff and board of directors
are well placed to put appropriate pressure on member companies who
have been favoring their own tactical contributions over strategic
work to benefit us all. Let them know when you see this happening.

https://www.openstack.org/foundation/staff
https://www.openstack.org/foundation/board-of-directors

-- 
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] [openstack][magnum][heat]problems for synchronizing stack parameters from heat

2015-08-14 Thread Steven Hardy

On Fri, Aug 14, 2015 at 05:34:59PM +0800, 王华 wrote:
Hi Clint Byrum,
Trusts can solve this problem, but it may cause performance problem.
When we want to get a stack, we need to get the trust_id from db first,
andA 
authenticate with the trust_id, then we can get the stack. A 

I'm not sure you actually need trusts, you just need a token scoped to the
appropriate project, so if your admin user has sufficient roles in all the
projects, you can iterate over the projects and get a token per-project,
such that the scope of the project_id matches the tenant/project in the
request to heat.

I appreciate this isn't much more efficient than the impersonation
approach, but it does reduce the complexity a bit.

Steve

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

Re: [openstack-dev] [Nova] [Cinder] [Glance] glance_store and glance


On 14/08/15 13:06 +0100, stuart.mcla...@hp.com wrote:

I got zero responses on the mailing list raising a problem with Glance v2 [1].

I got zero responses on cross project meeting raising a problem with Glance v2
[2].

I'm very happy with my choice of words, because I think this hand slap on
Glance is the first time I got acknowledgement in my frustration with Glance.

I should not have to attend a Glance meeting to get someone to fix Glance v2
integration issues in Cinder.

Glance is trying to increase v2 integration with Nova besides show [3], but
I would recommend Nova to not accept further v2 integration until Glance has
figured out how to handle issues in projects that already have v2 integration.

To start, Glance should assign a cross project liaison [4] to actually respond
to integration issues in Cinder.

Having focuses on the following is not helping:

* Artifacts (I honestly don't know what this is and failed to find an
explanation that's *not* some API doc).


Hi Mike,

There has definitely been debate around artifacts, both within and outside
the project.  Rather than beating us up, I'm genuinely interested to
know if you have any words of advice on how we could have handled this
differently (to avoid 'pissing off the community').


+1

While I think the comments below are spot on and they explain why some
things happened, I do agree with Mike that we - Glance - as a community have
lost focus and there hasn't been enough dedication as in previous
cycles.

I see this as an opportunity for us to reflect and work on better
plans for Mitaka. Let's not focus just on the examples Mike used
since those are just examples that might give the right/wrong
impression to people outside the Glance community.

I'd really like us to take a step back and look at what has been
accomplished in this cycle. That should give us a better understanding
on where we should be headed in the next one and it'll also help us
understanding where we've failed.


The original patch to extend Glance's mission to include artifacts is here:

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

The set of approvers show that this was an OpenStack-wide effort rather
than a solo run by Glance.

At the summit in Vancouver we held a session to revisit this.  Around 40
people attended (including around 7 TC members) and debated artifacts
openly and with a constructive tone.

My memory is that opinions in the room were fairly equally split. One
TC member said it would be 'embarrasing' if OpenStack had two catalog
services. Another TC member adamently advocated that Glance should stick
to images.

We reached out to the community for feedback and acted as best we could
on the feedback we received.

It would have been ok (if unpopular) for us to have acted unilaterally.

How would Cinder have handled this type of situation? What could/should
we have done differently? What would you suggest we do now?


* Tagging


If you mean 'metadefs' I'd tend to agree here. But, post the big tent
model, we have -- at least in one case -- kept focus by promoting proposed
non-core functionality to its own project:

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


ah metadef, yeah... I'll leave this discussion for a different thread.


* Role based properties [5] (who is asking for this, and why is Glance
enforcing roles?)


Protected properties are typically used for licensing, so there is a real
business/legal use case here. The public clouds I know of use them. Is the
implementation stellar? Possibly not.


And now I know what Mike was referring to.

Thanks, Stuart.
Flavio

--
@flaper87
Flavio Percoco


pgpwOnmoBlsIO.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] [Monasca] Minutes for Monasca mid-cycle meetup

2015-08-14 Thread Ildikó Váncsa

Hi,

I will try to join if I can, I have an overlapping meeting on Tuesdays.

In general I think it would be really good to start a closer collaboration, the 
componentization work in Ceilometer gives a really good opportunity as Chris 
described.

Best Regards,
Ildikó

 -Original Message-
 From: Chris Dent [mailto:chd...@redhat.com]
 Sent: August 12, 2015 15:45
 To: OpenStack Development Mailing List (not for usage questions)
 Subject: Re: [openstack-dev] [Monasca] Minutes for Monasca mid-cycle meetup
 
 On Tue, 11 Aug 2015, Hochmuth, Roland M wrote:
 
  It sounds like we should connect up soon. I could attend a Ceilometer
  meeting, or you could attend the Monasca meeting which is held Tuesday
  mornings at 9:00 MST.
 
 I'm away this coming Tuesday, but perhaps some of the other Ceilo people 
 could show up? I've got it on my schedule to come the
 week after.
 
 I suspect there's a lot we can do over the long run to avoid duplicating code 
 and effort but that there will be some humps to ride over
 to different pieces (and people!) talking to one another.
 Should be fun. Looking forward to it.
 
 --
 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

[openstack-dev] [Keystone] [Horizon] Pagination support for Identity dashboard entities

2015-08-14 Thread Timur Sufiev

Hello, Keystone folks!

I've just discovered an unfortunate fact that Horizon pagination for
Tenants/Projects list that worked with Keystone v2 doesn't work with
Keysone v3 anymore - its API call simply lacks the 'marker' and 'limit'
parameters [1] that Horizon is relying upon. Meanwhile having looked
through [2] and [3] I'm a bit confused: while Keystone v3 API states it
supports [2] pagination for every kind of entities (by using 'page' and
'per_page' parameters), the related blueprint [3] is not yet approved,
meaning that most likely the API implementation did not make it into
existing Keystone codebase. So I wonder whether there are some plans to
implement pagination for Keystone API calls that list its entities?

P.S. I'm aware of SearchLight project that tries to help Horizon with other
OpenStack APIs (part of its mission), what I'm trying to understand here is
are we going to have some fallback pagination mechanism for Horizon's
Identity in a short-term/mid-term perspective.

[1] http://developer.openstack.org/api-ref-identity-admin-v2.html
[2] http://developer.openstack.org/api-ref-identity-v3.html
[3] https://blueprints.launchpad.net/keystone/+spec/pagination
__
OpenStack Development Mailing 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][Puppet] Keystone V2/V3 service endpoints

2015-08-14 Thread Matthew Mosesohn

Gilles,

I already considered this when looking at another openstackclient issue.
Version 1.0.4 has almost no changes from 1.0.3, which is the official
release for Kilo. Maybe we can get this keystone URL handling fix
backported to the 1.0.X branch of openstackclient?

-Matthew

On Fri, Aug 14, 2015 at 3:47 PM, Gilles Dubreuil gil...@redhat.com wrote:



 On 14/08/15 20:45, Gilles Dubreuil wrote:
 
 
  On 13/08/15 23:29, Rich Megginson wrote:
  On 08/13/2015 12:41 AM, Gilles Dubreuil wrote:
  Hi Matthew,
 
  On 11/08/15 01:14, Rich Megginson wrote:
  On 08/10/2015 07:46 AM, Matthew Mosesohn wrote:
  Sorry to everyone for bringing up this old thread, but it seems we
 may
  need more openstackclient/keystone experts to settle this.
 
  I'm referring to the comments in
  https://review.openstack.org/#/c/207873/
  Specifically comments from Richard Megginson and Gilles Dubreuil
  indicating openstackclient behavior for v3 keystone API.
 
 
  A few items seem to be under dispute:
  1 - Keystone should be able to accept v3 requests at
  http://keystone-server:5000/http://keystone-server:5000/
  I don't think so.  Keystone requires the version suffix /v2.0 or
  /v3.
 
  Yes, if the public endpoint is set without a version then the service
  can deal with either version.
 
  http://paste.openstack.org/raw/412819/
 
  That is not true for the admin endpoint (authentication is already
 done,
  the admin services deals only with tokens), at least for now, Keystone
  devs are working on it.
 
  I thought it worked like this - the openstack cli will infer from the
  arguments if it should do v2 or v3 auth.  In the above case for v3,
  since you specify the username/password, osc knows it has to use
  password auth (as opposed to token auth), and since all of the required
  v3 arguments are provided (v3 api version, domains for user/project), it
  can use v3 password auth.  It knows it has to use the /v3/auth/token
  path to get a token.
 
  Similarly for v2, since it only has username/password, no v3 api or v3
  domain arguments, it knows it has to use v2 password auth.  It knows it
  has to use /v2.0/token to get a token.
 
  With the puppet-keystone code, since it uses TOKEN/URL, osc cannot infer
  if it can use v2 or v3, so it requires the /v2.0 or /v3 suffix, and
  the api version.
 
 
  First of my apologies because I confused admin enpdoint with the admin
  service (or whatever that's dubbed).
 
  As of Keystone v3 (not the API, the latest version of Keystone which
  supports both API v2.0 and V3), the OS_AUTH_URL doesn't need the
  version. That can be effectively any of the endpoints, either the main
  (or public) by default on port 5000 or the admin by default on port
  35357, the third one internal pointing to either of the first two ones.
 
  This is a behavior at Keystone level not at the OSC. I mean OSC will
  just reflect the http-api behavior.
 
  Now the admin service, the one needed for the OS-TOKEN (used for
  bootstrapping) needs a URL (OS_URL) with a version to work.
 
  ATM, the issue with puppet keystone is that endpoints, OS_URL and
  OS_AUTH_URL are walking on each others.
 
 

 My latest update on this one, is that I found out while testing beaker
 which is using OSC 1.0.3 is not handling OS_AUTH_URL properly.

 I had been testing with OSC 1.5.1 and now latest 1.6.1 from Dolerean
 repo, where the version-less URLs are working, but not with OSC 1.0.1:

 --

 # cat openrc
 export OS_AUTH_URL=http://127.0.0.1:5000
 export OS_USERNAME=adminv3
 export OS_PASSWORD=testing
 export OS_PROJECT_NAME=openstackv3
 export OS_USER_DOMAIN_NAME=admin_domain
 export OS_PROJECT_DOMAIN_NAME=admin_domain
 export OS_IDENTITY_API_VERSION=3

 # openstack endpoint list -f csv
 ID,Region,Service Name,Service Type,Enabled,Interface,URL

 87b7db1b23df487bb4ec96de5aa3c271,RegionOne,keystone,identity,True,internal,
 http://127.0.0.1:5000;

 d9b345109d8a4320ac0dd832d2532cce,RegionOne,keystone,identity,True,admin,
 http://127.0.0.1:35357;

 f3a579a64f0241ef9aef3dc983e0fd4a,RegionOne,keystone,identity,True,public,
 http://127.0.0.1:5000;

 --

 # cat openrc_v2
 export OS_AUTH_URL=http://[::1]:5000
 export OS_USERNAME=admin
 export OS_PASSWORD=a_big_secret
 export OS_TENANT_NAME=openstack

 # openstack endpoint list -f csv --long
 ID,Region,Service Name,Service
 Type,PublicURL,AdminURL,InternalURL
 cf8825c44bd041109d5c7438ba9db8f3,RegionOne,keystone,identity,
 http://127.0.0.1:5000,http://127.0.0.1:35357,http://127.0.0.1:5000;




 
  2 - openstackclient should be able to interpret v3 requests and
 append
  v3/ to OS_AUTH_URL=http://keystone-server.5000/ or rewrite the URL
  if it is set as
  OS_AUTH_URL=http://keystone-server.5000/
 http://keystone-server.5000/
  It does, if it can determine from the given authentication arguments
 if
  it can do v3 or v2.0.
 
  It effectively does, again, assuming the path doesn't contain a version
  number (x.x.x.x:5000)
 
  3 - All deployments

Re: [openstack-dev] [Fuel][Puppet] Keystone V2/V3 service endpoints

2015-08-14 Thread Gilles Dubreuil



On 14/08/15 20:45, Gilles Dubreuil wrote:
 
 
 On 13/08/15 23:29, Rich Megginson wrote:
 On 08/13/2015 12:41 AM, Gilles Dubreuil wrote:
 Hi Matthew,

 On 11/08/15 01:14, Rich Megginson wrote:
 On 08/10/2015 07:46 AM, Matthew Mosesohn wrote:
 Sorry to everyone for bringing up this old thread, but it seems we may
 need more openstackclient/keystone experts to settle this.

 I'm referring to the comments in
 https://review.openstack.org/#/c/207873/
 Specifically comments from Richard Megginson and Gilles Dubreuil
 indicating openstackclient behavior for v3 keystone API.


 A few items seem to be under dispute:
 1 - Keystone should be able to accept v3 requests at
 http://keystone-server:5000/http://keystone-server:5000/
 I don't think so.  Keystone requires the version suffix /v2.0 or
 /v3.

 Yes, if the public endpoint is set without a version then the service
 can deal with either version.

 http://paste.openstack.org/raw/412819/

 That is not true for the admin endpoint (authentication is already done,
 the admin services deals only with tokens), at least for now, Keystone
 devs are working on it.

 I thought it worked like this - the openstack cli will infer from the
 arguments if it should do v2 or v3 auth.  In the above case for v3,
 since you specify the username/password, osc knows it has to use
 password auth (as opposed to token auth), and since all of the required
 v3 arguments are provided (v3 api version, domains for user/project), it
 can use v3 password auth.  It knows it has to use the /v3/auth/token
 path to get a token.

 Similarly for v2, since it only has username/password, no v3 api or v3
 domain arguments, it knows it has to use v2 password auth.  It knows it
 has to use /v2.0/token to get a token.

 With the puppet-keystone code, since it uses TOKEN/URL, osc cannot infer
 if it can use v2 or v3, so it requires the /v2.0 or /v3 suffix, and
 the api version.

 
 First of my apologies because I confused admin enpdoint with the admin
 service (or whatever that's dubbed).
 
 As of Keystone v3 (not the API, the latest version of Keystone which
 supports both API v2.0 and V3), the OS_AUTH_URL doesn't need the
 version. That can be effectively any of the endpoints, either the main
 (or public) by default on port 5000 or the admin by default on port
 35357, the third one internal pointing to either of the first two ones.
 
 This is a behavior at Keystone level not at the OSC. I mean OSC will
 just reflect the http-api behavior.
 
 Now the admin service, the one needed for the OS-TOKEN (used for
 bootstrapping) needs a URL (OS_URL) with a version to work.
 
 ATM, the issue with puppet keystone is that endpoints, OS_URL and
 OS_AUTH_URL are walking on each others.
 
 

My latest update on this one, is that I found out while testing beaker
which is using OSC 1.0.3 is not handling OS_AUTH_URL properly.

I had been testing with OSC 1.5.1 and now latest 1.6.1 from Dolerean
repo, where the version-less URLs are working, but not with OSC 1.0.1:

--

# cat openrc
export OS_AUTH_URL=http://127.0.0.1:5000
export OS_USERNAME=adminv3
export OS_PASSWORD=testing
export OS_PROJECT_NAME=openstackv3
export OS_USER_DOMAIN_NAME=admin_domain
export OS_PROJECT_DOMAIN_NAME=admin_domain
export OS_IDENTITY_API_VERSION=3

# openstack endpoint list -f csv
ID,Region,Service Name,Service Type,Enabled,Interface,URL
87b7db1b23df487bb4ec96de5aa3c271,RegionOne,keystone,identity,True,internal,http://127.0.0.1:5000;
d9b345109d8a4320ac0dd832d2532cce,RegionOne,keystone,identity,True,admin,http://127.0.0.1:35357;
f3a579a64f0241ef9aef3dc983e0fd4a,RegionOne,keystone,identity,True,public,http://127.0.0.1:5000;

--

# cat openrc_v2
export OS_AUTH_URL=http://[::1]:5000
export OS_USERNAME=admin
export OS_PASSWORD=a_big_secret
export OS_TENANT_NAME=openstack

# openstack endpoint list -f csv --long
ID,Region,Service Name,Service
Type,PublicURL,AdminURL,InternalURL
cf8825c44bd041109d5c7438ba9db8f3,RegionOne,keystone,identity,http://127.0.0.1:5000,http://127.0.0.1:35357,http://127.0.0.1:5000;





 2 - openstackclient should be able to interpret v3 requests and append
 v3/ to OS_AUTH_URL=http://keystone-server.5000/ or rewrite the URL
 if it is set as
 OS_AUTH_URL=http://keystone-server.5000/http://keystone-server.5000/
 It does, if it can determine from the given authentication arguments if
 it can do v3 or v2.0.

 It effectively does, again, assuming the path doesn't contain a version
 number (x.x.x.x:5000)

 3 - All deployments require /etc/keystone/keystone.conf with a token
 (and not simply use openrc for creating additional endpoints, users,
 etc beyond keystone itself and an admin user)
 No.  What I said about this issue was Most people using
 puppet-keystone, and realizing Keystone resources on nodes that are not
 the Keystone node, put a /etc/keystone/keystone.conf on that node with
 the admin_token in it.

 That doesn't mean the deployment requires /etc/keystone/keystone.conf.
 It should

Re: [openstack-dev] [openstack][magnum][heat]problems for synchronizing stack parameters from heat