Re: [openstack-dev] [Fuel] Core Reviewers groups restructure

[Vladimir Kuklin]

+1


On Tue, Sep 22, 2015 at 2:17 AM, Mike Scherbakov 
wrote:

> Thanks guys.
> So for fuel-octane then there are no actions needed.
>
> For fuel-agent-core group [1], looks like we are already good (it doesn't
> have fuel-core group nested). But it would need to include fuel-infra group
> and remove Aleksandra Fedorova (she will be a part of fuel-infra group).
>
> python-fuel-client-core [2] is good as well (no nested fuel-core).
> However, there is another group python-fuelclient-release [3], which has to
> be eliminated, and main python-fuelclient-core would just have fuel-infra
> group included for maintenance purposes.
>
> [1] https://review.openstack.org/#/admin/groups/995,members
> [2] https://review.openstack.org/#/admin/groups/551,members
> [3] https://review.openstack.org/#/admin/groups/552,members
>
>
> On Mon, Sep 21, 2015 at 11:06 AM Oleg Gelbukh 
> wrote:
>
>> FYI, we have a separate core group for stackforge/fuel-octane repository
>> [1].
>>
>> I'm supporting the move to modularization of Fuel with cleaner separation
>> of authority and better defined interfaces. Thus, I'm +1 to such a change
>> as a part of that move.
>>
>> [1] https://review.openstack.org/#/admin/groups/1020,members
>>
>> --
>> Best regards,
>> Oleg Gelbukh
>>
>> On Sun, Sep 20, 2015 at 11:56 PM, Mike Scherbakov <
>> mscherba...@mirantis.com> wrote:
>>
>>> Hi all,
>>> as of my larger proposal on improvements to code review workflow [1], we
>>> need to have cores for repositories, not for the whole Fuel. It is the path
>>> we are taking for a while, and new core reviewers added to specific repos
>>> only. Now we need to complete this work.
>>>
>>> My proposal is:
>>>
>>>1. Get rid of one common fuel-core [2] group, members of which can
>>>merge code anywhere in Fuel. Some members of this group may cover a 
>>> couple
>>>of repositories, but can't really be cores in all repos.
>>>2. Extend existing groups, such as fuel-library [3], with members
>>>from fuel-core who are keeping up with large number of reviews / merges.
>>>This data can be queried at Stackalytics.
>>>3. Establish a new group "fuel-infra", and ensure that it's included
>>>into any other core group. This is for maintenance purposes, it is 
>>> expected
>>>to be used only in exceptional cases. Fuel Infra team will have to decide
>>>whom to include into this group.
>>>4. Ensure that fuel-plugin-* repos will not be affected by removal
>>>of fuel-core group.
>>>
>>> #2 needs specific details. Stackalytics can show active cores easily, we
>>> can look at people with *:
>>> http://stackalytics.com/report/contribution/fuel-web/180. This is for
>>> fuel-web, change the link for other repos accordingly. If people are added
>>> specifically to the particular group, leaving as is (some of them are no
>>> longer active. But let's clean them up separately from this group
>>> restructure process).
>>>
>>>- fuel-library-core [3] group will have following members: Bogdan
>>>D., Sergii G., Alex Schultz, Vladimir Kuklin, Alex Didenko.
>>>- fuel-web-core [4]: Sebastian K., Igor Kalnitsky, Alexey Kasatkin,
>>>Vitaly Kramskikh, Julia Aranovich, Evgeny Li, Dima Shulyak
>>>- fuel-astute-core [5]: Vladimir Sharshov, Evgeny Li
>>>- fuel-dev-tools-core [6]: Przemek Kaminski, Sebastian K.
>>>- fuel-devops-core [7]: Tatyana Leontovich, Andrey Sledzinsky,
>>>Nastya Urlapova
>>>- fuel-docs-core [8]: Irina Povolotskaya, Denis Klepikov, Evgeny
>>>Konstantinov, Olga Gusarenko
>>>- fuel-main-core [9]: Vladimir Kozhukalov, Roman Vyalov, Dmitry
>>>Pyzhov, Sergii Golovatyuk, Vladimir Kuklin, Igor Kalnitsky
>>>- fuel-nailgun-agent-core [10]: Vladimir Sharshov, V.Kozhukalov
>>>- fuel-ostf-core [11]: Tatyana Leontovich, Nastya Urlapova, Andrey
>>>Sledzinsky, Dmitry Shulyak
>>>- fuel-plugins-core [12]: Igor Kalnitsky, Evgeny Li, Alexey Kasatkin
>>>- fuel-qa-core [13]: Andrey Sledzinsky, Tatyana Leontovich, Nastya
>>>Urlapova
>>>- fuel-stats-core [14]: Alex Kislitsky, Alexey Kasatkin, Vitaly
>>>Kramskikh
>>>- fuel-tasklib-core [15]: Igor Kalnitsky, Dima Shulyak, Alexey
>>>Kasatkin (this project seems to be dead, let's consider to rip it off)
>>>- fuel-specs-core: there is no such a group at the moment. I propose
>>>to create one with following members, based on stackalytics data [16]:
>>>Vitaly Kramskikh, Bogdan Dobrelia, Evgeny Li, Sergii Golovatyuk, Vladimir
>>>Kuklin, Igor Kalnitsky, Alexey Kasatkin, Roman Vyalov, Dmitry Borodaenko,
>>>Mike Scherbakov, Dmitry Pyzhov. We would need to reconsider who can merge
>>>after Fuel PTL/Component Leads elections
>>>- fuel-octane-core: needs to be created. Members: Yury Taraday, Oleg
>>>Gelbukh, Ilya Kharin
>>>- fuel-mirror-core: needs to be created. Sergey Kulanov, Vitaly
>>>Parakhin
>>>- fuel-upgrade-core: needs to be created. 

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

[Sean Dague]

On 09/22/2015 05:30 PM, Mathieu Gagné wrote:
> On 2015-09-22 4:52 PM, Sean Dague wrote:
>> On 09/22/2015 03:16 PM, Mathieu Gagné wrote:
>>>
>>> The oslo_middleware.ssl middleware looks to offer little overhead and
>>> offer the maximum flexibility. I appreciate the wish to use the Keystone
>>> catalog but I don't feel this is the right answer.
>>>
>>> For example, if I deploy Bifrost without Keystone, I won't have a
>>> catalog to rely on and will still have the same lack of SSL termination
>>> proxy support.
>>>
>>> The simplest solution is often the right one.
>>
>> I do get there are specific edge cases here, but I don't think that in
>> the general case we should be pushing a mode where Keystone is optional.
>> It is a bedrock of our system.
>>
> 
> I understand that Keystone is "a bedrock of our system". This however
> does not make it THE solution when simpler proven existing ones exist. I
> fail to understand why other solutions can't be considered.
> 
> I opened a dialog with the community to express my concerns about the
> lack of universal support for SSL termination proxy so we can find a
> solution together which will cover ALL use cases.
> 
> I proposed using an existing solution (oslo_middleware.ssl) (that I
> didn't know of until now) which takes little to no time to implement and
> cover a lot of use cases and special edge cases.

Does that solution work in the HA Proxy case where there is one
terminating address for multiple backend servers? Because there is the
concern that this impacts not only the Location header, but the link
documents inside the responses which clients are expected to be able to
link.follow. This is an honest question, I don't know how the
oslo_middleware.ssl acts in these cases. And HA Proxy 1 to N mapping is
very common deployment model.

The dialog isn't over, this is still an exploration. Nothing's going to
happen in code right now, because everything is in deep freeze for the
RC spins, the release, and summit planning. But we do need all the cards
on the table about options and trade offs if we are going to get 20+
projects aligned on a thing.

> Operators encounters and *HAVE* to handle a lot of edge cases. We are
> trying *very hard* to open up a dialog with the developer community so
> they can be heard, understood and addressed by sharing our real world
> use cases.
> 
> In that specific case, my impression is that they unfortunately happens
> to not be a priority when evaluating solutions and will actually make my
> job harder. I'm sad to see we can't come with an agreement on that one.
> I feel like I failed to properly communicate my needs as an operator and
> make them understood to others.

Here is the parameter space we are playing with:

1. Are the "Location:" headers correct, or understood in a way that
clients will do the right thing:

a. when direct connected
b. when connected in a 1 to 1 SSL termination proxy
c. when connected in a 1 to N HA Proxy

2. Are the links provided in REST documents correct, or understood in a
way that libraries like requests / phantomjs can follow links natively:

a. when direct connected
b. when connected in a 1 to 1 SSL termination proxy
c. when connected in a 1 to N HA Proxy

3. Are the minority of services that have "operate without keystone" as
a design tenant able to function.

a. when direct connected
b. when connected in a 1 to 1 SSL termination proxy
c. when connected in a 1 to N HA proxy

Today {1,2,3}{a} are handled by services auto figuring out their URL.
That might mean that you jump across from internalURL to publicURL when
following links, because the addresses in the documents are what the
server believes it's URL is.

{1,2,3}{b,c} are handled by manually configuring each api daemon about
what it's URL should be. Recent experiences with a novaclient release
demonstrated that a lot of people aren't actually doing that.

The answer to 3,c seems like it's always going to be manual.

The X-Forwarded-* headers seem like they address {1,3}{b} fine. But the
implications on {1,2,3}{c} are unclear. It's also unclear how {2}{b}
functions in that model and if the clients will interpret that in all
scenarios even document links.

Upgrading the service catalog usage would address {1,2}{a,b,c}, but make
{3}{b} live in the land of manual configs.

We need to get the full map out here, and help fill in details of where
our holes are, which solutions plug which ones, and what set of
tradeoffs we're going to be working around in future releases. Once
we've got that, and our solution going forward, we can start banging the
drum to get all the projects headed in a direction here.

-Sean

-- 
Sean Dague
http://dague.net

__
OpenStack Development Mailing List (not for 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

[Thierry Carrez]

Tristan Cacqueray wrote:
> [...]
> There are 5 projects without candidates, so according to this
> resolution[1], the TC we'll have to appoint a new PTL for Barbican,
> MagnetoDB, Magnum, Murano and Security
> [...]

Following our policy[1], the Technical Committee decided[2] the
following for project teams without PTL candidates in the nomination
timeframe:

- Robert Clark was nominated PTL for the Security Team.

- Serg Melikyan was nominated PTL for the Murano Team.

- Douglas Mendizabal was nominated PTL for the Barbican Team.

- An election should be held for Magnum contributors to pick their PTL
between Adrian Otto and Hongbin Lu. It will be organized by election
officials at their earliest convenience.

- MagnetoDB being abandoned, no PTL was chosen. Instead, we decided to
fast-track the removal[3] of MagnetoDB from the official list of
OpenStack projects.

[1]
http://governance.openstack.org/resolutions/20141128-elections-process-for-leaderless-programs.html

[2] http://eavesdrop.openstack.org/meetings/tc/2015/tc.2015-09-22-20.01.html

[3] https://review.openstack.org/#/c/224743/

Regards,

-- 
Thierry Carrez (ttx)



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] [releases] semver and dependency changes

[Thierry Carrez]

Robert Collins wrote:
> On 23 September 2015 at 02:03, Thierry Carrez  wrote:
>> Robert Collins wrote:
>>> [...]
>>> So, one answer we can use is "The version impact of a requirements
>>> change is never less than the largest version change in the change."
>>> That is:
>>> nothing -> a requirement -> major version change
>>
>> That feels a bit too much. In a lot of cases, the added requirement will
>> be used in a new, backward-compatible feature (requiring y bump), or
>> will serve to remove code without changing functionality (requiring z
>> bump). I would think that the cases where a new requirement requires a x
>> bump are rare.
> 
> So the question is 'will requiring this new thing force any users of
> the library to upgrade past a major version of that new thing'. If its
> new to OpenStack, then the answer is clearly no, for users of the
> library within OpenStack, but we don't know about users outside of
> OpenStack'. I am entirely happy to concede that this should be case by
> case though.
> 
>>> 1.x.y -> 2.0.0 -> major version change
>>> 1.2.y -> 1.3.0 -> minor version change
>>> 1.2.3. -> 1.2.4 -> patch version change
>>
>> The last two sound like good rules of thumb.
> 
> What about the one you didn't comment on ? :)

Damn, you got me. Hmm... "it depends" ? I think we can't really have a
default rule for a major bump. Depending on how the library is used, it
could trigger anything. Defaulting to a major bump as a result sounds a
bit overkill.

-- 
Thierry Carrez (ttx)

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

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

[Paul Carlton]

On 23/09/15 14:11, Daniel P. Berrange wrote:

On Wed, Sep 23, 2015 at 01:48:17PM +0100, Paul Carlton wrote:


On 22/09/15 16:44, Daniel P. Berrange wrote:

On Tue, Sep 22, 2015 at 09:29:46AM -0600, Chris Friesen wrote:

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

It seems to me that the ideal solution would be to start doing pre-copy
migration, then if that doesn't converge with the specified downtime value
then maybe have the option to just cut over to the destination and do a
post-copy migration of the remaining data.

Yes, that is precisely what the QEMU developers working on this
featue suggest we should do. The lazy page faulting on the target
host has a performance hit on the guest, so you definitely need
to give a little time for pre-copy to start off with, and then
switch to post-copy once some benchmark is reached, or if progress
info shows the transfer is not making progress.

Regards,
Daniel

I'd be a bit concerned about automatically switching to the post copy
mode.  As Daniel commented perviously, if something goes wrong on the
source node the customer's instance could be lost.  Many cloud operators
will want to control the use of this mode.  As per my previous message
this could be something that could be set on or off by default but
provide a PUT operation on os-migration to update setting on for a
specific migration

NB, if you are concerned about the source host going down while
migration is still taking place, you will loose the VM even with
pre-copy mode too, since the VM will of course still be running
on the source.

The new failure scenario is essentially about the network
connection between the source & host guest - if the network
layer fails while post-copy is running, then you loose the
VM.

In some sense post-copy will reduce the window of failure,
because it should ensure that the VM migration completes
in a faster & finite amount of time. I think this is
probably particularly important for host evacuation so
the admin can guarantee to get all the VMs off a host in
a reasonable amount of time.

As such I don't think you need expose post-copy as a concept in the
API, but I could see a nova.conf value to say whether use of post-copy
was acceptable, so those who want to have stronger resilience against
network failure can turn off post-copy.

Regards,
Daniel


If the source node fails during a pre-copy migration then when that node
is restored the instance is ok again (usually).  With the post-copy
approach the risk is that the instance will be corrupted which many
cloud operators would consider to be an unacceptable risk.

However, let's start by exposing it as a nova.conf setting and see how
that goes.

--
Paul Carlton
Software Engineer
Cloud Services
Hewlett Packard
BUK03:T242
Longdown Avenue
Stoke Gifford
Bristol BS34 8QZ

Mobile:+44 (0)7768 994283
Email:mailto:paul.carlt...@hpe.com
Hewlett-Packard Limited registered Office: Cain Road, Bracknell, Berks RG12 1HN 
Registered No: 690597 England.
The contents of this message and any attachments to it are confidential and may be 
legally privileged. If you have received this message in error, you should delete it from 
your system immediately and advise the sender. To any recipient of this message within 
HP, unless otherwise stated you should consider this message and attachments as "HP 
CONFIDENTIAL".




smime.p7s
Description: S/MIME Cryptographic 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] where the aggregate and cell document is

[gong_ys2004]

Hi stackers,I want to set up cell and aggregator env, but I failed to find the 
document about them.could you please help me to find the document?
regards,yong sheng gong__
OpenStack Development Mailing List (not for 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

[Julien Danjou]

On Wed, Sep 23 2015, ZZelle wrote:

> * It doesn't work when the service itself acts as a proxy (typically nova
> image-list)
> * it doesn't work when you rewrite from
> https://://...
> to http://:/...
>   because the  information is not provided in the headers (except if
> you exploit a webob limitation)

Yup, that's what I wrote in my previous mail – that's the only case not
covered correctly except if you have specific oslo.config option à la
Keystone.

Though we could also use and document a header that we would use inside
OpenStack to pass the  around. That would avoid having anything to
configure in each service, just setting a proper header in your proxy.
Which means less configuration to do for OpenStack – always a good thing
IMHO.

-- 
Julien Danjou
# Free Software hacker
# http://julien.danjou.info


signature.asc
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] [Fuel] Nominate Denis Dmitriev for fuel-qa(devops) core

[Anastasia Urlapova]

Congratulations to Denis!



On Fri, Sep 18, 2015 at 2:55 PM, Yuriy Shamray 
wrote:

> +1
>
> On Fri, Sep 18, 2015 at 1:34 PM, Yegor Kotko  wrote:
>
>> +1
>>
>> On Tue, Sep 15, 2015 at 6:29 AM, Sebastian Kalinowski <
>> skalinow...@mirantis.com> wrote:
>>
>>> +1
>>>
>>> 2015-09-14 22:37 GMT+02:00 Ivan Kliuk :
>>>
 +1

 On Mon, Sep 14, 2015 at 10:19 PM, Anastasia Urlapova <
 aurlap...@mirantis.com> wrote:

> Folks,
> I would like to nominate Denis Dmitriev[1] for fuel-qa/fuel-devops
> core.
>
> Dennis spent three months in Fuel BugFix team, his velocity was
> between 150-200% per week. Thanks to his efforts we have won these old
> issues with time sync and ceph's clock skew. Dennis's ideas constantly 
> help
> us to improve our functional system suite.
>
> Fuelers, please vote for Denis!
>
> Nastya.
>
> [1]
> http://stackalytics.com/?user_id=ddmitriev=all_type=all=fuel-qa
>
> --
> You received this message because you are subscribed to the Google
> Groups "fuel-core-team" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to fuel-core-team+unsubscr...@mirantis.com.
> For more options, visit
> https://groups.google.com/a/mirantis.com/d/optout.
>



 --
 Best regards,
 Ivan Kliuk

 --
 You received this message because you are subscribed to the Google
 Groups "fuel-core-team" group.
 To unsubscribe from this group and stop receiving emails from it, send
 an email to fuel-core-team+unsubscr...@mirantis.com.
 For more options, visit
 https://groups.google.com/a/mirantis.com/d/optout.

>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "fuel-core-team" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to fuel-core-team+unsubscr...@mirantis.com.
>>> For more options, visit
>>> https://groups.google.com/a/mirantis.com/d/optout.
>>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "fuel-core-team" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to fuel-core-team+unsubscr...@mirantis.com.
>> For more options, visit https://groups.google.com/a/mirantis.com/d/optout
>> .
>>
>
>
>
> --
> --
> Best regards,
> Shamray Yuriy
> QA/DevOps, Mirantis, Inc.
> Skype: ss-yuriy
> +38 (098) 400 48 41
> 38 Lenina ave., Kharkov, Ukraine
> www.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

[openstack-dev] [Heat] [Zaqar] Liberty RC1 available

[Thierry Carrez]

Hello everyone,

Heat and Zaqar just produced their first release candidate for the end
of the Liberty cycle. The RC1 tarballs, as well as a list of last-minute
features and fixed bugs since liberty-1 are available at:

https://launchpad.net/heat/liberty/liberty-rc1
https://launchpad.net/zaqar/liberty/liberty-rc1

Unless release-critical issues are found that warrant a release
candidate respin, these RC1s will be formally released as final versions
on October 15. You are therefore strongly encouraged to test and
validate these tarballs !

Alternatively, you can directly test the stable/liberty release branch at:

http://git.openstack.org/cgit/openstack/heat/log/?h=stable/liberty
http://git.openstack.org/cgit/openstack/zaqar/log/?h=stable/liberty

If you find an issue that could be considered release-critical, please
file it at:

https://bugs.launchpad.net/heat/+filebug
or
https://bugs.launchpad.net/zaqar/+filebug

and tag it *liberty-rc-potential* to bring it to the release crew's
attention.

Note that the "master" branches of Heat and Zaqar are now officially
open for Mitaka development, so feature freeze restrictions no longer
apply there.

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

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

[Julien Danjou]

On Wed, Sep 23 2015, Sean Dague wrote:

> Does that solution work in the HA Proxy case where there is one
> terminating address for multiple backend servers?

Yep.

> Because there is the concern that this impacts not only the Location
> header, but the link documents inside the responses which clients are
> expected to be able to link.follow. This is an honest question, I
> don't know how the oslo_middleware.ssl acts in these cases. And HA
> Proxy 1 to N mapping is very common deployment model.

It should, but some project like Keystone does not handle that
correctly. I just submitted a patch that fixes this kind of thing by
using correctly the WSGI environment variable to build a correct URL.
That fixes also the use cases where Keystone does not run on / but on
e.g. /identity (the bug I initially wanted to fix).

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

