Re: [openstack-dev] [kolla] kolla-mesos development being scaled back

On Wed, Apr 20, 2016 at 2:40 PM, Steven Dake (stdake) wrote: > Unfortunately > the project implementors don't intend to continue its development in the > Open, but instead take it "internal" and work on it privately. I disagree > with this approach, but as the PTL of Kolla I have done everything

Re: [openstack-dev] [kolla] kolla-mesos development being scaled back

On Wed, Apr 20, 2016 at 4:43 PM Steven Dake (stdake) wrote: > Hey folks, > > I know a lot of folks are already aware of this, but as we head into > summit, in the interest of an Open Community, it is important to share this > information widely. The major implementors of the kolla-emsos reposito

[openstack-dev] [horizon][designate] : Facing problem in integrating Designate-Dashboard plugin on Horizon

Hi All, I have tried steps 1-2 from  https://github.com/openstack/designate-dashboard/blob/master/README.rst and also declared designate-dashboard in the horizon settings files as given on  https://github.com/openstack/designate-dashboard/tree/stable/liberty#howto  (step 2). Still, on devstack, n

Re: [openstack-dev] [Openstack-operators] [all][log] Ideas to log request-ids in cross-projects

-Original Message- From: Doug Hellmann [mailto:d...@doughellmann.com] Sent: Wednesday, March 16, 2016 8:35 PM To: openstack-operators Subject: Re: [Openstack-operators] [openstack-dev] [all][log] Ideas to log request-ids in cross-projects Excerpts from Kekane, Abhishek's message of 201

[openstack-dev] [kolla] kolla-mesos development being scaled back

Hey folks, I know a lot of folks are already aware of this, but as we head into summit, in the interest of an Open Community, it is important to share this information widely. The major implementors of the kolla-emsos repository listed in this specification [1] don't intend to continue its dev

Re: [openstack-dev] [keystone] Keystone commands

On 20 April 2016 at 14:02, Dolph Mathews wrote: > On Tue, Apr 19, 2016 at 10:40 PM, Kenny Ji-work > wrote: > >> Hi all, >> >> I have installed openstack mitaka, when I execute any keystone's commands >> with the result displayed below: >> But I execute `openstack role list`, the result is succee

Re: [openstack-dev] [Vitrage] questions about "relationships"

Elisha, Thanks for your detail explanation. I think I can understand how Vitrage works now. :) Since Vitrage needs to read data from different data sources and build one Entity Graph, the elasticity of vitrage-grpah process will be a big challenge per my understanding. :) Thanks again, Tony F

Re: [openstack-dev] [kolla] How to get rpm locally during kolla build

Hi, On Wed, Apr 20, 2016 at 2:12 PM, wrote: > I have network problem, it is unstable. Then `kolla-build --registry > 127.0.0.1:4000 --push ` always fail when building openstack-base image > I wonder if there is any way to put those rpms into local directory then the > network problem can be wor

[openstack-dev] [kolla] How to get rpm locally during kolla build

Hi, I have network problem, it is unstable. Then `kolla-build --registry 127.0.0.1:4000 --push ` always fail when building openstack-base image like this: INFO:kolla.cmd.build:openstack-base: INFO:kolla.cmd.build:

Re: [openstack-dev] 答复: [probably forge email可能是仿冒邮件]Re: openstack-dev] [vitrage] vitrage alarms list

Hi, Can you send the local.conf file in your devstack folder ? Can you send the /etc/vitrage/vitrage.conf file ? If you do vitrage topology show do you get an error ? the log that you sent is it vitrage-api.log or vitrage.log ? Thanks Eyal On Wed, Apr 20, 2016 at 5:34 AM, wrote: > > Hi, > Th

Re: [openstack-dev] [tripleo][heat] Summit session clashes

On Wed, Apr 20, 2016 at 3:26 AM, Zane Bitter wrote: > Umm, I thought that was the idea. > > I need to be at both of those Heat ones anyway, so this doesn't really help > me. I'd rather have the DLM session in this slot instead. (The only sessions > I can really skip are the Release Model, Function

Re: [openstack-dev] [Swift] Erasure coding and geo replication

Hi, Has the release of 2.7 significantly changed the assessment here? Thanks Mark On 15/02/16 23:29, Kota TSUYUZAKI wrote: Hello Mark, AFAIK, a few reasons for that we still are in working progress for erasure code + geo replication. and expect to survive a region outage... With that I m

Re: [openstack-dev] [magnum][app-catalog][all] Build unified abstraction for all COEs

Sure… I can clarify with a few additional thoughts: .1) I wouldn’t recommend that it be required for the operator to offer this API. Representing a view of both providing managed services for private cloud customer-on-premise installations of upstream OpenStack and as a business owner with respons

