Re: [openstack-dev] [TripleO] reviewer update march

+1 On 04/03/2014 01:02 PM, Robert Collins wrote: Getting back in the swing of things... Hi, like most OpenStack projects we need to keep the core team up to date: folk who are not regularly reviewing will lose context over time, and new folk who have been reviewing regularly should be trust

Re: [openstack-dev] [Heat] [Murano] [Solum] applications in the cloud

Hi Steve, your indexing idea sounds interesting, but I am not sure it would work reliably. The kind of matching based on names of parameters and outputs and internal get_attr uses has very strong assumptions and I think there is a not so low risk of false positives. What if the templates includes

Re: [openstack-dev] [TripleO] reviewer update march

On 03/04/14 14:02, Robert Collins wrote: > Getting back in the swing of things... > > Hi, > like most OpenStack projects we need to keep the core team up to > date: folk who are not regularly reviewing will lose context over > time, and new folk who have been reviewing regularly should be trus

Re: [openstack-dev] [TripleO] reviewer update march

On 04/03/2014 01:02 PM, Robert Collins wrote: Getting back in the swing of things... Hi, like most OpenStack projects we need to keep the core team up to date: folk who are not regularly reviewing will lose context over time, and new folk who have been reviewing regularly should be trusted

Re: [openstack-dev] Quota Management

Glad to see this, i will be glad to contribute on it if the project could move on.. On Apr 4, 2014, at 10:01, Cazzolato, Sergio J wrote: > > Glad to see that, for sure I'll participate of this session. > > Thanks > > -Original Message- > From: Jay Pipes [mailto:jaypi...@gmail.com]

[openstack-dev] [Swift] Icehouse RC1 available

Hello everyone, Last but not least, Swift just published its first Icehouse release candidate. You can find the tarball for 1.13.1-rc1 at: https://launchpad.net/swift/icehouse/1.13.1-rc1 Unless release-critical issues are found that warrant a release candidate respin, this RC1 will be formally r

Re: [openstack-dev] [Nova] Hosts within two Availability Zones : possible or not ?

Hi all, 2014-04-03 18:47 GMT+02:00 Meghal Gosalia : > Hello folks, > > Here is the bug [1] which is currently not allowing a host to be part of > two availability zones. > This bug was targeted for havana. > > The fix in the bug was made because it was assumed > that openstack does not suppo

[openstack-dev] [Cinder] Whats the way to do cleanup during service shutdown / restart ?

resendign it with correct cinder prefix in subject. thanx, deepak On Thu, Apr 3, 2014 at 7:44 PM, Deepak Shetty wrote: > > Hi, > I am looking to umount the glsuterfs shares that are mounted as part > of gluster driver, when c-vol is being restarted or Ctrl-C'ed (as in > devstack env) or wh

Re: [openstack-dev] Help in re-running openstack

Shiva, Can u tell what exactly u r trying to change in /opt/stack/ ? My guess is that u might be running into stack.sh re-pulling the sources hence overriding ur changes ? Try with OFFLINE=True in localrc (create a localrc file in /opt/stack/ and put OFFLINE=True) and redo stack.sh On Thu, Apr

Re: [openstack-dev] [cinder] the ability about list the available volume back-ends and their capabilities

Hi, Mike: Thanks for your time and your advice. I will contact Avishay in #openstack-cinder tonight. -- zhangleiqiang (Trump) Best Regards > -Original Message- > From: Mike Perez [mailto:thin...@gmail.com] > Sent: Friday, April 04, 2014 1:51 AM > To:

Re: [openstack-dev] ML2 Type driver for supporting network overlays, with more than 4K seg

The blueprint is updated with more information on the requirements and interaction with VDP https://blueprints.launchpad.net/neutron/+spec/netron-ml2-mechnism-driver-for-cisco-dfa-support On Monday, March 31, 2014 12:50 PM, Padmanabhan Krishnan wrote: Hi Mathieu, Thanks for the link. Some s

Re: [openstack-dev] [Neutron] minimal scope covered by third-party testing

