Re: [openstack-dev] Evil Firmware

2014-01-17 Thread Robert Collins
The physical function is the one with the real PCI config space, so as long as the host controls it then there should be minimal risk from the guests since they have limited access via the virtual functions--typically mostly just message-passing to the physical function. As long as its a

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

2014-01-17 Thread Robert Collins
On 16 January 2014 03:31, Alan Kavanagh alan.kavan...@ericsson.com wrote: Hi fellow OpenStackers Does anyone have any recommendations on open source tools for disk erasure/data destruction software. I have so far looked at DBAN and disk scrubber and was wondering if ironic team have some

Re: [openstack-dev] [OpenStack-Dev] Third party testing

2014-01-17 Thread Robert Collins
On 16 January 2014 14:51, John Griffith john.griff...@solidfire.com wrote: On Wed, Jan 15, 2014 at 6:41 PM, Michael Still mi...@stillhq.com wrote: John -- I agree with you entirely here. My concern is more that I think the CI tests need to run more frequently than weekly. Completely agree,

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

2014-01-17 Thread Flavio Percoco
On 16/01/14 17:32 -0500, Doug Hellmann wrote: On Thu, Jan 16, 2014 at 3:19 PM, Ben Nemec openst...@nemebean.com 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

Re: [openstack-dev] [TripleO][Tuskar] Editing Nodes

2014-01-17 Thread mar...@redhat.com
On 16/01/14 00:28, Clint Byrum wrote: Excerpts from James Slagle's message of 2014-01-15 05:07:08 -0800: I'll start by laying out how I see editing or updating nodes working in TripleO without Tuskar: To do my initial deployment: 1. I build a set of images for my deployment for different

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

2014-01-17 Thread Roman Podoliaka
Hi all, Huge +1 for periodic syncs for two reasons: 1) it makes syncs smaller and thus easier 2) code in oslo-incubator often contains important bug fixes (e.g. incorrect usage of eventlet TLS we found in Nova a few months ago) Thanks, Roman On Fri, Jan 17, 2014 at 10:15 AM, Flavio Percoco

[openstack-dev] [qa] RE: [Tempest - Stress Test] : implement a full SSH connection on ssh_floating.py and improve it

