[openstack-dev] [horizon] patch about "pagination info at top and bottom of table"

Hi All, This is my first time to contribute code to openstack. I made a patch for "pagination info at top and bottom of table". https://review.openstack.org/#/c/183963/ Cindy said: "Tried this out on the flavors table. Set page number to 2, but it still displayed all flavors." But there are no w

[openstack-dev] [all] cross project communication: Return request-id to caller

Hi Devs, Each OpenStack service sends a request ID header with HTTP responses. This request ID can be useful for tracking down problems in the logs. However, when operation crosses service boundaries, this tracking can become difficult, as each service has its own request ID. Request ID is not

[openstack-dev] [Fuel] [Plugins] modification disk configuration

Hi folks In some plugin such as the nfs for glance or nova and the netapp for cinder, we have replaced the lvm by nfs mount point. However we still have partition setup for glance, cinder, nova which are not used anymore. we can still int the disk configure allocate the minimum space to these par

[openstack-dev] Invitation to 2nd China OpenStack Hackathon

Hi, OpenStack developers. Huawei and Intel are pleased to announce the 2nd China OpenStack bugfest hackathon! This time around, we are inviting contributors in China to help make the Liberty release a grand success. https://wiki.openstack.org/wiki/2015_9_PRC_Hackathon When: August 19 to 21 (jus

Re: [openstack-dev] oslo.vmware release 0.13.0 (liberty)

Hi, I prefer the patched posted by Sabari. The patch has two changes: 1. It fixes unit tests 2. In the even that an instance spawn fails then it catches an exception to warn the admin that the guestId may be invalid. The only degradation may be that the warning will no longer be there. I t

Re: [openstack-dev] [Glance] [all] Liberty summit: Updates in Glance

Jesse, you beat me on this one :) On 26/05/15 13:54 -0400, Nikhil Komawar wrote: Thank you Jesse for your valuable input (here and at the summit) as well as intent to clarify the discussion. Just trying to ensure people are aware about the EXPERIMENTAL nature of the v3 API and reasons behind it

Re: [openstack-dev] Redis as Messaging System

Excerpts from Ryan Brown's message of 2015-05-26 05:48:14 -0700: > Zaqar provides an option to use Redis as a backend, and Zaqar provides > pubsub messaging. > Please please please do not mistake under-the-cloud messaging, which oslo.messaging is intended to facilitate, for user-facing messaging

[openstack-dev] [packaging] Adding packaging as an OpenStack project

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi all, tl;dr: - - We'd like to push distribution packaging of OpenStack on upstream gerrit with reviews. - - The intention is to better share the workload, and improve the overall QA for packaging *and* upstream. - - The goal is *not* to publish pa

Re: [openstack-dev] [Zaqar][all] Zaqar will stay... Lots of work ahead

Hi, Thanks for writing down the summit notes Flavio. I'm really glad that there are so many great features to work on in this cycle. I'll be there to help as much as possible with every one of them. I would also like to add that we will be doing a lot of work in the client side, updating it to co

Re: [openstack-dev] [Fuel] [Plugins] modification disk configuration

Hi Samuel, Currently it's not possible to change partitioning schema of Fuel roles, but you can change partitioning in post_deployment tasks of your plugin. Thanks, On Wed, May 27, 2015 at 9:38 AM, Samuel Bartel wrote: > Hi folks > > In some plugin such as the nfs for glance or nova and the n

Re: [openstack-dev] [packaging] Adding packaging as an OpenStack project

Great initiative, IMO. I favour going directly to openstack-, rather than stackforge-, for the migration reason that you mention.   Original Message   From: Thomas Goirand Sent: Wednesday, 27 May 2015 09:17 To: OpenStack Development Mailing List (not for usage questions) Reply To: OpenStack Devel

[openstack-dev] [nova] Availability of device names for operations with volumes and BDM and other features.

Hi all, I'd like to bring up this matter again, although it was at some extent discussed during the recent summit. The problem arises from the fact that the functionality exposing device names for usage through public APIs is deteriorating in nova. It's being deliberately removed because as

Re: [openstack-dev] [Ironic][oslo] Stepping down from oslo-ironic liaison

Hi, By the way, who is the "oslo liaison" for nova? If there is nobody, I would like to take this position. Victor Le 25/05/2015 18:45, Ghe Rivero a écrit : My focus on the Ironic project has been decreasing in the last cycles, so it's about time to relinquish my position as a oslo-ironic li

Re: [openstack-dev] [Fuel] Setting cluster status when provisioning a node