If you use `wsgiref.util.application_uri(environment)' it should do
everything correctly. With the SSL middleware enabled that Mathieu
talked about, it will translate correctly http to https too.

The {public,admin}_endpoint are only useful in the case where you map
http://myproxy/identity -> http://mykeystone/ using a proxy

Because the prefix is not passed to Keystone. If you map 1:1 the path
part, we could also leverage X-Forwarded-Host and X-Forwarded-Port to
avoid having {public,admin}_endpoint options.


-- 
Julien Danjou
-- Free Software hacker
-- http://julien.danjou.info


signature.asc
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] Consistent support for SSL termination proxies across all API services

[ZZelle]

Hi,

SSLMiddleware takes into account a Header[1] to set wsgi.url_scheme
which allows a proxy to provide the original protocol to Heat/Neutron/...


Does that solution work in the HA Proxy case where there is one
> terminating address for multiple backend servers? Because there is the
> concern that this impacts not only the Location header, but the link
> documents inside the responses which clients are expected to be able to
> link.follow. This is an honest question, I don't know how the
> oslo_middleware.ssl acts in these cases. And HA Proxy 1 to N mapping is
> very common deployment model.
>

It ensures the protocol provided in headers will be used to generate
correct Location Headers and links.

BUT there are some limitations:

* It doesn't work when the service itself acts as a proxy (typically nova
image-list)
* it doesn't work when you rewrite from
https://://...
to http://:/...
  because the  information is not provided in the headers (except if
you exploit a webob limitation)


Cédric/ZZelle@IRC
__
OpenStack Development Mailing List (not for 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

[Paul Carlton]

On 22/09/15 16:20, Daniel P. Berrange wrote:

On Tue, Sep 22, 2015 at 09:05:11AM -0600, Chris Friesen wrote:

On 09/21/2015 02:56 AM, Daniel P. Berrange wrote:

On Fri, Sep 18, 2015 at 05:47:31PM +, Carlton, Paul (Cloud Services) wrote:

However the most significant impediment we encountered was customer
complaints about performance of instances during migration.  We did a little
bit of work to identify the cause of this and concluded that the main issues
was disk i/o contention.  I wonder if this is something you or others have
encountered?  I'd be interested in any idea for managing the rate of the
migration processing to prevent it from adversely impacting the customer
application performance.  I appreciate that if we throttle the migration
processing it will take longer and may not be able to keep up with the rate
of disk/memory change in the instance.

I would not expect live migration to have an impact on disk I/O, unless
your storage is network based and using the same network as the migration
data. While migration is taking place you'll see a small impact on the
guest compute performance, due to page table dirty bitmap tracking, but
that shouldn't appear directly as disk I/O problem. There is no throttling
of guest I/O at all during migration.

Technically if you're doing a lot of disk I/O couldn't you end up with a
case where you're thrashing the page cache enough to interfere with
migration?  So it's actually memory change that is the problem, but it might
not be memory that the application is modifying directly but rather memory
allocated by the kernel.


Could you point me at somewhere I can get details of the tuneable setting
relating to cutover down time please?  I'm assuming that at these are
libvirt/qemu settings?  I'd like to play with them in our test environment
to see if we can simulate busy instances and determine what works.  I'd also
be happy to do some work to expose these in nova so the cloud operator can
tweak if necessary?

It is already exposed as 'live_migration_downtime' along with
live_migration_downtime_steps, and live_migration_downtime_delay.
Again, it shouldn't have any impact on guest performance while
live migration is taking place. It only comes into effect when
checking whether the guest is ready to switch to the new host.

Has anyone given thought to exposing some of these new parameters to the
end-user?  I could see a scenario where an image might want to specify the
acceptable downtime over migration.  (On the other hand that might be tricky
from the operator perspective.)

I'm of the opinion that we should really try to avoid exposing *any*
migration tunables to the tenant user. All the tunables are pretty
hypervisor specific and low level and not very friendly to expose
to tenants. Instead our focus should be on ensuring that it will
always "just work" from the tenants POV.

When QEMU gets 'post copy' migration working, we'll want to adopt
that asap, as that will give us the means to guarantee that migration
will always complete with very little need for tuning.

At most I could see the users being able to given some high level
indication as to whether their images tolerate some level of
latency, so Nova can decide what migration characteristic is
acceptable.

Regards,
Daniel

Actually I was not envisaging the controls on migration tuning being
made available to the user.  I was thinking we should provide the cloud
administrator with the facility to increase the live_migration_downtime
setting to increase the chance of a migration being able to complete.
I would expect that this would be used in consultation with the instance
owner.  It seems to me, it might be a viable alternative to pausing the
instance to allow the migration to complete.

--
Paul Carlton
Software Engineer
Cloud Services
Hewlett Packard
BUK03:T242
Longdown Avenue
Stoke Gifford
Bristol BS34 8QZ

Mobile:+44 (0)7768 994283
Email:mailto:paul.carlt...@hpe.com
Hewlett-Packard Limited registered Office: Cain Road, Bracknell, Berks RG12 1HN 
Registered No: 690597 England.
The contents of this message and any attachments to it are confidential and may be 
legally privileged. If you have received this message in error, you should delete it from 
your system immediately and advise the sender. To any recipient of this message within 
HP, unless otherwise stated you should consider this message and attachments as "HP 
CONFIDENTIAL".




smime.p7s
Description: S/MIME Cryptographic 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] [Fuel] Core Reviewers groups restructure

[Sergii Golovatiuk]

+1

--
Best regards,
Sergii Golovatiuk,
Skype #golserge
IRC #holser

On Wed, Sep 23, 2015 at 12:10 PM, Vladimir Kuklin 
wrote:

> +1
>
>
> On Tue, Sep 22, 2015 at 2:17 AM, Mike Scherbakov  > wrote:
>
>> Thanks guys.
>> So for fuel-octane then there are no actions needed.
>>
>> For fuel-agent-core group [1], looks like we are already good (it doesn't
>> have fuel-core group nested). But it would need to include fuel-infra group
>> and remove Aleksandra Fedorova (she will be a part of fuel-infra group).
>>
>> python-fuel-client-core [2] is good as well (no nested fuel-core).
>> However, there is another group python-fuelclient-release [3], which has to
>> be eliminated, and main python-fuelclient-core would just have fuel-infra
>> group included for maintenance purposes.
>>
>> [1] https://review.openstack.org/#/admin/groups/995,members
>> [2] https://review.openstack.org/#/admin/groups/551,members
>> [3] https://review.openstack.org/#/admin/groups/552,members
>>
>>
>> On Mon, Sep 21, 2015 at 11:06 AM Oleg Gelbukh 
>> wrote:
>>
>>> FYI, we have a separate core group for stackforge/fuel-octane repository
>>> [1].
>>>
>>> I'm supporting the move to modularization of Fuel with cleaner
>>> separation of authority and better defined interfaces. Thus, I'm +1 to such
>>> a change as a part of that move.
>>>
>>> [1] https://review.openstack.org/#/admin/groups/1020,members
>>>
>>> --
>>> Best regards,
>>> Oleg Gelbukh
>>>
>>> On Sun, Sep 20, 2015 at 11:56 PM, Mike Scherbakov <
>>> mscherba...@mirantis.com> wrote:
>>>
 Hi all,
 as of my larger proposal on improvements to code review workflow [1],
 we need to have cores for repositories, not for the whole Fuel. It is the
 path we are taking for a while, and new core reviewers added to specific
 repos only. Now we need to complete this work.

 My proposal is:

1. Get rid of one common fuel-core [2] group, members of which can
merge code anywhere in Fuel. Some members of this group may cover a 
 couple
of repositories, but can't really be cores in all repos.
2. Extend existing groups, such as fuel-library [3], with members
from fuel-core who are keeping up with large number of reviews / merges.
This data can be queried at Stackalytics.
3. Establish a new group "fuel-infra", and ensure that it's
included into any other core group. This is for maintenance purposes, 
 it is
expected to be used only in exceptional cases. Fuel Infra team will 
 have to
decide whom to include into this group.
4. Ensure that fuel-plugin-* repos will not be affected by removal
of fuel-core group.

 #2 needs specific details. Stackalytics can show active cores easily,
 we can look at people with *:
 http://stackalytics.com/report/contribution/fuel-web/180. This is for
 fuel-web, change the link for other repos accordingly. If people are added
 specifically to the particular group, leaving as is (some of them are no
 longer active. But let's clean them up separately from this group
 restructure process).

- fuel-library-core [3] group will have following members: Bogdan
D., Sergii G., Alex Schultz, Vladimir Kuklin, Alex Didenko.
- fuel-web-core [4]: Sebastian K., Igor Kalnitsky, Alexey Kasatkin,
Vitaly Kramskikh, Julia Aranovich, Evgeny Li, Dima Shulyak
- fuel-astute-core [5]: Vladimir Sharshov, Evgeny Li
- fuel-dev-tools-core [6]: Przemek Kaminski, Sebastian K.
- fuel-devops-core [7]: Tatyana Leontovich, Andrey Sledzinsky,
Nastya Urlapova
- fuel-docs-core [8]: Irina Povolotskaya, Denis Klepikov, Evgeny
Konstantinov, Olga Gusarenko
- fuel-main-core [9]: Vladimir Kozhukalov, Roman Vyalov, Dmitry
Pyzhov, Sergii Golovatyuk, Vladimir Kuklin, Igor Kalnitsky
- fuel-nailgun-agent-core [10]: Vladimir Sharshov, V.Kozhukalov
- fuel-ostf-core [11]: Tatyana Leontovich, Nastya Urlapova, Andrey
Sledzinsky, Dmitry Shulyak
- fuel-plugins-core [12]: Igor Kalnitsky, Evgeny Li, Alexey Kasatkin
- fuel-qa-core [13]: Andrey Sledzinsky, Tatyana Leontovich, Nastya
Urlapova
- fuel-stats-core [14]: Alex Kislitsky, Alexey Kasatkin, Vitaly
Kramskikh
- fuel-tasklib-core [15]: Igor Kalnitsky, Dima Shulyak, Alexey
Kasatkin (this project seems to be dead, let's consider to rip it off)
- fuel-specs-core: there is no such a group at the moment. I
propose to create one with following members, based on stackalytics data
[16]: Vitaly Kramskikh, Bogdan Dobrelia, Evgeny Li, Sergii Golovatyuk,
Vladimir Kuklin, Igor Kalnitsky, Alexey Kasatkin, Roman Vyalov, Dmitry
Borodaenko, Mike Scherbakov, Dmitry Pyzhov. We would need to reconsider 
 who
can merge after Fuel 

Re: [openstack-dev] [neutron + ovn] Does neutron ovn plugin support to setup multiple neutron networks for one container?

[WANG, Ming Hao (Tony T)]

Hi Russell,

I just realized OVN plugin is an independent plugin of OVS plugin.
In this case, how do we handle the provider network connections between compute 
nodes? Is it handled by OVN actually?

Thanks,
Tony 

-Original Message-
From: WANG, Ming Hao (Tony T) 
Sent: Wednesday, September 23, 2015 1:58 PM
To: WANG, Ming Hao (Tony T); 'OpenStack Development Mailing List (not for usage 
questions)'
Subject: RE: [openstack-dev] [neutron + ovn] Does neutron ovn plugin support to 
setup multiple neutron networks for one container?

Hi Russell,

Is there any material to explain how OVN parent port work?

Thanks,
Tony

-Original Message-
From: WANG, Ming Hao (Tony T) 
Sent: Wednesday, September 23, 2015 10:02 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: RE: [openstack-dev] [neutron] Does neutron ovn plugin support to setup 
multiple neutron networks for one container?

Russell,

Thanks for your info.
If I want to assign multiple interfaces to a container on different neutron 
networks(for example, netA and netB), is it mandatory to let the VM hosting 
containers have network interfaces in netA and netB, and ovn will help to 
direct the container traffic to its corresponding VM network interfaces?

from https://github.com/openvswitch/ovs/blob/master/ovn/CONTAINERS.OpenStack.md 
:
"This VLAN tag is stripped out in the hypervisor by OVN."
I suppose when the traffic goes out the VM, the VLAN tag has already been 
stripped out. 
When the traffic arrives ovs on physical host, it will be tagged with neutron 
local vlan. Is it right?

Thanks in advance,
Tony

-Original Message-
From: Russell Bryant [mailto:rbry...@redhat.com] 
Sent: Wednesday, September 23, 2015 12:46 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron] Does neutron ovn plugin support to setup 
multiple neutron networks for one container?

On 09/22/2015 08:08 AM, WANG, Ming Hao (Tony T) wrote:
> Dear all,
> 
> For neutron ovn plugin supports containers in one VM, My understanding is one 
> container can't be assigned two network interfaces in different neutron 
> networks. Is it right?
> The reason:
> 1. One host VM only has one network interface.
> 2. all the VLAN tags are stripped out when the packet goes out the VM.
> 
> If it is True, does neutron ovn plugin or ovn has plan to support this?

You should be able to assign multiple interfaces to a container on different 
networks.  The traffic for each interface will be tagged with a unique VLAN ID 
on its way in and out of the VM, the same way it is done for each container 
with a single interface.

--
Russell Bryant

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

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

[openstack-dev] [neutron] Stumped...need help with neutronclient job failure

[Paul Michali]

Hi,

I created a pair of experimental jobs for python-neutronclient that will
run functional tests on core and advanced services, respectively. In the
python-neutronclient repo, I have a commit [1] that splits the tests into
two directories for core/adv-svcs, enables the VPN devstack plugin for the
advanced services tests, and removes the skip decorator for the VPN tests.

When these two jobs run, the core job pass (as expected). The advanced
services job shows all four advanced services tests (testing REST LIST
requests for IKE policy, IPSec policy, IPSec site-to-site connection, and
VPN service resources) failing, with this T/B:

ft1.1: 
neutronclient.tests.functional.adv-svcs.test_readonly_neutron_vpn.SimpleReadOnlyNeutronVpnClientTest.test_neutron_vpn_*ipsecpolicy_list*_StringException:
Empty attachments:
  pythonlogging:''
  stderr
  stdout

Traceback (most recent call last):
  File "neutronclient/tests/functional/adv-svcs/test_readonly_neutron_vpn.py",
line 37, in test_neutron_vpn_ipsecpolicy_list
ipsecpolicy = self.parser.listing(self.neutron('vpn-ipsecpolicy-list'))
  File "neutronclient/tests/functional/base.py", line 78, in neutron
**kwargs)
  File 
"/opt/stack/new/python-neutronclient/.tox/functional-adv-svcs/local/lib/python2.7/site-packages/tempest_lib/cli/base.py",
line 292, in neutron
'neutron', action, flags, params, fail_ok, merge_stderr)
  File 
"/opt/stack/new/python-neutronclient/.tox/functional-adv-svcs/local/lib/python2.7/site-packages/tempest_lib/cli/base.py",
line 361, in cmd_with_auth
self.cli_dir)
  File 
"/opt/stack/new/python-neutronclient/.tox/functional-adv-svcs/local/lib/python2.7/site-packages/tempest_lib/cli/base.py",
line 61, in execute
proc = subprocess.Popen(cmd, stdout=stdout, stderr=stderr)
  File "/usr/lib/python2.7/subprocess.py", line 710, in __init__
errread, errwrite)
  File "/usr/lib/python2.7/subprocess.py", line 1327, in _execute_child
raise child_exception
OSError: [Errno 2] No such file or directory


When I look at the other logs on this run [2], I see these things:
- The VPN agent is running (so the DevStack plugin started up VPN)
- screen-q-svc.log shows only two of the four REST GET requests
- Initially there was no testr results, but I modified post test hook
script similar to what Neutron does (so it shows results now)
- No other errors seen, including nothing on the StringException

When I run this locally, all four tests pass, and I see four REST requests
in the screen-q-svc.log.

I tried a hack to enable NEUTRONCLIENT_DEBUG environment variable, but no
additional information was shown.

Does anyone have any thoughts on what may be going wrong here?
Any ideas on how to troubleshoot this issue?

Thanks in advance!

Paul Michali (pc_m)

Refs
[1] https://review.openstack.org/#/c/214587/
[2]
http://logs.openstack.org/87/214587/8/experimental/gate-neutronclient-test-dsvm-functional-adv-svcs/5dfa152/
__
OpenStack Development Mailing List (not for 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

[Daniel P. Berrange]

On Wed, Sep 23, 2015 at 01:48:17PM +0100, Paul Carlton wrote:
> 
> 
> On 22/09/15 16:44, Daniel P. Berrange wrote:
> >On Tue, Sep 22, 2015 at 09:29:46AM -0600, Chris Friesen wrote:
> 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 running 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.
> >>It seems to me that the ideal solution would be to start doing pre-copy
> >>migration, then if that doesn't converge with the specified downtime value
> >>then maybe have the option to just cut over to the destination and do a
> >>post-copy migration of the remaining data.
> >Yes, that is precisely what the QEMU developers working on this
> >featue suggest we should do. The lazy page faulting on the target
> >host has a performance hit on the guest, so you definitely need
> >to give a little time for pre-copy to start off with, and then
> >switch to post-copy once some benchmark is reached, or if progress
> >info shows the transfer is not making progress.
> >
> >Regards,
> >Daniel
> I'd be a bit concerned about automatically switching to the post copy
> mode.  As Daniel commented perviously, if something goes wrong on the
> source node the customer's instance could be lost.  Many cloud operators
> will want to control the use of this mode.  As per my previous message
> this could be something that could be set on or off by default but
> provide a PUT operation on os-migration to update setting on for a
> specific migration

NB, if you are concerned about the source host going down while
migration is still taking place, you will loose the VM even with
pre-copy mode too, since the VM will of course still be running
on the source.

The new failure scenario is essentially about the network
connection between the source & host guest - if the network
layer fails while post-copy is running, then you loose the
VM.

In some sense post-copy will reduce the window of failure,
because it should ensure that the VM migration completes
in a faster & finite amount of time. I think this is
probably particularly important for host evacuation so
the admin can guarantee to get all the VMs off a host in
a reasonable amount of time.

As such I don't think you need expose post-copy as a concept in the
API, but I could see a nova.conf value to say whether use of post-copy
was acceptable, so those who want to have stronger resilience against
network failure can turn off post-copy.

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] [fuel] PTL & Component Leads elections

[Vladimir Kuklin]

Dmitry, Mike

Thank you for the list of usable links.

But still - we do not have clearly defined procedure on determening who is
eligible to nominate and vote for PTL and Component Leads. Remember, that
Fuel still has different release cycle and Kilo+Liberty contributors list
is not exactly the same for "365days" contributors list.

Can we finally come up with the list of people eligible to nominate and
vote?

On Sun, Sep 20, 2015 at 2:37 AM, Mike Scherbakov 
wrote:

> Let's move on.
> I started work on MAINTAINERS files, proposed two patches:
> https://review.openstack.org/#/c/225457/1
> https://review.openstack.org/#/c/225458/1
>
> These can be used as templates for other repos / folders.
>
> Thanks,
>
> On Fri, Sep 18, 2015 at 7:45 PM Davanum Srinivas 
> wrote:
>
>> +1 Dmitry
>>
>> -- Dims
>>
>> On Fri, Sep 18, 2015 at 9:07 PM, Dmitry Borodaenko <
>> dborodae...@mirantis.com> 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:
>>> > >> 

Re: [openstack-dev] [neutron][lbaas] - Heat support for LbaasV2

[Fox, Kevin M]

Seperate ns would work great.

Thanks,
Kevin


From: Banashankar KV
Sent: Tuesday, September 22, 2015 9:14:35 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron][lbaas] - Heat support for LbaasV2

What you think about separating both of them with the name as Doug mentioned. 
In future if we want to get rid of the v1 we can just remove that namespace. 
Everything will be clean.

Thanks
Banashankar


On Tue, Sep 22, 2015 at 6:01 PM, Fox, Kevin M 
> wrote:
As I understand it, loadbalancer in v2 is more like pool was in v1. Can we make 
it such that if you are using the loadbalancer resource and have the mandatory 
v2 properties that it tries to use v2 api, otherwise its a v1 resource? 
PoolMember should be ok being the same. It just needs to call v1 or v2 
depending on if the lb its pointing at is v1 or v2. Is monitor's api different 
between them? Can it be like pool member?

Thanks,
Kevin


From: Brandon Logan
Sent: Tuesday, September 22, 2015 5:39:03 PM

To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [neutron][lbaas] - Heat support for LbaasV2

So for the API v1s api is of the structure:

/lb/(vip|pool|member|health_monitor)

V2s is:
/lbaas/(loadbalancer|listener|pool|healthmonitor)

member is a child of pool, so it would go down one level.

The only difference is the lb for v1 and lbaas for v2.  Not sure if that
is enough of a different.

Thanks,
Brandon
On Tue, 2015-09-22 at 23:48 +, Fox, Kevin M wrote:
> Thats the problem. :/
>
> I can't think of a way to have them coexist without: breaking old
> templates, including v2 in the name, or having a flag on the resource
> saying the version is v2. And as an app developer I'd rather not have
> my existing templates break.
>
> I haven't compared the api's at all, but is there a required field of
> v2 that is different enough from v1 that by its simple existence in
> the resource you can tell a v2 from a v1 object? Would something like
> that work? PoolMember wouldn't have to change, the same resource could
> probably work for whatever lb it was pointing at I'm guessing.
>
> Thanks,
> Kevin
>
>
>
> __
> From: Banashankar KV [banvee...@gmail.com]
> Sent: Tuesday, September 22, 2015 4:40 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [neutron][lbaas] - Heat support for
> LbaasV2
>
>
>
> Ok, sounds good. So now the question is how should we name the new V2
> resources ?
>
>
>
> Thanks
> Banashankar
>
>
>
> On Tue, Sep 22, 2015 at 4:33 PM, Fox, Kevin M 
> >
> wrote:
> Yes, hence the need to support the v2 resources as seperate
> things. Then I can rewrite the templates to include the new
> resources rather then the old resources as appropriate. IE, it
> will be a porting effort to rewrite them. Then do a heat
> update on the stack to migrate it from lbv1 to lbv2. Since
> they are different resources, it should create the new and
> delete the old.
>
> Thanks,
> Kevin
>
>
> __
> From: Banashankar KV [banvee...@gmail.com]
> Sent: Tuesday, September 22, 2015 4:16 PM
>
> To: OpenStack Development Mailing List (not for usage
> questions)
> Subject: Re: [openstack-dev] [neutron][lbaas] - Heat support
> for LbaasV2
>
>
>
>
> But I think, V2 has introduced some new components and whole
> association of the resources with each other is changed, we
> should be still able to do what Kevin has mentioned ?
>
> Thanks
> Banashankar
>
>
>
> On Tue, Sep 22, 2015 at 3:39 PM, Fox, Kevin M
> > wrote:
> There needs to be a way to have both v1 and v2
> supported in one engine
>
> Say I have templates that use v1 already in existence
> (I do), and I want to be able to heat stack update on
> them one at a time to v2. This will replace the v1 lb
> with v2, migrating the floating ip from the v1 lb to
> the v2 one. This gives a smoothish upgrade path.
>
> Thanks,
> Kevin
> 
> From: Brandon Logan 
> [brandon.lo...@rackspace.com]
> Sent: Tuesday, September 22, 2015 3:22 PM
> To: 
> openstack-dev@lists.openstack.org
> 

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

[Paul Carlton]

On 22/09/15 16:44, Daniel P. Berrange wrote:

On Tue, Sep 22, 2015 at 09:29:46AM -0600, Chris Friesen wrote:

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

It seems to me that the ideal solution would be to start doing pre-copy
migration, then if that doesn't converge with the specified downtime value
then maybe have the option to just cut over to the destination and do a
post-copy migration of the remaining data.

Yes, that is precisely what the QEMU developers working on this
featue suggest we should do. The lazy page faulting on the target
host has a performance hit on the guest, so you definitely need
to give a little time for pre-copy to start off with, and then
switch to post-copy once some benchmark is reached, or if progress
info shows the transfer is not making progress.

Regards,
Daniel

I'd be a bit concerned about automatically switching to the post copy
mode.  As Daniel commented perviously, if something goes wrong on the
source node the customer's instance could be lost.  Many cloud operators
will want to control the use of this mode.  As per my previous message
this could be something that could be set on or off by default but
provide a PUT operation on os-migration to update setting on for a
specific migration

--
Paul Carlton
Software Engineer
Cloud Services
Hewlett Packard
BUK03:T242
Longdown Avenue
Stoke Gifford
Bristol BS34 8QZ

Mobile:+44 (0)7768 994283
Email:mailto:paul.carlt...@hpe.com
Hewlett-Packard Limited registered Office: Cain Road, Bracknell, Berks RG12 1HN 
Registered No: 690597 England.
The contents of this message and any attachments to it are confidential and may be 
legally privileged. If you have received this message in error, you should delete it from 
your system immediately and advise the sender. To any recipient of this message within 
HP, unless otherwise stated you should consider this message and attachments as "HP 
CONFIDENTIAL".




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

Re: [openstack-dev] [puppet] service default value functions

[Denis Egorenko]

+1 to way from paste above.

2015-09-23 16:42 GMT+03:00 Martin Mágr :

>
>
> On 09/23/2015 02:17 AM, Cody Herriges wrote:
>
> Alex Schultz wrote:
>
> Hey puppet folks,
>
> Based on the meeting yesterday[0], I had proposed creating a parser
> function called is_service_default[1] to validate if a variable matched
> our agreed upon value of ''.  This got me thinking
> about how can we maybe not use the arbitrary string throughout the
> puppet that can not easily be validated.  So I tested creating another
> puppet function named service_default[2] to replace the use of ' DEFAULT>' throughout all the puppet modules.  My tests seemed to
> indicate that you can use a parser function as parameter default for
> classes.
>
> I wanted to send a note to gather comments around the second function.
> When we originally discussed what to use to designate for a service's
> default configuration, I really didn't like using an arbitrary string
> since it's hard to parse and validate. I think leveraging a function
> might be better since it is something that can be validated via tests
> and a syntax checker.  Thoughts?
>
>
> Thanks,
> -Alex
>
> [0] 
> http://eavesdrop.openstack.org/meetings/puppet_openstack/2015/puppet_openstack.2015-09-15-15.00.html
> [1] https://review.openstack.org/#/c/223672
> [2] https://review.openstack.org/#/c/224187
>
> I've been mulling this over the last several days and I just can't
> accept an entire ruby function which would be ran for every parameter
> with the desired static value of "" when the class is
> declared and parsed.  I am not generally against using functions as a
> parameter default just not a fan in this case because running ruby just
> to return a static string seems inappropriate and not optimal.
>
> In this specific case I think the params pattern and inheritance can
> obtain us the same goals.  I also find this a valid us of inheritance
> cross module namespaces but...only because all our modules must depend
> on puppet-openstacklib.
> http://paste.openstack.org/show/473655
>
>
> +1 for implementation in pastebin above. Much better solution than running
> function.
>
> Regards,
> Martin
>
>
>
>
> __
> 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
>
>


-- 
Best Regards,
Egorenko Denis,
Deployment Engineer
Mirantis
__
OpenStack Development Mailing List (not for 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] How to properly detect and fence a compromised host (and why I dislike TrustedFilter)

[Matt Riedemann]

On 6/25/2015 3:59 AM, Sylvain Bauza wrote:



Le 24/06/2015 19:56, Joe Gordon a écrit :



On Tue, Jun 23, 2015 at 3:41 AM, Sylvain Bauza > wrote:

Hi team,

Some discussion occurred over IRC about a bug which was publicly
open related to TrustedFilter [1]
I want to take the opportunity for raising my concerns about that
specific filter, why I dislike it and how I think we could improve
the situation - and clarify everyone's thoughts)

The current situation is that way : Nova only checks if one host
is compromised only when the scheduler is called, ie. only when
booting/migrating/evacuating/unshelving an instance (well, not
exactly all the evacuate/live-migrate cases, but let's not discuss
about that now). When the request goes in the scheduler, all the
hosts are checked against all the enabled filters and the
TrustedFilter is making an external HTTP(S) call to the
Attestation API service (not handled by Nova) for *each host* to
see if the host is valid (not compromised) or not.

To be clear, that's the only in-tree scheduler filter which
explicitly does an external call to a separate service that Nova
is not managing. I can see at least 3 reasons for thinking about
why it's bad :

#1 : that's a terrible bottleneck for performance, because we're
IO-blocking N times given N hosts (we're even not multiplexing the
HTTP requests)
#2 : all the filters are checking an internal Nova state for the
host (called HostState) but that the TrustedFilter, which means
that conceptually we defer the decision to a 3rd-party engine
#3 : that Attestation API services becomes a de facto dependency
for Nova (since it's an in-tree filter) while it's not listed as a
dependency and thus not gated.


All of these reasons could be acceptable if that would cover the
exposed usecase given in [1] (ie. I want to make sure that if my
host gets compromised, my instances will not be running on that
host) but that just doesn't work, due to the situation I mentioned
above.

So, given that, here are my thoughts :
a/ if a host gets compromised, we can just disable its service to
prevent its election as a valid destination host. There is no need
for a specialised filter.
b/ if a host is compromised, we can assume that the instances have
to resurrect elsewhere, ie. we can call a nova evacuate
c/ checking if an host is compromised or not is not a Nova
responsibility since it's already perfectly done by [2]

In other words, I'm considering that "security" usecase as
something analog as the HA usecase [3] where we need a 3rd-party
tool responsible for periodically checking the state of the hosts,
and if compromised then call the Nova API for fencing the host and
evacuating the compromised instances.

Given that, I'm proposing to deprecate TrustedFilter and explictly
mention to drop it from in-tree in a later cycle
https://review.openstack.org/194592


Given people are using this, it is a negligible maintenance burden.  I
think deprecating with the intention of removing is not worth it.

Although it would be very useful to further document the risks with
this filter (live migration, possible performance issues etc.)


Well, I can understand that customers could not be agreeing to remove
the filter because there is no clear alternative for them. That said, I
think saying that the filter is deprecated without saying when it would
be removed would help some contributors thinking about that and working
on a better solution, exactly like we did for EC2 API.

To be clear, I want to freeze the filter by deprecating it and
explaining why it's wrong (by amending the devref section and giving a
LOG warning saying it's deprecated) and then leave the filter within
in-tree unless we are sure that there is a good solution out of Nova.

-Sylvain





Thoughts ?
-Sylvain



[1] https://bugs.launchpad.net/nova/+bug/1456228
[2] https://github.com/OpenAttestation/OpenAttestation
[3]
http://blog.russellbryant.net/2014/10/15/openstack-instance-ha-proposal/


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

Re: [openstack-dev] [neutron + ovn] Does neutron ovn plugin support to setup multiple neutron networks for one container?

[Russell Bryant]

I'll reply to each of your 3 messages here:

On 09/23/2015 05:57 AM, WANG, Ming Hao (Tony T) wrote:
> Hi Russell,
> 
> I just realized OVN plugin is an independent plugin of OVS plugin.

Yes, it's a plugin developed in the "networking-ovn" project.

http://git.openstack.org/cgit/openstack/networking-ovn/

> In this case, how do we handle the provider network connections between 
> compute nodes? Is it handled by OVN actually?

I'm going to start by explaining the status of OVN itself, and then I'll
come back and address the Neutron integration:

 -- OVN --

OVN implements logical networks as overlays using the Geneve protocol.
Connecting from logical to physical networks is done by one of two ways.

The first is using VTEP gateways.  This could be hardware or software
gateways that implement the hardware_vtep schema.  This is typically a
TOR switch that supports the vtep schema, but I believe someone is going
to build a software version based on ovs and dpdk.  OVN includes a
daemon called "ovn-controller-vtep" that is run for each vtep gateway to
manage connectivity between OVN networks and the gateway.  It could run
on the switch itself, or some other management host.  The last set of
patches to get this working initially were merged just 8 days ago.

The ovn-architecture document describes "Life Cycle of a VTEP gateway":


https://github.com/openvswitch/ovs/blob/master/ovn/ovn-architecture.7.xml#L820

or you can find a temporary copy of a rendered version here:

  http://www.russellbryant.net/ovs-docs/ovn-architecture.7.pdf

The second is what Neutron refers to as "provider networks".  OVN does
support this, as well.  It was merge just a couple weeks ago.  The
commit message for OVN "localnet" ports goes into quite a bit of detail
about how this works in OVN:


https://github.com/openvswitch/ovs/commit/c02819293d52f7ea7b714242d871b2b01f57f905

 -- Neutron --

Both of these things are freshly implemented in OVN so the Neutron
integration is a WIP.

For vtep gateways, there's not an established API.  networking-l2gw is
the closest thing, but I've got some concerns with both the API and
implementation.  As a first baby step, we're just going to provide a
hack that lets an admin create a connection between a network and
gateway using a neutron port with a special binding:profile.  We'll also
be continuing to look at providing a proper API.

For provider networks, working with them in Neutron will be no different
than it is today with the current OVS support.  I just have to finish
the Neutron plugin integration, which I just started on yesterday.

> 
> Thanks,
> Tony 
> 
> -Original Message-
> From: WANG, Ming Hao (Tony T) 
> Sent: Wednesday, September 23, 2015 1:58 PM
> To: WANG, Ming Hao (Tony T); 'OpenStack Development Mailing List (not for 
> usage questions)'
> Subject: RE: [openstack-dev] [neutron + ovn] Does neutron ovn plugin support 
> to setup multiple neutron networks for one container?
> 
> Hi Russell,
> 
> Is there any material to explain how OVN parent port work?

Note that while this uses a binding:profile hack for now, we're going to
update the plugin to support the vlan-aware-vms API for this use case
once that is completed.

http://docs.openstack.org/developer/networking-ovn/containers.html

http://specs.openstack.org/openstack/neutron-specs/specs/liberty/vlan-aware-vms.html

https://github.com/openvswitch/ovs/blob/master/ovn/CONTAINERS.OpenStack.md

https://github.com/shettyg/ovn-docker

> Thanks,
> Tony
> 
> -Original Message-
> From: WANG, Ming Hao (Tony T) 
> Sent: Wednesday, September 23, 2015 10:02 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: RE: [openstack-dev] [neutron] Does neutron ovn plugin support to 
> setup multiple neutron networks for one container?
> 
> Russell,
> 
> Thanks for your info.
> If I want to assign multiple interfaces to a container on different
> neutron networks(for example, netA and netB), is it mandatory to let
> the VM hosting containers have network interfaces in netA and netB,
> and ovn will help to direct the container traffic to its
> corresponding VM network interfaces?
> 
> from 
> https://github.com/openvswitch/ovs/blob/master/ovn/CONTAINERS.OpenStack.md :
> "This VLAN tag is stripped out in the hypervisor by OVN."
> I suppose when the traffic goes out the VM, the VLAN tag has already been 
> stripped out. 
> When the traffic arrives ovs on physical host, it will be tagged with neutron 
> local vlan. Is it right?

Hopefully the links provided in response to the above mail help explain
it.  In short, the VM only needs one network interface and all traffic
for all containers go over that network interface.  To put each
container on different Neutron networks, the hypervisor needs to be able
to differentiate the traffic from each container even though its all
going over the same network interface to/from the VM.  That's where VLAN
ids are used.  It's used as a simple way to tag traffic as it goes over

Re: [openstack-dev] Election tools work session in Tokyo

[Jeremy Stanley]

On 2015-09-23 11:41:24 +0200 (+0200), Thierry Carrez wrote:
[...]
> This is a bit cross-project, so the natural fit would be a
> cross-project workshop [...] Alternatively that could fit in a
> infra work session, you may want to suggest it there

Yep, I agree both are a possible fit. Cross-project tooling is
basically another term for our community infrastructure, after all.

> (not sure if they have opened an etherpad for session suggestion
> yet).
[...]

Not yet. Don't hate me, but I was hoping odsreg would be useful for
this. ;)

If you want to stick with only using odsreg for the cross-project
session proposals, Infra can just start ours straight from an
etherpad. We don't usually get more than a dozen sessions proposed,
but because of the wide-reaching impact of our work throughout the
project we do tend to get at least a few from outside our immediate
team.
-- 
Jeremy Stanley

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

Re: [openstack-dev] [cinder] How to make a mock effactive for all method of a testclass

[Eric Harney]

On 09/23/2015 04:06 AM, liuxinguo wrote:
> Hi,
> 
> In a.py we have a function:
> def _change_file_mode(filepath):
> utils.execute('chmod', '600', filepath, run_as_root=True)
> 
> In test_xxx.py, there is a testclass:
> class DriverTestCase(test.TestCase):
> def test_a(self)
> ...
> Call a. _change_file_mode
> ...
> 
> def test_b(self)
> ...
> Call a. _change_file_mode
> ...
> 
> I have tried to mock like mock out function _change_file_mode like this:
> @mock.patch.object(a, '_change_file_mode', return_value=None)
> class DriverTestCase(test.TestCase):
> def test_a(self)
> ...
> Call a. _change_file_mode
> ...
> 
> def test_b(self)
> ...
> Call a. _change_file_mode
> ...
> 
> But the mock takes no effort, the real function _change_file_mode is still 
> executed.
> So how to make a mock effactive for all method of a testclass?
> Thanks for any input!
> 
> Wilson Liu

The simplest way I found to do this was to use mock.patch in the test
class's setUp() method, and tear it down again in tearDown().

There may be cleaner ways to do this with tools in oslotest etc. (I'm
not sure), but this is fairly straightforward.

See here -- self._clear_patch stores the mock:
http://git.openstack.org/cgit/openstack/cinder/tree/cinder/tests/unit/test_volume.py?id=8de60a8b#n257


__
OpenStack Development Mailing List (not for 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] How to properly detect and fence a compromised host (and why I dislike TrustedFilter)

[Sylvain Bauza]

Le 23/09/2015 15:31, Matt Riedemann a écrit :



On 6/25/2015 3:59 AM, Sylvain Bauza wrote:



Le 24/06/2015 19:56, Joe Gordon a écrit :



On Tue, Jun 23, 2015 at 3:41 AM, Sylvain Bauza > wrote:

Hi team,

Some discussion occurred over IRC about a bug which was publicly
open related to TrustedFilter [1]
I want to take the opportunity for raising my concerns about that
specific filter, why I dislike it and how I think we could improve
the situation - and clarify everyone's thoughts)

The current situation is that way : Nova only checks if one host
is compromised only when the scheduler is called, ie. only when
booting/migrating/evacuating/unshelving an instance (well, not
exactly all the evacuate/live-migrate cases, but let's not discuss
about that now). When the request goes in the scheduler, all the
hosts are checked against all the enabled filters and the
TrustedFilter is making an external HTTP(S) call to the
Attestation API service (not handled by Nova) for *each host* to
see if the host is valid (not compromised) or not.

To be clear, that's the only in-tree scheduler filter which
explicitly does an external call to a separate service that Nova
is not managing. I can see at least 3 reasons for thinking about
why it's bad :

#1 : that's a terrible bottleneck for performance, because we're
IO-blocking N times given N hosts (we're even not multiplexing the
HTTP requests)
#2 : all the filters are checking an internal Nova state for the
host (called HostState) but that the TrustedFilter, which means
that conceptually we defer the decision to a 3rd-party engine
#3 : that Attestation API services becomes a de facto dependency
for Nova (since it's an in-tree filter) while it's not listed as a
dependency and thus not gated.


All of these reasons could be acceptable if that would cover the
exposed usecase given in [1] (ie. I want to make sure that if my
host gets compromised, my instances will not be running on that
host) but that just doesn't work, due to the situation I mentioned
above.

So, given that, here are my thoughts :
a/ if a host gets compromised, we can just disable its service to
prevent its election as a valid destination host. There is no need
for a specialised filter.
b/ if a host is compromised, we can assume that the instances have
to resurrect elsewhere, ie. we can call a nova evacuate
c/ checking if an host is compromised or not is not a Nova
responsibility since it's already perfectly done by [2]

In other words, I'm considering that "security" usecase as
something analog as the HA usecase [3] where we need a 3rd-party
tool responsible for periodically checking the state of the hosts,
and if compromised then call the Nova API for fencing the host and
evacuating the compromised instances.

Given that, I'm proposing to deprecate TrustedFilter and explictly
mention to drop it from in-tree in a later cycle
https://review.openstack.org/194592


Given people are using this, it is a negligible maintenance burden.  I
think deprecating with the intention of removing is not worth it.

Although it would be very useful to further document the risks with
this filter (live migration, possible performance issues etc.)


Well, I can understand that customers could not be agreeing to remove
the filter because there is no clear alternative for them. That said, I
think saying that the filter is deprecated without saying when it would
be removed would help some contributors thinking about that and working
on a better solution, exactly like we did for EC2 API.

To be clear, I want to freeze the filter by deprecating it and
explaining why it's wrong (by amending the devref section and giving a
LOG warning saying it's deprecated) and then leave the filter within
in-tree unless we are sure that there is a good solution out of Nova.

-Sylvain





Thoughts ?
-Sylvain



[1] https://bugs.launchpad.net/nova/+bug/1456228
[2] https://github.com/OpenAttestation/OpenAttestation
[3]
http://blog.russellbryant.net/2014/10/15/openstack-instance-ha-proposal/ 




__
OpenStack Development Mailing 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] How to make a mock effactive for all method of a testclass

[Brant Knudson]

On Wed, Sep 23, 2015 at 3:06 AM, liuxinguo  wrote:

> Hi,
>
>
>
> In a.py we have a function:
>
> def *_change_file_mode*(filepath):
>
> utils.execute(*'chmod'*, *'600'*, filepath, run_as_root=True)
>
>
>
> In test_xxx.py, there is a testclass:
>
> clas*s DriverTestCase(test.TestCase):*
>
> *def test_a(self)*
>
> *…*
>
> *Call a. _change_file_mode*
>
> *…*
>
>
>
> *def test_b(self)*
>
> *…*
>
> *Call a. _change_file_mode*
>
> *…*
>
>
>
> I have tried to mock like mock out function *_change_file_mode *like this:
>
> *@mock.patch.object*(a, *'_change_file_mode', *return_value=None)
>
> clas*s DriverTestCase(test.TestCase):*
>
> *def test_a(self)*
>
> *…*
>
> *Call a. _change_file_mode*
>
> *…*
>
>
>
> *def test_b(self)*
>
> *…*
>
> *Call a. _change_file_mode*
>
> *…*
>
>
>
> But the mock takes no effort, the real function _change_file_mode is still
> executed.
>
> So how to make a mock effactive for all method of a testclass?
>
> Thanks for any input!
>
>
>

Use oslotest's mockpatch.PatchObject fixture:
http://docs.openstack.org/developer/oslotest/api.html#oslotest.mockpatch.PatchObject


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

Re: [openstack-dev] [puppet] service default value functions

[Alex Schultz]

>
> I've been mulling this over the last several days and I just can't
> accept an entire ruby function which would be ran for every parameter
> with the desired static value of "" when the class is
> declared and parsed.  I am not generally against using functions as a
> parameter default just not a fan in this case because running ruby just
> to return a static string seems inappropriate and not optimal.
>
> In this specific case I think the params pattern and inheritance can
> obtain us the same goals.  I also find this a valid us of inheritance
> cross module namespaces but...only because all our modules must depend
> on puppet-openstacklib.
>
> http://paste.openstack.org/show/473655
>

Yes after thinking it over, I agree that the function for a parameter
is probably not the best route.  I think going the inheritance route
is a much more established pattern and would make more sense.

Just throwing this out there, another option could be using a fact in
puppet-openstacklib. We could create an os_service_default fact or
something named similarly that would be a static constant that could
be used for a parameter default and we could leverage it as part of
the is_service_default() function.  We would still require
puppet-openstacklib be included but we wouldn't need to do all the
inherits in the classes.  Just a thought.

Thanks,
-Alex


>
>
> --
> Cody
>
>
> __
> OpenStack Development Mailing 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] [puppet] service default value functions

[Martin Mágr]

On 09/23/2015 02:17 AM, Cody Herriges wrote:

Alex Schultz wrote:

Hey puppet folks,

Based on the meeting yesterday[0], I had proposed creating a parser
function called is_service_default[1] to validate if a variable matched
our agreed upon value of ''.  This got me thinking
about how can we maybe not use the arbitrary string throughout the
puppet that can not easily be validated.  So I tested creating another
puppet function named service_default[2] to replace the use of '' throughout all the puppet modules.  My tests seemed to
indicate that you can use a parser function as parameter default for
classes.

I wanted to send a note to gather comments around the second function.
When we originally discussed what to use to designate for a service's
default configuration, I really didn't like using an arbitrary string
since it's hard to parse and validate. I think leveraging a function
might be better since it is something that can be validated via tests
and a syntax checker.  Thoughts?


Thanks,
-Alex

[0] 
http://eavesdrop.openstack.org/meetings/puppet_openstack/2015/puppet_openstack.2015-09-15-15.00.html
[1] https://review.openstack.org/#/c/223672
[2] https://review.openstack.org/#/c/224187


I've been mulling this over the last several days and I just can't
accept an entire ruby function which would be ran for every parameter
with the desired static value of "" when the class is
declared and parsed.  I am not generally against using functions as a
parameter default just not a fan in this case because running ruby just
to return a static string seems inappropriate and not optimal.

In this specific case I think the params pattern and inheritance can
obtain us the same goals.  I also find this a valid us of inheritance
cross module namespaces but...only because all our modules must depend
on puppet-openstacklib.

http://paste.openstack.org/show/473655


+1 for implementation in pastebin above. Much better solution than 
running function.


Regards,
Martin





__
OpenStack Development Mailing 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] [sahara] fixing python-saharaclient gate jobs

[Doug Hellmann]

It looks like all of the python-saharaclient gate jobs are failing
because of some new checks added to devstack to ensure the LIBS_FROM_GIT
feature is fully configured properly in a given job. The jobs for
python-saharaclient do not install the client from source because
they're running in a configuration without sahara at all.

There is some discussion about how to fix that in the openstack-qa
channel logs starting from [1]. The solution is complex enough that
the Sahara team infra liaison should be involved to ensure that the
correct jobs are updated.

Doug

[1] 
http://eavesdrop.openstack.org/irclogs/%23openstack-qa/%23openstack-qa.2015-09-23.log.html#t2015-09-23T15:04:52

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

Re: [openstack-dev] [sahara][trove] fixing client gate jobs

[Doug Hellmann]

> On Sep 23, 2015, at 11:25 AM, Doug Hellmann  wrote:
> 
> It looks like all of the python-saharaclient gate jobs are failing
> because of some new checks added to devstack to ensure the LIBS_FROM_GIT
> feature is fully configured properly in a given job. The jobs for
> python-saharaclient do not install the client from source because
> they're running in a configuration without sahara at all.
> 
> There is some discussion about how to fix that in the openstack-qa
> channel logs starting from [1]. The solution is complex enough that
> the Sahara team infra liaison should be involved to ensure that the
> correct jobs are updated.
> 
> Doug
> 
> [1] 
> http://eavesdrop.openstack.org/irclogs/%23openstack-qa/%23openstack-qa.2015-09-23.log.html#t2015-09-23T15:04:52

The same problem appears to affect python-troveclient, so adding their project 
tag to the subject.

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] [poppy] Nominate Sriram Madupasi Vasudevan for Poppy (CDN) to Core

[Amit Gandhi]

I have received a majority vote for Sriram, and would like to congratulate 
Sriram for being elevated to Core status on Poppy.

Amit.


From: Malini Kamalambal 
>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Monday, September 21, 2015 at 8:50 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Subject: Re: [openstack-dev] [poppy] Nominate Sriram Madupasi Vasudevan for 
Poppy (CDN) to Core

+2

From: Amit Gandhi >
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Monday, September 21, 2015 at 5:20 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Subject: [openstack-dev] [poppy] Nominate Sriram Madupasi Vasudevan for Poppy 
(CDN) to Core

All,

I would like to nominate Sriram Madupasi Vasudevan (thesriram) [1] to Core for 
Poppy (CDN) [2].

Sriram has worked on the project for the past 12 months, and has been 
instrumental in building out various features and resolving bugs for the team.

Please respond with your votes.

Thanks
Amit.

[1] http://stackalytics.com/?release=all_type=stackforge=poppy
[2] http://www.poppycdn.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] [poppy] Nominate Tony Tan for Poppy (CDN) Core

[Amit Gandhi]

I have received a majority vote for Tony, and would like to congratulate Tony 
Tan for being elevated to Core status on Poppy.

Amit.


From: Malini Kamalambal 
>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Monday, September 21, 2015 at 8:50 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Subject: Re: [openstack-dev] [poppy] Nominate Tony Tan for Poppy (CDN) Core

+2

From: Amit Gandhi >
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Monday, September 21, 2015 at 5:22 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Subject: [openstack-dev] [poppy] Nominate Tony Tan for Poppy (CDN) Core

All,

I would like to nominate Tony Tan (tonytan4ever) [1] to Core for Poppy (CDN) 
[2].

Tony has worked on the project for the past 12 months, and has been 
instrumental in building out various features and resolving bugs for the team.  
He has written the majority of the Akamai driver and has been working hard to 
bring SSL integration to the workflow.

Please respond with your votes.

Thanks
Amit.

[1] http://stackalytics.com/?release=all_type=stackforge=poppy
[2] http://www.poppycdn.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] [nova] How to properly detect and fence a compromised host (and why I dislike TrustedFilter)

[Matt Riedemann]

On 9/23/2015 10:00 AM, Sylvain Bauza wrote:



Le 23/09/2015 15:31, Matt Riedemann a écrit :



On 6/25/2015 3:59 AM, Sylvain Bauza wrote:



Le 24/06/2015 19:56, Joe Gordon a écrit :



On Tue, Jun 23, 2015 at 3:41 AM, Sylvain Bauza > wrote:

Hi team,

Some discussion occurred over IRC about a bug which was publicly
open related to TrustedFilter [1]
I want to take the opportunity for raising my concerns about that
specific filter, why I dislike it and how I think we could improve
the situation - and clarify everyone's thoughts)

The current situation is that way : Nova only checks if one host
is compromised only when the scheduler is called, ie. only when
booting/migrating/evacuating/unshelving an instance (well, not
exactly all the evacuate/live-migrate cases, but let's not discuss
about that now). When the request goes in the scheduler, all the
hosts are checked against all the enabled filters and the
TrustedFilter is making an external HTTP(S) call to the
Attestation API service (not handled by Nova) for *each host* to
see if the host is valid (not compromised) or not.

To be clear, that's the only in-tree scheduler filter which
explicitly does an external call to a separate service that Nova
is not managing. I can see at least 3 reasons for thinking about
why it's bad :

#1 : that's a terrible bottleneck for performance, because we're
IO-blocking N times given N hosts (we're even not multiplexing the
HTTP requests)
#2 : all the filters are checking an internal Nova state for the
host (called HostState) but that the TrustedFilter, which means
that conceptually we defer the decision to a 3rd-party engine
#3 : that Attestation API services becomes a de facto dependency
for Nova (since it's an in-tree filter) while it's not listed as a
dependency and thus not gated.


All of these reasons could be acceptable if that would cover the
exposed usecase given in [1] (ie. I want to make sure that if my
host gets compromised, my instances will not be running on that
host) but that just doesn't work, due to the situation I mentioned
above.

So, given that, here are my thoughts :
a/ if a host gets compromised, we can just disable its service to
prevent its election as a valid destination host. There is no need
for a specialised filter.
b/ if a host is compromised, we can assume that the instances have
to resurrect elsewhere, ie. we can call a nova evacuate
c/ checking if an host is compromised or not is not a Nova
responsibility since it's already perfectly done by [2]

In other words, I'm considering that "security" usecase as
something analog as the HA usecase [3] where we need a 3rd-party
tool responsible for periodically checking the state of the hosts,
and if compromised then call the Nova API for fencing the host and
evacuating the compromised instances.

Given that, I'm proposing to deprecate TrustedFilter and explictly
mention to drop it from in-tree in a later cycle
https://review.openstack.org/194592


Given people are using this, it is a negligible maintenance burden.  I
think deprecating with the intention of removing is not worth it.

Although it would be very useful to further document the risks with
this filter (live migration, possible performance issues etc.)


Well, I can understand that customers could not be agreeing to remove
the filter because there is no clear alternative for them. That said, I
think saying that the filter is deprecated without saying when it would
be removed would help some contributors thinking about that and working
on a better solution, exactly like we did for EC2 API.

To be clear, I want to freeze the filter by deprecating it and
explaining why it's wrong (by amending the devref section and giving a
LOG warning saying it's deprecated) and then leave the filter within
in-tree unless we are sure that there is a good solution out of Nova.

-Sylvain





Thoughts ?
-Sylvain



[1] https://bugs.launchpad.net/nova/+bug/1456228
[2] https://github.com/OpenAttestation/OpenAttestation
[3]
http://blog.russellbryant.net/2014/10/15/openstack-instance-ha-proposal/



__

OpenStack Development Mailing 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] [ops] Operator Local Patches

[Kris G. Lindgren]

Cross-posting to the dev list as well for better coverage.

___
Kris Lindgren
Senior Linux Systems Engineer
GoDaddy

From: "Kris G. Lindgren"
Date: Tuesday, September 22, 2015 at 4:21 PM
To: openstack-operators
Subject: Re: Operator Local Patches

Hello all,

Friendly reminder: If you have local patches and haven't yet done so, please 
contribute to the etherpad at: 
https://etherpad.openstack.org/p/operator-local-patches

___
Kris Lindgren
Senior Linux Systems Engineer
GoDaddy

From: "Kris G. Lindgren"
Date: Friday, September 18, 2015 at 4:35 PM
To: openstack-operators
Cc: Tom Fifield
Subject: Operator Local Patches

Hello Operators!

During the ops meetup in Palo Alto were we talking about sessions for Tokyo. A 
session that I purposed, that got a bunch of +1's,  was about local patches 
that operators were carrying.  From my experience this is done to either 
implement business logic,  fix assumptions in projects that do not apply to 
your implementation, implement business requirements that are not yet 
implemented in openstack, or fix scale related bugs.  What I would like to do 
is get a working group together to do the following:

1.) Document local patches that operators have (even those that are in gerrit 
right now waiting to be committed upstream)
2.) Figure out commonality in those patches
3.) Either upstream the common fixes to the appropriate projects or figure out 
if a hook can be added to allow people to run their code at that specific point
4.) 
5.) Profit

To start this off, I have documented every patch, along with a description of 
what it does and why we did it (where needed), that GoDaddy is running [1].  
What I am asking is that the operator community please update the etherpad with 
the patches that you are running, so that we have a good starting point for 
discussions in Tokyo and beyond.

[1] - https://etherpad.openstack.org/p/operator-local-patches
___
Kris Lindgren
Senior Linux Systems Engineer
GoDaddy
__
OpenStack Development Mailing List (not for 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] where the aggregate and cell document is

[Matt Riedemann]

On 9/23/2015 6:32 AM, gong_ys2004 wrote:

Hi stackers,
I want to set up cell and aggregator env, but I failed to find the
document about them.
could you please help me to find the document?

regards,
yong sheng gong


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



Go here:

http://docs.openstack.org/

There is a search box.  Enter 'aggregate' or 'cells' and hit Enter. 
You'll get results.


You can also find things about aggregates and cells in the nova devref:

http://docs.openstack.org/developer/nova/

--

Thanks,

Matt Riedemann


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

Re: [openstack-dev] [puppet] service default value functions

[Cody Herriges]

Alex Schultz wrote:
>> I've been mulling this over the last several days and I just can't
>> accept an entire ruby function which would be ran for every parameter
>> with the desired static value of "" when the class is
>> declared and parsed.  I am not generally against using functions as a
>> parameter default just not a fan in this case because running ruby just
>> to return a static string seems inappropriate and not optimal.
>>
>> In this specific case I think the params pattern and inheritance can
>> obtain us the same goals.  I also find this a valid us of inheritance
>> cross module namespaces but...only because all our modules must depend
>> on puppet-openstacklib.
>>
>> http://paste.openstack.org/show/473655
>>
> 
> Yes after thinking it over, I agree that the function for a parameter
> is probably not the best route.  I think going the inheritance route
> is a much more established pattern and would make more sense.
> 
> Just throwing this out there, another option could be using a fact in
> puppet-openstacklib. We could create an os_service_default fact or
> something named similarly that would be a static constant that could
> be used for a parameter default and we could leverage it as part of
> the is_service_default() function.  We would still require
> puppet-openstacklib be included but we wouldn't need to do all the
> inherits in the classes.  Just a thought.
> 

That is a viable option.  I can't recall which versions of puppet
support facts.d but if all that we support do we could even make it 100%
static and just put a file on disk with the contents
"servicedefault=''.

-- 
Cody



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

Re: [openstack-dev] [puppet] service default value functions

[Alex Schultz]

On Wed, Sep 23, 2015 at 11:46 AM, Cody Herriges  wrote:
> Alex Schultz wrote:
>>> I've been mulling this over the last several days and I just can't
>>> accept an entire ruby function which would be ran for every parameter
>>> with the desired static value of "" when the class is
>>> declared and parsed.  I am not generally against using functions as a
>>> parameter default just not a fan in this case because running ruby just
>>> to return a static string seems inappropriate and not optimal.
>>>
>>> In this specific case I think the params pattern and inheritance can
>>> obtain us the same goals.  I also find this a valid us of inheritance
>>> cross module namespaces but...only because all our modules must depend
>>> on puppet-openstacklib.
>>>
>>> http://paste.openstack.org/show/473655
>>>
>>
>> Yes after thinking it over, I agree that the function for a parameter
>> is probably not the best route.  I think going the inheritance route
>> is a much more established pattern and would make more sense.
>>
>> Just throwing this out there, another option could be using a fact in
>> puppet-openstacklib. We could create an os_service_default fact or
>> something named similarly that would be a static constant that could
>> be used for a parameter default and we could leverage it as part of
>> the is_service_default() function.  We would still require
>> puppet-openstacklib be included but we wouldn't need to do all the
>> inherits in the classes.  Just a thought.
>>
>
> That is a viable option.  I can't recall which versions of puppet
> support facts.d but if all that we support do we could even make it 100%
> static and just put a file on disk with the contents
> "servicedefault=''.
>


I think it was 3.3 or 3.4 which are our minimums I believe.

-Alex

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

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

[openstack-dev] [QA] Mitaka Summit Session Planning

[Matthew Treinish]

Hi Everyone,

I started an etherpad to track ideas for summit sessions:

https://etherpad.openstack.org/p/mitaka-qa-summit-topics

If you have an idea for a session feel free to add it to the etherpad.

As we get closer to summit we'll dedicate a QA meeting to selecting
which topics we'll have sessions on.

Thanks,

Matt Treinish


signature.asc
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] Consistent support for SSL termination proxies across all API services

[Sean Dague]

On 09/23/2015 07:36 AM, Julien Danjou wrote:
> On Wed, Sep 23 2015, Sean Dague wrote:
> 
>> Does that solution work in the HA Proxy case where there is one
>> terminating address for multiple backend servers?
> 
> Yep.

Ok, how exactly does that work? Because it seems like
oslo_middleware.ssl is only changing the protocol if the proxy sets it.

But the host in the urls will still be the individual host, which isn't
the proxy hostname/ip. Sorry if I'm being daft here, just want to
understand how that flow ends up working.

>> Because there is the concern that this impacts not only the Location
>> header, but the link documents inside the responses which clients are
>> expected to be able to link.follow. This is an honest question, I
>> don't know how the oslo_middleware.ssl acts in these cases. And HA
>> Proxy 1 to N mapping is very common deployment model.
> 
> It should, but some project like Keystone does not handle that
> correctly. I just submitted a patch that fixes this kind of thing by
> using correctly the WSGI environment variable to build a correct URL.
> That fixes also the use cases where Keystone does not run on / but on
> e.g. /identity (the bug I initially wanted to fix).
> 
>   https://review.openstack.org/#/c/226464/
> 
> If you use `wsgiref.util.application_uri(environment)' it should do
> everything correctly. With the SSL middleware enabled that Mathieu
> talked about, it will translate correctly http to https too.

