Re: [openstack-dev] [fuel][plugins] Should we maintain example plugins?

[Matthew Mosesohn]

Mike,

#1 - If you truly agree with that, you should weigh in here:
https://review.openstack.org/#/c/287286/
#2 - Requires a blueprint and new docs, but okay.
#3 - Yes! We have very poor CI for fuel plugin builder. All it does is
ensure it makes a plugin, not that it can be installed and deployed.

On Thu, Mar 10, 2016 at 10:44 AM, Mike Scherbakov
 wrote:
> Folks,
> here is what I think:
> 1) I suggest to fix what is broken now. So that people who come across
> examples would not have to deal with issues. We may debate for other few
> days (hopefully not more), and all plugin devs will be suffering during this
> time. Also, according to Matt,
>
>> I should add that this is the only automated daily test that will verify
> that our plugin framework actually works.
> simply means that we must fix it in order to catch any possible regressions
> we may introduce later (if not already).
>
> 2) I like idea Ilya K. has proposed. To rephrase it (to put extra accent
> into it and get feedback), we may not need to have example plugins. However,
> we can have fpb generating template plugin, with commented code in there. If
> you uncomment, you a get a comprehensive example of a working plugin.
> To ensure that uncommented code would actually work, we must have a test for
> it (which would uncomment - run - ensure everything deploys).
>
> 3) Ideally, we need to catch issues at pre-commit stage. So I'd suggest to
> think if there is a way to have tests, which would run such examples against
> pluggable framework for every change to the framework, so that we can have
> -1 right away if something goes wrong.
>
> I've started separate thread on general thoughts about backward
> compatibility and multiple releases support, which actually affects
> examples: [1]
> http://lists.openstack.org/pipermail/openstack-dev/2016-March/088921.html
>
> Thanks,
>
> On Wed, Mar 9, 2016 at 7:59 AM Evgeniy L  wrote:
>>
>> Because it doesn't make much sense for a plugin developer to have scripts
>> to build packages for installation on slave nodes. For default template it's
>> better to have something minimalistic and the rest of the tasks commented,
>> otherwise it may create a lot of confusion.
>>
>> On Wed, Mar 9, 2016 at 6:37 PM, Ilya Kutukov 
>> wrote:
>>>
>>> Talking about templates I mean plugins generated by FBP from the
>>> `templates` folder using command you mentioned above.
>>>
>>> Why not to extend (not replace) template-generated plugins with
>>> additional data to provide right coverage?
>>>
>>> On Wed, Mar 9, 2016 at 6:23 PM, Evgeniy L  wrote:

 Ilya,

 What do you mean by "templates" the plugin which is create by just "fpb
 --create plugin-name"?
 It doesn't cover enough, package installation and all range of tasks
 executions.

 Thanks,

 On Wed, Mar 9, 2016 at 6:16 PM, Ilya Kutukov 
 wrote:
>
> Igor, i completely agree, actually plugin examples is almost a
> copy-paste.
>
> The only thing i see useful in the built plugins example is the ability
> to point some code lines, discussing plugin design and writing
> documentation. Why not to generate this examples automatically from
> templates?
>
> Also, as developer and administrator i love to use examples/templates
> where all essential settings and options are persist but commented (e.g.
> ProFTPD or Apache) and i could uncomment and copy-paste them not being
> afraid of typos. Also it allows to keep documentation actual and head
> documentation small. Duplication of inline documentation between examples
> and templates making things more weird and overshadows idea of inline
> documentation itself.
>
> Eugeny, why not to run integration tests against plugins generated from
> templates? It's will be even better integration tests.
>
>
>
> On Mon, Mar 7, 2016 at 4:49 PM, Igor Kalnitsky
>  wrote:
>>
>> > and really lowering barriers for people who just begin create
>> > plugins.
>>
>> Nonsense. First, people usually create them via running `fpb --create
>> plugin-name` that generates plugin boilerplate. And that boilerplate
>> won't contain that changes.
>>
>> Second, if people ain't smart enough to change few lines in
>> `metadata.yaml` of generated boilerplate to make it work with latest
>> Fuel, maybe it's better for them to do not develop plugins at all?
>>
>> On Fri, Mar 4, 2016 at 2:24 PM, Stanislaw Bogatkin
>>  wrote:
>> > +1 to maintain example plugins. It is easy enough and really
>> > lowering
>> > barriers for people who just begin create plugins.
>> >
>> > On Fri, Mar 4, 2016 at 2:08 PM, Matthew Mosesohn
>> > 
>> > wrote:
>> >>
>> >> Igor,
>> >>

Re: [openstack-dev] [Fuel] Compatibility of fuel plugins and fuel versions

[Matthew Mosesohn]

Hi Mike,

Normally I would support your idea, but the reality is any plugin from
7.0 that defines a plugin role isn't going to work in 8.0 or 9.0. We
changed too many task names and you just can't make a plugin support
both versions not without something incredibly clever that I
haven't thought of already. If I'm a plugin developer, I'm not going
to advertise support for versions that won't work or expect it to
work when I haven't stated it explicitly.

The example plugins are quite simple and have no real tasks, so
enabling this for plugins is ok.  For real plugins that do more then
install 1 package and enable 1 service, version limiting is the only
thing to keep your users from losing their hair trying to figure out
why it doesn't work.

Best Regards,
Matthew Mosesohn

On Thu, Mar 10, 2016 at 10:30 AM, Mike Scherbakov
 wrote:
> Hi folks,
> in order to make a decision whether we need to support example plugins, and
> if actually need them [1], I'd suggest to discuss more common things about
> plugins.
>
> My thoughts:
> 1) This is not good, that our plugins created for Fuel 8 won't even install
> on Fuel 9. By default, we should assume that plugin will work at newer
> version of Fuel. However, for proper user experience, I suggest to create
> meta-field "validated_against", where plugin dev would provide versions of
> Fuel this plugin has been tested with. Let's say, it was tested against 7.0,
> 8.0. If user installs plugin in Fuel 9, I'd suggest to show a warning saying
> about risks and the fact that the plugin has not been tested against 9. We
> should not restrict intsallation against 9, though.
>
> 2) We need to keep backward compatibility of pluggable interface for a few
> releases. So that plugin developer can use pluggable interface of version x,
> which was supported in Fuel 6.1. If we still support it, it would mean (see
> next point) compatibility of this plugin with 6.1, 7.0, 8.0, 9.0. If we want
> to deprecate pluggable interface version, we should announce it, and
> basically follow standard process of deprecation.
>
> 3) Plugin's ability to work against multiple releases of Fuel (multi-release
> support). If if..else clauses to support multiple releases are fairly
> minimal, let's say take less that 10% of LOC, I'd suggest to have this
> supported. Just because it will be easier for plugin devs to support their
> plugin code (no code duplication, single repo for multiple releases).
>
> Thoughts?
>
> [1]
> http://lists.openstack.org/pipermail/openstack-dev/2016-March/088211.html
> --
> 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 Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Horizon] How do we move forward with xstatic releases?

[Richard Jones]

On 10 March 2016 at 18:23, Matthias Runge  wrote:
>
> 4.alt.2:
> move to proper packages for static file management. I mean, they need to
> be built anyways.
>

Please define what you mean by "proper packages" here. I *think* you might
mean system packages (aka Debian or Red Hat) which is not feasible given
other environments that Horizon runs under. Please correct me if I'm wrong!



> It has been mentioned, xstatic packages can block the gate. We currently
> control xstatic package releases, thus we can roll back, if something
> goes wrong.
>
> If we're pulling directly with npm/bower, someone from the outside can
> break us. We already have the situation with pypi packages.
> With proper packages, we could even use the gate to release those
> packages and thus verify, we're not breaking anyone.
>

We're going to have potential breakage (gate breakage, in the integrated
tests) any time we release a package (regardless of release mechanism) and
have to update two separate repositories resulting in out-of-sync version
specification and expectation (ie. upper-constraints specification and
Horizon's code expectation) as described in my OP. The only solution that
we're aware of is to synchronise updating those two things, through one of
the mechanisms proposed so far (or possibly through a mechanism not yet
proposed.)


I think that David's proposal is the only really feasible approach at this
time:

1. Horizon maintains its own constrained version list for the xstatic
packages,
2. Plugins to Horizon must depend on Horizon to supply xstatic packages
except where they use additional packages that Horizon does not use, and
3. We avoid installing app-catalog (the system, not the plugin) in the
integrated tests (I don't believe doing this is even on the ... "horizon"
so to speak) *or* in a Debian / Red Hat (i.e. system-packaged) system that
also has Horizon installed. Or we try to convince app-catalog to stay
lock-step with Horizon's xstatic versions. I understand the risk of a
collision between app-catalog and Horizon in the same system-packaged
environment is very low.


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

Re: [openstack-dev] [fuel][plugins] Should we maintain example plugins?

[Mike Scherbakov]

Folks,
here is what I think:
1) I suggest to fix what is broken now. So that people who come across
examples would not have to deal with issues. We may debate for other few
days (hopefully not more), and all plugin devs will be suffering during
this time. Also, according to Matt,

> I should add that this is the only automated daily test that will verify
that our plugin framework actually works.
simply means that we must fix it in order to catch any possible regressions
we may introduce later (if not already).

2) I like idea Ilya K. has proposed. To rephrase it (to put extra accent
into it and get feedback), we may not need to have example plugins.
However, we can have fpb generating template plugin, with commented code in
there. If you uncomment, you a get a comprehensive example of a working
plugin.
To ensure that uncommented code would actually work, we must have a test
for it (which would uncomment - run - ensure everything deploys).

3) Ideally, we need to catch issues at pre-commit stage. So I'd suggest to
think if there is a way to have tests, which would run such examples
against pluggable framework for every change to the framework, so that we
can have -1 right away if something goes wrong.

I've started separate thread on general thoughts about backward
compatibility and multiple releases support, which actually affects
examples: [1]
http://lists.openstack.org/pipermail/openstack-dev/2016-March/088921.html

Thanks,

On Wed, Mar 9, 2016 at 7:59 AM Evgeniy L  wrote:

> Because it doesn't make much sense for a plugin developer to have scripts
> to build packages for installation on slave nodes. For default template
> it's better to have something minimalistic and the rest of the tasks
> commented, otherwise it may create a lot of confusion.
>
> On Wed, Mar 9, 2016 at 6:37 PM, Ilya Kutukov 
> wrote:
>
>> Talking about templates I mean plugins generated by FBP from the
>> `templates` folder using command you mentioned above.
>>
>> Why not to extend (not replace) template-generated plugins with
>> additional data to provide right coverage?
>>
>> On Wed, Mar 9, 2016 at 6:23 PM, Evgeniy L  wrote:
>>
>>> Ilya,
>>>
>>> What do you mean by "templates" the plugin which is create by just "fpb
>>> --create plugin-name"?
>>> It doesn't cover enough, package installation and all range of tasks
>>> executions.
>>>
>>> Thanks,
>>>
>>> On Wed, Mar 9, 2016 at 6:16 PM, Ilya Kutukov 
>>> wrote:
>>>
 Igor, i completely agree, actually plugin examples is almost a
 copy-paste.

 The only thing i see useful in the built plugins example is the ability
 to point some code lines, discussing plugin design and writing
 documentation. Why not to generate this examples automatically from
 templates?

 Also, as developer and administrator i love to use examples/templates
 where all essential settings and options are persist but commented (e.g.
 ProFTPD or Apache) and i could uncomment and copy-paste them not being
 afraid of typos. Also it allows to keep documentation actual and head
 documentation small. Duplication of inline documentation between examples
 and templates making things more weird and overshadows idea of inline
 documentation itself.

 Eugeny, why not to run integration tests against plugins generated from
 templates? It's will be even better integration tests.



 On Mon, Mar 7, 2016 at 4:49 PM, Igor Kalnitsky  wrote:

> > and really lowering barriers for people who just begin create
> plugins.
>
> Nonsense. First, people usually create them via running `fpb --create
> plugin-name` that generates plugin boilerplate. And that boilerplate
> won't contain that changes.
>
> Second, if people ain't smart enough to change few lines in
> `metadata.yaml` of generated boilerplate to make it work with latest
> Fuel, maybe it's better for them to do not develop plugins at all?
>
> On Fri, Mar 4, 2016 at 2:24 PM, Stanislaw Bogatkin
>  wrote:
> > +1 to maintain example plugins. It is easy enough and really lowering
> > barriers for people who just begin create plugins.
> >
> > On Fri, Mar 4, 2016 at 2:08 PM, Matthew Mosesohn <
> mmoses...@mirantis.com>
> > wrote:
> >>
> >> Igor,
> >>
> >> It seems you are proposing an IKEA approach to plugins. Take Fuel's
> >> example plugin, add in the current Fuel release, and then build it.
> We
> >> maintained these plugins in the past, but now it should a manual
> step
> >> to test it out on the current release.
> >>
> >> What would be a more ideal situation that meets the needs of users
> and
> >> QA? Right now we have failed tests until we can decide on a solution
> >> that works for everybody.
> >>
> >> On Fri, Mar 4, 

[openstack-dev] [Fuel] Compatibility of fuel plugins and fuel versions

[Mike Scherbakov]

Hi folks,
in order to make a decision whether we need to support example plugins, and
if actually need them [1], I'd suggest to discuss more common things about
plugins.

My thoughts:
1) This is not good, that our plugins created for Fuel 8 won't even install
on Fuel 9. By default, we should assume that plugin will work at newer
version of Fuel. However, for proper user experience, I suggest to create
meta-field "validated_against", where plugin dev would provide versions of
Fuel this plugin has been tested with. Let's say, it was tested against
7.0, 8.0. If user installs plugin in Fuel 9, I'd suggest to show a warning
saying about risks and the fact that the plugin has not been tested against
9. We should not restrict intsallation against 9, though.

2) We need to keep backward compatibility of pluggable interface for a few
releases. So that plugin developer can use pluggable interface of version
x, which was supported in Fuel 6.1. If we still support it, it would mean
(see next point) compatibility of this plugin with 6.1, 7.0, 8.0, 9.0. If
we want to deprecate pluggable interface version, we should announce it,
and basically follow standard process of deprecation.

3) Plugin's ability to work against multiple releases of Fuel
(multi-release support). If if..else clauses to support multiple releases
are fairly minimal, let's say take less that 10% of LOC, I'd suggest to
have this supported. Just because it will be easier for plugin devs to
support their plugin code (no code duplication, single repo for multiple
releases).

Thoughts?

[1]
http://lists.openstack.org/pipermail/openstack-dev/2016-March/088211.html
-- 
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

Re: [openstack-dev] The #openstack-packaging channel requires an invite?

[Thomas Bechtold]

On Wed, Mar 09, 2016 at 12:28:59PM -0600, Matt Riedemann wrote:
[snipped]
> Ha, the irony.
> 
> OK, so I thought awhile back, around YVR summit time, there was a group of
> different packagers from different distros (debian/red hat/fedora/suse) that
> were working together on some common tooling.
> 
> Is that still a thing and if so, do they congregate somewhere? Because
> *that's* where I think people need to go, not the #openstack-stable channel.

For RPM, there is #openstack-rpm-packaging. See
https://wiki.openstack.org/wiki/Rpm-packaging

-- 
Tom

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

Re: [openstack-dev] [Horizon] How do we move forward with xstatic releases?

[Matthias Runge]

On 09/03/16 19:52, Michael Krotscheck wrote:
> On Wed, Mar 9, 2016 at 7:58 AM Monty Taylor  > wrote:
> 
> 
> > SOLUTION 4: vendor the javascript
> >
> > Heh.
> 
> Heh indeed.
> 
> SOLUTION 4.alt: use npm/bower instead of xstatic to pull the javascript.
> 
> 
> +1. Let's move the codebase forward, instead of continuing to build
> hacky workarounds for poor past architectural decisions.
> 
Coming from a distro perspective:

4.alt.2:
move to proper packages for static file management. I mean, they need to
be built anyways.

It has been mentioned, xstatic packages can block the gate. We currently
control xstatic package releases, thus we can roll back, if something
goes wrong.

If we're pulling directly with npm/bower, someone from the outside can
break us. We already have the situation with pypi packages.
With proper packages, we could even use the gate to release those
packages and thus verify, we're not breaking anyone.

Matthias

-- 
Matthias Runge 

Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Paul Argiry, Charles Cachera, Michael Cunningham,
Michael O'Neill

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

Re: [openstack-dev] [release][all][ptl] preparing to create stable/mitaka branches for libraries

[Matthias Runge]

On 09/03/16 18:26, Doug Hellmann wrote:
> It's time to start opening the stable branches for libraries. I've

> openstack/django_openstack_auth 2.2.0

Yes please

Matthias
-- 
Matthias Runge 

Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Paul Argiry, Charles Cachera, Michael Cunningham,
Michael O'Neill

__
OpenStack Development Mailing List (not for 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] Limits on volume read throughput?

[Preston L. Bannister]

In my case Centos 7 is using QEMU 1.5.3 ... which is *ancient*. This is on
a node with a packstack install of OpenStack. If you have a different
result, I would like to know why...

Got a bit further in my reading and testing. Also got my raw volume read
performance in an instance from ~300MB/s (with some tweaking) up to the
current ~800MB/s. Given the host raw volume read rate is ~1.2GB/s, and
there are substantial improvements in the software stack (Linux, iSCSI,
QEMU) in later versions ... this is a good result.

Found the main bottleneck was the iSCSI target in the physical Linux host.
(Not in my current test case, in QEMU.) From online presentations on
QEMU/iSCSI/Linux, there are known large improvements in more recent
versions. Punt. Need to re-test on top of Ubuntu Trusty LTS (what most
customers seem headed toward).  Will re-base my testing, at some point.

My testing (for simplicity) is on an all-in-one node.

Curious what other folk are getting with very-fast iSCSI targets. What is
the upper range?








On Mon, Mar 7, 2016 at 7:59 AM, Chris Friesen 
wrote:

> Just a heads-up that the 3.10 kernel in CentOS/RHEL is *not* a stock 3.10
> kernel.  It has had many things backported from later kernels, though they
> may not have backported the specific improvements you're looking for.
>
> I think CentOS is using qemu 2.3, which is pretty new.  Not sure how new
> their libiscsi is though.
>
> Chris
>
> On 03/07/2016 12:25 AM, Preston L. Bannister wrote:
>
>> Should add that the physical host of the moment is Centos 7 with a
>> packstack
>> install of OpenStack. The instance is Ubuntu Trusty. Centos 7 has a
>> relatively
>> old 3.10 Linux kernel.
>>
>>  From the last week (or so) of digging, I found there were substantial
>> claimed
>> improvements in /both/ flash support in Linux and the block I/O path in
>> QEMU -
>> in more recent versions. How much that impacts the current measures, I do
>> not
>> (yet) know.
>>
>> Which suggests a bit of tension. Redhat folk are behind much of these
>> improvements, but RHEL (and Centos) are rather far behind. Existing RHEL
>> customers want and need careful, conservative changes. Folk deploying
>> OpenStack
>> need more aggressive release content, for which Ubuntu is currently the
>> best base.
>>
>> Will we see a "Redhat Cloud Base" as an offering with RHEL support
>> levels, and
>> more aggressive QEMU and Linux kernel inclusion?
>>
>> At least for now, building OpenStack clouds on Ubuntu might be a much
>> better bet.
>>
>>
>> Are those claimed improvements in QEMU and the Linux kernel going to make
>> a
>> difference in my measured result? I do not know. Still reading, building
>> tests,
>> and collecting measures...
>>
>>
>>
>>
>> On Thu, Mar 3, 2016 at 11:28 AM, Chris Friesen <
>> chris.frie...@windriver.com
>> > wrote:
>>
>> On 03/03/2016 01:13 PM, Preston L. Bannister wrote:
>>
>>  > Scanning the same volume from within the instance still
>> gets the same
>>  > ~450MB/s that I saw before.
>>
>>  Hmmm, with iSCSI inbetween that could be the TCP memcpy
>> limitation.
>>
>>
>> Measuring iSCSI in isolation is next on my list. Both on the
>> physical
>> host, and
>> in the instance. (Now to find that link to the iSCSI test,
>> again...)
>>
>>
>> Based on earlier comments it appears that you're using the qemu
>> built-in
>> iSCSI initiator.
>>
>> Assuming that's the case, maybe it would make sense to do a test run
>> with
>> the in-kernel iSCSI code and take qemu out of the picture?
>>
>> Chris
>>
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> > >
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing 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]Why vm boots from the cirros image so slow?

[Zhi Chang]

hi guys.


There is a question confuses me a long time. I create a vm by using the 
"cirros" image. Why the vm was so slow? 


In the VNC console, I see these info says "further output written to 
/dev/tty0". And the vm hangs a long time. What does the vm doing at that time??


Besides, could someone tell me the history of the image name "cirros"?


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

Re: [openstack-dev] [glance] Glance Mitaka: Passing the torch

[Bhandaru, Malini K]

Flavio, Glance and OpenStack benefited during your reign or period of humble 
service.
Will miss you at the helm. Also thank you for anointing/attracting two new 
solid cores: Brian and Sabari
Malini


-Original Message-
From: Tom Fifield [mailto:t...@openstack.org] 
Sent: Wednesday, March 09, 2016 7:55 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [glance] Glance Mitaka: Passing the torch

A beautiful post, sir. Thank you for everything!

On 09/03/16 22:15, Flavio Percoco wrote:
>
> Greetings,
>
> I'm not going to run for Glance's PTL position for the Newton timeframe.
>
> There are many motivations behind this choice. Some of them I'm 
> willing to discuss in private if people are interested but I'll go as 
> far as saying there are personal and professional reasons for me to 
> not run again.
>
> As I've always done in my past cycles as PTL, I'd like to take some 
> time to summarize what's happened in the past cycle not only for the 
> new PTL to know what's coming up but for the community to know how 
> things went.
>
> Before I even start, I'd like to thank everyone in the Glance community.
> I truly
> believe this was a great cycle for the project and the community has 
> gotten stronger. None of this would have been possible without the 
> help of all of you and for that, I'm deeply in debt with you all. It 
> does not just take an employer to get someone to contribute to a 
> project. Being paid, for those who are, to do Open Source is not 
> enough. It takes passion, motivation and a lot of patience to analyze 
> a technology, think out of the box and look for ways it can be 
> improved either by fixing bugs or by implementing new features. The 
> amount of time and dedication this process requires is probably worth 
> way more than what we get back from it.
>
> Now, with all that being said, here's Glance Mitaka for all of you:
>
> Completed Features
> ==
>
> I think I've mentioned this already but I'm proud of it so I'll say it 
> again.
> The prioritization and scheduling of Glance Mitaka went so well that 
> we managed to release M-3 without any feature freeze exception (FFE) 
> request. This doesn't mean all the features were implemented. In fact, 
> at least 4 were pushed back to Newton. However, the team communicated, 
> reviewed, sprinted and coded in such a way that we were able to 
> re-organize the schedule to avoid wasting time on things we new 
> weren't going to make it. This required transparency and hard 
> decisions but that's part of the job, right?
>
> * [0] CIM Namespace Metadata
> * [1] Support download from and upload to Cinder volumes
> * [2] Glance db purge utility
> * [3] Deprecate Glance v3 API
> * [4] Implement trusts for Glance
> * [5] Migrate the HTTP Store to Use Requests
> * [6] Glance Image Signing and Verification
> * [7] Supporting OVF Single Disk Image Upload
> * [8] Prevention of Unauthorized errors during upload/download in 
> Swift driver
> * [9] Add filters using an ‘in’ operator
>
> [0]
> http://specs.openstack.org/openstack/glance-specs/specs/mitaka/impleme
> nted/cim-namespace-metadata-definitions.html
>
> [1]
> http://specs.openstack.org/openstack/glance-specs/specs/mitaka/impleme
> nted/cinder-store-upload-download.html
>
> [2]
> http://specs.openstack.org/openstack/glance-specs/specs/mitaka/impleme
> nted/database-purge.html
>
> [3]
> http://specs.openstack.org/openstack/glance-specs/specs/mitaka/impleme
> nted/deprecate-v3-api.html
>
> [4]
> http://specs.openstack.org/openstack/glance-specs/specs/mitaka/impleme
> nted/glance-trusts.html
>
> [5]
> http://specs.openstack.org/openstack/glance-specs/specs/mitaka/impleme
> nted/http-store-on-requests.html
>
> [6]
> http://specs.openstack.org/openstack/glance-specs/specs/mitaka/impleme
> nted/image-signing-and-verification-support.html
>
> [7]
> http://specs.openstack.org/openstack/glance-specs/specs/mitaka/impleme
> nted/ovf-lite.html
>
> [8]
> http://specs.openstack.org/openstack/glance-specs/specs/mitaka/impleme
> nted/prevention-of-401-in-swift-driver.html
>
> [9]
> http://specs.openstack.org/openstack/glance-specs/specs/mitaka/impleme
> nted/v2-add-filters-with-in-operator.html
>
>
> If the above doesn't sound impressive to you, let me fill you in with 
> some extra info about Glance's community.
>
> Community
> =
>
> Glance's community currently has 12 core members, 3 of which joined 
> during Mitaka and 2 of those 3 members joined at the end of the cycle. 
> That means the team ran on 9 reviewers for most of the cycle except 
> that out of those 9, 1 left the team and joined later in the cycle and 
> 3 folks weren't super active this cycle. That left the team with 5 
> constant reviewers throughout the cycle.
>
> Now, the above is *NOT* to say that the success of the cycle is thanks 
> to those
> 5 constant reviewers. On the contrary, it's to say that we've managed 
> to build a community capable of working together with other non-core 
> 

[openstack-dev] Branch miss-match between server and client in Kilo

[Janki Chhatbar]

Hi All

Greetings for the day!

I have noticed that while installing* OpenStack Kilo* using DevStack, the
server components cloned are stable/kilo whereas the client components
cloned are master. This leads to errors in installation or commands
miss-match. For eg.

