date:20150918


>> This honestly hasn’t even been *fully* tested yet, but it SHOULD work.
It did not work. Please read on.
>> User sets ACLs on Secrets and Container in Barbican, to allow the LBaaS user 
>> (right now using whatever user-id we publish in our docs) to read their data.
I did perform the above step to give read access for the container and secrets 
to “admin”, but it did not work.

Root Cause
==
The certmanager in lbaas which connects to barbican uses the keystone session 
gathered from
neutron_lbaas.common.keystone.get_session()
Since the keystone session is marked for tenant “admin” lbaas is not able to 
get the tenant’s container/certificate.

I have filed a bug for the same.

https://bugs.launchpad.net/neutron/+bug/1497410

This is an important fix required since tenants wont be able to use SSL 
Offload. Will try to upload a fix for this next week.


Thanks,
Vijay V.

From: Adam Harwell [mailto:adam.harw...@rackspace.com]
Sent: 16 September 2015 00:32
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [neutron][lbaas] Is SSL offload config possible 
using non "admin" tenant?

There is not really good documentation for this yet…
When I say Neutron-LBaaS tenant, I am maybe using the wrong word — I guess the 
user that is configured as the service-account in neutron.conf.
The user will hit the ACL API themselves to set up the ACLs on their own 
secrets/containers, we won’t do it for them. So, workflow is like:


  *   User creates Secrets in Barbican.
  *   User creates CertificateContainer in Barbican.
  *   User sets ACLs on Secrets and Container in Barbican, to allow the LBaaS 
user (right now using whatever user-id we publish in our docs) to read their 
data.
  *   User creates a LoadBalancer in Neutron-LBaaS.
  *   LBaaS hits Barbican using its standard configured service-account to 
retrieve the Container/Secrets from the user’s Barbican account.
This honestly hasn’t even been *fully* tested yet, but it SHOULD work. The 
question is whether right now in devstack the admin user is allowed to read all 
user secrets just because it is the admin user (which I think might be the 
case), in which case we won’t actually know if ACLs are working as intended 
(but I think we assume that Barbican has tested that feature and we can just 
rely on it working).

--Adam

https://keybase.io/rm_you


From: Vijay Venkatachalam 
>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Monday, September 14, 2015 at 9:12 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Subject: Re: [openstack-dev] [neutron][lbaas] Is SSL offload config possible 
using non "admin" tenant?

Is there a documentation which records step by step?

What is Neutron-LBaaS tenant?

Is it the tenant who is configuring the listener? *OR* is it some tenant which 
is created for lbaas plugin that is the having all secrets for all tenants 
configuring lbaas.

>>You need to set up ACLs on the Barbican side for that container, to make it 
>>readable to the Neutron-LBaaS tenant.
I checked the ACL docs
http://docs.openstack.org/developer/barbican/api/quickstart/acls.html

The ACL API is to allow “users”(not “Tenants”) access to secrets/containers. 
What is the API or CLI that the admin will use to allow access of the tenant’s 
secret+container to Neutron-LBaaS tenant.


From: Adam Harwell [mailto:adam.harw...@rackspace.com]
Sent: 15 September 2015 03:00
To: OpenStack Development Mailing List (not for usage questions) 
>
Subject: Re: [openstack-dev] [neutron][lbaas] Is SSL offload config possible 
using non "admin" tenant?

You need to set up ACLs on the Barbican side for that container, to make it 
readable to the Neutron-LBaaS tenant. For now, the tenant-id should just be 
documented, but we are looking into making an API call that would expose the 
admin tenant-id to the user so they can make an API call to discover it.

Once the user has the neutron-lbaas tenant ID, they use the Barbican ACL system 
to add that ID as a readable user of the container and all of the secrets. Then 
Neutron-LBaaS hits barbican with the credentials of the admin tenant, and is 
granted access to the user’s container.

--Adam

https://keybase.io/rm_you


From: Vijay Venkatachalam 
>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Friday, September 11, 2015 at 2:35 PM
To: "OpenStack Development Mailing List

Re: [openstack-dev] [nova] live migration in Mitaka

2015-09-18 Thread Timofei Durakov

Hi,
some work items:
http://lists.openstack.org/pipermail/openstack-dev/2015-September/073965.html
- ci coverage for live-migration
https://blueprints.launchpad.net/nova/+spec/split-different-live-migration-types
- compute + drivers code cleanup

On Fri, Sep 18, 2015 at 6:47 PM, John Garbutt  wrote:

> On 18 September 2015 at 16:23, Daniel P. Berrange 
> wrote:
> > On Fri, Sep 18, 2015 at 11:53:05AM +, Murray, Paul (HP Cloud) wrote:
> >> Hi All,
> >>
> >> There are various efforts going on around live migration at the moment:
> >> fixing up CI, bug fixes, additions to cover more corner cases, proposals
> >> for new operations
> >>
> >> Generally live migration could do with a little TLC (see: [1]), so I am
> >> going to suggest we give some of that care in the next cycle.
> >>
> >> Please respond to this post if you have an interest in this and what you
> >> would like to see done. Include anything you are already getting on with
> >> so we get a clear picture. If there is enough interest I'll put this
> >> together as a proposal for a work stream. Something along the lines of
> >> "robustify live migration".
> >
> >
> >
> > Testing. Testing. Testing.
>
> +1 for Testing
>
> The "CI for reliable live-migration" thread was covering some of the
> details on the multi-host CI options.
>
> Thanks,
> johnthetubaugy
>
> __
> OpenStack Development Mailing 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] [releases][requirements][keystone]something incompatible with our requirements

2015-09-18 Thread Monty Taylor


On 09/18/2015 03:32 PM, Robert Collins wrote:

I know this is terrible timing with the release and all, but
constraints updates are failing. This is the first evidence - and it
doesn't look like a race to me:
http://logs.openstack.org/57/221157/10/check/gate-tempest-dsvm-full/18eb440/logs/devstacklog.txt.gz#_2015-09-18_13_51_46_902

https://review.openstack.org/#/c/221157/ is the updated review to
bring it all together. I'm worried that the incompatibility is going
to impact distributors and/or may even be from one of our own recent
library releases.


It's related to an interaction between os-client-config and 
python-openstackclient. A fix just went into os-client-config and was 
released and we're getting the associated patch into 
python-openstackclient now.


Sorry for the disturbance. It's not a requirements issue.


__
OpenStack Development Mailing 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] [Novadocker] Resizing docker containers

2015-09-18 Thread aman mangal

Hi,

I was wondering if it is possible to add support for resizing docker
containers without disrupting their execution. Is it even possible, without
any direct support from openstack and with modifications to only
novadocker? Any insights?

Aman
__
OpenStack Development Mailing 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] [Congress] Congress Usecases VM

2015-09-18 Thread Tim Hinrichs

It's great to have this available!  I think it'll help people understand
what's going on MUCH more quickly.

Some thoughts.
- The image is 3GB, which took me 30 minutes to download.  Are all VMs this
big?  I think we should finish this as a VM but then look into doing it
with containers to make it EVEN easier for people to get started.

- It gave me an error about a missing shared directory when I started up.

- I expected devstack to be running when I launched the VM.  devstack
startup time is substantial, and if there's a problem, it's good to assume
the user won't know how to fix it.  Is it possible to have devstack up and
running when we start the VM?  That said, it started up fine for me.

- It'd be good to have a README to explain how to use the use-case
structure. It wasn't obvious to me.

- The top-level dir of the Congress_Usecases folder has a Congress_Usecases
folder within it.  I assume the inner one shouldn't be there?

- When I ran the 10_install_policy.sh, it gave me a bunch of authorization
problems.

But otherwise I think the setup looks reasonable.  Will there be an undo
script so that we can run the use cases one after another without worrying
about interactions?

Tim


On Fri, Sep 18, 2015 at 11:03 AM Shiv Haris  wrote:

> Hi Congress folks,
>
>
>
> BTW the login/password for the VM is vagrant/vagrant
>
>
>
> -Shiv
>
>
>
>
>
> *From:* Shiv Haris [mailto:sha...@brocade.com]
> *Sent:* Thursday, September 17, 2015 5:03 PM
> *To:* openstack-dev@lists.openstack.org
> *Subject:* [openstack-dev] [Congress] Congress Usecases VM
>
>
>
> Hi All,
>
>
>
> I have put my VM (virtualbox) at:
>
>
>
> http://paloaltan.net/Congress/Congress_Usecases_SEPT_17_2015.ova
>
>
>
> I usually run this on a macbook air – but it should work on other
> platfroms as well. I chose virtualbox since it is free.
>
>
>
> Please send me your usecases – I can incorporate in the VM and send you an
> updated image. Please take a look at the structure I have in place for the
> first usecase; would prefer it be the same for other usecases. (However I
> am still open to suggestions for changes)
>
>
>
> Thanks,
>
>
>
> -Shiv
>
>
> __
> OpenStack Development Mailing 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] [magnum] Associating patches with bugs/bps (Please don't hurt me)

2015-09-18 Thread Adrian Otto

Although I do think this is a good suggestion, let's resist the temptation to 
overthink this. No matter what guidance is offered, each exception to a policy 
needs to be judged individually. I suggest that when we encounter situations 
like this, that we allow the submitter to simply label the change as trivial 
and we trust that commit to go untracked unless there is a clear consensus to 
the contrary. Really the only downside to not tracking trivial changes is that 
our bug fix statistics are slightly lower. That's okay with me, as long as we 
are actually tracking the meaningful contributions.

--
Adrian

On Sep 18, 2015, at 4:02 PM, Hongbin Lu 
> wrote:

For the guidance, I saw the judgement is a bit subjective. It could happen that 
a contributor think his/her patch is trivial (or it is not fixing a function 
defect), but a reviewer think the opposite. For example, I find it hard to 
judge when I reviewed the following patches:

https://review.openstack.org/#/c/224183/
https://review.openstack.org/#/c/224198/
https://review.openstack.org/#/c/224184/

It could be helpful if the guide can provide some examples of what is a trivial 
patch, and what is not. OpenStack uses this approach to define what is a 
good/bad commit message, which I find it quite helpful.

https://wiki.openstack.org/wiki/GitCommitMessages#Examples_of_bad_practice
https://wiki.openstack.org/wiki/GitCommitMessages#Examples_of_good_practice

Best regards,
Hongbin

From: Adrian Otto [mailto:adrian.o...@rackspace.com]
Sent: September-17-15 5:09 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [magnum] Associating patches with bugs/bps (Please 
don't hurt me)

For posterity, I have recorded this guidance in our Contributing Wiki:

See the NOTE section under:

https://wiki.openstack.org/wiki/Magnum/Contributing#Identify_bugs

Excerpt:

"NOTE: If you are fixing something trivial, that is not actually a functional 
defect in the software, you can do that without filing a bug ticket, if you 
don't want it to be tracked when we tally this work between releases. If you do 
this, just mention it in the commit message that it's a trivial change that 
does not require a bug ticket. You can reference this guideline if it comes up 
in discussion during the review process. Functional defects should be tracked 
in bug tickets. New features should be tracked in blueprints. Trivial features 
may be tracked using a bug ticket marked as 'Wishlist' importance."

I hope that helps.

Adrian

On Sep 17, 2015, at 2:01 PM, Adrian Otto 
> wrote:

Let’s apply sensible reason. If it’s a new feature or a bug, it should be 
tracked against an artifact like a bug ticket or a blueprint. If it’s truly 
trivia, we don’t care. I can tell you that some of the worst bugs I have ever 
seen in my career had fixes that were about 4 bytes long. That did not make 
them any less serious.

If you are fixing an actual legitimate bug that has a three character fix, and 
you don’t want it to be tracked as the reviewer, then you can say so in the 
commit message. We can act accordingly going forward.

Adrian

On Sep 17, 2015, at 1:53 PM, Assaf Muller 
> wrote:

On Thu, Sep 17, 2015 at 4:09 PM, Jeff Peeler 
> wrote:

On Thu, Sep 17, 2015 at 3:28 PM, Fox, Kevin M 
> wrote:
I agree. Lots of projects have this issue. I submitted a bug fix once that 
literally was 3 characters long, and it took:
A short commit message, a long commit message, and a full bug report being 
filed and cross linked. The amount of time writing it up was orders of 
magnitude longer then the actual fix.

Seems a bit much...

Looking at this review, I'd go a step farther and argue that code cleanups like 
this one should be really really easy to get through. No one likes to do them, 
so we should be encouraging folks that actually do it. Not pile up roadblocks.

It is indeed frustrating. I've had a few similar reviews (in other projects - 
hopefully it's okay I comment here) as well. Honestly, I think if a given team 
is willing to draw the line as for what is permissible to commit without bug 
creation, then they should be permitted that freedom.

However, that said, I'm sure somebody is going to point out that come release 
time having the list of bugs fixed in a given release is handy, spelling errors 
included.

We've had the same debate in Neutron and we relaxed the rules. We don't require 
bugs for trivial changes. In fact, my argument has always been: Come release
time, when we say that the Neutron community fixed so and so bugs, we would be 
lying if we were to include fixing spelling issues in comments. That's not a 
bug.

__
OpenStack

Re: [openstack-dev] [cinder] LVM snapshot performance issue -- why isn't thin provisioning the default?

2015-09-18 Thread Chris Friesen


On 09/18/2015 12:11 PM, John Griffith wrote:



On Fri, Sep 18, 2015 at 11:31 AM, Chris Friesen > wrote:

On 09/18/2015 11:01 AM, John Griffith wrote:



On Fri, Sep 18, 2015 at 9:06 AM, Chris Friesen

>> wrote:

 On 09/18/2015 06:57 AM, Eric Harney wrote:

 On 09/17/2015 06:06 PM, John Griffith wrote:


 Having the "global conf" settings intermixed with the
backend sections
 caused a number of issues when we first started working on
this.  That's
 part of why we require the "self.configuration" usage all
over in the
 drivers.  Each driver instantiation is it's own independent
entity.


 Yes, each driver instantiation is independent, but that would
still be
 the case if these settings inherited values set in [DEFAULT]
when they
 aren't set in the backend section.


 Agreed.  If I explicitly set something in the [DEFAULT] section,
that should
 carry through and apply to all the backends unless overridden in 
the
 backend-specific section.



Bottom line "yes", ideally in the case of drivers we would check
global/default
setting, and then override it if something was provided in the driver
specific
setting, or if the driver itself set a different default.  That seems
like the
right way to be doing it anyway.  I've looked at that a bit this
morning, the
issue is that currently we don't even pass any of those higher level 
conf
settings in to the drivers init methods anywhere.  Need to figure out 
how to
change that, then it should be a relatively simple fix.


Actually, I think it should be slightly different.  If I set a variable in
the global/default section of the config file, then that should override any
defaults in the code for a driver.

Hmm... well, on the bright side that might be easier to implement at least :). I
guess I don't agree on the meaning of "DEFAULT", to me a "DEFAULT" section
means, "these are the defaults if you don't specify something else", no?  Your
proposal seems really counter-intuitive to me.


That's what I proposed.

If you specify anything in the driver-specific portion of the config file, that 
takes priority over everything.  If you specify something in the DEFAULT portion 
of the config file, then that takes priority over the in-code defaults.  If you 
specify a default value in the driver-specific code, that takes priority over 
any defaults specified in the global/generic code.


Chris


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

Re: [openstack-dev] [Glance] glance core rotation part 1

2015-09-18 Thread Nikhil Komawar

This is done.

On 9/14/15 7:45 AM, Fei Long Wang wrote:
> +1
>
> Yep, it would be nice if Zhi Yan can promote OpenStack in Alibaba :)
>
> On 14/09/15 22:59, Mikhail Fedosin wrote:
>> +1.
>> I hope that Zhi Yan joined Alibaba to make it use Openstack in the
>> future :)
>>
>> On Mon, Sep 14, 2015 at 11:23 AM, Kuvaja, Erno > > wrote:
>>
>> +1
>>
>>  
>>
>> *From:*Alex Meade [mailto:mr.alex.me...@gmail.com
>> ]
>> *Sent:* Friday, September 11, 2015 7:37 PM
>> *To:* OpenStack Development Mailing List (not for usage questions)
>> *Subject:* Re: [openstack-dev] [Glance] glance core rotation part 1
>>
>>  
>>
>> +1
>>
>>  
>>
>> On Fri, Sep 11, 2015 at 2:33 PM, Ian Cordasco
>> >
>> wrote:
>>
>>  
>>
>> -Original Message-
>> From: Nikhil Komawar > >
>> Reply: OpenStack Development Mailing List (not for usage
>> questions) > >
>> Date: September 11, 2015 at 09:30:23
>> To: openstack-dev@lists.openstack.org
>> 
>> > >
>> Subject:  [openstack-dev] [Glance] glance core rotation part 1
>>
>> > Hi,
>> >
>> > I would like to propose the following removals from
>> glance-core based on
>> > the simple criterion of inactivity/limited activity for a
>> long period (2
>> > cycles or more) of time:
>> >
>> > Alex Meade
>> > Arnaud Legendre
>> > Mark Washenberger
>> > Iccha Sethi
>>
>> I think these are overdue
>>
>> > Zhi Yan Liu (Limited activity in Kilo and absent in Liberty)
>>
>> Sad to see Zhi Yan Liu's activity drop off.
>>
>> > Please vote +1 or -1 and we will decide by Monday EOD PT.
>>
>> +1
>>
>> --
>> Ian Cordasco
>>
>> 
>> __
>> OpenStack Development Mailing 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
>
> -- 
> Cheers & Best regards,
> Fei Long Wang (王飞龙)
> --
> Senior Cloud Software Engineer
> Tel: +64-48032246
> Email: flw...@catalyst.net.nz
> Catalyst IT Limited
> Level 6, Catalyst House, 150 Willis Street, Wellington
> -- 
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-- 

Thanks,
Nikhil

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

Re: [openstack-dev] [cinder] LVM snapshot performance issue -- why isn't thin provisioning the default?

On Fri, Sep 18, 2015 at 12:32 PM, Chris Friesen  wrote:

> On 09/18/2015 12:11 PM, John Griffith wrote:
>
>>
>>
>> On Fri, Sep 18, 2015 at 11:31 AM, Chris Friesen <
>> chris.frie...@windriver.com
>> > wrote:
>>
>> On 09/18/2015 11:01 AM, John Griffith wrote:
>>
>>
>>
>> On Fri, Sep 18, 2015 at 9:06 AM, Chris Friesen
>> 
>> >
>> >> wrote:
>>
>>  On 09/18/2015 06:57 AM, Eric Harney wrote:
>>
>>  On 09/17/2015 06:06 PM, John Griffith wrote:
>>
>>
>>  Having the "global conf" settings intermixed with the
>> backend sections
>>  caused a number of issues when we first started
>> working on
>> this.  That's
>>  part of why we require the "self.configuration"
>> usage all
>> over in the
>>  drivers.  Each driver instantiation is it's own
>> independent
>> entity.
>>
>>
>>  Yes, each driver instantiation is independent, but that
>> would
>> still be
>>  the case if these settings inherited values set in
>> [DEFAULT]
>> when they
>>  aren't set in the backend section.
>>
>>
>>  Agreed.  If I explicitly set something in the [DEFAULT]
>> section,
>> that should
>>  carry through and apply to all the backends unless
>> overridden in the
>>  backend-specific section.
>>
>>
>>
>> Bottom line "yes", ideally in the case of drivers we would check
>> global/default
>> setting, and then override it if something was provided in the
>> driver
>> specific
>> setting, or if the driver itself set a different default.  That
>> seems
>> like the
>> right way to be doing it anyway.  I've looked at that a bit this
>> morning, the
>> issue is that currently we don't even pass any of those higher
>> level conf
>> settings in to the drivers init methods anywhere.  Need to figure
>> out how to
>> change that, then it should be a relatively simple fix.
>>
>>
>> Actually, I think it should be slightly different.  If I set a
>> variable in
>> the global/default section of the config file, then that should
>> override any
>> defaults in the code for a driver.
>>
>> Hmm... well, on the bright side that might be easier to implement at
>> least :). I
>> guess I don't agree on the meaning of "DEFAULT", to me a "DEFAULT" section
>> means, "these are the defaults if you don't specify something else", no?
>> Your
>> proposal seems really counter-intuitive to me.
>>
>
> That's what I proposed.
>
> If you specify anything in the driver-specific portion of the config file,
> that takes priority over everything.  If you specify something in the
> DEFAULT portion of the config file, then that takes priority over the
> in-code defaults.  If you specify a default value in the driver-specific
> code, that takes priority over any defaults specified in the global/generic
> code.
>
>
> Chris
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
Ahh... ok, yeah; sorry, I interpreted that differently when I read it.
Thanks for clarifying.

So the good news is we most definitely agree there, and that I've got
something that gets us at least part way there.  Now, to just figure out
how to determine if the value in the driver section was set explicitly or
is just parsing out the default value in the opt declaration.

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

Re: [openstack-dev] [fuel] PTL & Component Leads elections

2015-09-18 Thread Dmitry Borodaenko

Dims,

Thanks for the reminder!

I've summarized the uncontroversial parts of that thread in a policy
proposal as per you suggestion [0], please review and comment. I've
renamed SMEs to maintainers since Mike has agreed with that part, and I
omitted code review SLAs from the policy since that's the part that has
generated the most discussion.

[0] https://review.openstack.org/225376

I don't think we should postpone the election: the PTL election follows
the same rules as OpenStack so we don't need a Fuel-specific policy for
that, and the component leads election doesn't start until October 9,
which gives us 3 weeks to confirm consensus on that aspect of the
policy.

-- 
Dmitry Borodaenko


On Fri, Sep 18, 2015 at 07:30:39AM -0400, Davanum Srinivas wrote:
> Sergey,
> 
> Please see [1]. Did we codify some of these roles and responsibilities as a
> community in a spec? There was also a request to use terminology like say
> MAINTAINERS in that email as well.
> 
> Are we pulling the trigger a bit early for an actual election?
> 
> Thanks,
> Dims
> 
> [1] http://markmail.org/message/2ls5obgac6tvcfss
> 
> On Fri, Sep 18, 2015 at 6:56 AM, Vladimir Kuklin 
> wrote:
> 
> > Sergey, Fuelers
> >
> > This is awesome news!
> >
> > By the way, I have a question on who is eligible to vote and to nominate
> > him/her-self for both PTL and Component Leads. Could you elaborate on that?
> >
> > And there is no such entity as Component Lead in OpenStack - so we are
> > actually creating one. What are the new rights and responsibilities of CL?
> >
> > On Fri, Sep 18, 2015 at 5:39 AM, Sergey Lukjanov 
> > wrote:
> >
> >> Hi folks,
> >>
> >> I'd like to announce that we're running the PTL and Component Leads
> >> elections. Detailed information available on wiki. [0]
> >>
> >> Project Team Lead: Manages day-to-day operations, drives the project
> >> team goals, resolves technical disputes within the project team. [1]
> >>
> >> Component Lead: Defines architecture of a module or component in Fuel,
> >> reviews design specs, merges majority of commits and resolves conflicts
> >> between Maintainers or contributors in the area of responsibility. [2]
> >>
> >> Fuel has two large sub-teams, with roughly comparable codebases, that
> >> need dedicated component leads: fuel-library and fuel-python. [2]
> >>
> >> Nominees propose their candidacy by sending an email to the
> >> openstack-dev@lists.openstack.org mailing-list, which the subject:
> >> "[fuel] PTL candidacy" or "[fuel]  lead candidacy"
> >> (for example, "[fuel] fuel-library lead candidacy").
> >>
> >> Time line:
> >>
> >> PTL elections
> >> * September 18 - September 28, 21:59 UTC: Open candidacy for PTL position
> >> * September 29 - October 8: PTL elections
> >>
> >> Component leads elections (fuel-library and fuel-python)
> >> * October 9 - October 15: Open candidacy for Component leads positions
> >> * October 16 - October 22: Component leads elections
> >>
> >> [0] https://wiki.openstack.org/wiki/Fuel/Elections_Fall_2015
> >> [1] https://wiki.openstack.org/wiki/Governance
> >> [2]
> >> http://lists.openstack.org/pipermail/openstack-dev/2015-August/072406.html
> >> [3] https://lwn.net/Articles/648610/
> >>
> >> --
> >> Sincerely yours,
> >> Sergey Lukjanov
> >> Sahara Technical Lead
> >> (OpenStack Data Processing)
> >> Principal Software Engineer
> >> Mirantis Inc.
> >>
> >> __
> >> OpenStack Development Mailing List (not for usage questions)
> >> Unsubscribe:
> >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >>
> >
> >
> > --
> > Yours Faithfully,
> > Vladimir Kuklin,
> > Fuel Library Tech Lead,
> > Mirantis, Inc.
> > +7 (495) 640-49-04
> > +7 (926) 702-39-68
> > Skype kuklinvv
> > 35bk3, Vorontsovskaya Str.
> > Moscow, Russia,
> > www.mirantis.com 
> > www.mirantis.ru
> > vkuk...@mirantis.com
> >
> > __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> 
> 
> -- 
> Davanum Srinivas :: https://twitter.com/dims

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


__
OpenStack Development Mailing 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] Design Summit Topics for Nova

