Re: [openstack-dev] Separating our Murano PL core in own package

Timur, I don't know about plans to support different languages for Murano Engine. I think Murano PL may be valuable as standalone library, so I think we should extract Murano PL code to separate package, and if we will need it as a library it will be easy to extract to. On Mon, Mar 24, 2014 at 12

Re: [openstack-dev] Separating our Murano PL core in own package

+1 for muranoapi.engine.murano_pl, because 'dsl'/'language' terms are too broad. On Mon, Mar 24, 2014 at 12:48 AM, Timur Nurlygayanov wrote: > Hi Serg, > > This idea sounds good, I suggest to use name 'murano.engine.murano_pl' (not > just common name like 'language' or 'dsl', but name, which will

[openstack-dev] [rally] Proposing Kun to Rally Core.

Hi stackers, I would like to propose Kun Huang to Rally Core team. As you saw already, he is doing a lot of good reviews, and catch a lot of nits and bugs, so he will be a good core reviewer. Here is detailed statistics for the latest 30 days: http://stackalytics.com/report/contribution/rally/30

Re: [openstack-dev] Separating our Murano PL core in own package

>because 'dsl'/'language' terms are too broad. Too broad in general, but we choose name for sub-package, and in murano term 'language' mean Murano PL. +1 for language On Mon, Mar 24, 2014 at 11:26 AM, Timur Sufiev wrote: > +1 for muranoapi.engine.murano_pl, because 'dsl'/'language' terms are t

Re: [openstack-dev] Separating our Murano PL core in own package

What does PL stand for, anyway? -- Best regards, Oleg Gelbukh On Mon, Mar 24, 2014 at 11:39 AM, Serg Melikyan wrote: > >because 'dsl'/'language' terms are too broad. > Too broad in general, but we choose name for sub-package, and in murano > term 'language' mean Murano PL. > > +1 for language >

Re: [openstack-dev] Separating our Murano PL core in own package

Programming Language, AFAIK On Mon, Mar 24, 2014 at 11:46 AM, Oleg Gelbukh wrote: > What does PL stand for, anyway? > > -- > Best regards, > Oleg Gelbukh > > > On Mon, Mar 24, 2014 at 11:39 AM, Serg Melikyan wrote: > >> >because 'dsl'/'language' terms are too broad. >> Too broad in general, but

Re: [openstack-dev] [neutron][rootwrap] Performance considerations, sudo?

It's the first call starting the daemon / loading config files, etc?, May be that first sample should be discarded from the mean for all processes (it's an outlier value). On 03/21/2014 05:32 PM, Yuriy Taraday wrote: On Fri, Mar 21, 2014 at 2:01 PM, Thierry Carrez mailto:thie...@openstack

[openstack-dev] [Ceilometer] [QA] unification of timestamp related parameters in query fileds

Hi stackers: I have a problem about unification of timestamp related parameters in query fileds. the related bug is: https://bugs.launchpad.net/ceilometer/+bug/1295100 start_timestamp/end_timestamp and start/end and timestamp is not unified in query fields. for examples: the valid key

Re: [openstack-dev] auto-delete in amqp "reply_*" queues in OpenStack

Chris, In oslo.messaging a single reply queue is used to gather results from all the calls. It is created lazily on the first call and is used until the process is killed. I did a quick look at oslo.rpc from oslo-incubator and it seems like it uses the same pattern, which is not surprising since o

Re: [openstack-dev] [nova] An analysis of code review in Nova

Regarding the spawn there are a number of patches up for review at the moment - they are all mutually exclusive and hopefully will make the process a lot smoother. https://review.openstack.org/#/q/topic:bp/vmware-spawn-refactor,n,z In addition to this we have a patch up for review with the OSLO int

Re: [openstack-dev] [Ironic][Nova] Functional testing of Nova Ironic driver

Hi, https://etherpad.openstack.org/p/IronicAndDevstackAgain might help you. Should flawlessly work on Ubuntu 12.04. Latest devstack creates baremetal flavor by itself, so you don't need to create it manually. Let me know if you need any additional help. Or it could be better to ask in IRC #openst

Re: [openstack-dev] [rally] Proposing Kun to Rally Core.

+1 Kun has been very active on gerrit, and contributed good patches, so will be a great addition to the core team. -- Hugh Saunders On 24 March 2014 07:31, Boris Pavlovic wrote: > Hi stackers, > > > I would like to propose Kun Huang to Rally Core team. > As you saw already, he is doing a lot

Re: [openstack-dev] [depfreeze] Dependency freeze coming up (EOD Tuesday March 25)