*In tacker,*
tacker git repo is stable/kilo which points to incorrect git repo URL. I
have filled a  bug and proposed a patch for this (
https://bugs.launchpad.net/tacker/+bug/1555130)

*In Magnum*,
*magnum stable/kilo* clones *python-magnumclient master* which leads to
command mismatch (https://bugs.launchpad.net/magnum/+bug/1509273).


   1. Does this affect all other services?
   2. Does this mean that the branch needs to be changed for all the
   service's clients? The change will be in /devstack/lib/{service} file in
   "GITBRANCH" variable.

 If changes are required, I am willing to work on those.

Thanking you

Janki Chhatbar
OpenStack | SDN | Docker
(+91) 9409239106
simplyexplainedblog.wordpress.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [QA] Meeting Thursday March 10th at 9:00 UTC

[GHANSHYAM MANN]

Hello everyone,


Please reminder that the weekly OpenStack QA team IRC meeting will be
Thursday, March 10th at 9:00 UTC in the #openstack-meeting channel.


The agenda for the meeting can be found here:

https://wiki.openstack.org/wiki/Meetings/QATeamMeeting#Proposed_Agenda_for_March_10th_2016_.280900_UTC.29


Anyone is welcome to add an item to the agenda.

To help people figure out what time 9:00 UTC is in other timezones the
next meeting will be at:

04:00 EST

18:00 JST

18:30 ACST

11:00 CEST

04:00 CDT


02:00 PDT

Regards
Ghanshyam Mann

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

Re: [openstack-dev] [glance] Glance Mitaka: Passing the torch

[Tom Fifield]

A beautiful post, sir. Thank you for everything!

On 09/03/16 22:15, Flavio Percoco wrote:


Greetings,

I'm not going to run for Glance's PTL position for the Newton timeframe.

There are many motivations behind this choice. Some of them I'm willing to
discuss in private if people are interested but I'll go as far as saying
there
are personal and professional reasons for me to not run again.

As I've always done in my past cycles as PTL, I'd like to take some time to
summarize what's happened in the past cycle not only for the new PTL to
know
what's coming up but for the community to know how things went.

Before I even start, I'd like to thank everyone in the Glance community.
I truly
believe this was a great cycle for the project and the community has gotten
stronger. None of this would have been possible without the help of all
of you
and for that, I'm deeply in debt with you all. It does not just take an
employer
to get someone to contribute to a project. Being paid, for those who
are, to do
Open Source is not enough. It takes passion, motivation and a lot of
patience to
analyze a technology, think out of the box and look for ways it can be
improved
either by fixing bugs or by implementing new features. The amount of
time and
dedication this process requires is probably worth way more than what we
get
back from it.

Now, with all that being said, here's Glance Mitaka for all of you:

Completed Features
==

I think I've mentioned this already but I'm proud of it so I'll say it
again.
The prioritization and scheduling of Glance Mitaka went so well that we
managed
to release M-3 without any feature freeze exception (FFE) request. This
doesn't
mean all the features were implemented. In fact, at least 4 were pushed
back to
Newton. However, the team communicated, reviewed, sprinted and coded in
such a
way that we were able to re-organize the schedule to avoid wasting time on
things we new weren't going to make it. This required transparency and hard
decisions but that's part of the job, right?

* [0] CIM Namespace Metadata
* [1] Support download from and upload to Cinder volumes
* [2] Glance db purge utility
* [3] Deprecate Glance v3 API
* [4] Implement trusts for Glance
* [5] Migrate the HTTP Store to Use Requests
* [6] Glance Image Signing and Verification
* [7] Supporting OVF Single Disk Image Upload
* [8] Prevention of Unauthorized errors during upload/download in Swift
driver
* [9] Add filters using an ‘in’ operator

[0]
http://specs.openstack.org/openstack/glance-specs/specs/mitaka/implemented/cim-namespace-metadata-definitions.html

[1]
http://specs.openstack.org/openstack/glance-specs/specs/mitaka/implemented/cinder-store-upload-download.html

[2]
http://specs.openstack.org/openstack/glance-specs/specs/mitaka/implemented/database-purge.html

[3]
http://specs.openstack.org/openstack/glance-specs/specs/mitaka/implemented/deprecate-v3-api.html

[4]
http://specs.openstack.org/openstack/glance-specs/specs/mitaka/implemented/glance-trusts.html

[5]
http://specs.openstack.org/openstack/glance-specs/specs/mitaka/implemented/http-store-on-requests.html

[6]
http://specs.openstack.org/openstack/glance-specs/specs/mitaka/implemented/image-signing-and-verification-support.html

[7]
http://specs.openstack.org/openstack/glance-specs/specs/mitaka/implemented/ovf-lite.html

[8]
http://specs.openstack.org/openstack/glance-specs/specs/mitaka/implemented/prevention-of-401-in-swift-driver.html

[9]
http://specs.openstack.org/openstack/glance-specs/specs/mitaka/implemented/v2-add-filters-with-in-operator.html


If the above doesn't sound impressive to you, let me fill you in with
some extra
info about Glance's community.

Community
=

Glance's community currently has 12 core members, 3 of which joined during
Mitaka and 2 of those 3 members joined at the end of the cycle. That
means the
team ran on 9 reviewers for most of the cycle except that out of those
9, 1 left
the team and joined later in the cycle and 3 folks weren't super active
this
cycle. That left the team with 5 constant reviewers throughout the cycle.

Now, the above is *NOT* to say that the success of the cycle is thanks
to those
5 constant reviewers. On the contrary, it's to say that we've managed to
build a
community capable of working together with other non-core reviewers.
This was a
key thing for this cycle.

I don't think it's a secret to anyone that, at the beginning of the
cycle, the
community was fragile and somewhat split. There were different opinions
on what
Glance should (or shouldn't) look like, what new features Glance should (or
shouldn't) have and where the project should be headed in the next 6
months.

The team sat down, the team talked and the team agreed on what the project
should be and that's what the team did in the Mitaka cycle. Sharing one
message
with the rest of the OpenStack community (and especially new Glance
contributors) was a key for the community to become stronger.

What changed? What did the 

Re: [openstack-dev] [Fuel][Fuel-Library] Fuel CI issues

[Dmitry Borodaenko]

On Wed, Mar 09, 2016 at 10:56:04PM +, Andrew Woodward wrote:
> Issue: moving to puppet-openstack on master has exposed fuel-library
> to breakage and there are many concerns about changes landing that can
> break it.
> 
> Alex S. Proposed that we continue the course, and finish setting up
> Check voting on the relevant puppet-openstack modules - The
> participants agreed with this

Since many people came up with different assumptions about how the CI
duty for Fuel CI for Puppet OpenStack is supposed to work, I've created
a wiki page with a proposed definition of the process:
https://wiki.openstack.org/wiki/Fuel/CI/Puppet_OpenStack_CI_duty

Please read, comment, and add more details as needed.

Please also review and comment on the spec from Igor Belikov:
https://review.openstack.org/286731

> Action: Sergii G & Aleksandra Fedorova will propose needed changes to
> project-config to add tests
> 
> Issue: closing the regressions gap until fuel-ci votes on
> puppet-openstack check
> 
> It was proposed that we invent a system that holds back the versions
> nightly, and after completion of automated testing; It can
> automatically move it forward.
> 
> Action: There was no consensus on this and should be discussed here
> further on this thread.

In the meanwhile, Alex has proposed a fuel-library change that would
record the commit ids of the Puppet OpenStack modules it was built with:
https://review.openstack.org/288768

Merging this would enable us to implement Aleksandra's proposal of using
the versions of Puppet OpenStack modules that have most recently passed
BVT to verify commits to fuel-library and other Fuel components covered
with deploy tests.

-- 
Dmitry Borodaenko

__
OpenStack Development Mailing List (not for 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][pci] What is the point of the ALLOCATED vs. CLAIMED device status?

[yongli he]

Hi, Jay

Here is a rough summary about claimed state:

when we resizing VM to same host, suppose we now have PCI A,  will renew 
to B1, B2, before the whole resizing process finished, we given user the 
change to revert the re-size, it's better reverting to original PCI A, 
not a new PCI devices. claimed status help to recording which one is 
allocated, but not suppose be assign to the current VM.


these whole logic is missing in the Nova now,  i had post some patches 
for this, but need to refresh(now Abandoned):

https://review.openstack.org/#/q/topic:pci_resize
(ignore the first patch)

Regards
Yongli He



在 2016年03月08日 02:23, Jay Pipes 写道:

Subject says it all.

I've been trying to fix this bug:

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

and just shake my head every time I look at the PCI handling code in 
nova/pci/manager.py and nova/pci/stats.py.


Why do we have a CLAIMED state as well as an ALLOCATED state?

Best,
-jay

__ 


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

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



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

Re: [openstack-dev] [Horizon] Javascript linting and documentation

[Richard Jones]

On 10 March 2016 at 06:49, Michael Krotscheck  wrote:

> I guess I don't see what problems is being solved by turning the rule off,
> and I also don't see the harm in having more check. It does generate a lot
> of warnings, but invoking `npm run lint -- --quiet` gets rid of those.
>

We already have a "lintq" npm task that does this, which most of us use.
The problem is that we then ignore all the legitimate code linting warnings.


Also, from my experience, sphinx-based doc builds are notoriously
> permissive about bad formatting. Eslint's stricter jsdoc checks would add
> an additional safety net.
>

My perspective on this is if the documentation builder can produce
documentation that is useful then it's enforcing exactly enough checks on
the input. For example, the jsdoc linter currently forces us to write
@returns statements in our docs for angular methods that have no return
value, and never will (i.e. module.config()) or is otherwise not exposed to
developers and not interesting (i.e. the return from service or controller
construction). I mentioned this in passing in the meeting, but most of our
JS documentation has been written to ngdoc syntax, and that's potentially a
good thing since it provides much greater hinting to the doc generators
about how to present and organise the output, but also influences things
like @returns usefulness. We just have to find the right tool (or, more
likely, create, since I've been looking for a while and haven't found a
suitable tool) that uses the information we're coding into our comments.



> However, if you're working on this with the docs team, then the result
> should be applicable to the entirety of openstack - meaning that once your
> work is complete, it may make sense to turn the rule off globally.
>

Yep!


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

Re: [openstack-dev] {openstack-dev][tc] Leadership training proposal/info

[Colette Alexander]

On Tue, Mar 8, 2016 at 1:37 PM, Doug Hellmann  wrote:

>
>
> The etherpad [1] doesn't discuss any other alternatives that were
> evaluated and rejected. Were any other options considered? In
> particular, how does this course compare to an event such as the
> Community Leadership Summit[2], for which all of the participants
> are other open source contributors, rather than small business
> owners/managers?
>
> [1] https://etherpad.openstack.org/p/Leadershiptraining
>
>
I just wanted to chime in here, too, that the etherpad does list (at the
bottom) a few other options/companies/groups I researched/vetted, some of
which are larger and more corporate offerings, and/or self-guided online
learning opportunities that I think might cover good leadership training
for the OpenStack community. None of them seemed particularly geared
towards getting the conversation going around defining goals around
leadership in a larger community (rather than corporation) while offering a
subset of varied training opportunities tailored to the group in the way
that ZingTrain does (which they do, btw, because they're geared less
towards corporations, more towards small businesses). I've started filling
in even more options that have come my way since starting to talk with
folks who are giving feedback about what they'd like to see available - so
consider this an invitation to the entire community to add more
options/detail/reviews if you've taken anything you like or hate, or are
curious about an option you may have heard of through colleagues or friends!

I've also posted the sample mash-up itinerary I mentioned previously under
the option for that training in the etherpad, and I'll continue to work
with ZingTrain to finalize a couple of other options. In the meantime if
anyone has feedback or questions or would like to see something look a
little different, do let me know.

Thierry - I didn't quite respond directly to you question about the
consequence of having this expand to include much of the TC in attendance
being that the dev community as a whole feels like there's too much of a
divide between the TC and the larger Community. As I see it, given that we
max out around 20 participants, we could certainly work to actively reserve
space for non-TC community members who express interest. All 13 current
members of the TC have expressed interest in going, and we have potentially
7 entirely new members that can be elected, which puts us around the
maximum preferred in a training if every spot is newly elected and everyone
interested now decides to come (though ZingTrain has said that 22-25 is
sometimes an acceptable overflow). The event-planner in me is assuming that
won't actually happen and we'll have space, but we won't know til after the
election. I think it'd be a huge asset to have more than the TC represented
there, so consider me signed up for helping to organize/engage there.

thanks everyone!

-colette
__
OpenStack Development Mailing List (not for 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] Fuel CI issues

[Andrew Woodward]

Today we had a sync up call and discussed this. To summarize

Attendees:
Aleksandr Didenko
Alex Schultz
Andrew Woodward
Alexey Shtokolov
Bartek Kupidura
Bogdan Dobrelya
Denis Egorenko
Ivan Berezovskiy
Kyrylo Galanov
Maksim Malchuk
Matthew Mosesohn
Max Yatsenko
Oleg Gelbukh
Oleksiy Molchanov
Petr Zhurba
Sergey Kolekonov
Sergey Vasilenko
Sergii Golovatiuk
Stanislav Makar
Stanislaw Bogatkin
Vladimir Eremin
Vladimir Kuklin

Issue: moving to puppet-openstack on master has exposed fuel-library to
breakage and there are many concerns about changes landing that can break
it.

Alex S. Proposed that we continue the course, and finish setting up Check
voting on the relevant puppet-openstack modules - The participants agreed
with this

Action: Sergii G & Aleksandra Fedorova will propose needed changes to
project-config to add tests

Issue: closing the regressions gap until fuel-ci votes on puppet-openstack
check

It was proposed that we invent a system that holds back the versions
nightly, and after completion of automated testing; It can automatically
move it forward.

Action: There was no consensus on this and should be discussed here further
on this thread.



On Sun, Mar 6, 2016 at 11:33 PM Dmitry Borodaenko 
wrote:

> Aleksandra,
>
> Very good point on separating the concerns about integration tests for
> Fuel as a whole and verifying commits to a single component such as
> fuel-library. In theory, it could support the right balance between
> stable CI and up-to-date code, but only if we resolve the two remaining
> problems: one small and technical and the other large and social.
>
> You've already pointed out the first problem: update of fuel-library CI
> environment is not yet fully automated, and so the environment is liable
> to lag behind all involved components for days if not weeks.
>
> This by itself is simple enough, if labourous, to work around (update it
> manually every day, or after every successful BVT), but still leaves us
> with the problem of motivation.
>
> We've been discussing the CI duty for fuel-library integration with
> puppet-openstack since more than a month ago [0], and it has
> continuously failed to materialize. Within days of getting an action
> item in that IRC meeting to arrange it, Andrew Maksimov has responded
> privately that nobody in his team has time for this. And we all know
> what "I don't have time" actually means [1]. Two weeks later, we were
> ready to launch the integration and the question of CI duty came up
> again [2], with the same result.
>
> [0]
> http://eavesdrop.openstack.org/meetings/fuel/2016/fuel.2016-02-04-16.02.log.html#l-66
> [1]
> http://lifehacker.com/5892948/instead-of-saying-i-dont-have-time-say-its-not-a-priority
> [2]
> http://eavesdrop.openstack.org/meetings/fuel/2016/fuel.2016-02-18-16.00.log.html#l-190
>
> Here we are two more weeks later, the integration is on, and the first
> reaction from fuel-library core reviewers is "we don't have time to deal
> with this, turn it back off right now". And I'm not just summarizing
> Vladimir's email, on Friday we had a long thread on an internal mailing
> list with exactly this in the subject line (my apologies, but my disgust
> at the fact that it was started behind closed doors drowns any qualms
> about dragging it back into the open).
>
> After we change Fuel CI to use fixed, most recent to have passed BVT,
> revisions of puppet-openstack modules, first thing that will happen is
> that BVT on Fuel ISO will start failing again, while fuel-library CI
> will continue to work. Without the pressure of failing commit
> verification CI, fuel-library developers will have even less incentive
> to keep fuel-library up to date with puppet-openstack (not to mention
> pro-actively reviewing puppet-openstack commits to catch potential
> regressions before they happen), and very soon Fuel QA team will get fed
> up with not having a stable ISO for the swarm test, and will demand that
> we go back to using fixed puppet-openstack revisions for the ISO, too.
>
> Both here and on the internal thread, many technical and organizational
> concerns were raised, and I'll get to them in a bit, but a concern
> without the will to resolve it is only an excuse, we won't get far if we
> don't want to make it work.
>
> So why don't fuel-library developers want to spend time on
> puppet-openstack integration?
>
> I see two dimensions to this problem. On one axis, there's the
> cost/benefit balance: how much work does it take, and what do we gain
> from doing it? On the other is the question of who benefits and who
> carries the costs?
>
> Without tracking HEAD of puppet-openstack in fuel-library, the primary
> cost is carried by puppet-openstack developers who maintain the upstream
> modules in the first place, and a small fraction of fuel-library
> contributors (5+ out of 50+ [3][4]) who periodically have to spend
> significant amount of effort to bring fuel-library up to date with the
> current state of 

Re: [openstack-dev] [nova] patches that improve code quality

[Shinobu Kinjo]

Ideally it's good practice to do refactoring the codes to add more
readability. In reality, it's kind of impossible.
Because there might be another process required after refactoring and
it would take a time.
But that's good point, honestly.

On Thu, Mar 10, 2016 at 1:33 AM, Matt Riedemann
 wrote:
>
>
> On 3/9/2016 6:22 AM, Radomir Dopieralski wrote:
>>
>> Some of the code we have in Nova is admittedly hard to read and brittle.
>> This is true even though we cave excellent code review,
>> and the reviewers that deeply care for the quality of code that is being
>> merged. Some of this code has been there always, some got that way as a
>> result of bug fixes and patches that were intended to touch as little
>> code as possible, and some is just to bad judgment or mistakes.
>>
>> Whatever the reason, such code accumulates and makes the program harder
>> to understand, to debug and to modify. The maintenance and development
>> costs rise. It's also less pleasant to work with such code base.
>>
>> Cleaning up such code and rewriting it to be easier to understand and
>> more robust is a good practice that every programmer should be familiar
>> with. However, it's not always easy or even possible to do that while
>> working on a feature or a bugfix. If our patch includes a lot of changes
>> that are unrelated to the feature or bug at hand, it becomes harder to
>> understand and review, and even runs a risk of being rejected. It's also
>> easier to introduce bugs that way.
>>
>> A good practice would be to make such changes in separate patches,
>> possibly also adding tests (where they are missing) showing that there
>> is no change in behavior. Such patches can be reviewed with special
>> attention to readability and robustness, and in the review there will be
>> often even further improvements. We end up with a better program and
>> easier (and more pleasant) work.
>>
>> And now, finally, I can get to the point of this e-mail. I'm relatively
>> new to this project, but I found no way to direct the (precious)
>> attention of core reviewers to such patches. They are not bugs, neither
>> they are parts of any new feature, and so there is no list in Nova that
>> core reviewers look at where we could add such a patch. Admittedly, such
>> patches are not urgent -- the code works the same (or almost the same)
>> way without them -- but it would be nice to have some way of merging
>> them eventually, because they do make our lives easier in the long run.
>>
>> So here's my question: what is the correct way to have such a patch
>> merged in Nova, and -- if there isn't one -- should we think about
>> making it easier?
>
>
> I don't think we give any special priority to technical debt cleanup unless
> it's part of a larger series, like cleaning up code before fixing a bug or
> landing a feature.
>
> So you can and should push patches to refactor code to make it more
> maintainable/readable/etc, but there isn't a guarantee that it's going to
> get attention any sooner than every other patch out in the review queue
> (according to stackalytics there are currently 842 open reviews in nova
> [1]).
>
> [1] http://stackalytics.com/report/reviews/nova/open
>
> --
>
> 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



-- 
Email:
shin...@linux.com
GitHub:
shinobu-x
Blog:
Life with Distributed Computational System based on OpenSource

__
OpenStack Development Mailing List (not for 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][zaqar][cloudkitty] Default ports list

[Matt Fischer]

This is not the first time. Monasca and Murano had a collision too[1]. When
this happens the changes trickle down into automation tools also and
complicates things.

[1] https://bugs.launchpad.net/murano/+bug/1505785

On Wed, Mar 9, 2016 at 3:30 PM, Xav Paice  wrote:

> From an ops point of view, this would be extremely helpful information to
> share with various teams around an organization.  Even a simple wiki page
> would be great.
>
> On 10 March 2016 at 10:35, Fei Long Wang  wrote:
>
>> Hi all,
>>
>> Yesterday I just found cloudkitty is using the same default port ()
>> which is used by Zaqar now. So I'm wondering if there is any rule/policy
>> for those new services need to be aware. I googled but can't find anything
>> about this. The only link I can find is
>> http://docs.openstack.org/liberty/config-reference/content/firewalls-default-ports.html.
>> So my question is should we document the default ports list on an official
>> place given the big tent mode? Thanks.
>>
>> --
>> Cheers & Best regards,
>> Fei Long Wang (王飞龙)
>> --
>> Senior Cloud Software Engineer
>> Tel: +64-48032246
>> Email: flw...@catalyst.net.nz
>> Catalyst IT Limited
>> Level 6, Catalyst House, 150 Willis Street, Wellington
>> --
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __
> OpenStack Development Mailing 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][zaqar][cloudkitty] Default ports list

[Xav Paice]

>From an ops point of view, this would be extremely helpful information to
share with various teams around an organization.  Even a simple wiki page
would be great.

On 10 March 2016 at 10:35, Fei Long Wang  wrote:

> Hi all,
>
> Yesterday I just found cloudkitty is using the same default port ()
> which is used by Zaqar now. So I'm wondering if there is any rule/policy
> for those new services need to be aware. I googled but can't find anything
> about this. The only link I can find is
> http://docs.openstack.org/liberty/config-reference/content/firewalls-default-ports.html.
> So my question is should we document the default ports list on an official
> place given the big tent mode? Thanks.
>
> --
> Cheers & Best regards,
> Fei Long Wang (王飞龙)
> --
> Senior Cloud Software Engineer
> Tel: +64-48032246
> Email: flw...@catalyst.net.nz
> Catalyst IT Limited
> Level 6, Catalyst House, 150 Willis Street, Wellington
> --
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing 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] Linuxbridge gate failures

[Armando M.]

Neutrinos,

We had two back-to-back gate failures on [1,2] and more seem to be ramping
up. These are tracked in bug [3] (e-r query tracked in [4]). Can I trouble
some gentle soul to have a look?

Thanks,
Armando

[1] https://review.openstack.org/#/c/286818/
[2] https://review.openstack.org/#/c/285339/
[3] https://bugs.launchpad.net/neutron/+bug/1531862
[4] https://review.openstack.org/#/c/290861/
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [release][all][ptl] preparing to create stable/mitaka branches for libraries

[Dmitry Tantsur]

2016-03-09 18:26 GMT+01:00 Doug Hellmann :

> It's time to start opening the stable branches for libraries. I've
> prepared a list of repositories and the proposed versions from which
> we will create stable/mitaka branches, and need each team to sign off on
> the versions. If you know you intend to release a bug fix version in
> the next couple of days, we can wait to avoid having to backport
> patches, but otherwise we should go ahead and create the branches.
>
> I will process each repository as I hear from the owning team.
>
> openstack/ceilometermiddleware 0.4.0
> openstack/django_openstack_auth 2.2.0
> openstack/glance_store 0.13.0
> openstack/ironic-lib 1.1.0
> openstack/keystoneauth 2.3.0
> openstack/keystonemiddleware 4.3.0
> openstack/os-brick 1.1.0
> openstack/os-client-config 1.16.0
> openstack/pycadf 2.1.0
> openstack/python-barbicanclient 4.0.0
> openstack/python-brick-cinderclient-ext 0.1.0
> openstack/python-ceilometerclient 2.3.0
> openstack/python-cinderclient 1.6.0
> openstack/cliff 2.0.0
> openstack/python-designateclient 2.0.0
> openstack/python-glanceclient 2.0.0
> openstack/python-heatclient 1.0.0
> openstack/python-ironic-inspector-client 1.5.0
>

This one is fine.

Thanks,
Dmitry.


> openstack/python-ironicclient 1.2.0
> openstack/python-keystoneclient 2.3.1
> openstack/python-manilaclient 1.8.0
> openstack/python-neutronclient 4.1.1
> openstack/python-novaclient 3.3.0
> openstack/python-saharaclient 0.13.0
> openstack/python-swiftclient 3.0.0
> openstack/python-troveclient 2.1.0
> openstack/python-zaqarclient 1.0.0
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
--
-- Dmitry Tantsur
--
__
OpenStack Development Mailing List (not for 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] issue of ResourceGroup in Heat template

[Jay Dobies]

On 3/9/16 4:39 PM, Zane Bitter wrote:

On 09/03/16 05:42, Sergey Kraynev wrote:

Hi Gary,


First of all you don't need to use "depends_on", because using
"get_attr" already create implicit dependency from rg_a.
About getting Null instead of real Ip address:
It sounds like a bug, but IMO, it's expected behavior, because I
suppose it happens due to:
  - you create in rg_a some Server and probably it goes to active state
before ip address becomes available for get_attr. It is necessary to
check, but if it's try to add wait condition for this resource, then
you will get created rg_a with fully available resources and I suppose
IP will be available.


I would have expected the IP address to be available before the server
becomes CREATE_COMPLETE. If it isn't then I'd consider that a bug too -
as you pointed out, people are relying on the dependency created by
get_attr to ensure that they can actually get the attribute.

cheers,
Zane.


On 9 March 2016 at 13:14, Duan, Li-Gong (Gary, HPServers-Core-OE-PSC)
 wrote:

Hi,



I have 3 Heat templates using ResourceGroup. There are 2 resource
groups(rg_a and rg_b) and rg_b depends on rg_a.  and rg_b requires
the IP
address of rg_a as the paremeter of rg_b. I use “rg_a_public_ip:
{get_attr:
[rg_a, rg_a_public_ip]}” to get the IP address of rg_a both in the
section
of rg_b parameters (rg_b/properties/resource_def/properties) and the
section
of outputs.

As per my observation,  rg_a_public_ip shows “null” in the parameter
section
of rg_b. while rg_a_public_ip shows the correct IP address in the
outputs
section of the yaml file.



My questions are:

1)  Does this behavior is expected as designed or this is a bug?

2)  What is the alternative solution for the above case(user want
to get
the run-time information of the instance when creating the second
resource
group)  if this behavior is expected?



--- a.yaml ---

resources:

rg_a:

   type: OS::Heat::ResourceGroup

   properties:

   count: 1


Is this still an issue when you remove the resource group and create the 
resource directly? The count of 1 might just be for testing purposes, 
but if that's the end goal you should be able to drop the group entirely.




   resource_def:

   type: b.yaml

   properties:

…



rg_b:

type: OS::Heat::ResourceGroup

depends_on:

 -rg_a

properties:

 count: 2

 resource_def:

 type: c.yaml

 properties:

 rg_a_public_ip: {get_attr: [rg_a, rg_a_public_ip]}
  the value is “null”

 …



outputs:

rg_a_public_ip: {get_attr: [rg_a, rg_a_public_ip]}
-  the value is correct.

--



--b.yaml  

…

resources:

 rg_a:

type: OS::Nova::Server

properties:

  …

outputs:

  rg_a_public_ip:

  value: {get_attr: [rg_a, networks, public, 0]}

--



-- c.yaml 

parameters:

rg_a_public_ip:

  type: string

  description: IP of rg_a

…

resources:

rg_b:

 type: OS::Nova::Server

 properties:

  …

 outputs:

  …

---



Regards,

Gary




__

OpenStack Development Mailing 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] [release][all][ptl] preparing to create stable/mitaka branches for libraries

[Sean McGinnis]

On Wed, Mar 09, 2016 at 12:26:18PM -0500, Doug Hellmann wrote:
> It's time to start opening the stable branches for libraries. I've
> prepared a list of repositories and the proposed versions from which
> we will create stable/mitaka branches, and need each team to sign off on
> the versions. If you know you intend to release a bug fix version in
> the next couple of days, we can wait to avoid having to backport
> patches, but otherwise we should go ahead and create the branches.
> 
> I will process each repository as I hear from the owning team.
> 
> openstack/os-brick 1.1.0
> openstack/python-cinderclient 1.6.0

Cinder is good to go for these.

Thanks!
Sean McGinnis (smcginnis)

__
OpenStack Development Mailing 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] [horizon] Proposal to add Diana Whitten to horizon-core

[Cindy Lu]

+2 for Diana :)

 - Original message -
 From: David Lyle 
 To: OpenStack Development Mailing List 
 Cc:
 Subject: [openstack-dev] [horizon] Proposal to add Diana Whitten to
 horizon-core
 Date: Tue, Mar 8, 2016 2:07 PM

 I propose adding Diana Whitten[1] to horizon-core.

 Diana is an active reviewer, contributor and community member. Over
 the past couple of releases, Diana has driven extensive changes around
 theme-ability in Horizon and drastically increased the standardization
 of our use of bootstrap. During this time, Diana has also provided
 valuable reviews to keep us on the straight and narrow preventing our
 continued abuse of defenseless web technologies.

 Please respond with comments, +1s, or objections by Friday.

 Thanks,
 David

 [1]
 http://stackalytics.com/?module=horizon-group_id=hurgleburgler=all


 __
 OpenStack Development Mailing 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] [heat] issue of ResourceGroup in Heat template

[Zane Bitter]

On 09/03/16 05:42, Sergey Kraynev wrote:

Hi Gary,


First of all you don't need to use "depends_on", because using
"get_attr" already create implicit dependency from rg_a.
About getting Null instead of real Ip address:
It sounds like a bug, but IMO, it's expected behavior, because I
suppose it happens due to:
  - you create in rg_a some Server and probably it goes to active state