On 17 September 2015 at 15:23, Tony Breeds  wrote:
> On Wed, Sep 16, 2015 at 11:40:28AM -0700, melanie witt wrote:
>
>> Today I was informed that google forms are blocked in China [1], so I wanted
>> to mention it here so we can consider an alternate way to collect submissions
>> from those who might not be able to access the form.
>
> I'll act as an email to google forms proxy if needed. People that willbe at 
> the
> summit can fill in the temp;ate below.
> (stolen from the google forms)
>
> ---
> Topic Title:
> Topic Description:
> Submitter IRC handle:
> Session leader IRC handle
>  Please note the session leader must be there on the day at the summit. Please
>  just leave this blank if you feel unable to find someone to lead the session.
>
> Link to nova-spec review:
>  Features you want to discuss need to have at least a WIP spec before being
>  considered for the design summit track. Ideally we will merge the spec before
>  the design summit, so a session would not be required.
>
> Link to pre-reading:
>  Before the submission is on the final list, we need to have some background
>  reading for more complex topics, or topics that have had lots of previous
>  discussion, so its easier for everyone to get involved. This could be a wiki
>  page, an etherpad, an ML post, or devref.
> ---

Tony, thanks for taking on the paper work there.

Sorry for the two tier system. Its not intentional.
Let me know if there a China friendly alternative folks are able to
setup for us.

I have started an etherpad as a fallback catch-all system, mostly just
including the above suggestions:
https://etherpad.openstack.org/p/mitaka-nova-summit-suggestions

Thanks,
John

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

Re: [openstack-dev] [mistral][requirements] lockfile not in global requirements

2015-09-18 Thread Lingxian Kong

Hi, Andreas,

Sorry for the late response from Mistral. Anyway, I'm coming :-)

I'll take a look and solve it if needed, thanks for letting us know that.

On Fri, Sep 18, 2015 at 2:22 AM, Andreas Jaeger  wrote:

> The syncing of requirements fails from the requirements repository to
> mistral-extra with
> 'lockfile' is not in global-requirements.txt
>
> Mistral team, could you either propose to add lockfile to the global
> requirements file - or remove it from your project, please?
>
> for details see:
>
> https://jenkins.openstack.org/job/propose-requirements-updates/363/consoleFull
>
> Andreas
> --
>  Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi
>   SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
>GF: Felix Imendörffer, Jane Smithard, Graham Norton,
>HRB 21284 (AG Nürnberg)
> GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



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

Re: [openstack-dev] [all][elections] PTL nomination period is now over

On 18/09/15 09:17 +0100, Steven Hardy wrote:

On Fri, Sep 18, 2015 at 08:56:06AM +0200, Flavio Percoco wrote:

On 17/09/15 16:00 -0400, Doug Hellmann wrote:
>Excerpts from Morgan Fainberg's message of 2015-09-17 12:51:33 -0700:
>
>>I think this is all superfluous however and we should simply encourage
>>people to not wait until the last minute. Waiting to see who is
>>running/what the field looks like isn't as important as standing up and
>>saying you're interested in running.
>
>+1

Just want to +1 this. I'm going to be, probably, extrem here and
sugest that we should just shrink the candidacy period to 1 (max 2)
days.

-1 - the "problem" here (if you want to call it that) is that some folks
evidently found a week nomination period insufficient, for $whatever reason.

The obvious solution to that is to simply adopt the same branch model for
the openstack/election repo as all other projects - create a branch (or
directory) per release in openstack/election, and allow candidates to
propose their candidacy at any time during the preceding release cycle.

Then, if you clearly state the deadline ahead of time, you simply publish
results and/or start elections on that date, with whatever is in the repo
on that date and folks have the whole cycle (say from summit to RC1 time)
to consider running and propose their candidacy whenever they want.

This is the same thing I said in my previous email (you cut that off
of your reply) with the only difference that you're suggesting not
having a "candidacy day" but rather just have a "start election" day.

I'd argue saying that a deadline for candidacies is useful to have and
it brings more formality to the process. It helps, in the case of
using `openstack/elections` to have a deadline for cutting the branch
or freezing reviews, etc.

Setting up the election takes some time, which means there has to be a
date where the election officers stop considering new candidacies.

I also think this would encourage discussion within the project teams about
who wants to run for PTL, with transparency about those interested/willing
ahead of time.

+1

Perhaps you might WIP all submissions until a few days before the deadline,
such that if communities decide via mutual agreement one candidate should
take their turn as PTL submissions may be abandoned without any election.

I guess this may work in some cases but this defeats the whole purpose
of having an election and being able to vote, in private, which many
people value.

IMHO rotation of PTL responsibilities is healthy, as is discussion
and openness in the community - being PTL isn't some sort of prize, it's a
time-consuming burden, which is mostly about coordination and release
management, not really about "leadership" at all (although it is about
community building and leading by example..)

I guess what I mean is I'm not really sure what the timeboxed nomination
period aims to achieve, particularly if you shrink it to one or two days -
that makes it extremely easy for folks to miss due to illness/travel or
$whatever, and implies some kind of race - which is the opposite, IMHO of
the dynamic we should be encouraging.

In my previous email I mentioned that folks can simply send the
candidacy in advance or have someone else to propose it. Seriously,
it's not about having a single day for sending the candidacy, it's
about having a clear deadline where no more candidacies are
considered. If a candidacy is sent 4 months in advance, I guess that's
fine. I don't care.

Cheers,
Flavio

--
@flaper87
Flavio Percoco

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

[openstack-dev] Hardware requirements for OpenStack

2015-09-18 Thread Haider Ali

Hello

I am new to OpenStack and following
http://docs.openstack.org/juno/install-guide/install/apt/content/ch_basic_environment.html
guide to install OpenStack on my local PC. My question is do i need
separate machines Controller, Network and Compute node ( connected via LAN
) or i can install all these 3 nodes on a single PC as well.

Thanks

-- 
Haider Ali
National University of Computer and Emerging Sciences Lahore
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][elections] PTL nomination period is now over


On 17/09/15 16:00 -0400, Doug Hellmann wrote:

Excerpts from Morgan Fainberg's message of 2015-09-17 12:51:33 -0700:


I think this is all superfluous however and we should simply encourage
people to not wait until the last minute. Waiting to see who is
running/what the field looks like isn't as important as standing up and
saying you're interested in running.


+1


Just want to +1 this. I'm going to be, probably, extrem here and
sugest that we should just shrink the candidacy period to 1 (max 2)
days.

The election period is announced way earlier in the cycle. Candidates
have 6 month to think about what should come next for their project.
Instead of having a full week to send candidacies, I'd just send a
reminder that the candidacy day is coming and everyone should get
their candidacies done.

If, for some reason, someone can't send the candidacy the day when
candidacies should be sent, then it'd be possible to designate someone
to submit it for review on his behalf. Even better, since now it's all
done through gerrit, that person can just send it in advance.

Flavio

--
@flaper87
Flavio Percoco


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

Re: [openstack-dev] [all] [ptl] Troubleshooting cross-project communications

On 18 September 2015 at 00:50, Mike Perez  wrote:
> On 16:16 Sep 16, Thierry Carrez wrote:
>> Anne Gentle wrote:
>> > [...]
>> > What are some of the problems with each layer?
>> >
>> > 1. weekly meeting: time zones, global reach, size of cross-project
>> > concerns due to multiple projects being affected, another meeting for
>> > PTLs to attend and pay attention to
>>
>> A lot of PTLs (or liaisons/lieutenants) skip the meeting, or will only
>> attend when they have something to ask. Their time is precious and most
>> of the time the meeting is not relevant for them, so why bother ? You
>> have a few usual suspects attending all of them, but those people are
>> cross-project-aware already so those are not the people that would
>> benefit the most from the meeting.
>>
>> This partial attendance makes the meeting completely useless as a way to
>> disseminate information. It makes the meeting mostly useless as a way to
>> get general approval on cross-project specs.
>>
>> The meeting still is very useful IMHO to have more direct discussions on
>> hot topics. So a ML discussion is flagged for direct discussion on IRC
>> and we have a time slot already booked for that.
>
> Content for the cross project meeting are usually:
>
> * Not ready for decisions.
> * Lack solutions.
>
> A proposal in steps of how cross project ideas start, to something ready for
> the cross project IRC meeting, then the TC:
>
> 1) An idea starts from either or both:
>a) Mailing list discussion.
>b) A patch to a single project (until it's flagged that this patch could be
>   benefical to other projects)
> 2) OpenStack Spec is proposed - discussions happen in gerrit from here on out.
>Not on the mailing list. Keep encouraging discussions back to gerrit to 
> keep
>everything in one place in order to avoid confusion with having to fish
>for some random discussion elsewhere.
> 3) Once enough consensus happens an agenda item is posted cross project IRC
>meeting.
> 4) Final discussions happen in the meeting. If consensus is still met by
>interested parties who attend, it moves to TC.  If there is a lack of
>consensus it goes back to gerrit and repeat.

+1

That totally seems worth a try.

Its extra process, but that should help drive the right conversations,
in more efficient way.

Thanks,
johnthetubaguy

> With this process, we should have less meetings. Less meetings is:
>
> * Awesome
> * Makes this meeting more meaningful when it happens because decisions are
>   potentially going to be agreed and passed to the TC!
>
> If a cross project spec is not getting attention, don't post it to the list 
> for
> attention. We get enough email and it'll probably be lost. Instead, let the
> product working group recognize this and reach out to the projects that this
> spec would benefit, to bring meaningful attention to the spec.
>
> For vertical alignment, interaction like IRC is not necessary. A very brief,
> bullet point of collected information from projects that have anything
> interesting is given in a weekly digest email to the list If anyone has
> questions or wants more information, they can use their own time to ask that
> project team.
>
> Potentially, if we kept everything to the spec on gerrit, and had the product
> working group bringing needed attention to specs, we could eliminate the cross
> project meeting.

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

Re: [openstack-dev] [all][elections] PTL nomination period is now over

2015-09-18 Thread Sylvain Bauza




Le 17/09/2015 23:09, Nikhil Komawar a écrit :


On 9/17/15 3:51 PM, Morgan Fainberg wrote:


On Thu, Sep 17, 2015 at 12:00 PM, Kevin Benton > wrote:

 It guarantees that if you hit the date deadline local time, that
 you won't miss the deadline. It doesn't matter if there are extra
 hours afterwards. The idea is that it gets rid of the need to do
 time zone conversions.

 If we are trying to do some weird optimization where everyone
 wants to submit in the last 60 seconds, then sure AOE isn't great
 for that because you still have to convert. It doesn't seem to me
 like that's what we are trying to do though.

Alternatively you give a UTC time (which all of our meetings are in
anyway) and set the deadline. Maybe we should be setting the deadline
to the western-most timezone (UTC-11/-12?) 23:59 as the deadline. This
would simply do what you're stating without having to explain AOE more
concretely than "submit by 23:59 your tz day X".

I think this is all superfluous however and we should simply encourage
people to not wait until the last minute. Waiting to see who is
running/what the field looks like isn't as important as standing up
and saying you're interested in running.


I like that you have used the word encourage however, will have to
disagree here. Life in general can't permit that to everyone -- there
can be any important things pop up at unexpected time, someone on
vacation and getting late to come back etc. And on top of that people
can get caught up particularly at this week.  The time-line for
proposals is a good idea seems a good idea in general.


That's exactly why the schedule is always proposed in the beginning of 
the cycle [1] so that any people interested in becoming PTLs would need 
to make sure that they could provide their candidacy (there are 7 days 
for proposing).


Also, the policy accepts to have a candidacy proposed by someone else, 
just by having the candidate +1'ing the change even after the deadline, 
so anyone in vacation can just proxy his candidacy by someone else.


Last but not the least, I assume that people wanting to be PTLs 
understand that they are here for helping the community so they have 
also to understand how the community works and what its rules are.


-Sylvain

[1] 
https://wiki.openstack.org/w/index.php?title=Liberty_Release_Schedule=78501



You shouldn't worry about hurting anyone's feelings by running and
more importantly most PTLs will be happy to have someone else shoulder
some of the weight; by tossing your name into the ring it signals
you're willing to help out in this regard. I know that as a PTL (an
outgoing one at that) having this clear signal would raise an
individual towards the top of the list for asking if they want the
responsibility delegated to them as it was indicated they already
wanted to be part of leadership for the project.

Just a $0.02 on the timing concerns.

--Morgan
  




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

  My 2 pennies worth.




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

Re: [openstack-dev] [ironic] [inspector] Liberty soft freeze

2015-09-18 Thread Dmitry Tantsur

Note for inspector folks: this applies to us as well. Lets land whatever 
we have planned for 2.2.0 and fix any issues arising.


Please see milestone page for list of things that we still need to 
review/fix:

https://launchpad.net/ironic-inspector/+milestone/2.2.0

On 09/18/2015 03:50 AM, Jim Rollenhagen wrote:

Hi folks,

It's time for our soft freeze for Liberty, as planned. Core reviewers
should do their best to refrain from landing risky code. We'd like to
ship 4.2.0 as the candidate for stable/liberty next Thursday, September
24.

Here's the things we still want to complete in 4.2.0:
https://launchpad.net/ironic/+milestone/4.2.0

Note that zapping is no longer there; sadly, after lots of writing and
reviewing code, we want to rethink how we implement this. We've talked
about being able to go from MANAGEABLE->CLEANING->MANAGEABLE with a list
of clean steps. Same idea, but without the word zapping, the new DB
fields, etc. At any rate, it's been bumped to Mitaka to give us time to
figure it out.

This may also mean in-band RAID configuration may not land; the
interface in general did land, and drivers may do out-of-band
configuration. We assumed that in-band RAID would be done through
zapping. However, if folks can agree on how to do it during automated
cleaning, I'd be happy to get that in Liberty if the code is not too
risky. If it is risky, we'll need to punt it to Mitaka as well.

I'd like to see the rest of the work on the milestone completed during
Liberty, and I hope everyone can jump in and help us to do that.

Thanks in advance!

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




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

Re: [openstack-dev] [all][elections] PTL nomination period is now over

On 17/09/15 15:47 -0400, Doug Hellmann wrote:

Excerpts from Thierry Carrez's message of 2015-09-17 18:10:26 +0200:

Monty Taylor wrote:
> I agree- and this is a great example of places where human judgement is
> better than rules.
>
> For instance - one of the projects had a nominee but it missed the
> deadline, so that's probably an easy on.
>
> For one of the projects it had been looking dead for a while, so this is
> the final nail in the coffin from my POV
>
> For the other three - I know they're still active projects with people
> interested in them, so sorting them out will be fun!

Looks like in 4 cases (Magnum, Barbican, Murano, Security) there is
actually a candidate, they just missed the deadline. So that should be
an easy discussion at the next TC meeting.

For the last one, it is not an accident. I think it is indeed the final
nail on the coffin.

Yes, I was planning to wait until after the summit to propose that we
drop MagnetoDB from the official list of projects due to inactivity. We
can deal with it sooner, obviously.

+1

--
@flaper87
Flavio Percoco

pgpFOg5bL1csB.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] [cinder] LVM snapshot performance issue -- why isn't thin provisioning the default?

On Fri, Sep 18, 2015 at 12:52 PM, Eric Harney  wrote:

> On 09/18/2015 01:01 PM, John Griffith wrote:
> > On Fri, Sep 18, 2015 at 9:06 AM, Chris Friesen <
> chris.frie...@windriver.com>
> > wrote:
> >
> >> On 09/18/2015 06:57 AM, Eric Harney wrote:
> >>
> >>> On 09/17/2015 06:06 PM, John Griffith wrote:
> >>>
> >>
> >> Having the "global conf" settings intermixed with the backend sections
>  caused a number of issues when we first started working on this.
> That's
>  part of why we require the "self.configuration" usage all over in the
>  drivers.  Each driver instantiation is it's own independent entity.
> 
> 
> >>> Yes, each driver instantiation is independent, but that would still be
> >>> the case if these settings inherited values set in [DEFAULT] when they
> >>> aren't set in the backend section.
> >>>
> >>
> >> Agreed.  If I explicitly set something in the [DEFAULT] section, that
> >> should carry through and apply to all the backends unless overridden in
> the
> >> backend-specific section.
> >>
> >> Chris
> >>
> >>
> > Meh I don't know about the "have to modify the code", the config file
> works
> > you just need to add that line to your driver section and configure the
> > backend correctly.
> >
>
> My point is that there doesn't seem to be a justification for "you just
> need to add that line to your driver section", which seems to counter
> what most people's expectation would be.
>
There certainly is, I don't want to force the same options against all
backends.  Perfect example is the issues with some distros in the past that
DID use global settings and stomp over any driver; which in turn broke
those that weren't compatible with that conf setting even though in the
driver section they overrode it.


>
> People can and do fail to do that, because they assume that [DEFAULT]
> settings are treated as defaults.
>