Will that cover the case of webob's request.application_uri? If so I
think that covers the REST documents in at least Nova (one good data
point, and one that I know has been copied around). At least as far as
the protocol is concerned, it's still got a potential url issue.

> The {public,admin}_endpoint are only useful in the case where you map
> http://myproxy/identity -> http://mykeystone/ using a proxy
> 
> Because the prefix is not passed to Keystone. If you map 1:1 the path
> part, we could also leverage X-Forwarded-Host and X-Forwarded-Port to
> avoid having {public,admin}_endpoint options.

It also looks like there are new standards for Forwarded headers, so the
middleware should probably support those as well.
http://tools.ietf.org/html/rfc7239.

-Sean

-- 
Sean Dague
http://dague.net



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] [nova][cinder] how to handle AZ bug 1496235?

[Ivan Kolodyazhny]

Hi Matt,

In Liberty, we introduced allow_availability_zone_fallback [1] option in
Cinder config as fix for bug [2]. If you set this option, Cinder will
create volume in a default AZ instead of set volume into the error state

[1]
https://github.com/openstack/cinder/commit/b85d2812a8256ff82934d150dbc4909e041d8b31
[2] https://bugs.launchpad.net/cinder/+bug/1489575

Regards,
Ivan Kolodyazhny

On Wed, Sep 23, 2015 at 9:00 PM, Matt Riedemann 
wrote:

> I came across bug 1496235 [1] today.  In this case the user is booting an
> instance from a volume using source=image, so nova actually does the volume
> create call to the volume API.  They are booting the instance into a valid
> nova availability zone, but that same AZ isn't defined in Cinder, so the
> volume create request fails (since nova passes the instance AZ to cinder
> [2]).
>
> I marked this as invalid given how the code works.
>
> I'm posting here since I'm wondering if there are alternatives worth
> pursuing.  For example, nova could get the list of AZs from the volume API
> and if the nova AZ isn't in that list, don't provide it on the volume
> create request.  That's essentially the same as first creating the volume
> outside of nova and not specifying an AZ, then when doing the boot from
> volume, provide the volume_id as the source.
>
> The question is, is it worth doing that?  I'm not familiar enough with how
> availability zones are meant to work between nova and cinder so it's hard
> for me to have much of an opinion here.
>
> [1] https://bugs.launchpad.net/nova/+bug/1496235
> [2]
> https://github.com/openstack/nova/blob/master/nova/virt/block_device.py#L381-L383
>
> --
>
> Thanks,
>
> Matt Riedemann
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] New PyCharm License

[David_Paterson]

Dell - Internal Use - Confidential

Launchpad id: davpat2112

Thanks,
David
From: Andrew Melton [mailto:andrew.mel...@rackspace.com]
Sent: Monday, September 21, 2015 10:54 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] New PyCharm License


Hi devs,



I've got the new license for the next year. As always, please reply to this 
email with your launchpad-id if you would like a license.



Also, if there are other JetBrains products you use to contribute to OpenStack, 
please let me know and I will request licenses.

​

--Andrew
__
OpenStack Development Mailing List (not for 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] Criteria for applying vulnerability:managed tag

[Jeremy Stanley]

On 2015-09-01 18:56:38 + (+), Jeremy Stanley wrote:
[...]
> In the spirit of proper transparency, I'm initiating a frank and
> open dialogue on what our criteria for direct vulnerability
> management within the VMT would require of a deliverable and its
> controlling project-team.
[...]

Since there's been no further discussion on the thread for at least
a couple weeks, I've proposed https://review.openstack.org/226869 to
formalize this in governance. Please direct further followup
comments to the review. Thanks!
-- 
Jeremy Stanley

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

Re: [openstack-dev] [neutron][lbaas] - Heat support for LbaasV2

[Fox, Kevin M]

One of the weird things about the lbaasv1 vs v2 thing which is different from 
just about every other v1->v2 change I've seen is v1 and v2 lb's are totally 
separate things. Unlike, say cinder, where doing a list volumes would show up 
in both api's, so upgrading is smooth.

Thanks,
Kevin

From: Sergey Kraynev [skray...@mirantis.com]
Sent: Wednesday, September 23, 2015 11:09 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron][lbaas] - Heat support for LbaasV2

Guys. I happy, that you already discussed it here :)
However, I'd like to raise same question on our Heat IRC meeting.
Probably we should define some common concepts, because I think, that lbaas is 
not single example of service with
several APIs.
I will post update in this thread later (after meeting).

Regards,
Sergey.

On 23 September 2015 at 14:37, Fox, Kevin M 
> wrote:
Seperate ns would work great.

Thanks,
Kevin


From: Banashankar KV
Sent: Tuesday, September 22, 2015 9:14:35 PM

To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron][lbaas] - Heat support for LbaasV2

What you think about separating both of them with the name as Doug mentioned. 
In future if we want to get rid of the v1 we can just remove that namespace. 
Everything will be clean.

Thanks
Banashankar


On Tue, Sep 22, 2015 at 6:01 PM, Fox, Kevin M 
> wrote:
As I understand it, loadbalancer in v2 is more like pool was in v1. Can we make 
it such that if you are using the loadbalancer resource and have the mandatory 
v2 properties that it tries to use v2 api, otherwise its a v1 resource? 
PoolMember should be ok being the same. It just needs to call v1 or v2 
depending on if the lb its pointing at is v1 or v2. Is monitor's api different 
between them? Can it be like pool member?

Thanks,
Kevin


From: Brandon Logan
Sent: Tuesday, September 22, 2015 5:39:03 PM

To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [neutron][lbaas] - Heat support for LbaasV2

So for the API v1s api is of the structure:

/lb/(vip|pool|member|health_monitor)

V2s is:
/lbaas/(loadbalancer|listener|pool|healthmonitor)

member is a child of pool, so it would go down one level.

The only difference is the lb for v1 and lbaas for v2.  Not sure if that
is enough of a different.

Thanks,
Brandon
On Tue, 2015-09-22 at 23:48 +, Fox, Kevin M wrote:
> Thats the problem. :/
>
> I can't think of a way to have them coexist without: breaking old
> templates, including v2 in the name, or having a flag on the resource
> saying the version is v2. And as an app developer I'd rather not have
> my existing templates break.
>
> I haven't compared the api's at all, but is there a required field of
> v2 that is different enough from v1 that by its simple existence in
> the resource you can tell a v2 from a v1 object? Would something like
> that work? PoolMember wouldn't have to change, the same resource could
> probably work for whatever lb it was pointing at I'm guessing.
>
> Thanks,
> Kevin
>
>
>
> __
> From: Banashankar KV [banvee...@gmail.com]
> Sent: Tuesday, September 22, 2015 4:40 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [neutron][lbaas] - Heat support for
> LbaasV2
>
>
>
> Ok, sounds good. So now the question is how should we name the new V2
> resources ?
>
>
>
> Thanks
> Banashankar
>
>
>
> On Tue, Sep 22, 2015 at 4:33 PM, Fox, Kevin M 
> >
> wrote:
> Yes, hence the need to support the v2 resources as seperate
> things. Then I can rewrite the templates to include the new
> resources rather then the old resources as appropriate. IE, it
> will be a porting effort to rewrite them. Then do a heat
> update on the stack to migrate it from lbv1 to lbv2. Since
> they are different resources, it should create the new and
> delete the old.
>
> Thanks,
> Kevin
>
>
> __
> From: Banashankar KV [banvee...@gmail.com]
> Sent: Tuesday, September 22, 2015 4:16 PM
>
> To: OpenStack Development Mailing List (not for usage
> questions)
> Subject: Re: [openstack-dev] [neutron][lbaas] - Heat support
> for LbaasV2
>
>
>
>
> But I think, V2 has introduced some new components and whole
> association of the resources with each other is changed, we
> should be still able to do what Kevin has mentioned ?
>
> Thanks
> Banashankar
>
>
>
> On 

[openstack-dev] [Security] Weekly Meeting Agenda

[Clark, Robert Graham]

Hi All,

I won't be available to run the weekly meeting tomorrow as I'm out travelling, 
Michael McCune (elmiko) has volunteered to lead the meeting.

There's IRC information on our wiki page : 
https://wiki.openstack.org/wiki/Security

Agenda items (Please reply to add any more):

*PTL Shenanigans : https://review.openstack.org/#/c/224798/

*VMT Project Tracking : https://review.openstack.org/#/c/226869/

*Anchor (Ephemeral PKI)

*Bandit (Security Linter)

*Developer Guidance (Don't do this)

*Security Documents (Do do this)

*Security Notes (Think about not doing this)

*Syntribos (API Fuzzing)

*Any Other Business

Have a good meeting all!

-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] [nova][cinder] how to handle AZ bug 1496235?

[John Griffith]

On Wed, Sep 23, 2015 at 1:34 PM, Matt Riedemann 
wrote:

>
>
> On 9/23/2015 2:15 PM, Matt Riedemann wrote:
>
>>
>>
>> On 9/23/2015 1:46 PM, Ivan Kolodyazhny wrote:
>>
>>> Hi Matt,
>>>
>>> In Liberty, we introduced allow_availability_zone_fallback [1] option in
>>> Cinder config as fix for bug [2]. If you set this option, Cinder will
>>> create volume in a default AZ instead of set volume into the error state
>>>
>>> [1]
>>>
>>> https://github.com/openstack/cinder/commit/b85d2812a8256ff82934d150dbc4909e041d8b31
>>>
>>> [2] https://bugs.launchpad.net/cinder/+bug/1489575
>>>
>>> Regards,
>>> Ivan Kolodyazhny
>>>
>>> On Wed, Sep 23, 2015 at 9:00 PM, Matt Riedemann
>>> > wrote:
>>>
>>> I came across bug 1496235 [1] today.  In this case the user is
>>> booting an instance from a volume using source=image, so nova
>>> actually does the volume create call to the volume API.  They are
>>> booting the instance into a valid nova availability zone, but that
>>> same AZ isn't defined in Cinder, so the volume create request fails
>>> (since nova passes the instance AZ to cinder [2]).
>>>
>>> I marked this as invalid given how the code works.
>>>
>>> I'm posting here since I'm wondering if there are alternatives worth
>>> pursuing.  For example, nova could get the list of AZs from the
>>> volume API and if the nova AZ isn't in that list, don't provide it
>>> on the volume create request.  That's essentially the same as first
>>> creating the volume outside of nova and not specifying an AZ, then
>>> when doing the boot from volume, provide the volume_id as the source.
>>>
>>> The question is, is it worth doing that?  I'm not familiar enough
>>> with how availability zones are meant to work between nova and
>>> cinder so it's hard for me to have much of an opinion here.
>>>
>>> [1] https://bugs.launchpad.net/nova/+bug/1496235
>>> [2]
>>>
>>>
>>> https://github.com/openstack/nova/blob/master/nova/virt/block_device.py#L381-L383
>>>
>>>
>>> --
>>>
>>> Thanks,
>>>
>>> Matt Riedemann
>>>
>>>
>>>
>>>
>>> __
>>>
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>>
>>> 
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>>
>>>
>>>
>>> __
>>>
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>> Sorry but that seems like a hack.
>>
>> I'm trying to figure out the relationship between AZs in nova and cinder
>> and so far no one seems to really know.  In the cinder IRC channel I was
>> told there isn't one, which would mean we shouldn't even try creating
>> the volume using the server instance AZ.
>>
>> Also, if there is no relationship, I was trying to figure out why there
>> is the cinder.cross_az_attach config option.  That was added in grizzly
>> [1].  I was thinking maybe it was a legacy artifact from nova-volume,
>> but that was dropped in grizzly.
>>
>> So is cinder.cross_az_attach even useful?
>>
>> [1] https://review.openstack.org/#/c/21672/
>>
>>
> The plot thickens.
>
> I was checking to see what change was made to start passing the server
> instance az on the volume create call during boot from volume, and that was
> [1] which was added in kilo to fix a bug where boot from volume into a nova
> az will fail if cinder.cross_az_attach=False and storage_availability_zone
> is set in cinder.conf.
>
> So I guess we can't just stop passing the instance az to the volume create
> call.
>
> But what I'd really like to know is how this is all used between cinder
> and nova, or was this all some work done as part of a larger effort that
> was never completed?  Basically, can we deprecate the
> cinder.cross_az_attach config option in nova and start decoupling this code?
>
> [1] https://review.openstack.org/#/c/157041/
>
>
> --
>
> Thanks,
>
> Matt Riedemann
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
​To be honest this is probably my fault, AZ's were pulled in as part of the
nova-volume migration to Cinder and just sort of died.  Quite frankly I
wasn't sure "what" to do with them but brought over the concept and the
zones that existing in Nova-Volume.  It's been an issue since day 1 of
Cinder, and 

[openstack-dev] [nova][cinder] how to handle AZ bug 1496235?

[Matt Riedemann]

I came across bug 1496235 [1] today.  In this case the user is booting 
an instance from a volume using source=image, so nova actually does the 
volume create call to the volume API.  They are booting the instance 
into a valid nova availability zone, but that same AZ isn't defined in 
Cinder, so the volume create request fails (since nova passes the 
instance AZ to cinder [2]).


I marked this as invalid given how the code works.

I'm posting here since I'm wondering if there are alternatives worth 
pursuing.  For example, nova could get the list of AZs from the volume 
API and if the nova AZ isn't in that list, don't provide it on the 
volume create request.  That's essentially the same as first creating 
the volume outside of nova and not specifying an AZ, then when doing the 
boot from volume, provide the volume_id as the source.


The question is, is it worth doing that?  I'm not familiar enough with 
how availability zones are meant to work between nova and cinder so it's 
hard for me to have much of an opinion here.


[1] https://bugs.launchpad.net/nova/+bug/1496235
[2] 
https://github.com/openstack/nova/blob/master/nova/virt/block_device.py#L381-L383


--

Thanks,

Matt Riedemann


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

Re: [openstack-dev] [Openstack-operators] [Large Deployments Team][Performance Team] New informal working group suggestion

[Kris G. Lindgren]

Dina,

Do we have a place to put things (etherpad) that we are seeing performance 
issues with?  I know we are seeing issues with CPU load under nova-conductor as 
well as some stuff with the neutron API timing out (seems like it never 
responds to the request (no log entry on the neutron side).

___
Kris Lindgren
Senior Linux Systems Engineer
GoDaddy

From: Matt Van Winkle
Date: Tuesday, September 22, 2015 at 7:46 AM
To: Dina Belova, OpenStack Development Mailing List, 
"openstack-operat...@lists.openstack.org"
Subject: Re: [Openstack-operators] [Large Deployments Team][Performance Team] 
New informal working group suggestion

Thanks, Dina!

For context to the rest of the LDT folks, Dina reached out to me about working 
on this under our umbrella for now.  It made sense until we understand if it's 
a large enough thing to live as its own working group because most of us have 
various performance concerns too.  So, like Public Clouds, we'll have to figure 
out how to integrate this sub group.

I suspect the time slot for Tokyo is already packed, so the work for the 
Performance subgroup may have to be informal or in other sessions, but I'll 
start working with Tom and the folks covering the session for me (since I won't 
be able to make it) on what we might be able to do.  I've also asked Dina to 
join the Oct meeting prior to the Summit so we can further discuss the sub team.

Thanks!
VW

From: Dina Belova >
Date: Tuesday, September 22, 2015 7:57 AM
To: OpenStack Development Mailing List 
>, 
"openstack-operat...@lists.openstack.org"
 
>
Subject: [Large Deployments Team][Performance Team] New informal working group 
suggestion

Hey, OpenStackers!

I'm writing to propose to organise new informal team to work specifically on 
the OpenStack performance issues. This will be a sub team in already existing 
Large Deployments Team, and I suppose it will be a good idea to gather people 
interested in OpenStack performance in one room and identify what issues are 
worrying contributors, what can be done and share results of performance 
researches :)

So please volunteer to take part in this initiative. I hope it will be many 
people interested and we'll be able to use cross-projects session 
slot to meet in Tokyo and hold a 
kick-off meeting.

I would like to apologise I'm writing to two mailing lists at the same time, 
but I want to make sure that all possibly interested people will notice the 
email.

Thanks and see you in Tokyo :)

Cheers,
Dina

--

Best regards,

Dina Belova

Senior Software Engineer

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

[openstack-dev] [OSSN 0053] Keystone token disclosure may result in malicious trust creation

[Nathan Kinder]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Keystone token disclosure may result in malicious trust creation
- ---

### Summary ###
Keystone tokens are the foundation of authentication and authorization
in OpenStack. When a service node is compromised, it is possible that
an attacker would have access to all tokens passing through that node.
With a valid token an attacker will be able to issue new tokens that
may be used to create trusts between the originating user and a new
user.

### Affected Services / Software ###
Keystone, Grizzly, Havana, Icehouse, Juno, Kilo

### Discussion ###
If a service node is compromised, an attacker now has access to every
token that passes through that node. By default, a Keystone token can
be exchanged for another token, and there is no restriction on scoping
of the new token. With the trust API, these tokens can be used to
delegate roles between the original user and a new user.

Trusts allow a user to set up a long term delegation that permits
another user to perform operations on their behalf. While tokens
created through trusts are limited in what they can do, the
limitations are only on things like changing passwords or creating
new tokens. This would grant an attacker access to all the operations
available to the originating user in their projects, and the roles that
are delegated through the trust.

