[openstack-dev] 答复: [heat] autoscaling across regions and availability zones

I have register a bp about this : https://blueprints.launchpad.net/heat/+spec/implement-autoscalinggroup-availabilityzones ・ ・ And I am thinking how to implement this recently. ・ ・ According to AWS autoscaling implementation “attempts to distribute instances evenly between the Av

[openstack-dev] [keystone][specs] listing the entire API in a new spec

To add to the growing pains of keystone-specs, one thing I've noticed is, there is inconsistency in the 'REST API Impact' section. To be clear here, I don't mean we shouldn't include what new APIs will be created, I think that is essential. But rather, remove the need to specifically spell out the

Re: [openstack-dev] [neutron] Flavor framework: Conclusion

German, First of all extension list looks lbaas-centric right now. Secondly, TLS and L7 are such APIs which objects should not require loadbalancer or flavor to be created (like pool or healthmonitor that are pure db objects). Only when you associate those objects with loadbalancer (or its child o

Re: [openstack-dev] [heat] One more lifecycle plug point - in scaling groups

Steven Hardy wrote on 07/02/2014 06:16:21 AM: > On Wed, Jul 02, 2014 at 02:41:19AM +, Adrian Otto wrote: > >Zane, > >If you happen to have a link to this blueprint, could you replywith it? ... > > I believe Zane was referring to: > > https://blueprints.launchpad.net/heat/+spec/updat

Re: [openstack-dev] [neutron] Specs repo not synced

On 07/04/2014 01:30 AM, Salvatore Orlando wrote: > git.openstack.org has an up-to-date > log: http://git.openstack.org/cgit/openstack/neutron-specs/log/ > > Unfortunately I don't know what the policy is for syncing repos with github. they should sync automatically, some

[openstack-dev] [TripleO] Building deploy ramdisks with dracut

I've recently been looking into using dracut to build the deploy-ramdisks that we use for TripleO. There are a few reasons for this: 1) dracut is a fairly standard way to generate a ramdisk, so users are more likely to know how to debug problems with it. 2) If we build with dracut, we get a lot o

[openstack-dev] [nova][libvirt] why use domain destroy instead of shutdown?

Hi all, I noticed in nova/virt/libvirt/driver.py we use domain destroy instead of domain shutdown in most cases (except for soft reboot). Is there a special reason we don't use shutdown to do a graceful shutdown of the guest for the stop, shelve, migrate, etc functions? Using destroy can corrup

Re: [openstack-dev] [keystone][qa] Returning 203 in keystone v2 list apis?

On 07/03/2014 04:48 PM, David Kranz wrote: While moving success response code checking in tempest to the client, I noticed that exactly one of the calls to list users for a tenant checked for 200 or 203. Looking at http://docs.openstack.org/api/openstack-identity-service/2.0/content/, it seems

Re: [openstack-dev] [keystone][qa] Returning 203 in keystone v2 list apis?

On Thu, Jul 3, 2014 at 4:18 PM, Brant Knudson wrote: > > On Thu, Jul 3, 2014 at 3:48 PM, David Kranz wrote: > >> While moving success response code checking in tempest to the client, I >> noticed that exactly one of the calls to list users for a tenant checked >> for 200 or 203. Looking at http:

Re: [openstack-dev] [neutron] Specs repo

git.openstack.org has an up-to-date log: http://git.openstack.org/cgit/openstack/neutron-specs/log/ Unfortunately I don't know what the policy is for syncing repos with github. Salvatore On 4 July 2014 00:34, Sumit Naiksatam wrote: > Is this still the right repo for this: > https://github.com

Re: [openstack-dev] [neutron] Flavor framework: Conclusion

I am actually a bit bummed that Extensions are postponed. In LBaaS we are working hard on L7 and TLS extensions which we (the operators) like to switch on and off with different flavors... German -Original Message- From: Kyle Mestery [mailto:mest...@noironetworks.com] Sent: Thursday,

Re: [openstack-dev] [Neutron][LBaaS] Status of entities that do not exist in a driver backend

Hi Jorge, +1 for QUEUED and DETACHED I would suggest to make the time how long we keep entities in DELETED state configurable. We use something like 30 days, too, but we have made it configurable to adapt to changes... German -Original Message- From: Jorge Miramontes [mailto:jorge.mir

Re: [openstack-dev] [neutron][oslo.messaging]

Thanks Nader for the extra effort and I am glad you made progress here. Milton From: Nader Lahouti [mailto:nader.laho...@gmail.com] Sent: Thursday, July 03, 2014 3:59 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [neutron][oslo.messaging] Thanks

Re: [openstack-dev] [neutron][oslo.messaging]

Thanks a lot Doug and Alexei for your prompt response. I used what Doug suggested and worked. Thanks again for the help. Nader. On Thu, Jul 3, 2014 at 12:04 PM, Doug Hellmann wrote: > On Thu, Jul 3, 2014 at 1:58 PM, Alexei Kornienko > wrote: > > Hi, > > > > You can use oslo.messaging._drivers

Re: [openstack-dev] [trove] Discussion of capabilities feature

Iccha, Thanks for the feedback. I guess I should have been more specific - my intent here was to layout use cases and requirements and not talk about specific implementations. I believe that if we can get agreement on the requirements, it will be easier to review/discuss design/implementation c

[openstack-dev] [neutron] Specs repo

Is this still the right repo for this: https://github.com/openstack/neutron-specs The latest commit on the master branch shows June 25th timestamp, but we have had a lots of patches merging after that. Where are those going? Thanks, ~Sumit. ___ OpenSta

Re: [openstack-dev] [third-party-ci][neutron] What is "Success" exactly?

On 07/03/2014 04:34 PM, Kevin Benton wrote: > Yes, I can propose a spec for that. It probably won't be until Monday. > Is that okay? > Sure, that's fine. Thanks Kevin, I look forward to your spec once it is up. Enjoy tomorrow. :D Thanks Kevin, Anita. > > On Thu, Jul 3, 2014 at 11:42 AM, Anita Ku

Re: [openstack-dev] [neutron][oslo.messaging]

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 03/07/14 19:47, Nader Lahouti wrote: > Hi All and Ihar, > > As part of blueprint oslo-messaging the > neutron/openstack/common/rpc tree is removed. I was using > impl_kombu module to process notification from keystone with this > following code s

Re: [openstack-dev] [Neutron][LBaaS] Layer7 Switching - L7 Rule - comapre_type values

I was implying that it applies to all drivers. Cheers, --Jorge From: Eugene Nikanorov mailto:enikano...@mirantis.com>> Reply-To: "OpenStack Development Mailing List (not for usage questions)" mailto:openstack-dev@lists.openstack.org>> Date: Thursday, July 3, 2014 3:30 PM To: "OpenStack Developme

Re: [openstack-dev] [keystone][qa] Returning 203 in keystone v2 list apis?

On Thu, Jul 3, 2014 at 3:48 PM, David Kranz wrote: > While moving success response code checking in tempest to the client, I > noticed that exactly one of the calls to list users for a tenant checked > for 200 or 203. Looking at http://docs.openstack.org/api/ > openstack-identity-service/2.0/cont

Re: [openstack-dev] [DevStack] neutron config not working

On Thu, Jul 3, 2014 at 10:14 AM, Paul Czarkowski wrote: > I¹m seeing similar. Instances launch, they show as having Ips in > `neutron list` but I cannot access them via IP. > > Other thing I¹ve notices is that doing a `neutron agent-list` gives me an > empty list, I would assume it should a

Re: [openstack-dev] [neutron] Flavor framework: Conclusion

Awesome, thanks for working on this Eugene and Mark! I'll still leave an item on Monday's meeting agenda to discuss this, hopefully it can be brief. Thanks, Kyle On Thu, Jul 3, 2014 at 10:32 AM, Eugene Nikanorov wrote: > Hi, > > Mark and me has spent some time today discussing existing proposals

[openstack-dev] [nova] nova bug scrub web page

Hi Folks - I have taken a script from the infra folks and jogo, made some tweaks and have put it into a web page. Please see it here http://54.201.139.117/demo.html This is all of the new, confirmed, triaged, and in progress bugs that we have in nova as of a couple of hours ago. I have added

Re: [openstack-dev] [Keystone] HTTP Get and HEAD requests mismatch on resulting HTTP status (proposed REST API Response Status Changes)

Hi, This is very similar to an issue I encountered with Glance. For some unknown reason, we were adding a Location header for 200 responses. When served behind apache+mod_fcgid, the module saw the Location header and has a hard coded conversion to 302 Redirect. This caused glanceclient to follo

[openstack-dev] [keystone][qa] Returning 203 in keystone v2 list apis?

While moving success response code checking in tempest to the client, I noticed that exactly one of the calls to list users for a tenant checked for 200 or 203. Looking at http://docs.openstack.org/api/openstack-identity-service/2.0/content/, it seems that most of the list apis can return 203.

[openstack-dev] openstack and SDN

The most challenge part for me for the past few days is understanding the how SDN can reduce the burden on Neutron. A single SDN plugin consider OpenDayLight controller plugin deployed on neutron. I have physical and virtual switches which support open flow. I know OpenFlow will install the flow t

Re: [openstack-dev] [third-party-ci][neutron] What is "Success" exactly?

Yes, I can propose a spec for that. It probably won't be until Monday. Is that okay? On Thu, Jul 3, 2014 at 11:42 AM, Anita Kuno wrote: > On 07/03/2014 02:33 PM, Kevin Benton wrote: > > Maybe we can require period checks against the head of the master > > branch (which should always pass) and b

Re: [openstack-dev] [third-party] - rebasing patches for CI

Are these zuul refs publicly accessible so that the third party CI systems could reference then to guarantee they are testing the same thing? On Thu, Jul 3, 2014 at 11:31 AM, Jay Pipes wrote: > On 07/03/2014 02:10 PM, Kevin Benton wrote: > >> The reason I thought it changed was that this is the

Re: [openstack-dev] [Neutron][LBaaS] Layer7 Switching - L7 Rule - comapre_type values

> I also don't think it is fair for certain drivers to hold other drivers "hostage" For some time there was a policy (openstack-wide) that public API should have a free open source implementation. In this sense open source driver may hold other drivers as "hostages". Eugene. On Thu, Jul 3, 2014

Re: [openstack-dev] [trove] Discussion of capabilities feature

Hey Doug, Thank you so much for putting this together. I have some questions/clarifications(inline) which would be useful to be addressed in the spec. From: Doug Shelley mailto:d...@tesora.com>> Reply-To: "OpenStack Development Mailing List (not for usage questions)" mailto:openstack-dev@list

Re: [openstack-dev] [Fuel] Few hot questions related to patching for openstack

On Thu, Jul 3, 2014 at 7:05 AM, Aleksandr Didenko wrote: >> I think we should allow user to delete unneeded releases. > > In this case user won't be able to add new nodes to the existing > environments of the same version. So we should check and warn user about it, > or simply not allow to delete

Re: [openstack-dev] [Keystone] HTTP Get and HEAD requests mismatch on resulting HTTP status (proposed REST API Response Status Changes)

Here is the list of patches pending to resolve this issue (Keystone Master, Keystone Stable/Icehouse, and Tempest) https://review.openstack.org/#/q/status:open+topic:bug/1334368,n,z  — Morgan Fainberg -- From: Nathan Kinder nkin...@redhat.co

[openstack-dev] Announcing git-review 1.24

I am pleased to announce git-review 1.24 is officially released today (Thursday, July 3, 2014). This version brings together 77 new changes from 20 different collaborators including fixes for 15 bugs and a variety of other improvements: https://git.openstack.org/cgit/openstack-infra/git-review/log

Re: [openstack-dev] [blazar] py26 and py27 jobs failing

Yes I know that, but we need the big patch in order to get our V2 REST API working, so I asked to review this patch instead of submitting a new one. On Wed, 2014-07-02 at 17:24 -0400, Ryan Petrello wrote: > That's a pretty notable review to accommodate the pecan change. In the > meantime, wouldn'

Re: [openstack-dev] [OpenStack-Infra] [QA][Infra] Mid-Cycle Meet-up Registration Closed

Matthew Treinish writes: > Hi Everyone, > > Just a quick update, we have to close registration for the Infra/QA mid-cycle > meet-up. Based on the number of people who have signed up on the wiki page [1] > we are basically at the maximum capacity for the rooms we reserved. So if you > had intended

Re: [openstack-dev] [Nova] [Gantt] Scheduler split status

On 07/03/2014 01:53 PM, Sylvain Bauza wrote: > Hi, > > == > tl; dr: A decision has been made to split out the scheduler to a > separate project not on a feature parity basis with nova-scheduler, your > comments are welcome. > == ... > During the last Gantt meeting held Tuesday, we discussed abou

[openstack-dev] [trove] Discussion of capabilities feature

At yesterday's Trove team meeting [1] there was significant discussion around the Capabilities [2] feature. While the community previously approved a BP and some of the initial implementation, it is apparent now that there is no agreement in the community around the requirements, use cases or pr

[openstack-dev] [sahara] team meeting minutes July 3

Again, thanks everyone who have joined Sahara meeting. Below are the logs from the meeting. Minutes: http://eavesdrop.openstack.org/meetings/sahara/2014/sahara.2014-07-03-18.06.html Logs: http://eavesdrop.openstack.org/meetings/sahara/2014/sahara.2014-07-03-18.06.log.html Thanks, Dmitry _

Re: [openstack-dev] [neutron][oslo.messaging]

On Thu, Jul 3, 2014 at 1:58 PM, Alexei Kornienko wrote: > Hi, > > You can use oslo.messaging._drivers.impl_rabbit instead of impl_kombu > It was renamed and slightly change but I think it will work as you expect. You should not depend on using any API defined in that module. The _drivers package

Re: [openstack-dev] [Neutron][LBaaS] Status of entities that do not exist in a driver backend

+1 to QUEUED status. For entities that have the concept of being attached/detached why not have a 'DETACHED' status to indicate that the entity is not provisioned at all (i.e. The config is just stored in the DB). When it is attached during provisioning then we can set it to 'ACTIVE' or any of the

Re: [openstack-dev] [Neutron][LBaaS] Which entities need status

Hey German, We have similar statuses. I have been wanting to add a 'QUEUED' status however. The reason is that we currently use 'BUILD' which indicates active provisioning when in reality it is actually queued first and then provisioned. Thus, there are potential issues when trying to determine av

Re: [openstack-dev] [third-party-ci][neutron] What is "Success" exactly?

On 07/03/2014 02:33 PM, Kevin Benton wrote: > Maybe we can require period checks against the head of the master > branch (which should always pass) and build statistics based on the results > of that. I like this suggestion. I really like this suggestion. H, what to do with a good suggestion?

Re: [openstack-dev] [third-party-ci][neutron] What is "Success" exactly?

On Thu, Jul 3, 2014 at 10:27 AM, Kevin Benton wrote: > >This allows the viewer to see categories of reviews based upon their > >divergence from OpenStack's Jenkins results. I think evaluating > >divergence from Jenkins might be a metric worth consideration. > > I think the only thing this really

Re: [openstack-dev] [Neutron][LBaaS] Layer7 Switching - L7 Rule - comapre_type values

I agree. Also, since we are planning on having two different API versions run in parallel the only driver that needs to be worked on initially is the reference implementation. I'm guessing we will have two reference implementations, one for v1 and one for v2. The v2 implementation currently see

Re: [openstack-dev] [third-party-ci][neutron] What is "Success" exactly?

Maybe we can require period checks against the head of the master branch (which should always pass) and build statistics based on the results of that. Otherwise it seems like we have to take a CI system's word for it that a particular patch indeed broke that system. -- Kevin Benton On Thu, Jul 3

Re: [openstack-dev] [third-party] - rebasing patches for CI

On 07/03/2014 02:10 PM, Kevin Benton wrote: The reason I thought it changed was that this is the first cycle where I have encountered scenarios where my unit tests for the patch run fine locally, but then they fail when they are checked by Jenkins (caused by a change after the parent of my patch)

Re: [openstack-dev] [third party] - minimum response time for 3rd party CI responses

>In short, you need to test every single proposed patch to the system fully and consistently, otherwise there's simply no point in running any tests at all, as you will spend an inordinate amount of time tracking down what broke what. I agree that every patch should be tested. However, since third

Re: [openstack-dev] [third-party] - rebasing patches for CI

The reason I thought it changed was that this is the first cycle where I have encountered scenarios where my unit tests for the patch run fine locally, but then they fail when they are checked by Jenkins (caused by a change after the parent of my patch). I suppose I was just lucky before and never

Re: [openstack-dev] [third-party-ci][neutron] What is "Success" exactly?

On 07/03/2014 01:27 PM, Kevin Benton wrote: >> This allows the viewer to see categories of reviews based upon their >> divergence from OpenStack's Jenkins results. I think evaluating >> divergence from Jenkins might be a metric worth consideration. > > I think the only thing this really reflects t

Re: [openstack-dev] [neutron][oslo.messaging]

Hi, You can use /oslo.messaging._drivers.impl_rabbit/ instead of impl_kombu It was renamed and slightly change but I think it will work as you expect. Regards, Alexei Kornienko On 07/03/2014 08:47 PM, Nader Lahouti wrote: Hi All and Ihar, As part of blueprint oslo-messaging the neutron/openst

[openstack-dev] [Nova] [Gantt] Scheduler split status

Hi, == tl; dr: A decision has been made to split out the scheduler to a separate project not on a feature parity basis with nova-scheduler, your comments are welcome. == As it has been agreed now a cycle ago, the nova-scheduler will be ported to a separate OpenStack project, called Gantt [1]. The

Re: [openstack-dev] [TripleO] [Heat] Reminder: Mid-cycle Meetup - Attendance Confirmation

On 30/06/14 13:02 -0400, Jordan OMara wrote: On 25/06/14 14:32 -0400, Jordan OMara wrote: On 25/06/14 18:20 +, Carlino, Chuck (OpenStack TripleO, Neutron) wrote: Is $179/day the expected rate? Thanks, Chuck Yes, that's the best rate available from both of the downtown (walkable) hotels.

Re: [openstack-dev] [olso] olso incubator logging issues

On Mon, Jun 30, 2014 at 9:00 AM, Sean Dague wrote: > Every time I crack open a nova logs in detail, at least 2 new olso > incubator log issues have been introduced. > > The current ones is clearly someone is over exploding arrays, as we're > getting things like: > 2014-06-29 13:36:41.403 19459 DEB

Re: [openstack-dev] [neutron][oslo.messaging]

You'll find the documentation for using oslo.messaging at http://docs.openstack.org/developer/oslo.messaging/ Based on the fact that you mention listening for notifications, you probably want to look at the notification listener documentation in particular (http://docs.openstack.org/developer/osl

[openstack-dev] [neutron][oslo.messaging]

Hi All and Ihar, As part of blueprint oslo-messaging the neutron/openstack/common/rpc tree is removed. I was using impl_kombu module to process notification from keystone with this following code sample: ... from neutron.openstack.common.rpc import impl_kombu try: conf = impl_kom

Re: [openstack-dev] [OpenStack-Infra] [infra] Nominations for jenkins-job-builder core

Looks like there are no objections to this nomination so I have made Marc and Darragh Jenkins Job Builder Core reviewers. Congrats guys and keep the reviews rolling. On Mon, Jun 30, 2014 at 10:52 AM, Darragh Bailey wrote: > > > On 20 June 2014 22:01, James E. Blair wrote: > >> Hi, >> >> The J

Re: [openstack-dev] [oslo] Openstack and SQLAlchemy

On Mon, Jun 30, 2014 at 12:56 PM, Mike Bayer wrote: > Hi all - > > For those who don't know me, I'm Mike Bayer, creator/maintainer of > SQLAlchemy, Alembic migrations and Dogpile caching. In the past month > I've become a full time Openstack developer working for Red Hat, given > the task of car

Re: [openstack-dev] [third-party-ci][neutron] What is "Success" exactly?

>This allows the viewer to see categories of reviews based upon their >divergence from OpenStack's Jenkins results. I think evaluating >divergence from Jenkins might be a metric worth consideration. I think the only thing this really reflects though is how much the third party CI system is mirrori

Re: [openstack-dev] Moving neutron to oslo.db

Ben, As I know the API of oslo.db and oslo-incubator/db are almost the same. So why it should be complicated? Best regards, Boris Pavlovic On Thu, Jul 3, 2014 at 9:10 PM, Ben Nemec wrote: > +27, -2401 > > Wow, that's pretty painless. Were there earlier patches to Neutron to > prepare for t

Re: [openstack-dev] [oslo] Asyncio and oslo.messaging

On Thu, Jul 3, 2014 at 11:27 AM, Mark McLoughlin wrote: > Hey > > This is an attempt to summarize a really useful discussion that Victor, > Flavio and I have been having today. At the bottom are some background > links - basically what I have open in my browser right now thinking > through all of

Re: [openstack-dev] [third party] - minimum response time for 3rd party CI responses

On 07/03/2014 08:42 AM, Luke Gorrie wrote: On 3 July 2014 02:44, Michael Still mailto:mi...@stillhq.com>> wrote: The main purpose is to let change reviewers know that a change might be problematic for a piece of code not well tested by the gate Just a thought: A "sampling" approach co

Re: [openstack-dev] Moving neutron to oslo.db

+27, -2401 Wow, that's pretty painless. Were there earlier patches to Neutron to prepare for the transition or was it really that easy? On 07/03/2014 07:34 AM, Salvatore Orlando wrote: > No I was missing everything and kept wasting time because of alembic. > > This will teach me to keep my mout

Re: [openstack-dev] [neutron][third-party] Simple and robust CI script?

On 1 July 2014 19:12, Luke Gorrie wrote: > It does not yet run devstack/tempest and I hope to reuse that part from > somebody else's efforts. > shellci is happily voting on the sandbox with the Snabb NFV CI account so far: http://egg.snabb.co:81/shellci/shellci.log Time to make it start running

Re: [openstack-dev] [third party] - minimum response time for 3rd party CI responses

On 07/03/2014 03:49 AM, Luke Gorrie wrote: On 3 July 2014 02:44, Michael Still mailto:mi...@stillhq.com>> wrote: I have seen both. Normally there's a failure, reviewers notice, and then the developer spins trying out fixes by uploading new patch sets. Interesting. Yes, I can see that y

Re: [openstack-dev] [all] Launchpad comment boxes, not wrapping where you want??

On 07/03/2014 10:48 AM, Derek Higgins wrote: If your like me, launchpads wrapping of paragraphs in comment boxes gets under your skin, making it very difficult to follow tracebacks, logs, etc see https://bugs.launchpad.net/launchpad/+bug/545125 I finally got motivated to try and do somethin

Re: [openstack-dev] [third-party-ci][neutron] What is "Success" exactly?

On 07/03/2014 10:31 AM, Sullivan, Jon Paul wrote: >> -Original Message- >> From: Anita Kuno [mailto:ante...@anteaya.info] >> Sent: 03 July 2014 15:06 >> To: openstack-dev@lists.openstack.org >> Subject: Re: [openstack-dev] [third-party-ci][neutron] What is "Success" >> exactly? > > I guess

[openstack-dev] [Containers] Nova virt driver requirements

Hi, All! As far as I know, there are some requirements, which virt driver must meet to use Openstack 'label'. For example, it's not allowed to mount cinder volumes inside host OS. Are there any documents, describing all such things? How can I determine, if my virtualization driver for nova (de

Re: [openstack-dev] [Neutron][LBaaS] Status of entities that do not exist in a driver backend

If the objects remain in 'PENDING_CREATE' until provisioned it would seem that the process got stuck in that status and may be in a bad state from user perspective. I like the idea of QUEUED or similar to reference that the object has been accepted but not provisioned. Phil On 7/3/14 10:28 AM, "B

Re: [openstack-dev] [neutron] Flavor framework: Conclusion

Hi, Mark and me has spent some time today discussing existing proposals and I think we got to a consensus. Initially I had two concerns about Mark's proposal which are - extension list attribute on the flavor - driver entry point on the service profile The first idea (ext list) need to be clarifi

[openstack-dev] [Neutron][LBaaS] Status of entities that do not exist in a driver backend

With the new API and object model refactor there have been some issues arising dealing with the status of entities. The main issue is that Listener, Pool, Member, and Health Monitor can exist independent of a Load Balancer. The Load Balancer is the entity that will contain the information about w

[openstack-dev] [oslo] Asyncio and oslo.messaging

Hey This is an attempt to summarize a really useful discussion that Victor, Flavio and I have been having today. At the bottom are some background links - basically what I have open in my browser right now thinking through all of this. We're attempting to take baby-steps towards moving completely

Re: [openstack-dev] [DevStack] neutron config not working

I¹m seeing similar. Instances launch, they show as having Ips in `neutron list` but I cannot access them via IP. Other thing I¹ve notices is that doing a `neutron agent-list` gives me an empty list, I would assume it should at least show the dhcp agent ? On 7/1/14, 12:00 PM, "Kyle Mestery"

Re: [openstack-dev] [sahara] team meeting July 3 1800 UTC

I'm on Paris mid-cycle sprint, so, Alex Ignatov and Dmitry Mescheryakov will chair the meeting today. On Wed, Jul 2, 2014 at 4:35 PM, Sergey Lukjanov wrote: > Hi folks, > > We'll be having the Sahara team meeting as usual in > #openstack-meeting-alt channel. > > Agenda: https://wiki.openstack.org

Re: [openstack-dev] [Neutron] DVR SNAT shortcut

Salvatore, There is FIP distribution at the agent level, in the sense the N/S of FIP for a VM will be hosted on the same compute node. We centralized SNAT from feedback by others. The current design and code only supports centralized SNAT for DVR routers. The design could be modified to allo

[openstack-dev] [all] Launchpad comment boxes, not wrapping where you want??

If your like me, launchpads wrapping of paragraphs in comment boxes gets under your skin, making it very difficult to follow tracebacks, logs, etc see https://bugs.launchpad.net/launchpad/+bug/545125 I finally got motivated to try and do something about it (at least in chrome), as the above b

Re: [openstack-dev] [third-party-ci][neutron] What is "Success" exactly?

> -Original Message- > From: Anita Kuno [mailto:ante...@anteaya.info] > Sent: 03 July 2014 15:06 > To: openstack-dev@lists.openstack.org > Subject: Re: [openstack-dev] [third-party-ci][neutron] What is "Success" > exactly? I guess you missed this last time - the mail had gotten quite long

Re: [openstack-dev] [neutron]Performance of security group

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Oh, so you have the enhancement implemented? Great! Any numbers that shows how much we gain from that? /Ihar On 03/07/14 02:49, shihanzhang wrote: > Hi, Miguel Angel Ajo! Yes, the ipset implementation is ready, today > I will modify my spec, when t

Re: [openstack-dev] [Fuel] Few hot questions related to patching for openstack

Hi, > I think we should allow user to delete unneeded releases. In this case user won't be able to add new nodes to the existing environments of the same version. So we should check and warn user about it, or simply not allow to delete releases if there are live envs with the same version. On

Re: [openstack-dev] [third-party-ci][neutron] What is "Success" exactly?

On 07/03/2014 09:52 AM, Sullivan, Jon Paul wrote: >> -Original Message- >> From: Anita Kuno [mailto:ante...@anteaya.info] >> Sent: 03 July 2014 13:53 >> To: openstack-dev@lists.openstack.org >> Subject: Re: [openstack-dev] [third-party-ci][neutron] What is "Success" >> exactly? >> >> On 07/

Re: [openstack-dev] Using tmux instead of screen in devstack

On Thu, Jul 3, 2014 at 2:59 AM, Anant Patil wrote: > > >> If we did move from screen to tmux. > We aren't moving away... I have emphasized this enough. One should be > able just "choose" tmux explicitly otherwise things will run in screen > by default, as usual. > And I am saying due to the natur

Re: [openstack-dev] [neutron] Flavor framework: Conclusion

+1 On Wed, Jul 2, 2014 at 10:12 PM, Kyle Mestery wrote: > We're coming down to the wire here with regards to Neutron BPs in > Juno, and I wanted to bring up the topic of the flavor framework BP. > This is a critical BP for things like LBaaS, FWaaS, etc. We need this > work to land in Juno, as t

Re: [openstack-dev] [third-party-ci][neutron] What is "Success" exactly?

> -Original Message- > From: Anita Kuno [mailto:ante...@anteaya.info] > Sent: 03 July 2014 13:53 > To: openstack-dev@lists.openstack.org > Subject: Re: [openstack-dev] [third-party-ci][neutron] What is "Success" > exactly? > > On 07/03/2014 06:22 AM, Sullivan, Jon Paul wrote: > >> -Ori

Re: [openstack-dev] [third-party-ci][neutron] What is "Success" exactly?

On 07/03/2014 07:12 AM, Salvatore Orlando wrote: > Apologies for quoting again the top post of the thread. > > Comments inline (mostly thinking aloud) > Salvatore > > > On 30 June 2014 22:22, Jay Pipes wrote: > >> Hi Stackers, >> >> Some recent ML threads [1] and a hot IRC meeting today [2] br

Re: [openstack-dev] [third-party-ci][neutron] What is "Success" exactly?

On 07/03/2014 06:22 AM, Sullivan, Jon Paul wrote: >> -Original Message- >> From: Anita Kuno [mailto:ante...@anteaya.info] >> Sent: 01 July 2014 14:42 >> To: openstack-dev@lists.openstack.org >> Subject: Re: [openstack-dev] [third-party-ci][neutron] What is "Success" >> exactly? >> >> On 06/

Re: [openstack-dev] [Fuel] Few hot questions related to patching for openstack

So, our releases will have following versions of releases on UI: 5.0) "2014.1" 5.0.1) "2014.1.1-5.0.1" 5.1) "2014.1.1-5.1" And if someone install 5.0, upgrade it to 5.0.1 and then upgrade to 5.1, he will have three releases for each OS. I think we should allow user to delete unneeded releases. It

