Re: [openstack-dev] [nova] API priorities in Newton

On 03/30/2016 12:54 PM, Matt Riedemann wrote: - POC of Gabbi for additional API validation I'm assuming cdent would be driving this, and he's also working on the resource providers stuff for the scheduler, but might be a decent side project for him to stay sane. Actually, Sergey Nikitin can

Re: [openstack-dev] [Fuel] [Shotgun] Decoupling Shotgun from Fuel

On 03/29/2016 08:41 AM, Roman Prykhodchenko wrote: Should we propose options and then arrange a poll? Yup, ++ :) 29 бер. 2016 р. о 16:40 Neil Jerram <neil.jer...@metaswitch.com> написав(ла): On 29/03/16 15:17, Jay Pipes wrote: Hi! Once Shotgun is pulled out of Fuel, may I suggest re

Re: [openstack-dev] [Fuel] [Shotgun] Decoupling Shotgun from Fuel

Hi! Once Shotgun is pulled out of Fuel, may I suggest renaming it to something different? I know in the past that Anita and a few others thought the name was not something we should really be encouraging in the OpenStack ecosystem. Just something to consider since it's being decoupled

Re: [openstack-dev] [tc] Non-candidacy

On 03/28/2016 12:17 PM, Thierry Carrez wrote: Doug Hellmann wrote: Excerpts from Jay Pipes's message of 2016-03-25 14:05:44 -0400: Hi all, Thanks for all the fish. But it's time for me to move over and let some new voices contribute to the OpenStack Technical Committee. I will continue to

Re: [openstack-dev] [cross-project] [all] Quotas -- service vs. library

On 03/16/2016 07:10 AM, Attila Fazekas wrote: NO : For any kind of extra quota service. In other places I saw other reasons for a quota service or similar, the actual cost of this approach is higher than most people would think so NO. Maybe Library, But I do not want to see for example the

Re: [openstack-dev] [nova] [infra] The same SRIOV / NFV CI failures missed a regression, why?

On 03/25/2016 04:08 PM, Jeremy Stanley wrote: On 2016-03-25 15:20:00 -0400 (-0400), Jay Pipes wrote: [...] 3) The upstream Infrastructure team works with the hired system administrators to create a single CI system that can spawn functional test jobs on the lab hardware and report results back

Re: [openstack-dev] [nova] The same SRIOV / NFV CI failures missed a regression, why?

On 03/24/2016 09:35 AM, Matt Riedemann wrote: We have another mitaka-rc-potential bug [1] due to a regression when detaching SR-IOV interfaces in the libvirt driver. There were two NFV CIs that ran on the original change [2]. Both failed with the same devstack setup error [3][4]. So it sucks

[openstack-dev] [tc] Non-candidacy

Hi all, Thanks for all the fish. But it's time for me to move over and let some new voices contribute to the OpenStack Technical Committee. I will continue to be a proponent for the viewpoint that OpenStack should be considered a toolkit of small, focused services and utilities, upon which

Re: [openstack-dev] [neutron][nova][stable][sr-iov] Status of physical_device_mappings

+tags for stable and nova Hi Vladimir, comments inline. :) On 03/21/2016 05:16 AM, Vladimir Eremin wrote: Hey OpenStackers, I’ve recently found out, that changing of use neutron sriov-agent in Mitaka from optional to required[1] makes a kind of regression. While I understand that it is

Re: [openstack-dev] [nova][neutron] Routed networks / Generic Resource pools

On 03/21/2016 06:22 AM, Miguel Angel Ajo Pelayo wrote: Hi, I was doing another pass on this spec, to see if we could leverage it as-is for QoS / bandwidth tracking / bandwidth guarantees, and I have a question [1] I guess I'm just missing some detail, but looking at the 2nd scenario,

Re: [openstack-dev] [stable] Proposing Tony Breeds for stable-maint-core

-1 He talks funny. Best, -jay On 03/18/2016 04:11 PM, Matt Riedemann wrote: I'd like to propose tonyb for stable-maint-core. Tony is pretty much my day to day guy on stable, he's generally in every stable team meeting (which is not attended well so I appreciate it), and he's as proactive as

Re: [openstack-dev] [nova] Nova PTL for Newton

