Re: [openstack-dev] [Nova] Blueprint: standard specification of guest CPU topology

Hi Chet, I have read this patch which may be commited by your workmate https://review.openstack.org/#/c/63254 and I have a question to ask: Case 1: An user want to build a 8vcpu instance, there may have seven flavors with 8vcpu which have different topology extra specs: 1s*4c*2t (s=sockets, c=cor

Re: [openstack-dev] Keystone Apache2 WSGI Fails when Token > 8190 Bytes

It turns out that there is a bug filed against the problem we are facing: https://bugs.launchpad.net/keystone/+bug/1255321 > -Original Message- > From: Miller, Mark M (EB SW Cloud - R&D - Corvallis) > Sent: Thursday, January 16, 2014 11:09 PM > To: OpenStack Development Mailing List (not

Re: [openstack-dev] Keystone Apache2 WSGI Fails when Token > 8190 Bytes

Thank you John for the response. However I am asking about another but similar problem. I am using the Apache2 WSGI front end to Keystone and not the Eventlet. Mark > -Original Message- > From: John Dickinson [mailto:m...@not.mn] > Sent: Thursday, January 16, 2014 10:39 PM > To: OpenSt

Re: [openstack-dev] [ ceilometer] The Pagination patches

Hi, Jay, Thanks for your reply. According to you review comments, I rebase my code, please see my comments for your questions. For the issue that ensure there is at least one unique column in the sort keys if pagination is used, I have an idea. How about add the primary key at the end of sort ke

Re: [openstack-dev] Keystone Apache2 WSGI Fails when Token > 8190 Bytes

Yep, you should follow https://bugs.launchpad.net/keystone/+bug/1190149 and the related patches in each project. --John On Jan 16, 2014, at 10:30 PM, Miller, Mark M (EB SW Cloud - R&D - Corvallis) wrote: > Hello, > > I have come across a bug or limitation when using an Apache2 SSL-WSGI fro

[openstack-dev] Keystone Apache2 WSGI Fails when Token > 8190 Bytes

Hello, I have come across a bug or limitation when using an Apache2 SSL-WSGI front end for Keystone. If the returned token for a Keystone authenticate request is greater than 8190 bytes, the mod_wsgi code throws an error similar to the following: [Thu Jan 16 22:27:47 2014] [info] Initial (No.1

Re: [openstack-dev] [nova] how is resource tracking supposed to work for live migration and evacuation?

There are some related discussion on this before. There is a BP at https://blueprints.launchpad.net/nova/+spec/extensible-resource-tracking which try to support more resources. And I have a documentation at https://docs.google.com/document/d/1gI_GE0-H637lTRIyn2UPfQVebfk5QjDi6ohObt6MIc0 . My

Re: [openstack-dev] [Nova] why don't we deal with "claims" when live migrating an instance?

I noticed the BP has been approved, but I really want to understand more on the reason, can anyone provide me some hints? In the BP, it states that "For resize, we need to confirm, as we want to give end user an opportunity to rollback". But why do we want to give user an opportunity to rollbac

Re: [openstack-dev] Proposal for dd disk i/o performance blueprint of cinder.

Excerpts from Alan Kavanagh's message of 2014-01-16 20:28:05 -0800: > +1makes sense to me. I will write up a Blueprint for this for review in > Ironic and we take it from their. > > I don't see this as evil firmware, more a good process we need to automate as > part of sanity checks before

Re: [openstack-dev] [TripleO][Tuskar] Domain Model Locations

Excerpts from Jay Pipes's message of 2014-01-12 11:40:41 -0800: > On Fri, 2014-01-10 at 10:28 -0500, Jay Dobies wrote: > > >> So, it's not as simple as it may initially seem :) > > > > > > Ah, I should have been clearer in my statement - my understanding is that > > > we're scrapping concepts like

Re: [openstack-dev] [ironic] Disk Eraser

Although the performance is important the more critical feature is to "guarantee complete dd for the disk". Alan From: Oleg Gelbukh [mailto:ogelb...@mirantis.com] Sent: January-16-14 5:21 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [ironic] Di

Re: [openstack-dev] Proposal for dd disk i/o performance blueprint of cinder.

The point was that tenant-A can not read or be able to "retrieve any data" once the blade lease is over the the blade is returned to the pool. Therefore, what would make sense is that we build an "in-service" a method to ensure that the disk is erased before being brought back into the pool to b

Re: [openstack-dev] [ironic] Disk Eraser

Cheers Chris I have used diskscrub and its one of the better tools. It would make sense as I noted in a previous email to have ironic run some dd tool before bringing the compute blade back into pool for scheduling. Should we write up a blueprint for this? Would also good to know if anyone has