Re: [openstack-dev] [python-keystoneclient] Return request-id to caller

Hi Brant, David, Thank you for your opinions. On Wed, 13 Apr 2016 13:07:55 + David Stanek wrote: > On Wed, Apr 13, 2016 at 3:26 AM koshiya maho > wrote: > > > > > My request to all keystone cores to give their suggestions about the same. > > > > > I'll test this a little and see if I can

Re: [openstack-dev] [devstack] openstack client slowness / client-as-a-service

On 20/04/16 06:17, Monty Taylor wrote: On 04/19/2016 10:16 AM, Daniel P. Berrange wrote: On Tue, Apr 19, 2016 at 09:57:56AM -0500, Dean Troyer wrote: On Tue, Apr 19, 2016 at 9:06 AM, Adam Young wrote: I wonder how much of that is Token caching. In a typical CLI use patter, a new token is cr

[openstack-dev] [neutron][release] neutron *-aas release notes are not linked.

Hi, I noticed Mitaka release notes for neutron *-aas [1,2,3] are not referred to from anywhere. Neutron has four deliverables (neutron, lbaas, fwaas, vpnaas), but only the release note of the main neutron repo is linked. Is the right solution to add links to the main neutron release notes? Anothe

Re: [openstack-dev] [keystone] Keystone commands

On Tue, Apr 19, 2016 at 10:40 PM, Kenny Ji-work wrote: > Hi all, > > I have installed openstack mitaka, when I execute any keystone's commands > with the result displayed below: > But I execute `openstack role list`, the result is succeed. > > *[root@devstack scripts]# keystone --debug role-list*

[openstack-dev] [keystone] Keystone commands

Hi all, I have installed openstack mitaka, when I execute any keystone's commands with the result displayed below: But I execute `openstack role list`, the result is succeed. [root@devstack scripts]# keystone --debug role-list /usr/lib/python2.7/site-packages/keystoneclient/shell.py:64: Depr

Re: [openstack-dev] [ironic] upgrade support between which versions of ironic?

I agree this is reasonable to support all these cases in “cold upgrades” but in supports-rolling-upgrade (live upgrade in another word) case it is different and complicated and not necessary, During rolling upgrade, we will have old/new services co-existed, and we need to make services compatib

Re: [openstack-dev] [devstack] openstack client slowness / client-as-a-service

On 04/19/2016 11:03 PM, Dean Troyer wrote: On Tue, Apr 19, 2016 at 8:17 PM, Adam Young > wrote: Maybe it is time to revamp Devstack. Is there some way that, without a major rewrite, it could take better advantage of the CLI? Could we group commands, or m

Re: [openstack-dev] [devstack] openstack client slowness / client-as-a-service

On Tue, Apr 19, 2016 at 8:17 PM, Adam Young wrote: > Maybe it is time to revamp Devstack. Is there some way that, without a > major rewrite, it could take better advantage of the CLI? Could we group > commands, or migrate sections to python scripts that really all need to be > done together? Fo

Re: [openstack-dev] [keystone] Problem with WSGI on keystone

On Tue, Apr 19, 2016 at 11:57 AM, Rosensweig, Elisha (Nokia - IL) < elisha.rosensw...@nokia.com> wrote: > Hi All, > > Recently, I've been having trouble running stack.sh from scratch. With the > default configuration I've been using for a while, I get the following > error in /opt/stack/logs/key.l

[openstack-dev] 答复: [probably forge email可能是仿冒邮件]Re: openstack-dev] [vitrage] vitrage alarms list

Hi, Thanks for your response. There is no error about the request of alarms list in vitrage-graph log. Here is the vitrage-api log about the alarms error. Thank you for your help~ :) 2016-04-20 09:45:34.599585 2016-04-20 09:45:34.599 3700 DEBUG vitrage.service [-] static_physical.transformer

[openstack-dev] [nova] Nova API sub-team meeting

Hi, We have weekly Nova API meeting today. The meeting is being held Wednesday UTC1300 and irc channel is #openstack-meeting-4. The proposed agenda and meeting details are here: https://wiki.openstack.org/wiki/Meetings/NovaAPI Please feel free to add items to the agenda. Thanks ___

Re: [openstack-dev] [Magnum]Cache docker images

Kevin, I agree this is not ideal solution, but it's probably the best option to deal with public cloud "stability" (e.g. we switched to the same model at AWS andgot really good boost in provisioning time and reduce # failures during cluster provisioning). And if application need guarantee "fresh

[openstack-dev] [all] [steth] Call for contributors for Steth - a network inspection tool

