[openstack-dev] [Octavia] Using Nova Scheduling Affinity and AntiAffinity

Nova scheduler has ServerGroupAffinityFilter and ServerGroupAntiAffinityFilter which does the colocation and apolocation for VMs. I think this is something we've discussed before about taking advantage of nova's scheduling. I need to verify that this will work with what we (RAX) plan to do, but I

Re: [openstack-dev] [Openstack][TripleO] What if undercloud machines down, can we reboot overcloud machines?

That is correct, we intend that the undercloud should be designed with HA in mind. In terms of the design of TripleO, the devtest.sh implementation aims to have this available as a default (see http://docs.openstack.org/developer/tripleo-incubator/README.html#stage-2-being-worked-on for some dated

Re: [openstack-dev] [all] [ptls] The Czar system, or how to scale PTLs

On Sat, Aug 23, 2014 at 11:02 AM, Anne Gentle wrote: > > > > On Fri, Aug 22, 2014 at 6:17 PM, Rochelle.RochelleGrober < > rochelle.gro...@huawei.com> wrote: > >> /flame-on >> Ok, this is funny to some of us in the community. The general populace >> of this community is so against the idea of man

Re: [openstack-dev] [Mistral] Workflow on-finish

Right now, you can just include a special task into a workflow that, for example, sends an HTTP request to whatever you need to notify about workflow completion. Although, I see it rather as a hack (not so horrible though). Renat Akhmerov @ Mirantis Inc. On 28 Aug 2014, at 12:01, Renat Akhmer

Re: [openstack-dev] [Mistral] Workflow on-finish

There are two blueprints that I supposed to use for this purpose: https://blueprints.launchpad.net/mistral/+spec/mistral-event-listeners-http https://blueprints.launchpad.net/mistral/+spec/mistral-event-listeners-amqp So my opinion: This functionality should be orthogonal to what we configure in D

Re: [openstack-dev] [ironic] [neutron] make mac address updatable - port status for ironic servers

Yes, its to be expected. IIRC, you were helping me investigate the same thing at the TripleO mid-cycle. :) The port gets the necessary configuration setup by the DHCP agent to take care of PXE, but this being baremetal there is no hypervisor on which some agent is running and plugging VIFs into a

Re: [openstack-dev] [Openstack][TripleO] What if undercloud machines down, can we reboot overcloud machines?

I do agree but it create an extra requirement for Undercloud if we high availability is important criteria. Because of this, undercloud has to be there 24x7, 365 days and to make it available we need to have HA for this also. So, you indirectly mean that undercloud also should be designed keeping h

Re: [openstack-dev] [nova] Configuring libivrt VIF driver

Hi Daniel, > For Juno the vif_driver option still exists & can be used. In the current master branch, there is no 'vif_driver' option for libvirt. It has been deleted by [1], and I can't find any patches to enable 'vif_driver' config on gerrit. Is there plan to get the 'vif_driver' config avail

Re: [openstack-dev] [nova] Configuring libivrt VIF driver

On 27/08/2014 17:06, Daniel P. Berrange wrote: On Tue, Aug 26, 2014 at 05:02:10PM +0300, Itzik Brown wrote: Hi, Following the conversation [1]: My understanding was that the way to use out of the tree vif_driver is to set vif_driver option in nova.conf until there is a better way to support su

Re: [openstack-dev] [infra] [neutron] [tc] Neutron Incubator workflow

On Wed, Aug 27, 2014 at 5:06 PM, Jeremy Stanley wrote: > > Good point, and that definitely is a reason to just keep those > pieces in their own separate Git repositories outside of the core > Neutron repository in perpetuity (even after they "graduate" from > incubation). One package per repositor

Re: [openstack-dev] [all] Design Summit reloaded