Re: [openstack-dev] Proposal for dd disk i/o performance blueprint of cinder.

-Original Message- From: CARVER, PAUL [mailto:pc2...@att.com] Sent: January-16-14 8:21 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] Proposal for dd disk i/o performance blueprint of cinder. Alan Kavanagh wrote: >I posted a query to

Re: [openstack-dev] Proposal for dd disk i/o performance blueprint of cinder.

+1makes sense to me. I will write up a Blueprint for this for review in Ironic and we take it from their. I don't see this as evil firmware, more a good process we need to automate as part of sanity checks before taking a leased baremetal back and making it available in the pool again, imh

Re: [openstack-dev] [qa][Neutron][Tempest][Network] Break down NetworkBasicOps to smaller test cases

On Wed, Jan 15, 2014 at 11:20:22AM -0500, Yair Fried wrote: > Hi Guys > As Maru pointed out - NetworkBasicOps scenario has grown out of proportion > and is no longer "basic" ops. Is your issue here that it's just called basic ops and you don't think that's reflective of what is being tested in th

[openstack-dev] [qa][Nova] Update: Nova API List for Missing Tempest Tests

Hi, Thanks many guys for updating this list! I have updated: Nova API List for Missing Tempest Tests. https://docs.google.com/spreadsheet/ccc?key=0AmYuZ6T4IJETdEVNTWlYVUVOWURmOERSZ0VGc1BBQWc The summary of this list: different count from Tested or not

[openstack-dev] [QA] The future of nosetests with Tempest

Hi everyone, With some recent changes made to Tempest compatibility with nosetests is going away. We've started using newer features that nose just doesn't support. One example of this is that we've started using testscenarios and we're planning to do this in more places moving forward. So at Ice

Re: [openstack-dev] a "common" client library

On Jan 16, 2014, at 8:36 PM, "Renat Akhmerov" mailto:rakhme...@mirantis.com>> wrote: Ok, I think most of the reasoning you’ve said makes sense. So for a non-incubated project we’re going to have separate clients and then get them integrated into this single client once the project itself gets

[openstack-dev] [Openstack-dev][swift] profiling middleware blueprint status

hi John, I've been working on Swift profiling middleware blueprint since HK design summit. I found the status of direction needs approval and series goal is not defined yet. Would you please help to check if we need to change it? BTW, the code is ready for review. :-) -Edward Zhang_

Re: [openstack-dev] [State-Management] Proposal to add Changbin Liu to taskflow-core

On Jan 17, 2014 2:27 AM, "Joshua Harlow" wrote: > > Greetings all stackers, > > I propose that we add Changbin Liu[1] to the taskflow-core team[2]. +1 -- WBR, Ivan A. Melnikov ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lis

Re: [openstack-dev] a "common" client library

Ok, I think most of the reasoning you’ve said makes sense. So for a non-incubated project we’re going to have separate clients and then get them integrated into this single client once the project itself gets incubated? Or it’s going to happen when the project gets integrated into core os projec

Re: [openstack-dev] [savanna] savannaclient v2 api

My 5 cents: -- REMOVE - @rest.put('/node-group-templates/') - Not Implemented REMOVE - @rest.put('/cluster-templates/') - Not Implemented -- Disagree with that. Samsung people did great job in both savanna/savanna-dashboard to make this implemented [2], [3]. We should leave and support the

Re: [openstack-dev] a "common" client library

On Jan 16, 2014, at 8:42 PM, Jesse Noller wrote: > > > On Jan 16, 2014, at 4:59 PM, "Renat Akhmerov" wrote: > >> On 16 Jan 2014, at 13:06, Jesse Noller wrote: >> Since it’s pretty easy to get lost among all the opinions I’d like to clarify/ask a couple of things: Keep

Re: [openstack-dev] a "common" client library

On Jan 16, 2014, at 4:59 PM, "Renat Akhmerov" mailto:rakhme...@mirantis.com>> wrote: On 16 Jan 2014, at 13:06, Jesse Noller mailto:jesse.nol...@rackspace.com>> wrote: Since it’s pretty easy to get lost among all the opinions I’d like to clarify/ask a couple of things: * Keeping all the

Re: [openstack-dev] [Ceilometer] RFC: blueprint monitoring-network

Hi, Manuel. Thank you for your comments. > since you introduce switches that are currently not reflected in the Neutron > entities, am I correct that a switch.port is always unknown to Neutron? Can a > switch.port ever be a VM port? Yes, Neutron doesn't know a switch.port. A switch.port is rel

Re: [openstack-dev] [TripleO] milestone-proposed branches

