Re: [openstack-dev] [zaqar] [marconi] Juno Performance Testing (Round 1)

On 08/26/2014 11:41 PM, Kurt Griffiths wrote: > Hi folks, > > I ran some rough benchmarks to get an idea of where Zaqar currently stands > re latency and throughput for Juno. These results are by no means > conclusive, but I wanted to publish what I had so far for the sake of > discussion. > > No

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

Ports are bound in order of configured drivers so as long as the OpenVswitch driver is put first in the list, it will bind the ports it can and then ODL would bind the leftovers. [1][2] The only missing component is that ODL doesn't look like it uses l2pop so establishing tunnels between the OVS ag

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

On Wed, Aug 27, 2014 at 3:13 PM, Kevin Benton wrote: > Ports are bound in order of configured drivers so as long as the > OpenVswitch driver is put first in the list, it will bind the ports it can > and then ODL would bind the leftovers. [1][2] The only missing component is > that ODL doesn't loo

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

On Wed, Aug 27, 2014 at 2:44 PM, Kevin Benton wrote: > >Incubator doesn't mean being kicked out of tree, it just mean that the > API and resource model needs to be baked for fast iteration, and can't be > put in tree temporarily. > > That was exactly my point about developing a major feature like

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

>So why not agent based? Maybe I have an experimental operating system that can't run python. Maybe the RPC channel between compute nodes and Neutron doesn't satisfy certain security criteria. Regardless of the reason, it doesn't matter because that is an implementation detail that should be irrel

Re: [openstack-dev] [neutron] Juno-3 BP meeting

Works for me. On Wed, Aug 27, 2014 at 10:54 AM, Assaf Muller wrote: > Good for me. > > - Original Message - > > Works perfect for me. I will join. > > > > Sent from my Android phone using TouchDown ( www.nitrodesk.com ) > > > > > > -Original Message- > > From: Carl Baldwin [c...

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

>Flag is only for admin use, tenant can't see it, and the default policy for router is setup by config file. It's still a public API that will have to follow a deprecation cycle. If a new API was going to be introduced for admins to control the distributed nature of routers, it would have been nic

Re: [openstack-dev] [Fuel] Issues with hardcoded versions of requirements in specs of packages

> if we want to build iso with custom packages, we have to add flexibility to our dependencies lists. yes please, if there is no other option. It should be easy for anyone to build Fuel on custom packages, so let's target for it. I do not see issues in flexible deps while we are managing our upstr

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

I am curious to know about Swift role here. Can you elaborate little bit please? On Wed, Aug 27, 2014 at 4:14 AM, Steve Baker wrote: > On 23/08/14 07:39, Zane Bitter wrote: > > We held the inaugural Heat mid-cycle meetup in Raleigh, North Carolina > > this week. There were a dozen folks in atte

Re: [openstack-dev] [Fuel] Pre-5.1 and master builds ISO are available for download

Hi guys, I have to say something about beta releases. As far as I know our beta release has the same version 5.1 as our final release. I think this versions should be different, because in case of some problem it will be much easier to identify what version we are trying to debug. Also from the

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

I believe that local boot option is available in Ironic. Will not be a good idea to boot from local disk instead of relying on PXE boot always? Curious to know why we are not going this path? On Wed, Aug 27, 2014 at 3:54 AM, 严超 wrote: > Thank you very much. > And sorry for the cross-posting. >

Re: [openstack-dev] [Fuel] Pre-5.1 and master builds ISO are available for download

I would not use "beta" word anywhere at all. These are nightly builds, pre-5.1. So it will become 5.1 eventually, but for the moment - it is just master branch. We've not even reached HCF. After we reach HCF, we will start calling builds as Release Candidates (RC1, RC2, etc.) - and QA team runs a

Re: [openstack-dev] [neutron] Juno-3 BP meeting

If we yet had time at the end, as a lower priority, I'd like to talk about: https://blueprints.launchpad.net/neutron/+spec/agent-child-processes-status Which I believe is in good shape (l3 & dhcp are implemented, and leave the bases to do the work for all other agents). - Original Mess

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

hi Ian, I work on the CentOS images at centos.org On 08/26/2014 11:11 AM, Ian Wienand wrote: > I would like to get centos 7 based testing working, but I am stuck > without images being provided in the HP Cloud. Rackspace has a > (slightly quirky, but workable) image and we have an experimental j

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

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 therefore I want to offer my support. How can I p

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

On Wed, Aug 27, 2014 at 02:39:09PM +0530, Jyoti Ranjan wrote: >I am curious to know about Swift role here. Can you elaborate little bit >please? I think Zane already covered it with "We just want people to stop polling us, because it's killing our performance". Basically, if we provide t

Re: [openstack-dev] [nova][neutron] Migration from nova-network to Neutron for large production clouds

> -Original Message- > From: Michael Still [mailto:mi...@stillhq.com] > Sent: 26 August 2014 22:20 > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] [nova][neutron] Migration from nova-network to > Neutron for large production clouds ... > >

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