Hi All, Deploying OpenStack can be a challenging task in a large-scale environment, one of them being the networking side of all of this. Each technology have their own environmental prerequisites. For instance, VLAN needs to be configured as we expect; bandwidth should meet our requirements,con

Re: [openstack-dev] More on the topic of DELIMITER, the Quota Management Library proposal

Jay, thanks for the detailed comments. Detailed responses follow. -amrith > -Original Message- > From: Jay Pipes [mailto:jaypi...@gmail.com] > Sent: Monday, April 18, 2016 2:54 PM > To: openstack-dev@lists.openstack.org > Subject: Re: [openstack-dev] More on the topic of DELIMITER, the Qu

Re: [openstack-dev] [magnum][app-catalog][all] Build unified abstraction for all COEs

I am going to clarify one thing. Users will always have access to native APIs provided by individual COEs, regardless of the existence of the common abstraction. In other words, the proposed common abstraction layer is an addition, not a replacement. Best regards, Hongbin > -Original Messa

Re: [openstack-dev] [tripleo][heat] Summit session clashes

On 20/04/16 13:26, Zane Bitter wrote: On 19/04/16 18:04, Steve Baker wrote: On 19/04/16 20:29, Steven Hardy wrote: On Tue, Apr 19, 2016 at 04:24:46PM +1200, Steve Baker wrote: All of the TripleO design summit sessions are on Thursday afternoon in slots which clash with Heat sessions. H

Re: [openstack-dev] [tosca-parser] [heat-translator] Collaboration with [Tacker] project at the Austin Summit

Hi Howard, Yes, absolutely. See you in few days! Regards, Sahdev Zala From: Zhipeng Huang To: "OpenStack Development Mailing List (not for usage questions)" Date: 04/19/2016 07:51 PM Subject:Re: [openstack-dev] [tosca-parser] [heat-translator] Collaboration with [Tacker]

Re: [openstack-dev] [tripleo][heat] Summit session clashes

On 19/04/16 18:04, Steve Baker wrote: On 19/04/16 20:29, Steven Hardy wrote: On Tue, Apr 19, 2016 at 04:24:46PM +1200, Steve Baker wrote: All of the TripleO design summit sessions are on Thursday afternoon in slots which clash with Heat sessions. Heat is a core component of TripleO

Re: [openstack-dev] [nova] Nova commands

That's it, I've solved the issue. Thanks a log! :) From: melanie witt To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [nova] Nova commands Message-ID: <5716539f.2060...@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed On Tue, 19 Apr 2016 19:31:04 +0800,

Re: [openstack-dev] [devstack] openstack client slowness / client-as-a-service

On 04/19/2016 07:24 PM, Jamie Lennox wrote: Rather than ditching python for something like go, I'd rather put together a CLI with no plugins and that only depended on keystoneauth and os-client-config as libraries. No? Let me add that if you are doing anything non trivial withe the CLI, you m

Re: [openstack-dev] [nova] [neutron] the nova network facade that isn't

On 04/19/2016 07:11 PM, Matt Riedemann wrote: > I've always personally considered the network proxy to neutron in the > API as getting more of a pass since nova has a network service in it, it > doesn't have it's own image or volume service since those were > completely split out. But since the ad

Re: [openstack-dev] [Neutron] meeting topics for 4/21/2016 networking-sfc project IRC meeting

Thursday works for me either lunch or dinner. Regards John Sent from my iPhone On Apr 19, 2016, at 5:31 PM, Cathy Zhang mailto:cathy.h.zh...@huawei.com>> wrote: Sure, good suggestion! I am thinking we can have a lunch/dinner together. I will put this in Thursday's meeting agenda and let you

Re: [openstack-dev] [Neutron] meeting topics for 4/21/2016 networking-sfc project IRC meeting

Sure, good suggestion! I am thinking we can have a lunch/dinner together. I will put this in Thursday's meeting agenda and let you and others know the f2f meeting time and place. Any specific date that is not good for you? Thanks, Cathy From: John McDowall [mailto:jmcdow...@paloaltonetworks.c

Re: [openstack-dev] [Neutron] meeting topics for 4/21/2016 networking-sfc project IRC meeting

Cathy, Thanks - is it worth while to have a f2f meeting with everyone at the summit? Regards John Sent from my iPhone On Apr 19, 2016, at 5:25 PM, Cathy Zhang mailto:cathy.h.zh...@huawei.com>> wrote: Hi John, Thanks for the note. Great that you already have a skeleton OVN driver for networ

Re: [openstack-dev] [Neutron] meeting topics for 4/21/2016 networking-sfc project IRC meeting

