Re: [openstack-dev] Requests + urllib3 + distro packages

On 10/08/2015 08:39 PM, Robert Collins wrote: This is a bugbear that keeps cropping up and biting us. I'm hoping we can figure out a permanent fix. The problem that occurs is the result of a few interacting things: - requests has very very specific versions of urllib3 it works with. So

Re: [openstack-dev] [devstack] A few questions on configuring DevStack for Neutron

On 10/08/2015 07:13 PM, Christopher Aedo wrote: On Thu, Oct 8, 2015 at 9:38 AM, Sean M. Collins wrote: Please see my response here: http://lists.openstack.org/pipermail/openstack-dev/2015-October/076251.html In the future, do not create multiple threads since responses

Re: [openstack-dev] [tc] naming N and O releases nowish

On 10/07/2015 09:24 AM, Sean Dague wrote: On 10/07/2015 08:57 AM, Thierry Carrez wrote: Sean Dague wrote: We're starting to make plans for the next cycle. Long term plans are getting made for details that would happen in one or two cycles. As we already have the locations for the N and O

Re: [openstack-dev] [Fuel] py.test vs testrepository

On 10/06/2015 10:52 AM, Sebastian Kalinowski wrote: I've already wrote in the review that caused this thread that I do not want to blindly follow rules for using one or another. We should always consider technical requirements. And I do not see a reason to leave py.test (and nobody show me such

Re: [openstack-dev] [Fuel] py.test vs testrepository

On 10/06/2015 06:01 PM, Thomas Goirand wrote: On 10/06/2015 01:14 PM, Yuriy Taraday wrote: On Mon, Oct 5, 2015 at 5:40 PM Roman Prykhodchenko > wrote: Atm I have the following pros. and cons. regarding testrepository: pros.: 1. It’s

Re: [Openstack-operators] [openstack-dev] [neutron] - deprecation of max_fixed_ips_per_port

On 10/04/2015 06:27 AM, Russell Bryant wrote: On 10/02/2015 07:25 PM, Kevin Benton wrote: Hi, There is an option in Neutron called max_fixed_ips_per_port that limits the number of IP addresses that can be assigned to each port. It doesn't appear to have a clear use case since we prevent users

Re: [openstack-dev] [magnum]swarm + compose = k8s?

*waving hands wildly at details* ... I believe that the real win is if Magnum's control plan can integrate the network and storage fabrics that exist in an OpenStack with kube/mesos/swarm. Just deploying is VERY meh. I do not care - it's not interesting ... an ansible playbook can do that in

[openstack-dev] [election][TC] TC Candidacy

Hi! I would like to continue serving on the TC, if you'll have me. Although past performance is no guarantee of future profits, I think it's worth noting that I've been doing this for a while now. I was on the precursor to the TC, the Project Policy Board. Over the time I've been the

Re: [openstack-dev] Compute API (Was Re: [nova][cinder] how to handle AZ bug 1496235?)

ova codebase and couldn't be rather provided by the Heat API. Oh sure, it would perhaps require another endpoint behind the same service, but isn't that better than having another endpoint in Nova ? [1] https://github.com/openstack/governance/blob/master/reference/projects.yaml#L482-L484 I re

Re: [openstack-dev] [Heat] Assumptions regarding extensions to OpenStack api's

On 09/25/2015 02:32 PM, Pratik Mallya wrote: Hello Heat Team, I was wondering if OpenStack Heat assumes that the Nova extensions api would always exist in a cloud? My impression was that since these features are extensions, they may or may not be implemented by the cloud provider and hence Heat

Re: [openstack-dev] [glance][nova] how to upgrade from v1 to v2?

On 09/25/2015 06:37 PM, Chris Hoge wrote: On Sep 25, 2015, at 10:12 AM, Andrew Laski > wrote: I understand that reasoning, but still am unsure on a few things. The direction seems to be moving towards having a requirement that the same

[openstack-dev] Patches coming for .coveragerc

Hey all! Coverage released a 4.0 today (yay!) which changes how the config file is read. As a result, "ignore-errors" in the .coveragerc file needs to be ignore_errors. We're running a script right now to submit a change to every project with this change. The topic will be coverage-v4

Re: [ansible-project] Re: os_volume 404 error

ormal" behavior. I'm sure we'll just find another nugger of normal :) On Sunday, September 20, 2015 at 7:32:22 PM UTC-4, David Shrewsbury wrote: > > Accounts would be most helpful and appreciated. Myself and Monty Taylor do > most of the Ansible and > shade development, so if we

Re: [openstack-dev] openstack-dahboard directory is not created