Bad assumption, we should probably document this until we fix it (making a
very large assumption that we'll ever agree on how to fix it).

>
> To help people who make that assumption, yes, you have to modify the
> code, because the code supplies a default value that you cannot supply
> in the same way via config files.
>

Or you could just fill out the config file properly:
[lvm-1]
iscsi_helper = lioadm

I didn't have to modify any code.



>
> > Regardless, I see your point (but I still certainly don't agree that it's
> > "blatantly wrong").
> >
>
> You can substitute "very confusing" for "blatantly wrong" but I think
> those are about the same thing when talking about usability issues with
> how to configure a service.
>

Fair enough.  Call it whatever you like.


>
> Look at options like:
>  - strict_ssh_host_key_policy
>  - sio_verify_server_certificate
>  - driver_ssl_cert_verify


> All of these default to False, and if turned on, enable protections
> against MITM attacks.  All of them also fail to turn on for the relevant
> drivers if set in [DEFAULT].  These should, if set in DEFAULT when using
> multi-backend, issue a warning so the admin knows that they are not
> getting the intended security guarantees.  Instead, nothing happens and
> Cinder and the storage works.  Confusion is dangerous.
>

Yeah, so is crappy documentation lack of understanding.


>
> > Bottom line "yes", ideally in the case of drivers we would check
> > global/default setting, and then override it if something was provided in
> > the driver specific setting, or if the driver itself set a different
> > default.  That seems like the right way to be doing it anyway.  I've
> looked
> > at that a bit this morning, the issue is that currently we don't even
> pass
> > any of those higher level conf settings in to the drivers init methods
> > anywhere.  Need to figure out how to change that, then it should be a
> > relatively simple fix.
> >
>
> What I was getting at earlier though, is that I'm not really sure there
> is a simple fix.  It may be simple to change the behavior to more
> predictable behavior, but doing that in a way that doesn't introduce
> upgrade problems for deployments relying on the current defaults seems
> difficult to me.
>
Agreed, but honestly I'd like to at least try.  Especially when people use
terms like "blatantly wrong" and "dangerous", kinda prompts one to think 

that perhaps it should be looked at.  If nothing else, we shouldn't have
driver settings in the DEFAULT section, we should just create a driver
section, but we still need to figure out how to deal with things outside of
the "general" section vs the backend stanza.

Also, I'd argue that the behavior your arguing for is MORE dangerous and
troublesome.  The LIO being in the global CONF was a perfect example where
it broke third party devices on a specific distro because it assumed that
EVERYTHING on the system was using the lio methods and in that case you
really couldn't do anything but modify code.

I've pinged you a number of times on IRC, maybe we can chat there a

Re: [openstack-dev] [releases][requirements][keystone]something incompatible with our requirements

2015-09-18 Thread Doug Hellmann

Excerpts from Robert Collins's message of 2015-09-19 07:32:18 +1200:
> I know this is terrible timing with the release and all, but
> constraints updates are failing. This is the first evidence - and it
> doesn't look like a race to me:
> http://logs.openstack.org/57/221157/10/check/gate-tempest-dsvm-full/18eb440/logs/devstacklog.txt.gz#_2015-09-18_13_51_46_902
> 
> https://review.openstack.org/#/c/221157/ is the updated review to
> bring it all together. I'm worried that the incompatibility is going
> to impact distributors and/or may even be from one of our own recent
> library releases.
> 

It looks like this is a problem from os-client-config 1.7.0 and later.
The constraints file has not been updating on new releases, so we're
still constrained to 1.6.4 in jobs that use the constraints, which is
why it isn't showing up elsewhere.

To debug, I ran:

git clone openstack/python-openstackclient
tox -e py27 --notest
.tox/py27/bin/openstack --debug
(error)
.tox/py27/bin/pip install os-client-config==1.7.1
.tox/py27/bin/openstack --debug
(error)
.tox/py27/bin/pip install os-client-config==1.7.0
.tox/py27/bin/openstack --debug
(error)
.tox/py27/bin/pip install os-client-config==1.6.4
.tox/py27/bin/openstack --debug
(works)

Doug

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

Re: [openstack-dev] [Barbican] Providing service user read access to all tenant's certificates

Typos corrected.

From: Vijay Venkatachalam
Sent: 18 September 2015 00:36
To: OpenStack Development Mailing List (not for usage questions) 

Subject: RE: [openstack-dev] [Barbican] Providing service user read access to 
all tenant's certificates

Yes Dave, that is what is happening today.

But that approach looks a little untidy, because tenant admin has to do some 
infrastructure work.

It will be good from the user/tenant admin's perspective to just do 2 things

1.  Upload certificates info

2.  Create LBaaS Configuration with certificates already uploaded

Now because barbican and LBaaS does *not* work nicely with each other, every 
tenant admin has to do the following

1.  Upload certificates info

2.  Read a document or finds out there is a LBaaS service user and somehow 
gets hold of LBaaS service user's userid. Assigns read rights to that 
certificate to LBaaS service user.

3.  Creates LBaaS Configuration with certificates already uploaded

This does not fit the "As a service" model of OpenStack where tenant's just 
configure whatever they want and the infrastructure takes care of automating 
the rest.

Thanks,
Vijay V.

From: Dave McCowan (dmccowan) [mailto:dmcco...@cisco.com]
Sent: 17 September 2015 18:20
To: OpenStack Development Mailing List (not for usage questions) 
>
Subject: Re: [openstack-dev] [Barbican] Providing service user read access to 
all tenant's certificates

The tenant admin from Step 1, should also do Step 2.

From: Vijay Venkatachalam 
>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Wednesday, September 16, 2015 at 9:57 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Subject: Re: [openstack-dev] [Barbican] Providing service user read access to 
all tenant's certificates

How does lbaas do step 2?
It does not have the privilege for that secret/container using the service user.
Should it use the keystone token through which user created LB config and 
assign read access for the secret/container to the LBaaS service user?

Thanks,
Vijay V.

From: Fox, Kevin M [mailto:kevin@pnnl.gov]
Sent: 16 September 2015 19:24
To: OpenStack Development Mailing List (not for usage questions) 
>
Subject: Re: [openstack-dev] [Barbican] Providing service user read access to 
all tenant's certificates

Why not have lbaas do step 2? Even better would be to help with the instance 
user spec and combined with lbaas doing step 2, you could restrict secret 
access to just the amphora that need the secret?

Thanks,
Kevin

From: Vijay Venkatachalam
Sent: Tuesday, September 15, 2015 7:06:39 PM
To: OpenStack Development Mailing List 
(openstack-dev@lists.openstack.org)
Subject: [openstack-dev] [Barbican] Providing service user read access to all 
tenant's certificates
Hi,
   Is there a way to provide read access to a certain user to all 
secrets/containers of all project/tenant's certificates?
   This user with universal "read" privilege's will be used as a 
service user by LBaaS plugin to read tenant's certificates during LB 
configuration implementation.

   Today's LBaaS users are following the below mentioned process

1.  tenant's creator/admin user uploads a certificate info as secrets and 
container

2.  User then have to create ACLs for the LBaaS service user to access the 
containers and secrets

3.  User creates LB config with the container reference

4.  LBaaS plugin using the service user will then access container 
reference provided in LB config and proceeds to implement.

Ideally we would want to avoid step 2 in the process. Instead add a step 5 
where the lbaas plugin's service user checks if the user configuring the LB has 
read access to the container reference provided.

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

Re: [openstack-dev] [neutron][lbaas] Is SSL offload config possible using non "admin" tenant?


Sure Adam. Pleasure is mine ☺.

Also, I don’t see any wrong doing by LBaaS (infact it is the right thing to do) 
if LBaaS plugin is specifying the tenant containers unique URL and also correct 
tenant context in the keystone session to fetch the container.
Although, if barbican fixes to ignore the tenant value in keystone session and 
only authenticates the user for verification, it is a bonus and LBaaS current 
code will work.

LongTerm, We need to eliminate the step of assigning access by tenant’s admin 
and automate it.

I had initiated a thread 3 days  earlier with Barbican on the same issue. Here 
is the link.
https://www.mail-archive.com/openstack-dev@lists.openstack.org/msg63476.html

Thanks,
Vijay V.


From: Adam Harwell [mailto:adam.harw...@rackspace.com]
Sent: 19 September 2015 01:17
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [neutron][lbaas] Is SSL offload config possible 
using non "admin" tenant?

That sounds like the Barbican ACLs are not working properly. The whole point of 
using Barbican ACLs is that the keystone session marked for tenant "admin" 
should be able to get access to ANY tenant’s container/secrets if the ACLs are 
set. I am still not convinced this is an issue on the LBaaS side. 
Unfortunately, I don’t have a lot of time to test this right now as we’re up 
against the clock for the gate, so your help in debugging and fixing this issue 
is greatly appreciated! I just want to make sure the expected workflow is fully 
understood.

--Adam

https://keybase.io/rm_you


From: Vijay Venkatachalam 
>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Friday, September 18, 2015 at 2:02 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Subject: Re: [openstack-dev] [neutron][lbaas] Is SSL offload config possible 
using non "admin" tenant?


>> This honestly hasn’t even been *fully* tested yet, but it SHOULD work.
It did not work. Please read on.
>> User sets ACLs on Secrets and Container in Barbican, to allow the LBaaS user 
>> (right now using whatever user-id we publish in our docs) to read their data.
I did perform the above step to give read access for the container and secrets 
to “admin”, but it did not work.

Root Cause
==
The certmanager in lbaas which connects to barbican uses the keystone session 
gathered from
neutron_lbaas.common.keystone.get_session()
Since the keystone session is marked for tenant “admin” lbaas is not able to 
get the tenant’s container/certificate.

I have filed a bug for the same.

https://bugs.launchpad.net/neutron/+bug/1497410

This is an important fix required since tenants wont be able to use SSL 
Offload. Will try to upload a fix for this next week.


Thanks,
Vijay V.

From: Adam Harwell [mailto:adam.harw...@rackspace.com]
Sent: 16 September 2015 00:32
To: OpenStack Development Mailing List (not for usage questions) 
>
Subject: Re: [openstack-dev] [neutron][lbaas] Is SSL offload config possible 
using non "admin" tenant?

There is not really good documentation for this yet…
When I say Neutron-LBaaS tenant, I am maybe using the wrong word — I guess the 
user that is configured as the service-account in neutron.conf.
The user will hit the ACL API themselves to set up the ACLs on their own 
secrets/containers, we won’t do it for them. So, workflow is like:


  *   User creates Secrets in Barbican.
  *   User creates CertificateContainer in Barbican.
  *   User sets ACLs on Secrets and Container in Barbican, to allow the LBaaS 
user (right now using whatever user-id we publish in our docs) to read their 
data.
  *   User creates a LoadBalancer in Neutron-LBaaS.
  *   LBaaS hits Barbican using its standard configured service-account to 
retrieve the Container/Secrets from the user’s Barbican account.
This honestly hasn’t even been *fully* tested yet, but it SHOULD work. The 
question is whether right now in devstack the admin user is allowed to read all 
user secrets just because it is the admin user (which I think might be the 
case), in which case we won’t actually know if ACLs are working as intended 
(but I think we assume that Barbican has tested that feature and we can just 
rely on it working).

--Adam

https://keybase.io/rm_you


From: Vijay Venkatachalam 
>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Monday, September 14, 2015 at 9:12 PM
To: "OpenStack Development Mailing List (not for usage questions)"

Re: [openstack-dev] [cinder] LVM snapshot performance issue -- why isn't thin provisioning the default?

2015-09-18 Thread Eric Harney

On 09/18/2015 03:33 PM, John Griffith wrote:
> On Fri, Sep 18, 2015 at 12:52 PM, Eric Harney  wrote:
> 
>> On 09/18/2015 01:01 PM, John Griffith wrote:
>>> On Fri, Sep 18, 2015 at 9:06 AM, Chris Friesen <
>> chris.frie...@windriver.com>
>>> wrote:
>>>
 On 09/18/2015 06:57 AM, Eric Harney wrote:

> On 09/17/2015 06:06 PM, John Griffith wrote:
>

 Having the "global conf" settings intermixed with the backend sections
>> caused a number of issues when we first started working on this.
>> That's
>> part of why we require the "self.configuration" usage all over in the
>> drivers.  Each driver instantiation is it's own independent entity.
>>
>>
> Yes, each driver instantiation is independent, but that would still be
> the case if these settings inherited values set in [DEFAULT] when they
> aren't set in the backend section.
>

 Agreed.  If I explicitly set something in the [DEFAULT] section, that
 should carry through and apply to all the backends unless overridden in
>> the
 backend-specific section.

 Chris


>>> Meh I don't know about the "have to modify the code", the config file
>> works
>>> you just need to add that line to your driver section and configure the
>>> backend correctly.
>>>
>>
>> My point is that there doesn't seem to be a justification for "you just
>> need to add that line to your driver section", which seems to counter
>> what most people's expectation would be.
>>
> There certainly is, I don't want to force the same options against all
> backends.  Perfect example is the issues with some distros in the past that
> DID use global settings and stomp over any driver; which in turn broke
> those that weren't compatible with that conf setting even though in the
> driver section they overrode it.
> 
> 
>>
>> People can and do fail to do that, because they assume that [DEFAULT]
>> settings are treated as defaults.
>>
> 
> Bad assumption, we should probably document this until we fix it (making a
> very large assumption that we'll ever agree on how to fix it).
> 
>>
>> To help people who make that assumption, yes, you have to modify the
>> code, because the code supplies a default value that you cannot supply
>> in the same way via config files.
>>
> 
> Or you could just fill out the config file properly:
> [lvm-1]
> iscsi_helper = lioadm
> 
> I didn't have to modify any code.
> 
> 
> 

In the use case I was describing, I'm shipping a package, as a
distribution, with a default configuration file. The deployer (not me)
is the only one that knows about config sections that they want for
multi-backend. I don't think it's fair to require them to fill out
things like iscsi_helper, because there is only one correct value for
iscsi_helper on the platform I support, and defaulting to a different
one is not useful.

The fact that we don't inherit [DEFAULT] settings means that it is not
possible for me to ship a package with the correct defaults without
changing the hard-coded default value, in the code, to customize it for
my platform. I want to set iscsi_helper = lioadm in a configuration file
and have that be the default for any enabled_backend.


>>
>>> Regardless, I see your point (but I still certainly don't agree that it's
>>> "blatantly wrong").
>>>
>>
>> You can substitute "very confusing" for "blatantly wrong" but I think
>> those are about the same thing when talking about usability issues with
>> how to configure a service.
>>
> 
> Fair enough.  Call it whatever you like.
> 
> 
>>
>> Look at options like:
>>  - strict_ssh_host_key_policy
>>  - sio_verify_server_certificate
>>  - driver_ssl_cert_verify
> 
> 
>> All of these default to False, and if turned on, enable protections
>> against MITM attacks.  All of them also fail to turn on for the relevant
>> drivers if set in [DEFAULT].  These should, if set in DEFAULT when using
>> multi-backend, issue a warning so the admin knows that they are not
>> getting the intended security guarantees.  Instead, nothing happens and
>> Cinder and the storage works.  Confusion is dangerous.
>>
> 
> Yeah, so is crappy documentation lack of understanding.
> 
> 

I can't make my customers read documentation and test them for
understanding.  I can make software that's more robust and less prone to
misuse.  Warning people with "hey, you're using multi-backend and have
set this security-related option in a section where it will never have
an effect in your deployment" is one way to do this that we could do today.

>>
>>> Bottom line "yes", ideally in the case of drivers we would check
>>> global/default setting, and then override it if something was provided in
>>> the driver specific setting, or if the driver itself set a different
>>> default.  That seems like the right way to be doing it anyway.  I've
>> looked
>>> at that a bit this morning, the issue is that currently we don't even
>> pass
>>> any of those higher level conf

Re: [openstack-dev] [Congress] Congress Usecases VM

2015-09-18 Thread Shiv Haris

Hi Congress folks,

BTW the login/password for the VM is vagrant/vagrant

-Shiv

From: Shiv Haris [mailto:sha...@brocade.com]
Sent: Thursday, September 17, 2015 5:03 PM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [Congress] Congress Usecases VM

Hi All,

I have put my VM (virtualbox) at:

http://paloaltan.net/Congress/Congress_Usecases_SEPT_17_2015.ova

I usually run this on a macbook air - but it should work on other platfroms as 
well. I chose virtualbox since it is free.

Please send me your usecases - I can incorporate in the VM and send you an 
updated image. Please take a look at the structure I have in place for the 
first usecase; would prefer it be the same for other usecases. (However I am 
still open to suggestions for changes)

Thanks,

-Shiv

__
OpenStack Development Mailing 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] LVM snapshot performance issue -- why isn't thin provisioning the default?

2015-09-18 Thread Eric Harney

On 09/18/2015 01:01 PM, John Griffith wrote:
> On Fri, Sep 18, 2015 at 9:06 AM, Chris Friesen 
> wrote:
> 
>> On 09/18/2015 06:57 AM, Eric Harney wrote:
>>
>>> On 09/17/2015 06:06 PM, John Griffith wrote:
>>>
>>
>> Having the "global conf" settings intermixed with the backend sections
 caused a number of issues when we first started working on this.  That's
 part of why we require the "self.configuration" usage all over in the
 drivers.  Each driver instantiation is it's own independent entity.

>>> Yes, each driver instantiation is independent, but that would still be
>>> the case if these settings inherited values set in [DEFAULT] when they
>>> aren't set in the backend section.
>>>
>>
>> Agreed.  If I explicitly set something in the [DEFAULT] section, that
>> should carry through and apply to all the backends unless overridden in the
>> backend-specific section.
>>
>> Chris
>>
>>
> Meh I don't know about the "have to modify the code", the config file works
> you just need to add that line to your driver section and configure the
> backend correctly.
> 

My point is that there doesn't seem to be a justification for "you just
need to add that line to your driver section", which seems to counter
what most people's expectation would be.

People can and do fail to do that, because they assume that [DEFAULT]
settings are treated as defaults.

To help people who make that assumption, yes, you have to modify the
code, because the code supplies a default value that you cannot supply
in the same way via config files.

> Regardless, I see your point (but I still certainly don't agree that it's
> "blatantly wrong").
> 

You can substitute "very confusing" for "blatantly wrong" but I think
those are about the same thing when talking about usability issues with
how to configure a service.

Look at options like:
 - strict_ssh_host_key_policy
 - sio_verify_server_certificate
 - driver_ssl_cert_verify

All of these default to False, and if turned on, enable protections
against MITM attacks.  All of them also fail to turn on for the relevant
drivers if set in [DEFAULT].  These should, if set in DEFAULT when using
multi-backend, issue a warning so the admin knows that they are not
getting the intended security guarantees.  Instead, nothing happens and
Cinder and the storage works.  Confusion is dangerous.

> Bottom line "yes", ideally in the case of drivers we would check
> global/default setting, and then override it if something was provided in
> the driver specific setting, or if the driver itself set a different
> default.  That seems like the right way to be doing it anyway.  I've looked
> at that a bit this morning, the issue is that currently we don't even pass
> any of those higher level conf settings in to the drivers init methods
> anywhere.  Need to figure out how to change that, then it should be a
> relatively simple fix.
> 

What I was getting at earlier though, is that I'm not really sure there
is a simple fix.  It may be simple to change the behavior to more
predictable behavior, but doing that in a way that doesn't introduce
upgrade problems for deployments relying on the current defaults seems
difficult to me.

__
OpenStack Development Mailing 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] [releases][requirements][keystone]something incompatible with our requirements

2015-09-18 Thread Robert Collins

I know this is terrible timing with the release and all, but
constraints updates are failing. This is the first evidence - and it
doesn't look like a race to me:
http://logs.openstack.org/57/221157/10/check/gate-tempest-dsvm-full/18eb440/logs/devstacklog.txt.gz#_2015-09-18_13_51_46_902

https://review.openstack.org/#/c/221157/ is the updated review to
bring it all together. I'm worried that the incompatibility is going
to impact distributors and/or may even be from one of our own recent
library releases.



-- 
Robert Collins 
Distinguished Technologist
HP Converged Cloud

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

Re: [openstack-dev] [Barbican] Providing service user read access to all tenant's certificates


I would think OpenStack as Self Service portal.
Anyway, tenant’s admin need not play cloud admin’s role.
Only the cloud admin who sets up and manages openstack infrastructure (like 
controller Nodes etc) could know about the LBaaS service user. As much as 
possible the tenant admin should not be mandated to learn about the LBaaS 
service user.

From: Nathan Reller [mailto:nathan.s.rel...@gmail.com]
Sent: 18 September 2015 18:32
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [Barbican] Providing service user read access to 
all tenant's certificates

> But that approach looks a little untidy, because tenant admin has to do some 
> infrastructure work.

I would think infrastructure work would be part of the admin role. They are 
doing other things such as creating LBaaS, which seems like an infrastructure 
job to me. I would think configuring LBaaS and key management are similar. It 
seems like you think they are not similar. Can you explain more?

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

Re: [openstack-dev] [neutron][lbaas] Is SSL offload config possible using non "admin" tenant?

2015-09-18 Thread Adam Harwell

That sounds like the Barbican ACLs are not working properly. The whole point of 
using Barbican ACLs is that the keystone session marked for tenant "admin" 
should be able to get access to ANY tenant’s container/secrets if the ACLs are 
set. I am still not convinced this is an issue on the LBaaS side. 
Unfortunately, I don’t have a lot of time to test this right now as we’re up 
against the clock for the gate, so your help in debugging and fixing this issue 
is greatly appreciated! I just want to make sure the expected workflow is fully 
understood.

--Adam

https://keybase.io/rm_you


From: Vijay Venkatachalam 
>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Friday, September 18, 2015 at 2:02 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Subject: Re: [openstack-dev] [neutron][lbaas] Is SSL offload config possible 
using non "admin" tenant?


>> This honestly hasn’t even been *fully* tested yet, but it SHOULD work.
It did not work. Please read on.
>> User sets ACLs on Secrets and Container in Barbican, to allow the LBaaS user 
>> (right now using whatever user-id we publish in our docs) to read their data.
I did perform the above step to give read access for the container and secrets 
to “admin”, but it did not work.

Root Cause
==
The certmanager in lbaas which connects to barbican uses the keystone session 
gathered from
neutron_lbaas.common.keystone.get_session()
Since the keystone session is marked for tenant “admin” lbaas is not able to 
get the tenant’s container/certificate.

I have filed a bug for the same.

https://bugs.launchpad.net/neutron/+bug/1497410

This is an important fix required since tenants wont be able to use SSL 
Offload. Will try to upload a fix for this next week.


Thanks,
Vijay V.

From: Adam Harwell [mailto:adam.harw...@rackspace.com]
Sent: 16 September 2015 00:32
To: OpenStack Development Mailing List (not for usage questions) 
>
Subject: Re: [openstack-dev] [neutron][lbaas] Is SSL offload config possible 
using non "admin" tenant?

There is not really good documentation for this yet…
When I say Neutron-LBaaS tenant, I am maybe using the wrong word — I guess the 
user that is configured as the service-account in neutron.conf.
The user will hit the ACL API themselves to set up the ACLs on their own 
secrets/containers, we won’t do it for them. So, workflow is like:


  *   User creates Secrets in Barbican.
  *   User creates CertificateContainer in Barbican.
  *   User sets ACLs on Secrets and Container in Barbican, to allow the LBaaS 
user (right now using whatever user-id we publish in our docs) to read their 
data.
  *   User creates a LoadBalancer in Neutron-LBaaS.
  *   LBaaS hits Barbican using its standard configured service-account to 
retrieve the Container/Secrets from the user’s Barbican account.
This honestly hasn’t even been *fully* tested yet, but it SHOULD work. The 
question is whether right now in devstack the admin user is allowed to read all 
user secrets just because it is the admin user (which I think might be the 
case), in which case we won’t actually know if ACLs are working as intended 
(but I think we assume that Barbican has tested that feature and we can just 
rely on it working).

--Adam

https://keybase.io/rm_you


From: Vijay Venkatachalam 
>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Monday, September 14, 2015 at 9:12 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Subject: Re: [openstack-dev] [neutron][lbaas] Is SSL offload config possible 
using non "admin" tenant?

Is there a documentation which records step by step?

What is Neutron-LBaaS tenant?

Is it the tenant who is configuring the listener? *OR* is it some tenant which 
is created for lbaas plugin that is the having all secrets for all tenants 
configuring lbaas.

>>You need to set up ACLs on the Barbican side for that container, to make it 
>>readable to the Neutron-LBaaS tenant.
I checked the ACL docs
http://docs.openstack.org/developer/barbican/api/quickstart/acls.html

The ACL API is to allow “users”(not “Tenants”) access to secrets/containers. 
What is the API or CLI that the admin will use to allow access of the tenant’s 
secret+container to Neutron-LBaaS tenant.


From: Adam Harwell [mailto:adam.harw...@rackspace.com]
Sent: 15 September 2015 03:00
To: OpenStack Development Mailing List (not for usage questions)

Re: [openstack-dev] [releases][requirements][keystone]something incompatible with our requirements

2015-09-18 Thread Morgan Fainberg

I'm not seeing the source of this at a quick glance (in keystoneclient where I 
am assuming the plugin is being loaded from?). I'll look a bit more closely 
after I finish my food. 

--Morgan

Sent via mobile

> On Sep 18, 2015, at 12:32, Robert Collins  wrote:
> 
> I know this is terrible timing with the release and all, but
> constraints updates are failing. This is the first evidence - and it
> doesn't look like a race to me:
> http://logs.openstack.org/57/221157/10/check/gate-tempest-dsvm-full/18eb440/logs/devstacklog.txt.gz#_2015-09-18_13_51_46_902
> 
> https://review.openstack.org/#/c/221157/ is the updated review to
> bring it all together. I'm worried that the incompatibility is going
> to impact distributors and/or may even be from one of our own recent
> library releases.
> 
> 
> 
> -- 
> Robert Collins 
> Distinguished Technologist
> HP Converged Cloud
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing 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] [releases][requirements][keystone]something incompatible with our requirements

2015-09-18 Thread Robert Collins

On 19 September 2015 at 08:03, Doug Hellmann  wrote:
> Excerpts from Robert Collins's message of 2015-09-19 07:32:18 +1200:
>> I know this is terrible timing with the release and all, but
>> constraints updates are failing. This is the first evidence - and it
>> doesn't look like a race to me:
>> http://logs.openstack.org/57/221157/10/check/gate-tempest-dsvm-full/18eb440/logs/devstacklog.txt.gz#_2015-09-18_13_51_46_902
>>
>> https://review.openstack.org/#/c/221157/ is the updated review to
>> bring it all together. I'm worried that the incompatibility is going
>> to impact distributors and/or may even be from one of our own recent
>> library releases.
>>
>
> It looks like this is a problem from os-client-config 1.7.0 and later.
> The constraints file has not been updating on new releases, so we're
> still constrained to 1.6.4 in jobs that use the constraints, which is
> why it isn't showing up elsewhere.
>
> To debug, I ran:
>
> git clone openstack/python-openstackclient
> tox -e py27 --notest
> .tox/py27/bin/openstack --debug
> (error)
> .tox/py27/bin/pip install os-client-config==1.7.1
> .tox/py27/bin/openstack --debug
> (error)
> .tox/py27/bin/pip install os-client-config==1.7.0
> .tox/py27/bin/openstack --debug
> (error)
> .tox/py27/bin/pip install os-client-config==1.6.4
> .tox/py27/bin/openstack --debug
> (works)

Monty seems to think that this is a case where we can just roll
forward - I'm going to guess its a grouping thing:
A = os-client-config
B = python-openstackclient

A < x + B < y works
A < x + B >= y breaks
A >= x + B < y breaks
A >= x + B >= y works

And API use of A and B is not itself incompatible at any point:
clients of A and clients of B don't need to change - though one might
argue that A and B are mutually incompatible once A@x released and
that really we should have been able to detect that before releases
were cut of them.

That said, PyPI can express that situation (in that A < x can depend
on B = x can depend on B >=y) natively...

But we can't express in OpenStack projects today due to limitations in
pip combined with the g-r syncing process - we take a flattened view
of everything and the algebra for specifiers is per package, not
composable/groupable like this would require.

We don't have a good canned answer here: while the transition is in
progress we're protected (in functional tests, and shortly in unit
tests), but anyone not using constraints will feel the pain.

Even once the transition is complete anyone doing partial upgrades can
be burnt (upgrade only B or only A and it breaks).

Worse, because of limitations in pip (specifically that reverse deps
are not checked when updating packages) there is little we can do to
stop people being broken in the field: we're contributing to pip to
get to the point that those things are possible, but currently its
future work.

So - I think the pragmatic thing here is to:
 - review the CI for A and B here to see if we can prevent the
incompatibilities occuring at all in future transitions like this
[expand-contract is a much safer pattern and should be usable]
 - document in the readme for python-openstackclient that this schism
exists so its discoverable for the supported lifetime of liberty

-Rob

-- 
Robert Collins 
Distinguished Technologist
HP Converged Cloud

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

Re: [openstack-dev] [cinder] LVM snapshot performance issue -- why isn't thin provisioning the default?

On Fri, Sep 18, 2015 at 11:31 AM, Chris Friesen  wrote:

> On 09/18/2015 11:01 AM, John Griffith wrote:
>
>>
>>
>> On Fri, Sep 18, 2015 at 9:06 AM, Chris Friesen <
>> chris.frie...@windriver.com
>> > wrote:
>>
>> On 09/18/2015 06:57 AM, Eric Harney wrote:
>>
>> On 09/17/2015 06:06 PM, John Griffith wrote:
>>
>>
>> Having the "global conf" settings intermixed with the backend
>> sections
>> caused a number of issues when we first started working on
>> this.  That's
>> part of why we require the "self.configuration" usage all
>> over in the
>> drivers.  Each driver instantiation is it's own independent
>> entity.
>>
>>
>> Yes, each driver instantiation is independent, but that would
>> still be
>> the case if these settings inherited values set in [DEFAULT] when
>> they
>> aren't set in the backend section.
>>
>>
>> Agreed.  If I explicitly set something in the [DEFAULT] section, that
>> should
>> carry through and apply to all the backends unless overridden in the
>> backend-specific section.
>>
>
>
> Bottom line "yes", ideally in the case of drivers we would check
>> global/default
>> setting, and then override it if something was provided in the driver
>> specific
>> setting, or if the driver itself set a different default.  That seems
>> like the
>> right way to be doing it anyway.  I've looked at that a bit this morning,
>> the
>> issue is that currently we don't even pass any of those higher level conf
>> settings in to the drivers init methods anywhere.  Need to figure out how
>> to
>> change that, then it should be a relatively simple fix.
>>
>
> Actually, I think it should be slightly different.  If I set a variable in
> the global/default section of the config file, then that should override
> any defaults in the code for a driver.
>

Hmm... well, on the bright side that might be easier to implement at least
:). I guess I don't agree on the meaning of "DEFAULT", to me a "DEFAULT"
section means, "these are the defaults if you don't specify something
else", no?  Your proposal seems really counter-intuitive to me.

Anyway, I've come up with a way to read the DEFAULT section of CONF on
init in the driver so that's good.  The trick now though is when there's a
difference in value between the driver section and the default section;
knowing what was set explicitly and what wasn't.  In other words I don't
have any way of knowing for sure if the setting came from reading in the
defaults in the declaration options or if it was explicitly set in the
config file.

Still working on it, but curious if anybody might know how to get around
this little sticking point.

Thanks,
John




> So the order of descending precedence would go:
>
> 1) setting specified in driver-specific section of config file
> 2) setting specified in global/default section of config file
> 3) setting specified in driver-specific code
> 4) setting specified in global/default code (not sure if this exists)
>
>
>
> Chris
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing 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-dahboard directory is not created

2015-09-18 Thread OpenStack Mailing List Archive


Link: https://openstack.nimeyo.com/59453/?show=59453#q59453
From: vidya 

I am trying to create openstack -dashboard on my VM and /usr/share/openstack-dashboard in not create. Please help me what i am missing here.

here is what i tried 
 1 yum install openstack-selinux
 2  yum install yum-plugin-priorities
 3  yum install http://dl.fedoraproject.org/pub/epel/7/x86_64/e/epel-release-7-5.noarch.rpm
4  yum install openstack-dashboard httpd mod_wsgi memcached python-memcached
5  yum install python-pip
6  yum groupinstall 'Development Tools'
7  yum  install python-devel
8  yum install libffi-devel
9  yum install openssl-devel
   10  pip install dep/horizon-2014.1.1.tar.gz 
   11  yum install openstack-dashboard
   12  yum upgrade
   13  reboot
   14  history
   15  yum install openstack-dashboard
   16  pip install horizon-2014.1.1.tar.gz 

16 execution gave me this

Processing ./dep/horizon-2014.1.1.tar.gz
  Requirement already satisfied (use --upgrade to upgrade): horizon==2014.1.1 from file:///home/centos/dep/horizon-2014.1.1.tar.gz in /usr/lib/python2.7/site-packages