On 03/11/2016 02:22 PM, John Garbutt wrote: Hi, It has been greatly rewarding serving you all as Nova PTL over the Liberty and Mitaka cycles. I thank you all for the support, encouragement and advice I have been given over the last year. I really appreciate that. (That's british speak for "I

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

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

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

Which projects in OpenStack actually use WSME at this time? Best, -jay On 03/08/2016 07:10 AM, Chris Dent wrote: On Tue, 8 Mar 2016, Stéphane Bisinger wrote: Is there an estimate of how much work/time it would take to refactor the library to slowly satisfy those three points? No, that is

[openstack-dev] [nova][pci] What is the point of the ALLOCATED vs. CLAIMED device status?

Subject says it all. I've been trying to fix this bug: https://bugs.launchpad.net/nova/+bug/1549984 and just shake my head every time I look at the PCI handling code in nova/pci/manager.py and nova/pci/stats.py. Why do we have a CLAIMED state as well as an ALLOCATED state? Best, -jay

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

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

Re: [openstack-dev] [nova] Do we need a microversion to return a 501 from GET os-virtual-interfaces?

On 03/06/2016 02:21 PM, Matt Riedemann wrote: Thanks, good point. I think 400 would be best here. And according to our handy-dandy docs [1] it should be OK to do this without a microversion. Yup, 400 is correct and yes, you should not need a new microversion addition to the API. Best, -jay

Re: [openstack-dev] [nova] A prototype implementation towards the "shared state scheduler"

e back home tomorrow to give this some thought. :) Best, -jay Regards, -Yingxin On Wednesday, February 24, 2016 5:04 PM, Cheng, Yingxin wrote: Very sorry for the delay, it feels hard for me to reply to all the concerns raised, most of you have years more experiences. I've tried hard to p

Re: [openstack-dev] [nova] deprecating pluggable managers

++ Long time coming :) On 03/03/2016 11:31 AM, Sean Dague wrote: As we were evaluating bits of configuration that we really don't expect people to use, one of the issues is pluggable managers. From the early days of Nova the classes that ran the service managers were defined in the config file.

Re: [openstack-dev] [api][neutron] question on putting an existing tag

On 02/26/2016 09:02 AM, Akihiro Motoki wrote: Hi API-WG, Neutron is implementing tag support for network resource [0]. The implementation follows 'Tags' guideline defined by API-WG [1]. I have a questions on the guideline. We can create a tag by PUT'ing an individual tag: What status

Re: [openstack-dev] [nova] solving API case sensitivity issues

On 02/24/2016 07:48 AM, Sean Dague wrote: We have a specific bug around aggregrate metadata setting in Nova which exposes a larger issue with our mysql schema. https://bugs.launchpad.net/nova/+bug/1538011 On mysql the following will explode with a 500: nova aggregate-create agg1 nova

Re: [openstack-dev] [nova] A prototype implementation towards the "shared state scheduler"

On 02/22/2016 04:23 AM, Sylvain Bauza wrote: I won't argue against performance here. You made a very nice PoC for testing scaling DB writes within a single python process and I trust your findings. While I would be naturally preferring some shared-nothing approach that can horizontally scale,

Re: [openstack-dev] [nova] A prototype implementation towards the "shared state scheduler"

On 02/23/2016 06:03 PM, Chris Friesen wrote: On 02/21/2016 01:56 PM, Jay Pipes wrote: Yingxin, sorry for the delay in responding to this thread. My comments inline. On 02/17/2016 12:45 AM, Cheng, Yingxin wrote: To better illustrate the differences between shared-state, resource-provider

Re: [openstack-dev] [nova] A prototype implementation towards the "shared state scheduler"

On 02/23/2016 06:12 PM, Chris Friesen wrote: On 02/22/2016 03:23 AM, Sylvain Bauza wrote: See, I don't think that a compute node unable to start a request is an 'abnormal case'. There are many reasons why a request can't be honored by the compute node : - for example, the scheduler doesn't

Re: [openstack-dev] [Neutron] - DVR L3 data plane performance results and scenarios

On 02/22/2016 10:25 PM, Wuhongning wrote: Hi all, There is also a control plane performance issue when we try to catch on the spec of typical AWS limit (200 subnets per router). When a router with 200 subnets is scheduled on a new host, a 30s delay is watched when all data plane setup is

Re: [openstack-dev] [glance]one more use case for Image Import Refactor from OPNFV

On 02/22/2016 09:12 AM, Brian Rosmaita wrote: Hello everyone, Joe, I think you are proposing a perfectly legitimate use case, but it's not what the Glance community is calling "image import", and that's leading to some confusion. The Glance community has defined "image import" as: "A cloud

Re: [openstack-dev] [all] A proposal to separate the design summit

On 02/22/2016 12:45 PM, Thierry Carrez wrote: I don't think the proposal removes that opportunity. Contributors /can/ still go to OpenStack Summits. They just don't /have to/. I just don't think every contributor needs to be present at every OpenStack Summit, while I'd like to see most of them

