Re: [openstack-dev] Version header for OpenStack microversion support

Recapping... - ensure we are not using X- in the header - use the service type, not name For keystone it would be: OpenStack-API-Version: identity 3.7 For nova it would be: OpenStack-API-Version: compute 2.27 (which matches what is proposed here:

Re: [openstack-dev] [tempest][nova][defcore] Add option to disable some strict response checking for interop testing

On 6/14/2016 6:37 PM, Chris Hoge wrote: I’m beginning to wonder if we need to make DefCore use release branches then back-port bug-fixes and relevant features additions as necessary. To clarify, do you mean use release branches from the upstream repos? Because if DefCore is supporting 2

Re: [openstack-dev] [tempest][nova][defcore] Add option to disable some strict response checking for interop testing

On 6/14/2016 6:19 PM, Chris Hoge wrote: One would hope that micro-versions would be able to address this exact issue for vendors by giving them a means to propose optional but well-defined API response additions (not extensions) that are defined upstream and usable by all vendors. If it’s not

Re: [openstack-dev] [tempest][nova][defcore] Add option to disable some strict response checking for interop testing

On 23:53 Jun 17, Matthew Treinish wrote: > On Fri, Jun 17, 2016 at 04:26:49PM -0700, Mike Perez wrote: > > On 15:12 Jun 14, Matthew Treinish wrote: > > > I don't think backwards compatibility policies really apply to what what > > > define > > > as the set of tests that as a community we are

[Openstack] Changing a service state Down to Up?

I've had my console service on one of my Compute nodes in the Down state for a couple of days. I haven't bothered with it, but because I'm now stuck in network creation/understanding and my block storage problems, I thought I'd fix that. Saw a bunch of problems in the logs and have now fixed

[Openstack] neutron, l2population, linuxbridge and multiple ips

Dear list, I'm trying set up an isolated network for testing clustermanagers like keepalived on linux and carp on openbsd. This means there are ips which are bound to multiple ports. The main problem is when I try to configure new ip-addresses inside the vms and _not_ in neutron, these ips

Re: [openstack-dev] [daisycloud-core] IRC weekly meeting logistics

Got your mail late. It is OK, Have a nice weekend. I will send meet minutes after meeting. On Jun 17, 2016 12:26 PM, "Jaivish Kothari" < janonymous.codevult...@gmail.com> wrote: > Hi Daisy Team, > > It is my honor to become a part of team,Unfortunately i had to leave the > town for Client meeting

Re: [openstack-dev] [ironic] Proposing two new cores

On Thu, Jun 16, 2016 at 11:12:31AM -0400, Jim Rollenhagen wrote: > Hi all, > > I'd like to propose Jay Faulkner (JayF) and Sam Betts (sambetts) for the > ironic-core team. > > Jay has been in the community as long as I have, has been IPA and > ironic-specs core for quite some time. His

Re: [openstack-dev] Version header for OpenStack microversion support

True, manila is currently using the same header; but given that nova and ironic are supporting the new header recommendation, this has come up for discussion in the manila community. In any case, the use of the prefix “X-“, and project names within the header is not recommended. Please refer

Re: [openstack-dev] [Ironic] Grenade non-voting test results

On Fri, Jun 17, 2016 at 08:23:05PM +, Jay Faulkner wrote: > +1 lets get it voting. Feel free to add me as a reviewer to the > project-config patch to make the change if you want me to vote officially :). Agree. I did the thing :) https://review.openstack.org/#/c/331422/1 // jim > > >

Re: [openstack-dev] Version header for OpenStack microversion support

On Sat, 18 Jun 2016, Jamie Lennox wrote: Quick question: why do we need the service type or name in there? You really should know what API you're talking to already and it's just something that makes it more difficult to handle all the different APIs in a common way. The basic idea is so that

Re: [Openstack-operators] Upgrade OpenStack Juno to Mitaka

Michael Stang writes: > Is this one the actual guid for upgrades, and is it valid for every > upgrade or ony for specific versions?: > http://docs.openstack.org/ops-guide/ops_upgrades.html Yes, that's part of the official Operations Guide. It is not version-specific. The examples are based on

Re: [openstack-dev] [murano] Nominating Alexander Tivelkov and Zhu Rong for murano cores

Thanks, folks! I will do my best! Regards, Zhu Rong__ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

Re: [openstack-dev] Version header for OpenStack microversion support

Excerpts from Henry Nash's message of 2016-06-18 13:14:17 +0100: > > On 18 Jun 2016, at 11:32, Jamie Lennox wrote: > > > > Quick question: why do we need the service type or name in there? You > > really should know what API you're talking to already and it's just > >

[Openstack] Kilo Devstack - DCHP is not assigning IPs to the VMs

Hi All, I have installed kilo devstack and have a problem with dhcp, it is not assigning IPs to the VMs. What are the reasons for that ? Best regards, Ahmed ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to :

Re: [openstack-dev] Version header for OpenStack microversion support

…I think it is so you can have a header in a request that, once issued, can be passed for service to service, e.g.: OpenStack-API-Version: identity 3.7, compute 2.11 Henry > On 18 Jun 2016, at 11:32, Jamie Lennox wrote: > > Quick question: why do we need the service

Re: [openstack-dev] Version header for OpenStack microversion support

Quick question: why do we need the service type or name in there? You really should know what API you're talking to already and it's just something that makes it more difficult to handle all the different APIs in a common way. On Jun 18, 2016 8:25 PM, "Steve Martinelli"

Re: [openstack-dev] Version header for OpenStack microversion support

Looks like Manila is using the service name instead of type (X-OpenStack-Manila-API-Version) according to this link anyway: http://docs.openstack.org/developer/manila/devref/api_microversion_dev.html Keystone can follow the cross project spec and use the service type (Identity instead of

Re: [OpenStack-Infra] Upcoming changes now that Jenkins has retired

Hey Steve, Yes. The user "jenkins" in gerrit has actually been controlled by zuul for some years now. This rename is basically to reflect that and includes an 1st party CI comments (so check and gate). Cheers, Josh On Sat, Jun 18, 2016 at 3:26 PM, Steven Dake (stdake) wrote:

Re: [openstack-dev] [OpenStack-Infra] Upcoming changes now that Jenkins has retired

Hey Steve, Yes. The user "jenkins" in gerrit has actually been controlled by zuul for some years now. This rename is basically to reflect that and includes an 1st party CI comments (so check and gate). Cheers, Josh On Sat, Jun 18, 2016 at 3:26 PM, Steven Dake (stdake) wrote:

Re: [Openstack] swift-recon over different rings

On 18/06/16 01:49, Carlos Rodrigues wrote: Hello Mark, Thank you for your answer. What openstack/swift version are you using? I have liberty openstack swift and swift-recon returns error when i run with -p option I am using matika version of swift (2.7). Looking at my checkout of the