Re: [openstack-dev] [Neutron][ml2][Manila] API to query segments used during port binding

2016-03-08 Thread Sukhdev Kapur
Hi Marc,

I am driving the ironic-ml2 integration and introduced baremetal type for
vmic_type.
You can very much use the same integration here - however, I am not
completely clear about your use case.
Do you want neutron/ML2 to plumb the network for Manila or do you want to
find out what VLAN (segmentation id) is used on the segment which connects
TOR to the storage device?

You had this on the agenda of ML2 meeting for tomorrow and I was going to
discuss this with you in the meeting. But, I noticed that you removed it
from the agenda. Do you have what you need? If not, you may want to join us
in the ML2 meeting tomorrow and we can discuss this use case there.

-Sukhdev


On Tue, Mar 1, 2016 at 1:08 AM, Koderer, Marc  wrote:

>
> On 01 Mar 2016, at 06:22, Kevin Benton  wrote:
>
> >This seems gross and backwards. It makes sense as a short term hack but
> given that we have time to design this correctly I'd prefer to get this
> information in a more straighforward way.
>
> Well it depends on what is happening here. If Manilla is wiring up a
> specific VLAN for a port, that makes it part of the port binding process,
> in which case it should be an ML2 driver. Can you provide some more details
> about what Manilla is doing with this info?
>
>
> The VLAN segment ID and IP address is used in the share driver to
> configure the
> corresponding interface resources within the storage. Just to give some
> examples:
>
>  - NetApp driver uses it to create a logical interface and assign it to a
>“storage virtual machine” [1]
>  - EMC driver does it in similar manner [2]
>
> My idea was to use the same principle as ironic ml2 intregration is doing
> [3]
> by setting the vnic_type to “baremetal”.
>
> In Manila's current implementation storage drivers are also responsible to
> setup the right networking setup. Would you suggest to move this part into
> the
> port binding phase?
>
> Regards
> Marc
>
>
> [1]:
> https://github.com/openstack/manila/blob/master/manila/share/drivers/netapp/dataontap/cluster_mode/lib_multi_svm.py#L272
> [2]:
> https://github.com/openstack/manila/blob/master/manila/share/drivers/emc/plugins/vnx/connection.py#L609
> [3]:
> https://specs.openstack.org/openstack/ironic-specs/specs/not-implemented/ironic-ml2-integration.html
>
>
>
> On Mon, Feb 29, 2016 at 5:29 PM, Ben Swartzlander 
> wrote:
>
>> On 02/29/2016 04:38 PM, Kevin Benton wrote:
>>
>>> You're correct. Right now there is no way via the HTTP API to find which
>>> segments a port is bound to.
>>> This is something we can certainly consider adding, but it will need an
>>> RFE so it wouldn't land until Newton at the earliest.
>>>
>>
>> I believe Newton is the target for this work. This is feature freeze week
>> after all.
>>
>> Have you considered writing an ML2 driver that just notifies Manilla of
>>> the port's segment info? All of this information is available to ML2
>>> drivers in the PortContext object that is passed to them.
>>>
>>
>> This seems gross and backwards. It makes sense as a short term hack but
>> given that we have time to design this correctly I'd prefer to get this
>> information in a more straighforward way.
>>
>> -Ben Swartzlander
>>
>>
>> On Mon, Feb 29, 2016 at 6:48 AM, Ihar Hrachyshka >> > wrote:
>>>
>>> Fixed neutron tag in the subject.
>>>
>>> Marc > wrote:
>>>
>>> Hi Neutron team,
>>>
>>> I am currently working on a feature for hierarchical port
>>> binding support in
>>> Manila [1] [2]. Just to give some context: In the current
>>> implementation Manila
>>> creates a neutron port but let it unbound (state DOWN).
>>> Therefore Manila uses
>>> the port create only retrieve an IP address and segmentation ID
>>> (some drivers
>>> only support VLAN here).
>>>
>>> My idea is to change this behavior and do an actual port binding
>>> action so that
>>> the configuration of VLAN isn’t a manual job any longer. And
>>> that multi-segment
>>> and HPB is supported on the long-run.
>>>
>>> My current issue is: How can Manila retrieve the segment
>>> information for a
>>> bound port? Manila only is interested in the last (bottom)
>>> segmentation ID
>>> since I assume the storage is connected to a ToR switch.
>>>
>>> Database-wise it’s possible to query it using
>>> ml2_port_binding_levels table.
>>> But AFAIK there is no API to query this. The only information
>>> that is exposed
>>> are all segments of a network. But this is not sufficient to
>>> identify which
>>> segments actually used for a port binding.
>>>
>>> Regards
>>> Marc
>>> SAP SE
>>>
>>> [1]:
>>>
>>> 

Re: [openstack-dev] [oslo] oslo.messaging dispatching into private/protected methods?

2016-03-08 Thread Mehdi Abaakouk



So during this exploration of this code for the above review it made
me wonder if this is a feature or bug, or if we should at least close
the hole of allowing calling into nearly any endpoint method/attribute
(even non-callable ones to?).
...
Thoughts?


I agree that doesn't make any sense to call non-callable and 
protected/private methods.

So, I'm ok to seal the hole.

--
Mehdi Abaakouk
mail: sil...@sileht.net
irc: sileht

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


Re: [openstack-dev] [telemetry][aodh] "aodh alarm list" vs "aodh alarm search"

2016-03-08 Thread liusheng
Thanks for this discussion and the agreement, it sounds good, I will 
upload related changes.


--
Liu sheng

在 2016/3/7 23:42, gordon chung 写道:


On 07/03/2016 8:05 AM, Julien Danjou wrote:

On Mon, Mar 07 2016, gordon chung wrote:


shall we drop 'alarm search' nomenclature and use just 'alarm list' for
both queries (standard and complex). the concern i have right now is the
proposal is to add standard query support to 'alarm list' while complex
query support is in 'alarm search'. this is very confusing especially
because both commands use '--query' as their option input.

So you have to differentiate 2 things: the REST API and the CLI.
You can't merge both on the REST API side, because the complex query
system require to send a JSON object, so that requires a POST – whereas
listing is simply done via GET. That part we can't merge together.

Now, if your plan is to merge both command on the CLI side, I see no
objection. That's probably a good UX point.


yeah, the proposal is to merge on the client side. let's do that, since
it was same way we were leaning at the meeting[1].

1. drop aodh alarm search
2. add both --query and --complex-query support to aodh alarm list

[1]
http://eavesdrop.openstack.org/meetings/telemetry/2016/telemetry.2016-03-03-15.01.log.html

cheers,




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


Re: [openstack-dev] [L2-Gateway] Install and Configuration issue

2016-03-08 Thread Irena Berezovsky
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 should the service_provider be set to?
>
> Thanks,
> Jason
>
> __
> OpenStack Development Mailing 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] Nominate Maksim Malchuk for the fuel-virtualbox-core team

2016-03-08 Thread Bulat Gaifullin
+1

Regards,
Bulat Gaifullin
Mirantis Inc.



> On 03 Mar 2016, at 17:03, Dmitry Klenov  wrote:
> 
> Maksim, good job! +1 from my side though I am not a core.
> 
> On Thu, Mar 3, 2016 at 4:10 PM, Aleksey Zvyagintsev 
> > wrote:
> +1
> 
> On Thu, Mar 3, 2016 at 12:57 PM, Aleksandr Didenko  > wrote:
> +1
> 
> On Thu, Mar 3, 2016 at 11:00 AM, Kyrylo Galanov  > wrote:
> +1
> 
> On Thu, Mar 3, 2016 at 2:53 AM, Roman Vyalov  > wrote:
> +1
> 
> On Wed, Mar 2, 2016 at 5:47 PM, Sergey Kulanov  > wrote:
> Hey Fuelers,
> 
> Since we've successfully moved [1] virtual-box scripts from fuel-main [2] to
> separate fuel-virtualbox [3] git repo, I propose to update 
> fuel-virtualbox-core
> team [4] by adding Maksim Malchuk. Maksim is the main contributor to these
> scripts during Mitaka release cycle [5]
> 
> Fuel Cores, please vote.
> 
> [1]. 
> http://lists.openstack.org/pipermail/openstack-dev/2016-February/086560.html 
> 
> [2]. https://github.com/openstack/fuel-main 
> 
> [3]. https://github.com/openstack/fuel-virtualbox 
> 
> [4]. https://review.openstack.org/#/admin/groups/1299,members 
> 
> [5]. https://github.com/openstack/fuel-virtualbox/commits/master 
> 
> 
> -- 
> Sergey
> DevOps Engineer 
> IRC: SergK
> Skype: Sergey_kul
> 
> __
> OpenStack Development Mailing 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 
> 
> 
> 
> 
> 
> -- 
> ---
> Best regards,
>Aleksey Zvyagintsev
> 
> __
> OpenStack Development Mailing 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] [tripleo] CI jobs failures

2016-03-08 Thread Richard Su



On 03/08/2016 09:58 AM, Derek Higgins wrote:

On 7 March 2016 at 18:22, Ben Nemec  wrote:

On 03/07/2016 11:33 AM, Derek Higgins wrote:

On 7 March 2016 at 15:24, Derek Higgins  wrote:

On 6 March 2016 at 16:58, James Slagle  wrote:

On Sat, Mar 5, 2016 at 11:15 AM, Emilien Macchi  wrote:

I'm kind of hijacking Dan's e-mail but I would like to propose some
technical improvements to stop having so much CI failures.


1/ Stop creating swap files. We don't have SSD, this is IMHO a terrible
mistake to swap on files because we don't have enough RAM. In my
experience, swaping on non-SSD disks is even worst that not having
enough RAM. We should stop doing that I think.

We have been relying on swap in tripleo-ci for a little while. While
not ideal, it has been an effective way to at least be able to test
what we've been testing given the amount of physical RAM that is
available.

Ok, so I have a few points here, in places where I'm making
assumptions I'll try to point it out

o Yes I agree using swap should be avoided if at all possible

o We are currently looking into adding more RAM to our testenv hosts,
it which point we can afford to be a little more liberal with Memory
and this problem should become less of an issue, having said that

o Even though using swap is bad, if we have some processes with a
large Mem footprint that don't require constant access to a portion of
the footprint swaping it out over the duration of the CI test isn't as
expensive as it would suggest (assuming it doesn't need to be swapped
back in and the kernel has selected good candidates to swap out)

o The test envs that host the undercloud and overcloud nodes have 64G
of RAM each, they each host 4 testenvs and each test env if running a
HA job can use up to 21G of RAM so we have over committed there, it
this is only a problem if a test env host gets 4 HA jobs that are
started around the same time (and as a result a each have 4 overcloud
nodes running at the same time), to allow this to happen without VM's
being killed by the OOM we've also enabled swap there. The majority of
the time this swap isn't in use, only if all 4 testenvs are being
simultaneously used and they are all running the second half of a CI
test at the same time.

o The overcloud nodes are VM's running with a "unsafe" disk caching
mechanism, this causes sync requests from guest to be ignored and as a
result if the instances being hosted on these nodes are going into
swap this swap will be cached on the host as long as RAM is available.
i.e. swap being used in the undercloud or overcloud isn't being synced
to the disk on the host unless it has to be.

o What I'd like us to avoid is simply bumping up the memory every time
we hit a OOM error without at least
   1. Explaining why we need more memory all of a sudden
   2. Looking into a way we may be able to avoid simply bumping the RAM
(at peak times we are memory constrained)

as an example, Lets take a look at the swap usage on the undercloud of
a recent ci nonha job[1][2], These insances have 5G of RAM with 2G or
swap enabled via a swapfile
the overcloud deploy started @22:07:46 and finished at @22:28:06

In the graph you'll see a spike in memory being swapped out around
22:09, this corresponds almost exactly to when the overcloud image is
being downloaded from swift[3], looking the top output at the end of
the test you'll see that swift-proxy is using over 500M of Mem[4].

I'd much prefer we spend time looking into why the swift proxy is
using this much memory rather then blindly bump the memory allocated
to the VM, perhaps we have something configured incorrectly or we've
hit a bug in swift.

Having said all that we can bump the memory allocated to each node but
we have to accept 1 of 2 possible consequences
1. We'll env up using the swap on the testenv hosts more then we
currently are or
2. We'll have to reduce the number of test envs per host from 4 down
to 3, wiping 25% of our capacity

Thinking about this a little more, we could do a radical experiment
for a week and just do this, i.e. bump up the RAM on each env and
accept we loose 25 of our capacity, maybe it doesn't matter, if our
success rate goes up then we'd be running less rechecks anyways.
The downside is that we'd probably hit less timing errors (assuming
the tight resources is whats showing them up), I say downside because
this just means downstream users might hit them more often if CI
isn't. Anyways maybe worth discussing at tomorrows meeting.

+1 to reducing the number of testenvs and allocating more memory to
each.  The huge number of rechecks we're having to do is definitely
contributing to our CI load in a big way, so if we could cut those down
by 50% I bet it would offset the lost testenvs.  And it would reduce
developer aggravation by about a million percent. :-)

Also, on some level I'm not too concerned about the absolute minimum
memory use case.  Nobody 

Re: [openstack-dev] [keystone] Using multiple token formats in a one openstack cloud

2016-03-08 Thread Matt Fischer
>
>
> I don't think your example is right: "PKI will validate that token
> without going to any keystone server". How would it track revoked tokens?
> I'm pretty sure that they still get validated, they are stored in the DB
> even.
>
> I also disagree that there are different use cases. Just switch to fernet
> and save yourself what's going to be weeks of pain with probably no
> improvement in anything with this idea.
>
>
> Is there any details on how to switch to Fernet for a running cloud ? I
> can see a migration path where the cloud is stopped, the token format
> changed and the cloud restarted.
>
> It seems more complex (and maybe insane, as Adam would say) to do this for
> a running cloud without disturbing the users of the cloud.
>
>
It requires a brief outage as you switch the provider over. We stopped all
but 1 node in the cluster then modified it, we did liberty + fernet +
apache all at the same time to avoid multiple restarts. As for the other
services, newer keystone middlewares will realize "hey my token doesn't
work anymore" and will get a new one. At the time we did ours, this was not
the case, so we bounced every service that uses the middleware. All in all
in was a brief outage, basically the length of time to upgrade a few
packages and restart a service on a single node.. My opinion is that it was
far less invasive than something like upgrading neutron, but the APIs were
down for a brief time.

Come to my talk in Austin and we'll cover it a bit more.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [keystone] Using multiple token formats in a one openstack cloud

2016-03-08 Thread Tim Bell

From: Matt Fischer >
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Tuesday 8 March 2016 at 20:35
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Subject: Re: [openstack-dev] [keystone] Using multiple token formats in a one 
openstack cloud

I don't think your example is right: "PKI will validate that token without 
going to any keystone server". How would it track revoked tokens? I'm pretty 
sure that they still get validated, they are stored in the DB even.

I also disagree that there are different use cases. Just switch to fernet and 
save yourself what's going to be weeks of pain with probably no improvement in 
anything with this idea.

Is there any details on how to switch to Fernet for a running cloud ? I can see 
a migration path where the cloud is stopped, the token format changed and the 
cloud restarted.

It seems more complex (and maybe insane, as Adam would say) to do this for a 
running cloud without disturbing the users of the cloud.

Tim

On Tue, Mar 8, 2016 at 9:56 AM, rezroo 
> wrote:
The basic idea is to let the openstack clients decide what sort of token 
optimization to use - for example, while a normal client uses uuid tokens, some 
services like heat or magnum may opt for pki tokens for their operations. A 
service like nova, configured for PKI will validate that token without going to 
any keystone server, but if it gets a uuid token then validates it with a 
keystone endpoint. I'm under the impression that the different token formats 
have different use-cases, so am wondering if there is a conceptual reason why 
multiple token formats are an either/or scenario.


On 3/8/2016 8:06 AM, Matt Fischer wrote:
This would be complicated to setup. How would the Openstack services validate 
the token? Which keystone node would they use? A better question is why would 
you want to do this?

On Tue, Mar 8, 2016 at 8:45 AM, rezroo 
> wrote:
Keystone supports both tokens and ec2 credentials simultaneously, but as far as 
I can tell, will only do a single token format (uuid, pki/z, fernet) at a time. 
Is it possible or advisable to configure keystone to issue multiple token 
formats? For example, I could configure two keystone servers, each using a 
different token format, so depending on endpoint used, I could get a uuid or 
pki token. Each service can use either token format, so is there a conceptual 
or implementation issue with this setup?
Thanks,
Reza

__
OpenStack Development Mailing 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:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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


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


Re: [openstack-dev] [neutron] Last chance to finish changes affecting DB schema for Mitaka

2016-03-08 Thread Takashi Yamamoto
Henry,

i think it's better to fix model vs migration mismatch issues [1]
before tagging.
how do you think?

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

On Tue, Mar 8, 2016 at 11:52 PM, 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
>
> __
> OpenStack Development Mailing 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] [app-catalog] Nominating Kirill Zaitsev to App Catalog Core

2016-03-08 Thread Christopher Aedo
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-dev] [Horizon] Javascript linting and documentation

2016-03-08 Thread Richard Jones
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


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

2016-03-08 Thread Robert Collins
On 9 March 2016 at 09:51, Colette Alexander  wrote:
>
>
> On Tue, Mar 8, 2016 at 12:27 PM, Matt Riedemann 
> wrote:
>>>
>>>
>>
>> So is this for only current TC members? What about people that aren't on
>> the TC?
>>
>> I asked in this in today's TC meeting but figured I'd ask here where it's
>> more global.
>
>
> Because of limited space in the class, and because of the very early stages
> of figuring out what, exactly, leadership training or support might look
> like in OpenStack, we're focusing on current and future-elected (in April)
> TC members as attendees. If there is any extra space in the class available,
> I'll be sure to announce that here on the ML as soon as we know, and would
> *love* to open space up to the rest of the community, even in these early
> stages. Anyone who's interested in learning more or giving feedback should
> also feel free to ping me on IRC (I'm gothicmindfood) or email - I'm happy
> to answer any and all questions about this.


IMO whatever works for the folk wishing to go is sensible. As I
blogged at the beginning of this cycle, I'm convinced that this is a
useful opportunity for OpenStack as a whole, as well as for the
individuals that attend - I'm very glad you've been pushing
coordination of this forward. Thank you.

-Rob


-- 
Robert Collins 
Distinguished Technologist
HP Converged Cloud

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


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

2016-03-08 Thread Robert Collins
On 9 March 2016 at 14:23, Jeremy Stanley  wrote:
> On 2016-03-09 13:57:45 +1300 (+1300), Robert Collins wrote:
>> On 9 March 2016 at 13:07, Jeremy Stanley  wrote:
>> > On 2016-03-08 17:25:41 +1100 (+1100), Richard Jones wrote:
>> > [...]
>> >> SOLUTION 6 - make zuul capable of performing atomic cross-repository
>> >> commits.
>> >
>> > This seems unlikely to happen, as it's very much counter to Zuul's
>> > designed-in reliance on serializing changes to test before merging
>> > them.
>>
>> I'd like to explore this more, but a mailing list thread probably
>> isn't terribly efficient - I don't even know where to start to figure
>> out any differing assumptions, whether whats being propose is
>> conceptually desirable and-or how to represent that in zuul. But we've
>> spent nearly three days of bug smash here in sydney trying to get some
>> sort of design for going forward, and so far this is the only one that
>> hasn't bad pretty big negative external side effects such as 'break
>> every other user of xstatic when horizon updates'. :(.
>>
>> So -> IRC and/or/perhaps voice?
>
> ML thread will probably work for some initial exploration, but with
> James leading the Zuul v3 design and implementation he's in the best
> position to say whether it's going to be sane to support having
> changes in multiple repos which must test and merge together rather
> than being able to merge one before the other. Previously we've seen
> the idea of atomic merges coordinated across multiple repositories
> to be a sign of poor software design, and as such have actively
> discouraged the notion (it did come up briefly during the original
> cross-repo dependencies design, and was pretty quickly rejected as
> unsanitary).
>
> Anyway, I'll give him a heads up on this since he likely doesn't
> follow Horizon-specific discussions very closely.

Thanks. The driving factor here is that supporting both versions of
many of these static things - both JS, and the html that interacts
with it - is very tricky. E.g. having two copies of all templates
tricky.

-Rob

-- 
Robert Collins 
Distinguished Technologist
HP Converged Cloud

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


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

2016-03-08 Thread Matt Riedemann



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

When you get back, let's continue the conversation either in email or
IRC #openstack-dev. Looking forward to hearing your feedback on this.

Thanks,

-amrith



-Original Message-
From: Matt Riedemann [mailto:mrie...@linux.vnet.ibm.com]
Sent: Tuesday, March 08, 2016 12:11 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 10:17 AM, Matt Riedemann wrote:

This is a call for help on resolving bug 1538506 [1] where the
proboscis tests randomly fail on the stable branches with something

like:


TypeError: create() got an unexpected keyword argument 'slave_of'

Craig Vyvial has a proposed stable/kilo change [2] but it has some
issues, at least from me as a reviewer of that change.

The tests are failing the periodic-stable job daily [3].

Can we get someone to help out with this? Otherwise I'm inclined to
say the tests should be disabled on the stable branches, but that's
pretty drastic.

Note that this is the kind of thing that breaks stable branch
policy, which is going to be part of a review when applying for the
stable:follows-policy tag. [4]  And the stable:follows-policy tag
may be used to determine when a stable branch for a project goes
end of life if it's not being maintained.

[1] https://bugs.launchpad.net/trove/+bug/1538506
[2] https://review.openstack.org/#/c/276934/
[3] http://goo.gl/fqf11U
[4]
http://governance.openstack.org/reference/tags/stable_follows-polic
y.h
tml



This is my solution for liberty, cap python-troveclient<2.1.0 in
global- requirements on stable/liberty [1].

Then there is a change to trove on stable/liberty to use the g-r
version range for python-troveclient for unit tests [2].

Alternatively, we could avoid the cap in stable/liberty by:

1. Reverting https://review.openstack.org/#/c/245738/
2. Blacklisting python-troveclient 2.1.0 in g-r 3. Release python-
troveclient 2.2.0.

It's getting late in the mitaka release to be messing with this
though since we're already past client freeze.

[1] https://review.openstack.org/#/c/290021/
[2] https://review.openstack.org/#/c/290023/

--

Thanks,

Matt Riedemann



__

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


_
_

OpenStack Development Mailing List (not for 

Re: [openstack-dev] [nova][ceilometer] unable to see compute.node.cpu.* metrics in ceilometer

2016-03-08 Thread Lu, Lianhao
On Mar 8, 2016 02:15, Kapil wrote:
> Hi
> 
> 
> I enabled ComputeDriverCPUMonitor in nova.conf on one of the compute 
> nodes, restarted nova-compute, ceilometer-agent-compute on the compute 
> node and ceilometer-collector, ceilometer-api, 
> ceilometer-agent-central, ceilometer-agent-notification on the 
> controller node.
> 
> However, I cannot see the cpu meters or samples in ceilometer.

Which version of nova/ceilometer are you using? First you need to make sure 
that nova
have generated the related notifications. Please be noted that there is a 
configuration change
in recent nova. See [1] for how to configure nova to use UBS. 
> 
> Any suggestions to what may be the issue ?
> 
[1] 
https://01.org/sites/default/files/utilization_based_scheduing_in_openstack_compute_nova-revision002.pdf
 

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

2016-03-08 Thread Jeremy Stanley
On 2016-03-09 13:57:45 +1300 (+1300), Robert Collins wrote:
> On 9 March 2016 at 13:07, Jeremy Stanley  wrote:
> > On 2016-03-08 17:25:41 +1100 (+1100), Richard Jones wrote:
> > [...]
> >> SOLUTION 6 - make zuul capable of performing atomic cross-repository
> >> commits.
> >
> > This seems unlikely to happen, as it's very much counter to Zuul's
> > designed-in reliance on serializing changes to test before merging
> > them.
> 
> I'd like to explore this more, but a mailing list thread probably
> isn't terribly efficient - I don't even know where to start to figure
> out any differing assumptions, whether whats being propose is
> conceptually desirable and-or how to represent that in zuul. But we've
> spent nearly three days of bug smash here in sydney trying to get some
> sort of design for going forward, and so far this is the only one that
> hasn't bad pretty big negative external side effects such as 'break
> every other user of xstatic when horizon updates'. :(.
> 
> So -> IRC and/or/perhaps voice?

ML thread will probably work for some initial exploration, but with
James leading the Zuul v3 design and implementation he's in the best
position to say whether it's going to be sane to support having
changes in multiple repos which must test and merge together rather
than being able to merge one before the other. Previously we've seen
the idea of atomic merges coordinated across multiple repositories
to be a sign of poor software design, and as such have actively
discouraged the notion (it did come up briefly during the original
cross-repo dependencies design, and was pretty quickly rejected as
unsanitary).

Anyway, I'll give him a heads up on this since he likely doesn't
follow Horizon-specific discussions very closely.
-- 
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] [release] mitaka-3 development milestone

2016-03-08 Thread Jeremy Stanley
On 2016-03-08 15:13:40 -0500 (-0500), Corey Bryant wrote:
[...]
> I'm only seeing neutron-vpnaas-8.0.0.0b3.dev1.tar.gz on
> https://tarballs.openstack.org/neutron-vpnaas. Do we need an
> update there?

After some investigation, it appears your tarball jobs were broken
up until https://review.openstack.org/288930 merged to fix them.
Unfortunately 8.0.0.0b3 tagged a commit several days prior to that,
well back into the window where your tox.ini broke on attempting to
generate a tarball. An 8.0.0.0b4 release at or after the point where
the above fix merged should produce a normal tarball again, but I
don't know if that's sane with respect to the current release
schedule.
-- 
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] How do we move forward with xstatic releases?