Oleg, Thanks for the feedback. I have the following as a response: 1. This spec is just an excerpt for scoping in the proposed improvement to the 7.0 release plan. If it get’s scope the full specification will go through a standard review process so it will be possible to discuss names along wi

Re: [openstack-dev] [Ironic][oslo] Stepping down from oslo-ironic liaison

Tan, Awesome, please update the page here: https://wiki.openstack.org/wiki/CrossProjectLiaisons thanks, dims On Tue, May 26, 2015 at 9:04 PM, Tan, Lin wrote: > Hi Doug and guys, > > I would like to work as oslo-ironic liasison to sync Ironic with Oslo. > I will attend the regular Oslo meeting f

Re: [openstack-dev] [Ironic][oslo] Stepping down from oslo-ironic liaison

Victor, Nice, yes, Joe was the liaison with Nova so far. Yes, please go ahead and add your name in the wiki for Nova as i believe Joe is winding down the oslo liaison as well. https://wiki.openstack.org/wiki/CrossProjectLiaisons#Oslo thanks, dims On Wed, May 27, 2015 at 5:12 AM, Victor Stinner

[openstack-dev] [nova-docker] Looking for volunteers to take care of nova-docker

Hi all, So the feedback during the Vancouver summit from some of the nova cores was that, we needed volunteers to take care of the nova-docker driver before it can be considered to merge in the Nova tree. As an exercise is resposibility, we need people who can reinstate the nova-docker non-voting

Re: [openstack-dev] [oslo.messaging][zeromq] Next step

Hi, I'll try to address the question about Proxy process. AFAIK there is no way yet in zmq to bind more than once to a specific port (e.g. tcp://*:9501). Apparently we can: socket1.bind('tcp://node1:9501') socket2.bind('tcp://node2:9501') but we can not: socket1.bind('tcp://*:9501') socket

Re: [openstack-dev] [Neutron]: DVR Presentation slides from the Vancouver summit

Thanks for the share.. :) From: Vasudevan, Swaminathan (PNB Roseville) [mailto:swaminathan.vasude...@hp.com] Sent: Tuesday, May 26, 2015 11:20 PM To: OpenStack Development Mailing List (openstack-dev@lists.openstack.org) Subject: [openstack-dev] [Neutron]: DVR Presentation slides from the Vancouv

Re: [openstack-dev] [neutron] - dnsmasq 'dhcp-authoritative' option broke multiple DHCP servers

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 05/26/2015 11:53 PM, Kevin Benton wrote: >> Actually, that approach was initially taken for bug 1345947, but > then the patch was abandoned to be replaced with a simpler - > --dhcp-authoritative approach that ended up with unexpected NAKs > for

Re: [openstack-dev] Redis as Messaging System

On 05/27/2015 04:12 AM, Clint Byrum wrote: > > Excerpts from Ryan Brown's message of 2015-05-26 05:48:14 -0700: >> Zaqar provides an option to use Redis as a backend, and Zaqar provides >> pubsub messaging. >> > > Please please please do not mistake under-the-cloud messaging, which > oslo.messagi

Re: [openstack-dev] [Glance] [all] Liberty summit: Updates in Glance

> -Original Message- > From: Flavio Percoco [mailto:fla...@redhat.com] > Sent: 27 May 2015 00:58 > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] [Glance] [all] Liberty summit: Updates in Glance > > Jesse, you beat me on this one :) > > On

[openstack-dev] [Manila] Expected Manila behavior for creation of share from snapshot

Hi everyone, At last IRC meeting was raised following question: "Whether Manila should allow us to create shares from snapshots with different share networks or not?" What do users/admins expect in that case?

Re: [openstack-dev] [packaging] Adding packaging as an OpenStack project

Many thanks to Thomas and the other packagers for a great discussion at the summit and this fast follow-up, explained well. Looking forward to seeing what can be achieved! On 27/05/15 16:14, Thomas Goirand wrote: > Hi all, > > tl;dr: > - We'd like to push distribution packaging of OpenStack on up

[openstack-dev] [oslo] Updates from the Summit

Hi Team, Here are the etherpads from the summit[1]. Some highlights are as follows: Oslo.messaging : Took status of the existing zmq driver, proposed a new driver in parallel to the existing zmq driver. Also looked at possibility of using Pika with RabbitMQ. Folks from pivotal promised to help wit

Re: [openstack-dev] [openstackclient] Use and practices of --format shell for defining individual variables