Requirement already satisfied (use --upgrade to upgrade): Django<1.7,>=1.4 in /usr/lib/python2.7/site-packages (from horizon==2014.1.1)
Requirement already satisfied (use --upgrade to upgrade): django-compressor>=1.3 in /usr/lib/python2.7/site-packages (from horizon==2014.1.1)
Requirement already satisfied (use --upgrade to upgrade): django-openstack-auth>=1.1.4 in /usr/lib/python2.7/site-packages (from horizon==2014.1.1)
Requirement already satisfied (use --upgrade to upgrade): eventlet>=0.13.0 in /usr/lib/python2.7/site-packages (from horizon==2014.1.1)
Requirement already satisfied (use --upgrade to upgrade): iso8601>=0.1.9 in /usr/lib/python2.7/site-packages (from horizon==2014.1.1)
Requirement already satisfied (use --upgrade to upgrade): kombu>=2.4.8 in /usr/lib/python2.7/site-packages (from horizon==2014.1.1)
Requirement already satisfied (use --upgrade to upgrade): lesscpy>=0.9j in /usr/lib/python2.7/site-packages (from horizon==2014.1.1)
Requirement already satisfied (use --upgrade to upgrade): lockfile>=0.8 in /usr/lib/python2.7/site-packages (from horizon==2014.1.1)
Requirement already satisfied (use --upgrade to upgrade): netaddr>=0.7.6 in /usr/lib/python2.7/site-packages (from horizon==2014.1.1)
Requirement already satisfied (use --upgrade to upgrade): pbr<1.0,>=0.6 in /usr/lib/python2.7/site-packages (from horizon==2014.1.1)
Requirement already satisfied (use --upgrade to upgrade): python-ceilometerclient>=1.0.6 in /usr/lib/python2.7/site-packages (from horizon==2014.1.1)
Requirement already satisfied (use --upgrade to upgrade): python-cinderclient>=1.0.6 in /usr/lib/python2.7/site-packages (from horizon==2014.1.1)
Requirement already satisfied (use --upgrade to upgrade): python-glanceclient>=0.9.0 in /usr/lib/python2.7/site-packages (from horizon==2014.1.1)
Requirement already satisfied (use --upgrade to upgrade): python-heatclient>=0.2.3 in /usr/lib/python2.7/site-packages (from horizon==2014.1.1)
Requirement already satisfied (use --upgrade to upgrade): python-keystoneclient>=0.7.0 in /usr/lib/python2.7/site-packages (from horizon==2014.1.1)
Requirement already satisfied (use --upgrade to upgrade): python-neutronclient<3,>=2.3.4 in /usr/lib/python2.7/site-packages (from horizon==2014.1.1)
Requirement already satisfied (use --upgrade to upgrade): python-novaclient>=2.17.0 in /usr/lib/python2.7/site-packages (from horizon==2014.1.1)
Requirement already satisfied (use --upgrade to upgrade): python-swiftclient>=1.6 in /usr/lib/python2.7/site-packages (from horizon==2014.1.1)
Requirement already satisfied (use --upgrade to upgrade): python-troveclient>=1.0.3 in /usr/lib/python2.7/site-packages (from horizon==2014.1.1)
Requirement already satisfied (use --upgrade to upgrade): pytz>=2010h in /usr/lib/python2.7/site-packages (from horizon==2014.1.1)
Requirement already satisfied (use --upgrade to upgrade): six>=1.6.0 in /usr/lib/python2.7/site-packages (from horizon==2014.1.1)
Requirement already satisfied (use --upgrade to upgrade): django-appconf>=0.4 in /usr/lib/python2.7/site-packages (from django-compressor>=1.3->horizon==2014.1.1)
Requirement already satisfied (use --upgrade to upgrade): oslo.policy>=0.5.0 in /usr/lib/python2.7/site-packages (from django-openstack-auth>=1.1.4->horizon==2014.1.1)
Requirement already satisfied (use --upgrade to upgrade): oslo.config>=2.3.0 in /usr/lib/python2.7/site-packages (from django-openstack-auth>=1.1.4->horizon==2014.1.1)
Requirement already satisfied (use --upgrade to upgrade): greenlet>=0.3 in /usr/lib64/python2.7/site-packages (from eventlet>=0.13.0->horizon==2014.1.1)
Requirement already satisfied (use --upgrade to upgrade): amqp<2.0,>=1.4.5 in /usr/lib/python2.7/site-packages (from kombu>=2.4.8->horizon==2014.1.1)
Requirement already satisfied (use --upgrade to upgrade): anyjson>=0.3.3 in /usr/lib/python2.7/site-packages (from

Re: [openstack-dev] Apache2 vs uWSGI vs ...

2015-09-18 Thread Morgan Fainberg

The conversations around alternative wsgi containers (uwsgi, gunicorn, etc) 
still would be tied to apache or nginx. While it is possible to deploy without 
the webservers in some cases, jt would not be recommended nor do I see that 
being tested in gate. We want to leverage the auth support of the webserver. 
While uWSGI has interesting features, it wouldnt really replace nginx or 
apache. It is just an alternative deployment strategy that makes managing the 
keystone (or any OpenStack service) processes independent of the web server. 

I do not expect any of these choices to have a performance impact. It will ease 
some operational concerns. There is no reason uwsgi or gunicorn wont work today 
(I have run keystone with both in a devstack locally). The documentation and 
communicating the reasons to pick one or the other is all that is needed. From 
a gate perspective configuration and restarts of the web server could be made 
easier in devstack with uWSGI. It would not prevent use of mod_wsgi. 

--Morgan

Sent via mobile

> On Sep 18, 2015, at 09:53, Yee, Guang  wrote:
> 
> I am with Adam, I kinda doubt Apache cause performance issues for Keystone, 
> especially since all we have are just simple REST APIs. For other services 
> with specific needs, like large file streaming, there may be some arguments 
> to pick one over the other. We haven’t had the need to use Apache for dynamic 
> routing or proxying at deployment. I am sure there are better tools out there 
> that can do the job.
>  
> Making Keystone web service independent is a fine goal. However, since 
> Keystone is moving away from being an identity provider, federation and 
> external auth will play a major part going forward. Some of them are depended 
> on the Apache at the moment. We may have to refactor Keystone to isolate the 
> authentication service from the rest, then figure out how to gate it with 
> Apache. I don’t think that’s trivial work though.
>  
> At this point, I don’t know what we are really gaining by ripping out Apache, 
> comparing to amount of work to make that happen.
>  
>  
> Guang
>  
>  
> From: Vladimir Kuklin [mailto:vkuk...@mirantis.com] 
> Sent: Friday, September 18, 2015 9:09 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: [openstack-dev] Apache2 vs uWSGI vs ...
>  
> Folks
> 
> I just suggested to untie keystone from wsgi and implement uwsgi support. And 
> then let the user decide what he or she wants.
> 
> There is a plenty of auth modules for nginx also.
> 
> Nginx us much better as a proxy server and you know it.
> 
> Regarding mod wsgi and apache we already saw that it cannot handle simple 
> restart. I think this is not in any way acceptable from operations point if 
> view.
> 
> 18 сент. 2015 г. 18:59 пользователь "Fox, Kevin M"  
> написал:
> Part of the reason to use Apache though is the diverse set of authentication 
> mechanisms it supports. Operators have the desire to plugin Keystone into 
> their existing authentication systems and Apache tends to be easier to do 
> that then others.
> 
> Thanks,
> Kevin
> 
> From: Jim Rollenhagen [j...@jimrollenhagen.com]
> Sent: Thursday, September 17, 2015 7:04 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] Apache2 vs uWSGI vs ...
> 
> On Thu, Sep 17, 2015 at 06:48:50PM -0400, Davanum Srinivas wrote:
> > In the fuel project, we recently ran into a couple of issues with Apache2 +
> > mod_wsgi as we switched Keystone to run . Please see [1] and [2].
> >
> > Looking deep into Apache2 issues specifically around "apache2ctl graceful"
> > and module loading/unloading and the hooks used by mod_wsgi [3]. I started
> > wondering if Apache2 + mod_wsgi is the "right" solution and if there was
> > something else better that people are already using.
> >
> > One data point that keeps coming up is, all the CI jobs use Apache2 +
> > mod_wsgi so it must be the best solutionIs it? If not, what is?
> 
> Disclaimer: it's been a while since I've cared about performance with a
> web server in front of a Python app.
> 
> IIRC, mod_wsgi was abandoned for a while, but I think it's being worked
> on again. In general, I seem to remember it being thought of as a bit
> old and crusty, but mostly working.
> 
> At a previous job, we switched from Apache2 + mod_wsgi to nginx + uwsgi[0]
> and saw a significant performance increase. This was a Django app. uwsgi
> is fairly straightforward to operate and comes loaded with a myriad of
> options[1] to help folks make the most of it. I've played with Ironic
> behind uwsgi and it seemed to work fine, though I haven't done any sort
> of load testing. I'd encourage folks to give it a shot. :)
> 
> Of course, uwsgi can also be ran behind Apache2, if you'd prefer.
> 
> gunicorn[2] is another good option that may be worth investigating; I
> personally don't have any experience with

Re: [openstack-dev] [all] [ptl] Troubleshooting cross-project communications

2015-09-18 Thread Shamail



> On Sep 17, 2015, at 7:50 PM, Mike Perez  wrote:
> 
>> On 16:16 Sep 16, Thierry Carrez wrote:
>> Anne Gentle wrote:
>>> [...]
>>> What are some of the problems with each layer? 
>>> 
>>> 1. weekly meeting: time zones, global reach, size of cross-project
>>> concerns due to multiple projects being affected, another meeting for
>>> PTLs to attend and pay attention to
>> 
>> A lot of PTLs (or liaisons/lieutenants) skip the meeting, or will only
>> attend when they have something to ask. Their time is precious and most
>> of the time the meeting is not relevant for them, so why bother ? You
>> have a few usual suspects attending all of them, but those people are
>> cross-project-aware already so those are not the people that would
>> benefit the most from the meeting.
>> 
>> This partial attendance makes the meeting completely useless as a way to
>> disseminate information. It makes the meeting mostly useless as a way to
>> get general approval on cross-project specs.
>> 
>> The meeting still is very useful IMHO to have more direct discussions on
>> hot topics. So a ML discussion is flagged for direct discussion on IRC
>> and we have a time slot already booked for that.
> 
> Content for the cross project meeting are usually:
> 
> * Not ready for decisions.
> * Lack solutions.
> 
> A proposal in steps of how cross project ideas start, to something ready for
> the cross project IRC meeting, then the TC:
> 
> 1) An idea starts from either or both:
>   a) Mailing list discussion.
>   b) A patch to a single project (until it's flagged that this patch could be
>  benefical to other projects)
> 2) OpenStack Spec is proposed - discussions happen in gerrit from here on out.
>   Not on the mailing list. Keep encouraging discussions back to gerrit to keep
>   everything in one place in order to avoid confusion with having to fish
>   for some random discussion elsewhere.
> 3) Once enough consensus happens an agenda item is posted cross project IRC
>   meeting.
> 4) Final discussions happen in the meeting. If consensus is still met by
>   interested parties who attend, it moves to TC.  If there is a lack of
>   consensus it goes back to gerrit and repeat.
> 
This approach makes sense.  It will also allow items that don't reach consensus 
to possibly be captured (once) and rise to the top again when/if it becomes a 
pressing need.  There has to be some process to abandon changes eventually too 
(if the scope changes or the initial ask if no longer relevant).  

> With this process, we should have less meetings. Less meetings is:
> 
> * Awesome
> * Makes this meeting more meaningful when it happens because decisions are
>  potentially going to be agreed and passed to the TC!
> 
> If a cross project spec is not getting attention, don't post it to the list 
> for
> attention. We get enough email and it'll probably be lost. Instead, let the
> product working group recognize this and reach out to the projects that this
> spec would benefit, to bring meaningful attention to the spec.
+1 
If something needs attention, we would be glad to help evaluate/socialize.
> 
> For vertical alignment, interaction like IRC is not necessary. A very brief,
> bullet point of collected information from projects that have anything
> interesting is given in a weekly digest email to the list If anyone has
> questions or wants more information, they can use their own time to ask that
> project team.
> 
> Potentially, if we kept everything to the spec on gerrit, and had the product
> working group bringing needed attention to specs, we could eliminate the cross
> project meeting.
> 
Does it make sense to propose a continuation of this discussion at the summit 
(using the tool that Thierry just linked in another message) or a cross-project 
meeting before the summit?  A few of us from the Product WG will be glad to 
participate.

> -- 
> 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] [releases][requirements][keystone]something incompatible with our requirements

2015-09-18 Thread David Stanek

On Fri, Sep 18, 2015 at 3:32 PM, Robert Collins 
wrote:

> I know this is terrible timing with the release and all, but
> constraints updates are failing. This is the first evidence - and it
> doesn't look like a race to me:
>
> http://logs.openstack.org/57/221157/10/check/gate-tempest-dsvm-full/18eb440/logs/devstacklog.txt.gz#_2015-09-18_13_51_46_902
>
> https://review.openstack.org/#/c/221157/ is the updated review to
> bring it all together. I'm worried that the incompatibility is going
> to impact distributors and/or may even be from one of our own recent
> library releases.
>

This looks like the issue I just ran into. The newest os-client-config
depends on keystoneauth1 and this breaks openstackclient since it registers
its plugins under the keystoneclient entrypoint and not the keystoneauth1
entry point.

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

Re: [openstack-dev] [Neutron] Kuryr - Spec

2015-09-18 Thread Antoni Segura Puimedon

On Fri, Sep 18, 2015 at 8:30 PM, Gal Sagie  wrote:

> Hello everyone,
>
> We have a spec for project Kuryr in Neutron repository [1] , we have been
> iterating on it
> internally and with the great help and feedback from the Magnum team.
>
> I am glad to say that we reached a pretty good step where we have most of
> the
> Magnum team +1 the spec, i personally think all of the items for the first
> milestone
> (which is for Mitaka release) are well defined and already in working
> process (and low level
> design process).
>
> I would like to thank the Magnum team for working closely with us on this
> and for
> the valuable feedback.
>
> The reason why we put this in the Neutron repository is the fact that we
> feel Kuryr
> is not another Neutron implementation, it is an infrastructure project
> that can be used by
> any Neutron plugin and need (in my opinion) to go hand in hand with
> Neutron.
> We would like to make it visible to the Neutron team and i hope that we
> can get
> this spec merged for the Mitaka release to define our goals in Kuryr.
>
> We also have detailed designs and blueprints process in Kuryr repository
> for
> all the items described in the spec.
> I hope to see more comments/review from Neutron members on this spec.
>
> On a side note, we had a virtual sprint for Kuryr last week, apuimedo and
> taku will have
> a video of a demo thanks to the progress made on the sprint, so stay tuned
> for that to see whats available.
>

And Gal and I will be demoing live the development version in the Summit
[1], so come
see our talk ;-)

[1]
https://openstacksummitoctober2015tokyo.sched.org/event/b90847a5496c0a2454929d95a0afc46e


>
> Thanks
> Gal.
>
> [1] https://review.openstack.org/#/c/213490/
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] (NOVA) Is there a Queue maintained for instance requests

2015-09-18 Thread Dhvanan Shah

Hi,

I had a question regarding the process of spawning an instance.
In the whole process from requesting an instance to scheduling to spawning
,is there a queue maintained where the requests go first, like in the case
of a scheduler of any OS that has a queue for jobs to be scheduled.
This question arises as I wanted to look at handling multiple instance
requests at a time and wanted to see if there was a common place where all
the instances get registered first and get spawned after that.

I went through the code base and tried to find if there was a queue. I
tried to traceback from the side of the client
-> create( in nova/api/openstack/compute/servers.py ) api server that
handles all the requests
->create and _create_instance (in nova/compute/api.py) that handle all the
requests regarding the compute resources.
->build_instances (nova/conductor/manager.py) handles all the db operations
from here on the request is sent to the scheduler that return a host for
the instance.


So I'm not sure if I missed it but I was not able to find any queue where
the requests are being registered. Could someone please help me understand
how this works.

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

[openstack-dev] [neutron][lbaas] Barbican container lookup fron lbaas

2015-09-18 Thread Varun Lodaya

Hi Guys,

With lbaasv2, I noticed that when we try to associate tls containers with lbaas 
listeners, lbaas tries to validate the container and while doing so, tries to 
get keystone token based on tenant/user credentials in neutron.conf file. 
However, the barbican containers could belong to different users in different 
tenants, in that case, container look up would always fail? Am I missing 
something?

Thanks,
Varun
__
OpenStack Development Mailing 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] PTL & Component Leads elections

2015-09-18 Thread Davanum Srinivas

+1 Dmitry

-- Dims

On Fri, Sep 18, 2015 at 9:07 PM, Dmitry Borodaenko  wrote:

> Dims,
>
> Thanks for the reminder!
>
> I've summarized the uncontroversial parts of that thread in a policy
> proposal as per you suggestion [0], please review and comment. I've
> renamed SMEs to maintainers since Mike has agreed with that part, and I
> omitted code review SLAs from the policy since that's the part that has
> generated the most discussion.
>
> [0] https://review.openstack.org/225376
>
> I don't think we should postpone the election: the PTL election follows
> the same rules as OpenStack so we don't need a Fuel-specific policy for
> that, and the component leads election doesn't start until October 9,
> which gives us 3 weeks to confirm consensus on that aspect of the
> policy.
>
> --
> Dmitry Borodaenko
>
>
> On Fri, Sep 18, 2015 at 07:30:39AM -0400, Davanum Srinivas wrote:
> > Sergey,
> >
> > Please see [1]. Did we codify some of these roles and responsibilities
> as a
> > community in a spec? There was also a request to use terminology like say
> > MAINTAINERS in that email as well.
> >
> > Are we pulling the trigger a bit early for an actual election?
> >
> > Thanks,
> > Dims
> >
> > [1] http://markmail.org/message/2ls5obgac6tvcfss
> >
> > On Fri, Sep 18, 2015 at 6:56 AM, Vladimir Kuklin 
> > wrote:
> >
> > > Sergey, Fuelers
> > >
> > > This is awesome news!
> > >
> > > By the way, I have a question on who is eligible to vote and to
> nominate
> > > him/her-self for both PTL and Component Leads. Could you elaborate on
> that?
> > >
> > > And there is no such entity as Component Lead in OpenStack - so we are
> > > actually creating one. What are the new rights and responsibilities of
> CL?
> > >
> > > On Fri, Sep 18, 2015 at 5:39 AM, Sergey Lukjanov <
> slukja...@mirantis.com>
> > > wrote:
> > >
> > >> Hi folks,
> > >>
> > >> I'd like to announce that we're running the PTL and Component Leads
> > >> elections. Detailed information available on wiki. [0]
> > >>
> > >> Project Team Lead: Manages day-to-day operations, drives the project
> > >> team goals, resolves technical disputes within the project team. [1]
> > >>
> > >> Component Lead: Defines architecture of a module or component in Fuel,
> > >> reviews design specs, merges majority of commits and resolves
> conflicts
> > >> between Maintainers or contributors in the area of responsibility. [2]
> > >>
> > >> Fuel has two large sub-teams, with roughly comparable codebases, that
> > >> need dedicated component leads: fuel-library and fuel-python. [2]
> > >>
> > >> Nominees propose their candidacy by sending an email to the
> > >> openstack-dev@lists.openstack.org mailing-list, which the subject:
> > >> "[fuel] PTL candidacy" or "[fuel]  lead candidacy"
> > >> (for example, "[fuel] fuel-library lead candidacy").
> > >>
> > >> Time line:
> > >>
> > >> PTL elections
> > >> * September 18 - September 28, 21:59 UTC: Open candidacy for PTL
> position
> > >> * September 29 - October 8: PTL elections
> > >>
> > >> Component leads elections (fuel-library and fuel-python)
> > >> * October 9 - October 15: Open candidacy for Component leads positions
> > >> * October 16 - October 22: Component leads elections
> > >>
> > >> [0] https://wiki.openstack.org/wiki/Fuel/Elections_Fall_2015
> > >> [1] https://wiki.openstack.org/wiki/Governance
> > >> [2]
> > >>
> http://lists.openstack.org/pipermail/openstack-dev/2015-August/072406.html
> > >> [3] https://lwn.net/Articles/648610/
> > >>
> > >> --
> > >> Sincerely yours,
> > >> Sergey Lukjanov
> > >> Sahara Technical Lead
> > >> (OpenStack Data Processing)
> > >> Principal Software Engineer
> > >> Mirantis Inc.
> > >>
> > >>
> __
> > >> OpenStack Development Mailing List (not for usage questions)
> > >> Unsubscribe:
> > >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > >>
> > >>
> > >
> > >
> > > --
> > > Yours Faithfully,
> > > Vladimir Kuklin,
> > > Fuel Library Tech Lead,
> > > Mirantis, Inc.
> > > +7 (495) 640-49-04
> > > +7 (926) 702-39-68
> > > Skype kuklinvv
> > > 35bk3, Vorontsovskaya Str.
> > > Moscow, Russia,
> > > www.mirantis.com 
> > > www.mirantis.ru
> > > vkuk...@mirantis.com
> > >
> > >
> __
> > > OpenStack Development Mailing List (not for usage questions)
> > > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > >
> > >
> >
> >
> > --
> > Davanum Srinivas :: https://twitter.com/dims
>
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
>

Re: [openstack-dev] [neutron] [oslo.privsep] Any progress on privsep?

2015-09-18 Thread Li Ma

Thanks for your reply, Gus. That's awesome. I'd like to have a look at
it or test if possible.

Any source code available in the upstream?

On Fri, Sep 18, 2015 at 12:40 PM, Angus Lees  wrote:
> On Fri, 18 Sep 2015 at 14:13 Li Ma  wrote:
>>
>> Hi stackers,
>>
>> Currently we are discussing the possibility of using a pure python
>> library to configure network in neutron [1]. We find out that it is
>> impossible to do it without privsep, because we run external commands
>> which cannot be replaced by python calls via rootwrap.
>>
>> Privsep has been merged in the Liberty cycle. I just wonder how it is
>> going on.
>>
>> [1] https://bugs.launchpad.net/neutron/+bug/1492714
>
>
> Thanks for your interest :)  This entire cycle has been spent on the spec.
> It looks like it might be approved very soon (got the first +2 overnight),
> which will then unblock a string of "create new oslo project" changes.
>
> During the spec discussion, the API was changed (for the better).  Now it
> looks like the discussion has settled down, I'm getting to work rewriting it
> following the new API.  It took me about 2 weeks to write it the first time
> around (almost all on testing framework), so I'd expect something of similar
> magnitude this time.
>
> I don't make predictions about timelines that rely on the OpenStack review
> process, but if you forced me I'd _guess_ it will be ready for projects to
> try out early in M.
>
>  - Gus
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 

Li Ma (Nick)
Email: skywalker.n...@gmail.com

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

Re: [openstack-dev] [oslo.messaging][zmq]

2015-09-18 Thread Doug Hellmann

Excerpts from ozamiatin's message of 2015-09-16 18:24:53 +0300:
> Hi All,
> 
> I'm excited to report that today we have merged [1] new zmq driver into 
> oslo.messaging master branch.
> The driver is not completely done yet, so we are going to continue 
> developing it on the master branch now.
> 
> What we've reached for now is passing functional tests gate (we are 
> going to turn it on in the master [2]).
> And we also have devstack up and running (almost 80% tempest tests 
> passed when I've tested it since last commit into feature/zmq). I need 
> to check all this after merge, to ensure that I didn't break something 
> resolving conflicts.
> 
> I'm going to put all ongoing tasks on launchpad and provide some 
> documentation soon, so anyone is welcome to develop new zmq driver.
> I also would like to thank Viktor Serhieiev and Doug Royal who already 
> contributed to feature/zmq.
> 
> [1] - https://review.openstack.org/#/c/223877
> [2] - https://review.openstack.org/#/c/224035
> 
> Thanks,
> Oleksii
> 

Congratulations on merging those changes into master! I know it has been
a long road, but I'm glad to see zmq reaching a usable state. Many
thanks to the entire team contributing to the work!

Doug

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

Re: [openstack-dev] [Barbican] Providing service user read access to all tenant's certificates

2015-09-18 Thread Kant, Arun

>From description of use case, looks like you want 'service user' to access any 
>tenant resource regardless of that user has a tenant role or not and  without 
>explicit read assignment on that resource.  This can be done via a customized 
>policy where related 'get' calls are allowed access for a specific role and 
>assign that role to 'service user'. This role check can be made restrictive by 
>looking for specific 'service' tenant or 'service' domain.

-Arun


From: Vijay Venkatachalam [mailto:vijay.venkatacha...@citrix.com]
Sent: Friday, September 18, 2015 1:16 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Barbican] Providing service user read access to 
all tenant's certificates

Typos corrected.

From: Vijay Venkatachalam
Sent: 18 September 2015 00:36
To: OpenStack Development Mailing List (not for usage questions) 
>
Subject: RE: [openstack-dev] [Barbican] Providing service user read access to 
all tenant's certificates

Yes Dave, that is what is happening today.

But that approach looks a little untidy, because tenant admin has to do some 
infrastructure work.

It will be good from the user/tenant admin's perspective to just do 2 things

1.   Upload certificates info

2.   Create LBaaS Configuration with certificates already uploaded

Now because barbican and LBaaS does *not* work nicely with each other, every 
tenant admin has to do the following


1.   Upload certificates info

2.   Read a document or finds out there is a LBaaS service user and somehow 
gets hold of LBaaS service user's userid. Assigns read rights to that 
certificate to LBaaS service user.

3.   Creates LBaaS Configuration with certificates already uploaded

This does not fit the "As a service" model of OpenStack where tenant's just 
configure whatever they want and the infrastructure takes care of automating 
the rest.

Thanks,
Vijay V.

From: Dave McCowan (dmccowan) [mailto:dmcco...@cisco.com]
Sent: 17 September 2015 18:20
To: OpenStack Development Mailing List (not for usage questions) 
>
Subject: Re: [openstack-dev] [Barbican] Providing service user read access to 
all tenant's certificates


The tenant admin from Step 1, should also do Step 2.

From: Vijay Venkatachalam 
>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Wednesday, September 16, 2015 at 9:57 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Subject: Re: [openstack-dev] [Barbican] Providing service user read access to 
all tenant's certificates


How does lbaas do step 2?
It does not have the privilege for that secret/container using the service user.
Should it use the keystone token through which user created LB config and 
assign read access for the secret/container to the LBaaS service user?

Thanks,
Vijay V.