On 09/18/2015 02:03 PM, OpenStack Mailing List Archive wrote: Link: https://openstack.nimeyo.com/59453/?show=59453#q59453 From: vidya I am trying to create openstack -dashboard on my VM and /usr/share/openstack-dashboard in not create. Please help me what i am missing here.

Re: [openstack-dev] [releases][requirements][keystone]something incompatible with our requirements

On 09/18/2015 03:32 PM, Robert Collins wrote: I know this is terrible timing with the release and all, but constraints updates are failing. This is the first evidence - and it doesn't look like a race to me:

Re: [openstack-dev] [releases][requirements][keystone]something incompatible with our requirements

On 09/18/2015 04:29 PM, Robert Collins wrote: On 19 September 2015 at 08:03, Doug Hellmann wrote: Excerpts from Robert Collins's message of 2015-09-19 07:32:18 +1200: I know this is terrible timing with the release and all, but constraints updates are failing. This is

Re: [openstack-dev] [all][elections] PTL nomination period is now over

On 09/17/2015 04:50 PM, Anita Kuno wrote: On 09/17/2015 08:22 AM, Matt Riedemann wrote: On 9/17/2015 8:25 AM, Tristan Cacqueray wrote: PTL Nomination is now over. The official candidate list is available on the wiki[0]. There are 5 projects without candidates, so according to this

Re: [openstack-dev] [nova][neutron][devstack] New proposed 'default' network model

On 09/15/2015 06:30 PM, Armando M. wrote: On 15 September 2015 at 08:04, Monty Taylor <mord...@inaugust.com <mailto:mord...@inaugust.com>> wrote: Hey all! If any of you have ever gotten drunk with me, you'll know I hate floating IPs more than I hate being stabbed

Re: [openstack-dev] [nova][neutron][devstack] New proposed 'default' network model

On 09/15/2015 06:16 PM, Armando M. wrote: On 15 September 2015 at 08:27, Mike Spreitzer <mspre...@us.ibm.com <mailto:mspre...@us.ibm.com>> wrote: Monty Taylor <mord...@inaugust.com <mailto:mord...@inaugust.com>> wrote on 09/15/2015 11:04:07 AM: > a) an

Re: [openstack-dev] [nova][neutron][devstack] New proposed 'default' network model

On 09/15/2015 08:28 PM, Matt Riedemann wrote: On 9/15/2015 10:27 AM, Mike Spreitzer wrote: Monty Taylor <mord...@inaugust.com> wrote on 09/15/2015 11:04:07 AM: > a) an update to python-novaclient to allow a named network to be passed > to satisfy the "you have more

Re: [openstack-dev] [nova][neutron][devstack] New proposed 'default' network model

ivity? Surely everyone is entitled to his/her opinion, but I don't honestly believe these are fair statements to make. The original statement by Monty Taylor is clear to me: I wish to boot an instance that is on a public network and reachable without madness. As of toda

[openstack-dev] [nova][neutron][devstack] New proposed 'default' network model

Hey all! If any of you have ever gotten drunk with me, you'll know I hate floating IPs more than I hate being stabbed in the face with a very angry fish. However, that doesn't really matter. What should matter is "what is the most sane thing we can do for our users" As you might have seen

Re: [openstack-dev] [glance] proposed priorities for Mitaka

On 09/15/2015 03:13 PM, stuart.mcla...@hp.com wrote: After having some conversations with folks at the Ops Midcycle a few weeks ago, and observing some of the more recent email threads related to glance, glance-store, the client, and the API, I spent last week contacting a few of you

Re: [openstack-dev] [glance] proposed priorities for Mitaka

On 09/15/2015 07:09 PM, stuart.mcla...@hp.com wrote: I've been looking into the existing task-based-upload that Doug mentions: can anyone clarify the following? On a default devstack install you can do this 'task' call: http://paste.openstack.org/show/462919 Yup. That's the one. as an

Re: [openstack-dev] [glance] proposed priorities for Mitaka

On 09/14/2015 02:41 PM, Flavio Percoco wrote: On 14/09/15 08:10 -0400, Doug Hellmann wrote: After having some conversations with folks at the Ops Midcycle a few weeks ago, and observing some of the more recent email threads related to glance, glance-store, the client, and the API, I spent last

Re: [openstack-dev] [glance] proposed priorities for Mitaka

On 09/15/2015 02:06 AM, Clint Byrum wrote: Excerpts from Doug Hellmann's message of 2015-09-14 13:46:16 -0700: Excerpts from Clint Byrum's message of 2015-09-14 13:25:43 -0700: Excerpts from Doug Hellmann's message of 2015-09-14 12:51:24 -0700: Excerpts from Flavio Percoco's message of

