Re: [openstack-dev] [kolla][release] Announcing Liberty-1 release of Kolla

[Steven Dake (stdake)]

On 7/1/15, 3:50 PM, "Kevin Carter"  wrote:

>Steve, 
>
>The initial review you guys had done did help a bunch and it was great to
>work with you and everyone else in the channel. As you're aware, code
>base that you had tested was our Juno (stable at that time) release which
>has more than its fair share of Rackspace-isms. One of which is the
>requirement to have access to the upstream repository for the
>installation of its python bits. So within that release it is true that
>if the upstream repository were to go away a redeployment or the
>expansion of the stack would be impossible until service was restored.
>While you could always self host the upstream repos, there is an open
>rsync relay, that wasn't functionality baked into OSAD at that time.
>However, since your eval we've released Kilo which now provides for the
>ability to self-host all of the python bits / container images / and
>anything else you may need or want from within the infrastructure (that's
>the default and what we gate on). While this functionality existed in
>master when you guys had done the test it had not been officially
>released so its likely you had not looked into it at this point.
>Additionally, we've done a huge amount of work to separate Kilo / Master
>from what was done in Icehouse / Juno while also providing an upgrade
>path for our existing deployments which will ensure that deployers are
>able to take advantage of the general improvements throughout the stack
>in Kilo and beyond. We, like you, do still have to reliance on some
>upstream resources however the inclusion of the repo-server containers
>should thwart these issues. Our python bits are built once within that
>repo-server infrastructure and everything within the OSAD points to the
>internal repository for its source of truth. As I said, we still have
>some reliance on upstream and likely always will but once an OSAD
>deployment is online, in Kilo or Master, it should be able to redeploy
>itself indefinitely. Obviously there's still more that we can do to make
>this better, and we're getting there, but I don't believe the same
>theoretical i!
> ssues you had seen before are present now.
>
>All that said, great work on the Libery-1 release and I look forward to
>play with Kolla with these new bits sometime in the near future.

Kevin,

Thanks!

The development team did a fantastic job focusing in Liberty 1 - 14
blueprints - pretty amazing amount of work in a short 5 week cycle.  Plan
to see same level of focus to meet our Liberty-2 milestone goals and
deliver on our complete mission.

Regards
-steve

>
>--
>
>Kevin Carter
>IRC: cloudnull
>
>
>From: Steven Dake (stdake) 
>Sent: Wednesday, July 1, 2015 2:21 PM
>To: OpenStack Development Mailing List (not for usage questions);
>s...@yaple.net
>Subject: Re: [openstack-dev] [kolla][release] Announcing Liberty-1
>release of Kolla
>
>On 7/1/15, 8:11 AM, "Ian Cordasco"  wrote:
>
>>
>>
>>On 6/30/15, 23:36, "Sam Yaple"  wrote:
>>
>>>Ian,
>>>
>>>
>>>The most significant difference would be that Kolla uses image based
>>>deployment rather than building from source on each node at runtime
>>>allowing for a more consistent and repeatable deployment.
>>>
>>
>>Do you mean specific docker images? Can you expand on how
>>os-ansible-deployment is not repeatable? They use an lxc-container cached
>>image so all containers are uniform (consistent, repeatable, etc.) and
>>build wheels (once) and use an internal repo mirror so that all
>>installations use the exact same set of wheels (e.g., consistent and
>>repeatable).
>>
>>Are there places where you've found osad to be not consistent or
>>repeatable?
>
>Ian,
>
>We did a 10 day eval of OSAD and liked the tech.  We did find the way the
>deployment pipeline works to be lacking.  A purely theoretical problem
>with the deployment pipeline is key repositories used to build the
>software could be offline.  Since the building of the software occurs
>during deployment, this could result in an inability to alter the
>configuration of the deployment after OpenStack is deployed.  Kolla
>suffers from this same problem during the installation (build pipeline)
>step.  But as long as you have already built images somewhere in your
>system, you are still able to deploy, avoiding complete downtime on
>deployment that OSAD could theoretically suffer.
>
>This theoretical issue makes the deployment non-repeatable.  Hope our 10
>day eval analysis helps improve OSAD.
>
>Regards
>-steve
>
>>
>>>
>>>On Tue, Jun 30, 2015 at 2:28 PM, Ian Cordasco
>>> wrote:
>>>
>>>
>>>
>>>On 6/29/15, 23:59, "Steven Dake (stdake)"  wrote:
>>>
The Kolla community
is pleased to announce the
 release of the
 Kolla Liberty 1 milestone.  This release fixes 56 bugs
 and implements 14 blueprints!


Our community developed the following notable features:



* A start at
source-basedcontainers
>>>
>>>So how does this now compare to the stackfor

Re: [openstack-dev] [Murano][Congress] Application placement use case

[ruby.krishnaswamy]

Hi


Did you mean placement at “two levels”. First to select the region and then 
within each region, Nova scheduler will place on hosts.

But where will the capabilities of each region (based on which placement 
decision will be made) be stored? Will each region be queried to obtain this 
information?
Will a single application need to be placed (split across) different regions?

Ruby

De : Georgy Okrokvertskhov [mailto:gokrokvertsk...@mirantis.com]
Envoyé : mercredi 1 juillet 2015 21:26
À : OpenStack Development Mailing List
Objet : [openstack-dev] [Murano][Congress] Application placement use case


Hi,


I would like to share with the community one of the real use case which we saw 
while working with one of the Murano customer and ask an advice. This customer 
has multiple OpenStack regions which are serving for different hypervisors. The 
reason for that is Oracle OpenStack which is used to work with Solaris on top 
of SPARC architecture. There are other hypervisors KVM and VMWare which are 
used.

There are multiple applications which should be placed to different regions 
based on their requirements (OS, Hypervisor, networking restrictions). As there 
is no single cloud, Nova scheduler can’t be used (at least in my understanding) 
so we need to have some placement policies to put applications properly. And 
obviously we don’t want to ask end user about the placement.


Right now in Murano we can do this by:

1.Hardcoding placement inside application. This approach will work and does 
not require any significant change in Murano. But there are obvious limitations 
like if we have two options for placement which one should be hardcoded.

2.Create special placement scheduler application\class in Murano which will 
use some logic to place applications properly. This is better approach as 
nothing is hard coded in applications except their requirements. Applications 
will just have a workflow to ask placement scheduler for a decision and then 
will just use this decision.

3.Use some external tool or OpenStack component for placement decision. 
This is a very generic use case which we saw multiple times. Tools like CIRBA 
are often used for this. Murano will need an interface to ask these tools. I 
think about this solution as an extension of 2.


I am aware that Murano is working on integration with Congress and I am looking 
for an opportunity here to address real use case of Murano usage in real 
customer environment. It will be great to know if OpenStack can offer something 
here without involving 3rd party tools. I suspect that this is a good use case 
for Congress, but I would like to see how it might be implemented.


Thanks
Gosha

--
Georgy Okrokvertskhov
Architect,
OpenStack Platform Products,
Mirantis
http://www.mirantis.com
Tel. +1 650 963 9828
Mob. +1 650 996 3284

_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

__
OpenStack Development Mailing List (not for 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][Fuel-Library] Nominate Aleksandr Didenko for fuel-library core

[Mike Scherbakov]

Alex - congratulations! Added you to fuel-library core.

On Tue, Jun 30, 2015 at 3:52 AM, Sebastian Kalinowski <
skalinow...@mirantis.com> wrote:

> +1
>
> 2015-06-30 10:38 GMT+02:00 Evgeniy L :
>
>> +1
>>
>> On Tue, Jun 30, 2015 at 9:34 AM, Igor Kalnitsky 
>> wrote:
>>
>>> +1. Alex's doing a great job!
>>>
>>> On Mon, Jun 29, 2015 at 5:40 PM, Sergey Vasilenko
>>>  wrote:
>>> > +1
>>> >
>>> >
>>> __
>>> > OpenStack Development Mailing List (not for usage questions)
>>> > Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> >
>>>
>>>
>>> __
>>> OpenStack Development Mailing 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
>
>


-- 
Mike Scherbakov
#mihgen
__
OpenStack Development Mailing 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] Rebuilding instances booted from volume

[ZhengZhenyu]

Hi, All
According to my test, Nova cannot rebuild Volume-Booted instances, patch: 
https://review.openstack.org/#/c/176891/fixes rebuild for instances launched 
using image and attached with volumes, but yet rebuilding an instance booted 
from volumeis still not working.
The rebuild action for volume-booted instances after implementing the above 
patch performs like this:
The volumes are detached and attached again, the selected image/snapshot for 
rebuilding is actually useless.This means that if the /dev/vda for an instance 
booted from volume is broken for some reason, we cannot rebuild it from a 
newimage or the snapshot of this instance (nova just detach and attach again 
the same volume).
I don't know whether this is a bug or it is designed on purpose.
Thanks,
BR,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

Re: [openstack-dev] [all][packaging] Adding files to /etc in a package

[Robert Collins]

On 2 July 2015 at 13:26, Thomas Goirand  wrote:
> On 07/02/2015 02:07 AM, Tony Breeds wrote:
>> On Wed, Jul 01, 2015 at 11:07:30PM +, Perry, Sean wrote:
>>> BTW, see dh_bash-completion from the debhelper package. When in doubt about 
>>> packaging on a deb based distro look at the debhelper tools source (which 
>>> is perl).
>>>
>>> -Original Message-
>>> From: Perry, Sean
>>> Sent: Wednesday, July 01, 2015 4:04 PM
>>> To: OpenStack Development Mailing List (not for usage questions)
>>> Subject: RE: [openstack-dev] [all][packaging] Adding files to /etc in a 
>>> package
>>>
>>> According to Debian standards (which Ubuntu follows mostly) if a package
>>> ships bash completion information that file belongs in 
>>> /etc/bash_completion.d
>>> with a file named after the package. You can look in that dir on an
>>> Ubuntu/debian box and see the setup.
>>
>> Right, but I'm talking about python packaging.  Which is certainly closely
>> related to system/distribution packaging, but lacks a lot of the machinery
>> to get it right.
>
> Correct. Python packaging is made for packaging ... python! Not
> configuration files and other system bits.

I'm with you there. BUT. Python programs use configuration files. And
Python programs provide daemons. Its entirely reasonable and expected
within the context of a given program that 'sudo make install' or
'sudo setup.py install' or <...> any number of variations should make
the program be usable by all users of the system that its installing
it into.

I'm going to presume we agree on that in the rest my reply. You may
want to stop here if we don't agree about that.

>> What I'm trying to do is:
>> 1) make it simple for the 'developer' comsumers of the python package to use
>>bash completions (witghout needing the system packages)
>
> Use the source, luke! Or write yourself a small shell script...

Unless-and-until distributions provide a standard home-dir scoped
place to install bash completion scripts, developers and users
installing from python packaging are going to expect that the
completion scripts in the software they are installing get installed.
Expecting every user to home-roll a workaround multiplies the overall
cost by the number of users. So I can imagine three routes...
 - teach the thing being installed to install completion scripts into
the existing right place(s)
 - define a new place thats homedir and virtualenv friendly and teach
the thing installing them to install there.
 - punt and do nothing

There's a big chunk of complexity hidden in my second point there. And
even if we do it we still need to get it onto our dev machines: Mac OS
X, various versions of Ubuntu, Fedora, RHEL and Suse. So I don't think
it makes a lot of sense to bank on getting that right-and-out-there
before we look at the user experience directly.

>> 2) Help the system/distribution packagers or at the very least not make thier
>>life more difficult.
>
> If you attempt to address this, you're making my life miserable. Please
> don't do it, thanks.

Since the entire job of the dh-* script ecosystem is to automate
repeated patterns without making individual developers figure things
out, I find 'miserable' comes across as a massive exaggeration. Surely
its a single one-off dh script to create to handle bash completion
scripts and move them into the right place, and you are done?

-Rob

-- 
Robert Collins 
Distinguished Technologist
HP Converged Cloud

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

Re: [openstack-dev] [puppet] [infra] issues with beaker/centos7 job

[Ian Wienand]

On 07/02/2015 11:52 AM, Emilien Macchi wrote:
> details. I tried to install deltarpm before, but it says : "No Presto
> metadata available for rdo-release".

So I looked into this with Gilles, and that error is a red-herring
(it's just saying the rdo repos don't create the presto/deltarpm
stuff); the real issue is when python-requests fails to install [1] a
bit later due to [2] (mentioned in comments of [3]).

So this is really a upstream packaging issue and not an issue with the
nodepool images.

-i

[1] 
http://logs.openstack.org/83/197783/8/check/gate-puppet-neutron-puppet-beaker-rspec-upgrade-dsvm-centos7/9f628b4/console.html
[2] https://bugzilla.redhat.com/show_bug.cgi?format=multiple&id=1212145
[3] https://review.openstack.org/#/c/197782/

__
OpenStack Development Mailing List (not for 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][packaging] Adding files to /etc in a package

[Tony Breeds]

On Thu, Jul 02, 2015 at 03:26:41AM +0200, Thomas Goirand wrote:

> Use the source, luke! Or write yourself a small shell script...

I have, and I'm pretty sure that's where this conversation started.
 
> If you attempt to address this, you're making my life miserable. Please
> don't do it, thanks.

really? miserable?

Please lets try to keep the hyperbole to a minimum.  preferably 0

I'm going to walk away from this topic, and concentrate on something more
productive.  Please do the same.

Yours Tony.


pgpxIaqeElvxH.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] when I run "git review -s", it occur a error

[Jeremy Stanley]

On 2015-07-02 09:56:07 +0800 (+0800), yige2008123 wrote:
> thank you ZZelle replay, I slove it by  second option, but my hava another
> problem
> 
> ➜  # git review
> fatal: remote error:
> ICLA contributor agreement requires current contact information.
[...]

If you already followed the instructions at
http://docs.openstack.org/infra/manual/developers.html#account-setup
and still get that, see https://ask.openstack.org/question/56720 for
additional troubleshooting tips.
-- 
Jeremy Stanley

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

[openstack-dev] [puppet] [infra] issues with beaker/centos7 job

[Emilien Macchi]

After hitting issues with EPEL mirrors downtime, we have now an issue with
DeltaRPM.
I reported the bug here:
https://bugs.launchpad.net/puppet-openstack/+bug/1470685 if you want more
details. I tried to install deltarpm before, but it says : "No Presto
metadata available for rdo-release".

I did some testing to try to fix it and I could not reproduce the bug
locally, it seems related to the image nodepool is running:
https://review.openstack.org/#/c/197782/
https://review.openstack.org/#/c/197783/

In the meantime, we are disabling voting for this job:
https://review.openstack.org/#/c/197807/

Any help is welcome on this one,

Note: I'm back online on Friday.
-- 
Emilien Macchi
__
OpenStack Development Mailing List (not for 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] - breaking changes for plugins/drivers

[Joshua Harlow]

Doug Wiegley wrote:



On Jun 30, 2015, at 11:22 PM, Kevin Benton mailto:blak...@gmail.com>> wrote:

Hi,

We have had at least two breaking changes merge this week for
out-of-tree drivers/plugins. These are just the two I noticed that
broke the Big Switch CI (the one I keep an eye on since I had set it up):

1. Removed test_lib that changes config files.
https://review.openstack.org/#/c/196583/
2. Removed the loopingcall common util with no deprecation cycle or
announcement. https://review.openstack.org/#/c/192999/

I proposed a revert for 1 that merged, but I don't particularly want
to keep fighting this. What is our current policy on this? Just change
whatever we want and tell plugin maintainers this is just the way
things work?


So, this is a big hairy bit of suck right now. We expected some of this
fallout with the services split and plugin decomp (in fact, we counted
on it to move this ball forward), and we had adopted these guideilnes:

1. Other repos should not rely on oslo-incubated modules.
(neutron/openstack/…)
2. Other repos should not rely on neutron’s test infrastructure.
(neutron/tests/…)
3. For changes in any other area, they should be additive, or have a
backwards compatibility shim or a big warning notice (the last being the
suckiest answer.)
4. When we start getting “stable” interfaces in neutron/lib/…, which has
the proviso of NO breaking changes without a shim or deprecation cycle,
we get rid of restriction #3.


http://docs.openstack.org/developer/debtcollector/ exists to help in #3 
and #4 and hopefully it helps (whether people look at the warnings it 
emit is another question entirely). It's used in oslo libraries (and 
elsewhere, since it's made for all) for similar purposes...




We’ve been regularly merging code that breaks #3 and we have plugins
that use code from #1 and #2 today.

IMO, the core review team needs to be aware that neutron is now a
library, and refactors and gratuitous cleanups have a pretty hefty cost.
Especially in Liberty, be careful.

Thanks,
doug






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


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


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

Re: [openstack-dev] [all][packaging] Adding files to /etc in a package

[Thomas Goirand]

On 07/02/2015 02:07 AM, Tony Breeds wrote:
> On Wed, Jul 01, 2015 at 11:07:30PM +, Perry, Sean wrote:
>> BTW, see dh_bash-completion from the debhelper package. When in doubt about 
>> packaging on a deb based distro look at the debhelper tools source (which is 
>> perl).
>>
>> -Original Message-
>> From: Perry, Sean 
>> Sent: Wednesday, July 01, 2015 4:04 PM
>> To: OpenStack Development Mailing List (not for usage questions)
>> Subject: RE: [openstack-dev] [all][packaging] Adding files to /etc in a 
>> package
>>
>> According to Debian standards (which Ubuntu follows mostly) if a package
>> ships bash completion information that file belongs in /etc/bash_completion.d
>> with a file named after the package. You can look in that dir on an
>> Ubuntu/debian box and see the setup.
> 
> Right, but I'm talking about python packaging.  Which is certainly closely
> related to system/distribution packaging, but lacks a lot of the machinery
> to get it right.

Correct. Python packaging is made for packaging ... python! Not
configuration files and other system bits.

> What I'm trying to do is:
> 1) make it simple for the 'developer' comsumers of the python package to use
>bash completions (witghout needing the system packages)

Use the source, luke! Or write yourself a small shell script...

> 2) Help the system/distribution packagers or at the very least not make thier
>life more difficult.

If you attempt to address this, you're making my life miserable. Please
don't do it, thanks.

Cheers,

Thomas Goirand (zigo)


__
OpenStack Development Mailing List (not for 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][packaging] Adding files to /etc in a package

[Thomas Goirand]