>- Original Message - >From: "Clint Byrum" >To: "openstack-dev" >Sent: Thursday, January 16, 2014 7:29:28 PM >Subject: Re: [openstack-dev] [TripleO] milestone-proposed branches >Note that tripleo-incubator is special and should not be released. It >is intentionally kept unfrozen and un

Re: [openstack-dev] [nova] [neutron] PCI pass-through network support

On Thu, 2014-01-16 at 01:28 +0100, Ian Wells wrote: > To clarify a couple of Robert's points, since we had a conversation > earlier: > On 15 January 2014 23:47, Robert Li (baoli) wrote: > --- do we agree that BDF address (or device id, whatever > you call it), and node id should

Re: [openstack-dev] [TripleO] milestone-proposed branches

Note that tripleo-incubator is special and should not be released. It is intentionally kept unfrozen and unreleased to make sure there is no illusion of stability. If there are components in it that need releasing, they should be moved into relevant projects or forked into their own projects. Exc

Re: [openstack-dev] [TripleO] [Tuskar] [UX] Infrastructure Management UI - Icehouse scoped wireframes

Looking good, let me know if I can be of help to make some high-fidelity mockups. On Thu, Jan 16, 2014 at 6:30 AM, Jay Dobies wrote: > This is a really good evolution. I'm glad the wireframes are getting > closer to what we're doing for Icehouse. > > A few notes... > > On page 6, what does the

Re: [openstack-dev] "Evil" Firmware

On 01/16/2014 05:12 PM, CARVER, PAUL wrote: Jumping back to an earlier part of the discussion, it occurs to me that this has broader implications. There's some discussion going on under the heading of Neutron with regard to PCI passthrough. I imagine it's under Neutron because of a desire to pro

Re: [openstack-dev] Proposal for dd disk i/o performance blueprint of cinder.

On 01/16/2014 04:22 PM, Clint Byrum wrote: Excerpts from Fox, Kevin M's message of 2014-01-16 09:29:14 -0800: Yeah, I think the evil firmware issue is separate and should be solved separately. Ideally, there should be a mode you can set the bare metal server into where firmware updates are no

Re: [openstack-dev] a "common" client library

*snip* > > > Distinction between client layers won't get lost and would only be > improved. My basic idea is the following: > > 1) Transport layer would handle all transport related stuff - HTTP, > JSON encoding, auth, caching, etc. > > 2) Model layer (Resource classes, BaseManager, etc.) will

Re: [openstack-dev] [Nova] why don't we deal with "claims" when live migrating an instance?

Hi Scott, I'm now trying to fix this issue at https://blueprints.launchpad.net/nova/+spec/auto-confirm-cold-migration After the fix, we do not need to "confirm" the cold migration. http://lists.openstack.org/pipermail/openstack-dev/2014-January/023726.html Thanks, Jay 2014/1/17 Scott Devoid

Re: [openstack-dev] "Evil" Firmware

Clint Byrum wrote: >Excerpts from Alan Kavanagh's message of 2014-01-15 19:11:03 -0800: >> Hi Paul >> >> I posted a query to Ironic which is related to this discussion. My thinking >> was I want to ensure the case you note here (1) " a tenant can not read >> >another tenants disk.." the ne

Re: [openstack-dev] Proposal for instance-level snapshots in Nova

On Jan 16, 2014, at 1:28 PM, Jon Bernard wrote: > * Vishvananda Ishaya wrote: >> >> On Jan 14, 2014, at 2:10 PM, Jon Bernard wrote: >> >>> >>> As you’ve defined the feature so far, it seems like most of it could be implemented client side: * pause the instance * s

Re: [openstack-dev] a "common" client library

On 16 Jan 2014, at 13:06, Jesse Noller wrote: >> Since it’s pretty easy to get lost among all the opinions I’d like to >> clarify/ask a couple of things: >> >> Keeping all the clients physically separate/combining them in to a single >> library. Two things here: >> In case of combining them, w

Re: [openstack-dev] a "common" client library

On 16 Jan 2014, at 12:36, Dean Troyer wrote: > I've already written a POC for solum and some other things to demonstrate how > to add additional projects simply by installing the python-*client package. > https://github.com/dtroyer/python-oscplugin is a trivial example. Thanks, this link is

Re: [openstack-dev] [Neturon] firewall_driver and ML2 and vif_security discussion

Thanks! Kyle 2014/1/16 Kyle Mestery : > On Jan 16, 2014, at 4:27 PM, Nachi Ueno wrote: > >> Hi Bob, Kyle >> >> I pushed (A) https://review.openstack.org/#/c/67281/. >> so could you review it? >> > Just did, looks good Nachi, thanks! > >> 2014/1/16 Robert Kukura : >>> On 01/16/2014 03:13 PM, Kyle