Re: [openstack-dev] [glance] tasks (following "proposed priorities for Mitaka")

On 09/14/2015 04:58 PM, Brian Rosmaita wrote: Apologies for forking the thread, but there was way too much in Doug's email (and Flavio's response) and I only want to make a few points about tasks. Please read Doug's original email and Flavio's reply at some point, preferably before you read

Re: [openstack-dev] OpenStack support for Amazon Concepts - was Re: cloud-init IPv6 support

On 09/05/2015 06:19 PM, Sean M. Collins wrote: On Fri, Sep 04, 2015 at 04:20:23PM EDT, Kevin Benton wrote: Right, it depends on your perspective of who 'owns' the API. Is it cloud-init or EC2? At this point I would argue that cloud-init is in control because it would be a large undertaking to

[openstack-dev] This is what disabled-by-policy should look like to the user

mordred@camelot:~$ neutron net-create test-net-mt Policy doesn't allow create_network to be performed. Thank you neutron. Excellent job. Here's what that looks like at the REST layer: DEBUG: keystoneclient.session RESP: [403] date: Fri, 04 Sep 2015 13:55:47 GMT connection: close content-type:

Re: [openstack-dev] This is what disabled-by-policy should look like to the user

On 09/04/2015 10:55 AM, Morgan Fainberg wrote: On Sep 4, 2015, at 07:04, Monty Taylor <mord...@inaugust.com> wrote: mordred@camelot:~$ neutron net-create test-net-mt Policy doesn't allow create_network to be performed. Thank you neutron. Excellent job. Here's what that look

Re: [ansible-project] Re: Ansible 2.0 os_server 404 image not found

Sorry for your troubles. The problem is almost certianly in the v1/v2 version detection. I think we can do better for you here. However, in the mean time - would you mind trying something to test a hypothesis? Make a ~/.config/openstack/clouds.yaml with: clouds: metacloud: auth:

Re: [openstack-dev] This is what disabled-by-policy should look like to the user

On 09/04/2015 01:42 PM, John Griffith wrote: On Fri, Sep 4, 2015 at 11:35 AM, Mathieu Gagné <mga...@internap.com> wrote: On 2015-09-04 12:50 PM, Monty Taylor wrote: On 09/04/2015 10:55 AM, Morgan Fainberg wrote: Obviously the translation of errors would be more difficult if the en

[Yahoo-eng-team] [Bug 1491512] [NEW] Behavior change with latest nova paste config

Public bug reported: http://logs.openstack.org/55/219655/1/check/gate-shade-dsvm-functional- nova/1154770/console.html#_2015-09-02_12_10_56_113 This started failing about 12 hours ago. Looking at it with Sean, we think it's because it actually never worked, but nova was failing silent before.

[Yahoo-eng-team] [Bug 1491511] [NEW] Behavior change with latest nova paste config

Public bug reported: http://logs.openstack.org/55/219655/1/check/gate-shade-dsvm-functional- nova/1154770/console.html#_2015-09-02_12_10_56_113 This started failing about 12 hours ago. Looking at it with Sean, we think it's because it actually never worked, but nova was failing silent before.

[Yahoo-eng-team] [Bug 1491579] [NEW] against all sanity, nova needs to work around broken public clouds

Public bug reported: The version listing endpoint is a clearly a giant security risk, so the intrepid operators of Rackspace, HP, Dreamhost, Auro and RunAbove have all decided, in their infinite wisdom and deference to magical ponies that BLOCKING it is a great idea. Luckily, a non-zero number

Re: [openstack-dev] [api] [wsme] [ceilometer] Replacing WSME with _____ ?

On 08/28/2015 08:32 AM, Julien Danjou wrote: On Fri, Aug 28 2015, Chris Dent wrote: This morning I kicked off a quick spec for replacing WSME in Ceilometer with ... something: https://review.openstack.org/#/c/218155/ This is because not only is WSME not that great, it also results in

Re: [openstack-dev] [api] [wsme] [ceilometer] Replacing WSME with _____ ?

On 08/28/2015 08:32 AM, Julien Danjou wrote: On Fri, Aug 28 2015, Chris Dent wrote: This morning I kicked off a quick spec for replacing WSME in Ceilometer with ... something: https://review.openstack.org/#/c/218155/ This is because not only is WSME not that great, it also results in

[ansible-project] Re: os_server module

Yeah - if you're v3 passing in domain is important. When you add user_domain_id and project_domain_id - what error do you get? (you have to pass in both) On Friday, August 28, 2015 at 12:19:16 AM UTC-7, Antoine Voiry wrote: All, I am facing something strange with the OS_SERVER module. Also