On 07/02/2015 12:26 AM, Tony Breeds wrote:
> On Wed, Jul 01, 2015 at 01:33:03PM +0200, Thomas Goirand wrote:
> 
>> The file has nothing to do in /usr/share/doc either. By per the debian
>> policy manual: we shouldn't rely on /usr/share/doc, as it can be removed
>> entirely by the users. /usr/share/python-novaclient could be a place,
>> but really, the correct location is
>> /usr/share/bash-completion/completions, not /etc (btw: that's a new
>> thing, it used to be in /etc, but there's now a lintian warning about it).
> 
> Personally I like /usr/share/python-novaclient as that's very deliberatlely
> package centric and if I do that right should make your life as a consumer of
> the python-novaclient git repo a little simplier.

The problem is that this is the *debian* way in *some* case (it doesn't
fit this one where we should put it in
/usr/share/bash-completion/completions), and I don't think it matches
the Red Hat policy at all (Red Hat guys, please speak up!). Again:
please leave this decision to package maintainers, they know better.

> so with that in mind I'm thinking something like:
> ---
>  [files]
>  packages =
>  novaclient
> + data_files =
> + usr/share/python-novaclient/nova.bash_completion = 
> tools/nova.bash_completion
> ---
> Note[1]: I typed that in to my mail client so the diff will be malformed
> Note[2]: I deliberatly used 'usr/' rather than '/usr/' so the config file is 
> in
>  the install root
> Note[3]: For my development systems I can easily add a symlink like:
> (cd /usr/share/bash-completions/ ; ln -s 
> ../python-novaclient/nova.bash_completion nov

For your development system, as you wrote, you can wget the file from
github. And if that's annoying to do one by one, you can write a script
to do it for all clients at once. Even better: write this inside
devstack. But by all means, fixing your development env isn't a reason
to add cruft to the pbr packaging.

> Note[4]: the subject of this email is now wrong but we get the idea.
> 
> So assuming that somethign like that is acceptable to distribution packages 
> and
> python packagers we're winning :)

Distribution package maintainers would like you to not address it at
all, and just let us manage it in debian/rules, thanks.

> The last questions are:
> - How does pbr handle the case where usr/share/python-novaclient/ dosn't 
> exist ?
> - Can I make is do the equivilent of: mkdir -p 
> $install_root/usr/share/python-novaclient/ somehow?
> - At this point I'll propose a change like this for:
> python-ceilometerclient python-cinderclient python-glanceclient
> python-group-based-policy-client python-heatclient python-ironicclient
> python-keystoneclient python-magnetodbclient python-manilaclient
> python-manilaclient python-mistralclient python-mistralclient
> python-monascaclient python-muranoclient python-muranoclient
> python-neutronclient python-novaclient python-senlinclient
> python-surveilclient python-tackerclient python-watcherclient 

Please *don't* !!!

Cheers,

Thomas Goirand (zigo)


__
OpenStack Development Mailing List (not for 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][packaging] Adding files to /etc in a package

[Thomas Goirand]

On 07/02/2015 01:03 AM, Perry, Sean wrote:
> According to Debian standards (which Ubuntu follows mostly) if
> a package ships bash completion information that file belongs in
> /etc/bash_completion.d with a file named after the package.

This is no longer the case. Now it's:
/usr/share/bash-completion/completions

there's even a lintian warning about it.

Cheers,

Thomas Goirand (zigo)


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

Re: [openstack-dev] [magnum] Magnum Midcycle Event Scheduling Doodle Poll closes July 7th

[Kai Qiang Wu]

Hi Stdake,

If remote participation, do I need to vote for
http://doodle.com/pinkuc5hw688zhxw ?



Thanks

Best Wishes,

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

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

Follow your heart. You are miracle!



From:   "Steven Dake (stdake)" 
To: "OpenStack Development Mailing List (not for usage questions)"

Date:   07/02/2015 02:06 AM
Subject:[openstack-dev] [magnum] Magnum Midcycle Event Scheduling
Doodle Poll closes July 7th



Apologies for double post �C left off [magnum] prior by error.

Ton Ngo of IBM Silicon Valley Research has graciously offered to host the 2
day Magnum midcycle event at IBM’s facilities.

The sessions will run from 9AM �C 5PM and catered lunch and refreshments
(soda/water) will be provided.

The mid-cycle will be a standard mid-cycle with a 1 hour introduction
followed by two days of design sessions.

Please cast your votes on any days you can make.

http://doodle.com/pinkuc5hw688zhxw

There are ~25 seats available.  Preference will be given to in-person core
reviewers, followed by any folks that have made commits to the repository.
After dates are settled, a separate eventbrite event will be setup to sort
out the specifics such as  dietary needs, etc and confirm in-person seating
if we are past capacity limits.

We will make remote participation available, but the experience will likely
be less then optimal for remote participants.

Regards
-steve
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for 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][packaging] Adding files to /etc in a package

[Perry, Sean]

> -Original Message-
> From: Tony Breeds [mailto:t...@bakeyournoodle.com]
> Sent: Wednesday, July 01, 2015 5:08 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [all][packaging] Adding files to /etc in a 
> package
> 
> On Wed, Jul 01, 2015 at 11:07:30PM +, Perry, Sean wrote:
> > BTW, see dh_bash-completion from the debhelper package. When in
> doubt about packaging on a deb based distro look at the debhelper tools
> source (which is perl).
> >
> > -Original Message-
> > From: Perry, Sean
> > Sent: Wednesday, July 01, 2015 4:04 PM
> > To: OpenStack Development Mailing List (not for usage questions)
> > Subject: RE: [openstack-dev] [all][packaging] Adding files to /etc in
> > a package
> >
> > According to Debian standards (which Ubuntu follows mostly) if a
> > package ships bash completion information that file belongs in
> > /etc/bash_completion.d with a file named after the package. You can
> > look in that dir on an Ubuntu/debian box and see the setup.
> 
> Right, but I'm talking about python packaging.  Which is certainly closely
> related to system/distribution packaging, but lacks a lot of the machinery to
> get it right.
> 
> What I'm trying to do is:
> 1) make it simple for the 'developer' comsumers of the python package to
> use
>bash completions (witghout needing the system packages)
> 2) Help the system/distribution packagers or at the very least not make thier
>life more difficult.
> 
> Yours Tony.

Sorry Tony, the comment about lintian threw me off.

Well you could
* use /usr/share/bash-completion/completions. This is the canonical location 
for completions. Eventually Debian and others will go here instead of 
/etc/bash_completions.d. This will work for users without packages and should 
not cause too much pain for packagers.
* place a file in /etc/bash_completions.d that sources your 
/where/ever/you/put/it. This gives you flexibility but may be problematic for 
packagers down the line. One possibility is putting the files in 
/usr/local/share/ and having a 
/etc/bash_completion.d/ that sources the /usr/local file. 
This is keeping with the rest of OpenStack so the packagers will be used to the 
pain :-)
* as a twist on the previous choice you can leave off the 
/etc/bash_completion.d file but document how the users can source these files 
from their own ~/.bash_completion or whatever.

Hope this helps.
__
OpenStack Development Mailing List (not for 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][packaging] Adding files to /etc in a package

[Tony Breeds]

On Wed, Jul 01, 2015 at 11:07:30PM +, Perry, Sean wrote:
> BTW, see dh_bash-completion from the debhelper package. When in doubt about 
> packaging on a deb based distro look at the debhelper tools source (which is 
> perl).
> 
> -Original Message-
> From: Perry, Sean 
> Sent: Wednesday, July 01, 2015 4:04 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: RE: [openstack-dev] [all][packaging] Adding files to /etc in a 
> package
> 
> According to Debian standards (which Ubuntu follows mostly) if a package
> ships bash completion information that file belongs in /etc/bash_completion.d
> with a file named after the package. You can look in that dir on an
> Ubuntu/debian box and see the setup.

Right, but I'm talking about python packaging.  Which is certainly closely
related to system/distribution packaging, but lacks a lot of the machinery
to get it right.

What I'm trying to do is:
1) make it simple for the 'developer' comsumers of the python package to use
   bash completions (witghout needing the system packages)
2) Help the system/distribution packagers or at the very least not make thier
   life more difficult.
 
Yours Tony.


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

Re: [openstack-dev] [all] [test-]requirements-PYN.txt will cause gate failures on check-*-requirements

[Robert Collins]

On 2 July 2015 at 11:36, Robert Collins  wrote:
> On 29 June 2015 at 15:59, Robert Collins  wrote:
>> Hi, so we're nearly ready to deprecate the python-version-specific
>> requirements files. Once we have infra's requirements cross checking
>> jobs all copacetic again, we should be able to move forward.
>
> So we've got them working again in master, and I'm about to work on
> support for stable - things are a bit awkward and all tied together
> there. Sorry for the extended disruption on requirement updates!
>
> The status right now is:
> - all stable jobs are failing on requirements checks, because we don't
> have the needed code modules in the openstack/requirements stable
> branches. This is critical and my top priority to unblock everything
> stable/.
>
> - master requirement checks should work Just Fine, as long as the
> requirements are current. However the bot doesn't know enough to merge
> -PYN requirements files for you. So you need to do that manually. The
> easiest way IMO is:
>
> REQS=$(pwd)/reqs
> virtualenv $REQS
> . $REQS/bin/activate
> pip install -U pip setuptools -e
> git+https://git.openstack.org/openstack/requirements#egg=openstack.requirements
> cd path-to-project
> cat requirements-py3.txt >> requirements.txt
> cat test-requirements-py3.txt >> test-requirements.txt
> git rm *requirements-py3.txt
> update-requirements --source $REQS/src/openstack.requirements .
> git diff
> # you'll have some cruft to cleanup - duplicate comments at the bottom
> of the files and so on
> # commit and review
> # repeat from 'cd path-to-project' as needed.
>
> One word of caution. Some of the projects i've done this for -
> keystone and glance - had -e editable lines in their requirements
> files: these got through because infra wasn't linting the -py3 files
> at all until recently, and I'm not yet sure if we can get them back
> in. So we may need to actually fixup those dependencies asap. E.g. get
> /a/ release of glance-store out with its partial python3 support, to
> permit the glance python34 gate to work at all.

Second word of caution. tox.ini probably needs editing too.

-Rob



-- 
Robert Collins 
Distinguished Technologist
HP Converged Cloud

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

[openstack-dev] [all] [test-]requirements-PYN.txt will cause gate failures on check-*-requirements

[Robert Collins]

On 29 June 2015 at 15:59, Robert Collins  wrote:
> Hi, so we're nearly ready to deprecate the python-version-specific
> requirements files. Once we have infra's requirements cross checking
> jobs all copacetic again, we should be able to move forward.

So we've got them working again in master, and I'm about to work on
support for stable - things are a bit awkward and all tied together
there. Sorry for the extended disruption on requirement updates!

The status right now is:
- all stable jobs are failing on requirements checks, because we don't
have the needed code modules in the openstack/requirements stable
branches. This is critical and my top priority to unblock everything
stable/.

- master requirement checks should work Just Fine, as long as the
requirements are current. However the bot doesn't know enough to merge
-PYN requirements files for you. So you need to do that manually. The
easiest way IMO is:

REQS=$(pwd)/reqs
virtualenv $REQS
. $REQS/bin/activate
pip install -U pip setuptools -e
git+https://git.openstack.org/openstack/requirements#egg=openstack.requirements
cd path-to-project
cat requirements-py3.txt >> requirements.txt
cat test-requirements-py3.txt >> test-requirements.txt
git rm *requirements-py3.txt
update-requirements --source $REQS/src/openstack.requirements .
git diff
# you'll have some cruft to cleanup - duplicate comments at the bottom
of the files and so on
# commit and review
# repeat from 'cd path-to-project' as needed.

One word of caution. Some of the projects i've done this for -
keystone and glance - had -e editable lines in their requirements
files: these got through because infra wasn't linting the -py3 files
at all until recently, and I'm not yet sure if we can get them back
in. So we may need to actually fixup those dependencies asap. E.g. get
/a/ release of glance-store out with its partial python3 support, to
permit the glance python34 gate to work at all.

-Rob


-- 
Robert Collins 
Distinguished Technologist
HP Converged Cloud

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

[openstack-dev] [app-catalog] Meeting Thursday July 2nd at 17:00UTC

[Christopher Aedo]

Hello! Our next OpenStack App Catalog meeting will take place this
Thursday July 2nd at 17:00 UTC in #openstack-meeting-3

The agenda can be found here:
https://wiki.openstack.org/wiki/Meetings/app-catalog

Please add agenda items if there's anything you would like to discuss.
We'll touch on the work we're doing to create a Horizon plugin and the
preliminary steps to support more asset types among other things.
Please join us if you can!

-Christopher

__
OpenStack Development Mailing List (not for 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][packaging] Adding files to /etc in a package

[Perry, Sean]

BTW, see dh_bash-completion from the debhelper package. When in doubt about 
packaging on a deb based distro look at the debhelper tools source (which is 
perl).

-Original Message-
From: Perry, Sean 
Sent: Wednesday, July 01, 2015 4:04 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: RE: [openstack-dev] [all][packaging] Adding files to /etc in a package

According to Debian standards (which Ubuntu follows mostly) if a package ships 
bash completion information that file belongs in /etc/bash_completion.d with a 
file named after the package. You can look in that dir on an Ubuntu/debian box 
and see the setup.

-Original Message-
From: Tony Breeds [mailto:t...@bakeyournoodle.com]
Sent: Wednesday, July 01, 2015 3:26 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [all][packaging] Adding files to /etc in a package

On Wed, Jul 01, 2015 at 01:33:03PM +0200, Thomas Goirand wrote:

> The file has nothing to do in /usr/share/doc either. By per the debian 
> policy manual: we shouldn't rely on /usr/share/doc, as it can be 
> removed entirely by the users. /usr/share/python-novaclient could be a 
> place, but really, the correct location is 
> /usr/share/bash-completion/completions, not /etc (btw: that's a new 
> thing, it used to be in /etc, but there's now a lintian warning about it).

Personally I like /usr/share/python-novaclient as that's very deliberatlely 
package centric and if I do that right should make your life as a consumer of 
the python-novaclient git repo a little simplier.

so with that in mind I'm thinking something like:
---
 [files]
 packages =
 novaclient
+ data_files =
+ usr/share/python-novaclient/nova.bash_completion = 
+ tools/nova.bash_completion
---
Note[1]: I typed that in to my mail client so the diff will be malformed
Note[2]: I deliberatly used 'usr/' rather than '/usr/' so the config file is in
 the install root
Note[3]: For my development systems I can easily add a symlink like:
(cd /usr/share/bash-completions/ ; ln -s 
../python-novaclient/nova.bash_completion nova)
Note[4]: the subject of this email is now wrong but we get the idea.

So assuming that somethign like that is acceptable to distribution packages and 
python packagers we're winning :)

The last questions are:
- How does pbr handle the case where usr/share/python-novaclient/ dosn't exist ?
- Can I make is do the equivilent of: mkdir -p 
$install_root/usr/share/python-novaclient/ somehow?
- At this point I'll propose a change like this for:
python-ceilometerclient python-cinderclient python-glanceclient
python-group-based-policy-client python-heatclient python-ironicclient
python-keystoneclient python-magnetodbclient python-manilaclient
python-manilaclient python-mistralclient python-mistralclient
python-monascaclient python-muranoclient python-muranoclient
python-neutronclient python-novaclient python-senlinclient
python-surveilclient python-tackerclient python-watcherclient 

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

Re: [openstack-dev] [all][packaging] Adding files to /etc in a package

[Perry, Sean]

According to Debian standards (which Ubuntu follows mostly) if a package ships 
bash completion information that file belongs in /etc/bash_completion.d with a 
file named after the package. You can look in that dir on an Ubuntu/debian box 
and see the setup.

-Original Message-
From: Tony Breeds [mailto:t...@bakeyournoodle.com] 
Sent: Wednesday, July 01, 2015 3:26 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [all][packaging] Adding files to /etc in a package

On Wed, Jul 01, 2015 at 01:33:03PM +0200, Thomas Goirand wrote:

> The file has nothing to do in /usr/share/doc either. By per the debian 
> policy manual: we shouldn't rely on /usr/share/doc, as it can be 
> removed entirely by the users. /usr/share/python-novaclient could be a 
> place, but really, the correct location is 
> /usr/share/bash-completion/completions, not /etc (btw: that's a new 
> thing, it used to be in /etc, but there's now a lintian warning about it).

Personally I like /usr/share/python-novaclient as that's very deliberatlely 
package centric and if I do that right should make your life as a consumer of 
the python-novaclient git repo a little simplier.

so with that in mind I'm thinking something like:
---
 [files]
 packages =
 novaclient
+ data_files =
+ usr/share/python-novaclient/nova.bash_completion = 
+ tools/nova.bash_completion
---
Note[1]: I typed that in to my mail client so the diff will be malformed
Note[2]: I deliberatly used 'usr/' rather than '/usr/' so the config file is in
 the install root
Note[3]: For my development systems I can easily add a symlink like:
(cd /usr/share/bash-completions/ ; ln -s 
../python-novaclient/nova.bash_completion nova)
Note[4]: the subject of this email is now wrong but we get the idea.

So assuming that somethign like that is acceptable to distribution packages and 
python packagers we're winning :)

The last questions are:
- How does pbr handle the case where usr/share/python-novaclient/ dosn't exist ?
- Can I make is do the equivilent of: mkdir -p 
$install_root/usr/share/python-novaclient/ somehow?
- At this point I'll propose a change like this for:
python-ceilometerclient python-cinderclient python-glanceclient
python-group-based-policy-client python-heatclient python-ironicclient
python-keystoneclient python-magnetodbclient python-manilaclient
python-manilaclient python-mistralclient python-mistralclient
python-monascaclient python-muranoclient python-muranoclient
python-neutronclient python-novaclient python-senlinclient
python-surveilclient python-tackerclient python-watcherclient 

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

Re: [openstack-dev] [all]deprecating [test-]requirements-PYN.txt

[Robert Collins]

On 29 June 2015 at 23:56, Doug Hellmann  wrote:


>> I think we should do three things:
>>  - error if universal builds are requested and python versioned
>> requirements files are present.

> That may break some of the Oslo stable libs, since not all of them were
> ready for Python 3 last cycle, and certainly not before. Have you done
> any analysis to find those libs so we can get patches ready
> preemptively?
>
> Doug

So if that breaks them, they must have:
[wheel]
universal = 1
in their setup.cfg

*and*
they must have [test-]requirements[-pyN].txt rather than just requirements.txt.

If they have that, they are broken already: installing them on python3
will install the wrong dependencies.

I haven't done a system wide grep for that no.

-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] [neutron] [fwaas] - Collecting use cases for API improvements - Closing 7/14

[Eichberger, German]

All,

Thank you for submitting use cases. We now have critical mass in [1] 
(https://etherpad.openstack.org/p/fwaas_use_cases). I am wondering if everybody 
interested to review them by 7/14. Our plan is to ratify them in the FWaaS IRC 
meeting on 7/15 so we can move on to the next step which is mapping them to the 
existing API and identifying gaps…

Thanks,
German

From: Sameer Satyam 
mailto:sameer.sat...@outlook.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Thursday, May 28, 2015 at 5:30 PM
To: OpenStack Development Mailing List not for usage questions 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [neutron] [fwaas] - Collecting use cases for API 
improvements

German,

Thanks for the initiative. From a Rackspace perspective, we would love to 
participate and provide inputs on the use cases. As discussed during the 
meeting at the summit (and as you alluded to in your email), it's about user 
experience and clear separation of use cases between FWaaS and SG as well as 
any any necessary reconciliation between the two sets of APIs to make the 
distinctions (or integration points if needed) obvious to the user.

Thanks,
Sameer

> From: german.eichber...@hp.com
> To: 
> openstack-dev@lists.openstack.org
> Date: Wed, 27 May 2015 22:36:47 +
> Subject: [openstack-dev] [neutron] [fwaas] - Collecting use cases for API 
> improvements
>
> All,
>
>
> During the FWaaS session in Vancouver [1] it became apparent that both the 
> FWaaS API and the Security Groups API are lacking in functionality and the 
> connection between the two is not well defined.
>
>
> For instance if a cloud user opens up all ports in the security groups they 
> still can’t connect and might figure out days later that there is a second 
> API (FWaaS) which prevents him from connecting to his service. This will 
> probably make for a frustrating experience.
>
>
> Similarly, the operators I spoke to all said that the current FWaaS 
> implementation isn’t going far enough and needs a lot of missing 
> functionality added to fulfill their requirements on a Firewall 
> implementation.
>
>
> With that backdrop I am proposing to take a step back and assemble a group of 
> operators and users to collect use cases for the firewall service – both 
> FWaaS and Security Groups based. I believe it is important at this juncture 
> to really focus on the users and less on technical limitations. I also think 
> this reset is necessary to make a service which meets the needs of operators 
> and users better.
>
>
> Once we have collected the use cases we can evaluate our current API’s and 
> functionality and start making the necessary improvements to turn FWaaS into 
> a service which covers most of the use cases and requirements.
>
>
> Please join me in this effort. We have set up an etherpad [2] to start 
> collecting the use cases and will discuss them in an upcoming meeting.
>
>
> Thanks,
>
> German
>
>
>
>
>
> [1] https://etherpad.openstack.org/p/YVR-neutron-sg-fwaas-future-direction
>
> [2] https://etherpad.openstack.org/p/fwaas_use_cases
>
>
> __
> OpenStack Development Mailing 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] [kolla][release] Announcing Liberty-1 release of Kolla

[Kevin Carter]

Steve, 

The initial review you guys had done did help a bunch and it was great to work 
with you and everyone else in the channel. As you're aware, code base that you 
had tested was our Juno (stable at that time) release which has more than its 
fair share of Rackspace-isms. One of which is the requirement to have access to 
the upstream repository for the installation of its python bits. So within that 
release it is true that if the upstream repository were to go away a 
redeployment or the expansion of the stack would be impossible until service 
was restored. While you could always self host the upstream repos, there is an 
open rsync relay, that wasn't functionality baked into OSAD at that time. 
However, since your eval we've released Kilo which now provides for the ability 
to self-host all of the python bits / container images / and anything else you 
may need or want from within the infrastructure (that's the default and what we 
gate on). While this functionality existed in master when you gu
 ys had done the test it had not been officially released so its likely you had 
not looked into it at this point. Additionally, we've done a huge amount of 
work to separate Kilo / Master from what was done in Icehouse / Juno while also 
providing an upgrade path for our existing deployments which will ensure that 
deployers are able to take advantage of the general improvements throughout the 
stack in Kilo and beyond. We, like you, do still have to reliance on some 
upstream resources however the inclusion of the repo-server containers should 
thwart these issues. Our python bits are built once within that repo-server 
infrastructure and everything within the OSAD points to the internal repository 
for its source of truth. As I said, we still have some reliance on upstream and 
likely always will but once an OSAD deployment is online, in Kilo or Master, it 
should be able to redeploy itself indefinitely. Obviously there's still more 
that we can do to make this better, and we're getting there
 , but I don't believe the same theoretical issues you had seen before are 
present now.

All that said, great work on the Libery-1 release and I look forward to play 
with Kolla with these new bits sometime in the near future.

--

Kevin Carter
IRC: cloudnull


From: Steven Dake (stdake) 
Sent: Wednesday, July 1, 2015 2:21 PM
To: OpenStack Development Mailing List (not for usage questions); s...@yaple.net
Subject: Re: [openstack-dev] [kolla][release] Announcing Liberty-1 release of 
Kolla

On 7/1/15, 8:11 AM, "Ian Cordasco"  wrote:

>
>
>On 6/30/15, 23:36, "Sam Yaple"  wrote:
>
>>Ian,
>>
>>
>>The most significant difference would be that Kolla uses image based
>>deployment rather than building from source on each node at runtime
>>allowing for a more consistent and repeatable deployment.
>>
>
>Do you mean specific docker images? Can you expand on how
>os-ansible-deployment is not repeatable? They use an lxc-container cached
>image so all containers are uniform (consistent, repeatable, etc.) and
>build wheels (once) and use an internal repo mirror so that all
>installations use the exact same set of wheels (e.g., consistent and
>repeatable).
>
>Are there places where you've found osad to be not consistent or
>repeatable?

Ian,

We did a 10 day eval of OSAD and liked the tech.  We did find the way the
deployment pipeline works to be lacking.  A purely theoretical problem
with the deployment pipeline is key repositories used to build the
software could be offline.  Since the building of the software occurs
during deployment, this could result in an inability to alter the
configuration of the deployment after OpenStack is deployed.  Kolla
suffers from this same problem during the installation (build pipeline)
step.  But as long as you have already built images somewhere in your
system, you are still able to deploy, avoiding complete downtime on
deployment that OSAD could theoretically suffer.

This theoretical issue makes the deployment non-repeatable.  Hope our 10
day eval analysis helps improve OSAD.

Regards
-steve

>
>>
>>On Tue, Jun 30, 2015 at 2:28 PM, Ian Cordasco
>> wrote:
>>
>>
>>
>>On 6/29/15, 23:59, "Steven Dake (stdake)"  wrote:
>>
>>>The Kolla community
>>>is pleased to announce the
>>> release of the
>>> Kolla Liberty 1 milestone.  This release fixes 56 bugs
>>> and implements 14 blueprints!
>>>
>>>
>>>Our community developed the following notable features:
>>>
>>>
>>>
>>>* A start at
>>>source-basedcontainers
>>
>>So how does this now compare to the stackforge/os-ansible-deployment
>>(soon
>>to be openstack/openstack-ansible) project?
>>
>>_
>>_
>>OpenStack Development Mailing List (not for usage questions)
>>Unsubscribe:
>>openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>
>>http://lists.openstack.org/cgi-bin/

Re: [openstack-dev] [all][packaging] Adding files to /etc in a package

[Tony Breeds]

On Wed, Jul 01, 2015 at 01:33:03PM +0200, Thomas Goirand wrote:

> The file has nothing to do in /usr/share/doc either. By per the debian
> policy manual: we shouldn't rely on /usr/share/doc, as it can be removed
> entirely by the users. /usr/share/python-novaclient could be a place,
> but really, the correct location is
> /usr/share/bash-completion/completions, not /etc (btw: that's a new
> thing, it used to be in /etc, but there's now a lintian warning about it).

Personally I like /usr/share/python-novaclient as that's very deliberatlely
package centric and if I do that right should make your life as a consumer of
the python-novaclient git repo a little simplier.

so with that in mind I'm thinking something like:
---
 [files]
 packages =
 novaclient
+ data_files =
+ usr/share/python-novaclient/nova.bash_completion = 
tools/nova.bash_completion
---
Note[1]: I typed that in to my mail client so the diff will be malformed
Note[2]: I deliberatly used 'usr/' rather than '/usr/' so the config file is in
 the install root
Note[3]: For my development systems I can easily add a symlink like:
(cd /usr/share/bash-completions/ ; ln -s 
../python-novaclient/nova.bash_completion nova)
Note[4]: the subject of this email is now wrong but we get the idea.

So assuming that somethign like that is acceptable to distribution packages and
python packagers we're winning :)

The last questions are:
- How does pbr handle the case where usr/share/python-novaclient/ dosn't exist ?
- Can I make is do the equivilent of: mkdir -p 
$install_root/usr/share/python-novaclient/ somehow?
- At this point I'll propose a change like this for:
python-ceilometerclient python-cinderclient python-glanceclient
python-group-based-policy-client python-heatclient python-ironicclient
python-keystoneclient python-magnetodbclient python-manilaclient
python-manilaclient python-mistralclient python-mistralclient
python-monascaclient python-muranoclient python-muranoclient
python-neutronclient python-novaclient python-senlinclient
python-surveilclient python-tackerclient python-watcherclient 

Yours Tony.


pgp_6gJj9uuKF.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] Barbican : Regarding the Tempest Tests for Barbican

[Douglas Mendizábal]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Asha,

Information for running the Functional tests can be found in our
official documentation. [1]

- - Douglas Mendizábal

[1]
http://docs.openstack.org/developer/barbican/testing.html#functional-tes
ts

On 7/1/15 5:08 PM, Asha Seshagiri wrote:
> Thanks a lot Douglas for your response :) I would like to know the
> steps required to configure and run automated functional test cases
> for  validating Barbican APIs.
> 
> Thanks and Regards, Asha Seshagiri
> 
> On Wed, Jul 1, 2015 at 3:30 PM, Douglas Mendizábal 
>  > wrote:
> 
> Hi Asha,
> 
> The blueprint you linked for Tempest is over a year old.  I think
> it pre-dates the Tempest team's decision to stop putting all
> project tests in the same repo.  I believe the spec is obsolete,
> but someone from the Tempest team can correct me if I'm wrong.
> 
> The automated tests that validate the API are the Functional Tests
> I linked in my earlier email.
> 
> - Douglas Mendizábal
> 
> On 7/1/15 3:22 PM, Asha Seshagiri wrote:
>> Hi Douglas ,
> 
>> Are there any Automated Test cases created for validating the 
>> Barbican APIs.
> 
>> Thanks and Regards, Asha Seshagiri
> 
>> On Wed, Jul 1, 2015 at 3:12 PM, Asha Seshagiri 
>> mailto:asha.seshag...@gmail.com>
>  >>
>> wrote:
> 
>> Thanks Douglas for your response and appreciate for pointing me
>> to the right link
> 
>> I was talking about the tempest tests to validate the Barbican 
>> APIs Please find the spec[1] and blue print link [2] for the
>> same .
> 
>> [1]http://specs.openstack.org/openstack/qa-specs/specs/barbican-api-t
e
>
>> 
sts.html
> 
> 
sts.html>
> 
> 
> [2]https://blueprints.launchpad.net/tempest/+spec/add-basic-tests-for-
ba
>
> 
rbican
> 
>> Are above specs and blueprint have become void for Barbican? Now
>> I could use the  link sent by you for validating the APIs
> 
>> Thanks and Regards, Asha Seshagiri
> 
> 
> 
> 
>> On Wed, Jul 1, 2015 at 2:32 PM, Douglas Mendizábal 
>>  
>>  >> wrote:
> 
>> Hi Asha,
> 
>> I'm not sure what you mean by "tempest tests."  If you're
>> looking for Functional Tests for Barbican, then you can find them
>> in the functionaltests directory [1] inside the Barbican repo.
> 
>> We have no intentions of adding Barbican specific tests to the 
>> Tempest repo.  It's my understanding that Tempest is moving away 
>> from one monolithic repository into a modular approach using 
>> tempest-lib.
> 
>> - Douglas Mendizábal
> 
>> [1] 
>> http://git.openstack.org/cgit/openstack/barbican/tree/functionaltest
>
>> 
> 
> s
> 
> 
>> On 7/1/15 2:12 PM, Asha Seshagiri wrote:
>>> Hi All ,
> 
>>> Has anyone done the Tempest tests for Barbican API Any help 
>>> would be highly appreciated.
> 
>>> -- /Thanks and Regards,/ /Asha Seshagiri/
> 
> 
> 
>> _
_
>
>> 
> 
> 
> 
> 
>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: 
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> 
>>
> 

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

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