Hi John, Thanks for the note. Great that you already have a skeleton OVN driver for networking-sfc. The next step is to contribute to the detail driver specification and then work out the edges and details on the coding side as well as unit test and integration test (still a lot of work down th

Re: [openstack-dev] [magnum][app-catalog][all] Build unified abstraction for all COEs

This pursuit is a trap. Magnum should focus on making native container APIs available. We should not wrap APIs with leaky abstractions. The lowest common denominator of all COEs is an remarkably low value API that adds considerable complexity to Magnum that will not strategically advance OpenSta

Re: [openstack-dev] [neutron][kilo] - vxlan's max bandwidth

I like larger MTUs, and used to call stateless offloads like TSO/GSO "Poor man's Jumbo Frames" but if you can get the stateless offloads going, you can go beyond the savings one gets from JumboFrames because a TSO/GSO/GRO "segment" can end-up being semi-effectively 32-64KB. rick jones PS - don

[openstack-dev] [kolla] let the liberty backport begin

Hey folks, Thanks to the release team and infrastructure team, we have a stable/liberty branch that is equivalent as of this afternoon to each other. Michal is free to submit his backport patch to stable/liberty now. In the process I was required to abandon all changes against stable/liberty.

Re: [openstack-dev] [tosca-parser] [heat-translator] Collaboration with [Tacker] project at the Austin Summit

Hi Sahdev, Could parser team also be part of the joint session ? On Tue, Apr 19, 2016 at 9:55 PM, Sahdev P Zala wrote: > Hi Team, > > We will be having a collaborative session with Tacker project at the > summit. The following Tacker working session will be focused on it, > > Tacker Developer T

Re: [openstack-dev] [nova] Question on removal of 'arbitrary' pluggable interfaces

On 4/18/2016 1:08 PM, Joshua Harlow wrote: Hi nova folks, I was reading over the following: http://lists.openstack.org/pipermail/openstack-operators/2016-April/010186.html And I am wondering if there is a list of all the plugin points and there schedule for being deprecated and then removed (

Re: [openstack-dev] [release][requirements][packaging][summit] input needed on summit discussion about global requirements

On 04/19/2016 03:10 PM, Doug Hellmann wrote: >> On your etherpad, you wrote: >> >> "During the lead-up to preparing the final releases, one of the tracking >> tasks we have is to ensure all projects have synced their global >> requirements updates. This is another area where we could reduce the >>

Re: [openstack-dev] [Fuel] snapshot tool

IMHO, removal of sensitive information is done by services when they (do not) log relative data to logs, such as tokens. Current set of commands only collects specific config folders and files and logs, but if an admin decided to store keys in one of these folders - the tool will collect them too.

Re: [openstack-dev] [neutron][kilo] - vxlan's max bandwidth

On 18 April 2016 at 04:33, Ihar Hrachyshka wrote: > Akihiro Motoki wrote: > > 2016-04-18 15:58 GMT+09:00 Ihar Hrachyshka : >> >>> Sławek Kapłoński wrote: >>> >>> Hello, What MTU have You got configured on VMs? I had issue with performance on vxlan network with standard MTU (1500)

Re: [openstack-dev] [devstack] openstack client slowness / client-as-a-service

On 20 April 2016 at 04:17, Monty Taylor wrote: > On 04/19/2016 10:16 AM, Daniel P. Berrange wrote: > >> On Tue, Apr 19, 2016 at 09:57:56AM -0500, Dean Troyer wrote: >> >>> On Tue, Apr 19, 2016 at 9:06 AM, Adam Young wrote: >>> >>> I wonder how much of that is Token caching. In a typical CLI use

Re: [openstack-dev] [magnum][app-catalog][all] Build unified abstraction for all COEs

I would recommend against implementing a lowest common denominator API for the COEs ³right now.² It¹s too early to tell if the COEs are going to be seen as a commodity (where in the long run they may all perform relatively equal for the majority of workloads ‹ in which case why do you care to hav

Re: [openstack-dev] [nova] [neutron] the nova network facade that isn't

On 4/19/2016 5:56 PM, Armando M. wrote: On 19 April 2016 at 07:02, Sean Dague mailto:s...@dague.net>> wrote: On 04/18/2016 04:48 PM, Matt Riedemann wrote: > > I guess at a high level my thinking was always, if nova-network isn't > deprecated, and these APIs are broken when

Re: [openstack-dev] [nova] [neutron] the nova network facade that isn't

On 4/19/2016 5:59 PM, Armando M. wrote: On 18 April 2016 at 15:41, Jay Pipes mailto:jaypi...@gmail.com>> wrote: On 04/18/2016 04:33 PM, Sean Dague wrote: When doing bug triage this morning a few bugs popped up: - https://bugs.launchpad.net/nova/+bug/1456899 - nova

Re: [openstack-dev] [release][requirements][packaging][summit] input needed on summit discussion about global requirements

Thomas, I normally side with the distro's take on making sure there is no duplication, but I think Thierry's point comes from two differences coming up that the traditional distro's don't tend to account for. The traditional distro usually is about a single machine. being able to install all t

Re: [openstack-dev] [nova] [neutron] the nova network facade that isn't

On 18 April 2016 at 15:41, Jay Pipes wrote: > On 04/18/2016 04:33 PM, Sean Dague wrote: > >> When doing bug triage this morning a few bugs popped up: >> >> - https://bugs.launchpad.net/nova/+bug/1456899 - nova absolute-limits >> Security groups count incorrect when using Neutron >> - https://bugs

Re: [openstack-dev] [nova] [neutron] the nova network facade that isn't

On 19 April 2016 at 07:02, Sean Dague wrote: > On 04/18/2016 04:48 PM, Matt Riedemann wrote: > > > > > I guess at a high level my thinking was always, if nova-network isn't > > deprecated, and these APIs are broken when using Neutron, it's (mostly) > > trivial to add a proxy to fill those gaps (

Re: [openstack-dev] [release][requirements][packaging][summit] input needed on summit discussion about global requirements

Ah! Now we're getting right on the spot, where it hurts, and we're finding the root cause. That's a very good thing. Let's dig ! :) On 04/19/2016 05:26 PM, Chris Dent wrote: > I, in project A, don't want to limit my requirements because project B > has not yet upgraded itself to be able to use the

Re: [openstack-dev] [release][requirements][packaging][summit] input needed on summit discussion about global requirements

On 04/19/2016 11:48 AM, Thierry Carrez wrote: >> Remember that in distros, there's only a single version of a library at >> any given time, at the exception of transitions (yes, in Red Hat it's >> technically possible to install multiple versions, but the policy >> strongly advocates against this).

Re: [openstack-dev] [tripleo][releases] Remove diskimage-builder from releases

On 2016-04-19 15:34:16 -0400 (-0400), James Slagle wrote: > A fork would be unfortunate. What about a new repo that's just for > the elements used heavily by infra, e.g., > openstack-infra-elements. [...] We do already have a bunch of elements in openstack-infra/project-config, so most of the velo

Re: [openstack-dev] [tripleo][heat][all] Summit session clashes

On 19/04/16 20:29, Steven Hardy wrote: On Tue, Apr 19, 2016 at 04:24:46PM +1200, Steve Baker wrote: All of the TripleO design summit sessions are on Thursday afternoon in slots which clash with Heat sessions. Heat is a core component of TripleO and as a contributor to both projects I

Re: [openstack-dev] [Neutron] meeting topics for 4/21/2016 networking-sfc project IRC meeting

Cathy, I will not make the meeting on Thursday (traveling), but I have a skeleton OVN Driver in progress and should have it working by the end of the week with OVN and the current networking-sfc API. Lots of edge conditions and details to be worked out but the driver model make it pretty easy.

Re: [openstack-dev] [release][requirements][packaging][summit] input needed on summit discussion about global requirements

On 2016-04-19 16:10:12 +0100 (+0100), Chris Dent wrote: > On Tue, 19 Apr 2016, Jeremy Stanley wrote: [...] > > I feel like many of the people pushing this idea simply didn't > > get to experience the pain it causes the first time around and > > won't believe their peers who lived through it. > > I

Re: [openstack-dev] [tripleo][releases] Remove diskimage-builder from releases

Excerpts from Ian Wienand's message of 2016-04-20 06:25:17 +1000: > On 04/20/2016 03:25 AM, Doug Hellmann wrote: > > It's not just about control, it's also about communication. One of > > the most frequent refrains we hear is "what is OpenStack", and one > > way we're trying to answer that is to pu

Re: [openstack-dev] [tripleo][releases] Remove diskimage-builder from releases

On Tue, Apr 19, 2016, at 01:25 PM, Ian Wienand wrote: > On 04/20/2016 03:25 AM, Doug Hellmann wrote: > > It's not just about control, it's also about communication. One of > > the most frequent refrains we hear is "what is OpenStack", and one > > way we're trying to answer that is to publicize all

Re: [openstack-dev] [ironic] upgrade support between which versions of ironic?

Thanks for starting the thread, Ruby. We need to first establish a grenade job to test "cold upgrades" and assert the supports-upgrade tag. I believe Ironic meets all the criteria for that tag except: - having a job that tests it (so, you know, it might be broken and I might be wrong) - having op

Re: [openstack-dev] [nova] [neutron] the nova network facade that isn't

I've got scripts I use nova floating ip subcommands to attach/detach floating ips occasionally because it was easier to write then using the equiv neutron commands even though I'm using neutron. I'd think some folks will be doing the same. That being said, we'll have to rewrite all that code fo

Re: [openstack-dev] [devstack] openstack client slowness / client-as-a-service

On Tue, Apr 19, 2016 at 12:17 PM, Monty Taylor wrote: > On 04/19/2016 10:16 AM, Daniel P. Berrange wrote: > >> On Tue, Apr 19, 2016 at 09:57:56AM -0500, Dean Troyer wrote: >> >>> On Tue, Apr 19, 2016 at 9:06 AM, Adam Young wrote: >>> >>> I wonder how much of that is Token caching. In a typical

Re: [openstack-dev] [tripleo][releases] Remove diskimage-builder from releases

On 04/20/2016 06:09 AM, Fox, Kevin M wrote: I've seen dib updated and broken things. I've seen dib elements updated and things broke (centos6 removal in particular hurt.) By the time it gets to a release, however, anything we've broken is already baked in. Any changes in there have already

Re: [openstack-dev] [packaging-deb] [infra] publishing built packages for others to depend on

On 2016-04-19 11:30:35 +0200 (+0200), Thomas Goirand wrote: [...] > Which direction does the infra team believe I should take? Aside from a little bit of feedback I provided in #openstack-infra today, I don't have a bunch of time to dig into this before next week but it looks like the packaging se

Re: [openstack-dev] [Cinder] API features discoverability

On 04/18/2016 09:17 AM, Ramakrishna, Deepti wrote: > Hi Michal, > > This seemed like a good idea when I first read it. What more, the server code > for extension listing [1] does not do any authorization, so it can be used > for any logged in user. > > However, I don't know if requiring the admin

Re: [openstack-dev] [Fuel] snapshot tool

Hello, I've got a couple of questions: - What about this tool using non-root accounts to connect to OpenStack nodes? Currently, it seems to assume that it always is going to use "root" for SSH. - Shouldn't it sanitize all sensitive information (user names, host names, passwords, tokens, keys etc)?

Re: [openstack-dev] [nova] [neutron] the nova network facade that isn't

On Tue, 19 Apr 2016 10:02:46 -0400, Sean Dague wrote: Right, I think in the Havana timeframe, things were very different. Part of the rationale for full parity was that applications would be written against nova-network, and smoothly transition to neutron. But with over 90% neutron, assuming some

Re: [openstack-dev] [devstack] openstack client slowness / client-as-a-service

> -Original Message- > From: Jay Pipes [mailto:jaypi...@gmail.com] > Sent: Tuesday, April 19, 2016 8:10 PM > To: openstack-dev@lists.openstack.org > Subject: Re: [openstack-dev] [devstack] openstack client slowness / > client-as-a-service > > On 04/19/2016 02:17 PM, Monty Taylor wrote: >

Re: [openstack-dev] [tripleo][releases] Remove diskimage-builder from releases

On 04/20/2016 03:25 AM, Doug Hellmann wrote: It's not just about control, it's also about communication. One of the most frequent refrains we hear is "what is OpenStack", and one way we're trying to answer that is to publicize all of the things we release through releases.openstack.org. So for

Re: [openstack-dev] [devstack] openstack client slowness / client-as-a-service

On 04/19/2016 03:24 PM, Steve Martinelli wrote: Or make use of openstacksdk instead of pulling in all the clients This would be a good thing, yes. -jay __ OpenStack Development Mailing List (not for usage questions) Unsub

Re: [openstack-dev] [nova] [neutron] the nova network facade that isn't

On 04/18/2016 05:41 PM, Jay Pipes wrote: On 04/18/2016 04:33 PM, Sean Dague wrote: When doing bug triage this morning a few bugs popped up: - https://bugs.launchpad.net/nova/+bug/1456899 - nova absolute-limits Security groups count incorrect when using Neutron - https://bugs.launchpad.net/nova/

Re: [openstack-dev] [tripleo][releases] Remove diskimage-builder from releases

On Tue, Apr 19, 2016, at 10:25 AM, Doug Hellmann wrote: > Excerpts from Jeremy Stanley's message of 2016-04-19 15:41:26 +: > > On 2016-04-19 09:22:57 -0400 (-0400), Doug Hellmann wrote: > > > Excerpts from Ian Wienand's message of 2016-04-19 12:11:35 +1000: > > [...] > > > > I don't expect the

Re: [openstack-dev] [tripleo][releases] Remove diskimage-builder from releases

As an Op, I've been bitten by both sides of this I've seen dib updated and broken things. I've seen dib elements updated and things broke (centos6 removal in particular hurt.) I've appreciated dib elements getting fixed quickly at times because distro's changed, and the element needed change

Re: [openstack-dev] [devstack] openstack client slowness / client-as-a-service

From: Fox, Kevin M [kevin@pnnl.gov] Sent: Tuesday, April 19, 2016 12:59 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [devstack] openstack client slowness / client-as-a-service What about a plugin cach

Re: [openstack-dev] [puppet] Stepping down from puppet-openstack-core

On Mon, Apr 18, 2016 at 8:37 AM, Sebastien Badia wrote: > Hello here, > > I would like to ask to be removed from the core reviewers team on the > Puppet for OpenStack project. > > I lack dedicated time to contribute on my spare time to the project. And I > don't work anymore on OpenStack deployme

Re: [openstack-dev] [Magnum]Cache docker images

I'm kind of uncomfortable as an op with the prebundled stuff. how do you upgrade things when needed if there is no way to pull updated images from a central place? Thanks, Kevin From: Hongbin Lu [hongbin...@huawei.com] Sent: Tuesday, April 19, 2016 11:56 AM To: O

Re: [openstack-dev] [Magnum]Cache docker images

If they have a valid CA signed cert for the docker registry, it should 'Just work (TM)' :) Self signing is a different issue. Maybe just an additional option in addition to the prefix option to pass a CA to add to the root trust chain? Thanks, Kevin From: Hongb