Re: [openstack-dev] [api] [wsme] [ceilometer] Replacing WSME with _____ ?

On 08/28/2015 07:36 AM, Lucas Alvares Gomes wrote: Hi, If you just want to shoot the breeze please respond here. If you have specific comments on the spec please response there. I have been thinking about doing it for Ironic as well so I'm looking for options. IMHO after using WSME I would

Re: [openstack-dev] [Neutron] netaddr and abbreviated CIDR format

On 08/21/2015 03:33 PM, Jay Pipes wrote: On 08/21/2015 02:34 PM, Sean M. Collins wrote: So - the tl;dr is that I don't think that we should accept inputs like the following: x - 192 x/y - 10/8 x.x/y - 192.168/16 x.x.x/y - 192.168.0/24 which are equivalent to:: x.0.0.0/y -

Re: [openstack-dev] [Cinder] A possible solution for HA Active-Active

On 08/01/2015 03:40 AM, Mike Perez wrote: On Fri, Jul 31, 2015 at 8:56 AM, Joshua Harlow harlo...@outlook.com wrote: ...random thought here, skip as needed... in all honesty orchestration solutions like mesos (http://mesos.apache.org/assets/img/documentation/architecture3.jpg), map-reduce

Re: [openstack-dev] OPENSTACK with CEPH storage backend cant down size an instance

On 07/24/2015 12:47 PM, Clint Byrum wrote: Excerpts from James Galvin's message of 2015-07-24 09:08:36 -0700: Hi All I am having some trouble with down sizing an instance, I can resize the instance from say small flavour to medium flavour but when trying to resize the instance back from

Re: [openstack-dev] [all] Setting epoch in setup.cfg??

On 07/14/2015 11:08 AM, Ian Cordasco wrote: On 7/13/15, 16:19, Joshua Harlow harlo...@outlook.com wrote: Ian Cordasco wrote: On 7/13/15, 15:09, Dave Walkerem...@daviey.com wrote: On 13 Jul 2015 8:52 pm, Ian Cordascoian.corda...@rackspace.com wrote: On 7/13/15, 03:38, Thierry

[openstack-dev] OpenStack Mitaka (三鷹) - Our next release name has been selected

Hi everybody! Ok. There is nothing more actually useful I can say that isn't in the subject line. As I mentioned previously, the preliminary results from our name election are here: http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_4983776e190c8dbc As you are all probably aware by now, as a

Re: [openstack-dev] [testing] moving testrepository *outside* the tox venv

On 07/10/2015 07:19 PM, Robert Collins wrote: On 10 July 2015 at 01:59, Morgan Fainberg morgan.fainb...@gmail.com wrote: Or a database per python major version (or at least gracefully handle the incompatibility). So that would partition the data, and the whole point of test *repository* is

Re: [Openstack] [openstack-community] [openstack-dev] OpenStack Meiji (明治) - Our next release name has been selected

to anything. Cheers Tristan *From:* Jaesuk Ahn [mailto:bluejay@gmail.com] *Sent:* Wednesday, 8 July 2015 2:41 PM *To:* OpenStack Development Mailing List; Openstack Users; Monty Taylor; Community User Groups, OpenStack *Subject:* Re: [openstack-community] [openstack-dev] OpenStack

[Openstack] Rescinding the M name decision

Hi everyone! In light of issues raised concerning the initially selected name for the M release (Meiji), that name will not be used. It turns out fully open community and fully inclusive collaboration is a hard thing to get right. On the one hand, we do not want to exclude anyone's input or

[openstack-dev] OpenStack Meiji (明治) - Our next release name has been selected

Hi everybody! Ok. There is nothing more actually useful I can say that isn't in the subject line. As I mentioned previously, the preliminary results from our name election are here: http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_4983776e190c8dbc As a follow on step, the OpenStack Foundation

[Openstack] OpenStack Meiji (明治) - Our next release name has been selected

Hi everybody! Ok. There is nothing more actually useful I can say that isn't in the subject line. As I mentioned previously, the preliminary results from our name election are here: http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_4983776e190c8dbc As a follow on step, the OpenStack Foundation

Re: [openstack-dev] [TripleO] diskimage-builder 1.0.0

On 06/29/2015 08:44 AM, Gregory Haynes wrote: Hello all, DIB has come a long way and we seem to have a fairly stable interface for the elements and the image creation scripts. As such, I think it's about time we commit to a major version release. Hopefully this can give our users the

Re: [openstack-dev] [cinder][glance][nova] Python 3 coming!

On 06/26/2015 04:26 AM, Victor Stinner wrote: Hi, The Python 3.4 gate (py34) of cinder, glance and nova just became voting. You now have to write Python code compatible with Python 2.7 and 3.4. WOOHOO! Well done! If the py34 check job fails on your patch, you may try to rebase it to get

Re: [openstack-dev] [all] Any other downstream developers having problems with pbr?

On 06/26/2015 07:24 AM, Clark Boylan wrote: On Fri, Jun 26, 2015, at 04:01 AM, Matthew Booth wrote: I wrote this: https://review.openstack.org/#/c/195983/1/tools/de-pbr.py,cm Ideally we'd fix PBR, but this seems to be expected behaviour. Thoughts? Use the PBR_VERSION env var [1], it exists

Re: [openstack-dev] Scheduler hints, API and Objects

On 06/25/2015 10:22 AM, Andrew Laski wrote: I have been growing concerned recently with some attempts to formalize scheduler hints, both with API validation and Nova objects defining them, and want to air those concerns and see if others agree or can help me see why I shouldn't worry.

Re: [openstack-dev] [api][nova][ironic] Microversion API HTTP header

On 06/25/2015 01:35 PM, Devananda van der Veen wrote: Sean's point and Dmitri's are similar. There are APIs for projects which do not have official team or program names. And some teams may produce more than one forward-facing service. Naming the API based in the team name doesn't make

Re: [openstack-dev] [devstack] apache wsgi application support

On 06/24/2015 02:05 PM, Sean Dague wrote: On 06/24/2015 01:51 PM, Brant Knudson wrote: On Wed, Jun 24, 2015 at 7:27 AM, Chris Dent chd...@redhat.com mailto:chd...@redhat.com wrote: On Wed, 24 Jun 2015, Sean Dague wrote: On 06/24/2015 07:57 AM, Chris Dent wrote:

Re: [openstack-dev] [cinder][stable] Cinder client broken in Juno

On 06/23/2015 11:49 AM, Mike Perez wrote: There was a bug raised [1] from some large deployments that the Cinder client 1.2.0 and beyond is not working because of version discovery. Unfortunately it's not taking into account of deployments that have a proxy. Cinder client asks Keystone to

Re: [openstack-dev] [Fuel][Fuel-library] Using librarian-puppet to manage upstream fuel-library modules

On 06/23/2015 01:51 PM, Alex Schultz wrote: Hello everyone, I took some time this morning to write out a document[0] that outlines one possible ways for us to manage our upstream modules in a more consistent fashion. I know we've had a few emails bouncing around lately around this topic of

Re: [openstack-dev] [all][requirements] requirements reviews falling behind

On 06/22/2015 02:49 PM, Doug Hellmann wrote: We have quite a long list of patches to the openstack/requirements repository, many of which are straightforward changes to increase the minimums for libraries we develop within the community (meaning we are holding up projects from using new

[Openstack] M Naming Poll ended - results still need to clear legal

Hey all! The M naming poll has concluded. I'd say and the winner is ... except we still need to get the winning choice(s) vetted for legal entanglements. Feel free to go and look at the results, they are publicly available - but please DON'T start making t-shirts or having parties (ok, have as

[openstack-dev] M Naming Poll ended - results still need to clear legal

Hey all! The M naming poll has concluded. I'd say and the winner is ... except we still need to get the winning choice(s) vetted for legal entanglements. Feel free to go and look at the results, they are publicly available - but please DON'T start making t-shirts or having parties (ok, have as

Re: [openstack-dev] [Stackalytics] Complementary projects

On 06/19/2015 11:40 AM, Jay Pipes wrote: On 06/19/2015 10:31 AM, Joe Gordon wrote: On Jun 19, 2015 3:56 PM, Jay Pipes jaypi...@gmail.com mailto:jaypi...@gmail.com wrote: On 06/19/2015 09:19 AM, Ilya Shakhat wrote: Some reasons of having complementary projects in Stackalytics: *

Re: [openstack-dev] [Neutron][DevStack] Standing on the shoulders of giants - Linux Bridge testing at the gate

On 06/19/2015 03:20 AM, Sean M. Collins wrote: Hi, I wanted to give a quick update on the new experimental job for testing the Linux Bridge mechanism driver for Neutron. I believe that there is only one patch that needs to be merged, in order to get the job to a point where we could move

Re: [openstack-dev] [all] setup.py executable bit

On 06/17/2015 03:24 PM, Ian Cordasco wrote: On 6/17/15, 13:53, Jeremy Stanley fu...@yuggoth.org wrote: On 2015-06-17 14:47:48 -0400 (-0400), Doug Hellmann wrote: +1 both to using -x and to removing the shebang. Agreed. We don't want anyone directly invoking this file as an executable

Re: [openstack-dev] [puppet][murano] Developing puppet module for Murano

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 06/17/2015 08:53 AM, Emilien Macchi wrote: Hi Serg, On 06/17/2015 05:35 AM, Serg Melikyan wrote: Hi Emilien, I would like to answer your question regarding stackforge/puppet-murano repository asked in different thread: Someone from

[openstack-dev] Starting the M Release Name Poll

Hey everybody! I've started the poll for the M release. By now, you should have gotten an email with a link to the vote. If you did not and think that you should have, please let me know (directly, not to the mailing list please) and I can re-send and/or fix as necessary. Please remember that

[openstack-dev] Please Merge patches titled Merge Tag ...

Hi! When we cut a release, we do so on a branch. This means that the tag for the release is not in the master branch of the repo, which means git can produce unexpected output in some cases. To solve this, we have the proposal bot propose a null-merge of the tag back in to master. The patch in

Re: [openstack-dev] [Ironic] When to bump the microversion?

On 06/04/2015 11:27 AM, Dmitry Tantsur wrote: On 06/04/2015 05:03 PM, Sean Dague wrote: On 06/04/2015 10:50 AM, Dmitry Tantsur wrote: On 06/04/2015 04:40 PM, Ruby Loo wrote: Hi, In Kilo, we introduced microversions but it seems to be a work-in-progress. There is an effort now to add

[Openstack] Release naming for M open for nominations

Hey everyone! It's time to pick a name for the M release. If you have a name you'd like us to vote on, please add it here: https://wiki.openstack.org/wiki/Release_Naming/M_Proposals The nominations will be open until 2015-06-07 23:59:59 UTC. If you don't remember the rules, they're here:

[openstack-dev] Release naming for M open for nominations

Hey everyone! It's time to pick a name for the M release. If you have a name you'd like us to vote on, please add it here: https://wiki.openstack.org/wiki/Release_Naming/M_Proposals The nominations will be open until 2015-06-07 23:59:59 UTC. If you don't remember the rules, they're here:

Re: [openstack-dev] [nova] usefulness of device parameter at volumeAttachment

On 05/28/2015 11:25 PM, Jay Pipes wrote: On 05/26/2015 03:13 AM, Daniel P. Berrange wrote: On Sat, May 23, 2015 at 11:00:32AM +0200, Géza Gémes wrote: Hi, When someone calls nova volume-attach or the block-device-mapping parameter at boot, it is possible to specify a device name for the

Re: [openstack-dev] [Ironic] [TC] Discussion: changing Ironic's release model

On 05/28/2015 12:41 PM, Devananda van der Veen wrote: Hi all, tl;dr; At the summit, the Ironic team discussed the challenges we've had with the current release model and came up with some ideas to address them. I had a brief follow-up conversation with Doug and Thierry, but I'd like this

Re: [openstack-dev] [new][app-catalog] App Catalog next steps

On 05/27/2015 06:35 PM, Keith Bray wrote: Joe, regarding apps-catalog for any app deployable on OpenStack (regardless of deployment technology), my two cents is that is a good idea. I also believe, however, that the app-catalog needs to evolve first with features that make it super simple to

Re: [openstack-dev] [nova][api] Allow passing body for more API methods

On 05/11/2015 02:05 PM, Dean Troyer wrote: On Mon, May 11, 2015 at 11:44 AM, Rosa, Andrea (HP Cloud Services) andrea.r...@hp.com wrote: Agreed. Violating the HTTP spec is something that should be avoided. Actually it is not violating the HTTP spec, from RFC: A payload within a DELETE

Re: [openstack-dev] [all] who is the ptl of trove?

On 05/08/2015 03:45 AM, Nikhil Manchanda wrote: Comments and answers inline. Li Tianqing writes: [...] 1) why we put the trove vm into user's tenant, not the trove's tenant? User can login on that vm, and that vm must connect to rabbitmq. It is quite insecure. what's

Re: [openstack-dev] [puppet][operators] How to specify Keystone v3 credentials?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 05/04/2015 08:47 PM, Emilien Macchi wrote: On 05/04/2015 10:37 PM, Rich Megginson wrote: On 05/04/2015 07:52 PM, Mathieu Gagné wrote: On 2015-05-04 9:15 PM, Rich Megginson wrote: On 05/04/2015 06:03 PM, Mathieu Gagné wrote: On 2015-05-04

Re: [openstack-dev] [pbr] regular releases, and path to 1.0

On 05/04/2015 03:53 PM, Robert Collins wrote: Hi, I'd like to talk about how often we can and should release pbr, and what criteria we should use for 1.0. tl;dr: release weekly [outside of organisation-wide-freezes], do a 1.0 immediately. pbr, like all our libraries affects everything

Re: [openstack-dev] [pbr] regular releases, and path to 1.0

On 05/04/2015 04:15 PM, Robert Collins wrote: On 5 May 2015 at 08:12, Monty Taylor mord...@inaugust.com wrote: On 05/04/2015 03:53 PM, Robert Collins wrote: I'm fine with that in principle - I tend to release personal libraries pretty much as soon as something interesting hits them. I have

Re: [openstack-dev] [TC][Keystone] Rehashing the Pecan/Falcon/other WSGI debate

On 05/01/2015 09:16 PM, Jamie Lennox wrote: Hi all, At around the time Barbican was applying for incubation there was a discussion about supported WSGI frameworks. From memory the decision at the time was that Pecan was to be the only supported framework and that for incubation Barbican

Re: [OpenStack-Infra] Questions with respect to packaging

On 04/29/2015 02:19 AM, Steve Kowalik wrote: On 29/04/15 04:41, Monty Taylor wrote: On 04/28/2015 02:02 PM, Clark Boylan wrote: On Mon, Apr 27, 2015, at 11:13 PM, Steve Kowalik wrote: [snip] * Decide if we host full upstream sources, or if we point at a remote site with tarballs

Re: [openstack-dev] [swift] Go! Swift!

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 04/30/2015 08:06 PM, John Dickinson wrote: On Apr 30, 2015, at 9:52 AM, Jay Pipes jaypi...@gmail.com wrote: On 04/30/2015 12:40 PM, John Dickinson wrote: Swift is a scalable and durable storage engine for storing unstructured data. It's

Re: [OpenStack-Infra] PuppetBoard

On 04/26/2015 08:08 PM, Spencer Krum wrote: Hi All, The primary maintainer of puppetboard is stepping aside: https://github.com/puppet-community/puppetboard/issues/132. We use puppetboard to display facts from machines and reports of puppet runs. We can expect to continue to have this need

Re: [openstack-dev] [magnum] New fedora 21 Atomic images available for testing

On 04/26/2015 02:21 PM, Gregory Haynes wrote: Excerpts from Steven Dake (stdake)'s message of 2015-04-23 23:27:00 +: Hi folks, I have spent the last couple of days trying to bring some sanity to the image building process for Magnum. I have found a tool which the Atomic upstream

Re: [openstack-dev] [pbr] support for 'python setup.py install'

On 04/25/2015 09:49 AM, Jeremy Stanley wrote: On 2015-04-25 12:12:15 +1200 (+1200), Robert Collins wrote: [...] I'd like to make that a little more official: - put it in our docs - stop testing python setup.py install. [...] And emit a clear error message? (Even if that just means

Re: [openstack-dev] [pbr] support for 'python setup.py install'

On 04/24/2015 08:12 PM, Robert Collins wrote: In our pbr integration tests we ensure that 'python setup.py install' works, as well as ensuring that 'pip install' works. But see http://lists.openstack.org/pipermail/openstack-dev/2013-September/015525.html - for the last 18 months in pbr we've

Re: [openstack-dev] [pbr] support for 'python setup.py install'

April 2015 at 15:27, Monty Taylor mord...@inaugust.com wrote: On 04/25/2015 09:49 AM, Jeremy Stanley wrote: On 2015-04-25 12:12:15 +1200 (+1200), Robert Collins wrote: [...] I'd like to make that a little more official: - put it in our docs - stop testing python setup.py install

Re: [openstack-dev] [pbr] support for 'python setup.py install'

On 04/25/2015 11:46 AM, Monty Taylor wrote: On 04/25/2015 11:33 AM, Dave Walker wrote: I'm not going to pretend it is graceful... but is there a situation where _ isn't correct? Ooh. This is a worthy avenue to explore ... Ok. After some chatting with fungi in IRC - I've got this: https

Re: [openstack-dev] [all] Question for the TC candidates

On 04/24/2015 06:28 PM, David Medberry wrote: On Fri, Apr 24, 2015 at 2:14 AM, Chris Dent chd...@redhat.com wrote: What can and should the TC at large, and you specifically, do to ensure quality improves for the developers, end-users and operators of OpenStack as a full system, both as a

Re: [openstack-dev] [Nova][Neutron] Linuxbridge as the default in DevStack [was: Status of the nova-network to Neutron migration work]

On 04/18/2015 10:44 AM, Fox, Kevin M wrote: Replying inline. -Original Message- From: Monty Taylor [mailto:mord...@inaugust.com] Sent: Friday, April 17, 2015 7:53 PM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Nova][Neutron] Linuxbridge as the default

Re: [openstack-dev] [Nova][Neutron] Linuxbridge as the default in DevStack [was: Status of the nova-network to Neutron migration work]

On 04/17/2015 06:48 PM, Rochelle Grober wrote: I know the DevStack issue seems to be solved, but I had to respond.inline From: Fox, Kevin M [mailto:kevin@pnnl.gov] Sent: Friday, April 17, 2015 12:28 To: OpenStack Development Mailing List (not for usage questions) Subject: Re:

Re: [openstack-dev] [wsme] [ironic] [ceilometer] [magnum] [kite] [tuskar] WSME unmaintained ?

On 04/16/2015 07:41 AM, Lucas Alvares Gomes wrote: Hi, We have a couple of Openstack projects that uses WSME for their REST APIs[1], but WSME project looks abandoned. The review stats are not good, for the last 40 days the project didn't have a single review from a core reviewer[2], the

Re: [openstack-dev] [all] QPID incompatible with python 3 and untested in gate -- what to do?

On 04/14/2015 08:21 PM, Chris Dent wrote: On Tue, 14 Apr 2015, Sean Dague wrote: It's time to be honest about the level of support that comes with those other backends, deprecate the plugability, and move on to more interesting problems. We do have plenty of them to solve. :) Perhaps in

Re: [openstack-dev] [all] QPID incompatible with python 3 and untested in gate -- what to do?

On 04/14/2015 01:22 PM, Clint Byrum wrote: Hello! There's been some recent progress on python3 compatibility for core libraries that OpenStack depends on[1], and this is likely to open the flood gates for even more python3 problems to be found and fixed. Recently a proposal was made to make

Re: [openstack-dev] [all][pbr] splitting our deployment vs install dependencies

On 04/12/2015 08:01 PM, James Polley wrote: On Mon, Apr 13, 2015 at 9:12 AM, Monty Taylor mord...@inaugust.com wrote: On 04/12/2015 06:43 PM, Robert Collins wrote: Right now we do something that upstream pip considers wrong: we make our requirements.txt be our install_requires. Upstream

Re: [openstack-dev] [all][pbr] splitting our deployment vs install dependencies

On 04/12/2015 06:43 PM, Robert Collins wrote: Right now we do something that upstream pip considers wrong: we make our requirements.txt be our install_requires. Upstream there are two separate concepts. install_requirements, which are meant to document what *must* be installed to import

Re: [openstack-dev] [OpenStack-docs] What's Up Doc? Apr 10 2015

an official installation guide; no need to expose newbies including myself to the complexity of v2. Bernd -Original Message- From: Monty Taylor [mailto:mord...@inaugust.com] Sent: Sunday, April 12, 2015 6:22 AM To: OpenStack Development Mailing List (not for usage questions); openstack-d

Re: [openstack-dev] What's Up Doc? Apr 10 2015

Sorry for top posting - I wasn't subscribed to the doc list before clarkb told me about this thread. Warning ... rage coming ... if you don't want to read rage on a Saturday, I recommend skipping this email. a) There may be a doc bug here, but I'm not 100% convinced it's a doc bug - I'll try to

[OpenStack-Infra] A proposal to use phabricator for issue tracking

As a follow up to my previous email about thinking about ceasing to use storyboard, I have done some work towards investigating using phabricator. phabricator came out of Facebook, but has been spun out completely and is now managed as an Open Source project. There is a company that has formed

Re: [OpenStack-Infra] A proposal to use phabricator for issue tracking

On 04/03/2015 11:54 AM, Sean Dague wrote: On 04/03/2015 11:00 AM, Monty Taylor wrote: As a follow up to my previous email about thinking about ceasing to use storyboard, I have done some work towards investigating using phabricator. phabricator came out of Facebook, but has been spun out

Re: [OpenStack-Infra] A proposal to use phabricator for issue tracking

On 04/03/2015 12:06 PM, Jeremy Stanley wrote: On 2015-04-03 11:54:00 -0400 (-0400), Sean Dague wrote: [...] 2) is there an event stream of changes (either real time or rss) that can be consumed by said tools? Having the change stream would be really helpful. Which relates to a feature

Re: [openstack-dev] [Infra] Use of heat for CI of OpenStack

On 04/03/2015 08:55 AM, Maish Saidel-Keesing wrote: I was wondering.. Is the OpenStack CI/CD Infra using Heat in any way? Do the commits trigger a new build of DevStack/OpenStack that is based on a Heat Template or just the provisioning of a regular instance and then deployment of code on

<    1   2   3   4   5   6   7   8   9   10   >