> 
> 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> 
> 
>> -- /Thanks and Regards,/ /Asha Seshagiri/
> 
> 
> 
> 
>> -- /Thanks and Regards,/ /Asha Seshagiri/
> 
> 
>> _
_
>
>> 

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

>
> 
OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe 
> 
>
> 
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> 
> 
> -- /Thanks and Regards,/ /Asha Seshagiri/
> 
> 
> ___

Re: [openstack-dev] Barbican : Regarding the Tempest Tests for Barbican

[Asha Seshagiri]

Thanks a lot Douglas for your response :)
I would like to know the steps required to configure and run automated
functional test cases for  validating Barbican APIs.

Thanks and Regards,
Asha Seshagiri

On Wed, Jul 1, 2015 at 3:30 PM, Douglas Mendizábal <
douglas.mendiza...@rackspace.com> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Hi Asha,
>
> The blueprint you linked for Tempest is over a year old.  I think it
> pre-dates the Tempest team's decision to stop putting all project
> tests in the same repo.  I believe the spec is obsolete, but someone
> from the Tempest team can correct me if I'm wrong.
>
> The automated tests that validate the API are the Functional Tests I
> linked in my earlier email.
>
> - - Douglas Mendizábal
>
> On 7/1/15 3:22 PM, Asha Seshagiri wrote:
> > Hi Douglas ,
> >
> > Are there any Automated Test cases created for validating the
> > Barbican APIs.
> >
> > Thanks and Regards, Asha Seshagiri
> >
> > On Wed, Jul 1, 2015 at 3:12 PM, Asha Seshagiri
> > mailto:asha.seshag...@gmail.com>>
> > wrote:
> >
> > Thanks Douglas for your response and appreciate for pointing me to
> > the right link
> >
> > I was talking about the tempest tests to validate the Barbican
> > APIs Please find the spec[1] and blue print link [2] for the same
> > .
> >
> > [1]http://specs.openstack.org/openstack/qa-specs/specs/barbican-api-te
> sts.html
> >
> >
> [2]https://blueprints.launchpad.net/tempest/+spec/add-basic-tests-for-ba
> rbican
> >
> > Are above specs and blueprint have become void for Barbican? Now I
> > could use the  link sent by you for validating the APIs
> >
> > Thanks and Regards, Asha Seshagiri
> >
> >
> >
> >
> > On Wed, Jul 1, 2015 at 2:32 PM, Douglas Mendizábal
> >  > > wrote:
> >
> > Hi Asha,
> >
> > I'm not sure what you mean by "tempest tests."  If you're looking
> > for Functional Tests for Barbican, then you can find them in the
> > functionaltests directory [1] inside the Barbican repo.
> >
> > We have no intentions of adding Barbican specific tests to the
> > Tempest repo.  It's my understanding that Tempest is moving away
> > from one monolithic repository into a modular approach using
> > tempest-lib.
> >
> > - Douglas Mendizábal
> >
> > [1]
> > http://git.openstack.org/cgit/openstack/barbican/tree/functionaltest
> >
> >
> s
> >
> >
> > On 7/1/15 2:12 PM, Asha Seshagiri wrote:
> >> Hi All ,
> >
> >> Has anyone done the Tempest tests for Barbican API Any help
> >> would be highly appreciated.
> >
> >> -- /Thanks and Regards,/ /Asha Seshagiri/
> >
> >
> >
> > __
> >
> >
> 
> >
> >
> > OpenStack Development Mailing List (not for usage questions)
> >> Unsubscribe:
> >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > 
> >>
> >
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> > __
> 
> >
> >
> OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > 
> >
> >
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> >
> >
> > -- /Thanks and Regards,/ /Asha Seshagiri/
> >
> >
> >
> >
> > -- /Thanks and Regards,/ /Asha Seshagiri/
> >
> >
> > __
> 
> >
> >
> OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> -BEGIN PGP SIGNATURE-
> Comment: GPGTools - https://gpgtools.org
>
> iQIcBAEBCgAGBQJVlE3/AAoJEB7Z2EQgmLX70vcP/imbbk9quMlxpX0IbGTOuoAH
> +cpiUU0g9dQFawjQQpVXQhalR1JNOIhZlFICP1VHama6mh/HChuM4EUS/Ic/w4Dd
> eRGamkwG2l/OWWdNaE7l4y6kCgvT6QQQFKwJNG6HgJtChs4u9aL6WgQS85ACaw70
> I6ZK0QBXXe/VQFMmxWqYflHmDF6G5UP+4BzGcwIO41tWKKYf9V0rFh5JBDDFW7yC
> A6YuWNGHfR3OqJuS5hw0if2q94LXzw2qKI6eMMmiV9OAT0U/mLufTPpNkH37DJ0w
> CCQudKlqZQN0FELhr1oxM88KVoOD0N1S/yOfjNA4TdvvpB/2EIt+t8GZZKoXeLtx
> YfzPsa1cBO/zpgoiPO6zCqF7HvUMwSnPEBnRAQl15mXUfSKJJJzh0GaCEQ5bjTIb
> 2s+xQIyBAXuUtTPYJMzHlw2nEeov77U+OvR90lswSuppO/du3YTYfJX799pqTLg5
> QY4bsuxQpdVlHV+nu4mC2cImU0ZUVTzNDCMKgWbw30Ni+yc9TDTlZs301/odHrjy
> WuiKkXId/Fp5hYh7dSvt4wMKO0XdiMUiSNP1KybO0smCvCxa5AhcsiL1nZ05f+cG
> eylLvYheaEGemnsTy1SVOQ0UowA7sDAaaOTl9KBhvAYZS+dWHwaC5ZJzDB/rRdnG
> WELJUjLwg2V2MSGFRiIk
> =G1kZ
> -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
>



-- 
*Than

Re: [openstack-dev] [all][packaging] Adding files to /etc in a package

[Tony Breeds]

On Wed, Jul 01, 2015 at 03:28:06PM +, Ian Cordasco wrote:

> So for people using the clients to talk to arbitrary clouds from their
> personal computer (that can be running more than just linux) we need to
> fix this. The problem is that if the person is installing a wheel or using
> a new enough version of pip (which creates wheels first and then installs
> them after caching them, which is awesome by the way) then there are
> limitations that prevent the package from writing files to arbitrary
> paths. (For reference, https://github.com/pypa/pip/issues/2874)
> 
> Tl;dr, be very careful to test whatever solution is chosen going forward.
> I'll be doing the same with https://bugs.launchpad.net/glance/+bug/1469869

Thanks.  I'll be careful once we reach consensus.  I can test any change I make
with devstack on Fedora and Ubuntu as well as my local mac.  That shoudl help :)

Yours Tony.


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

Re: [openstack-dev] [all][packaging] Adding files to /etc in a package

[Tony Breeds]

On Wed, Jul 01, 2015 at 02:13:50PM +, Jeremy Stanley wrote:
> On 2015-07-01 12:08:46 +1000 (+1000), Tony Breeds wrote:
> > Okay so I take you point no problem, but I'm not running distro
> > packages and I still want completions. There must be a way to
> > package the file to at least make it easier to achieve both our
> > goals.
> [...]
> 
> http://docs.openstack.org/developer/pbr/#files

Thanks Jeremy.  It seems that hard part is goign to be picking a path that
doesn't make packaging harder.

Yours Tony.


pgpWtuv60OZBX.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][cinder][qa] encrypted volumes tests don't actually test encrypted volumes for most backends

[Matt Riedemann]

On 6/30/2015 6:47 PM, Mike Perez wrote:

On 12:24 Jun 26, Matt Riedemann wrote:


So the question is, is everyone OK with this and ready to make that change?


Thanks for all your work on this Matt.

I'm fine with this. I say bite the bullet and we'll see the CI's surface that
aren't skipping or failing this test.

I will communicate with CI maintainers on the CI list about failures as I've
been doing, and reference this thread and the meeting discussion.



Just a status report on this since there are a lot of moving parts:

1. The tempest change merged: https://review.openstack.org/#/c/193831/

2. The devstack change is approved: https://review.openstack.org/#/c/193834/

3. The d-g change is still under review: 
https://review.openstack.org/#/c/193835/


4. Tom Barron opened a couple of nova bugs for issues found by third 
party CI on the cinder change:


https://bugs.launchpad.net/nova/+bug/1470142

https://bugs.launchpad.net/nova/+bug/1470562

I have patches up in nova for both of those bugs.

--

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] [neutron] new etherpad for Neutron instrumentation

[Ryan Moats]

All-

After talking with Carl, Matt, and Gal about this subject on the IRC
channel this morning, I've created an etherpad [1] to gauge interest in
creating a blueprint for Neutron instrumentation.

I think this is a place where the project has substantial gaps that could
create barriers to adoption by operators and would like (as we move
forward) to invite operators in to provide their input...

Thanks,
Ryan Moats

[1] https://etherpad.openstack.org/p/neutron-instrumentation__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Barbican : Regarding the Tempest Tests for Barbican

[Douglas Mendizábal]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi Asha,

The blueprint you linked for Tempest is over a year old.  I think it
pre-dates the Tempest team's decision to stop putting all project
tests in the same repo.  I believe the spec is obsolete, but someone
from the Tempest team can correct me if I'm wrong.

The automated tests that validate the API are the Functional Tests I
linked in my earlier email.

- - Douglas Mendizábal

On 7/1/15 3:22 PM, Asha Seshagiri wrote:
> Hi Douglas ,
> 
> Are there any Automated Test cases created for validating the
> Barbican APIs.
> 
> Thanks and Regards, Asha Seshagiri
> 
> On Wed, Jul 1, 2015 at 3:12 PM, Asha Seshagiri
> mailto:asha.seshag...@gmail.com>>
> wrote:
> 
> Thanks Douglas for your response and appreciate for pointing me to 
> the right link
> 
> I was talking about the tempest tests to validate the Barbican
> APIs Please find the spec[1] and blue print link [2] for the same
> .
> 
> [1]http://specs.openstack.org/openstack/qa-specs/specs/barbican-api-te
sts.html
>
> 
[2]https://blueprints.launchpad.net/tempest/+spec/add-basic-tests-for-ba
rbican
> 
> Are above specs and blueprint have become void for Barbican? Now I
> could use the  link sent by you for validating the APIs
> 
> Thanks and Regards, Asha Seshagiri
> 
> 
> 
> 
> On Wed, Jul 1, 2015 at 2:32 PM, Douglas Mendizábal 
>  > wrote:
> 
> Hi Asha,
> 
> I'm not sure what you mean by "tempest tests."  If you're looking
> for Functional Tests for Barbican, then you can find them in the 
> functionaltests directory [1] inside the Barbican repo.
> 
> We have no intentions of adding Barbican specific tests to the 
> Tempest repo.  It's my understanding that Tempest is moving away
> from one monolithic repository into a modular approach using
> tempest-lib.
> 
> - Douglas Mendizábal
> 
> [1] 
> http://git.openstack.org/cgit/openstack/barbican/tree/functionaltest
>
> 
s
> 
> 
> On 7/1/15 2:12 PM, Asha Seshagiri wrote:
>> Hi All ,
> 
>> Has anyone done the Tempest tests for Barbican API Any help
>> would be highly appreciated.
> 
>> -- /Thanks and Regards,/ /Asha Seshagiri/
> 
> 
> 
> __
>
> 

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

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

>
> 
OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
-BEGIN PGP SIGNATURE-
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJVlE3/AAoJEB7Z2EQgmLX70vcP/imbbk9quMlxpX0IbGTOuoAH
+cpiUU0g9dQFawjQQpVXQhalR1JNOIhZlFICP1VHama6mh/HChuM4EUS/Ic/w4Dd
eRGamkwG2l/OWWdNaE7l4y6kCgvT6QQQFKwJNG6HgJtChs4u9aL6WgQS85ACaw70
I6ZK0QBXXe/VQFMmxWqYflHmDF6G5UP+4BzGcwIO41tWKKYf9V0rFh5JBDDFW7yC
A6YuWNGHfR3OqJuS5hw0if2q94LXzw2qKI6eMMmiV9OAT0U/mLufTPpNkH37DJ0w
CCQudKlqZQN0FELhr1oxM88KVoOD0N1S/yOfjNA4TdvvpB/2EIt+t8GZZKoXeLtx
YfzPsa1cBO/zpgoiPO6zCqF7HvUMwSnPEBnRAQl15mXUfSKJJJzh0GaCEQ5bjTIb
2s+xQIyBAXuUtTPYJMzHlw2nEeov77U+OvR90lswSuppO/du3YTYfJX799pqTLg5
QY4bsuxQpdVlHV+nu4mC2cImU0ZUVTzNDCMKgWbw30Ni+yc9TDTlZs301/odHrjy
WuiKkXId/Fp5hYh7dSvt4wMKO0XdiMUiSNP1KybO0smCvCxa5AhcsiL1nZ05f+cG
eylLvYheaEGemnsTy1SVOQ0UowA7sDAaaOTl9KBhvAYZS+dWHwaC5ZJzDB/rRdnG
WELJUjLwg2V2MSGFRiIk
=G1kZ
-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] Barbican : Regarding the Tempest Tests for Barbican

[Asha Seshagiri]

Hi Douglas ,

Are there any Automated Test cases created for validating the Barbican APIs.

Thanks and Regards,
Asha Seshagiri

On Wed, Jul 1, 2015 at 3:12 PM, Asha Seshagiri 
wrote:

> Thanks Douglas for your response and appreciate for pointing me to the
> right link
>
> I was talking about the tempest tests to validate the Barbican APIs
> Please find the spec[1] and blue print link [2] for the same .
>
> [1]
> http://specs.openstack.org/openstack/qa-specs/specs/barbican-api-tests.html
> [2]
> https://blueprints.launchpad.net/tempest/+spec/add-basic-tests-for-barbican
>
> Are above specs and blueprint have become void for Barbican?
> Now I could use the  link sent by you for validating the APIs
>
> Thanks and Regards,
> Asha Seshagiri
>
>
>
>
> On Wed, Jul 1, 2015 at 2:32 PM, Douglas Mendizábal <
> douglas.mendiza...@rackspace.com> wrote:
>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA512
>>
>> Hi Asha,
>>
>> I'm not sure what you mean by "tempest tests."  If you're looking for
>> Functional Tests for Barbican, then you can find them in the
>> functionaltests directory [1] inside the Barbican repo.
>>
>> We have no intentions of adding Barbican specific tests to the Tempest
>> repo.  It's my understanding that Tempest is moving away from one
>> monolithic repository into a modular approach using tempest-lib.
>>
>> - - Douglas Mendizábal
>>
>> [1] http://git.openstack.org/cgit/openstack/barbican/tree/functionaltest
>> s
>>
>>
>> On 7/1/15 2:12 PM, Asha Seshagiri wrote:
>> > Hi All ,
>> >
>> > Has anyone done the Tempest tests for Barbican API Any help would
>> > be highly appreciated.
>> >
>> > -- /Thanks and Regards,/ /Asha Seshagiri/
>> >
>> >
>> > __
>> 
>> >
>> >
>> OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe:
>> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>> -BEGIN PGP SIGNATURE-
>> Comment: GPGTools - https://gpgtools.org
>>
>> iQIcBAEBCgAGBQJVlEAyAAoJEB7Z2EQgmLX7NBYQAJB/ArYrW0LDitmlaTcupf8I
>> B+LjBD6uMLI0nsFx4dOFu/FROSe37XkNvWumkj96wPZcmZNx1wuOntuyYu7STMBH
>> Z+3JHxLwEdW5A3j0437IuNf14y8JZhio1+txMa0MWEEWIkfk/15Ppz3vhkKgfKsc
>> ldMxQ0RboH5xXOWpIpCa8S022I+N2Erhp7Rn1xKA0rICKzvhpa87lB2aFZdZ3NMw
>> pgM3W1Nzongl+zG0NHxqtxBX2y41nvzWSX7slvcjE1LIjPcBuc12Ja9WM6piZj/L
>> +CxLHf8hAfZDxUDEm1Uwm9yvaWFtQFw684+CksRB4uq6KMGpF1EYOvnfoHtC71X9
>> GokjNYZoz8vqkRdtXHvMwUTPH1V+G3y0mBL2eAZspfxjcfqkDudilkMdmEAhPWLy
>> ihsH/S5g4SCgozYb9sZ9RJxNN/lGJodjyg3ODdFUwjPQtryejryVp2EOryA0T5Pd
>> 7M7Zlhmm/NlZzwQBqQxDmVFHNU3baYizLTinPiYtURNmy6CqDs8WAWR/Br0oGJUI
>> 5vL/y5hjPBR+WJV9IXfT0EuNqFTck1r0+vm/isez4hM2T7wFJcpFSPXS7l1GKxsx
>> HTOqvujAOREcGfLYBBwwCoKCmDWoTqBjxUfY182sjYoUx1SnL5Ws01AdRcU3oNIl
>> dEpBJSS6YgwvUZkjUJD2
>> =FKK1
>> -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
>>
>
>
>
> --
> *Thanks and Regards,*
> *Asha Seshagiri*
>



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

Re: [openstack-dev] Barbican : Regarding the Tempest Tests for Barbican

[Asha Seshagiri]

Thanks Douglas for your response and appreciate for pointing me to the
right link

I was talking about the tempest tests to validate the Barbican APIs
Please find the spec[1] and blue print link [2] for the same .

[1]
http://specs.openstack.org/openstack/qa-specs/specs/barbican-api-tests.html
[2]
https://blueprints.launchpad.net/tempest/+spec/add-basic-tests-for-barbican

Are above specs and blueprint have become void for Barbican?
Now I could use the  link sent by you for validating the APIs

Thanks and Regards,
Asha Seshagiri




On Wed, Jul 1, 2015 at 2:32 PM, Douglas Mendizábal <
douglas.mendiza...@rackspace.com> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Hi Asha,
>
> I'm not sure what you mean by "tempest tests."  If you're looking for
> Functional Tests for Barbican, then you can find them in the
> functionaltests directory [1] inside the Barbican repo.
>
> We have no intentions of adding Barbican specific tests to the Tempest
> repo.  It's my understanding that Tempest is moving away from one
> monolithic repository into a modular approach using tempest-lib.
>
> - - Douglas Mendizábal
>
> [1] http://git.openstack.org/cgit/openstack/barbican/tree/functionaltest
> s
>
>
> On 7/1/15 2:12 PM, Asha Seshagiri wrote:
> > Hi All ,
> >
> > Has anyone done the Tempest tests for Barbican API Any help would
> > be highly appreciated.
> >
> > -- /Thanks and Regards,/ /Asha Seshagiri/
> >
> >
> > __
> 
> >
> >
> OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> -BEGIN PGP SIGNATURE-
> Comment: GPGTools - https://gpgtools.org
>
> iQIcBAEBCgAGBQJVlEAyAAoJEB7Z2EQgmLX7NBYQAJB/ArYrW0LDitmlaTcupf8I
> B+LjBD6uMLI0nsFx4dOFu/FROSe37XkNvWumkj96wPZcmZNx1wuOntuyYu7STMBH
> Z+3JHxLwEdW5A3j0437IuNf14y8JZhio1+txMa0MWEEWIkfk/15Ppz3vhkKgfKsc
> ldMxQ0RboH5xXOWpIpCa8S022I+N2Erhp7Rn1xKA0rICKzvhpa87lB2aFZdZ3NMw
> pgM3W1Nzongl+zG0NHxqtxBX2y41nvzWSX7slvcjE1LIjPcBuc12Ja9WM6piZj/L
> +CxLHf8hAfZDxUDEm1Uwm9yvaWFtQFw684+CksRB4uq6KMGpF1EYOvnfoHtC71X9
> GokjNYZoz8vqkRdtXHvMwUTPH1V+G3y0mBL2eAZspfxjcfqkDudilkMdmEAhPWLy
> ihsH/S5g4SCgozYb9sZ9RJxNN/lGJodjyg3ODdFUwjPQtryejryVp2EOryA0T5Pd
> 7M7Zlhmm/NlZzwQBqQxDmVFHNU3baYizLTinPiYtURNmy6CqDs8WAWR/Br0oGJUI
> 5vL/y5hjPBR+WJV9IXfT0EuNqFTck1r0+vm/isez4hM2T7wFJcpFSPXS7l1GKxsx
> HTOqvujAOREcGfLYBBwwCoKCmDWoTqBjxUfY182sjYoUx1SnL5Ws01AdRcU3oNIl
> dEpBJSS6YgwvUZkjUJD2
> =FKK1
> -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
>



-- 
*Thanks and Regards,*
*Asha Seshagiri*
__
OpenStack Development Mailing List (not for 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] - breaking changes for plugins/drivers

[Kevin Benton]

I think we need to revisit the test infrastructure requirement. We have a
lot of logic to setup and test plugins/drivers and making each repo
duplicate all of that is a pretty big waste of effort. Maybe some base
stuff should go in neutron lib?
 On Jul 1, 2015 12:32 PM, "Doug Wiegley" 
wrote:

>
> On Jun 30, 2015, at 11:22 PM, Kevin Benton  wrote:
>
> Hi,
>
> We have had at least two breaking changes merge this week for out-of-tree
> drivers/plugins. These are just the two I noticed that broke the Big Switch
> CI (the one I keep an eye on since I had set it up):
>
> 1. Removed test_lib that changes config files.
> https://review.openstack.org/#/c/196583/
> 2. Removed the loopingcall common util with no deprecation cycle or
> announcement. https://review.openstack.org/#/c/192999/
>
> I proposed a revert for 1 that merged, but I don't particularly want to
> keep fighting this. What is our current policy on this? Just change
> whatever we want and tell plugin maintainers this is just the way things
> work?
>
>
> So, this is a big hairy bit of suck right now.  We expected some of this
> fallout with the services split and plugin decomp (in fact, we counted on
> it to move this ball forward), and we had adopted these guideilnes:
>
> 1. Other repos should not rely on oslo-incubated modules.
>  (neutron/openstack/…)
> 2. Other repos should not rely on neutron’s test infrastructure.
>  (neutron/tests/…)
> 3. For changes in any other area, they should be additive, or have a
> backwards compatibility shim or a big warning notice (the last being the
> suckiest answer.)
> 4. When we start getting “stable” interfaces in neutron/lib/…, which has
> the proviso of NO breaking changes without a shim or deprecation cycle, we
> get rid of restriction #3.
>
> We’ve been regularly merging code that breaks #3 and we have plugins that
> use code from #1 and #2 today.
>
> IMO, the core review team needs to be aware that neutron is now a library,
> and refactors and gratuitous cleanups have a pretty hefty cost. Especially
> in Liberty, be careful.
>
> Thanks,
> doug
>
>
>
>
>
> --
> Kevin Benton
>  __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Barbican : Regarding the Tempest Tests for Barbican

[Douglas Mendizábal]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi Asha,

I'm not sure what you mean by "tempest tests."  If you're looking for
Functional Tests for Barbican, then you can find them in the
functionaltests directory [1] inside the Barbican repo.

We have no intentions of adding Barbican specific tests to the Tempest
repo.  It's my understanding that Tempest is moving away from one
monolithic repository into a modular approach using tempest-lib.

- - Douglas Mendizábal

[1] http://git.openstack.org/cgit/openstack/barbican/tree/functionaltest
s


On 7/1/15 2:12 PM, Asha Seshagiri wrote:
> Hi All ,
> 
> Has anyone done the Tempest tests for Barbican API Any help would
> be highly appreciated.
> 
> -- /Thanks and Regards,/ /Asha Seshagiri/
> 
> 
> __

>
> 
OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
-BEGIN PGP SIGNATURE-
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJVlEAyAAoJEB7Z2EQgmLX7NBYQAJB/ArYrW0LDitmlaTcupf8I
B+LjBD6uMLI0nsFx4dOFu/FROSe37XkNvWumkj96wPZcmZNx1wuOntuyYu7STMBH
Z+3JHxLwEdW5A3j0437IuNf14y8JZhio1+txMa0MWEEWIkfk/15Ppz3vhkKgfKsc
ldMxQ0RboH5xXOWpIpCa8S022I+N2Erhp7Rn1xKA0rICKzvhpa87lB2aFZdZ3NMw
pgM3W1Nzongl+zG0NHxqtxBX2y41nvzWSX7slvcjE1LIjPcBuc12Ja9WM6piZj/L
+CxLHf8hAfZDxUDEm1Uwm9yvaWFtQFw684+CksRB4uq6KMGpF1EYOvnfoHtC71X9
GokjNYZoz8vqkRdtXHvMwUTPH1V+G3y0mBL2eAZspfxjcfqkDudilkMdmEAhPWLy
ihsH/S5g4SCgozYb9sZ9RJxNN/lGJodjyg3ODdFUwjPQtryejryVp2EOryA0T5Pd
7M7Zlhmm/NlZzwQBqQxDmVFHNU3baYizLTinPiYtURNmy6CqDs8WAWR/Br0oGJUI
5vL/y5hjPBR+WJV9IXfT0EuNqFTck1r0+vm/isez4hM2T7wFJcpFSPXS7l1GKxsx
HTOqvujAOREcGfLYBBwwCoKCmDWoTqBjxUfY182sjYoUx1SnL5Ws01AdRcU3oNIl
dEpBJSS6YgwvUZkjUJD2
=FKK1
-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] [Neutron] - breaking changes for plugins/drivers

[Doug Wiegley]

> On Jun 30, 2015, at 11:22 PM, Kevin Benton  wrote:
> 
> Hi,
> 
> We have had at least two breaking changes merge this week for out-of-tree 
> drivers/plugins. These are just the two I noticed that broke the Big Switch 
> CI (the one I keep an eye on since I had set it up):
> 
> 1. Removed test_lib that changes config files. 
> https://review.openstack.org/#/c/196583/ 
> 
> 2. Removed the loopingcall common util with no deprecation cycle or 
> announcement. https://review.openstack.org/#/c/192999/ 
> 
> 
> I proposed a revert for 1 that merged, but I don't particularly want to keep 
> fighting this. What is our current policy on this? Just change whatever we 
> want and tell plugin maintainers this is just the way things work?

So, this is a big hairy bit of suck right now.  We expected some of this 
fallout with the services split and plugin decomp (in fact, we counted on it to 
move this ball forward), and we had adopted these guideilnes:

1. Other repos should not rely on oslo-incubated modules.  (neutron/openstack/…)
2. Other repos should not rely on neutron’s test infrastructure.  
(neutron/tests/…)
3. For changes in any other area, they should be additive, or have a backwards 
compatibility shim or a big warning notice (the last being the suckiest answer.)
4. When we start getting “stable” interfaces in neutron/lib/…, which has the 
proviso of NO breaking changes without a shim or deprecation cycle, we get rid 
of restriction #3.

We’ve been regularly merging code that breaks #3 and we have plugins that use 
code from #1 and #2 today.

IMO, the core review team needs to be aware that neutron is now a library, and 
refactors and gratuitous cleanups have a pretty hefty cost. Especially in 
Liberty, be careful.

Thanks,
doug




> 
> -- 
> Kevin Benton
> __
> OpenStack Development Mailing 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] [Murano][Congress] Application placement use case

[Georgy Okrokvertskhov]

Hi,

I would like to share with the community one of the real use case which we
saw while working with one of the Murano customer and ask an advice. This
customer has multiple OpenStack regions which are serving for different
hypervisors. The reason for that is Oracle OpenStack which is used to work
with Solaris on top of SPARC architecture. There are other hypervisors KVM
and VMWare which are used.

There are multiple applications which should be placed to different regions
based on their requirements (OS, Hypervisor, networking restrictions). As
there is no single cloud, Nova scheduler can’t be used (at least in my
understanding) so we need to have some placement policies to put
applications properly. And obviously we don’t want to ask end user about
the placement.

Right now in Murano we can do this by:

   1.

   Hardcoding placement inside application. This approach will work and
   does not require any significant change in Murano. But there are obvious
   limitations like if we have two options for placement which one should be
   hardcoded.
   2.

   Create special placement scheduler application\class in Murano which
   will use some logic to place applications properly. This is better approach
   as nothing is hard coded in applications except their requirements.
   Applications will just have a workflow to ask placement scheduler for a
   decision and then will just use this decision.
   3.

   Use some external tool or OpenStack component for placement decision.
   This is a very generic use case which we saw multiple times. Tools like
   CIRBA are often used for this. Murano will need an interface to ask these
   tools. I think about this solution as an extension of 2.


I am aware that Murano is working on integration with Congress and I am
looking for an opportunity here to address real use case of Murano usage in
real customer environment. It will be great to know if OpenStack can offer
something here without involving 3rd party tools. I suspect that this is a
good use case for Congress, but I would like to see how it might be
implemented.

Thanks
Gosha

-- 
Georgy Okrokvertskhov
Architect,
OpenStack Platform Products,
Mirantis
http://www.mirantis.com
Tel. +1 650 963 9828
Mob. +1 650 996 3284
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [kolla][release] Announcing Liberty-1 release of Kolla

[Steven Dake (stdake)]

On 7/1/15, 8:11 AM, "Ian Cordasco"  wrote:

>
>
>On 6/30/15, 23:36, "Sam Yaple"  wrote:
>
>>Ian,
>>
>>
>>The most significant difference would be that Kolla uses image based
>>deployment rather than building from source on each node at runtime
>>allowing for a more consistent and repeatable deployment.
>>
>
>Do you mean specific docker images? Can you expand on how
>os-ansible-deployment is not repeatable? They use an lxc-container cached
>image so all containers are uniform (consistent, repeatable, etc.) and
>build wheels (once) and use an internal repo mirror so that all
>installations use the exact same set of wheels (e.g., consistent and
>repeatable).
>
>Are there places where you've found osad to be not consistent or
>repeatable?

Ian,

We did a 10 day eval of OSAD and liked the tech.  We did find the way the
deployment pipeline works to be lacking.  A purely theoretical problem
with the deployment pipeline is key repositories used to build the
software could be offline.  Since the building of the software occurs
during deployment, this could result in an inability to alter the
configuration of the deployment after OpenStack is deployed.  Kolla
suffers from this same problem during the installation (build pipeline)
step.  But as long as you have already built images somewhere in your
system, you are still able to deploy, avoiding complete downtime on
deployment that OSAD could theoretically suffer.

This theoretical issue makes the deployment non-repeatable.  Hope our 10
day eval analysis helps improve OSAD.

Regards
-steve

>
>>
>>On Tue, Jun 30, 2015 at 2:28 PM, Ian Cordasco
>> wrote:
>>
>>
>>
>>On 6/29/15, 23:59, "Steven Dake (stdake)"  wrote:
>>
>>>The Kolla community
>>>is pleased to announce the
>>> release of the
>>> Kolla Liberty 1 milestone.  This release fixes 56 bugs
>>> and implements 14 blueprints!
>>>
>>>
>>>Our community developed the following notable features:
>>>
>>>
>>>
>>>* A start at
>>>source-basedcontainers
>>
>>So how does this now compare to the stackforge/os-ansible-deployment
>>(soon
>>to be openstack/openstack-ansible) project?
>>
>>_
>>_
>>OpenStack Development Mailing List (not for usage questions)
>>Unsubscribe: 
>>openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>
>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>>
>>
>>
>
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

[openstack-dev] Barbican : Regarding the Tempest Tests for Barbican

[Asha Seshagiri]

Hi All ,

Has anyone done the Tempest tests for Barbican API
Any help would be highly appreciated.

-- 
*Thanks and Regards,*
*Asha Seshagiri*
__
OpenStack Development Mailing List (not for 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] Issue with neutron-dhcp-agent not recovering known ports cache after restart

[Shraddha Pandhe]

Hi,

I had a discussion about this with Kevin Benton on IRC. Filed a bug:
https://bugs.launchpad.net/neutron/+bug/1470612

Thanks!


On Wed, Jul 1, 2015 at 11:03 AM, Shraddha Pandhe <
spandhe.openst...@gmail.com> wrote:

> Hi Shihan,
>
> I think the problem is slightly different. Does your patch take care of
> the scenario where a port was deleted  AFTER agent restart (not when agent
> was down)?
>
> My problem is that, when the agent restarts, it loses its previous network
> cache. As soon as the agent starts, as part of "__init__", it rebuilds that
> cache [1]. But it does not put the ports in there [2].
>
> In sync_state, Neutron tries to enable/disable networks, by checking the
> diff between Neutron's state and its own network cache that it just built
> [3]. It enables any NEW networks and disables any DELETED networks, but it
> does nothing to PREVIOUSLY KNOWN NETWORKS. So those subnets and ports
> remain empty lists.
>
> Now, if such a port is deleted, [4] will return None and the port will
> never get deleted from the config.
>
> [1]
> https://github.com/openstack/neutron/blob/master/neutron/agent/dhcp/agent.py#L68
> [2]
> https://github.com/openstack/neutron/blob/master/neutron/agent/dhcp/agent.py#L79-L86
> [3]
> https://github.com/openstack/neutron/blob/master/neutron/agent/dhcp/agent.py#L154-L171
> [4]
> https://github.com/openstack/neutron/blob/master/neutron/agent/dhcp/agent.py#L349
>
>
>
__
OpenStack Development Mailing List (not for 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] Issue with neutron-dhcp-agent not recovering known ports cache after restart

[Shraddha Pandhe]

Hi Shihan,

I think the problem is slightly different. Does your patch take care of the
scenario where a port was deleted  AFTER agent restart (not when agent was
down)?

My problem is that, when the agent restarts, it loses its previous network
cache. As soon as the agent starts, as part of "__init__", it rebuilds that
cache [1]. But it does not put the ports in there [2].

In sync_state, Neutron tries to enable/disable networks, by checking the
diff between Neutron's state and its own network cache that it just built
[3]. It enables any NEW networks and disables any DELETED networks, but it
does nothing to PREVIOUSLY KNOWN NETWORKS. So those subnets and ports
remain empty lists.

Now, if such a port is deleted, [4] will return None and the port will
never get deleted from the config.

[1]
https://github.com/openstack/neutron/blob/master/neutron/agent/dhcp/agent.py#L68
[2]
https://github.com/openstack/neutron/blob/master/neutron/agent/dhcp/agent.py#L79-L86
[3]
https://github.com/openstack/neutron/blob/master/neutron/agent/dhcp/agent.py#L154-L171
[4]
https://github.com/openstack/neutron/blob/master/neutron/agent/dhcp/agent.py#L349
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Error starting designate (DNSaaS)

[Tim Simmons]

All,


The updated documentation for Designate is here:

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


The readthedocs version was abandoned a while ago, it was taken down by the 
Designate maintainers but appears to have returned.

Refer to

http://docs.openstack.org/developer/designate/install/ubuntu-dev.html

for the most up-to-date dev environment guide.


Feel free to join us in #openstack-dns if you run into issues.


Thanks,

Tim Simmons


From: Jaime Fernández 
Sent: Wednesday, July 1, 2015 12:24 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] Error starting designate (DNSaaS)

Just to test designate, as a first step, I installed everything in a single 
virtual machine.
The config file is exactly the same one than provided by 
http://designate.readthedocs.org/en/latest/getting-started.html#development-environment
 (except for property state_path with value /var/lib/designate). It looks like 
this file configures a sqlite database. Perhaps tomorrow I will try with MySQL 
instead of sqlite, but I also tried other official guideline that was using 
bind and mysql and it also failed in the same step. So, I'm not sure if it is 
some type of conflict with RHEL6.5, or the latest sql scripts have some bug.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [magnum] Magnum Midcycle Event Scheduling Doodle Poll closes July 7th