2016-03-08 Thread Robert Collins
On 9 March 2016 at 13:07, Jeremy Stanley  wrote:
> On 2016-03-08 17:25:41 +1100 (+1100), Richard Jones wrote:
> [...]
>> SOLUTION 6 - make zuul capable of performing atomic cross-repository
>> commits.
>
> This seems unlikely to happen, as it's very much counter to Zuul's
> designed-in reliance on serializing changes to test before merging
> them.

I'd like to explore this more, but a mailing list thread probably
isn't terribly efficient - I don't even know where to start to figure
out any differing assumptions, whether whats being propose is
conceptually desirable and-or how to represent that in zuul. But we've
spent nearly three days of bug smash here in sydney trying to get some
sort of design for going forward, and so far this is the only one that
hasn't bad pretty big negative external side effects such as 'break
every other user of xstatic when horizon updates'. :(.

So -> IRC and/or/perhaps voice?

-Rob


-- 
Robert Collins 
Distinguished Technologist
HP Converged Cloud

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


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

2016-03-08 Thread Richard Jones
But Jeremy: Atomic Zuul. How cool is that name.


So I know I'm going to potentially get yelled at for voicing this, but what
are the chances that app-catalog and Horizon are ever installed on the same
system? That is, could it have its own xstatic constraints, with the
promise that the two constraints will never meet in a dark alley behind
some VM somewhere? app-catalog isn't in the integrated tests, so it's never
going to break the gate like Horizon will...


On 9 March 2016 at 11:07, Jeremy Stanley  wrote:

> On 2016-03-08 17:25:41 +1100 (+1100), Richard Jones wrote:
> [...]
> > SOLUTION 6 - make zuul capable of performing atomic cross-repository
> > commits.
>
> This seems unlikely to happen, as it's very much counter to Zuul's
> designed-in reliance on serializing changes to test before merging
> them.
> --
> Jeremy Stanley
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [keystone] [horizon] [qa] keystone versionless endpoints and v3

2016-03-08 Thread Jamie Lennox
So with the merge of [1] the devstack change [2] to use unversioned
endpoints passes gate. From previous experience this should not be
considered an extensive test, however the only real way to find out what
doesn't work is to merge it and see what fails.


[1] https://review.openstack.org/#/c/287532/
[2] https://review.openstack.org/#/c/285879/

On 9 March 2016 at 10:21, Matt Fischer  wrote:

> On Tue, Feb 23, 2016 at 8:49 PM, Jamie Lennox 
> wrote:
>
>>
>>
>> On 18 February 2016 at 10:50, Matt Fischer  wrote:
>>
>>> I've been having some issues with keystone v3 and versionless endpoints
>>> and I'd like to know what's expected to work exactly in Liberty and beyond.
>>> I thought with v3 we used versionless endpoints but it seems to cause some
>>> breakages and some disagreement as to what should work.
>>>
>>
>> Excellent! I'm really glad someone is looking into this beyond the simple
>> cases.
>>
>>
>>> Here's what I've found:
>>>
>>> Using versionless endpoints:
>>>  - horizon project selector doesn't work (v3 api configured in horizon
>>> local_settings) [1]
>>>  - keystone client doesn't work (expected v3 I think)
>>>  - nova/neutron etc seem ok with a few exceptions [2]
>>>
>>> Adding /v3 to my endpoints:
>>>  - openstackclient seems to double up the /v3 reference which fails [3],
>>> this breaks puppet-openstack, in addition to general CLI usage.
>>>
>>> Adding /v2.0 to my endpoints:
>>>  - things seem to work the best this way
>>>  - this matches the install docs too
>>>  - its not very "v3-onic"
>>>
>>>
>>> My goal is to be as v3 as possible, but everything needs to work 100%.
>>> Given that...
>>>
>>> What's the correct and supported way to setup endpoints such that
>>> Keystone v3 works?
>>>
>>
>> So the problem with switching to v3 is that a lot of services and clients
>> were designed to assume you would have a /v2.0 on your URL. To work with v3
>> they therefore inspect the url and essentially s/v2.0/v3 before making
>> calls. Any of the services using the keystoneclient/keystoneauth session
>> stuff correctly shouldn't have this problem - but that is certainly not
>> everyone.
>>
>> It does however explain why you see problems with /v3 where /v2.0 seems
>> to work even for the v3 API.
>>
>>
>>> Are services expected to handle versionless keystone endpoints properly?
>>>
>>
>> Services should never need to manipulate the catalog. This is what's
>> causing the problem. If they leave it up to the client to do this then it
>> will handle the unversioned endpoint.
>>
>>
>>>
>>>
>> Can I ignore that keystoneclient doesn't work with versionless? Does this
>>> imply that services that use the python library (like Horizon) will also be
>>> broken?
>>>
>>
>> This I'm surprised by. Do you mean the keystone CLI utility that ships
>> with keystoneclient? If so the decision was made it should never support v3
>> and to use openstackclient instead. I haven't actually looked at this in a
>> long time but we should probably fix it even though it's been deprecated
>> for a long time now.
>>
>>
>>> Do I need/Should I have both v2.0 and v3 endpoints in my catalog?
>>>
>>> No. And particularly with the new catalog formats that went through the
>> cross project working group recently we made the decision that these
>> endpoints should not contain a version number at all. This is not ready yet
>> but we are working towards that goal.
>>
>>
>>> [1] its making curl calls without a version on the endpoint, causing it
>>> to fail. I will file a bug pending the outcome of this discussion.
>>>
>>> [2] specifically neutron_admin_auth_url in nova.conf doesn't seem to
>>> work without a Keystone API version on it. For
>>> cinder keymgr_encryption_auth_url also seems to need it. I assume I'll
>>> eventually also hit some of these:
>>> https://etherpad.openstack.org/p/v3-only-devstack
>>>
>>
>> Can you file bugs for both of these? I've worked on both these sections
>> before so should be able to have a look into it.
>>
>> I was going to finish by saying that we have unversioned endpoints in
>> devstack - but looking again now and we don't :( There have been various
>> reverted patches in the v3 transition and this must have been one of them.
>>
>> For now i would suggest keeping the endpoints with the /v2.0 prefix as
>> even things using v3 API know how to work around this. The goal is to go
>> versionless everywhere (including other services, long goal but the others
>> will be easier than keystone) and anything you find that isn't working
>> isn't using the clients correctly so file a bug and add me to it.
>>
>>
>> Jamie
>>
>
> Jamie,
>
> Apologies for the delay in response and thanks for the information.  I had
> come to the same conclusion as you after sending this, leaving /v2.0 on the
> URLs in the catalog but specifying v3 seems to work the best for now in
> Liberty. I look forward to the day when v3+versionless is the default!
>
> I will bring my 

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

2016-03-08 Thread Jeremy Stanley
On 2016-03-08 17:25:41 +1100 (+1100), Richard Jones wrote:
[...]
> SOLUTION 6 - make zuul capable of performing atomic cross-repository
> commits.

This seems unlikely to happen, as it's very much counter to Zuul's
designed-in reliance on serializing changes to test before merging
them.
-- 
Jeremy Stanley

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


[openstack-dev] [Neutron][DVR] No Meeting tomorrow

2016-03-08 Thread Brian Haley
Sorry for the late notice, but I need to cancel the DVR meeting for 
tomorrow the 9th as a few of us have a conflict.  We'll resume again 
next week on the 16th.


-Brian

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


[openstack-dev] [kolla] Mitaka release schedules and priorities - only 30 days left!

2016-03-08 Thread Steven Dake (stdake)
Hi Koala Bears!

The release candidate schedules are as follows:

We are in feature freeze.  No new features in Kolla until after Mitaka is 
released on April 4th-April 8th.  We may lag this date a little bit depending 
on the state of the tarballs repo for build from source, or we may just tag and 
backport when the tarball releases trickle out.

RC1: March 18th: strict tagging deadline!
All blueprints left in the release MUST BE COMPLETED BY THIS DATE
Any remaining feature that was part of a larger blueprint work-item that was 
highly distributed in nature was converted to an individual Critical priority 
bug. These mostly involve drop root and reconfigure.  There may be a few other 
things in there.  Please consider when working on bugs to work the Critical 
bugs first, then the High bugs, then the Medium bugs, then the Low bugs, then 
the Wishlist bugs.

RC2: March 25th: strict tagging deadline!
Hopefully all blueprints are in a finished state.  Anything not essential or 
high in nature will be pushed to Newton.

RC3: April 1st: strict tagging deadline!
This is our final RC unless critical BUGS are found in the implementation.  
Missing features will be bumped to newton at this point bug or blueprint wise.  
Upgrade is priority #1.  We will branch Mitaka here.

Final release: April 8th: This tagging deadline will be strict assuming other 
projects hit their deadlines.  I am open to suggestions about how to handle 
upstream changes in Mitaka past this point.  Master will be open for new 
features.  ONLY CRITICAL BUG FIXES WILL BE BACKPORTED INTO stable/mitaka.

Regards,
-steve


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


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

2016-03-08 Thread Fox, Kevin M
fyi, we are planning on using the xstatic packages for the app catalog website 
so we can share as much code as possible with horizon and the app catalog 
horizon plugin. So it will affect the app catalog too, not just horizon.

Thanks,
Kevin

From: David Lyle [dkly...@gmail.com]
Sent: Tuesday, March 08, 2016 2:43 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Horizon] How do we move forward with xstatic 
releases?



On Mon, Mar 7, 2016 at 9: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:
[cid:ii_ilix1nfi0_153547b4957000a0]
​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. 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:

This seems unlikely to go well.


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 don't know that you can duck low enough for that.

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.


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.


I combined this with #2.

SOLUTION 4: vendor the javascript

Heh.

This makes me sad.


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.


I guess I combined 2, 3 and 5. Just remove the xstatic overhead from the 
openstack global mechanism.

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


Richard

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


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


David
__
OpenStack Development Mailing List (not 

Re: [openstack-dev] [keystone] [horizon] [qa] keystone versionless endpoints and v3

2016-03-08 Thread Matt Fischer
On Tue, Feb 23, 2016 at 8:49 PM, Jamie Lennox  wrote:

>
>
> On 18 February 2016 at 10:50, Matt Fischer  wrote:
>
>> I've been having some issues with keystone v3 and versionless endpoints
>> and I'd like to know what's expected to work exactly in Liberty and beyond.
>> I thought with v3 we used versionless endpoints but it seems to cause some
>> breakages and some disagreement as to what should work.
>>
>
> Excellent! I'm really glad someone is looking into this beyond the simple
> cases.
>
>
>> Here's what I've found:
>>
>> Using versionless endpoints:
>>  - horizon project selector doesn't work (v3 api configured in horizon
>> local_settings) [1]
>>  - keystone client doesn't work (expected v3 I think)
>>  - nova/neutron etc seem ok with a few exceptions [2]
>>
>> Adding /v3 to my endpoints:
>>  - openstackclient seems to double up the /v3 reference which fails [3],
>> this breaks puppet-openstack, in addition to general CLI usage.
>>
>> Adding /v2.0 to my endpoints:
>>  - things seem to work the best this way
>>  - this matches the install docs too
>>  - its not very "v3-onic"
>>
>>
>> My goal is to be as v3 as possible, but everything needs to work 100%.
>> Given that...
>>
>> What's the correct and supported way to setup endpoints such that
>> Keystone v3 works?
>>
>
> So the problem with switching to v3 is that a lot of services and clients
> were designed to assume you would have a /v2.0 on your URL. To work with v3
> they therefore inspect the url and essentially s/v2.0/v3 before making
> calls. Any of the services using the keystoneclient/keystoneauth session
> stuff correctly shouldn't have this problem - but that is certainly not
> everyone.
>
> It does however explain why you see problems with /v3 where /v2.0 seems to
> work even for the v3 API.
>
>
>> Are services expected to handle versionless keystone endpoints properly?
>>
>
> Services should never need to manipulate the catalog. This is what's
> causing the problem. If they leave it up to the client to do this then it
> will handle the unversioned endpoint.
>
>
>>
>>
> Can I ignore that keystoneclient doesn't work with versionless? Does this
>> imply that services that use the python library (like Horizon) will also be
>> broken?
>>
>
> This I'm surprised by. Do you mean the keystone CLI utility that ships
> with keystoneclient? If so the decision was made it should never support v3
> and to use openstackclient instead. I haven't actually looked at this in a
> long time but we should probably fix it even though it's been deprecated
> for a long time now.
>
>
>> Do I need/Should I have both v2.0 and v3 endpoints in my catalog?
>>
>> No. And particularly with the new catalog formats that went through the
> cross project working group recently we made the decision that these
> endpoints should not contain a version number at all. This is not ready yet
> but we are working towards that goal.
>
>
>> [1] its making curl calls without a version on the endpoint, causing it
>> to fail. I will file a bug pending the outcome of this discussion.
>>
>> [2] specifically neutron_admin_auth_url in nova.conf doesn't seem to work
>> without a Keystone API version on it. For cinder keymgr_encryption_auth_url
>> also seems to need it. I assume I'll eventually also hit some of these:
>> https://etherpad.openstack.org/p/v3-only-devstack
>>
>
> Can you file bugs for both of these? I've worked on both these sections
> before so should be able to have a look into it.
>
> I was going to finish by saying that we have unversioned endpoints in
> devstack - but looking again now and we don't :( There have been various
> reverted patches in the v3 transition and this must have been one of them.
>
> For now i would suggest keeping the endpoints with the /v2.0 prefix as
> even things using v3 API know how to work around this. The goal is to go
> versionless everywhere (including other services, long goal but the others
> will be easier than keystone) and anything you find that isn't working
> isn't using the clients correctly so file a bug and add me to it.
>
>
> Jamie
>

Jamie,

Apologies for the delay in response and thanks for the information.  I had
come to the same conclusion as you after sending this, leaving /v2.0 on the
URLs in the catalog but specifying v3 seems to work the best for now in
Liberty. I look forward to the day when v3+versionless is the default!

I will bring my test env back up later this week and work on bugs for both
issues that I called out.
__
OpenStack Development Mailing List (not for 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

2016-03-08 Thread Richard Jones
+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


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

2016-03-08 Thread Tripp, Travis S
+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


Re: [openstack-dev] [Heat] Dealing with nonexistent resources during resource-list / stack-delete

2016-03-08 Thread Steve Baker

On 09/03/16 05:41, Johannes Grassler wrote:

Hello,

On 03/08/2016 04:57 PM, Zane Bitter wrote:

On 08/03/16 10:40, Johannes Grassler wrote:

On 03/07/2016 04:48 PM, Zane Bitter wrote:

On 04/03/16 04:35, Johannes Grassler wrote:

[Uncaught client exceptions in resource plugins' add_dependencies()
methods]

In the meantime, we need to find and squash every instance of this
problem
wherever we can like you said.


It might also be a good idea to caution against unchecked API client
invocations in

http://docs.openstack.org/developer/heat/developing_guides/pluginguide.html 


[...]

It's best if they *do* omit it entirely. The only reason we override 
it in
the Neutron resources is that the Neutron API is terrible for 
orchestration

purposes[1]. It adds a bunch of invisible, fragile magic that breaks in
subtle ways when e.g. resources are moved into nested stacks.


I never saw the Neutron API that way before (I guess I just got used 
to the

unintuitive bits), but seeing it spelled out in your rant makes it very
obvious, yes. I didn't know that was the root cause for overriding
add_dependencies() and that very ignorance of mine...

The default implementation provides everything that we *ought* to 
need, so if
we document anything I think it should be that plugin developers 
should not

touch add_dependencies() at all.


...suggests mentioning that much is probably a good idea (lest 
somebody pick
one of the Neutron plugins as a template to base their own resource 
plugin

on).


Definitely not big enough to require a spec IMO.


Yes, I can see that, given how it's not something plugin writers 
should do
anyway. Then I'll just write a little paragraph cautioning against 
overriding

add_dependcies() and add a Related-Bug: line.

Thanks for that. The paragraph could say that it is preferable to not 
override add_dependencies, but if they do then they should *never* make 
REST API calls inside it. This is for the reason you've discovered, and 
also because it will kill the performance of some stack operations.


From what I can see you've discovered the only 2 places where REST API 
calls are made from add_dependencies, I've added comments to the 
review[1] to suggest how they can be removed.


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

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

2016-03-08 Thread Lin Hua Cheng
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


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

2016-03-08 Thread Matt Riedemann



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

When you get back, let's continue the conversation either in email or
IRC #openstack-dev. Looking forward to hearing your feedback on this.

Thanks,

-amrith



-Original Message-
From: Matt Riedemann [mailto:mrie...@linux.vnet.ibm.com]
Sent: Tuesday, March 08, 2016 12:11 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 10:17 AM, Matt Riedemann wrote:

This is a call for help on resolving bug 1538506 [1] where the
proboscis tests randomly fail on the stable branches with something

like:


TypeError: create() got an unexpected keyword argument 'slave_of'

Craig Vyvial has a proposed stable/kilo change [2] but it has some
issues, at least from me as a reviewer of that change.

The tests are failing the periodic-stable job daily [3].

Can we get someone to help out with this? Otherwise I'm inclined to
say the tests should be disabled on the stable branches, but that's
pretty drastic.

Note that this is the kind of thing that breaks stable branch
policy, which is going to be part of a review when applying for the
stable:follows-policy tag. [4]  And the stable:follows-policy tag
may be used to determine when a stable branch for a project goes
end of life if it's not being maintained.

[1] https://bugs.launchpad.net/trove/+bug/1538506
[2] https://review.openstack.org/#/c/276934/
[3] http://goo.gl/fqf11U
[4]
http://governance.openstack.org/reference/tags/stable_follows-polic
y.h
tml



This is my solution for liberty, cap python-troveclient<2.1.0 in
global- requirements on stable/liberty [1].

Then there is a change to trove on stable/liberty to use the g-r
version range for python-troveclient for unit tests [2].

Alternatively, we could avoid the cap in stable/liberty by:

1. Reverting https://review.openstack.org/#/c/245738/
2. Blacklisting python-troveclient 2.1.0 in g-r 3. Release python-
troveclient 2.2.0.

It's getting late in the mitaka release to be messing with this
though since we're already past client freeze.

[1] https://review.openstack.org/#/c/290021/
[2] https://review.openstack.org/#/c/290023/

--

Thanks,

Matt Riedemann



__

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


_
_

OpenStack Development Mailing List (not for usage questions)
Unsubscribe:

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

2016-03-08 Thread Armando M.
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.


>
> 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] [Horizon] How do we move forward with xstatic releases?