There are other ways that a compromised token can be misused beyond the
methods described here. This note addresses one possible path for
vulnerabilities based on the unintended access that could be gained
from trusts created through intercepted tokens.

This behavior is intrinsic to the bearer token model used within
Keystone / OpenStack.

### Recommended Actions ###
The following steps are recommended to reduce exposure, based on the
granularity and accepted level of risk in a given environment:

1. Monitor and audit trust creation events within your environment.
Keystone emits notifications on trust creation and deletion that are
accessible through system logs or, if configured, the CADF
data/security/trust resource extension.

2. Offer roles that cannot create trusts / delegate permissions /
assign new roles via Keystone to users. This limits the vector of
attack to compromising Keystone directly or man-in-the-middle capture
of a separate token that has the authorization to create
trusts/delegate/assign roles.

3. Retain the default token lifespan of 1 hour.  Many workloads require
a single token for the whole workload, and take more than one hour, so
installations have increased token lifespans back to the old value of
24 hours - increasing their exposure to this issue.

### Contacts / References ###
This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0053
Original LaunchPad Bug : https://bugs.launchpad.net/keystone/+bug/145558
2
OpenStack Security ML : openstack-secur...@lists.openstack.org
OpenStack Security Group : https://launchpad.net/~openstack-ossg
Hierarchical Roles : https://review.openstack.org/#/c/125704
Policy by URL : https://review.openstack.org/#/c/192422
Unified policy file : https://review.openstack.org/#/c/134656
Endpoint_ID from URL : https://review.openstack.org/#/c/199844
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJWAv74AAoJEJa+6E7Ri+EV3IcH/jv2OGH4fcPz6ftTLbvDgS2T
+5j+Os43ME5KRPIzqgcsQwga3Vse8dSIf8OAiJehqsfuB5wt/nmooFikE56WA/ah
m7fn6g20KmHdGF9EVBaOwhSBFStN9bGDffmR1tEdJ4Z/9rGDYQCOl3/KbUdXyLMr
/WrrBPu2MgeM9XcnyxN+fXhRWp4W2t5MmQCsXky14grtyY1hPmC03wZ98qUZR9CE
KT3UEmtLqG7rfy6UN8msndNeHTj2ZdWiZUc5Og2F/DROIh3KHAbHxl+oi/AqkbXX
ABoVGY2g0PSI1par25mYpOMX1D5k/Pe1DAcMfG07f1xvYwSZfieTDTCSL6yuwq8=
=O6MG
-END PGP SIGNATURE-

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

Re: [openstack-dev] [Openstack-operators] [Large Deployments Team][Performance Team] New informal working group suggestion

[Dina Belova]

Kris,

I've created a ether pad - we can fill it with data before the summit and
discuss them in Tokyo.
https://etherpad.openstack.org/p/openstack-performance-issues

Cheers,
Dina

On Wed, Sep 23, 2015 at 9:32 PM, Kris G. Lindgren 
wrote:

> Dina,
>
> Do we have a place to put things (etherpad) that we are seeing performance
> issues with?  I know we are seeing issues with CPU load under
> nova-conductor as well as some stuff with the neutron API timing out (seems
> like it never responds to the request (no log entry on the neutron side).
>
> ___
> Kris Lindgren
> Senior Linux Systems Engineer
> GoDaddy
>
> From: Matt Van Winkle
> Date: Tuesday, September 22, 2015 at 7:46 AM
> To: Dina Belova, OpenStack Development Mailing List, "
> openstack-operat...@lists.openstack.org"
> Subject: Re: [Openstack-operators] [Large Deployments Team][Performance
> Team] New informal working group suggestion
>
> Thanks, Dina!
>
> For context to the rest of the LDT folks, Dina reached out to me about
> working on this under our umbrella for now.  It made sense until we
> understand if it's a large enough thing to live as its own working group
> because most of us have various performance concerns too.  So, like Public
> Clouds, we'll have to figure out how to integrate this sub group.
>
> I suspect the time slot for Tokyo is already packed, so the work for the
> Performance subgroup may have to be informal or in other sessions, but I'll
> start working with Tom and the folks covering the session for me (since I
> won't be able to make it) on what we might be able to do.  I've also asked
> Dina to join the Oct meeting prior to the Summit so we can further discuss
> the sub team.
>
> Thanks!
> VW
>
> From: Dina Belova 
> Date: Tuesday, September 22, 2015 7:57 AM
> To: OpenStack Development Mailing List ,
> "openstack-operat...@lists.openstack.org" <
> openstack-operat...@lists.openstack.org>
> Subject: [Large Deployments Team][Performance Team] New informal working
> group suggestion
>
> Hey, OpenStackers!
>
> I'm writing to propose to organise new informal team to work specifically
> on the OpenStack performance issues. This will be a sub team in already
> existing Large Deployments Team, and I suppose it will be a good idea to
> gather people interested in OpenStack performance in one room and identify
> what issues are worrying contributors, what can be done and share results
> of performance researches :)
>
> So please volunteer to take part in this initiative. I hope it will be
> many people interested and we'll be able to use cross-projects session
> slot  to meet in Tokyo and
> hold a kick-off meeting.
>
> I would like to apologise I'm writing to two mailing lists at the same
> time, but I want to make sure that all possibly interested people will
> notice the email.
>
> Thanks and see you in Tokyo :)
>
> Cheers,
> Dina
>
> --
>
> Best regards,
>
> Dina Belova
>
> Senior Software Engineer
>
> Mirantis Inc.
>
>


-- 

Best regards,

Dina Belova

Software Engineer

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

[openstack-dev] Mitaka travel tips ?

[David Moreau Simard]

There was a travel tips document for the Kilo summit in Paris [1].
Lots of great helpful information in there not covered on the Openstack
Summit page [2] like where to get SIM cards and stuff.

Is there one for Mitaka yet ? I can't find it.

[1] https://wiki.openstack.org/wiki/Design_Summit/Kilo/Travel_Tips
[2] https://www.openstack.org/summit/tokyo-2015/tokyo-and-travel/

David Moreau Simard
__
OpenStack Development Mailing List (not for 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] - Heat support for LbaasV2

[Sergey Kraynev]

Guys. I happy, that you already discussed it here :)
However, I'd like to raise same question on our Heat IRC meeting.
Probably we should define some common concepts, because I think, that lbaas
is not single example of service with
several APIs.
I will post update in this thread later (after meeting).

Regards,
Sergey.

On 23 September 2015 at 14:37, Fox, Kevin M  wrote:

> Seperate ns would work great.
>
> Thanks,
> Kevin
>
> --
> *From:* Banashankar KV
> *Sent:* Tuesday, September 22, 2015 9:14:35 PM
>
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [neutron][lbaas] - Heat support for LbaasV2
>
> What you think about separating both of them with the name as Doug
> mentioned. In future if we want to get rid of the v1 we can just remove
> that namespace. Everything will be clean.
>
> Thanks
> Banashankar
>
>
> On Tue, Sep 22, 2015 at 6:01 PM, Fox, Kevin M  wrote:
>
>> As I understand it, loadbalancer in v2 is more like pool was in v1. Can
>> we make it such that if you are using the loadbalancer resource and have
>> the mandatory v2 properties that it tries to use v2 api, otherwise its a v1
>> resource? PoolMember should be ok being the same. It just needs to call v1
>> or v2 depending on if the lb its pointing at is v1 or v2. Is monitor's api
>> different between them? Can it be like pool member?
>>
>> Thanks,
>> Kevin
>>
>> --
>> *From:* Brandon Logan
>> *Sent:* Tuesday, September 22, 2015 5:39:03 PM
>>
>> *To:* openstack-dev@lists.openstack.org
>> *Subject:* Re: [openstack-dev] [neutron][lbaas] - Heat support for
>> LbaasV2
>>
>> So for the API v1s api is of the structure:
>>
>> /lb/(vip|pool|member|health_monitor)
>>
>> V2s is:
>> /lbaas/(loadbalancer|listener|pool|healthmonitor)
>>
>> member is a child of pool, so it would go down one level.
>>
>> The only difference is the lb for v1 and lbaas for v2.  Not sure if that
>> is enough of a different.
>>
>> Thanks,
>> Brandon
>> On Tue, 2015-09-22 at 23:48 +, Fox, Kevin M wrote:
>> > Thats the problem. :/
>> >
>> > I can't think of a way to have them coexist without: breaking old
>> > templates, including v2 in the name, or having a flag on the resource
>> > saying the version is v2. And as an app developer I'd rather not have
>> > my existing templates break.
>> >
>> > I haven't compared the api's at all, but is there a required field of
>> > v2 that is different enough from v1 that by its simple existence in
>> > the resource you can tell a v2 from a v1 object? Would something like
>> > that work? PoolMember wouldn't have to change, the same resource could
>> > probably work for whatever lb it was pointing at I'm guessing.
>> >
>> > Thanks,
>> > Kevin
>> >
>> >
>> >
>> > __
>> > From: Banashankar KV [banvee...@gmail.com]
>> > Sent: Tuesday, September 22, 2015 4:40 PM
>> > To: OpenStack Development Mailing List (not for usage questions)
>> > Subject: Re: [openstack-dev] [neutron][lbaas] - Heat support for
>> > LbaasV2
>> >
>> >
>> >
>> > Ok, sounds good. So now the question is how should we name the new V2
>> > resources ?
>> >
>> >
>> >
>> > Thanks
>> > Banashankar
>> >
>> >
>> >
>> > On Tue, Sep 22, 2015 at 4:33 PM, Fox, Kevin M 
>> > wrote:
>> > Yes, hence the need to support the v2 resources as seperate
>> > things. Then I can rewrite the templates to include the new
>> > resources rather then the old resources as appropriate. IE, it
>> > will be a porting effort to rewrite them. Then do a heat
>> > update on the stack to migrate it from lbv1 to lbv2. Since
>> > they are different resources, it should create the new and
>> > delete the old.
>> >
>> > Thanks,
>> > Kevin
>> >
>> >
>> > __
>> > From: Banashankar KV [banvee...@gmail.com]
>> > Sent: Tuesday, September 22, 2015 4:16 PM
>> >
>> > To: OpenStack Development Mailing List (not for usage
>> > questions)
>> > Subject: Re: [openstack-dev] [neutron][lbaas] - Heat support
>> > for LbaasV2
>> >
>> >
>> >
>> >
>> > But I think, V2 has introduced some new components and whole
>> > association of the resources with each other is changed, we
>> > should be still able to do what Kevin has mentioned ?
>> >
>> > Thanks
>> > Banashankar
>> >
>> >
>> >
>> > On Tue, Sep 22, 2015 at 3:39 PM, Fox, Kevin M
>> >  wrote:
>> > There needs to be a way to have both v1 and v2
>> > supported in one engine
>> >
>> > Say I have templates that use v1 already in existence
>> > (I do), and I want to be able to heat stack update on
>> > them one 

Re: [openstack-dev] New PyCharm License

[Andrew Melton]

Hey Devs,

I now have a set of WebStorm licenses. Please reply with your launchpad-id and 
I'll get you the invitation link for WebStorm.

--Andrew

From: Andrew Melton 
Sent: Tuesday, September 22, 2015 1:43 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] New PyCharm License

Hey Devs,

Reply-All strikes again...

I've had to invalidate the old link. If you still need a PyCharm License, 
please reach out to me with your launchpad-id and I'll get you the updated link.

I'm also working on a WebStorm license. I'll let the list know when I have it.

--Andrew

From: Jim Rollenhagen 
Sent: Monday, September 21, 2015 3:19 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] New PyCharm License

On Mon, Sep 21, 2015 at 06:30:30PM +, Andrew Melton wrote:
> Please follow this link to request a license: 
> https://account.jetbrains.com/a/4c4ojw.
>
> You will need a JetBrains account to request the license. This link is open 
> for anyone to use, so please do not share it in the public. You may share it 
> with other OpenStack contributors on your team, but if you do, please send me 
> their launchpad-ids. Lastly, if you decide to stop using PyCharm, please send 
> me an email so I can revoke the license and open it up for use by someone 
> else.

Welp, it's in the public now. :(

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

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

Re: [openstack-dev] New PyCharm License

[OpenStack Mailing List Archive]

Link: https://openstack.nimeyo.com/59599/?show=59903#a59903
From: joonmyung 

Hello Andrew,

My Launchpad id is joon-myung-kang
Thanks,
Joon



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

Re: [openstack-dev] New PyCharm License

[Johnston, Nate]

Yes please - my launchpad ID is ‘nate-johnston’.

Thanks!

—N.

On Sep 21, 2015, at 10:54 AM, Andrew Melton 
> wrote:


Hi devs,


I've got the new license for the next year. As always, please reply to this 
email with your launchpad-id if you would like a license.


Also, if there are other JetBrains products you use to contribute to OpenStack, 
please let me know and I will request licenses.

​

--Andrew

__
OpenStack Development Mailing 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] [Security] Weekly Meeting Agenda

[michael mccune]

On 09/23/2015 02:56 PM, Clark, Robert Graham wrote:

Hi All,

I won’t be available to run the weekly meeting tomorrow as I’m out
travelling, Michael McCune (elmiko) has volunteered to lead the meeting.

There’s IRC information on our wiki page :
https://wiki.openstack.org/wiki/Security

Agenda items (Please reply to add any more):

·PTL Shenanigans : https://review.openstack.org/#/c/224798/

·VMT Project Tracking : https://review.openstack.org/#/c/226869/

·Anchor (Ephemeral PKI)

·Bandit (Security Linter)

·Developer Guidance (Don’t do this)

·Security Documents (Do do this)

·Security Notes (Think about not doing this)

·Syntribos (API Fuzzing)

·Any Other Business

*//*

Have a good meeting all!

-Rob


thanks 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] [nova][cinder] how to handle AZ bug 1496235?

[Matt Riedemann]

On 9/23/2015 1:46 PM, Ivan Kolodyazhny wrote:

Hi Matt,

In Liberty, we introduced allow_availability_zone_fallback [1] option in
Cinder config as fix for bug [2]. If you set this option, Cinder will
create volume in a default AZ instead of set volume into the error state

[1]
https://github.com/openstack/cinder/commit/b85d2812a8256ff82934d150dbc4909e041d8b31
[2] https://bugs.launchpad.net/cinder/+bug/1489575

Regards,
Ivan Kolodyazhny

On Wed, Sep 23, 2015 at 9:00 PM, Matt Riedemann
> wrote:

I came across bug 1496235 [1] today.  In this case the user is
booting an instance from a volume using source=image, so nova
actually does the volume create call to the volume API.  They are
booting the instance into a valid nova availability zone, but that
same AZ isn't defined in Cinder, so the volume create request fails
(since nova passes the instance AZ to cinder [2]).

I marked this as invalid given how the code works.

I'm posting here since I'm wondering if there are alternatives worth
pursuing.  For example, nova could get the list of AZs from the
volume API and if the nova AZ isn't in that list, don't provide it
on the volume create request.  That's essentially the same as first
creating the volume outside of nova and not specifying an AZ, then
when doing the boot from volume, provide the volume_id as the source.

The question is, is it worth doing that?  I'm not familiar enough
with how availability zones are meant to work between nova and
cinder so it's hard for me to have much of an opinion here.

[1] https://bugs.launchpad.net/nova/+bug/1496235
[2]

https://github.com/openstack/nova/blob/master/nova/virt/block_device.py#L381-L383

--

Thanks,

Matt Riedemann


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

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




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



Sorry but that seems like a hack.

I'm trying to figure out the relationship between AZs in nova and cinder 
and so far no one seems to really know.  In the cinder IRC channel I was 
told there isn't one, which would mean we shouldn't even try creating 
the volume using the server instance AZ.


Also, if there is no relationship, I was trying to figure out why there 
is the cinder.cross_az_attach config option.  That was added in grizzly 
[1].  I was thinking maybe it was a legacy artifact from nova-volume, 
but that was dropped in grizzly.


So is cinder.cross_az_attach even useful?

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

--

Thanks,

Matt Riedemann


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

[openstack-dev] [puppet][swift] Applying security recommendations within puppet-swift

[Alex Schultz]

Hey all,

So as part of the Puppet mid-cycle, we did bug triage.  One of the
bugs that was looked into was bug 1289631[0].  This bug is about
applying the recommendations from the security guide[1] within the
puppet-swift module.  So I'm sending a note out to get other feedback
on if this is a good idea or not.  Should we be applying this type of
security items within the puppet modules by default? Should we make
this optional?  Thoughts?


Thanks,
-Alex


[0] https://bugs.launchpad.net/puppet-swift/+bug/1289631
[1] 
http://docs.openstack.org/security-guide/object-storage.html#securing-services-general

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

Re: [openstack-dev] [puppet] service default value functions

[Emilien Macchi]

On 09/22/2015 08:17 PM, Cody Herriges wrote:
> Alex Schultz wrote:
>> Hey puppet folks,
>>
>> Based on the meeting yesterday[0], I had proposed creating a parser
>> function called is_service_default[1] to validate if a variable matched
>> our agreed upon value of ''.  This got me thinking
>> about how can we maybe not use the arbitrary string throughout the
>> puppet that can not easily be validated.  So I tested creating another
>> puppet function named service_default[2] to replace the use of '> DEFAULT>' throughout all the puppet modules.  My tests seemed to
>> indicate that you can use a parser function as parameter default for
>> classes. 
>>
>> I wanted to send a note to gather comments around the second function. 
>> When we originally discussed what to use to designate for a service's
>> default configuration, I really didn't like using an arbitrary string
>> since it's hard to parse and validate. I think leveraging a function
>> might be better since it is something that can be validated via tests
>> and a syntax checker.  Thoughts?
>>
>>
>> Thanks,
>> -Alex
>>
>> [0] 
>> http://eavesdrop.openstack.org/meetings/puppet_openstack/2015/puppet_openstack.2015-09-15-15.00.html
>> [1] https://review.openstack.org/#/c/223672
>> [2] https://review.openstack.org/#/c/224187
>>
> 
> I've been mulling this over the last several days and I just can't
> accept an entire ruby function which would be ran for every parameter
> with the desired static value of "" when the class is
> declared and parsed.  I am not generally against using functions as a
> parameter default just not a fan in this case because running ruby just
> to return a static string seems inappropriate and not optimal.
> 
> In this specific case I think the params pattern and inheritance can
> obtain us the same goals.  I also find this a valid us of inheritance
> cross module namespaces but...only because all our modules must depend
> on puppet-openstacklib.
> 
> http://paste.openstack.org/show/473655

+1 for this solution, which is straightforward and easy to
maintain/implement.
-1 for a fact which is (to me) more code and relying on puppet versions
is something a bit dangerous, even if facts.d are supported by our CI jobs.
-- 
Emilien Macchi



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

Re: [openstack-dev] [neutron + ovn] Does neutron ovn plugin support to setup multiple neutron networks for one container?

[WANG, Ming Hao (Tony T)]

Hi Russell,

Is there any material to explain how OVN parent port work?

Thanks,
Tony

-Original Message-
From: WANG, Ming Hao (Tony T) 
Sent: Wednesday, September 23, 2015 10:02 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: RE: [openstack-dev] [neutron] Does neutron ovn plugin support to setup 
multiple neutron networks for one container?

Russell,

Thanks for your info.
If I want to assign multiple interfaces to a container on different neutron 
networks(for example, netA and netB), is it mandatory to let the VM hosting 
containers have network interfaces in netA and netB, and ovn will help to 
direct the container traffic to its corresponding VM network interfaces?

from https://github.com/openvswitch/ovs/blob/master/ovn/CONTAINERS.OpenStack.md 
:
"This VLAN tag is stripped out in the hypervisor by OVN."
I suppose when the traffic goes out the VM, the VLAN tag has already been 
stripped out. 
When the traffic arrives ovs on physical host, it will be tagged with neutron 
local vlan. Is it right?

Thanks in advance,
Tony

-Original Message-
From: Russell Bryant [mailto:rbry...@redhat.com] 
Sent: Wednesday, September 23, 2015 12:46 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron] Does neutron ovn plugin support to setup 
multiple neutron networks for one container?

On 09/22/2015 08:08 AM, WANG, Ming Hao (Tony T) wrote:
> Dear all,
> 
> For neutron ovn plugin supports containers in one VM, My understanding is one 
> container can't be assigned two network interfaces in different neutron 
> networks. Is it right?
> The reason:
> 1. One host VM only has one network interface.
> 2. all the VLAN tags are stripped out when the packet goes out the VM.
> 
> If it is True, does neutron ovn plugin or ovn has plan to support this?

You should be able to assign multiple interfaces to a container on different 
networks.  The traffic for each interface will be tagged with a unique VLAN ID 
on its way in and out of the VM, the same way it is done for each container 
with a single interface.

--
Russell Bryant

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

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

Re: [openstack-dev] [nova] [api] Nova currently handles list with limit=0 quite different for different objects.

[Zhenyu Zheng]

Hi, Alex,

Thanks for the information, I was unable to join the conference yesterday.
Then lets get the dicision done before fix it.

BR,

Zheng

On Wed, Sep 23, 2015 at 12:56 PM, Alex Xu  wrote:

> Hi, Zhengyu,
>
> We discussed this in yesterday Nova API meeting. We think it should get
> consistent in API-WG.
>
> And there already have patch for pagination guideline
> https://review.openstack.org/190743 , and there also have some discussion
> on limits.
> So we are better waiting the guideline get consistent before fix it.
>
> Thanks
> Alex
>
> On Sep 23, 2015, at 9:18 AM, Zhenyu Zheng 
> wrote:
>
> Any thoughts on this?
>
> On Mon, Sep 14, 2015 at 11:53 AM, Zhenyu Zheng 
> wrote:
>
>> Hi, Thanks for your reply, after check again and I agree with you. I
>> think we should come up with a conclusion about how we should treat this
>> limit=0 across nova. And that's also why I sent out this mail. I will
>> register this topic in the API meeting open discussion section, my be a BP
>> in M to fix this.
>>
>> BR,
>>
>> Zheng
>>
>> On Sat, Sep 12, 2015 at 12:07 AM, Kevin L. Mitchell <
>> kevin.mitch...@rackspace.com> wrote:
>>
>>> On Fri, 2015-09-11 at 15:41 +0800, Zhenyu Zheng wrote:
>>> > Hi, I found out that nova currently handles list with limit=0 quite
>>> > different for different objects.
>>> >
>>> > Especially when list servers:
>>> >
>>> > According to the code:
>>> >
>>> http://git.openstack.org/cgit/openstack/nova/tree/nova/api/openstack/common.py#n206
>>> >
>>> > when limit = 0, it should apply as max_limit, but currently, in:
>>> >
>>> http://git.openstack.org/cgit/openstack/nova/tree/nova/db/sqlalchemy/api.py#n1930
>>> >
>>> > we directly return [], this is quite different with comment in the api
>>> > code.
>>> >
>>> >
>>> > I checked other objects:
>>> >
>>> > when list security groups and server groups, it will return as no
>>> > limit has been set. And for flavors it returns []. I will continue to
>>> > try out other APIs if needed.
>>> >
>>> > I think maybe we should make a rule for all objects, at least fix the
>>> > servers to make it same in api and db code.
>>> >
>>> > I have reported a bug in launchpad:
>>> >
>>> > https://bugs.launchpad.net/nova/+bug/1494617
>>> >
>>> >
>>> > Any suggestions?
>>>
>>> After seeing the test failures that showed up on your proposed fix, I'm
>>> thinking that the proposed change reads like an API change, requiring a
>>> microversion bump.  That said, I approve of increased consistency across
>>> the API, and perhaps the behavior on limit=0 is something the API group
>>> needs to discuss a guideline for?
>>> --
>>> Kevin L. Mitchell 
>>> Rackspace
>>>
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> 
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>>
> __
> OpenStack Development Mailing 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] About availability zones

[Feodor Tersin]

Hi.

Currently, when performing live-migration the AZ of the instance didn't update. 
In usecase like this:Instance_1 is in host1 which is in az1, we live-migrate it 
to host2 (provide host2 in API request) which is in az2. The operation will 
secusess but the availability zone data stored in instance1 is still az1, this 
may cause inconsistency with the az data stored in instance db and the actual 
az. I think update the az information in instance using the host az can solve 
this.
Since a host can be included into different AZs, you probably need to allow a 
caller optionally to specify a target AZ. And as i understand the same problem 
occurs for resize, evacuate and other similar operations, doesn't it?

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

[Flavio Percoco]

Greetings,

The community is in the process of collecting topics for the
cross-project tack that we'll have in the Mitaka summit.