Hi Salvatore, On 03/04/2014 14:56, Salvatore Orlando wrote: > Hi Simon, > > > I hope stricter criteria will be enforced for Juno; I personally think > every CI should run at least the smoketest suite for L2/L3 services (eg: > load balancer scenario will stay optional). I had a little thinking

[openstack-dev] Swift ring building..

Hi, I have a question regarding the ring building process in a swift cluster. Many sources online suggest building the rings using ring-builder and scp the generated ring files to all the nodes in the cluster. What I'm trying to understand is if the scp step is just to simplify things, or is it ab

[openstack-dev] [Devstack] add support for ceph

Hello, We had quite a lengthy discussion on this review : https://review.openstack.org/#/c/65113/ about a patch that seb has sent to add ceph support to devstack. The main issues seems to resolve around the fact that in devstack we support only packages that are in the distros and not having to

Re: [openstack-dev] Help in re-running openstack

Hi shiva You can reload the openstack services by following the below steps.. i) Enter into the devstack directry i.e cd devstack ii) Execute rejoin-stackh.sh i.e ./rejoin-stack.sh iii) Press ctrl+a+shift+" iv) Select the appropriate service to restart Please let me know if further issues. Tha

Re: [openstack-dev] [Nova] Hosts within two Availability Zones : possible or not ?

2014-04-04 10:30 GMT+02:00 Sylvain Bauza : > Hi all, > > > > 2014-04-03 18:47 GMT+02:00 Meghal Gosalia : > > Hello folks, >> >> Here is the bug [1] which is currently not allowing a host to be part >> of two availability zones. >> This bug was targeted for havana. >> >> The fix in the bug was m

Re: [openstack-dev] Swift ring building..

Hi, Am 04.04.14 11:14, schrieb Shyam Prasad N: > I have a question regarding the ring building process in a swift cluster. > Many sources online suggest building the rings using ring-builder and > scp the generated ring files to all the nodes in the cluster. > What I'm trying to understand is if t

Re: [openstack-dev] [Heat] [Murano] [Solum] applications in the cloud

Hi Steve, Thomas I'm glad the discussion is so constructive! If we add type interfaces to HOT this may do the job. Applications in AppCatalog need to be portable across OpenStack clouds. Thus if we use some globally-unique type naming system applications could identify their dependencies in unamb

[openstack-dev] 1302376 : bug or feature

Hi all, I've logged a bug in trove. I'm a little unsure if this is a bug or feature. Please have a look at the bug @ https://bugs.launchpad.net/trove/+bug/1302376 and suggest if it is valid. Thanks, Shweta | Consultant Engineering GlobalLogic www.globallogic.com htt

Re: [openstack-dev] 1302376 : bug or feature

Goodday Shweta, it's a definitely a bug, thanks for registering the bug-report. Best regards, Denis Makogon On Fri, Apr 4, 2014 at 1:04 PM, Shweta shweta wrote: > Hi all, > > I've logged a bug in trove. I'm a little unsure if this is a bug or > feature. Please have a look at the bug @ > https

[openstack-dev] [tempest]:Please updated etherpad before adding tempest tests

Hello everyone, This is regarding implementation of blueprint https://blueprints.launchpad.net/tempest/+spec/testcases-expansion-icehouse. As per mentioned in etherpads for this blueprint, please add your name if you are working on any of the items mentioned in the list. Otherwise efforts will

Re: [openstack-dev] Quota Management

On 03/04/14 23:20, Jay Pipes wrote: > On Thu, 2014-04-03 at 14:41 -0500, Kevin L. Mitchell wrote: >> On Thu, 2014-04-03 at 19:16 +, Cazzolato, Sergio J wrote: >>> Jay, thanks for taking ownership on this idea, we are really >>> interested to contribute to this, so what do you think are the next

[openstack-dev] [RFC] Tempest without branches