2016-03-08 Thread David Lyle
On Mon, Mar 7, 2016 at 9: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. 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:
>

This seems unlikely to go well.


>
> 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 don't know that you can duck low enough for that.

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.


>
> 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.
>
>
I combined this with #2.


> SOLUTION 4: vendor the javascript
>
> Heh.
>

This makes me sad.


>
> 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.
>
>
I guess I combined 2, 3 and 5. Just remove the xstatic overhead from the
openstack global mechanism.


> Your thoughts on any and all of the above are requested.
>
>
> Richard
>
> [1] https://review.openstack.org/#/c/289142/
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
David
__
OpenStack Development Mailing List (not for 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

2016-03-08 Thread Colette Alexander
On Tue, Mar 8, 2016 at 2:34 PM, Colette Alexander <
colettealexan...@gmail.com> wrote:

> 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.
>
> If you ask me what the 'big goal' of talking about leadership in this
> community is about, I'd say it's about infusing a culture of leadership and
> support for leadership skills and practices in the community that serve its
> members and ultimately provide a more sustainable and humane experience for
> any of the community members who wish to take on leadership positions here.
> To just blatantly copy/paste my case from the etherpad:
> *"As the OpenStack community matures, so too must its support and
> development of its leaders. Many open source movements are not as
> thoroughly democratized as OpenStack, and rely on a Benevolent Dictator for
> Life (BDFL) who is largely responsible for shaping the vision and strategy
> and making ‘product’ decisions for the whole of the project. Without a
> BDFL, many have argued OpenStack will be unable to navigate to product
> maturity. But when one looks back at the last 5 years of growth, it’s very
> apparent that the strength of OpenStack lies in its democracy and community
> diversity - that a reliance on many strong and capable leaders in the
> community is a crucial part of its character and intrinsic to its success.
> Bolstering leadership skills even more through available training and
> resources, and infusing OpenStack’s culture with an emphasis on leadership
> as a core value will only work towards strengthening its democracy."*[0]
>
>
ETA the elusive etherpad link:
[0] https://etherpad.openstack.org/p/Leadershiptraining
__
OpenStack Development Mailing List (not for 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

2016-03-08 Thread Colette Alexander
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'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.

If you ask me what the 'big goal' of talking about leadership in this
community is about, I'd say it's about infusing a culture of leadership and
support for leadership skills and practices in the community that serve its
members and ultimately provide a more sustainable and humane experience for
any of the community members who wish to take on leadership positions here.
To just blatantly copy/paste my case from the etherpad:
*"As the OpenStack community matures, so too must its support and
development of its leaders. Many open source movements are not as
thoroughly democratized as OpenStack, and rely on a Benevolent Dictator for
Life (BDFL) who is largely responsible for shaping the vision and strategy
and making ‘product’ decisions for the whole of the project. Without a
BDFL, many have argued OpenStack will be unable to navigate to product
maturity. But when one looks back at the last 5 years of growth, it’s very
apparent that the 

[openstack-dev] [neutron][taas] Proposal of Dashboard for TaaS

2016-03-08 Thread Anil Rao
Thanks Soichi and Kaz for your work on implementing Horizon (dashboard) support 
for TaaS. The proposal (with screen shots) discussed in our recent IRC meeting 
look very nice. Here are some additional suggestions for improvement.



1.   General

a.   When a port is being selected (for a tap-service instance or a 
tap-flow) it would be nice to also provide some extra information associated 
with that port, such as the VM it belongs to and the IP address.  This will 
look very similar to what is being done today when associating a floating IP 
with a VM vNIC. The extra context will allow users to identify their source and 
destination end-points with more ease. If a VM is not currently associated with 
a port then the extra information is not necessary.

b.  When selecting the traffic monitoring direction, it would be nice to 
provide two check boxes, one for 'ingress' and the other for 'egress'. A user 
wishing to monitor a port in both directions can select both check boxes. I 
feel this looks better than having an option  called 'both'.

2.   Using the Tap Services Tab

a.   Allow tap-flow-create and tap-flow-delete operations to also be 
carried out from here. This will let users who prefer working in this fashion 
get everything done from the same place.

b.  Provide a way to list tap flows currently associated with a tap service.

c.   Allow multiple tap-flows to be created at the same time. Let the user 
pick multiple source ports (and traffic monitoring directions) and have all of 
them attached to a designated tap-service.

3.   Using the Network Topology Tab

a.   Allow tap-create and tap-delete operations to be also carried out from 
here. This will allow users who prefer working in this fashion get everything 
done from the same place. The user can pick the destination port (from one of 
the existing VMs) in the same way that a source port is picked when creating a 
tap-flow.

b.  Color code the VM whose vNIC is attached to the destination port of a 
tap-service.

c.   BONUS: Allow the user to click on a VM that is serving as the 
destination side of a tap-service and highlight all the VMs that are attached 
to tap-flows associated with that tap-service.
Regards,
Anil
__
OpenStack Development Mailing 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

2016-03-08 Thread David Lyle
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-dev] [kolla][release] Announcing Kolla Mitaka-3 milestone release \o/

2016-03-08 Thread Steven Dake (stdake)
Fellow OpenStackers,


The Kolla community is pleased to announce the release of Mitaka milestone #3.  
Angus Salkeld has agreed to be our release manager for the kolla-mesos 
repository.  As an aside, we held our midcycle during mitaka-3 development, for 
which the notes can be found here:


https://etherpad.openstack.org/p/kolla-mitaka-midcycle


Mitaka-3 changes:

  *   Named Volumes used throughout Kolla remove data loss problem with data 
containers.
  *   Upgrade to Docker 1.10.z.
  *   Upgrade of nearly all OpenStack services implemented.
  *   Upgrade of many of the key OpenStack infrastructure services implemented.
  *   Reconfigure for many services implemented.
  *   Introduction of a proper diagnostics system.  With this system it is 
possible to perform  data analysis and visualization, providing lightweight and 
scalable log processing.
  *   Security improvements
 *   Drop root in most containers implemented to protect from rooting of a 
datacenter on container breakout.
 *   Isolation of internal and external API networks.
 *   TLS for the external network
 *   Improved audit logs
  *   New and updated big tent OpenStack services:
  *   Manila container
  *   Convert Neutron to thin containers
  *   Custom repos in the base image

]The kolla-mesos repository continuess to make rapid progress.  The compute kit 
services can now be deployed using kolla-mesos including nova and neutron.  The 
implementation uses standard kolla container images without special building of 
the images specifically for mesos.  The kolla-mesos repository will be 
technical preview in Mitaka.


Two talks were accepted from Kolla community members.  Upgrading OpenStack was 
turned into what may look like a panel relating to Openstack upgrades.  Alicja 
and Michal have a full slot for our diagnostics work.  Make sure to tag these 
talks in your Austin summit visit if you can make Austin and have interest in 
Kolla.


We are super excited about the release of Mitaka-3!  We did some really 
impressive output in a short period of time, implementing solutions for 25 
blueprints and 51 bugs.  This cycle our core team grew by one member, Angus 
Salkeld.  Our community continues to remain extremely diverse and is growing 
with 190 IC interactions and 40 corporate affiliations.  Check out our 
stackalytics page:


http://stackalytics.com/?module=kolla-group=person-day



Regards,

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


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

2016-03-08 Thread Doug Hellmann
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?

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


Re: [openstack-dev] [all] [api] Reminder: WSME is not being actively maintained

2016-03-08 Thread Doug Hellmann
Excerpts from gordon chung's message of 2016-03-08 21:22:11 +:
> 
> On 08/03/2016 6:25 AM, Chris Dent wrote:
> >
> > Last summer Lucas Gomes and I were press ganged into becoming core on
> > WSME. Since then we've piecemeal been verifying bug fixes and generally
> > trying to keep things moving. However, from the beginning we both agreed
> > that WSME is _not_ a web framework that we should be encouraging. Though
> > it looks like it started with very good intentions, it never really
> > reached a state where any of the following are true:
> >
> > * The WSME code is easy to understand and maintain.
> > * WSME provides correct handling of HTTP (notably response status
> >and headers).
> > * WSME has an architecture that is suitable for creating modern
> >Python-based web applications.
> >
> > Last summer we naively suggested that projects that are using it move to
> > using something else. That suggestion did not take into account the
> > realities of OpenStack.
> >
> > So we need to come up with a new plan. Lucas and I can continue to
> > merge bug fixes as people provide them (and we become aware of them) and
> > we can continue to hassle Doug Hellman to make a release when one is
> > necessary but this does little to address the three gaps above nor the
> > continued use of the framework in existing projects.
> >
> > Ideas?
> >
> 
> it seems like the main reason there are so many projects leveraging WSME 
> is because everyone is just using Ironic or Ceilometer as the starting 
> point for their APIs. can we officially say to all new projects who plan 
> on copying API logic of Ironic et al.: 'stop'.

Sure. We should probably provide an alternative suggestion.

> 
> what are the viable alternatives out there? Voluptuous, JSONSchema? i 
> apologies, i know this is a question that gets asked every few months.

__
OpenStack Development Mailing List (not for 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][vote] Proposing Alicja Kwasniewska for core reviewer

2016-03-08 Thread Kwasniewska, Alicja
Thank you!

I really appreciate being a part of Kolla project and now also core reviewers 
team! It is a pleasure to work with you guys. Thank you all for your support 
and help (especially for all -1 ;) ), wouldn't be here without you!

Kind regards,
Alicja

PS best present for Women's Day ever! :)

From: Steven Dake (stdake) [mailto:std...@cisco.com]
Sent: Tuesday, March 8, 2016 7:15 PM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [kolla][vote] Proposing Alicja Kwasniewska for 
core reviewer

The vote is unanimous.

Welcome to the core reviewer team Alicja!  Ping me when you get online next and 
our timezone overlaps, and I'll walk you through the differences in the gerrit 
interface you should know.

I have made appropriate changes in gerrit.

Regards
-steve

From: Steven Dake >
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Friday, March 4, 2016 at 9:55 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Subject: [openstack-dev] [kolla][vote] Proposing Alicja Kwasniewska for core 
reviewer

Core Reviewers,

Alicja has been instrumental in our work around jinja2 docker file creation, 
removing our symlink madness.  She has also been instrumental in actually 
getting Diagnostics implemented in a sanitary fashion.  She has also done a 
bunch of other work that folks in the community already know about that I won't 
repeat here.

I had always hoped she would start reviewing so we could invite her to the core 
review team, and over the last several months she has reviewed quite a bit!  
Her 90 day stats[1] place her at #9 with a solid ratio of 72%.  Her 30 day 
stats[2] are even better and place her at #6 with an improving ratio of 67%.  
She also just doesn't rubber stamp reviews or jump in reviews at the end; she 
sticks with them from beginning to end and finds real problems, not trivial 
things.  Finally Alicja is full time on Kolla as funded by her employer so she 
will be around for the long haul and always available.

Please consider my proposal to be a +1 vote.

To be approved for the core reviewer team, Alicja requires a majority vote of 6 
total votes with no veto within the one week period beginning now and ending 
Friday March 11th.  If your on the fence, you can always abstain.  If the vote 
is unanimous before the voting ends, I will make appropriate changes to 
gerrit's acls.  If their is a veto vote, voting will close prior to March 11th.

Regards,
-steve

[1] http://stackalytics.com/report/contribution/kolla-group/90
[2] http://stackalytics.com/report/contribution/kolla-group/30
__
OpenStack Development Mailing List (not for 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

2016-03-08 Thread Doug Hellmann
Excerpts from Colette Alexander's message of 2016-03-01 14:41:01 -0800:
> Hello Stackers,
> 
> This is the continuation of an ongoing conversation within the TC about
> encouraging the growth of leadership skills within the community that began
> just after the Mitaka summit last year[1]. After being asked by lifeless to
> do a bit of research and discussing needs/wants re: leadership directly
> with TC members, I made some suggestions on an etherpad[2], and was then
> asked to go find out about funding possibilities.
> 
> tl;dr - If you're a member of the TC or the Board and would like to attend
> Leadership Training at ZingTrain in Ann Arbor, please get back to me ASAP
> with your contact info and preferred timing/dates for this two-day training
> - also, please let me know whether April 20/21 (or April 21/22) would
> specifically work for you or not.

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?

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?

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?

I appreciate the effort you've gone into so far, and the Foundation
for offering to cover some of the costs, but I think we're putting
the cart before the horse.

Doug

[1] https://etherpad.openstack.org/p/Leadershiptraining
[2] http://www.communityleadershipsummit.com


> 
> 
> Longer version:
> Mark Collier and the Foundation have graciously offered to cover the costs
> of training for a two-day session at ZingTrain in Ann Arbor  - this
> includes the cost of breakfast/lunch for two days as well as two full
> working-days of seminars. Attendees would be responsible for their own
> travel, lodging, and incidental expenses beyond that (hopefully picked up
> by your employer who sees this as an amazing opportunity for your career
> growth). Currently, I've heard the week before the Austin Summit suggested
> by more than one person coming in from out of the country as preferred
> dates, but we've not committed to anything yet, so here might be a great
> time and place to hash that out among interested parties. ZingTrain has
> suggested a cap of ~20 people on the course, but that's not totally firm,
> so it's possible to add more if more are interested, or we could hold two
> separate two-day sessions to accommodate overflow. My ideal mix of people
> include those who are really excited by the idea of training, and those who
> are are seriously skeptical of any leadership training at all. In fact, if
> you've been to leadership training before and have found it to be terrible
> and awful, I think your input would be most valuable on this one. My
> summary of reasoning behind the 'why' of ZingTrain can be found on the
> etherpad I already mentioned[2]. Also, did I mention, the food will be
> amazing? It will be[3].
> 
> Some complications: the week before the Newton Summit there will be a set
> of incoming TC members (elected in early April) and likely some TC members
> who will be outgoing. Some possible solutions: we can certainly push back
> training til post-Summit when we can have a set of the 'new' TC, or we can
> sign up anyone interested currently, and allow a limited number of newly
> elected folks who are interested sign on as the election is finished. I
> certainly welcome any thoughts on that.
> 
> A note about starting out with the TC/Board for training: this initiative
> began as a set of conversations about leadership as a whole in the entire
> OpenStack community, so the intent with limiting to TC/Board here is not
> exclusion, merely finding the right place to start. My proposal with the TC
> begins with them, because the 

Re: [openstack-dev] [release] mitaka-3 development milestone

2016-03-08 Thread Thierry Carrez

Corey Bryant wrote:

neutron 8.0.0.0b3:
https://tarballs.openstack.org/neutron/neutron-8.0.0.0b3.tar.gz
https://tarballs.openstack.org/neutron-fwaas/neutron-fwaas-8.0.0.0b3.tar.gz
https://tarballs.openstack.org/neutron-lbaas/neutron-lbaas-8.0.0.0b3.tar.gz

https://tarballs.openstack.org/neutron-vpnaas/neutron-vpnaas-8.0.0.0b3.tar.gz


Hi Thierry,

I'm only seeing neutron-vpnaas-8.0.0.0b3.dev1.tar.gz on
https://tarballs.openstack.org/neutron-vpnaas.  Do we need an update there?


Something weird happened there... Let us investigate and get back to you.


--
Thierry Carrez (ttx)

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


Re: [openstack-dev] [all] [api] Reminder: WSME is not being actively maintained

2016-03-08 Thread gordon chung


On 08/03/2016 6:25 AM, Chris Dent wrote:
>
> Last summer Lucas Gomes and I were press ganged into becoming core on
> WSME. Since then we've piecemeal been verifying bug fixes and generally
> trying to keep things moving. However, from the beginning we both agreed
> that WSME is _not_ a web framework that we should be encouraging. Though
> it looks like it started with very good intentions, it never really
> reached a state where any of the following are true:
>
> * The WSME code is easy to understand and maintain.
> * WSME provides correct handling of HTTP (notably response status
>and headers).
> * WSME has an architecture that is suitable for creating modern
>Python-based web applications.
>
> Last summer we naively suggested that projects that are using it move to
> using something else. That suggestion did not take into account the
> realities of OpenStack.
>
> So we need to come up with a new plan. Lucas and I can continue to
> merge bug fixes as people provide them (and we become aware of them) and
> we can continue to hassle Doug Hellman to make a release when one is
> necessary but this does little to address the three gaps above nor the
> continued use of the framework in existing projects.
>
> Ideas?
>

it seems like the main reason there are so many projects leveraging WSME 
is because everyone is just using Ironic or Ceilometer as the starting 
point for their APIs. can we officially say to all new projects who plan 
on copying API logic of Ironic et al.: 'stop'.

what are the viable alternatives out there? Voluptuous, JSONSchema? i 
apologies, i know this is a question that gets asked every few months.

cheers,

-- 
gord

__
OpenStack Development Mailing 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] no upgrades meeting on March 14

2016-03-08 Thread Ihar Hrachyshka

Hi all,

a lot of subteam folks will take part in the code sprint in Brno next  
Mon-Wed, so we’ll cancel the next meeting. Next meeting will occur March 21.


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


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

2016-03-08 Thread Matt Riedemann



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

When you get back, let's continue the conversation either in email or
IRC #openstack-dev. Looking forward to hearing your feedback on this.

Thanks,

-amrith



-Original Message-
From: Matt Riedemann [mailto:mrie...@linux.vnet.ibm.com]
Sent: Tuesday, March 08, 2016 12:11 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 10:17 AM, Matt Riedemann wrote:

This is a call for help on resolving bug 1538506 [1] where the
proboscis tests randomly fail on the stable branches with something

like:


TypeError: create() got an unexpected keyword argument 'slave_of'

Craig Vyvial has a proposed stable/kilo change [2] but it has some
issues, at least from me as a reviewer of that change.

The tests are failing the periodic-stable job daily [3].

Can we get someone to help out with this? Otherwise I'm inclined to
say the tests should be disabled on the stable branches, but that's
pretty drastic.

Note that this is the kind of thing that breaks stable branch
policy, which is going to be part of a review when applying for the
stable:follows-policy tag. [4]  And the stable:follows-policy tag
may be used to determine when a stable branch for a project goes
end of life if it's not being maintained.

[1] https://bugs.launchpad.net/trove/+bug/1538506
[2] https://review.openstack.org/#/c/276934/
[3] http://goo.gl/fqf11U
[4]
http://governance.openstack.org/reference/tags/stable_follows-polic
y.h
tml



This is my solution for liberty, cap python-troveclient<2.1.0 in
global- requirements on stable/liberty [1].

Then there is a change to trove on stable/liberty to use the g-r
version range for python-troveclient for unit tests [2].

Alternatively, we could avoid the cap in stable/liberty by:

1. Reverting https://review.openstack.org/#/c/245738/
2. Blacklisting python-troveclient 2.1.0 in g-r 3. Release python-
troveclient 2.2.0.

It's getting late in the mitaka release to be messing with this
though since we're already past client freeze.

[1] https://review.openstack.org/#/c/290021/
[2] https://review.openstack.org/#/c/290023/

--

Thanks,

Matt Riedemann



__

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


_
_

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

Re: [openstack-dev] [TripleO] core members for tripleo-ui

2016-03-08 Thread Dan Prince
On Mon, 2016-02-29 at 18:32 +0100, Ana Krivokapic wrote:
> On Mon, Feb 29, 2016 at 4:27 PM, Dan Prince 
> wrote:
> > 
> > There is a new projects for the ui called tripleo-ui. As most of
> > the
> > existing TripleO core members aren't going to be reviewing UI
> > specific
> > patches is seems reasonable that we might add a few review
> > candidates
> > who can focus specifically on UI specific patches.
> Thanks, I think this makes perfect sense!
> 
> > 
> > 
> > I'd like to proposed we add Jiri Tomasek and Ana Krivokapic as core
> > candidates that will focus primarily on the UI. They would be added
> > to
> > tripleo core but would agree to only +2 patches within the UI for
> > now,
> > or at least until they are re-nominated for more general TripleO
> > core,
> > etc.
> I'd like to suggest Florian Fuchs instead of myself, as he has far
> more contributions (both commits and reviews) to the UI project (such
> as it is so far, [1]) then I do.

So be it. Its over a week now and no negative feedback so I went ahead
and added Jiri Tomasek and Florian Fuchs.

Thanks everyone who voted.

Dan

> 
> > 
> > 
> > Core members if you could please vote on this so we can add these
> > members at the close of this week. Thanks,
> > 
> > Dan
> > 
> > ___
> > ___
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsu
> > bscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> [1] https://github.com/rdo-management/rdo-director-ui/graphs/contribu
> tors
> 

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

2016-03-08 Thread Colette Alexander
On Tue, Mar 8, 2016 at 12:27 PM, Matt Riedemann 
wrote:

>
>>
> So is this for only current TC members? What about people that aren't on
> the TC?
>
> I asked in this in today's TC meeting but figured I'd ask here where it's
> more global.