From: Fox, Kevin M [mailto:kevin@pnnl.gov]
Sent: 16 September 2015 19:24
To: OpenStack Development Mailing List (not for usage questions) 
>
Subject: Re: [openstack-dev] [Barbican] Providing service user read access to 
all tenant's certificates

Why not have lbaas do step 2? Even better would be to help with the instance 
user spec and combined with lbaas doing step 2, you could restrict secret 
access to just the amphora that need the secret?

Thanks,
Kevin


From: Vijay Venkatachalam
Sent: Tuesday, September 15, 2015 7:06:39 PM
To: OpenStack Development Mailing List 
(openstack-dev@lists.openstack.org)
Subject: [openstack-dev] [Barbican] Providing service user read access to all 
tenant's certificates
Hi,
   Is there a way to provide read access to a certain user to all 
secrets/containers of all project/tenant's certificates?
   This user with universal "read" privilege's will be used as a 
service user by LBaaS plugin to read tenant's certificates during LB 
configuration implementation.

   Today's LBaaS users are following the below mentioned process

1.  tenant's creator/admin user uploads a certificate info as secrets and 
container

2.  User then have to create ACLs for the LBaaS service user to access the 
containers and secrets

3.  User creates LB config with the container reference

4.  LBaaS plugin using the service user will then access container 
reference provided in LB config and proceeds to implement.

Ideally we would want to avoid step 2 in the process. Instead add a step 5 
where the lbaas plugin's service user checks if the user

Re: [openstack-dev] [cinder] LVM snapshot performance issue -- why isn't thin provisioning the default?

On Fri, Sep 18, 2015 at 2:46 PM, Eric Harney  wrote:

> On 09/18/2015 03:33 PM, John Griffith wrote:
> > On Fri, Sep 18, 2015 at 12:52 PM, Eric Harney 
> wrote:
> >
> >> On 09/18/2015 01:01 PM, John Griffith wrote:
> >>> On Fri, Sep 18, 2015 at 9:06 AM, Chris Friesen <
> >> chris.frie...@windriver.com>
> >>> wrote:
> >>>
>  On 09/18/2015 06:57 AM, Eric Harney wrote:
> 
> > On 09/17/2015 06:06 PM, John Griffith wrote:
> >
> 
>  Having the "global conf" settings intermixed with the backend sections
> >> caused a number of issues when we first started working on this.
> >> That's
> >> part of why we require the "self.configuration" usage all over in
> the
> >> drivers.  Each driver instantiation is it's own independent entity.
> >>
> >>
> > Yes, each driver instantiation is independent, but that would still
> be
> > the case if these settings inherited values set in [DEFAULT] when
> they
> > aren't set in the backend section.
> >
> 
>  Agreed.  If I explicitly set something in the [DEFAULT] section, that
>  should carry through and apply to all the backends unless overridden
> in
> >> the
>  backend-specific section.
> 
>  Chris
> 
> 
> >>> Meh I don't know about the "have to modify the code", the config file
> >> works
> >>> you just need to add that line to your driver section and configure the
> >>> backend correctly.
> >>>
> >>
> >> My point is that there doesn't seem to be a justification for "you just
> >> need to add that line to your driver section", which seems to counter
> >> what most people's expectation would be.
> >>
> > There certainly is, I don't want to force the same options against all
> > backends.  Perfect example is the issues with some distros in the past
> that
> > DID use global settings and stomp over any driver; which in turn broke
> > those that weren't compatible with that conf setting even though in the
> > driver section they overrode it.
> >
> >
> >>
> >> People can and do fail to do that, because they assume that [DEFAULT]
> >> settings are treated as defaults.
> >>
> >
> > Bad assumption, we should probably document this until we fix it
> (making a
> > very large assumption that we'll ever agree on how to fix it).
> >
> >>
> >> To help people who make that assumption, yes, you have to modify the
> >> code, because the code supplies a default value that you cannot supply
> >> in the same way via config files.
> >>
> >
> > Or you could just fill out the config file properly:
> > [lvm-1]
> > iscsi_helper = lioadm
> >
> > I didn't have to modify any code.
> > 
> >
> >
>
> In the use case I was describing, I'm shipping a package, as a
> distribution, with a default configuration file. The deployer (not me)
> is the only one that knows about config sections that they want for
> multi-backend. I don't think it's fair to require them to fill out
> things like iscsi_helper, because there is only one correct value for
> iscsi_helper on the platform I support, and defaulting to a different
> one is not useful.
>
Ahh, ok; so back to one of the problems with OpenStack IMO, too many
options/choices.  Regardless though yes I can see where you're coming from
now.  In your case there is only one supported/correct option here so that
creates a problem.



>
> The fact that we don't inherit [DEFAULT] settings means that it is not
> possible for me to ship a package with the correct defaults without
> changing the hard-coded default value, in the code, to customize it for
> my platform. I want to set iscsi_helper = lioadm in a configuration file
> and have that be the default for any enabled_backend.
>
Yes, now I see the case you're referring to, thanks!  This is why I tried
to grab you on IRC to make sure I actually followed what your particular
case was.



>
> >>
> >>> Regardless, I see your point (but I still certainly don't agree that
> it's
> >>> "blatantly wrong").
> >>>
> >>
> >> You can substitute "very confusing" for "blatantly wrong" but I think
> >> those are about the same thing when talking about usability issues with
> >> how to configure a service.
> >>
> >
> > Fair enough.  Call it whatever you like.
> >
> >
> >>
> >> Look at options like:
> >>  - strict_ssh_host_key_policy
> >>  - sio_verify_server_certificate
> >>  - driver_ssl_cert_verify
> >
> >
> >> All of these default to False, and if turned on, enable protections
> >> against MITM attacks.  All of them also fail to turn on for the relevant
> >> drivers if set in [DEFAULT].  These should, if set in DEFAULT when using
> >> multi-backend, issue a warning so the admin knows that they are not
> >> getting the intended security guarantees.  Instead, nothing happens and
> >> Cinder and the storage works.  Confusion is dangerous.
> >>
> >
> > Yeah, so is crappy documentation lack of understanding.
> >
> >
>
> I can't make my customers read documentation and test them for
>

Re: [openstack-dev] [all][ptl][release] final liberty cycle client library releases needed

Doug,

python-mistralclient-1.1.0 (also on pypi) is the final release for Liberty. 
Here’s the patch updating global-requirements.txt: 
https://review.openstack.org/#/c/225330/ 
 (upper-constraints.txt should be 
soon updated automatically, in my understanding)

I really apologize because I should have probably followed ML better and 
attended corresponding meetings in order to know all of this release management 
stuff.  But I still have a number questions on release management like:
So far I have been doing release management for Mistral myself (~2 years), and 
the last year I’ve been trying to be aligned with OpenStack schedule. In may 
2015 Mistral was accepted into Big Tent so does that mean I’m not longer 
responsible for doing that? Or I can still do it on my own? Even with final 
Mistral client for Liberty I’ve done it just myself (didn’t create a stable 
branch though yet), maybe I shouldn’t have. Clarifications would be helpful.
Same question about stable branches.
Does this all apply to all Big Tent projects?
What exactly is upper-constraints.txt for? I’m still not sure why 
global-requirements.txt is not enough.
What’s the best source of info about release management? Is it complete?

Sorry for asking this probably basic stuff.

Let me know if some of what I’ve done is wrong. It’s a late night here but I’ll 
check ML the first thing in the morning just in case.

Thanks

Renat Akhmerov
@ Mirantis Inc.

> On 15 Sep 2015, at 22:24, Nikhil Komawar  wrote:
> 
> Hi Doug,
> 
> And it would be good to lock in on glance_store (if it applies to this
> email) 0.9.1 too. (that's on pypi)
> 
> On 9/14/15 9:26 AM, Kuvaja, Erno wrote:
>> Hi Doug,
>> 
>> Please find python-glanceclient 1.0.1 release request 
>> https://review.openstack.org/#/c/222716/
>> 
>> - Erno
>> 
>>> -Original Message-
>>> From: Doug Hellmann [mailto:d...@doughellmann.com]
>>> Sent: Monday, September 14, 2015 1:46 PM
>>> To: openstack-dev
>>> Subject: [openstack-dev] [all][ptl][release] final liberty cycle client 
>>> library
>>> releases needed
>>> 
>>> PTLs and release liaisons,
>>> 
>>> In order to keep the rest of our schedule for the end-of-cycle release 
>>> tasks,
>>> we need to have final releases for all client libraries in the next day or 
>>> two.
>>> 
>>> If you have not already submitted your final release request for this cycle,
>>> please do that as soon as possible.
>>> 
>>> If you *have* already submitted your final release request for this cycle,
>>> please reply to this email and let me know that you have so I can create 
>>> your
>>> stable/liberty branch.
>>> 
>>> Thanks!
>>> Doug
>>> 
>>> __
>>> 
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: OpenStack-dev-
>>> requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> -- 
> 
> Thanks,
> Nikhil
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing 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] Define better terms for WAITING and DELAYED states


> On 18 Sep 2015, at 18:47, HADDLETON, Robert W (Bob) 
>  wrote:
> 
> Hi Renat:
> 
> [TL;DR] - maybe use multiple words in the state name to avoid confusion
> 
> I agree that there is a lot of overlap - WAITING and DELAYED and POSTPONED 
> are all very similar.  The context is important when trying to decipher what 
> the words means.
> 
> I would normally interpret WAITING as having a known condition:
> 
> * I'm WAITING for the baseball game to begin
> 
> DELAYED implies WAITING but adds the context that something was supposed to 
> have started already, or has already started, is now blocked by something out 
> of your control, and you may or may not know when it will start again:
> 
> * The (start of the) ballgame has been DELAYED (by rain) (until 2:00). (So 
> I'm still WAITING for it to begin)
> 
> POSTPONED implies DELAYED, but adds that something was "scheduled" to start 
> at a certain time and has been re-scheduled for a later time.  It may or may 
> not have started already, and the later time may or may not be known:
> 
> * The ballgame has been POSTPONED (because of rain) (until tomorrow) (so the 
> game has been DELAYED and I'm still WAITING for it to start)
> 
> So using any of the three words on their own without context or additional 
> information will likely be confusing, or at least subject to different 
> interpretations.
> 
> I would be reluctant to rename DELAYED to POSTPONED, because it raises more 
> questions (until when?) than DELAYED without providing more answers.

Yeah, this makes perfect sense to me. Really good analysis. I agree that 
context is really important to eliminate ambiguity.

> I think what it comes down to is the need to provide more information in the 
> state name than is possible with one English word:
> 
> WAITING_FOR_PRECONDITIONS
> DELAYED_BY_RETRY
> 
> These provide more specific context to the state but the state transition 
> table gets to be unmanageable when there is a state for everything.
> 
> If more Waiting/delayed states are added it in the future it might make sense 
> to create them as sub-states of RUNNING, to keep the transitions manageable.


This all makes me think that we probably just need to clarify one of these 
names so they look like:
RUNNING_DELAYED - a substate of RUNNING and it has exactly this meaning: it’s 
generally running but delayed till some later time.
WAITING - it is not a substate of RUNNING and hence it means a task has not 
started yet

And at the same time these names still remain not too verbose.

What do you think?

P.S. Thank you very much Robert!

Renat Akhmerov
@ Mirantis Inc.

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

Re: [openstack-dev] [magnum] Associating patches with bugs/bps (Please don't hurt me)

2015-09-18 Thread Hongbin Lu

For the guidance, I saw the judgement is a bit subjective. It could happen that 
a contributor think his/her patch is trivial (or it is not fixing a function 
defect), but a reviewer think the opposite. For example, I find it hard to 
judge when I reviewed the following patches:

https://review.openstack.org/#/c/224183/
https://review.openstack.org/#/c/224198/
https://review.openstack.org/#/c/224184/

It could be helpful if the guide can provide some examples of what is a trivial 
patch, and what is not. OpenStack uses this approach to define what is a 
good/bad commit message, which I find it quite helpful.

https://wiki.openstack.org/wiki/GitCommitMessages#Examples_of_bad_practice
https://wiki.openstack.org/wiki/GitCommitMessages#Examples_of_good_practice

Best regards,
Hongbin

From: Adrian Otto [mailto:adrian.o...@rackspace.com]
Sent: September-17-15 5:09 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [magnum] Associating patches with bugs/bps (Please 
don't hurt me)

For posterity, I have recorded this guidance in our Contributing Wiki:

See the NOTE section under:

https://wiki.openstack.org/wiki/Magnum/Contributing#Identify_bugs

Excerpt:

"NOTE: If you are fixing something trivial, that is not actually a functional 
defect in the software, you can do that without filing a bug ticket, if you 
don't want it to be tracked when we tally this work between releases. If you do 
this, just mention it in the commit message that it's a trivial change that 
does not require a bug ticket. You can reference this guideline if it comes up 
in discussion during the review process. Functional defects should be tracked 
in bug tickets. New features should be tracked in blueprints. Trivial features 
may be tracked using a bug ticket marked as 'Wishlist' importance."

I hope that helps.

Adrian

On Sep 17, 2015, at 2:01 PM, Adrian Otto 
> wrote:

Let’s apply sensible reason. If it’s a new feature or a bug, it should be 
tracked against an artifact like a bug ticket or a blueprint. If it’s truly 
trivia, we don’t care. I can tell you that some of the worst bugs I have ever 
seen in my career had fixes that were about 4 bytes long. That did not make 
them any less serious.

If you are fixing an actual legitimate bug that has a three character fix, and 
you don’t want it to be tracked as the reviewer, then you can say so in the 
commit message. We can act accordingly going forward.

Adrian

On Sep 17, 2015, at 1:53 PM, Assaf Muller 
> wrote:

On Thu, Sep 17, 2015 at 4:09 PM, Jeff Peeler 
> wrote:

On Thu, Sep 17, 2015 at 3:28 PM, Fox, Kevin M 
> wrote:
I agree. Lots of projects have this issue. I submitted a bug fix once that 
literally was 3 characters long, and it took:
A short commit message, a long commit message, and a full bug report being 
filed and cross linked. The amount of time writing it up was orders of 
magnitude longer then the actual fix.

Seems a bit much...

Looking at this review, I'd go a step farther and argue that code cleanups like 
this one should be really really easy to get through. No one likes to do them, 
so we should be encouraging folks that actually do it. Not pile up roadblocks.

It is indeed frustrating. I've had a few similar reviews (in other projects - 
hopefully it's okay I comment here) as well. Honestly, I think if a given team 
is willing to draw the line as for what is permissible to commit without bug 
creation, then they should be permitted that freedom.

However, that said, I'm sure somebody is going to point out that come release 
time having the list of bugs fixed in a given release is handy, spelling errors 
included.

We've had the same debate in Neutron and we relaxed the rules. We don't require 
bugs for trivial changes. In fact, my argument has always been: Come release
time, when we say that the Neutron community fixed so and so bugs, we would be 
lying if we were to include fixing spelling issues in comments. That's not a 
bug.

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

Re: [openstack-dev] [releases][requirements][keystone]something incompatible with our requirements

2015-09-18 Thread Monty Taylor


On 09/18/2015 04:29 PM, Robert Collins wrote:

On 19 September 2015 at 08:03, Doug Hellmann  wrote:

Excerpts from Robert Collins's message of 2015-09-19 07:32:18 +1200:

I know this is terrible timing with the release and all, but
constraints updates are failing. This is the first evidence - and it
doesn't look like a race to me:
http://logs.openstack.org/57/221157/10/check/gate-tempest-dsvm-full/18eb440/logs/devstacklog.txt.gz#_2015-09-18_13_51_46_902

https://review.openstack.org/#/c/221157/ is the updated review to
bring it all together. I'm worried that the incompatibility is going
to impact distributors and/or may even be from one of our own recent
library releases.



It looks like this is a problem from os-client-config 1.7.0 and later.
The constraints file has not been updating on new releases, so we're
still constrained to 1.6.4 in jobs that use the constraints, which is
why it isn't showing up elsewhere.

To debug, I ran:

git clone openstack/python-openstackclient
tox -e py27 --notest
.tox/py27/bin/openstack --debug
(error)
.tox/py27/bin/pip install os-client-config==1.7.1
.tox/py27/bin/openstack --debug
(error)
.tox/py27/bin/pip install os-client-config==1.7.0
.tox/py27/bin/openstack --debug
(error)
.tox/py27/bin/pip install os-client-config==1.6.4
.tox/py27/bin/openstack --debug
(works)


Monty seems to think that this is a case where we can just roll
forward - I'm going to guess its a grouping thing:
A = os-client-config
B = python-openstackclient

A < x + B < y works
A < x + B >= y breaks
A >= x + B < y breaks
A >= x + B >= y works


Yeah. Actually, I believe we've found a case where the system is doing 
its job - it just took us a sec to see that.


I've got a new patch up to os-client-config which fixes the problem 
without requiring modifications to openstackclient- which is how this 
should work. It's an ugly patch - but meh, life is ugly.



And API use of A and B is not itself incompatible at any point:
clients of A and clients of B don't need to change - though one might
argue that A and B are mutually incompatible once A@x released and
that really we should have been able to detect that before releases
were cut of them.

That said, PyPI can express that situation (in that A < x can depend
on B = x can depend on B >=y) natively...

But we can't express in OpenStack projects today due to limitations in
pip combined with the g-r syncing process - we take a flattened view
of everything and the algebra for specifiers is per package, not
composable/groupable like this would require.

We don't have a good canned answer here: while the transition is in
progress we're protected (in functional tests, and shortly in unit
tests), but anyone not using constraints will feel the pain.

Even once the transition is complete anyone doing partial upgrades can
be burnt (upgrade only B or only A and it breaks).

Worse, because of limitations in pip (specifically that reverse deps
are not checked when updating packages) there is little we can do to
stop people being broken in the field: we're contributing to pip to
get to the point that those things are possible, but currently its
future work.

So - I think the pragmatic thing here is to:
  - review the CI for A and B here to see if we can prevent the
incompatibilities occuring at all in future transitions like this
[expand-contract is a much safer pattern and should be usable]
  - document in the readme for python-openstackclient that this schism
exists so its discoverable for the supported lifetime of liberty

-Rob




__
OpenStack Development Mailing 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] [oslo.messaging][zmq]

2015-09-18 Thread Davanum Srinivas

Hear hear! nice work Oleksii and team!

-- Dims

On Fri, Sep 18, 2015 at 4:51 PM, Doug Hellmann 
wrote:

> Excerpts from ozamiatin's message of 2015-09-16 18:24:53 +0300:
> > Hi All,
> >
> > I'm excited to report that today we have merged [1] new zmq driver into
> > oslo.messaging master branch.
> > The driver is not completely done yet, so we are going to continue
> > developing it on the master branch now.
> >
> > What we've reached for now is passing functional tests gate (we are
> > going to turn it on in the master [2]).
> > And we also have devstack up and running (almost 80% tempest tests
> > passed when I've tested it since last commit into feature/zmq). I need
> > to check all this after merge, to ensure that I didn't break something
> > resolving conflicts.
> >
> > I'm going to put all ongoing tasks on launchpad and provide some
> > documentation soon, so anyone is welcome to develop new zmq driver.
> > I also would like to thank Viktor Serhieiev and Doug Royal who already
> > contributed to feature/zmq.
> >
> > [1] - https://review.openstack.org/#/c/223877
> > [2] - https://review.openstack.org/#/c/224035
> >
> > Thanks,
> > Oleksii
> >
>
> Congratulations on merging those changes into master! I know it has been
> a long road, but I'm glad to see zmq reaching a usable state. Many
> thanks to the entire team contributing to the work!
>
> Doug
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



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

Re: [openstack-dev] [fuel] PTL & Component Leads elections

2015-09-18 Thread Vladimir Kuklin

Sergey, Fuelers

This is awesome news!

By the way, I have a question on who is eligible to vote and to nominate
him/her-self for both PTL and Component Leads. Could you elaborate on that?

And there is no such entity as Component Lead in OpenStack - so we are
actually creating one. What are the new rights and responsibilities of CL?

On Fri, Sep 18, 2015 at 5:39 AM, Sergey Lukjanov 
wrote:

> Hi folks,
>
> I'd like to announce that we're running the PTL and Component Leads
> elections. Detailed information available on wiki. [0]
>
> Project Team Lead: Manages day-to-day operations, drives the project
> team goals, resolves technical disputes within the project team. [1]
>
> Component Lead: Defines architecture of a module or component in Fuel,
> reviews design specs, merges majority of commits and resolves conflicts
> between Maintainers or contributors in the area of responsibility. [2]
>
> Fuel has two large sub-teams, with roughly comparable codebases, that
> need dedicated component leads: fuel-library and fuel-python. [2]
>
> Nominees propose their candidacy by sending an email to the
> openstack-dev@lists.openstack.org mailing-list, which the subject:
> "[fuel] PTL candidacy" or "[fuel]  lead candidacy"
> (for example, "[fuel] fuel-library lead candidacy").
>
> Time line:
>
> PTL elections
> * September 18 - September 28, 21:59 UTC: Open candidacy for PTL position
> * September 29 - October 8: PTL elections
>
> Component leads elections (fuel-library and fuel-python)
> * October 9 - October 15: Open candidacy for Component leads positions
> * October 16 - October 22: Component leads elections
>
> [0] https://wiki.openstack.org/wiki/Fuel/Elections_Fall_2015
> [1] https://wiki.openstack.org/wiki/Governance
> [2]
> http://lists.openstack.org/pipermail/openstack-dev/2015-August/072406.html
> [3] https://lwn.net/Articles/648610/
>
> --
> Sincerely yours,
> Sergey Lukjanov
> Sahara Technical Lead
> (OpenStack Data Processing)
> Principal Software Engineer
> Mirantis Inc.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Yours Faithfully,
Vladimir Kuklin,
Fuel Library Tech Lead,
Mirantis, Inc.
+7 (495) 640-49-04
+7 (926) 702-39-68
Skype kuklinvv
35bk3, Vorontsovskaya Str.
Moscow, Russia,
www.mirantis.com 
www.mirantis.ru
vkuk...@mirantis.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][elections] PTL nomination period is now over

On 09/17/2015 09:15 PM, Nikhil Komawar wrote:
> 
> I like to solve problems and seems like this is a common problem in many
> conferences, seminars, etc. The usual way of solving this issue is to
> have a grace period with last minute extension to deadline for
> proposals, possibly for a unknown period of time and unannounced.

I'm strongly against this extra rules. OpenStack Officials Elections are
ran by volunteers and any rules that adds complexity should be avoided.

Thanks,
Tristan




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] [all][elections] PTL nomination period is now over


On 18/09/15 12:22 +, Tristan Cacqueray wrote:

On 09/17/2015 09:15 PM, Nikhil Komawar wrote:


I like to solve problems and seems like this is a common problem in many
conferences, seminars, etc. The usual way of solving this issue is to
have a grace period with last minute extension to deadline for
proposals, possibly for a unknown period of time and unannounced.


I'm strongly against this extra rules. OpenStack Officials Elections are
ran by volunteers and any rules that adds complexity should be avoided.


+1

Also, the schedule is announced 6 months in advance. The candidacy
period is announced when it starts and a reminder is sent a couple of
days before it ends.

This is not to say that ppl is not subject to other, not expected,
inconvenienes but I don't think extending the period or bending the
process is the right solution here.


--
@flaper87
Flavio Percoco


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

[openstack-dev] [nova] live migration in Mitaka

2015-09-18 Thread Murray, Paul (HP Cloud)

Hi All,

There are various efforts going on around live migration at the moment: fixing 
up CI, bug fixes, additions to cover more corner cases, proposals for new 
operations

Generally live migration could do with a little TLC (see: [1]), so I am going 
to suggest we give some of that care in the next cycle.

Please respond to this post if you have an interest in this and what you would 
like to see done. Include anything you are already getting on with so we get a 
clear picture. If there is enough interest I'll put this together as a proposal 
for a work stream. Something along the lines of "robustify live migration".

Paul

[1]: 
https://www.openstack.org/summit/vancouver-2015/summit-videos/presentation/live-migration-at-hp-public-cloud


Paul Murray
Nova Technical Lead, HP Cloud
+44 117 316 2527

Hewlett-Packard Limited   |   Registered Office: Cain Road, Bracknell, 
Berkshire, RG12 1HN   |Registered No: 690597 England   |VAT Number: GB 
314 1496 79

This e-mail may contain confidential and/or legally privileged material for the 
sole use of the intended recipient.  If you are not the intended recipient (or 
authorized to receive for the recipient) please contact the sender by reply 
e-mail and delete all copies of this message.  If you are receiving this 
message internally within the Hewlett Packard group of companies, you should 
consider the contents "CONFIDENTIAL".

__
OpenStack Development Mailing 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][requirements] lockfile not in global requirements

2015-09-18 Thread Andreas Jaeger


On 09/18/2015 12:54 PM, Renat Akhmerov wrote:

Thanks Andreas and Lingxian,

Andreas, the corresponding patch has landed:
https://review.openstack.org/#/c/225073/



Great, then syncing of requirements should be green again.

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


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

Re: [openstack-dev] [all][elections] PTL nomination period is now over

On 09/18/2015 09:41 AM, Steven Hardy wrote:
>> In my previous email I mentioned that folks can simply send the
>> > candidacy in advance or have someone else to propose it. Seriously,
>> > it's not about having a single day for sending the candidacy, it's
>> > about having a clear deadline where no more candidacies are
>> > considered. If a candidacy is sent 4 months in advance, I guess that's
>> > fine. I don't care.
> Cool, that wasn't really how I interpreted your previous mail, sounds like
> we're in violent agreement! :)
> 
> Cheers,
> 
> Steve