Re: [openstack-dev] [Neturon] firewall_driver and ML2 and vif_security discussion

On Jan 16, 2014, at 4:27 PM, Nachi Ueno wrote: > Hi Bob, Kyle > > I pushed (A) https://review.openstack.org/#/c/67281/. > so could you review it? > Just did, looks good Nachi, thanks! > 2014/1/16 Robert Kukura : >> On 01/16/2014 03:13 PM, Kyle Mestery wrote: >>> >>> On Jan 16, 2014, at 1:37 P

Re: [openstack-dev] [OpenStack-Dev] Cherry picking commit from oslo-incubator

On Thu, Jan 16, 2014 at 3:19 PM, Ben Nemec wrote: > On 2014-01-16 13:48, John Griffith wrote: > >> Hey Everyone, >> >> A review came up today that cherry-picked a specific commit to OSLO >> Incubator, without updating the rest of the files in the module. I >> rejected that patch, because my phil

Re: [openstack-dev] [Neturon] firewall_driver and ML2 and vif_security discussion

Hi Bob, Kyle I pushed (A) https://review.openstack.org/#/c/67281/. so could you review it? 2014/1/16 Robert Kukura : > On 01/16/2014 03:13 PM, Kyle Mestery wrote: >> >> On Jan 16, 2014, at 1:37 PM, Nachi Ueno wrote: >> >>> Hi Amir >>> >>> 2014/1/16 Amir Sadoughi : Hi all, I just w

Re: [openstack-dev] Proposal for dd disk i/o performance blueprint of cinder.

Excerpts from CARVER, PAUL's message of 2014-01-16 05:21:24 -0800: > > Alan Kavanagh wrote: > > >I posted a query to Ironic which is related to this discussion. My thinking > >was I want to ensure the case you note here (1) " a >tenant can not read > >another tenants disk.." the next (2) w

Re: [openstack-dev] [nova] how is resource tracking supposed to work for live migration and evacuation?

On Jan 16, 2014, at 1:12 PM, Chris Friesen wrote: > Hi, > > I'm trying to figure out how resource tracking is intended to work for live > migration and evacuation. > > For a while I thought that maybe we were relying on the call to > ComputeManager._instance_update() in > ComputeManager.pos

Re: [openstack-dev] Proposal for dd disk i/o performance blueprint of cinder.

Excerpts from Fox, Kevin M's message of 2014-01-16 09:29:14 -0800: > Yeah, I think the evil firmware issue is separate and should be solved > separately. > > Ideally, there should be a mode you can set the bare metal server into where > firmware updates are not allowed. This is useful to more fo

[openstack-dev] [State-Management] Proposal to add Changbin Liu to taskflow-core

Greetings all stackers, I propose that we add Changbin Liu[1] to the taskflow-core team[2]. Changbin has been actively contributing to taskflow for a while now, both in helping develop code and helping with the review load. He has provided quality reviews and is doing an awesome job with the vari

Re: [openstack-dev] [gantt] Sync up patches

OK, it looks like the concensus is that we don't try and keep the gantt tree in sync with nova instead we: 1) Get the current gantt tree to pass unit tests 2) Get gantt to pass integration tests (e.g. get it working as the nova scheduler) 3) Modify devstack to optionally use gantt 4) Freeze

Re: [openstack-dev] [neutron] ML2 vlan type driver does not honor network_vlan_ranges

network_vlan_ranges is a 'pool' of vlans from which to pick a vlans for tenant networks. Provider networks are not confined to this pool. In fact, I believe it is a more common use-case that provider vlans are outside the pool so that they do not conflict with tenant vlan allocation. -- Henry On

Re: [openstack-dev] a "common" client library

On Jan 16, 2014, at 3:22 PM, Renat Akhmerov wrote: > Has anyone ever considered an idea of generating a fully functional REST > client automatically based on an API specification (WADL could be used for > that)? Not sure how convenient it would be, it really depends on a particular > implemen

Re: [openstack-dev] Proposal for instance-level snapshots in Nova

* Vishvananda Ishaya wrote: > > On Jan 14, 2014, at 2:10 PM, Jon Bernard wrote: > > > > > > >> As you’ve defined the feature so far, it seems like most of it could > >> be implemented client side: > >> > >> * pause the instance > >> * snapshot the instance > >> * snapshot any attached volume

Re: [openstack-dev] a "common" client library