Because of limited space in the class, and because of the very early stages
of figuring out what, exactly, leadership training or support might look
like in OpenStack, we're focusing on current and future-elected (in April)
TC members as attendees. If there is any extra space in the class
available, I'll be sure to announce that here on the ML as soon as we know,
and would *love* to open space up to the rest of the community, even in
these early stages. Anyone who's interested in learning more or giving
feedback should also feel free to ping me on IRC (I'm gothicmindfood) or
email - I'm happy to answer any and all questions about this.

Thanks!

-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


[openstack-dev] [ceilometer] Could not get ceilometer events for instances running on demo tenant

2016-03-08 Thread Umar Yousaf
I have a single node configuration for devstack liberty working and I want
to record all the *ceilometer events* like compute.instance.start,
compute.instance.end, compute.instance.update etc occurred recently.
I am unable to get any event occurred for instances running for demo
project i.e when I try *ceilometer event-list* I end up with an empty list
but I could fortunately get all the necessary events occurred for instances
running for admin project/tenant with the same command, I already have set
following in ceilometer.conf

 [notification]
 store_events = True

In addition to this I want to get these through python client so if someone
could provide me with the equivalent python call, that would be more than
handy.
Thanks in advance :)
Regard,
Umar
__
OpenStack Development Mailing List (not for 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

2016-03-08 Thread Matt Riedemann



On 3/1/2016 4:41 PM, Colette Alexander wrote:

Hello Stackers,

This is the continuation of an ongoing conversation within the TC about
encouraging the growth of leadership skills within the community that
began just after the Mitaka summit last year[1]. After being asked by
lifeless to do a bit of research and discussing needs/wants re:
leadership directly with TC members, I made some suggestions on an
etherpad[2], and was then asked to go find out about funding possibilities.

tl;dr - If you're a member of the TC or the Board and would like to
attend Leadership Training at ZingTrain in Ann Arbor, please get back to
me ASAP with your contact info and preferred timing/dates for this
two-day training - also, please let me know whether April 20/21 (or
April 21/22) would specifically work for you or not.


Longer version:
Mark Collier and the Foundation have graciously offered to cover the
costs of training for a two-day session at ZingTrain in Ann Arbor  -
this includes the cost of breakfast/lunch for two days as well as two
full working-days of seminars. Attendees would be responsible for their
own travel, lodging, and incidental expenses beyond that (hopefully
picked up by your employer who sees this as an amazing opportunity for
your career growth). Currently, I've heard the week before the Austin
Summit suggested by more than one person coming in from out of the
country as preferred dates, but we've not committed to anything yet, so
here might be a great time and place to hash that out among interested
parties. ZingTrain has suggested a cap of ~20 people on the course, but
that's not totally firm, so it's possible to add more if more are
interested, or we could hold two separate two-day sessions to
accommodate overflow. My ideal mix of people include those who are
really excited by the idea of training, and those who are are seriously
skeptical of any leadership training at all. In fact, if you've been to
leadership training before and have found it to be terrible and awful, I
think your input would be most valuable on this one. My summary of
reasoning behind the 'why' of ZingTrain can be found on the etherpad I
already mentioned[2]. Also, did I mention, the food will be amazing? It
will be[3].

Some complications: the week before the Newton Summit there will be a
set of incoming TC members (elected in early April) and likely some TC
members who will be outgoing. Some possible solutions: we can certainly
push back training til post-Summit when we can have a set of the 'new'
TC, or we can sign up anyone interested currently, and allow a limited
number of newly elected folks who are interested sign on as the election
is finished. I certainly welcome any thoughts on that.

A note about starting out with the TC/Board for training: this
initiative began as a set of conversations about leadership as a whole
in the entire OpenStack community, so the intent with limiting to
TC/Board here is not exclusion, merely finding the right place to start.
My proposal with the TC begins with them, because the leadership
conversation within OpenStack began with them, and the goals of training
are really to help them talk about defining the issue/problem
collectively, within a space designed to help people do that.

If you have any questions at all, please feel free to ping me on IRC
(gothicmindfood) or ask them here.

Thanks everyone!

-colette


[1]
http://eavesdrop.openstack.org/meetings/tc/2015/tc.2015-11-03-20.07.log.html
[2] https://etherpad.openstack.org/p/Leadershiptraining
[3] http://www.zingermansdeli.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



So is this for only current TC members? What about people that aren't on 
the TC?


I asked in this in today's TC meeting but figured I'd ask here where 
it's more global.


--

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] [magnum] SELinux is temporarily disabled due to bug 1551648

2016-03-08 Thread Hongbin Lu
Hi team,

FYI. In short, we have to temporarily disable SELinux [1] due to bug 1551648 
[2].

SELinux is an important security features for Linux kernel. It improves 
isolation between neighboring containers in the same host. In before, Magnum 
had it turned on in each bay node. However, we have to turn it off for now 
because k8s bay is not functioning if it is turned on. The details were 
described in the bug report [2]. We will turn SELinux back on once the issue is 
resolved (you are welcomed to contribute a fix). Thanks.

[1] https://review.openstack.org/#/c/289626/
[2] https://bugs.launchpad.net/magnum/+bug/1551648
Best regards,
Hongbin
__
OpenStack Development Mailing List (not for 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] mitaka-3 development milestone

2016-03-08 Thread Corey Bryant
On Fri, Mar 4, 2016 at 11:49 AM, Thierry Carrez 
wrote:

> Hello everyone,
>
> The last milestone of the Mitaka development cycle, "mitaka-3", is now
> reached. Some OpenStack projects following the milestone-based release
> schedule took the opportunity to publish a development artifact, which
> contains all the new features and bugfixes that have been added since
> mitaka-2 6 weeks ago:
>
> aodh 2.0.0.0b3:
> https://tarballs.openstack.org/aodh/aodh-2.0.0.0b3.tar.gz
>
> barbican 2.0.0.0b3:
> https://tarballs.openstack.org/barbican/barbican-2.0.0.0b3.tar.gz
>
> ceilometer 6.0.0.0b3:
> https://tarballs.openstack.org/ceilometer/ceilometer-6.0.0.0b3.tar.gz
>
> cinder 8.0.0.0b3:
> https://tarballs.openstack.org/cinder/cinder-8.0.0.0b3.tar.gz
>
> congress 3.0.0.0b3:
> https://tarballs.openstack.org/congress/congress-3.0.0.0b3.tar.gz
>
> designate 2.0.0.0b3:
> https://tarballs.openstack.org/designate/designate-2.0.0.0b3.tar.gz
>
> https://tarballs.openstack.org/designate-dashboard/designate-dashboard-2.0.0.0b3.tar.gz
>
> glance 12.0.0.0b3:
> https://tarballs.openstack.org/glance/glance-12.0.0.0b3.tar.gz
>
> heat 6.0.0.0b3:
> https://tarballs.openstack.org/heat/heat-6.0.0.0b3.tar.gz
>
> horizon 9.0.0.0b3:
> https://tarballs.openstack.org/horizon/horizon-9.0.0.0b3.tar.gz
>
> keystone 9.0.0.0b3:
> https://tarballs.openstack.org/keystone/keystone-9.0.0.0b3.tar.gz
>
> manila 2.0.0.0b3:
> https://tarballs.openstack.org/manila/manila-2.0.0.0b3.tar.gz
>
> mistral 2.0.0.0b3:
> https://tarballs.openstack.org/mistral/mistral-2.0.0.0b3.tar.gz
>
> https://tarballs.openstack.org/mistral-dashboard/mistral-dashboard-2.0.0.0b3.tar.gz
> https://tarballs.openstack.org/mistral-extra/mistral-extra-2.0.0.0b3.tar.gz
>
> murano 2.0.0.0b3:
> https://tarballs.openstack.org/murano/murano-2.0.0.0b3.tar.gz
>
> neutron 8.0.0.0b3:
> https://tarballs.openstack.org/neutron/neutron-8.0.0.0b3.tar.gz
> https://tarballs.openstack.org/neutron-fwaas/neutron-fwaas-8.0.0.0b3.tar.gz
> https://tarballs.openstack.org/neutron-lbaas/neutron-lbaas-8.0.0.0b3.tar.gz
>
> https://tarballs.openstack.org/neutron-vpnaas/neutron-vpnaas-8.0.0.0b3.tar.gz


Hi Thierry,

I'm only seeing neutron-vpnaas-8.0.0.0b3.dev1.tar.gz on
https://tarballs.openstack.org/neutron-vpnaas.  Do we need an update there?

Thanks,
Corey
__
OpenStack Development Mailing List (not for 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][vote] exception for backporting upgrades to liberty/stable

2016-03-08 Thread Steven Dake (stdake)
The vote was not exactly unanimous.

I counted the following:

1.1.0
Steven Dake +1
Paul Bourke +1
Martin Andre +1
Michal Rostecki -1
Jeff Peeler +1
Ryan Hallisey +1
Michal Rosteki -1
Michal Jasterzebski -1

Since there are 6 votes in favor out of the 11 person core review team, 1.1.0 
will include backported upgrades for z and y streams.

1.2.0
Steven Dake -1
Michal Rosteki +1
Michal Jasterzebski +1

Since 1.2.0 was not what the original vote was abut, and it would be 
incompatible with 1.1.0, I'm not sure what to do if both votes passed.  
Nonetheless, if someone from the core reviewer community requests a 1.2.0 vote 
as opposed to a 1.1.0 backport, please feel free to follow up with me on IRC if 
you wish to remain anonymous or follow up on this thread.

At this time, the current plan is to release 1.1.0 before April 1st with Docker 
1.10.0+, named volumes, neutron thin containers, and upgrades from 1.1.0 to a 
later version (either X, Y, or Z).  We won't be backporting reconfigure, 
prechecks, post-deploy, TLS, or any of the other numerous features in Kolla 
Mitaka.

Regards,
-steve

From: Steven Dake >
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Monday, March 7, 2016 at 8:03 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Subject: [openstack-dev] [kolla][vote] exception for backporting upgrades to 
liberty/stable

Hi folks,

It was never really discussed if we would back-port upgrades to liberty.  This 
came up during  an irc conversation Friday [1], and a vote was requested.  Tthe 
facts of the discussion distilled are:

  *   We never agreed as a group to do back-port of upgrade during our 
back-port discussion
  *   An operator that can't upgrade her Z version of Kolla (1.1.1 from 1.1.0) 
is stuck without CVE or OSSA corrections.
  *   Because of a lack of security upgrades, the individual responsible for 
executing the back-port would abandon the work (but not tuse the abaondon 
feature for of gerrit for changes already in the queue)

Since we never agreed, in that IRC discussion a vote was requested, and I am 
administering the vote.  The vote request was specifically should we have a 
back-port of upgrade in 1.1.0.  Both parties agreed they would live with the 
results.

I would like to point out that not porting upgrades means that the liberty 
branch would essentially become abandoned unless some other brave soul takes up 
a backport.  I would also like to point out that that is yet another exception 
much like thin-containers back-port which was accepted.  See how exceptions 
become the way to the dark side.  We really need to stay exception free going 
forward (in Mitaka and later) as much as possible to prevent expectations that 
we will make exceptions when none should be made.

Please vote +1 (backport) or -1 (don't backport).  An abstain in this case is 
the same as voting -1, so please vote either way.  I will leave the voting open 
for 1 week until April 14th.  If there I a majority in favor, I will close 
voting early.  We currently require 6 votes for majority as our core team 
consists of 11 people.

Regards,
-steve


[1] 
http://eavesdrop.openstack.org/irclogs/%23kolla/%23kolla.2016-03-04.log.html#t2016-03-04T18:23:26

Warning [1] was a pretty heated argument and there may have been some swearing 
:)

voting.

"Should we back-port upgrades
__
OpenStack Development Mailing 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][release] Releasing python-neutronclient 4.1.2?

2016-03-08 Thread Armando M.
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.

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


Re: [openstack-dev] [qa] Tempest removal of tempest.api.compute.test_authorization

2016-03-08 Thread Sean Dague
On 02/16/2016 03:38 PM, Matthew Treinish wrote:
> On Tue, Feb 09, 2016 at 07:41:18PM -0500, Sean Dague wrote:
>> As proposed in this patch - https://review.openstack.org/#/c/271467/
>>
>> These tests do some manipulation of the request URI to attempt to
>> request Nova resources owned by a different project_id. However they all
>> basically test the same 7 lines of Nova, and now that Nova doesn't
>> require project_id in the url it's actively harmful to moving forward.
>>
> 
> Looking at the review it looks like people working on defcore chimed and said
> that they are ok with these tests being removed. So my primary concern with
> removing the tests seems to be addressed. It looks like all 3 criteria from:
> 
> https://wiki.openstack.org/wiki/QA/Tempest-test-removal
> 
> have been addressed. (since there is equivalent coverage elsewhere and the
> tests haven't ever really failed according to [1]) But, before I'm +2 on the
> change I had a couple of questions. Do you think there is a potential exposure
> being opened up here across release boundaries? Is there still value in 
> running
> the tests on either stable releases or existing deployments? Tempest is used 
> for
> more than just gate testing master and I just want to make sure we're not
> opening a hole in our coverage to make some nova changes on master easier.

I realized there remained an open question here.

I don't think this test is really useful for stable. At the end of the
day everything in the test class is testing the same single if condition
in Nova. That's covered well enough by Nova in tree tests.

-Sean

-- 
Sean Dague
http://dague.net

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


Re: [openstack-dev] [keystone] Using multiple token formats in a one openstack cloud

2016-03-08 Thread Matt Fischer
I don't think your example is right: "PKI will validate that token without
going to any keystone server". How would it track revoked tokens? I'm
pretty sure that they still get validated, they are stored in the DB even.

I also disagree that there are different use cases. Just switch to fernet
and save yourself what's going to be weeks of pain with probably no
improvement in anything with this idea.

On Tue, Mar 8, 2016 at 9:56 AM, rezroo  wrote:

> The basic idea is to let the openstack clients decide what sort of token
> optimization to use - for example, while a normal client uses uuid tokens,
> some services like heat or magnum may opt for pki tokens for their
> operations. A service like nova, configured for PKI will validate that
> token without going to any keystone server, but if it gets a uuid token
> then validates it with a keystone endpoint. I'm under the impression that
> the different token formats have different use-cases, so am wondering if
> there is a conceptual reason why multiple token formats are an either/or
> scenario.
>
>
> On 3/8/2016 8:06 AM, Matt Fischer wrote:
>
> This would be complicated to setup. How would the Openstack services
> validate the token? Which keystone node would they use? A better question
> is why would you want to do this?
>
> On Tue, Mar 8, 2016 at 8:45 AM, rezroo  wrote:
>
>> Keystone supports both tokens and ec2 credentials simultaneously, but as
>> far as I can tell, will only do a single token format (uuid, pki/z, fernet)
>> at a time. Is it possible or advisable to configure keystone to issue
>> multiple token formats? For example, I could configure two keystone
>> servers, each using a different token format, so depending on endpoint
>> used, I could get a uuid or pki token. Each service can use either token
>> format, so is there a conceptual or implementation issue with this setup?
>> Thanks,
>> Reza
>>
>> __
>> OpenStack Development Mailing 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:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [tripleo] CI jobs failures

2016-03-08 Thread James Slagle
On Tue, Mar 8, 2016 at 12:58 PM, Derek Higgins  wrote:
> We discussed this at today's meeting but never really came to a
> conclusion except to say most people wanted to try it. The main
> objection brought up was that we shouldn't go dropping the nonha job,
> that isn't what I was proposing so let me rephrase here and see if we
> can gather +/-1's
>
> I'm proposing we redeploy our testenvs with more RAM allocated per
> env, specifically we would go from
> 5G undercloud and 4G overcloud nodes to
> 6G undercloud and 5G overcloud nodes to

+1

>
> In addition to accommodate this we would reduce the number of env's
> available from 48 (the actually number varies from time to time) to 36
> (3 envs per host)
>
> No changes would be happening on the jobs we actually run

+1

>
> The assumption is that with the increased resources we would hit less
> false negative test results and as a result recheck jobs less (so the
> 25% reduction in capacity wouldn't hit us as hard as it might seem),
> we also may not be able to easily undo this if it doesn't work out as
> once we start merging things that use the extra RAM it will be hard to
> go back.

The CPU load is also very high. When I have been looking at jobs that
appear stuck, it takes almost 3 minutes just to do a nova list
sometimes. So I think 1 less testenv on each host will help that as
well.

-- 
-- James Slagle
--

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

2016-03-08 Thread Amrith Kumar
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 fixed.
> >>
> >> When you get back, let's continue the conversation either in email or
> >> IRC #openstack-dev. Looking forward to hearing your feedback on this.
> >>
> >> Thanks,
> >>
> >> -amrith
> >>
> >>
> >>> -Original Message-
> >>> From: Matt Riedemann [mailto:mrie...@linux.vnet.ibm.com]
> >>> Sent: Tuesday, March 08, 2016 12:11 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 10:17 AM, Matt Riedemann wrote:
>  This is a call for help on resolving bug 1538506 [1] where the
>  proboscis tests randomly fail on the stable branches with something
> >>> like:
> 
>  TypeError: create() got an unexpected keyword argument 'slave_of'
> 
>  Craig Vyvial has a proposed stable/kilo change [2] but it has some
>  issues, at least from me as a reviewer of that change.
> 
>  The tests are failing the periodic-stable job daily [3].
> 
>  Can we get someone to help out with this? Otherwise I'm inclined to
>  say the tests should be disabled on the stable branches, but that's
>  pretty drastic.
> 
>  Note that this is the kind of thing that breaks stable branch
>  policy, which is going to be part of a review when applying for the
>  stable:follows-policy tag. [4]  And the stable:follows-policy tag
>  may be used to determine when a stable branch for a project goes
>  end of life if it's not being maintained.
> 
>  [1] https://bugs.launchpad.net/trove/+bug/1538506
>  [2] https://review.openstack.org/#/c/276934/
>  [3] http://goo.gl/fqf11U
>  [4]
>  http://governance.openstack.org/reference/tags/stable_follows-polic
>  y.h
>  tml
> 
> >>>
> >>> This is my solution for liberty, cap python-troveclient<2.1.0 in
> >>> global- requirements on stable/liberty [1].
> >>>
> >>> Then there is a change to trove on stable/liberty to use the g-r
> >>> version range for python-troveclient for unit tests [2].
> >>>
> >>> Alternatively, we could avoid the cap in stable/liberty by:
> >>>
> >>> 1. Reverting https://review.openstack.org/#/c/245738/
> >>> 2. Blacklisting python-troveclient 2.1.0 in g-r 3. Release python-
> >>> troveclient 2.2.0.
> >>>
> >>> It's getting late in the mitaka release to be messing with this
> >>> though since we're already past client freeze.
> >>>
> >>> [1] 

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

2016-03-08 Thread Amrith Kumar
See below.

> -Original Message-
> From: Matt Riedemann [mailto:mrie...@linux.vnet.ibm.com]
> Sent: Tuesday, March 08, 2016 1:53 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: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/a
> > pi/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-
> requirements.txt#L174

[amrith] Yes, the server understands replica_of.

> 
> > 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-
> requirements.txt#L202

[amrith] My mistake, this specific issue won't cause a problem there. It'll 
work.

> 
> > 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 fixed.
> >
> > When you get back, let's continue the conversation either in email or
> IRC #openstack-dev. Looking forward to hearing your feedback on this.
> >
> > Thanks,
> >
> > -amrith
> >
> >
> >> -Original Message-
> >> From: Matt Riedemann [mailto:mrie...@linux.vnet.ibm.com]
> >> Sent: Tuesday, March 08, 2016 12:11 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 10:17 AM, Matt Riedemann wrote:
> >>> This is a call for help on resolving bug 1538506 [1] where the
> >>> proboscis tests randomly fail on the stable branches with something
> >> like:
> >>>
> >>> TypeError: create() got an unexpected keyword argument 'slave_of'
> >>>
> >>> Craig Vyvial has a proposed stable/kilo change [2] but it has some
> >>> issues, at least from me as a reviewer of that change.
> >>>
> >>> The tests are failing the periodic-stable job daily [3].
> >>>
> >>> Can we get someone to help out with this? Otherwise I'm inclined to
> >>> say the tests should be disabled on the stable branches, but that's
> >>> pretty drastic.
> >>>
> >>> Note that this is the kind of thing that breaks stable branch
> >>> policy, which is going to be part of a review when applying for the
> >>> stable:follows-policy tag. [4]  And the stable:follows-policy tag
> >>> may be used to determine when a stable branch for a project goes end
> >>> of life if it's not being maintained.
> >>>
> >>> [1] https://bugs.launchpad.net/trove/+bug/1538506
> >>> [2] https://review.openstack.org/#/c/276934/
> >>> [3] http://goo.gl/fqf11U
> >>> [4]
> >>> http://governance.openstack.org/reference/tags/stable_follows-policy
> >>> .h
> >>> tml
> >>>
> >>
> >> This is my solution for liberty, cap python-troveclient<2.1.0 in
> >> global- requirements on stable/liberty [1].
> >>
> >> Then there is a change to trove on stable/liberty to use the g-r
> >> version range for python-troveclient for unit tests [2].
> >>
> >> Alternatively, we could avoid the cap in stable/liberty by:
> >>
> >> 1. Reverting https://review.openstack.org/#/c/245738/
> >> 2. Blacklisting python-troveclient 2.1.0 in g-r 3. Release python-
> >> troveclient 2.2.0.
> >>
> >> It's getting late in the mitaka release to be messing with this
> >> though since we're already past client freeze.
> >>
> >> [1] https://review.openstack.org/#/c/290021/
> >> [2] https://review.openstack.org/#/c/290023/
> >>
> >> --
> >>
> >> Thanks,
> >>
> >> Matt Riedemann
> >>
> >>
> >> _
> >> _ OpenStack Development Mailing List (not for usage questions)
> >> Unsubscribe:
> >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >> 

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

2016-03-08 Thread Matt Riedemann



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





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

When you get back, let's continue the conversation either in email or
IRC #openstack-dev. Looking forward to hearing your feedback on this.

Thanks,

-amrith



-Original Message-
From: Matt Riedemann [mailto:mrie...@linux.vnet.ibm.com]
Sent: Tuesday, March 08, 2016 12:11 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 10:17 AM, Matt Riedemann wrote:

This is a call for help on resolving bug 1538506 [1] where the
proboscis tests randomly fail on the stable branches with something

like:


TypeError: create() got an unexpected keyword argument 'slave_of'

Craig Vyvial has a proposed stable/kilo change [2] but it has some
issues, at least from me as a reviewer of that change.

The tests are failing the periodic-stable job daily [3].

Can we get someone to help out with this? Otherwise I'm inclined to
say the tests should be disabled on the stable branches, but that's
pretty drastic.

Note that this is the kind of thing that breaks stable branch policy,
which is going to be part of a review when applying for the
stable:follows-policy tag. [4]  And the stable:follows-policy tag may
be used to determine when a stable branch for a project goes end of
life if it's not being maintained.

[1] https://bugs.launchpad.net/trove/+bug/1538506
[2] https://review.openstack.org/#/c/276934/
[3] http://goo.gl/fqf11U
[4]
http://governance.openstack.org/reference/tags/stable_follows-policy.h
tml



This is my solution for liberty, cap python-troveclient<2.1.0 in global-
requirements on stable/liberty [1].

Then there is a change to trove on stable/liberty to use the g-r version
range for python-troveclient for unit tests [2].

Alternatively, we could avoid the cap in stable/liberty by:

1. Reverting https://review.openstack.org/#/c/245738/
2. Blacklisting python-troveclient 2.1.0 in g-r 3. Release python-
troveclient 2.2.0.

It's getting late in the mitaka release to be messing with this though
since we're already past client freeze.

[1] https://review.openstack.org/#/c/290021/
[2] https://review.openstack.org/#/c/290023/

--

Thanks,

Matt Riedemann


__

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


__

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





--

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] [trove][stable] proboscis tests randomly failing in stable branches; bug 1538506

2016-03-08 Thread Matt Riedemann



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-requirements.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-requirements.txt#L202


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

When you get back, let's continue the conversation either in email or IRC 
#openstack-dev. Looking forward to hearing your feedback on this.

Thanks,

-amrith



-Original Message-
From: Matt Riedemann [mailto:mrie...@linux.vnet.ibm.com]
Sent: Tuesday, March 08, 2016 12:11 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 10:17 AM, Matt Riedemann wrote:

This is a call for help on resolving bug 1538506 [1] where the
proboscis tests randomly fail on the stable branches with something

like:


TypeError: create() got an unexpected keyword argument 'slave_of'

Craig Vyvial has a proposed stable/kilo change [2] but it has some
issues, at least from me as a reviewer of that change.

The tests are failing the periodic-stable job daily [3].

Can we get someone to help out with this? Otherwise I'm inclined to
say the tests should be disabled on the stable branches, but that's
pretty drastic.

Note that this is the kind of thing that breaks stable branch policy,
which is going to be part of a review when applying for the
stable:follows-policy tag. [4]  And the stable:follows-policy tag may
be used to determine when a stable branch for a project goes end of
life if it's not being maintained.

[1] https://bugs.launchpad.net/trove/+bug/1538506
[2] https://review.openstack.org/#/c/276934/
[3] http://goo.gl/fqf11U
[4]
http://governance.openstack.org/reference/tags/stable_follows-policy.h
tml



This is my solution for liberty, cap python-troveclient<2.1.0 in global-
requirements on stable/liberty [1].

Then there is a change to trove on stable/liberty to use the g-r version
range for python-troveclient for unit tests [2].

Alternatively, we could avoid the cap in stable/liberty by:

1. Reverting https://review.openstack.org/#/c/245738/
2. Blacklisting python-troveclient 2.1.0 in g-r 3. Release python-
troveclient 2.2.0.

It's getting late in the mitaka release to be messing with this though
since we're already past client freeze.

[1] https://review.openstack.org/#/c/290021/
[2] https://review.openstack.org/#/c/290023/

--

Thanks,

Matt Riedemann


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


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



--

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] [kolla][vote] exception for backporting upgrades to liberty/stable

