Re: [openstack-dev] [api] [Nova] [Ironic] [Magnum] Microversion guideline in API-WG

On 06/04/2015 08:58 AM, Xu, Hejie wrote: Hi, guys, I’m working on adding Microversion into the API-WG’s guideline which make sure we have consistent Microversion behavior in the API for user. The Nova and Ironic already have Microversion implementation, and as I know Magnum _https://review.openst

Re: [openstack-dev] [puppet] [fuel] more collaboration request

Zane, Backing the rules with incentives is very important, thanks for bringing it up! This is exactly why I'm trying to be conservative about how much upstream integration overhead Fuel team can commit to: make it too burdensome and it will fizzle out. On the other hand, unintrusive and increment

Re: [openstack-dev] [Neutron] Quota enforcement

>I would kindly ask our glorious drivers team if they're ok with me submitting a spec in the shorter format approved for Liberty without going through the RFE process, as the spec is however in the Kilo backlog. +1! >Do these kinds of test even make sense? And are they feasible at all? I doubt we

Re: [openstack-dev] [Magnum] TLS Support in Magnum

Hi, Tom 2015年6月16日(火) 3:00 Tom Cammann : > > At the summit we talked about using Magnum as a CA and signing the > certificates, and we seemed to have some consensus about doing this with > the > possibility of using Anchor. This would take a lot of the onus off of > the user to > fiddle around wi

Re: [openstack-dev] [trove]Put all alternativeconfigurationsin default trove.conf

Thanks @amrith I found out the problem. Our code base is different and these files should be generated by function "_prepare_file_and_userdata". It explains why we should not set "datastore_manager" in guestagent.conf and why it works for you. It makes it less like a configuration file. Becu

Re: [openstack-dev] [Solum] Why do app names have to be unique?

I think app names should be unique per tenant. My opinion is that this should be solums default behavior and does not require an extra setting in the config file. I feel the pain of non unique names when I play with my own vagrant environment and deploy multiple 'test' apps. To identify the rig

Re: [openstack-dev] [Mistral] Proposal for the Resume Feature

+1, I just have one question. Do we want to able resume for WF in error state? I mean isn't real "resume" it should be more of a rerun, don't you think? So in an error state we will create new executor and just re run it Thanks Limor -Original Message- From: Lingxian Kong [mailto:anlin.

Re: [openstack-dev] [Solum] Should logs be deleted when we delete an app?

I agree, users should have a mechanism to keep logs around. I implemented the logs deletion feature after we got a bunch of requests from users to delete logs once they delete an app, so they don't get charged for storage once the app is deleted. My implementation deletes the logs by default an

Re: [openstack-dev] [designate] and [lbaas] - GSLB API and backend support

Hi all, We don’t have a rough draft API doc yet, so I’m suggesting that we postpone tomorrow morning’s meeting until next week. Does anyone have any other agenda items, or want the meeting tomorrow? Thanks, doug > On Jun 2, 2015, at 10:52 AM, Doug Wiegley > wrote: > > Hi all, > > The init

Re: [openstack-dev] [javascript] [horizon] [merlin] [refstack] Javascript Linting

Sorry, wrong patch. That one added the style requirement to the project contribution guidelines. This is the one that added the .jscsrc config: https://review.openstack.org/#/c/185725/ On Tue, 16 Jun 2015 at 14:21 Richard Jones wrote: > JSCS in Horizon has been extended with the John Papa style

Re: [openstack-dev] [javascript] [horizon] [merlin] [refstack] Javascript Linting

On 16 June 2015 at 16:21, Richard Jones wrote: > JSCS in Horizon has been extended with the John Papa style guidelines to > enforce consistent angularjs code style*. It's no longer just a findbug > tool. I don't have time to investigate - can ESLint perform the same role > for Horizon? Yes - http

Re: [openstack-dev] [javascript] [horizon] [merlin] [refstack] Javascript Linting

JSCS in Horizon has been extended with the John Papa style guidelines to enforce consistent angularjs code style*. It's no longer just a findbug tool. I don't have time to investigate - can ESLint perform the same role for Horizon? Current Horizon activity involves a whole lot of bringing code int

Re: [openstack-dev] [Solum] Should logs be deleted when we delete an app?

Regardless of what the API defaults to, could we have the CLI prompt/warn so that the user easily knows that both options exist? Is there a precedent within OpenStack for a similar situation? E.g. > solum app delete MyApp Do you want to also delete your logs? (default is Yes): [YES/no

Re: [openstack-dev] [Magnum] TLS Support in Magnum

On 06/15/2015 08:45 PM, Madhuri wrote: +1 Kevin. We will make Barbican a dependency to make it the default option to secure keys. Regards, Madhuri On Tue, Jun 16, 2015 at 12:48 AM, Fox, Kevin M > wrote: If your asking the cloud provider to go through the effort

Re: [openstack-dev] [Mistral] Proposal for the Resume Feature

Thanks Winson for the write-up, very detailed infomation. (the format was good) I'm totally in favor of your idea, actually, I really think you proposal is complementary to my proposal in https://etherpad.openstack.org/p/vancouver-2015-design-summit-mistral, please see 'Workflow rollback/recovery'

Re: [openstack-dev] [Glance] [all] Proposal for Weekly Glance Drivers meeting.

Awesome, glad to see it's proposed. On 16/06/15 11:41, Nikhil Komawar wrote: Hi, As per the discussion during the last weekly Glance meeting (14:51:42at http://eavesdrop.openstack.org/meetings/glance/2015/glance.2015-06-11-14.00.log.html ), we will begin a short drivers' meeting where anyone ca

Re: [openstack-dev] [nova] Adding success message to succeed actions

Hi, John Thanks for your reply, I will follow your instructions. It will be great if I can help out with any part of the plan, I'm really happy to do it. BR, Zheng > Date: Mon, 15 Jun 2015 14:50:41 +0100 > From: j...@johngarbutt.com > To: openstack-dev@lists.openstack.org > Subject: Re: [opensta

Re: [openstack-dev] [Magnum] Discuss configurable-coe-api-port Blueprint

Hi Adrian, If I summarize your option, it would be, 1) Have a function like this, magnum bay-create --name swarmbay --baymodel swarmbaymodel --baymodel-property-override apiserver_port=8766 And then magnum pass that property to override baymodel default properties, and create the bay. 2) Yo