On Jan 16, 2014, at 4:06 PM, Jesse Noller wrote: > > On Jan 16, 2014, at 2:22 PM, Renat Akhmerov wrote: > >> Since it’s pretty easy to get lost among all the opinions I’d like to >> clarify/ask a couple of things: >> >> Keeping all the clients physically separate/combining them in to a sing

[openstack-dev] [nova] how is resource tracking supposed to work for live migration and evacuation?

Hi, I'm trying to figure out how resource tracking is intended to work for live migration and evacuation. For a while I thought that maybe we were relying on the call to ComputeManager._instance_update() in ComputeManager.post_live_migration_at_destination(). However, in ResourceTracker.upd

Re: [openstack-dev] [Neturon] firewall_driver and ML2 and vif_security discussion

On 01/16/2014 03:13 PM, Kyle Mestery wrote: > > On Jan 16, 2014, at 1:37 PM, Nachi Ueno wrote: > >> Hi Amir >> >> 2014/1/16 Amir Sadoughi : >>> Hi all, >>> >>> I just want to make sure I understand the plan and its consequences. I’m on >>> board with the YAGNI principle of hardwiring mechanism

Re: [openstack-dev] a "common" client library

On Jan 16, 2014, at 2:22 PM, Renat Akhmerov mailto:rakhme...@mirantis.com>> wrote: Since it’s pretty easy to get lost among all the opinions I’d like to clarify/ask a couple of things: * Keeping all the clients physically separate/combining them in to a single library. Two things here:

Re: [openstack-dev] [Neturon] firewall_driver and ML2 and vif_security discussion

That also makes sense to me as the simplest option. Looking forward to all of your patches. Thanks, Amir On Jan 16, 2014, at 2:13 PM, Kyle Mestery mailto:mest...@siliconloons.com>> wrote: On Jan 16, 2014, at 1:37 PM, Nachi Ueno mailto:na...@ntti3.com>> wrote: Hi Amir 2014/1/16 Amir Sadoug

[openstack-dev] [neutron] ML2 vlan type driver does not honor network_vlan_ranges

In testing some new function I've written, I've unsurfaced the problem that the ML2 vlan type driver does not enforce the vlan range specified in the network_vlan_ranges option in ml2_conf.ini file. It is properly enforcing the physical network name, and even checking to be sure the segmentation

Re: [openstack-dev] a "common" client library

On Thu, Jan 16, 2014 at 2:22 PM, Renat Akhmerov wrote: > > >- Keeping all the clients physically separate/combining them in to a >single library. Two things here: > - In case of combining them, what exact project are we considering? > If this list is limited to core projects li

Re: [openstack-dev] [OpenStack-Dev] Cherry picking commit from oslo-incubator

On 2014-01-16 13:48, John Griffith wrote: Hey Everyone, A review came up today that cherry-picked a specific commit to OSLO Incubator, without updating the rest of the files in the module. I rejected that patch, because my philosophy has been that when you update/pull from oslo-incubator it sho

Re: [openstack-dev] a "common" client library

Since it’s pretty easy to get lost among all the opinions I’d like to clarify/ask a couple of things: Keeping all the clients physically separate/combining them in to a single library. Two things here: In case of combining them, what exact project are we considering? If this list is limited to

Re: [openstack-dev] [Neturon] firewall_driver and ML2 and vif_security discussion

On Jan 16, 2014, at 1:37 PM, Nachi Ueno wrote: > Hi Amir > > 2014/1/16 Amir Sadoughi : >> Hi all, >> >> I just want to make sure I understand the plan and its consequences. I’m on >> board with the YAGNI principle of hardwiring mechanism drivers to return >> their firewall_driver types for n

Re: [openstack-dev] [OpenStack-Dev] Cherry picking commit from oslo-incubator

I think I agree with you John. Micromanaging the common library just makes more work. Is there any argument to not syncing everything? And do you mean cherry-picking only some of the changes in a single module?!? if that's the case then future syncing could get weird, really weird. -Alex -

Re: [openstack-dev] a "common" client library

On Thu, Jan 16, 2014 at 8:40 PM, Donald Stufft wrote: > > On Jan 16, 2014, at 2:36 PM, Joe Gordon wrote: > > 2) major overhaul of client libraries so they are all based off a common > base library. This would cover namespace changes, and possible a push to > move CLI into python-openstackclient

[openstack-dev] [OpenStack-Dev] Cherry picking commit from oslo-incubator

Hey Everyone, A review came up today that cherry-picked a specific commit to OSLO Incubator, without updating the rest of the files in the module. I rejected that patch, because my philosophy has been that when you update/pull from oslo-incubator it should be done as a full sync of the entire mod

