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

[Steve Martinelli]

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:
https://review.openstack.org/#/c/300077/14/api-guide/source/microversions.rst
)

Similarly for manila and ironic, I don't have the links handy, or the what
the headers are currently

On Sat, Jun 18, 2016 at 11:13 AM, Ravi, Goutham 
wrote:

> 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 to the API Working Group’s
> recommendation in this regard:
>
>
>
>
> http://specs.openstack.org/openstack/api-wg/guidelines/microversion_specification.html
>
>
>
> The example already suggests what needs to be done in case of the identity
> project J
>
>
>
> --
>
> Goutham
>
>
>
> *From: *Steve Martinelli 
> *Reply-To: *"OpenStack Development Mailing List (not for usage
> questions)" 
> *Date: *Saturday, June 18, 2016 at 6:22 AM
> *To: *"OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> *Subject: *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 Keystone).
>
> On Jun 17, 2016 12:44 PM, "Ed Leafe"  wrote:
>
> On Jun 17, 2016, at 11:29 AM, Henry Nash  wrote:
>
> > We are currently in the process of implementing microversion support in
> keystone - and are obviously trying to follow the cross-projec spec for
> this (
> http://specs.openstack.org/openstack/api-wg/guidelines/microversion_specification.html
> ).
> >
> > One thing I noticed was that the header specified in this spec is of the
> form:
> >
> > OpenStack-API-Version: [SERVICE_TYPE] [X,Y]
> >
> > for example:
> >
> > OpenStack-API-Version: identity 3.7
> >
> > However, from what i can see of the current implementations I have seen
> of microversioning in OpenStack (Nova, Manilla), they use service-specific
> headers, e.g.
> >
> > X-OpenStack-Nova-API-Version: 2.12
> >
> > My question is whether there a plan to converge on the generalized
> header format….or are we keep with the service-specific headers? I’d
> obviously like to implement the correct one for keystone.
>
> Yes, the plan is to converge on the more generic headers. The Nova headers
> (don’t know about Manilla) pre-date the API WG spec, and were the
> motivation for development of that spec. We’ve even made it possible to
> accept both header formats [0] until things can be migrated to the
> recommended format.
>
> [0] https://review.openstack.org/#/c/300077/
>
> -- Ed Leafe
>
>
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Matt Riedemann]

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 years of releases, that's going to 
conflict with the 18 month lifespan of branches upstream, i.e. kilo is 
already EOL. So backporting to stable/juno or stable/kilo at this point 
isn't possible, at least in the official openstack repos.


And backporting features to stable branches would break our stable 
branch policy.


--

Thanks,

Matt Riedemann


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Matt Riedemann]

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 too off topic, can someone
from the Nova team explain how something like that would work (if it
would at all)?

-Chris
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



The 2.4 microversion is about as simple as it gets to adding more data 
to a response:


http://docs.openstack.org/developer/nova/api_microversion_history.html#id3

If you're requesting microversion >=2.4 you get the 'reserved' flag back 
when showing details on a fixed IP, else it's omitted from the response 
(as in v2.0 and v2.1).


--

Thanks,

Matt Riedemann


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Mike Perez]

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 saying a vendor has to 
> > > pass to
> > > say they're OpenStack. From my perspective as a community we either take 
> > > a hard
> > > stance on this and say to be considered an interoperable cloud (and to 
> > > get the
> > > trademark) you have to actually have an interoperable product. We slowly 
> > > ratchet
> > > up the requirements every 6 months, there isn't any implied backwards
> > > compatibility in doing that. You passed in the past but not in the newer 
> > > stricter
> > > guidelines.
> > > 
> > > Also, even if I did think it applied, we're not talking about a change 
> > > which
> > > would fall into breaking that. The change was introduced a year and half 
> > > ago
> > > during kilo and landed a year ago during liberty:
> > > 
> > > https://review.openstack.org/#/c/156130/
> > > 
> > > That's way longer than our normal deprecation period of 3 months and a 
> > > release
> > > boundary.
> > 
> > 
> > 
> > What kind of communication happens today for these changes? There are so 
> > many
> > channels/high volume mailing lists a downstream deployer is expected by the
> > community to listening in. Some disruptive change being introduced a year or
> > longer ago can still be communicated poorly.
> 
> Sure, I agree with that, but I don't think this was necessarily communicated
> poorly. This has been already mentioned a few times on this thread but:
> 
> It was talked about on openstack-dev:
> 
> http://lists.openstack.org/pipermail/openstack-dev/2015-February/057613.html
> 
> On the defcore list: (which is definitely not high volume/traffic ML)
> 
> http://lists.openstack.org/pipermail/defcore-committee/2015-June/000849.html
> 
> This was also raised as an issue for 1 vendor ~6 months ago. (which is also 
> the
> same duration of the hard deadline being discussed in this thread):
> 
> http://lists.openstack.org/pipermail/defcore-committee/2016-January/000986.html
> 
> IMHO, this was more than enough time to introduce a fix or workaround on their
> end. Likely the easiest being just adding an extra nova-api endpoint with the
> extensions disabled.
> 
> I don't have any links or other evidence to point to, but I know that this
> exact topic has been discussed with with people from the vendors having
> difficulties during sessions at at least one of the 2 summits and/or 2 QA
> midcycle meetups since this change landed. I really don't think this is a
> communication problem or unfair surprise for anyone.
> 
> There might be more too, but I don't remember every conversation that I've had
> in the community over the past year. (or where to find the links to point to)