Re: [openstack-dev] [devstack] openstack client slowness / client-as-a-service

What about a plugin cache like feature? if no cache, or cache older then 24 hours, dump all discovered plugins into a python file that loads them more statically. if the cache is valid, just use it. and a hook in rpms/debs to remove the cache on plugin install/uninstall. Thanks, Kevin _

[openstack-dev] [ironic] upgrade support between which versions of ironic?

Hi, Currently, ironic doesn't support ("live", "online", "rolling", or minimal-downtime) upgrades between named versions of ironic. (Where "named version" is the final release or stable release that is associated with a development cycle). So for example, Liberty -> Mitaka release. We've been wor

Re: [openstack-dev] [tripleo][releases] Remove diskimage-builder from releases

On Tue, Apr 19, 2016 at 11:41 AM, Jeremy Stanley wrote: > DIB is an unfortunate combination of a mostly stable framework and a > large pre-written set of scripts and declarative data which is > constantly evolving for widespread use outside the OpenStack > ecosystem (so most of the change volume i

Re: [openstack-dev] [tripleo][releases] Remove diskimage-builder from releases

On Tue, Apr 19, 2016 at 1:25 PM, Doug Hellmann wrote: > It's not just about control, it's also about communication. One of > the most frequent refrains we hear is "what is OpenStack", and one > way we're trying to answer that is to publicize all of the things > we release through releases.openstac

Re: [openstack-dev] [devstack] openstack client slowness / client-as-a-service

Or make use of openstacksdk instead of pulling in all the clients stevemar From: Jay Pipes To: openstack-dev@lists.openstack.org Date: 2016/04/19 03:11 PM Subject:Re: [openstack-dev] [devstack] openstack client slowness / client-as-a-service On 04/19/2016 02:17

Re: [openstack-dev] [devstack] openstack client slowness / client-as-a-service

On 04/19/2016 02:17 PM, Monty Taylor wrote: Rather than ditching python for something like go, I'd rather put together a CLI with no plugins and that only depended on keystoneauth and os-client-config as libraries. No? Bingo. -jay __

Re: [openstack-dev] [Magnum]Cache docker images

Eli, The approach of pre-pulling docker images has a problem. It only works for specific docker storage driver. In comparison, the tar file approach is portable across different storage drivers. Best regards, Hongbin From: taget [mailto:qiaoliy...@gmail.com] Sent: April-19-16 4:26 AM To: opens

Re: [openstack-dev] [Magnum]Cache docker images

Yes, that is an alternative. The complication is how to secure the communication between Magnum bays and the standalone docker registry. I assume we needs some custom logic to setup the communication channel (i.e. install the TLS credential). One way to support it is to add a configuration hook

Re: [openstack-dev] [oslo][keystone][documentation][gate] Babel dependency for oslo.log

Your wish has been delivered ;) https://review.openstack.org/#/c/307983/ -Josh Andreas Jaeger wrote: On 2016-04-18 19:42, Joshua Harlow wrote: Andreas Jaeger wrote: On 04/17/2016 09:15 PM, Davanum Srinivas wrote: Hi Oslo folks, Andreas and others, Over the weekend oslo.log 3.4.0 was releas