Re: [openstack-dev] a "common" client library

+1 to a stand alone library for this. >> 1) We would have to maintain rationale versioning and backwards compatibility of this library. If we start library from scratch we'll have to add/change lots of stuff before we'll reach some stability period. I don’t think this is a hard problem to solve.

Re: [openstack-dev] a "common" client library

On Jan 16, 2014, at 2:36 PM, Joe Gordon wrote: > 2) major overhaul of client libraries so they are all based off a common base > library. This would cover namespace changes, and possible a push to move CLI > into python-openstackclient This seems like the biggest win to me. ---

Re: [openstack-dev] [Neturon] firewall_driver and ML2 and vif_security discussion

Hi Amir 2014/1/16 Amir Sadoughi : > Hi all, > > I just want to make sure I understand the plan and its consequences. I’m on > board with the YAGNI principle of hardwiring mechanism drivers to return > their firewall_driver types for now. > > However, after (A), (B), and (C) are completed, to all

Re: [openstack-dev] a "common" client library

On Thu, Jan 16, 2014 at 2:03 PM, Alexei Kornienko < alexei.kornie...@gmail.com> wrote: > Hello Joe, > > > continuous refactoring and syncing across 22+ repositories sounds like a > nightmare, one that I would like to avoid. > > You are right this is not easy. > > However I have several reasons to

Re: [openstack-dev] [Nova] why don't we deal with "claims" when live migrating an instance?

Related question: Why does resize get called (and the VM put in "RESIZE VERIFY" state) when migrating from one machine to another, keeping the same flavor? On Thu, Jan 16, 2014 at 9:54 AM, Brian Elliott wrote: > > On Jan 15, 2014, at 4:34 PM, Clint Byrum wrote: > > > Hi Chris. Your thread may

Re: [openstack-dev] [Neturon] firewall_driver and ML2 and vif_security discussion