Thanks Doug, I knew there would be a more definitive and simple use. eval is that way! Ronald Ronald Bradford Web Site: http://ronaldbradford.com LinkedIn: http://www.linkedin.com/in/ronaldbradford Twitter:@RonaldBradford Skype: RonaldBradford GTalk

Re: [openstack-dev] [Fuel] Setting cluster status when provisioning a node

Excellent, nice to know that we're on the same page about this. Thank you! -- Best regards, Oleg Gelbukh On Wed, May 27, 2015 at 12:22 PM, Roman Prykhodchenko wrote: > Oleg, > > Thanks for the feedback. I have the following as a response: > > 1. This spec is just an excerpt for scoping in the

Re: [openstack-dev] [Glance] Liberty Priorities

On 26/05/15 17:14 +, Jesse Cook wrote: I created an etherpad with priorities the RAX team I work on will be focusing on based on our talks at the summit: https://etherpad.openstack.org/p/ liberty-priorities-rax. Input, guidance, feedback, and collaboration is not just welcome, it is encourage

Re: [openstack-dev] [Fuel] Setting cluster status when provisioning a node

Thank you Roman for driving this! Full list of nodes statuses is: NODE_STATUSES = Enum( 'ready', 'discover', 'provisioning', 'provisioned', 'deploying', 'error', 'removing', ) We could combine 'provisioning', 'provisioned', 'deploying' into one maybe as cluster has on

Re: [openstack-dev] [packaging] Adding packaging as an OpenStack project

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 05/27/2015 10:14 AM, Thomas Goirand wrote: > Hi all, > > tl;dr: - We'd like to push distribution packaging of OpenStack on > upstream gerrit with reviews. - The intention is to better share > the workload, and improve the overall QA for packaging

[openstack-dev] [nova] "correct" API for getting image metadata for an instance ?

As part of the work to object-ify the image metadata dicts, I'm looking at the current way the libvirt driver fetches image metadata for an instance, in cases where the compute manager hasn't already passed it into the virt driver API. I see 2 methods that libvirt uses to get the image metadata -

Re: [openstack-dev] [Glance] Liberty Priorities

I added a few metadata on the etherpad and linked it to main Glance etherpad here https://etherpad.openstack.org/p/liberty-glance . We can collaborate better across different product groups on image conversion as well as other subjects therein. Cheers, Nikhil On 5/27/15 9:23 AM, Flavio Percoc

[openstack-dev] [all] IRC meetings agenda is now driven from Gerrit !

Hi everyone, TL;DR: IRC meetings list now lives at http://eavesdrop.openstack.org ical file with meetings is now at http://eavesdrop.openstack.org/irc-meetings.ical Long version: I'm very pleased to announce that we solved a long-standing pain in how we organize the IRC meetings agenda. We used

[openstack-dev] [fuel][plugin][astute][UI] DSL restrictions with an action: "none" to display a message?

Folks, With our plugin UI definition [0] I'm trying to use a restriction with 'action: "none"' to display a message but nothing happen. According to the doc this should just works [1], btw I didn't find any similar example on fuel-web/nailgun. So I guess I hit a bug here or smth is wrong with plu

Re: [openstack-dev] [all] cross project communication: Return request-id to caller

Excerpts from Kekane, Abhishek's message of 2015-05-27 07:06:56 +: > Hi Devs, > > Each OpenStack service sends a request ID header with HTTP responses. This > request ID can be useful for tracking down problems in the logs. However, > when operation crosses service boundaries, this tracking

Re: [openstack-dev] [Glance] [all] Liberty summit: Updates in Glance

I kinda agree with all 3 of you, possibly because there are Grey areas on how best we can actually do this. We are talking about one cycle ahead to the very least. While that is a great thing to do, I think we should focus on making the current Artifacts implementation stable & bring it to a st

Re: [openstack-dev] [nova-docker] Looking for volunteers to take care of nova-docker

Bich, Sure thing, just start on #nova-docker irc channel and we can talk there -- dims On Wed, May 27, 2015 at 11:28 AM, Bich Le wrote: > I'd like to contribute. > But I may need some help / pointers in getting started (I have experience > with running and hacking openstack, but this would be m

Re: [openstack-dev] [all] cross project communication: Return request-id to caller

On 5/27/15, 10:15, "Doug Hellmann" wrote: >Excerpts from Kekane, Abhishek's message of 2015-05-27 07:06:56 +: >> Hi Devs, >> >> Each OpenStack service sends a request ID header with HTTP responses. >>This request ID can be useful for tracking down problems in the logs. >>However, when oper