Re: [openstack-dev] [all] A proposal to separate the design summit

On 02/22/2016 11:36 AM, Ed Leafe wrote: One thing that hasn't been mentioned is the push by many of the larger companies involved to have their devs give as many presentations as possible at the Summit in the hope of improving their visibility in the OpenStack world, and possibly also providing

Re: [openstack-dev] [all] A proposal to separate the design summit

On 02/22/2016 10:14 AM, Thierry Carrez wrote: Hi everyone, TL;DR: Let's split the events, starting after Barcelona. Long long version: In a global and virtual community, high-bandwidth face-to-face time is essential. This is why we made the OpenStack Design Summits an integral part of our

Re: [openstack-dev] [nova] nova-compute blocking main thread under heavy disk IO

On 02/22/2016 10:43 AM, Chris Friesen wrote: Hi all, We've recently run into some interesting behaviour that I thought I should bring up to see if we want to do anything about it. Basically the problem seems to be that nova-compute is doing disk I/O from the main thread, and if it blocks then

Re: [openstack-dev] [api] header non proliferation (that naming thing, _again_)

On 02/22/2016 07:00 AM, Sean Dague wrote: On 02/21/2016 01:41 PM, Jay Pipes wrote: On 02/21/2016 12:50 PM, Chris Dent wrote: In a recent api-wg meeting I set forth the idea that it is both a bad idea to add lots of different headers and to add headers which have meaning in the name

Re: [openstack-dev] [nova][neutron] How would nova microversion get-me-a-network in the API?

On 02/22/2016 06:56 AM, Sean Dague wrote: On 02/19/2016 12:49 PM, John Garbutt wrote: Consider a user that uses these four clouds: * nova-network flat DHCP * nova-network VLAN manager * neutron with a single provider network setup * neutron where user needs to create their own network For

Re: [openstack-dev] [nova] A prototype implementation towards the "shared state scheduler"

Mitaka and Newton. That is the new game, so I'd love to see how you plan to interact with that. Ideally, I'd appreciate if Jay Pipes, Chris Dent and you could share your ideas because all of you are having great ideas to improve a current frustratin

Re: [openstack-dev] [api] header non proliferation (that naming thing, _again_)

On 02/21/2016 12:50 PM, Chris Dent wrote: In a recent api-wg meeting I set forth the idea that it is both a bad idea to add lots of different headers and to add headers which have meaning in the name of the header (rather than just the value). This proved to a bit confusing, so I was asked to

Re: [openstack-dev] [glance]one more use case for Image Import Refactor from OPNFV

IMO. I don't care to cater to these kinds of use cases. Best, -jay Best Regards Chaoyi Huang ( Joe Huang ) -Original Message----- From: Jay Pipes [mailto:jaypi...@gmail.com] Sent: Friday, February 19, 2016 10:43 AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [glance

Re: [openstack-dev] [glance]one more use case for Image Import Refactor from OPNFV

On 02/18/2016 08:34 PM, joehuang wrote: Hello, Glad to know that the “Image Import Refactor” is the essential BP in Mitaka. One more use case from OPNFV as following: In OPNFV, one deployment scenario is each data center will be deployed with independent OpenStack instance, but shared identity

Re: [openstack-dev] [nova] Update on scheduler and resource tracker progress

On 02/18/2016 07:16 PM, Clint Byrum wrote: Excerpts from Jay Pipes's message of 2016-02-18 11:33:04 -0800: I'm talking about the destination host selection process too, but I was just assuming you'd need compound indexes to make this really efficient, and I assumed that would mean more indexes

Re: [openstack-dev] [nova] Update on scheduler and resource tracker progress

On 02/12/2016 01:47 PM, Clint Byrum wrote: Excerpts from Jay Pipes's message of 2016-02-11 12:24:04 -0800: Hello all, Performance working group, please pay attention to Chapter 2 in the details section. Chapter 2 - Addressing performance and scale

[openstack-dev] [nova][neutron] Update on os-vif progress (port binding negotiation)

Hello Stackers, Apologies for the delay in getting this update email out to everyone. tl;dr - We are making good progress on the os-vif library and plugin system. We have immediate goals for Mitaka, all of which are in progress and on track to complete by Feature Freeze. details

Re: [openstack-dev] [all] [tc] unconstrained growth, why?

On 02/17/2016 09:28 AM, Doug Hellmann wrote: Excerpts from Chris Dent's message of 2016-02-17 11:30:29 +: A reason _I_[1] think we need to limit things is because from the outside OpenStack doesn't really look like anything that you can put a short description on. It's more murky than that

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