The good ol' OSDREG has been setup[0] to help collectiong these topics
and we'd like to encourage the community to propose sessions there.

During the TC meeting last night, it was pointed out that some people
have already proposed sessions on this[1] etherpad. I'd also like to
ask these folks to move these proposals to OSDREG as that's the tool
the cross-project track committee will be using as a reference for
proposals.

The deadline for proposing topics for the cross-project track is
October 9th. That will leave the committee roughly 2 weeks to review
the proposals and schedule them before the summit.

Bests,
Flavio

[0] http://odsreg.openstack.org/
[1] https://etherpad.openstack.org/p/mitaka-cross-project-session-planning

--
@flaper87
Flavio Percoco


pgpIVEUKOPI4x.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] [nova] About availability zones

[Zhenyu Zheng]

Hi,

Thanks for the reply, one possible usecase is that user wants to
live-migrate to az2 so he specified host2. As we didn't update the
instance.az, if the user live-migrate again without specifiying destination
host, the instance will migrate to az1 again, this might be different as
the user expect. Any thought about this?

BR,

Zheng

On Wed, Sep 23, 2015 at 4:30 PM, Sylvain Bauza  wrote:

>
>
> Le 23/09/2015 05:24, Zhenyu Zheng a écrit :
>
> Hi, all
>
> I have a question about availability zones when performing live-migration.
>
> Currently, when performing live-migration the AZ of the instance didn't
> update. In usecase like this:
> Instance_1 is in host1 which is in az1, we live-migrate it to host2
> (provide host2 in API request) which is in az2. The operation will secusess
> but the availability zone data stored in instance1 is still az1, this may
> cause inconsistency with the az data stored in instance db and the actual
> az. I think update the az information in instance using the host az can
> solve this.
>
>
> Well, no. Instance.AZ is only the reflect of what the user asked, not what
> the current AZ is from the host the instance belongs to. In other words,
> instance.az is set once forever by taking the --az hint from the API
> request and persisting it in DB.
>
> That means that if you want to create a new VM without explicitly
> specifying one AZ in the CLI, it will take the default value of
> CONF.default_schedule_az which is None (unless you modify that flag).
>
> Consequently, when it will go to the scheduler, the AZFilter will not
> check the related AZs from any host because you didn't asked for an AZ.
> That means that the instance is considered "AZ-free".
>
> Now, when live-migrating, *if you specify a destination*, you totally
> bypass the scheduler and thus the AZFilter. By doing that, you can put your
> instance to another host without really checking the AZ.
>
> That said, if you *don't specify a destination*, then the scheduler will
> be called and will enforce the instance.az field with regards to the host
> AZ. That should still work (again, depending on whether you explicitly set
> an AZ at the boot time)
>
> To be clear, there is no reason of updating that instance AZ field. We can
> tho consider it's a new "request"' field and could be potentially moved to
> the RequestSpec object, but for the moment, this is a bit too early since
> we don't really use that new RequestSpec object yet.
>
>
>
> Also, I have heard from my collegue that in the future we are planning to
> use host az information for instances. I couldn't find informations about
> this, could anyone provide me some information about it if thats true?
>
>
> See my point above, I'd rather prefer to fix how live-migrations check the
> scheduler (and not bypass it when specifying a destination) and possibly
> move the instance AZ field to the RequestSpec object once that object is
> persisted, but I don't think we should check the host instead of the
> instance in the AZFilter.
>
>
> I assume all of that can be very confusing and mostly tribal knowledge,
> that's why we need to document that properly and one first shot is
> https://review.openstack.org/#/c/223802/
>
> -Sylvain
>
> Thanks,
>
> Best Regards,
>
> Zheng
>
>
> __
> 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
>
>
__
OpenStack Development Mailing List (not for 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] incubator move to private modules

[Kekane, Abhishek]

Hi All,

I am working on "Returning request-id to caller".
Please refer, https://review.openstack.org/#/c/156508

To implement this specs in cross-projects it is also required to move 
oslo-incubator to private modules.

IMO moving oslo-incubator/openstack as a private module 
oslo-incubator/_openstack will require lot of changes (import statements) in 
all projects which are using it which will be time consuming.
I also want to know if anyone is proposing blueprint/specs for the same.

Thank you,

Abhishek Kekane

From: Davanum Srinivas [mailto:dava...@gmail.com]
Sent: 26 August 2015 15:57
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [oslo] incubator move to private modules

yep ttx. this will be for Mitaka.

-- Dims

On Wed, Aug 26, 2015 at 6:18 AM, Thierry Carrez 
> wrote:
Flavio Percoco wrote:
> On 25/08/15 06:01 -0400, Davanum Srinivas wrote:
>> Morgan,
>>
>> Bit more radical :) I am inclined to just yank all code from
>> oslo-incubator and
>> let the projects modify/move what they have left into their own
>> package/module
>> structure (and change the contracts however they see fit).
>
> Glad this conversation is happening, I've started to think about this
> as well. I think we're at a point were we could just let projects move
> from were they are.
>
> However, I'd like this to be a bit more organized. For instance, if we
> dismiss oslo-incubator and let projects move forward on their own,
> it'd be better to have all the `openstack/common/` packages renamed so
> that it'll create less confusion to newcomers. At the very least, as
> Morgan mentioned, these packages could be prefixed with an `_` and
> become 'private' and 'owned' by the project.
>
> We still need a 'deprecation' process for the code in the
> oslo-incubator repository and we would still have to accept fixes for
> previous releases.

The Death of the Incubator. Sounds like a great thing to discuss at the
Design Summit. I don't think we would kill it before start of Mitaka
anyway ?

--
Thierry Carrez (ttx)


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



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

__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.
__
OpenStack Development Mailing List (not for 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] How to make a mock effactive for all method of a testclass

[Gorka Eguileor]

On 23/09, liuxinguo wrote:
> Hi,
> 
> In a.py we have a function:
> def _change_file_mode(filepath):
> utils.execute('chmod', '600', filepath, run_as_root=True)
> 
> In test_xxx.py, there is a testclass:
> class DriverTestCase(test.TestCase):
> def test_a(self)
> ...
> Call a. _change_file_mode
> ...
> 
> def test_b(self)
> ...
> Call a. _change_file_mode
> ...
> 
> I have tried to mock like mock out function _change_file_mode like this:
> @mock.patch.object(a, '_change_file_mode', return_value=None)
> class DriverTestCase(test.TestCase):
> def test_a(self)
> ...
> Call a. _change_file_mode
> ...
> 
> def test_b(self)
> ...
> Call a. _change_file_mode
> ...
> 
> But the mock takes no effort, the real function _change_file_mode is still 
> executed.
> So how to make a mock effactive for all method of a testclass?
> Thanks for any input!
> 
> Wilson Liu

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

Hi,

There is something else going on with your code, as the code you are
showing us here should not even execute at all.  You should be getting a
couple of errors:

 TypeError: test_a() takes exactly 1 argument (2 given)
 TypeError: test_b() takes exactly 1 argument (2 given)

Because mocking the whole class will still pass the mock object as an
argument to the methods.

Anyway, if you accept the mocked object as an argument in your test
methods it would work.

Cheers,
Gorka.

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

[openstack-dev] [cinder] How to make a mock effactive for all method of a testclass

[liuxinguo]

Hi,

In a.py we have a function:
def _change_file_mode(filepath):
utils.execute('chmod', '600', filepath, run_as_root=True)

In test_xxx.py, there is a testclass:
class DriverTestCase(test.TestCase):
def test_a(self)
...
Call a. _change_file_mode
...

def test_b(self)
...
Call a. _change_file_mode
...

I have tried to mock like mock out function _change_file_mode like this:
@mock.patch.object(a, '_change_file_mode', return_value=None)
class DriverTestCase(test.TestCase):
def test_a(self)
...
Call a. _change_file_mode
...

def test_b(self)
...
Call a. _change_file_mode
...

But the mock takes no effort, the real function _change_file_mode is still 
executed.
So how to make a mock effactive for all method of a testclass?
Thanks for any input!

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

Re: [openstack-dev] [nova] About availability zones

[Sylvain Bauza]

Le 23/09/2015 08:56, Feodor Tersin a écrit :

Hi.

/Currently, when performing live-migration the AZ of the instance
didn't update. In usecase like this:/
/Instance_1 is in host1 which is in az1, we live-migrate it to
host2 (provide host2 in API request) which is in az2. The
operation will secusess but the availability zone data stored in
instance1 is still az1, this may cause inconsistency with the az
data stored in instance db and the actual az. I think update the
az information in instance using the host az can solve this./


Since a host can be included into different AZs, you probably need to 
allow a caller optionally to specify a target AZ. And as i understand 
the same problem occurs for resize, evacuate and other similar 
operations, doesn't it?


No, an host can't be in two different AZs. It can be in two or more 
aggregates, but then only one of those aggregates can be having an AZ 
metadata key.

https://github.com/openstack/nova/blob/1df8248b6ad7982174c417abf80070107eac8909/nova/compute/api.py#L3645-L3670

FWIW, I provided a devref change for explaining that : 
https://review.openstack.org/#/c/223802/


-Sylvain





__
OpenStack Development Mailing 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] About availability zones

[Sylvain Bauza]

Le 23/09/2015 05:24, Zhenyu Zheng a écrit :

Hi, all

I have a question about availability zones when performing live-migration.

Currently, when performing live-migration the AZ of the instance 
didn't update. In usecase like this:
Instance_1 is in host1 which is in az1, we live-migrate it to host2 
(provide host2 in API request) which is in az2. The operation will 
secusess but the availability zone data stored in instance1 is still 
az1, this may cause inconsistency with the az data stored in instance 
db and the actual az. I think update the az information in instance 
using the host az can solve this.




Well, no. Instance.AZ is only the reflect of what the user asked, not 
what the current AZ is from the host the instance belongs to. In other 
words, instance.az is set once forever by taking the --az hint from the 
API request and persisting it in DB.


That means that if you want to create a new VM without explicitly 
specifying one AZ in the CLI, it will take the default value of 
CONF.default_schedule_az which is None (unless you modify that flag).


Consequently, when it will go to the scheduler, the AZFilter will not 
check the related AZs from any host because you didn't asked for an AZ. 
That means that the instance is considered "AZ-free".


Now, when live-migrating, *if you specify a destination*, you totally 
bypass the scheduler and thus the AZFilter. By doing that, you can put 
your instance to another host without really checking the AZ.


That said, if you *don't specify a destination*, then the scheduler will 
be called and will enforce the instance.az field with regards to the 
host AZ. That should still work (again, depending on whether you 
explicitly set an AZ at the boot time)


To be clear, there is no reason of updating that instance AZ field. We 
can tho consider it's a new "request"' field and could be potentially 
moved to the RequestSpec object, but for the moment, this is a bit too 
early since we don't really use that new RequestSpec object yet.




Also, I have heard from my collegue that in the future we are planning 
to use host az information for instances. I couldn't find informations 
about this, could anyone provide me some information about it if thats 
true?




See my point above, I'd rather prefer to fix how live-migrations check 
the scheduler (and not bypass it when specifying a destination) and 
possibly move the instance AZ field to the RequestSpec object once that 
object is persisted, but I don't think we should check the host instead 
of the instance in the AZFilter.



I assume all of that can be very confusing and mostly tribal knowledge, 
that's why we need to document that properly and one first shot is 
https://review.openstack.org/#/c/223802/


-Sylvain


Thanks,

Best Regards,

Zheng


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


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

[openstack-dev] [fuel] Weekly IRC meeting 9/24

[Andrew Woodward]

As a reminder, the weekly IRC meeting is scheduled for 16:00 UTC Tomorrow
in #openstack-meeting-alt

Please review meeting agenda and update if there is something you wish to
discuss.

https://etherpad.openstack.org/p/fuel-weekly-meeting-agenda
-- 

--

Andrew Woodward

Mirantis

Fuel Community Ambassador

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

[openstack-dev] [nova] Servicegroup refactoring for the Control Plane - Mitaka

[Vilobh Meshram]

Hi All,

As part of Liberty spec [1] was approved with the conclusion that
nova.services data be stored and managed by respective driver backend that
is selected by the CONF.servicegroup_driver (which can be
DB/Zookeeper/Memcache).

When this spec was proposed again for Mitaka[3], the idea that has come up
is that the nova.services data will remain in nova database itself and the
servicegroup zookeeper, memcache drivers be used solely for
liveliness/up/down ness of the service. The idea being using the best of
both worlds and few operations for example getting min/max for a service id
can be quicker when done a query in DB in comparison to ZK/Memcache
backends. But ZK driver is worthwhile for state management as it minimizes
the burden on nova db to store the additional *periodic* (depending on
service_down_time) liveliness information.

Please note [4] depends on [3] and a conclusion on [3] can pave a way
forward for [4] (similarly [1] was a dependency for [2]). A detail document
[5] encompassing all the possible options by having different permutation
of various drivers (db/zk/mc). Once we have a conclusion on one of the
approach proposed in [5] will update spec [3] to reflect these changes.

So in short

*Accepted in Liberty [1] [2] :*
[1] Services information be stored in respective backend configured by
CONF.servicegroup_driver
and all the interfaces which plan to access service information go through
servicegroup layer.
[2] Add tooz specific drivers e.g. replace existing nova servicegroup
zookeeper driver with a new zookeeper driver backed by Tooz zookeeper
driver.

*Proposal for Mitaka [3][4] :*
[3] Services information be stored in nova.services (nova database) and
liveliness information be managed by CONF.servicegroup_driver
(DB/Zookeeper/Memcache)
[4] Stick to what is accepted for #2. Just that the scope will be decided
based on whether we go with #1 (as accepted for Liberty) or #3 (what is
proposed for Mitaka)


- Vilobh

[1] Servicegroup foundational refactoring for Control Plane *(Liberty)* -
https://review.openstack.org/#/c/190322/

[2] Add tooz service group driver* (Liberty)* -
https://review.openstack.org/#/c/138607/

[3] Servicegroup foundational refactoring for Control Plane *(Mitaka)* -
https://review.openstack.org/#/c/222423/

[4] Add tooz service group driver *(Mitaka) *-
https://review.openstack.org/#/c/222422/

[5] *Various options and there impact* :
https://etherpad.openstack.org/p/servicegroup-refactoring
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][cinder] how to handle AZ bug 1496235?

[Matt Riedemann]

On 9/23/2015 2:15 PM, Matt Riedemann wrote:



On 9/23/2015 1:46 PM, Ivan Kolodyazhny wrote:

Hi Matt,

In Liberty, we introduced allow_availability_zone_fallback [1] option in
Cinder config as fix for bug [2]. If you set this option, Cinder will
create volume in a default AZ instead of set volume into the error state

[1]
https://github.com/openstack/cinder/commit/b85d2812a8256ff82934d150dbc4909e041d8b31

[2] https://bugs.launchpad.net/cinder/+bug/1489575

Regards,
Ivan Kolodyazhny

On Wed, Sep 23, 2015 at 9:00 PM, Matt Riedemann
> wrote:

I came across bug 1496235 [1] today.  In this case the user is
booting an instance from a volume using source=image, so nova
actually does the volume create call to the volume API.  They are
booting the instance into a valid nova availability zone, but that
same AZ isn't defined in Cinder, so the volume create request fails
(since nova passes the instance AZ to cinder [2]).

I marked this as invalid given how the code works.

I'm posting here since I'm wondering if there are alternatives worth
pursuing.  For example, nova could get the list of AZs from the
volume API and if the nova AZ isn't in that list, don't provide it
on the volume create request.  That's essentially the same as first
creating the volume outside of nova and not specifying an AZ, then
when doing the boot from volume, provide the volume_id as the source.

The question is, is it worth doing that?  I'm not familiar enough
with how availability zones are meant to work between nova and
cinder so it's hard for me to have much of an opinion here.

[1] https://bugs.launchpad.net/nova/+bug/1496235
[2]

https://github.com/openstack/nova/blob/master/nova/virt/block_device.py#L381-L383


--

Thanks,

Matt Riedemann



__

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


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




__

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



Sorry but that seems like a hack.

I'm trying to figure out the relationship between AZs in nova and cinder
and so far no one seems to really know.  In the cinder IRC channel I was
told there isn't one, which would mean we shouldn't even try creating
the volume using the server instance AZ.

Also, if there is no relationship, I was trying to figure out why there
is the cinder.cross_az_attach config option.  That was added in grizzly
[1].  I was thinking maybe it was a legacy artifact from nova-volume,
but that was dropped in grizzly.

So is cinder.cross_az_attach even useful?

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



The plot thickens.

I was checking to see what change was made to start passing the server 
instance az on the volume create call during boot from volume, and that 
was [1] which was added in kilo to fix a bug where boot from volume into 
a nova az will fail if cinder.cross_az_attach=False and 
storage_availability_zone is set in cinder.conf.


So I guess we can't just stop passing the instance az to the volume 
create call.


But what I'd really like to know is how this is all used between cinder 
and nova, or was this all some work done as part of a larger effort that 
was never completed?  Basically, can we deprecate the 
cinder.cross_az_attach config option in nova and start decoupling this code?


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

--

Thanks,

Matt Riedemann


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

Re: [openstack-dev] [puppet][swift] Applying security recommendations within puppet-swift

[Alex Schultz]

On Wed, Sep 23, 2015 at 2:32 PM, Alex Schultz  wrote:
> Hey all,
>
> So as part of the Puppet mid-cycle, we did bug triage.  One of the
> bugs that was looked into was bug 1289631[0].  This bug is about
> applying the recommendations from the security guide[1] within the
> puppet-swift module.  So I'm sending a note out to get other feedback
> on if this is a good idea or not.  Should we be applying this type of
> security items within the puppet modules by default? Should we make
> this optional?  Thoughts?
>
>
> Thanks,
> -Alex
>
>
> [0] https://bugs.launchpad.net/puppet-swift/+bug/1289631
> [1] 
> http://docs.openstack.org/security-guide/object-storage.html#securing-services-general

Also for the puppet side of this conversation, the change for the
security items[0] also seems to conflict with bug 1458915[1] which is
about removing the posix users/groups/file modes.  So which direction
should we go?

[0] https://review.openstack.org/#/c/219883/
[1] https://bugs.launchpad.net/puppet-swift/+bug/1458915

__
OpenStack Development Mailing 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] [elections] Last day to elect your PTL for Cinder, Glance, Ironic, Keystone, Mistral, Neutron and Oslo!

[Tristan Cacqueray]

Hello Cinder, Glance, Ironic, Keystone, Mistral, Neutron and Oslo
contributors,

Just a quick reminder that elections are closing soon, if you haven't
already you should use your right to vote and pick your favourite candidate!

Thanks for your time,
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] [nova][cinder] how to handle AZ bug 1496235?

[Mathieu Gagné]

On 2015-09-23 4:50 PM, Andrew Laski wrote:
> On 09/23/15 at 04:30pm, Mathieu Gagné wrote:
>> On 2015-09-23 4:12 PM, Andrew Laski wrote:
>>> On 09/23/15 at 02:55pm, Matt Riedemann wrote:

 Heh, so when I just asked in the cinder channel if we can just
 deprecate nova boot from volume with source=(image|snapshot|blank)
 (which automatically creates the volume and polls for it to be
 available) and then add a microversion that doesn't allow it, I was
 half joking, but I see we're on the same page.  This scenario seems to
 introduce a lot of orchestration work that nova shouldn't necessarily
 be in the business of handling.
>>>
>>> I am very much in support of this.  This has been a source of
>>> frustration for our users because it is prone to failures we can't
>>> properly expose to users and timeouts.  There are much better places to
>>> handle the orchestration of creating a volume and then booting from it
>>> than Nova.
>>>
>>
>> Unfortunately, this is a feature our users *heavily* rely on and we
>> worked very hard to make it happen. We had a private patch on our side
>> for years to optimize boot-from-volume before John Griffith came up with
>> an upstream solution for SolidFire [2] and others with a generic
>> solution [3] [4].
>>
>> Being able to "nova boot" and have everything done for you is awesome.
>> Just see what Monty Taylor mentioned in his thread about sane default
>> networking [1]. Having orchestration on the client side is just
>> something our users don't want to have to do and often complain about.
> 
> At risk of getting too offtopic I think there's an alternate solution to
> doing this in Nova or on the client side.  I think we're missing some
> sort of OpenStack API and service that can handle this.  Nova is a low
> level infrastructure API and service, it is not designed to handle these
> orchestrations.  I haven't checked in on Heat in a while but perhaps
> this is a role that it could fill.
> 
> I think that too many people consider Nova to be *the* OpenStack API
> when considering instances/volumes/networking/images and that's not
> something I would like to see continue.  Or at the very least I would
> like to see a split between the orchestration/proxy pieces and the
> "manage my VM/container/baremetal" bits.
> 

"too many people" happens to include a lot of 3rd party tools supporting
OpenStack which our users complain a lot about. Just see all the
possible way to get an external IP [5]. Introducing yet another service
would increase the pain on our users which will see their tools and
products not working even more.

Just see how EC2 is doing it [6], you won't see them suggest to use yet
another service to orchestrate what I consider a fundamental feature "I
wish to boot an instance on a volume".

The current ease to boot from volume is THE selling feature our users
want and heavily/actively use. We fought very hard to make it work and
reading about how it should be removed is frustrating.

Issues we identified shouldn't be a reason to drop this feature. Other
providers are making it work and I don't see why we couldn't. I'm
convinced we can do better.

[5]
https://github.com/openstack-infra/shade/blob/03c1556a12aabfc21de60a9fac97aea7871485a3/shade/meta.py#L106-L173
[6]
http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/block-device-mapping-concepts.html

Mathieu

>>
>> [1]
>> http://lists.openstack.org/pipermail/openstack-dev/2015-September/074527.html
>>
>> [2] https://review.openstack.org/#/c/142859/
>> [3] https://review.openstack.org/#/c/195795/
>> [4] https://review.openstack.org/#/c/201754/
>>
>> -- 
>> 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

Re: [openstack-dev] [elections] Last day to elect your PTL for Cinder, Glance, Ironic, Keystone, Mistral, Neutron and Oslo!

[Tristan Cacqueray]

On 09/23/2015 09:22 PM, Tristan Cacqueray wrote:
> Hello Cinder, Glance, Ironic, Keystone, Mistral, Neutron and Oslo
> contributors,
> 
> Just a quick reminder that elections are closing soon, if you haven't
> already you should use your right to vote and pick your favourite candidate!
> 

The start of the election period was delayed by approximately 24 hours,
however we overlooked that when announcing the close date for the
election [1].

To ensure we conduct a valid election as outlined in the OpenStack
charter [2]  we are extending the voting deadline until
2015-09-25 23:59 UTC [3]

Thanks for your time and understanding.

[1]
http://lists.openstack.org/pipermail/openstack-dev/2015-September/074938.html
[2]
http://git.openstack.org/cgit/openstack/governance/tree/reference/charter.rst#n97
[3] http://www.timeanddate.com/worldclock/fixedtime.html?iso=20150925T2359




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] Consistent support for SSL termination proxies across all API services

[Julien Danjou]

On Wed, Sep 23 2015, Sean Dague wrote:

> Ok, how exactly does that work? Because it seems like
> oslo_middleware.ssl is only changing the protocol if the proxy sets it.
>
> But the host in the urls will still be the individual host, which isn't
> the proxy hostname/ip. Sorry if I'm being daft here, just want to
> understand how that flow ends up working.

No problem, you're no supposed to know everything. :)

As ZZelle said too, we can set the correct host and port expected by
honoring X-Forwarded-Host and X-Forwarded-Port, which are set by HTTP
proxies when they act as reverse-proxies and forward requests.
That will make the WSGI application unaware of the fact that there is a
request proxy in front of them. Magic!

We could do that in the SSL middleware (and maybe rename it?) or in
another middleware, and enable them by default. So we'd have that
working by default, which would be great IMHO.

> Will that cover the case of webob's request.application_uri? If so I
> think that covers the REST documents in at least Nova (one good data
> point, and one that I know has been copied around). At least as far as
> the protocol is concerned, it's still got a potential url issue.

That should work with any WSGI request, so I'd say yes.

>> The {public,admin}_endpoint are only useful in the case where you map
>> http://myproxy/identity -> http://mykeystone/ using a proxy
>> 
>> Because the prefix is not passed to Keystone. If you map 1:1 the path
>> part, we could also leverage X-Forwarded-Host and X-Forwarded-Port to
>> avoid having {public,admin}_endpoint options.
>
> It also looks like there are new standards for Forwarded headers, so the
> middleware should probably support those as well.
> http://tools.ietf.org/html/rfc7239.