Re: [openstack-dev] [stable] stable/kilo and stable/juno blocked on zake 0.2.2 release

On 5/27/2015 10:57 AM, Matt Riedemann wrote: All changes to stable/kilo (and probably stable/juno) are broken due to a zake 0.2.2 release today which excludes kazoo 2.1. tooz 0.12 requires uncapped zake and kazoo so it's pulling in kazoo 2.1 which zake 0.2.2 doesn't allow. ceilometer pulls in

[openstack-dev] [stable] stable/kilo and stable/juno blocked on zake 0.2.2 release

All changes to stable/kilo (and probably stable/juno) are broken due to a zake 0.2.2 release today which excludes kazoo 2.1. tooz 0.12 requires uncapped zake and kazoo so it's pulling in kazoo 2.1 which zake 0.2.2 doesn't allow. ceilometer pulls in tooz. There is no stable/juno branch for to

Re: [openstack-dev] [stable] stable/kilo and stable/juno blocked on zake 0.2.2 release

On 5/27/2015 10:58 AM, Matt Riedemann wrote: On 5/27/2015 10:57 AM, Matt Riedemann wrote: All changes to stable/kilo (and probably stable/juno) are broken due to a zake 0.2.2 release today which excludes kazoo 2.1. tooz 0.12 requires uncapped zake and kazoo so it's pulling in kazoo 2.1 whic

Re: [openstack-dev] [fuel][plugin][astute][UI] DSL restrictions with an action: "none" to display a message?

Hi, That's an issue of course. Settings definitely should support 'none' action in their restrictions. Thank you for catching it! And we've prepared the *fix*: https://review.openstack.org/#/c/186049/. It should be merged ASAP. Best regards, Julia On Wed, May 27, 2015 at 5:57 PM, Swann Croiset

Re: [openstack-dev] [Horizon] dashboard-app split in horizon

Yes Rob, you are correct. ToastService was something Cindy wrote to replace horizon.alert (aka messages). We can't remove it because legacy still uses it.-"Rob Cresswell (rcresswe)" wrote: -To: "OpenStack Development Mailing List (not for usage questions)" From: "Rob Cresswell (rcresswe)"

Re: [openstack-dev] [Zaqar][all] Zaqar will stay... Lots of work ahead

On 05/26/2015 09:29 AM, Flavio Percoco wrote: > Greetings, > > TL;DR: Thanks everyone for your feedback. Based on the discussed plans > at the summit - I'll be writing more about these later - Zaqar will > stick around and play its role in the community. > > Summit Summary > == > > I

[openstack-dev] [DevStack][Neutron] PHYSICAL_NETWORK vs. PUBLIC_PHYSICAL_NETWORK - rant

Hi, We have a *lot* of configuration knobs in DevStack for Neutron. I am not a smart man, so I think we may need to wrap our arms around this and simplify. Here's an example. Can you tell me the difference between PUBLIC_PHYSICAL_NETWORK and PHYSICAL_NETWORK? I had a local.conf with the follo

Re: [openstack-dev] [all] IRC meetings agenda is now driven from Gerrit !

On Wed, May 27, 2015 at 10:53:38AM EDT, Thierry Carrez wrote: > For future meeting additions and schedule modifications, please propose > changes to openstack-infra/irc-meetings via Gerrit ! Fantastic work everyone! I knew this was always a tough manual task, it's great to see it finally become au

[openstack-dev] [Swift] dropping Py26 support

All, A month ago I sent a question out asking "should we drop Py26 support in Swift?". I heard zero people asking us to keep support for it on the mailing list. At the summit, we brought it up again with operators, and the consensus of the room was to drop support. What does this mean? Simply,

Re: [openstack-dev] [Zaqar][all] Zaqar will stay... Lots of work ahead

Excerpts from Flavio Percoco's message of 2015-05-26 01:28:06 -0700: > Greetings, > > TL;DR: Thanks everyone for your feedback. Based on the discussed plans > at the summit - I'll be writing more about these later - Zaqar will > stick around and play its role in the community. > > Summit Summary

Re: [openstack-dev] [oslo] Updates from the Summit

Thanks dims! Good write up, Other things I noted (more controversial ones); is that we need to come up with a concurrency strategy (and/or guidelines, and/or best practices). At least I feel this will be a way that works and imho implies that one concurrency strategy will (likely) not fit eve

Re: [openstack-dev] [all] cross project communication: Return request-id to caller