[openstack-dev] [Neutron] meeting topics for 4/21/2016 networking-sfc project IRC meeting

Hi everyone, Here are some topics I have for this week's project meeting discussion(The meeting time is not changed, still UTC 1700 Thursday). Feel free to add more. You can also find the meeting topics in the project wiki page. https://wiki.openstack.org/wiki/Meetings/ServiceFunctionChainingMee

Re: [openstack-dev] [devstack] openstack client slowness / client-as-a-service

A pluginless CLI that simply used REST calls rather than the python-clientlibs should be able to launch in get to the business of doing work in 0.2 seconds - counting time to load and parse clouds.yaml. That time could be reduced - the time spent in occ parsing vendor json files is not strictly ne

Re: [openstack-dev] [release][requirements][packaging][summit] input needed on summit discussion about global requirements

Excerpts from Thomas Goirand's message of 2016-04-19 05:59:19 -0700: > On 04/19/2016 01:01 PM, Chris Dent wrote: > > We also, however, need to consider what the future might look like and > > at least for some people and situations > > I agree. > > > the future does not involve > > debs or rpms o

Re: [openstack-dev] [devstack] openstack client slowness / client-as-a-service

From: Ian Cordasco [sigmaviru...@gmail.com] Sent: Tuesday, April 19, 2016 11:11 AM To: Perry, Sean; OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [devstack] openstack client slowness / client-as-a-service -O