Re: [openstack-dev] [Magnum] TLS Support in Magnum

Adrian, On Tue, Jun 16, 2015 at 2:39 AM, Adrian Otto wrote: > Madhuri, > > On Jun 15, 2015, at 12:47 AM, Madhuri Rai > wrote: > > Hi, > > Thanks Adrian for the quick response. Please find my response inline. > > On Mon, Jun 15, 2015 at 3:09 PM, Adrian Otto > wrote: > >> Madhuri, >> >> On J

Re: [openstack-dev] [Magnum] TLS Support in Magnum

Excerpts from Fox, Kevin M's message of 2015-06-15 15:59:18 -0700: > No, I was confused by your statement: > "When we create a bay, we have an ssh keypair that we use to inject the ssh > public key onto the nova instances we create." > > It sounded like you were using that keypair to inject a pub

Re: [openstack-dev] [Magnum] TLS Support in Magnum

Thanks Egor. On Tue, Jun 16, 2015 at 1:52 AM, Egor Guz wrote: > +1 for non-Barbican support first, unfortunately Barbican is not very well > adopted in existing installation. > > Madhuri, also please keep in mind we should come with solution which > should work with Swarm and Mesos as well in fu

Re: [openstack-dev] [Magnum] TLS Support in Magnum

+1 Kevin. We will make Barbican a dependency to make it the default option to secure keys. Regards, Madhuri On Tue, Jun 16, 2015 at 12:48 AM, Fox, Kevin M wrote: > If your asking the cloud provider to go through the effort to install > Magnum, its not that much extra effort to install Barbican

Re: [openstack-dev] [nova] Online Migrations.

I discussed this a bit earlier with John and we came up with a thought that I was going to present after getting a little bit more documentation and spec around. With out going into too much detail, here is the basics of the idea. Add a new column to all data models that allow us to inject with

Re: [openstack-dev] [puppet] [fuel] more collaboration request

Emilien, Thanks for re-raising this. This is a sore subject on the Fuel's side, and I will sulk in my own shame for not being better here and continue to encourage my colleagues to be better in this regard. On Wed, Jun 10, 2015 at 10:45 PM Emilien Macchi wrote: > Hi, > > Before reading this e-m

[openstack-dev] [puppet] weekly meeting #38

Hi everyone, Here's an initial agenda for our weekly meeting tomorrow at 1500 UTC in #openstack-meeting-4: https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20150616 Please add additional items you'd like to discuss. -- Emilien Macchi signature.asc Description: OpenPGP digita