Hi all, I just want to make sure I understand the plan and its consequences. I’m on board with the YAGNI principle of hardwiring mechanism drivers to return their firewall_driver types for now. However, after (A), (B), and (C) are completed, to allow for Open vSwitch-based security groups (bl

[openstack-dev] [savanna] team meeting minutes Jan 16

Thanks everyone who have joined Savanna meeting. Here are the logs from the meeting: Minutes: savanna.2014-01-16-18.06.html Log: savanna.2014-01-16-18.06.log.html

Re: [openstack-dev] a "common" client library

Hello Joe, continuous refactoring and syncing across 22+ repositories sounds like a nightmare, one that I would like to avoid. You are right this is not easy. However I have several reasons to do that: The hardest part is to bring basic stuff in sync across all projects (That's what we are do

Re: [openstack-dev] sqla 0.8 ... and sqla 0.9

Also with: https://review.openstack.org/#/c/66051/ On 1/16/14, 10:40 AM, "Jeremy Stanley" wrote: >On 2014-01-12 07:27:11 -0500 (-0500), Sean Dague wrote: >> With the taskflow update, the only thing between upping our sqla >> requirement to < 0.8.99 is pbr's requirements integration test >> gett

Re: [openstack-dev] a "common" client library

On Jan 16, 2014, at 11:39 AM, Mark Washenberger mailto:mark.washenber...@markwash.net>> wrote: On Thu, Jan 16, 2014 at 8:06 AM, Dean Troyer mailto:dtro...@gmail.com>> wrote: On Thu, Jan 16, 2014 at 9:37 AM, Jesse Noller mailto:jesse.nol...@rackspace.com>> wrote: On Jan 16, 2014, at 9:26 AM,

Re: [openstack-dev] sqla 0.8 ... and sqla 0.9

On 2014-01-12 07:27:11 -0500 (-0500), Sean Dague wrote: > With the taskflow update, the only thing between upping our sqla > requirement to < 0.8.99 is pbr's requirements integration test > getting a work around for pip's behavior change (which will > currently not install netifaces because it's no

Re: [openstack-dev] a "common" client library

On Thu, Jan 16, 2014 at 12:07 PM, Alexei Kornienko < alexei.kornie...@gmail.com> wrote: > On 01/16/2014 06:15 PM, Jesse Noller wrote: > > > On Jan 16, 2014, at 9:54 AM, Alexei Kornienko > wrote: > > On 01/16/2014 05:25 PM, Jesse Noller wrote: > > > On Jan 16, 2014, at 9:07 AM, Joe Gordon wro

Re: [openstack-dev] a "common" client library

On Thu, Jan 16, 2014 at 12:03 AM, Flavio Percoco wrote: > On 15/01/14 21:35 +, Jesse Noller wrote: > >> >> On Jan 15, 2014, at 1:37 PM, Doug Hellmann >> wrote: >> >> Several people have mentioned to me that they are interested in, or >>> actively working on, code related to a "common" clien

Re: [openstack-dev] a "common" client library

On Wed, Jan 15, 2014 at 7:53 PM, Alexei Kornienko < alexei.kornie...@gmail.com> wrote: > >I did notice, however, that neutronclient is > conspicuously absent from the Work Items in the blueprint's Whiteboard. > It will surely be added later. We already working on several things in > parallel and w

Re: [openstack-dev] [Neturon] firewall_driver and ML2 and vif_security discussion

Hi Mathieu, Bob Thank you for your reply OK let's do (A) - (C) for now. (A) Remove firewall_driver from server side Remove Noop <-- I'll write patch for this (B) update ML2 with extend_port_dict <-- Bob will push new review for this (C) Fix vif_security patch using (1) and (2). <-- I'll up

Re: [openstack-dev] a "common" client library

On Thu, Jan 16, 2014 at 8:06 AM, Dean Troyer wrote: > On Thu, Jan 16, 2014 at 9:37 AM, Jesse Noller > wrote: > >> On Jan 16, 2014, at 9:26 AM, Justin Hammond >> wrote: >> >> I'm not sure if it was said, but which httplib using being used (urllib3 >> maybe?). Also I noticed many people were talk

Re: [openstack-dev] Proposal for dd disk i/o performance blueprint of cinder.

Yeah, I think the evil firmware issue is separate and should be solved separately. Ideally, there should be a mode you can set the bare metal server into where firmware updates are not allowed. This is useful to more folks then just baremetal cloud admins. Something to ask the hardware vendors

Re: [openstack-dev] [Neturon] firewall_driver and ML2 and vif_security discussion

On 01/16/2014 04:43 AM, Mathieu Rohon wrote: > Hi, > > your proposals make sense. Having the firewall driver configuring so > much things looks pretty stange. Agreed. I fully support proposed fix 1, adding enable_security_group config, at least for ml2. I'm not sure whether making this sort of ch

Re: [openstack-dev] a "common" client library

On 01/16/2014 06:15 PM, Jesse Noller wrote: On Jan 16, 2014, at 9:54 AM, Alexei Kornienko mailto:alexei.kornie...@gmail.com>> wrote: On 01/16/2014 05:25 PM, Jesse Noller wrote: On Jan 16, 2014, at 9:07 AM, Joe Gordon > wrote: On Thu, Jan 16, 2014 at 9:45

Re: [openstack-dev] Hat Tip to fungi

Russell Bryant wrote: > On 01/16/2014 08:44 AM, Anita Kuno wrote: >> I tip my hat to you, sir. > > +1 +1! > This is some very well deserved recognition for hard work and dedication > to OpenStack. :-) Maybe we should restore the awards. I think last time we did them was... the Bexar summit in S

Re: [openstack-dev] a "common" client library

On Thu, Jan 16, 2014 at 10:25 AM, Jesse Noller wrote: > > On Jan 16, 2014, at 9:07 AM, Joe Gordon wrote: > > > > > On Thu, Jan 16, 2014 at 9:45 AM, Jesse Noller > wrote: > >> >> On Jan 16, 2014, at 5:53 AM, Chmouel Boudjnah >> wrote: >> >> >> On Thu, Jan 16, 2014 at 12:38 PM, Chris Jones wr

Re: [openstack-dev] question of vcpu-memory-hotplug progress

On Jan 15, 2014, at 7:36 PM, Wangshen (Peter) wrote: > Hi, all > We are interesting in vcpu-memory-hotplug under this link: > https://blueprints.launchpad.net/nova/+spec/vcpu-memory-hotplug > And we have already finished vcpu hotplug and done the basic tests. > > But this blueprint seems not b

Re: [openstack-dev] a "common" client library

On Thu, Jan 16, 2014 at 10:23 AM, Jay Pipes wrote: > > Right, but requests supports chunked-transfer encoding properly, so > really there's no reason those clients could not move to a > requests-based codebase. > Absolutely...it was totally me chickening out at the time why they didn't get change

Re: [openstack-dev] a "common" client library

On Thu, Jan 16, 2014 at 5:23 PM, Jay Pipes wrote: > Right, but requests supports chunked-transfer encoding properly, so > really there's no reason those clients could not move to a > requests-based codebase. > We had that discussion for swiftclient and we are not against it but unfortunately the

Re: [openstack-dev] [gantt] Sync up patches

Le 16/01/2014 17:18, Vishvananda Ishaya a écrit : On Jan 16, 2014, at 6:46 AM, Joe Gordon > wrote: On Wed, Jan 15, 2014 at 1:29 PM, Dugger, Donald D mailto:donald.d.dug...@intel.com>> wrote: My thought was to try and get some parallel effort going, do t

Re: [openstack-dev] instance migration strangeness in devstack

OK, thank you for the sanity check. Dan On 01/16/2014 11:29 AM, Vishvananda Ishaya wrote: In that case, this sounds like a bug to me related to lvm volumes. You should check the nova-compute.log from both hosts and the nova-conductor.log. If it isn’t obvious what the problem is, you should op

[openstack-dev] [nova][vmware] VMwareAPI sub-team status update 2014-01-16

We're closing in on Icehouse-2 and only 4 of our blueprints were in good enough shape to stay in the queue. Numbers on the BP indicate the priority number (per project) I've arbitrarily assigned the BP based on subteam feedback. This does mean priority 1, 2, and 3 got bumped from i-2 to i-3 so... l

Re: [openstack-dev] [gantt] Sync up patches

On 01/16/2014 11:18 AM, Vishvananda Ishaya wrote: > > On Jan 16, 2014, at 6:46 AM, Joe Gordon > wrote: > >> >> >> >> On Wed, Jan 15, 2014 at 1:29 PM, Dugger, Donald D >> mailto:donald.d.dug...@intel.com>> >> wrote: >> >> My thought was to try and get some paral

Re: [openstack-dev] instance migration strangeness in devstack

In that case, this sounds like a bug to me related to lvm volumes. You should check the nova-compute.log from both hosts and the nova-conductor.log. If it isn’t obvious what the problem is, you should open a bug and attach as much info as possible. Vish On Jan 16, 2014, at 8:04 AM, Dan Genin

Re: [openstack-dev] instance migration strangeness in devstack

Raw backed instance migration also works so this appears to be an LVM issue. On 01/16/2014 11:04 AM, Dan Genin wrote: Thank you for replying, Vish. I did sync and verified that the file was written to the host disk by mounting the LVM volume on the host. When I tried live migration I got a Hor

Re: [openstack-dev] a "common" client library

On Thu, 2014-01-16 at 10:06 -0600, Dean Troyer wrote: > On Thu, Jan 16, 2014 at 9:37 AM, Jesse Noller > wrote: > On Jan 16, 2014, at 9:26 AM, Justin Hammond > wrote: > > I'm not sure if it was said, but which httplib using being > > used (urllib3 > > maybe?

Re: [openstack-dev] a "common" client library

On Thu, Jan 16, 2014 at 9:54 AM, Alexei Kornienko < alexei.kornie...@gmail.com> wrote: > > Knowing usual openstack workflow I'm afraid that #1,#2 with a waterfall > approach may take years to be complete. > And after they'll be approved it will become clear that this architecture > is already outda

Re: [openstack-dev] a "common" client library

My prioritization of noauth is rooted in the fact that we're finding that the current pattern of hitting auth to validate a token is not scaling well. Out current solution to this scale issue is: - use noauth when possible between the services - use normal auth for public services - provide a meth

Re: [openstack-dev] a "common" client library

On Jan 16, 2014, at 9:54 AM, Alexei Kornienko mailto:alexei.kornie...@gmail.com>> wrote: On 01/16/2014 05:25 PM, Jesse Noller wrote: On Jan 16, 2014, at 9:07 AM, Joe Gordon mailto:joe.gord...@gmail.com>> wrote: On Thu, Jan 16, 2014 at 9:45 AM, Jesse Noller mailto:jesse.nol...@rackspace.co

Re: [openstack-dev] [gantt] Sync up patches

On Jan 16, 2014, at 6:46 AM, Joe Gordon wrote: > > > > On Wed, Jan 15, 2014 at 1:29 PM, Dugger, Donald D > wrote: > My thought was to try and get some parallel effort going, do the resync as a > continuing task as suffer a little ongoing pain versus a large amount of pain > at the end. G

Re: [openstack-dev] a "common" client library

On Thu, Jan 16, 2014 at 8:45 AM, Jesse Noller wrote: > After speaking with people working on OSC and looking at the code base in > depth; I don’t think this addresses what Chris is implying: OSC wraps the > individual CLIs built by each project today, instead of the inverse: a > common backend tha

Re: [openstack-dev] [neutron] [third-party-testing] Sharing information

Apologies for an almost duplicate post, I corrected the mistake in the example. Ooops. > -Original Message- > From: Sullivan, Jon Paul > Sent: 16 January 2014 15:38 > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] [neutron] [third-party-te

  1   2   >