Re: [openstack-dev] [third party] - minimum response time for 3rd party CI responses

On 3 July 2014 02:44, Michael Still wrote: > The main purpose is to let change reviewers know that a change might > be problematic for a piece of code not well tested by the gate Just a thought: A "sampling" approach could be a reasonable way to stay responsive under heavy load and still give

Re: [openstack-dev] [neutron][third-party-ci] Midokura CI Bot results migration

On 07/03/2014 07:54 AM, Lucas Eznarriaga wrote: > Hi, > > Due to maintenance reasons, our CI results server has been moved to a new > machine. > As we didn't use a dns name before, previous links posted on the > review.openstack.org will appear as broken but they're still available > changing the

Re: [openstack-dev] Moving neutron to oslo.db

No I was missing everything and kept wasting time because of alembic. This will teach me to keep my mouth shut and don't distract people who are actually doing good work. Thanks for doings this work. Salvatore On 3 July 2014 14:15, Roman Podoliaka wrote: > Hi Salvatore, > > I must be missing

Re: [openstack-dev] Moving neutron to oslo.db

Hi Salvatore, I must be missing something. Hasn't it been done in https://review.openstack.org/#/c/103519/? :) Thanks, Roman On Thu, Jul 3, 2014 at 2:51 PM, Salvatore Orlando wrote: > Hi, > > As you surely now, in Juno oslo.db will graduate [1] > I am currently working on the port. It's been al