[Steven Dake (stdake)]

Apologies for double post – left off [magnum] prior by error.

Ton Ngo of IBM Silicon Valley Research has graciously offered to host the 2 day 
Magnum midcycle event at IBM’s facilities.

The sessions will run from 9AM – 5PM and catered lunch and refreshments 
(soda/water) will be provided.

The mid-cycle will be a standard mid-cycle with a 1 hour introduction followed 
by two days of design sessions.

Please cast your votes on any days you can make.

http://doodle.com/pinkuc5hw688zhxw

There are ~25 seats available.  Preference will be given to in-person core 
reviewers, followed by any folks that have made commits to the repository.  
After dates are settled, a separate eventbrite event will be setup to sort out 
the specifics such as  dietary needs, etc and confirm in-person seating if we 
are past capacity limits.

We will make remote participation available, but the experience will likely be 
less then optimal for remote participants.

Regards
-steve

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

Re: [openstack-dev] [kolla] Kolla-Palooza mid-cycle dates - July 28th, July 29th! - Please mark your calendars!

[Steven Dake (stdake)]

On 7/1/15, 1:22 AM, "Thierry Carrez"  wrote:

>Steven Dake (stdake) wrote:
>> The dates for the Kolla midcycle have been confirmed for July 28th and
>> July 29th.  Coffee/Tea will be provided in the mornings, and catered
>> lunch will be provided with soda or water both days.  A dinner will be
>> held July 28th.  Since budget is really tight for most folks because of
>> a desire to send Engineers to Tokyo for ODS, and the associated costs of
>> Tokyo travel, if you can¹t make the Kolla midcycle event in person
>> because of travel costs, we will also have remote participation
>>available.
>
>Please add it to https://wiki.openstack.org/wiki/Sprints !

Done.  Thanks for the guidance :)

Regards
-steve

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


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

Re: [openstack-dev] Juno Compute RPC v3.33 Endpoint Error when the Controller is running rabbitMQ v3.4.2

[Dan Smith]

> I have a three node Juno system running on Ubuntu 14.04. On the
> compute node I keep getting the following Endpoint does not support
> RPC version 3.33 to caller error when I launch a Nova instance. The
> Controller is running rabbitMQ v3.4.2. So I do not understand why the
> compute node thinks the endpoint does not support v3.33. I tried both
> rabbitMQ v3.3.3 and v3.5 on the compute node with the same result.

This message is referring to the nova compute RPC API version 3.33, not
the rabbit version.

> Data below. Any suggestions?

I imagine you've got different versions of nova on your nodes. Likely
your controller nodes are running something other (older) than the final
release of Juno, as 3.35 is what you should see if they were:

https://github.com/openstack/nova/blob/stable/juno/nova/compute/rpcapi.py#L274

Even still, the compute nodes are older than 3.33 in some way, which
means you probably have two issues.

Since this is a deployment/operations question at this point, I think
it's probably better for one of the non-dev lists.

--Dan

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

[openstack-dev] Juno Compute RPC v3.33 Endpoint Error when the Controller is running rabbitMQ v3.4.2

[Gregg Marxer]

Hi Experts,

I have a three node Juno system running on Ubuntu 14.04. On the compute node I 
keep getting the following Endpoint does not support RPC version 3.33 to caller 
error when I launch a Nova instance. The Controller is running rabbitMQ v3.4.2. 
So I do not understand why the compute node thinks the endpoint does not 
support v3.33. I tried both rabbitMQ v3.3.3 and v3.5 on the compute node with 
the same result. Data below. Any suggestions?

https://ask.openstack.org/en/question/69203/juno-controller-rabbitmq-v342-but-compute-node-v333-rpc-error/

Regards,

Gregg Marxer | Field Systems Engineer
O 949.631.6733   M 732.713.1361
f5.com | synthesis.f5.com

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

Re: [openstack-dev] Error starting designate (DNSaaS)

[Jaime Fernández]

Just to test designate, as a first step, I installed everything in a single
virtual machine.
The config file is exactly the same one than provided by
http://designate.readthedocs.org/en/latest/getting-started.html#development-environment
(except for property state_path with value /var/lib/designate). It looks
like this file configures a sqlite database. Perhaps tomorrow I will try
with MySQL instead of sqlite, but I also tried other official guideline
that was using bind and mysql and it also failed in the same step. So, I'm
not sure if it is some type of conflict with RHEL6.5, or the latest sql
scripts have some bug.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [heat] Question about retrieving resource_list from ResourceGroup

[Zane Bitter]

On 26/06/15 15:14, Hongbin Lu wrote:

Hi team,

I would like to start my question by using a sample template:

heat_template_version: 2014-10-16

parameters:

   count:

 type: number

 default: 5

   removal_list:

 type: comma_delimited_list

 default: []

resources:

   sample_group:

 type: OS::Heat::ResourceGroup

 properties:

   count: {get_param: count}

   removal_policies: [{resource_list: {get_param: removal_list}}]

   resource_def:

 type: testnested.yaml

outputs:

   resource_list:

value: # How to output a list of resources of sample_group? Like
"resource_list: ['0', '1', '2', '3', '4']"?

As showed above, this template has a resource group that contains
resources defined in a nested template. First, I am going to use this
template to create a stack. Then, I am going to update the stack to
scale down the resource group by specifying (through parameters) a
subset of resources that I want to remove. For example,

$  heat stack-create -f test.yaml test

$ heat stack-show test

$ heat stack-update -f test.yaml -P "count=3;removal_list=1,3" test

I want to know if it is possible to output a “resource_list” that lists
all the removal candidate, so that I can programmatically process the
list to compile another list (that is “removal_list”) which will be
passed back to the template as a parameter. Any help will be appreciated.


This is not really an openstack-dev@ question, and would be better 
directed at the openstack@ mailing list or, preferably, ask.openstack.org.


That said, assuming you're running Juno, the 'outputs' attribute[1] will 
return a dict of the outputs from the ResourceGroup members, so you can 
infer the membership from the keys in that dict.


cheers,
Zane.

[1] 
http://docs.openstack.org/developer/heat/template_guide/openstack.html#OS::Heat::AutoScalingGroup-attrs


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

Re: [openstack-dev] Error starting designate (DNSaaS)

[Rudrajit Tapadar]

Hello,

By any chance are you using a VIP sitting on top of a DB cluster as your
database connection in designate.conf?


On Wed, Jul 1, 2015 at 9:10 AM, Jaime Fernández  wrote:

> I've followed instructions at
> http://designate.readthedocs.org/en/latest/getting-started.html#development-environment
> to build and launch designate in a redhat 6.5 VM.
>
> I was able to install it (with some minor changes) but when trying to
> start designate, the first command failed:
>
> *designate-manage database sync*
>
> In the first execution, designate raises this error:
>
> *2015-06-30 12:04:08.874 26704 INFO migrate.versioning.api
> [designate-manage - - - - -] 46 -> 47... 2015-06-30 12:04:09.456 26704
> CRITICAL designate [designate-manage - - - - -] OperationalError:
> (OperationalError) no such column: reverse_name u'UPDATE recordsets SET
> reverse_name=reverse(recordsets.name )' ()*
> If I reexecute this command, it changes slightly but it fails in the same
> step (46 -> 47):
>
> *2015-06-30 12:04:23.359 26715 INFO migrate.versioning.api
> [designate-manage - - - - -] 46 -> 47... 2015-06-30 12:04:23.365 26715
> CRITICAL designate [designate-manage - - - - -] OperationalError:
> (OperationalError) duplicate column name: reverse_name u"\nALTER TABLE
> domains ADD reverse_name VARCHAR(255) DEFAULT ''" ()*
>
> It looks like a problem in the database scripts. Any fix for this?
>
>
> Today I installed devstack in a Ubuntu VM, with designate support, and it
> does work. Apparently both are using the same source code for designate.
> Could it be related to the operating system?
>
> __
> OpenStack Development Mailing 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] Error starting designate (DNSaaS)

[Jaime Fernández]

I've followed instructions at
http://designate.readthedocs.org/en/latest/getting-started.html#development-environment
to build and launch designate in a redhat 6.5 VM.

I was able to install it (with some minor changes) but when trying to start
designate, the first command failed:

*designate-manage database sync*

In the first execution, designate raises this error:

*2015-06-30 12:04:08.874 26704 INFO migrate.versioning.api
[designate-manage - - - - -] 46 -> 47... 2015-06-30 12:04:09.456 26704
CRITICAL designate [designate-manage - - - - -] OperationalError:
(OperationalError) no such column: reverse_name u'UPDATE recordsets SET
reverse_name=reverse(recordsets.name )' ()*
If I reexecute this command, it changes slightly but it fails in the same
step (46 -> 47):

*2015-06-30 12:04:23.359 26715 INFO migrate.versioning.api
[designate-manage - - - - -] 46 -> 47... 2015-06-30 12:04:23.365 26715
CRITICAL designate [designate-manage - - - - -] OperationalError:
(OperationalError) duplicate column name: reverse_name u"\nALTER TABLE
domains ADD reverse_name VARCHAR(255) DEFAULT ''" ()*

It looks like a problem in the database scripts. Any fix for this?


Today I installed devstack in a Ubuntu VM, with designate support, and it
does work. Apparently both are using the same source code for designate.
Could it be related to the operating system?
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [os-ansible-deployment] Feedback on Keystone Federation Spec

[Adam Young]

On 06/30/2015 12:21 PM, Jesse Pretorius wrote:

Hi everyone,

There was quite a bit of fanfare around the new federation features in 
OpenStack Kilo.


In the os-ansible-deployment/openstack-ansible project we've been 
putting together a view on how to implement federation with as little 
complexity as possible.


We've been working on some prototype code which can be seen by looking 
at the patches on the blueprint whiteboard [1] and have also prepared 
a spec for the implementation [2].


We'd like to get some feedback from the broader community - from 
deployers interested in using the feature and from 
developers/deployers who've worked with federation. The feedback we'd 
like to see is both in terms of the spec and the prototype code (which 
is changing quite frequently as we figure out the bits and pieces).


The follow-on to this work will be to specifically add the capability 
to make use of an ADFS IdP for a Keystone SP. This work will be linked 
to another blueprint [3] which is still a work in progress.


I look forward to the review feedback!

[1] 
https://blueprints.launchpad.net/openstack-ansible/+spec/keystone-federation

[2] https://review.openstack.org/194147
[3] 
https://blueprints.launchpad.net/openstack-ansible/+spec/keystone-sp-adfs-idp


I'm going to be doing an Anisble based setup for a Demo based on Ipsilon 
and FreeIPA.  For it, I will need to set up both  SAML Federation and 
SSSD/Kerberos Federation.  I suspect that much of the ADFS code is going 
to be common with the.


I'd like to make sure that the Playbooks for enabling Federation are 
something that people can use regardless of how they did their initial 
install (ignoring that it might battle with Puppet for Puppet based 
installs).



The







--
Jesse Pretorius
IRC: odyssey4me


__
OpenStack Development Mailing 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] [congress] mid cycle Sprint dates

[Jeremy Stanley]

On 2015-07-01 15:40:31 + (+), Tim Hinrichs wrote:
> We settled on dates and location for the Congress mid cycle sprint:
[...]

Invoking the spirit of Thierry, please remember to add it to the
list at:

https://wiki.openstack.org/wiki/Sprints#Liberty_sprints

-- 
Jeremy Stanley

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

[openstack-dev] [congress] mid cycle Sprint dates

[Tim Hinrichs]

Hi all!

We settled on dates and location for the Congress mid cycle sprint:

Aug 6-7
VMware campus, Palo Alto, CA

Please RSVP if you plan to come so we can get a headcount.

Hope to see you there!

Tim
__
OpenStack Development Mailing List (not for 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][packaging] Adding files to /etc in a package

[Ian Cordasco]

On 7/1/15, 09:13, "Jeremy Stanley"  wrote:

>On 2015-07-01 12:08:46 +1000 (+1000), Tony Breeds wrote:
>> Okay so I take you point no problem, but I'm not running distro
>> packages and I still want completions. There must be a way to
>> package the file to at least make it easier to achieve both our
>> goals.
>[...]
>
>http://docs.openstack.org/developer/pbr/#files
>-- 
>Jeremy Stanley

So for people using the clients to talk to arbitrary clouds from their
personal computer (that can be running more than just linux) we need to
fix this. The problem is that if the person is installing a wheel or using
a new enough version of pip (which creates wheels first and then installs
them after caching them, which is awesome by the way) then there are
limitations that prevent the package from writing files to arbitrary
paths. (For reference, https://github.com/pypa/pip/issues/2874)

Tl;dr, be very careful to test whatever solution is chosen going forward.
I'll be doing the same with https://bugs.launchpad.net/glance/+bug/1469869

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

Re: [openstack-dev] Python 2.6 failed jobs for SQLA-Migrate

[Ian Cordasco]

On 7/1/15, 09:03, "Mike Bayer"  wrote:

>
>
>On 6/30/15 9:51 PM, Thomas Goirand wrote:
>> Hi,
>>
>> Mike nicely tried to help me to get sqla-migrate to work with sqlalchemy
>> 1.0.6 which is now in Debian. But there's some failures in Python 2.6:
>>
>> https://review.openstack.org/#/c/197144/
>>
>> Do we still care about them? Can we get them removed from -migrate? IMO,
>> supporting the last SQLA is more important than the old Py 2.6.
>
>That is very odd that there's a failure, and if this is specific to SQLA
>1.0 also then I'd be pretty worried something weird is going on.  SQLA
>still supports 2.6 only because I haven't yet had the need to really use
>2.7-isms.
>
>I'm all for making the 2.6 job non-voting here but I do want to fix this.
>
>
>
>
>>
>> Thoughts anyone?
>>
>> Cheers,
>>
>> Thomas Goirand (zigo)
>>
>> 
>>_
>>_
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: 
>>openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Is sqlalchemy-migrate capped on the stable branches that still support
2.6? If so, I don't see a reason against removing it. That said, this is
failing on stderr receiving output when it shouldn't. Is that a (perhaps
deprecation) warning being raised by SQLA? If so, I think that test
failure is a good thing because it's helping catch the use of something
that's deprecated in SQLA.

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

Re: [openstack-dev] Python 2.6 failed jobs for SQLA-Migrate

[Mike Bayer]

On 7/1/15 10:03 AM, Mike Bayer wrote:



On 6/30/15 9:51 PM, Thomas Goirand wrote:

Hi,

Mike nicely tried to help me to get sqla-migrate to work with sqlalchemy
1.0.6 which is now in Debian. But there's some failures in Python 2.6:

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

Do we still care about them? Can we get them removed from -migrate? IMO,
supporting the last SQLA is more important than the old Py 2.6.


That is very odd that there's a failure, and if this is specific to 
SQLA 1.0 also then I'd be pretty worried something weird is going on.  
SQLA still supports 2.6 only because I haven't yet had the need to 
really use 2.7-isms.


I'm all for making the 2.6 job non-voting here but I do want to fix this.


I'm never going to fit this in the changelog, so here is what is going on.

migrate does some bizarre series of tests where it invokes its own 
command runner "migrate" through a library called "scripttest": 
https://scripttest.readthedocs.org/en/latest/.


Then, somewhere when it starts up, it also does some entrypoint stuff.   
In migrate/versioning/util/__init__.py we see:


return EntryPoint.parse('x=%s' % dotted_name).load(False)

Turns out setuptools wants to emit a deprecation warning there.  I was 
all set to rant on setuptools for what I then saw, but turns out, this 
is just a Python2.6/2.7 ism.


Here's a deprecation warning on py27:

Python 2.7.8 (default, Apr 15 2015, 09:26:43)
[GCC 4.9.2 20150212 (Red Hat 4.9.2-6)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import warnings
>>> warnings.warn("foo", DeprecationWarning)
>>>


Here is it on py26:

[classic@fedvms1 sqlalchemy-migrate]$ .tox/py26/bin/python
Python 2.6.8 (unknown, Jun  9 2015, 17:10:15)
[GCC 4.9.2 20150212 (Red Hat 4.9.2-6)] on linux4
Type "help", "copyright", "credits" or "license" for more information.
>>> import warnings
>>> warnings.warn("foo", DeprecationWarning)
__main__:1: DeprecationWarning: foo
>>>

 To wrap it up, "scripttest" doesn't want any standard error output 
unless we set it.   so we just turn off that flag and we're done.


https://review.openstack.org/197625














Thoughts anyone?

Cheers,

Thomas Goirand (zigo)

__ 


OpenStack Development Mailing 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] [Security][VMT] Promoting Michael McCune and Travis McPeak to Security CoreSec

[michael mccune]

On 07/01/2015 06:58 AM, Clark, Robert Graham wrote:

With various +1’s and no objections I’m pleased to announce that Michael
and Travis are now added to the ossg-coresec team.

This team assists the VMT with vulnerability metrics, triage and of
course OpenStack Security Notes.

Congratulations both!


thanks everyone!

mike


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

Re: [openstack-dev] [kolla][release] Announcing Liberty-1 release of Kolla

[Ian Cordasco]

On 6/30/15, 23:36, "Sam Yaple"  wrote:

>Ian,
>
>
>The most significant difference would be that Kolla uses image based
>deployment rather than building from source on each node at runtime
>allowing for a more consistent and repeatable deployment.
>

Do you mean specific docker images? Can you expand on how
os-ansible-deployment is not repeatable? They use an lxc-container cached
image so all containers are uniform (consistent, repeatable, etc.) and
build wheels (once) and use an internal repo mirror so that all
installations use the exact same set of wheels (e.g., consistent and
repeatable).

Are there places where you've found osad to be not consistent or
repeatable?

>
>On Tue, Jun 30, 2015 at 2:28 PM, Ian Cordasco
> wrote:
>
>
>
>On 6/29/15, 23:59, "Steven Dake (stdake)"  wrote:
>
>>The Kolla community
>>is pleased to announce the
>> release of the
>> Kolla Liberty 1 milestone.  This release fixes 56 bugs
>> and implements 14 blueprints!
>>
>>
>>Our community developed the following notable features:
>>
>>
>>
>>* A start at
>>source-basedcontainers
>
>So how does this now compare to the stackforge/os-ansible-deployment (soon
>to be openstack/openstack-ansible) project?
>
>__
>OpenStack Development Mailing 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] [Glance] Liberty mid-cycle meet up.

[Jeremy Stanley]

On 2015-07-01 04:39:31 + (+), Bhandaru, Malini K wrote:
> Nikhil any chance we can have remote participation? Based on the
> agenda folks can remote dial in.

If IRC/Etherpad are insufficient for remote participation and you
feel you need a dial-in conference bridge, remember that our project
infrastructure includes a PBX with voice conferencing capability
(both traditional telephone line and VoIP/SIP):

https://wiki.openstack.org/wiki/Infrastructure/Conferencing

-- 
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] [all][packaging] Adding files to /etc in a package

[Jeremy Stanley]

On 2015-07-01 12:08:46 +1000 (+1000), Tony Breeds wrote:
> Okay so I take you point no problem, but I'm not running distro
> packages and I still want completions. There must be a way to
> package the file to at least make it easier to achieve both our
> goals.
[...]

http://docs.openstack.org/developer/pbr/#files
-- 
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] Python 2.6 failed jobs for SQLA-Migrate

[Mike Bayer]

On 6/30/15 9:51 PM, Thomas Goirand wrote:

Hi,

Mike nicely tried to help me to get sqla-migrate to work with sqlalchemy
1.0.6 which is now in Debian. But there's some failures in Python 2.6:

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

Do we still care about them? Can we get them removed from -migrate? IMO,
supporting the last SQLA is more important than the old Py 2.6.


That is very odd that there's a failure, and if this is specific to SQLA 
1.0 also then I'd be pretty worried something weird is going on.  SQLA 
still supports 2.6 only because I haven't yet had the need to really use 
2.7-isms.


I'm all for making the 2.6 job non-voting here but I do want to fix this.






Thoughts anyone?

Cheers,

Thomas Goirand (zigo)

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



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

[openstack-dev] [glance] The sorry state of our spec process

[Flavio Percoco]

Greetings,

We're 1 week through L-2 (or is it 2?, I can't do time) and we, the
glance project, haven't even merged a single spec. Regardless of the
reasons behind this situation and the fact that we've been indeed
taking steps to improve this situation, I think we should put this
issue to an end.

There are many issues we've faced in Glance:

1. The glance-drivers team is too small [0]
2. Many specs have been held back waiting for code [1]
3. Huge expectations from the spec and very low review rate (even from
other members of the glance team).

There was a recent discussion on this m-l[2] about the spec process in
Nova and while I don't agree with everything that was said there, I do
think it highlights important problems that we're facing in glance as
well.

Therefore, I'd like to propose the following:

1. Expand our drivers team. I thik people in the glance community are
getting annoyed of reading this requests from me and "The Mythical
Man-Month" would agree with them. However, it's really sad that some
of our oldest (in terms of tenure) contributors that have shown
interest in joining the team haven't been added yet. I proposed to
bring all cores to the drivers team already and I still think that's a
good thing. Assuming that's something we don't want, then I'd like us
to find 2 or 3 people willing to volunteer for this task.