Good point, we should update the middleware as needed.

Though they still not cover that use case where you have a base URL that
is different between the proxy and the application. I don't think it's a
widely used case, but still, there are at 2 least two way to support it:
1. Having config option (like Keystone currently has)
2. Having a special e.g. X-Forwarded-BaseURL header set by the proxy
   that we would catch in our middleware and would prepend to
   environment['SCRIPT_NAME'].

The 2 options are even compatible, though I'd say 2. is probably simpler
in the long run and more… "unified".

I'm willing to clear that out and come with specs and patches if that
can help. :)

-- 
Julien Danjou
# Free Software hacker
# http://julien.danjou.info


signature.asc
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] [puppet] use zuul-cloner when running rspec

[Emilien Macchi]

Background
==

Current rspec tests are tested with modules mentioned in .fixtures.yaml
file of each module.

* the file is not consistent across all modules
* it hardcodes module names & versions
* this way does not allow to use "Depend-On" feature, that would allow
to test cross-modules patches

Proposal


* Like we do in beaker & integration jobs, use zuul-cloner to clone
modules in our CI jobs.
* Use r10k to prepare fixtures modules.
* Use Puppetfile hosted by openstack/puppet-openstack-integration

In that way:
* we will have modules name + versions testing consistency across all
modules
* the same Puppetfile would be used by unit/beaker/integration testing.
* the patch that pass tests on your laptop would pass tests in upstream CI
* if you don't have zuul-cloner on your laptop, don't worry it will use
git clone. Though you won't have Depends-On feature working on your
laptop (technically not possible).
* Though your patch will support Depends-On in OpenStack Infra for unit
tests. If you submit a patch in puppet-openstacklib that drop something
wrong, you can send a patch in puppet-nova that will test it, and unit
tests will fail.

Drawbacks
=
* cloning from .fixtures.yaml takes ~ 10 seconds
* using r10k + zuul-clone takes ~50 seconds (more modules to clone).

I think 40 seconds is something accept regarding the benefit.


Next steps
==

* PoC in puppet-nova: https://review.openstack.org/#/c/226830/
* Patch openstack/puppet-modulesync-config to be consistent across all
our modules.

Bonus
=
we might need (asap) a canary job for puppet-openstack-integration
repository, that would run tests on a puppet-* module (since we're using
install_modules.sh & Puppetfile files in puppet-* modules).
Nothing has been done yet for this work.


Thoughts?
-- 
Emilien Macchi



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

Re: [openstack-dev] [nova][cinder] how to handle AZ bug 1496235?

[Sylvain Bauza]

Le 23/09/2015 21:45, John Griffith a écrit :



On Wed, Sep 23, 2015 at 1:34 PM, Matt Riedemann 
> wrote:




On 9/23/2015 2:15 PM, Matt Riedemann wrote:



On 9/23/2015 1:46 PM, Ivan Kolodyazhny wrote:

Hi Matt,

In Liberty, we introduced allow_availability_zone_fallback
[1] option in
Cinder config as fix for bug [2]. If you set this option,
Cinder will
create volume in a default AZ instead of set volume into
the error state

[1]

https://github.com/openstack/cinder/commit/b85d2812a8256ff82934d150dbc4909e041d8b31

[2] https://bugs.launchpad.net/cinder/+bug/1489575

Regards,
Ivan Kolodyazhny

On Wed, Sep 23, 2015 at 9:00 PM, Matt Riedemann

>> wrote:

I came across bug 1496235 [1] today.  In this case the
user is
booting an instance from a volume using source=image,
so nova
actually does the volume create call to the volume
API.  They are
booting the instance into a valid nova availability
zone, but that
same AZ isn't defined in Cinder, so the volume create
request fails
(since nova passes the instance AZ to cinder [2]).

I marked this as invalid given how the code works.

I'm posting here since I'm wondering if there are
alternatives worth
pursuing.  For example, nova could get the list of AZs
from the
volume API and if the nova AZ isn't in that list,
don't provide it
on the volume create request.  That's essentially the
same as first
creating the volume outside of nova and not specifying
an AZ, then
when doing the boot from volume, provide the volume_id
as the source.

The question is, is it worth doing that?  I'm not
familiar enough
with how availability zones are meant to work between
nova and
cinder so it's hard for me to have much of an opinion
here.

[1] https://bugs.launchpad.net/nova/+bug/1496235
[2]


https://github.com/openstack/nova/blob/master/nova/virt/block_device.py#L381-L383


--

Thanks,

Matt Riedemann




__

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





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





__

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


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


Sorry but that seems like a hack.

I'm trying to figure out the relationship between AZs in nova
and cinder
and so far no one seems to really know.  In the cinder IRC
channel I was
told there isn't one, which would mean we shouldn't even try
creating
the volume using the server instance AZ.

Also, if there is no relationship, I was trying to figure out
why there
is the cinder.cross_az_attach config option.  That was added
in grizzly
[1].  I was thinking maybe it was a legacy artifact from
nova-volume,
but that was dropped in grizzly.

So is cinder.cross_az_attach even useful?

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


The plot thickens.

I was checking to see what change was made to start passing the
server instance az on the volume create call during boot from
volume, and that was [1] which was added in kilo to fix a bug
where boot from volume into a nova az will fail if
cinder.cross_az_attach=False and storage_availability_zone is set
in cinder.conf.

So I guess we can't just stop passing the instance az to the
volume create call.

But what I'd really like 

Re: [openstack-dev] [nova][cinder] how to handle AZ bug 1496235?

[Matt Riedemann]

On 9/23/2015 2:57 PM, Sylvain Bauza wrote:



Le 23/09/2015 21:45, John Griffith a écrit :



On Wed, Sep 23, 2015 at 1:34 PM, Matt Riedemann
> wrote:



On 9/23/2015 2:15 PM, Matt Riedemann wrote:



On 9/23/2015 1:46 PM, Ivan Kolodyazhny wrote:

Hi Matt,

In Liberty, we introduced allow_availability_zone_fallback
[1] option in
Cinder config as fix for bug [2]. If you set this option,
Cinder will
create volume in a default AZ instead of set volume into
the error state

[1]

https://github.com/openstack/cinder/commit/b85d2812a8256ff82934d150dbc4909e041d8b31

[2] https://bugs.launchpad.net/cinder/+bug/1489575

Regards,
Ivan Kolodyazhny

On Wed, Sep 23, 2015 at 9:00 PM, Matt Riedemann

>> wrote:

I came across bug 1496235 [1] today.  In this case the
user is
booting an instance from a volume using source=image,
so nova
actually does the volume create call to the volume
API.  They are
booting the instance into a valid nova availability
zone, but that
same AZ isn't defined in Cinder, so the volume create
request fails
(since nova passes the instance AZ to cinder [2]).

I marked this as invalid given how the code works.

I'm posting here since I'm wondering if there are
alternatives worth
pursuing.  For example, nova could get the list of AZs
from the
volume API and if the nova AZ isn't in that list,
don't provide it
on the volume create request.  That's essentially the
same as first
creating the volume outside of nova and not specifying
an AZ, then
when doing the boot from volume, provide the volume_id
as the source.

The question is, is it worth doing that?  I'm not
familiar enough
with how availability zones are meant to work between
nova and
cinder so it's hard for me to have much of an opinion
here.

[1] https://bugs.launchpad.net/nova/+bug/1496235
[2]


https://github.com/openstack/nova/blob/master/nova/virt/block_device.py#L381-L383


--

Thanks,

Matt Riedemann




__

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





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





__

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


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


Sorry but that seems like a hack.

I'm trying to figure out the relationship between AZs in nova
and cinder
and so far no one seems to really know.  In the cinder IRC
channel I was
told there isn't one, which would mean we shouldn't even try
creating
the volume using the server instance AZ.

Also, if there is no relationship, I was trying to figure out
why there
is the cinder.cross_az_attach config option.  That was added
in grizzly
[1].  I was thinking maybe it was a legacy artifact from
nova-volume,
but that was dropped in grizzly.

So is cinder.cross_az_attach even useful?

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


The plot thickens.

I was checking to see what change was made to start passing the
server instance az on the volume create call during boot from
volume, and that was [1] which was added in kilo to fix a bug
where boot from volume into a nova az will fail if
cinder.cross_az_attach=False and storage_availability_zone is set
in cinder.conf.

So I guess we can't just stop passing the instance az to the

Re: [openstack-dev] [nova][cinder] how to handle AZ bug 1496235?

[Mathieu Gagné]

On 2015-09-23 4:12 PM, Andrew Laski wrote:
> On 09/23/15 at 02:55pm, Matt Riedemann wrote:
>>
>> Heh, so when I just asked in the cinder channel if we can just
>> deprecate nova boot from volume with source=(image|snapshot|blank)
>> (which automatically creates the volume and polls for it to be
>> available) and then add a microversion that doesn't allow it, I was
>> half joking, but I see we're on the same page.  This scenario seems to
>> introduce a lot of orchestration work that nova shouldn't necessarily
>> be in the business of handling.
> 
> I am very much in support of this.  This has been a source of
> frustration for our users because it is prone to failures we can't
> properly expose to users and timeouts.  There are much better places to
> handle the orchestration of creating a volume and then booting from it
> than Nova.
> 

Unfortunately, this is a feature our users *heavily* rely on and we
worked very hard to make it happen. We had a private patch on our side
for years to optimize boot-from-volume before John Griffith came up with
an upstream solution for SolidFire [2] and others with a generic
solution [3] [4].

Being able to "nova boot" and have everything done for you is awesome.
Just see what Monty Taylor mentioned in his thread about sane default
networking [1]. Having orchestration on the client side is just
something our users don't want to have to do and often complain about.

[1]
http://lists.openstack.org/pipermail/openstack-dev/2015-September/074527.html
[2] https://review.openstack.org/#/c/142859/
[3] https://review.openstack.org/#/c/195795/
[4] https://review.openstack.org/#/c/201754/

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

Re: [openstack-dev] [nova][cinder] how to handle AZ bug 1496235?

[Matt Riedemann]

On 9/23/2015 2:45 PM, John Griffith wrote:



On Wed, Sep 23, 2015 at 1:34 PM, Matt Riedemann
> wrote:



On 9/23/2015 2:15 PM, Matt Riedemann wrote:



On 9/23/2015 1:46 PM, Ivan Kolodyazhny wrote:

Hi Matt,

In Liberty, we introduced allow_availability_zone_fallback
[1] option in
Cinder config as fix for bug [2]. If you set this option,
Cinder will
create volume in a default AZ instead of set volume into the
error state

[1]

https://github.com/openstack/cinder/commit/b85d2812a8256ff82934d150dbc4909e041d8b31

[2] https://bugs.launchpad.net/cinder/+bug/1489575

Regards,
Ivan Kolodyazhny

On Wed, Sep 23, 2015 at 9:00 PM, Matt Riedemann

>> wrote:

 I came across bug 1496235 [1] today.  In this case the
user is
 booting an instance from a volume using source=image,
so nova
 actually does the volume create call to the volume
API.  They are
 booting the instance into a valid nova availability
zone, but that
 same AZ isn't defined in Cinder, so the volume create
request fails
 (since nova passes the instance AZ to cinder [2]).

 I marked this as invalid given how the code works.

 I'm posting here since I'm wondering if there are
alternatives worth
 pursuing.  For example, nova could get the list of AZs
from the
 volume API and if the nova AZ isn't in that list, don't
provide it
 on the volume create request.  That's essentially the
same as first
 creating the volume outside of nova and not specifying
an AZ, then
 when doing the boot from volume, provide the volume_id
as the source.

 The question is, is it worth doing that?  I'm not
familiar enough
 with how availability zones are meant to work between
nova and
 cinder so it's hard for me to have much of an opinion here.

 [1] https://bugs.launchpad.net/nova/+bug/1496235
 [2]


https://github.com/openstack/nova/blob/master/nova/virt/block_device.py#L381-L383


 --

 Thanks,

 Matt Riedemann




__

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




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





__

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

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


Sorry but that seems like a hack.

I'm trying to figure out the relationship between AZs in nova
and cinder
and so far no one seems to really know.  In the cinder IRC
channel I was
told there isn't one, which would mean we shouldn't even try
creating
the volume using the server instance AZ.

Also, if there is no relationship, I was trying to figure out
why there
is the cinder.cross_az_attach config option.  That was added in
grizzly
[1].  I was thinking maybe it was a legacy artifact from
nova-volume,
but that was dropped in grizzly.

So is cinder.cross_az_attach even useful?

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


The plot thickens.

I was checking to see what change was made to start passing the
server instance az on the volume create call during boot from
volume, and that was [1] which was added in kilo to fix a bug where
boot from volume into a nova az will fail if
cinder.cross_az_attach=False and storage_availability_zone is set in
cinder.conf.

So I guess we can't just stop passing the instance az to the volume
create call.

But what I'd really like to know is how 

Re: [openstack-dev] [nova][cinder] how to handle AZ bug 1496235?

[Andrew Laski]

On 09/23/15 at 01:45pm, John Griffith wrote:



​To be honest this is probably my fault, AZ's were pulled in as part of the
nova-volume migration to Cinder and just sort of died.  Quite frankly I
wasn't sure "what" to do with them but brought over the concept and the
zones that existing in Nova-Volume.  It's been an issue since day 1 of
Cinder, and as you note there are little hacks here and there over the
years to do different things.

I think your question about whether they should be there at all or not is a
good one.  We have had some interest from folks lately that want to couple
Nova and Cinder AZ's (I'm really not sure of any details or use-cases here).

My opinion would be until somebody proposes a clear use case and need that
actually works that we consider deprecating it.


I've heard some discussion about trying to use coupled AZs in order to 
schedule volumes close to instances.  However I think that is occurring 
because it's possible to do that, not because that would be a good way 
to handle the coordinated scheduling problem.


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

Re: [openstack-dev] [nova][cinder] how to handle AZ bug 1496235?

[Andrew Laski]

On 09/23/15 at 02:55pm, Matt Riedemann wrote:



On 9/23/2015 2:45 PM, John Griffith wrote:



On Wed, Sep 23, 2015 at 1:34 PM, Matt Riedemann
> wrote:



   On 9/23/2015 2:15 PM, Matt Riedemann wrote:



   On 9/23/2015 1:46 PM, Ivan Kolodyazhny wrote:

   Hi Matt,

   In Liberty, we introduced allow_availability_zone_fallback
   [1] option in
   Cinder config as fix for bug [2]. If you set this option,
   Cinder will
   create volume in a default AZ instead of set volume into the
   error state

   [1]
   
https://github.com/openstack/cinder/commit/b85d2812a8256ff82934d150dbc4909e041d8b31

   [2] https://bugs.launchpad.net/cinder/+bug/1489575

   Regards,
   Ivan Kolodyazhny

   On Wed, Sep 23, 2015 at 9:00 PM, Matt Riedemann
   
   >> wrote:

I came across bug 1496235 [1] today.  In this case the
   user is
booting an instance from a volume using source=image,
   so nova
actually does the volume create call to the volume
   API.  They are
booting the instance into a valid nova availability
   zone, but that
same AZ isn't defined in Cinder, so the volume create
   request fails
(since nova passes the instance AZ to cinder [2]).

I marked this as invalid given how the code works.

I'm posting here since I'm wondering if there are
   alternatives worth
pursuing.  For example, nova could get the list of AZs
   from the
volume API and if the nova AZ isn't in that list, don't
   provide it
on the volume create request.  That's essentially the
   same as first
creating the volume outside of nova and not specifying
   an AZ, then
when doing the boot from volume, provide the volume_id
   as the source.

The question is, is it worth doing that?  I'm not
   familiar enough
with how availability zones are meant to work between
   nova and
cinder so it's hard for me to have much of an opinion here.

[1] https://bugs.launchpad.net/nova/+bug/1496235
[2]

   
https://github.com/openstack/nova/blob/master/nova/virt/block_device.py#L381-L383


--

Thanks,

Matt Riedemann



   
__

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


   

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




   
__

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

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


   Sorry but that seems like a hack.

   I'm trying to figure out the relationship between AZs in nova
   and cinder
   and so far no one seems to really know.  In the cinder IRC
   channel I was
   told there isn't one, which would mean we shouldn't even try
   creating
   the volume using the server instance AZ.

   Also, if there is no relationship, I was trying to figure out
   why there
   is the cinder.cross_az_attach config option.  That was added in
   grizzly
   [1].  I was thinking maybe it was a legacy artifact from
   nova-volume,
   but that was dropped in grizzly.

   So is cinder.cross_az_attach even useful?

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


   The plot thickens.

   I was checking to see what change was made to start passing the
   server instance az on the volume create call during boot from
   volume, and that was [1] which was added in kilo to fix a bug where
   boot from volume into a nova az will fail if
   cinder.cross_az_attach=False and storage_availability_zone is set in
   cinder.conf.

   So I guess we can't just stop passing the instance az to the volume
   create call.

   But what I'd really like to know is how this is all used between
   cinder and nova, or 

Re: [openstack-dev] [nova][cinder] how to handle AZ bug 1496235?

[Sylvain Bauza]

Le 23/09/2015 22:15, Andrew Laski a écrit :

On 09/23/15 at 01:45pm, John Griffith wrote:



​To be honest this is probably my fault, AZ's were pulled in as part 
of the

nova-volume migration to Cinder and just sort of died.  Quite frankly I
wasn't sure "what" to do with them but brought over the concept and the
zones that existing in Nova-Volume.  It's been an issue since day 1 of
Cinder, and as you note there are little hacks here and there over the
years to do different things.

I think your question about whether they should be there at all or 
not is a
good one.  We have had some interest from folks lately that want to 
couple
Nova and Cinder AZ's (I'm really not sure of any details or use-cases 
here).


My opinion would be until somebody proposes a clear use case and need 
that

actually works that we consider deprecating it.


I've heard some discussion about trying to use coupled AZs in order to 
schedule volumes close to instances.  However I think that is 
occurring because it's possible to do that, not because that would be 
a good way to handle the coordinated scheduling problem.




So, while I think it's understandable to have that done, since Nova AZs 
are related to compute nodes and Cinder AZs could be related to volumes, 
I'd tend to ask Cinder to rename the AZ concept into something else less 
confusing.


Also, there is a long story about trying to have Cinder provide 
resources to the Nova scheduler so that we could have volume affinity 
when booting, so I would prefer to go that way instead of trying to 
misuse AZs.


I'm about to ask for a Nova/Cinder/Neutron room at the Summit to discuss 
how Cinder and Neutron could provide resources to the scheduler, I'd 
love to get feedback from those teams there.


 -Sylvain

__ 


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

[ZZelle]

Hi


> Ok, how exactly does that work? Because it seems like
> oslo_middleware.ssl is only changing the protocol if the proxy sets it.
>
> But the host in the urls will still be the individual host, which isn't
> the proxy hostname/ip. Sorry if I'm being daft here, just want to
> understand how that flow ends up working.
>

Host and X-Forwarded-Proto headers are provided by the proxy to the service.
Host and X-Forwarded-Proto headers are either built by the proxy or
forwarded (if there are many proxies).


> Will that cover the case of webob's request.application_uri? If so I
> think that covers the REST documents in at least Nova (one good data
> point, and one that I know has been copied around). At least as far as
> the protocol is concerned, it's still got a potential url issue.


I let Julien answers :)


> It also looks like there are new standards for Forwarded headers, so the
> middleware should probably support those as well.
> http://tools.ietf.org/html/rfc7239.
>

Good to know! I can update SSLMiddleware to handle it as the rfc uses the
format:

  "Forwarded: proto=https"

which is different from de facto standard (supported by SSLMiddleware):

  "X-Forwarded-Proto: https"

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

Re: [openstack-dev] [nova][cinder] how to handle AZ bug 1496235?

[Andrew Laski]

On 09/23/15 at 04:30pm, Mathieu Gagné wrote:

On 2015-09-23 4:12 PM, Andrew Laski wrote:

On 09/23/15 at 02:55pm, Matt Riedemann wrote:


Heh, so when I just asked in the cinder channel if we can just
deprecate nova boot from volume with source=(image|snapshot|blank)
(which automatically creates the volume and polls for it to be
available) and then add a microversion that doesn't allow it, I was
half joking, but I see we're on the same page.  This scenario seems to
introduce a lot of orchestration work that nova shouldn't necessarily
be in the business of handling.


I am very much in support of this.  This has been a source of
frustration for our users because it is prone to failures we can't
properly expose to users and timeouts.  There are much better places to
handle the orchestration of creating a volume and then booting from it
than Nova.



Unfortunately, this is a feature our users *heavily* rely on and we
worked very hard to make it happen. We had a private patch on our side
for years to optimize boot-from-volume before John Griffith came up with
an upstream solution for SolidFire [2] and others with a generic
solution [3] [4].

Being able to "nova boot" and have everything done for you is awesome.
Just see what Monty Taylor mentioned in his thread about sane default
networking [1]. Having orchestration on the client side is just
something our users don't want to have to do and often complain about.


At risk of getting too offtopic I think there's an alternate solution to 
doing this in Nova or on the client side.  I think we're missing some 
sort of OpenStack API and service that can handle this.  Nova is a low 
level infrastructure API and service, it is not designed to handle these 
orchestrations.  I haven't checked in on Heat in a while but perhaps 
this is a role that it could fill.


I think that too many people consider Nova to be *the* OpenStack API 
when considering instances/volumes/networking/images and that's not 
something I would like to see continue.  Or at the very least I would 
like to see a split between the orchestration/proxy pieces and the 
"manage my VM/container/baremetal" bits.




[1]
http://lists.openstack.org/pipermail/openstack-dev/2015-September/074527.html
[2] https://review.openstack.org/#/c/142859/
[3] https://review.openstack.org/#/c/195795/
[4] https://review.openstack.org/#/c/201754/

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

[openstack-dev] Election tools work session in Tokyo

[Tony Breeds]

Hi All,
As most of you will have seen we used a gerrit based workflow for this PTL
election (and will use the same system for the upcoming TC election).

As a trial it went well, Tristan and I wrote a few tools to help the process
along.  However I'd like to take advantage of a work session in Tokyo to get a
few interested parties together to enhance the system before the N release.

To be fair, not of this *requires* people to be in a room together but the
momentum would be helpful.

What is the process for requesting a room?

Once we have a room it'd be good to work through what we want the 'N' election
season to work like so that we can start implementing that.

Thoughts?

Yours Tony.


pgpo2yJfg7JCt.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] Election tools work session in Tokyo

[Thierry Carrez]

Tony Breeds wrote:
> Hi All,
> As most of you will have seen we used a gerrit based workflow for this PTL
> election (and will use the same system for the upcoming TC election).
> 
> As a trial it went well, Tristan and I wrote a few tools to help the process
> along.  However I'd like to take advantage of a work session in Tokyo to get a
> few interested parties together to enhance the system before the N release.
> 
> To be fair, not of this *requires* people to be in a room together but the
> momentum would be helpful.
> 
> What is the process for requesting a room?
> 
> Once we have a room it'd be good to work through what we want the 'N' election
> season to work like so that we can start implementing that.
> 
> Thoughts?

This is a bit cross-project, so the natural fit would be a cross-project
workshop, which you can suggest at http://odsreg.openstack.org (see
Flavio's recent email on that). It's a bit specific though, so I'm not
sure it will be approved for a full session.

Alternatively that could fit in a infra work session, you may want to
suggest it there (not sure if they have opened an etherpad for session
suggestion yet).

Otherwise we could also discuss it as part of the Infra/QA/RelMgt
contributors meetup on Friday.

-- 
Thierry Carrez (ttx)



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] [nova][cinder] how to handle AZ bug 1496235?

[Ikuo Kumagai]

Hi All,

I'm sorry I was in vacation yesterday(in JST), and I did not notice this
discussion.
I registered "bug 1496235".

In our case , there is Nova 2 az(az1, az2),and Cinder 1 az (default).
Cinder backend is ceph, that is a cluster of compute nodes inclued az1 and
az2 of nova. Nova's 2 az always use cinder default zone .

When I resistered, the option I wanted is that I can select "sync" or
"async" az between nova and cinder.

Regards,
IKUO Kumagai


2015-09-24 10:05 GMT+09:00 Sam Morrison :