On 02/17/2016 09:30 AM, Doug Hellmann wrote: Excerpts from Mike Perez's message of 2016-02-17 03:21:51 -0800: On 02/16/2016 11:30 AM, Doug Hellmann wrote: So I think the project team is doing everything we've asked. We changed our policies around new projects to emphasize the social aspects

Re: [openstack-dev] [api] create openstack/service-registry

On 02/12/2016 07:48 AM, Everett Toews wrote: Hi All, I need to air a concern over the create openstack/service-registry [1] patch which aims to create an OpenStack service type registry project to act as a dedicated registry location for service types in OpenStack under the auspices of the API

Re: [openstack-dev] [all] tenant vs. project

On 02/12/2016 07:01 AM, Sean Dague wrote: Ok... this is going to be one of those threads, but I wanted to try to get resolution here. OpenStack is wildly inconsistent in it's use of tenant vs. project. As someone that wasn't here at the beginning, I'm not even sure which one we are supposed to

Re: [openstack-dev] [nova][neutron] How would nova microversion get-me-a-network in the API?

On 02/12/2016 02:18 PM, Doug Wiegley wrote: I thought one of the original notions behind this was to make ‘nova boot’ as simple as in the nova-net case, which would imply not needing to use —nic at all. I personally like the idea of the flag being for the no network case. This would be my

[openstack-dev] [nova] Update on scheduler and resource tracker progress

Hello all, Performance working group, please pay attention to Chapter 2 in the details section. tl;dr - At the Nova mid-cycle, we finalized decisions on a way forward in redesigning the way that resources are tracked in Nova. This work is a major undertaking and has implications for

Re: [openstack-dev] [gate] RFC dropping largeops tests

On 02/10/2016 07:33 AM, Sean Dague wrote: The largeops tests at this point are mostly finding out that some of our new cloud providers are slow - http://tinyurl.com/j5u4nf5 This is fundamentally a performance test, with timings having been tuned to pass 98% of the time on two clouds that were

Re: [openstack-dev] [all][tc] Proposal: Separate design summits from OpenStack conferences

On 02/08/2016 10:29 AM, Sean Dague wrote: On 02/08/2016 10:07 AM, Thierry Carrez wrote: Brian Curtin wrote: On Sun, Feb 7, 2016 at 3:07 PM, Jay Pipes <jaypi...@gmail.com> wrote: I would love to see the OpenStack contributor community take back the design summit to its original

Re: [openstack-dev] [all] Proposal for having a service type registry and curated OpenStack REST API

On 02/08/2016 07:13 AM, Sean Dague wrote: On 02/07/2016 08:30 AM, Jay Pipes wrote: On 02/04/2016 06:38 AM, Sean Dague wrote: What options do we have? 2) Have a registry of "common" names. Upside, we can safely use common names everywhere and not fear collision down the road. Dow

Re: [openstack-dev] [all][tc] Proposal: Separate design summits from OpenStack conferences

On 02/08/2016 09:03 AM, Fausto Marzi wrote: The OpenStack Summit is a great thing as it is now. It creates big momentum, it's a strong motivator for the engineers (as enjoy our time there) I disagree with you on this. The design summits are intended to be working events, not conference

Re: [openstack-dev] [all][tc] Proposal: Separate design summits from OpenStack conferences

On 02/08/2016 11:56 AM, James Bottomley wrote: On Mon, 2016-02-08 at 09:43 -0500, Jay Pipes wrote: On 02/08/2016 09:03 AM, Fausto Marzi wrote: The OpenStack Summit is a great thing as it is now. It creates big momentum, it's a strong motivator for the engineers (as enjoy our time there) I

[openstack-dev] [all] Proposal for having a service type registry and curated OpenStack REST API (was: [all] the trouble with names)

On 02/04/2016 06:38 AM, Sean Dague wrote: What options do we have? 2) Have a registry of "common" names. Upside, we can safely use common names everywhere and not fear collision down the road. Downside, yet another contention point. A registry would clearly be under TC administration,

[openstack-dev] [all][tc] Proposal: Separate design summits from OpenStack conferences

Hello all, tl;dr = I have long thought that the OpenStack Summits have become too commercial and provide little value to the software engineers contributing to OpenStack. I propose the following: 1) Separate the design summits from the conferences 2) Hold only a single OpenStack

Re: [openstack-dev] [nova] Migration progress

On 02/04/2016 11:02 PM, Bhandaru, Malini K wrote: Another thought, for such ephemeral/changing data, such as progress, why not save the information in the cache (and flush to database at a lower rate), and retrieve for display to active listeners/UI from the cache. Once complete or aborted, of