There is one technical issue if we want to let candidate submit their
candidacy early on. The openstack/election repository needs a cycle name
as well as a the final project list.



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

[openstack-dev] [Neutron] Separate floating IP pools?

2015-09-18 Thread Clark, Robert Graham

Is it possible to have separate floating-IP pools and grant a tenant access to 
only some of them?

Thought popped into my head while looking at the rbac-network spec here: 
https://review.openstack.org/#/c/132661/4/specs/liberty/rbac-networks.rst

Creating individual pools, allowing only some tenants access and having 
off-cloud network ACLs would get part way to satisfying the use cases that 
drive the above spec (I'm thinking of this as a more short term solution, 
certainly not a direct alternative).

I'm sure this is answered elsewhere but I couldn't find any direct information 
so I'm assuming no, it isn't supported but I wonder how much effort would be 
required to make it work?
-Rob
__
OpenStack Development Mailing 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][requirements] lockfile not in global requirements

Thanks Andreas and Lingxian,

Andreas, the corresponding patch has landed: 
https://review.openstack.org/#/c/225073/ 


Renat Akhmerov
@ Mirantis Inc.



> On 18 Sep 2015, at 12:08, Lingxian Kong  wrote:
> 
> Hi, Andreas,
> 
> Sorry for the late response from Mistral. Anyway, I'm coming :-)
> 
> I'll take a look and solve it if needed, thanks for letting us know that.
> 
> On Fri, Sep 18, 2015 at 2:22 AM, Andreas Jaeger  > wrote:
> The syncing of requirements fails from the requirements repository to 
> mistral-extra with
> 'lockfile' is not in global-requirements.txt
> 
> Mistral team, could you either propose to add lockfile to the global 
> requirements file - or remove it from your project, please?
> 
> for details see:
> https://jenkins.openstack.org/job/propose-requirements-updates/363/consoleFull
>  
> 
> 
> Andreas
> -- 
>  Andreas Jaeger aj@{suse.com ,opensuse.org 
> } Twitter/Identica: jaegerandi
>   SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
>GF: Felix Imendörffer, Jane Smithard, Graham Norton,
>HRB 21284 (AG Nürnberg)
> GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe 
> 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
> 
> 
> 
> 
> -- 
> Regards!
> ---
> Lingxian Kong
> __
> OpenStack Development Mailing 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] PTL & Component Leads elections

2015-09-18 Thread Davanum Srinivas

Sergey,

Please see [1]. Did we codify some of these roles and responsibilities as a
community in a spec? There was also a request to use terminology like say
MAINTAINERS in that email as well.

Are we pulling the trigger a bit early for an actual election?

Thanks,
Dims

[1] http://markmail.org/message/2ls5obgac6tvcfss

On Fri, Sep 18, 2015 at 6:56 AM, Vladimir Kuklin 
wrote:

> Sergey, Fuelers
>
> This is awesome news!
>
> By the way, I have a question on who is eligible to vote and to nominate
> him/her-self for both PTL and Component Leads. Could you elaborate on that?
>
> And there is no such entity as Component Lead in OpenStack - so we are
> actually creating one. What are the new rights and responsibilities of CL?
>
> On Fri, Sep 18, 2015 at 5:39 AM, Sergey Lukjanov 
> wrote:
>
>> Hi folks,
>>
>> I'd like to announce that we're running the PTL and Component Leads
>> elections. Detailed information available on wiki. [0]
>>
>> Project Team Lead: Manages day-to-day operations, drives the project
>> team goals, resolves technical disputes within the project team. [1]
>>
>> Component Lead: Defines architecture of a module or component in Fuel,
>> reviews design specs, merges majority of commits and resolves conflicts
>> between Maintainers or contributors in the area of responsibility. [2]
>>
>> Fuel has two large sub-teams, with roughly comparable codebases, that
>> need dedicated component leads: fuel-library and fuel-python. [2]
>>
>> Nominees propose their candidacy by sending an email to the
>> openstack-dev@lists.openstack.org mailing-list, which the subject:
>> "[fuel] PTL candidacy" or "[fuel]  lead candidacy"
>> (for example, "[fuel] fuel-library lead candidacy").
>>
>> Time line:
>>
>> PTL elections
>> * September 18 - September 28, 21:59 UTC: Open candidacy for PTL position
>> * September 29 - October 8: PTL elections
>>
>> Component leads elections (fuel-library and fuel-python)
>> * October 9 - October 15: Open candidacy for Component leads positions
>> * October 16 - October 22: Component leads elections
>>
>> [0] https://wiki.openstack.org/wiki/Fuel/Elections_Fall_2015
>> [1] https://wiki.openstack.org/wiki/Governance
>> [2]
>> http://lists.openstack.org/pipermail/openstack-dev/2015-August/072406.html
>> [3] https://lwn.net/Articles/648610/
>>
>> --
>> Sincerely yours,
>> Sergey Lukjanov
>> Sahara Technical Lead
>> (OpenStack Data Processing)
>> Principal Software Engineer
>> Mirantis Inc.
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> Yours Faithfully,
> Vladimir Kuklin,
> Fuel Library Tech Lead,
> Mirantis, Inc.
> +7 (495) 640-49-04
> +7 (926) 702-39-68
> Skype kuklinvv
> 35bk3, Vorontsovskaya Str.
> Moscow, Russia,
> www.mirantis.com 
> www.mirantis.ru
> vkuk...@mirantis.com
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


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

Re: [openstack-dev] [all][elections] PTL nomination period is now over

On 09/18/2015 06:58 AM, Flavio Percoco wrote:
> On 17/09/15 15:47 -0400, Doug Hellmann wrote:
>> Excerpts from Thierry Carrez's message of 2015-09-17 18:10:26 +0200:
>>> Monty Taylor wrote:
>>> > I agree- and this is a great example of places where human
>>> judgement is
>>> > better than rules.
>>> >
>>> > For instance - one of the projects had a nominee but it missed the
>>> > deadline, so that's probably an easy on.
>>> >
>>> > For one of the projects it had been looking dead for a while, so
>>> this is
>>> > the final nail in the coffin from my POV
>>> >
>>> > For the other three - I know they're still active projects with people
>>> > interested in them, so sorting them out will be fun!
>>>
>>> Looks like in 4 cases (Magnum, Barbican, Murano, Security) there is
>>> actually a candidate, they just missed the deadline. So that should be
>>> an easy discussion at the next TC meeting.

To be more precise, there are 2 candidacies for Magnum and 1 for
Security. I would prefer all candidates have their candidacy statement
proposed and then merged upon TC decision.

>>>
>>> For the last one, it is not an accident. I think it is indeed the final
>>> nail on the coffin.
>>>
>>
>> Yes, I was planning to wait until after the summit to propose that we
>> drop MagnetoDB from the official list of projects due to inactivity. We
>> can deal with it sooner, obviously.
> 
> +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
> 




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] [all][elections] PTL nomination period is now over

2015-09-18 Thread Steven Hardy

On Fri, Sep 18, 2015 at 08:56:06AM +0200, Flavio Percoco wrote:
> On 17/09/15 16:00 -0400, Doug Hellmann wrote:
> >Excerpts from Morgan Fainberg's message of 2015-09-17 12:51:33 -0700:
> >
> >>I think this is all superfluous however and we should simply encourage
> >>people to not wait until the last minute. Waiting to see who is
> >>running/what the field looks like isn't as important as standing up and
> >>saying you're interested in running.
> >
> >+1
> 
> Just want to +1 this. I'm going to be, probably, extrem here and
> sugest that we should just shrink the candidacy period to 1 (max 2)
> days.

-1 - the "problem" here (if you want to call it that) is that some folks
evidently found a week nomination period insufficient, for $whatever reason.

The obvious solution to that is to simply adopt the same branch model for
the openstack/election repo as all other projects - create a branch (or
directory) per release in openstack/election, and allow candidates to
propose their candidacy at any time during the preceding release cycle.

Then, if you clearly state the deadline ahead of time, you simply publish
results and/or start elections on that date, with whatever is in the repo
on that date and folks have the whole cycle (say from summit to RC1 time)
to consider running and propose their candidacy whenever they want.

I also think this would encourage discussion within the project teams about
who wants to run for PTL, with transparency about those interested/willing
ahead of time.

Perhaps you might WIP all submissions until a few days before the deadline,
such that if communities decide via mutual agreement one candidate should
take their turn as PTL submissions may be abandoned without any election.

IMHO rotation of PTL responsibilities is healthy, as is discussion
and openness in the community - being PTL isn't some sort of prize, it's a
time-consuming burden, which is mostly about coordination and release
management, not really about "leadership" at all (although it is about
community building and leading by example..)

I guess what I mean is I'm not really sure what the timeboxed nomination
period aims to achieve, particularly if you shrink it to one or two days -
that makes it extremely easy for folks to miss due to illness/travel or
$whatever, and implies some kind of race - which is the opposite, IMHO of
the dynamic we should be encouraging.

Steve

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

Re: [openstack-dev] [all][elections] PTL nomination period is now over

2015-09-18 Thread Steven Hardy

On Fri, Sep 18, 2015 at 10:55:30AM +0200, Flavio Percoco wrote:
> On 18/09/15 09:17 +0100, Steven Hardy wrote:
> >On Fri, Sep 18, 2015 at 08:56:06AM +0200, Flavio Percoco wrote:
> >>On 17/09/15 16:00 -0400, Doug Hellmann wrote:
> >>>Excerpts from Morgan Fainberg's message of 2015-09-17 12:51:33 -0700:
> >>>
> I think this is all superfluous however and we should simply encourage
> people to not wait until the last minute. Waiting to see who is
> running/what the field looks like isn't as important as standing up and
> saying you're interested in running.
> >>>
> >>>+1
> >>
> >>Just want to +1 this. I'm going to be, probably, extrem here and
> >>sugest that we should just shrink the candidacy period to 1 (max 2)
> >>days.
> >
> >-1 - the "problem" here (if you want to call it that) is that some folks
> >evidently found a week nomination period insufficient, for $whatever reason.
> >
> >The obvious solution to that is to simply adopt the same branch model for
> >the openstack/election repo as all other projects - create a branch (or
> >directory) per release in openstack/election, and allow candidates to
> >propose their candidacy at any time during the preceding release cycle.
> >
> >Then, if you clearly state the deadline ahead of time, you simply publish
> >results and/or start elections on that date, with whatever is in the repo
> >on that date and folks have the whole cycle (say from summit to RC1 time)
> >to consider running and propose their candidacy whenever they want.
> 
> This is the same thing I said in my previous email (you cut that off
> of your reply) with the only difference that you're suggesting not
> having a "candidacy day" but rather just have a "start election" day.

Ok, apologies, it wasn't my intention to mis-quote you, but I interpreted
your comments as meaning "candidacy period" meant proposals for candidacy
could *only* be made during that time, e.g your remarks about designating
someone to submit a review on a particular day.

> I'd argue saying that a deadline for candidacies is useful to have and
> it brings more formality to the process. It helps, in the case of
> using `openstack/elections` to have a deadline for cutting the branch
> or freezing reviews, etc.
> 
> Setting up the election takes some time, which means there has to be a
> date where the election officers stop considering new candidacies.

I think we're basically in agreement and arguing for the same thing - folks
should be able to look at the release schedule, and see, just like the
clearly communicated "feature freeze" date, a PTL candidacy freeze.

> >I also think this would encourage discussion within the project teams about
> >who wants to run for PTL, with transparency about those interested/willing
> >ahead of time.
> 
> +1
> 
> >Perhaps you might WIP all submissions until a few days before the deadline,
> >such that if communities decide via mutual agreement one candidate should
> >take their turn as PTL submissions may be abandoned without any election.
> 
> I guess this may work in some cases but this defeats the whole purpose
> of having an election and being able to vote, in private, which many
> people value.

Sure, but the dynamic implied by voting in private, an election, and
proposing candidacy at the last minute is one of competition for the role.

That, IMHO, is not all that healthy in this context, and most communities
should already be making all sorts of decisions by consensus, discussion
and mutual agreement.

Nothing I'm prosing defeats the purpose of the existing system - if more
than one candidate is keen to volunteer, they just do so, and the election
happens just as it does now.

> >IMHO rotation of PTL responsibilities is healthy, as is discussion
> >and openness in the community - being PTL isn't some sort of prize, it's a
> >time-consuming burden, which is mostly about coordination and release
> >management, not really about "leadership" at all (although it is about
> >community building and leading by example..)
> >
> >I guess what I mean is I'm not really sure what the timeboxed nomination
> >period aims to achieve, particularly if you shrink it to one or two days -
> >that makes it extremely easy for folks to miss due to illness/travel or
> >$whatever, and implies some kind of race - which is the opposite, IMHO of
> >the dynamic we should be encouraging.
> 
> In my previous email I mentioned that folks can simply send the
> candidacy in advance or have someone else to propose it. Seriously,
> it's not about having a single day for sending the candidacy, it's
> about having a clear deadline where no more candidacies are
> considered. If a candidacy is sent 4 months in advance, I guess that's
> fine. I don't care.

Cool, that wasn't really how I interpreted your previous mail, sounds like
we're in violent agreement! :)

Cheers,

Steve

__
OpenStack Development Mailing List (not for usage

Re: [openstack-dev] Apache2 vs uWSGI vs ...


On 18/09/15 06:44 -0700, Morgan Fainberg wrote:

There is and has been desire to support uWSGI and other alternatives to
mod_wsgi. There are a variety of operational reasons to consider uWSGI and/or
gunicorn behind apache most notably to facilitate easier management of the
processes independently of the webserver itself. With mod_wsgi the processes
are directly tied to the apache server where as with uWSGI and gunicorn you can
manage the various services independently and/or with differing VENVs more
easily. 


There are potential other concerns that must be weighed when considering which
method of deployment to use. I hope we have clear documentation within the next
cycle (and possible choices for the gate) for utilizing uWSGI and/or gunicorn. 



+1

FWIW, Zaqar has always been shipped as a wsgi app and the container
the team has recommended ever since it was put in production for the
first time has been uWSGI. uWSGI is already used by Zaqar in the gate
but it's being installed independently.

Flavio



--Morgan

Sent via mobile

On Sep 18, 2015, at 06:12, Adam Young  wrote:


   On 09/17/2015 10:04 PM, Jim Rollenhagen wrote:

   On Thu, Sep 17, 2015 at 06:48:50PM -0400, Davanum Srinivas wrote:

   In the fuel project, we recently ran into a couple of issues with 
Apache2 +
   mod_wsgi as we switched Keystone to run . Please see [1] and [2].

   Looking deep into Apache2 issues specifically around "apache2ctl 
graceful"
   and module loading/unloading and the hooks used by mod_wsgi [3]. I 
started
   wondering if Apache2 + mod_wsgi is the "right" solution and if there 
was
   something else better that people are already using.

   One data point that keeps coming up is, all the CI jobs use Apache2 +
   mod_wsgi so it must be the best solutionIs it? If not, what is?

   Disclaimer: it's been a while since I've cared about performance with a
   web server in front of a Python app.

   IIRC, mod_wsgi was abandoned for a while, but I think it's being worked
   on again. In general, I seem to remember it being thought of as a bit
   old and crusty, but mostly working.


   I am not aware of that.  It has been the workhorse of the Python/wsgi world
   for a while, and we use it heavily.


   At a previous job, we switched from Apache2 + mod_wsgi to nginx + 
uwsgi[0]
   and saw a significant performance increase. This was a Django app. uwsgi
   is fairly straightforward to operate and comes loaded with a myriad of
   options[1] to help folks make the most of it. I've played with Ironic
   behind uwsgi and it seemed to work fine, though I haven't done any sort
   of load testing. I'd encourage folks to give it a shot. :)


   Again, switching web servers is as likely to introduce as to solve
   problems.  If there are performance issues:

   1.  Idenitfy what causes them
   2.  Change configuration settings to deal with them
   3.  Fix upstream bugs in the underlying system.


   Keystone is not about performance.  Keystone is about security.  The cloud
   is designed to scale horizontally first.  Before advocating switching to a
   difference web server, make sure it supports the technologies required.


   1. TLS at the latest level
   2. Kerberos/GSSAPI/SPNEGO
   3. X509 Client cert validation
   4. SAML

   OpenID connect would be a good one to add to the list;  Its been requested
   for a while.

   If Keystone is having performance issues, it is most likely at the database
   layer, not the web server.



   "Programmers waste enormous amounts of time thinking about, or worrying
   about, the speed of noncritical parts of their programs, and these attempts
   at efficiency actually have a strong negative impact when debugging and
   maintenance are considered. We should forget about small efficiencies, say
   about 97% of the time: premature optimization is the root of all evil. Yet
   we should not pass up our opportunities in that critical 3%."   --Donald
   Knuth





   Of course, uwsgi can also be ran behind Apache2, if you'd prefer.

   gunicorn[2] is another good option that may be worth investigating; I
   personally don't have any experience with it, but I seem to remember
   hearing it has good eventlet support.

   // jim

   [0] https://uwsgi-docs.readthedocs.org/en/latest/
   [1] https://uwsgi-docs.readthedocs.org/en/latest/Options.html
   [2] http://gunicorn.org/

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

Re: [openstack-dev] [openstack-ansible] To NTP, or not to NTP, that is the question

2015-09-18 Thread Ian Cordasco

On 9/18/15, 08:03, "Major Hayden"  wrote:

>Hey there,
>
>I start working on a bug[1] last night about adding a managed NTP
>configuration to openstack-ansible hosts.  My patch[2] gets chrony up and
>running with configurable NTP servers, but I'm still struggling to meet
>the "Proposal" section of the bug where the author has asked for
>non-infra physical nodes to get their time from the infra nodes.  I can't
>figure out how to make it work for AIO builds when one physical host is
>part of all of the groups. ;)
>
>I'd argue that time synchronization is critical for a few areas:
>
>  1) Security/auditing when comparing logs
>  2) Troubleshooting when comparing logs
>  3) I've been told swift is time-sensitive
>  4) MySQL/Galera don't like time drift
>
>However, there's a strong argument that this should be done by deployers,
>and not via openstack-ansible.  I'm still *very* new to the project and
>I'd like to hear some feedback from other folks.

Personally, I fall into the camp of "this is a deployer concern".
Specifically, there is already an ansible-galaxy role to enable NTP on
your deployment hosts (https://galaxy.ansible.com/list#/roles/464) which
*could* be expanded to do this very work that you're talking about. Using
specialized roles to achieve this (and contributing back to the larger
ansible community) seems like a bigger win than trying to reimplement some
of this in OSA instead of reusing other roles that already exist.

Compare it to a hypothetical situation where Keystone wrote its own
backing libraries to implement Fernet instead of using the cryptography
library. In that case there would be absolutely no argument that Keystone
should use cryptography (even if it uses cffi and has bindings to OpenSSL
which our infra team doesn't like and some deployers find difficult to
manage when using pure-python deployment tooling). Why should OSA be any
different from another OpenStack project?

Cheers,
Ian

__
OpenStack Development Mailing 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][i18n] Is there any point in using _() inpython-novaclient?

2015-09-18 Thread Andreas Jaeger

With the limited resources that the translation team has, we should not 
translate the clients but concentrate on the openstackclient, as 
discussed here:


http://lists.openstack.org/pipermail/openstack-i18n/2015-September/001402.html

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


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

Re: [openstack-dev] [cinder] LVM snapshot performance issue -- why isn't thin provisioning the default?

2015-09-18 Thread Chris Friesen


On 09/18/2015 06:57 AM, Eric Harney wrote:

On 09/17/2015 06:06 PM, John Griffith wrote:



Having the "global conf" settings intermixed with the backend sections
caused a number of issues when we first started working on this.  That's
part of why we require the "self.configuration" usage all over in the
drivers.  Each driver instantiation is it's own independent entity.



Yes, each driver instantiation is independent, but that would still be
the case if these settings inherited values set in [DEFAULT] when they
aren't set in the backend section.


Agreed.  If I explicitly set something in the [DEFAULT] section, that should 
carry through and apply to all the backends unless overridden in the 
backend-specific section.


Chris

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

Re: [openstack-dev] Apache2 vs uWSGI vs ...

2015-09-18 Thread Alexander Makarov

Please consider that we use some apache mods - does
nginx/uwsgi/gunicorn have oauth, shibboleth & openid support?

On Fri, Sep 18, 2015 at 4:54 PM, Vladimir Kuklin  wrote:
> Folks
>
> I think we do not need to switch to nginx-only or consider any kind of war
> between nginx and apache adherents. Everyone should be able to use
> web-server he or she needs without being pinned to the unwanted one. It is
> like Postgres vs MySQL war. Why not support both?
>
> May be someone does not need something that apache supports and nginx not
> and needs nginx features which apache does not support. Let's let our users
> decide what they want.
>
> And the first step should be simple here - support for uwsgi. It will allow
> for usage of any web-server that can work with uwsgi. It will allow also us
> to check for the support of all apache-like bindings like SPNEGO or whatever
> and provide our users with enough info on making decisions. I did not
> personally test nginx modules for SAML and SPNEGO, but I am pretty confident
> about TLS/SSL parts of nginx.
>
> Moreover, nginx will allow you to do things you cannot do with apache, e.g.
> do smart load balancing, which may be crucial for high-loaded installations.
>
>
> On Fri, Sep 18, 2015 at 4:12 PM, Adam Young  wrote:
>>
>> On 09/17/2015 10:04 PM, Jim Rollenhagen wrote:
>>
>> On Thu, Sep 17, 2015 at 06:48:50PM -0400, Davanum Srinivas wrote:
>>
>> In the fuel project, we recently ran into a couple of issues with Apache2
>> +
>> mod_wsgi as we switched Keystone to run . Please see [1] and [2].
>>
>> Looking deep into Apache2 issues specifically around "apache2ctl graceful"
>> and module loading/unloading and the hooks used by mod_wsgi [3]. I started
>> wondering if Apache2 + mod_wsgi is the "right" solution and if there was
>> something else better that people are already using.
>>
>> One data point that keeps coming up is, all the CI jobs use Apache2 +
>> mod_wsgi so it must be the best solutionIs it? If not, what is?
>>
>> Disclaimer: it's been a while since I've cared about performance with a
>> web server in front of a Python app.
>>
>> IIRC, mod_wsgi was abandoned for a while, but I think it's being worked
>> on again. In general, I seem to remember it being thought of as a bit
>> old and crusty, but mostly working.
>>
>>
>> I am not aware of that.  It has been the workhorse of the Python/wsgi
>> world for a while, and we use it heavily.
>>
>> At a previous job, we switched from Apache2 + mod_wsgi to nginx + uwsgi[0]
>> and saw a significant performance increase. This was a Django app. uwsgi
>> is fairly straightforward to operate and comes loaded with a myriad of
>> options[1] to help folks make the most of it. I've played with Ironic
>> behind uwsgi and it seemed to work fine, though I haven't done any sort
>> of load testing. I'd encourage folks to give it a shot. :)
>>
>>
>> Again, switching web servers is as likely to introduce as to solve
>> problems.  If there are performance issues:
>>
>> 1.  Idenitfy what causes them
>> 2.  Change configuration settings to deal with them
>> 3.  Fix upstream bugs in the underlying system.
>>
>>
>> Keystone is not about performance.  Keystone is about security.  The cloud
>> is designed to scale horizontally first.  Before advocating switching to a
>> difference web server, make sure it supports the technologies required.
>>
>>
>> 1. TLS at the latest level
>> 2. Kerberos/GSSAPI/SPNEGO
>> 3. X509 Client cert validation
>> 4. SAML
>>
>> OpenID connect would be a good one to add to the list;  Its been requested
>> for a while.
>>
>> If Keystone is having performance issues, it is most likely at the
>> database layer, not the web server.
>>
>>
>>
>> "Programmers waste enormous amounts of time thinking about, or worrying
>> about, the speed of noncritical parts of their programs, and these attempts
>> at efficiency actually have a strong negative impact when debugging and
>> maintenance are considered. We should forget about small efficiencies, say
>> about 97% of the time: premature optimization is the root of all evil. Yet
>> we should not pass up our opportunities in that critical 3%."   --Donald
>> Knuth
>>
>>
>>
>> Of course, uwsgi can also be ran behind Apache2, if you'd prefer.
>>
>> gunicorn[2] is another good option that may be worth investigating; I
>> personally don't have any experience with it, but I seem to remember
>> hearing it has good eventlet support.
>>
>> // jim
>>
>> [0] https://uwsgi-docs.readthedocs.org/en/latest/
>> [1] https://uwsgi-docs.readthedocs.org/en/latest/Options.html
>> [2] http://gunicorn.org/
>>
>> __
>> OpenStack Development Mailing 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] Apache2 vs uWSGI vs ...

2015-09-18 Thread Boris Bobrov

There are 2 dimensions this discussion should happen in: web server and 
application server. Now we use apache2 as web server and mod_wsgi as app 
server.

I don't have a specific opinion on the app server (mod_wsgi vs uwsgi) and I 
don't really care.

Regarding apache2 vs nginx. I don't see any reasons for the switch. Apache2 is 
well known to deployers and sysadmins. It is very rich for modules. I wonder 
if there are customer-written modules.

On Friday 18 September 2015 16:54:02 Vladimir Kuklin wrote:
> Folks
> 
> I think we do not need to switch to nginx-only or consider any kind of war
> between nginx and apache adherents. Everyone should be able to use
> web-server he or she needs without being pinned to the unwanted one. It is
> like Postgres vs MySQL war. Why not support both?