Re: [openstack-dev] [all] oslo.i18n 0.1.0 released

On 07/02/2014 09:11 PM, Doug Hellmann wrote: > The Oslo team is pleased to announce the first release of oslo.i18n, > the library that replaces the gettextutils module from oslo-incubator. > > The new library has been uploaded to PyPI, and there is a changeset in > the queue update the global requ

Re: [openstack-dev] [all] milestone-proposed is dead, long lives proposed/foo

On 2014-07-03 11:20:43 +0400 (+0400), Yuriy Taraday wrote: > I mean other mirrors like we have in our local net. Given not so > good connection to upstream repos (the reason we have this mirror > in the first place) I can't think of reliable way to clean them > up. Where can I find scripts that pro

[openstack-dev] [neutron][third-party-ci] Midokura CI Bot results migration

Hi, Due to maintenance reasons, our CI results server has been moved to a new machine. As we didn't use a dns name before, previous links posted on the review.openstack.org will appear as broken but they're still available changing the previous hardcoded ip: 119.15.112.63 by the new dns name: 3rdp

[openstack-dev] Moving neutron to oslo.db

Hi, As you surely now, in Juno oslo.db will graduate [1] I am currently working on the port. It's been already cleared that making alembic migrations "idempotent" and healing the DB schema is a requirement for this task. These two activities are tracked by the blueprints [2] and [3]. I think we've