Joe Gordon wrote: > There are still two outstanding trove dependencies that are currently > used in trove but not in global requirements. It would be nice to get > this sorted out before the freeze so we can > turn https://review.openstack.org/#/c/80690/ on. > > mockito https://review.openstack.or

[openstack-dev] [OpenStack-dev][QA] Does turbo-hipster fail in Nova?

Hi all, Does turbo-hipster fail in Nova? I rechecked and recommitted my patches[1][2], the gate jobs always fail. I check all the Nova patches on Gerrit[3] now, and found lots of nova patches fail caused by turbo-hipster. Does it meet some problems? Thanks. wingwj - [1] https

Re: [openstack-dev] Separating our Murano PL core in own package

Hi Serg, Are you proposing to have a standalone git repository / stack forge project for that? Or just a separate package inside our primary murano repo? -- Regards, Alexander Tivelkov On Mon, Mar 24, 2014 at 12:00 PM, Serg Melikyan wrote: > Programming Language, AFAIK > > > On Mon, Mar 24, 20

Re: [openstack-dev] [Nova] Updates to Juno blueprint review process

Russell Bryant wrote: > On 03/21/2014 02:55 PM, Stefano Maffulli wrote: >> While I'm here, and for the records, I think that creating a new >> workflow 'temporarily' only until we have Storyboard usable, is a *huge* >> mistake. It seems to me that you're ignoring or at least underestimating >> the

Re: [openstack-dev] [OpenStack-dev][QA] Does turbo-hipster fail in Nova?

The information provided in patch[1] is like this: - gate-real-db-upgrade_nova_mysql_devstack_131007 SUCCESS in 9m 08s - gate-real-db-upgrad

Re: [openstack-dev] [rally] Proposing Kun to Rally Core.

+1 ! Thanks. -chen From: Boris Pavlovic [mailto:[email protected]] Sent: Monday, March 24, 2014 3:32 PM To: OpenStack Development Mailing List Subject: [openstack-dev] [rally] Proposing Kun to Rally Core. Hi stackers, I would like to propose Kun Huang to Rally Core team. As you saw alrea

Re: [openstack-dev] [rally] Proposing Kun to Rally Core.

+1I would like to propose Kun Huang to Rally Core team. As you saw already, he is doing a lot of good reviews, and catch a lot of nits and bugs, so he will be a good core reviewer.   Here is detailed statistics for the latest 30 days:http://stackalytics.com/report/contribution/rally/30 Thoughts? B

Re: [openstack-dev] [rally] Proposing Kun to Rally Core.

nice to join you guys ; ) On Monday, March 24, 2014, Hugh Saunders wrote: > +1 > Kun has been very active on gerrit, and contributed good patches, so will > be a great addition to the core team. > > > -- > Hugh Saunders > > > On 24 March 2014 07:31, Boris Pavlovic > > > wrote: > >> Hi stackers

Re: [openstack-dev] [rally] Proposing Kun to Rally Core.

Kun, Welcome to Rally core team! =) Best regards, Boris Pavlovic On Mon, Mar 24, 2014 at 2:12 PM, Gareth wrote: > nice to join you guys ; ) > > > On Monday, March 24, 2014, Hugh Saunders wrote: > >> +1 >> Kun has been very active on gerrit, and contributed good patches, so will >> be a great

Re: [openstack-dev] Separating our Murano PL core in own package

Alexander, to have simple sub-package in muranoapi.engine/muranoapi On Mon, Mar 24, 2014 at 1:43 PM, Alexander Tivelkov wrote: > Hi Serg, > > Are you proposing to have a standalone git repository / stack forge > project for that? Or just a separate package inside our primary murano repo? > > --

Re: [openstack-dev] Separating our Murano PL core in own package

I like dsl most because it is a. Short. This is especially good when you have that "awesome" 79-chars limitation b. It leaves a lot of room for changes. MuranoPL can change name. DSL - not :) On Mon, Mar 24, 2014 at 1:43 PM, Alexander Tivelkov wrote: > Hi Serg, > > Are you proposing to have a st

Re: [openstack-dev] Jenkins test logs and their retention period