Re: [openstack-dev] Dynamically adding Extra Specs

Apologies for the delayed responses. Comments inline. On 01/27/2016 02:29 AM, Dhvanan Shah wrote: Hey Jay! Thanks for the clarification. There was another thing that I wanted to know, is there any provision to pass extra arguments or some extra specifications along with the VM request to nova.

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

On 02/05/2016 11:20 PM, Thomas Goirand wrote: IMO, a middleware to access proprietary SaaS may be fully open. But it's not OpenStack, as Sean Dague wrote. That's what I wrote in the paragraph following the one you quoted. :) -jay

Re: [openstack-dev] Announcing Ekko -- Scalable block-based backup for OpenStack

On 02/05/2016 09:58 AM, Sam Yaple wrote: Since Nova has no backup mechanism this is clearly a gap and that was the issue Ekko wants to solve. Nova has had backups for a long time: http://developer.openstack.org/api-ref-compute-v2.1.html#createBackup Best, -jay

Re: [openstack-dev] [all] the trouble with names

On 02/05/2016 08:38 AM, Dean Troyer wrote: On Fri, Feb 5, 2016 at 7:00 AM, Chris Dent > wrote: I think this discussion is dancing around the edges of a referendum on the "duplication" aspect of the big tent. It is also dancing

Re: [openstack-dev] Announcing Ekko -- Scalable block-based backup for OpenStack

On 02/05/2016 11:38 AM, Sam Yaple wrote: On Fri, Feb 5, 2016 at 3:31 PM, Jay Pipes <jaypi...@gmail.com <mailto:jaypi...@gmail.com>> wrote: On 02/05/2016 09:58 AM, Sam Yaple wrote: Since Nova has no backup mechanism this is clearly a gap and that was the issue

Re: [openstack-dev] [all] the trouble with names

#2 On 02/05/2016 02:24 PM, Sean Dague wrote: On 02/05/2016 02:09 PM, Jay Pipes wrote: On 02/05/2016 08:38 AM, Dean Troyer wrote: On Fri, Feb 5, 2016 at 7:00 AM, Chris Dent <cdent...@anticdent.org <mailto:cdent...@anticdent.org>> wrote: I think this discussion is dancing arou

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

On 02/05/2016 02:16 PM, Sean Dague wrote: On 02/05/2016 01:17 PM, Doug Hellmann wrote: So, is Poppy "open core"? Whether or not it is, I'm not sure how it is part of a Ubiquitous Open Source Cloud Platform. Because it only enables the use of commerical services. It's fine that it's open

Re: [openstack-dev] [Nova][Neutron] Scheduling with routed networks

about scheduling and routed networks in a new revision to the backlog spec [1] that I created a couple of weeks ago. I also captured my understanding of the discussion we had this afternoon as things were winding down. I remember Jay Pipes, Andrew Laskey, Dan Smith, John Garbutt, and Armando

Re: [openstack-dev] Announcing Ekko -- Scalable block-based backup for OpenStack

On 01/28/2016 06:03 AM, Steven Dake (stdake) wrote: The TC set precedent in this first competition-induced review which is worth a good read for other projects thinking of competing with existing projects of which there are already plenty in OpenStack.. https://review.openstack.org/206789

Re: [openstack-dev] [api] service type vs. project name for use in headers

On 01/27/2016 08:31 PM, Dean Troyer wrote: On Wed, Jan 27, 2016 at 1:47 PM, michael mccune > wrote: i am not convinced that we would ever need to have a standard on how these names are chosen for the header values, or if we would even need to

Re: [openstack-dev] [api] service type vs. project name for use in headers

Couldn't agree more, Chris. -jay On 01/28/2016 11:06 AM, Chris Dent wrote: On Wed, 27 Jan 2016, Dean Troyer wrote: I think we would be better served in selecting these things thinking about the API consumers first. We already have enough for them to wade through, the API-WG is making great

Re: [openstack-dev] Announcing Ekko -- Scalable block-based backup for OpenStack

On 01/27/2016 12:53 PM, gordon chung wrote: It makes for a crappy user experience. Crappier than the crappy user experience that OpenStack API users already have because we have done a crappy job shepherding projects in order to make sure there isn't overlap between their APIs (yes, Ceilometer

Re: [openstack-dev] [nova][neutron] Update on Neutron's rolling upgrade support?

Thanks very much for the update, Ihar, much appreciated! On 01/26/2016 01:19 PM, Ihar Hrachyshka wrote: Jay Pipes <jaypi...@gmail.com> wrote: Hey Sean, Tomorrow morning UTC, we'll be discussing Neutron topics at the Nova mid-cycle. Wondering if you might give us a quick status