Why nginx? Why not lighttpd? OpenLitespeed? Litespeed? ?

What do you understand by "support both"? I understand it as "both are tested 
in devstack". Apache2 is supported because you can set up devstack and 
everything works.

There are things in keystone that work under apache. They are not tested. They 
were written to work under apache because it's the simplest and the most 
standard way to do. Making them work in nginx means forcing developers write 
some code. You're ready to do that?

> May be someone does not need something that apache supports and nginx not
> and needs nginx features which apache does not support. Let's let our users
> decide what they want.
> 
> And the first step should be simple here - support for uwsgi.

Why uwsgi? Why not gunicorn? Cherrypy? Twisted?

> It will allow
> for usage of any web-server that can work with uwsgi. It will allow also us
> to check for the support of all apache-like bindings like SPNEGO or
> whatever and provide our users with enough info on making decisions. I did
> not personally test nginx modules for SAML and SPNEGO, but I am pretty
> confident about TLS/SSL parts of nginx.
> 
> Moreover, nginx will allow you to do things you cannot do with apache, e.g.
> do smart load balancing, which may be crucial for high-loaded installations.
> On Fri, Sep 18, 2015 at 4:12 PM, Adam Young  wrote:
> > On 09/17/2015 10:04 PM, Jim Rollenhagen wrote:
> > 
> > On Thu, Sep 17, 2015 at 06:48:50PM -0400, Davanum Srinivas wrote:
> > 
> > In the fuel project, we recently ran into a couple of issues with Apache2
> > +
> > mod_wsgi as we switched Keystone to run . Please see [1] and [2].
> > 
> > Looking deep into Apache2 issues specifically around "apache2ctl graceful"
> > and module loading/unloading and the hooks used by mod_wsgi [3]. I started
> > wondering if Apache2 + mod_wsgi is the "right" solution and if there was
> > something else better that people are already using.
> > 
> > One data point that keeps coming up is, all the CI jobs use Apache2 +
> > mod_wsgi so it must be the best solutionIs it? If not, what is?
> > 
> > Disclaimer: it's been a while since I've cared about performance with a
> > web server in front of a Python app.
> > 
> > IIRC, mod_wsgi was abandoned for a while, but I think it's being worked
> > on again. In general, I seem to remember it being thought of as a bit
> > old and crusty, but mostly working.
> > 
> > 
> > I am not aware of that.  It has been the workhorse of the Python/wsgi
> > world for a while, and we use it heavily.
> > 
> > 
> > At a previous job, we switched from Apache2 + mod_wsgi to nginx + uwsgi[0]
> > and saw a significant performance increase. This was a Django app. uwsgi
> > is fairly straightforward to operate and comes loaded with a myriad of
> > options[1] to help folks make the most of it. I've played with Ironic
> > behind uwsgi and it seemed to work fine, though I haven't done any sort
> > of load testing. I'd encourage folks to give it a shot. :)
> > 
> > 
> > Again, switching web servers is as likely to introduce as to solve
> > problems.  If there are performance issues:
> > 
> > 1.  Idenitfy what causes them
> > 2.  Change configuration settings to deal with them
> > 3.  Fix upstream bugs in the underlying system.
> > 
> > 
> > Keystone is not about performance.  Keystone is about security.  The cloud
> > is designed to scale horizontally first.  Before advocating switching to a
> > difference web server, make sure it supports the technologies required.
> > 
> > 
> > 1. TLS at the latest level
> > 2. Kerberos/GSSAPI/SPNEGO
> > 3. X509 Client cert validation
> > 4. SAML
> > 
> > OpenID connect would be a good one to add to the list;  Its been requested
> > for a while.
> > 
> > If Keystone is having performance issues, it is most likely at the
> > database layer, not the web server.
> > 
> > 
> > 
> > "Programmers waste enormous amounts of time thinking about, or worrying
> > about, the speed of noncritical parts of their programs, and these
> > attempts
> > at efficiency actually have a strong negative impact when debugging and
> > maintenance are considered. We *should* forget about small efficiencies,
>

[openstack-dev] [openstack-ansible] To NTP, or not to NTP, that is the question

2015-09-18 Thread Major Hayden

Hey there,

I start working on a bug[1] last night about adding a managed NTP configuration 
to openstack-ansible hosts.  My patch[2] gets chrony up and running with 
configurable NTP servers, but I'm still struggling to meet the "Proposal" 
section of the bug where the author has asked for non-infra physical nodes to 
get their time from the infra nodes.  I can't figure out how to make it work 
for AIO builds when one physical host is part of all of the groups. ;)

I'd argue that time synchronization is critical for a few areas:

  1) Security/auditing when comparing logs
  2) Troubleshooting when comparing logs
  3) I've been told swift is time-sensitive
  4) MySQL/Galera don't like time drift

However, there's a strong argument that this should be done by deployers, and 
not via openstack-ansible.  I'm still *very* new to the project and I'd like to 
hear some feedback from other folks.

[1] https://bugs.launchpad.net/openstack-ansible/+bug/1413018
[2] https://review.openstack.org/#/c/225006/

--
Major Hayden

__
OpenStack Development Mailing 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] Apache2 vs uWSGI vs ...

2015-09-18 Thread Vladimir Kuklin

Folks

I think we do not need to switch to nginx-only or consider any kind of war
between nginx and apache adherents. Everyone should be able to use
web-server he or she needs without being pinned to the unwanted one. It is
like Postgres vs MySQL war. Why not support both?

May be someone does not need something that apache supports and nginx not
and needs nginx features which apache does not support. Let's let our users
decide what they want.

And the first step should be simple here - support for uwsgi. It will allow
for usage of any web-server that can work with uwsgi. It will allow also us
to check for the support of all apache-like bindings like SPNEGO or
whatever and provide our users with enough info on making decisions. I did
not personally test nginx modules for SAML and SPNEGO, but I am pretty
confident about TLS/SSL parts of nginx.

Moreover, nginx will allow you to do things you cannot do with apache, e.g.
do smart load balancing, which may be crucial for high-loaded installations.


On Fri, Sep 18, 2015 at 4:12 PM, Adam Young  wrote:

> On 09/17/2015 10:04 PM, Jim Rollenhagen wrote:
>
> On Thu, Sep 17, 2015 at 06:48:50PM -0400, Davanum Srinivas wrote:
>
> In the fuel project, we recently ran into a couple of issues with Apache2 +
> mod_wsgi as we switched Keystone to run . Please see [1] and [2].
>
> Looking deep into Apache2 issues specifically around "apache2ctl graceful"
> and module loading/unloading and the hooks used by mod_wsgi [3]. I started
> wondering if Apache2 + mod_wsgi is the "right" solution and if there was
> something else better that people are already using.
>
> One data point that keeps coming up is, all the CI jobs use Apache2 +
> mod_wsgi so it must be the best solutionIs it? If not, what is?
>
> Disclaimer: it's been a while since I've cared about performance with a
> web server in front of a Python app.
>
> IIRC, mod_wsgi was abandoned for a while, but I think it's being worked
> on again. In general, I seem to remember it being thought of as a bit
> old and crusty, but mostly working.
>
>
> I am not aware of that.  It has been the workhorse of the Python/wsgi
> world for a while, and we use it heavily.
>
>
> At a previous job, we switched from Apache2 + mod_wsgi to nginx + uwsgi[0]
> and saw a significant performance increase. This was a Django app. uwsgi
> is fairly straightforward to operate and comes loaded with a myriad of
> options[1] to help folks make the most of it. I've played with Ironic
> behind uwsgi and it seemed to work fine, though I haven't done any sort
> of load testing. I'd encourage folks to give it a shot. :)
>
>
> Again, switching web servers is as likely to introduce as to solve
> problems.  If there are performance issues:
>
> 1.  Idenitfy what causes them
> 2.  Change configuration settings to deal with them
> 3.  Fix upstream bugs in the underlying system.
>
>
> Keystone is not about performance.  Keystone is about security.  The cloud
> is designed to scale horizontally first.  Before advocating switching to a
> difference web server, make sure it supports the technologies required.
>
>
> 1. TLS at the latest level
> 2. Kerberos/GSSAPI/SPNEGO
> 3. X509 Client cert validation
> 4. SAML
>
> OpenID connect would be a good one to add to the list;  Its been requested
> for a while.
>
> If Keystone is having performance issues, it is most likely at the
> database layer, not the web server.
>
>
>
> "Programmers waste enormous amounts of time thinking about, or worrying
> about, the speed of noncritical parts of their programs, and these attempts
> at efficiency actually have a strong negative impact when debugging and
> maintenance are considered. We *should* forget about small efficiencies,
> say about 97% of the time: *premature optimization is the root of all
> evil.* Yet we should not pass up our opportunities in that critical
> 3%."   --Donald Knuth
>
>
>
>
> Of course, uwsgi can also be ran behind Apache2, if you'd prefer.
>
> gunicorn[2] is another good option that may be worth investigating; I
> personally don't have any experience with it, but I seem to remember
> hearing it has good eventlet support.
>
> // jim
>
> [0] https://uwsgi-docs.readthedocs.org/en/latest/
> [1] https://uwsgi-docs.readthedocs.org/en/latest/Options.html
> [2] http://gunicorn.org/
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://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
>
>


-- 
Yours Faithfully,
Vladimir Kuklin,
Fuel Library Tech Lead,
Mirantis, Inc.
+7 (495)

Re: [openstack-dev] [cinder] LVM snapshot performance issue -- why isn't thin provisioning the default?

2015-09-18 Thread Eric Harney

On 09/17/2015 06:06 PM, John Griffith wrote:
> On Thu, Sep 17, 2015 at 11:31 AM, Eric Harney  wrote:
> 
>> On 09/17/2015 05:00 AM, Duncan Thomas wrote:
>>> On 16 September 2015 at 23:43, Eric Harney  wrote:
>>>
 Currently, at least some options set in [DEFAULT] don't apply to
 per-driver sections, and require you to set them in the driver section
 as well.

>>>
>>> This is extremely confusing behaviour. Do you have any examples? I'm not
>>> sure if we can fix it without breaking people's existing configs but I
>>> think it is worth trying. I'll add it to the list of things to talk about
>>> briefly in Tokyo.
>>>
>>
>> The most recent place this bit me was with iscsi_helper.
>>
>> If cinder.conf has:
>>
>> [DEFAULT]
>> iscsi_helper = lioadm
>> enabled_backends = lvm1
>>
>> [lvm1]
>> volume_driver = ...LVMISCSIDriver
>> # no iscsi_helper setting
>>
>>
>> You end up with c-vol showing "iscsi_helper = lioadm", and
>> "lvm1.iscsi_helper = tgtadm", which is the default in the code, and not
>> the default in the configuration file.
>>
>> I agree that this is confusing, I think it's also blatantly wrong.  I'm
>> not sure how to fix it, but I think it's some combination of your
>> suggestions above and possibly having to introduce new option names.
>>
> 
> I'm not sure why that's "blatantly wrong', this is a side effect of having
> multiple backends enabled, it's by design really.  Any option that is
> defined in driver.py needs to be set in the actual enabled-backend stanza
> IIRC.  This includes iscsi_helper, volume_clear etc.
> 

I think it's wrong because it's not predictable for someone configuring
Cinder.  I understand that this is a side effect of multi-backend, but
I'm not sure what the reasoning is if it's intentional design.  I think
most people would expect a setting set in a [DEFAULT] section to be
treated as a default rather than being ignored.

This is particularly odd in the case of "iscsi_helper", where I want to
ship packages configured to use LIO since tgt doesn't exist on the
platform, and is never the right value for my packages.

This isn't possible without patching the code directly, which seems like
a shortfall in our configuration system.

> Having the "global conf" settings intermixed with the backend sections
> caused a number of issues when we first started working on this.  That's
> part of why we require the "self.configuration" usage all over in the
> drivers.  Each driver instantiation is it's own independent entity.
> 

Yes, each driver instantiation is independent, but that would still be
the case if these settings inherited values set in [DEFAULT] when they
aren't set in the backend section.

> I haven't looked at this for a long time, but if something has changed or
> I'm missing something my apologies.  We can certainly consider changing it,
> but because of the way we do multi-backend I'm not exactly sure how you
> would do this, or honestly why you would want to.
> 
> John
> 


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

Re: [openstack-dev] Apache2 vs uWSGI vs ...

2015-09-18 Thread Morgan Fainberg

There is and has been desire to support uWSGI and other alternatives to 
mod_wsgi. There are a variety of operational reasons to consider uWSGI and/or 
gunicorn behind apache most notably to facilitate easier management of the 
processes independently of the webserver itself. With mod_wsgi the processes 
are directly tied to the apache server where as with uWSGI and gunicorn you can 
manage the various services independently and/or with differing VENVs more 
easily. 

There are potential other concerns that must be weighed when considering which 
method of deployment to use. I hope we have clear documentation within the next 
cycle (and possible choices for the gate) for utilizing uWSGI and/or gunicorn. 

--Morgan

Sent via mobile

> On Sep 18, 2015, at 06:12, Adam Young  wrote:
> 
>> On 09/17/2015 10:04 PM, Jim Rollenhagen wrote:
>>> On Thu, Sep 17, 2015 at 06:48:50PM -0400, Davanum Srinivas wrote:
>>> In the fuel project, we recently ran into a couple of issues with Apache2 +
>>> mod_wsgi as we switched Keystone to run . Please see [1] and [2].
>>> 
>>> Looking deep into Apache2 issues specifically around "apache2ctl graceful"
>>> and module loading/unloading and the hooks used by mod_wsgi [3]. I started
>>> wondering if Apache2 + mod_wsgi is the "right" solution and if there was
>>> something else better that people are already using.
>>> 
>>> One data point that keeps coming up is, all the CI jobs use Apache2 +
>>> mod_wsgi so it must be the best solutionIs it? If not, what is?
>> Disclaimer: it's been a while since I've cared about performance with a
>> web server in front of a Python app.
>> 
>> IIRC, mod_wsgi was abandoned for a while, but I think it's being worked
>> on again. In general, I seem to remember it being thought of as a bit
>> old and crusty, but mostly working.
> 
> I am not aware of that.  It has been the workhorse of the Python/wsgi world 
> for a while, and we use it heavily.
> 
>> At a previous job, we switched from Apache2 + mod_wsgi to nginx + uwsgi[0]
>> and saw a significant performance increase. This was a Django app. uwsgi
>> is fairly straightforward to operate and comes loaded with a myriad of
>> options[1] to help folks make the most of it. I've played with Ironic
>> behind uwsgi and it seemed to work fine, though I haven't done any sort
>> of load testing. I'd encourage folks to give it a shot. :)
> 
> Again, switching web servers is as likely to introduce as to solve problems.  
> If there are performance issues:
> 
> 1.  Idenitfy what causes them
> 2.  Change configuration settings to deal with them
> 3.  Fix upstream bugs in the underlying system.
> 
> 
> Keystone is not about performance.  Keystone is about security.  The cloud is 
> designed to scale horizontally first.  Before advocating switching to a 
> difference web server, make sure it supports the technologies required.
> 
> 
> 1. TLS at the latest level
> 2. Kerberos/GSSAPI/SPNEGO
> 3. X509 Client cert validation
> 4. SAML
> 
> OpenID connect would be a good one to add to the list;  Its been requested 
> for a while.
> 
> If Keystone is having performance issues, it is most likely at the database 
> layer, not the web server.
> 
> 
> 
> "Programmers waste enormous amounts of time thinking about, or worrying 
> about, the speed of noncritical parts of their programs, and these attempts 
> at efficiency actually have a strong negative impact when debugging and 
> maintenance are considered. We should forget about small efficiencies, say 
> about 97% of the time: premature optimization is the root of all evil. Yet we 
> should not pass up our opportunities in that critical 3%."   --Donald Knuth
>  
> 
> 
>> Of course, uwsgi can also be ran behind Apache2, if you'd prefer.
>> 
>> gunicorn[2] is another good option that may be worth investigating; I
>> personally don't have any experience with it, but I seem to remember
>> hearing it has good eventlet support.
>> 
>> // jim
>> 
>> [0] https://uwsgi-docs.readthedocs.org/en/latest/
>> [1] https://uwsgi-docs.readthedocs.org/en/latest/Options.html
>> [2] http://gunicorn.org/
>> 
>> __
>> OpenStack Development Mailing 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] [Barbican] Providing service user read access to all tenant's certificates

2015-09-18 Thread Nathan Reller

> But that approach looks a little untidy, because tenant admin has to do
some infrastructure work.

I would think infrastructure work would be part of the admin role. They are
doing other things such as creating LBaaS, which seems like an
infrastructure job to me. I would think configuring LBaaS and key
management are similar. It seems like you think they are not similar. Can
you explain more?

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

[openstack-dev] [mistral] Define better terms for WAITING and DELAYED states

Hello,

We have a bug [1] that addresses the small semantical issue in names of the
states for workflow and task executions: WAITING and DELAYED.
I’m really interested in your opinion about this. Especially native english
speakers’ opinion because, IMO, they would be able to challenge better what
we’re discussing.

Problem description

We now have a set of states:
IDLE - Nothing is going on, object was just created
RUNNING - Workflow/task is running
PAUSED - Workflow/task has been paused
SUCCESS - Workflow/task has completed successfully
ERROR - Workflow/task has completed with an error
WAITING - Task execution object has been created but it is not ready to start
because some preconditions were not met. For now it mostly refers to a case
when we have a ‘join’ task depending on a number of other tasks, e.g. ‘task1’
depends on ‘task2’ and ‘task3’. But say ‘task2’ has completed and ‘task3’ has
not and hence ‘task1’ has to wait. I may assume that in the future it may be
related not only to joins.
DELAYED - Task has been delayed for a certain number of seconds. I may happen,
for example, in case of using ‘retry’ policy.

So the semantical difference between WAITING and DELAYED is the following:
Unlike WAITING, DELAYED says that we know exactly that the task will run, it’s
just a matter of time. In case of WAITING, it may never run just because some
of the preconditions may never be met.

And the concern is that we probably don’t use good names for WAITING and
DELAYED because, from English language perspective, they look similar to a
number of folks (including myself) and it’s therefore confusing if we look at
two tasks with states WAITING and DELAYED.

The latest idea that we had is just to rename DELAYED to POSTPONED because the
latter sort of expresses the fact of being postponed for a certain period of
time slightly better :) But I’m really not sure.

Would appreciate your input on this.

Thanks

[1] https://bugs.launchpad.net/mistral/+bug/1470369

Renat Akhmerov
@ Mirantis Inc.

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

Re: [openstack-dev] Hardware requirements for OpenStack

2015-09-18 Thread Xiandong Meng

Yes, you should be able to install controller, neutron and compute node on
a single PC (all-in-one).
If you google it, you will find many practical guide on how to do it.
Here is one example :
https://fosskb.wordpress.com/2015/04/18/installing-openstack-kilo-on-ubuntu-15-04-single-machine-setup/



Regards,

Xiandong Meng 
mengxiand...@gmail.com

On Fri, Sep 18, 2015 at 5:21 AM, Haider Ali  wrote:

> Hello
>
> I am new to OpenStack and following
> http://docs.openstack.org/juno/install-guide/install/apt/content/ch_basic_environment.html
> guide to install OpenStack on my local PC. My question is do i need
> separate machines Controller, Network and Compute node ( connected via LAN
> ) or i can install all these 3 nodes on a single PC as well.
>
> Thanks
>
> --
> Haider Ali
> National University of Computer and Emerging Sciences Lahore
>
> __
> OpenStack Development Mailing 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] Apache2 vs uWSGI vs ...

2015-09-18 Thread Adam Young


On 09/17/2015 10:04 PM, Jim Rollenhagen wrote:

On Thu, Sep 17, 2015 at 06:48:50PM -0400, Davanum Srinivas wrote:

In the fuel project, we recently ran into a couple of issues with Apache2 +
mod_wsgi as we switched Keystone to run . Please see [1] and [2].

Looking deep into Apache2 issues specifically around "apache2ctl graceful"
and module loading/unloading and the hooks used by mod_wsgi [3]. I started
wondering if Apache2 + mod_wsgi is the "right" solution and if there was
something else better that people are already using.

One data point that keeps coming up is, all the CI jobs use Apache2 +
mod_wsgi so it must be the best solutionIs it? If not, what is?

Disclaimer: it's been a while since I've cared about performance with a
web server in front of a Python app.

IIRC, mod_wsgi was abandoned for a while, but I think it's being worked
on again. In general, I seem to remember it being thought of as a bit
old and crusty, but mostly working.


I am not aware of that.  It has been the workhorse of the Python/wsgi 
world for a while, and we use it heavily.




At a previous job, we switched from Apache2 + mod_wsgi to nginx + uwsgi[0]
and saw a significant performance increase. This was a Django app. uwsgi
is fairly straightforward to operate and comes loaded with a myriad of
options[1] to help folks make the most of it. I've played with Ironic
behind uwsgi and it seemed to work fine, though I haven't done any sort
of load testing. I'd encourage folks to give it a shot. :)


Again, switching web servers is as likely to introduce as to solve 
problems.  If there are performance issues:


1.  Idenitfy what causes them
2.  Change configuration settings to deal with them
3.  Fix upstream bugs in the underlying system.


Keystone is not about performance.  Keystone is about security.  The 
cloud is designed to scale horizontally first.  Before advocating 
switching to a difference web server, make sure it supports the 
technologies required.



1. TLS at the latest level
2. Kerberos/GSSAPI/SPNEGO
3. X509 Client cert validation
4. SAML

OpenID connect would be a good one to add to the list;  Its been 
requested for a while.


If Keystone is having performance issues, it is most likely at the 
database layer, not the web server.




"Programmers waste enormous amounts of time thinking about, or worrying 
about, the speed of noncritical parts of their programs, and these 
attempts at efficiency actually have a strong negative impact when 
debugging and maintenance are considered. We /should/ forget about small 
efficiencies, say about 97% of the time: *premature optimization is the 
root of all evil.* Yet we should not pass up our opportunities in that 
critical 3%." --Donald Knuth






Of course, uwsgi can also be ran behind Apache2, if you'd prefer.

gunicorn[2] is another good option that may be worth investigating; I
personally don't have any experience with it, but I seem to remember
hearing it has good eventlet support.

// jim

[0] https://uwsgi-docs.readthedocs.org/en/latest/
[1] https://uwsgi-docs.readthedocs.org/en/latest/Options.html
[2] http://gunicorn.org/

__
OpenStack Development Mailing 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-ansible] To NTP, or not to NTP, that is the question

2015-09-18 Thread Matthew Mosesohn

Major,

in Fuel, we've dealt with this problem for a long time in its varying
degrees of unpleasantness. Some virtualization platforms, such as
VirtualBox, are very prone to time drift. Hardware nodes, thankfully, don't
suffer so badly.

Time sync is very important for RabbitMQ, Corosync, and Ceph, in addition
to those items you mentioned above. I haven't seen swift itself break due
to time issues, but you may be right.

The most ideal situation is to point all hosts to public NTP pool servers.
Barring that, elect 1 host to base its time by its hardware clock, and then
direct all other hosts to sync time against that one host. This has major
issues when you're doing virtual deployments with snapshot/revert and
experiencing major time skew, so you may need extra VM management scripts
to manually sync time again after revert.

Best Regards,
Matthew Mosesohn

On Fri, Sep 18, 2015 at 4:03 PM, Major Hayden  wrote:

> Hey there,
>
> I start working on a bug[1] last night about adding a managed NTP
> configuration to openstack-ansible hosts.  My patch[2] gets chrony up and
> running with configurable NTP servers, but I'm still struggling to meet the
> "Proposal" section of the bug where the author has asked for non-infra
> physical nodes to get their time from the infra nodes.  I can't figure out
> how to make it work for AIO builds when one physical host is part of all of
> the groups. ;)
>
> I'd argue that time synchronization is critical for a few areas:
>
>   1) Security/auditing when comparing logs
>   2) Troubleshooting when comparing logs
>   3) I've been told swift is time-sensitive
>   4) MySQL/Galera don't like time drift
>
> However, there's a strong argument that this should be done by deployers,
> and not via openstack-ansible.  I'm still *very* new to the project and I'd
> like to hear some feedback from other folks.
>
> [1] https://bugs.launchpad.net/openstack-ansible/+bug/1413018
> [2] https://review.openstack.org/#/c/225006/
>
> --
> Major Hayden
>
> __
> OpenStack Development Mailing 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-ansible] To NTP, or not to NTP, that is the question

2015-09-18 Thread Jay Pipes


On 09/18/2015 11:04 AM, Ian Cordasco wrote:

On 9/18/15, 08:03, "Major Hayden"  wrote:


Hey there,

I start working on a bug[1] last night about adding a managed NTP
configuration to openstack-ansible hosts.  My patch[2] gets chrony up and
running with configurable NTP servers, but I'm still struggling to meet
the "Proposal" section of the bug where the author has asked for
non-infra physical nodes to get their time from the infra nodes.  I can't
figure out how to make it work for AIO builds when one physical host is
part of all of the groups. ;)

I'd argue that time synchronization is critical for a few areas:

  1) Security/auditing when comparing logs
  2) Troubleshooting when comparing logs
  3) I've been told swift is time-sensitive
  4) MySQL/Galera don't like time drift

However, there's a strong argument that this should be done by deployers,
and not via openstack-ansible.  I'm still *very* new to the project and
I'd like to hear some feedback from other folks.