On Wed, 27 Aug 2014, Angus Salkeld wrote: I believe developers working on OpenStack work for companies that really want this to happen. The developers also want their projects to be well regarded. Just the way the problem is using framed is a bit like you did above and this is very daunting for

[openstack-dev] [hacking] Avoid old style class declarations

Hi, I've proposed a check to avoid having old style classes used in our code. https://review.openstack.org/#/c/116846/ It looks common sense to me, but if there's need to be any debate about, go ahead. Cheers, -- Julien Danjou /* Free Software hacker http://julien.danjou.info */ signatu

Re: [openstack-dev] [neutron][ml2] Openvswitch agent support for non promic mode adapters

you probably should consider using the future extension manager in ML2 : https://review.openstack.org/#/c/89211/ On Mon, Aug 25, 2014 at 12:54 PM, Irena Berezovsky wrote: > Hi Andreas, > We can definitely set some time to discuss this. > I am usually available from 5 to 14:00 UTC. > Let's follow

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

On 08/26/2014 11:40 AM, Anne Gentle wrote: > > > > On Mon, Aug 25, 2014 at 8:36 AM, Sean Dague > wrote: > > On 08/20/2014 12:37 PM, Zane Bitter wrote: > > On 11/08/14 05:24, Thierry Carrez wrote: > >> So the idea that being (and remaining) in the integrated r

[openstack-dev] [neutron] [nova] Parity meeting cancelled going forward

Due to low turnout and the fact we have a good hand on the parity work for Juno, I'm canceling this meeting going forward. If items pop up at the end of Juno which are parity related, please add them to the weekly Neutron meeting agenda [1] and we'll cover them there. Thanks! Kyle [1] https://wik

[openstack-dev] [all] Design Summit reloaded

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 the constraints we have (already booked space and time). Here is

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

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 some of those ideas for Paris, > within the con

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

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 some of those ideas for Paris, > within the con

[openstack-dev] [Neutron] Author tags

Hi, A few cycles ago the Nova group decided to remove @author from copyright statements. This is due to the fact that this information is stored in git. After adding a similar hacking rule to Neutron it has stirred up some debate. Does anyone have any reason to for us not to go ahead with https:

[openstack-dev] oslo.serialization 0.1.0 release

The Oslo team is pleased to announce the release of oslo.serialization 0.1.0, the first release of the Oslo library containing tools for rendering objects in formats useful for storage or transmission. This release moves the jsonutils module from the oslo-incubator to oslo.serialization. Pleas

Re: [openstack-dev] [neutron][IPv6] Neighbor Discovery for HA

Hi Xuhan, What I saw is that GARP is sent to the gateway port and also to the router ports, from a neutron router. I’m not sure why it’s sent to the router ports (internal network). My understanding for arping to the gateway port is that it is needed for proper NAT operation. Since we are not p

[openstack-dev] [oslo.messaging] Request to include AMQP 1.0 support in Juno-3

Hi All, I believe Juno-3 is our last chance to get this feature [1] included into olso.messaging. I honestly believe this patch is about as low risk as possible for a change that introduces a whole new transport into oslo.messaging. The patch shouldn't affect the existing transports at all, and

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