2. Lets try to get things into the backlog instead of expecting them
to be perfectly shaped and targeted for this release. Lets let people
start from  a base, generally agreed, idea so that code can be written
and reviews on the actual feature can be made. Once the feature is
implemented, we can move the spec to the release directory. I believe
this was also proposed in Nikola's thread[2].

3. Not all specs need to have 3-month-long discussions to be approved.
I'm not suggesting to just merge specs that are in poor state but we
can't always ask for code to understand whether a spec makes sense or
not.

Unfortunately, we're already in L-2 and I believe it'll be really hard
for some of those features to land in Liberty, which is also sad and
quite a waste of time.

I don't believe the above is the ultimate solution to this issue but I
believe it will help. For the next cycle, we really need to organize
this process differently.

The email is already long enough so, I hope we'll agree on something
and finally take some actions.

Cheers,
Flavio

[0] https://review.openstack.org/#/c/126550/
[1] https://review.openstack.org/#/admin/groups/342,members
(Mark Washenberger and Arnaud Legendre are not contributors anymore)
[2] http://lists.openstack.org/pipermail/openstack-dev/2015-June/067861.html


--
@flaper87
Flavio Percoco


pgpk8Y7zfh9rE.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] Network issue with libvirt-xen driver, iptables race

[Daniel P. Berrange]

On Tue, Jun 30, 2015 at 03:02:54PM +0100, Anthony PERARD wrote:
> Hi all,
> 
> We have an issue with the driver libvirt-xen. When a guest is started by
> Nova, nova-network is going to do some network setup and call
> iptables-{save,restore}, and the Xen toolstack is going to setup the
> vif of the guest, via a script, which also update the iptables.
> 
> The Xen script is simply calling those commands:
>   ip link set dev ${dev} down
>   ip link set dev ${dev} address fe:ff:ff:ff:ff:ff
>   ip address flush dev ${dev}
>   brctl addif ${bridge} ${dev}
>   ip link set dev ${dev} up
>   iptables -I FORWARD -m physdev --physdev-is-bridged --physdev-in "$dev" -j 
> ACCEPT
>   iptables -I FORWARD -m physdev --physdev-is-bridged --physdev-out "$dev" -j 
> ACCEPT
> 
> $dev been by default vif$domid.$devid.
> 
> Only the call to iptables is an issue and fail fairly often when it looses
> the race against iptables-{save,restore}.
> 
> It is possible to have Nova asking to run a different script that would not
> call iptables. But that script would need to be store somewhere, in the
> nova repo would be best.
> 
> Any though on that?
> 
> Is `iptables` call necessary for the vif with OpenStack?
> If so, can nova-network do the update? Or the script called by the Xen
> toolstack could take an OpenStack lock before calling iptables?
> 
> Bug report: https://bugs.launchpad.net/nova/+bug/1461642

IIRC, the iptables physdev matches are to deal with the fact that the
kernel default sends all bridge traffic via the net filter layer. This
is arguably a layering violation, because if you're bridging guests at
the network layer, you generally don't expect traffic to be filtered
at the IP layer. Some distros override this kernel default by setting
some sysctls:

 net.bridge.bridge-nf-call-ip6tables = 0
 net.bridge.bridge-nf-call-iptables = 0
 net.bridge.bridge-nf-call-arptables = 0

At which point I think the iptables rules you quote should be
redundant.

In terms of locking, libvirt uses the '-w' flag when calling iptables
which prevents concurrent execution of iptables. I'm not sure whether
adding -w would be sufficient to deal with your particular case.
Regardless, any time nova invokes iptables, it should use -w

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] [nova] Network issue with libvirt-xen driver, iptables race

[Anthony PERARD]

On Wed, Jul 01, 2015 at 10:26:43AM +0100, Bob Ball wrote:
> Hi Anthony,
> 
> > The Xen script is simply calling those commands:
> > ...
> >   iptables -I FORWARD -m physdev --physdev-is-bridged --physdev-in "$dev"
> > -j ACCEPT
> >   iptables -I FORWARD -m physdev --physdev-is-bridged --physdev-out
> > "$dev" -j ACCEPT
> 
> Are you saying that these two commands aren't needed to be called by Xen in 
> the OpenStack case because, for example, forwarding is set up by nova-network?
> 
> > It is possible to have Nova asking to run a different script that would not
> > call iptables. But that script would need to be store somewhere, in the
> > nova repo would be best.
> 
> Did you mean for Xen to be calling the different script, rather than Nova?  
> If Nova is calling it then the obvious place is in the Nova repo.

What I meant is, when Nova is creating the XML guest config, it can set the
script parameter for the network interface.

> If it's a script that Xen needs to call then I would suggest it went to the 
> contrib/xen directory.  There already appears to be a vif-script there which 
> was implemented for Neutron, does that do what's needed here?

Thanks, I will look at this. Is this contrib/ dir going to be install
somewhere on a Nova release? So that there is no need for extra user
intervention at deployment time as long as Nova can generate an absolute
path for where the script is.

> > Is `iptables` call necessary for the vif with OpenStack?
> 
> Pass on that one - someone who knows libvirt might know if libvirt does 
> everything that's needed in the Xen case or if there are kvm specific scripts.

I guest, the question is, is the default to ACCEPT everything or not.

> > If so, can nova-network do the update? Or the script called by the Xen
> > toolstack could take an OpenStack lock before calling iptables?
> 
> I'd hope that it's not necessary for the Xen script to invoke iptables; the 
> idea of having the two processes working with the same lock for iptables 
> sounds nasty (e.g. it might make it harder to know which process is holding 
> on to the lock in the case of a bug).  If this really is needed perhaps Nova 
> should be calling the iptables commands after setting up the VIF?  This way 
> it's just Nova that's in control of the lock.

I think it's possible to have nova setting up the iptables for the vif,
we would just need nova to generate a name for the vif as it might be
difficult to guest the name of the interface.
(To guest, nova would need to know the domid, which libvirt should have.)

Thanks,

-- 
Anthony PERARD

__
OpenStack Development Mailing List (not for 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] - breaking changes for plugins/drivers

[Gary Kotton]

One of the hidden costs of an external plugin that things break. This is 
something that happens to us at least once a week. We have been proactive in 
this by doing the following:

  1.  Running the decomposed plugin unit tests with every neutron change - this 
gives us an indication of which patch broke and why
  2.  Running the Ci

The onus is on the decomposed maintainers.

Having said that the ability to actually do some development is liberating.

A luta continua

From: Kevin Benton mailto:blak...@gmail.com>>
Reply-To: OpenStack List 
mailto:openstack-dev@lists.openstack.org>>
Date: Wednesday, July 1, 2015 at 1:49 PM
To: OpenStack List 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [Neutron] - breaking changes for plugins/drivers

>For the second one, I think we made it clear before that no plugins must rely 
>on neutron.openstack.* contents.

Where was this made clear? I didn't know about this until it broke and I'm a 
very frequent contributor and reviewer, which is the core of my complaint. The 
updated wiki is helpful, but doing it after-the-fact only helps when people try 
to figure out why they can't make changes to their repos.

In that patch there were 3 in-tree third party plugins that had to be updated. 
That should have given a hint that it was likely to break other plugins as 
well. The other annoying lesson from that is that plugins/drivers still in tree 
are getting better treatment than the ones that went through the split process.

We need to be much more diligent about announcing these things ahead of time or 
we need to be clear that Neutron is completely unstable as a framework and 
third party drivers should basically never import anything from the neutron 
namespace.


On Tue, Jun 30, 2015 at 11:58 PM, Ihar Hrachyshka 
mailto:ihrac...@redhat.com>> wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 07/01/2015 08:22 AM, Kevin Benton wrote:
> Hi,
>
> We have had at least two breaking changes merge this week for
> out-of-tree drivers/plugins. These are just the two I noticed that
> broke the Big Switch CI (the one I keep an eye on since I had set
> it up):
>
> 1. Removed test_lib that changes config files.
> https://review.openstack.org/#/c/196583/ 2. Removed the loopingcall
> common util with no deprecation cycle or announcement.
> https://review.openstack.org/#/c/192999/
>
> I proposed a revert for 1 that merged, but I don't particularly
> want to keep fighting this. What is our current policy on this?
> Just change whatever we want and tell plugin maintainers this is
> just the way things work?
>

For the first one, the revert is justified.

For the second one, I think we made it clear before that no plugins
must rely on neutron.openstack.* contents.

Now I've made it mentioned at:
https://wiki.openstack.org/wiki/Neutron/LibraryAPIBreakage

If your plugin is using any of neutron.openstack.* contents, just stop
doing it. It's going to break.

Ihar
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJVk4+AAAoJEC5aWaUY1u57OE8IAKDqKudi5zOUxRPc4Elzsdw4
mASF5Mtguj5q9OUpYIyeOkbsIKmOwop4tbGjz52L+OZ8aLq1XptpKLUuX6mBL3lS
m0/DtD2RlBRTmiO/kyBxeqJbsj7nZU9eoiDJ88gN51IetN1kIR09rAbmdkoduhK2
FIrFLJhhuVqmb8S377cbSgJ46kC1DeDa2xhtFWB39iIKO3ZTwO7ia5KRipTSTyNV
4ngB0+d8EgMfmsKj4Bd7/btkg5rI+o4qNgd4L1Ncd1BQzPiOzzeeGo0lAe86Kf7z
KUH2Sw6n6mIUZJSGzDP4cigGqSsilBaurryK90G/Go1q7BEMRFVyrGHObnMBZTw=
=qSnW
-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



--
Kevin Benton
__
OpenStack Development Mailing List (not for 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] oslo.messaging version and RabbitMQ heartbeat support

[Mike Dorman]

As a follow up to the discussion during the IRC meeting yesterday, please vote 
for one of these approaches:

1)  Make the default for the rabbit_heartbeat_timeout_threshold parameter 60, 
which matches the default in Kilo oslo.messaging.  This will by default enable 
the RMQ heartbeat feature, which also matches the default in Kilo 
oslo.messaging.  Operators will need to set this parameter to 0 in order to 
disable the feature, which will be documented in the comments within the 
manifest.  We will reevaluate the default value for the Liberty release, since 
the oslo.messaging default most likely will change to 0 for that release.

2)  In addition to #1 above, also add a rabbit_enable_heartbeat parameter, 
which will default to false.  Setting that to true will be needed to explicitly 
enable the RMQ heartbeat feature, regardless of the value of 
rabbit_heartbeat_timeout_threshold.  By default the RMQ heartbeat feature will 
be disabled, which may be a marginally safer approach (due to the 
requirements.txt stuff, see below), but will not match the upstream Kilo 
oslo.messaging default.  This will also turn off the feature for people who 
have already been “getting it for free” if they do nothing and don’t update 
their composition module.

My vote is for #1.

Let’s plan to close the voting by next week’s IRC meeting, so we can come to a 
final conclusion at that time.

Thanks,
Mike




From: Mike Dorman
Reply-To: "OpenStack Development Mailing List (not for usage questions)"
Date: Tuesday, June 23, 2015 at 5:07 PM
To: "OpenStack Development Mailing List (not for usage questions)"
Subject: [openstack-dev] [puppet] oslo.messaging version and RabbitMQ heartbeat 
support

As a follow up to https://review.openstack.org/#/c/194399/ and the meeting 
discussion earlier today, I’ve determined that everybody (RDU, Ubuntu, Debian) 
is packaging oslo.messaging 1.8.2 or 1.8.3 with the Kilo build.  (This is also 
the version we get on our internal Anvil-based build.)  This is considerably 
lower than 1.11.0 where the default rabbit_heartbeat_timeout_threshold changes 
(from 60 to 0.)

If we go forward using the default rabbit_heartbeat_timeout_threshold value of 
60, that will be the correct default behavior up through oslo.messaging 1.10.x.

When people upgrade to 1.11.0 or higher, we’ll no longer match the upstream 
default behavior.  But, it should maintain the _actual_ behavior (heartbeating 
enabled) for people doing an upgrade.  Once Liberty is cut, we should 
reevaluate to make sure we’re matching whatever the default is at that time.

However, the larger problem I see is that oslo.messaging requirements.txt in 
<=1.10.x does not enforce the needed versions of kombu and amqp for heartbeat 
to work:
https://github.com/openstack/oslo.messaging/blob/1.8.2/requirements.txt#L25-L26 
 This is confusing as heartbeat is enabled by default!

I am not sure what the behavior is when heartbeat is enabled with older kombu 
or amqp.  Does anyone know?  If it silently fails, maybe we don’t care.  But if 
enabling heartbeat (by default, rabbit_heartbeat_timeout_threshold=60) actively 
breaks, that would be bad.

I see two options here:

1)  Make default rabbit_heartbeat_timeout_threshold=60 in the Puppet modules, 
to strictly follow the upstream default in Kilo.  Reevaluate this default value 
for Liberty.  Ignore the kombu/amqp library stuff and hope “it just works 
itself out naturally.”

2)  Add a rabbit_enable_heartbeat parameter to explicitly enable/disable the 
feature, and default to disable.  This goes against the current default 
behavior, but will match it for oslo.messaging >=1.11.0.  I think this is the 
safest path, as we won’t be automatically enabling heartbeat for people who 
don’t have a new enough kombu or amqp.

Personally, I like #1, because I am going to enable this feature, anyway.  And 
I can’t really imagine why one would _not_ want to enable it.  But I am fine 
implementing it either way, I just want to get it done so I can get off my 
local forks. :)

Thoughts?

Mike

__
OpenStack Development Mailing List (not for 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] - breaking changes for plugins/drivers

[Kyle Mestery]

On Wed, Jul 1, 2015 at 5:49 AM, Kevin Benton  wrote:

> >For the second one, I think we made it clear before that no plugins must
> rely on neutron.openstack.* contents.
>
> Where was this made clear? I didn't know about this until it broke and I'm
> a very frequent contributor and reviewer, which is the core of my
> complaint. The updated wiki is helpful, but doing it after-the-fact only
> helps when people try to figure out why they can't make changes to their
> repos.
>
>
I agree, and I'd also like to mention that it would be good to move this
type of documentation in-tree so it can be autogenerated rather than using
the wiki.


> In that patch there were 3 in-tree third party plugins that had to be
> updated. That should have given a hint that it was likely to break other
> plugins as well. The other annoying lesson from that is that
> plugins/drivers still in tree are getting better treatment than the ones
> that went through the split process.
>
>
Also agree. The current plan of record is that plugins/drivers which have
not started to decompose will be marked as deprecated in Liberty, and we'll
remove them in Mxx. I hope Henry can update his "Phase 2 Decomp" devref [1]
to indicate this.

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

We need to be much more diligent about announcing these things ahead of
> time or we need to be clear that Neutron is completely unstable as a
> framework and third party drivers should basically never import anything
> from the neutron namespace.
>
>
We're working on that. The decomp of the reference plugin will help this
situation because you won't be able to pass the gate if you break these
types of things, and that will give patch authors time to notify everyone
else of breaking changes, or even just submit patches to the other
repositories.


> On Tue, Jun 30, 2015 at 11:58 PM, Ihar Hrachyshka 
> wrote:
>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA256
>>
>> On 07/01/2015 08:22 AM, Kevin Benton wrote:
>> > Hi,
>> >
>> > We have had at least two breaking changes merge this week for
>> > out-of-tree drivers/plugins. These are just the two I noticed that
>> > broke the Big Switch CI (the one I keep an eye on since I had set
>> > it up):
>> >
>> > 1. Removed test_lib that changes config files.
>> > https://review.openstack.org/#/c/196583/ 2. Removed the loopingcall
>> > common util with no deprecation cycle or announcement.
>> > https://review.openstack.org/#/c/192999/
>> >
>> > I proposed a revert for 1 that merged, but I don't particularly
>> > want to keep fighting this. What is our current policy on this?
>> > Just change whatever we want and tell plugin maintainers this is
>> > just the way things work?
>> >
>>
>> For the first one, the revert is justified.
>>
>> For the second one, I think we made it clear before that no plugins
>> must rely on neutron.openstack.* contents.
>>
>> Now I've made it mentioned at:
>> https://wiki.openstack.org/wiki/Neutron/LibraryAPIBreakage
>>
>> If your plugin is using any of neutron.openstack.* contents, just stop
>> doing it. It's going to break.
>>
>> Ihar
>> -BEGIN PGP SIGNATURE-
>> Version: GnuPG v2
>>
>> iQEcBAEBCAAGBQJVk4+AAAoJEC5aWaUY1u57OE8IAKDqKudi5zOUxRPc4Elzsdw4
>> mASF5Mtguj5q9OUpYIyeOkbsIKmOwop4tbGjz52L+OZ8aLq1XptpKLUuX6mBL3lS
>> m0/DtD2RlBRTmiO/kyBxeqJbsj7nZU9eoiDJ88gN51IetN1kIR09rAbmdkoduhK2
>> FIrFLJhhuVqmb8S377cbSgJ46kC1DeDa2xhtFWB39iIKO3ZTwO7ia5KRipTSTyNV
>> 4ngB0+d8EgMfmsKj4Bd7/btkg5rI+o4qNgd4L1Ncd1BQzPiOzzeeGo0lAe86Kf7z
>> KUH2Sw6n6mIUZJSGzDP4cigGqSsilBaurryK90G/Go1q7BEMRFVyrGHObnMBZTw=
>> =qSnW
>> -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
>>
>
>
>
> --
> Kevin Benton
>
> __
> OpenStack Development Mailing 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] when I run "git review -s", it occur a error

[ZZelle]

Hi,

Git review tries to download gerrit hook used to add automatically a
Change-Id when missing.

Old versions of git-review (<1.24 iirc) badly supports http(s) protocols
and use scp to download the hook.


You have 2 options:
* upgrade your git-review
* or download manually the hook:
  mkdir .git/hooks
  wget https://review.openstack.org/tools/hooks/commit-msg -qO
.git/hooks/commit-msg
  chmod +x .git/hooks/commit-msg


Cédric







On Wed, Jul 1, 2015 at 1:38 PM, 胡西宁  wrote:

>
> hi everyone, when I run "git review -s",  it occur a error below, who can
> help me slove it, thanks
>
> # LANG=C LANGUAGE=C git review -v
>
> 2015-07-01 19:33:24.301828 Running: git log --color=never --oneline
> HEAD^1..HEAD
> 2015-07-01 19:33:24.306742 Running: git remote
> 2015-07-01 19:33:24.310573 Running: git branch -a --color=never
> 2015-07-01 19:33:24.315126 Running: git rev-parse --show-toplevel --git-dir
> 2015-07-01 19:33:24.318862 Running: git remote show -n gerrit
> Found origin Push URL:
> https://review.openstack.org/stackforge/python-tackerclient.git
> Fetching commit hook from: scp://review.openstack.org:None
> 2015-07-01 19:33:24.323647 Running: scp review.openstack.org:hooks/commit-msg
> .git/hooks/commit-msg
> Problems encountered installing commit-msg hook
> The following command failed with exit code 1
> "scp  review.openstack.org:hooks/commit-msg .git/hooks/commit-msg"
> ---
> .git/hooks/commit-msg: No such file or directory
>
>
> this my remote repo:
> #git remote -v
> gerrit https://review.openstack.org/stackforge/python-tackerclient.git
> (fetch)
> gerrit https://review.openstack.org/stackforge/python-tackerclient.git
> (push)
> originhttps://github.com/stackforge/python-tackerclient.git (fetch)
> originhttps://github.com/stackforge/python-tackerclient.git (push)
>
> thanks
> cinghu
>
>
>
> __
> OpenStack Development Mailing 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] EC2 API - users wanted

[Alexandre Levine]

Hi all,

I wanted to remind everybody that the existing nova's EC2 API was 
deprecated in Kilo and the replacement-to-be (stackforge/ec2-api) stays 
virtually untouched by customers. It means that without real beta and 
production testing it's not going to get accepted into OpenStack. Since 
nova's EC2 API being deprecated doesn't get any good support, let alone 
development, at some point situation might become even more pitiful than 
it was before the Kilo release, when nova's EC2 API had some critical 
bugs and there was a risk to loose support of this protocol in OpenStack 
altogether.


I'd like to urge everybody on the op's side to start using or testing 
the replacement EC2 API project. The Kilo-compatible release can be 
found here:


https://github.com/stackforge/ec2-api/tree/0.1.0/ec2api

We'll be more than glad to help with any usage or testing effort and fix 
whatever issues arise ASAP.


Thanks in advance.

Best regards,
  Alex Levine