On 5/27/15 3:06 AM, Kekane, Abhishek wrote: Hi Devs, Each OpenStack service sends a request ID header with HTTP responses. This request ID can be useful for tracking down problems in the logs. However, when operation crosses service boundaries, this tracking can become difficult, as each s

Re: [openstack-dev] [Zaqar][all] Zaqar will stay... Lots of work ahead

On 27/05/15 12:42, Clint Byrum wrote: == Crazy idea section == One thing I never had a chance to discuss with any of the Zaqar devs that I would find interesting is an email-only backend for Zaqar. Basically make Zaqar an HTTP-to-email gateway. There are quite a few hyper-scale options for SMTP

Re: [openstack-dev] [kolla][infra] Functional gate expansion

On 5/26/15, 2:16 PM, "jpee...@redhat.com" wrote: >(Trying to summarize discussions from earlier on IRC) > >On Mon, May 25, 2015 at 06:54:43PM +, Steven Dake (stdake) wrote: >>Hey fellow Kolla devs, >> >>With Sam¹s recent change to add build from source as an option and build >>from Debuntia

Re: [openstack-dev] [oslo] Updates from the Summit

Josh, thanks. yes, the kombu vs pika is just a research thing someone should look at. no blueprint, no spec, so not approved in anyway :) -- dims On Wed, May 27, 2015 at 1:24 PM, Joshua Harlow wrote: > Thanks dims! > > Good write up, > > Other things I noted (more controversial ones); is that w

Re: [openstack-dev] oslo.vmware release 0.13.0 (liberty)

On Wed, May 27, 2015 at 12:54 AM, Gary Kotton wrote: > Hi, > I prefer the patched posted by Sabari. The patch has two changes: > >1. It fixes unit tests >2. In the even that an instance spawn fails then it catches an >exception to warn the admin that the guestId may be invalid. The o

Re: [openstack-dev] [nova] Availability of device names for operations with volumes and BDM and other features.

On 05/27/2015 09:47 AM, Alexandre Levine wrote: > Hi all, > > I'd like to bring up this matter again, although it was at some extent > discussed during the recent summit. > > The problem arises from the fact that the functionality exposing device > names for usage through public APIs is deteriora

[openstack-dev] Fwd: ERROR (BadRequest): Block Device Mapping is Invalid: failed to get volume

Upgraded to Juno and now can't nova boot: [root@openstack nova(keystone)]# nova boot --flavor 3 --boot-volume a9f8f997-bc87-4f39-9f9f-0b41169a0256 radius --nic net-id=b2324538-26ee-4d06-bccd-0ef2f6778f6b,v4-fixed-ip=10.71.0.161 ERROR (BadRequest): Block Device Mapping is Invalid: failed to get volu

Re: [openstack-dev] [ceilometer][all] Scalable metering

On Tue, May 26, 2015 at 6:03 PM, gordon chung wrote: > hi Tim, > > we're still doing some investigation but we're tracking/discussing part of > the polling load issue here: https://review.openstack.org/#/c/185084/ > > we're open to any ideas -- especially from nova api et al experts. > > So I agr

Re: [openstack-dev] [Nova] Using depends-on for patches which require an approved spec

I think this will help because it separates the judgement of "is this code good enough to land" from the project and release coordination of "should this code land now". I've been floating the idea of separating +2 and +A powers for the same purpose: free up many of the technical reviewers from ha

Re: [openstack-dev] [Nova] Using depends-on for patches which require an approved spec

On Tue, May 26, 2015 at 8:45 AM, Daniel P. Berrange wrote: > On Fri, May 22, 2015 at 02:57:23PM -0700, Michael Still wrote: > > Hey, > > > > it would be cool if devs posting changes for nova which depend on us > > approving their spec could use Depends-On to make sure their code > > doesn't land

Re: [openstack-dev] [Zaqar][all] Zaqar will stay... Lots of work ahead

Excerpts from Zane Bitter's message of 2015-05-27 10:40:48 -0700: > On 27/05/15 12:42, Clint Byrum wrote: > > > > == Crazy idea section == > > > > One thing I never had a chance to discuss with any of the Zaqar devs that > > I would find interesting is an email-only backend for Zaqar. Basically > >

Re: [openstack-dev] [Manila] Question to driver maintainers

Hi Igor, The 3PAR can extend a share without loss of connectivity. Regards, markstur From: yang, xing [mailto:xing.y...@emc.com] Sent: Friday, May 22, 2015 3:43 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Manila] Question to driver maintain

Re: [openstack-dev] oslo.vmware release 0.13.0 (liberty)