l2pop is about l2 networks optimization with tunnel creation and arp repsonder population (so this is not only a overlays network optimization. For example ofagent now use l2pop info for flat and vlan optimization [1]), This optimization is orthogonal to several agent based mechanism driver (lb, ov

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

On Wed, Aug 27, 2014 at 02:51:55PM +0200, 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

Re: [openstack-dev] [neutron][ml2] Openvswitch agent support for non promic mode adapters

Hi Mathieu, We had a short discussion with Andreas about the use case stated below and also considered the SR-IOV related use case. It seems that all required changes can be encapsulated in the L2 OVS agent, since it requires to add fdb mac registration on adapted interface. What was your idea r

[openstack-dev] [neutron] static IP & DHCP

Hi, I want to assign static IP to my instance. However, when trying to do so, the IP doesnt get associated with the VM. My VM boot logs show: Sending discover... Sending discover... Sending discover... No lease, failing WARN: /etc/rc3.d/S40-network failed How do I assign a static IP to my VM?

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

Daniel P. Berrange wrote: > On Wed, Aug 27, 2014 at 02:51:55PM +0200, Thierry Carrez wrote: >> [...] >> I think this proposal makes the best use of our setup: discuss clear >> cross-project issues, address key specific topics which need >> face-to-face time and broader attendance, then try to repli

Re: [openstack-dev] [neutron][IPv6] Neighbor Discovery for HA

Hi Xuhan, What I saw is that GARP is sent to the gateway port and also to the router ports, from a neutron router. I’m not sure why it’s sent to the router ports (internal network). My understanding for arping to the gateway port is that it is needed for proper NAT operation. Since we are not

[openstack-dev] [nova][NFV] VIF_VHOSTUSER

Howdy! I am writing to ask whether it will be possible to merge VIF_VHOSTUSER [1] in Juno? VIF_VHOSTUSER adds support for a QEMU 2.1 has a feature called vhost-user [2] that allows a guest to do Virtio-net I/O via a userspace vswitch. This makes it convenient to deploy new vswitches that are opti

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

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 such cases but the commit [2] removed > t

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

On 27/08/14 09:55, Thierry Carrez wrote: Daniel P. Berrange wrote: On Wed, Aug 27, 2014 at 02:51:55PM +0200, Thierry Carrez wrote: [...] I think this proposal makes the best use of our setup: discuss clear cross-project issues, address key specific topics which need face-to-face time and broade

Re: [openstack-dev] [neutron][ml2] Openvswitch agent support for non promic mode adapters

hi irena, in the proposal of andreas you want to enforce the non-promisc mode per l2-agent? so every port managed by this agent will have to be in a non-promisc state? at a first read of the mail, I understood that you want to manage that per port with an extension. By using an extension, an agent

[openstack-dev] test

Xingjun Chu IP Solutions Huawei Technologies Canada Co.,Ltd. 303 Terry Fox Drive, Suite 400 Kanata, Ontario Canada K2K 3J1 T: 613-595-1900 Ext. 1618 F: 613-595-1901 Email: xingjun@huawei.com [cid:image001.png@01CFC1DF.D00AF300] ___

Re: [openstack-dev] [qa][all][Heat] Packaging of functional tests

On 26/08/14 18:59, Clint Byrum wrote: Excerpts from Steve Baker's message of 2014-08-26 14:25:46 -0700: On 27/08/14 03:18, David Kranz wrote: On 08/26/2014 10:14 AM, Zane Bitter wrote: Steve Baker has started the process of moving Heat tests out of the Tempest repository and into the Heat repo

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

We probably will at some point, but I don't know that it's a huge priority right now. The PXE booting method works fine, and as I mentioned we don't intend you to reboot machines without using the undercloud anyway, just like Nova doesn't expect you to reboot vms directly via libvirt (or your driv

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

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. Please note that Swift cluster may give you old data at some point of time. On Wed, Aug 27, 2014 at 4:12 PM, Steven Har

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

On Wed, Aug 27, 2014 at 8:24 AM, Gary Kotton wrote: > Hi, > A few cycles ago the Nova group decided to remove @author from copyright > statements. This is due to the fact that this information is stored in git. > After adding a similar hacking rule to Neutron it has stirred up some > debate. > Doe

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

Hi Thiago, Yes Docker could be used to replace the virtualization layer on the Compute Node, it's the case if we configure Nova to use the Docker Driver. In our case, we are orchestrating Docker in OpenStack via Heat. We used a VM as a docker host for many reasons : - It is a way to economize

Re: [openstack-dev] [nova][NFV] VIF_VHOSTUSER

On Wed, Aug 27, 2014 at 04:06:25PM +0200, Luke Gorrie wrote: > Howdy! > > I am writing to ask whether it will be possible to merge VIF_VHOSTUSER [1] > in Juno? > > VIF_VHOSTUSER adds support for a QEMU 2.1 has a feature called vhost-user > [2] that allows a guest to do Virtio-net I/O via a usersp

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

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 namespaces, it's kind of a hack that violates the principle o

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

On 8/27/2014 8:51 AM, Thierry Carrez wrote: > better use of our 4 days Will the design space be available on the fifth day too? No need to schedule anything on that day ("Day 0"), but having the space available would be nice for ad hoc gatherings. ___

[openstack-dev] [nova] Brainstorming summit sessions

Hi, I'd like to start the summit planning process for Paris by asking for people to brain storm a list of topics we might want to cover. We can then prioritize that list and make sure that we address the most important issues. This is a process that worked well for us at the mid-cycle meetup. To

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

On Aug 27, 2014, at 8:47 AM, Sean Dague wrote: > On 08/26/2014 11:40 AM, Anne Gentle wrote: >> >> >> >> On Mon, Aug 25, 2014 at 8:36 AM, Sean Dague > > wrote: >> >>On 08/20/2014 12:37 PM, Zane Bitter wrote: >>> On 11/08/14 05:24, Thierry Carrez wrote: So the i

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

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. Please note that Swift cluster may give you

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

On 08/27/2014 09: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 uses namespa

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

On Wed, 27 Aug 2014, Sean Dague wrote: Here is the problem when it comes to working with code from git, in python, that uses namespaces, it's kind of a hack that violates the principle of least surprise. It's true this problem does happen... So I'd like us to revisit using a namespace for gl

[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

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

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] 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] [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

[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

[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

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

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] [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] [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

[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] [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

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] [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.

[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] 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] 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] [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

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] [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] [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] [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] [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] [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] [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] [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

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] [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] [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] [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] [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

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] [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] [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] [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] [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] [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

[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] [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

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] [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] 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] [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] [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] 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

  1   2   >