Thanks for the references. So these references show:

* DefCore was aware of these changes long ago.
* Vendors were aware of these changes long ago.
* Referenced vendor is still failing after knowing about this change for six
  months.

Question to DefCore, what were you doing in this time frame to prepare vendors
for success with this change rolling out in order to keep a healthy market
place?

> > Just like we've done with Reno in communicating better about disruptive 
> > changes
> > in release notes, what tells teams like DefCore about changes with Tempest?
> > (I looked in release.o.o for tempest release notes, although maybe I missed
> > it?)
> 
> Yes, tempest has release notes, they are here:
> 
> http://docs.openstack.org/releasenotes/tempest/
> 
> But, the change in question predates the existence of reno and centralized
> release notes for everything in openstack.
> 
> If this change were pushed today it would definitely be included in the 
> release
> notes. We also would do the same things, put it on the dev list, put it on the
> defcore list. (although probably as a standalone thread this time) I also 
> think
> we'd probably ping hogepodge on irc about it too just so he could also raise 
> it
> up on the defcore side. (which we might have done back then too) Defcore and
> tempest are tightly coupled so we do have pretty constant communication around
> changes being made. But, I do admit we have better mechanisms in place today
> to communicate this kind of change, and hopefully this would be handled better
> now.

This is great! I hope people who have use cases with Tempest are using these
release notes for future big changes.

> > 
> > Since some members of DefCore have interest in making the market place 
> > healthy,
> > what is DefCore doing today to communicate these disruptive changes early to
> > deployers? Did it not happen in this particular case because:
> > 
> > * DefCore has no one working closely in the Tempest project to flag things?
> > * Defcore does work closely with Tempest, but somehow the communication for
> 

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

[jason]

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 urgently today as told to me so it might not be
> possible to attend the meeting :( , but i would surely follow up through
> logs and Irc Daisy Channel.
> I regret for the inconvenience caused.
>
>
> Regards
> Jaivish Kothari
>
>
> On Tue, Jun 14, 2016 at 9:07 AM,  wrote:
>
>> Hi Team,
>>
>> Here is the IRC weekly meeting logistics:
>>
>>
>> Weekly on Friday at 1200 UTC, You can check out your local time here:
>> http://www.timeanddate.com/worldclock/fixedtime.html?hour=12=0=0
>> IRC channel: #daisycloud at freenode
>>
>> So our first meeting will be on this friday (Jun 17). The Agenda mainly
>> is:
>>
>> 1. Rollcall
>> 2. Welcome Jaivish and everyone introduce him/herself, for the very first
>> time over this IRC channel.
>> 3. Daisy status update
>> 4. Daisy for NFV update
>>
>>
>>
>> Could anyone please help me to update logistics info as well as
>> contributors info to https://wiki.openstack.org/wiki/Daisy ? Because I
>> can not log into https://wiki.openstack.org any more, I dont know why, I
>> think it is a problem of the wiki.openstack.org website. Every time I
>> trying to login it show me a blank page, and if I refresh it, it shows error:
>> "Nonce already used or out of range"
>>
>>
>> Our current active contributor list
>>
>> -
>> NameIRC Nick  Email
>> -
>> Zhijiang Hu huzhj hu.zhiji...@zte.com.cn
>> Jaivish Kothari janonymousjanonymous.codevult...@gmail.com
>> Wei Kong  kong.w...@zte.com.cn
>> Yao Lulu.yao...@zte.com.cn
>> Ya Zhou   zhou...@zte.com.cn
>> Jing Sun  sun.jin...@zte.com.cn
>>
>>
>>
>> 
>> ZTE Information Security Notice: The information contained in this mail (and 
>> any attachment transmitted herewith) is privileged and confidential and is 
>> intended for the exclusive use of the addressee(s).  If you are not an 
>> intended recipient, any disclosure, reproduction, distribution or other 
>> dissemination or use of the information contained is strictly prohibited.  
>> If you have received this mail in error, please delete it and notify us 
>> immediately.
>>
>>
>>
>>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Jim Rollenhagen]

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 background is operations, and
> he's getting good with Python. He's given great reviews for quite a
> while now, and the number is steadily increasing. I think it's a
> no-brainer.
> 
> Sam has been in the ironic community for quite some time as well, with
> close ties to the neutron community as well. His background seems to be
> in networking, he's got great python skills as well. His reviews are
> super useful. He doesn't have quite as many as some people, but they are
> always thoughtful, and he often catches things others don't. I do hope
> to see more of his reviews.
> 
> Both Sam and Jay are to the point where I consider their +1 or -1 as
> highly as any other core, so I think it's past time to allow them to +2
> as well.
> 
> Current cores, please reply with your vote.