Here is some preliminary views (it currently ignores the ceilometer logs, I haven't had a chance to dive in there yet). It actually looks like a huge part of the issue is olso.messaging, the bulk of screen-n-cond is oslo.messaging debug errors. It seems that in debug mode oslo.messaging is basical

[openstack-dev] [Neutron][LBaaS] Glossary

Hi, Here's the wiki page with a list of terms we're usually operate when discussing lbaas object model: https://wiki.openstack.org/wiki/Neutron/LBaaS/Glossary Feel free to add/modify/ask questions. Thanks, Eugene. ___ OpenStack-dev mailing list OpenSta

[openstack-dev] [horizon] admin deployement/maintenance commands.

Hi all, I drafted 2 blueprints (and pushed to patches) to allow administrators to: - deploy an apache configuration : https://blueprints.launchpad.net/horizon/+spec/web-conf-generation-script - maintain the local_settings.py and migrate it easily with new features (migration script) with

[openstack-dev] [Murano] API/data formats version change and compatibility

Hi all! While adapting Murano's Dynamic UI to the new MuranoPL data input format, I've encountered the need to add some new fields to it, which meant that the 'Version' field also had to be added to Dynamic UI. So, Dynamic UI definition without Version field is supposed to be of v.1 while upcoming

Re: [openstack-dev] [Murano][Heat] MuranoPL questions?

Hi Stan, Comments inline. > Zane, > > I appreciate your explanations on Heat/HOT. This really makes sense. > I didn't mean to say that MuranoPL is better for Heat. Actually HOT is good > for Heat's mission. I completely acknowledge it. > I've tried to avoid comparison between languages and I'm s

Re: [openstack-dev] [Murano] API/data formats version change and compatibility

Let's discuss this in community meeting. I would suggest drop support for older version at least until we release Murano 1.0. As soon as we start to guarantee backward compatibility we will introduce MinimalMuranoVersion instead of Version because format would not change but some particular templa

Re: [openstack-dev] [Neutron][LBaaS] Glossary

Looks good, Thanks Susanne On Mon, Mar 24, 2014 at 6:55 AM, Eugene Nikanorov wrote: > Hi, > > Here's the wiki page with a list of terms we're usually operate when > discussing lbaas object model: > https://wiki.openstack.org/wiki/Neutron/LBaaS/Glossary > > Feel free to add/modify/ask questions.

Re: [openstack-dev] [Murano][Heat] MuranoPL questions?

Hi, > > So that's where I want to make a first stop. If your primary user is not a > developer, there is no reason to introduce a DSL for security reasons. The > provider can trust the code he writes, and there is no need to create a > dedicated language. I thinks this need to be clarified. The

Re: [openstack-dev] [Murano][Heat] MuranoPL questions?

On Mon, Mar 24, 2014 at 4:13 PM, Thomas Herve wrote: What I can say is that I'm not convinced. The only use-case for a DSL would > be if you have to upload user-written code, but what you mentioned is a Web > interface, where the user doesn't use the DSL, and the cloud provider is > the developer.

[openstack-dev] [cinder] Extend operation for NFS driver

Hi cinder, Just noticed we have competing solutions to implement extend_volume in the generic NFS driver [1] & [2]. I understand these are not targeted until after RC1, but I also didn't want the duplicate effort lost in the shuffle. Are there any thoughts on which is the more appropriate implem

[openstack-dev] Multiple patches in one review

When a change is complex good practice is to break the change into a series of smaller individual patches that show the individual incremental steps needed to get to the final goal. When partitioned into small steps each change is easier to review and hopefully illustrates the progression. In most

Re: [openstack-dev] Multiple patches in one review

On Mon, Mar 24 2014, John Dennis wrote: > But from that point forward it appears as if each commit is handled > independently rather than being an ordered list of commits that are > grouped together sharing a single review where their relationship is > explicit. Also the jenkins tests either needs

Re: [openstack-dev] Multiple patches in one review

On 03/24/2014 10:31 AM, John Dennis wrote: > When a change is complex good practice is to break the change into a > series of smaller individual patches that show the individual > incremental steps needed to get to the final goal. When partitioned into > small steps each change is easier to review

Re: [openstack-dev] [Marconi] Proposal to add Malini Kamalambal to the marconi-core team

+1! Malini is going to be a great addition! On 03/21/2014 09:06 PM, Alejandro Cabrera wrote: > +1. > > Malini is dedicated to making Marconi and Openstack a healthier, better > place. I am very happy to see Malini being proposed for Core. I trust > that she'll do wonders for the project and will

Re: [openstack-dev] Multiple patches in one review

On Mon, Mar 24, 2014 at 8:31 AM, John Dennis wrote: > When a change is complex good practice is to break the change into a > series of smaller individual patches that show the individual > incremental steps needed to get to the final goal. When partitioned into > small steps each change is easier

Re: [openstack-dev] Multiple patches in one review

On 03/24/2014 11:08 AM, John Griffith wrote: > > On Mon, Mar 24, 2014 at 8:31 AM, John Dennis > wrote: > > When a change is complex good practice is to break the change into a > series of smaller individual patches that show the individual > incremental ste

Re: [openstack-dev] MuranoPL questions?

MuranoPL supposed to provide a solution for the real needs to manage services in the centralized manner and to allow cloud provider customers to create their own services. The application catalog similar to AppDirect (www.appdirect.com) natively supported by OpenStack is a huge step forward. Think

Re: [openstack-dev] [Nova] Updates to Juno blueprint review process

On 03/22/2014 03:14 AM, Sean Dague wrote: > Honestly, I largely disagree. This is applying some process where there > clearly wasn't any before. We have a different perception evidently. I'm assuming you're exaggerating for the sake of clarity because assuming there was no process before means tha

Re: [openstack-dev] [keystone] python-keystoneclient unit tests only if python-memcache is installed

FWIW, I opened a bug [1] and proposed a fix [2]. [1]: https://bugs.launchpad.net/python-keystoneclient/+bug/1296794 [2]: https://review.openstack.org/#/c/82527/ On Fri, Mar 21, 2014 at 12:38 AM, Thomas Goirand wrote: > On 03/20/2014 11:48 PM, Dolph Mathews wrote: > > Yes, those tests are condit

Re: [openstack-dev] auto-delete in amqp "reply_*" queues in OpenStack

On 03/24/2014 02:59 AM, Dmitry Mescheryakov wrote: Chris, In oslo.messaging a single reply queue is used to gather results from all the calls. It is created lazily on the first call and is used until the process is killed. I did a quick look at oslo.rpc from oslo-incubator and it seems like it u

[openstack-dev] [Neutron][LBaaS] Neutron LBaaS, Libra and "managed services" concept

Hi Neutron LBaaS folks, I have been getting up to speed on the Neutron LBaaS implementation and have been wondering how to make it fit our needs in HP public cloud as well as as an enterprise-grade load balancer service for HP Openstack implementations. We are currently using Libra as our LBaaS i

Re: [openstack-dev] Multiple patches in one review

On 2014-03-24 09:31, John Dennis wrote: > When a change is complex good practice is to break the change into a > series of smaller individual patches that show the individual > incremental steps needed to get to the final goal. When partitioned into > small steps each change is easier to review and

[openstack-dev] oslo.rootwrap 1.2.0 released

A new version of the oslo.rootwrap library (1.2.0) was just released: https://pypi.python.org/pypi/oslo.rootwrap http://tarballs.openstack.org/oslo.rootwrap/oslo.rootwrap-1.2.0.tar.gz MD5SUM: 2cd7e0b6e838d2ee492982e99a7834a2 It contains the following improvements and bugfixes: Add "use_syslog_r

Re: [openstack-dev] OpenStack vs. SQLA 0.9

There's a proposed change to Keystone to update SQLAlchemy to 0.9[0] which is failing in the doc build. I'm not sure exactly what it's doing that's causing it to fail. I proposed changes to work around the issues[1] based on the error messages. Part of the fix requires a change in oslo-incubator co

Re: [openstack-dev] [openstack-qa] Graduation Requirements + Scope of Tempest

On 3/21/14 3:49 PM, "Rochelle.RochelleGrober" wrote: > >> From: Malini Kamalambal [mailto:[email protected]] > >> >> We are talking about different levels of testing, >> >> 1. Unit tests - which everybody agrees should be in the individual >> project >> itself >> 2. System Tests

[openstack-dev] Spec repos for blueprint development and review

Hi, So recently we started this experiment with the compute and qa programs to try using Gerrit to review blueprints. Launchpad is deficient in this area, and while we hope Storyboard will deal with it much better, but it's not ready yet. As a development organization, OpenStack scales by adopti

[openstack-dev] [Mistral] Community meeting minutes - 03/24/2014

Hi folks, thanks for taking part in Mistral meeting on #openstack-meeting Here is the minutes and the full log. Minutes http://eavesdrop.openstack.org/meetings/mistral/2014/mistral.2014-03-24-16.03.html Log: http://eavesdrop.openstack.org/meetings/mistral/2014/mistral.2014-03-24-16.03.log.html

[openstack-dev] [nova] nova-compute not re-establishing connectivity after controller switchover

We've been stress-testing our system doing controlled switchover of the controller. Normally this works okay, but we've run into a situation that seems to show a flaw in the reconnection logic. On the compute node, nova-compute has managed to get into a state where it shows as "down" in "nova

[openstack-dev] Ports' vif_details after upgrading from havana with ML2

Hello, In Icehouse was introduced new column vif_details and removed cap_port_filter. During db migration data in cap_port_filter column are lost and after upgrade the vif_details column is legally empty. This leads to tempest tests failure when checking port_filter[1]. What would be the impact o

Re: [openstack-dev] [TripleO] test environment requirements

- Original Message - > From: "Clint Byrum" > To: "openstack-dev" > Sent: Sunday, March 23, 2014 9:02:23 PM > Subject: Re: [openstack-dev] [TripleO] test environment requirements > > Excerpts from Dan Prince's message of 2014-03-21 09:25:42 -0700: > > > > - Original Message - >

Re: [openstack-dev] [TripleO] test environment requirements

- Original Message - > From: "Robert Collins" > To: "OpenStack Development Mailing List (not for usage questions)" > > Sent: Sunday, March 23, 2014 11:18:19 PM > Subject: Re: [openstack-dev] [TripleO] test environment requirements > > On 24 March 2014 14:06, Clint Byrum wrote: > > Ex

Re: [openstack-dev] [nova] nova-compute not re-establishing connectivity after controller switchover

> Any ideas on what might be going on would be appreciated. This looks like something that should be filed as a bug. I don't have any ideas off hand, bit I will note that the reconnection logic works fine for us in the upstream upgrade tests. That scenario includes starting up a full stack, then t

Re: [openstack-dev] [nova] nova-compute not re-establishing connectivity after controller switchover

On 03/24/2014 10:41 AM, Chris Friesen wrote: We've been stress-testing our system doing controlled switchover of the controller. Normally this works okay, but we've run into a situation that seems to show a flaw in the reconnection logic. On the compute node, nova-compute has managed to get in

Re: [openstack-dev] Spec repos for blueprint development and review

On 03/24/2014 12:34 PM, James E. Blair wrote: > Hi, > > So recently we started this experiment with the compute and qa programs > to try using Gerrit to review blueprints. Launchpad is deficient in > this area, and while we hope Storyboard will deal with it much better, > but it's not ready yet.

[openstack-dev] [Neutron][LBaaS] Neutron LBaaS, Libra and "managed services"

My apologies if you receive this twice. I seems to have problems with my gmail account. Hi Neutron LBaaS folks, I have been getting up to speed on the Neutron LBaaS implementation and have been wondering how to make it fit our needs in HP public cloud as well as as an enterprise-grade load ba

Re: [openstack-dev] [Nova] Updates to Juno blueprint review process

On 03/24/2014 11:42 AM, Stefano Maffulli wrote: > On 03/22/2014 03:14 AM, Sean Dague wrote: >> Honestly, I largely disagree. This is applying some process where there >> clearly wasn't any before. > > We have a different perception evidently. I'm assuming you're > exaggerating for the sake of clar

Re: [openstack-dev] test environment requirements

> From: Dan Prince [mailto:[email protected]] > Sent: 24 March 2014 16:53 > Subject: Re: [openstack-dev] [TripleO] test environment requirements > > > From: "Clint Byrum" > > To: "openstack-dev" > > Sent: Sunday, March 23, 2014 9:02:23 PM > > Subject: Re: [openstack-dev] [TripleO] test environm

Re: [openstack-dev] [nova] nova-compute not re-establishing connectivity after controller switchover

On 03/24/2014 10:59 AM, Dan Smith wrote: Any ideas on what might be going on would be appreciated. This looks like something that should be filed as a bug. I don't have any ideas off hand, bit I will note that the reconnection logic works fine for us in the upstream upgrade tests. That scenario

Re: [openstack-dev] Spec repos for blueprint development and review

On 03/24/2014 01:07 PM, Russell Bryant wrote: > On 03/24/2014 12:34 PM, James E. Blair wrote: >> Hi, >> >> So recently we started this experiment with the compute and qa programs >> to try using Gerrit to review blueprints. Launchpad is deficient in >> this area, and while we hope Storyboard will

[openstack-dev] [infra] Meeting Tuesday March 25th at 19:00 UTC

Hi everyone, The OpenStack Infrastructure (Infra) team is hosting our weekly meeting tomorrow, Tuesday March 25th, at 19:00 UTC in #openstack-meeting Meeting agenda available here: https://wiki.openstack.org/wiki/Meetings/InfraTeamMeeting (anyone is welcome to to add agenda items) Everyone inter

Re: [openstack-dev] [Nova] Updates to Juno blueprint review process

On Sat, Mar 22, 2014 at 3:14 AM, Sean Dague wrote: > > Storyboard remains vaporware. I will be enormously happy when it is not. > You could, oh, I dunno, maybe contribute to the codebase. I am _certain_ that it would make more people happy than calling it vaporware on a public list. Michael

Re: [openstack-dev] [Nova] Updates to Juno blueprint review process

On 03/24/2014 12:20 PM, Russell Bryant wrote: > On 03/24/2014 11:42 AM, Stefano Maffulli wrote: >> On 03/22/2014 03:14 AM, Sean Dague wrote: >>> Honestly, I largely disagree. This is applying some process where there >>> clearly wasn't any before. >> >> We have a different perception evidently. I'm

Re: [openstack-dev] Spec repos for blueprint development and review

On 03/24/2014 01:07 PM, Russell Bryant wrote: > On 03/24/2014 12:34 PM, James E. Blair wrote: >> Hi, >> >> So recently we started this experiment with the compute and qa programs >> to try using Gerrit to review blueprints. Launchpad is deficient in >> this area, and while we hope Storyboard will

Re: [openstack-dev] Multiple patches in one review

+1 to all Ben said. There are reasons to split things up in to a logical progression of changes but each change must stand alone and must pass tests. Carl On Mon, Mar 24, 2014 at 10:03 AM, Ben Nemec wrote: > I should point out that Jenkins can't apply the next patch in sequence > just to get te

Re: [openstack-dev] [TripleO] test environment requirements

On 2014-03-23 22:18, Robert Collins wrote: > On 24 March 2014 14:06, Clint Byrum wrote: >> Excerpts from Robert Collins's message of 2014-03-13 02:51:30 -0700: >>> So we already have pretty high requirements - its basically a 16G >>> workstation as minimum. >>> >>> Specifically to test the full st

Re: [openstack-dev] [neutron][rootwrap] Performance considerations, sudo?

Don't discard the first number so quickly. For example, say we use a timeout mechanism for the daemon running inside namespaces to avoid using too much memory with a daemon in every namespace. That means we'll pay the startup cost repeatedly but in a way that amortizes it down. Even if it is rea

Re: [openstack-dev] [nova] nova-compute not re-establishing connectivity after controller switchover

On 03/24/2014 11:31 AM, Chris Friesen wrote: It looks like we're raising RecoverableConnectionError: connection already closed down in /usr/lib64/python2.7/site-packages/amqp/abstract_channel.py, but nothing handles it. It looks like the most likely place that should be handling it is nova.op

Re: [openstack-dev] [Nova] Updates to Juno blueprint review process

On 03/24/2014 01:40 PM, Michael Krotscheck wrote: > On Sat, Mar 22, 2014 at 3:14 AM, Sean Dague > wrote: > > Storyboard remains vaporware. I will be enormously happy when it is not. > > > You could, oh, I dunno, maybe contribute to the codebase. I am _certain_ > that

Re: [openstack-dev] [Mistral] Local vs. Scalable Engine

I have the following murano-ci failure for my last patch set. https://murano-ci.mirantis.com/job/mistral_master_on_commit/194/ Since I modified the API launch script in mistral, is that the cause of this failure here? Do I have to make changes to the tempest test? Please advise. Thanks. On Fr

Re: [openstack-dev] [openstack-qa] Graduation Requirements + Scope of Tempest

On Fri, Mar 21, 2014 at 9:38 AM, Malini Kamalambal < [email protected]> wrote: > > > On 3/21/14 12:01 PM, "David Kranz" wrote: > > >On 03/20/2014 04:19 PM, Rochelle.RochelleGrober wrote: > >> > >>> -Original Message- > >>> From: Malini Kamalambal [mailto:malini.kamalam...@ra

[openstack-dev] [Ironic] Nodeless Vendor Passthru API

All, Ironic allows drivers to expose a "vendor passthru" API on a Node. This basically serves two purposes: 1. Allows drivers to expose functionality that hasn't yet been standardized in the Ironic API. For example, the Seamicro driver exposes "attach_volume", "set_boot_device" and "set_node_vlan

Re: [openstack-dev] Spec repos for blueprint development and review

Russell Bryant writes: > On 03/24/2014 12:34 PM, James E. Blair wrote: >> Hi, >> >> So recently we started this experiment with the compute and qa programs >> to try using Gerrit to review blueprints. Launchpad is deficient in >> this area, and while we hope Storyboard will deal with it much be

Re: [openstack-dev] Separating our Murano PL core in own package

Seeing that the following repos already exist, maybe there is some need for cleanup? - https://github.com/stackforge/murano-agent - https://github.com/stackforge/murano-api - https://github.com/stackforge/murano-common - https://github.com/stackforge/murano-conductor - https://github.com/stackfor

Re: [openstack-dev] Spec repos for blueprint development and review

On 03/24/2014 10:07 AM, Russell Bryant wrote: On 03/24/2014 12:34 PM, James E. Blair wrote: Hi, So recently we started this experiment with the compute and qa programs to try using Gerrit to review blueprints. Launchpad is deficient in this area, and while we hope Storyboard will deal with it

Re: [openstack-dev] [depfreeze] Dependency freeze coming up (EOD Tuesday March 25)

On Mon, Mar 24, 2014 at 5:33 AM, Thierry Carrez wrote: > Joe Gordon wrote: > > There are still two outstanding trove dependencies that are currently > > used in trove but not in global requirements. It would be nice to get > > this sorted out before the freeze so we can > > turn https://review.ope

Re: [openstack-dev] [neutron][rootwrap] Performance considerations, sudo?

On Mon, Mar 24, 2014 at 9:51 PM, Carl Baldwin wrote: > Don't discard the first number so quickly. > > For example, say we use a timeout mechanism for the daemon running > inside namespaces to avoid using too much memory with a daemon in > every namespace. That means we'll pay the startup cost re

Re: [openstack-dev] Spec repos for blueprint development and review

On 03/24/2014 02:05 PM, James E. Blair wrote: > Russell Bryant writes: > >> On 03/24/2014 12:34 PM, James E. Blair wrote: >>> Hi, >>> >>> So recently we started this experiment with the compute and qa programs >>> to try using Gerrit to review blueprints. Launchpad is deficient in >>> this area,

Re: [openstack-dev] [nova] An analysis of code review in Nova

I fully support https://review.openstack.org/#/c/70175/ but I fail to see why the spawn-refactor should depend on that. There are only 13 lines touched that are related. These two tasks could be completed more or less in parallel. On Mon, Mar 24, 2014 at 4:57 AM, Gary Kotton wrote: > Regarding th

Re: [openstack-dev] [depfreeze] Dependency freeze coming up (EOD Tuesday March 25)

On 03/24/2014 02:20 PM, Doug Hellmann wrote: > > > > On Mon, Mar 24, 2014 at 5:33 AM, Thierry Carrez > wrote: > > Joe Gordon wrote: > > There are still two outstanding trove dependencies that are currently > > used in trove but not in global requiremen

Re: [openstack-dev] Separating our Murano PL core in own package

On Mon, Mar 24, 2014 at 10:08 PM, Joshua Harlow wrote: > Seeing that the following repos already exist, maybe there is some need for > cleanup? > > - https://github.com/stackforge/murano-agent > - https://github.com/stackforge/murano-api > - https://github.com/stackforge/murano-common > - https://

Re: [openstack-dev] Spec repos for blueprint development and review

On 03/24/2014 02:19 PM, Monty Taylor wrote: > On 03/24/2014 10:07 AM, Russell Bryant wrote: >> On 03/24/2014 12:34 PM, James E. Blair wrote: >>> Hi, >>> >>> So recently we started this experiment with the compute and qa programs >>> to try using Gerrit to review blueprints. Launchpad is deficient

Re: [openstack-dev] [Nova] Updates to Juno blueprint review process

On Fri, Mar 21, 2014 at 4:40 PM, Steve Gordon wrote: > - Original Message - > > We recently discussed the idea of using gerrit to review blueprint > > specifications [1]. There was a lot of support for the idea so we have > > proceeded with putting this together before the start of the J

Re: [openstack-dev] [depfreeze] Dependency freeze coming up (EOD Tuesday March 25)

On Mon, Mar 24, 2014 at 2:28 PM, Sean Dague wrote: > On 03/24/2014 02:20 PM, Doug Hellmann wrote: > > > > > > > > On Mon, Mar 24, 2014 at 5:33 AM, Thierry Carrez > > wrote: > > > > Joe Gordon wrote: > > > There are still two outstanding trove dependencies th

[openstack-dev] [barbican] Meeting Monday March 24th at 20:00 UTC

Hi Everyone, The Barbican team is hosting our weekly meeting today, Monday March 24, at 20:00 UTC in #openstack-meeting-alt Meeting agenda is avaialbe here https://wiki.openstack.org/wiki/Meetings/Barbican and everyone is welcomed to add agenda items You can check this link http://time.is/0800P

Re: [openstack-dev] [Mistral][TaskFlow] Long running actions

So getting back to this thread. I'd like to split it up into a few sections to address the HA and long-running-actions cases, which I believe are 2 seperate (but connected) questions. === Long-running actions === First, let me describe a little bit about what I believe are the execution model

[openstack-dev] Rolling upgrades in icehouse

Hello folks, I was reading a blogpost mentioned in the newsletter here - http://redhatstackblog.redhat.com/2014/03/11/an-icehouse-sneak-peek-openstack-compute-nova/ A note about rolling upgrades is mentioned - The Compute services now allow for a level of rolling upgrade, whereby control servic

Re: [openstack-dev] [depfreeze] Dependency freeze coming up (EOD Tuesday March 25)

RE Sahara, we'll need one more version bump to remove all backward compat code added for smooth transition. What's the deadline for doing it? Personally, I'd like to do it next week. Is it ok? Thanks. On Mon, Mar 24, 2014 at 10:41 PM, Doug Hellmann wrote: > > > > On Mon, Mar 24, 2014 at 2:28 PM,

Re: [openstack-dev] [depfreeze] Dependency freeze coming up (EOD Tuesday March 25)

Sean Dague writes: > > The Trove team said last week they could probably land the remove in > trove this week for mockito (it was on their roadmap anyway). So unless > they feel that's not doable, I think we're good. > > -Sean Yes, this was discussed at the trove IRC meeting last week, and is s

Re: [openstack-dev] Rolling upgrades in icehouse

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > Where can I obtain more information about this feature? - From the blog post that I've yet to write :D > Does above imply that database is upgraded along with control > service update as well? Yes, but only for the services that interact directly

Re: [openstack-dev] Spec repos for blueprint development and review

On Mon, Mar 24, 2014 at 02:32:35PM -0400, Russell Bryant wrote: > On 03/24/2014 02:19 PM, Monty Taylor wrote: > > On 03/24/2014 10:07 AM, Russell Bryant wrote: > >> On 03/24/2014 12:34 PM, James E. Blair wrote: > >>> Hi, > >>> > >>> So recently we started this experiment with the compute and qa pro

Re: [openstack-dev] auto-delete in amqp "reply_*" queues in OpenStack

I see two possible explanations for these 5 remaining queues: * They were indeed recreated by 'compute' services. I.e. controller service send some command over rpc and then it was shut down. Its reply queue was automatically deleted, since its only consumer was disconnected. The compute services

Re: [openstack-dev] Rolling upgrades in icehouse

How does this interact with cells ? Can the cell API instances be upgraded independently of the cells themselves ? My ideal use case would be - It would be possible to upgrade one of the cells (such as a QA environment) before the cell API nodes - Cells can be upgraded one-by-one as needed by

Re: [openstack-dev] [neutron][rootwrap] Performance considerations, sudo?

I was thinking that we could document the information about sudo and iproute2 patches with the upcoming release. How would I go about doing this? Is there any section in our documentation about OS level tweaks or requirements such as these that could present this information as part of the releas

[openstack-dev] [TripleO][Tempest]

Hey, so folk want to start glueing tempest and tripleo-ci together - yay! Sadly I was asleep during the IRC conversation, but I just wanted to note - we've no need to bake tempested into images at this point - the jenkins slave is appropriately resourced to run tempest against the deployed cloud,

Re: [openstack-dev] [TripleO] test environment requirements

On 25 March 2014 06:28, Ben Nemec wrote: > > I created an etherpad here: > https://etherpad.openstack.org/p/devtest-env-reqs > > And linked it from the blueprint here: > https://blueprints.launchpad.net/tripleo/+spec/test-environment-requirements > > I only added some details about devtest on ope

Re: [openstack-dev] [Neutron][LBaaS] Neutron LBaaS, Libra and "managed services"

Hi Susanne, a couple of comments inline: > > We would like to discuss adding the concept of "managed services" to the > Neutron LBaaS either directly or via a Neutron LBaaS plug-in to Libra/HA > proxy. The latter could be a second approach for some of the software > load-balancers e.g. HA prox

Re: [openstack-dev] Rolling upgrades in icehouse

On Mar 24, 2014, at 12:31 PM, Tim Bell wrote: > > How does this interact with cells ? Can the cell API instances be upgraded > independently of the cells themselves ? > > My ideal use case would be > > - It would be possible to upgrade one of the cells (such as a QA environment) > before th

  1   2   >