>
> > On 24 Sep 2015, at 9:59 am, Andrew Laski  wrote:
> >
> > I was perhaps hasty in approving that patch and didn't realize that Matt
> had reached out for operator feedback at the same time that he proposed it.
> Since this is being used in production I wouldn't want it to be removed
> without at least having an alternative, and hopefully better, method of
> achieving your goal.  Reverting the deprecation seems reasonable to me for
> now while we work out the details around Cinder/Nova AZ interactions.
>
> Thanks Andrew,
>
> What we basically want is for our users to have instances and volumes on a
> section of hardware and then for them to be able to have other instances
> and volumes in another section of hardware.
>
> If one section dies then the other section is fine. For us we use
> availability-zones for this. If this is not the intended use for AZs what
> is a better way for us to do this.
>
> Cheers,
> Sam
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [oslo][doc] Oslo doc sprint 9/24-9/25

[Anita Kuno]

On 09/23/2015 07:18 PM, Davanum Srinivas wrote:
> Reminder, we are doing the Doc Sprint tomorrow. Please help out with what
> ever item or items you can.
> 
> Thanks,
> Dims
> 
> On Wed, Sep 16, 2015 at 5:40 PM, James Carey 
> wrote:
> 
>> In order to improve the Oslo libraries documentation, the Oslo team is
>> having a documentation sprint from 9/24 to 9/25.
>>
>> We'll kick things off at 14:00 UTC on 9/24 in the
>> #openstack-oslo-docsprint IRC channel and we'll use an etherpad [0].

Have you considered using the #openstack-sprint channel, which can be
booked here: https://wiki.openstack.org/wiki/VirtualSprints

and was created for just this kind of occasion. Also it has channel
logging, helpful for those trying to co-ordinate across timezones.

May you have a good sprint,
Anita.

>>
>> All help is appreciated.   If you can help or have suggestions for
>> areas of focus, please update the etherpad.
>>
>> [0] https://etherpad.openstack.org/p/oslo-liberty-virtual-doc-sprint
>>
>> __
>> OpenStack Development Mailing 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][cinder] how to handle AZ bug 1496235?

[Andrew Laski]

On 09/24/15 at 09:34am, Sam Morrison wrote:

Just got alerted to this on the operator list.

We very much rely on this.

We have multiple availability zones in nova and each zone has a corresponding 
cinder-volume service(s) in the same availability zone.

We don’t want people attaching a volume from one zone to another as the network 
won’t allow that as the zones are in different network domains and different 
data centres.

I wonder if you guys can reconsider deprecating this option as it is very 
useful to us.


I was perhaps hasty in approving that patch and didn't realize that Matt 
had reached out for operator feedback at the same time that he proposed 
it.  Since this is being used in production I wouldn't want it to be 
removed without at least having an alternative, and hopefully better, 
method of achieving your goal.  Reverting the deprecation seems 
reasonable to me for now while we work out the details around 
Cinder/Nova AZ interactions.






Cheers,
Sam




On 24 Sep 2015, at 7:43 am, Mathieu Gagné  wrote:

On 2015-09-23 4:50 PM, Andrew Laski wrote:

On 09/23/15 at 04:30pm, Mathieu Gagné wrote:

On 2015-09-23 4:12 PM, Andrew Laski wrote:

On 09/23/15 at 02:55pm, Matt Riedemann wrote:


Heh, so when I just asked in the cinder channel if we can just
deprecate nova boot from volume with source=(image|snapshot|blank)
(which automatically creates the volume and polls for it to be
available) and then add a microversion that doesn't allow it, I was
half joking, but I see we're on the same page.  This scenario seems to
introduce a lot of orchestration work that nova shouldn't necessarily
be in the business of handling.


I am very much in support of this.  This has been a source of
frustration for our users because it is prone to failures we can't
properly expose to users and timeouts.  There are much better places to
handle the orchestration of creating a volume and then booting from it
than Nova.



Unfortunately, this is a feature our users *heavily* rely on and we
worked very hard to make it happen. We had a private patch on our side
for years to optimize boot-from-volume before John Griffith came up with
an upstream solution for SolidFire [2] and others with a generic
solution [3] [4].

Being able to "nova boot" and have everything done for you is awesome.
Just see what Monty Taylor mentioned in his thread about sane default
networking [1]. Having orchestration on the client side is just
something our users don't want to have to do and often complain about.


At risk of getting too offtopic I think there's an alternate solution to
doing this in Nova or on the client side.  I think we're missing some
sort of OpenStack API and service that can handle this.  Nova is a low
level infrastructure API and service, it is not designed to handle these
orchestrations.  I haven't checked in on Heat in a while but perhaps
this is a role that it could fill.

I think that too many people consider Nova to be *the* OpenStack API
when considering instances/volumes/networking/images and that's not
something I would like to see continue.  Or at the very least I would
like to see a split between the orchestration/proxy pieces and the
"manage my VM/container/baremetal" bits.



"too many people" happens to include a lot of 3rd party tools supporting
OpenStack which our users complain a lot about. Just see all the
possible way to get an external IP [5]. Introducing yet another service
would increase the pain on our users which will see their tools and
products not working even more.

Just see how EC2 is doing it [6], you won't see them suggest to use yet
another service to orchestrate what I consider a fundamental feature "I
wish to boot an instance on a volume".

The current ease to boot from volume is THE selling feature our users
want and heavily/actively use. We fought very hard to make it work and
reading about how it should be removed is frustrating.

Issues we identified shouldn't be a reason to drop this feature. Other
providers are making it work and I don't see why we couldn't. I'm
convinced we can do better.

[5]
https://github.com/openstack-infra/shade/blob/03c1556a12aabfc21de60a9fac97aea7871485a3/shade/meta.py#L106-L173
[6]
http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/block-device-mapping-concepts.html

Mathieu



[1]
http://lists.openstack.org/pipermail/openstack-dev/2015-September/074527.html

[2] https://review.openstack.org/#/c/142859/
[3] https://review.openstack.org/#/c/195795/
[4] https://review.openstack.org/#/c/201754/

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

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

[Jamie Lennox]

So this is a long thread and i may have missed something in it,
however this exact topic came up as a blocker on a devstack patch to
get TLS testing in the gate with HAproxy.

The long term solution we had come up with (but granted not proposed
anywhere public) is that we should transition services to use relative
links.

As far as i'm aware this is only a problem within the services
themselves as the URL they receive is not what was actually requested
if it went via HAproxy. It is not a problem with interservice requests
because they should get URLs from the service catalog (or otherwise
not display them to the user). Which means that this generally affects
the version discovery page, and "links" from resources to like a next,
prev, and base url.

Is there a reason we can't transition this to use a relative URL
possibly with a django style WEBROOT so that a discovery response
returned /v2.0 and /v3 rather than the fully qualified URL and the
clients be smart enough to figure this out?



On 24 September 2015 at 07:51, Julien Danjou  wrote:
> On Wed, Sep 23 2015, Sean Dague wrote:
>
>> Ok, how exactly does that work? Because it seems like
>> oslo_middleware.ssl is only changing the protocol if the proxy sets it.
>>
>> But the host in the urls will still be the individual host, which isn't
>> the proxy hostname/ip. Sorry if I'm being daft here, just want to
>> understand how that flow ends up working.
>
> No problem, you're no supposed to know everything. :)
>
> As ZZelle said too, we can set the correct host and port expected by
> honoring X-Forwarded-Host and X-Forwarded-Port, which are set by HTTP
> proxies when they act as reverse-proxies and forward requests.
> That will make the WSGI application unaware of the fact that there is a
> request proxy in front of them. Magic!
>
> We could do that in the SSL middleware (and maybe rename it?) or in
> another middleware, and enable them by default. So we'd have that
> working by default, which would be great IMHO.
>
>> Will that cover the case of webob's request.application_uri? If so I
>> think that covers the REST documents in at least Nova (one good data
>> point, and one that I know has been copied around). At least as far as
>> the protocol is concerned, it's still got a potential url issue.
>
> That should work with any WSGI request, so I'd say yes.
>
>>> The {public,admin}_endpoint are only useful in the case where you map
>>> http://myproxy/identity -> http://mykeystone/ using a proxy
>>>
>>> Because the prefix is not passed to Keystone. If you map 1:1 the path
>>> part, we could also leverage X-Forwarded-Host and X-Forwarded-Port to
>>> avoid having {public,admin}_endpoint options.
>>
>> It also looks like there are new standards for Forwarded headers, so the
>> middleware should probably support those as well.
>> http://tools.ietf.org/html/rfc7239.
>
> Good point, we should update the middleware as needed.
>
> Though they still not cover that use case where you have a base URL that
> is different between the proxy and the application. I don't think it's a
> widely used case, but still, there are at 2 least two way to support it:
> 1. Having config option (like Keystone currently has)
> 2. Having a special e.g. X-Forwarded-BaseURL header set by the proxy
>that we would catch in our middleware and would prepend to
>environment['SCRIPT_NAME'].
>
> The 2 options are even compatible, though I'd say 2. is probably simpler
> in the long run and more… "unified".
>
> I'm willing to clear that out and come with specs and patches if that
> can help. :)
>
> --
> Julien Danjou
> # Free Software hacker
> # http://julien.danjou.info
>
> __
> OpenStack Development Mailing 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] [oslo][doc] Oslo doc sprint 9/24-9/25

[Davanum Srinivas]

Reminder, we are doing the Doc Sprint tomorrow. Please help out with what
ever item or items you can.

Thanks,
Dims

On Wed, Sep 16, 2015 at 5:40 PM, James Carey 
wrote:

> In order to improve the Oslo libraries documentation, the Oslo team is
> having a documentation sprint from 9/24 to 9/25.
>
> We'll kick things off at 14:00 UTC on 9/24 in the
> #openstack-oslo-docsprint IRC channel and we'll use an etherpad [0].
>
> All help is appreciated.   If you can help or have suggestions for
> areas of focus, please update the etherpad.
>
> [0] https://etherpad.openstack.org/p/oslo-liberty-virtual-doc-sprint
>
> __
> OpenStack Development Mailing 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] [nova][cinder] how to handle AZ bug 1496235?

[Sam Morrison]

Just got alerted to this on the operator list.

We very much rely on this.

We have multiple availability zones in nova and each zone has a corresponding 
cinder-volume service(s) in the same availability zone.

We don’t want people attaching a volume from one zone to another as the network 
won’t allow that as the zones are in different network domains and different 
data centres.

I wonder if you guys can reconsider deprecating this option as it is very 
useful to us.

Cheers,
Sam



> On 24 Sep 2015, at 7:43 am, Mathieu Gagné  wrote:
> 
> On 2015-09-23 4:50 PM, Andrew Laski wrote:
>> On 09/23/15 at 04:30pm, Mathieu Gagné wrote:
>>> On 2015-09-23 4:12 PM, Andrew Laski wrote:
 On 09/23/15 at 02:55pm, Matt Riedemann wrote:
> 
> Heh, so when I just asked in the cinder channel if we can just
> deprecate nova boot from volume with source=(image|snapshot|blank)
> (which automatically creates the volume and polls for it to be
> available) and then add a microversion that doesn't allow it, I was
> half joking, but I see we're on the same page.  This scenario seems to
> introduce a lot of orchestration work that nova shouldn't necessarily
> be in the business of handling.
 
 I am very much in support of this.  This has been a source of
 frustration for our users because it is prone to failures we can't
 properly expose to users and timeouts.  There are much better places to
 handle the orchestration of creating a volume and then booting from it
 than Nova.
 
>>> 
>>> Unfortunately, this is a feature our users *heavily* rely on and we
>>> worked very hard to make it happen. We had a private patch on our side
>>> for years to optimize boot-from-volume before John Griffith came up with
>>> an upstream solution for SolidFire [2] and others with a generic
>>> solution [3] [4].
>>> 
>>> Being able to "nova boot" and have everything done for you is awesome.
>>> Just see what Monty Taylor mentioned in his thread about sane default
>>> networking [1]. Having orchestration on the client side is just
>>> something our users don't want to have to do and often complain about.
>> 
>> At risk of getting too offtopic I think there's an alternate solution to
>> doing this in Nova or on the client side.  I think we're missing some
>> sort of OpenStack API and service that can handle this.  Nova is a low
>> level infrastructure API and service, it is not designed to handle these
>> orchestrations.  I haven't checked in on Heat in a while but perhaps
>> this is a role that it could fill.
>> 
>> I think that too many people consider Nova to be *the* OpenStack API
>> when considering instances/volumes/networking/images and that's not
>> something I would like to see continue.  Or at the very least I would
>> like to see a split between the orchestration/proxy pieces and the
>> "manage my VM/container/baremetal" bits.
>> 
> 
> "too many people" happens to include a lot of 3rd party tools supporting
> OpenStack which our users complain a lot about. Just see all the
> possible way to get an external IP [5]. Introducing yet another service
> would increase the pain on our users which will see their tools and
> products not working even more.
> 
> Just see how EC2 is doing it [6], you won't see them suggest to use yet
> another service to orchestrate what I consider a fundamental feature "I
> wish to boot an instance on a volume".
> 
> The current ease to boot from volume is THE selling feature our users
> want and heavily/actively use. We fought very hard to make it work and
> reading about how it should be removed is frustrating.
> 
> Issues we identified shouldn't be a reason to drop this feature. Other
> providers are making it work and I don't see why we couldn't. I'm
> convinced we can do better.
> 
> [5]
> https://github.com/openstack-infra/shade/blob/03c1556a12aabfc21de60a9fac97aea7871485a3/shade/meta.py#L106-L173
> [6]
> http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/block-device-mapping-concepts.html
> 
> Mathieu
> 
>>> 
>>> [1]
>>> http://lists.openstack.org/pipermail/openstack-dev/2015-September/074527.html
>>> 
>>> [2] https://review.openstack.org/#/c/142859/
>>> [3] https://review.openstack.org/#/c/195795/
>>> [4] https://review.openstack.org/#/c/201754/
>>> 
>>> -- 
>>> 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] [neutron] Neutron debugging tool

[Nodir Kodirov]

Thanks for the great suggestions and pointers, everyone!

easyOVS seems to cover many use cases I had in my mind. I'll give it a
try and see if/how I can extend it.

I do agree with Salvatore about putting reference to all these tools
in OpenStack docs. I filed a docs bug [1] suggesting that we need to
add (sub-)section to Chapter 12. Network Troubleshooting in OpenStack
Operations Guide [2]. This way, tools will be quickly exposed to the
docs surface and one does not need to spend hours to discover them
from scattered places.

Again, thanks for all input!

Nodir

[1] https://bugs.launchpad.net/openstack-manuals/+bug/1499114
[2] http://docs.openstack.org/openstack-ops/content/network_troubleshooting.html

On 22 September 2015 at 05:27, Carol Bouchard (caboucha)
 wrote:
> There was a presentation on DON at the Vancouver summit.  Here is the link:
>
>
>
> https://www.openstack.org/summit/vancouver-2015/summit-videos/presentation/don-diagnosing-ovs-in-neutron
>
>
>
> From: Salvatore Orlando [mailto:salv.orla...@gmail.com]
> Sent: Tuesday, September 22, 2015 3:51 AM
> To: OpenStack Development Mailing List (not for usage questions)
>
>
> Subject: Re: [openstack-dev] [neutron] Neutron debugging tool
>
>
>
> Thanks Ganesh!
>
>
>
> I did not know about this tool.
>
> I also quite like the network visualization bits, though I wonder how
> practical that would be when one debugs very large deployments.
>
>
>
> I think it won't be a bad idea to list these tools in the networking guide
> or in neutron's devref, or both.
>
>
>
> Salvatore
>
>
>
> On 22 September 2015 at 04:25, Ganesh Narayanan (ganeshna)
>  wrote:
>
> Another project for diagnosing OVS in Neutron:
>
>
>
> https://github.com/CiscoSystems/don
>
>
>
> Thanks,
>
> Ganesh
>
>
>
> From: Salvatore Orlando 
> Reply-To: OpenStack Development Mailing List
> 
> Date: Monday, 21 September 2015 2:55 pm
> To: OpenStack Development Mailing List 
> Subject: Re: [openstack-dev] [neutron] Neutron debugging tool
>
>
>
> It sounds like indeed that easyOVS covers what you're aiming too.
>
> However, from what I gather there is still plenty to do in easy OVS, so
> perhaps rather than starting a new toolset from scratch you might build on
> the existing one.
>
>
>
> Personally I'd welcome its adoption into the Neutron stadium as debugging
> control plane/data plane issues in the neutron reference impl is becoming
> difficult also for expert users and developers.
>
> I'd just suggest renaming it because calling it "OVS" is just plain wrong.
> The neutron reference implementation and OVS are two distinct things.
>
>
>
> As concern neutron-debug, this is a tool that was developed in the early
> stages of the project to verify connectivity using "probes" in namespaces.
> These probes are simply tap interfaces associated with neutron ports. The
> neutron-debug tool is still used in some devstack exercises. Nevertheless,
> I'd rather keep building something like easyOVS and then deprecated
> neutron-debug rather than develop it.
>
>
>
> Salvatore
>
>
>
>
>
> On 21 September 2015 at 02:40, Li Ma  wrote:
>
> AFAIK, there is a project available in the github that does the same thing.
> https://github.com/yeasy/easyOVS
>
> I used it before.
>
>
> On Mon, Sep 21, 2015 at 12:17 AM, Nodir Kodirov 
> wrote:
>> Hello,
>>
>> I am planning to develop a tool for network debugging. Initially, it
>> will handle DVR case, which can also be extended to other too. Based
>> on my OpenStack deployment/operations experience, I am planning to
>> handle common pitfalls/misconfigurations, such as:
>> 1) check external gateway validity
>> 2) check if appropriate qrouter/qdhcp/fip namespaces are created in
>> compute/network hosts
>> 3) execute probing commands inside namespaces, to verify reachability
>> 4) etc.
>>
>> I came across neutron-debug [1], which mostly focuses on namespace
>> debugging. Its coverage is limited to OpenStack, while I am planning
>> to cover compute/network nodes as well. In my experience, I had to ssh
>> to the host(s) to accurately diagnose the failure (e.g., 1, 2 cases
>> above). The tool I am considering will handle these, given the host
>> credentials.
>>
>> I'd like get community's feedback on utility of such debugging tool.
>> Do people use neutron-debug on their OpenStack environment? Does the
>> tool I am planning to develop with complete diagnosis coverage sound
>> useful? Anyone is interested to join the development? All feedback are
>> welcome.
>>
>> Thanks,
>>
>> - Nodir
>>
>> [1]
>> http://docs.openstack.org/cli-reference/content/neutron-debug_commands.html
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> 

[openstack-dev] [all][stable][release] 2015.1.2

[Chuck Short]

Hi,

We would like to do a stable/kilo branch release, next Thursday. In order
to do that I would like to freeze the branches on Friday. Cut some test
tarballs on Tuesday and release on Thursday. Does anyone have an opinnon on
this?

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

Re: [openstack-dev] [nova][cinder] how to handle AZ bug 1496235?

[Sam Morrison]

> On 24 Sep 2015, at 9:59 am, Andrew Laski  wrote:
> 
> I was perhaps hasty in approving that patch and didn't realize that Matt had 
> reached out for operator feedback at the same time that he proposed it. Since 
> this is being used in production I wouldn't want it to be removed without at 
> least having an alternative, and hopefully better, method of achieving your 
> goal.  Reverting the deprecation seems reasonable to me for now while we work 
> out the details around Cinder/Nova AZ interactions.

Thanks Andrew,

What we basically want is for our users to have instances and volumes on a 
section of hardware and then for them to be able to have other instances and 
volumes in another section of hardware.

If one section dies then the other section is fine. For us we use 
availability-zones for this. If this is not the intended use for AZs what is a 
better way for us to do this.

Cheers,
Sam



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

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

[Dmitry Borodaenko]

Vladimir,

Sergey's initial email from this thread has a link to the Fuel elections
wiki page that describes the exact procedure to determine the electorate
and the candidates [0]:

The electorate for a given PTL and Component Leads election are the
Foundation individual members that are also committers for one of
the Fuel team's repositories over the last year timeframe (September
18, 2014 06:00 UTC to September 18, 2015 05:59 UTC).

...

Any member of an election electorate can propose their candidacy for
the same election.

[0] https://wiki.openstack.org/wiki/Fuel/Elections_Fall_2015#Electorate

If you follow more links from that page, you will find the Governance
page [1] and from there the Election Officiating Guidelines [2] that
provide a specific shell one-liner to generate that list:

git log --pretty=%aE --since '1 year ago' | sort -u

[1] https://wiki.openstack.org/wiki/Governance
[2] https://wiki.openstack.org/wiki/Election_Officiating_Guidelines

As I have specified in the proposed Team Structure policy document [3],
this is the same process that is used by other OpenStack projects.

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

Having a different release schedule is not a sufficient reason for Fuel
to reinvent the wheel, for example OpenStack Infrastructure project
doesn't even have a release schedule for many of its deliverables, and
still follows the same elections schedule as the rest of OpenStack:

[4] http://governance.openstack.org/reference/projects/infrastructure.html

Lets keep things simple.

-- 
Dmitry Borodaenko


On Wed, Sep 23, 2015 at 01:27:07PM +0300, Vladimir Kuklin wrote:
> Dmitry, Mike
> 
> Thank you for the list of usable links.
> 
> But still - we do not have clearly defined procedure on determening who is
> eligible to nominate and vote for PTL and Component Leads. Remember, that
> Fuel still has different release cycle and Kilo+Liberty contributors list
> is not exactly the same for "365days" contributors list.
> 
> Can we finally come up with the list of people eligible to nominate and
> vote?
> 
> On Sun, Sep 20, 2015 at 2:37 AM, Mike Scherbakov 
> wrote:
> 
> > Let's move on.
> > I started work on MAINTAINERS files, proposed two patches:
> > https://review.openstack.org/#/c/225457/1
> > https://review.openstack.org/#/c/225458/1
> >
> > These can be used as templates for other repos / folders.
> >
> > Thanks,
> >
> > On Fri, Sep 18, 2015 at 7:45 PM Davanum Srinivas 
> > wrote:
> >
> >> +1 Dmitry
> >>
> >> -- Dims
> >>
> >> On Fri, Sep 18, 2015 at 9:07 PM, Dmitry Borodaenko <
> >> dborodae...@mirantis.com> 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 

Re: [openstack-dev] [all] Cross-Project track topic proposals

[Jim Rollenhagen]

On Wed, Sep 23, 2015 at 10:45:56AM +0200, Flavio Percoco wrote:
> Greetings,
> 
> The community is in the process of collecting topics for the
> cross-project tack that we'll have in the Mitaka summit.
> 
> The good ol' OSDREG has been setup[0] to help collectiong these topics
> and we'd like to encourage the community to propose sessions there.

As a note, ODSREG appears to require a valid oauth login, even for read
access. Though all developers should have a valid login, this isn't
awesome in the spirit of openness. Is this intentional / should that be
fixed?

// 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-dev] [neutron][networking-ovn][vtep] Proposal: support for vtep-gateway in ovn

[Amitabha Biswas]

Hi everyone,
I want to open up the discussion regarding how to support OVN VTEP gateway deployment and its lifecycle in Neutron. 
In the "Life Cycle of a VTEP gateway" part in the OVN architecture document (http://www.russellbryant.net/ovs-docs/ovn-architecture.7.pdf), step 3 is where the Neutron OVN plugin is involved. At a minimum, the Neutron OVN plugin will enable setting the type as "vtep" and the vtep-logical-switch and vtep-physical-switch options in the OVN_Northbound database.
 
There are 2 parts to the proposal/discussion - a short term solution and a long term one:
A short term solution (proposed by Russell Bryant) is similar to the work that was done for container support in OVN - using a binding profile http://networking-ovn.readthedocs.org/en/latest/containers.html. A ovn logical network/switch can be mapped to a vtep logical gateway by creating a port in that logical network and creating a binding profile for that port in the following manner:
neutron port-create --binding-profile '{"vtep-logical-switch":"vtep_lswitch_key", "vtep-physical-switch":"vtep_pswitch_key"}' private.
Where vtep-logical-switch and vtep-physical-switch should have been defined in the OVN_Southbound database by the previous steps (1,2) in the life cycle. 
 
For the longer term solution, there needs to be a discussion:
Should the knowledge about the physical and logical step gateway should be exposed to Neutron - if yes how? This would allow a Neutron NB API/extension to bind a “known” vtep gateway to the neutron logical network. This would be similar to the workflow done in the networking-l2gw extension https://review.openstack.org/#/c/144173/3/specs/kilo/l2-gateway-api.rst
1. Allow the admin to define and manage the vtep gateway through Neutron REST API.
2. Define connections between Neutron networks and gateways. This is conceptually similar to Step 3 of the step gateway performed by the OVN Plugin in the short term solution.
OR
Should OVN pursue it’s own Neutron extension (including vtep gateway support).
 
Thanks Amitabha



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