[openstack-dev] [nova][neutron] Update on Neutron's rolling upgrade support?

Hey Sean, Tomorrow morning UTC, we'll be discussing Neutron topics at the Nova mid-cycle. Wondering if you might give us a quick status update on where we are with the Neutron devstack grenade jobs and what your work has uncovered on the Neutron side that might be possible to discuss in our

Re: [openstack-dev] Announcing Ekko -- Scalable block-based backup for OpenStack

On 01/26/2016 02:47 AM, Sam Yaple wrote: Hello Fausto, I am happy to have a conversation about this with you and the Freezer team. I have a feeling the current direction of Ekko will add many components that will not be needed for Freezer and vice-versa. Nevertheless, I am all about community!

Re: [openstack-dev] Announcing Ekko -- Scalable block-based backup for OpenStack

On 01/26/2016 03:28 PM, Sam Yaple wrote: On Tue, Jan 26, 2016 at 10:15 AM, Jay Pipes <jaypi...@gmail.com <mailto:jaypi...@gmail.com>> wrote: On 01/26/2016 02:47 AM, Sam Yaple wrote: Hello Fausto, I am happy to have a conversation about this with you and the

Re: [openstack-dev] Dynamically adding Extra Specs

Hi! Comments inline... On 01/22/2016 01:26 AM, Dhvanan Shah wrote: Hi, I had a few queries regarding adding extra specs for VM requests. According to my understanding if I want to add extra specs to requests then I need to change that in different flavors adding those capabilities by setting

Re: [openstack-dev] [Nova] sponsor some LVM development

On 01/22/2016 09:33 AM, Matthew Booth wrote: On Tue, Jan 19, 2016 at 8:47 PM, Fox, Kevin M > wrote: One feature I think we would like to see that could benefit from LVM is some kind of multidisk support with better fault tolerance

Re: [openstack-dev] [all][tc] Stabilization cycles: Elaborating on the idea to move it forward

On 01/20/2016 01:30 PM, Doug Hellmann wrote: Excerpts from Flavio Percoco's message of 2016-01-20 13:23:02 -0430: Greetings, At the Tokyo summit, we discussed OpenStack's development themes in a cross-project session. In this session a group of folks started discussing what topics the overall

Re: [openstack-dev] [Neutron] [Docs] Definition of a provider Network

On 01/19/2016 02:33 AM, Andreas Scheuring wrote: Hi everybody, I stumbled over a definition that explains the difference between a Provider network and a self service network. [1] To summarize it says: - Provider Network: primarily uses layer2 services and vlan segmentation and cannot be used

Re: [openstack-dev] [Oslo] Improving deprecated options identification and documentation

On 01/14/2016 11:45 AM, Ronald Bradford wrote: Presently the oslo.config Opt class has the attributes deprecated_for_removal and deprecated_reason [1] I would like to propose that we use deprecated_reason (at a minimum) to detail in what release an option was deprecated in, and what release it

Re: [openstack-dev] [Nova] Get-validserver-state default policy

