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

On 18 January 2014 16:31, John Griffith wrote: > On Fri, Jan 17, 2014 at 6:24 PM, Robert Collins > 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 would block things. As you know, tripleo i

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

On 17 January 2014 09:22, 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 single > library. Two things here: > > In case of combining them, what ex

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

On 17 January 2014 08:03, Alexei Kornienko 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 can be easily > failed

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

On 17 January 2014 06:57, Mark Washenberger 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 in the main > import path i

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

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 a

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

On 17 January 2014 06:39, Mark Washenberger 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 swift Is this currently s

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

On 18 January 2014 12:21, Chris Friesen 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 think, will take a wh

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

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 divis

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

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 Date

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

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 wit

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

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" wrote: > > I would like to gauge interest in a new project named Diesel. > > https://wiki.openstack.

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

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] https://review.openstack.or

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

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 cloud

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

On Fri, Jan 17, 2014 at 6:24 PM, Robert Collins wrote: > On 18 January 2014 06:42, John Griffith wrote: >> On Fri, Jan 17, 2014 at 1:15 AM, Robert Collins >> 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 p

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

On Fri, Jan 17, 2014 at 3:21 PM, Chris Friesen 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 think, will ta

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

On 18 January 2014 06:42, John Griffith wrote: > On Fri, Jan 17, 2014 at 1:15 AM, Robert Collins > 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 > submitting those results would be a good starting poi

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

On 18 January 2014 09:09, Clint Byrum 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 be included

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

On 17 Jan 2014, at 10:04, Jonathan LaCour wrote: > "pip install openstack" That would be awesome :) Renat Akhmerov @ Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo

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

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 can

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

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 scheduli

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

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] [neutron] ML2 vlan type driver does not honor network_vlan_ranges

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 t

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

Jay Pipes wrote on 01/17/2014 04:32:55 PM: > From: Jay Pipes > To: "OpenStack Development Mailing List (not for usage questions)" > , > Date: 01/17/2014 04:37 PM > Subject: Re: [openstack-dev] [neutron] [third-party-testing] Sharing > information > > On Thu, 2014-01-16 at 15:37 +, Sullivan

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

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 l

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

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 schedule

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

On Fri, Jan 17, 2014 at 12:35 PM, Alan Kavanagh wrote: > 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 > the

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

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] [Nova] why don't we deal with "claims" when live migrating an instance?

On Fri, 2014-01-17 at 09:39 -0800, Vishvananda Ishaya wrote: > > On Jan 16, 2014, at 9:41 PM, Jiang, Yunhong > 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 resiz

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

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

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

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 histor

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

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" t

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

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 wrote: > > Note that tripleo-incubator is special and should not be released. It > > is intentionally kep

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

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 wrote: > 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

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

On Fri, 2014-01-17 at 17:03 +, Andrew Hutchings wrote: > On 17 Jan 2014, at 16:10, Jay Pipes 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 s

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

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" wrote: >I would prefer not to have keystone using yet another framework from the >rest of openstack

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

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 Ge

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

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

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

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 version

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

Hi Lance, Thank you for the documentation link. It really solves the problem with trust expiration. I really like an idea to restrict trust to specific roles. This is great. As you mentioned, you use sql to store trusts information. Do you use any encryption for that? I am thinking from security

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

+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. The

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

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] [nova] how is resource tracking supposed to work for live migration and evacuation?

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 tra

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

-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 tru

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

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, wai

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

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 k

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

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 Okrokvertskhov

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

On Thu, Jan 16, 2014 at 5: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: > > >- Keeping

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

On Thu, Jan 16, 2014 at 1:23 PM, Donald Stufft wrote: > > 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

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

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] [OpenStack-Dev] Third party testing

On Fri, Jan 17, 2014 at 1:15 AM, Robert Collins wrote: > On 16 January 2014 14:51, John Griffith wrote: >> On Wed, Jan 15, 2014 at 6:41 PM, Michael Still 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. >

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

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 th

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

On Jan 16, 2014, at 9:41 PM, Jiang, Yunhong 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 opportunity to roll

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

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] [OpenStack-Dev] Cherry picking commit from oslo-incubator

On Fri, Jan 17, 2014 at 1:15 AM, Flavio Percoco wrote: > On 16/01/14 17:32 -0500, Doug Hellmann wrote: >> >> 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 spe

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

On 17 Jan 2014, at 16:10, Jay Pipes 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 and high a

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

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

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

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

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] a "common" client library

>> 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 indepen

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

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: https://etherpad.openstack.o

[openstack-dev] [climate] Meeting minutes

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: http://eavesdrop.openstack.o

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

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 that

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

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 a

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

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 >

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

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 net/physic

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

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), i

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

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 [mailto:yun

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

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 and

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

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 use

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

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 (not

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

On 17/01/2014 08:19, Robert Collins wrote: > On 16 January 2014 03:31, Alan Kavanagh 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 wonde

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

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

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

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 possib

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

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 implementa

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

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 to

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

On Thu, Jan 16, 2014 at 7:29 PM, Clint Byrum 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 devtest that they co

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

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

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

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 dat

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

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 an

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

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

Re: [openstack-dev] "Evil" Firmware

On 17 January 2014 09:12, Robert Collins 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 > functions--typically > > mostly just

Re: [openstack-dev] "Evil" Firmware

On 17 January 2014 01:16, Chris Friesen 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 regard to PCI passthrou

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

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 servic

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

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 (P&I) Marc Koderer Cloud Technology Software Developer T-Online-Allee 1, 64211 Dar

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

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

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

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 decora

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

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

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

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? And

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

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 enough

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

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 l

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

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. https:/

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

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 wrot

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

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 di

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

On 16 January 2014 14:51, John Griffith wrote: > On Wed, Jan 15, 2014 at 6:41 PM, Michael Still 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, but I guess in essence to start these ar

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

On 16/01/14 17:32 -0500, Doug Hellmann wrote: 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

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

On 16 January 2014 03:31, Alan Kavanagh 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 better recommendations

Re: [openstack-dev] "Evil" Firmware

> 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