before ip address becomes available for get_attr. It is necessary to
check, but if it's try to add wait condition for this resource, then
you will get created rg_a with fully available resources and I suppose
IP will be available.


I would have expected the IP address to be available before the server 
becomes CREATE_COMPLETE. If it isn't then I'd consider that a bug too - 
as you pointed out, people are relying on the dependency created by 
get_attr to ensure that they can actually get the attribute.


cheers,
Zane.


On 9 March 2016 at 13:14, Duan, Li-Gong (Gary, HPServers-Core-OE-PSC)
 wrote:

Hi,



I have 3 Heat templates using ResourceGroup. There are 2 resource
groups(rg_a and rg_b) and rg_b depends on rg_a.  and rg_b requires the IP
address of rg_a as the paremeter of rg_b. I use “rg_a_public_ip: {get_attr:
[rg_a, rg_a_public_ip]}” to get the IP address of rg_a both in the section
of rg_b parameters (rg_b/properties/resource_def/properties) and the section
of outputs.

As per my observation,  rg_a_public_ip shows “null” in the parameter section
of rg_b. while rg_a_public_ip shows the correct IP address in the outputs
section of the yaml file.



My questions are:

1)  Does this behavior is expected as designed or this is a bug?

2)  What is the alternative solution for the above case(user want to get
the run-time information of the instance when creating the second resource
group)  if this behavior is expected?



--- a.yaml ---

resources:

rg_a:

   type: OS::Heat::ResourceGroup

   properties:

   count: 1

   resource_def:

   type: b.yaml

   properties:

…



rg_b:

type: OS::Heat::ResourceGroup

depends_on:

 -rg_a

properties:

 count: 2

 resource_def:

 type: c.yaml

 properties:

 rg_a_public_ip: {get_attr: [rg_a, rg_a_public_ip]}
  the value is “null”

 …



outputs:

rg_a_public_ip: {get_attr: [rg_a, rg_a_public_ip]}
-  the value is correct.

--



--b.yaml  

…

resources:

 rg_a:

type: OS::Nova::Server

properties:

  …

outputs:

  rg_a_public_ip:

  value: {get_attr: [rg_a, networks, public, 0]}

--



-- c.yaml 

parameters:

rg_a_public_ip:

  type: string

  description: IP of rg_a

…

resources:

rg_b:

 type: OS::Nova::Server

 properties:

  …

 outputs:

  …

---



Regards,

Gary




__
OpenStack Development Mailing 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] [all][zaqar][cloudkitty] Default ports list

[Fei Long Wang]

Hi all,

Yesterday I just found cloudkitty is using the same default port () 
which is used by Zaqar now. So I'm wondering if there is any rule/policy 
for those new services need to be aware. I googled but can't find 
anything about this. The only link I can find is 
http://docs.openstack.org/liberty/config-reference/content/firewalls-default-ports.html. 
So my question is should we document the default ports list on an 
official place given the big tent mode? Thanks.


--
Cheers & Best regards,
Fei Long Wang (王飞龙)
--
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
--


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

Re: [openstack-dev] [Horizon] How do we move forward with xstatic releases?

[Tripp, Travis S]

> On 03/09/2016 04:43 PM, Serg Melikyan wrote:

>>>
>>> This is exactly my first thought. The plugins *must* depend on Horizon,
>>> and they have to use the same versions of XStatic packages anyways,
>
> >> so why specify the dependencies twice?
>>
>>
>> Plugins may require different xstatic library, which is not even used
>> by Horizon. Issue raised by Richard exists for plugins too, not only
>> for Horizon itself.
>
>
> How would such an xstatic library conflict with what is in Horizon then,
> though?

> Say there are two xstatic libraries, a and b. B depends on a. Horizon depends 
> only on a. Plugin-foo depends on b. Horizon updates to a version of a that 
> the version of b consumed by plugin-foo is not compatible with.

> Rob

Just FYI, this topic came up in the horizon IRC today at the 20:30:45 minute 
mark.:  
http://eavesdrop.openstack.org/meetings/horizon/2016/horizon.2016-03-09-20.00.log.html
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc] [trove][stable] proboscis tests randomly failing in stable branches; bug 1538506

[Matt Riedemann]

On 3/9/2016 2:15 PM, Amrith Kumar wrote:

Thanks Matt.

Agreed on 1, 2, 3, and 4. The reason for #5 is that there are other changes 
(for which we have FFE's) which will be merged and a new version of the client 
requested.

Specifically, this change

https://review.openstack.org/290177

Thanks,

-amrith


-Original Message-
From: Matt Riedemann [mailto:mrie...@linux.vnet.ibm.com]
Sent: Wednesday, March 09, 2016 2:53 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [tc] [trove][stable] proboscis tests randomly
failing in stable branches; bug 1538506



On 3/9/2016 1:34 PM, Amrith Kumar wrote:

Matt,

We discussed this at the Trove meeting. Here's my current understanding

of the situation:


1. Your change https://review.openstack.org/#/c/290048/ which reverts

the trove client side of the change should be merged.


2. This change (the Trove API side)

https://review.openstack.org/#/c/245845/ should also be reverted. I'm
assuming that you'll submit a change for this as well for completeness.

I can submit a change for this.



3. We need to blacklist python-troveclient 2.1.0 on Liberty, this is
your change https://review.openstack.org/#/c/290021/

4. We need to blacklist python-troveclient 2.1.0 on master, this is

currently *NOT* what your change https://review.openstack.org/290168 does.
I disagree with the approach of just increasing the minimum requirement
from 1.2.0 to >=2.1.0.

I'm OK with blacklisting 2.1.0 on master and can make that change in the
same patch.



5. We need to request a new python-troveclient. Whether it should be

called 2.1.1 or 2.2.0, I'm not positive. My thought is 2.1.1. But out of
an abundance of caution, I'm going to look to #openstack-
release/#openstack-infra for guidance on this.

There are no other changes to python-troveclient since 2.1.0 was released:

user@xubuntu:~/git/python-troveclient$ git log --oneline --no-merges
2.1.0..
user@xubuntu:~/git/python-troveclient$


So 2.1.1 is fine.



Thanks,

-amrith


-Original Message-
From: Matt Riedemann [mailto:mrie...@linux.vnet.ibm.com]
Sent: Wednesday, March 09, 2016 12:42 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [trove][stable] proboscis tests randomly
failing in stable branches; bug 1538506



On 3/9/2016 8:54 AM, Amrith Kumar wrote:

Matt,

As I understand it, you have 4 changes up for review.

   Change [1] seeks to revert the change [6] to python-troveclient

on

   master and reinstate the slave_of parameter.

   Change [2] is doing for stable/liberty, the same things that

were

   done for master in [9] on master, and [7] on Kilo earlier.

   Change [3] is looking to blacklist python-troveclient 2.1.0 on
   stable/liberty.

   Change [4] is looking to bump the minimum python-troveclient

version

   on master to 2.1.0.


Right, and there was actually another for that beat me to this:

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



Here are three questions I have:

(1) Wouldn't backward compatibility also require that you revert the
other change that removed slave_of on the server [5] ? After all,
just like a python client that calls create() with slave_of, a REST
client could call the endpoint with slave_of. What is the policy for
REST API backward compatibility?


I guess it depends on the Trove team. In Nova, backward compatibility
in the API is serious business and that's why we have left all sorts
of warts in the v2.0 API and couldn't remove them. But with the v2.1
API and microversions, we're able to move the API forward (Ironic
also has microversions, and I think cinder/neutron/keystone are
working on adding that support).

So if maintaining backward compatibility in the trove API is
important to the trove team and it's users, then yes the API change
should probably be reverted. For anyone doing CD with Trove, they are
already broken, but people upgrading from liberty to mitaka could save

themselves the break.




(2) Wouldn't [4] just block 2.1.0 in global-requirements on master
(mitaka)?


I'm not sure I understand, [4] here bumps the minimum required
version of python-troveclient to be 2.1.0, not block it. As noted in
the review, I don't know that it's really necessary to bump to 2.1.0
iff we land and release [1].



(3) Something, potentially your patch set [2], should also fix the
test that is invoking create() with slave_of, no?


[2] is stable/liberty which still has slave_of in the create API, so
I don't think that needs to be fixed in stable/liberty.



-amrith

[1] https://review.openstack.org/290048/
[2] https://review.openstack.org/290023/
[3] https://review.openstack.org/290021/
[4] https://review.openstack.org/290168/
[5] https://review.openstack.org/#/c/245845/
[6] https://review.openstack.org/#/c/245738/
[7] https://review.openstack.org/#/c/246735/

On 03/08/2016 08:24 PM, Matt Riedemann wrote:



On 3/8/2016 4:44 PM, Matt Riedemann wrote:



On 3/8/2016 3:17 PM, Matt Riedemann wrote:



On 

Re: [openstack-dev] [Horizon] How do we move forward with xstatic releases?

[Richard Jones]

Hi Serg,

There's a crucial difference: getting the solution to this wrong for
Horizon will break the gate for all OpenStack projects. Updating an xstatic
package that a plugin uses has no side-effect outside of the plugin.


  Richard

On 10 March 2016 at 02:43, Serg Melikyan  wrote:

> >This is exactly my first thought. The plugins *must* depend on Horizon,
> and they have to use the same versions of XStatic packages anyways, so why
> specify the dependencies twice?
>
> Plugins may require different xstatic library, which is not even used
> by Horizon. Issue raised by Richard exists for plugins too, not only
> for Horizon itself.
>
>
> On Wed, Mar 9, 2016 at 12:24 AM, Radomir Dopieralski
>  wrote:
> > On 03/08/2016 11:43 PM, David Lyle wrote:
> >
> >> I'm wondering if since horizon is really the only project consuming
> >> these xstatic libraries and none are likely to venture down this path of
> >> madness with us that it would be safe to manage the xstatic requirements
> >> and upper-constraints locally.
> >>
> >> Technically the plugins for horizon depend on this, but they depend via
> >> horizon. If they require specific versions that are not supported by
> >> Horizon, I think all bets are off anyway.
> >
> >
> > This is exactly my first thought. The plugins *must* depend on Horizon,
> > and they have to use the same versions of XStatic packages anyways, so
> > why specify the dependencies twice? If the changes between versions are
> > so big as to be breaking, then the plugins have to be updated to work
> > with the new Horizon anyways.
> >
> > --
> > Radomir Dopieralski
> >
> >
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> --
> Serg Melikyan, Senior Software Engineer at Mirantis, Inc.
> http://mirantis.com | smelik...@mirantis.com
>
> +1 (650) 440-8979
>
> __
> OpenStack Development Mailing 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] [Horizon] Javascript linting and documentation

[Tripp, Travis S]

Hi Michael,

The problem is that the warnings are so great that is really hard to read.

What if we amended the recently added lintq to do some inline filtering of the 
doc warnings?  This is just a bandaid of course.

I also am opposed to any major linting changes until Mitaka closes. They cause 
too many merge conflicts when the fix goes in, making the real bugs harder to 
get through.

-Travis

From: Michael Krotscheck >
Reply-To: OpenStack List 
>
Date: Wednesday, March 9, 2016 at 12:49 PM
To: OpenStack List 
>
Subject: Re: [openstack-dev] [Horizon] Javascript linting and documentation

+1 to what Rob said.

I guess I don't see what problems is being solved by turning the rule off, and 
I also don't see the harm in having more check. It does generate a lot of 
warnings, but invoking `npm run lint -- --quiet` gets rid of those. Also, from 
my experience, sphinx-based doc builds are notoriously permissive about bad 
formatting. Eslint's stricter jsdoc checks would add an additional safety net.

However, if you're working on this with the docs team, then the result should 
be applicable to the entirety of openstack - meaning that once your work is 
complete, it may make sense to turn the rule off globally.

Michael

On Wed, Mar 9, 2016 at 11:14 AM Rob Cresswell (rcresswe) 
> wrote:
If possible, I’d really prefer we left linting work to Newton. It’ll be good to 
get it to a more usable state again, but we ought to be focusing on thoroughly 
checking the new Launch Instance for bugs and edge usage cases, as well as the 
outstanding bugs and blueprints targeted at RC1 
(https://launchpad.net/horizon/+milestone/mitaka-rc1). This is a great 
opportunity to prove that the Angular rewrites are fully capable of providing 
an improved experience, and we should be capitalising on that.

Rob


On 9 Mar 2016, at 02:25, Richard Jones 
> wrote:

Hey all,

I started looking into fixing the wall of "npm run lint" warnings today and 
quickly noticed that about 85% of the "linting" warnings were about jsdoc. We 
have significant issues around jsdoc anyway and we're supposed to be using 
Sphinx anyway[1].

Some Horizon folks will know that I've been investigating generating 
publishable documentation for our Javascript code for some time. Most of the 
tools either don't work (dgeni) or produce pretty unusable output for a project 
our size (jsdoc and grunt-ngdocs). I am about to investigate Sphinx in 
collaboration with the docs team.

Regardless, I believe that the documentation generation should generate errors 
about that documentation, not the code linter. Once we actually get a 
documentation generator going. Until then, we don't even know what syntax the 
documentation should follow.

I've proposed a change which just turns jsdoc "linting" off[2]. At the moment, 
it is less than useful (the noise drowns out any other, legitimate linting).


 Richard


[1] http://governance.openstack.org/reference/cti/javascript-cti.html
[2] https://review.openstack.org/#/c/290235/

__
OpenStack Development Mailing 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] [app-catalog] IRC Meeting Thursday March 10th at 17:00UTC

[Christopher Aedo]

Join us Thursday for our weekly meeting, scheduled for March 10th at
17:00UTC in #openstack-meeting-3

The agenda can be found here, and please add to if you want to get
something on the agenda:
https://wiki.openstack.org/wiki/Meetings/app-catalog

Looking forward to seeing everyone there tomorrow!

-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] [release][all][ptl] preparing to create stable/mitaka branches for libraries

[Sergey Kraynev]

Hi, Doug

Heat team is agree to use python-heatclient == 1.0.0 for creating stable branch

On 9 March 2016 at 20:26, Doug Hellmann  wrote:
> It's time to start opening the stable branches for libraries. I've
> prepared a list of repositories and the proposed versions from which
> we will create stable/mitaka branches, and need each team to sign off on
> the versions. If you know you intend to release a bug fix version in
> the next couple of days, we can wait to avoid having to backport
> patches, but otherwise we should go ahead and create the branches.
>
> I will process each repository as I hear from the owning team.
>
> openstack/ceilometermiddleware 0.4.0
> openstack/django_openstack_auth 2.2.0
> openstack/glance_store 0.13.0
> openstack/ironic-lib 1.1.0
> openstack/keystoneauth 2.3.0
> openstack/keystonemiddleware 4.3.0
> openstack/os-brick 1.1.0
> openstack/os-client-config 1.16.0
> openstack/pycadf 2.1.0
> openstack/python-barbicanclient 4.0.0
> openstack/python-brick-cinderclient-ext 0.1.0
> openstack/python-ceilometerclient 2.3.0
> openstack/python-cinderclient 1.6.0
> openstack/cliff 2.0.0
> openstack/python-designateclient 2.0.0
> openstack/python-glanceclient 2.0.0
> openstack/python-heatclient 1.0.0
> openstack/python-ironic-inspector-client 1.5.0
> openstack/python-ironicclient 1.2.0
> openstack/python-keystoneclient 2.3.1
> openstack/python-manilaclient 1.8.0
> openstack/python-neutronclient 4.1.1
> openstack/python-novaclient 3.3.0
> openstack/python-saharaclient 0.13.0
> openstack/python-swiftclient 3.0.0
> openstack/python-troveclient 2.1.0
> openstack/python-zaqarclient 1.0.0
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Regards,
Sergey.

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

Re: [openstack-dev] [tc] [trove][stable] proboscis tests randomly failing in stable branches; bug 1538506

[Amrith Kumar]

Thanks Matt.

Agreed on 1, 2, 3, and 4. The reason for #5 is that there are other changes 
(for which we have FFE's) which will be merged and a new version of the client 
requested.

Specifically, this change

https://review.openstack.org/290177

Thanks,

-amrith

> -Original Message-
> From: Matt Riedemann [mailto:mrie...@linux.vnet.ibm.com]
> Sent: Wednesday, March 09, 2016 2:53 PM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [tc] [trove][stable] proboscis tests randomly
> failing in stable branches; bug 1538506
> 
> 
> 
> On 3/9/2016 1:34 PM, Amrith Kumar wrote:
> > Matt,
> >
> > We discussed this at the Trove meeting. Here's my current understanding
> of the situation:
> >
> > 1. Your change https://review.openstack.org/#/c/290048/ which reverts
> the trove client side of the change should be merged.
> >
> > 2. This change (the Trove API side)
> https://review.openstack.org/#/c/245845/ should also be reverted. I'm
> assuming that you'll submit a change for this as well for completeness.
> 
> I can submit a change for this.
> 
> >
> > 3. We need to blacklist python-troveclient 2.1.0 on Liberty, this is
> > your change https://review.openstack.org/#/c/290021/
> >
> > 4. We need to blacklist python-troveclient 2.1.0 on master, this is
> currently *NOT* what your change https://review.openstack.org/290168 does.
> I disagree with the approach of just increasing the minimum requirement
> from 1.2.0 to >=2.1.0.
> 
> I'm OK with blacklisting 2.1.0 on master and can make that change in the
> same patch.
> 
> >
> > 5. We need to request a new python-troveclient. Whether it should be
> called 2.1.1 or 2.2.0, I'm not positive. My thought is 2.1.1. But out of
> an abundance of caution, I'm going to look to #openstack-
> release/#openstack-infra for guidance on this.
> 
> There are no other changes to python-troveclient since 2.1.0 was released:
> 
> user@xubuntu:~/git/python-troveclient$ git log --oneline --no-merges
> 2.1.0..
> user@xubuntu:~/git/python-troveclient$
> 
> 
> So 2.1.1 is fine.
> 
> >
> > Thanks,
> >
> > -amrith
> >
> >> -Original Message-
> >> From: Matt Riedemann [mailto:mrie...@linux.vnet.ibm.com]
> >> Sent: Wednesday, March 09, 2016 12:42 PM
> >> To: openstack-dev@lists.openstack.org
> >> Subject: Re: [openstack-dev] [trove][stable] proboscis tests randomly
> >> failing in stable branches; bug 1538506
> >>
> >>
> >>
> >> On 3/9/2016 8:54 AM, Amrith Kumar wrote:
> >>> Matt,
> >>>
> >>> As I understand it, you have 4 changes up for review.
> >>>
> >>>   Change [1] seeks to revert the change [6] to python-troveclient
> on
> >>>   master and reinstate the slave_of parameter.
> >>>
> >>>   Change [2] is doing for stable/liberty, the same things that
> were
> >>>   done for master in [9] on master, and [7] on Kilo earlier.
> >>>
> >>>   Change [3] is looking to blacklist python-troveclient 2.1.0 on
> >>>   stable/liberty.
> >>>
> >>>   Change [4] is looking to bump the minimum python-troveclient
> >> version
> >>>   on master to 2.1.0.
> >>
> >> Right, and there was actually another for that beat me to this:
> >>
> >> https://review.openstack.org/#/c/290115/
> >>
> >>>
> >>> Here are three questions I have:
> >>>
> >>> (1) Wouldn't backward compatibility also require that you revert the
> >>> other change that removed slave_of on the server [5] ? After all,
> >>> just like a python client that calls create() with slave_of, a REST
> >>> client could call the endpoint with slave_of. What is the policy for
> >>> REST API backward compatibility?
> >>
> >> I guess it depends on the Trove team. In Nova, backward compatibility
> >> in the API is serious business and that's why we have left all sorts
> >> of warts in the v2.0 API and couldn't remove them. But with the v2.1
> >> API and microversions, we're able to move the API forward (Ironic
> >> also has microversions, and I think cinder/neutron/keystone are
> >> working on adding that support).
> >>
> >> So if maintaining backward compatibility in the trove API is
> >> important to the trove team and it's users, then yes the API change
> >> should probably be reverted. For anyone doing CD with Trove, they are
> >> already broken, but people upgrading from liberty to mitaka could save
> themselves the break.
> >>
> >>>
> >>> (2) Wouldn't [4] just block 2.1.0 in global-requirements on master
> >>> (mitaka)?
> >>
> >> I'm not sure I understand, [4] here bumps the minimum required
> >> version of python-troveclient to be 2.1.0, not block it. As noted in
> >> the review, I don't know that it's really necessary to bump to 2.1.0
> >> iff we land and release [1].
> >>
> >>>
> >>> (3) Something, potentially your patch set [2], should also fix the
> >>> test that is invoking create() with slave_of, no?
> >>
> >> [2] is stable/liberty which still has slave_of in the create API, so
> >> I don't think that needs to be fixed in stable/liberty.
> >>
> >>>
> >>> -amrith
> >>>
> >>> [1] 

Re: [openstack-dev] [Neutron] Ihar as *-aas core reviewer

[Sean M. Collins]

I probably speak for all FwaaS cores when I say - "Welcome!" 

Frankly I had just assumed he had core privileges for our repo anyway
via an inherited ACL.
-- 
Sean M. Collins

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

Re: [openstack-dev] [tc] [trove][stable] proboscis tests randomly failing in stable branches; bug 1538506

[Matt Riedemann]

On 3/9/2016 1:34 PM, Amrith Kumar wrote:

Matt,

We discussed this at the Trove meeting. Here's my current understanding of the 
situation:

1. Your change https://review.openstack.org/#/c/290048/ which reverts the trove 
client side of the change should be merged.

2. This change (the Trove API side) https://review.openstack.org/#/c/245845/ 
should also be reverted. I'm assuming that you'll submit a change for this as 
well for completeness.


I can submit a change for this.



3. We need to blacklist python-troveclient 2.1.0 on Liberty, this is your 
change https://review.openstack.org/#/c/290021/

4. We need to blacklist python-troveclient 2.1.0 on master, this is currently 
*NOT* what your change https://review.openstack.org/290168 does. I disagree with 
the approach of just increasing the minimum requirement from 1.2.0 to >=2.1.0.


I'm OK with blacklisting 2.1.0 on master and can make that change in the 
same patch.




5. We need to request a new python-troveclient. Whether it should be called 
2.1.1 or 2.2.0, I'm not positive. My thought is 2.1.1. But out of an abundance 
of caution, I'm going to look to #openstack-release/#openstack-infra for 
guidance on this.


There are no other changes to python-troveclient since 2.1.0 was released:

user@xubuntu:~/git/python-troveclient$ git log --oneline --no-merges 2.1.0..
user@xubuntu:~/git/python-troveclient$


So 2.1.1 is fine.



Thanks,

-amrith


-Original Message-
From: Matt Riedemann [mailto:mrie...@linux.vnet.ibm.com]
Sent: Wednesday, March 09, 2016 12:42 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [trove][stable] proboscis tests randomly
failing in stable branches; bug 1538506



On 3/9/2016 8:54 AM, Amrith Kumar wrote:

Matt,

As I understand it, you have 4 changes up for review.

  Change [1] seeks to revert the change [6] to python-troveclient on
  master and reinstate the slave_of parameter.

  Change [2] is doing for stable/liberty, the same things that were
  done for master in [9] on master, and [7] on Kilo earlier.

  Change [3] is looking to blacklist python-troveclient 2.1.0 on
  stable/liberty.

  Change [4] is looking to bump the minimum python-troveclient

version

  on master to 2.1.0.


Right, and there was actually another for that beat me to this:

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



Here are three questions I have:

(1) Wouldn't backward compatibility also require that you revert the
other change that removed slave_of on the server [5] ? After all, just
like a python client that calls create() with slave_of, a REST client
could call the endpoint with slave_of. What is the policy for REST API
backward compatibility?


I guess it depends on the Trove team. In Nova, backward compatibility in
the API is serious business and that's why we have left all sorts of warts
in the v2.0 API and couldn't remove them. But with the v2.1 API and
microversions, we're able to move the API forward (Ironic also has
microversions, and I think cinder/neutron/keystone are working on adding
that support).

So if maintaining backward compatibility in the trove API is important to
the trove team and it's users, then yes the API change should probably be
reverted. For anyone doing CD with Trove, they are already broken, but
people upgrading from liberty to mitaka could save themselves the break.



(2) Wouldn't [4] just block 2.1.0 in global-requirements on master
(mitaka)?


I'm not sure I understand, [4] here bumps the minimum required version of
python-troveclient to be 2.1.0, not block it. As noted in the review, I
don't know that it's really necessary to bump to 2.1.0 iff we land and
release [1].



(3) Something, potentially your patch set [2], should also fix the
test that is invoking create() with slave_of, no?


[2] is stable/liberty which still has slave_of in the create API, so I
don't think that needs to be fixed in stable/liberty.



-amrith

[1] https://review.openstack.org/290048/
[2] https://review.openstack.org/290023/
[3] https://review.openstack.org/290021/
[4] https://review.openstack.org/290168/
[5] https://review.openstack.org/#/c/245845/
[6] https://review.openstack.org/#/c/245738/
[7] https://review.openstack.org/#/c/246735/

On 03/08/2016 08:24 PM, Matt Riedemann wrote:



On 3/8/2016 4:44 PM, Matt Riedemann wrote:



On 3/8/2016 3:17 PM, Matt Riedemann wrote:



On 3/8/2016 1:18 PM, Amrith Kumar wrote:

Matt,

See inline below.

-amrith


-Original Message-
From: Matt Riedemann [mailto:mrie...@linux.vnet.ibm.com]
Sent: Tuesday, March 08, 2016 2:00 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [trove][stable] proboscis tests
randomly failing in stable branches; bug 1538506



On 3/8/2016 12:52 PM, Matt Riedemann wrote:



On 3/8/2016 12:35 PM, Amrith Kumar wrote:

Matt,

The correct solution for liberty is that we should fix the tests.
Here's why I believe that this is the case.

In pertinent part, the backtrace from your 

Re: [openstack-dev] [Horizon] Javascript linting and documentation

[Michael Krotscheck]

+1 to what Rob said.

I guess I don't see what problems is being solved by turning the rule off,
and I also don't see the harm in having more check. It does generate a lot
of warnings, but invoking `npm run lint -- --quiet` gets rid of those.
Also, from my experience, sphinx-based doc builds are notoriously
permissive about bad formatting. Eslint's stricter jsdoc checks would add
an additional safety net.

However, if you're working on this with the docs team, then the result
should be applicable to the entirety of openstack - meaning that once your
work is complete, it may make sense to turn the rule off globally.

Michael

On Wed, Mar 9, 2016 at 11:14 AM Rob Cresswell (rcresswe) 
wrote:

> If possible, I’d really prefer we left linting work to Newton. It’ll be
> good to get it to a more usable state again, but we ought to be focusing on
> thoroughly checking the new Launch Instance for bugs and edge usage cases,
> as well as the outstanding bugs and blueprints targeted at RC1 (
> https://launchpad.net/horizon/+milestone/mitaka-rc1). This is a great
> opportunity to prove that the Angular rewrites are fully capable of
> providing an improved experience, and we should be capitalising on that.
>
> Rob
>
>
> On 9 Mar 2016, at 02:25, Richard Jones  wrote:
>
> Hey all,
>
> I started looking into fixing the wall of "npm run lint" warnings today
> and quickly noticed that about 85% of the "linting" warnings were about
> jsdoc. We have significant issues around jsdoc anyway and we're supposed to
> be using Sphinx anyway[1].
>
> Some Horizon folks will know that I've been investigating generating
> publishable documentation for our Javascript code for some time. Most of
> the tools either don't work (dgeni) or produce pretty unusable output for a
> project our size (jsdoc and grunt-ngdocs). I am about to investigate Sphinx
> in collaboration with the docs team.
>
> Regardless, I believe that the documentation generation should generate
> errors about that documentation, not the code linter. Once we actually get
> a documentation generator going. Until then, we don't even know what syntax
> the documentation should follow.
>
> I've proposed a change which just turns jsdoc "linting" off[2]. At the
> moment, it is less than useful (the noise drowns out any other, legitimate
> linting).
>
>
>  Richard
>
>
> [1] http://governance.openstack.org/reference/cti/javascript-cti.html
> [2] https://review.openstack.org/#/c/290235/
>
> __
> OpenStack Development Mailing 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] [release][all][ptl] preparing to create stable/mitaka branches for libraries