9 out of 11 sounds like consensus to me. Welcome to the team, Jay and
Sam! :)

ironic-core membership:
https://review.openstack.org/#/admin/groups/165,members

As a note, the IPA core team was ironic-core plus Jay and Josh. We
apparently forgot to remove Josh's core rights from IPA when he stopped
working on ironic, so I've done that. Now that Jay is in ironic-core,
I've consolidated things such that ironic-core is the review team for
IPA.

Patch for the IPA change is here: https://review.openstack.org/331425

ironic-python-agent-core membership:
https://review.openstack.org/#/admin/groups/307,members

// jim

> 
> // jim
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Ravi, Goutham]

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 to the API Working Group’s recommendation in this 
regard:

http://specs.openstack.org/openstack/api-wg/guidelines/microversion_specification.html

The example already suggests what needs to be done in case of the identity 
project ☺

--
Goutham

From: Steve Martinelli 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Saturday, June 18, 2016 at 6:22 AM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: 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 Keystone).
On Jun 17, 2016 12:44 PM, "Ed Leafe" > 
wrote:
On Jun 17, 2016, at 11:29 AM, Henry Nash 
> wrote:

> We are currently in the process of implementing microversion support in 
> keystone - and are obviously trying to follow the cross-projec spec for this 
> (http://specs.openstack.org/openstack/api-wg/guidelines/microversion_specification.html).
>
> One thing I noticed was that the header specified in this spec is of the form:
>
> OpenStack-API-Version: [SERVICE_TYPE] [X,Y]
>
> for example:
>
> OpenStack-API-Version: identity 3.7
>
> However, from what i can see of the current implementations I have seen of 
> microversioning in OpenStack (Nova, Manilla), they use service-specific 
> headers, e.g.
>
> X-OpenStack-Nova-API-Version: 2.12
>
> My question is whether there a plan to converge on the generalized header 
> format….or are we keep with the service-specific headers? I’d obviously like 
> to implement the correct one for keystone.

Yes, the plan is to converge on the more generic headers. The Nova headers 
(don’t know about Manilla) pre-date the API WG spec, and were the motivation 
for development of that spec. We’ve even made it possible to accept both header 
formats [0] until things can be migrated to the recommended format.

[0] https://review.openstack.org/#/c/300077/

-- Ed Leafe






__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Jim Rollenhagen]

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

> 
> 
> Thanks,
> 
> Jay
> 
> 
> From: Villalovos, John L 
> Sent: Friday, June 17, 2016 10:49:32 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: [openstack-dev] [Ironic] Grenade non-voting test results
> 
> TL;DR: In my opinion Grenade job is performing reliably.
> 
> Using the table at:
> http://ci-watch.tintri.com/project?project=ironic=7+days
> Note: Unable to extract the data out of the web page to do more thorough data 
> evaluation.
> 
> The Grenade job appears to be performing successfully. On Thursday evening it 
> may appear that grenade was failing without reason, but the cause is: 
> https://bugs.launchpad.net/ironic/+bug/1590139
> 
> This bug was fixed in master, but the patch to stable/mitaka had not yet 
> landed. And since Grenade runs tests on stable/mitaka it continued to fail. 
> This morning the patch to fix stable/mitaka landed and the Grenade job is 
> passing again.
> 
> Unfortunately https://bugs.launchpad.net/ironic/+bug/1590139 (which started 
> around 6-June-2016) would cause random Ironic jobs to fail, as only some jobs 
> would get sent to the new Zuul builders. Any job to the new Zuul builders 
> would fail.  So some jobs would pass and some fail for the same patch.
> 
> I did my best to take all of that into account and in my opinion the grenade 
> job is performing reliably. If I can figure out how to extract better 
> statistics I will update this email.
> 
> Please let me know if you have questions or if I'm wrong :)
> 
> Thanks,
> John
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Chris Dent]

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 it is possible to write generic client code
that has a header with a specific name and purpose that can have a
value that works for multiple services and can be coded and talked
about in a generic way.