On 01/15/2016 01:50 AM, Juvonen, Tomi (Nokia - FI/Espoo) wrote: This API change was agreed is the spec review to be “rule: admin_or_owner”, but during code review “rule: admin_api” was also wanted. Link to spec to see details what this is about (https://review.openstack.org/192246/):

Re: [openstack-dev] App dev guides update [nova] [keystone] [cinder] [swift] [glance] [neutron] [trove] [heat] [manila] [ceilometer] [sahara] [senlin]

Anne, thank you for this update. And thank you to the contributors who improved the SDK and developer guide documentation. Fantastic work, all of you! Best, -jay On 01/13/2016 12:18 AM, Anne Gentle wrote: Hi all, I wanted to be sure to post to the dev, docs, and user mailing lists about the

Re: [openstack-dev] Shovel (RackHD/OpenStack)

On 01/13/2016 03:28 PM, Keedy, Andre wrote: Hi All, I’m pleased to announce a new application called ‘Shovel ‘that is now available in a public repository on GitHub (https://github.com/keedya/Shovel). Shovel is a server with a set of APIs that wraps around RackHD/Ironic’s existing APIs allowing

Re: [openstack-dev] [doc] [api] Vision and changes for OpenStack API Guides

On 01/08/2016 04:39 PM, Anne Gentle wrote: Hi all, With milestone 2 coming next week I want to have a chat about API guides, API reference information, and the http://developer.openstack.org site. We have a new tool, fairy-slipper [1], yep you read that right, that can migrate files from WADL

Re: [openstack-dev] [all] re-introducing twisted to global-requirements

On 01/08/2016 02:52 PM, Jim Rollenhagen wrote: On Fri, Jan 08, 2016 at 02:08:04PM -0500, Jay Pipes wrote: On 01/07/2016 07:38 PM, Jim Rollenhagen wrote: snippity snip snip We haven't made it a dep for anything yet, only added to g-r. According to Dims, not to g-r, but to u-c, right Dims

Re: [openstack-dev] [all] re-introducing twisted to global-requirements

On 01/07/2016 07:38 PM, Jim Rollenhagen wrote: On Thu, Jan 07, 2016 at 07:18:15PM -0500, Jay Pipes wrote: On 01/07/2016 06:42 PM, Jim Rollenhagen wrote: On Thu, Jan 07, 2016 at 03:32:39PM -0500, Jay Pipes wrote: On 01/07/2016 03:01 PM, Jim Rollenhagen wrote: On Thu, Jan 07, 2016 at 02:41

Re: [openstack-dev] [all] re-introducing twisted to global-requirements

On 01/07/2016 06:12 PM, Ben Meyer wrote: On 01/07/2016 03:32 PM, Jay Pipes wrote: On 01/07/2016 03:01 PM, Jim Rollenhagen wrote: On Thu, Jan 07, 2016 at 02:41:12PM -0500, Sean Dague wrote: On 01/07/2016 02:09 PM, Jim Rollenhagen wrote: Hi all, A change to global-requirements[1] introduces

Re: [openstack-dev] [all] re-introducing twisted to global-requirements

On 01/07/2016 06:42 PM, Jim Rollenhagen wrote: On Thu, Jan 07, 2016 at 03:32:39PM -0500, Jay Pipes wrote: On 01/07/2016 03:01 PM, Jim Rollenhagen wrote: On Thu, Jan 07, 2016 at 02:41:12PM -0500, Sean Dague wrote: On 01/07/2016 02:09 PM, Jim Rollenhagen wrote: Hi all, A change to global

Re: [openstack-dev] [OpenStack-Infra] [infra][stackalytics] some projects not visible in stackalytics now

Hi everyone, and happy New Year! Ilya and a number of other Mirantis folks are currently on holiday until the 10th. I'm sure he will address the issues promptly upon his return. All the best, -jay On 01/07/2016 09:34 AM, Michał Dulko wrote: On 01/07/2016 02:59 PM, Shake Chen wrote: seem

Re: [openstack-dev] [all] re-introducing twisted to global-requirements

On 01/07/2016 03:01 PM, Jim Rollenhagen wrote: On Thu, Jan 07, 2016 at 02:41:12PM -0500, Sean Dague wrote: On 01/07/2016 02:09 PM, Jim Rollenhagen wrote: Hi all, A change to global-requirements[1] introduces mimic, which is an http server that can mock various APIs, including nova and ironic,

Re: [openstack-dev] Nova scheduler startup when database is not available

On 12/24/2015 02:30 PM, Clint Byrum wrote: This is entirely philosophical, but we should think about when it is appropriate to adopt which mode of operation. There are basically two ways being discussed: 1) Fail fast. 2) Retry forever. Fail fast pros- Immediate feedback for problems, no

Re: [openstack-dev] [neutron] Query about re-directing incoming traffic.

On 12/28/2015 11:13 AM, Vikram Choudhary wrote: Hi All, We want to redirect all / some specific incoming traffic to a particular neutron port, where a network function is deployed. [Network function could be DPI, IDS, Firewall, Classifier, etc]. In this regard, we have few queries: 1. How we

Re: [openstack-dev] Nova scheduler startup when database is not available

On 12/23/2015 08:35 PM, Morgan Fainberg wrote: On Wed, Dec 23, 2015 at 10:32 AM, Jay Pipes <jaypi...@gmail.com <mailto:jaypi...@gmail.com>> wrote: On 12/23/2015 12:27 PM, Lars Kellogg-Stedman wrote: I've been looking into the startup constraints involved when

Re: [openstack-dev] Nova scheduler startup when database is not available

On 12/23/2015 12:27 PM, Lars Kellogg-Stedman wrote: I've been looking into the startup constraints involved when launching Nova services with systemd using Type=notify (which causes systemd to wait for an explicit notification from the service before considering it to be "started". Some

Re: [openstack-dev] [gate] any project using olso.db test_migrations is currently blocked

On 12/16/2015 01:03 PM, Carl Baldwin wrote: On Wed, Dec 16, 2015 at 10:04 AM, Mike Bayer wrote: Instead of just breaking the world, and burning 10s to 100 engineer hours in redo tests and investigating and addressing the break after the fact. We shouldn't let this happen