Re: [openstack-dev] [TripleO] os-refresh-config run frequency

And the spec is now up at https://review.openstack.org/104524 for everyone to pull apart... ;) Matt > -Original Message- > From: Macdonald-Wallace, Matthew > Sent: 03 July 2014 11:18 > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] [Triple

Re: [openstack-dev] [neutron]Performance of security group

I have created a separate spec for the RPC part. https://review.openstack.org/104522 On 07/02/2014 05:52 PM, Kyle Mestery wrote: On Wed, Jul 2, 2014 at 3:43 AM, Ihar Hrachyshka wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 02/07/14 10:12, Miguel Angel Ajo wrote: Shihazhang, I

Re: [openstack-dev] [third-party-ci][neutron] What is "Success" exactly?

Apologies for quoting again the top post of the thread. Comments inline (mostly thinking aloud) Salvatore On 30 June 2014 22:22, Jay Pipes wrote: > Hi Stackers, > > Some recent ML threads [1] and a hot IRC meeting today [2] brought up some > legitimate questions around how a newly-proposed Sta

Re: [openstack-dev] [Neutron] DVR SNAT shortcut

I would just add that if I'm not mistaken the DVR work would also include the features currently offered by nova network's 'multi-host' capability. While DVR clearly does a lot more than multi host, keeping SNAT centralized only might not fully satisfy this requirement. Indeed nova-network offers S

[openstack-dev] [nova] Nova API meeting

Hi, Just a reminder that the weekly Nova API meeting is being held tomorrow Friday UTC . We encourage cloud operators and those who use the REST API such as SDK developers and others who and are interested in the future of the API to participate. In other timezones the meeting is at: EST

Re: [openstack-dev] [third-party-ci][neutron] What is "Success" exactly?

> -Original Message- > From: Anita Kuno [mailto:ante...@anteaya.info] > Sent: 01 July 2014 14:42 > To: openstack-dev@lists.openstack.org > Subject: Re: [openstack-dev] [third-party-ci][neutron] What is "Success" > exactly? > > On 06/30/2014 09:13 PM, Jay Pipes wrote: > > On 06/30/2014 07:0

Re: [openstack-dev] [TripleO] os-refresh-config run frequency

FWIW, I've just registered https://blueprints.launchpad.net/tripleo/+spec/re-assert-system-state and I'm about to start work on the spec. Matt > -Original Message- > From: Clint Byrum [mailto:cl...@fewbar.com] > Sent: 27 June 2014 17:01 > To: openstack-dev > Subject: Re: [openstack-dev]

  1   2   >