2014-01-17 Thread Koderer, Marc
Hello Juilen, I forwarded your mail to the correct mailing list. Please do not use the qa list any longer. I am happy that you are interested in stress tests. All the tests in tempest/stress/actions are more or less deprecated. So what you should use instead is the stress decorator (e.g.

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

2014-01-17 Thread Julien Danjou
On Thu, Jan 16 2014, John Griffith wrote: As it turns out I've received a bit of push back on this, so it seems maybe I'm being unreasonable, or that I'm mistaken in my understanding of the process here. To me it seems like a complete and total waste to have an oslo-incubator and common libs

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

2014-01-17 Thread Gareth
Hi guys I have another question about erasing all data from disk. When using dd from /dev/zero could set bytes to zero from LBA0 on a disk. But dd a whole disk will cost very very long time and the custom way is to dd key data on the disk, for example the first 512B as MBR. But this is not

[openstack-dev] [Fuel-dev] [OSTF][Ceilometer] ceilometer meters and samples delete

2014-01-17 Thread Dmitry Iakunchikov
Hi, Ceilometer's tests creates some data which could not be deleted. For example: after creation new instance, ceilometer creates new meters for this instance and there is no possibility to delete them. Even after instance deletion they would not be deleted. Should we take attention to this?

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

2014-01-17 Thread Alexander Ignatov
++ for generic PUT for both ‘cancel’ and ‘refresh-status’, Andrew. Thanks! Regards, Alexander Ignatov On 17 Jan 2014, at 06:19, Andrey Lazarev alaza...@mirantis.com wrote: My 5 cents: -- REMOVE - @rest.put('/node-group-templates/node_group_template_id') - Not Implemented REMOVE -

Re: [openstack-dev] [qa] RE: [Tempest - Stress Test] : implement a full SSH connection on ssh_floating.py and improve it

2014-01-17 Thread LELOUP Julien
Hello Marc, Thanks for your answer. At the moment I'm willing to spend some time on this kind of scenario so I will see how to use the stress decorator inside a scenario test. Does this means that all stress tests available in tempest/stress should be ported as scenario tests with this

Re: [openstack-dev] [Fuel-dev] [OSTF][Ceilometer] ceilometer meters and samples delete

2014-01-17 Thread Julien Danjou
On Fri, Jan 17 2014, Dmitry Iakunchikov wrote: Ceilometer's tests creates some data which could not be deleted. For example: after creation new instance, ceilometer creates new meters for this instance and there is no possibility to delete them. Even after instance deletion they would not be

[openstack-dev] [qa] negative test framework: ready for review

2014-01-17 Thread Koderer, Marc
Hi all, first part of the negative test framework is ready for review: https://review.openstack.org/#/c/64733/ Please have a look. Regards Marc and David DEUTSCHE TELEKOM AG Digital Business Unit, Cloud Services (PI) Marc Koderer Cloud Technology Software Developer T-Online-Allee 1, 64211

Re: [openstack-dev] [Fuel-dev] [OSTF][Ceilometer] ceilometer meters and samples delete

2014-01-17 Thread Nadya Privalova
Hi guys, I would ask in another way. Ceilometer has a mechanism to add a sample through POST. So it looks not consistent not to allow user to delete a sample. IMHO, insertion and deletion through REST looks a little bit hacky: user always has an ability to fake data collected from OpenStack

Re: [openstack-dev] Evil Firmware

2014-01-17 Thread Ian Wells
On 17 January 2014 01:16, Chris Friesen chris.frie...@windriver.com wrote: 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

Re: [openstack-dev] Evil Firmware

2014-01-17 Thread Ian Wells
On 17 January 2014 09:12, Robert Collins robe...@robertcollins.net wrote: The physical function is the one with the real PCI config space, so as long as the host controls it then there should be minimal risk from the guests since they have limited access via the virtual

Re: [openstack-dev] [Fuel-dev] [OSTF][Ceilometer] ceilometer meters and samples delete

2014-01-17 Thread Julien Danjou
On Fri, Jan 17 2014, Nadya Privalova wrote: I would ask in another way. Ceilometer has a mechanism to add a sample through POST. So it looks not consistent not to allow user to delete a sample. IMHO, insertion and deletion through REST looks a little bit hacky: user always has an ability to

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

2014-01-17 Thread Jay Pipes
On Thu, 2014-01-16 at 22:56 -0500, Matthew Treinish wrote: 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

Re: [openstack-dev] [Fuel-dev] [OSTF][Ceilometer] ceilometer meters and samples delete

2014-01-17 Thread Ildikó Váncsa
Hi, In my opinion it would be better to let the user to define a ttl value for his/her own samples. I do not see the use case, where it is needed to delete samples, also if the user is able to randomly delete some data, then the statistics functions will not generate a valid output for that

Re: [openstack-dev] [Fuel-dev] [OSTF][Ceilometer] ceilometer meters and samples delete

2014-01-17 Thread Dmitry Iakunchikov
For now in Fuel we keep samples forever In case if we will use time_to_live, how long we should keep this data? 2014/1/17 Julien Danjou jul...@danjou.info On Fri, Jan 17 2014, Nadya Privalova wrote: I would ask in another way. Ceilometer has a mechanism to add a sample through POST. So

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

2014-01-17 Thread James Slagle
On Thu, Jan 16, 2014 at 7:29 PM, Clint Byrum cl...@fewbar.com wrote: 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. I think it would be nice if we could point people at a

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

2014-01-17 Thread David Kranz
On 01/16/2014 10:56 PM, Matthew Treinish wrote: 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

[openstack-dev] [Neutron] Relationship between Neutron LBaaS and Libra

2014-01-17 Thread Thomas Herve
Hi all, I've been looking at Neutron default LBaaS provider using haproxy, and while it's working nicely, it seems to have several shortcomings in terms of scalability and high availability. The Libra project seems to offer a more robust alternative, at least for scaling. The haproxy

Re: [openstack-dev] [qa] RE: [Tempest - Stress Test] : implement a full SSH connection on ssh_floating.py and improve it

2014-01-17 Thread Koderer, Marc
Hi Julien, most of the cases in tempest/stress are already covered by exiting tests in /api or /scenario. The only thing that is missing is the decorator on them. BTW here is the Etherpad from the summit talk that we had: https://etherpad.openstack.org/p/icehouse-summit-qa-stress-tests It

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

2014-01-17 Thread Jay Pipes
On Thu, 2014-01-16 at 20:59 -0800, Clint Byrum wrote: 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

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

2014-01-17 Thread Clark, Robert Graham
On 17/01/2014 08:19, Robert Collins wrote: On 16 January 2014 03:31, Alan Kavanagh alan.kavan...@ericsson.com wrote: Hi fellow OpenStackers Does anyone have any recommendations on open source tools for disk erasure/data destruction software. I have so far looked at DBAN and disk scrubber

Re: [openstack-dev] [Openstack] [Neutron] auto configration of local_ip

2014-01-17 Thread balaj...@freescale.com
Hi, Once we configure Interface of compute node for local_ip, then it can be used for both IPv4 and IPv6 as well based on the deployment network. Regards, Balaji.P From: Nir Yechiel [mailto:nyech...@redhat.com] Sent: Thursday, January 16, 2014 9:28 PM To: OpenStack Development Mailing List

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

2014-01-17 Thread Jay Pipes
On Fri, 2014-01-17 at 06:59 +, Gao, Fengqian wrote: 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

Re: [openstack-dev] [Tempest - Stress Test] : implement a full SSH connection on ssh_floating.py and improve it

2014-01-17 Thread LELOUP Julien
Hi Marc, The Etherpad you provided was helpful to know the current state of the stress tests. I admit that I have some difficulties to understand how I can run a single test built with the @stresstest decorator (even not a beginner in Python, I still have things to learn on this technology

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

2014-01-17 Thread Murray, Paul (HP Cloud Services)
To be clear - the changes that Yunhong describes below are not part of the extensible-resource-tracking blueprint. Extensible-resource-tracking has the more modest aim to provide plugins to track additional resource data. Paul. -Original Message- From: Jiang, Yunhong

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

2014-01-17 Thread Jaromir Coufal
Sure Steve, that would be awesome! The only blocker for now is that there are still happening some changes based on feedback of what is doable / what is not. So right when we get more confident on stable(-ish) version (or at least I'll try to sort out widgets which should stay how they are),

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

2014-01-17 Thread Robert Li (baoli)
Yunhong, Thank you for bringing that up on the live migration support. In addition to the two solutions you mentioned, Irena has a different solution. Let me put all the them here again: 1. network xml/group based solution. In this solution, each host that supports a provider

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

2014-01-17 Thread Matthew Treinish
On Fri, Jan 17, 2014 at 08:32:19AM -0500, David Kranz wrote: On 01/16/2014 10:56 PM, Matthew Treinish wrote: 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

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

2014-01-17 Thread David Kranz
On 01/17/2014 10:34 AM, Matthew Treinish wrote: On Fri, Jan 17, 2014 at 08:32:19AM -0500, David Kranz wrote: On 01/16/2014 10:56 PM, Matthew Treinish wrote: Hi everyone, With some recent changes made to Tempest compatibility with nosetests is going away. We've started using newer features

Re: [openstack-dev] [TripleO][Tuskar] Editing Nodes

2014-01-17 Thread Jay Dobies
On 01/17/2014 03:28 AM, mar...@redhat.com wrote: On 16/01/14 00:28, Clint Byrum wrote: Excerpts from James Slagle's message of 2014-01-15 05:07:08 -0800: I'll start by laying out how I see editing or updating nodes working in TripleO without Tuskar: To do my initial deployment: 1. I build

Re: [openstack-dev] [qa] RE: [Tempest - Stress Test] : implement a full SSH connection on ssh_floating.py and improve it

2014-01-17 Thread David Kranz
On 01/17/2014 09:06 AM, Koderer, Marc wrote: Hi Julien, most of the cases in tempest/stress are already covered by exiting tests in /api or /scenario. The only thing that is missing is the decorator on them. BTW here is the Etherpad from the summit talk that we had:

Re: [openstack-dev] a common client library

2014-01-17 Thread John Dennis
Keeping them separate is awesome for *us* but really, really, really sucks for users trying to use the system. I agree. Keeping them separate trades user usability for developer usability, I think user usability is a better thing to strive for. I don't understand how multiple independent

Re: [openstack-dev] [Fuel-dev] [OSTF][Ceilometer] ceilometer meters and samples delete

2014-01-17 Thread Jay Pipes
On Fri, 2014-01-17 at 12:43 +0200, Dmitry Iakunchikov wrote: Ceilometer's tests creates some data which could not be deleted. For example: after creation new instance, ceilometer creates new meters for this instance and there is no possibility to delete them. Even after instance deletion

Re: [openstack-dev] [Neutron] Relationship between Neutron LBaaS and Libra

2014-01-17 Thread Jay Pipes
On Fri, 2014-01-17 at 14:34 +0100, Thomas Herve wrote: Hi all, I've been looking at Neutron default LBaaS provider using haproxy, and while it's working nicely, it seems to have several shortcomings in terms of scalability and high availability. The Libra project seems to offer a more

[openstack-dev] [climate] Meeting minutes

2014-01-17 Thread Dina Belova
Thanks everyone for attending our weekly meeting :) Meeting minutes are: Minutes: http://eavesdrop.openstack.org/meetings/climate/2014/climate.2014-01-17-15.00.html Minutes (text): http://eavesdrop.openstack.org/meetings/climate/2014/climate.2014-01-17-15.00.txt Log:

Re: [openstack-dev] a common client library

2014-01-17 Thread Matthew Farina
It seems we have two target audiences here. Developers who work on OpenStack and developers who write apps to use it. In the long run I think we need to optimize for both of these groups. If we want developers to write applications to use OpenStack in python we likely need a common python SDK.

Re: [openstack-dev] [Neutron] Relationship between Neutron LBaaS and Libra

2014-01-17 Thread Andrew Hutchings
On 17 Jan 2014, at 16:10, Jay Pipes jaypi...@gmail.com wrote: On Fri, 2014-01-17 at 14:34 +0100, Thomas Herve wrote: Hi all, I've been looking at Neutron default LBaaS provider using haproxy, and while it's working nicely, it seems to have several shortcomings in terms of scalability

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

2014-01-17 Thread John Griffith
On Fri, Jan 17, 2014 at 1:15 AM, Flavio Percoco fla...@redhat.com wrote: On 16/01/14 17:32 -0500, Doug Hellmann wrote: On Thu, Jan 16, 2014 at 3:19 PM, Ben Nemec openst...@nemebean.com wrote: On 2014-01-16 13:48, John Griffith wrote: Hey Everyone, A review came up today

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

2014-01-17 Thread Robert Collins
Hey, so I think my criteria would be: - low chance of user confusion - little or no overhead for dev until we're more broadly ready for long term support So - if you want to make an incubator release branch thats fine with me but: - please make sure the docs in the branch and trunk explain the

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

2014-01-17 Thread Vishvananda Ishaya
On Jan 16, 2014, at 9:41 PM, Jiang, Yunhong yunhong.ji...@intel.com wrote: 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

Re: [openstack-dev] [Fuel-dev] [OSTF][Ceilometer] ceilometer meters and samples delete

2014-01-17 Thread David Easter
I¹d like to make sure I understand the question. Is this the scenario? * A user installs Mirantis OpenStack * The user runs the Mirantis OpenStack Health Check (OSTF) against Ceilometer * The Health Check creates a VM against which ceilometer can collect data * Ceilometer collects the data from

Re: [openstack-dev] [OpenStack-Dev] Third party testing

2014-01-17 Thread John Griffith
On Fri, Jan 17, 2014 at 1:15 AM, Robert Collins robe...@robertcollins.net wrote: On 16 January 2014 14:51, John Griffith john.griff...@solidfire.com wrote: On Wed, Jan 15, 2014 at 6:41 PM, Michael Still mi...@stillhq.com wrote: John -- I agree with you entirely here. My concern is more that I

[openstack-dev] [Solum][Keystone] Best practices for storing keystone trusts information

2014-01-17 Thread Georgy Okrokvertskhov
Hi, In Solum project we want to use Keystone trusts to work with other OpenStack services on behalf of user. Trusts are long term entities and a service should keep them for a long time. I want to understand what are best practices for working with trusts and storing them in a service? What are

Re: [openstack-dev] a common client library

2014-01-17 Thread Jonathan LaCour
On Thu, Jan 16, 2014 at 1:23 PM, Donald Stufft don...@stufft.io wrote: On Jan 16, 2014, at 4:06 PM, Jesse Noller jesse.nol...@rackspace.com wrote: On Jan 16, 2014, at 2:22 PM, Renat Akhmerov rakhme...@mirantis.com wrote: Since it’s pretty easy to get lost among all the opinions I’d like

Re: [openstack-dev] a common client library

2014-01-17 Thread Jonathan LaCour
On Thu, Jan 16, 2014 at 5:42 PM, Jesse Noller jesse.nol...@rackspace.comwrote: On Jan 16, 2014, at 4:59 PM, Renat Akhmerov rakhme...@mirantis.com wrote: On 16 Jan 2014, at 13:06, Jesse Noller jesse.nol...@rackspace.com wrote: Since it’s pretty easy to get lost among all the opinions

Re: [openstack-dev] [Glance] [Metadatarepository] Metadata repository initiative status

2014-01-17 Thread Tripp, Travis S
Hello All, I just took a look at this blueprint and see that it doesn't have any priority. Was there a discussion on priority? Any idea what, if any of this will make it into Icehouse? Also, are there going to be any further design sessions on it? Thanks, Travis From: Georgy

Re: [openstack-dev] [Solum][Keystone] Best practices for storing keystone trusts information

2014-01-17 Thread Lance D Bragstad
Hi Georgy, The following might help with some of the trust questions you have, if you haven't looked at it already: https://github.com/openstack/identity-api/blob/master/openstack-identity-api/v3/src/markdown/identity-api-v3-os-trust-ext.md As far as storage implementation, trust uses sql and

[openstack-dev] [all] stable/havana currently blocked - do not approve or recheck stable/* patches

2014-01-17 Thread Sean Dague
Because of a pip issue with netaddr on stable/grizzly devstack, all the stable/havana changes for jobs that include grenade are currently blocked. This is because of stevedore's version enforcement of netaddr versions inside the cinder scheduler. John, Chmouel, Dean, and I have got eyes on it,

[openstack-dev] [OSSG][OSSN] Keystone can allow user impersonation when using REMOTE_USER for external authentication

2014-01-17 Thread Nathan Kinder
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Keystone can allow user impersonation when using REMOTE_USER for external authentication - --- ### Summary ### When external authentication is used with Keystone using the ExternalDefault plug-in, external usernames containing @ characters are

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

2014-01-17 Thread Jiang, Yunhong
Paul, thanks for clarification. --jyh -Original Message- From: Murray, Paul (HP Cloud Services) [mailto:pmur...@hp.com] Sent: Friday, January 17, 2014 7:02 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [nova] how is resource

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

2014-01-17 Thread Jiang, Yunhong
Robert, thanks for your long reply. Personally I'd prefer option 2/3 as it keep Nova the only entity for PCI management. Glad you are ok with Ian's proposal and we have solution to resolve the libvirt network scenario in that framework. Thanks --jyh -Original Message- From: Robert

Re: [openstack-dev] [horizon] Blueprint decrypt-and-display-vm-generated-password

2014-01-17 Thread Alessandro Pilotti
+1 Nova's get-password is corrently the only safe way from a security perspective to handle guest passwords. This feature needs to be mirrored in Horizon, otherwise most users will continue to resort to unsafe solutions like the clear text admin_pass due to lack of practical alternatives.

[openstack-dev] FW: OpenStack Cloud Virtualization Implementation Strategies

2014-01-17 Thread Alan Kavanagh
FYI From: Light Reading [mailto:sen...@responses.lightreading.com] Sent: January-17-14 2:20 PM To: Alan Kavanagh Subject: OpenStack Cloud Virtualization Implementation Strategies If you have trouble viewing this email, read the online

Re: [openstack-dev] [Solum][Keystone] Best practices for storing keystone trusts information

2014-01-17 Thread Adrian Otto
Georgy, For Solum, let's refrain from storing any secrets, whether they be passwords or trusts, or tokens. I definitely don't want to be in the business of managing how to secure them in an SQL database. I don't even want admin password values to appear in the configuration files. I'd prefer

Re: [openstack-dev] [Glance] [Metadatarepository] Metadata repository initiative status

2014-01-17 Thread Georgy Okrokvertskhov
Hi Travis, I think it will be discussed on the mini-summit which will be on Jan 27th-28th in Washington DC. Here is an etherpad with the summit agenda: https://etherpad.openstack.org/p/glance-mini-summit-agenda I hope that after F2F discussion all BPs will have priority and assignment. Thanks

Re: [openstack-dev] [wsme] Undefined attributes in WSME

2014-01-17 Thread Kurt Griffiths
FWIW, I believe Nova is looking at using JSON Schema as well, since they need to handle API extensions. This came up during a design session at the HK summit. On 1/12/14, 5:33 PM, Jamie Lennox jamielen...@redhat.com wrote: I would prefer not to have keystone using yet another framework from the

Re: [openstack-dev] [Neutron] Relationship between Neutron LBaaS and Libra

2014-01-17 Thread Jay Pipes
On Fri, 2014-01-17 at 17:03 +, Andrew Hutchings wrote: On 17 Jan 2014, at 16:10, Jay Pipes jaypi...@gmail.com wrote: On Fri, 2014-01-17 at 14:34 +0100, Thomas Herve wrote: Hi all, I've been looking at Neutron default LBaaS provider using haproxy, and while it's working nicely,

Re: [openstack-dev] [Solum][Keystone] Best practices for storing keystone trusts information

2014-01-17 Thread Georgy Okrokvertskhov
Hi Adrian, Barbican looks good for this purpose. I will do a prototype with it. Thanks Georgy On Fri, Jan 17, 2014 at 11:43 AM, Adrian Otto adrian.o...@rackspace.comwrote: Georgy, For Solum, let's refrain from storing any secrets, whether they be passwords or trusts, or tokens. I

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

2014-01-17 Thread Clint Byrum
tl;dr: You're right, it would be useful. Points on what is blocking it below: Excerpts from James Slagle's message of 2014-01-17 05:18:01 -0800: On Thu, Jan 16, 2014 at 7:29 PM, Clint Byrum cl...@fewbar.com wrote: Note that tripleo-incubator is special and should not be released. It is

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

2014-01-17 Thread Alan Kavanagh
Hi Rob Then apart from the disk eraser and reinstalling the blade from scratch everytime it is returned from lease, and ensure network isolation, what are the other many concerns you are worried about for sharing the bare metal then? Would really like to know what the other major issues are

Re: [openstack-dev] [Neutron] Relationship between Neutron LBaaS and Libra

2014-01-17 Thread Alex Freedland
Andrew, Jay and all, Thank you for bringing this topic up. Incidentally, just a month ago at OpenStack Israel I spoke to Monty and other HP folks about getting the Libra initiatives integrated into LBaaS. I am happy that this discussion is now happening on the mailing list. I remember the

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

2014-01-17 Thread Jay Pipes
On Thu, 2014-01-16 at 15:37 +, Sullivan, Jon Paul wrote: From: Jay Pipes [mailto:jaypi...@gmail.com] On Thu, 2014-01-16 at 10:39 +, Sullivan, Jon Paul wrote: From: Kyle Mestery [mailto:mest...@siliconloons.com] FYI, here [1] are the meeting logs from today’s meeting.

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

2014-01-17 Thread yunhong jiang
On Fri, 2014-01-17 at 09:39 -0800, Vishvananda Ishaya wrote: On Jan 16, 2014, at 9:41 PM, Jiang, Yunhong yunhong.ji...@intel.com wrote: 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

Re: [openstack-dev] [OpenStack][Nova][compute] Why prune all compute node stats when sync up compute nodes

2014-01-17 Thread yunhong jiang
On Thu, 2014-01-16 at 00:22 +0800, Jay Lau wrote: Greeting, In compute/manager.py, there is a periodic task named as update_available_resource(), it will update resource for each compute periodically. @periodic_task.periodic_task def update_available_resource(self, context):

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

2014-01-17 Thread Devananda van der Veen
On Fri, Jan 17, 2014 at 12:35 PM, Alan Kavanagh alan.kavan...@ericsson.comwrote: Hi Rob Then apart from the disk eraser and reinstalling the blade from scratch everytime it is returned from lease, and ensure network isolation, what are the other many concerns you are worried about for

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

2014-01-17 Thread Robert Li (baoli)
Yunhong, I'm hoping that these comments can be directly addressed: a practical deployment scenario that requires arbitrary attributes. detailed design on the following (that also take into account the introduction of predefined attributes): * PCI stats report since the

Re: [openstack-dev] [ironic] [QA] some notes on ironic functional testing

2014-01-17 Thread Chris K
Hi Alexander, Reading your post got me to thinking. What if we modified the ssh driver so it used the libvirt api. Just off the top of my head some thing along the lines of changing the ssh driver to issue python-libvirt commands would work. As an example: shh user@host python -c \import

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

2014-01-17 Thread Mohammad Banikazemi
Jay Pipes jaypi...@gmail.com wrote on 01/17/2014 04:32:55 PM: From: Jay Pipes jaypi...@gmail.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org, Date: 01/17/2014 04:37 PM Subject: Re: [openstack-dev] [neutron] [third-party-testing]

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

2014-01-17 Thread Paul Ward
Henry, thank you very much for your reply. To try to tie together our discussion here with what's in the launchpad bug report I opened (https://bugs.launchpad.net/neutron/+bug/1269926), here is the method used to create the network. I'm creating the network via a UI, which does a rest api POST

Re: [openstack-dev] [Neutron] Relationship between Neutron LBaaS and Libra

2014-01-17 Thread Georgy Okrokvertskhov
Hi, Here are e-mail threads which keeps the history of LBaaS decisions: LBaaS IIRC meeting minutes: http://lists.openstack.org/pipermail/openstack-dev/2012-August/000390.html LBaaS e-mail discussion: http://lists.openstack.org/pipermail/openstack-dev/2012-August/000785.html As you see there was

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

2014-01-17 Thread yunhong jiang
On Fri, 2014-01-17 at 22:30 +, Robert Li (baoli) wrote: Yunhong, I'm hoping that these comments can be directly addressed: a practical deployment scenario that requires arbitrary attributes. I'm just strongly against to support only one attributes (your PCI group) for scheduling

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

2014-01-17 Thread Chris Friesen
On 01/17/2014 04:20 PM, Devananda van der Veen wrote: tl;dr, We should not be recycling bare metal nodes between untrusted tenants at this time. There's a broader discussion about firmware security going on, which, I think, will take a while for the hardware vendors to really address. What

Re: [openstack-dev] a common client library

2014-01-17 Thread Renat Akhmerov
On 17 Jan 2014, at 10:04, Jonathan LaCour jonathan-li...@cleverdevil.org wrote: pip install openstack That would be awesome :) Renat Akhmerov @ Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org

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

2014-01-17 Thread Robert Collins
On 18 January 2014 09:09, Clint Byrum cl...@fewbar.com wrote: tl;dr: You're right, it would be useful. Points on what is blocking it below: I'll address the bigger points here below, but for the record, I think setup-endpoints and register-endpoint are stable enough now that they should just

Re: [openstack-dev] [OpenStack-Dev] Third party testing

2014-01-17 Thread Robert Collins
On 18 January 2014 06:42, John Griffith john.griff...@solidfire.com wrote: On Fri, Jan 17, 2014 at 1:15 AM, Robert Collins robe...@robertcollins.net wrote: Maybe this is going a bit sideways, but my point was that making a first step of getting periodic runs on vendor gear and publicly

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

2014-01-17 Thread Devananda van der Veen
On Fri, Jan 17, 2014 at 3:21 PM, Chris Friesen chris.frie...@windriver.comwrote: On 01/17/2014 04:20 PM, Devananda van der Veen wrote: tl;dr, We should not be recycling bare metal nodes between untrusted tenants at this time. There's a broader discussion about firmware security going on,

Re: [openstack-dev] [OpenStack-Dev] Third party testing

2014-01-17 Thread John Griffith
On Fri, Jan 17, 2014 at 6:24 PM, Robert Collins robe...@robertcollins.net wrote: On 18 January 2014 06:42, John Griffith john.griff...@solidfire.com wrote: On Fri, Jan 17, 2014 at 1:15 AM, Robert Collins robe...@robertcollins.net wrote: Maybe this is going a bit sideways, but my point was

[openstack-dev] [Diesel] Proposal for new project

2014-01-17 Thread Raymond, Rob
I would like to gauge interest in a new project named Diesel. https://wiki.openstack.org/wiki/Diesel If you are already familiar with Savanna, the best way to describe it is: Savanna is to map reduce applications as Diesel is to web applications. The mission of Diesel is to allow OpenStack

Re: [openstack-dev] [Neutron] Availability of external testing logs

2014-01-17 Thread Collins, Sean
Yeah - it appears that even if you clear a -1 the countdown clock still keeps ticking, one of my reviews[0] just expired this morning. I'll bring it up at the IPv6 meeting to restore any patches in our topic that are currently abandoned so that you can clear them. [0]

Re: [openstack-dev] [Diesel] Proposal for new project

2014-01-17 Thread Rajesh Ramchandani
Hi Rob - there seems be overlap with project Solum. Can you please outline high level differences between Diesel and Solum? Raj Sent from my iPad On Jan 18, 2014, at 9:06 AM, Raymond, Rob rob.raym...@hp.com wrote: I would like to gauge interest in a new project named Diesel.

Re: [openstack-dev] a common client library

2014-01-17 Thread John Utz
Outlook Web MUA, forgive the top post. :-( While a single import line that brings all the good stuff in at one shot is very convenient for the creation of an application, it would muddy the security picture *substantially* for the exact type of developer\customer that you would be targeting

Re: [openstack-dev] [Diesel] Proposal for new project

2014-01-17 Thread Adrian Otto
Please discuss this with the Solum team before proceeding. This sounds like a complete overlap with the app deployment portion of Solum. It would make much more sense to combine efforts than to run this as two projects. -- Adrian Original message From: Rajesh Ramchandani

Re: [openstack-dev] [Diesel] Proposal for new project

2014-01-17 Thread Raymond, Rob
Hi Raj As I see it, Solum is a set of utilities aimed at developers to use OpenStack clouds but will not be part of OpenStack proper. While Diesel is meant to be a service that is provided by an OpenStack cloud (and at some point becoming part of OpenStack itself). It defines a contract and

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

2014-01-17 Thread Robert Collins
On 18 January 2014 12:21, Chris Friesen chris.frie...@windriver.com wrote: On 01/17/2014 04:20 PM, Devananda van der Veen wrote: tl;dr, We should not be recycling bare metal nodes between untrusted tenants at this time. There's a broader discussion about firmware security going on, which, I

Re: [openstack-dev] a common client library

2014-01-17 Thread Robert Collins
On 17 January 2014 06:39, Mark Washenberger mark.washenber...@markwash.net wrote: There's a few more items here that are needed for glance to be able to work with requests (which we really really want). 1) Support for 100-expect-continue is probably going to be required in glance as well as

Re: [openstack-dev] a common client library

2014-01-17 Thread Jamie Lennox
I can't see any reason that all of these situations can't be met. We can finally take the openstack pypi namespace, move keystoneclient - openstack.keystone and similar for the other projects. Have them all based upon openstack.base and probably an openstack.transport for transport. For the

Re: [openstack-dev] a common client library

2014-01-17 Thread Robert Collins
On 17 January 2014 06:57, Mark Washenberger mark.washenber...@markwash.net wrote: Just throwing this out there because it seems relevant to client design. As we've been looking at porting clients to using v2 of the Images API, its seems more and more to me that including the *server* version

Re: [openstack-dev] a common client library

2014-01-17 Thread Robert Collins
On 17 January 2014 08:03, Alexei Kornienko alexei.kornie...@gmail.com wrote: Hello Joe, 2)Another option would be to follow waterfall process and create a solid library interface before including it to all client projects. However such approach this period can take unknown amount of time and

Re: [openstack-dev] a common client library

2014-01-17 Thread Robert Collins
On 17 January 2014 09:22, Renat Akhmerov 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: In case of

Re: [openstack-dev] [OpenStack-Dev] Third party testing

2014-01-17 Thread Robert Collins
On 18 January 2014 16:31, John Griffith john.griff...@solidfire.com wrote: On Fri, Jan 17, 2014 at 6:24 PM, Robert Collins robe...@robertcollins.net wrote: Certainly - I totally agree that anything nothing. I was asking about your statement of not having enough infra to get a handle on what