An interesting conversation has cropped up over the last few days in -qa and -infra which I want to bring to the wider OpenStack community. When discussing the use of Tempest as part of the Defcore validation we came to an interesting question: Why does Tempest have stable/* branches? Does it need

[openstack-dev] [Ironic][Agent]

Hello, everyone, I'd like to involve more people to express their opinions about the way how we are going to run Ironic-python-agent. I mean should we run it with root privileges or not. >From the very beginning agent is supposed to run under ramdisk OS and it is intended to make disk partitionin

Re: [openstack-dev] Swift ring building..

Thanks Christian. That reply covered everything I was seeking to know on this subject. On Fri, Apr 4, 2014 at 3:11 PM, Christian Schwede < christian.schw...@enovance.com> wrote: > Hi, > > Am 04.04.14 11:14, schrieb Shyam Prasad N: > > I have a question regarding the ring building process in a sw

Re: [openstack-dev] [RFC] Tempest without branches

On 04/04/2014 07:37 AM, Sean Dague wrote: An interesting conversation has cropped up over the last few days in -qa and -infra which I want to bring to the wider OpenStack community. When discussing the use of Tempest as part of the Defcore validation we came to an interesting question: Why does

[openstack-dev] [sahara] Icehouse RC1 available

Hello everyone, Sahara published its first Icehouse release candidate today. The list of bugs fixed since feature freeze and the RC1 tarball are available at: https://launchpad.net/sahara/icehouse/icehouse-rc1 Unless release-critical issues are found that warrant a release candidate respin, this

Re: [openstack-dev] Marconi PTL Candidacy

On 03/04/14 17:53 +, Kurt Griffiths wrote: [snip] If elected, my priorities during Juno will include: 1. Operational Maturity: Marconi is already production-ready, but we still have work to do to get to world-class reliability, monitoring, logging, and efficiency. 2. Documentation: During I

Re: [openstack-dev] [heat] Problems with software config and Heat standalone configurations

No problem. Filed here: https://bugs.launchpad.net/heat/+bug/1302578 for continued discussion. -M Kind Regards, Michael D. Elder STSM | Master Inventor mdel...@us.ibm.com | linkedin.com/in/mdelder "Success is not delivering a feature; success is learning h

Re: [openstack-dev] [Ironic][Agent] Ironic-python-agent

Hello Vladimir, I would prefer an agent-less node, meaning the agent is only used under the ramdisk OS to collect hw info, to do firmware updates and to install nodes etc. In this sense, the agent running as root is fine. Once the node is installed, the agent should be out of the picture. I

Re: [openstack-dev] [Oslo][Nova][Heat] Sample config generator issue

On Thu, Apr 3, 2014 at 5:42 PM, Zane Bitter wrote: > On 03/04/14 08:48, Doug Hellmann wrote: >> >> On Wed, Apr 2, 2014 at 9:55 PM, Zane Bitter wrote: >>> >>> We have an issue in Heat where the sample config generator from Oslo is >>> currently broken (see bug #1288586). Unfortunately it turns out

Re: [openstack-dev] [heat] Problems with Heat software configurations and KeystoneV2

Opened in Launchpad: https://bugs.launchpad.net/heat/+bug/1302624 I still have concerns though about the design approach of creating a new project for every stack and new users for every resource. If I provision 1000 patterns a day with an average of 10 resources per pattern, you're looking at

Re: [openstack-dev] [ceilometer] Serveral questions about alarm function of ceilometer

Hi Yuanjing, some pointers inline. 2014-04-03 4:33 GMT+02:00 Yuanjing (D) : > Hi > > I have a requirement of monitoring VMs, if a VM's meter like cpu_util > become too high, then system generate an alarm for this VM with meter > information. > > I have tested alarm function of ceilometer, be

[openstack-dev] Issues with Python Requests

Howdy, Now that swift has aligned with the other projects to use requests in python-swiftclient, we have lost a couple of features. 1. Requests doesn't support expect: 100-continue. This is very useful for services like swift or glance where you want to make sure a request can continue before y

Re: [openstack-dev] [TripleO] reviewer update march

On Thu, Apr 3, 2014 at 7:02 AM, Robert Collins wrote: > Getting back in the swing of things... > > Hi, > like most OpenStack projects we need to keep the core team up to > date: folk who are not regularly reviewing will lose context over > time, and new folk who have been reviewing regularly s

[openstack-dev] [infra][neutron]Requesting consideration of httmock package for test-requirements in Juno

I’d like to get this added to the test-requirements for Neutron. It is a very flexible HTTP mock module that works with the Requests package. It is a decorator that wraps the Request’s send() method and allows easy mocking of responses, etc (w/o using a web server). The bug is: https://bugs.lau

Re: [openstack-dev] Issues with Python Requests

On Apr 4, 2014, at 10:41 AM, Chuck Thier wrote: > Howdy, > > Now that swift has aligned with the other projects to use requests in > python-swiftclient, we have lost a couple of features. > > 1. Requests doesn't support expect: 100-continue. This is very useful for > services like swift or

[openstack-dev] [nova][ironic] BaremetalHostManager unused?

Whilst looking at something unrelated in HostManager, I noticed that HostManager.service_states appears to be unused, and decided to remove it. This seems to have a number of implications: 1. capabilities in HostManager.get_all_host_states will always be None. 2. capabilities passed to host_state_

Re: [openstack-dev] Issues with Python Requests

On Fri, Apr 4, 2014 at 9:44 AM, Donald Stufft wrote: > requests should work fine if you used the event let monkey patch the > socket module prior to import requests. > That's what I had hoped as well (and is what swift-bench did already), but it performs the same if I monkey patch or not. -- Ch

[openstack-dev] [Neutron] Release Notes for Icehouse

Hi all, I think it's important for our developers to publish an official Release Note as other core openstack projects does at the end of Icehouse development cycle, it contains the new features added and upgrade issue to be noticed by the users. any one like to be volunteer to help accomplish it?

Re: [openstack-dev] [Ironic][Agent] Ironic-python-agent

+1 From: Ling Gao [mailto:ling...@us.ibm.com] Sent: Friday, April 04, 2014 10:10 AM To: OpenStack Development Mailing List (not for usage questions) Cc: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Ironic][Agent] Ironic-python-agent Hello Vladimir,

Re: [openstack-dev] Help in re-running openstack

On Fri, Apr 4, 2014 at 3:43 AM, Deepak Shetty wrote: > Shiva, > Can u tell what exactly u r trying to change in /opt/stack/ ? > My guess is that u might be running into stack.sh re-pulling the sources > hence overriding ur changes ? Try with OFFLINE=True in localrc (create a > localrc file in /

Re: [openstack-dev] [Ironic][Agent] Ironic-python-agent

+1 The agent is a tool Ironic is using to take the place of a hypervisor to discover and prepare nodes to recieve workloads. For hardware, this includes more work -- such as firmware flashing, bios configuration, and disk imaging -- all of which must be done in an OOB manner. (This

Re: [openstack-dev] [rally] Tenant quotas can now be updated during a benchmark

Hi Joshua, Quotas will not be expanded during the scenario, they will be updated *prior* the scenario with the requested values as context of this scenario. If values are too low, the scenario will continue to fail. This update does not allow to benchmark quotas update modification time. Regards,

Re: [openstack-dev] [nova][ironic] BaremetalHostManager unused?

Hi Matt! I've looked into this a bit now, too, and don't have a conclusive answer as to how (or even whether) it's working today. Instead, I'd like to point out that Ironic is aiming to deprecate nova.virt.baremetal and nova.scheduler.baremetal_host_manager, in favor of nova.virt.ironic and nova.

Re: [openstack-dev] [Neutron] minimal scope covered by third-party testing

Hi Simon, You are absolutely right in your train of thoughts: unless the third-party CI monitors and vets all the potential changes it cares about there's always a chance something might break. This is why I think it's important that each Neutron third party CI should not only test Neutron changes

Re: [openstack-dev] [Neutron] Release Notes for Icehouse

On Apr 4, 2014, at 11:03 AM, Yaguang Tang mailto:yaguang.t...@canonical.com>> wrote: I think it's important for our developers to publish an official Release Note as other core openstack projects does at the end of Icehouse development cycle, it contains the new features added and upgrade issu

Re: [openstack-dev] [tempest]:Please updated etherpad before adding tempest tests

"Kekane, Abhishek" wrote on 04/04/2014 06:26:58 AM: > This is regarding implementation of blueprint https:// > blueprints.launchpad.net/tempest/+spec/testcases-expansion-icehouse. > > As per mentioned in etherpads for this blueprint, please add your > name if you are working on any of the item

[openstack-dev] [TripleO] [Heat] TripleO Heat Templates and merge.py

Hi All, I was wondering if the time has come to document what exactly are we doing with tripleo-heat-templates and merge.py[1], figure out what needs to happen to move away and raise the necessary blueprints on Heat and TripleO side. (merge.py is a script we use to build the final TripleO Heat te

[openstack-dev] [Climate] Meeting minutes

Hello stackers! Here are our meeting minutes: Minutes: http://eavesdrop.openstack.org/meetings/climate/2014/climate.2014-04-04-15.01.html Minutes (text): http://eavesdrop.openstack.org/meetings/climate/2014/climate.2014-04-04-15.01.txt Log: http://eavesdrop.openstack.org/meetings/climate/2014/cli

Re: [openstack-dev] [keystone] [oslo] Using oslo.cache in keystoneclient.middleware.auth_token

> It appears the current version of oslo.cache is going to bring in quite >a few oslo libraries that we would not want keystone client to depend on >[1]. Moving the middleware to a separate library would solve that. I think it makes a lot of sense to separate out the middleware. Would this be a ne

Re: [openstack-dev] [Ironic][Agent] Ironic-python-agent

On Fri, Apr 4, 2014 at 3:10 PM, Ling Gao wrote: > Hello Vladimir, > I would prefer an agent-less node, meaning the agent is only used > under the ramdisk OS to collect hw info, to do firmware updates and to > install nodes etc. In this sense, the agent running as root is fine. Once > the nod

[openstack-dev] [ceilometer][glance][heat][neutron][nova] Quick fix for "upstream-translation-update Jenkins job failing" (bug 1299349)

tl;dr: $ python clean_po.py PROJECT/locale/ $ git commit The comments on bug 1299349 are already quite long, so apparently this got lost. To save everyone some time, the fix is as easy as above. So what's clean_po.py? Devananda van der Veen (devananda) posted a handy script to fix the issue

[openstack-dev] PTL Voting is now open

Elections are underway and will remain open for you to cast your vote until at least 1300 utc April 11, 2014. We are having elections for Nova, Neutron, Cinder, Ceilometer, Heat and TripleO. If you are a Foundation individual member and had a commit in one of the program's projects[0] over the H

Re: [openstack-dev] [Ironic][Agent]

On Fri, Apr 4, 2014 at 5:19 AM, Vladimir Kozhukalov < vkozhuka...@mirantis.com> wrote: > On the other hand, it is easy to imagine a situation when you want to run > agent on every node of your cluster after installing OS. It could be useful > to keep hardware info consistent (for example, many har

Re: [openstack-dev] [Heat] [Murano] [Solum] applications in the cloud

One thing I'm not seeing handled is cross-app knowledge. From an earlier post: > 1) User selects an app which requires a DB > 2) Murano sees this requirement for DB and do a search in the app > catalog to find all apps which expose this functionality. Murano uses > app package definitions for th

Re: [openstack-dev] Issues with Python Requests

On Apr 4, 2014, at 10:56 AM, Chuck Thier wrote: > On Fri, Apr 4, 2014 at 9:44 AM, Donald Stufft wrote: > requests should work fine if you used the event let monkey patch the socket > module prior to import requests. > > That's what I had hoped as well (and is what swift-bench did already), bu

[openstack-dev] [oslo] incubator open for juno development

The oslo incubator is open for changes scheduled for Juno. Please make sure you have your bugs and blueprints targeted correctly before submitting patches. The libraries are still frozen until we have cross-project unit test jobs working, so please only approve changes related to making those test

Re: [openstack-dev] [keystone] [oslo] Using oslo.cache in keystoneclient.middleware.auth_token

On Fri, Apr 4, 2014 at 10:51 AM, Kurt Griffiths < kurt.griffi...@rackspace.com> wrote: > > It appears the current version of oslo.cache is going to bring in quite > >a few oslo libraries that we would not want keystone client to depend on > >[1]. Moving the middleware to a separate library would s

Re: [openstack-dev] [keystone] [oslo] Using oslo.cache in keystoneclient.middleware.auth_token

On Fri, Apr 4, 2014 at 12:22 PM, Dean Troyer wrote: > On Fri, Apr 4, 2014 at 10:51 AM, Kurt Griffiths > wrote: >> >> > It appears the current version of oslo.cache is going to bring in quite >> >a few oslo libraries that we would not want keystone client to depend on >> >[1]. Moving the middlewar

Re: [openstack-dev] [rally] Tenant quotas can now be updated during a benchmark

Bruno, Btw great idea add benchmark scenarios for quotas as well! Best regards, Boris Pavlovic On Fri, Apr 4, 2014 at 7:28 PM, Bruno Semperlotti < bruno.semperlo...@gmail.com> wrote: > Hi Joshua, > > Quotas will not be expanded during the scenario, they will be updated > *prior* the scenario w

Re: [openstack-dev] Issues with Python Requests

On Fri, Apr 4, 2014 at 11:18 AM, Donald Stufft wrote: > > On Apr 4, 2014, at 10:56 AM, Chuck Thier wrote: > > On Fri, Apr 4, 2014 at 9:44 AM, Donald Stufft wrote: > >> requests should work fine if you used the event let monkey patch the >> socket module prior to import requests. >> > > That's w

[openstack-dev] What's Up Doc? Apr 4 2014

Please take this survey to understand the obstacles to doc contributions. We are very interested in increasing the doc contributions and making our doc processes work well for OpenStack as it scales. I believe we can take actions based on the questions here, please send the link to OpenStack contri

Re: [openstack-dev] [Heat] [Murano] [Solum] applications in the cloud

Excerpts from Stan Lagun's message of 2014-04-04 02:54:05 -0700: > Hi Steve, Thomas > > I'm glad the discussion is so constructive! > > If we add type interfaces to HOT this may do the job. > Applications in AppCatalog need to be portable across OpenStack clouds. > Thus if we use some globally-un

Re: [openstack-dev] [Ironic][Agent]

On April 4, 2014 at 9:12:56 AM, Devananda van der Veen (devananda@gmail.com) wrote: Ironic's responsibility ends where the host OS begins. Ironic is a bare metal provisioning service, not a configuration management service. +1 // jim ___ OpenStack

Re: [openstack-dev] [Ironic][Agent]

> There are lots of configuration management agents already out there (chef? > puppet? salt? ansible? ... the list is pretty long these days...) which you > can bake into the images that you deploy with Ironic, but I'd like to be > clear that, in my opinion, Ironic's responsibility ends where the h

Re: [openstack-dev] [Ironic][Agent]

Excerpts from Vladimir Kozhukalov's message of 2014-04-04 05:19:41 -0700: > Hello, everyone, > > I'd like to involve more people to express their opinions about the way how > we are going to run Ironic-python-agent. I mean should we run it with root > privileges or not. > > From the very beginnin

Re: [openstack-dev] [Ironic][Agent]

>seems that this discussion is splitted in 2 threads Lucas, That's because I added a subject when responded. :-) Ling Gao From: Lucas Alvares Gomes To: "OpenStack Development Mailing List (not for usage questions)" , Date: 04/04/2014 01:16 PM Subject:Re: [openstack-dev]

Re: [openstack-dev] [Ironic][Agent]

> Ironic's responsibility ends where the host OS begins. Ironic is a bare metal provisioning service, not a configuration management service. I agree with the above, but just to clarify I would say that Ironic shouldn't *interact* with the host OS once it booted. Obviously it can still perform

Re: [openstack-dev] [TripleO] [Heat] TripleO Heat Templates and merge.py

Excerpts from Tomas Sedovic's message of 2014-04-04 08:47:46 -0700: > Hi All, > > I was wondering if the time has come to document what exactly are we > doing with tripleo-heat-templates and merge.py[1], figure out what needs > to happen to move away and raise the necessary blueprints on Heat and

Re: [openstack-dev] [Heat] [Murano] [Solum] applications in the cloud

On Fri, Apr 4, 2014 at 9:05 PM, Clint Byrum wrote: > IMO that is not really true and trying to stick all these databases into > one "SQL database" interface is not a use case I'm interested in > pursuing. > Indeed. "Any SQL database" is a useless interface. What I was trying to say is that some

Re: [openstack-dev] [TripleO] reviewer update march

On 3.4.2014 13:02, Robert Collins wrote: Getting back in the swing of things... Hi, like most OpenStack projects we need to keep the core team up to date: folk who are not regularly reviewing will lose context over time, and new folk who have been reviewing regularly should be trusted with

Re: [openstack-dev] [ceilometer][glance][heat][neutron][nova] Quick fix for "upstream-translation-update Jenkins job failing" (bug 1299349)

On 04/04/2014 05:57 PM, Dolph Mathews wrote: > tl;dr: > > $ python clean_po.py PROJECT/locale/ > $ git commit > > The comments on bug 1299349 are already quite long, so apparently this > got lost. To save everyone some time, the fix is as easy as above. So > what's clean_po.py? > > Devananda

Re: [openstack-dev] [Nova] Hosts within two Availability Zones : possible or not ?

I am fine with taking the approach of user passing multiple avail. zones Az1,Az2 if he wants vm to be in (intersection of AZ1 and Az2). It will be more cleaner. But, similar approach should also be used while setting the default_scheduling_zone. Since, we will not be able to add host to multipl

Re: [openstack-dev] [TripleO] reviewer update march

Excerpts from Robert Collins's message of 2014-04-03 04:02:20 -0700: > Getting back in the swing of things... > > Hi, > like most OpenStack projects we need to keep the core team up to > date: folk who are not regularly reviewing will lose context over > time, and new folk who have been review

Re: [openstack-dev] [TripleO] reviewer update march

On 04/03/2014 01:02 PM, Robert Collins wrote: Getting back in the swing of things... Hi, like most OpenStack projects we need to keep the core team up to date: folk who are not regularly reviewing will lose context over time, and new folk who have been reviewing regularly should be trusted

Re: [openstack-dev] [heat] Problems with Heat software configurations and KeystoneV2

Excerpts from Michael Elder's message of 2014-04-04 07:16:55 -0700: > Opened in Launchpad: https://bugs.launchpad.net/heat/+bug/1302624 > > I still have concerns though about the design approach of creating a new > project for every stack and new users for every resource. > > If I provision 100

Re: [openstack-dev] Issues with Python Requests

I think I have worked out the performance issues with eventlet and Requests with most of it being that swiftclient needs to make use of requests.session to re-use connections, and there are likely other areas there that we can make improvements. Now on to expect: 100-continue support, has anyone e

Re: [openstack-dev] [Heat] [TripleO] Better handling of lists in Heat - a proposal to add a map function

On 19/02/14 02:48, Clint Byrum wrote: Since picking up Heat and trying to think about how to express clusters of things, I've been troubled by how poorly the CFN language supports using lists. There has always been the Fn::Select function for dereferencing arrays and maps, and recently we added a

Re: [openstack-dev] Issues with Python Requests

I found https://github.com/kennethreitz/requests/issues/713 """ Lukasa commented a month ago There's been no progress on this, and it's not high on the list of priorities for any of the core de

Re: [openstack-dev] [RFC] Tempest without branches

(easier to insert my questions at top of discussion as they are more general) How would test deprecations work in a branchless Tempest? Right now, there is the discussion on removing the XML tests from Tempest, yet they are still valid for Havana and Icehouse. If they get "removed", will they

Re: [openstack-dev] [TripleO] [Heat] TripleO Heat Templates and merge.py

On 04/04/14 13:58, Clint Byrum wrote: >We could keep roughly the same structure: a separate template for each >OpenStack service (compute, block storage, object storage, ironic, nova >baremetal). We would then use Heat environments to treat each of these >templates as a custom resource (e.g. OS::

[openstack-dev] [TripleO] stable/icehouse branches cut

The stable/icehouse branches for: tripleo-image-elements tripleo-heat-templates tuskar Have been created from the latest tags, which I just tagged and released yesterday. The stable/icehouse branch for tripleo-incubator was cut from the latest sha as of this afternoon (since we don't tag and rel

Re: [openstack-dev] [RFC] Tempest without branches

On 04/04/2014 04:31 PM, Rochelle.RochelleGrober wrote: > (easier to insert my questions at top of discussion as they are more > general) > > > > > > How would test deprecations work in a branchless Tempest? Right now, > there is the discussion on removing the XML tests from Tempest, yet the

[openstack-dev] setting up cross-project unit test jobs for oslo libs

I have submitted a patch to add jobs to run the unit tests of projects using oslo libraries with the unreleased master HEAD version of those libraries, to gate both the project and the library. If you are a PTL or Oslo liaison, and are interested in following its progress, please subscribe: https:/

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

I was just going to let this thread die, because it's clear that we're just approaching this from different philosophical viewpoints, and I think that we need _both_ viewpoints expressed in the community. Trying to change each other's mind would be as pointless as it is futile ;) That said, it

[openstack-dev] [Nova][Trove] Managed Instances Feature

Greetings, I am trying to address an issue from certain perspectives and I think some support from Nova may be needed. Problem Services like Trove use run in Nova Compute Instances. These Services try to provide an integrated and stable platform for which the ³service² can run in a predictable m

Re: [openstack-dev] [heat] Problems with Heat software configurations and KeystoneV2

On 04/04/2014 02:46 PM, Clint Byrum wrote: Excerpts from Michael Elder's message of 2014-04-04 07:16:55 -0700: Opened in Launchpad: https://bugs.launchpad.net/heat/+bug/1302624 I still have concerns though about the design approach of creating a new project for every stack and new users for eve

Re: [openstack-dev] [heat] Problems with Heat software configurations and KeystoneV2

> On Apr 3, 2014, at 8:40 PM, Steve Baker wrote: > >> On 04/04/14 14:05, Michael Elder wrote: >> Hello, >> >> I'm looking for insights about the interaction between keystone and the >> software configuration work that's gone into Icehouse in the last month or >> so. >> >> I've found that

[openstack-dev] [OSSG][OSSN] Heat templates with invalid references allows unintended network access

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Heat templates with invalid references allows unintended network access - --- ### Summary ### Orchestration templates can create security groups to define network access rules. When creating these rules, it is possible to have a rule grant incoming n

[openstack-dev] [Nova][Neutron] API inconsistencies with security groups

Howdy, I'm moving a conversation that has begun on a review to this mailing list as it is perhaps systematic of a larger issue regarding API compatibility (specifically between neutron and nova-networking). Unfortunately these are areas I don't have much experience with so I'm hoping to gain some

[openstack-dev] [openstack] [nova] admin user create instance for another user/tenant

I wonder if there is a way to do the following. I have a user A with admin role in tenant A, and I want to create a VM in/for tenant B as user A. Obviously, I can use A's admin privilege to add itself to tenant B, but I want to avoid that. Based on the policy.json file, it seems doable: https://gi

Re: [openstack-dev] [heat] Problems with Heat software configurations and KeystoneV2

Excerpts from Adam Young's message of 2014-04-04 18:48:40 -0700: > On 04/04/2014 02:46 PM, Clint Byrum wrote: > > Excerpts from Michael Elder's message of 2014-04-04 07:16:55 -0700: > >> Opened in Launchpad: https://bugs.launchpad.net/heat/+bug/1302624 > >> > >> I still have concerns though about t

Re: [openstack-dev] [Neutron] [IPv6] Ubuntu PPA with IPv6 enabled, need help to achieve it

On 04/02/2014 02:33 AM, Martinx - ジェームズ wrote: > Guys! > > I would like to do this: > > > 1- Create and maintain a Ubuntu PPA Archive to host Neutron with IPv6 > patches (from Nephos6 / Shixiong?). > > > Why? > > > Well, I'm feeling that Neutron with native and complete IPv6 support > will b