From: Chris Jones [mailto:c...@tenshu.net] Hi Anita Your impromptu infra-clue-dissemination talks sound interesting (I'd like to see the elastic recheck fingerprint one, for example). Would it make sense to amplify your reach, by making some short screencasts of these sorts of things? Cheer

[openstack-dev] [nova] Is the BP approval process broken?

I'll try and not whine about my pet project but I do think there is a problem here. For the Gantt project to split out the scheduler there is a crucial BP that needs to be implemented ( https://review.openstack.org/#/c/89893/ ) and, unfortunately, the BP has been rejected and we'll have to try

Re: [openstack-dev] [all] Design Summit reloaded

On August 27, 2014 3:26 PM Clint Byrum wrote: Excerpts from Thierry Carrez's message of 2014-08-27 05:51:55: > Hi everyone, > > I've been thinking about what changes we can bring to the Design Summit > format to make it more productive. I've heard the feedback from the > mid-cycle meetups and wou

Re: [openstack-dev] [Neutron] Author tags

I do agree with Kyle. There is no rush for having this code merged in order to a void multiple rebase work for the other patches. Edgar On 8/27/14, 9:25 AM, "Kyle Mestery" wrote: >On Wed, Aug 27, 2014 at 8:24 AM, Gary Kotton wrote: >> Hi, >> A few cycles ago the Nova group decided to remove @a

Re: [openstack-dev] [all] Design Summit reloaded

On 08/27/2014 07:39 PM, Chris Jones wrote: > Hi Anita > > Your impromptu infra-clue-dissemination talks sound interesting (I'd like to > see the elastic recheck fingerprint one, for example). Would it make sense to > amplify your reach, by making some short screencasts of these sorts of things?

Re: [openstack-dev] [infra] [neutron] [tc] Neutron Incubator workflow

On Wed, Aug 27, 2014 at 6:59 PM, Mandeep Dhami wrote: > > Also note that one of the "features" of the incubator is that it can be > packaged/released independently (like python-neutronclient) and a feature > branch is not designed for that workflow. > Which is a good reason to not use the word '

[openstack-dev] [ironic] [neutron] make mac address updatable - port status for ironic servers

Hi all, I'm working on bug [1] and have code in review[2]. The bug wants neutron's port['mac_address'] to be updatable to handle the case where an ironic server's nic is replaced. A comment in the review suggests that we only allow mac address update when the port status is not ACTIVE. While

Re: [openstack-dev] [infra] [neutron] [tc] Neutron Incubator workflow

On 2014-08-27 16:59:54 -0700 (-0700), Mandeep Dhami wrote: > Also note that one of the "features" of the incubator is that it can be > packaged/released independently (like python-neutronclient) and a feature > branch is not designed for that workflow. Good point, and that definitely is a reason t

Re: [openstack-dev] [infra] [neutron] [tc] Neutron Incubator workflow

On 2014-08-27 16:53:39 -0700 (-0700), Clark Boylan wrote: [...] > I thought there was a wiki article on how they work but I can't > find it. Maybe someone else can link it here. [...] https://wiki.openstack.org/wiki/GerritJenkinsGit#Merge_Commits -- Jeremy Stanley __

Re: [openstack-dev] [Keystone][Marconi][Heat] Creating accounts in Keystone

Excerpts from Adam Young's message of 2014-08-24 20:17:34 -0700: > On 08/23/2014 02:01 AM, Clint Byrum wrote: > > I don't know how Zaqar does its magic, but I'd love to see simple signed > > URLs rather than users/passwords. This would work for Heat as well. That > > way we only have to pass in a s

Re: [openstack-dev] [infra] [neutron] [tc] Neutron Incubator workflow

Also note that one of the "features" of the incubator is that it can be packaged/released independently (like python-neutronclient) and a feature branch is not designed for that workflow. Regards, Mandeep On Wed, Aug 27, 2014 at 4:55 PM, Jeremy Stanley wrote: > On 2014-08-27 16:05:36 -0700 (-

Re: [openstack-dev] [infra] [neutron] [tc] Neutron Incubator workflow

On 2014-08-27 16:05:36 -0700 (-0700), Joe Gordon wrote: > We have feature branches? How do we use them? I am not even sure > if feature branches were evaluated as an option when the incubator > was proposed. Keystone's new API used a feature branch, the EC work in Swift did, so did the Gearman int

Re: [openstack-dev] [infra] [neutron] [tc] Neutron Incubator workflow

On Wed, Aug 27, 2014, at 04:05 PM, Joe Gordon wrote: > On Wed, Aug 27, 2014 at 12:30 PM, James E. Blair > wrote: > > > Kevin Benton writes: > > > > > From what I understand, the intended projects for the incubator can't > > > operate without neutron because they are just extensions/plugins/drive

Re: [openstack-dev] [infra] [neutron] [tc] Neutron Incubator workflow

On Wed, Aug 27, 2014, at 03:52 PM, Ivar Lazzaro wrote: > Quoting Stefano from a different thread [0]: > > The rationale for the separate repository is that Neutron's code needs a > > lot of love for the *existing* codebase, before new features can be > > added (and before core team can accept mo

Re: [openstack-dev] [all] Design Summit reloaded

Hi Anita Your impromptu infra-clue-dissemination talks sound interesting (I'd like to see the elastic recheck fingerprint one, for example). Would it make sense to amplify your reach, by making some short screencasts of these sorts of things? Cheers, -- Chris Jones > On 27 Aug 2014, at 21:48,

[openstack-dev] [Mistral] Workflow on-finish

Renat, It will be helpful to perform a callback on completion of the async workflow. Can we add on-finish to the workflow spec and when workflow completes, runs task(s) defined in the on-finish section of the spec? This will allow the workflow author to define how the callback is to be done. He

Re: [openstack-dev] [infra] Centos 7 images for HP Helion

On 08/27/2014 08:31 PM, Karanbir Singh wrote: If you let me know what the issues with the Rackspace images are, I can try to reach out and help them work through those. The main issue was a verison of cloud-init installed via pip that conflicted with packaged python. I put a work-around in de

Re: [openstack-dev] [Heat] Passing a list of ResourceGroup's attributes back to its members

On 14/08/14 00:00, Tomas Sedovic wrote: > On 12/08/14 01:06, Steve Baker wrote: >> On 09/08/14 11:15, Zane Bitter wrote: >>> On 08/08/14 11:07, Tomas Sedovic wrote: On 08/08/14 00:53, Zane Bitter wrote: > On 07/08/14 13:22, Tomas Sedovic wrote: >> Hi all, >> >> I have a Resourc

Re: [openstack-dev] [infra] [neutron] [tc] Neutron Incubator workflow

On Wed, Aug 27, 2014 at 12:30 PM, James E. Blair wrote: > Kevin Benton writes: > > > From what I understand, the intended projects for the incubator can't > > operate without neutron because they are just extensions/plugins/drivers. > > I could have phrased that better. What I meant was that th

Re: [openstack-dev] [infra] [neutron] [tc] Neutron Incubator workflow

Quoting Stefano from a different thread [0]: The rationale for the separate repository is that Neutron's code needs a > lot of love for the *existing* codebase, before new features can be > added (and before core team can accept more responsibilities for it). > But progress is unstoppable: new fea

Re: [openstack-dev] [Keystone][Marconi][Heat] Creating accounts in Keystone

On 27/08/14 12:15, Kurt Griffiths wrote: On 8/25/14, 9:50 AM, "Ryan Brown" wrote: I'm actually quite partial to roles because, in my experience, service accounts rarely have their credentials rotated more than once per eon. Having the ability to let instances grab tokens would certainly help H

Re: [openstack-dev] [all] gate debugging

As it has been pointed out previously in this thread debugging gate failures is mostly about chasing race conditions, which in some cases involve the most disparate interactions between Openstack services [1]. Finding the root cause of these races is a mix of knowledge, pragmatism, and luck. Havin

Re: [openstack-dev] [all] gate debugging

On Wed, Aug 27, 2014 at 05:47:09PM -0400, Doug Hellmann wrote: > > On Aug 27, 2014, at 5:27 PM, Doug Hellmann wrote: > > > > > On Aug 27, 2014, at 2:54 PM, Sean Dague wrote: > > > >> Note: thread intentionally broken, this is really a different topic. > >> > >> On 08/27/2014 02:30 PM, Doug H

[openstack-dev] [requirements] kombu >= 2.5.0? or even >= 3?

(going through old reviews I'm listed on to figure out what should abandon)... This review is stuck on a merge conflict from 2 months ago - https://review.openstack.org/#/c/92095/ It's worth noting that in the gate we are currently testing juno with kombu 3.0.7 (looks like out of the trusty packa

Re: [openstack-dev] [all] Design Summit reloaded

Excerpts from Anita Kuno's message of 2014-08-27 13:48:25 -0700: > On 08/27/2014 02:46 PM, John Griffith wrote: > > On Wed, Aug 27, 2014 at 9:25 AM, Flavio Percoco wrote: > > > >> On 08/27/2014 03:26 PM, Sean Dague wrote: > >>> On 08/27/2014 08:51 AM, Thierry Carrez wrote: > Hi everyone, > >

Re: [openstack-dev] [all] Design Summit reloaded

Excerpts from Sean Dague's message of 2014-08-27 06:26:38 -0700: > On 08/27/2014 08:51 AM, Thierry Carrez wrote: > > Hi everyone, > > > > I've been thinking about what changes we can bring to the Design Summit > > format to make it more productive. I've heard the feedback from the > > mid-cycle me

Re: [openstack-dev] [all] Design Summit reloaded

Excerpts from Thierry Carrez's message of 2014-08-27 05:51:55 -0700: > Hi everyone, > > I've been thinking about what changes we can bring to the Design Summit > format to make it more productive. I've heard the feedback from the > mid-cycle meetups and would like to apply some of those ideas for

Re: [openstack-dev] [Octavia] Octavia VM image design

I am investigating building scripts that use diskimage-builder (https://github.com/openstack/diskimage-builder) to create a "purpose built" image. This should allow some flexibility in the base image and the output image format (including a path to docker). The definition of "purpose built" is op

Re: [openstack-dev] [all] gate debugging

On 08/27/2014 05:27 PM, Doug Hellmann wrote: > > On Aug 27, 2014, at 2:54 PM, Sean Dague wrote: > >> Note: thread intentionally broken, this is really a different topic. >> >> On 08/27/2014 02:30 PM, Doug Hellmann wrote:> >>> On Aug 27, 2014, at 1:30 PM, Chris Dent wrote: >>> On Wed, 27 Au

Re: [openstack-dev] [all] gate debugging

On Aug 27, 2014, at 5:27 PM, Doug Hellmann wrote: > > On Aug 27, 2014, at 2:54 PM, Sean Dague wrote: > >> Note: thread intentionally broken, this is really a different topic. >> >> On 08/27/2014 02:30 PM, Doug Hellmann wrote:> >>> On Aug 27, 2014, at 1:30 PM, Chris Dent wrote: >>> On

Re: [openstack-dev] [neutron][ml2] Mech driver as out-of-tree add-on

It's more than just an optimization when it comes to overlay networks though. It's the only way for agents to establish segment connectivity when something like vxlan multicast discovery isn't possible. It shouldn't be l2pop's responsibility for something like basic connectivity. That should be han

Re: [openstack-dev] [Heat] Heat Juno Mid-cycle Meetup report

On 28/08/14 03:41, Zane Bitter wrote: > On 27/08/14 11:04, Steven Hardy wrote: >> On Wed, Aug 27, 2014 at 07:54:41PM +0530, Jyoti Ranjan wrote: >>> I am little bit skeptical about using Swift for this use case >>> because of >>> its eventual consistency issue. I am not sure Swift cluster is

Re: [openstack-dev] [all] gate debugging

On Aug 27, 2014, at 2:54 PM, Sean Dague wrote: > Note: thread intentionally broken, this is really a different topic. > > On 08/27/2014 02:30 PM, Doug Hellmann wrote:> >> On Aug 27, 2014, at 1:30 PM, Chris Dent wrote: >> >>> On Wed, 27 Aug 2014, Doug Hellmann wrote: >>> I have found it

Re: [openstack-dev] [all] Design Summit reloaded

On Wed, Aug 27, 2014 at 2:48 PM, Anita Kuno wrote: > On 08/27/2014 02:46 PM, John Griffith wrote: > > On Wed, Aug 27, 2014 at 9:25 AM, Flavio Percoco > wrote: > > > >> On 08/27/2014 03:26 PM, Sean Dague wrote: > >>> On 08/27/2014 08:51 AM, Thierry Carrez wrote: > Hi everyone, > >

[openstack-dev] [Octavia] Octavia VM image design

It seems to me there are two major approaches to the Octavia VM design: 1. Start with a standard Linux distribution (e.g. Ubuntu 14.04 LTS) and install HAProxy 1.5 and Octavia control layer 2. Develop a minimal purpose driven distribution (similar to m0n0wall) with just HAProxy, iprout

[openstack-dev] [heat] Re: Change in openstack/heat[master]: Implement AZ spanning for ASGs

You offered to share ideas about a different way to approach spanning AZs for OS::Heat::AutoScalingGroup. I am interested. Can we discuss it here? Thanks, Mike___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/

Re: [openstack-dev] [all] Design Summit reloaded

On 08/27/2014 02:46 PM, John Griffith wrote: > On Wed, Aug 27, 2014 at 9:25 AM, Flavio Percoco wrote: > >> On 08/27/2014 03:26 PM, Sean Dague wrote: >>> On 08/27/2014 08:51 AM, Thierry Carrez wrote: Hi everyone, I've been thinking about what changes we can bring to the Design Summi

Re: [openstack-dev] [Neutron] Author tags

On Aug 27, 2014, at 2:27 PM, Mandeep Dhami mailto:dh...@noironetworks.com>> wrote: T hese should all be comment changes, so there "should be" no impact. While I agree that it is late for J3, IMO this is the type of change (minor/comment only) that should be OK J4 rather than wait for Kilo.

Re: [openstack-dev] [infra] [neutron] [tc] Neutron Incubator workflow

I agree that components isolated to one service or something along those lines where there is a clear plugin point in Neutron, it might make sense to separate them permanently. However, at that point why even bother with the Neutron incubator when a new project can be started? The feature branch i

Re: [openstack-dev] [infra] [neutron] [tc] Neutron Incubator workflow

What are you talking about? The only reply was from me clarifying that one of the purposes of the incubator was for components of neutron that are experimental but are intended to be merged. In that case it might not make sense to have a life cycle of their own in another repo indefinitely. On We

Re: [openstack-dev] [all] gate debugging

On 08/27/2014 03:43 PM, Sean Dague wrote: > On 08/27/2014 03:33 PM, David Kranz wrote: >> On 08/27/2014 02:54 PM, Sean Dague wrote: >>> Note: thread intentionally broken, this is really a different topic. >>> >>> On 08/27/2014 02:30 PM, Doug Hellmann wrote:> On Aug 27, 2014, at 1:30 PM, Chris

Re: [openstack-dev] [all] gate debugging

On 08/27/2014 03:43 PM, Sean Dague wrote: On 08/27/2014 03:33 PM, David Kranz wrote: On 08/27/2014 02:54 PM, Sean Dague wrote: Note: thread intentionally broken, this is really a different topic. On 08/27/2014 02:30 PM, Doug Hellmann wrote:> On Aug 27, 2014, at 1:30 PM, Chris Dent wrote: O

Re: [openstack-dev] [all] gate debugging

On 08/27/2014 03:33 PM, David Kranz wrote: > On 08/27/2014 02:54 PM, Sean Dague wrote: >> Note: thread intentionally broken, this is really a different topic. >> >> On 08/27/2014 02:30 PM, Doug Hellmann wrote:> >>> On Aug 27, 2014, at 1:30 PM, Chris Dent wrote: >>> On Wed, 27 Aug 2014, Doug H

Re: [openstack-dev] [all] gate debugging

On 08/27/2014 02:54 PM, Sean Dague wrote: Note: thread intentionally broken, this is really a different topic. On 08/27/2014 02:30 PM, Doug Hellmann wrote:> On Aug 27, 2014, at 1:30 PM, Chris Dent wrote: On Wed, 27 Aug 2014, Doug Hellmann wrote: I have found it immensely helpful, for examp

Re: [openstack-dev] [infra] [neutron] [tc] Neutron Incubator workflow

Kevin Benton writes: > From what I understand, the intended projects for the incubator can't > operate without neutron because they are just extensions/plugins/drivers. I could have phrased that better. What I meant was that they could operate without being actually in the Neutron repo, not tha

Re: [openstack-dev] [all] [glance] python namespaces considered harmful to development, lets not introduce more of them

Sean Dague writes: > On 08/27/2014 11:14 AM, Flavio Percoco wrote: >> On 08/27/2014 04:31 PM, Sean Dague wrote: >> 1. Do a partial rename and then complete it after the glance migration >> is done. If I'm not missing anything, we should be able to do something >> like: >> - Rename the projec

Re: [openstack-dev] [all] The future of the integrated release

On Wed, Aug 27, 2014 at 10:59:36AM -0400, Doug Hellmann wrote: > > On Aug 27, 2014, at 8:47 AM, Sean Dague wrote: [. . .] > > So I think we all want the future where OpenStack is a really nice set > > of composable services that let you easily create the cloud you want. > > They are all stable,

Re: [openstack-dev] [all] gate debugging

On 2014-08-27 14:54:55 -0400 (-0400), Sean Dague wrote: [...] > I think we break down on communication when we get into a > conversation of "I want to learn gate debugging" because I don't > quite know what that means, or where the starting point of > understanding is. So those intentions are well

Re: [openstack-dev] [all] Design Summit reloaded

On Wed, Aug 27, 2014 at 7:51 AM, Thierry Carrez wrote: > Hi everyone, > > I've been thinking about what changes we can bring to the Design Summit > format to make it more productive. I've heard the feedback from the > mid-cycle meetups and would like to apply some of those ideas for Paris, > withi

Re: [openstack-dev] [nova] refactoring of resize/migrate

On 08/27/2014 06:41 AM, Markus Zoeller wrote: The review of the spec to blueprint "hot-resize" has several comments about the need of refactoring the existing code base of "resize" and "migrate" before the blueprint could be considered (see [1]). I'm interested in the result of the blueprint ther

[openstack-dev] [all] gate debugging

Note: thread intentionally broken, this is really a different topic. On 08/27/2014 02:30 PM, Doug Hellmann wrote:> > On Aug 27, 2014, at 1:30 PM, Chris Dent wrote: > >> On Wed, 27 Aug 2014, Doug Hellmann wrote: >> >>> I have found it immensely helpful, for example, to have a written set >>> of th

Re: [openstack-dev] [infra] [neutron] [tc] Neutron Incubator workflow

On 08/26/2014 07:09 PM, James E. Blair wrote: Hi, After reading https://wiki.openstack.org/wiki/Network/Incubator I have some thoughts about the proposed workflow. We have quite a bit of experience and some good tools around splitting code out of projects and into new projects. But we don't ge

Re: [openstack-dev] [all] Design Summit reloaded

On Wed, Aug 27, 2014 at 9:25 AM, Flavio Percoco wrote: > On 08/27/2014 03:26 PM, Sean Dague wrote: > > On 08/27/2014 08:51 AM, Thierry Carrez wrote: > >> Hi everyone, > >> > >> I've been thinking about what changes we can bring to the Design Summit > >> format to make it more productive. I've hea

Re: [openstack-dev] [all] The future of the integrated release

On Aug 27, 2014, at 1:30 PM, Chris Dent wrote: > On Wed, 27 Aug 2014, Doug Hellmann wrote: > >> I have found it immensely helpful, for example, to have a written set >> of the steps involved in creating a new library, from importing the >> git repo all the way through to making it available to

Re: [openstack-dev] [Neutron] Author tags

T hese should all be comment changes, so there "should be" no impact. While I agree that it is late for J3, IMO this is the type of change (minor/comment only) that should be OK J4 rather than wait for Kilo. On Wed, Aug 27, 2014 at 7:25 AM, Kyle Mestery wrote: > On Wed, Aug 27, 2014 at 8:24 AM,

Re: [openstack-dev] [OpenStack-Dev][Cinder] Cinder Core nomination

Thanks John! Thanks everyone! Xing From: John Griffith [mailto:john.griff...@solidfire.com] Sent: Wednesday, August 27, 2014 2:19 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [OpenStack-Dev][Cinder] Cinder Core nomination On Wed, Aug 27, 2

Re: [openstack-dev] [OpenStack-Dev][Cinder] Cinder Core nomination

On Wed, Aug 27, 2014 at 11:39 AM, Huang Zhiteng wrote: > Definitely +1. > > Xing has been very active in providing feedback for reviews. Thanks > for the help and welcome to the team! > > On Tue, Aug 19, 2014 at 5:24 PM, Avishay Traeger > wrote: > > +1 > > > > > > On Thu, Aug 14, 2014 at 9:55 A

Re: [openstack-dev] [Heat] Heat Juno Mid-cycle Meetup report

Excerpts from Steven Hardy's message of 2014-08-27 10:08:36 -0700: > On Wed, Aug 27, 2014 at 09:40:31AM -0700, Clint Byrum wrote: > > Excerpts from Zane Bitter's message of 2014-08-27 08:41:29 -0700: > > > On 27/08/14 11:04, Steven Hardy wrote: > > > > On Wed, Aug 27, 2014 at 07:54:41PM +0530, Jyot

Re: [openstack-dev] [OpenStack-Dev][Cinder] Cinder Core nomination

Definitely +1. Xing has been very active in providing feedback for reviews. Thanks for the help and welcome to the team! On Tue, Aug 19, 2014 at 5:24 PM, Avishay Traeger wrote: > +1 > > > On Thu, Aug 14, 2014 at 9:55 AM, Boring, Walter > wrote: >> >> Hey guys, >>I wanted to pose a nominati

Re: [openstack-dev] [all] The future of the integrated release

On Wed, 27 Aug 2014, Doug Hellmann wrote: I have found it immensely helpful, for example, to have a written set of the steps involved in creating a new library, from importing the git repo all the way through to making it available to other projects. Without those instructions, it would have bee

Re: [openstack-dev] [Keystone][Marconi][Heat] Creating accounts in Keystone

On 08/27/2014 12:15 PM, Kurt Griffiths wrote: > On 8/25/14, 9:50 AM, "Ryan Brown" wrote: > >> I'm actually quite partial to roles because, in my experience, service >> accounts rarely have their credentials rotated more than once per eon. >> Having the ability to let instances grab tokens would

Re: [openstack-dev] [Heat] Heat Juno Mid-cycle Meetup report

On Wed, Aug 27, 2014 at 09:40:31AM -0700, Clint Byrum wrote: > Excerpts from Zane Bitter's message of 2014-08-27 08:41:29 -0700: > > On 27/08/14 11:04, Steven Hardy wrote: > > > On Wed, Aug 27, 2014 at 07:54:41PM +0530, Jyoti Ranjan wrote: > > >> I am little bit skeptical about using Swift for

Re: [openstack-dev] [Heat] Heat Juno Mid-cycle Meetup report

On Wed, Aug 27, 2014 at 11:41:29AM -0400, Zane Bitter wrote: > On 27/08/14 11:04, Steven Hardy wrote: > >On Wed, Aug 27, 2014 at 07:54:41PM +0530, Jyoti Ranjan wrote: > >>I am little bit skeptical about using Swift for this use case because of > >>its eventual consistency issue. I am not su

Re: [openstack-dev] [Heat] Heat Juno Mid-cycle Meetup report

Excerpts from Zane Bitter's message of 2014-08-27 08:41:29 -0700: > On 27/08/14 11:04, Steven Hardy wrote: > > On Wed, Aug 27, 2014 at 07:54:41PM +0530, Jyoti Ranjan wrote: > >> I am little bit skeptical about using Swift for this use case because > >> of > >> its eventual consistency issu

Re: [openstack-dev] [oslo] review priorities

On Aug 27, 2014, at 12:29 PM, Julien Danjou wrote: > On Wed, Aug 27 2014, Doug Hellmann wrote: > >> I *believe* we have started work on all of the graduations we are likely to >> complete during Juno. I suggest we start focusing our efforts on reviews >> related to the other outstanding bluepri

Re: [openstack-dev] [zaqar] [marconi] Removing GET message by ID in v1.1 (Redux)

I doesn't support the idea of removing this endpoint, although it requires some efforts to maintain. First of all, because of the confusion among users, that it could bring. The href to message is returned in many cases, and was seen as canonical way to deal with it. (As far as I understand, w

Re: [openstack-dev] [neutron] Incubator concerns from packaging perspective

On 08/21/2014 03:12 AM, Ihar Hrachyshka wrote: > I wonder where discussion around the proposal is running. Is it public? Yes, it's public, and this thread is part of it. Look at the dates of the wiki: this is a recent proposal (first appearance Aug 11), came out to address the GBP issue, quickly i

Re: [openstack-dev] [oslo] review priorities

On Wed, Aug 27 2014, Doug Hellmann wrote: > I *believe* we have started work on all of the graduations we are likely to > complete during Juno. I suggest we start focusing our efforts on reviews > related to the other outstanding blueprints and critical bugs. I see a lot > of open patches for task

Re: [openstack-dev] [all] [glance] python namespaces considered harmful to development, lets not introduce more of them

On Aug 27, 2014, at 11:55 AM, Donald Stufft wrote: >> >> On Aug 27, 2014, at 11:45 AM, Doug Hellmann wrote: >> >> >> On Aug 27, 2014, at 10:31 AM, Sean Dague wrote: >> >>> So this change came in with adding glance.store - >>> https://review.openstack.org/#/c/115265/5/lib/glance, which I th

Re: [openstack-dev] [all] The future of the integrated release

On Aug 27, 2014, at 11:17 AM, Chris Dent wrote: > On Wed, 27 Aug 2014, Doug Hellmann wrote: > >> For example, Matt helped me with an issue yesterday, and afterwards >> I asked him to write up a few details about how he reached his >> conclusion because he was moving fast enough that I wasn’t >>

Re: [openstack-dev] [Keystone][Marconi][Heat] Creating accounts in Keystone

On 8/25/14, 9:50 AM, "Ryan Brown" wrote: >I'm actually quite partial to roles because, in my experience, service >accounts rarely have their credentials rotated more than once per eon. >Having the ability to let instances grab tokens would certainly help >Heat, especially if we start using Zaqar

[openstack-dev] [oslo] review priorities

I *believe* we have started work on all of the graduations we are likely to complete during Juno. I suggest we start focusing our efforts on reviews related to the other outstanding blueprints and critical bugs. I see a lot of open patches for taskflow, for example. Doug _

Re: [openstack-dev] [all] Design Summit reloaded

On 08/27/2014 03:26 PM, Sean Dague wrote: > On 08/27/2014 08:51 AM, Thierry Carrez wrote: >> Hi everyone, >> >> I've been thinking about what changes we can bring to the Design Summit >> format to make it more productive. I've heard the feedback from the >> mid-cycle meetups and would like to apply

[openstack-dev] [oslo] let's start preparing for the kilo summit

Based on Thierry’s comment that we’ll have less space/time for summit sessions, I want to make sure we start thinking about topics that need to be addressed as a team earlier than we might usually. I created an etherpad for us to start sketching out ideas: https://etherpad.openstack.org/p/kilo-

Re: [openstack-dev] [all] [glance] python namespaces considered harmful to development, lets not introduce more of them

> On Aug 27, 2014, at 11:45 AM, Doug Hellmann wrote: > > > On Aug 27, 2014, at 10:31 AM, Sean Dague > wrote: > >> So this change came in with adding glance.store - >> https://review.openstack.org/#/c/115265/5/lib/glance, which I think is a >> bad direction to be headed.

Re: [openstack-dev] [all] [glance] python namespaces considered harmful to development, lets not introduce more of them

On Aug 27, 2014, at 11:14 AM, Flavio Percoco wrote: > On 08/27/2014 04:31 PM, Sean Dague wrote: >> So this change came in with adding glance.store - >> https://review.openstack.org/#/c/115265/5/lib/glance, which I think is a >> bad direction to be headed. >> >> Here is the problem when it comes

Re: [openstack-dev] [Heat] Heat Juno Mid-cycle Meetup report

Swift does have some guarantees around read-after-write consistency, but for Heat I think the best bet would be the X-Newest[1] header which has been in swift for a very, very long time. The downside here is that (IIUC) it queries all storage nodes for that object. It does not provide a hard guaran

[openstack-dev] [zaqar] [marconi] Removing GET message by ID in v1.1 (Redux)

Crew, as we continue implementing v1.1 in anticipation for a “public preview” at the summit, I’ve started to wonder again about removing the ability to GET a message by ID from the API. Previously, I was concerned that it may be too disruptive a change and should wait for 2.0. But consider this:

Re: [openstack-dev] [all] [glance] python namespaces considered harmful to development, lets not introduce more of them

On Aug 27, 2014, at 10:31 AM, Sean Dague wrote: > So this change came in with adding glance.store - > https://review.openstack.org/#/c/115265/5/lib/glance, which I think is a > bad direction to be headed. > > Here is the problem when it comes to working with code from git, in > python, that use

Re: [openstack-dev] [all] [glance] python namespaces considered harmful to development, lets not introduce more of them

On 08/27/2014 11:14 AM, Flavio Percoco wrote: > On 08/27/2014 04:31 PM, Sean Dague wrote: >> So this change came in with adding glance.store - >> https://review.openstack.org/#/c/115265/5/lib/glance, which I think is a >> bad direction to be headed. >> >> Here is the problem when it comes to workin

Re: [openstack-dev] [Heat] Heat Juno Mid-cycle Meetup report

On 27/08/14 11:04, Steven Hardy wrote: On Wed, Aug 27, 2014 at 07:54:41PM +0530, Jyoti Ranjan wrote: I am little bit skeptical about using Swift for this use case because of its eventual consistency issue. I am not sure Swift cluster is good to be used for this kind of problem. Pleas

Re: [openstack-dev] [all] Design Summit reloaded

On Aug 27, 2014, at 8:51 AM, Thierry Carrez wrote: > Hi everyone, > > I've been thinking about what changes we can bring to the Design Summit > format to make it more productive. I've heard the feedback from the > mid-cycle meetups and would like to apply some of those ideas for Paris, > within

Re: [openstack-dev] [oslo] usage patterns for oslo.config

Mark - > I don't think I've seen code (except for obscure cases) which uses the > CONF global directly (as opposed to being passed CONF as a parameter) > but doesn't register the options at import time. > > Mark. > > Keystone uses the CONF global directly and doesn't register the options at impor

[openstack-dev] [Tripleo] Release report

1. os-apply-config: no changes, 0.1.19 2. os-refresh-config: no changes, 0.1.7 3. os-collect-config: no changes, 0.1.27 4. os-cloud-config: release: 0.1.6 --> 0.1.7 --> https://pypi.python.org/pypi/os-cloud-config/0.1.7 --> http://tarballs.openstack.org/os-clo

[openstack-dev] [openstack-sdk-php] Canceled Meeting and Future of weekly meetings

First I'd like to note that the weekly PHP SDK meeting this week is canceled. For the time being, unless someone has a good argument to the contrary, the meeting will be suspended. Those of us working on PHP can be found in the #openstack-sdks room in IRC. The meetings have stopped being useful a

Re: [openstack-dev] [Heat][Docker] How to Dockerize your applications with OpenStack Heat in simple steps

On Tue, Aug 26, 2014 at 3:35 PM, Martinx - ジェームズ wrote: > Hey Stackers! Wait! =) > > Let me ask something... > > Why are you guys using Docker within a VM?!?! What is the point of doing > such thing?! > > I thought Docker was here to entirely replace the virtualization layer, > bringing a "bare

Re: [openstack-dev] [all] The future of the integrated release

On Wed, 27 Aug 2014, Doug Hellmann wrote: For example, Matt helped me with an issue yesterday, and afterwards I asked him to write up a few details about how he reached his conclusion because he was moving fast enough that I wasn’t actually learning anything from what he was saying to me on IRC.

Re: [openstack-dev] [all] The future of the integrated release

On Aug 26, 2014, at 2:01 PM, Joe Gordon wrote: > > > > On Wed, Aug 20, 2014 at 2:25 AM, Eoghan Glynn wrote: > > > > > > Additional cross-project resources can be ponied up by the large > > > > contributor companies, and existing cross-project resources are not > > > > necessarily divertabl

Re: [openstack-dev] [all] [glance] python namespaces considered harmful to development, lets not introduce more of them

On 08/27/2014 04:31 PM, Sean Dague wrote: > So this change came in with adding glance.store - > https://review.openstack.org/#/c/115265/5/lib/glance, which I think is a > bad direction to be headed. > > Here is the problem when it comes to working with code from git, in > python, that uses namespa

[openstack-dev] [QA] Meeting Thursday August 28th at 17:00 UTC

Hi Everyone, Just a quick reminder that the weekly OpenStack QA team IRC meeting will be this Thursday, August 28th at 17:00 UTC in the #openstack-meeting channel. The agenda for tomorrow's meeting can be found here: https://wiki.openstack.org/wiki/Meetings/QATeamMeeting Anyone is welcome to add

  1   2   >