__
OpenStack Development Mailing List (not for 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] [openstack-operators][neutron[dhcp][dnsmask]: duplicate entries in addn_hosts causing no IP allocation

[Daniel Comnea]

Indeed Neil that is the case.
Pasting below some info in case someone will face the same issue.

root@node-9:~# apt-cache madison dnsmasq-base
dnsmasq-base | 2.59-4ubuntu0.1 | http://1.1.1.1/ubuntu/fuelweb/x86_64/
precise/main amd64 Packages
root@node-9:~# dpkg -I dnsmasq-base
dpkg-deb: error: failed to read archive `dnsmasq-base': No such file or
directory
root@node-94:~# dpkg -l | grep dnsmas
ii  dnsmasq-base
2.59-4ubuntu0.1 Small caching DNS proxy
and DHCP/TFTP server
ii  dnsmasq-utils
2.59-4ubuntu0.1 Utilities for
manipulating DHCP leases
root@node-9:~# apt-cache showpkg dnsmasq-base
Package: dnsmasq-base
Versions:
2.59-4ubuntu0.1
(/var/lib/apt/lists/1.1.1.1:8080_ubuntu_fuelweb_x86%5f64_dists_precise_main_binary-amd64_Packages)
(/var/lib/dpkg/status)
 Description Language:
 File: /var/lib/apt/lists/211.210.0.9:8080
_ubuntu_fuelweb_x86%5f64_dists_precise_main_binary-amd64_Packages
  MD5: 1f9c3f0c557ca377bcc6c659e4694437


Reverse Depends:
  neutron-dhcp-agent,dnsmasq-base
  nova-network,dnsmasq-base
  libvirt-bin,dnsmasq-base 2.46-1
Dependencies:
2.59-4ubuntu0.1 - libc6 (2 2.15) libdbus-1-3 (2 1.1.1) libidn11 (2 1.13)
libnetfilter-conntrack3 (2 0.9.1) dnsmasq (3 2.59-4ubuntu0) dnsmasq:i386 (3
2.59-4ubuntu0) dnsmasq (3 2.59-4ubuntu0) dnsmasq:i386 (3 2.59-4ubuntu0)
Provides:
2.59-4ubuntu0.1 -
Reverse Provides:
root@node-9:~#


Will keep you updated on how i solved it (hopefully will help others)


Dani


On Wed, Jul 1, 2015 at 12:01 PM, Neil Jerram 
wrote:

> Hi Dani,
>
> I think that would be fine, if it worked.  The  that you want
> is dnsmasq-base, I believe.
>
> However, I would not expect it to work, on a Fuel 5.1 node, because I
> believe such nodes are set up to use the Fuel master as their package
> repository, and I don't think that a Fuel 5.1 master will have any newer
> dnsmasq packages that what you already have installed.
>
> I hope that makes sense - happy to explain further if not.
>
> Neil
>
>
> On 01/07/15 10:24, Daniel Comnea wrote:
>
>> Neil, much thanks !!!
>>
>> Any idea if i can go and only run apt-get --only-upgrade install
>>   or that will be too crazy?
>>
>> Cheers,
>> Dani
>>
>>
>> On Wed, Jul 1, 2015 at 9:23 AM, Neil Jerram > > wrote:
>>
>> Well, the bug discussion seems to point specifically to this dnsmasq
>> fix:
>>
>>
>> http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=9380ba70d67db6b69f817d8e318de5ba1e990b12
>>
>>  Neil
>>
>>
>> On 01/07/15 07:34, Daniel Comnea wrote:
>>
>> Hi,
>>
>> sorry for no feedback, i've been doing more and more test and
>> after
>> enabled the dnsmasq log i found the error which i'm not longer
>> sure if
>> is related to having duplicated entries
>>
>> dnsmasq-dhcp[21231]: 0 DHCPRELEASE(tap8ecf66b6-72) 192.168.111.24
>> fa:16:3e:72:04:82 unknown lease
>>
>> Looking around it seems i'm hitting this bug [1] but not clear
>> from the
>> description what was the problem on dnsmasp 2.59 (which comes
>> wiht Fuel 5.1)
>>
>> Any ideas?
>>
>> Cheers,
>> Dani
>>
>> [1] https://bugs.launchpad.net/neutron/+bug/1271344
>>
>> On Wed, Jun 10, 2015 at 7:13 AM, Daniel Comnea
>> mailto:comnea.d...@gmail.com>
>> >>
>> wrote:
>>
>>  Thanks a bunch Kevin!
>>
>>  I'll try this patch and report back.
>>
>>  Dani
>>
>>
>>  On Tue, Jun 9, 2015 at 2:50 AM, Kevin Benton
>> mailto:blak...@gmail.com>
>>  >>
>> wrote:
>>
>>  Hi Daniel,
>>
>>  I'm concerned that we are encountered out-of-order port
>> events
>>  on the DHCP agent side so the delete message is
>> processed before
>>  the create message. Would you be willing to apply a
>> small patch
>>  to your dhcp agent to see if it fixes the issue?
>>
>>  If it does fix the issue, you should see occasional
>> warnings in
>>  the DHCP agent log that show "Received message for port
>> that was
>>  already deleted". If it doesn't fix the issue, we may
>> be losing
>>  the delete event entirely. If that's the case, it would
>> be great
>>  if you can enable debuging on the agent and upload a
>> log of a
>>  run when it happens.
>>
>>  Cheers,
>>  Kevin Benton
>>
>>  Here is the patch:
>>
>>  diff --git a/neutron/agent/dhcp_agent.py
>>  b/neutron/agent/dhcp_agent.py
>>  index 71c9709..9b9b637 100644

Re: [openstack-dev] [ceilometer] Aodh has been imported, next steps

[Eoghan Glynn]

> > > I think removing options from the API requires version bump. So if we
> > > plan to do this, that should be introduced in v3 as opposed to v2,
> > > which should remain the same and maintained for two cycles (assuming
> > > that we still have this policy in OpenStack). It this is achievable by
> > > removing the old code and relying on the new repo that would be the
> > > best, if not then we need to figure out how to freeze the old code.
> > 
> > This is not an API change as we're not modifying anything in the API.
> > It's just the endpoint *potentially* split in two. But you can also merge
> > them as they are 2 separate entities (/v2/alarms and /v2/*).
> > So there's no need for a v3 here.
> 
> Will this be accessible in the same way as currently or it needs changes on
> client side?

How about ceilometer-api service returns 301 'Moved Permanently' for any
requests to /v2/alarms, redirecting to the new Aodh endpoint?

Being a standard HTTP response code, this should be handled gracefully by
any (non-broken) HTTP client.

Cheers,
Eoghan

__
OpenStack Development Mailing 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] [Ironic] Specs process query

[Matt Keenan]

Hi,

In submitting my first ironic spec, I am following the process outlined at:
  https://wiki.openstack.org/wiki/Ironic/Specs_Process

As of Kilo this suggests we also follow:

http://lists.openstack.org/pipermail/openstack-dev/2014-August/041960.html

This indicates that once a spec is registered before submission of the 
spec text the registered spec needs to be given the ok.


Quick discussion on IRC indicates that this was never adhered to. If 
it's not going to be adhered to then I'd suggest removing this reference 
from Specs_Process.


cheers

Matt

__
OpenStack Development Mailing 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] [XenAPI] New meeting time

[Bob Ball]

Hi all,

To be able to involve some new sub-team members in China, we've moved the 
meeting times as discussed in the last two XenAPI meetings.

The new time is at 0930 UTC, Alternate Wednesdays, with the next meeting at 
0930 UTC on 8th July.

See you there!

Bob

__
OpenStack Development Mailing 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] when I run "git review -s", it occur a error

[胡西宁]

hi everyone, when I run "git review -s",  it occur a error below, who 
can help me slove it, thanks


# LANG=C LANGUAGE=C git review -v

2015-07-01 19:33:24.301828 Running: git log --color=never --oneline 
HEAD^1..HEAD

2015-07-01 19:33:24.306742 Running: git remote
2015-07-01 19:33:24.310573 Running: git branch -a --color=never
2015-07-01 19:33:24.315126 Running: git rev-parse --show-toplevel --git-dir
2015-07-01 19:33:24.318862 Running: git remote show -n gerrit
Found origin Push URL: 
https://review.openstack.org/stackforge/python-tackerclient.git

Fetching commit hook from: scp://review.openstack.org:None
2015-07-01 19:33:24.323647 Running: scp 
review.openstack.org:hooks/commit-msg .git/hooks/commit-msg

Problems encountered installing commit-msg hook
The following command failed with exit code 1
"scp  review.openstack.org:hooks/commit-msg .git/hooks/commit-msg"
---
.git/hooks/commit-msg: No such file or directory


this my remote repo:
#git remote -v
gerrit https://review.openstack.org/stackforge/python-tackerclient.git 
(fetch)
gerrit https://review.openstack.org/stackforge/python-tackerclient.git 
(push)

originhttps://github.com/stackforge/python-tackerclient.git (fetch)
originhttps://github.com/stackforge/python-tackerclient.git (push)

thanks
cinghu



__
OpenStack Development Mailing List (not for 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][packaging] Adding files to /etc in a package

[Thomas Goirand]

On 07/01/2015 04:08 AM, Tony Breeds wrote:
> On Wed, Jul 01, 2015 at 03:55:53AM +0200, Thomas Goirand wrote:
> 
>> Please don't do this. This is the kind of job to be done by package
>> maintainers in distribution, because mostly, Python maintainers wouldn't
>> know how to do things correctly. Here we've got a good example: the bash
>> completion scripts are now to be installed in
>> /usr/share/bash-completion/completions and not in /etc.
>>
>> As for the general project config files, I often install them in
>> /usr/share/-common, and then copy the file in /etc/ in
>> a postinst, so that the file isn't marked as CONFFILE.
>>
>> So please don't attempt to do the work of distributions. We then end up
>> with config files in /usr/etc (as per what happen with Neutron
>> packages), and it's a mess to un-cruft.
> 
> Okay so I take you point no problem, but I'm not running distro packages and I
> still want completions.  There must be a way to package the file to at least
> make it easier to achieve both our goals.
> 
> Right now I have to manually wget the file from git.o.o which isn't really 
> okay
> IMO.
> 
> Could the python package make /usr/share/doc/python-novaclient/tools and ship
> it there.  That would mean that distribution packaging could just take that 
> file
> and install it in the correct and usful location AND I could just symlink it
> and we both win.
> 
> Yours Tony.

The file has nothing to do in /usr/share/doc either. By per the debian
policy manual: we shouldn't rely on /usr/share/doc, as it can be removed
entirely by the users. /usr/share/python-novaclient could be a place,
but really, the correct location is
/usr/share/bash-completion/completions, not /etc (btw: that's a new
thing, it used to be in /etc, but there's now a lintian warning about it).

Cheers,

Thomas Goirand (zigo)


__
OpenStack Development Mailing List (not for 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] [openstack-operators][neutron[dhcp][dnsmask]: duplicate entries in addn_hosts causing no IP allocation

[Neil Jerram]

Hi Dani,

I think that would be fine, if it worked.  The  that you 
want is dnsmasq-base, I believe.


However, I would not expect it to work, on a Fuel 5.1 node, because I 
believe such nodes are set up to use the Fuel master as their package 
repository, and I don't think that a Fuel 5.1 master will have any newer 
dnsmasq packages that what you already have installed.


I hope that makes sense - happy to explain further if not.

Neil


On 01/07/15 10:24, Daniel Comnea wrote:

Neil, much thanks !!!

Any idea if i can go and only run apt-get --only-upgrade install
  or that will be too crazy?

Cheers,
Dani


On Wed, Jul 1, 2015 at 9:23 AM, Neil Jerram mailto:neil.jer...@metaswitch.com>> wrote:

Well, the bug discussion seems to point specifically to this dnsmasq
fix:


http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=9380ba70d67db6b69f817d8e318de5ba1e990b12

 Neil


On 01/07/15 07:34, Daniel Comnea wrote:

Hi,

sorry for no feedback, i've been doing more and more test and after
enabled the dnsmasq log i found the error which i'm not longer
sure if
is related to having duplicated entries

dnsmasq-dhcp[21231]: 0 DHCPRELEASE(tap8ecf66b6-72) 192.168.111.24
fa:16:3e:72:04:82 unknown lease

Looking around it seems i'm hitting this bug [1] but not clear
from the
description what was the problem on dnsmasp 2.59 (which comes
wiht Fuel 5.1)

Any ideas?

Cheers,
Dani

[1] https://bugs.launchpad.net/neutron/+bug/1271344

On Wed, Jun 10, 2015 at 7:13 AM, Daniel Comnea
mailto:comnea.d...@gmail.com>
>>
wrote:

 Thanks a bunch Kevin!

 I'll try this patch and report back.

 Dani


 On Tue, Jun 9, 2015 at 2:50 AM, Kevin Benton
mailto:blak...@gmail.com>
 >> wrote:

 Hi Daniel,

 I'm concerned that we are encountered out-of-order port
events
 on the DHCP agent side so the delete message is
processed before
 the create message. Would you be willing to apply a
small patch
 to your dhcp agent to see if it fixes the issue?

 If it does fix the issue, you should see occasional
warnings in
 the DHCP agent log that show "Received message for port
that was
 already deleted". If it doesn't fix the issue, we may
be losing
 the delete event entirely. If that's the case, it would
be great
 if you can enable debuging on the agent and upload a
log of a
 run when it happens.

 Cheers,
 Kevin Benton

 Here is the patch:

 diff --git a/neutron/agent/dhcp_agent.py
 b/neutron/agent/dhcp_agent.py
 index 71c9709..9b9b637 100644
 --- a/neutron/agent/dhcp_agent.py
 +++ b/neutron/agent/dhcp_agent.py
 @@ -71,6 +71,7 @@ class DhcpAgent(manager.Manager):
   self.needs_resync = False
   self.conf = cfg.CONF
   self.cache = NetworkCache()
 +self.deleted_ports = set()
   self.root_helper =
config.get_root_helper(self.conf)
   self.dhcp_driver_cls =
 importutils.import_class(self.conf.dhcp_driver)
   ctx = context.get_admin_context_without_session()
 @@ -151,6 +152,7 @@ class DhcpAgent(manager.Manager):
   LOG.info(_('Synchronizing state'))
   pool =
eventlet.GreenPool(cfg.CONF.num_sync_threads)
   known_network_ids =
set(self.cache.get_network_ids())
 +self.deleted_ports = set()

   try:
   active_networks =
 self.plugin_rpc.get_active_networks_info()
 @@ -302,6 +304,10 @@ class DhcpAgent(manager.Manager):
   @utils.synchronized('dhcp-agent')
   def port_update_end(self, context, payload):
   """Handle the port.update.end notification
event."""
 +if payload['port']['id'] in self.deleted_ports:
 +LOG.warning(_("Received message for port
that was "
 +  "already deleted: %s"),
 payload['port']['id'])
 +return
   updated_port = dhcp.DictModel(payload['port'])
   

[openstack-dev] [Security][VMT] Promoting Michael McCune and Travis McPeak to Security CoreSec

[Clark, Robert Graham]

With various +1's and no objections I'm pleased to announce that Michael and 
Travis are now added to the ossg-coresec team.

This team assists the VMT with vulnerability metrics, triage and of course 
OpenStack Security Notes.

Congratulations both!

-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] [Neutron] - breaking changes for plugins/drivers

[Kevin Benton]

>For the second one, I think we made it clear before that no plugins must
rely on neutron.openstack.* contents.

Where was this made clear? I didn't know about this until it broke and I'm
a very frequent contributor and reviewer, which is the core of my
complaint. The updated wiki is helpful, but doing it after-the-fact only
helps when people try to figure out why they can't make changes to their
repos.

In that patch there were 3 in-tree third party plugins that had to be
updated. That should have given a hint that it was likely to break other
plugins as well. The other annoying lesson from that is that
plugins/drivers still in tree are getting better treatment than the ones
that went through the split process.

We need to be much more diligent about announcing these things ahead of
time or we need to be clear that Neutron is completely unstable as a
framework and third party drivers should basically never import anything
from the neutron namespace.


On Tue, Jun 30, 2015 at 11:58 PM, Ihar Hrachyshka 
wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On 07/01/2015 08:22 AM, Kevin Benton wrote:
> > Hi,
> >
> > We have had at least two breaking changes merge this week for
> > out-of-tree drivers/plugins. These are just the two I noticed that
> > broke the Big Switch CI (the one I keep an eye on since I had set
> > it up):
> >
> > 1. Removed test_lib that changes config files.
> > https://review.openstack.org/#/c/196583/ 2. Removed the loopingcall
> > common util with no deprecation cycle or announcement.
> > https://review.openstack.org/#/c/192999/
> >
> > I proposed a revert for 1 that merged, but I don't particularly
> > want to keep fighting this. What is our current policy on this?
> > Just change whatever we want and tell plugin maintainers this is
> > just the way things work?
> >
>
> For the first one, the revert is justified.
>
> For the second one, I think we made it clear before that no plugins
> must rely on neutron.openstack.* contents.
>
> Now I've made it mentioned at:
> https://wiki.openstack.org/wiki/Neutron/LibraryAPIBreakage
>
> If your plugin is using any of neutron.openstack.* contents, just stop
> doing it. It's going to break.
>
> Ihar
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2
>
> iQEcBAEBCAAGBQJVk4+AAAoJEC5aWaUY1u57OE8IAKDqKudi5zOUxRPc4Elzsdw4
> mASF5Mtguj5q9OUpYIyeOkbsIKmOwop4tbGjz52L+OZ8aLq1XptpKLUuX6mBL3lS
> m0/DtD2RlBRTmiO/kyBxeqJbsj7nZU9eoiDJ88gN51IetN1kIR09rAbmdkoduhK2
> FIrFLJhhuVqmb8S377cbSgJ46kC1DeDa2xhtFWB39iIKO3ZTwO7ia5KRipTSTyNV
> 4ngB0+d8EgMfmsKj4Bd7/btkg5rI+o4qNgd4L1Ncd1BQzPiOzzeeGo0lAe86Kf7z
> KUH2Sw6n6mIUZJSGzDP4cigGqSsilBaurryK90G/Go1q7BEMRFVyrGHObnMBZTw=
> =qSnW
> -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
>



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

Re: [openstack-dev] [Ironic] [Inspector] Addition to ironic-inspector-core, switching to 2x +2 rule

[Yuiko Takada]

Thanks for all the support!!
I will do my best to meet the expectations of you.
Let's make Ironic Inspector better and better together.

As our core team grows, I'd like us to try to stick with 2x +2 rules. Up to
> now it was mostly "Dmitry approves everything" rule, now let us make sure
> we have at least 2 +2 on a patch before merging it, unless it's critical
> for release or fixing gate. Don't wait for me to W+1 if you see that patch
> already has 2x +2.
>
> I'd ask the core team to review all the incoming patches. Once our
> devstack gate is finally working, review will be a lot easier.

Nice :) +2!


Best Regards,
Yuiko Takada


2015-07-01 17:56 GMT+09:00 Dmitry Tantsur :

> Hi all!
>
> Please welcome Yuiko Takada to ironic-inspector-core team. Yuiko has been
> with the team for some time already. She did substantial work on porting
> ironic-inspector to Oslo libraries and on our new devstack gate job.
>
> Thanks Yuiko, it's a pleasure to work with you.
>
> As our core team grows, I'd like us to try to stick with 2x +2 rules. Up
> to now it was mostly "Dmitry approves everything" rule, now let us make
> sure we have at least 2 +2 on a patch before merging it, unless it's
> critical for release or fixing gate. Don't wait for me to W+1 if you see
> that patch already has 2x +2.
>
> I'd ask the core team to review all the incoming patches. Once our
> devstack gate is finally working, review will be a lot easier.
>
> Cheers,
> Dmitry
>
> __
> OpenStack Development Mailing 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] Network issue with libvirt-xen driver, iptables race

[Bob Ball]

Hi Anthony,

> The Xen script is simply calling those commands:
> ...
>   iptables -I FORWARD -m physdev --physdev-is-bridged --physdev-in "$dev"
> -j ACCEPT
>   iptables -I FORWARD -m physdev --physdev-is-bridged --physdev-out
> "$dev" -j ACCEPT

Are you saying that these two commands aren't needed to be called by Xen in the 
OpenStack case because, for example, forwarding is set up by nova-network?

> It is possible to have Nova asking to run a different script that would not
> call iptables. But that script would need to be store somewhere, in the
> nova repo would be best.

Did you mean for Xen to be calling the different script, rather than Nova?  If 
Nova is calling it then the obvious place is in the Nova repo.

If it's a script that Xen needs to call then I would suggest it went to the 
contrib/xen directory.  There already appears to be a vif-script there which 
was implemented for Neutron, does that do what's needed here?

> Is `iptables` call necessary for the vif with OpenStack?

Pass on that one - someone who knows libvirt might know if libvirt does 
everything that's needed in the Xen case or if there are kvm specific scripts.

> If so, can nova-network do the update? Or the script called by the Xen
> toolstack could take an OpenStack lock before calling iptables?

I'd hope that it's not necessary for the Xen script to invoke iptables; the 
idea of having the two processes working with the same lock for iptables sounds 
nasty (e.g. it might make it harder to know which process is holding on to the 
lock in the case of a bug).  If this really is needed perhaps Nova should be 
calling the iptables commands after setting up the VIF?  This way it's just 
Nova that's in control of the lock.

Bob

__
OpenStack Development Mailing List (not for 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] [openstack-operators][neutron[dhcp][dnsmask]: duplicate entries in addn_hosts causing no IP allocation

[Daniel Comnea]

Neil, much thanks !!!

Any idea if i can go and only run apt-get --only-upgrade install
  or that will be too crazy?

Cheers,
Dani


On Wed, Jul 1, 2015 at 9:23 AM, Neil Jerram 
wrote:

> Well, the bug discussion seems to point specifically to this dnsmasq fix:
>
>
> http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=9380ba70d67db6b69f817d8e318de5ba1e990b12
>
> Neil
>
>
> On 01/07/15 07:34, Daniel Comnea wrote:
>
>> Hi,
>>
>> sorry for no feedback, i've been doing more and more test and after
>> enabled the dnsmasq log i found the error which i'm not longer sure if
>> is related to having duplicated entries
>>
>> dnsmasq-dhcp[21231]: 0 DHCPRELEASE(tap8ecf66b6-72) 192.168.111.24
>> fa:16:3e:72:04:82 unknown lease
>>
>> Looking around it seems i'm hitting this bug [1] but not clear from the
>> description what was the problem on dnsmasp 2.59 (which comes wiht Fuel
>> 5.1)
>>
>> Any ideas?
>>
>> Cheers,
>> Dani
>>
>> [1] https://bugs.launchpad.net/neutron/+bug/1271344
>>
>> On Wed, Jun 10, 2015 at 7:13 AM, Daniel Comnea > > wrote:
>>
>> Thanks a bunch Kevin!
>>
>> I'll try this patch and report back.
>>
>> Dani
>>
>>
>> On Tue, Jun 9, 2015 at 2:50 AM, Kevin Benton > > wrote:
>>
>> Hi Daniel,
>>
>> I'm concerned that we are encountered out-of-order port events
>> on the DHCP agent side so the delete message is processed before
>> the create message. Would you be willing to apply a small patch
>> to your dhcp agent to see if it fixes the issue?
>>
>> If it does fix the issue, you should see occasional warnings in
>> the DHCP agent log that show "Received message for port that was
>> already deleted". If it doesn't fix the issue, we may be losing
>> the delete event entirely. If that's the case, it would be great
>> if you can enable debuging on the agent and upload a log of a
>> run when it happens.
>>
>> Cheers,
>> Kevin Benton
>>
>> Here is the patch:
>>
>> diff --git a/neutron/agent/dhcp_agent.py
>> b/neutron/agent/dhcp_agent.py
>> index 71c9709..9b9b637 100644
>> --- a/neutron/agent/dhcp_agent.py
>> +++ b/neutron/agent/dhcp_agent.py
>> @@ -71,6 +71,7 @@ class DhcpAgent(manager.Manager):
>>   self.needs_resync = False
>>   self.conf = cfg.CONF
>>   self.cache = NetworkCache()
>> +self.deleted_ports = set()
>>   self.root_helper = config.get_root_helper(self.conf)
>>   self.dhcp_driver_cls =
>> importutils.import_class(self.conf.dhcp_driver)
>>   ctx = context.get_admin_context_without_session()
>> @@ -151,6 +152,7 @@ class DhcpAgent(manager.Manager):
>>   LOG.info(_('Synchronizing state'))
>>   pool = eventlet.GreenPool(cfg.CONF.num_sync_threads)
>>   known_network_ids = set(self.cache.get_network_ids())
>> +self.deleted_ports = set()
>>
>>   try:
>>   active_networks =
>> self.plugin_rpc.get_active_networks_info()
>> @@ -302,6 +304,10 @@ class DhcpAgent(manager.Manager):
>>   @utils.synchronized('dhcp-agent')
>>   def port_update_end(self, context, payload):
>>   """Handle the port.update.end notification event."""
>> +if payload['port']['id'] in self.deleted_ports:
>> +LOG.warning(_("Received message for port that was "
>> +  "already deleted: %s"),
>> payload['port']['id'])
>> +return
>>   updated_port = dhcp.DictModel(payload['port'])
>>   network =
>> self.cache.get_network_by_id(updated_port.network_id)
>>   if network:
>> @@ -315,6 +321,7 @@ class DhcpAgent(manager.Manager):
>>   def port_delete_end(self, context, payload):
>>   """Handle the port.delete.end notification event."""
>>   port = self.cache.get_port_by_id(payload['port_id'])
>> +self.deleted_ports.add(payload['port_id'])
>>   if port:
>>   network =
>> self.cache.get_network_by_id(port.network_id)
>>   self.cache.remove_port(port)
>>
>>
>>
>>
>>
>>
>>
>>
>> On Mon, Jun 8, 2015 at 8:26 AM, Daniel Comnea
>> mailto:comnea.d...@gmail.com>> wrote:
>>
>> Any help, ideas please?
>>
>> Thx,
>> Dani
>>
>> On Mon, Jun 8, 2015 at 9:25 AM, Daniel Comnea
>> mailto:comnea.d...@gmail.com>> wrote:
>>
>> + Operators
>>
>> Much thanks in advance,
>> Dani
>>
>>
>>
>>
>> On Sun, Jun 7, 2015 at 6:31 PM, Daniel Comnea
>

Re: [openstack-dev] [Ironic] [Inspector] Addition to ironic-inspector-core, switching to 2x +2 rule

[Imre Farkas]

On 07/01/2015 10:56 AM, Dmitry Tantsur wrote:

Hi all!

Please welcome Yuiko Takada to ironic-inspector-core team. Yuiko has
been with the team for some time already. She did substantial work on
porting ironic-inspector to Oslo libraries and on our new devstack gate
job.

Thanks Yuiko, it's a pleasure to work with you.


Congrats Yuiko, that is very well deserved!



As our core team grows, I'd like us to try to stick with 2x +2 rules. Up
to now it was mostly "Dmitry approves everything" rule, now let us make
sure we have at least 2 +2 on a patch before merging it, unless it's
critical for release or fixing gate. Don't wait for me to W+1 if you see
that patch already has 2x +2.

I'd ask the core team to review all the incoming patches. Once our
devstack gate is finally working, review will be a lot easier.


+1

Imre

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

Re: [openstack-dev] [Ironic] [Inspector] Addition to ironic-inspector-core, switching to 2x +2 rule

[Lucas Alvares Gomes]

Hi,

>
> Please welcome Yuiko Takada to ironic-inspector-core team. Yuiko has been
> with the team for some time already. She did substantial work on porting
> ironic-inspector to Oslo libraries and on our new devstack gate job.
>

Congratulations, well deserved!

__
OpenStack Development Mailing 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] [Ironic] [Inspector] Addition to ironic-inspector-core, switching to 2x +2 rule

[Dmitry Tantsur]

Hi all!

Please welcome Yuiko Takada to ironic-inspector-core team. Yuiko has 
been with the team for some time already. She did substantial work on 
porting ironic-inspector to Oslo libraries and on our new devstack gate job.


Thanks Yuiko, it's a pleasure to work with you.

As our core team grows, I'd like us to try to stick with 2x +2 rules. Up 
to now it was mostly "Dmitry approves everything" rule, now let us make 
sure we have at least 2 +2 on a patch before merging it, unless it's 
critical for release or fixing gate. Don't wait for me to W+1 if you see 
that patch already has 2x +2.


I'd ask the core team to review all the incoming patches. Once our 
devstack gate is finally working, review will be a lot easier.


Cheers,
Dmitry

__
OpenStack Development Mailing 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][Plugins] Task priority in post deployment

[loic.nicolle]

Hi,

I'm wondering if it's possible to create a plugin which do some actions before 
the upload of TestVM image ? but after openstack deployment.

In my case I have done a plugin which change glance backend, but TestVM image 
was upload before on the default backend (swift) so I can't use it after.

My task priority (at plugin level) is :

  stage: post_deployment/2000

I also try to change priority to lower level (eg : 700)

Regards,

Loic



_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

__
OpenStack Development Mailing 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] [stable] Future stable branch point releases

[Thierry Carrez]

Hi everyone,

Following the discussion on the idea of abandoning synchronized,
time-based stable branch point releases (which got nice coverage at
http://lwn.net/Articles/647638/), here is the plan the stable
maintenance team came up with:


1. We'll continue doing point releases for Juno and Kilo stable branches

The stable/juno and stable/kilo branches of the projects that were part
of the Juno and Kilo "integrated release" will still be tagged the old
way (synchronized time-based tagging over a closed set of projects) over
the coming year. The proposed schedule is as follows:

Juno 2014.2.3  (was done June 19 by apevec)
Kilo 2015.1.1  early July, 2015, release manager: apevec
Kilo 2015.1.2  mid-September, 2015, release manager: zulcss
Juno 2014.2.4  (eol) early November, 2015. release manager: apevec
Kilo 2015.1.3  (eol) end of January, 2016, release manager: Daviey


2. Enable continuous stable branch delivery during this cycle

Over the coming months, we'll formalize how to generate .Z increments to
the X.Y.Z liberty-style version for every commit to the future
stable/liberty branches. This will result in every commit to every
stable branch to be micro-released.

We'll also set up a way to dynamically generate release notes from the
content of the branch, likely by storing release note snippets in the
branch itself.


3. Switch to .Z micro-releases starting with stable/liberty

Assuming the tooling is ready, we'll switch to micro-releasing when we
open the stable branch to stable maintenance after the Liberty final
release date on October 15.


Cheers,

-- 
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] [Openstack-operators] [openstack-operators][neutron[dhcp][dnsmask]: duplicate entries in addn_hosts causing no IP allocation

[Neil Jerram]

Well, the bug discussion seems to point specifically to this dnsmasq fix:

http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=9380ba70d67db6b69f817d8e318de5ba1e990b12

Neil


On 01/07/15 07:34, Daniel Comnea wrote:

Hi,

sorry for no feedback, i've been doing more and more test and after
enabled the dnsmasq log i found the error which i'm not longer sure if
is related to having duplicated entries

dnsmasq-dhcp[21231]: 0 DHCPRELEASE(tap8ecf66b6-72) 192.168.111.24
fa:16:3e:72:04:82 unknown lease

Looking around it seems i'm hitting this bug [1] but not clear from the
description what was the problem on dnsmasp 2.59 (which comes wiht Fuel 5.1)

Any ideas?

Cheers,
Dani

[1] https://bugs.launchpad.net/neutron/+bug/1271344

On Wed, Jun 10, 2015 at 7:13 AM, Daniel Comnea mailto:comnea.d...@gmail.com>> wrote:

Thanks a bunch Kevin!

I'll try this patch and report back.

Dani


On Tue, Jun 9, 2015 at 2:50 AM, Kevin Benton mailto:blak...@gmail.com>> wrote:

Hi Daniel,

I'm concerned that we are encountered out-of-order port events
on the DHCP agent side so the delete message is processed before
the create message. Would you be willing to apply a small patch
to your dhcp agent to see if it fixes the issue?

If it does fix the issue, you should see occasional warnings in
the DHCP agent log that show "Received message for port that was
already deleted". If it doesn't fix the issue, we may be losing
the delete event entirely. If that's the case, it would be great
if you can enable debuging on the agent and upload a log of a
run when it happens.

Cheers,
Kevin Benton

Here is the patch:

diff --git a/neutron/agent/dhcp_agent.py
b/neutron/agent/dhcp_agent.py
index 71c9709..9b9b637 100644
--- a/neutron/agent/dhcp_agent.py
+++ b/neutron/agent/dhcp_agent.py
@@ -71,6 +71,7 @@ class DhcpAgent(manager.Manager):
  self.needs_resync = False
  self.conf = cfg.CONF
  self.cache = NetworkCache()
+self.deleted_ports = set()
  self.root_helper = config.get_root_helper(self.conf)
  self.dhcp_driver_cls =
importutils.import_class(self.conf.dhcp_driver)
  ctx = context.get_admin_context_without_session()
@@ -151,6 +152,7 @@ class DhcpAgent(manager.Manager):
  LOG.info(_('Synchronizing state'))
  pool = eventlet.GreenPool(cfg.CONF.num_sync_threads)
  known_network_ids = set(self.cache.get_network_ids())
+self.deleted_ports = set()

  try:
  active_networks =
self.plugin_rpc.get_active_networks_info()
@@ -302,6 +304,10 @@ class DhcpAgent(manager.Manager):
  @utils.synchronized('dhcp-agent')
  def port_update_end(self, context, payload):
  """Handle the port.update.end notification event."""
+if payload['port']['id'] in self.deleted_ports:
+LOG.warning(_("Received message for port that was "
+  "already deleted: %s"),
payload['port']['id'])
+return
  updated_port = dhcp.DictModel(payload['port'])
  network =
self.cache.get_network_by_id(updated_port.network_id)
  if network:
@@ -315,6 +321,7 @@ class DhcpAgent(manager.Manager):
  def port_delete_end(self, context, payload):
  """Handle the port.delete.end notification event."""
  port = self.cache.get_port_by_id(payload['port_id'])
+self.deleted_ports.add(payload['port_id'])
  if port:
  network =
self.cache.get_network_by_id(port.network_id)
  self.cache.remove_port(port)








On Mon, Jun 8, 2015 at 8:26 AM, Daniel Comnea
mailto:comnea.d...@gmail.com>> wrote:

Any help, ideas please?

Thx,
Dani

On Mon, Jun 8, 2015 at 9:25 AM, Daniel Comnea
mailto:comnea.d...@gmail.com>> wrote:

+ Operators

Much thanks in advance,
Dani




On Sun, Jun 7, 2015 at 6:31 PM, Daniel Comnea
mailto:comnea.d...@gmail.com>>
wrote:

Hi all,

I'm running IceHouse (build using Fuel 5.1.1) on
Ubuntu where dnsmask version 2.59-4.
I have a very basic network layout where i have a
private net which has 2 subnets

  2fb7de9d-d6df-481f-acca-2f7860cffa60 |
private-net   |
e79c3477-d3e5-471c-a728-8d881cf31bee
 

Re: [openstack-dev] Magnum Midcycle Event Scheduling Doodle Poll closes July 7th

[Thierry Carrez]

Steven Dake (stdake) wrote:
> Ton Ngo of IBM Silicon Valley Research has graciously offered to host
> the 2 day Magnum midcycle event at IBM’s facilities.
> 
> The sessions will run from 9AM – 5PM and catered lunch and refreshments
> (soda/water) will be provided. 
> 
> The mid-cycle will be a standard mid-cycle with a 1 hour introduction
> followed by two days of design sessions.
> 
> Please cast your votes on any days you can make.
> 
> http://doodle.com/pinkuc5hw688zhxw
> 
> There are ~25 seats available.  Preference will be given to in-person
> core reviewers, followed by any folks that have made commits to the
> repository.  After dates are settled, a separate eventbrite event will
> be setup to sort out the specifics such as  dietary needs, etc and
> confirm in-person seating if we are past capacity limits.

Please add it to https://wiki.openstack.org/wiki/Sprints when the date
is set.

-- 
Thierry Carrez (ttx)

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

Re: [openstack-dev] [Glance] Liberty mid-cycle meetup.

[Thierry Carrez]

Nikhil Komawar wrote:
> As discussed in the earlier Glance weekly meeting, the mid-cycle meetup
> for Glance would be at Blacksburg, VA from July 28-July30. A tentative
> schedule and some details have been put in the etherpad. Please fill in
> your details in the survey and the etherpad so as to help the site
> manager handle surrounding details.
> 
> https://etherpad.openstack.org/p/liberty-glance-mid-cycle-meetup

Please add it to https://wiki.openstack.org/wiki/Sprints !
(starting to feel like a bot)

-- 
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] [kolla] Kolla-Palooza mid-cycle dates - July 28th, July 29th! - Please mark your calendars!

[Thierry Carrez]

Steven Dake (stdake) wrote:
> The dates for the Kolla midcycle have been confirmed for July 28th and
> July 29th.  Coffee/Tea will be provided in the mornings, and catered
> lunch will be provided with soda or water both days.  A dinner will be
> held July 28th.  Since budget is really tight for most folks because of
> a desire to send Engineers to Tokyo for ODS, and the associated costs of
> Tokyo travel, if you can’t make the Kolla midcycle event in person
> because of travel costs, we will also have remote participation available.

Please add it to https://wiki.openstack.org/wiki/Sprints !

-- 
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] [devstack] Use devstack/master to install older releases

[Jordan Pittier]

Hi,

On Wed, Jul 1, 2015 at 12:35 AM, Dean Troyer  wrote:

> On Tue, Jun 30, 2015 at 7:04 AM, Emmanuel Cazenave 
> wrote:
>
>> My first approach was to use devstack/icehouse to install swift/icehouse,
>> devstack/juno for swift/juno, etc
>>
>
> This is the only approach that is sane...
>
>
>> I am now trying to use devstack/master in every cases because I need this
>> : https://review.openstack.org/#/c/115307/ which allow not to install
>> nova+glance which I don't need at all, and whose installation takes a
>> really long time.
>>
>
> We would probably consider a backport of that to DevStack Juno, but
> Icehouse is effectively EOL and we will be removing that branch soon (days
> or weeks, not months).
>
I've proposed https://review.openstack.org/#/c/197464/ to backport that
patch to Juno.

>
>
>> Is my use case of installing older releases with devstack/master not
>> supported ?
>>
>
> No.  Even on master you may have issues trying to run a early cycle
> project with a late-cycle DevStack.  DevStack evolves to meet the needs of
> the projects as they develop.
>
> That Tempest fix is pretty straightforward, with only the one code block
> move not being a "skip this if project is not enabled" check.  With
> Icehouse EOL, there will be no additional updates so maintaining that
> backport in a local private branch should not be a big deal.  You will need
> that anyway to keep using icehouse after we remove that branch from the
> DevStack repo.
>
> dt
>
> --
>
> Dean Troyer
> dtro...@gmail.com
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Glance] Liberty mid-cycle meetup.

[Flavio Percoco]

On 01/07/15 00:19 -0400, Nikhil Komawar wrote:

Hi all,

As discussed in the earlier Glance weekly meeting, the mid-cycle meetup for
Glance would be at Blacksburg, VA from July 28-July30. A tentative schedule and
some details have been put in the etherpad. Please fill in your details in the
survey and the etherpad so as to help the site manager handle surrounding
details.

https://etherpad.openstack.org/p/liberty-glance-mid-cycle-meetup


Hey Nikhil,

Thanks for pulling this together. I, unfortunately, won't be able to
attend but I'll try to participate on-line to some of these sessions.

I'd like to take this opportunity to ask all attendees of this
mid-cycle to provide as much information as possible about the things
discussed during this 3 days so that other folks that weren't able to
attend will be able to provide feedback and get up to speed.

Cheers,
Flavio

--
@flaper87
Flavio Percoco


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

[openstack-dev] [kolla] Kolla-Palooza mid-cycle dates - July 28th, July 29th! - Please mark your calendars!

[Steven Dake (stdake)]

Hey folks,

The dates for the Kolla midcycle have been confirmed for July 28th and July 
29th.  Coffee/Tea will be provided in the mornings, and catered lunch will be 
provided with soda or water both days.  A dinner will be held July 28th.  Since 
budget is really tight for most folks because of a desire to send Engineers to 
Tokyo for ODS, and the associated costs of Tokyo travel, if you can’t make the 
Kolla midcycle event in person because of travel costs, we will also have 
remote participation available.

Remote participation may be a suboptimal experience compared to in-person, but 
is better then not attending at all, especially for the core reviewers and 
developers of the project.

I will set up an eventbrite invitation in the morning.  I’d ask folks quickly 
as possible sign up for the event that plan to attend and provide requested 
information.  I would have just tackled the eventbrite scheduling tonight and 
sent this announcement after, but I suspect it may take some time to sort out 
how precisely to get an event set  up in eventbrite and wanted to be fresh when 
I did the job ;)

Regards
-steve

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

Re: [openstack-dev] [Neutron] - breaking changes for plugins/drivers

[Ihar Hrachyshka]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 07/01/2015 08:22 AM, Kevin Benton wrote:
> Hi,
> 
> We have had at least two breaking changes merge this week for 
> out-of-tree drivers/plugins. These are just the two I noticed that
> broke the Big Switch CI (the one I keep an eye on since I had set
> it up):
> 
> 1. Removed test_lib that changes config files.
> https://review.openstack.org/#/c/196583/ 2. Removed the loopingcall
> common util with no deprecation cycle or announcement.
> https://review.openstack.org/#/c/192999/
> 
> I proposed a revert for 1 that merged, but I don't particularly
> want to keep fighting this. What is our current policy on this?
> Just change whatever we want and tell plugin maintainers this is
> just the way things work?
> 

For the first one, the revert is justified.

For the second one, I think we made it clear before that no plugins
must rely on neutron.openstack.* contents.

Now I've made it mentioned at:
https://wiki.openstack.org/wiki/Neutron/LibraryAPIBreakage

If your plugin is using any of neutron.openstack.* contents, just stop
doing it. It's going to break.

Ihar
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJVk4+AAAoJEC5aWaUY1u57OE8IAKDqKudi5zOUxRPc4Elzsdw4
mASF5Mtguj5q9OUpYIyeOkbsIKmOwop4tbGjz52L+OZ8aLq1XptpKLUuX6mBL3lS
m0/DtD2RlBRTmiO/kyBxeqJbsj7nZU9eoiDJ88gN51IetN1kIR09rAbmdkoduhK2
FIrFLJhhuVqmb8S377cbSgJ46kC1DeDa2xhtFWB39iIKO3ZTwO7ia5KRipTSTyNV
4ngB0+d8EgMfmsKj4Bd7/btkg5rI+o4qNgd4L1Ncd1BQzPiOzzeeGo0lAe86Kf7z
KUH2Sw6n6mIUZJSGzDP4cigGqSsilBaurryK90G/Go1q7BEMRFVyrGHObnMBZTw=
=qSnW
-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