Re: [openstack-dev] [devstack] openstack client slowness / client-as-a-service

On 04/19/2016 10:16 AM, Daniel P. Berrange wrote: On Tue, Apr 19, 2016 at 09:57:56AM -0500, Dean Troyer wrote: On Tue, Apr 19, 2016 at 9:06 AM, Adam Young wrote: I wonder how much of that is Token caching. In a typical CLI use patter, a new token is created each time a client is called, with

Re: [openstack-dev] [devstack] openstack client slowness / client-as-a-service

  -Original Message- From: Perry, Sean Reply: OpenStack Development Mailing List (not for usage questions) Date: April 19, 2016 at 12:41:02 To: OpenStack Development Mailing List (not for usage questions) Subject:  Re: [openstack-dev] [devstack] openstack client slowness / client-

Re: [openstack-dev] [release][requirements][packaging][summit] input needed on summit discussion about global requirements

On 04/19/2016 12:44 PM, Clint Byrum wrote: > Excerpts from Michał Jastrzębski's message of 2016-04-18 10:29:20 -0700: >> What I meant is if you have liberty Nova and liberty Cinder, and you >> want to upgrade Nova to Mitaka, you also upgrade Oslo to Mitaka and >> Cinder which was liberty either nee

Re: [openstack-dev] [keystone] Problem with WSGI on keystone