Joe, Given that the code once lived in nova and the team across has spent quite a bit of time to turn it into a library which at last count was adopted by 6 projects at least. i'd like to give the team some credit. openstack/ceilometer/test-requirements.txt:oslo.vmware>=0.11.1 # Apach

Re: [openstack-dev] oslo.vmware release 0.13.0 (liberty)

On Wed, May 27, 2015 at 11:23 AM, Davanum Srinivas wrote: > Joe, > > Given that the code once lived in nova and the team across has spent > quite a bit of time to turn it into a library which at last count was > adopted by 6 projects at least. i'd like to give the team some credit. > Agreed, the

[openstack-dev] [release][oslo][stable] too 0.12.1 (juno)

We are eager to announce the release of: tooz 0.12.1: Coordination library for distributed systems. This release is part of the juno stable release series. With source available at: http://git.openstack.org/cgit/openstack/tooz For more details, please see the git log history below and:

Re: [openstack-dev] [ceilometer][all] Scalable metering

> > So I agree doing lots of naive polling can lead to issues on even the > fastest of APIs, but are there any bugs about this that were opened > against nova? At the very least nova should investigate why the > specific calls are so slow and see if we what we can do to make them at > least a

Re: [openstack-dev] [Ironic][oslo] Stepping down from oslo-ironic liaison

On Wed, May 27, 2015 at 3:20 AM, Davanum Srinivas wrote: > Victor, > > Nice, yes, Joe was the liaison with Nova so far. Yes, please go ahead > and add your name in the wiki for Nova as i believe Joe is winding > down the oslo liaison as well. > https://wiki.openstack.org/wiki/CrossProjectLiaisons

Re: [openstack-dev] [all] cross project communication: Return request-id to caller

On Wed, May 27, 2015 at 10:31 AM, Mike Bayer wrote: > > > On 5/27/15 3:06 AM, Kekane, Abhishek wrote: > > Hi Devs, > > > > Each OpenStack service sends a request ID header with HTTP responses. This > request ID can be useful for tracking down problems in the logs. However, > when operation cross

Re: [openstack-dev] [all] cross project communication: Return request-id to caller

On Wed, May 27, 2015 at 12:06 AM, Kekane, Abhishek < abhishek.kek...@nttdata.com> wrote: > Hi Devs, > > > > Each OpenStack service sends a request ID header with HTTP responses. This > request ID can be useful for tracking down problems in the logs. However, > when operation crosses service bound

Re: [openstack-dev] [ceilometer][all] Scalable metering

We've noticed the load on the Nova and Keystone APIs. It may well be that there is an increased load on the hypervisor but this is distributed and thus we might not have seen it. The API impact was significant a factor of 14x increase in API call rate (http://openstack-in-production.blogsp

Re: [openstack-dev] [ceilometer][all] Scalable metering

cool cool. we'll work against that. i want to point out we added a caching mechanism in Juno which i hope helps with the Nova issue -- basically we cache some of the secondary calls we make when gathering information. https://github.com/openstack/ceilometer/commit/4863fc95bcbbb6f7dbe7e48ef13f370

[openstack-dev] [app-catalog] [infra] App Catalog infrastructure integration (was: App Catalog next steps)

[Operators ML dropped from Cc as my reply is off-topic there] On 2015-05-22 21:06:32 -0700 (-0700), Christopher Aedo wrote: [...] > - I'll be working with the OpenStack infra team to get the server > and CI set up in their environment (though that work will not > impact the catalog as it stands to

Re: [openstack-dev] [Glance] Liberty Priorities

On 5/27/15, 8:23 AM, "Flavio Percoco" wrote: >On 26/05/15 17:14 +, Jesse Cook wrote: >>I created an etherpad with priorities the RAX team I work on will be >>focusing >>on based on our talks at the summit: https://etherpad.openstack.org/p/ >>liberty-priorities-rax. Input, guidance, feedback,

Re: [openstack-dev] [Manila] Expected Manila behavior for creation of share from snapshot