[Doug Hellmann]

Excerpts from Flavio Percoco's message of 2016-03-09 14:55:00 -0400:
> On 09/03/16 13:41 -0500, Amrith Kumar wrote:
> >Doug,
> >
> >>> openstack/python-troveclient 2.1.0
> >
> >Trove isn't there yet. You are aware of the conversation(s) we're having 
> >about this, and there are two.
> >
> >One is the FFE which requires a client change, and the second is the 
> >backwards compatibility issue that Matt raised yesterday.
> 
> Will those changes require a major release?
> 
> If not, it's still fine to create the branch and then release a minor (or a
> patch) release from the stable branch (after the patches have been backported
> there).

We do not want features released from the stable branch. We can wait to
create the Trove client branch.

Doug

> 
> Flavio
> 
> >Thanks,
> >
> >-amrith
> >
> >--
> >Amrith Kumar, CTO   | amr...@tesora.com
> >Tesora, Inc | @amrithkumar
> >125 CambridgePark Drive, Suite 400  | http://www.tesora.com
> >Cambridge, MA. 02140| GPG: 0x5e48849a9d21a29b
> >
> >On 03/09/2016 12:26 PM, Doug Hellmann wrote:
> >> It's time to start opening the stable branches for libraries. I've
> >> prepared a list of repositories and the proposed versions from which
> >> we will create stable/mitaka branches, and need each team to sign off on
> >> the versions. If you know you intend to release a bug fix version in
> >> the next couple of days, we can wait to avoid having to backport
> >> patches, but otherwise we should go ahead and create the branches.
> >>
> >> I will process each repository as I hear from the owning team.
> >>
> >> openstack/ceilometermiddleware 0.4.0
> >> openstack/django_openstack_auth 2.2.0
> >> openstack/glance_store 0.13.0
> >> openstack/ironic-lib 1.1.0
> >> openstack/keystoneauth 2.3.0
> >> openstack/keystonemiddleware 4.3.0
> >> openstack/os-brick 1.1.0
> >> openstack/os-client-config 1.16.0
> >> openstack/pycadf 2.1.0
> >> openstack/python-barbicanclient 4.0.0
> >> openstack/python-brick-cinderclient-ext 0.1.0
> >> openstack/python-ceilometerclient 2.3.0
> >> openstack/python-cinderclient 1.6.0
> >> openstack/cliff 2.0.0
> >> openstack/python-designateclient 2.0.0
> >> openstack/python-glanceclient 2.0.0
> >> openstack/python-heatclient 1.0.0
> >> openstack/python-ironic-inspector-client 1.5.0
> >> openstack/python-ironicclient 1.2.0
> >> openstack/python-keystoneclient 2.3.1
> >> openstack/python-manilaclient 1.8.0
> >> openstack/python-neutronclient 4.1.1
> >> openstack/python-novaclient 3.3.0
> >> openstack/python-saharaclient 0.13.0
> >> openstack/python-swiftclient 3.0.0
> >> openstack/python-troveclient 2.1.0
> >> openstack/python-zaqarclient 1.0.0
> >>
> >> __
> >> OpenStack Development Mailing 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] [release][all][ptl] preparing to create stable/mitaka branches for libraries

[Amrith Kumar]

Flavio,

I believe that you are correct and that we don't need a major release. 

However, just to be positive, and out of an abundance of caution, I'm going to 
be looking to #openstack-infra or #openstack-release for confirmation.

Thanks,

-amrith

> -Original Message-
> From: Flavio Percoco [mailto:fla...@redhat.com]
> Sent: Wednesday, March 09, 2016 1:55 PM
> To: OpenStack Development Mailing List (not for usage questions)
> 
> Subject: Re: [openstack-dev] [release][all][ptl] preparing to create
> stable/mitaka branches for libraries
> 
> On 09/03/16 13:41 -0500, Amrith Kumar wrote:
> >Doug,
> >
> >>> openstack/python-troveclient 2.1.0
> >
> >Trove isn't there yet. You are aware of the conversation(s) we're having
> about this, and there are two.
> >
> >One is the FFE which requires a client change, and the second is the
> backwards compatibility issue that Matt raised yesterday.
> 
> Will those changes require a major release?
> 
> If not, it's still fine to create the branch and then release a minor (or
> a
> patch) release from the stable branch (after the patches have been
> backported there).
> 
> Flavio
> 
> >Thanks,
> >
> >-amrith
> >
> >--
> >Amrith Kumar, CTO   | amr...@tesora.com
> >Tesora, Inc | @amrithkumar
> >125 CambridgePark Drive, Suite 400  | http://www.tesora.com
> >Cambridge, MA. 02140| GPG: 0x5e48849a9d21a29b
> >
> >On 03/09/2016 12:26 PM, Doug Hellmann wrote:
> >> It's time to start opening the stable branches for libraries. I've
> >> prepared a list of repositories and the proposed versions from which
> >> we will create stable/mitaka branches, and need each team to sign off
> >> on the versions. If you know you intend to release a bug fix version
> >> in the next couple of days, we can wait to avoid having to backport
> >> patches, but otherwise we should go ahead and create the branches.
> >>
> >> I will process each repository as I hear from the owning team.
> >>
> >> openstack/ceilometermiddleware 0.4.0
> >> openstack/django_openstack_auth 2.2.0 openstack/glance_store 0.13.0
> >> openstack/ironic-lib 1.1.0 openstack/keystoneauth 2.3.0
> >> openstack/keystonemiddleware 4.3.0 openstack/os-brick 1.1.0
> >> openstack/os-client-config 1.16.0 openstack/pycadf 2.1.0
> >> openstack/python-barbicanclient 4.0.0
> >> openstack/python-brick-cinderclient-ext 0.1.0
> >> openstack/python-ceilometerclient 2.3.0 openstack/python-cinderclient
> >> 1.6.0 openstack/cliff 2.0.0 openstack/python-designateclient 2.0.0
> >> openstack/python-glanceclient 2.0.0 openstack/python-heatclient 1.0.0
> >> openstack/python-ironic-inspector-client 1.5.0
> >> openstack/python-ironicclient 1.2.0 openstack/python-keystoneclient
> >> 2.3.1 openstack/python-manilaclient 1.8.0
> >> openstack/python-neutronclient 4.1.1 openstack/python-novaclient
> >> 3.3.0 openstack/python-saharaclient 0.13.0
> >> openstack/python-swiftclient 3.0.0 openstack/python-troveclient 2.1.0
> >> openstack/python-zaqarclient 1.0.0
> >>
> >> _
> >> _ OpenStack Development Mailing List (not for usage questions)
> >> Unsubscribe:
> >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> 
> 
> 
> 
> >___
> >___ OpenStack Development Mailing List (not for usage questions)
> >Unsubscribe:
> >openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> --
> @flaper87
> Flavio Percoco
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc] [trove][stable] proboscis tests randomly failing in stable branches; bug 1538506

[Amrith Kumar]

Matt,

We discussed this at the Trove meeting. Here's my current understanding of the 
situation:

1. Your change https://review.openstack.org/#/c/290048/ which reverts the trove 
client side of the change should be merged.

2. This change (the Trove API side) https://review.openstack.org/#/c/245845/ 
should also be reverted. I'm assuming that you'll submit a change for this as 
well for completeness.

3. We need to blacklist python-troveclient 2.1.0 on Liberty, this is your 
change https://review.openstack.org/#/c/290021/

4. We need to blacklist python-troveclient 2.1.0 on master, this is currently 
*NOT* what your change https://review.openstack.org/290168 does. I disagree 
with the approach of just increasing the minimum requirement from 1.2.0 to 
>=2.1.0. 

5. We need to request a new python-troveclient. Whether it should be called 
2.1.1 or 2.2.0, I'm not positive. My thought is 2.1.1. But out of an abundance 
of caution, I'm going to look to #openstack-release/#openstack-infra for 
guidance on this.

Thanks,

-amrith

> -Original Message-
> From: Matt Riedemann [mailto:mrie...@linux.vnet.ibm.com]
> Sent: Wednesday, March 09, 2016 12:42 PM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [trove][stable] proboscis tests randomly
> failing in stable branches; bug 1538506
> 
> 
> 
> On 3/9/2016 8:54 AM, Amrith Kumar wrote:
> > Matt,
> >
> > As I understand it, you have 4 changes up for review.
> >
> >  Change [1] seeks to revert the change [6] to python-troveclient on
> >  master and reinstate the slave_of parameter.
> >
> >  Change [2] is doing for stable/liberty, the same things that were
> >  done for master in [9] on master, and [7] on Kilo earlier.
> >
> >  Change [3] is looking to blacklist python-troveclient 2.1.0 on
> >  stable/liberty.
> >
> >  Change [4] is looking to bump the minimum python-troveclient
> version
> >  on master to 2.1.0.
> 
> Right, and there was actually another for that beat me to this:
> 
> https://review.openstack.org/#/c/290115/
> 
> >
> > Here are three questions I have:
> >
> > (1) Wouldn't backward compatibility also require that you revert the
> > other change that removed slave_of on the server [5] ? After all, just
> > like a python client that calls create() with slave_of, a REST client
> > could call the endpoint with slave_of. What is the policy for REST API
> > backward compatibility?
> 
> I guess it depends on the Trove team. In Nova, backward compatibility in
> the API is serious business and that's why we have left all sorts of warts
> in the v2.0 API and couldn't remove them. But with the v2.1 API and
> microversions, we're able to move the API forward (Ironic also has
> microversions, and I think cinder/neutron/keystone are working on adding
> that support).
> 
> So if maintaining backward compatibility in the trove API is important to
> the trove team and it's users, then yes the API change should probably be
> reverted. For anyone doing CD with Trove, they are already broken, but
> people upgrading from liberty to mitaka could save themselves the break.
> 
> >
> > (2) Wouldn't [4] just block 2.1.0 in global-requirements on master
> > (mitaka)?
> 
> I'm not sure I understand, [4] here bumps the minimum required version of
> python-troveclient to be 2.1.0, not block it. As noted in the review, I
> don't know that it's really necessary to bump to 2.1.0 iff we land and
> release [1].
> 
> >
> > (3) Something, potentially your patch set [2], should also fix the
> > test that is invoking create() with slave_of, no?
> 
> [2] is stable/liberty which still has slave_of in the create API, so I
> don't think that needs to be fixed in stable/liberty.
> 
> >
> > -amrith
> >
> > [1] https://review.openstack.org/290048/
> > [2] https://review.openstack.org/290023/
> > [3] https://review.openstack.org/290021/
> > [4] https://review.openstack.org/290168/
> > [5] https://review.openstack.org/#/c/245845/
> > [6] https://review.openstack.org/#/c/245738/
> > [7] https://review.openstack.org/#/c/246735/
> >
> > On 03/08/2016 08:24 PM, Matt Riedemann wrote:
> >>
> >>
> >> On 3/8/2016 4:44 PM, Matt Riedemann wrote:
> >>>
> >>>
> >>> On 3/8/2016 3:17 PM, Matt Riedemann wrote:
> 
> 
>  On 3/8/2016 1:18 PM, Amrith Kumar wrote:
> > Matt,
> >
> > See inline below.
> >
> > -amrith
> >
> >> -Original Message-
> >> From: Matt Riedemann [mailto:mrie...@linux.vnet.ibm.com]
> >> Sent: Tuesday, March 08, 2016 2:00 PM
> >> To: openstack-dev@lists.openstack.org
> >> Subject: Re: [openstack-dev] [trove][stable] proboscis tests
> >> randomly failing in stable branches; bug 1538506
> >>
> >>
> >>
> >> On 3/8/2016 12:52 PM, Matt Riedemann wrote:
> >>>
> >>>
> >>> On 3/8/2016 12:35 PM, Amrith Kumar wrote:
>  Matt,
> 
>  The correct solution for liberty is that we should fix the tests.
>  Here's why I believe 

Re: [openstack-dev] {openstack-dev][tc] Leadership training proposal/info

[Colette Alexander]

On Wed, Mar 9, 2016 at 9:32 AM, Doug Hellmann  wrote:

> Excerpts from Sean Dague's message of 2016-03-09 12:22:08 -0500:
> > On 03/09/2016 11:36 AM, Doug Hellmann wrote:
> > > Excerpts from Colette Alexander's message of 2016-03-08 14:34:19 -0800:
> > >> On Tue, Mar 8, 2016 at 1:37 PM, Doug Hellmann 
> wrote:
> > > My interest in attending is based solely on the number of other TC
> > > members going. If a majority go, I feel I need to attend to have a good
> > > common frame of reference for future discussions. If only one or two
> > > folks go and prepare some sort of evaluation, I can skip the trip and
> > > only attend a future course if the evaluators recommend it.
>

I understand that feeling of not wanting to be left out if a majority of
folks are attending - that, I guess, is a side-concern of having seen more
interest in it than I initially expected there would be. Certainly, no one
has done a solid commit yet on the dates - I was going to have to wait
until after the April TC election was over to ask for one, anyhow. By then,
I was hoping to have a few options for itineraries/schedules to send out to
folks to get feedback/preferences on, and figured looking at a sample
schedule(s) might lead some to either decide to skip the trip or be more
interested in attending. Currently, the potential schedules being sent back
and forth between the trainers there have the daytime (8 AM - 5 PM) pretty
booked up with training, with lunch and evenings open, so an accidental
TC-midcycle could definitely occur after-hours. I think
preventing-a-mid-cycle-feeling is also a stronger case for letting TC
members sign up first, but attempting to leave some space open for other
interested members of the community, which I think could only help broaden
the perspectives on all the conversations happening there. As Sean
mentioned, showing up out of obligation rather than genuine interest would
probably be a huge drag for everyone - even skeptics will have an
interest/reason to be there.

I know leading that sort of session is difficult. Is that what
> ZingTrain is offering to do? My understanding from the earlier,
> off-list, discussion was that this was their pre-canned training
> seminar based on one of the books they have available, and not a
> customized facilitation of a discussion about our needs.  Colette,
> can you clarify?


So currently, there are now 3 different 2-day itineraries I've seen, that
I'm ironing out with the trainers (who've spent a few hours on the phone
with me getting background on the community and doing research on the
community on their own) - those itineraries include the standard 2-day
Leading with Zing! training, a brand new Managing Ourselves training, and a
custom 1 day of Leading with Zing! + 1 day Managing Ourselves that I think
might give the most interesting set of shared experiences to start a
conversation about leadership with. FWIW - my understanding of the
activities in the itinerary is that they're inherently structured to be
action/information intake and then group reflection - so there's
conversation built into the training itself. Additionally, I discussed with
them the idea that this would be about facilitating a larger conversation
about the community, to be led by attendees, and they offered to switch up
training on the fly to accommodate where the conversation led and/or add an
extra day post-training with the trainer as facilitator purely to have
reflection/discussion about what comes next. When I thought this might be
6-8 people just before the Summit, that day seemed to not be as necessary
as creating flexibility in the training schedule itself. But if we're
looking at ~14-17 people, and we're not running into the Summit directly
after, it might be more worthwhile. Thoughts on that?


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

Re: [openstack-dev] [horizon] Proposal to add Diana Whitten tohorizon-core

[Michael Krotscheck]

+1. Another vote in favor of ditching django altogether is good by me :)

On Wed, Mar 9, 2016 at 11:25 AM Thai Q Tran  wrote:

> Big +1 from me, thanks for all the hard work Diana!
>
>
> - Original message -
> From: David Lyle 
> To: OpenStack Development Mailing List 
> Cc:
> Subject: [openstack-dev] [horizon] Proposal to add Diana Whitten to
> horizon-core
> Date: Tue, Mar 8, 2016 2:07 PM
>
> I propose adding Diana Whitten[1] to horizon-core.
>
> Diana is an active reviewer, contributor and community member. Over
> the past couple of releases, Diana has driven extensive changes around
> theme-ability in Horizon and drastically increased the standardization
> of our use of bootstrap. During this time, Diana has also provided
> valuable reviews to keep us on the straight and narrow preventing our
> continued abuse of defenseless web technologies.
>
> Please respond with comments, +1s, or objections by Friday.
>
> Thanks,
> David
>
> [1]
> http://stackalytics.com/?module=horizon-group_id=hurgleburgler=all
>
> __
> OpenStack Development Mailing 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] [horizon] Proposal to add Diana Whitten tohorizon-core

[Thai Q Tran]

Big +1 from me, thanks for all the hard work Diana!
 
- Original message -From: David Lyle To: OpenStack Development Mailing List Cc:Subject: [openstack-dev] [horizon] Proposal to add Diana Whitten to horizon-coreDate: Tue, Mar 8, 2016 2:07 PM 
I propose adding Diana Whitten[1] to horizon-core.Diana is an active reviewer, contributor and community member. Overthe past couple of releases, Diana has driven extensive changes aroundtheme-ability in Horizon and drastically increased the standardizationof our use of bootstrap. During this time, Diana has also providedvaluable reviews to keep us on the straight and narrow preventing ourcontinued abuse of defenseless web technologies.Please respond with comments, +1s, or objections by Friday.Thanks,David[1] http://stackalytics.com/?module=horizon-group_id=hurgleburgler=all__OpenStack Development Mailing List (not for usage questions)Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
 


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

Re: [openstack-dev] [Horizon] Javascript linting and documentation

[Rob Cresswell (rcresswe)]

If possible, I’d really prefer we left linting work to Newton. It’ll be good to 
get it to a more usable state again, but we ought to be focusing on thoroughly 
checking the new Launch Instance for bugs and edge usage cases, as well as the 
outstanding bugs and blueprints targeted at RC1 
(https://launchpad.net/horizon/+milestone/mitaka-rc1). This is a great 
opportunity to prove that the Angular rewrites are fully capable of providing 
an improved experience, and we should be capitalising on that.

Rob


On 9 Mar 2016, at 02:25, Richard Jones 
> wrote:

Hey all,

I started looking into fixing the wall of "npm run lint" warnings today and 
quickly noticed that about 85% of the "linting" warnings were about jsdoc. We 
have significant issues around jsdoc anyway and we're supposed to be using 
Sphinx anyway[1].

Some Horizon folks will know that I've been investigating generating 
publishable documentation for our Javascript code for some time. Most of the 
tools either don't work (dgeni) or produce pretty unusable output for a project 
our size (jsdoc and grunt-ngdocs). I am about to investigate Sphinx in 
collaboration with the docs team.

Regardless, I believe that the documentation generation should generate errors 
about that documentation, not the code linter. Once we actually get a 
documentation generator going. Until then, we don't even know what syntax the 
documentation should follow.

I've proposed a change which just turns jsdoc "linting" off[2]. At the moment, 
it is less than useful (the noise drowns out any other, legitimate linting).


 Richard


[1] http://governance.openstack.org/reference/cti/javascript-cti.html
[2] https://review.openstack.org/#/c/290235/

__
OpenStack Development Mailing 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] [trove] OpenStack Trove meeting minutes (2016-03-09)

[Amrith Kumar]

Minutes of the OpenStack Trove meeting held today are at:

http://eavesdrop.openstack.org/meetings/trove/2016/trove.2016-03-09-18.00.html

--
Amrith Kumar, CTO   | amr...@tesora.com
Tesora, Inc | @amrithkumar
125 CambridgePark Drive, Suite 400  | http://www.tesora.com
Cambridge, MA. 02140| GPG: 0x5e48849a9d21a29b 




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

Re: [openstack-dev] [release][all][ptl] preparing to create stable/mitaka branches for libraries

[Flavio Percoco]

On 09/03/16 13:41 -0500, Amrith Kumar wrote:

Doug,


openstack/python-troveclient 2.1.0


Trove isn't there yet. You are aware of the conversation(s) we're having about 
this, and there are two.

One is the FFE which requires a client change, and the second is the backwards 
compatibility issue that Matt raised yesterday.


Will those changes require a major release?

If not, it's still fine to create the branch and then release a minor (or a
patch) release from the stable branch (after the patches have been backported
there).

Flavio


Thanks,

-amrith

--
Amrith Kumar, CTO   | amr...@tesora.com
Tesora, Inc | @amrithkumar
125 CambridgePark Drive, Suite 400  | http://www.tesora.com
Cambridge, MA. 02140| GPG: 0x5e48849a9d21a29b

On 03/09/2016 12:26 PM, Doug Hellmann wrote:

It's time to start opening the stable branches for libraries. I've
prepared a list of repositories and the proposed versions from which
we will create stable/mitaka branches, and need each team to sign off on
the versions. If you know you intend to release a bug fix version in
the next couple of days, we can wait to avoid having to backport
patches, but otherwise we should go ahead and create the branches.

I will process each repository as I hear from the owning team.

openstack/ceilometermiddleware 0.4.0
openstack/django_openstack_auth 2.2.0
openstack/glance_store 0.13.0
openstack/ironic-lib 1.1.0
openstack/keystoneauth 2.3.0
openstack/keystonemiddleware 4.3.0
openstack/os-brick 1.1.0
openstack/os-client-config 1.16.0
openstack/pycadf 2.1.0
openstack/python-barbicanclient 4.0.0
openstack/python-brick-cinderclient-ext 0.1.0
openstack/python-ceilometerclient 2.3.0
openstack/python-cinderclient 1.6.0
openstack/cliff 2.0.0
openstack/python-designateclient 2.0.0
openstack/python-glanceclient 2.0.0
openstack/python-heatclient 1.0.0
openstack/python-ironic-inspector-client 1.5.0
openstack/python-ironicclient 1.2.0
openstack/python-keystoneclient 2.3.1
openstack/python-manilaclient 1.8.0
openstack/python-neutronclient 4.1.1
openstack/python-novaclient 3.3.0
openstack/python-saharaclient 0.13.0
openstack/python-swiftclient 3.0.0
openstack/python-troveclient 2.1.0
openstack/python-zaqarclient 1.0.0

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









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



--
@flaper87
Flavio Percoco


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

Re: [openstack-dev] The #openstack-packaging channel requires an invite?

[Joshua Harlow]

On 03/09/2016 10:28 AM, Matt Riedemann wrote:

Is that still a thing and if so, do they congregate somewhere? Because
*that's* where I think people need to go, not the #openstack-stable
channel.


There is an #openstack-anvil channel,

The anvil project had/has similar goals of being a cross-distro 
packager: https://anvil.readthedocs.org/en/latest/topics/summary.html


U can feel free to use the #openstack-anvil channel if u so desire ;)

Overall though, I agree, it does seem odd that #openstack-packaging got 
moved to #openstack-stable since to me the two things are different (one 
is about packaging things, one is about stable openstack releases?) but 
maybe I'm also missing some context.


-Josh

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

Re: [openstack-dev] [Horizon] How do we move forward with xstatic releases?

[Michael Krotscheck]

On Wed, Mar 9, 2016 at 7:58 AM Monty Taylor  wrote:

>
> > SOLUTION 4: vendor the javascript
> >
> > Heh.
>
> Heh indeed.
>
> SOLUTION 4.alt: use npm/bower instead of xstatic to pull the javascript.
>

+1. Let's move the codebase forward, instead of continuing to build hacky
workarounds for poor past architectural decisions.

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

Re: [openstack-dev] The #openstack-packaging channel requires an invite?

[Andreas Jaeger]

On 03/09/2016 07:28 PM, Matt Riedemann wrote:
> Ha, the irony.
> 
> OK, so I thought awhile back, around YVR summit time, there was a group
> of different packagers from different distros (debian/red
> hat/fedora/suse) that were working together on some common tooling.
> 
> Is that still a thing and if so, do they congregate somewhere? Because
> *that's* where I think people need to go, not the #openstack-stable
> channel.
> 

#openstack-rpm-packaging for the RPM side,

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


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

Re: [openstack-dev] The #openstack-packaging channel requires an invite?

[Andreas Jaeger]

On 03/09/2016 06:48 PM, Matt Riedemann wrote:
> Someone showed up in the -stable channel this morning asking for help
> with packaging. I gather they were there because the IRC wiki [1] says
> the #openstack-stable channel is also for packaging discussions, given
> -stable originated from distro people.
> 
> I redirected them to https://wiki.openstack.org/wiki/Packaging which
> points to https://wiki.openstack.org/wiki/PackagerResources which says:
> 
> "The #openstack-packaging channel on Freenode is available for packaging
> collaboration and discussion."
> 
> Great!
> 
> However, you have to apparently be invited to join the elite
> #openstack-packaging channel.
> 
> What gives? Is that channel dead? Is there something else? Is there a
> secret handshake I can learn to palms to grease to get in?
> 
> [1] https://wiki.openstack.org/wiki/IRC
> 

Looking in project-config, I see #openstack-rpm-packaging configured for
RPM packaging discussion - as only registered channel for packaging
discussion,

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


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

Re: [openstack-dev] [release][all][ptl] preparing to create stable/mitaka branches for libraries

[Amrith Kumar]

Doug,

>> openstack/python-troveclient 2.1.0

Trove isn't there yet. You are aware of the conversation(s) we're having about 
this, and there are two.

One is the FFE which requires a client change, and the second is the backwards 
compatibility issue that Matt raised yesterday.

Thanks,

-amrith

--
Amrith Kumar, CTO   | amr...@tesora.com
Tesora, Inc | @amrithkumar
125 CambridgePark Drive, Suite 400  | http://www.tesora.com
Cambridge, MA. 02140| GPG: 0x5e48849a9d21a29b 

On 03/09/2016 12:26 PM, Doug Hellmann wrote:
> It's time to start opening the stable branches for libraries. I've
> prepared a list of repositories and the proposed versions from which
> we will create stable/mitaka branches, and need each team to sign off on
> the versions. If you know you intend to release a bug fix version in
> the next couple of days, we can wait to avoid having to backport
> patches, but otherwise we should go ahead and create the branches.
>
> I will process each repository as I hear from the owning team.
>
> openstack/ceilometermiddleware 0.4.0
> openstack/django_openstack_auth 2.2.0
> openstack/glance_store 0.13.0
> openstack/ironic-lib 1.1.0
> openstack/keystoneauth 2.3.0
> openstack/keystonemiddleware 4.3.0
> openstack/os-brick 1.1.0
> openstack/os-client-config 1.16.0
> openstack/pycadf 2.1.0
> openstack/python-barbicanclient 4.0.0
> openstack/python-brick-cinderclient-ext 0.1.0
> openstack/python-ceilometerclient 2.3.0
> openstack/python-cinderclient 1.6.0
> openstack/cliff 2.0.0
> openstack/python-designateclient 2.0.0
> openstack/python-glanceclient 2.0.0
> openstack/python-heatclient 1.0.0
> openstack/python-ironic-inspector-client 1.5.0
> openstack/python-ironicclient 1.2.0
> openstack/python-keystoneclient 2.3.1
> openstack/python-manilaclient 1.8.0
> openstack/python-neutronclient 4.1.1
> openstack/python-novaclient 3.3.0
> openstack/python-saharaclient 0.13.0
> openstack/python-swiftclient 3.0.0
> openstack/python-troveclient 2.1.0
> openstack/python-zaqarclient 1.0.0
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




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

Re: [openstack-dev] [release][all][ptl] preparing to create stable/mitaka branches for libraries

[Doug Hellmann]