On Tue, Apr 19, 2016 at 11:57 AM, Rosensweig, Elisha (Nokia - IL) < elisha.rosensw...@nokia.com> wrote: > Hi All, > > Recently, I've been having trouble running stack.sh from scratch. With the > default configuration I've been using for a while, I get the following > error in /opt/stack/logs/key.l

Re: [openstack-dev] [magnum][kuryr] Shared session in design summit

Original Message - > From: "Zhipeng Huang" > To: "OpenStack Development Mailing List (not for usage questions)" > > > Thanks Hongbin, > > Actually we have a new project called Fuxi that sorta like Kuryr for > storage, would be glad to discuss the ideas Hi Zhipeng, Is the planned sco

Re: [openstack-dev] [release][requirements][packaging][summit] input needed on summit discussion about global requirements

Excerpts from Matthew Thode's message of 2016-04-18 11:22:38 -0700: > On 04/18/2016 12:33 PM, Doug Hellmann wrote: > > Excerpts from Matthew Thode's message of 2016-04-18 10:23:37 -0500: > >> On 04/18/2016 08:24 AM, Hayes, Graham wrote: > >>> On 18/04/2016 13:51, Sean Dague wrote: > On 04/18/2

Re: [openstack-dev] [release][requirements][packaging][summit] input needed on summit discussion about global requirements

Excerpts from Michał Jastrzębski's message of 2016-04-18 10:29:20 -0700: > What I meant is if you have liberty Nova and liberty Cinder, and you > want to upgrade Nova to Mitaka, you also upgrade Oslo to Mitaka and > Cinder which was liberty either needs to be upgraded or is broken, > therefore duri

Re: [openstack-dev] Manila manage share problem

Hello, Grigoriy One or more of following requirements are not met in your case: 1) Generic driver should be configured to use "driver_handles_share_servers=False" mode. 2) Share type "my_share_type" should contain extra spec "driver_handles_share_servers=False", same as for (1) 3) Your NFS server

  1   2   >