Re: [openstack-dev] Online Migrations.

On 6/15/15 6:37 PM, Mike Bayer wrote: On 6/15/15 4:21 PM, Andrew Laski wrote: If I had to visualize what an approach looks like that does this somewhat cleanly, other than just putting off contract until the API has naturally moved beyond it, it would involve a fixed and structured source

Re: [openstack-dev] [Mistral] Proposal for the Resume Feature

Resending to see if this fixes the formatting for outlines below. I want to continue the discussion on the workflow "resume" feature. Resuming from our last conversation @ http://lists.openstack.org/pipermail/openstack-dev/2015-March/060265.html. I don't think we should limit how users resume.

Re: [openstack-dev] [javascript] [horizon] [merlin] [refstack] Javascript Linting

On 16 June 2015 at 11:36, Michael Krotscheck wrote: ... > My personal opinion/recommendation: Based on the above, I recommend we use > ESLint. My reasoning: It's one tool, it's extensible, it does both codestyle > things and bug finding things, and it has a good license. JSHint is > disqualified b

Re: [openstack-dev] [puppet] OpenStack Puppet configuration for HA deployment

Cristina Aiftimiei wrote: thank you very much for the suggestion. We are trying to achieve something like you describe - just that I didn't know how to ... describe what we want :). Your sugestion is very, very interesting. So from where do you advice that we start from? I'm looking at https://l

Re: [openstack-dev] [Mistral] Proposal for the Resume Feature

I want to continue the discussion on the workflow "resume" feature. Resuming from our last conversation @ http://lists.openstack.org/pipermail/openstack-dev/2015-March/060265.html. I don't think we should limit how users resume. There may be different possible scenarios. User can fix the environm

[openstack-dev] [Glance] [all] Proposal for Weekly Glance Drivers meeting.

Hi, As per the discussion during the last weekly Glance meeting (14:51:42at http://eavesdrop.openstack.org/meetings/glance/2015/glance.2015-06-11-14.00.log.html ), we will begin a short drivers' meeting where anyone can come and get more feedback. The purpose is to enable those who need multiple

[openstack-dev] [javascript] [horizon] [merlin] [refstack] Javascript Linting

I'm restarting this thread with a different subject line to get a broader audience. Here's the original thread: http://lists.openstack.org/pipermail/openstack-dev/2015-June/066040.html The question at hand is "What will be OpenStack's javascript equivalent of flake8". I'm going to consider the nee

Re: [openstack-dev] [Magnum] TLS Support in Magnum

Awesome. Thanks. :) Kevin From: Adrian Otto [adrian.o...@rackspace.com] Sent: Monday, June 15, 2015 4:13 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Magnum] TLS Support in Magnum Kevin, We currently do

[openstack-dev] [all][requirements] Proposing a slight change in requirements.txt syncing output.

At the moment we copy the global-requirements lines verbatim. So if we have two lines in global-requirements.txt: oslotest>=1.5.1 # Apache-2.0 PyECLib>=1.0.7 # BSD with very different layouts That is preserved precisely into the output file - be that requirements.txt, te

Re: [openstack-dev] [Magnum] TLS Support in Magnum

Kevin, We currently do not use SSH for any of our orchestration. You have highlighted a good reason for us to avoid that wherever possible. Good catch! Cheers, Adrian > On Jun 15, 2015, at 3:59 PM, Fox, Kevin M wrote: > > No, I was confused by your statement: > "When we create a bay, we have

[openstack-dev] [app-catalog] Meeting Thursday June 18th at 17:00 UTC

Hello! The OpenStack App Catalog meeting will take place this Thursday June 18th at 17:00 UTC in #openstack-meeting-3 Meeting agenda can be found here: https://wiki.openstack.org/wiki/Meetings/app-catalog Please add agenda items, as this is just a quick first pass, I have a feeling we'll have ple

Re: [openstack-dev] [Magnum] TLS Support in Magnum

No, I was confused by your statement: "When we create a bay, we have an ssh keypair that we use to inject the ssh public key onto the nova instances we create." It sounded like you were using that keypair to inject a public key. I just misunderstood. It does raise the question though, are you u

Re: [openstack-dev] Liberty mid-cycle meetups?