2016-03-08 Thread Ryan Hallisey
Another tricky situation..

Given that changes to Docker were the cause of the first two backports I'd 
consider those to not be exceptions, but necessary adaptations that Kolla has 
to deal with.  Unfortunately, this case seems more like an exception.  But, I'm 
not opposed to a necessary exception since we planned to deliver on it, but ran 
out of time. +1 to the backport. We definitely need it.

Thanks,
Ryan


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

Sent: Tuesday, March 8, 2016 1:15:10 PM
Subject: Re: [openstack-dev] [kolla][vote] exception for backporting upgrades 
to liberty/stable

Exceptions can always be rationalized which is one reason exceptions are evil 
among many. The facts however speak for themselves. If we don't have a way to 
introduce new content in liberty when CVEs are fixed, stable/liberty is just as 
flawed as the data loss problem which was the original trigger for the 
backporting of the playbooks in the first place to introduce named volumes. 

As a result, I am +1 to 1.1.0 backport. 

I am –1 to a 1.2.0 because back to back releases are a pain in the ass to 
manage and offer little value. 1.1.1 without upgrades would be flawed just as 
1.1.0 is today. 

Regards 
-steve 

From: Steven Dake < std...@cisco.com > 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" < 
openstack-dev@lists.openstack.org > 
Date: Monday, March 7, 2016 at 8:03 AM 
To: "OpenStack Development Mailing List (not for usage questions)" < 
openstack-dev@lists.openstack.org > 
Subject: [openstack-dev] [kolla][vote] exception for backporting upgrades to 
liberty/stable 




Hi folks, 

It was never really discussed if we would back-port upgrades to liberty. This 
came up during an irc conversation Friday [1], and a vote was requested. Tthe 
facts of the discussion distilled are: 


* We never agreed as a group to do back-port of upgrade during our 
back-port discussion 
* An operator that can't upgrade her Z version of Kolla (1.1.1 from 1.1.0) 
is stuck without CVE or OSSA corrections. 
* Because of a lack of security upgrades, the individual responsible for 
executing the back-port would abandon the work (but not tuse the abaondon 
feature for of gerrit for changes already in the queue) 
Since we never agreed, in that IRC discussion a vote was requested, and I am 
administering the vote. The vote request was specifically should we have a 
back-port of upgrade in 1.1.0. Both parties agreed they would live with the 
results. 

I would like to point out that not porting upgrades means that the liberty 
branch would essentially become abandoned unless some other brave soul takes up 
a backport. I would also like to point out that that is yet another exception 
much like thin-containers back-port which was accepted. See how exceptions 
become the way to the dark side. We really need to stay exception free going 
forward (in Mitaka and later) as much as possible to prevent expectations that 
we will make exceptions when none should be made. 

Please vote +1 (backport) or –1 (don’t backport). An abstain in this case is 
the same as voting –1, so please vote either way. I will leave the voting open 
for 1 week until April 14th. If there I a majority in favor, I will close 
voting early. We currently require 6 votes for majority as our core team 
consists of 11 people. 

Regards, 
-steve 


[1] 
http://eavesdrop.openstack.org/irclogs/%23kolla/%23kolla.2016-03-04.log.html#t2016-03-04T18:23:26
 

Warning [1] was a pretty heated argument and there may have been some swearing 
:) 

voting. 

"Should we back-port upgrades 

__
OpenStack Development Mailing 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][LBaaS]Removing LBaaS v1 - are weready?

2016-03-08 Thread Eichberger, German
Yes, it’s Database only — though we changed the agent driver in the DB from V1 
to V2 — so if you bring up a V2 with that database it should reschedule all 
your load balancers on the V2 agent driver.

German




On 3/8/16, 3:13 AM, "Samuel Bercovici"  wrote:

>So this looks like only a database migration, right?
>
>-Original Message-
>From: Eichberger, German [mailto:german.eichber...@hpe.com] 
>Sent: Tuesday, March 08, 2016 12:28 AM
>To: OpenStack Development Mailing List (not for usage questions)
>Subject: Re: [openstack-dev] [Neutron][LBaaS]Removing LBaaS v1 - are weready?
>
>Ok, for what it’s worth we have contributed our migration script: 
>https://review.openstack.org/#/c/289595/ — please look at this as a starting 
>point and feel free to fix potential problems…
>
>Thanks,
>German
>
>
>
>
>On 3/7/16, 11:00 AM, "Samuel Bercovici"  wrote:
>
>>As far as I recall, you can specify the VIP in creating the LB so you will 
>>end up with same IPs.
>>
>>-Original Message-
>>From: Eichberger, German [mailto:german.eichber...@hpe.com]
>>Sent: Monday, March 07, 2016 8:30 PM
>>To: OpenStack Development Mailing List (not for usage questions)
>>Subject: Re: [openstack-dev] [Neutron][LBaaS]Removing LBaaS v1 - are weready?
>>
>>Hi Sam,
>>
>>So if you have some 3rd party hardware you only need to change the 
>>database (your steps 1-5) since the 3rd party hardware will just keep 
>>load balancing…
>>
>>Now for Kevin’s case with the namespace driver:
>>You would need a 6th step to reschedule the loadbalancers with the V2 
>>namespace driver — which can be done.
>>
>>If we want to migrate to Octavia or (from one LB provider to another) it 
>>might be better to use the following steps:
>>
>>1. Download LBaaS v1 information (Tenants, Flavors, VIPs, Pools, Health 
>>Monitors , Members) into some JSON format file(s) 2. Delete LBaaS v1 3. 
>>Uninstall LBaaS v1 4. Install LBaaS v2 5. Transform the JSON format 
>>file into some scripts which recreate the load balancers with your 
>>provider of choice —
>>
>>6. Run those scripts
>>
>>The problem I see is that we will probably end up with different VIPs 
>>so the end user would need to change their IPs…
>>
>>Thanks,
>>German
>>
>>
>>
>>On 3/6/16, 5:35 AM, "Samuel Bercovici"  wrote:
>>
>>>As for a migration tool.
>>>Due to model changes and deployment changes between LBaaS v1 and LBaaS v2, I 
>>>am in favor for the following process:
>>>
>>>1. Download LBaaS v1 information (Tenants, Flavors, VIPs, Pools, 
>>>Health Monitors , Members) into some JSON format file(s) 2. Delete LBaaS v1 
>>>3.
>>>Uninstall LBaaS v1 4. Install LBaaS v2 5. Import the data from 1 back 
>>>over LBaaS v2 (need to allow moving from falvor1-->flavor2, need to 
>>>make room to some custom modification for mapping between v1 and v2
>>>models)
>>>
>>>What do you think?
>>>
>>>-Sam.
>>>
>>>
>>>
>>>
>>>-Original Message-
>>>From: Fox, Kevin M [mailto:kevin@pnnl.gov]
>>>Sent: Friday, March 04, 2016 2:06 AM
>>>To: OpenStack Development Mailing List (not for usage questions)
>>>Subject: Re: [openstack-dev] [Neutron][LBaaS]Removing LBaaS v1 - are weready?
>>>
>>>Ok. Thanks for the info.
>>>
>>>Kevin
>>>
>>>From: Brandon Logan [brandon.lo...@rackspace.com]
>>>Sent: Thursday, March 03, 2016 2:42 PM
>>>To: openstack-dev@lists.openstack.org
>>>Subject: Re: [openstack-dev] [Neutron][LBaaS]Removing LBaaS v1 - are weready?
>>>
>>>Just for clarity, V2 did not reuse tables, all the tables it uses are only 
>>>for it.  The main problem is that v1 and v2 both have a pools resource, but 
>>>v1 and v2's pool resource have different attributes.  With the way neutron 
>>>wsgi works, if both v1 and v2 are enabled, it will combine both sets of 
>>>attributes into the same validation schema.
>>>
>>>The other problem with v1 and v2 running together was only occurring when 
>>>the v1 agent driver and v2 agent driver were both in use at the same time.  
>>>This may actually have been fixed with some agent updates in neutron, since 
>>>that is common code.  It needs to be tested out though.
>>>
>>>Thanks,
>>>Brandon
>>>
>>>On Thu, 2016-03-03 at 22:14 +, Fox, Kevin M wrote:
 Just because you had thought no one was using it outside of a PoC doesn't 
 mean folks aren''t using it in production.

 We would be happy to migrate to Octavia. We were planning on doing just 
 that by running both v1 with haproxy namespace, and v2 with Octavia and 
 then pick off upgrading lb's one at a time, but the reuse of the v1 tables 
 really was an unfortunate decision that blocked that activity.

 We're still trying to figure out a path forward.

 We have an outage window next month. after that, it could be about 6 
 months before we could try a migration due to production load 
 picking up for a while. I may just have to burn out all the lb's 
 switch to v2, then 

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

2016-03-08 Thread Amrith Kumar
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.
3. User running an old python-troveclient and a new server from mitaka, this is 
not supported.
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 fixed.

When you get back, let's continue the conversation either in email or IRC 
#openstack-dev. Looking forward to hearing your feedback on this.

Thanks,

-amrith
 

> -Original Message-
> From: Matt Riedemann [mailto:mrie...@linux.vnet.ibm.com]
> Sent: Tuesday, March 08, 2016 12:11 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 10:17 AM, Matt Riedemann wrote:
> > This is a call for help on resolving bug 1538506 [1] where the
> > proboscis tests randomly fail on the stable branches with something
> like:
> >
> > TypeError: create() got an unexpected keyword argument 'slave_of'
> >
> > Craig Vyvial has a proposed stable/kilo change [2] but it has some
> > issues, at least from me as a reviewer of that change.
> >
> > The tests are failing the periodic-stable job daily [3].
> >
> > Can we get someone to help out with this? Otherwise I'm inclined to
> > say the tests should be disabled on the stable branches, but that's
> > pretty drastic.
> >
> > Note that this is the kind of thing that breaks stable branch policy,
> > which is going to be part of a review when applying for the
> > stable:follows-policy tag. [4]  And the stable:follows-policy tag may
> > be used to determine when a stable branch for a project goes end of
> > life if it's not being maintained.
> >
> > [1] https://bugs.launchpad.net/trove/+bug/1538506
> > [2] https://review.openstack.org/#/c/276934/
> > [3] http://goo.gl/fqf11U
> > [4]
> > http://governance.openstack.org/reference/tags/stable_follows-policy.h
> > tml
> >
> 
> This is my solution for liberty, cap python-troveclient<2.1.0 in global-
> requirements on stable/liberty [1].
> 
> Then there is a change to trove on stable/liberty to use the g-r version
> range for python-troveclient for unit tests [2].
> 
> Alternatively, we could avoid the cap in stable/liberty by:
> 
> 1. Reverting https://review.openstack.org/#/c/245738/
> 2. Blacklisting python-troveclient 2.1.0 in g-r 3. Release python-
> troveclient 2.2.0.
> 
> It's getting late in the mitaka release to be messing with this though
> since we're already past client freeze.
> 
> [1] https://review.openstack.org/#/c/290021/
> [2] https://review.openstack.org/#/c/290023/
> 
> --
> 
> Thanks,
> 
> Matt Riedemann
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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


Re: [openstack-dev] [kolla][vote] exception for backporting upgrades to liberty/stable

2016-03-08 Thread Steven Dake (stdake)
Exceptions can always be rationalized which is one reason exceptions are evil 
among many.  The facts however speak for themselves.  If we don't have a way to 
introduce new content in liberty when CVEs are fixed, stable/liberty is just as 
flawed as the data loss problem which was the original trigger for the 
backporting of the playbooks in the first place to introduce named volumes.

As a result, I am +1 to 1.1.0 backport.

I am -1 to a 1.2.0 because back to back releases are a pain in the ass to 
manage and offer little value.  1.1.1 without upgrades would be flawed just as 
1.1.0 is today.

Regards
-steve

From: Steven Dake >
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Monday, March 7, 2016 at 8:03 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Subject: [openstack-dev] [kolla][vote] exception for backporting upgrades to 
liberty/stable

Hi folks,

It was never really discussed if we would back-port upgrades to liberty.  This 
came up during  an irc conversation Friday [1], and a vote was requested.  Tthe 
facts of the discussion distilled are:

  *   We never agreed as a group to do back-port of upgrade during our 
back-port discussion
  *   An operator that can't upgrade her Z version of Kolla (1.1.1 from 1.1.0) 
is stuck without CVE or OSSA corrections.
  *   Because of a lack of security upgrades, the individual responsible for 
executing the back-port would abandon the work (but not tuse the abaondon 
feature for of gerrit for changes already in the queue)

Since we never agreed, in that IRC discussion a vote was requested, and I am 
administering the vote.  The vote request was specifically should we have a 
back-port of upgrade in 1.1.0.  Both parties agreed they would live with the 
results.

I would like to point out that not porting upgrades means that the liberty 
branch would essentially become abandoned unless some other brave soul takes up 
a backport.  I would also like to point out that that is yet another exception 
much like thin-containers back-port which was accepted.  See how exceptions 
become the way to the dark side.  We really need to stay exception free going 
forward (in Mitaka and later) as much as possible to prevent expectations that 
we will make exceptions when none should be made.

Please vote +1 (backport) or -1 (don't backport).  An abstain in this case is 
the same as voting -1, so please vote either way.  I will leave the voting open 
for 1 week until April 14th.  If there I a majority in favor, I will close 
voting early.  We currently require 6 votes for majority as our core team 
consists of 11 people.

Regards,
-steve


[1] 
http://eavesdrop.openstack.org/irclogs/%23kolla/%23kolla.2016-03-04.log.html#t2016-03-04T18:23:26

Warning [1] was a pretty heated argument and there may have been some swearing 
:)

voting.

"Should we back-port upgrades
__
OpenStack Development Mailing List (not for 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][vote] Proposing Alicja Kwasniewska for core reviewer

2016-03-08 Thread Steven Dake (stdake)
The vote is unanimous.

Welcome to the core reviewer team Alicja!  Ping me when you get online next and 
our timezone overlaps, and I'll walk you through the differences in the gerrit 
interface you should know.

I have made appropriate changes in gerrit.

Regards
-steve

From: Steven Dake >
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Friday, March 4, 2016 at 9:55 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Subject: [openstack-dev] [kolla][vote] Proposing Alicja Kwasniewska for core 
reviewer

Core Reviewers,

Alicja has been instrumental in our work around jinja2 docker file creation, 
removing our symlink madness.  She has also been instrumental in actually 
getting Diagnostics implemented in a sanitary fashion.  She has also done a 
bunch of other work that folks in the community already know about that I won't 
repeat here.

I had always hoped she would start reviewing so we could invite her to the core 
review team, and over the last several months she has reviewed quite a bit!  
Her 90 day stats[1] place her at #9 with a solid ratio of 72%.  Her 30 day 
stats[2] are even better and place her at #6 with an improving ratio of 67%.  
She also just doesn't rubber stamp reviews or jump in reviews at the end; she 
sticks with them from beginning to end and finds real problems, not trivial 
things.  Finally Alicja is full time on Kolla as funded by her employer so she 
will be around for the long haul and always available.

Please consider my proposal to be a +1 vote.

To be approved for the core reviewer team, Alicja requires a majority vote of 6 
total votes with no veto within the one week period beginning now and ending 
Friday March 11th.  If your on the fence, you can always abstain.  If the vote 
is unanimous before the voting ends, I will make appropriate changes to 
gerrit's acls.  If their is a veto vote, voting will close prior to March 11th.

Regards,
-steve

[1] http://stackalytics.com/report/contribution/kolla-group/90
[2] http://stackalytics.com/report/contribution/kolla-group/30
__
OpenStack Development Mailing 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] [searchlight] Horizon, Search, and Composability

2016-03-08 Thread Tripp, Travis S
Hello everybody,

At the Horizon mid-cycle we had a lot of discussion on UI composability and 
searchability. Matt and Tyr provided a short presentation and demo at the 
mid-cycle. This morning I gave a more detailed presentation and demo via 
hangouts on air regarding Searchlight and Horizon. The audience this morning 
was broader, so I started with content based on Matt and Tyr’s presentation and 
included an extended demo, additional information about Searchlight, and some 
status information about what was discussed at the Horizon mid-cycle. Since 
both of these have recordings, I wanted to share them both with you.

[Full Presentation (Travis)]

https://www.youtube.com/watch?v=ExzULavwvNQ

[Horizon Mid-Cycle Presentation (Matt and Tyr)]

https://www.youtube.com/watch?v=jr5iIs4zvbY

Thanks,
Travis

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


Re: [openstack-dev] [tripleo] CI jobs failures

2016-03-08 Thread Ben Nemec
On 03/08/2016 11:58 AM, Derek Higgins wrote:
> On 7 March 2016 at 18:22, Ben Nemec  wrote:
>> On 03/07/2016 11:33 AM, Derek Higgins wrote:
>>> On 7 March 2016 at 15:24, Derek Higgins  wrote:
 On 6 March 2016 at 16:58, James Slagle  wrote:
> On Sat, Mar 5, 2016 at 11:15 AM, Emilien Macchi  
> wrote:
>> I'm kind of hijacking Dan's e-mail but I would like to propose some
>> technical improvements to stop having so much CI failures.
>>
>>
>> 1/ Stop creating swap files. We don't have SSD, this is IMHO a terrible
>> mistake to swap on files because we don't have enough RAM. In my
>> experience, swaping on non-SSD disks is even worst that not having
>> enough RAM. We should stop doing that I think.
>
> We have been relying on swap in tripleo-ci for a little while. While
> not ideal, it has been an effective way to at least be able to test
> what we've been testing given the amount of physical RAM that is
> available.

 Ok, so I have a few points here, in places where I'm making
 assumptions I'll try to point it out

 o Yes I agree using swap should be avoided if at all possible

 o We are currently looking into adding more RAM to our testenv hosts,
 it which point we can afford to be a little more liberal with Memory
 and this problem should become less of an issue, having said that

 o Even though using swap is bad, if we have some processes with a
 large Mem footprint that don't require constant access to a portion of
 the footprint swaping it out over the duration of the CI test isn't as
 expensive as it would suggest (assuming it doesn't need to be swapped
 back in and the kernel has selected good candidates to swap out)

 o The test envs that host the undercloud and overcloud nodes have 64G
 of RAM each, they each host 4 testenvs and each test env if running a
 HA job can use up to 21G of RAM so we have over committed there, it
 this is only a problem if a test env host gets 4 HA jobs that are
 started around the same time (and as a result a each have 4 overcloud
 nodes running at the same time), to allow this to happen without VM's
 being killed by the OOM we've also enabled swap there. The majority of
 the time this swap isn't in use, only if all 4 testenvs are being
 simultaneously used and they are all running the second half of a CI
 test at the same time.

 o The overcloud nodes are VM's running with a "unsafe" disk caching
 mechanism, this causes sync requests from guest to be ignored and as a
 result if the instances being hosted on these nodes are going into
 swap this swap will be cached on the host as long as RAM is available.
 i.e. swap being used in the undercloud or overcloud isn't being synced
 to the disk on the host unless it has to be.

 o What I'd like us to avoid is simply bumping up the memory every time
 we hit a OOM error without at least
   1. Explaining why we need more memory all of a sudden
   2. Looking into a way we may be able to avoid simply bumping the RAM
 (at peak times we are memory constrained)

 as an example, Lets take a look at the swap usage on the undercloud of
 a recent ci nonha job[1][2], These insances have 5G of RAM with 2G or
 swap enabled via a swapfile
 the overcloud deploy started @22:07:46 and finished at @22:28:06

 In the graph you'll see a spike in memory being swapped out around
 22:09, this corresponds almost exactly to when the overcloud image is
 being downloaded from swift[3], looking the top output at the end of
 the test you'll see that swift-proxy is using over 500M of Mem[4].

 I'd much prefer we spend time looking into why the swift proxy is
 using this much memory rather then blindly bump the memory allocated
 to the VM, perhaps we have something configured incorrectly or we've
 hit a bug in swift.

 Having said all that we can bump the memory allocated to each node but
 we have to accept 1 of 2 possible consequences
 1. We'll env up using the swap on the testenv hosts more then we
 currently are or
 2. We'll have to reduce the number of test envs per host from 4 down
 to 3, wiping 25% of our capacity
>>>
>>> Thinking about this a little more, we could do a radical experiment
>>> for a week and just do this, i.e. bump up the RAM on each env and
>>> accept we loose 25 of our capacity, maybe it doesn't matter, if our
>>> success rate goes up then we'd be running less rechecks anyways.
>>> The downside is that we'd probably hit less timing errors (assuming
>>> the tight resources is whats showing them up), I say downside because
>>> this just means downstream users might hit them more often if CI
>>> isn't. Anyways maybe worth discussing at tomorrows meeting.

Re: [openstack-dev] [tripleo] CI jobs failures

2016-03-08 Thread Derek Higgins
On 7 March 2016 at 18:22, Ben Nemec  wrote:
> On 03/07/2016 11:33 AM, Derek Higgins wrote:
>> On 7 March 2016 at 15:24, Derek Higgins  wrote:
>>> On 6 March 2016 at 16:58, James Slagle  wrote:
 On Sat, Mar 5, 2016 at 11:15 AM, Emilien Macchi  wrote:
> I'm kind of hijacking Dan's e-mail but I would like to propose some
> technical improvements to stop having so much CI failures.
>
>
> 1/ Stop creating swap files. We don't have SSD, this is IMHO a terrible
> mistake to swap on files because we don't have enough RAM. In my
> experience, swaping on non-SSD disks is even worst that not having
> enough RAM. We should stop doing that I think.

 We have been relying on swap in tripleo-ci for a little while. While
 not ideal, it has been an effective way to at least be able to test
 what we've been testing given the amount of physical RAM that is
 available.
>>>
>>> Ok, so I have a few points here, in places where I'm making
>>> assumptions I'll try to point it out
>>>
>>> o Yes I agree using swap should be avoided if at all possible
>>>
>>> o We are currently looking into adding more RAM to our testenv hosts,
>>> it which point we can afford to be a little more liberal with Memory
>>> and this problem should become less of an issue, having said that
>>>
>>> o Even though using swap is bad, if we have some processes with a
>>> large Mem footprint that don't require constant access to a portion of
>>> the footprint swaping it out over the duration of the CI test isn't as
>>> expensive as it would suggest (assuming it doesn't need to be swapped
>>> back in and the kernel has selected good candidates to swap out)
>>>
>>> o The test envs that host the undercloud and overcloud nodes have 64G
>>> of RAM each, they each host 4 testenvs and each test env if running a
>>> HA job can use up to 21G of RAM so we have over committed there, it
>>> this is only a problem if a test env host gets 4 HA jobs that are
>>> started around the same time (and as a result a each have 4 overcloud
>>> nodes running at the same time), to allow this to happen without VM's
>>> being killed by the OOM we've also enabled swap there. The majority of
>>> the time this swap isn't in use, only if all 4 testenvs are being
>>> simultaneously used and they are all running the second half of a CI
>>> test at the same time.
>>>
>>> o The overcloud nodes are VM's running with a "unsafe" disk caching
>>> mechanism, this causes sync requests from guest to be ignored and as a
>>> result if the instances being hosted on these nodes are going into
>>> swap this swap will be cached on the host as long as RAM is available.
>>> i.e. swap being used in the undercloud or overcloud isn't being synced
>>> to the disk on the host unless it has to be.
>>>
>>> o What I'd like us to avoid is simply bumping up the memory every time
>>> we hit a OOM error without at least
>>>   1. Explaining why we need more memory all of a sudden
>>>   2. Looking into a way we may be able to avoid simply bumping the RAM
>>> (at peak times we are memory constrained)
>>>
>>> as an example, Lets take a look at the swap usage on the undercloud of
>>> a recent ci nonha job[1][2], These insances have 5G of RAM with 2G or
>>> swap enabled via a swapfile
>>> the overcloud deploy started @22:07:46 and finished at @22:28:06
>>>
>>> In the graph you'll see a spike in memory being swapped out around
>>> 22:09, this corresponds almost exactly to when the overcloud image is
>>> being downloaded from swift[3], looking the top output at the end of
>>> the test you'll see that swift-proxy is using over 500M of Mem[4].
>>>
>>> I'd much prefer we spend time looking into why the swift proxy is
>>> using this much memory rather then blindly bump the memory allocated
>>> to the VM, perhaps we have something configured incorrectly or we've
>>> hit a bug in swift.
>>>
>>> Having said all that we can bump the memory allocated to each node but
>>> we have to accept 1 of 2 possible consequences
>>> 1. We'll env up using the swap on the testenv hosts more then we
>>> currently are or
>>> 2. We'll have to reduce the number of test envs per host from 4 down
>>> to 3, wiping 25% of our capacity
>>
>> Thinking about this a little more, we could do a radical experiment
>> for a week and just do this, i.e. bump up the RAM on each env and
>> accept we loose 25 of our capacity, maybe it doesn't matter, if our
>> success rate goes up then we'd be running less rechecks anyways.
>> The downside is that we'd probably hit less timing errors (assuming
>> the tight resources is whats showing them up), I say downside because
>> this just means downstream users might hit them more often if CI
>> isn't. Anyways maybe worth discussing at tomorrows meeting.
>
> +1 to reducing the number of testenvs and allocating more memory to
> each.  The huge number of rechecks we're having to do is 

Re: [openstack-dev] [Neutron][LBaaS]Removing LBaaS v1 - are we ready?

2016-03-08 Thread Clint Byrum
Excerpts from Samuel Bercovici's message of 2016-03-02 07:06:30 -0800:
> 2.  HEAT Support - will it be ready in Mitaka?

Side note, please remember, Heat is not an acronym.

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


[openstack-dev] [oslo] oslo.messaging dispatching into private/protected methods?

2016-03-08 Thread Joshua Harlow

Hi all,

As I was working through https://review.openstack.org/#/c/288719/ for 
kevin benton to do some things with in neutron it came to my 
understanding that this code (the dispatcher code that is) can dispatch 
into nearly arbitrary callables of any object (or that is what it looks 
like it can do):


https://github.com/openstack/oslo.messaging/blob/4.5.0/oslo_messaging/rpc/dispatcher.py#L169

So during this exploration of this code for the above review it made me 
wonder if this is a feature or bug, or if we should at least close the 
hole of allowing calling into nearly any endpoint method/attribute (even 
non-callable ones to?).


So before doing much more of this (which I started in review 
https://review.openstack.org/#/c/289624/) I wanted to see if people are 
actually using this 'ability' (for lack of better words) to call into 
private/protected methods before pursuing 289624 much more...


Thoughts?

-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] [Neutron][LBaaS]Removing LBaaS v1 - are weready?

2016-03-08 Thread Fox, Kevin M
Does it work with DVR though? Probably would with Octavia since they are just 
vm's.

Thanks,
Kevin

From: Eichberger, German [german.eichber...@hpe.com]
Sent: Monday, March 07, 2016 4:11 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS]Removing LBaaS v1 - are weready?

Hi Kevin,

Floating IP will work in V2 as well :-)

Thanks,
German




On 3/7/16, 2:47 PM, "Fox, Kevin M"  wrote:

>You can attach a floating ip onto a vip. Thats what we've done to work around 
>the issue. Well, at least with v1. never tried it with v2.
>
>Thanks,
>Kevin
>
>From: Samuel Bercovici [samu...@radware.com]
>Sent: Monday, March 07, 2016 11:00 AM
>To: OpenStack Development Mailing List (not for usage questions)
>Subject: Re: [openstack-dev] [Neutron][LBaaS]Removing LBaaS v1 - are weready?
>
>As far as I recall, you can specify the VIP in creating the LB so you will end 
>up with same IPs.
>
>-Original Message-
>From: Eichberger, German [mailto:german.eichber...@hpe.com]
>Sent: Monday, March 07, 2016 8:30 PM
>To: OpenStack Development Mailing List (not for usage questions)
>Subject: Re: [openstack-dev] [Neutron][LBaaS]Removing LBaaS v1 - are weready?
>
>Hi Sam,
>
>So if you have some 3rd party hardware you only need to change the database 
>(your steps 1-5) since the 3rd party hardware will just keep load balancing…
>
>Now for Kevin’s case with the namespace driver:
>You would need a 6th step to reschedule the loadbalancers with the V2 
>namespace driver — which can be done.
>
>If we want to migrate to Octavia or (from one LB provider to another) it might 
>be better to use the following steps:
>
>1. Download LBaaS v1 information (Tenants, Flavors, VIPs, Pools, Health 
>Monitors , Members) into some JSON format file(s) 2. Delete LBaaS v1 3. 
>Uninstall LBaaS v1 4. Install LBaaS v2 5. Transform the JSON format file into 
>some scripts which recreate the load balancers with your provider of choice —
>
>6. Run those scripts
>
>The problem I see is that we will probably end up with different VIPs so the 
>end user would need to change their IPs…
>
>Thanks,
>German
>
>
>
>On 3/6/16, 5:35 AM, "Samuel Bercovici"  wrote:
>
>>As for a migration tool.
>>Due to model changes and deployment changes between LBaaS v1 and LBaaS v2, I 
>>am in favor for the following process:
>>
>>1. Download LBaaS v1 information (Tenants, Flavors, VIPs, Pools, Health
>>Monitors , Members) into some JSON format file(s) 2. Delete LBaaS v1 3.
>>Uninstall LBaaS v1 4. Install LBaaS v2 5. Import the data from 1 back
>>over LBaaS v2 (need to allow moving from falvor1-->flavor2, need to
>>make room to some custom modification for mapping between v1 and v2
>>models)
>>
>>What do you think?
>>
>>-Sam.
>>
>>
>>
>>
>>-Original Message-
>>From: Fox, Kevin M [mailto:kevin@pnnl.gov]
>>Sent: Friday, March 04, 2016 2:06 AM
>>To: OpenStack Development Mailing List (not for usage questions)
>>Subject: Re: [openstack-dev] [Neutron][LBaaS]Removing LBaaS v1 - are weready?
>>
>>Ok. Thanks for the info.
>>
>>Kevin
>>
>>From: Brandon Logan [brandon.lo...@rackspace.com]
>>Sent: Thursday, March 03, 2016 2:42 PM
>>To: openstack-dev@lists.openstack.org
>>Subject: Re: [openstack-dev] [Neutron][LBaaS]Removing LBaaS v1 - are weready?
>>
>>Just for clarity, V2 did not reuse tables, all the tables it uses are only 
>>for it.  The main problem is that v1 and v2 both have a pools resource, but 
>>v1 and v2's pool resource have different attributes.  With the way neutron 
>>wsgi works, if both v1 and v2 are enabled, it will combine both sets of 
>>attributes into the same validation schema.
>>
>>The other problem with v1 and v2 running together was only occurring when the 
>>v1 agent driver and v2 agent driver were both in use at the same time.  This 
>>may actually have been fixed with some agent updates in neutron, since that 
>>is common code.  It needs to be tested out though.
>>
>>Thanks,
>>Brandon
>>
>>On Thu, 2016-03-03 at 22:14 +, Fox, Kevin M wrote:
>>> Just because you had thought no one was using it outside of a PoC doesn't 
>>> mean folks aren''t using it in production.
>>>
>>> We would be happy to migrate to Octavia. We were planning on doing just 
>>> that by running both v1 with haproxy namespace, and v2 with Octavia and 
>>> then pick off upgrading lb's one at a time, but the reuse of the v1 tables 
>>> really was an unfortunate decision that blocked that activity.
>>>
>>> We're still trying to figure out a path forward.
>>>
>>> We have an outage window next month. after that, it could be about 6
>>> months before we could try a migration due to production load picking
>>> up for a while. I may just have to burn out all the lb's switch to
>>> v2, then rebuild them by hand in a marathon outage :/
>>>
>>> And then there's this thingy that 

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

2016-03-08 Thread Amrith Kumar
Matt,

As I just said in my earlier reply to you, Craig has been away for some time 
and I'll look into this.

I don't know that we need to revert the change or take the route you propose. 
There may be a much simpler solution. I'll propose a change for your review.

-amrith 

> -Original Message-
> From: Matt Riedemann [mailto:mrie...@linux.vnet.ibm.com]
> Sent: Tuesday, March 08, 2016 12:11 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 10:17 AM, Matt Riedemann wrote:
> > This is a call for help on resolving bug 1538506 [1] where the
> > proboscis tests randomly fail on the stable branches with something
> like:
> >
> > TypeError: create() got an unexpected keyword argument 'slave_of'
> >
> > Craig Vyvial has a proposed stable/kilo change [2] but it has some
> > issues, at least from me as a reviewer of that change.
> >
> > The tests are failing the periodic-stable job daily [3].
> >
> > Can we get someone to help out with this? Otherwise I'm inclined to
> > say the tests should be disabled on the stable branches, but that's
> > pretty drastic.
> >
> > Note that this is the kind of thing that breaks stable branch policy,
> > which is going to be part of a review when applying for the
> > stable:follows-policy tag. [4]  And the stable:follows-policy tag may
> > be used to determine when a stable branch for a project goes end of
> > life if it's not being maintained.
> >
> > [1] https://bugs.launchpad.net/trove/+bug/1538506
> > [2] https://review.openstack.org/#/c/276934/
> > [3] http://goo.gl/fqf11U
> > [4]
> > http://governance.openstack.org/reference/tags/stable_follows-policy.h
> > tml
> >
> 
> This is my solution for liberty, cap python-troveclient<2.1.0 in global-
> requirements on stable/liberty [1].
> 
> Then there is a change to trove on stable/liberty to use the g-r version
> range for python-troveclient for unit tests [2].
> 
> Alternatively, we could avoid the cap in stable/liberty by:
> 
> 1. Reverting https://review.openstack.org/#/c/245738/
> 2. Blacklisting python-troveclient 2.1.0 in g-r 3. Release python-
> troveclient 2.2.0.
> 
> It's getting late in the mitaka release to be messing with this though
> since we're already past client freeze.
> 
> [1] https://review.openstack.org/#/c/290021/
> [2] https://review.openstack.org/#/c/290023/
> 
> --
> 
> Thanks,
> 
> Matt Riedemann
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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


Re: [openstack-dev] [Heat] Dealing with nonexistent resources during resource-list / stack-delete

2016-03-08 Thread Zane Bitter

On 08/03/16 08:03, Johannes Grassler wrote:

Hello,

On 03/07/2016 04:48 PM, Zane Bitter wrote:

On 04/03/16 04:35, Johannes Grassler wrote:

[Uncaught client exceptions in resource plugins' add_dependencies()
methods]

Yes, you're right and this sucks. That's not the only problem we've
had in
this area recently - for example there was also:

https://bugs.launchpad.net/heat/+bug/1536515.

The fact that we have to have these hacked in implicit dependencies at
all is
terrible, but we really need to make sure they can't break basic
operations
like loading a stack from the DB so we can show or delete it. The
ideal would
be:

* We can guarantee to catch all (non-exit) exceptions, no matter what
kind of
crazy stuff people write in add_dependencies() * The plugin developer
doesn't
have to do anything special to get this behaviour


Just these two are a tall order already. One could have the client plugins
default to ignoring 404s (maybe by adding a `ignore_defaults` keyword
argument
to the client_plugin() method that defaults to True).

That will break third-party plugins that need to handle this exception
themselves for one reason or another. Are there such plugins, or could
there
conceivably be such plugins? I can't think of a likely scenario off the
top of
my head, but since I'm not familiar with any third party plugins that
may not
mean much.

Also, and probably more serious, it may require a potentially largish
number of
adaptations to core heat code in places where this behaviour is undesirable
(and that might in turn cause new bugs).


* The code remains backwards compatible with any third-party resource
plugins
circulating out there


...and that rules out handling the exception at a higher level (i.e.
whereever
add_dependencies() is called). Doing that creates a lot of possibilities
to end
up with a messy dependency graph.


* We always add as many dependencies as possible (i.e. all
non-exception-raising dependencies are added)


That pretty much means code in the add_dependcies() method, and the only
feasible way I see of influencing this code is finding a way to
selectively get
the client plugins to default to ignoring dependencies.


* Genuine dependency problems (e.g. non-existent target of
get_resource/get_attr) are still surfaced, preferably on CREATE only


Ignoring the 404s at a higher level may be feasible in the DELETE case,
but I'm
not sure how bad a problem a possibly incomplete dependency graph
creates for
stack-delete: is it a complete show stopper or just a matter of issuing
multiple stack-delete requests until all resources are gone?


I think you're being a little too pessimistic. I was going to explain 
one approach, but it turned out to be easier to just submit a patch:


https://review.openstack.org/290027

I believe this satisfies requirements 1, 2, and 4. I agree that there's 
no way we can really tackle 3 as far as third-party plugins go, but at 
least all explicit dependencies are guaranteed to be added. For the 
implicit ones, it's up to plugin authors not to screw it up.


BTW I created https://bugs.launchpad.net/heat/+bug/1554625 to cover this 
larger issue (as opposed to the specific problem you are fixing in bug 
1442121); that would probably be a good one to reference in your docs 
changes.


cheers,
Zane.

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

2016-03-08 Thread Matt Riedemann



On 3/8/2016 10:17 AM, Matt Riedemann wrote:

This is a call for help on resolving bug 1538506 [1] where the proboscis
tests randomly fail on the stable branches with something like:

TypeError: create() got an unexpected keyword argument 'slave_of'

Craig Vyvial has a proposed stable/kilo change [2] but it has some
issues, at least from me as a reviewer of that change.

The tests are failing the periodic-stable job daily [3].

Can we get someone to help out with this? Otherwise I'm inclined to say
the tests should be disabled on the stable branches, but that's pretty
drastic.

Note that this is the kind of thing that breaks stable branch policy,
which is going to be part of a review when applying for the
stable:follows-policy tag. [4]  And the stable:follows-policy tag may be
used to determine when a stable branch for a project goes end of life if
it's not being maintained.

[1] https://bugs.launchpad.net/trove/+bug/1538506
[2] https://review.openstack.org/#/c/276934/
[3] http://goo.gl/fqf11U
[4]
http://governance.openstack.org/reference/tags/stable_follows-policy.html



This is my solution for liberty, cap python-troveclient<2.1.0 in 
global-requirements on stable/liberty [1].


Then there is a change to trove on stable/liberty to use the g-r version 
range for python-troveclient for unit tests [2].


Alternatively, we could avoid the cap in stable/liberty by:

1. Reverting https://review.openstack.org/#/c/245738/
2. Blacklisting python-troveclient 2.1.0 in g-r
3. Release python-troveclient 2.2.0.

It's getting late in the mitaka release to be messing with this though 
since we're already past client freeze.


[1] https://review.openstack.org/#/c/290021/
[2] https://review.openstack.org/#/c/290023/

--

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] [keystone] Using multiple token formats in a one openstack cloud

2016-03-08 Thread Lance Bragstad
On Tue, Mar 8, 2016 at 10:58 AM, Adam Young  wrote:

> On 03/08/2016 11:06 AM, Matt Fischer wrote:
>
> This would be complicated to setup. How would the Openstack services
> validate the token? Which keystone node would they use? A better question
> is why would you want to do this?
>
> On Tue, Mar 8, 2016 at 8:45 AM, rezroo  wrote:
>
>> Keystone supports both tokens and ec2 credentials simultaneously, but as
>> far as I can tell, will only do a single token format (uuid, pki/z, fernet)
>> at a time. Is it possible or advisable to configure keystone to issue
>> multiple token formats? For example, I could configure two keystone
>> servers, each using a different token format, so depending on endpoint
>> used, I could get a uuid or pki token. Each service can use either token
>> format, so is there a conceptual or implementation issue with this setup?
>>
>
We do have token-less authentication built into keystone, which was
released in Liberty and might help with the service authentication case you
described [0]. Having a keystone node validate multiple token formats is
tough because it requires the token providers to know enough information
about other token formats to confidently say "yes, this is a PKI token" or
"no, this isn't a fernet token". Is the sole idea behind letting the client
pick the token format to get around the service authentication situation?
Is there another case you have that makes sense for a client to pick it's
token format?

[0]
https://github.com/openstack/keystone-specs/blob/master/specs/liberty/keystone-tokenless-authz-with-x509-ssl-client-cert.rst


> Thanks,
>> Reza
>>
>> __
>> OpenStack Development Mailing 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:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> Theoretically:
>
> Two different Keystone servers could independently issue different token
> formats.  They would need to share a common backend, so that they could all
> be verified online.  PKIZ  could be issued from multiple servers, each
> using different signing certs, so long as all the services got all the
> certs.
>
> Practically:
>
> You'd be insane to do this in production
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [keystone] Using multiple token formats in a one openstack cloud

2016-03-08 Thread Morgan Fainberg
This type of configuration is not supported as Matt highlighted. What
problem are you trying to solve with having the multiple token formats?
Before we discuss if it would be a good idea, we need to know what problem
you are solving.

On Tue, Mar 8, 2016 at 8:06 AM, Matt Fischer  wrote:

> This would be complicated to setup. How would the Openstack services
> validate the token? Which keystone node would they use? A better question
> is why would you want to do this?
>
> On Tue, Mar 8, 2016 at 8:45 AM, rezroo  wrote:
>
>> Keystone supports both tokens and ec2 credentials simultaneously, but as
>> far as I can tell, will only do a single token format (uuid, pki/z, fernet)
>> at a time. Is it possible or advisable to configure keystone to issue
>> multiple token formats? For example, I could configure two keystone
>> servers, each using a different token format, so depending on endpoint
>> used, I could get a uuid or pki token. Each service can use either token
>> format, so is there a conceptual or implementation issue with this setup?
>> Thanks,
>> Reza
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [keystone] Using multiple token formats in a one openstack cloud

2016-03-08 Thread Adam Young

On 03/08/2016 11:06 AM, Matt Fischer wrote:
This would be complicated to setup. How would the Openstack services 
validate the token? Which keystone node would they use? A better 
question is why would you want to do this?


On Tue, Mar 8, 2016 at 8:45 AM, rezroo > wrote:


Keystone supports both tokens and ec2 credentials simultaneously,
but as far as I can tell, will only do a single token format
(uuid, pki/z, fernet) at a time. Is it possible or advisable to
configure keystone to issue multiple token formats? For example, I
could configure two keystone servers, each using a different token
format, so depending on endpoint used, I could get a uuid or pki
token. Each service can use either token format, so is there a
conceptual or implementation issue with this setup?
Thanks,
Reza

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

Theoretically:

Two different Keystone servers could independently issue different token 
formats.  They would need to share a common backend, so that they could 
all be verified online.  PKIZ  could be issued from multiple servers, 
each using different signing certs, so long as all the services got all 
the certs.


Practically:

You'd be insane to do this in production
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [keystone] Using multiple token formats in a one openstack cloud

2016-03-08 Thread rezroo
The basic idea is to let the openstack clients decide what sort of token 
optimization to use - for example, while a normal client uses uuid 
tokens, some services like heat or magnum may opt for pki tokens for 
their operations. A service like nova, configured for PKI will validate 
that token without going to any keystone server, but if it gets a uuid 
token then validates it with a keystone endpoint. I'm under the 
impression that the different token formats have different use-cases, so 
am wondering if there is a conceptual reason why multiple token formats 
are an either/or scenario.


On 3/8/2016 8:06 AM, Matt Fischer wrote:
This would be complicated to setup. How would the Openstack services 
validate the token? Which keystone node would they use? A better 
question is why would you want to do this?


On Tue, Mar 8, 2016 at 8:45 AM, rezroo > wrote:


Keystone supports both tokens and ec2 credentials simultaneously,
but as far as I can tell, will only do a single token format
(uuid, pki/z, fernet) at a time. Is it possible or advisable to
configure keystone to issue multiple token formats? For example, I
could configure two keystone servers, each using a different token
format, so depending on endpoint used, I could get a uuid or pki
token. Each service can use either token format, so is there a
conceptual or implementation issue with this setup?
Thanks,
Reza

__
OpenStack Development Mailing 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] [Heat] Dealing with nonexistent resources during resource-list / stack-delete

2016-03-08 Thread Johannes Grassler

Hello,

On 03/08/2016 04:57 PM, Zane Bitter wrote:

On 08/03/16 10:40, Johannes Grassler wrote:

On 03/07/2016 04:48 PM, Zane Bitter wrote:

On 04/03/16 04:35, Johannes Grassler wrote:

[Uncaught client exceptions in resource plugins' add_dependencies()
methods]

In the meantime, we need to find and squash every instance of this
problem
wherever we can like you said.


It might also be a good idea to caution against unchecked API client
invocations in

http://docs.openstack.org/developer/heat/developing_guides/pluginguide.html

[...]


It's best if they *do* omit it entirely. The only reason we override it in
the Neutron resources is that the Neutron API is terrible for orchestration
purposes[1]. It adds a bunch of invisible, fragile magic that breaks in
subtle ways when e.g. resources are moved into nested stacks.


I never saw the Neutron API that way before (I guess I just got used to the
unintuitive bits), but seeing it spelled out in your rant makes it very
obvious, yes. I didn't know that was the root cause for overriding
add_dependencies() and that very ignorance of mine...


The default implementation provides everything that we *ought* to need, so if
we document anything I think it should be that plugin developers should not
touch add_dependencies() at all.


...suggests mentioning that much is probably a good idea (lest somebody pick
one of the Neutron plugins as a template to base their own resource plugin
on).


Definitely not big enough to require a spec IMO.


Yes, I can see that, given how it's not something plugin writers should do
anyway. Then I'll just write a little paragraph cautioning against overriding
add_dependcies() and add a Related-Bug: line.

Cheers,

Johannes

--
Johannes Grassler, Cloud Developer
SUSE Linux GmbH, HRB 21284 (AG Nürnberg)
GF: Felix Imendörffer, Jane Smithard, Graham Norton
Maxfeldstr. 5, 90409 Nürnberg, Germany

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


Re: [openstack-dev] [Congress] Issue with glancev2 datasource driver

2016-03-08 Thread Bryan Sullivan
Hi Masahito,
The debug log is attached.
Thanks,
Bryan Sullivan

> From: muroi.masah...@lab.ntt.co.jp
> Date: Wed, 24 Feb 2016 10:41:17 +0900
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [Congress] Issue with glancev2 datasource driver
> 
> Hi Bryan,
> 
> Could you show me debug log of the command using following command? When 
> I check the command in my stable/liberty, it works well.
> 
> $ openstack congress datasource row list glancev2 images --debug
> 
> And if the setting for the driver is valid, it would show you logs about 
> glance driver pulling image list from glance itself.
> 
> On 2016/02/24 6:01, Bryan Sullivan wrote:
> > I’m running into an issue with the rows provided by the glancev2 driver
> > for congress. There are images defined in glance (see below) but no rows
> > are being returned by congress. Any idea why this might be happening?
> >
> > Below I query Openstack directly, then try to get the same data thru
> > congress. I am using the stable/liberty branch, installed yesterday.
> > This is on the OPNFV Brahmaputra release (not devstack), and most other
> > congress datasources and functions are working as expected.
> >
> > Thanks for your help!
> >
> > Bryan Sullivan | AT
> >
> > opnfv@jumphost:~/git/python-congressclient$ openstack image list
> >
> > +--+-+
> >
> > | ID | Name |
> >
> > +--+-+
> >
> > | 98705491-edda-4645-a413-129502190d56 | cirros-0.3.3-x86_64-dmz |
> >
> > | 59cf60e8-e0ce-48b1-b081-6325c1e1c52b | cirros-0.3.3-x86_64 |
> >
> > +--+-+
> >
> > opnfv@jumphost:~/git/python-congressclient$ openstack congress
> > datasource row list glancev2 images
> >
> > opnfv@jumphost:~/git/python-congressclient$
> >
> >
> >
> > __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> 
> 
> -- 
> 室井 雅仁(Masahito MUROI)
> Software Innovation Center, NTT
> Tel: +81-422-59-4539
> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
  opnfv@jumphost:~/git/copper$ openstack congress datasource row list glancev2 
images --d
START with options: ['congress', 'datasource', 'row', 'list', 'glancev2', 
'images', '--d']
options: Namespace(access_token_endpoint='', auth_type='', 
auth_url='http://192.168.10.108:5000/v2.0', cacert='', client_id='', 
client_secret='', cloud='', debug=True, default_domain='default', 
deferred_help=False, domain_id='', domain_name='', endpoint='', 
identity_provider='', identity_provider_url='', insecure=None, interface='', 
log_file=None, os_compute_api_version='', os_identity_api_version='', 
os_image_api_version='', os_network_api_version='', os_object_api_version='', 
os_policy_api_version='1', os_project_id=None, os_project_name=None, 
os_volume_api_version='', password='openstack', project_domain_id='', 
project_domain_name='', project_id='700783aaf5084b1eae33e7ee0eb547cf', 
project_name='admin', protocol='', region_name='Canonical', scope='', 
service_provider_endpoint='', timing=False, token='', trust_id='', url='', 
user_domain_id='', user_domain_name='', user_id='', username='admin', 
verbose_level=3, verify=None)
defaults: {'auth_type': 'password', 'compute_api_version': '2', 
'database_api_version': '1.0', 'api_timeout': None, 'baremetal_api_version': 
'1', 'cacert': None, 'image_api_use_tasks': False, 'floating_ip_source': 
'neutron', 'key': None, 'interface': None, 'network_api_version': '2', 
'image_format': 'qcow2', 'object_api_version': '1', 'image_api_version': '1', 
'verify': True, 'identity_api_version': '2', 'volume_api_version': '1', 'cert': 
None, 'secgroup_source': 'neutron', 'dns_api_version': '2', 
'disable_vendor_agent': {}}
cloud cfg: {'auth_type': 'password', 'compute_api_version': '2', 
'database_api_version': '1.0', 'interface': None, 'policy_api_version': '1', 
'network_api_version': '2', 'image_format': 'qcow2', 'object_api_version': '1', 
'image_api_version': '1', 'verify': True, 'timing': False, 'dns_api_version': 
'2', 'verbose_level': 3, 'region_name': 'Canonical', 'api_timeout': None, 
'baremetal_api_version': '1', 'auth': {'username': 'admin', 'project_name': 
'admin', 'tenant_id': '700783aaf5084b1eae33e7ee0eb547cf', 'project_id': 
'700783aaf5084b1eae33e7ee0eb547cf', 'auth_url': 
'http://192.168.10.108:5000/v2.0', 'tenant_name': 'admin', 'password': 
'openstack'}, 'default_domain': 'default', 'image_api_use_tasks': 

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

2016-03-08 Thread Matt Riedemann
This is a call for help on resolving bug 1538506 [1] where the proboscis 
tests randomly fail on the stable branches with something like:


TypeError: create() got an unexpected keyword argument 'slave_of'

Craig Vyvial has a proposed stable/kilo change [2] but it has some 
issues, at least from me as a reviewer of that change.


The tests are failing the periodic-stable job daily [3].

Can we get someone to help out with this? Otherwise I'm inclined to say 
the tests should be disabled on the stable branches, but that's pretty 
drastic.


Note that this is the kind of thing that breaks stable branch policy, 
which is going to be part of a review when applying for the 
stable:follows-policy tag. [4]  And the stable:follows-policy tag may be 
used to determine when a stable branch for a project goes end of life if 
it's not being maintained.


[1] https://bugs.launchpad.net/trove/+bug/1538506
[2] https://review.openstack.org/#/c/276934/
[3] http://goo.gl/fqf11U
[4] 
http://governance.openstack.org/reference/tags/stable_follows-policy.html


--

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] [keystone] Using multiple token formats in a one openstack cloud

2016-03-08 Thread Matt Fischer
This would be complicated to setup. How would the Openstack services
validate the token? Which keystone node would they use? A better question
is why would you want to do this?

On Tue, Mar 8, 2016 at 8:45 AM, rezroo  wrote:

> Keystone supports both tokens and ec2 credentials simultaneously, but as
> far as I can tell, will only do a single token format (uuid, pki/z, fernet)
> at a time. Is it possible or advisable to configure keystone to issue
> multiple token formats? For example, I could configure two keystone
> servers, each using a different token format, so depending on endpoint
> used, I could get a uuid or pki token. Each service can use either token
> format, so is there a conceptual or implementation issue with this setup?
> Thanks,
> Reza
>
> __
> OpenStack Development Mailing 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] Dealing with nonexistent resources during resource-list / stack-delete

2016-03-08 Thread Zane Bitter

On 08/03/16 10:40, Johannes Grassler wrote:

Hello,

On 03/07/2016 04:48 PM, Zane Bitter wrote:

On 04/03/16 04:35, Johannes Grassler wrote:

[Uncaught client exceptions in resource plugins' add_dependencies()
methods]

In the meantime, we need to find and squash every instance of this
problem
wherever we can like you said.


It might also be a good idea to caution against unchecked API client
invocations in

http://docs.openstack.org/developer/heat/developing_guides/pluginguide.html

until a real fix for the problem is in place. Also, that document does
not even
mention the add_dependencies() method, leaving plugin developers that
much more
room to come up with dodgy code that does weird stuff in
add_dependencies() or
even omits it entirely.


It's best if they *do* omit it entirely. The only reason we override it 
in the Neutron resources is that the Neutron API is terrible for 
orchestration purposes[1]. It adds a bunch of invisible, fragile magic 
that breaks in subtle ways when e.g. resources are moved into nested 
stacks. The default implementation provides everything that we *ought* 
to need, so if we document anything I think it should be that plugin 
developers should not touch add_dependencies() at all.


If they must, though, then the relevant guidelines should be to ensure 
that any exceptions raised:


1) are deterministic; and
2) should prevent the stack from being created.


[1] Obligatory rant: 
http://lists.openstack.org/pipermail/openstack-dev/2014-April/032098.html



I haven't written any plugins so far, but I
suppose I
could update that part of the documentation - I've become rather
familiar this part of the code while fixing
.

If I wanted to add a section on add_dependencies() and its pitfalls to
pluginguide.rst, how would I go about it? Just submit a change with a
"Partial-Bug: #1442121" or is that big enough to require a spec?


Definitely not big enough to require a spec IMO.

cheers,
Zane.


__
OpenStack Development Mailing List (not for 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] [api] Reminder: WSME is not being actively maintained

2016-03-08 Thread Doug Hellmann
Excerpts from Chris Dent's message of 2016-03-08 11:25:48 +:
> 
> Last summer Lucas Gomes and I were press ganged into becoming core on
> WSME. Since then we've piecemeal been verifying bug fixes and generally
> trying to keep things moving. However, from the beginning we both agreed
> that WSME is _not_ a web framework that we should be encouraging. Though
> it looks like it started with very good intentions, it never really
> reached a state where any of the following are true:
> 
> * The WSME code is easy to understand and maintain.
> * WSME provides correct handling of HTTP (notably response status
>and headers).
> * WSME has an architecture that is suitable for creating modern
>Python-based web applications.
> 
> Last summer we naively suggested that projects that are using it move to
> using something else. That suggestion did not take into account the
> realities of OpenStack.
> 
> So we need to come up with a new plan. Lucas and I can continue to
> merge bug fixes as people provide them (and we become aware of them) and
> we can continue to hassle Doug Hellman to make a release when one is
> necessary but this does little to address the three gaps above nor the
> continued use of the framework in existing projects.
> 
> Ideas?

One big reason for choosing WSME early on was that it had support
for both XML and JSON APIs without the application code needing to
do anything explicitly. In the time since projects started using
WSME, the community has decided to stop providing XML API support
and some other tools have been picked up (JSONSchema, Voluptuous,
etc.) that provide parsing and validation features similar to WSME.
It seems natural that we build new APIs using those tools instead
of WSME. For existing functioning API endpoints, we can leave them
alone (using WSME) or change them one at a time as they are extended
with new features. I don't see any reason to rewrite anything just
to change tools.

Doug

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


[openstack-dev] Interface detach results in incorrect DHCP6 functioning on higher-index interfaces

2016-03-08 Thread Andrei Radulescu-Banu
I'm using the latest Devstack installed as a standalone, and testing the 
interface detach functionality through the Horizon GUI. In my case, I have a 
special Linux image with DHCP and DHCPv6 enabled on all interfaces. Here is my 
config:
- Two separate subnets, 'private', with DHCP enabled, and 'private6', with 
DHCP6 enabled
- Interface eth0 on 'private', eth1 on 'private6', eth2 on 'private' and eth3 
again on 'private6'
- Initially, eth0 and eth2 acquire a DHCP address; eth1 and eth3 a DHCP6 
address. Note their MAC addresses in the display.

[stack@paradise devstack]$ neutron net-show private
+-+--+
| Field   | Value|
+-+--+
| admin_state_up  | True |
| availability_zone_hints |  |
| availability_zones  | nova |
| id  | e63dc15c-bc65-41ef-8aaf-ca047d8f208c |
| ipv4_address_scope  |  |
| ipv6_address_scope  |  |
| mtu | 1450 |
| name| private  |
| port_security_enabled   | True |
| router:external | False|
| shared  | False|
| status  | ACTIVE   |
| subnets | 9b3df9c8-6de9-4373-a567-6b59b5312d8a |
| tenant_id   | 2876a2eb470b4ff1a8a04c960820f317 |
+-+--+
[stack@paradise devstack]$ neutron net-show private6
+-+--+
| Field   | Value|
+-+--+
| admin_state_up  | True |
| availability_zone_hints |  |
| availability_zones  | nova |
| id  | 67e7aa17-50e3-436a-99c9-1618683d2983 |
| ipv4_address_scope  |  |
| ipv6_address_scope  |  |
| mtu | 1450 |
| name| private6 |
| port_security_enabled   | True |
| router:external | False|
| shared  | False|
| status  | ACTIVE   |
| subnets | a6e39a5b-7153-481c-acd0-72ac26bb6288 |
| tenant_id   | 2876a2eb470b4ff1a8a04c960820f317 |
+-+--+
[stack@paradise devstack]$ neutron subnet-show private-subnet
+---++
| Field | Value  |
+---++
| allocation_pools  | {"start": "10.1.0.2", "end": "10.1.0.254"} |
| cidr  | 10.1.0.0/24|
| dns_nameservers   ||
| enable_dhcp   | True   |
| gateway_ip| 10.1.0.1   |
| host_routes   ||
| id| 9b3df9c8-6de9-4373-a567-6b59b5312d8a   |
| ip_version| 4  |
| ipv6_address_mode ||
| ipv6_ra_mode  ||
| name  | private-subnet |
| network_id| e63dc15c-bc65-41ef-8aaf-ca047d8f208c   |
| subnetpool_id ||
| tenant_id | 2876a2eb470b4ff1a8a04c960820f317   |
+---++
[stack@paradise devstack]$ neutron subnet-show private-subnet6
+---+--+
| Field | Value|
+---+--+
| allocation_pools  | {"start": "1:2:3:4::100", "end": "1:2:3:4::200"} |
| cidr  | 1:2:3:4::/64 |
| dns_nameservers   | 1:2:3:4::2   |
| enable_dhcp   | True |
| gateway_ip| 1:2:3:4::1   |
| 

Re: [openstack-dev] [Heat] Dealing with nonexistent resources during resource-list / stack-delete

2016-03-08 Thread Johannes Grassler

Hello,

On 03/07/2016 04:48 PM, Zane Bitter wrote:

On 04/03/16 04:35, Johannes Grassler wrote:

[Uncaught client exceptions in resource plugins' add_dependencies() methods]

In the meantime, we need to find and squash every instance of this problem
wherever we can like you said.


It might also be a good idea to caution against unchecked API client
invocations in

http://docs.openstack.org/developer/heat/developing_guides/pluginguide.html

until a real fix for the problem is in place. Also, that document does not even
mention the add_dependencies() method, leaving plugin developers that much more
room to come up with dodgy code that does weird stuff in add_dependencies() or
even omits it entirely. I haven't written any plugins so far, but I suppose I
could update that part of the documentation - I've become rather familiar this part 
of the code while fixing .

If I wanted to add a section on add_dependencies() and its pitfalls to
pluginguide.rst, how would I go about it? Just submit a change with a
"Partial-Bug: #1442121" or is that big enough to require a spec?

Cheers,

Johannes

--
Johannes Grassler, Cloud Developer
SUSE Linux GmbH, HRB 21284 (AG Nürnberg)
GF: Felix Imendörffer, Jane Smithard, Graham Norton
Maxfeldstr. 5, 90409 Nürnberg, Germany

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


[openstack-dev] [keystone] Using multiple token formats in a one openstack cloud

2016-03-08 Thread rezroo
Keystone supports both tokens and ec2 credentials simultaneously, but as 
far as I can tell, will only do a single token format (uuid, pki/z, 
fernet) at a time. Is it possible or advisable to configure keystone to 
issue multiple token formats? For example, I could configure two 
keystone servers, each using a different token format, so depending on 
endpoint used, I could get a uuid or pki token. Each service can use 
either token format, so is there a conceptual or implementation issue 
with this setup?

Thanks,
Reza

__
OpenStack Development Mailing List (not for 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][vote] exception for backporting upgrades to liberty/stable

2016-03-08 Thread Jeff Peeler
On Mon, Mar 7, 2016 at 11:00 AM, Sam Yaple  wrote:
>
> Obviously I am +1 on committing to a stable _stable_ branch. And that has
> always required Z upgrades. Luckily the work we did in master is also usable
> for z upgrades. Without the ability to perform an update after a
> vulnerability, we have to stable branch.

Assuming Sam meant "we have no stable branch" above, I think this is
crux of the matter. If we follow the purist developer philosophy
behind a stable branch, then maybe upgrades wouldn't be backported.
But if operators then can't count on using Liberty at that point, what
does it matter?

In the future I'm sure we can follow strict "developer level"
adherence to backports for Mitaka. So if it's not clear, +1 to
including this in 1.1.0.

> I would remind every one we _did_ have this conversation in Tokyo when we
> discussed pinning to stable versions of other projects rather than using
> head of thier stable branch. We currently do that and there is a review for
> a tool to make that even easier to maintain [1]. There was even talk of a
> bot to purpose these bumps in versions. That means z upgrades were expected
> for Liberty. Anyone thinking otherwise has a short memory.
>
> [1] https://review.openstack.org/#/c/248481/

This review has been merged now.

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


Re: [openstack-dev] [puppet] weekly meeting #73

2016-03-08 Thread Emilien Macchi
Hi,

We did our meeting, you can read the notes:
http://eavesdrop.openstack.org/meetings/puppet_openstack/2016/puppet_openstack.2016-03-08-15.00.html

Thanks,

On Mon, Mar 7, 2016 at 9:26 AM, Emilien Macchi <emil...@redhat.com> wrote:

> Hi,
>
> We'll have our weekly meeting tomorrow at 3pm UTC on
> #openstack-meeting4.
>
> https://wiki.openstack.org/wiki/Meetings/PuppetOpenStack
>
> As usual, free free to bring topics in this etherpad:
> https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20160308
>
> We'll also have open discussion for bugs & reviews, so anyone is welcome
> to join.
>
> See you there,
> --
> Emilien Macchi
>
>


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


[openstack-dev] [neutron] Last chance to finish changes affecting DB schema for Mitaka

2016-03-08 Thread Henry Gessau
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

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


Re: [openstack-dev] [keystone] Single Sign On integration research

2016-03-08 Thread Steve Martinelli

Looks great! I only have one suggestion for the ECP blog. We actually have
keystoneauth plugins for ECP [1]. Instead of issuing a request in your
example, you may be able to just use the federated auth plugin.

[1]
https://github.com/openstack/keystoneauth/blob/35cad4a2ef00339eb31d80458bafaada41a5d8ce/keystoneauth1/extras/_saml2/v3/saml2.py

stevemar



From:   Adam Heczko 
To: "OpenStack Development Mailing List (not for usage questions)"

Date:   2016/03/08 03:38 PM
Subject:Re: [openstack-dev] [keystone] Single Sign On integration
research



Good job Kseniya :)

A.

On Tue, Mar 8, 2016 at 3:21 PM, Jay Pipes  wrote:
  Awesome blogs, Kseniya, thank you for sharing this! :)
  -jay

  On 03/08/2016 09:12 AM, Kseniya Tychkova wrote:
   Hi,
   as you may know currently Keystone supports Single Sign-On (SSO) and as
   I think it is one of the most interesting features in Keystone.
   I've done research on Single Sign-On in Keystone. Practically I just
   tried to set up Keystone in 2 different configuration.
   As a result of my research I have 2 blog posts and I would like to share
   links with you:

   *1. Keystone Service Provider with Shibboleth Identity Provider (WebSSO
   profile)
   <
   http://xuctarine.blogspot.ru/2016/02/keystone-service-provider-with.html
   >*:
   <
   http://xuctarine.blogspot.ru/2016/02/keystone-service-provider-with.html
   >
   (
   http://xuctarine.blogspot.ru/2016/02/keystone-service-provider-with.html
   )
   Post describes how to step-by-step deploy Shibboleth Identity Provider
   with Keystone Service Provider.
   This configuration is interesting because you can easily replace
   Shibboleth Identity Provider
   with any other Identity Provider with SAML support.
   So it is, I think, most popular use case for SSO in Keystone.

   *2. How to setup Keystone with Shibboleth (ECP profile):
   <
   
http://xuctarine.blogspot.ru/2016/02/how-to-setup-keystone-with-shibboleth.html
   >
   *(
   
http://xuctarine.blogspot.ru/2016/02/how-to-setup-keystone-with-shibboleth.html

   )
   Post describes how to deploy Keystone Identity Provider with Keystone
   Service Provider.
   It is Keystone-to-Keystone configuration and it uses ECP profile
   (Enhanced Client or Proxy) of SAML Protocol.
   A lot of information for this post I took from rodrigods blog
   (
   
http://blog.rodrigods.com/it-is-time-to-play-with-keystone-to-keystone-federation-in-kilo
   ).

   I hope my posts will help you to deploy/configure SSO or at least will
   be interesting to take a look at SSO feature in Keystone.

   Kind regards, Kseniya


   __

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



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


__
OpenStack Development Mailing List (not for 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] Identifying Mitaka release blockers

2016-03-08 Thread John Garbutt
On 3 March 2016 at 13:10, Markus Zoeller  wrote:
> We have now 11-15 days left [1] until it is planned to release the first
> release candidate. To provide a stable release, we need to identify the
> potential release blockers. Bugs which potentially block the release
> should be tagged with "mitaka-rc-potential". They can then be queried in
> Launchpad with [2].
>
> Agreed on blockers will get the "mitaka-rc1" milestone in Launchpad and
> are queryable with [3]. Because the next Nova meeting at March 10th
> could be to close to RC1 to decide actionable items, bring those
> potentials to the attention on the ML or in #openstack-nova.
>
> Open patches for blocker bugs can be queried with the script
> "query_rc_blockers.py" from [4]. The tags will be kept on the bug reports
> in case we will release additional RCs.
>
> When the final release is done we can remove the "mitaka-rc-potential"
> tag from the open bug reports. Probably it makes sense to increase their
> importance to "high" after that to put some focus on them for the
> Newton cycle. Open patches for high|critical bugs can be queried with
> "query_high_prio_bug_fixes.py" from [4].
>
> I recommend to the subteams to go through the bug reports of their area
> and double-check them if there are blockers. Please also spent some
> effort to go through the list of "new" bug reports [5]. There weren't
> enough volunteers for the bug skimming duty in the last months to get
> this list to zero.
>
> References:
> [1] http://releases.openstack.org/mitaka/schedule.html#m-rc1
> [2] https://bugs.launchpad.net/nova/+bugs?field.tag=mitaka-rc-potential
> [3] https://launchpad.net/nova/+milestone/mitaka-rc1
> [4]
> https://github.com/markuszoeller/openstack/tree/master/scripts/launchpad
> [5] https://bugs.launchpad.net/nova/+bugs?search=Search=New

Point of clarification...

In nova we are only using "mitaka-rc-potential" to track possible bugs
might block/delay RC1. You are not required to add this tag before
merging a bug fix.

Having said that, the normal rules apply for this point in the cycle.
Reviewers should reject patches that are likely to damage the quality
of the release, due to a big regression risk, breaking the soft string
freeze, etc.

As always, any questions, please ask,
johnthetubaguy

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


Re: [openstack-dev] [keystone] Single Sign On integration research

2016-03-08 Thread Adam Heczko
Good job Kseniya :)

A.

On Tue, Mar 8, 2016 at 3:21 PM, Jay Pipes  wrote:

> Awesome blogs, Kseniya, thank you for sharing this! :)
> -jay
>
> On 03/08/2016 09:12 AM, Kseniya Tychkova wrote:
>
>> Hi,
>> as you may know currently Keystone supports Single Sign-On (SSO) and as
>> I think it is one of the most interesting features in Keystone.
>> I've done research on Single Sign-On in Keystone. Practically I just
>> tried to set up Keystone in 2 different configuration.
>> As a result of my research I have 2 blog posts and I would like to share
>> links with you:
>>
>> *1. Keystone Service Provider with Shibboleth Identity Provider (WebSSO
>> profile)
>> > >*:
>> > >
>> (
>> http://xuctarine.blogspot.ru/2016/02/keystone-service-provider-with.html
>> )
>> Post describes how to step-by-step deploy Shibboleth Identity Provider
>> with Keystone Service Provider.
>> This configuration is interesting because you can easily replace
>> Shibboleth Identity Provider
>> with any other Identity Provider with SAML support.
>> So it is, I think, most popular use case for SSO in Keystone.
>>
>> *2. How to setup Keystone with Shibboleth (ECP profile):
>> <
>> http://xuctarine.blogspot.ru/2016/02/how-to-setup-keystone-with-shibboleth.html
>> >
>> *(
>>
>> http://xuctarine.blogspot.ru/2016/02/how-to-setup-keystone-with-shibboleth.html
>> )
>> Post describes how to deploy Keystone Identity Provider with Keystone
>> Service Provider.
>> It is Keystone-to-Keystone configuration and it uses ECP profile
>> (Enhanced Client or Proxy) of SAML Protocol.
>> A lot of information for this post I took from rodrigods blog
>> (
>> http://blog.rodrigods.com/it-is-time-to-play-with-keystone-to-keystone-federation-in-kilo
>> ).
>>
>> I hope my posts will help you to deploy/configure SSO or at least will
>> be interesting to take a look at SSO feature in Keystone.
>>
>> Kind regards, Kseniya
>>
>>
>> __
>> OpenStack Development Mailing 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
>



-- 
Adam Heczko
Security 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] [keystone] Single Sign On integration research

2016-03-08 Thread Jay Pipes

Awesome blogs, Kseniya, thank you for sharing this! :)
-jay

On 03/08/2016 09:12 AM, Kseniya Tychkova wrote:

Hi,
as you may know currently Keystone supports Single Sign-On (SSO) and as
I think it is one of the most interesting features in Keystone.
I've done research on Single Sign-On in Keystone. Practically I just
tried to set up Keystone in 2 different configuration.
As a result of my research I have 2 blog posts and I would like to share
links with you:

*1. Keystone Service Provider with Shibboleth Identity Provider (WebSSO
profile)
*:

( http://xuctarine.blogspot.ru/2016/02/keystone-service-provider-with.html )
Post describes how to step-by-step deploy Shibboleth Identity Provider
with Keystone Service Provider.
This configuration is interesting because you can easily replace
Shibboleth Identity Provider
with any other Identity Provider with SAML support.
So it is, I think, most popular use case for SSO in Keystone.

*2. How to setup Keystone with Shibboleth (ECP profile):

*(
http://xuctarine.blogspot.ru/2016/02/how-to-setup-keystone-with-shibboleth.html
)
Post describes how to deploy Keystone Identity Provider with Keystone
Service Provider.
It is Keystone-to-Keystone configuration and it uses ECP profile
(Enhanced Client or Proxy) of SAML Protocol.
A lot of information for this post I took from rodrigods blog
(http://blog.rodrigods.com/it-is-time-to-play-with-keystone-to-keystone-federation-in-kilo).

I hope my posts will help you to deploy/configure SSO or at least will
be interesting to take a look at SSO feature in Keystone.

Kind regards, Kseniya


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



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


Re: [openstack-dev] [Kolla] DocImpact in reviews

2016-03-08 Thread Steven Dake (stdake)
I don't think we can really expect new contributors to understand all the magic 
flags.  This isn't a typical problem - typically DocImpact is used correctly.  
But it is the responsibility of the core reviewers to make sure that new 
contributors aren't needlessly wasting time by triggering triages of 
incorrectly used flags.

Regards
-steve

From: "Vikram Hosakote (vhosakot)" 
>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Monday, March 7, 2016 at 8:04 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Subject: Re: [openstack-dev] [Kolla] DocImpact in reviews

Good point.  I think this should be caught during code review.

Regards,
Vikram Hosakote
IRC: vhosakot

From: Swapnil Kulkarni >
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Monday, March 7, 2016 at 1:40 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Subject: [openstack-dev] [Kolla] DocImpact in reviews

Hello,

I was triaging some of the bugs reported to Kolla and I found a couple
of bugs [1] [2] created due to incorrect usage of DocImpact[1] tag in
reviews. The DocImapct tag should only be used in case if you have
done some change which requires following two,

1) Update in some existing documentation
2) Add some new documentation

which are not addressed in the current changeset where you are adding
the DocImapct.


[1] https://wiki.openstack.org/wiki/Documentation/DocImpact
[2] https://bugs.launchpad.net/kolla/+bug/1553291
[3] https://bugs.launchpad.net/kolla/+bug/1553405

Best Regards,
Swapnil Kulkarni
irc : coolsvap

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

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


[openstack-dev] [keystone] Single Sign On integration research

2016-03-08 Thread Kseniya Tychkova
Hi,
as you may know currently Keystone supports Single Sign-On (SSO) and as I
think it is one of the most interesting features in Keystone.
I've done research on Single Sign-On in Keystone. Practically I just tried
to set up Keystone in 2 different configuration.
As a result of my research I have 2 blog posts and I would like to share
links with you:

*1. Keystone Service Provider with Shibboleth Identity Provider (WebSSO
profile)
*:

( http://xuctarine.blogspot.ru/2016/02/keystone-service-provider-with.html )
Post describes how to step-by-step deploy Shibboleth Identity Provider with
Keystone Service Provider.
This configuration is interesting because you can easily replace Shibboleth
Identity Provider
with any other Identity Provider with SAML support.
So it is, I think, most popular use case for SSO in Keystone.


*2. How to setup Keystone with Shibboleth (ECP profile):
*(
http://xuctarine.blogspot.ru/2016/02/how-to-setup-keystone-with-shibboleth.html
)
Post describes how to deploy Keystone Identity Provider with Keystone
Service Provider.
It is Keystone-to-Keystone configuration and it uses ECP profile (Enhanced
Client or Proxy) of SAML Protocol.
A lot of information for this post I took from rodrigods blog (
http://blog.rodrigods.com/it-is-time-to-play-with-keystone-to-keystone-federation-in-kilo
).

I hope my posts will help you to deploy/configure SSO or at least will be
interesting to take a look at SSO feature in Keystone.

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


Re: [openstack-dev] [nova] How to fix the wrong usage of 'format' jsonschema keyword in server create API

2016-03-08 Thread Alex Xu
2016-03-07 21:10 GMT+08:00 Jay Pipes :

> On 03/07/2016 08:05 AM, Alex Xu wrote:
>
>> 2016-03-07 19:23 GMT+08:00 Sean Dague > >:
>>
>> On 03/07/2016 01:18 AM, Alex Xu wrote:
>> > Hi,
>> >
>> > Due to this regression bughttps://launchpad.net/bugs/1552888,
>> found we
>>
>> > are using 'formart' jsonschema keyword in wrong way. The 'format'
>> is not
>> > only for string instance, but all the types.
>>
>> Can you given an example of the kinds of things that are currently
>> being
>> rejected? And if we think those REST API calls are valid? I'd like to
>> know what we started blocking in Option 3 that no one noticed until
>> now.
>>
>>
>> In the legacy v2 API, we create server with network like this:
>> "networks": [{"uuid": "f4001fde-7bb8-4a73-b1a9-03b444d1f6f8", "port":
>> null}]'
>> The port can be null.
>>
>> With v2.1 API, you will get 400:
>>
>> curl -g -i -X POST
>> http://192.168.2.176:8774/v2.1/b90b53ed87d74e19806da34dbaa056c9/servers
>> -H "User-Agent: python-novaclient" -H "Content-Type: application/json"
>> -H "Accept: application/json" -H "X-Auth-Token:
>> e740965218754560a98d9ac188271253" -d '{"server": {"name": "vm4",
>> "imageRef": "33a713dc-7efe-488c-bf12-d902ff5e6118", "flavorRef": "1",
>> "max_count": 1, "min_count": 1, "networks": [{"uuid":
>> "f4001fde-7bb8-4a73-b1a9-03b444d1f6f8", "port": null}]}}'
>> HTTP/1.1 400 Bad Request
>> X-Openstack-Nova-Api-Version: 2.1
>> Vary: X-OpenStack-Nova-API-Version
>> Content-Type: application/json; charset=UTF-8
>> Content-Length: 117
>> X-Compute-Request-Id: req-c5ab91ca-dc24-42ea-8272-7f35571b15da
>> Date: Mon, 07 Mar 2016 13:01:58 GMT
>>
>> {"badRequest": {"message": "Invalid input for field/attribute port.
>> Value: None. None is not a 'uuid'", "code": 400}}
>>
>> This is due to we write json-schema like this:
>> 'port': {
>> 'type': ['string', 'null'],
>> format': 'uuid'
>>   },
>>
>>
>> We assume 'type' will enable 'null' value and 'format' only against on
>> string type. Actually 'null' will be passed to format check also, then
>> the format check return fault.
>>
>
> So, 'null' should be removed from there and the required set of attributes
> should have 'uuid' removed. Is that correct?

If so, I think it should be fine to correct it without a microversion.
>

Do you mean the option3? For option3, just need remove the 'null' from type.

For option 2, it looks like this https://review.openstack.org/#/c/288268/2


>
> 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] [nova] Standardized executable return codes/logging conventions?

2016-03-08 Thread Andrew Laski


On Tue, Mar 8, 2016, at 06:16 AM, Finucane, Stephen wrote:
> I'm working on a fix [1] for bug #1538227, "Failed `nova-manage db
> sync` returns exitcode of 0" [2]. Having done this, I've noted that
> there seems to be no consistent policy around (a) what return codes to
> use (if any), and (b) whether to use logging or printing. Are there
> any guidelines on this in Nova (or any OpenStack project, for that
> matter) and, if not, do we need some? This is important for me as I'm
> adding a new return code to said executable and I've been asked for
> provide some rationale for my choice of code [3]
> 
> FWIW, I think the returns codes don't matter so much so long as they
> always return non-zero for failed/error cases and don't change (without
> good reason) once they do so. I also think output should be done via
> print, per the recommendations of the Python documentation [4], but
> some consitency in output would be appreciated.

I commented on the review as well, but after thinking on this some more
I'm inclined to have it return an exitcode of 1 for a generic failure
and we could later get into splitting the return code based on exception
type or some other distinct property of failures.

> 
> Cheers,
> Stephen
> 
> [1] https://review.openstack.org/#/c/289308/2
> [2] https://bugs.launchpad.net/nova/+bug/1538227
> [3] https://review.openstack.org/#/c/289308/2/nova/cmd/manage.py
> [4] https://docs.python.org/3.3/howto/logging.html#when-to-use-logging
> 
> __
> OpenStack Development Mailing 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][All] Api development question

2016-03-08 Thread Valeriy Ponomaryov
"Not found" means API you request is not registered. AFAICS, you
register "access_groups",
but request "access-groups". Diff in symbols "_" and "-".

On Tue, Mar 8, 2016 at 1:34 PM,  wrote:

>
>
>
>
> Hi all,
>
>
>
> I am working on a feature for share access in manila.
>
> For that lets say for creating the entity, I created client and server
>
> counterpart.
>
>
>
> I am stuck as my client request is not able to reach server resource
>
> I have created for it. This is client server log
>
> http://paste.openstack.org/show/489642/
>
>
>
>
>
> manila/api/v2/router.py
>
> This is my router entry
>
>
>
> from manila.api.v2 import access_groups
>
> .
>
> .
>
>
>
> self.resources["access_groups"] = access_groups.create_resource()
>
> mapper.resource("access_group", "access_groups",
>
> controller=self.resources["access_groups"],
>
> collection={"detail": "GET"},
>
> member={"defaults": "GET"})
>
>
>
>
>
> I don’t understand what mistake I have made that the request
>
> Is not getting mapped to correct resource.
>
>
>
> stack@controller:/opt/stack/manila/manila/api/v2$ ls access_groups.py
>
> access_groups.py
>
> stack@controller:/opt/stack/manila/manila/api/v2$
>
>
>
> This is access_groups.py snippet
>
> http://paste.openstack.org/show/489667/
>
>
>
> Can someone please help in pointing, what can be probable reason of this ?
>
> I have checked the flow from client to server, not able to catch the
> mistake..
>
>
>
>
>
>
>
> Regards
>
>
>
> *Nidhi Mittal Hada*
>
> *Architect | PES / COE* – *Kolkata India*
>
> *Wipro Limited*
>
> *M* +91 74 3910 9883 | *O* +91 33 3095 4767 | *VOIP* +91 33 3095 4767
>
>
>
>
>
>
> The information contained in this electronic message and any attachments
> to this message are intended for the exclusive use of the addressee(s) and
> may contain proprietary, confidential or privileged information. If you are
> not the intended recipient, you should not disseminate, distribute or copy
> this e-mail. Please notify the sender immediately and destroy all copies of
> this message and any attachments. WARNING: Computer viruses can be
> transmitted via email. The recipient should check this email and any
> attachments for the presence of viruses. The company accepts no liability
> for any damage caused by any virus transmitted by this email.
> www.wipro.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
>
>


-- 
Kind Regards
Valeriy Ponomaryov
www.mirantis.com
vponomar...@mirantis.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Performance] Let's have next meeting on March 15th

2016-03-08 Thread Dina Belova
Just a reminder: we won't have a meeting today!

Happy Women's Day!

Cheers,
Dina

On Tue, Mar 1, 2016 at 7:54 PM, Dina Belova  wrote:

> Folks,
>
> due to the schedule our next meeting
>  is going to happen
> on March 8th, that's International Women's Day (non-working day in Russia,
> for instance). So let's have our next meeting scheduled for March 15th.
>
> Cheers,
> Dina
>



-- 

Best regards,

Dina Belova

Software Engineer

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


  1   2   >