Excerpts from Doug Hellmann's message of 2016-03-09 12:26:18 -0500:
> It's time to start opening the stable branches for libraries. I've
> prepared a list of repositories and the proposed versions from which
> we will create stable/mitaka branches, and need each team to sign off on
> the versions. If you know you intend to release a bug fix version in
> the next couple of days, we can wait to avoid having to backport
> patches, but otherwise we should go ahead and create the branches.
> 
> I will process each repository as I hear from the owning team.
> 
> openstack/ceilometermiddleware 0.4.0
> openstack/django_openstack_auth 2.2.0
> openstack/glance_store 0.13.0
> openstack/ironic-lib 1.1.0
> openstack/keystoneauth 2.3.0
> openstack/keystonemiddleware 4.3.0
> openstack/os-brick 1.1.0
> openstack/os-client-config 1.16.0
> openstack/pycadf 2.1.0
> openstack/python-barbicanclient 4.0.0
> openstack/python-brick-cinderclient-ext 0.1.0
> openstack/python-ceilometerclient 2.3.0
> openstack/python-cinderclient 1.6.0
> openstack/cliff 2.0.0
> openstack/python-designateclient 2.0.0
> openstack/python-glanceclient 2.0.0
> openstack/python-heatclient 1.0.0
> openstack/python-ironic-inspector-client 1.5.0
> openstack/python-ironicclient 1.2.0
> openstack/python-keystoneclient 2.3.1
> openstack/python-manilaclient 1.8.0
> openstack/python-neutronclient 4.1.1
> openstack/python-novaclient 3.3.0
> openstack/python-saharaclient 0.13.0
> openstack/python-swiftclient 3.0.0
> openstack/python-troveclient 2.1.0
> openstack/python-zaqarclient 1.0.0

One of the extra steps we're taking this time when creating the branch
is trying to propose an automated update to the release notes build to
include the new branch in the output. Based on a couple of the patches I
see now, there are some bad assumptions about indentation and toctree
content ordering in the part of the script that creates those patches.
Please review them carefully, and take them over and fix them if they
fail to build properly. We'll work on improving the script for the next
cycle.

Doug

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

Re: [openstack-dev] The #openstack-packaging channel requires an invite?

[Matt Riedemann]

On 3/9/2016 11:57 AM, Louis Taylor wrote:

On Wed, Mar 9, 2016 at 5:48 PM, Matt Riedemann
 wrote:

Someone showed up in the -stable channel this morning asking for help with
packaging. I gather they were there because the IRC wiki [1] says the
#openstack-stable channel is also for packaging discussions, given -stable
originated from distro people.

I redirected them to https://wiki.openstack.org/wiki/Packaging which points
to https://wiki.openstack.org/wiki/PackagerResources which says:

"The #openstack-packaging channel on Freenode is available for packaging
collaboration and discussion."

Great!

However, you have to apparently be invited to join the elite
#openstack-packaging channel.

What gives? Is that channel dead? Is there something else? Is there a secret
handshake I can learn to palms to grease to get in?


 From ChanServ:

17:55:03 -ChanServ(ChanServ@services.)- Information on #openstack-packaging:
17:55:03 -ChanServ(ChanServ@services.)- Registered : Nov 11 18:59:55
2011 (4y 17w 0d ago)
17:55:03 -ChanServ(ChanServ@services.)- Last used  : (about 75 weeks ago)
17:55:03 -ChanServ(ChanServ@services.)- Mode lock  : +imnstf #openstack-stable
17:55:03 -ChanServ(ChanServ@services.)- Flags  : KEEPTOPIC
TOPICLOCK GUARD PRIVATE
17:55:03 -ChanServ(ChanServ@services.)- *** End of Info ***

It doesn't look like it's been used in a long time (75 weeks).

Louis

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



Ha, the irony.

OK, so I thought awhile back, around YVR summit time, there was a group 
of different packagers from different distros (debian/red 
hat/fedora/suse) that were working together on some common tooling.


Is that still a thing and if so, do they congregate somewhere? Because 
*that's* where I think people need to go, not the #openstack-stable channel.


--

Thanks,

Matt Riedemann


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

Re: [openstack-dev] [Horizon] How do we move forward with xstatic releases?

[Robert Collins]

On 10 Mar 2016 2:58 AM, "Radomir Dopieralski" 
wrote:
>
> On 03/09/2016 04:43 PM, Serg Melikyan wrote:
>>>
>>> This is exactly my first thought. The plugins *must* depend on Horizon,
>>> and they have to use the same versions of XStatic packages anyways,
>
> >> so why specify the dependencies twice?
>>
>>
>> Plugins may require different xstatic library, which is not even used
>> by Horizon. Issue raised by Richard exists for plugins too, not only
>> for Horizon itself.
>
>
> How would such an xstatic library conflict with what is in Horizon then,
> though?

Say there are two xstatic libraries, a and b. B depends on a. Horizon
depends only on a. Plugin-foo depends on b. Horizon updates to a version of
a that the version of b consumed by plugin-foo is not compatible with.

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] [release][all][ptl] preparing to create stable/mitaka branches for libraries

[Steve Martinelli]

All systems are go for:

openstack/keystoneauth 2.3.0
openstack/keystonemiddleware 4.3.0
openstack/pycadf 2.1.0
openstack/python-keystoneclient 2.3.1




From:   Doug Hellmann 
To: openstack-dev 
Date:   2016/03/09 06:28 PM
Subject:[openstack-dev] [release][all][ptl] preparing to create
stable/mitaka branches for libraries



It's time to start opening the stable branches for libraries. I've
prepared a list of repositories and the proposed versions from which
we will create stable/mitaka branches, and need each team to sign off on
the versions. If you know you intend to release a bug fix version in
the next couple of days, we can wait to avoid having to backport
patches, but otherwise we should go ahead and create the branches.

I will process each repository as I hear from the owning team.

openstack/ceilometermiddleware 0.4.0
openstack/django_openstack_auth 2.2.0
openstack/glance_store 0.13.0
openstack/ironic-lib 1.1.0
openstack/keystoneauth 2.3.0
openstack/keystonemiddleware 4.3.0
openstack/os-brick 1.1.0
openstack/os-client-config 1.16.0
openstack/pycadf 2.1.0
openstack/python-barbicanclient 4.0.0
openstack/python-brick-cinderclient-ext 0.1.0
openstack/python-ceilometerclient 2.3.0
openstack/python-cinderclient 1.6.0
openstack/cliff 2.0.0
openstack/python-designateclient 2.0.0
openstack/python-glanceclient 2.0.0
openstack/python-heatclient 1.0.0
openstack/python-ironic-inspector-client 1.5.0
openstack/python-ironicclient 1.2.0
openstack/python-keystoneclient 2.3.1
openstack/python-manilaclient 1.8.0
openstack/python-neutronclient 4.1.1
openstack/python-novaclient 3.3.0
openstack/python-saharaclient 0.13.0
openstack/python-swiftclient 3.0.0
openstack/python-troveclient 2.1.0
openstack/python-zaqarclient 1.0.0

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



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

[openstack-dev] [Neutron] stable/mitaka branch imminent for the client

[Armando M.]

Folks,

Please see [1]. I gave Doug the go-ahead.

Cheers,
Armando

[1]
http://lists.openstack.org/pipermail/openstack-dev/2016-March/088853.html
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [release][all][ptl] preparing to create stable/mitaka branches for libraries

[Armando M.]

Good to go with:

openstack/python-neutronclient 4.1.1

Thanks,
Armando

On 9 March 2016 at 09:26, Doug Hellmann  wrote:

> It's time to start opening the stable branches for libraries. I've
> prepared a list of repositories and the proposed versions from which
> we will create stable/mitaka branches, and need each team to sign off on
> the versions. If you know you intend to release a bug fix version in
> the next couple of days, we can wait to avoid having to backport
> patches, but otherwise we should go ahead and create the branches.
>
> I will process each repository as I hear from the owning team.
>
> openstack/ceilometermiddleware 0.4.0
> openstack/django_openstack_auth 2.2.0
> openstack/glance_store 0.13.0
> openstack/ironic-lib 1.1.0
> openstack/keystoneauth 2.3.0
> openstack/keystonemiddleware 4.3.0
> openstack/os-brick 1.1.0
> openstack/os-client-config 1.16.0
> openstack/pycadf 2.1.0
> openstack/python-barbicanclient 4.0.0
> openstack/python-brick-cinderclient-ext 0.1.0
> openstack/python-ceilometerclient 2.3.0
> openstack/python-cinderclient 1.6.0
> openstack/cliff 2.0.0
> openstack/python-designateclient 2.0.0
> openstack/python-glanceclient 2.0.0
> openstack/python-heatclient 1.0.0
> openstack/python-ironic-inspector-client 1.5.0
> openstack/python-ironicclient 1.2.0
> openstack/python-keystoneclient 2.3.1
> openstack/python-manilaclient 1.8.0
> openstack/python-neutronclient 4.1.1
> openstack/python-novaclient 3.3.0
> openstack/python-saharaclient 0.13.0
> openstack/python-swiftclient 3.0.0
> openstack/python-troveclient 2.1.0
> openstack/python-zaqarclient 1.0.0
>
> __
> OpenStack Development Mailing 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] The #openstack-packaging channel requires an invite?

[Louis Taylor]

On Wed, Mar 9, 2016 at 5:48 PM, Matt Riedemann
 wrote:
> Someone showed up in the -stable channel this morning asking for help with
> packaging. I gather they were there because the IRC wiki [1] says the
> #openstack-stable channel is also for packaging discussions, given -stable
> originated from distro people.
>
> I redirected them to https://wiki.openstack.org/wiki/Packaging which points
> to https://wiki.openstack.org/wiki/PackagerResources which says:
>
> "The #openstack-packaging channel on Freenode is available for packaging
> collaboration and discussion."
>
> Great!
>
> However, you have to apparently be invited to join the elite
> #openstack-packaging channel.
>
> What gives? Is that channel dead? Is there something else? Is there a secret
> handshake I can learn to palms to grease to get in?

>From ChanServ:

17:55:03 -ChanServ(ChanServ@services.)- Information on #openstack-packaging:
17:55:03 -ChanServ(ChanServ@services.)- Registered : Nov 11 18:59:55
2011 (4y 17w 0d ago)
17:55:03 -ChanServ(ChanServ@services.)- Last used  : (about 75 weeks ago)
17:55:03 -ChanServ(ChanServ@services.)- Mode lock  : +imnstf #openstack-stable
17:55:03 -ChanServ(ChanServ@services.)- Flags  : KEEPTOPIC
TOPICLOCK GUARD PRIVATE
17:55:03 -ChanServ(ChanServ@services.)- *** End of Info ***

It doesn't look like it's been used in a long time (75 weeks).

Louis

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

Re: [openstack-dev] The #openstack-packaging channel requires an invite?

[Mathieu Gagné]

It got renamed a couple of months/year ago to #openstack-stable:
https://bugs.launchpad.net/openstack-ci/+bug/1360324

Documentation should have been updated to reflect this change.

Channel being invite-only is probably a side-effect of the migration.

Mathieu

On 2016-03-09 12:48 PM, Matt Riedemann wrote:
> Someone showed up in the -stable channel this morning asking for help
> with packaging. I gather they were there because the IRC wiki [1] says
> the #openstack-stable channel is also for packaging discussions, given
> -stable originated from distro people.
> 
> I redirected them to https://wiki.openstack.org/wiki/Packaging which
> points to https://wiki.openstack.org/wiki/PackagerResources which says:
> 
> "The #openstack-packaging channel on Freenode is available for packaging
> collaboration and discussion."
> 
> Great!
> 
> However, you have to apparently be invited to join the elite
> #openstack-packaging channel.
> 
> What gives? Is that channel dead? Is there something else? Is there a
> secret handshake I can learn to palms to grease to get in?
> 
> [1] https://wiki.openstack.org/wiki/IRC
> 


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

[openstack-dev] The #openstack-packaging channel requires an invite?

[Matt Riedemann]

Someone showed up in the -stable channel this morning asking for help 
with packaging. I gather they were there because the IRC wiki [1] says 
the #openstack-stable channel is also for packaging discussions, given 
-stable originated from distro people.


I redirected them to https://wiki.openstack.org/wiki/Packaging which 
points to https://wiki.openstack.org/wiki/PackagerResources which says:


"The #openstack-packaging channel on Freenode is available for packaging 
collaboration and discussion."


Great!

However, you have to apparently be invited to join the elite 
#openstack-packaging channel.


What gives? Is that channel dead? Is there something else? Is there a 
secret handshake I can learn to palms to grease to get in?


[1] https://wiki.openstack.org/wiki/IRC

--

Thanks,

Matt Riedemann


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

Re: [openstack-dev] [Fuel][Fuel-Library] Fuel CI issues

[Thomas Goirand]

On 02/29/2016 11:19 AM, Vladimir Kuklin wrote:
> Hi Ivan
> 
> Thanks for bringing this up. Frankly, I think that we hurried a little
> bit by making our integration with upstream puppet manifests too
> continuous. I would suppose that we used a little bit different technique.
> 
> First of all, we need to have a set of stable Fuel commits against which
> the changes to upstream manifests should be tested. Could you please
> elaborate on whether we are doing this already?
> 
> Secondly, we need to have FUEL CI working with a set of stable commits
> of puppet openstack manifests which passed those upstream tests as we
> should not have too much moving parts or we will get into situation
> similar to requirements.txt updates when we have pypi updated with new
> library, e.g. oslo-serialization.
> 
> In this case, we will be able to do proper testing against frozen
> code-base for each piece thus avoiding such issues while retaining fair
> amount of integration with upstream puppet manifests for OpenStack.
> 
> So what do you think?

IMO, what needs to happen, is Fuel to use a packaged version of these
puppet scripts. This has numerous advantages:

- the openstack.yaml repository would also point to the corresponding
puppet stuff

- the version of puppet-openstack would automatically match the one of
the target installation, because it would be stored in the corresponding
packaging repository

- we wouldn't need to hack symlinks in /etc/puppet/modules

- there would be no need to use rsync from the master node to the slave
nodes, as the correct version of fuel-library would be installed in the
IBP image by fuel-agent, making it automatically available

What we shouldn't do though, is loose the continuous testing of upstream
puppet-openstack modules, so we make sure they never break Fuel,
otherwise we would discover issues too late.

FYI, I have just finished uploading all of puppet-openstack Mitaka b1
tag (which in fact corresponds to b3, somehow) to Debian Experimental.
This could be reused by Fuel.

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] [release][all][ptl] preparing to create stable/mitaka branches for libraries

[Flavio Percoco]

On 09/03/16 12:26 -0500, Doug Hellmann wrote:

It's time to start opening the stable branches for libraries. I've
prepared a list of repositories and the proposed versions from which
we will create stable/mitaka branches, and need each team to sign off on
the versions. If you know you intend to release a bug fix version in
the next couple of days, we can wait to avoid having to backport
patches, but otherwise we should go ahead and create the branches.

I will process each repository as I hear from the owning team.

openstack/glance_store 0.13.0
openstack/python-glanceclient 2.0.0


These 2 look good!

Thanks, Doug!
Flavio

--
@flaper87
Flavio Percoco


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

Re: [openstack-dev] [trove][stable] proboscis tests randomly failing in stable branches; bug 1538506

[Matt Riedemann]

On 3/9/2016 8:54 AM, Amrith Kumar wrote:

Matt,

As I understand it, you have 4 changes up for review.

 Change [1] seeks to revert the change [6] to python-troveclient on
 master and reinstate the slave_of parameter.

 Change [2] is doing for stable/liberty, the same things that were
 done for master in [9] on master, and [7] on Kilo earlier.

 Change [3] is looking to blacklist python-troveclient 2.1.0 on
 stable/liberty.

 Change [4] is looking to bump the minimum python-troveclient version
 on master to 2.1.0.


Right, and there was actually another for that beat me to this:

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



Here are three questions I have:

(1) Wouldn't backward compatibility also require that you revert the
other change that removed slave_of on the server [5] ? After all, just
like a python client that calls create() with slave_of, a REST client
could call the endpoint with slave_of. What is the policy for REST API
backward compatibility?


I guess it depends on the Trove team. In Nova, backward compatibility in 
the API is serious business and that's why we have left all sorts of 
warts in the v2.0 API and couldn't remove them. But with the v2.1 API 
and microversions, we're able to move the API forward (Ironic also has 
microversions, and I think cinder/neutron/keystone are working on adding 
that support).


So if maintaining backward compatibility in the trove API is important 
to the trove team and it's users, then yes the API change should 
probably be reverted. For anyone doing CD with Trove, they are already 
broken, but people upgrading from liberty to mitaka could save 
themselves the break.




(2) Wouldn't [4] just block 2.1.0 in global-requirements on master
(mitaka)?


I'm not sure I understand, [4] here bumps the minimum required version 
of python-troveclient to be 2.1.0, not block it. As noted in the review, 
I don't know that it's really necessary to bump to 2.1.0 iff we land and 
release [1].




(3) Something, potentially your patch set [2], should also fix the test
that is invoking create() with slave_of, no?


[2] is stable/liberty which still has slave_of in the create API, so I 
don't think that needs to be fixed in stable/liberty.




-amrith

[1] https://review.openstack.org/290048/
[2] https://review.openstack.org/290023/
[3] https://review.openstack.org/290021/
[4] https://review.openstack.org/290168/
[5] https://review.openstack.org/#/c/245845/
[6] https://review.openstack.org/#/c/245738/
[7] https://review.openstack.org/#/c/246735/

On 03/08/2016 08:24 PM, Matt Riedemann wrote:



On 3/8/2016 4:44 PM, Matt Riedemann wrote:



On 3/8/2016 3:17 PM, Matt Riedemann wrote:



On 3/8/2016 1:18 PM, Amrith Kumar wrote:

Matt,

See inline below.

-amrith


-Original Message-
From: Matt Riedemann [mailto:mrie...@linux.vnet.ibm.com]
Sent: Tuesday, March 08, 2016 2:00 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [trove][stable] proboscis tests randomly
failing in stable branches; bug 1538506



On 3/8/2016 12:52 PM, Matt Riedemann wrote:



On 3/8/2016 12:35 PM, Amrith Kumar wrote:

Matt,

The correct solution for liberty is that we should fix the tests.
Here's why I believe that this is the case.

In pertinent part, the backtrace from your bug includes:

2016-01-27 07:02:06.777 | File
"/home/jenkins/workspace/periodic-trove-python27-liberty/trove/tests/

api/replication.py",
line 83, in create_slave
2016-01-27 07:02:06.777 | slave_of=instance_info.id)

This is in the tests, not the client.

The test is now generating a parameter that the client no longer
understands.

For a user, here are the various situations that could occur.

1. User running python-troveclient from the latest 2.1.0 and a
server
from liberty. All is good.
2. User running an old python-troveclient and a server from
liberty.
All is good.


Will this work with python-troveclient 1.2.0 which is the minimum
required troveclient for stable/liberty?

https://github.com/openstack/requirements/blob/stable/liberty/global-r

equirements.txt#L174



3. User running an old python-troveclient and a new server from
mitaka, this is not supported.


How is this not supported?  If it's not supported, the minimum
required version of troveclient in master g-r is wrong, since it
hasn't changed since liberty:

https://github.com/openstack/requirements/blob/master/global-requireme

nts.txt#L202


I've confirmed that running master (mitaka) unit tests for trove
against
python-troveclient 1.2.0 don't work:

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


[amrith] Just like the bug you listed, this appears to be a case of a
broken test. Would you please LP it.







4. User running a current python-troveclient from the latest 2.1.0
and a server from mitaka, All is good.

What you have here is a case where a test is generating an argument
(slave_of) that the client (master, 2.1.0) no longer understands.
There's nothing amiss there, except that the test needs to be

Re: [openstack-dev] {openstack-dev][tc] Leadership training proposal/info

[Sean Dague]

On 03/09/2016 12:32 PM, Doug Hellmann wrote:
> Excerpts from Sean Dague's message of 2016-03-09 12:22:08 -0500:
>> On 03/09/2016 11:36 AM, Doug Hellmann wrote:
>>> Excerpts from Colette Alexander's message of 2016-03-08 14:34:19 -0800:
 On Tue, Mar 8, 2016 at 1:37 PM, Doug Hellmann  
 wrote:

>
>
> As I understood it when this course was originally proposed, the
> idea was to have a few folks already in leadership positions go
> take the training and evaluate it. Then, assuming the evaluation
> was good, we would offer it to (or at least suggest it to) other
> members of the community like PTLs or folks interested in running
> for leadership positions of some sort (not that folks who aren't
> elected can't be leaders, but one step at a time).
>
> How did that evolve into most of the TC (and Board?) going? Did
> someone do that evaluation already?
>

 it only evolved into much of the TC going because more people than I
 initially expected to based on previous conversations expressed interest in
 being able to attend. The general cost of a single custom-session for a
 group makes it possible to accommodate that larger group (so, having 10-20
 people in an exclusive, not-public session, is within the bounds of
 expected attendance).  No one from the board so far has said they'd be able
 to attend, fwiw, and I've checked with a few of them privately to gauge
 interest, which seems minimal there. I don't think the expectation that
 this is an 'official' or 'required' training is suddenly there, though -
 this will still be intended to be an evaluative session, just one that was
 more conducive, timing-wise, to the schedules of people who expressed
 interest in attending it.
>>>
>>> My interest in attending is based solely on the number of other TC
>>> members going. If a majority go, I feel I need to attend to have a good
>>> common frame of reference for future discussions. If only one or two
>>> folks go and prepare some sort of evaluation, I can skip the trip and
>>> only attend a future course if the evaluators recommend it.
>>>
> I've already expressed my skepticism of the idea of a business
> leadership class, and this specific class, being useful to us. I
> did so privately because I am willing to listen to the feedback
> from folks that do attend and I haven't really been involved in the
> planning aside from being asked to be part of the small group doing
> an initial evaluation.  But now if we're gearing up to send a large
> group to I feel it's necessary to say something publicly.
>
> Do we have a set of goals for the outcome of having folks take a
> "leadership" course? Do we have specific issues we would like to
> address through changes in leadership style? Does this course cover
> them?
>

 So I laid out some of the questions I think the community could benefit
 from alignment on in the etherpad I started already[0], but one of the
 things that really struck me when talking to various members of the TC and
 the community at large about leadership was how vastly different everyone's
 experience, opinions, and approaches were to the questions I asked (which
 were variations of: "As an elected leader in OpenStack, what do you wish
 you would've had as resources to help you adjust to a leadership position?"
 and "What do you think leaders in OpenStack could benefit from, in terms of
 skillsets that could be strengthened or added via any kind of training?")
 At some points, I had people suggesting to me completely opposite
 definitions for the 'problem' of leadership in OpenStack, suggesting that
 certain skillsets that others wanted training for didn't matter at all, and
 generally realized that maybe we all don't have a great shared definition
 of what leadership skills matter here in the community. Having been
 interacting with the community for a few years  now, I wasn't surprised by
 the diversity of opinions, but I think it does mean that some alignment on
 defining the problem would be worthwhile.

 Hence, the idea that perhaps a small group of existing leadership should
 get together in a room and talk about how to define/agree on the problem
 appropriately, first, before even beginning to think about having the
 conversation to come up with solutions for it. So in many ways, the goals
 or outcomes of this training would be to get more than a few people in
 leadership positions within the community to gather around a shared
 language and understanding of leadership in order to define problems
 collectively and move forward with discussing solutions more broadly. That
 could take so many possible forms, and be so many things, it's almost
 impossible to sort through.
>>>
>>> I agree we need to 

Re: [openstack-dev] [nova] bug reports and stable branches: tags or series?

[Markus Zoeller]

Matt Riedemann  wrote on 03/04/2016 04:29:53 
PM:

> From: Matt Riedemann 
> To: openstack-dev@lists.openstack.org
> Date: 03/04/2016 04:30 PM
> Subject: Re: [openstack-dev] [nova] bug reports and stable branches: 
> tags or series?
> 
> 
> 
> On 3/4/2016 6:27 AM, Markus Zoeller wrote:
> > What's the story behind having the tags "in-stable-liberty" and
> > "liberty-backport-potential" and also having the series target 
"liberty"?
> >
> > I didn't gave much TCL to the backports in the past but I'd like to
> > change that, that's why I'm asking. Please let me know the history
> > behind it.
> >
> > Regards, Markus Zoeller (markus_z)
> >
> >
> > 
__
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> 
> The 'liberty-backport-potential' tag can be set by anyone if the bug fix 

> is a potential backport for the stable/liberty branch. This is generally 

> good to set if the bug was reported against liberty itself, a release 
> before liberty but not fixed in liberty, or reported after liberty but 
> was a latent bug in liberty. Basically, if the bug is also in liberty, 
> it's backport potential to also fix it there.
> 
> The 'in-stable-liberty' tag is applied by infra when a stable branch 
> patch is merged. I haven't actually been seeing this happening as 
> automatically as before with the in-stable-kilo tag. I'm not sure if 
> that's a bug in infra or if it's by design (or maybe it doesn't happen 
> if the bug is nominated (series target) for the liberty release).
> 
> The series target is really just for tracking the progress of a 
> backport, like on master. It sets the status/importance/owner, which is 
> useful. The thing with the series target though is anyone (at least 
> anyone part of the nova bug team) can nominate a bug for a series, but 
> only drivers [1] can accept it.
> 
> So, my general workflow is to both tag and nominate for backports. We 
> really want people to use the tag because then the bug team can come 
> along later and do the series nominations if those haven't happened yet. 

> But I use the tag to query launchpad for fixed bugs that have a tag like 

> liberty-backport-potential, and then I dig into those bugs to see if a 
> fix has been proposed as a backport to stable/liberty yet. Sometimes 
> that's already done and we can just remove the tag (or replace it with 
> in-stable-liberty), or we can work on backporting the fix (if it's fits 
> the stable branch policy for appropriate fixes [2]).
> 
> As I mentioned in the nova team meeting yesterday it'd be helpful to the 

> stable maintenance team if people doing bug triage can apply the 
> *-backport-potential tags depending on what release the bug was reported 

> against. You don't have to dig into the details to figure out if it's 
> actually a latent bug or not, just if someone says they hit a bug on 
> liberty, we can add kilo-backport-potential so we can look into it when 
> that time comes (after it's fixed on trunk).
> 
> [1] https://launchpad.net/~nova-drivers/+members#active
> [2] 
> http://docs.openstack.org/project-team-guide/stable-
> branches.html#appropriate-fixes
> 
> -- 
> 
> Thanks,
> 
> Matt Riedemann
> 

OK, thanks, I got it. I'm not yet sure how to encourage this.
I did a query on our current open bugs, not sure if this is helpful
for the stable maintance team. The result of [1] will look like this:

=
Bugs (potential backports to releases)
=
https://bugs.launchpad.net/nova/+bug/1382153 (n-cond shoul not 
join[...]
   kilo-backport-potential
# [...]
https://bugs.launchpad.net/nova/+bug/1476591 (volume in_use after 
V[...]
   liberty-backport-potential, kilo-backport-potential
# [...]
https://bugs.launchpad.net/nova/+bug/1191960 (force-delete of 
cinde[...]
   mitaka-backport-potential, liberty-backport-potential, 
kilo-back[...]
# [...]

=
Bugs ("mitaka-backport-potential") 
=
https://bugs.launchpad.net/nova/+bug/1506390 (LXC instances cannot 
[...]
# [...]

=
Bugs ("liberty-backport-potential") 
=
https://bugs.launchpad.net/nova/+bug/1450294 (Enable password 
suppo[...]
# [...]

=
Bugs ("kilo-backport-potential") 
=
https://bugs.launchpad.net/nova/+bug/1382153 (n-cond shoul not 
join[...]
# [...]

References:
[1] Script 

Re: [openstack-dev] [release][all][ptl] preparing to create stable/mitaka branches for libraries

[Sergey Lukjanov]

Hi,

from Sahara team side, we're okay with python-saharaclient 0.13.0, no fixes
expected.

Thanks.

On Wed, Mar 9, 2016 at 9:26 AM, Doug Hellmann  wrote:

> It's time to start opening the stable branches for libraries. I've
> prepared a list of repositories and the proposed versions from which
> we will create stable/mitaka branches, and need each team to sign off on
> the versions. If you know you intend to release a bug fix version in
> the next couple of days, we can wait to avoid having to backport
> patches, but otherwise we should go ahead and create the branches.
>
> I will process each repository as I hear from the owning team.
>
> openstack/ceilometermiddleware 0.4.0
> openstack/django_openstack_auth 2.2.0
> openstack/glance_store 0.13.0
> openstack/ironic-lib 1.1.0
> openstack/keystoneauth 2.3.0
> openstack/keystonemiddleware 4.3.0
> openstack/os-brick 1.1.0
> openstack/os-client-config 1.16.0
> openstack/pycadf 2.1.0
> openstack/python-barbicanclient 4.0.0
> openstack/python-brick-cinderclient-ext 0.1.0
> openstack/python-ceilometerclient 2.3.0
> openstack/python-cinderclient 1.6.0
> openstack/cliff 2.0.0
> openstack/python-designateclient 2.0.0
> openstack/python-glanceclient 2.0.0
> openstack/python-heatclient 1.0.0
> openstack/python-ironic-inspector-client 1.5.0
> openstack/python-ironicclient 1.2.0
> openstack/python-keystoneclient 2.3.1
> openstack/python-manilaclient 1.8.0
> openstack/python-neutronclient 4.1.1
> openstack/python-novaclient 3.3.0
> openstack/python-saharaclient 0.13.0
> openstack/python-swiftclient 3.0.0
> openstack/python-troveclient 2.1.0
> openstack/python-zaqarclient 1.0.0
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



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

Re: [openstack-dev] {openstack-dev][tc] Leadership training proposal/info

[Doug Hellmann]

Excerpts from Sean Dague's message of 2016-03-09 12:22:08 -0500:
> On 03/09/2016 11:36 AM, Doug Hellmann wrote:
> > Excerpts from Colette Alexander's message of 2016-03-08 14:34:19 -0800:
> >> On Tue, Mar 8, 2016 at 1:37 PM, Doug Hellmann  
> >> wrote:
> >>
> >>>
> >>>
> >>> As I understood it when this course was originally proposed, the
> >>> idea was to have a few folks already in leadership positions go
> >>> take the training and evaluate it. Then, assuming the evaluation
> >>> was good, we would offer it to (or at least suggest it to) other
> >>> members of the community like PTLs or folks interested in running
> >>> for leadership positions of some sort (not that folks who aren't
> >>> elected can't be leaders, but one step at a time).
> >>>
> >>> How did that evolve into most of the TC (and Board?) going? Did
> >>> someone do that evaluation already?
> >>>
> >>
> >> it only evolved into much of the TC going because more people than I
> >> initially expected to based on previous conversations expressed interest in
> >> being able to attend. The general cost of a single custom-session for a
> >> group makes it possible to accommodate that larger group (so, having 10-20
> >> people in an exclusive, not-public session, is within the bounds of
> >> expected attendance).  No one from the board so far has said they'd be able
> >> to attend, fwiw, and I've checked with a few of them privately to gauge
> >> interest, which seems minimal there. I don't think the expectation that
> >> this is an 'official' or 'required' training is suddenly there, though -
> >> this will still be intended to be an evaluative session, just one that was
> >> more conducive, timing-wise, to the schedules of people who expressed
> >> interest in attending it.
> > 
> > My interest in attending is based solely on the number of other TC
> > members going. If a majority go, I feel I need to attend to have a good
> > common frame of reference for future discussions. If only one or two
> > folks go and prepare some sort of evaluation, I can skip the trip and
> > only attend a future course if the evaluators recommend it.
> > 
> >>> I've already expressed my skepticism of the idea of a business
> >>> leadership class, and this specific class, being useful to us. I
> >>> did so privately because I am willing to listen to the feedback
> >>> from folks that do attend and I haven't really been involved in the
> >>> planning aside from being asked to be part of the small group doing
> >>> an initial evaluation.  But now if we're gearing up to send a large
> >>> group to I feel it's necessary to say something publicly.
> >>>
> >>> Do we have a set of goals for the outcome of having folks take a
> >>> "leadership" course? Do we have specific issues we would like to
> >>> address through changes in leadership style? Does this course cover
> >>> them?
> >>>
> >>
> >> So I laid out some of the questions I think the community could benefit
> >> from alignment on in the etherpad I started already[0], but one of the
> >> things that really struck me when talking to various members of the TC and
> >> the community at large about leadership was how vastly different everyone's
> >> experience, opinions, and approaches were to the questions I asked (which
> >> were variations of: "As an elected leader in OpenStack, what do you wish
> >> you would've had as resources to help you adjust to a leadership position?"
> >> and "What do you think leaders in OpenStack could benefit from, in terms of
> >> skillsets that could be strengthened or added via any kind of training?")
> >> At some points, I had people suggesting to me completely opposite
> >> definitions for the 'problem' of leadership in OpenStack, suggesting that
> >> certain skillsets that others wanted training for didn't matter at all, and
> >> generally realized that maybe we all don't have a great shared definition
> >> of what leadership skills matter here in the community. Having been
> >> interacting with the community for a few years  now, I wasn't surprised by
> >> the diversity of opinions, but I think it does mean that some alignment on
> >> defining the problem would be worthwhile.
> >>
> >> Hence, the idea that perhaps a small group of existing leadership should
> >> get together in a room and talk about how to define/agree on the problem
> >> appropriately, first, before even beginning to think about having the
> >> conversation to come up with solutions for it. So in many ways, the goals
> >> or outcomes of this training would be to get more than a few people in
> >> leadership positions within the community to gather around a shared
> >> language and understanding of leadership in order to define problems
> >> collectively and move forward with discussing solutions more broadly. That
> >> could take so many possible forms, and be so many things, it's almost
> >> impossible to sort through.
> > 
> > I agree we need to have the conversation and come to some 

Re: [openstack-dev] [horizon] Proposal to add Diana Whitten to horizon-core

[Beth Elwell]

I’m not a core but I wanted to add my complete agreement with making Diana a 
core in horizon. She has done some incredible work in horizon through her work 
on the code, reviews and also community attitude and assistance getting people 
(myself included) familiar with horizon.

Beth

> On 8 Mar 2016, at 22:48, Lin Hua Cheng  wrote:
> 
> big +1 from me.
> 
> She made a lot of contribution in making theming better for horizon and also 
> prevented potential issues through reviews.
> Thanks for all the hard work, Diana.
> 
> -Lin
> 
> On Tue, Mar 8, 2016 at 2:06 PM, David Lyle  > wrote:
> I propose adding Diana Whitten[1] to horizon-core.
> 
> Diana is an active reviewer, contributor and community member. Over
> the past couple of releases, Diana has driven extensive changes around
> theme-ability in Horizon and drastically increased the standardization
> of our use of bootstrap. During this time, Diana has also provided
> valuable reviews to keep us on the straight and narrow preventing our
> continued abuse of defenseless web technologies.
> 
> Please respond with comments, +1s, or objections by Friday.
> 
> Thanks,
> David
> 
> [1] 
> http://stackalytics.com/?module=horizon-group_id=hurgleburgler=all
>  
> 
> 
> __
> OpenStack Development Mailing 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] [release][all][ptl] preparing to create stable/mitaka branches for libraries

[Doug Hellmann]

It's time to start opening the stable branches for libraries. I've
prepared a list of repositories and the proposed versions from which
we will create stable/mitaka branches, and need each team to sign off on
the versions. If you know you intend to release a bug fix version in
the next couple of days, we can wait to avoid having to backport
patches, but otherwise we should go ahead and create the branches.

I will process each repository as I hear from the owning team.

openstack/ceilometermiddleware 0.4.0
openstack/django_openstack_auth 2.2.0
openstack/glance_store 0.13.0
openstack/ironic-lib 1.1.0
openstack/keystoneauth 2.3.0
openstack/keystonemiddleware 4.3.0
openstack/os-brick 1.1.0
openstack/os-client-config 1.16.0
openstack/pycadf 2.1.0
openstack/python-barbicanclient 4.0.0
openstack/python-brick-cinderclient-ext 0.1.0
openstack/python-ceilometerclient 2.3.0
openstack/python-cinderclient 1.6.0
openstack/cliff 2.0.0
openstack/python-designateclient 2.0.0
openstack/python-glanceclient 2.0.0
openstack/python-heatclient 1.0.0
openstack/python-ironic-inspector-client 1.5.0
openstack/python-ironicclient 1.2.0
openstack/python-keystoneclient 2.3.1
openstack/python-manilaclient 1.8.0
openstack/python-neutronclient 4.1.1
openstack/python-novaclient 3.3.0
openstack/python-saharaclient 0.13.0
openstack/python-swiftclient 3.0.0
openstack/python-troveclient 2.1.0
openstack/python-zaqarclient 1.0.0

__
OpenStack Development Mailing List (not for 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-dev][tc] Leadership training proposal/info

[Sean Dague]

On 03/09/2016 11:36 AM, Doug Hellmann wrote:
> Excerpts from Colette Alexander's message of 2016-03-08 14:34:19 -0800:
>> On Tue, Mar 8, 2016 at 1:37 PM, Doug Hellmann  wrote:
>>
>>>
>>>
>>> As I understood it when this course was originally proposed, the
>>> idea was to have a few folks already in leadership positions go
>>> take the training and evaluate it. Then, assuming the evaluation
>>> was good, we would offer it to (or at least suggest it to) other
>>> members of the community like PTLs or folks interested in running
>>> for leadership positions of some sort (not that folks who aren't
>>> elected can't be leaders, but one step at a time).
>>>
>>> How did that evolve into most of the TC (and Board?) going? Did
>>> someone do that evaluation already?
>>>
>>
>> it only evolved into much of the TC going because more people than I
>> initially expected to based on previous conversations expressed interest in
>> being able to attend. The general cost of a single custom-session for a
>> group makes it possible to accommodate that larger group (so, having 10-20
>> people in an exclusive, not-public session, is within the bounds of
>> expected attendance).  No one from the board so far has said they'd be able
>> to attend, fwiw, and I've checked with a few of them privately to gauge
>> interest, which seems minimal there. I don't think the expectation that
>> this is an 'official' or 'required' training is suddenly there, though -
>> this will still be intended to be an evaluative session, just one that was
>> more conducive, timing-wise, to the schedules of people who expressed
>> interest in attending it.
> 
> My interest in attending is based solely on the number of other TC
> members going. If a majority go, I feel I need to attend to have a good
> common frame of reference for future discussions. If only one or two
> folks go and prepare some sort of evaluation, I can skip the trip and
> only attend a future course if the evaluators recommend it.
> 
>>> I've already expressed my skepticism of the idea of a business
>>> leadership class, and this specific class, being useful to us. I
>>> did so privately because I am willing to listen to the feedback
>>> from folks that do attend and I haven't really been involved in the
>>> planning aside from being asked to be part of the small group doing
>>> an initial evaluation.  But now if we're gearing up to send a large
>>> group to I feel it's necessary to say something publicly.
>>>
>>> Do we have a set of goals for the outcome of having folks take a
>>> "leadership" course? Do we have specific issues we would like to
>>> address through changes in leadership style? Does this course cover
>>> them?
>>>
>>
>> So I laid out some of the questions I think the community could benefit
>> from alignment on in the etherpad I started already[0], but one of the
>> things that really struck me when talking to various members of the TC and
>> the community at large about leadership was how vastly different everyone's
>> experience, opinions, and approaches were to the questions I asked (which
>> were variations of: "As an elected leader in OpenStack, what do you wish
>> you would've had as resources to help you adjust to a leadership position?"
>> and "What do you think leaders in OpenStack could benefit from, in terms of
>> skillsets that could be strengthened or added via any kind of training?")
>> At some points, I had people suggesting to me completely opposite
>> definitions for the 'problem' of leadership in OpenStack, suggesting that
>> certain skillsets that others wanted training for didn't matter at all, and
>> generally realized that maybe we all don't have a great shared definition
>> of what leadership skills matter here in the community. Having been
>> interacting with the community for a few years  now, I wasn't surprised by
>> the diversity of opinions, but I think it does mean that some alignment on
>> defining the problem would be worthwhile.
>>
>> Hence, the idea that perhaps a small group of existing leadership should
>> get together in a room and talk about how to define/agree on the problem
>> appropriately, first, before even beginning to think about having the
>> conversation to come up with solutions for it. So in many ways, the goals
>> or outcomes of this training would be to get more than a few people in
>> leadership positions within the community to gather around a shared
>> language and understanding of leadership in order to define problems
>> collectively and move forward with discussing solutions more broadly. That
>> could take so many possible forms, and be so many things, it's almost
>> impossible to sort through.
> 
> I agree we need to have the conversation and come to some common
> understanding. It's not clear that a pre-defined seminar like this
> is the best forum for that sort of discussion. Our values should
> drive the discussion, rather than those of someone from outside of
> our community.

I've 

Re: [openstack-dev] [neutron][oslo]neutron agent not receiving callback

[Vikash Kumar]

Thanks,

 Yeah I just gone over doc. and tried to use the subscription. After
looking into code I understood thats its not for interprocess.

@Armando - Thanks for updating faq

On Wed, Mar 9, 2016 at 10:40 PM, Armando M.  wrote:

>
>
> On 9 March 2016 at 09:14, Assaf Muller  wrote:
>
>> On Wed, Mar 9, 2016 at 9:40 AM, Ihar Hrachyshka 
>> wrote:
>> > Vikash Kumar  wrote:
>> >
>> >>
>> >>
>> >> On Wed, Mar 9, 2016 at 3:42 PM, Vikash Kumar
>> >>  wrote:
>> >> I have written a sample neutron agent which subscribe for the
>> AFTER_CREATE
>> >> event of router. I have defined a sample method as callback, but the
>> method
>> >> doesn't gets called anytime.
>> >>
>> >> Also, in logs:
>> >>
>> >> 2016-03-09 01:36:08.220 7075 DEBUG neutron.callbacks.manager [-]
>> >> Subscribe:  router after_create
>> >> subscribe /opt/stack/neutron/neutron/callbacks/manager.py:41
>> >>
>> >>
>> >> which means the subscription is successful.
>> >>
>> >>Do I need to enable anything in config file to get that ? Or am I
>> >> missing something ?
>> >
>> >
>> > First, nothing oslo specific is discussed here, so [oslo] tag is
>> probably
>> > redundant.
>> >
>> > Overall, I believe you try to rely on wrong thing that won’t deliver for
>> > you: callbacks are internal to neutron-server, so events triggered by
>> > neutron-servers will never reach any other processes (like your agent).
>>
>> The same callbacks mechanism is also used in the L3 agent, but as Ihar
>> said, events in one process (neutron-server) will not trigger
>> callbacks in another process (l3-agent). If that's what you want,
>> you'll need RPC.
>>
>
> Callbacks is a general pub/sub local communication mechanism, whether it
> applies to neutron-server or an agent. Clarifying here:
>
> https://review.openstack.org/#/c/290700/
>
>
>>
>> >
>> > More info:
>> http://docs.openstack.org/developer/neutron/devref/callbacks.html
>> >
>> > Ihar
>> >
>> >
>> __
>> > OpenStack Development Mailing 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
>
>


-- 
Regards,
Vikash
__
OpenStack Development Mailing List (not for 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][oslo]neutron agent not receiving callback

[Armando M.]

On 9 March 2016 at 09:14, Assaf Muller  wrote:

> On Wed, Mar 9, 2016 at 9:40 AM, Ihar Hrachyshka 
> wrote:
> > Vikash Kumar  wrote:
> >
> >>
> >>
> >> On Wed, Mar 9, 2016 at 3:42 PM, Vikash Kumar
> >>  wrote:
> >> I have written a sample neutron agent which subscribe for the
> AFTER_CREATE
> >> event of router. I have defined a sample method as callback, but the
> method
> >> doesn't gets called anytime.
> >>
> >> Also, in logs:
> >>
> >> 2016-03-09 01:36:08.220 7075 DEBUG neutron.callbacks.manager [-]
> >> Subscribe:  router after_create
> >> subscribe /opt/stack/neutron/neutron/callbacks/manager.py:41
> >>
> >>
> >> which means the subscription is successful.
> >>
> >>Do I need to enable anything in config file to get that ? Or am I
> >> missing something ?
> >
> >
> > First, nothing oslo specific is discussed here, so [oslo] tag is probably
> > redundant.
> >
> > Overall, I believe you try to rely on wrong thing that won’t deliver for
> > you: callbacks are internal to neutron-server, so events triggered by
> > neutron-servers will never reach any other processes (like your agent).
>
> The same callbacks mechanism is also used in the L3 agent, but as Ihar
> said, events in one process (neutron-server) will not trigger
> callbacks in another process (l3-agent). If that's what you want,
> you'll need RPC.
>

Callbacks is a general pub/sub local communication mechanism, whether it
applies to neutron-server or an agent. Clarifying here:

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


>
> >
> > More info:
> http://docs.openstack.org/developer/neutron/devref/callbacks.html
> >
> > Ihar
> >
> >
> __
> > OpenStack Development Mailing 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] [Neutron] Ihar as *-aas core reviewer

[Armando M.]

Folks,

I would like to have Ihar as core reviewer for the advanced services (or
any neutron-governance project for the time we have those projects in the
governance).

Ihar is instrumental in ensuring that gate/stable issues are dealt with
promptly and swiftly and I trust he'll be using such as as responsibility
wisely.

So if you see him in your core team, that's the reason.

Thanks,
Armando
__
OpenStack Development Mailing List (not for 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] Last chance to finish changes affecting DB schema for Mitaka

[Armando M.]

On 9 March 2016 at 07:42, Ihar Hrachyshka  wrote:

> Henry Gessau  wrote:
>
> By tomorrow we intend to tag the heads of all the neutron alembic branches
>> with the MITAKA label [1][2][3][4].
>>
>> If you have a patch that adds an alembic migration and you want to get it
>> in
>> Mitaka you must be associated with a targeted BP/RFE/bug [5] and get your
>> code
>> merged by tomorrow (Wednesday, March 9).
>>
>> Here is a list of open reviews with DB migration changes [6]. Check if
>> your
>> Mitaka-targeted patch is on the list and if so, reach out to me (HenryG)
>> or
>> our PTL (armax) on IRC and let us know of your plans.
>>
>> -- HenryG
>>
>> [1] https://review.openstack.org/288212
>> [2] https://review.openstack.org/288213
>> [3] https://review.openstack.org/288214
>> [4] https://review.openstack.org/288215
>> [5] https://launchpad.net/neutron/+milestone/mitaka-rc1
>> [6]
>>
>> https://review.openstack.org/#/q/(project:openstack/neutron+OR+project:openstack/neutron-fwaas+OR+project:openstack/neutron-lbaas+OR+project:openstack/neutron-vpnaas)+status:open+file:%22%255E.*/versions/mitaka/.*%22+-label:workflow-1
>>
>>
> Note we are still in the middle of clarifying whether we want to allow
> DSCP feature in Mitaka, that involves alembic scripts. More details on the
> discussion:
>
> http://lists.openstack.org/pipermail/openstack-dev/2016-March/088717.html
>
> Thanks for holding the label patches.


Alea iacta est:

https://review.openstack.org/#/q/topic:bug/1552935

Please refrain from approving any change that involve DB migrations

Thanks,
Armando


>
> Ihar
>
>
> __
> OpenStack Development Mailing 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] [horizon] Proposal to add Diana Whitten to horizon-core

[Rob Cresswell (rcresswe)]

+1 from me. Diana’s almost single handedly fixed our Bootstrap usage and gives 
lots of great reviews all across Horizon too. The boost to branding, theming 
and potential for accessibility, as well as huge reduction in CSS/HTML 
maintenance overhead, has been brilliant.

Rob


On 9 Mar 2016, at 16:15, Timur Sufiev 
> wrote:

+1, Diana's contribution to the front-end aspect of Horizon during several 
recent release cycles was second to none!

On Wed, Mar 9, 2016 at 2:15 AM Richard Jones 
> wrote:
+1 we need Diana's perspective, knowledge and enthusiasm

On 9 March 2016 at 10:03, Tripp, Travis S 
> wrote:
+1, no questions asked. It is rare to find somebody with the passion that Diana 
has shown.

From: Lin Hua Cheng 
>>
Reply-To: OpenStack List 
>>
Date: Tuesday, March 8, 2016 at 3:48 PM
To: OpenStack List 
>>
Subject: Re: [openstack-dev] [horizon] Proposal to add Diana Whitten to 
horizon-core

big +1 from me.

She made a lot of contribution in making theming better for horizon and also 
prevented potential issues through reviews.
Thanks for all the hard work, Diana.

-Lin

On Tue, Mar 8, 2016 at 2:06 PM, David Lyle 
>>
 wrote:
I propose adding Diana Whitten[1] to horizon-core.

Diana is an active reviewer, contributor and community member. Over
the past couple of releases, Diana has driven extensive changes around
theme-ability in Horizon and drastically increased the standardization
of our use of bootstrap. During this time, Diana has also provided
valuable reviews to keep us on the straight and narrow preventing our
continued abuse of defenseless web technologies.

Please respond with comments, +1s, or objections by Friday.

Thanks,
David

[1] 
http://stackalytics.com/?module=horizon-group_id=hurgleburgler=all

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

__
OpenStack Development Mailing List (not for 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-dev][tc] Leadership training proposal/info

[Doug Hellmann]

Excerpts from Colette Alexander's message of 2016-03-08 14:34:19 -0800:
> On Tue, Mar 8, 2016 at 1:37 PM, Doug Hellmann  wrote:
> 
> >
> >
> > As I understood it when this course was originally proposed, the
> > idea was to have a few folks already in leadership positions go
> > take the training and evaluate it. Then, assuming the evaluation
> > was good, we would offer it to (or at least suggest it to) other
> > members of the community like PTLs or folks interested in running
> > for leadership positions of some sort (not that folks who aren't
> > elected can't be leaders, but one step at a time).
> >
> > How did that evolve into most of the TC (and Board?) going? Did
> > someone do that evaluation already?
> >
> 
> it only evolved into much of the TC going because more people than I
> initially expected to based on previous conversations expressed interest in
> being able to attend. The general cost of a single custom-session for a
> group makes it possible to accommodate that larger group (so, having 10-20
> people in an exclusive, not-public session, is within the bounds of
> expected attendance).  No one from the board so far has said they'd be able
> to attend, fwiw, and I've checked with a few of them privately to gauge
> interest, which seems minimal there. I don't think the expectation that
> this is an 'official' or 'required' training is suddenly there, though -
> this will still be intended to be an evaluative session, just one that was
> more conducive, timing-wise, to the schedules of people who expressed
> interest in attending it.

My interest in attending is based solely on the number of other TC
members going. If a majority go, I feel I need to attend to have a good
common frame of reference for future discussions. If only one or two
folks go and prepare some sort of evaluation, I can skip the trip and
only attend a future course if the evaluators recommend it.

> > I've already expressed my skepticism of the idea of a business
> > leadership class, and this specific class, being useful to us. I
> > did so privately because I am willing to listen to the feedback
> > from folks that do attend and I haven't really been involved in the
> > planning aside from being asked to be part of the small group doing
> > an initial evaluation.  But now if we're gearing up to send a large
> > group to I feel it's necessary to say something publicly.
> >
> > Do we have a set of goals for the outcome of having folks take a
> > "leadership" course? Do we have specific issues we would like to
> > address through changes in leadership style? Does this course cover
> > them?
> >
> 
> So I laid out some of the questions I think the community could benefit
> from alignment on in the etherpad I started already[0], but one of the
> things that really struck me when talking to various members of the TC and
> the community at large about leadership was how vastly different everyone's
> experience, opinions, and approaches were to the questions I asked (which
> were variations of: "As an elected leader in OpenStack, what do you wish
> you would've had as resources to help you adjust to a leadership position?"
> and "What do you think leaders in OpenStack could benefit from, in terms of
> skillsets that could be strengthened or added via any kind of training?")
> At some points, I had people suggesting to me completely opposite
> definitions for the 'problem' of leadership in OpenStack, suggesting that
> certain skillsets that others wanted training for didn't matter at all, and
> generally realized that maybe we all don't have a great shared definition
> of what leadership skills matter here in the community. Having been
> interacting with the community for a few years  now, I wasn't surprised by
> the diversity of opinions, but I think it does mean that some alignment on
> defining the problem would be worthwhile.
> 
> Hence, the idea that perhaps a small group of existing leadership should
> get together in a room and talk about how to define/agree on the problem
> appropriately, first, before even beginning to think about having the
> conversation to come up with solutions for it. So in many ways, the goals
> or outcomes of this training would be to get more than a few people in
> leadership positions within the community to gather around a shared
> language and understanding of leadership in order to define problems
> collectively and move forward with discussing solutions more broadly. That
> could take so many possible forms, and be so many things, it's almost
> impossible to sort through.

I agree we need to have the conversation and come to some common
understanding. It's not clear that a pre-defined seminar like this
is the best forum for that sort of discussion. Our values should
drive the discussion, rather than those of someone from outside of
our community.

> If you ask me what the 'big goal' of talking about leadership in this
> community is about, I'd say it's about infusing 

Re: [openstack-dev] [nova] patches that improve code quality

[Matt Riedemann]

On 3/9/2016 6:22 AM, Radomir Dopieralski wrote:

Some of the code we have in Nova is admittedly hard to read and brittle.
This is true even though we cave excellent code review,
and the reviewers that deeply care for the quality of code that is being
merged. Some of this code has been there always, some got that way as a
result of bug fixes and patches that were intended to touch as little
code as possible, and some is just to bad judgment or mistakes.

Whatever the reason, such code accumulates and makes the program harder
to understand, to debug and to modify. The maintenance and development
costs rise. It's also less pleasant to work with such code base.

Cleaning up such code and rewriting it to be easier to understand and
more robust is a good practice that every programmer should be familiar
with. However, it's not always easy or even possible to do that while
working on a feature or a bugfix. If our patch includes a lot of changes
that are unrelated to the feature or bug at hand, it becomes harder to
understand and review, and even runs a risk of being rejected. It's also
easier to introduce bugs that way.

A good practice would be to make such changes in separate patches,
possibly also adding tests (where they are missing) showing that there
is no change in behavior. Such patches can be reviewed with special
attention to readability and robustness, and in the review there will be
often even further improvements. We end up with a better program and
easier (and more pleasant) work.

And now, finally, I can get to the point of this e-mail. I'm relatively
new to this project, but I found no way to direct the (precious)
attention of core reviewers to such patches. They are not bugs, neither
they are parts of any new feature, and so there is no list in Nova that
core reviewers look at where we could add such a patch. Admittedly, such
patches are not urgent -- the code works the same (or almost the same)
way without them -- but it would be nice to have some way of merging
them eventually, because they do make our lives easier in the long run.

So here's my question: what is the correct way to have such a patch
merged in Nova, and -- if there isn't one -- should we think about
making it easier?


I don't think we give any special priority to technical debt cleanup 
unless it's part of a larger series, like cleaning up code before fixing 
a bug or landing a feature.


So you can and should push patches to refactor code to make it more 
maintainable/readable/etc, but there isn't a guarantee that it's going 
to get attention any sooner than every other patch out in the review 
queue (according to stackalytics there are currently 842 open reviews in 
nova [1]).


[1] http://stackalytics.com/report/reviews/nova/open

--

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] [TripleO] Including Aodh and Gnocchi in Mitaka

[Pradeep Kilambi]

Hey Guys:

As many of you know, we have been working on getting Aodh and Gnocchi
support into TripleO. We would like to formally request these two be
made blockers to get into Mitaka release for TripleO. We tried to get
these into Liberty, but due to time constraints it seems slim that
that would happen at this point. We would like to get some assurance
from the community if this is possible. I will elaborate each case and
why we really want them in Mitaka.

Aodh is basically the same alarm functionality in ceilometer split out
into its own project.  This is deprecated in Liberty, as in the code
is un-maintained. In Mitaka, the ceilometer alarms are completely
removed. So Aodh is the replacement. Hence, Aodh has to make it into
Mitaka, without which we will not be able to provide alarm
functionality going forward. So please consider this a blocker for
Mitaka. Even better if we can get it backported to Liberty as the code
is unmaintained :) . The patch set is up for review [1]

Gnocchi on the other hand is a new project that was born to address
the performance issues Ceilometer has by reworking our approach to
metric storage, in order to mitigate some mis-steps in the original
storage architecture. Going forward Gnocchi is the preferred backend
for Ceilometer along with other supported alternatives. Gnocchi should
make ceilometer much more usable at large scale. It would be great if
we can get gnocchi support into Mitaka as well. Since this is a new
service, there shouldn't be any need for upgrades or migration. Which
hopefully should be make it less risky. The patch set is up for review
[2]

If we can make these a priority in review queues and get it into
Mitaka it would be a huge relief.

Please feel free to reach out to me on irc if i can help answer any question,

Thanks,
~ Pradeep

[1] https://review.openstack.org/#/c/289435/
[2] https://review.openstack.org/#/c/252032/

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

[Jeremy Stanley]

On 2016-03-09 15:32:58 + (+), Vikram Hosakote (vhosakot) wrote:
> FYI, the bug is seen in Ubuntu gate just on  devstack-trusty-rax
> machine and not on  devstack-trusty-osic  and
> devstack-trusty-ovh.

Due to long-standing issues uploading images to Rackspace's Glance
implementation (and also differences in getting network interfaces
configured properly), the devstack-trusty images used there are not
consistent with the ones we have in our other providers where we've
been able to consistently upload rather than having to rely on
modifying snapshots of the provider's "special" (nonstandard) base
images. We've mostly got a handle on that now and once these jobs
all move from "devstack-trusty" to our new generic "ubuntu-trusty"
workers in the coming weeks we should be consistent everywhere.
-- 
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] [horizon] Proposal to add Diana Whitten to horizon-core

[Timur Sufiev]

+1, Diana's contribution to the front-end aspect of Horizon during several
recent release cycles was second to none!

On Wed, Mar 9, 2016 at 2:15 AM Richard Jones  wrote:

> +1 we need Diana's perspective, knowledge and enthusiasm
>
> On 9 March 2016 at 10:03, Tripp, Travis S  wrote:
>
>> +1, no questions asked. It is rare to find somebody with the passion that
>> Diana has shown.
>>
>> From: Lin Hua Cheng >
>> Reply-To: OpenStack List  openstack-dev@lists.openstack.org>>
>> Date: Tuesday, March 8, 2016 at 3:48 PM
>> To: OpenStack List  openstack-dev@lists.openstack.org>>
>> Subject: Re: [openstack-dev] [horizon] Proposal to add Diana Whitten to
>> horizon-core
>>
>> big +1 from me.
>>
>> She made a lot of contribution in making theming better for horizon and
>> also prevented potential issues through reviews.
>> Thanks for all the hard work, Diana.
>>
>> -Lin
>>
>> On Tue, Mar 8, 2016 at 2:06 PM, David Lyle  dkly...@gmail.com>> wrote:
>> I propose adding Diana Whitten[1] to horizon-core.
>>
>> Diana is an active reviewer, contributor and community member. Over
>> the past couple of releases, Diana has driven extensive changes around
>> theme-ability in Horizon and drastically increased the standardization
>> of our use of bootstrap. During this time, Diana has also provided
>> valuable reviews to keep us on the straight and narrow preventing our
>> continued abuse of defenseless web technologies.
>>
>> Please respond with comments, +1s, or objections by Friday.
>>
>> Thanks,
>> David
>>
>> [1]
>> http://stackalytics.com/?module=horizon-group_id=hurgleburgler=all
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<
>> http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing 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] [nfv][telco] Telco Working Group meeting for Wednesday Marcch 16th CANCELLED

[Steve Gordon]

Hi all,

There will be no Telco Working Group [1] meeting for Wednesday March 16th as we 
will be lacking a chair.

Thanks,

Steve

[1] https://wiki.openstack.org/wiki/TelcoWorkingGroup

__
OpenStack Development Mailing List (not for 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][oslo]neutron agent not receiving callback

[Assaf Muller]

On Wed, Mar 9, 2016 at 9:40 AM, Ihar Hrachyshka  wrote:
> Vikash Kumar  wrote:
>
>>
>>
>> On Wed, Mar 9, 2016 at 3:42 PM, Vikash Kumar
>>  wrote:
>> I have written a sample neutron agent which subscribe for the AFTER_CREATE
>> event of router. I have defined a sample method as callback, but the method
>> doesn't gets called anytime.
>>
>> Also, in logs:
>>
>> 2016-03-09 01:36:08.220 7075 DEBUG neutron.callbacks.manager [-]
>> Subscribe:  router after_create
>> subscribe /opt/stack/neutron/neutron/callbacks/manager.py:41
>>
>>
>> which means the subscription is successful.
>>
>>Do I need to enable anything in config file to get that ? Or am I
>> missing something ?
>
>
> First, nothing oslo specific is discussed here, so [oslo] tag is probably
> redundant.
>
> Overall, I believe you try to rely on wrong thing that won’t deliver for
> you: callbacks are internal to neutron-server, so events triggered by
> neutron-servers will never reach any other processes (like your agent).

The same callbacks mechanism is also used in the L3 agent, but as Ihar
said, events in one process (neutron-server) will not trigger
callbacks in another process (l3-agent). If that's what you want,
you'll need RPC.

>
> More info: http://docs.openstack.org/developer/neutron/devref/callbacks.html
>
> Ihar
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] {openstack-dev][tc] Leadership training proposal/info