Hi Valeriy, VNX can support creating a share from snapshot using a different share network. Thanks, Xing From: Valeriy Ponomaryov [mailto:vponomar...@mirantis.com] Sent: Wednesday, May 27, 2015 8:38 AM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [M

Re: [openstack-dev] [app-catalog] [infra] App Catalog infrastructure integration (was: App Catalog next steps)

Should we talk about having a repo where contributed resources could be gated? I have some templates I'd like to eventually commit, but it would be good to have some infrastructure in place to make sure they don't bit rot. Thanks, Kevin From: Jeremy Stanl

Re: [openstack-dev] [cinder] Some Changes to Cinder Core

On 05/22/2015 07:34 PM, Mike Perez wrote: > This is long overdue, but it gives me great pleasure to nominate Sean > McGinnis for > Cinder core. > > > Cinder core, please reply with a +1 for approval. This will be left > open until May 29th. Assuming there are no objections, this will go > forward

Re: [openstack-dev] [app-catalog] [infra] App Catalog infrastructure integration (was: App Catalog next steps)

On 2015-05-27 21:15:58 + (+), Fox, Kevin M wrote: > Should we talk about having a repo where contributed resources > could be gated? I have some templates I'd like to eventually > commit, but it would be good to have some infrastructure in place > to make sure they don't bit rot. It looks

Re: [openstack-dev] [packaging] Adding packaging as an OpenStack project

On 27/05/15 09:14, Thomas Goirand wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi all, tl;dr: - - We'd like to push distribution packaging of OpenStack on upstream gerrit with reviews. - - The intention is to better share the workload, and improve the overall QA for packaging *and* up

Re: [openstack-dev] [app-catalog] [infra] App Catalog infrastructure integration (was: App Catalog next steps)

Cool. Yeah. I'd rather not setup a whole testing system on my own if OpenStack's awesome one can do it. :) Thanks, Kevin From: Jeremy Stanley [fu...@yuggoth.org] Sent: Wednesday, May 27, 2015 2:27 PM To: OpenStack Development Mailing List (not for usage qu

[openstack-dev] OpenStackClient 1.3.0 release

OpenStackClient 1.3.0 has been released to PyPI. This release consists of mostly bug fixes and one new command. It also works with the current development versions of its dependent client libraries. python-openstackclient can be installed from the following locations: PyPI: https://pypi.python.or

[openstack-dev] [Ironic] new 'Client (CLI) impact' section in ironic spec template

Hi, I recently added a 'Client (CLI) impact' section to the ironic spec template [1], because I was finding it difficult to find that information in submitted specs. If you submitted a spec before May 6-ish, you will probably need to add in this section (even if it isn't applicable). Sorry, I mea

Re: [openstack-dev] [new][app-catalog] App Catalog next steps

On Fri, May 22, 2015 at 9:06 PM, Christopher Aedo wrote: > I want to start off by thanking everyone who joined us at the first > working session in Vancouver, and those folks who have already started > adding content to the app catalog. I was happy to see the enthusiasm > and excitement, and am l

Re: [openstack-dev] [nova] I think nova behaves poorly when booting multiple instances

On 26 May 2015 at 03:37, Chris Friesen wrote: > > Hi all, > > I've just opened a bug around booting multiple instances at once, and it was > suggested on IRC that I mention it here to broaden the discussion around the > ideal behaviour. > > The bug is at: https://bugs.launchpad.net/nova/+bug/1458

Re: [openstack-dev] [new][app-catalog] App Catalog next steps

Joe, regarding apps-catalog for any app deployable on OpenStack (regardless of deployment technology), my two cents is that is a good idea. I also believe, however, that the app-catalog needs to evolve first with features that make it super simple to understand which artifacts will work on whic

[openstack-dev] [neutron] [fwaas] - Collecting use cases for API improvements

All, During the FWaaS session in Vancouver [1] it became apparent that both the FWaaS API and the Security Groups API are lacking in functionality and the connection between the two is not well defined. For instance if a cloud user opens up all ports in the security groups they still can’t c

Re: [openstack-dev] [neutron] - dnsmasq 'dhcp-authoritative' option broke multiple DHCP servers

>Looking at [1], I don't see that it generates a script at all. What it does is it prepopulates a lease file for dnsmasq consumption (so there is no external shell involved). Do we talk about the same patch? Not that patch. In the first email, I mentioned 3 approaches: iptables, lease db generatio

Re: [openstack-dev] [stable] stable/kilo and stable/juno blocked on zake 0.2.2 release

On 5/27/2015 11:00 AM, Matt Riedemann wrote: On 5/27/2015 10:58 AM, Matt Riedemann wrote: On 5/27/2015 10:57 AM, Matt Riedemann wrote: All changes to stable/kilo (and probably stable/juno) are broken due to a zake 0.2.2 release today which excludes kazoo 2.1. tooz 0.12 requires uncapped

[openstack-dev] [TripleO] Package updates strategy

Steve is working on a patch to allow package-based updates of overcloud nodes[1] using the distro's package manager (yum in the case of RDO, but conceivable apt in others). Note we're talking exclusively about minor updates, not version-to-version upgrades here. Dan mentioned at the summit tha

Re: [openstack-dev] [neutron] [fwaas] - Collecting use cases for API improvements

On Wed, May 27, 2015 at 5:36 PM, Eichberger, German < german.eichber...@hp.com> wrote: > All, > > > During the FWaaS session in Vancouver [1] it became apparent that both the > FWaaS API and the Security Groups API are lacking in functionality and the > connection between the two is not well defin

Re: [openstack-dev] [TripleO] [Puppet] Package updates strategy

Zane Bitter wrote: Steve is working on a patch to allow package-based updates of overcloud nodes[1] using the distro's package manager (yum in the case of RDO, but conceivable apt in others). Note we're talking exclusively about minor updates, not version-to-version upgrades here. Dan mentioned

Re: [openstack-dev] [new][app-catalog] App Catalog next steps

On 05/27/2015 06:35 PM, Keith Bray wrote: > Joe, regarding apps-catalog for any app deployable on OpenStack > (regardless of deployment technology), my two cents is that is a good > idea. I also believe, however, that the app-catalog needs to evolve > first with features that make it super simple

Re: [openstack-dev] [nova] I think nova behaves poorly when booting multiple instances

If the current behavior is broken, and the behavior is causing problems with things like fixing quota's, should it just be deprecated and pushed off to orchestration rather then change it? Thanks, Kevin From: Robert Collins [robe...@robertcollins.net] Se

Re: [openstack-dev] [TripleO] [Puppet] Package updates strategy

On 28/05/15 10:54, Richard Raseley wrote: Zane Bitter wrote: Steve is working on a patch to allow package-based updates of overcloud nodes[1] using the distro's package manager (yum in the case of RDO, but conceivable apt in others). Note we're talking exclusively about minor updates, not versio

Re: [openstack-dev] [new][app-catalog] App Catalog next steps

I'd say, tools that utilize OpenStack, like the knife openstack plugin, are not something that you would probably go to the catalog to find. And also, the recipes that you would use with knife would not be specific to OpenStack in any way, so you would just be duplicating the config management s

Re: [openstack-dev] [TripleO] Package updates strategy

my gut feeling is that it will take way more work to do this well, then to dockerize the various parts, and then puppet (or whatever) could simply stop/start containers that had a new version. It could easily pick up what needed updating then. It would also fix once and for all the issue of want

Re: [openstack-dev] [new][app-catalog] App Catalog next steps

In-line responses. Thanks for chipping in Monty. -Keith On 5/27/15 6:03 PM, "Monty Taylor" wrote: >On 05/27/2015 06:35 PM, Keith Bray wrote: >> Joe, regarding apps-catalog for any app deployable on OpenStack >> (regardless of deployment technology), my two cents is that is a good >> idea. I al

Re: [openstack-dev] [new][app-catalog] App Catalog next steps

Kevin, I like your vision. Today we have images, heat templates, Murano packages. What are your thoughts on how to manage additions? Should it be restricted to things in the OpenStack namespace under the big tent? E.g., I'd like to see Solum language packs get added to the app-catalog. Solu

Re: [openstack-dev] [new][app-catalog] App Catalog next steps

Should RefStack be involved here? To integrate tightly with the App Catalog, the Cloud Provider would be required to run RefStack against their cloud, the results getting registered to an App Catalog service in that Cloud. The App Catalog UI in Horizon could then filter out from the global App C

Re: [openstack-dev] [new][app-catalog] App Catalog next steps

There's an alternate vision which is simply, resources that can be launched in an OpenStack environment directly. Solum, Mistral, Glance, etc fit into that definition. This is kind of how it is arranged today. Even with the high level app store only vision I proposed, these other types of cata

Re: [openstack-dev] [new][app-catalog] App Catalog next steps

Maybe. I'm not up to speed on defcore/refstack requirements.. But, to put the question on the table, do folks want the OpenStack App-catalog to only have support for the "lowest-common-denominator" of artifacts and cloud capabilities, or instead allow for showcasing all that is possible when using

Re: [openstack-dev] [Nova] Using depends-on for patches which require an approved spec

On Wed, May 27, 2015 at 12:15 PM, Joe Gordon wrote: > > > On Tue, May 26, 2015 at 8:45 AM, Daniel P. Berrange > wrote: > >> On Fri, May 22, 2015 at 02:57:23PM -0700, Michael Still wrote: >> > Hey, >> > >> > it would be cool if devs posting changes for nova which depend on us >> > approving their

  1   2   >