Personally, I fall into the camp of "this is a deployer concern".
Specifically, there is already an ansible-galaxy role to enable NTP on
your deployment hosts (https://galaxy.ansible.com/list#/roles/464) which
*could* be expanded to do this very work that you're talking about. Using
specialized roles to achieve this (and contributing back to the larger
ansible community) seems like a bigger win than trying to reimplement some
of this in OSA instead of reusing other roles that already exist.

Compare it to a hypothetical situation where Keystone wrote its own
backing libraries to implement Fernet instead of using the cryptography
library. In that case there would be absolutely no argument that Keystone
should use cryptography (even if it uses cffi and has bindings to OpenSSL
which our infra team doesn't like and some deployers find difficult to
manage when using pure-python deployment tooling). Why should OSA be any
different from another OpenStack project?


Have to agree with Ian here. NTP, as Major wrote, is a critical piece of 
the deployment puzzle, but I don't think it's necessary to put anything 
in OSA specifically to configure NTP. As Ian wrote, better to contribute 
to upstream ansible-galaxy playbooks/roles that do this well.


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] Apache2 vs uWSGI vs ...

2015-09-18 Thread Yee, Guang

I am with Adam, I kinda doubt Apache cause performance issues for Keystone, 
especially since all we have are just simple REST APIs. For other services with 
specific needs, like large file streaming, there may be some arguments to pick 
one over the other. We haven’t had the need to use Apache for dynamic routing 
or proxying at deployment. I am sure there are better tools out there that can 
do the job.

Making Keystone web service independent is a fine goal. However, since Keystone 
is moving away from being an identity provider, federation and external auth 
will play a major part going forward. Some of them are depended on the Apache 
at the moment. We may have to refactor Keystone to isolate the authentication 
service from the rest, then figure out how to gate it with Apache. I don’t 
think that’s trivial work though.

At this point, I don’t know what we are really gaining by ripping out Apache, 
comparing to amount of work to make that happen.

Guang

From: Vladimir Kuklin [mailto:vkuk...@mirantis.com]
Sent: Friday, September 18, 2015 9:09 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] Apache2 vs uWSGI vs ...

Folks

I just suggested to untie keystone from wsgi and implement uwsgi support. And 
then let the user decide what he or she wants.

There is a plenty of auth modules for nginx also.

Nginx us much better as a proxy server and you know it.

Regarding mod wsgi and apache we already saw that it cannot handle simple 
restart. I think this is not in any way acceptable from operations point if 
view.
18 сент. 2015 г. 18:59 пользователь "Fox, Kevin M" 
> написал:
Part of the reason to use Apache though is the diverse set of authentication 
mechanisms it supports. Operators have the desire to plugin Keystone into their 
existing authentication systems and Apache tends to be easier to do that then 
others.

Thanks,
Kevin

From: Jim Rollenhagen [j...@jimrollenhagen.com]
Sent: Thursday, September 17, 2015 7:04 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] Apache2 vs uWSGI vs ...

On Thu, Sep 17, 2015 at 06:48:50PM -0400, Davanum Srinivas wrote:
> In the fuel project, we recently ran into a couple of issues with Apache2 +
> mod_wsgi as we switched Keystone to run . Please see [1] and [2].
>
> Looking deep into Apache2 issues specifically around "apache2ctl graceful"
> and module loading/unloading and the hooks used by mod_wsgi [3]. I started
> wondering if Apache2 + mod_wsgi is the "right" solution and if there was
> something else better that people are already using.
>
> One data point that keeps coming up is, all the CI jobs use Apache2 +
> mod_wsgi so it must be the best solutionIs it? If not, what is?

Disclaimer: it's been a while since I've cared about performance with a
web server in front of a Python app.

IIRC, mod_wsgi was abandoned for a while, but I think it's being worked
on again. In general, I seem to remember it being thought of as a bit
old and crusty, but mostly working.

At a previous job, we switched from Apache2 + mod_wsgi to nginx + uwsgi[0]
and saw a significant performance increase. This was a Django app. uwsgi
is fairly straightforward to operate and comes loaded with a myriad of
options[1] to help folks make the most of it. I've played with Ironic
behind uwsgi and it seemed to work fine, though I haven't done any sort
of load testing. I'd encourage folks to give it a shot. :)

Of course, uwsgi can also be ran behind Apache2, if you'd prefer.

gunicorn[2] is another good option that may be worth investigating; I
personally don't have any experience with it, but I seem to remember
hearing it has good eventlet support.

// jim

[0] https://uwsgi-docs.readthedocs.org/en/latest/
[1] https://uwsgi-docs.readthedocs.org/en/latest/Options.html
[2] http://gunicorn.org/

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

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

Re: [openstack-dev] [cinder] LVM snapshot performance issue -- why isn't thin provisioning the default?

On Fri, Sep 18, 2015 at 9:06 AM, Chris Friesen 
wrote:

> On 09/18/2015 06:57 AM, Eric Harney wrote:
>
>> On 09/17/2015 06:06 PM, John Griffith wrote:
>>
>
> Having the "global conf" settings intermixed with the backend sections
>>> caused a number of issues when we first started working on this.  That's
>>> part of why we require the "self.configuration" usage all over in the
>>> drivers.  Each driver instantiation is it's own independent entity.
>>>
>>>
>> Yes, each driver instantiation is independent, but that would still be
>> the case if these settings inherited values set in [DEFAULT] when they
>> aren't set in the backend section.
>>
>
> Agreed.  If I explicitly set something in the [DEFAULT] section, that
> should carry through and apply to all the backends unless overridden in the
> backend-specific section.
>
> Chris
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
Meh I don't know about the "have to modify the code", the config file works
you just need to add that line to your driver section and configure the
backend correctly.

Regardless, I see your point (but I still certainly don't agree that it's
"blatantly wrong").

Bottom line "yes", ideally in the case of drivers we would check
global/default setting, and then override it if something was provided in
the driver specific setting, or if the driver itself set a different
default.  That seems like the right way to be doing it anyway.  I've looked
at that a bit this morning, the issue is that currently we don't even pass
any of those higher level conf settings in to the drivers init methods
anywhere.  Need to figure out how to change that, then it should be a
relatively simple fix.

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

[openstack-dev] [all] Cross-project workshop session suggestions

2015-09-18 Thread Thierry Carrez

Hello everyone,

At the Mitaka Design Summit in Tokyo we'll have a cross-project
workshops track on the Tuesday, as usual. The Technical Committee is
responsible for coming up with an agenda there, but we are interested in
your suggestions.

To that effect, we revived an instance of the good old "odsreg" system
for everyone to propose suggestions at:

http://odsreg.openstack.org/

If you have an idea of a topic that we should cover on that track,
please push it there. Please indicate if you're available to moderate
the session in case it's accepted.

Regards,

-- 
Thierry Carrez (ttx)

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

[openstack-dev] [all][elections] PTL Voting is now open

Elections are underway and will remain open for you to cast your vote
until 13:00 UTC September 24, 2015

We are having elections for Cinder, Glance, Ironic, Keystone, Mistral,
Neutron and Oslo.

If you are a Foundation individual member and had a commit in one of the
program's projects[0] over the Kilo-Liberty timeframe (September 18,
2014 06:00 UTC to September 18, 2015 05:59 UTC) then you are eligible to
vote. You should find your email with a link to the Condorcet page to
cast your vote in the inbox of your gerrit preferred email[1].

What to do if you don't see the email and have a commit in at least one
of the programs having an election:
  * check the trash or spam folders of your gerrit Preferred Email
address, in case it went into trash or spam
  * wait a bit and check again, in case your email server is a bit slow
  * find the sha of at least one commit from the program project
repos[0] and email me and Tony[2] at the below email addresses. If
we can confirm that you are entitled to vote, we will add you to
the voters list for the appropriate election.

Our democratic process is important to the health of OpenStack, please
exercise your right to vote.

Candidate statements/platforms can be found linked to Candidate names on
the wiki[3].

Happy voting,
Tristan


[0] The list of the program projects eligible for electoral
status:https://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml?id=sept-2015-elections

[1] Sign into review.openstack.org:
Go to Settings > Contact Information.
Look at the email listed as your Preferred Email.
That is where the ballot has been sent.

[2] Tony's email: tony at bakeyournoodle dot com
Tristan's email: tristan dot cacqueray at enovance dot com

[3]
https://wiki.openstack.org/wiki/PTL_Elections_September_2015#Confirmed_candidates:



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] [Neutron] Separate floating IP pools?

2015-09-18 Thread Carl Baldwin

On Fri, Sep 18, 2015 at 4:55 AM, Clark, Robert Graham
 wrote:
> Is it possible to have separate floating-IP pools and grant a tenant access
> to only some of them?

It is possible to have multiple floating IP pools by creating multiple
external networks.  However, it is not currently possible to have
multiple pools on a single external network.  This is a modeling
limitation.  Also, it is not possible to do any kind of RBAC on
multiple pools.  Currently the semantics of floating ips are that all
tenants have access to them implicitly.  Essentially, marking a
network as external makes that network visible to any tenant wishing
to attach a router and allows them to also allocate floating IPs.

> Thought popped into my head while looking at the rbac-network spec here:
> https://review.openstack.org/#/c/132661/4/specs/liberty/rbac-networks.rst

This could be a possible future direction after this RBAC work is
completed and released.  However, there are no concrete plans around
this yet.

> Creating individual pools, allowing only some tenants access and having
> off-cloud network ACLs would get part way to satisfying the use cases that
> drive the above spec (I’m thinking of this as a more short term solution,
> certainly not a direct alternative).

Maybe you could tell us more about the use case you're after so that
we can understand the motivation behind it.  For example, are you
thinking about multiple pools on the same external network or
different external networks? Help us understand what you're trying to
enable and why.

> I’m sure this is answered elsewhere but I couldn’t find any direct
> information so I’m assuming no, it isn’t supported but I wonder how much
> effort would be required to make it work?
>
> -Rob
>
>
> __
> OpenStack Development Mailing 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] [rating] CloudKitty's future and Big tent application

2015-09-18 Thread Stephane Albert

Hi,

We've lacked communication on the mailing list regarding CloudKitty.
This mail is basically an interest check regarding CloudKitty and rating
for OpenStack.

During the Vancouver OpenStack Summit we talked to a lot of people about
CloudKitty and its purpose. Many people seemed interested, and willing
to try it. We've recently released version 0.4.1.

I'm pleased to announce that we'll apply for the big tent hoping that it
will help the project gets the visibility it deserves. And bring more
people into it at the same time.

If you want to be part of the project feel free to join #cloudkitty or
be part of the next meeting, Monday, Sept 21st on #openstack-meeting-3
at 14:00 UTC.
If you want to discuss some specific topics please add them to the
agenda: https://wiki.openstack.org/wiki/Meetings/CloudKittyMeeting

Cheers

__
OpenStack Development Mailing 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] Apache2 vs uWSGI vs ...

2015-09-18 Thread Vladimir Kuklin

Folks

I just suggested to untie keystone from wsgi and implement uwsgi support.
And then let the user decide what he or she wants.

There is a plenty of auth modules for nginx also.

Nginx us much better as a proxy server and you know it.

Regarding mod wsgi and apache we already saw that it cannot handle simple
restart. I think this is not in any way acceptable from operations point if
view.
18 сент. 2015 г. 18:59 пользователь "Fox, Kevin M" 
написал:

> Part of the reason to use Apache though is the diverse set of
> authentication mechanisms it supports. Operators have the desire to plugin
> Keystone into their existing authentication systems and Apache tends to be
> easier to do that then others.
>
> Thanks,
> Kevin
> 
> From: Jim Rollenhagen [j...@jimrollenhagen.com]
> Sent: Thursday, September 17, 2015 7:04 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] Apache2 vs uWSGI vs ...
>
> On Thu, Sep 17, 2015 at 06:48:50PM -0400, Davanum Srinivas wrote:
> > In the fuel project, we recently ran into a couple of issues with
> Apache2 +
> > mod_wsgi as we switched Keystone to run . Please see [1] and [2].
> >
> > Looking deep into Apache2 issues specifically around "apache2ctl
> graceful"
> > and module loading/unloading and the hooks used by mod_wsgi [3]. I
> started
> > wondering if Apache2 + mod_wsgi is the "right" solution and if there was
> > something else better that people are already using.
> >
> > One data point that keeps coming up is, all the CI jobs use Apache2 +
> > mod_wsgi so it must be the best solutionIs it? If not, what is?
>
> Disclaimer: it's been a while since I've cared about performance with a
> web server in front of a Python app.
>
> IIRC, mod_wsgi was abandoned for a while, but I think it's being worked
> on again. In general, I seem to remember it being thought of as a bit
> old and crusty, but mostly working.
>
> At a previous job, we switched from Apache2 + mod_wsgi to nginx + uwsgi[0]
> and saw a significant performance increase. This was a Django app. uwsgi
> is fairly straightforward to operate and comes loaded with a myriad of
> options[1] to help folks make the most of it. I've played with Ironic
> behind uwsgi and it seemed to work fine, though I haven't done any sort
> of load testing. I'd encourage folks to give it a shot. :)
>
> Of course, uwsgi can also be ran behind Apache2, if you'd prefer.
>
> gunicorn[2] is another good option that may be worth investigating; I
> personally don't have any experience with it, but I seem to remember
> hearing it has good eventlet support.
>
> // jim
>
> [0] https://uwsgi-docs.readthedocs.org/en/latest/
> [1] https://uwsgi-docs.readthedocs.org/en/latest/Options.html
> [2] http://gunicorn.org/
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] live migration in Mitaka

On 18 September 2015 at 16:23, Daniel P. Berrange  wrote:
> On Fri, Sep 18, 2015 at 11:53:05AM +, Murray, Paul (HP Cloud) wrote:
>> Hi All,
>>
>> There are various efforts going on around live migration at the moment:
>> fixing up CI, bug fixes, additions to cover more corner cases, proposals
>> for new operations
>>
>> Generally live migration could do with a little TLC (see: [1]), so I am
>> going to suggest we give some of that care in the next cycle.
>>
>> Please respond to this post if you have an interest in this and what you
>> would like to see done. Include anything you are already getting on with
>> so we get a clear picture. If there is enough interest I'll put this
>> together as a proposal for a work stream. Something along the lines of
>> "robustify live migration".
>
>
>
> Testing. Testing. Testing.

+1 for Testing

The "CI for reliable live-migration" thread was covering some of the
details on the multi-host CI options.

Thanks,
johnthetubaugy

__
OpenStack Development Mailing 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] Apache2 vs uWSGI vs ...

2015-09-18 Thread David Stanek

I thoughts below mention Keystone, but in reality I would apply the same
logic to any OpenStack service.

On Fri, Sep 18, 2015 at 10:32 AM, Boris Bobrov  wrote:

> There are 2 dimensions this discussion should happen in: web server and
> application server. Now we use apache2 as web server and mod_wsgi as app
> server.
>

This is exactly true and Keystone should be deployable in an WSGI compliant
application server. If it's not I would consider it a bug.

>
> I don't have a specific opinion on the app server (mod_wsgi vs uwsgi) and I
> don't really care.
>
> Regarding apache2 vs nginx. I don't see any reasons for the switch.
> Apache2 is
> well known to deployers and sysadmins. It is very rich for modules. I
> wonder
> if there are customer-written modules.
>

Keystone doesn't use or require Apache. We recommend that it is deployed
using Apache, but there is no requirement to do that if you don't need to
use any Apache modules. For example, at least one of my devstack nodes
happily runs Keystone's manage_all.

 [snip]

> There are things in keystone that work under apache. They are not tested.
> They
> were written to work under apache because it's the simplest and the most
> standard way to do. Making them work in nginx means forcing developers
> write
> some code. You're ready to do that?
>

This should only be true for optional features and currently require Apache
modules.

>
> > May be someone does not need something that apache supports and nginx not
> > and needs nginx features which apache does not support. Let's let our
> users
> > decide what they want.
> >
> > And the first step should be simple here - support for uwsgi.
>
> Why uwsgi? Why not gunicorn? Cherrypy? Twisted?
>

uwsgi and gunicorn should both work fine, as should any WSGI application
server. CherryPy and Twister are more framework than application server, so
I would not expect them to work.

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

Re: [openstack-dev] [nova] live migration in Mitaka

2015-09-18 Thread Daniel P. Berrange

On Fri, Sep 18, 2015 at 11:53:05AM +, Murray, Paul (HP Cloud) wrote:
> Hi All,
> 
> There are various efforts going on around live migration at the moment:
> fixing up CI, bug fixes, additions to cover more corner cases, proposals
> for new operations
> 
> Generally live migration could do with a little TLC (see: [1]), so I am
> going to suggest we give some of that care in the next cycle.
> 
> Please respond to this post if you have an interest in this and what you
> would like to see done. Include anything you are already getting on with
> so we get a clear picture. If there is enough interest I'll put this
> together as a proposal for a work stream. Something along the lines of
> "robustify live migration".

We merged some robustness improvements for migration during Liberty.
Specifically, with KVM we now track the progress of data transfer
and if it is not making forward progress during a set window of
time, we will abort the migration. This ensures you don't get a
migration that never ends. We also now have code which dynamically
increases the max permitted downtime during switchover, to try and
make it more likely to succeeed. We could do with getting feedback
on how well the various tunable settings work in practie for real
world deployments, to see if we need to change any defaults.

There was a proposal to nova to allow the 'pause' operation to be
invoked while migration was happening. This would turn a live
migration into a coma-migration, thereby ensuring it succeeds.
I cna't remember if this merged or not, as i can't find the review
offhand, but its important to have this ASAP IMHO, as when
evacuating VMs from a host admins need a knob to use to force
successful evacuation, even at the cost of pausing the guest
temporarily.

In libvirt upstream we now have the ability to filter what disks are
migrated during block migration. We need to leverage that new feature
to fix the long standing problems of block migration when non-local
images are attached - eg cinder volumes. We definitely want this
in Mitaka.

We should look at what we need to do to isolate the migration data
network from the main management network. Currently we live
migrate over whatever network is associated with the compute hosts
primary Hostname / IP address. This is not neccessarily the fastest
NIC on the host. We ought to be able to record an alternative
hostname / IP address against each compute host to indicate the
desired migration interface.

Libvirt/KVM have the ability to turn on compression for migration
which again improves the chances of convergance & thus success.
We would look at leveraging that.

QEMU has a crude "auto-converge" flag you can turn on, which limits
guest CPU execution time, in an attempt to slow down data dirtying
rate to again improve chance of successful convergance.

I'm working on enhancements to QEMU itself to support TLS encryption
for migration. This will enable openstack to have secure migration
datastream, without having to tunnel via libvirtd. This is useful
as tunneling via libvirtd doesn't work with block migration. It will
also be much faster than tunnelling. This probably might be merged
in QEMU before Mitaka cycle ends, but more likely it is Nxxx cycle

There is also work on post-copy migration in QEMU. Normally with
live migration, the guest doesn't start executing on the target
host until migration has transferred all data. There are many
workloads where that doesn't work, as the guest is dirtying data
too quickly, With post-copy you can start runing the guest on the
target at any time, and when it faults on a missing page that will
be pulled from the source host. This is slightly more fragile as
you risk loosing the guest entirely if the source host dies before
migration finally completes. It does guarantee that migration will
succeed no matter what workload is in the guest. This is probably
N cycle material.

Testing. Testing. Testing.

Lots more I can't think of right now

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

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

Re: [openstack-dev] [mistral] Define better terms for WAITING and DELAYED states

2015-09-18 Thread HADDLETON, Robert W (Bob)


Hi Renat:

[TL;DR] - maybe use multiple words in the state name to avoid confusion

I agree that there is a lot of overlap - WAITING and DELAYED and 
POSTPONED are all very similar.  The context is important when trying to 
decipher what the words means.


I would normally interpret WAITING as having a known condition:

* I'm WAITING for the baseball game to begin

DELAYED implies WAITING but adds the context that something was supposed 
to have started already, or has already started, is now blocked by 
something out of your control, and you may or may not know when it will 
start again:


* The (start of the) ballgame has been DELAYED (by rain) (until 2:00). 
(So I'm still WAITING for it to begin)


POSTPONED implies DELAYED, but adds that something was "scheduled" to 
start at a certain time and has been re-scheduled for a later time.  It 
may or may not have started already, and the later time may or may not 
be known:


* The ballgame has been POSTPONED (because of rain) (until tomorrow) (so 
the game has been DELAYED and I'm still WAITING for it to start)


So using any of the three words on their own without context or 
additional information will likely be confusing, or at least subject to 
different interpretations.


I would be reluctant to rename DELAYED to POSTPONED, because it raises 
more questions (until when?) than DELAYED without providing more answers.


I think what it comes down to is the need to provide more information in 
the state name than is possible with one English word:


WAITING_FOR_PRECONDITIONS
DELAYED_BY_RETRY

These provide more specific context to the state but the state 
transition table gets to be unmanageable when there is a state for 
everything.


If more Waiting/delayed states are added it in the future it might make 
sense to create them as sub-states of RUNNING, to keep the transitions 
manageable.


Hope this helps

Bob


On 9/18/2015 8:55 AM, Renat Akhmerov wrote:

Hello,

We have a bug [1] that addresses the small semantical issue in names of
the states for workflow and task executions: WAITING and DELAYED.
I’m really interested in your opinion about this. Especially native
english speakers’ opinion because, IMO, they would be able to challenge
better what we’re discussing.

*Problem description*
*
*
We now have a set of states:

  * IDLE  - Nothing is going on, object was just created
  * RUNNING - Workflow/task is running
  * PAUSED - Workflow/task has been paused
  * SUCCESS - Workflow/task has completed successfully
  * ERROR - Workflow/task has completed with an error
  * WAITING - Task execution object has been created but it is not ready
to start because some preconditions were not met. For now it mostly
refers to a case when we have a ‘join’ task depending on a number of
other tasks, e.g. ‘task1’ depends on ‘task2’ and ‘task3’. But say
‘task2’ has completed and ‘task3’ has not and hence ‘task1’ has to
wait. I may assume that in the future it may be related not only to
joins.
  * DELAYED - Task has been delayed for a certain number of seconds. I
may happen, for example, in case of using ‘retry’ policy.


So the semantical difference between WAITING and DELAYED is the
following: Unlike WAITING, DELAYED says that we know exactly that the
task will run, it’s just a matter of time. In case of WAITING, it may
never run just because some of the preconditions may never be met.

And the concern is that we probably don’t use good names for WAITING and
DELAYED because, from English language perspective, they look similar to
a number of folks (including myself) and it’s therefore confusing if we
look at two tasks with states WAITING and DELAYED.

The latest idea that we had is just to rename DELAYED to POSTPONED
because the latter sort of expresses the fact of being postponed for a
certain period of time slightly better :) But I’m really not sure.

Would appreciate your input on this.

Thanks

[1] https://bugs.launchpad.net/mistral/+bug/1470369

Renat Akhmerov
@ Mirantis Inc.





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



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

Re: [openstack-dev] [all] Consistent support for SSL termination proxies across all API services

2015-09-18 Thread Fox, Kevin M

+1

From: Mathieu Gagné [mga...@internap.com]
Sent: Thursday, September 17, 2015 5:38 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [all] Consistent support for SSL termination proxies 
across all API services

Hi,

While debugging LP bug #1491579 [1], we identified [2] an issue where an
API sitting being a proxy performing SSL termination would not generate
the right redirection. The protocol ends up being the wrong one (http
instead of https) and this could hang your request indefinitely if
tcp/80 is not opened and a firewall drops your connection.

I suggested [3] adding support for the X-Fowarded-Proto header, thinking
Nova didn't supported it yet. In fact, someone suggested setting the
public_endpoint config instead.

So today I stumbled across this review [4] which added the
secure_proxy_ssl_header config to Nova. It allows the API to detect SSL
termination based on the (suggested) header X-Forwarded-Proto just like
previously suggested.

I also found this bug report [5] (opened in 2014) which also happens to
complain about bad URLs when API is sitting behind a proxy.

Multiple projects applied patches to try to fix the issue (based on
Launchpad comments):

* Glance added public_endpoint config
* Cinder added public_endpoint config
* Heat added secure_proxy_ssl_header config (through
heat.api.openstack:sslmiddleware_filter)
* Nova added secure_proxy_ssl_header config
* Manila added secure_proxy_ssl_header config (through
oslo_middleware.ssl:SSLMiddleware.factory)
* Ironic added public_endpoint config
* Keystone added secure_proxy_ssl_header config (LP #1370022)

As you can see, there is a lot of inconsistency between projects. (there
is more but lets start with that one)

My wish is for a common and consistent way for *ALL* OpenStack APIs to
support the same solution for this common problem. Let me tell you (and
I guess I can speak for all operators), we will be very happy to have
ONE config to remember of and set for *ALL* OpenStack services.

How can we get the ball rolling so we can fix it together once and for
all in a timely fashion?

[1] https://bugs.launchpad.net/python-novaclient/+bug/1491579
[2] https://bugs.launchpad.net/python-novaclient/+bug/1491579/comments/15
[3] https://bugs.launchpad.net/python-novaclient/+bug/1491579/comments/17
[4] https://review.openstack.org/#/c/206479/
[5] https://bugs.launchpad.net/glance/+bug/1384379

--
Mathieu

__
OpenStack Development Mailing 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-i18n] [nova][i18n] Is there any point in using _() inpython-novaclient?