Re: [openstack-dev] [OpenStack-Infra] Gerrit Upgrade to ver 2.11, completed.

On 12/17/2015 10:17 PM, Brian Haley wrote: On 2015-12-16 16:24, openstack-dev-requ...@lists.openstack.org wrote: Thanks to everyone for their patience while we upgraded to Gerrit 2.11. I'm happy to announce that we were able to successfully completed this task at around 21:00 UTC. You may

Re: [openstack-dev] [glance][keystone][artifacts] Service Catalog name for Glance Artifact Repository API

On 12/11/2015 08:25 PM, Alexander Tivelkov wrote: Hi folks! As it was decided during the Mitaka design summit, we are separating the experimental Artifact Repository API from the main Glance API. This API will have a versioning sequence independent from the main Glance API and will be run as a

Re: [openstack-dev] [glance][keystone][artifacts] Service Catalog name for Glance Artifact Repository API

On 12/11/2015 08:51 PM, Alexander Tivelkov wrote: Hi Steve, Thanks for the note on port. Any objections on glare using 9494 then? Anyone? Yes, I object to 9494. There should be no need to use any custom port for Glare's API service. Just use 80/443, which are HTTP(S)'s standard ports. It

Re: [openstack-dev] [neutron] Linux Bridge CI is now a voting gate job

On 12/08/2015 07:54 PM, Andreas Scheuring wrote: Great work! Indeed, Sean, fantastic effort getting this done. :) -jay On Mo, 2015-12-07 at 21:05 +, Sean M. Collins wrote: >It's been a couple months - the last time I posted on this subject we >were still working on getting Linux Bridge

Re: [openstack-dev] [kolla][nova] Orchiestrated upgrades in kolla

On 12/04/2015 11:50 PM, Michał Jastrzębski wrote: Hey guys, Orchiestrated upgrades is one of our highest priorities for M in kolla, so following up after discussion on summit I'd like to suggest an approach: Instead of creating playbook called "upgrade my openstack" we will create "upgrade my

Re: [openstack-dev] [kolla][nova] Orchiestrated upgrades in kolla

On 12/07/2015 04:28 AM, Michał Jastrzębski wrote: On 6 December 2015 at 09:33, Jay Pipes <jaypi...@gmail.com> wrote: On 12/04/2015 11:50 PM, Michał Jastrzębski wrote: Hey guys, Orchiestrated upgrades is one of our highest priorities for M in kolla, so following up after discussion on

Re: [openstack-dev] [all] [tc] [ironic] Picking an official name for a subproject (ironic-inspector in this case)

Count me in for being there. On 12/04/2015 09:29 PM, Jeremy Stanley wrote: On 2015-12-04 16:30:17 +0100 (+0100), Thierry Carrez wrote: My take is to rename ironic-inspector to clouseau, the ironic inspector from the Pink Panther series. If that comes to pass then count me in for the next

Re: [openstack-dev] [all] [tc] [ironic] Picking an official name for a subproject (ironic-inspector in this case)

On 12/04/2015 04:45 PM, Dmitry Tantsur wrote: 1. "baremetalintrospection" - named after the process we implement 2. "baremetalinspector" - using our code name after the official ironic project name. baremetal-inspection is my vote. I believe Pavlo will soon be proposing a hardware-composition

Re: [openstack-dev] [swift] [oslo.messaging] [fuel] [ha] Is Swift going to support oslo.messaging?

On 12/01/2015 08:17 AM, Richard Hawkins wrote: ​Is it possible to write the functionality you desire in your own middleware for Swift that lives outside of the Swift code? I would favor that approach for the following reasons: * You would have more control over code/changes so your middleware

Re: [openstack-dev] [keystone] Diagnostic APIs for Keystone

On 11/23/2015 10:07 PM, Adam Young wrote: What kind of diagnostic tooling do we need? I know the basics: If I have a known good user in LDAP, can they . This is the first thing, and it can be done by asking for an unscoped token. Certainly if you have a known good user in LDAP, they can .

Re: [openstack-dev] [Fuel][CI] recheck/reverify support for Fuel CI jobs

Why not "recheck fuel" to align with how other OpenStack 3rd party CI hooks work? See: recheck xen-server or recheck hyper-v Best, -jay On 11/20/2015 05:24 AM, Igor Belikov wrote: Alexey, First of all, “refuel” sounds very cool. Thanks for raising this topic, I would like to hear more

<    2   3   4   5   6   7   8   9   10   11   >