We should really use the wiki to communicate this: https://wiki.openstack.org/wiki/Sprints#Liberty_sprints The thread is good but the wiki is easier to update/keep up to date as things change.. --Morgan On Mon, Jun 15, 2015 at 3:34 PM, Geoff Arnold wrote: > I’ve been trying to pull together a

Re: [openstack-dev] Liberty mid-cycle meetups?

I recommend a [all] tag in the subject if we are going with the full list. Glance, Horizon and SearchLight will have an update on the date and venue here: https://docs.google.com/spreadsheets/d/1w0eI6SPCA2IrOyHiEYC2uDO3fbYGzahZRUQSva0UD3Y/edit#gid=0 On 6/15/15 6:34 PM, Geoff Arnold wrote: > I’ve

Re: [openstack-dev] Liberty mid-cycle meetups?

On 06/15/2015 06:34 PM, Geoff Arnold wrote: > I’ve been trying to pull together a list of Liberty mid-cycle meetups from > emails, Etherpads, wikis, etc. Many of the usual suspects are missing. Can we > use this thread to gather the full list? (Alternatively, if there’s an > authoritative source

Re: [openstack-dev] Liberty mid-cycle meetups?

I believe that this is supposed to be the main source: https://wiki.openstack.org/wiki/Sprints Thanks, doug > On Jun 15, 2015, at 4:34 PM, Geoff Arnold wrote: > > I’ve been trying to pull together a list of Liberty mid-cycle meetups from > emails, E

Re: [openstack-dev] [all] [stable] No longer doing stable point releases

> The only issue is having a correct version number. Swift could well > iterate after "20151", for example doing "20151.1" then "20151.2", etc. Swift never had "coordinated" YEAR.N versions, https://wiki.openstack.org/wiki/Swift/version_map and they never released a version from their stable/* bra

Re: [openstack-dev] Online Migrations.

On 6/15/15 4:21 PM, Andrew Laski wrote: On 06/15/15 at 03:23pm, Mike Bayer wrote: 1. at runtime? e.g. your nova service is running, it's doing "SELECT x, y FROM thing", then some magic thing happens somewhere and the app suddenly sees, hey "y" is gone! change all queries to "SELECT x FROM

Re: [openstack-dev] [all] [stable] No longer doing stable point releases

On 6/15/15, 16:24, "Thomas Goirand" wrote: >On 06/15/2015 05:19 PM, Ian Cordasco wrote: >> On 6/15/15, 09:24, "Thomas Goirand" wrote: >> >>> On 06/08/2015 01:55 PM, Kuvaja, Erno wrote: One thing I like about plan D is that it would give also indicator how much the stable branch has

[openstack-dev] Liberty mid-cycle meetups?

I’ve been trying to pull together a list of Liberty mid-cycle meetups from emails, Etherpads, wikis, etc. Many of the usual suspects are missing. Can we use this thread to gather the full list? (Alternatively, if there’s an authoritative source that I’ve missed, please share the link.) What I h

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

+1 from me to remove 'X-' -- dims On Mon, Jun 15, 2015 at 6:18 PM, Jay Pipes wrote: > On 06/15/2015 05:58 PM, Ed Leafe wrote: >> >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA512 >> >> On 06/15/2015 04:30 PM, Michael Davies wrote: >> >>> On Tue, Jun 16, 2015 at 5:15 AM, Kevin L. Mitchell >>>

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

On 06/15/2015 05:58 PM, Ed Leafe wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 06/15/2015 04:30 PM, Michael Davies wrote: On Tue, Jun 16, 2015 at 5:15 AM, Kevin L. Mitchell mailto:kevin.mitch...@rackspace.com>> wrote: Given the disagreement evinced by the responses to this thread,

Re: [openstack-dev] [Magnum] TLS Support in Magnum

Kevin, > On Jun 15, 2015, at 1:25 PM, Fox, Kevin M wrote: > > Why not just push the ssh keypair via cloud-init? Its more firewall friendly. Nova already handles the injection the SSH key for us. I think you meant to suggest that we use cloud-init to inject the TLS keys, right? Thanks, Adrian

Re: [openstack-dev] [puppet] [zaqar] Adding puppet-zaqar Module to Puppet Modules Project

Hi Richard, Thank you for working on this. It's really cool. On 16/06/15 07:48, Richard Raseley wrote: > Here are the two changes I submitted for review to get puppet-zaqar > added to the project: > > https://review.openstack.org/#/c/191942/ > https://review.openstack.org/#/c/191946/ > > I am not

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

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 06/15/2015 04:30 PM, Michael Davies wrote: > On Tue, Jun 16, 2015 at 5:15 AM, Kevin L. Mitchell > > wrote: > > Given the disagreement evinced by the responses to this thread, let > me ask a question: Would

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

On Mon, Jun 15, 2015 at 12:07 PM, Jay Pipes wrote: > It has come to my attention in [1] that the microversion spec for Nova [2] > and Ironic [3] have used the project name -- i.e. Nova and Ironic -- > instead of the name of the API -- i.e. "OpenStack Compute" and "OpenStack > Bare Metal" -- in th

Re: [openstack-dev] [kolla] voting ends June 17th - was: Scheduling for a mid-cycle - doodle poll inside

Reminder voting ends June 17th. From: Steven Dake mailto:std...@cisco.com>> Reply-To: "OpenStack Development Mailing List (not for usage questions)" mailto:openstack-dev@lists.openstack.org>> Date: Tuesday, June 9, 2015 at 12:02 PM To: "OpenStack Development Mailing List (not for usage questions)

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

On Tue, Jun 16, 2015 at 5:15 AM, Kevin L. Mitchell < kevin.mitch...@rackspace.com> wrote: > > Given the disagreement evinced by the responses to this thread, let me > ask a question: Would there be any particular problem with using > "X-OpenStack-API-Version"? Well, perhaps we should consider "Op

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

Excerpts from Sean Dague's message of 2015-06-15 14:00:43 -0700: > On 06/15/2015 04:50 PM, Jim Rollenhagen wrote: > > On Mon, Jun 15, 2015 at 01:07:39PM -0400, Jay Pipes wrote: > >> It has come to my attention in [1] that the microversion spec for Nova [2] > >> and Ironic [3] have used the project

Re: [openstack-dev] [all] [stable] No longer doing stable point releases

On 06/15/2015 05:19 PM, Ian Cordasco wrote: > On 6/15/15, 09:24, "Thomas Goirand" wrote: > >> On 06/08/2015 01:55 PM, Kuvaja, Erno wrote: >>> One thing I like about plan D >>> is that it would give also indicator how much the stable branch has >>> moved in >>> each individual project. >> >> The o

Re: [openstack-dev] [all][release] summit session summary: Release Versioning for Server Applications

Excerpts from Doug Hellmann's message of 2015-06-05 10:23:52 -0400: > Excerpts from Doug Hellmann's message of 2015-05-29 17:38:04 -0400: > > This message is a summary of the notes from the “Release Versioning > > Servers” discussion held during the release management/QA/infrastructure > > meetup

Re: [openstack-dev] [puppet] OpenStack Puppet configuration for HA deployment

I have to agree, every one's composition layer tends to come out differently and your mileage will vary using some one elses. You can examine the diverged fork of puppet-openstack that fuel uses at https://github.com/stackforge/fuel-library/tree/master/deployment/puppet/openstack which does ha, bu

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

On 06/15/2015 01:07 PM, Jay Pipes wrote: It has come to my attention in [1] that the microversion spec for Nova [2] and Ironic [3] have used the project name -- i.e. Nova and Ironic -- instead of the name of the API -- i.e. "OpenStack Compute" and "OpenStack Bare Metal" -- in the HTTP header th

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

On 06/15/2015 04:50 PM, Jim Rollenhagen wrote: > On Mon, Jun 15, 2015 at 01:07:39PM -0400, Jay Pipes wrote: >> It has come to my attention in [1] that the microversion spec for Nova [2] >> and Ironic [3] have used the project name -- i.e. Nova and Ironic -- instead >> of the name of the API -- i.e.

Re: [openstack-dev] stackforge projects are not second class citizens

I'd also like to point out that if the state of the projects has encouraged *new* contributors to OpenStack, then their contributions will likely take a couple to a few months to become visible in a significant way in the statistics. Two to three months to get your first merge is extremely commo

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

On Mon, Jun 15, 2015 at 01:07:39PM -0400, Jay Pipes wrote: > It has come to my attention in [1] that the microversion spec for Nova [2] > and Ironic [3] have used the project name -- i.e. Nova and Ironic -- instead > of the name of the API -- i.e. "OpenStack Compute" and "OpenStack Bare > Metal" --

Re: [openstack-dev] [packaging] Adding packaging as an OpenStack project

On 06/15/2015 03:03 PM, Allison Randal wrote: On 06/15/2015 11:48 AM, Thomas Goirand wrote: On 06/15/2015 04:55 PM, James Page wrote: The problem of managing delta and allowing a good level of distribution independence is still going to continue to exist and will be more difficult to manage due

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

On Mon, Jun 15, 2015 at 1:24 PM, Jay Pipes wrote: > On 06/15/2015 01:31 PM, Sean Dague wrote: > >> On 06/15/2015 01:07 PM, Jay Pipes wrote: >> >>> It has come to my attention in [1] that the microversion spec for Nova >>> [2] and Ironic [3] have used the project name -- i.e. Nova and Ironic -- >>

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

On 06/15/2015 02:26 PM, Ruby Loo wrote: On 15 June 2015 at 13:07, Jay Pipes mailto:jaypi...@gmail.com>> wrote: It has come to my attention in [1] that the microversion spec for Nova [2] and Ironic [3] have used the project name -- i.e. Nova and Ironic -- instead of the name of the AP

[openstack-dev] [puppet] review getting long in the tooth

Sync up module with latest msync commit. - https://review.openstack.org/#/c/189873 Make tests pass on Puppet 4.x - https://review.openstack.org/#/c/184646/ For what ever reason these two patch sets keep getting reviewed then either rebased or I implement minor non-blocking comments and resubmi

Re: [openstack-dev] [puppet] OpenStack Puppet configuration for HA deployment

Hi Matt & Richard, thank you very much for the suggestion. We are trying to achieve something like you describe - just that I didn't know how to ... describe what we want :). Your sugestion is very, very interesting. So from where do you advice that we start from? I'm looking at https://launchpad

Re: [openstack-dev] Starting the M Release Name Poll

Hi, I'd like to apologize to all of the people who worked hard on researching and proposing names for the M release that did not appear in the poll. When we worked on the new method for choosing a name, we did so with the idea that the entire process should be public and that the community is equ

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

On 06/15/2015 02:09 PM, Dmitry Tantsur wrote: 2015-06-15 19:50 GMT+02:00 Clint Byrum mailto:cl...@fewbar.com>>: Excerpts from Jay Pipes's message of 2015-06-15 10:07:39 -0700: > It has come to my attention in [1] that the microversion spec for Nova > [2] and Ironic [3] have used

Re: [openstack-dev] [Magnum] TLS Support in Magnum

Why not just push the ssh keypair via cloud-init? Its more firewall friendly. Having the controller -> instance via ssh has proven very problematic for us for a lot of projects. :/ Thanks, Kevin From: Adrian Otto [adrian.o...@rackspace.com] Sent: Monday,

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

On 06/15/2015 01:31 PM, Sean Dague wrote: On 06/15/2015 01:07 PM, Jay Pipes wrote: It has come to my attention in [1] that the microversion spec for Nova [2] and Ironic [3] have used the project name -- i.e. Nova and Ironic -- instead of the name of the API -- i.e. "OpenStack Compute" and "OpenS

Re: [openstack-dev] Online Migrations.

On 06/15/15 at 03:23pm, Mike Bayer wrote: On 6/15/15 2:21 PM, Dan Smith wrote: Tying this to the releases is less desirable from my perspective. It means that landing a thing requires more than six months of developer and reviewer context. We have that right now, and we get along, but it's muc

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

On 06/15/2015 03:45 PM, Kevin L. Mitchell wrote: On Mon, 2015-06-15 at 13:07 -0400, Jay Pipes wrote: The original spec said that the HTTP header should contain the name of the service type returned by the Keystone service catalog (which is also the official name of the REST API). I don't underst

Re: [openstack-dev] [oslo.messaging][zeromq] Next step

Excerpts from Alec Hothan (ahothan)'s message of 2015-06-15 11:45:53 -0700: > > On 6/12/15, 3:55 PM, "Clint Byrum" wrote: > > > > >> > > > >I think you missed "it is not tested in the gate" as a root cause for > >some of the ambiguity. Anecdotes and bug reports are super important for > >knowin

Re: [openstack-dev] [cinder] Will CI failures recently cause the corresponding driver removed from the L?

On 09:26 Jun 12, liuxinguo wrote: > Hi, > Our CI can not connect to port 29418 of review.openstack.org recently, > possibly because the GFW filtered the access. Now we are processing this > problem as soon as we found it. > According to the decision of Cinder Meeting 2015-06-10: > "June 15th propos

[openstack-dev] [puppet] [zaqar] Adding puppet-zaqar Module to Puppet Modules Project

Here are the two changes I submitted for review to get puppet-zaqar added to the project: https://review.openstack.org/#/c/191942/ https://review.openstack.org/#/c/191946/ I am not sure these are 100% correct, but I followed the guide[0] as well as I could. Any feedback would be appreciated.

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

On Mon, 2015-06-15 at 13:07 -0400, Jay Pipes wrote: > The original spec said that the HTTP header should contain the name of > the service type returned by the Keystone service catalog (which is also > the official name of the REST API). I don't understand why the spec was > changed retroactivel

[openstack-dev] [Infra] Meeting Tuesday June 16th at 19:00 UTC

Hi everyone, The OpenStack Infrastructure (Infra) team is having our next weekly meeting on Tuesday June 16th, 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 intereste

Re: [openstack-dev] Online Migrations.

On 6/15/15 2:21 PM, Dan Smith wrote: Tying this to the releases is less desirable from my perspective. It means that landing a thing requires more than six months of developer and reviewer context. We have that right now, and we get along, but it's much harder to plan, execute, and cleanup t

Re: [openstack-dev] Nominating Serge van Ginderachter to the os-ansible-deployment core team

+1 from me. On May 28, 2015, at 7:01 PM, Kevin Carter wrote: > Hello, > > I would like to nominate Serge (svg on IRC) for the > os-ansible-deployment-core team. Serge has been involved with the greater > Ansible community for some time and has been working with the OSAD project > for the last

[openstack-dev] [Swift] slight restructuring of core

We've slightly changed the core group in Swift. Now we have swift-core and also the new swiftclient-core. The swiftclient-core is able to merge patches in python-swiftclient but not in swift. We've made this change so that we can more easily add people who have a dedicated focus on the client C

Re: [openstack-dev] (re)centralizing library release management

Excerpts from Doug Hellmann's message of 2015-06-09 16:08:16 -0400: > Excerpts from Doug Hellmann's message of 2015-06-09 13:25:26 -0400: > > Until now we have encouraged project teams to prepare their own > > library releases as new versions of projects were needed. We've > > started running into

Re: [openstack-dev] [packaging] Adding packaging as an OpenStack project

On 06/15/2015 11:48 AM, Thomas Goirand wrote: > On 06/15/2015 04:55 PM, James Page wrote: >> The problem of managing delta and allowing a good level of >> distribution independence is still going to continue to exist and will >> be more difficult to manage due to the tighter coupling of development

[openstack-dev] [Ironic] weekly subteam status report

Hi, Following is the subteam report for Ironic. As usual, this is pulled directly from the Ironic whiteboard[0] and formatted. Bugs (dtantsur) (as of Mon, 15 Jun 15:00 UTC, diff since 1 Jun) Open: 159 (+9) 5 new (0), 51 in progress (+6), 0 critical, 12 high (+2) and 12 incomplete

Re: [openstack-dev] [packaging] Adding packaging as an OpenStack project

On 06/15/2015 04:55 PM, James Page wrote: > Hi All > > On 27/05/15 09:14, Thomas Goirand wrote: >> tl;dr: - We'd like to push distribution packaging of OpenStack on >> upstream gerrit with reviews. - The intention is to better share >> the workload, and improve the overall QA for packaging *and* >

Re: [openstack-dev] [Magnum] Make functional tests voting

Bug ticket for python-magnumclient gate test: https://bugs.launchpad.net/python-magnumclient/+bug/1465375 On Jun 15, 2015, at 11:07 AM, Tom Cammann mailto:tom.camm...@hp.com>> wrote: Review up for making it voting: https://review.openstack.org/#/c/191921/ It would probably be a good plan to run

Re: [openstack-dev] [oslo.messaging][zeromq] Next step

On 6/12/15, 3:55 PM, "Clint Byrum" wrote: > >> > >I think you missed "it is not tested in the gate" as a root cause for >some of the ambiguity. Anecdotes and bug reports are super important for >knowing where to invest next, but a test suite would at least establish a >base line and prevent t

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

On 15 June 2015 at 13:07, Jay Pipes wrote: > It has come to my attention in [1] that the microversion spec for Nova [2] > and Ironic [3] have used the project name -- i.e. Nova and Ironic -- > instead of the name of the API -- i.e. "OpenStack Compute" and "OpenStack > Bare Metal" -- in the HTTP h

Re: [openstack-dev] Online Migrations.

>> 3. Build the controls into our process with a way of storing the >> current release cycle information to only allow contract’s to >> occur at a set major release and maintain the column in the model >> till it is ready to be removed major release + 1 since the >> migration was a

Re: [openstack-dev] [Magnum] TLS Support in Magnum

Tom, > On Jun 15, 2015, at 10:59 AM, Tom Cammann wrote: > > My main issue with having the user generate the keys/certs for the kube nodes > is that the keys have to be insecurely moved onto the kube nodes. Barbican can > talk to heat but heat must still copy them across to the nodes, exposing th

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

On Mon, 15 Jun 2015, Clint Byrum wrote: I'm a little bit worried that we don't have a guiding principle to point at somewhere. Perhaps the API WG can encode guidance either way ("We use project names", or "we use service types"). I think it's a good idea to encode the principle, whatever it is

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

2015-06-15 19:50 GMT+02:00 Clint Byrum : > Excerpts from Jay Pipes's message of 2015-06-15 10:07:39 -0700: > > It has come to my attention in [1] that the microversion spec for Nova > > [2] and Ironic [3] have used the project name -- i.e. Nova and Ironic -- > > instead of the name of the API -- i

Re: [openstack-dev] [puppet] OpenStack Puppet configuration for HA deployment

Cristina Aiftimiei wrote: The puppetlabs-openstack clearly states: "" Limitations * High availability and SSL-enabled endpoints are not provided by this module. """ As Matt touched on, you really should be building your own 'composition layer' for deploying producti

Re: [openstack-dev] [Magnum] Make functional tests voting

Review up for making it voting: https://review.openstack.org/#/c/191921/ It would probably be a good plan to run the functional tests on the python-magnumclient, although I'm not too sure how to set that up. Tom On 15/06/15 18:47, Adrian Otto wrote: Tom, Yes, let’s make it voting now. I wen

Re: [openstack-dev] [Magnum] TLS Support in Magnum

My main issue with having the user generate the keys/certs for the kube nodes is that the keys have to be insecurely moved onto the kube nodes. Barbican can talk to heat but heat must still copy them across to the nodes, exposing the keys on the wire. Perhaps there are ways of moving secrets cor

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

Excerpts from Jay Pipes's message of 2015-06-15 10:07:39 -0700: > It has come to my attention in [1] that the microversion spec for Nova > [2] and Ironic [3] have used the project name -- i.e. Nova and Ironic -- > instead of the name of the API -- i.e. "OpenStack Compute" and > "OpenStack Bare M

Re: [openstack-dev] [Magnum] Make functional tests voting

Tom, Yes, let’s make it voting now. I went through the full review queue over the weekend, and I did find a few examples of functional tests timing out after 2 hours. It did not look to me like they actually ran, suggesting a malfunction in the setup of the test nodes. There we only one or two

Re: [openstack-dev] [Magnum] TLS Support in Magnum

Madhuri, On Jun 15, 2015, at 12:47 AM, Madhuri Rai mailto:madhuri.ra...@gmail.com>> wrote: Hi, Thanks Adrian for the quick response. Please find my response inline. On Mon, Jun 15, 2015 at 3:09 PM, Adrian Otto mailto:adrian.o...@rackspace.com>> wrote: Madhuri, On Jun 14, 2015, at 10:30 PM, M

Re: [openstack-dev] [kolla] Proposal for new core-reviewer Harm Waites

On Sun, Jun 14, 2015 at 05:48:48PM +, Steven Dake (stdake) wrote: I am proposing Harm Waites for the Kolla core team. +1! __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ.

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

On 06/15/2015 01:07 PM, Jay Pipes wrote: > It has come to my attention in [1] that the microversion spec for Nova > [2] and Ironic [3] have used the project name -- i.e. Nova and Ironic -- > instead of the name of the API -- i.e. "OpenStack Compute" and > "OpenStack Bare Metal" -- in the HTTP heade

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

On 06/15/2015 01:16 PM, Dmitry Tantsur wrote: On 06/15/2015 07:07 PM, Jay Pipes wrote: It has come to my attention in [1] that the microversion spec for Nova [2] and Ironic [3] have used the project name -- i.e. Nova and Ironic -- instead of the name of the API -- i.e. "OpenStack Compute" and "O

  1   2   >