[Thierry Carrez]

Colette Alexander wrote:

On Tue, Mar 8, 2016 at 1:37 PM, Doug Hellmann > wrote:


As I understood it when this course was originally proposed, the
idea was to have a few folks already in leadership positions go
take the training and evaluate it. Then, assuming the evaluation
was good, we would offer it to (or at least suggest it to) other
members of the community like PTLs or folks interested in running
for leadership positions of some sort (not that folks who aren't
elected can't be leaders, but one step at a time).

How did that evolve into most of the TC (and Board?) going? Did
someone do that evaluation already?



it only evolved into much of the TC going because more people than I
initially expected to based on previous conversations expressed interest
in being able to attend. The general cost of a single custom-session for
a group makes it possible to accommodate that larger group (so, having
10-20 people in an exclusive, not-public session, is within the bounds
of expected attendance).  No one from the board so far has said they'd
be able to attend, fwiw, and I've checked with a few of them privately
to gauge interest, which seems minimal there. I don't think the
expectation that this is an 'official' or 'required' training is
suddenly there, though - this will still be intended to be an evaluative
session, just one that was more conducive, timing-wise, to the schedules
of people who expressed interest in attending it.


I fear that a part of it is that some TC members realized that a 
critical mass of TC members would attend, which turns the event into a 
sort of TC midcycle (if only in social events like dinners), so they 
decided they should probably join to not be excluded. I sure would like 
to be there is half the TC members will be around: sounds like the 
avenue for pretty interesting discussions.


My fear with making that TC-only are the following: it increases the 
artificial rift between the TC members and the rest of the community, 
and it ignores that our leadership is not limited to TC members, but 
includes PTLs, cross-project liaisons and other thankless jobs. As a 
result, it reduces the value of the experiment by drawing only from the 
TC ranks (rather than inviting a sample representation of leadership to 
assess the training), and unnecessarily fuels the us vs. them attitude.


--
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] [L2-Gateway] Install and Configuration issue

[Jason Guy]

Hi Irena,

I was not clear in my initial message...but I am using the stable/liberty
branch.
It is interesting that the master branch has this set in the plugin now.
Clearly the code is evolving a bit for Mitaka. However you helped me to
discover what was wrong (I think). I forgot to change to the liberty branch
when I installed the neutron-server container.

I am not sure how to get the l2gw commands registered with the neutron
client in my utility container. Has anyone deployed this with
openstack-ansible?

I think I found a minor bug in the liberty branch.  As I am still in the
process of setting up the network, hardware VTEP and OVSDB server. I
noticed in the l2gateway agent log file, the traceback below.  I have a
feeling it will go away when I configure the OVSDB server, but it should be
failing gracefully, rather than throwing a traceback.

Thanks for your help!
Jason

2016-03-09 10:42:19.059 15505 ERROR
networking_l2gw.services.l2gateway.agent.ovsdb.base_connection
[req-266f23da-5948-4664-8dde-934dae006d9a - - - - -] Socket error in
connecting to the OVSDB server
2016-03-09 10:42:19.059 15505 ERROR
networking_l2gw.services.l2gateway.agent.ovsdb.base_connection Traceback
(most recent call last):
2016-03-09 10:42:19.059 15505 ERROR
networking_l2gw.services.l2gateway.agent.ovsdb.base_connection   File
"/openstack/venvs/neutron-12.0.7/lib/python2.7/site-packages/networking_l2gw/services/l2gateway/agent/ovsdb/base_connection.py",
line 71, in __init__
2016-03-09 10:42:19.059 15505 ERROR
networking_l2gw.services.l2gateway.agent.ovsdb.base_connection
int(gw_config.ovsdb_port)))
2016-03-09 10:42:19.059 15505 ERROR
networking_l2gw.services.l2gateway.agent.ovsdb.base_connection   File
"/openstack/venvs/neutron-12.0.7/lib/python2.7/site-packages/eventlet/greenio/base.py",
line 240, in connect
2016-03-09 10:42:19.059 15505 ERROR
networking_l2gw.services.l2gateway.agent.ovsdb.base_connection
socket_checkerr(fd)
2016-03-09 10:42:19.059 15505 ERROR
networking_l2gw.services.l2gateway.agent.ovsdb.base_connection   File
"/openstack/venvs/neutron-12.0.7/lib/python2.7/site-packages/eventlet/greenio/base.py",
line 44, in socket_checkerr
2016-03-09 10:42:19.059 15505 ERROR
networking_l2gw.services.l2gateway.agent.ovsdb.base_connection raise
socket.error(err, errno.errorcode[err])
2016-03-09 10:42:19.059 15505 ERROR
networking_l2gw.services.l2gateway.agent.ovsdb.base_connection error:
[Errno 111] ECONNREFUSED
2016-03-09 10:42:19.059 15505 ERROR
networking_l2gw.services.l2gateway.agent.ovsdb.base_connection
2016-03-09 10:42:19.068 15505 ERROR
networking_l2gw.services.l2gateway.agent.ovsdb.manager
[req-266f23da-5948-4664-8dde-934dae006d9a - - - - -] OVSDB server 10.0.0.1
is not reachable
2016-03-09 10:42:19.069 15505 DEBUG
networking_l2gw.services.l2gateway.agent.ovsdb.manager
[req-266f23da-5948-4664-8dde-934dae006d9a - - - - -] Calling
notify_ovsdb_states _connect_to_ovsdb_server
/openstack/venvs/neutron-12.0.7/lib/python2.7/site-packages/networking_l2gw/services/l2gateway/agent/ovsdb/manager.py:135
2016-03-09 10:42:19.071 15505 DEBUG oslo_messaging._drivers.amqpdriver
[req-266f23da-5948-4664-8dde-934dae006d9a - - - - -] CAST unique_id:
9d1eac2e0f2e4df781a05fb2638b5810 exchange 'neutron' topic
'l2gateway_plugin' _send
/openstack/venvs/neutron-12.0.7/lib/python2.7/site-packages/oslo_messaging/_drivers/amqpdriver.py:448


On Wed, Mar 9, 2016 at 2:17 AM, Irena Berezovsky 
wrote:

> Hi Jason,
> According to the L2GW config, it should be set as in this line:
>
> https://github.com/openstack/networking-l2gw/blob/master/etc/l2gw_plugin.ini#L25
>
> I think it should be working as default setting, but maybe you can try to
> set this explicitly.
>
> Hope it helps,
> Irena
>
> On Tue, Mar 8, 2016 at 12:33 PM, Jason Guy 
> wrote:
>
>> Hi, I am trying to get the L2GW plugin working with my openstack setup. I
>> did the installation from the git repo using setup.py install.
>>
>> I am having trouble getting the Neutron-server to take the plugin though.
>> Here is the config line from the neutron.conf:
>> # Plugins
>> core_plugin = neutron.plugins.ml2.plugin.Ml2Plugin
>> service_plugins =
>> neutron.services.l3_router.l3_router_plugin.L3RouterPlugin,neutron.services.metering.metering_plugin.MeteringPlugin,networking_l2gw.services.l2gateway.plugin.L2GatewayPlugin
>>
>> After restarting neutron-server, I am getting this error in the
>> neutron-server.log:
>>
>> INFO neutron.manager [req-b537d3d8-5ad5-419c-a7a0-133991af38fc - - - - -]
>> Loading Plugin: networking_l2gw.services.l2gateway.plugin.L2GatewayPlugin
>> ERROR neutron.services.service_base
>> [req-b537d3d8-5ad5-419c-a7a0-133991af38fc - - - - -] No providers specified
>> for 'L2GW' service, exiting
>>
>> I do not see anything in the install instructions regarding the
>> neutron.conf configuration, so I am guessing at this point, hence the
>> email. :) I have searched and tried to figure this out by looking at the
>> code. What 

Re: [openstack-dev] [Horizon] How do we move forward with xstatic releases?

[Radomir Dopieralski]

On 03/09/2016 04:43 PM, Serg Melikyan wrote:

This is exactly my first thought. The plugins *must* depend on Horizon,
and they have to use the same versions of XStatic packages anyways,

>> so why specify the dependencies twice?


Plugins may require different xstatic library, which is not even used
by Horizon. Issue raised by Richard exists for plugins too, not only
for Horizon itself.


How would such an xstatic library conflict with what is in Horizon then,
though?

--
Radomir Dopieralski


__
OpenStack Development Mailing List (not for 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][plugins] Should we maintain example plugins?

[Evgeniy L]

Because it doesn't make much sense for a plugin developer to have scripts
to build packages for installation on slave nodes. For default template
it's better to have something minimalistic and the rest of the tasks
commented, otherwise it may create a lot of confusion.

On Wed, Mar 9, 2016 at 6:37 PM, Ilya Kutukov  wrote:

> Talking about templates I mean plugins generated by FBP from the
> `templates` folder using command you mentioned above.
>
> Why not to extend (not replace) template-generated plugins with additional
> data to provide right coverage?
>
> On Wed, Mar 9, 2016 at 6:23 PM, Evgeniy L  wrote:
>
>> Ilya,
>>
>> What do you mean by "templates" the plugin which is create by just "fpb
>> --create plugin-name"?
>> It doesn't cover enough, package installation and all range of tasks
>> executions.
>>
>> Thanks,
>>
>> On Wed, Mar 9, 2016 at 6:16 PM, Ilya Kutukov 
>> wrote:
>>
>>> Igor, i completely agree, actually plugin examples is almost a
>>> copy-paste.
>>>
>>> The only thing i see useful in the built plugins example is the ability
>>> to point some code lines, discussing plugin design and writing
>>> documentation. Why not to generate this examples automatically from
>>> templates?
>>>
>>> Also, as developer and administrator i love to use examples/templates
>>> where all essential settings and options are persist but commented (e.g.
>>> ProFTPD or Apache) and i could uncomment and copy-paste them not being
>>> afraid of typos. Also it allows to keep documentation actual and head
>>> documentation small. Duplication of inline documentation between examples
>>> and templates making things more weird and overshadows idea of inline
>>> documentation itself.
>>>
>>> Eugeny, why not to run integration tests against plugins generated from
>>> templates? It's will be even better integration tests.
>>>
>>>
>>>
>>> On Mon, Mar 7, 2016 at 4:49 PM, Igor Kalnitsky 
>>> wrote:
>>>
 > and really lowering barriers for people who just begin create plugins.

 Nonsense. First, people usually create them via running `fpb --create
 plugin-name` that generates plugin boilerplate. And that boilerplate
 won't contain that changes.

 Second, if people ain't smart enough to change few lines in
 `metadata.yaml` of generated boilerplate to make it work with latest
 Fuel, maybe it's better for them to do not develop plugins at all?

 On Fri, Mar 4, 2016 at 2:24 PM, Stanislaw Bogatkin
  wrote:
 > +1 to maintain example plugins. It is easy enough and really lowering
 > barriers for people who just begin create plugins.
 >
 > On Fri, Mar 4, 2016 at 2:08 PM, Matthew Mosesohn <
 mmoses...@mirantis.com>
 > wrote:
 >>
 >> Igor,
 >>
 >> It seems you are proposing an IKEA approach to plugins. Take Fuel's
 >> example plugin, add in the current Fuel release, and then build it.
 We
 >> maintained these plugins in the past, but now it should a manual step
 >> to test it out on the current release.
 >>
 >> What would be a more ideal situation that meets the needs of users
 and
 >> QA? Right now we have failed tests until we can decide on a solution
 >> that works for everybody.
 >>
 >> On Fri, Mar 4, 2016 at 1:26 PM, Igor Kalnitsky <
 ikalnit...@mirantis.com>
 >> wrote:
 >> > No, this is a wrong road to go.
 >> >
 >> > What if in Fuel 10 we drop v1 plugins support? What should we do?
 >> > Remove v1 example from source tree? That doesn't seem good to me.
 >> >
 >> > Example plugins are only examples. The list of supported releases
 must
 >> > be maintained on system test side, and system tests must inject
 that
 >> > information into plugin's metadata.yaml and test it.
 >> >
 >> > Again, I don't say we shouldn't test plugins. I say, tests should
 be
 >> > responsible for preparing plugins. I can say even more: tests
 should
 >> > not rely on what is produced by plugins, since it's something that
 >> > could be changed and tests start failing.
 >> >
 >> > On Thu, Mar 3, 2016 at 7:54 PM, Swann Croiset <
 scroi...@mirantis.com>
 >> > wrote:
 >> >> IMHO it is important to keep plugin examples and keep testing
 them,
 >> >> very
 >> >> valuable for plugin developers.
 >> >>
 >> >> For example, I've encountered [0] the case where "plugin as role"
 >> >> feature
 >> >> wasn't easily testable with fuel-qa because not compliant with
 the last
 >> >> plugin data structure,
 >> >> and more recently we've spotted a regression [1] with
 "vip-reservation"
 >> >> feature introduced by a change in nailgun.
 >> >> These kind of issues are time consuming for plugin developers and
 >> >> can/must
 >> >> be avoided by testing them.
 >> >>
 >> >> I 

Re: [openstack-dev] [Horizon] How do we move forward with xstatic releases?

[Monty Taylor]

On 03/07/2016 10:52 PM, Richard Jones wrote:

We've solved *most* of the issues around releasing new xstatic packages,
documented here[1] (and related documentation).

We have one final issue that's blocking us, which is that during the
xstatic release there will be a point at which Horizon may be broken
from an integrated point of view - some of the interfaces may not work
and fail tests. The process goes something like this:

​Note: this assumes that depends-on can reliably bring in patches from
all over the place into a gate environment, which is technically
possible, but not necessarily correct today.

The problem is that because we can't atomically update both
upper-constraints *and* Horizon at the same time (or upper-constraints
*and* xstatic-angular, or Horizon *and* xstatic-angular) we run into a
situation where Horizon will be running against the wrong version of
xstatic-angular.

So we break one of the basic assumptions of the OpenStack world: that
every single commit in every repository for the integrated environment
will pass tests.

In the Python world, we code around this by making Horizon compatible
with both the X and X1 versions of xstatic-angular (if it was a Python
library). In Javascript land this is much more difficult - Javascript
libraries tend to break compatibility in far more interesting ways.


Yah. Honestly, this is one of the main places where I think we get into 
trouble in linux-distro land in trying to apply the tools/techniques 
developed for one set of problems with another.



Maintaining compatibility across CSS and font releases is also a
difficult problem, though changes here are unlikely to break Horizon
enough that gate tests would fail. So, solution 1 to the problem is:

SOLUTION 1: always maintain Horizon compatibility across xstatic library
releases.

This is potentially very difficult to guarantee. So, a second solution
has been proposed:

SOLUTION 2: move the upper-constraints information for *the xstatic
libraries only* from the global upper-constraints file into Horizon's
repository.

This allows us to atomically update both Horizon and the xstatic library
version, removing the potential to break because of the version
mismatch. Unfortunately it means that we have version compatibility
issues with anything else that wants to install alongside Horizon that
also uses xstatic packages. For example, Horizon plugins. We could move
Horizon plugins into the Horizon repository to solve this. /ducks


I actually like this one a lot. I know that there is a plugin problem 
... but ... plugin installers could also consume the horizon xstatic 
constraints when installing xstatic packages?


xstatic packages are specifically workarounds for doing javascript in a 
python-centric world. Putting then in upper-constraints and actually 
treating them like actual python packages rather than what they are 
which is a clever utilization of the python ecosystem to deliver 
javascript libraries is vexing at best.




A variation on this solution is:

SOLUTION 3: allow Horizon to locally override upper-constraints for the
time needed to merge a patch in devstack.

This solution allows Horizon to atomically update itself and the xstatic
library, but it also means installing Horizon in a CI/CD environment
becomes more difficult due to the need to always pull down the
upper-constraints file and edit it. We could code this in to tox, but
that doesn't help eg. devstack which needs to also do this thing.


Or people who are deploying horizon CD from master from source and 
applying upper-constraints to get the tested version. Those people would 
have to duplicate the tox logic.



SOLUTION 4: vendor the javascript

Heh.


Heh indeed.

SOLUTION 4.alt: use npm/bower instead of xstatic to pull the javascript.



SOLUTION 5: have dependencies on xstatic move from global requirements
to Horizon

This is similar to 2 & 3 with some of the same drawbacks (multiple users
of xstatic) but also we'd need a change to global-requirements handling
to ignore some entries in Horizon's requirements.

Your thoughts on any and all of the above are requested.


Thanks for your work on this - it's a hard problem - especially with 
sets of potentially conflicting desires from your consumers.



__
OpenStack Development Mailing 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][infra] Switching images for testing

[Andreas Jaeger]

We're migrating already since Friday jobs using the so-called
bare-trusty images to ubuntu-trusty images.

These images are used for for most of unit and functional tests, for
documentation etc. Devstack is still run on devstack-trusty nodes for
now, but will also move at a later date.

A direct benefit of this change is that bare-trusty images are only
available on Rackspace clouds, while the new ubuntu-trusty images are
available in all clouds that the CI systems use. This allows a better
load balancing for these.

We still have to convert some jobs and solve a few problems with
specific jobs before we can make a general announcement and explain
new possibilities that this change will bring projects.

For now, if jobs suddenly fail, please check - as usual - the log
files and if there is anything strange happening that always worked,
please raise it on the #openstack-infra IRC channel.

One note: We converted some names of jobs as well, so intead of
gate-REPO-tox-ENVIRONMENT we change these to
gate-REPO-tox-nodb-ENVIRONMENT if no MySQL/PostgreSQL databases are
needed and otherwise to gate-REPO-tox-db-ENVIRONMENT. As final step,
we will rename the nodb variant as default variant. Open changes are
[1] and [2].

A more detailed announcement will come once this change is done.

Andreas

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


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

Re: [openstack-dev] [Horizon] How do we move forward with xstatic releases?

[Serg Melikyan]

>This is exactly my first thought. The plugins *must* depend on Horizon, and 
>they have to use the same versions of XStatic packages anyways, so why specify 
>the dependencies twice?

Plugins may require different xstatic library, which is not even used
by Horizon. Issue raised by Richard exists for plugins too, not only
for Horizon itself.


On Wed, Mar 9, 2016 at 12:24 AM, Radomir Dopieralski
 wrote:
> On 03/08/2016 11:43 PM, David Lyle wrote:
>
>> I'm wondering if since horizon is really the only project consuming
>> these xstatic libraries and none are likely to venture down this path of
>> madness with us that it would be safe to manage the xstatic requirements
>> and upper-constraints locally.
>>
>> Technically the plugins for horizon depend on this, but they depend via
>> horizon. If they require specific versions that are not supported by
>> Horizon, I think all bets are off anyway.
>
>
> This is exactly my first thought. The plugins *must* depend on Horizon,
> and they have to use the same versions of XStatic packages anyways, so
> why specify the dependencies twice? If the changes between versions are
> so big as to be breaking, then the plugins have to be updated to work
> with the new Horizon anyways.
>
> --
> Radomir Dopieralski
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Serg Melikyan, Senior Software Engineer at Mirantis, Inc.
http://mirantis.com | smelik...@mirantis.com

+1 (650) 440-8979

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

[Vikram Hosakote (vhosakot)]

FYI, the bug is seen in Ubuntu gate just on  devstack-trusty-rax  machine and
not on  devstack-trusty-osic  and  devstack-trusty-ovh.

Regards,
Vikram Hosakote
IRC: vhosakot

From: "Steven Dake (stdake)" >
Reply-To: 
"openstack-dev@lists.openstack.org" 
>
Date: Wednesday, March 9, 2016 at 9:50 AM
To: 
"openstack-dev@lists.openstack.org" 
>
Subject: [openstack-dev] [kolla] ubuntu deploy gate

The ubuntu deploy gate is failing because of commit 
7f6de0a7e0d784181a6f99270768712e761f113a.

Please see review https://review.openstack.org/#/c/290243/ for more details.

For the moment ignore the ubuntu deploy gate until the appropriate fix is 
merged.

TIA
-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] [fuel][plugins] Should we maintain example plugins?

[Ilya Kutukov]

Talking about templates I mean plugins generated by FBP from the
`templates` folder using command you mentioned above.

Why not to extend (not replace) template-generated plugins with additional
data to provide right coverage?

On Wed, Mar 9, 2016 at 6:23 PM, Evgeniy L  wrote:

> Ilya,
>
> What do you mean by "templates" the plugin which is create by just "fpb
> --create plugin-name"?
> It doesn't cover enough, package installation and all range of tasks
> executions.
>
> Thanks,
>
> On Wed, Mar 9, 2016 at 6:16 PM, Ilya Kutukov 
> wrote:
>
>> Igor, i completely agree, actually plugin examples is almost a copy-paste.
>>
>> The only thing i see useful in the built plugins example is the ability
>> to point some code lines, discussing plugin design and writing
>> documentation. Why not to generate this examples automatically from
>> templates?
>>
>> Also, as developer and administrator i love to use examples/templates
>> where all essential settings and options are persist but commented (e.g.
>> ProFTPD or Apache) and i could uncomment and copy-paste them not being
>> afraid of typos. Also it allows to keep documentation actual and head
>> documentation small. Duplication of inline documentation between examples
>> and templates making things more weird and overshadows idea of inline
>> documentation itself.
>>
>> Eugeny, why not to run integration tests against plugins generated from
>> templates? It's will be even better integration tests.
>>
>>
>>
>> On Mon, Mar 7, 2016 at 4:49 PM, Igor Kalnitsky 
>> wrote:
>>
>>> > and really lowering barriers for people who just begin create plugins.
>>>
>>> Nonsense. First, people usually create them via running `fpb --create
>>> plugin-name` that generates plugin boilerplate. And that boilerplate
>>> won't contain that changes.
>>>
>>> Second, if people ain't smart enough to change few lines in
>>> `metadata.yaml` of generated boilerplate to make it work with latest
>>> Fuel, maybe it's better for them to do not develop plugins at all?
>>>
>>> On Fri, Mar 4, 2016 at 2:24 PM, Stanislaw Bogatkin
>>>  wrote:
>>> > +1 to maintain example plugins. It is easy enough and really lowering
>>> > barriers for people who just begin create plugins.
>>> >
>>> > On Fri, Mar 4, 2016 at 2:08 PM, Matthew Mosesohn <
>>> mmoses...@mirantis.com>
>>> > wrote:
>>> >>
>>> >> Igor,
>>> >>
>>> >> It seems you are proposing an IKEA approach to plugins. Take Fuel's
>>> >> example plugin, add in the current Fuel release, and then build it. We
>>> >> maintained these plugins in the past, but now it should a manual step
>>> >> to test it out on the current release.
>>> >>
>>> >> What would be a more ideal situation that meets the needs of users and
>>> >> QA? Right now we have failed tests until we can decide on a solution
>>> >> that works for everybody.
>>> >>
>>> >> On Fri, Mar 4, 2016 at 1:26 PM, Igor Kalnitsky <
>>> ikalnit...@mirantis.com>
>>> >> wrote:
>>> >> > No, this is a wrong road to go.
>>> >> >
>>> >> > What if in Fuel 10 we drop v1 plugins support? What should we do?
>>> >> > Remove v1 example from source tree? That doesn't seem good to me.
>>> >> >
>>> >> > Example plugins are only examples. The list of supported releases
>>> must
>>> >> > be maintained on system test side, and system tests must inject that
>>> >> > information into plugin's metadata.yaml and test it.
>>> >> >
>>> >> > Again, I don't say we shouldn't test plugins. I say, tests should be
>>> >> > responsible for preparing plugins. I can say even more: tests should
>>> >> > not rely on what is produced by plugins, since it's something that
>>> >> > could be changed and tests start failing.
>>> >> >
>>> >> > On Thu, Mar 3, 2016 at 7:54 PM, Swann Croiset <
>>> scroi...@mirantis.com>
>>> >> > wrote:
>>> >> >> IMHO it is important to keep plugin examples and keep testing them,
>>> >> >> very
>>> >> >> valuable for plugin developers.
>>> >> >>
>>> >> >> For example, I've encountered [0] the case where "plugin as role"
>>> >> >> feature
>>> >> >> wasn't easily testable with fuel-qa because not compliant with the
>>> last
>>> >> >> plugin data structure,
>>> >> >> and more recently we've spotted a regression [1] with
>>> "vip-reservation"
>>> >> >> feature introduced by a change in nailgun.
>>> >> >> These kind of issues are time consuming for plugin developers and
>>> >> >> can/must
>>> >> >> be avoided by testing them.
>>> >> >>
>>> >> >> I don't even understand why the question is raised while fuel
>>> plugins
>>> >> >> are
>>> >> >> supposed to be supported and more and more used [3], even by
>>> murano [4]
>>> >> >> ...
>>> >> >>
>>> >> >> [0] https://bugs.launchpad.net/fuel/+bug/1543962
>>> >> >> [1] https://bugs.launchpad.net/fuel/+bug/1551320
>>> >> >> [3]
>>> >> >>
>>> >> >>
>>> http://lists.openstack.org/pipermail/openstack-dev/2016-February/085636.html
>>> >> >> [4] https://review.openstack.org/#/c/286310/
>>> >> >>
>>> >> 

Re: [openstack-dev] [neutron][release] Releasing python-neutronclient 4.1.2?

[Miguel Angel Ajo Pelayo]

On Wed, Mar 9, 2016 at 4:16 PM, Doug Hellmann  wrote:

> Excerpts from Armando M.'s message of 2016-03-08 15:43:05 -0700:
> > On 8 March 2016 at 15:07, Doug Hellmann  wrote:
> >
> > > Excerpts from Armando M.'s message of 2016-03-08 12:49:16 -0700:
> > > > Hi folks,
> > > >
> > > > There's a feature or two that are pending to be delivered in Mitaka
> > > [1,2],
> > > > and those involve changes to both the server and client sides.
> Ideally
> > > we'd
> > > > merge both sides in time for Mitaka RC and that implies that we
> would be
> > > > able to release a new version of the client including changes [3,4].
> This
> > > > is especially important since a new client release would be
> beneficial to
> > > > improving test coverage as needed by [5].
> > > >
> > > > Considering what we released already, and what the tip of master is
> for
> > > the
> > > > client [6], I can't see any side effect that a new neutronclient
> release
> > > > may introduce.
> > > >
> > > > Having said that, I am leaning towards the all-or-none approach, but
> the
> > > > 'all' approach is predicated on the fact that we are indeed allowed
> to
> > > > release a new client and touch the global requirements.
> > > >
> > > > What's the release team's recommendation? Based on it, we may want to
> > > > decide to defer these to as soon as N master opens up.
> > >
> > > I'm a bit reluctant to start touching the requirements lists for
> > > feature work. We do have some bug fixes in the pipeline that will
> > > require library releases, but those are for bugs not new features.
> > > We also have one or two libs where feature work needed to be extended,
> > > but none of those have dependencies outside of the project producing
> > > them.
> > >
> > > The main reason to require a client release is for some *other* project
> > > to take advantage of the new feature work. Is that planned?
> > >
> >
> > Thanks for the prompt reply. Neutron would be the only consumer of these
> > additions, and no other project has pending work to leverage these
> > capabilities.
>
> In that case, I don't think we want to make an exception. Although
> Neutron is the only user of this feature, I counted more than 50 other
> projects that have python-neutronclient in a requirements file, and
> that's a lot of potential for impact with a new release.
>
> It seems like the options are to wait for Newton to land both parts of
> the feature, or to land the server side during Mitaka and release a
> feature update to the client as soon as Newton development opens.
>
> Doug
>

Yes, if anyone want's more detail, we discussed that in the
qos-meeting today [1], thank you Doug, for joining us.

I would like to ask for the inclusion of the server side, regardless
of the client bits. Fullstack would have to stay out, but I believe
the api-tests, unit tests, and functional tests included in the patch
will maintain the feature stability.

Users would have the chance to make use of the feature via direct
API calls without the client, or by bumping to neutronclient 4.2.x when
that's available. Distros would be able to backport the neutronclient
patch at their will.

I ask for it, not only for the sake of the feature, which I believe is not
critical, but because Comcast and other related contributors have been
patient enough (5-6 cycles?), learned and collaborated the U/S way to
get this finally in while helping with L2 agent extensibility and other
technical debt in the way. And because, the earlier the feature gets
used, the early we could iron out any possible bug features come with.


Best regards,
Miguel Ángel.

[1]
http://eavesdrop.openstack.org/meetings/neutron_qos/2016/neutron_qos.2016-03-09-14.03.log.html
 (around 15:37)


>
> >
> > >
> > > Doug
> > >
> > > >
> > > > Many thanks,
> > > > Armando
> > > >
> > > > [1] https://review.openstack.org/#/q/topic:bug/1468353
> > > > [2] https://review.openstack.org/#/q/topic:bug/1521783
> > > > [3] https://review.openstack.org/#/c/254280/
> > > > [4] https://review.openstack.org/#/c/288187/
> > > > [5] https://review.openstack.org/#/c/288392/
> > > > [6]
> > > >
> > >
> https://github.com/openstack/python-neutronclient/commit/8460b0dbb354a304a112be13c63cb933ebe1927a
> > >
> > >
> __
> > > OpenStack Development Mailing List (not for usage questions)
> > > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > >
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage 

Re: [openstack-dev] [fuel][plugins] Should we maintain example plugins?

[Ilya Kutukov]

r/is almost a copy-paste/is almost a copy-paste from plugins templates

On Wed, Mar 9, 2016 at 6:16 PM, Ilya Kutukov  wrote:

> Igor, i completely agree, actually plugin examples is almost a copy-paste.
>
> The only thing i see useful in the built plugins example is the ability to
> point some code lines, discussing plugin design and writing documentation.
> Why not to generate this examples automatically from templates?
>
> Also, as developer and administrator i love to use examples/templates
> where all essential settings and options are persist but commented (e.g.
> ProFTPD or Apache) and i could uncomment and copy-paste them not being
> afraid of typos. Also it allows to keep documentation actual and head
> documentation small. Duplication of inline documentation between examples
> and templates making things more weird and overshadows idea of inline
> documentation itself.
>
> Eugeny, why not to run integration tests against plugins generated from
> templates? It's will be even better integration tests.
>
>
>
> On Mon, Mar 7, 2016 at 4:49 PM, Igor Kalnitsky 
> wrote:
>
>> > and really lowering barriers for people who just begin create plugins.
>>
>> Nonsense. First, people usually create them via running `fpb --create
>> plugin-name` that generates plugin boilerplate. And that boilerplate
>> won't contain that changes.
>>
>> Second, if people ain't smart enough to change few lines in
>> `metadata.yaml` of generated boilerplate to make it work with latest
>> Fuel, maybe it's better for them to do not develop plugins at all?
>>
>> On Fri, Mar 4, 2016 at 2:24 PM, Stanislaw Bogatkin
>>  wrote:
>> > +1 to maintain example plugins. It is easy enough and really lowering
>> > barriers for people who just begin create plugins.
>> >
>> > On Fri, Mar 4, 2016 at 2:08 PM, Matthew Mosesohn <
>> mmoses...@mirantis.com>
>> > wrote:
>> >>
>> >> Igor,
>> >>
>> >> It seems you are proposing an IKEA approach to plugins. Take Fuel's
>> >> example plugin, add in the current Fuel release, and then build it. We
>> >> maintained these plugins in the past, but now it should a manual step
>> >> to test it out on the current release.
>> >>
>> >> What would be a more ideal situation that meets the needs of users and
>> >> QA? Right now we have failed tests until we can decide on a solution
>> >> that works for everybody.
>> >>
>> >> On Fri, Mar 4, 2016 at 1:26 PM, Igor Kalnitsky <
>> ikalnit...@mirantis.com>
>> >> wrote:
>> >> > No, this is a wrong road to go.
>> >> >
>> >> > What if in Fuel 10 we drop v1 plugins support? What should we do?
>> >> > Remove v1 example from source tree? That doesn't seem good to me.
>> >> >
>> >> > Example plugins are only examples. The list of supported releases
>> must
>> >> > be maintained on system test side, and system tests must inject that
>> >> > information into plugin's metadata.yaml and test it.
>> >> >
>> >> > Again, I don't say we shouldn't test plugins. I say, tests should be
>> >> > responsible for preparing plugins. I can say even more: tests should
>> >> > not rely on what is produced by plugins, since it's something that
>> >> > could be changed and tests start failing.
>> >> >
>> >> > On Thu, Mar 3, 2016 at 7:54 PM, Swann Croiset > >
>> >> > wrote:
>> >> >> IMHO it is important to keep plugin examples and keep testing them,
>> >> >> very
>> >> >> valuable for plugin developers.
>> >> >>
>> >> >> For example, I've encountered [0] the case where "plugin as role"
>> >> >> feature
>> >> >> wasn't easily testable with fuel-qa because not compliant with the
>> last
>> >> >> plugin data structure,
>> >> >> and more recently we've spotted a regression [1] with
>> "vip-reservation"
>> >> >> feature introduced by a change in nailgun.
>> >> >> These kind of issues are time consuming for plugin developers and
>> >> >> can/must
>> >> >> be avoided by testing them.
>> >> >>
>> >> >> I don't even understand why the question is raised while fuel
>> plugins
>> >> >> are
>> >> >> supposed to be supported and more and more used [3], even by murano
>> [4]
>> >> >> ...
>> >> >>
>> >> >> [0] https://bugs.launchpad.net/fuel/+bug/1543962
>> >> >> [1] https://bugs.launchpad.net/fuel/+bug/1551320
>> >> >> [3]
>> >> >>
>> >> >>
>> http://lists.openstack.org/pipermail/openstack-dev/2016-February/085636.html
>> >> >> [4] https://review.openstack.org/#/c/286310/
>> >> >>
>> >> >> On Thu, Mar 3, 2016 at 3:19 PM, Matthew Mosesohn
>> >> >> 
>> >> >> wrote:
>> >> >>>
>> >> >>> Hi Fuelers,
>> >> >>>
>> >> >>> I would like to bring your attention a dilemma we have here. It
>> seems
>> >> >>> that there is a dispute as to whether we should maintain the
>> releases
>> >> >>> list for example plugins[0]. In this case, this is for adding
>> version
>> >> >>> 9.0 to the list.
>> >> >>>
>> >> >>> Right now, we run a swarm test that tries to install the example
>> >> >>> plugin and do a deployment, but 

Re: [openstack-dev] [fuel][plugins] Should we maintain example plugins?

[Evgeniy L]

Ilya,

What do you mean by "templates" the plugin which is create by just "fpb
--create plugin-name"?
It doesn't cover enough, package installation and all range of tasks
executions.

Thanks,

On Wed, Mar 9, 2016 at 6:16 PM, Ilya Kutukov  wrote:

> Igor, i completely agree, actually plugin examples is almost a copy-paste.
>
> The only thing i see useful in the built plugins example is the ability to
> point some code lines, discussing plugin design and writing documentation.
> Why not to generate this examples automatically from templates?
>
> Also, as developer and administrator i love to use examples/templates
> where all essential settings and options are persist but commented (e.g.
> ProFTPD or Apache) and i could uncomment and copy-paste them not being
> afraid of typos. Also it allows to keep documentation actual and head
> documentation small. Duplication of inline documentation between examples
> and templates making things more weird and overshadows idea of inline
> documentation itself.
>
> Eugeny, why not to run integration tests against plugins generated from
> templates? It's will be even better integration tests.
>
>
>
> On Mon, Mar 7, 2016 at 4:49 PM, Igor Kalnitsky 
> wrote:
>
>> > and really lowering barriers for people who just begin create plugins.
>>
>> Nonsense. First, people usually create them via running `fpb --create
>> plugin-name` that generates plugin boilerplate. And that boilerplate
>> won't contain that changes.
>>
>> Second, if people ain't smart enough to change few lines in
>> `metadata.yaml` of generated boilerplate to make it work with latest
>> Fuel, maybe it's better for them to do not develop plugins at all?
>>
>> On Fri, Mar 4, 2016 at 2:24 PM, Stanislaw Bogatkin
>>  wrote:
>> > +1 to maintain example plugins. It is easy enough and really lowering
>> > barriers for people who just begin create plugins.
>> >
>> > On Fri, Mar 4, 2016 at 2:08 PM, Matthew Mosesohn <
>> mmoses...@mirantis.com>
>> > wrote:
>> >>
>> >> Igor,
>> >>
>> >> It seems you are proposing an IKEA approach to plugins. Take Fuel's
>> >> example plugin, add in the current Fuel release, and then build it. We
>> >> maintained these plugins in the past, but now it should a manual step
>> >> to test it out on the current release.
>> >>
>> >> What would be a more ideal situation that meets the needs of users and
>> >> QA? Right now we have failed tests until we can decide on a solution
>> >> that works for everybody.
>> >>
>> >> On Fri, Mar 4, 2016 at 1:26 PM, Igor Kalnitsky <
>> ikalnit...@mirantis.com>
>> >> wrote:
>> >> > No, this is a wrong road to go.
>> >> >
>> >> > What if in Fuel 10 we drop v1 plugins support? What should we do?
>> >> > Remove v1 example from source tree? That doesn't seem good to me.
>> >> >
>> >> > Example plugins are only examples. The list of supported releases
>> must
>> >> > be maintained on system test side, and system tests must inject that
>> >> > information into plugin's metadata.yaml and test it.
>> >> >
>> >> > Again, I don't say we shouldn't test plugins. I say, tests should be
>> >> > responsible for preparing plugins. I can say even more: tests should
>> >> > not rely on what is produced by plugins, since it's something that
>> >> > could be changed and tests start failing.
>> >> >
>> >> > On Thu, Mar 3, 2016 at 7:54 PM, Swann Croiset > >
>> >> > wrote:
>> >> >> IMHO it is important to keep plugin examples and keep testing them,
>> >> >> very
>> >> >> valuable for plugin developers.
>> >> >>
>> >> >> For example, I've encountered [0] the case where "plugin as role"
>> >> >> feature
>> >> >> wasn't easily testable with fuel-qa because not compliant with the
>> last
>> >> >> plugin data structure,
>> >> >> and more recently we've spotted a regression [1] with
>> "vip-reservation"
>> >> >> feature introduced by a change in nailgun.
>> >> >> These kind of issues are time consuming for plugin developers and
>> >> >> can/must
>> >> >> be avoided by testing them.
>> >> >>
>> >> >> I don't even understand why the question is raised while fuel
>> plugins
>> >> >> are
>> >> >> supposed to be supported and more and more used [3], even by murano
>> [4]
>> >> >> ...
>> >> >>
>> >> >> [0] https://bugs.launchpad.net/fuel/+bug/1543962
>> >> >> [1] https://bugs.launchpad.net/fuel/+bug/1551320
>> >> >> [3]
>> >> >>
>> >> >>
>> http://lists.openstack.org/pipermail/openstack-dev/2016-February/085636.html
>> >> >> [4] https://review.openstack.org/#/c/286310/
>> >> >>
>> >> >> On Thu, Mar 3, 2016 at 3:19 PM, Matthew Mosesohn
>> >> >> 
>> >> >> wrote:
>> >> >>>
>> >> >>> Hi Fuelers,
>> >> >>>
>> >> >>> I would like to bring your attention a dilemma we have here. It
>> seems
>> >> >>> that there is a dispute as to whether we should maintain the
>> releases
>> >> >>> list for example plugins[0]. In this case, this is for adding
>> version
>> >> >>> 9.0 to the list.
>> >> 

Re: [openstack-dev] [all][release] Release countdown for week R-4, Mar 7 - 11

[Doug Hellmann]

Excerpts from Sergey Kraynev's message of 2016-03-09 11:08:32 +0300:
> Hi Doug.
> 
> I have one question related with last item: "Release actions".
> Who will prepare patches for Reno and for updating .gitreview?
> Should it be done by related project team or it will be done by someone else?

The script that we use to create the stable branch will generate and
submit those patches automatically, so you just need to review and
approve them.

Doug

> 
> On 5 March 2016 at 02:01, Doug Hellmann  wrote:
> > The Mitaka 3 milestone has passed, and we're on our way to preparing
> > release candidates. See Thierry's email [1] for details about the
> > artifacts produced for the milestone.
> >
> > [1] 
> > http://lists.openstack.org/pipermail/openstack-announce/2016-March/001002.html
> >
> > Focus
> > -
> >
> > Project teams should be concentrating on finishing work for which
> > a feature freeze exception (FFE) was granted, and fixing release-critical
> > bugs before preparing the release candidates during week R-3. Any
> > FFE work not completed this week should be postponed to the next
> > cycle.
> >
> > General Notes
> > -
> >
> > The global requirements list is frozen. If you need to change a
> > dependency, for example to include a bug fix in one of our libraries
> > or an upstream library, please provide enough detail in the change
> > request to allow the requirements review team to evaluate the change.
> >
> > User-facing strings are frozen to allow the translation team time
> > to finish their work.
> >
> > Release Actions
> > ---
> >
> > The stable/mitaka branches for libraries will be created early
> > during R-4. After the branch is created, a patch will be submitted
> > to update the .gitreview file. If the project uses reno, another
> > patch will be submitted on master to add a mitaka-specific page to
> > the reno build.  Please watch for those patches and prioritize
> > reviewing them.
> >
> > Important Dates
> > ---
> >
> > RC Target Week: R-3, Mar 14-18
> >
> > Mitaka release schedule: http://releases.openstack.org/mitaka/schedule.html
> >
> > __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

__
OpenStack Development Mailing List (not for 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][release] Releasing python-neutronclient 4.1.2?

[Doug Hellmann]

Excerpts from Armando M.'s message of 2016-03-08 15:43:05 -0700:
> On 8 March 2016 at 15:07, Doug Hellmann  wrote:
> 
> > Excerpts from Armando M.'s message of 2016-03-08 12:49:16 -0700:
> > > Hi folks,
> > >
> > > There's a feature or two that are pending to be delivered in Mitaka
> > [1,2],
> > > and those involve changes to both the server and client sides. Ideally
> > we'd
> > > merge both sides in time for Mitaka RC and that implies that we would be
> > > able to release a new version of the client including changes [3,4]. This
> > > is especially important since a new client release would be beneficial to
> > > improving test coverage as needed by [5].
> > >
> > > Considering what we released already, and what the tip of master is for
> > the
> > > client [6], I can't see any side effect that a new neutronclient release
> > > may introduce.
> > >
> > > Having said that, I am leaning towards the all-or-none approach, but the
> > > 'all' approach is predicated on the fact that we are indeed allowed to
> > > release a new client and touch the global requirements.
> > >
> > > What's the release team's recommendation? Based on it, we may want to
> > > decide to defer these to as soon as N master opens up.
> >
> > I'm a bit reluctant to start touching the requirements lists for
> > feature work. We do have some bug fixes in the pipeline that will
> > require library releases, but those are for bugs not new features.
> > We also have one or two libs where feature work needed to be extended,
> > but none of those have dependencies outside of the project producing
> > them.
> >
> > The main reason to require a client release is for some *other* project
> > to take advantage of the new feature work. Is that planned?
> >
> 
> Thanks for the prompt reply. Neutron would be the only consumer of these
> additions, and no other project has pending work to leverage these
> capabilities.

In that case, I don't think we want to make an exception. Although
Neutron is the only user of this feature, I counted more than 50 other
projects that have python-neutronclient in a requirements file, and
that's a lot of potential for impact with a new release.

It seems like the options are to wait for Newton to land both parts of
the feature, or to land the server side during Mitaka and release a
feature update to the client as soon as Newton development opens.

Doug

> 
> >
> > Doug
> >
> > >
> > > Many thanks,
> > > Armando
> > >
> > > [1] https://review.openstack.org/#/q/topic:bug/1468353
> > > [2] https://review.openstack.org/#/q/topic:bug/1521783
> > > [3] https://review.openstack.org/#/c/254280/
> > > [4] https://review.openstack.org/#/c/288187/
> > > [5] https://review.openstack.org/#/c/288392/
> > > [6]
> > >
> > https://github.com/openstack/python-neutronclient/commit/8460b0dbb354a304a112be13c63cb933ebe1927a
> >
> > __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >

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

Re: [openstack-dev] [fuel][plugins] Should we maintain example plugins?

[Ilya Kutukov]

Igor, i completely agree, actually plugin examples is almost a copy-paste.

The only thing i see useful in the built plugins example is the ability to
point some code lines, discussing plugin design and writing documentation.
Why not to generate this examples automatically from templates?

Also, as developer and administrator i love to use examples/templates where
all essential settings and options are persist but commented (e.g. ProFTPD
or Apache) and i could uncomment and copy-paste them not being afraid of
typos. Also it allows to keep documentation actual and head documentation
small. Duplication of inline documentation between examples and templates
making things more weird and overshadows idea of inline documentation
itself.

Eugeny, why not to run integration tests against plugins generated from
templates? It's will be even better integration tests.



On Mon, Mar 7, 2016 at 4:49 PM, Igor Kalnitsky 
wrote:

> > and really lowering barriers for people who just begin create plugins.
>
> Nonsense. First, people usually create them via running `fpb --create
> plugin-name` that generates plugin boilerplate. And that boilerplate
> won't contain that changes.
>
> Second, if people ain't smart enough to change few lines in
> `metadata.yaml` of generated boilerplate to make it work with latest
> Fuel, maybe it's better for them to do not develop plugins at all?
>
> On Fri, Mar 4, 2016 at 2:24 PM, Stanislaw Bogatkin
>  wrote:
> > +1 to maintain example plugins. It is easy enough and really lowering
> > barriers for people who just begin create plugins.
> >
> > On Fri, Mar 4, 2016 at 2:08 PM, Matthew Mosesohn  >
> > wrote:
> >>
> >> Igor,
> >>
> >> It seems you are proposing an IKEA approach to plugins. Take Fuel's
> >> example plugin, add in the current Fuel release, and then build it. We
> >> maintained these plugins in the past, but now it should a manual step
> >> to test it out on the current release.
> >>
> >> What would be a more ideal situation that meets the needs of users and
> >> QA? Right now we have failed tests until we can decide on a solution
> >> that works for everybody.
> >>
> >> On Fri, Mar 4, 2016 at 1:26 PM, Igor Kalnitsky  >
> >> wrote:
> >> > No, this is a wrong road to go.
> >> >
> >> > What if in Fuel 10 we drop v1 plugins support? What should we do?
> >> > Remove v1 example from source tree? That doesn't seem good to me.
> >> >
> >> > Example plugins are only examples. The list of supported releases must
> >> > be maintained on system test side, and system tests must inject that
> >> > information into plugin's metadata.yaml and test it.
> >> >
> >> > Again, I don't say we shouldn't test plugins. I say, tests should be
> >> > responsible for preparing plugins. I can say even more: tests should
> >> > not rely on what is produced by plugins, since it's something that
> >> > could be changed and tests start failing.
> >> >
> >> > On Thu, Mar 3, 2016 at 7:54 PM, Swann Croiset 
> >> > wrote:
> >> >> IMHO it is important to keep plugin examples and keep testing them,
> >> >> very
> >> >> valuable for plugin developers.
> >> >>
> >> >> For example, I've encountered [0] the case where "plugin as role"
> >> >> feature
> >> >> wasn't easily testable with fuel-qa because not compliant with the
> last
> >> >> plugin data structure,
> >> >> and more recently we've spotted a regression [1] with
> "vip-reservation"
> >> >> feature introduced by a change in nailgun.
> >> >> These kind of issues are time consuming for plugin developers and
> >> >> can/must
> >> >> be avoided by testing them.
> >> >>
> >> >> I don't even understand why the question is raised while fuel plugins
> >> >> are
> >> >> supposed to be supported and more and more used [3], even by murano
> [4]
> >> >> ...
> >> >>
> >> >> [0] https://bugs.launchpad.net/fuel/+bug/1543962
> >> >> [1] https://bugs.launchpad.net/fuel/+bug/1551320
> >> >> [3]
> >> >>
> >> >>
> http://lists.openstack.org/pipermail/openstack-dev/2016-February/085636.html
> >> >> [4] https://review.openstack.org/#/c/286310/
> >> >>
> >> >> On Thu, Mar 3, 2016 at 3:19 PM, Matthew Mosesohn
> >> >> 
> >> >> wrote:
> >> >>>
> >> >>> Hi Fuelers,
> >> >>>
> >> >>> I would like to bring your attention a dilemma we have here. It
> seems
> >> >>> that there is a dispute as to whether we should maintain the
> releases
> >> >>> list for example plugins[0]. In this case, this is for adding
> version
> >> >>> 9.0 to the list.
> >> >>>
> >> >>> Right now, we run a swarm test that tries to install the example
> >> >>> plugin and do a deployment, but it's failing only for this reason. I
> >> >>> should add that this is the only automated daily test that will
> verify
> >> >>> that our plugin framework actually works. During the Mitaka
> >> >>> development  cycle, we already had an extended period where plugins
> >> >>> were broken[1]. 

Re: [openstack-dev] [app-catalog] Nominating Kirill Zaitsev to App Catalog Core

[Kirill Zaitsev]

Thanks everyone, this is an honor and great responsibility. I would do my best 
as App Catalog Core. 

-- 
Kirill Zaitsev
Software Engineer
Mirantis, Inc

On 9 March 2016 at 05:50:53, Christopher Aedo (d...@aedo.net) wrote:

On Thu, Mar 3, 2016 at 1:10 PM, Christopher Aedo  wrote:  
> I'd like to propose Kirill Zaitsev to the core team for app-catalog  
> and app-catalog-ui.  
> Kirill has been actively involved with the Community App Catalog since  
> nearly the beginning of the project, and more recently has been doing  
> the heavy lifting around implementing GLARE for a new backend.  
>  
> I think he would be an excellent addition - please vote, thanks!  

I failed to set a deadline here, but expected no one would object to  
this proposal. It's been nearly a week so I feel safe in welcoming  
Kirill as an app-catalog core - congrats!  

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