So in fact the reason the change is a good thing is exactly what you
say: The old way makes it more difficult to handle things in a common
way because you have to seek out lots of different headers. The library
referenced below lets you:

   version = microversion_parse.get_version(headers, service_type='compute')

and get back either the compute microversion, None or an error. Do it
again with 'identity' get back the identity microversion. Etc.

Another point: the old version of the header had "value" information on
both sides of the name value pair. The new version is more general.

Bonus for the lazy at heart (a virtue!): a client can send version
headers for every service being addressed in a suite of tasks in one
fell swoop.

And finally, we knew we needed to update the microversion headers to
get rid of two things which are deprecated:

* using 'X-' on headers
* referring to services by their project name when we should be using
  their service type

So if that change was going to be made anyway, and we wanted to avoid
having lots of miscellaneous headers (see proliferation guideline
below), may as well lump several changes to avoid too much churn and
have a tidy future.

Some potentially useful links:

* a library for parsing various microversion headers out of a variety of
  header representations:
  https://pypi.python.org/pypi/microversion_parse

* header non proliferation guideline:
  
http://specs.openstack.org/openstack/api-wg/guidelines/headers.html#avoid-proliferating-headers

* adding support for the new style to nova:
  * the spec
  
http://specs.openstack.org/openstack/nova-specs/specs/newton/approved/modern-microversions.html
  * nova itself (as I think it was Ed has already pointed out)
  https://review.openstack.org/#/c/300077/
  * novaclient
  https://review.openstack.org/#/c/323362/

I hope some of that is useful.

--
Chris Dent   (╯°□°)╯︵┻━┻http://anticdent.org/
freenode: cdent tw: @anticdent__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[aaronzhu1121]

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
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Clint Byrum]

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 
> > something that makes it more difficult to handle all the different APIs in 
> > a common way.
> >

< moved question to be inline for readability>

> …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
>

Whatever API version is used behind the compute API is none of the user's
business. Nova will support whatever identity API versions it supports,
and if you've passed it something that isn't compatible with the APIs it
knows how to speak, asking for it to support a version that it doesn't
isn't going to change the fact that this is an impossible request already.

That said, I kind of like the idea of specifying the name there for the
one API you are speaking, just in case something goes awry and you try
to send an identity request to compute, it's more clear that this is the
wrong API you're talking to. It's not like it's hard to split a string
on white space.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Henry Nash]

…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 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"  > wrote:
> 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 Keystone).
> 
> On Jun 17, 2016 12:44 PM, "Ed Leafe" > 
> wrote:
> On Jun 17, 2016, at 11:29 AM, Henry Nash  > wrote:
> 
> > We are currently in the process of implementing microversion support in 
> > keystone - and are obviously trying to follow the cross-projec spec for 
> > this 
> > (http://specs.openstack.org/openstack/api-wg/guidelines/microversion_specification.html
> >  
> > ).
> >
> > One thing I noticed was that the header specified in this spec is of the 
> > form:
> >
> > OpenStack-API-Version: [SERVICE_TYPE] [X,Y]
> >
> > for example:
> >
> > OpenStack-API-Version: identity 3.7
> >
> > However, from what i can see of the current implementations I have seen of 
> > microversioning in OpenStack (Nova, Manilla), they use service-specific 
> > headers, e.g.
> >
> > X-OpenStack-Nova-API-Version: 2.12
> >
> > My question is whether there a plan to converge on the generalized header 
> > format….or are we keep with the service-specific headers? I’d obviously 
> > like to implement the correct one for keystone.
> 
> Yes, the plan is to converge on the more generic headers. The Nova headers 
> (don’t know about Manilla) pre-date the API WG spec, and were the motivation 
> for development of that spec. We’ve even made it possible to accept both 
> header formats [0] until things can be migrated to the recommended format.
> 
> [0] https://review.openstack.org/#/c/300077/ 
> 
> 
> -- Ed Leafe
> 
> 
> 
> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe 
> 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe 
> 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Jamie Lennox]

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"  wrote:

> 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 Keystone).
> On Jun 17, 2016 12:44 PM, "Ed Leafe"  wrote:
>
>> On Jun 17, 2016, at 11:29 AM, Henry Nash  wrote:
>>
>> > We are currently in the process of implementing microversion support in
>> keystone - and are obviously trying to follow the cross-projec spec for
>> this (
>> http://specs.openstack.org/openstack/api-wg/guidelines/microversion_specification.html
>> ).
>> >
>> > One thing I noticed was that the header specified in this spec is of
>> the form:
>> >
>> > OpenStack-API-Version: [SERVICE_TYPE] [X,Y]
>> >
>> > for example:
>> >
>> > OpenStack-API-Version: identity 3.7
>> >
>> > However, from what i can see of the current implementations I have seen
>> of microversioning in OpenStack (Nova, Manilla), they use service-specific
>> headers, e.g.
>> >
>> > X-OpenStack-Nova-API-Version: 2.12
>> >
>> > My question is whether there a plan to converge on the generalized
>> header format….or are we keep with the service-specific headers? I’d
>> obviously like to implement the correct one for keystone.
>>
>> Yes, the plan is to converge on the more generic headers. The Nova
>> headers (don’t know about Manilla) pre-date the API WG spec, and were the
>> motivation for development of that spec. We’ve even made it possible to
>> accept both header formats [0] until things can be migrated to the
>> recommended format.
>>
>> [0] https://review.openstack.org/#/c/300077/
>>
>> -- Ed Leafe
>>
>>
>>
>>
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Steve Martinelli]

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 Keystone).
On Jun 17, 2016 12:44 PM, "Ed Leafe"  wrote:

> On Jun 17, 2016, at 11:29 AM, Henry Nash  wrote:
>
> > We are currently in the process of implementing microversion support in
> keystone - and are obviously trying to follow the cross-projec spec for
> this (
> http://specs.openstack.org/openstack/api-wg/guidelines/microversion_specification.html
> ).
> >
> > One thing I noticed was that the header specified in this spec is of the
> form:
> >
> > OpenStack-API-Version: [SERVICE_TYPE] [X,Y]
> >
> > for example:
> >
> > OpenStack-API-Version: identity 3.7
> >
> > However, from what i can see of the current implementations I have seen
> of microversioning in OpenStack (Nova, Manilla), they use service-specific
> headers, e.g.
> >
> > X-OpenStack-Nova-API-Version: 2.12
> >
> > My question is whether there a plan to converge on the generalized
> header format….or are we keep with the service-specific headers? I’d
> obviously like to implement the correct one for keystone.
>
> Yes, the plan is to converge on the more generic headers. The Nova headers
> (don’t know about Manilla) pre-date the API WG spec, and were the
> motivation for development of that spec. We’ve even made it possible to
> accept both header formats [0] until things can be migrated to the
> recommended format.
>
> [0] https://review.openstack.org/#/c/300077/
>
> -- Ed Leafe
>
>
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Joshua Hesketh]

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:

>
>
> On 6/16/16, 6:13 PM, "James E. Blair"  wrote:
>
> >Now that we have retired Jenkins, we have some upcoming changes:
> >
> >* Console logs are now available via TCP
> >
> >  The status page now has "telnet" protocol links to running jobs.  If
> >  you connect to the host and port specified in that link, you will be
> >  sent the console log for that job up to that point in time and it
> >  will continue to stream over that connection in real time.  If your
> >  browser doesn't understand "telnet://" URLs, just grab the host and
> >  port and type "telnet  " or better yet, "nc 
> >  " into your terminal.  You can also grep through in progress
> >  console logs with "nc   | grep ".
> >
> >* Console logs will soon be available over the WWW
> >
> >  Netcatting to Grep is cool, but sometimes if you're already in a
> >  browser, it may be easier to click on a link and have that just open
> >  up in your existing browser.  Monty has been working on a websocket
> >  interface to the console log stream that we hope to have in place
> >  soon.
> >
> >* Zuul will stop using the name "Jenkins"
> >
> >  There is a new user in Gerrit named "Zuul".  Zuul has been
> >  masquerading as Jenkins for the past few years, but now that we no
> >  longer run any software named "Jenkins" it is the right time to
> >  change the name to Zuul.  If you have any programs, scripts,
> >  dashboards, etc, that look for either the full name "Jenkins" or
> >  username "jenkins" from Gerrit, you should immediately update them
> >  to also use the full name "Zuul" or username "zuul" in order to
> >  prepare for the change.
>
> Jim,
>
> Apologies for the confusion on my end, but does this also apply to the
> gate jenkins user?
>
> Thanks
> -steve
>
> >
> >-Jim
> >
> >___
> >OpenStack-Infra mailing list
> >openstack-in...@lists.openstack.org
> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
>
>
> ___
> OpenStack-Infra mailing list
> openstack-in...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev