subject:"\[openstack\-dev\] \[all\]\[api\] POST \/api\-wg\/news"

[openstack-dev] [all][api] POST /api-wg/news

2017-08-10 Thread Chris Dent



308 Permanent Redirect
Location: /api-sig/news

Greetings OpenStack community,

As with last week, today's meeting started off with continued discussion about 
the Guided Review process that we are trying to create ahead of the Denver PTG. 
elmiko continues to shape the proposal in a review [0]. For the most part we're 
all pretty happy with it.

We then moved on to discussing the API-WG becoming API-SIG. Continued email 
discussion [4] has left us feeling like it's a good idea, so we voted to go for 
it. There were some concerns about how this might impact repository and bug 
tracking names, but we felt that we could leave those questions to be addressed 
when they become problems. Over the next few weeks you may see some changes in 
how things are named, but existing behaviors (making guidelines, sending this 
newsletter, having a weekly IRC meeting) will remain.

On the topic of guidance, there's one new work in progress [5] discouraging the 
use of extensions which add URLs to APIs or change the shape of 
representations. As the comments there indicate, this is a tricky topic when 
functionality is impacted either by policy or by the presence of different 
drivers. We haven't fully decided how we're going to explain these issues, but 
we do want to make sure that it is well known that if you are trying to create 
an interoperable API, optional URIs are a bad idea.

# Newly Published Guidelines

None this week.

# API Guidelines Proposed for Freeze

Guidelines that are ready for wider review by the whole community.

None this week

# Guidelines Currently Under Review [3]

* Explain, simply, why extensions are bad
  https://review.openstack.org/#/c/491611/

* A (shrinking) suite of several documents about doing version and service 
discovery
  Start at https://review.openstack.org/#/c/459405/

* WIP: microversion architecture archival doc (very early; not yet ready for 
review)
  https://review.openstack.org/444892

# Highlighting your API impacting issues

If you seek further review and insight from the API WG, please address your concerns in 
an email to the OpenStack developer mailing list[1] with the tag "[api]" in the 
subject. In your email, you should include any relevant reviews, links, and comments to 
help guide the discussion of the specific challenge you are facing.

To learn more about the API WG mission and the work we do, see OpenStack API 
Working Group [2].

Thanks for reading and see you next week!

# References

[0] https://review.openstack.org/#/c/487847/
[1] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[2] http://specs.openstack.org/openstack/api-wg/
[3] https://review.openstack.org/#/q/status:open+project:openstack/api-wg,n,z
[4] http://lists.openstack.org/pipermail/openstack-sigs/2017-August/35.html
[5] https://review.openstack.org/#/c/491611/


Meeting Agenda
https://wiki.openstack.org/wiki/Meetings/API-WG#Agenda
Past Meeting Records
http://eavesdrop.openstack.org/meetings/api_wg/
Open Bugs
https://bugs.launchpad.net/openstack-api-wg

--
Chris Dent  (⊙＿⊙') https://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

[openstack-dev] [all][api] POST /api-wg/news

2017-08-03 Thread Ed Leafe

Greetings OpenStack community,

Today's meeting started off with continued discussion about the Guided Review 
process that we are trying to create ahead of the Denver PTG, where we would 
like to incorporate such a process as part of our sessions. This has been 
crystallized into a document [0] by elmiko. One point that is still to be added 
is how we record discussions after the fact, so that they can be preserved and 
referenced in the future.

The bulk of the meeting was taken up in discussing the proposed change from a 
Working Group (WG) to a Special Interest Group (SIG). This is in response to 
Thierry Carrez's email [4] on the subject. No one had any particularly strong 
feelings either way; I mean, we want to be as useful as possible to as many 
people as possible, but it's simply not clear whether the change to being a SIG 
would a) make that easier, or b) make that more difficult, or c) have no 
effect. In our case, this is also complicated by the fact that we are small, 
and expanding to a wider audience might be too much. Or it may bring in lots of 
new people to help out. We really don't know. We will continue to discuss this 
on the mailing list and future meetings.

There are no new guidelines for this week, but a small update to an existing 
document [5] was merged.


# Newly Published Guidelines

None this week.

# API Guidelines Proposed for Freeze

Guidelines that are ready for wider review by the whole community.

None this week

# Guidelines Currently Under Review [3]

* A (shrinking) suite of several documents about doing version and service 
discovery
  Start at https://review.openstack.org/#/c/459405/

* WIP: microversion architecture archival doc (very early; not yet ready for 
review)
  https://review.openstack.org/444892

# Highlighting your API impacting issues

If you seek further review and insight from the API WG, please address your 
concerns in an email to the OpenStack developer mailing list[1] with the tag 
"[api]" in the subject. In your email, you should include any relevant reviews, 
links, and comments to help guide the discussion of the specific challenge you 
are facing.

To learn more about the API WG mission and the work we do, see OpenStack API 
Working Group [2].

Thanks for reading and see you next week!

# References

[0] https://review.openstack.org/#/c/487847/
[1] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[2] http://specs.openstack.org/openstack/api-wg/
[3] https://review.openstack.org/#/q/status:open+project:openstack/api-wg,n,z
[4] http://lists.openstack.org/pipermail/openstack-sigs/2017-July/22.html
[5] https://review.openstack.org/#/c/487504/

Meeting Agenda
https://wiki.openstack.org/wiki/Meetings/API-WG#Agenda
Past Meeting Records
http://eavesdrop.openstack.org/meetings/api_wg/
Open Bugs
https://bugs.launchpad.net/openstack-api-wg

-- Ed Leafe







signature.asc
Description: Message signed with OpenPGP
__
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-dev] [all][api] POST /api-wg/news

2017-07-27 Thread michael mccune


Greetings OpenStack community,

Today's meeting continued the discussion about the newly posted gerrit 
review for the Guided Review Process[0]. There is still some work to be 
done before the process is in shape to announce for the Denver PTG, but 
the group is confident about having the process in place before the 
event. As we would like to host the first guided reviews in Denver, we 
also briefly discussed the sessions planned for the API-WG at the PTG 
which will be held on Monday and Tuesday.


There are no new guidelines for this week, but a few smaller typo fixes 
have been added for review[4][5] and will be merged soon(TM).


We also briefly discussed the version discovery gudelines proposed by 
mordred and he informed us about some great advances in the keystoneauth 
project that will support this work. Tangentially, he also mentioned 
some of the work happening around the os-service-types library and its 
1.0 release. This is really nice work and will help to advance the state 
of the art for using the service catalog effectively.


# Newly Published Guidelines

None this week.

# API Guidelines Proposed for Freeze

Guidelines that are ready for wider review by the whole community.

None this week

# Guidelines Currently Under Review [3]

* A (shrinking) suite of several documents about doing version and 
service discovery

  Start at https://review.openstack.org/#/c/459405/

* WIP: microversion architecture archival doc (very early; not yet ready 
for review)

  https://review.openstack.org/444892

# Highlighting your API impacting issues

If you seek further review and insight from the API WG, please address 
your concerns in an email to the OpenStack developer mailing list[1] 
with the tag "[api]" in the subject. In your email, you should include 
any relevant reviews, links, and comments to help guide the discussion 
of the specific challenge you are facing.


To learn more about the API WG mission and the work we do, see OpenStack 
API Working Group [2].


Thanks for reading and see you next week!

# References

[0] https://review.openstack.org/#/c/487847/
[1] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[2] http://specs.openstack.org/openstack/api-wg/
[3] 
https://review.openstack.org/#/q/status:open+project:openstack/api-wg,n,z

[4] https://review.openstack.org/#/c/478638/
[5] https://review.openstack.org/#/c/487504/


Meeting Agenda
https://wiki.openstack.org/wiki/Meetings/API-WG#Agenda
Past Meeting Records
http://eavesdrop.openstack.org/meetings/api_wg/
Open Bugs
https://bugs.launchpad.net/openstack-api-wg

__
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-dev] [all][api] POST /api-wg/news

2017-07-20 Thread Chris Dent



Greetings OpenStack community,

Most of the time in today's meeting was dedicated to discussing ideas for the 
Guided Review Process [0] (that link will expire in favor of a gerrit review 
soon) we are considering for the PTG. The idea is that projects which are 
enmeshed in debate over how to correctly follow the guidelines in their APIs 
can come to a process of in-person review at the PTG. All involved can engage 
in the discussion and learn. The exact mechanics are still being worked out. 
The wiki page at [0] is a starting point which will be reviewed and revised on 
gerrit. Our discussion today centered around trying to make sure we can 
actually productively engage with one another.

There's been little activity with regard to guidelines or bugs recently. This 
is mostly because everyone is very busy with other responsibilities. We hope 
things will smooth out soon.

# Newly Published Guidelines

None this week.

# API Guidelines Proposed for Freeze

Guidelines that are ready for wider review by the whole community.

None this week

# Guidelines Currently Under Review [3]

* A (shrinking) suite of several documents about doing version and service 
discovery
  Start at https://review.openstack.org/#/c/459405/

* WIP: microversion architecture archival doc (very early; not yet ready for 
review)
  https://review.openstack.org/444892

# Highlighting your API impacting issues

If you seek further review and insight from the API WG, please address your concerns in 
an email to the OpenStack developer mailing list[1] with the tag "[api]" in the 
subject. In your email, you should include any relevant reviews, links, and comments to 
help guide the discussion of the specific challenge you are facing.

To learn more about the API WG mission and the work we do, see OpenStack API 
Working Group [2].

Thanks for reading and see you next week!

# References

[0] https://wiki.openstack.org/wiki/API_Working_Group/Guided_Review_Process
[1] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[2] http://specs.openstack.org/openstack/api-wg/
[3] https://review.openstack.org/#/q/status:open+project:openstack/api-wg,n,z


Meeting Agenda
https://wiki.openstack.org/wiki/Meetings/API-WG#Agenda
Past Meeting Records
http://eavesdrop.openstack.org/meetings/api_wg/
Open Bugs
https://bugs.launchpad.net/openstack-api-wg

--
Chris Dent  ┬──┬◡ﾉ(° -°ﾉ)   https://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

[openstack-dev] [all][api] POST /api-wg/news

2017-07-13 Thread Ed Leafe

Greetings OpenStack community,

If you missed our meeting today, well, you didn't miss much. Not a lot of new 
things going on. The bulk of the meeting was taken up with ideas for what we'd 
like to accomplish at the upcoming Denver PTG. We thought that it might be 
useful to have an informal "what do you think about our API" session, where 
people from various projects could bring up issues they are concerned about in 
their APIs, and we could then discuss what might be a better approach. The 
initial idea isn't to force anything, but rather to have these discussions 
*before* an API is released, so that there might be fewer problems later on. 
These are still initial working ideas, so we agreed to think this through a bit 
more before next week's meeting. If you have ideas, please let the group know.

# Newly Published Guidelines

None this week.

# API Guidelines Proposed for Freeze

Guidelines that are ready for wider review by the whole community.

None this week

# Guidelines Currently Under Review [3]

* A (shrinking) suite of several documents about doing version and service 
discovery
  Start at https://review.openstack.org/#/c/459405/

* WIP: microversion architecture archival doc (very early; not yet ready for 
review)
  https://review.openstack.org/444892

# Highlighting your API impacting issues

If you seek further review and insight from the API WG, please address your 
concerns in an email to the OpenStack developer mailing list[1] with the tag 
"[api]" in the subject. In your email, you should include any relevant reviews, 
links, and comments to help guide the discussion of the specific challenge you 
are facing.

To learn more about the API WG mission and the work we do, see OpenStack API 
Working Group [2].

Thanks for reading and see you next week!

# References

[1] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[2] http://specs.openstack.org/openstack/api-wg/
[3] https://review.openstack.org/#/q/status:open+project:openstack/api-wg,n,z


Meeting Agenda
https://wiki.openstack.org/wiki/Meetings/API-WG#Agenda
Past Meeting Records
http://eavesdrop.openstack.org/meetings/api_wg/
Open Bugs
https://bugs.launchpad.net/openstack-api-wg

-- Ed Leafe







signature.asc
Description: Message signed with OpenPGP
__
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-dev] [all][api] POST /api-wg/news

2017-07-06 Thread Chris Dent



Greetings OpenStack community,

For the first time in a while, the entire API-WG core was present, along with a 
fly by from mordred. The main topic of conversation was related to a proposed 
cloud profile document [4] including a static version of a thing like the 
service catalog. More discussion and thought will happen on the review but the 
gist is that an authenticated potential user of the cloud should be able to 
inspect what's available. There are no guidelines ready for freeze or merge 
this week.

# Newly Published Guidelines

None this week.

# API Guidelines Proposed for Freeze

Guidelines that are ready for wider review by the whole community.

None this week

# Guidelines Currently Under Review [3]

* A (shrinking) suite of several documents about doing version and service 
discovery
  Start at https://review.openstack.org/#/c/459405/

* WIP: microversion architecture archival doc (very early; not yet ready for 
review)
  https://review.openstack.org/444892

# Highlighting your API impacting issues

If you seek further review and insight from the API WG, please address your concerns in 
an email to the OpenStack developer mailing list[1] with the tag "[api]" in the 
subject. In your email, you should include any relevant reviews, links, and comments to 
help guide the discussion of the specific challenge you are facing.

To learn more about the API WG mission and the work we do, see OpenStack API 
Working Group [2].

Thanks for reading and see you next week!

# References

[1] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[2] http://specs.openstack.org/openstack/api-wg/
[3] https://review.openstack.org/#/q/status:open+project:openstack/api-wg,n,z
[4] https://review.openstack.org/#/c/459869/


Meeting Agenda
https://wiki.openstack.org/wiki/Meetings/API-WG#Agenda
Past Meeting Records
http://eavesdrop.openstack.org/meetings/api_wg/
Open Bugs
https://bugs.launchpad.net/openstack-api-wg

--
Chris Dent  ┬──┬◡ﾉ(° -°ﾉ)   https://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

[openstack-dev] [all][api] POST /api-wg/news

2017-06-29 Thread michael mccune


Greetings OpenStack community,

Today's meeting was slightly longer than last week's, with a few more in 
attendance as well. There were no new major issues brought up and the 
main topics were last week's frozen change[4] and a few minor 
fixes[5][6] in the queue now. These fixes were considered trivial and 
have been merged.


# Newly Published Guidelines

* Microversions: add next_min_version field in version body
  https://review.openstack.org/#/c/446138/

# Newly published typo fixes

* Fix html_last_updated_fmt for Python3
  https://review.openstack.org/475219

* Fix missing close bracket
  https://review.openstack.org/#/c/478603/

# API Guidelines Proposed for Freeze

Guidelines that are ready for wider review by the whole community.

None this week

# Guidelines Currently Under Review [3]

* A (shrinking) suite of several documents about doing version discovery
  Start at https://review.openstack.org/#/c/459405/

* WIP: microversion architecture archival doc (very early; not yet ready 
for review)

  https://review.openstack.org/444892

# Highlighting your API impacting issues

If you seek further review and insight from the API WG, please address 
your concerns in an email to the OpenStack developer mailing list[1] 
with the tag "[api]" in the subject. In your email, you should include 
any relevant reviews, links, and comments to help guide the discussion 
of the specific challenge you are facing.


To learn more about the API WG mission and the work we do, see OpenStack 
API Working Group [2].


Thanks for reading and see you next week!

# References

[1] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[2] http://specs.openstack.org/openstack/api-wg/
[3] 
https://review.openstack.org/#/q/status:open+project:openstack/api-wg,n,z

[4] https://review.openstack.org/#/c/446138/
[5] https://review.openstack.org/#/c/475219/
[6] https://review.openstack.org/#/c/478603/

Meeting Agenda
https://wiki.openstack.org/wiki/Meetings/API-WG#Agenda
Past Meeting Records
http://eavesdrop.openstack.org/meetings/api_wg/
Open Bugs
https://bugs.launchpad.net/openstack-api-wg

__
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-dev] [all][api] POST /api-wg/news

2017-06-22 Thread Edward Leafe

Greetings OpenStack community,

Today's meeting was even shorter and sweeter than last week's, as only edleafe 
was present, due to cdent being on PTO and elmiko being on the road. Prior to 
the meeting, though, we had decided that the guideline change for raising the 
minimum microversion was ready for freeze, and so it was indeed frozen. Other 
than that, there really is nothing else to report.

# Newly Published Guidelines

None this week

# API Guidelines Proposed for Freeze

Guidelines that are ready for wider review by the whole community.

* Microversions: add next_min_version field in version body
  https://review.openstack.org/#/c/446138/

# Guidelines Currently Under Review [3]

* A (shrinking) suite of several documents about doing version discovery
  Start at https://review.openstack.org/#/c/459405/

* Fix html_last_updated_fmt for Python3
  https://review.openstack.org/475219

* WIP: microversion architecture archival doc (very early; not yet ready for 
review)
  https://review.openstack.org/444892

# Highlighting your API impacting issues

If you seek further review and insight from the API WG, please address your 
concerns in an email to the OpenStack developer mailing list[1] with the tag 
"[api]" in the subject. In your email, you should include any relevant reviews, 
links, and comments to help guide the discussion of the specific challenge you 
are facing.

To learn more about the API WG mission and the work we do, see OpenStack API 
Working Group [2].

Thanks for reading and see you next week!

# References

[1] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[2] http://specs.openstack.org/openstack/api-wg/
[3] https://review.openstack.org/#/q/status:open+project:openstack/api-wg,n,z

Meeting Agenda
https://wiki.openstack.org/wiki/Meetings/API-WG#Agenda
Past Meeting Records
http://eavesdrop.openstack.org/meetings/api_wg/
Open Bugs
https://bugs.launchpad.net/openstack-api-wg

-- 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-dev] [all][api] POST /api-wg/news

2017-06-15 Thread Chris Dent



Greetings OpenStack community,

Today's meeting was short and sweet. We merged some frozen reivews (see below) and 
determined that other pending reviews are still pending. The survey to get some feedback 
on how to express the earliest possible date a microversion might raise didn't get a ton 
of votes, but those votes that did happen suggest that the original 
"not_before" is the least worst choice.

# Newly Published Guidelines

The following reviews have all merged

* Add guideline about consuming endpoints from catalog
  https://review.openstack.org/#/c/462814/

* Add support for historical service type aliases
  https://review.openstack.org/#/c/460654/

* Describe the publication of service-types-authority data
  https://review.openstack.org/#/c/462815/

They all modified the same document, resulting in: 
http://specs.openstack.org/openstack/api-wg/guidelines/consuming-catalog.html

# API Guidelines Proposed for Freeze

Guidelines that are ready for wider review by the whole community.

None this week.

# Guidelines Currently Under Review [3]

* Microversions: add next_min_version field in version body
  https://review.openstack.org/#/c/446138/

* A (shrinking) suite of several documents about doing version discovery
  Start at https://review.openstack.org/#/c/459405/

* WIP: microversion architecture archival doc (very early; not yet ready for 
review)
  https://review.openstack.org/444892

# Highlighting your API impacting issues

If you seek further review and insight from the API WG, please address your concerns in 
an email to the OpenStack developer mailing list[1] with the tag "[api]" in the 
subject. In your email, you should include any relevant reviews, links, and comments to 
help guide the discussion of the specific challenge you are facing.

To learn more about the API WG mission and the work we do, see OpenStack API 
Working Group [2].

Thanks for reading and see you next week!

# References

[1] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[2] http://specs.openstack.org/openstack/api-wg/
[3] https://review.openstack.org/#/q/status:open+project:openstack/api-wg,n,z

Meeting Agenda
https://wiki.openstack.org/wiki/Meetings/API-WG#Agenda
Past Meeting Records
http://eavesdrop.openstack.org/meetings/api_wg/
Open Bugs
https://bugs.launchpad.net/openstack-api-wg

--
Chris Dent  ┬──┬◡ﾉ(° -°ﾉ)   https://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] [all][api] POST /api-wg/news

2017-06-08 Thread Edward Leafe

On Jun 8, 2017, at 11:59 AM, Chris Dent  wrote:
> 
> The naming issue related to an optional field we want to add to the 
> microversion discovery document. Some projects wish to be able to signal that 
> they are intending to raise the minimum microversion at a point in the 
> future. The name for the next minimum version is fairly clear: 
> "next_min_version". What's less clear is the name which can be used for the 
> field that states the earliest date at which this will happen. This cannot be 
> a definitive date because different deployments will release the new code at 
> different times. We can only say "it will be no earlier than this time".
> 
> Naming this field has proven difficult. The original was "not_before", but 
> that has no association with "min_version" so is potentially confusing. 
> However, people who know how to parse the doc will know what it means so it 
> may not matter. As always, naming is hard, so we seek input from the 
> community to help us find a suitable name. This is something we don't want to 
> ever have to change, so it needs to be correct from the start. Candidates 
> include:
> 
> * not_before
> * not_raise_min_before
> * min_raise_not_before
> * earliest_min_raise_date
> * min_version_eol_date
> * next_min_version_effective_date
> 
> If you have an opinion on any of these, or a better suggestion please let us 
> know, either on the review at  >, or in response to this message.


Even better: please respond on the SurveyMonkey page to rank your preferences!

https://www.surveymonkey.com/r/L7XWNG5 



-- 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-dev] [all][api] POST /api-wg/news

2017-06-08 Thread Chris Dent



Greetings OpenStack community,

Today's meeting was mostly devoted to two topics: Which of Monty's several 
patches were ready for freeze and some naming issues with raising the minimum 
microversion.

We decided three of Monty's patches are ready, they are listed below in the 
"Freeze" section.

The naming issue related to an optional field we want to add to the microversion discovery 
document. Some projects wish to be able to signal that they are intending to raise the minimum 
microversion at a point in the future. The name for the next minimum version is fairly clear: 
"next_min_version". What's less clear is the name which can be used for the field that 
states the earliest date at which this will happen. This cannot be a definitive date because 
different deployments will release the new code at different times. We can only say "it will 
be no earlier than this time".

Naming this field has proven difficult. The original was "not_before", but that has no 
association with "min_version" so is potentially confusing. However, people who know how 
to parse the doc will know what it means so it may not matter. As always, naming is hard, so we 
seek input from the community to help us find a suitable name. This is something we don't want to 
ever have to change, so it needs to be correct from the start. Candidates include:

* not_before
* not_raise_min_before
* min_raise_not_before
* earliest_min_raise_date
* min_version_eol_date
* next_min_version_effective_date

If you have an opinion on any of these, or a better suggestion please let us know, 
either on the review at , or in 
response to this message.

# Newly Published Guidelines

Nothing new at this time.

# API Guidelines Proposed for Freeze

Guidelines that are ready for wider review by the whole community.

* Add guideline about consuming endpoints from catalog
  https://review.openstack.org/#/c/462814/

* Add support for historical service type aliases
  https://review.openstack.org/#/c/460654/

* Describe the publication of service-types-authority data
  https://review.openstack.org/#/c/462815/

# Guidelines Currently Under Review [3]

* Microversions: add next_min_version field in version body
  https://review.openstack.org/#/c/446138/

* A suite of several documents about doing version discovery
  Start at https://review.openstack.org/#/c/459405/

* WIP: microversion architecture archival doc (very early; not yet ready for 
review)
  https://review.openstack.org/444892

# Highlighting your API impacting issues

If you seek further review and insight from the API WG, please address your concerns in 
an email to the OpenStack developer mailing list[1] with the tag "[api]" in the 
subject. In your email, you should include any relevant reviews, links, and comments to 
help guide the discussion of the specific challenge you are facing.

To learn more about the API WG mission and the work we do, see OpenStack API 
Working Group [2].

Thanks for reading and see you next week!

# References

[1] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[2] http://specs.openstack.org/openstack/api-wg/
[3] https://review.openstack.org/#/q/status:open+project:openstack/api-wg,n,z
[4] Start at https://review.openstack.org/#/c/462814/
[5] https://review.openstack.org/#/c/446138/


Meeting Agenda
https://wiki.openstack.org/wiki/Meetings/API-WG#Agenda
Past Meeting Records
http://eavesdrop.openstack.org/meetings/api_wg/
Open Bugs
https://bugs.launchpad.net/openstack-api-wg

--
Chris Dent  ┬──┬◡ﾉ(° -°ﾉ)   https://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

[openstack-dev] [all][api] POST /api-wg/news

2017-06-01 Thread Ed Leafe

Greetings OpenStack community,

A very lively meeting today, with all the participants in a seemingly jovial 
mood. Must be something in the water. Or maybe June just brings out 
lightheartedness.

Much of the discussion centered on Monty Taylor's chain of patches [4] 
regarding version discovery and the service catalog. No controversy about them, 
but some grumbling over the sheer volume of content. This isn't a complaint; 
rather, I think we are in awe of the size of the brain dump as Monty shares his 
accumulated knowledge. We can use some help reviewing these, so that they are 
as understandable as such esoteric material can possibly be.

We also discussed the proposed change to the microversions guideline about how 
to signal an upcoming raising of the minimum version [5]. There was agreement 
that having such a signal was a good thing, but there is still some confusion 
about how to communicate when this change will happen. The idea is that it 
isn't enough to say that it's going to be raised; it's also important to 
communicate how long a user has to update their code to handle this raising. We 
came up with adding a field that states the earliest possible date of the 
change, with the understanding that it could happen later than that. This was 
to help users get an idea of the urgency of the change. So while we can agree 
on that, as usual it is the naming of the field that is problematic. The 
current choice is 'not_raise_min_before', but we're open to improvements. Let 
the bikeshedding begin!

# Newly Published Guidelines

Nothing new at this time.

# API Guidelines Proposed for Freeze

Guidelines that are ready for wider review by the whole community.

None at this time but please check out the reviews below.

# Guidelines Currently Under Review [3]

* Microversions: add next_min_version field in version body
  https://review.openstack.org/#/c/446138/

* A suite of several documents about using the service catalog and doing 
version discovery
  Start at https://review.openstack.org/#/c/462814/

* WIP: microversion architecture archival doc (very early; not yet ready for 
review)
  https://review.openstack.org/444892

# Highlighting your API impacting issues

If you seek further review and insight from the API WG, please address your 
concerns in an email to the OpenStack developer mailing list[1] with the tag 
"[api]" in the subject. In your email, you should include any relevant reviews, 
links, and comments to help guide the discussion of the specific challenge you 
are facing.

To learn more about the API WG mission and the work we do, see OpenStack API 
Working Group [2].

Thanks for reading and see you next week!

# References

[1] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[2] http://specs.openstack.org/openstack/api-wg/
[3] https://review.openstack.org/#/q/status:open+project:openstack/api-wg,n,z
[4] Start at https://review.openstack.org/#/c/462814/
[5] https://review.openstack.org/#/c/446138/


Meeting Agenda
https://wiki.openstack.org/wiki/Meetings/API-WG#Agenda
Past Meeting Records
http://eavesdrop.openstack.org/meetings/api_wg/
Open Bugs
https://bugs.launchpad.net/openstack-api-wg


-- Ed Leafe







signature.asc
Description: Message signed with OpenPGP
__
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-dev] [all][api] POST /api-wg/news

2017-05-25 Thread michael mccune


Greetings OpenStack community,

Today was a relatively short meeting with most the time being devoted to 
a discussion of Monty Taylor's document chain regarding using the 
service catalog for version discovery[4]. The group was largely in 
agreement that work is proceeding well and with a few more minor tweaks 
should be ready for freeze.


We also discussed a plan[5] to create a new mailing list targetted at 
users, developers, and operators who consume the OpenStack APIs and have 
a higher degree of interest in helping to shape them from an SDK 
perspective. This was welcomed as a "good thing"(TM), and everyone seemd 
to agree that having a space for people to discuss SDK and API related 
issues specifically is a nice step forward.


Finally, we had a small side-track discussing Sean Dague's progress[6] 
on the global request ID implementation efforts. This seems like great 
work that will help improve the state of tracking and monitoring within 
OpenStack.


# Newly Published Guidelines

Nothing new at this time.

# API Guidelines Proposed for Freeze

Guidelines that are ready for wider review by the whole community.

None at this time but please check out the reviews below.

# Guidelines Currently Under Review [3]

* Microversions: add next_min_version field in version body
  https://review.openstack.org/#/c/446138/

* A suite of several documents about using the service catalog and doing 
version discovery

  Start at https://review.openstack.org/#/c/462814/

* WIP: microversion architecture archival doc (very early; not yet ready 
for review)

  https://review.openstack.org/444892

# Highlighting your API impacting issues

If you seek further review and insight from the API WG, please address 
your concerns in an email to the OpenStack developer mailing list[1] 
with the tag "[api]" in the subject. In your email, you should include 
any relevant reviews, links, and comments to help guide the discussion 
of the specific challenge you are facing.


To learn more about the API WG mission and the work we do, see OpenStack 
API Working Group [2].


Thanks for reading and see you next week!

# References

[1] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[2] http://specs.openstack.org/openstack/api-wg/
[3] 
https://review.openstack.org/#/q/status:open+project:openstack/api-wg,n,z

[4] Start at https://review.openstack.org/#/c/462814/
[5] https://review.openstack.org/#/c/468046/
[6] http://lists.openstack.org/pipermail/openstack-dev/2017-May/117367.html


Meeting Agenda
https://wiki.openstack.org/wiki/Meetings/API-WG#Agenda
Past Meeting Records
http://eavesdrop.openstack.org/meetings/api_wg/
Open Bugs
https://bugs.launchpad.net/openstack-api-wg

__
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-dev] [all][api] POST /api-wg/news

2017-05-18 Thread Chris Dent



Greetings OpenStack community,

A short meeting today, mostly reflecting on the Birds of a Feather session [4] 
at Summit last week. It was well attended and engendered plenty of good 
discussion. There are notes on an etherpad at 
https://etherpad.openstack.org/p/BOS-API-WG-BOF that continue to be digested. 
One of the main takeaways was the group should work with people creating 
documentation (api-ref and otherwise) to encourage linking from those documents 
to the guidelines [2]. This will help to explain why some things are the way 
they are (for example microversions) and also highlight a path whereby people 
can contribute to improving or clarifying the guidelines.

Working on that linking will be an ongoing effort. In the meantime the primary 
action for the group (and anyone else interested in API consistency) is to 
review Monty's efforts to document client side interactions with the service 
catalog and version discovery (linked below).

# Newly Published Guidelines

Nothing new at this time.

# API Guidelines Proposed for Freeze

Guidelines that are ready for wider review by the whole community.

None at this time but please check out the reviews below.

# Guidelines Currently Under Review [3]

* Microversions: add next_min_version field in version body
  https://review.openstack.org/#/c/446138/

* A suite of several documents about using the service catalog and doing 
version discovery
  Start at https://review.openstack.org/#/c/462814/

* WIP: microversion architecture archival doc (very early; not yet ready for 
review)
  https://review.openstack.org/444892

# Highlighting your API impacting issues

If you seek further review and insight from the API WG, please address your concerns in 
an email to the OpenStack developer mailing list[1] with the tag "[api]" in the 
subject. In your email, you should include any relevant reviews, links, and comments to 
help guide the discussion of the specific challenge you are facing.

To learn more about the API WG mission and the work we do, see OpenStack API 
Working Group [2].

Thanks for reading and see you next week!

# References

[1] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[2] http://specs.openstack.org/openstack/api-wg/
[3] https://review.openstack.org/#/q/status:open+project:openstack/api-wg,n,z
[4] 
https://www.openstack.org/summit/boston-2017/summit-schedule/events/18679/api-working-group-update-and-bof

Meeting Agenda
https://wiki.openstack.org/wiki/Meetings/API-WG#Agenda
Past Meeting Records
http://eavesdrop.openstack.org/meetings/api_wg/
Open Bugs
https://bugs.launchpad.net/openstack-api-wg

--
Chris Dent  ┬──┬◡ﾉ(° -°ﾉ)   https://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

[openstack-dev] [all][api] POST /api-wg/news

2017-05-04 Thread Chris Dent

Greetings OpenStack community,

Small group today, mostly edleafe and I (cdent) speaking to one another, with
the ghostly presence of dtantsur lurking nearby. Main action today is that we
finally merged the Interoperability Guideline (links below). It took months of
sometimes heated discussion to reach a consensus, but we have one now. The
other big change in play is a series related to version discovery and effective
use of service types.

elmiko and I will be at summit, hosting an API-WG BOF session [4]. Please
attend if you have the time and interest.

There will be no API-WG meeting 11th of May. We'll return to normal business on
the 18th.

# Newly Published Guidelines

* Create a set of api interoperability guidelines from
https://review.openstack.org/#/c/421846/ to be published at
http://specs.openstack.org/openstack/api-wg/guidelines/api_interoperability.html
eventually.

# API Guidelines Proposed for Freeze

Guidelines that are ready for wider review by the whole community.

None at this time but please check out the review below.

# Guidelines Currently Under Review [3]

* Microversions: add next_min_version field in version body
https://review.openstack.org/#/c/446138/

* A suite of five documents about version discovery.
Start at https://review.openstack.org/#/c/459405/

* Support for historical service type aliases
https://review.openstack.org/#/c/460654/3

* WIP: microversion architecture archival doc (very early; not yet ready for
review)
https://review.openstack.org/444892

# Highlighting your API impacting issues

If you seek further review and insight from the API WG, please address your concerns in
an email to the OpenStack developer mailing list[1] with the tag "[api]" in the
subject. In your email, you should include any relevant reviews, links, and comments to
help guide the discussion of the specific challenge you are facing.

To learn more about the API WG mission and the work we do, see OpenStack API
Working Group [2].

Thanks for reading and see you next week!

# References

[1] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[2] http://specs.openstack.org/openstack/api-wg/
[3] https://review.openstack.org/#/q/status:open+project:openstack/api-wg,n,z
[4]
https://www.openstack.org/summit/boston-2017/summit-schedule/events/18679/api-working-group-update-and-bof

Meeting Agenda
https://wiki.openstack.org/wiki/Meetings/API-WG#Agenda
Past Meeting Records
http://eavesdrop.openstack.org/meetings/api_wg/
Open Bugs
https://bugs.launchpad.net/openstack-api-wg

--
Chris Dent ┬──┬◡ﾉ(° -°ﾉ) https://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

[openstack-dev] [all][api] POST /api-wg/news

2017-04-27 Thread Chris Dent



Greetings OpenStack community,

We were joined today by mordred who introduced a stack of documents that describe the 
current state of API version discovery, some of the hoops required to do it today, and 
the clean way to do it henceforth. There is a ton of information in these proposals 
(linked below in the "Under Review" section).

We also discussed how there was only a very light response to edleafe's plea 
for people to update the API-WG liaisons [0]. There's not a lot we can do about 
this. We'll correct what we know to correct and while we are all fans of active 
consensus we'll accept passive agreement.

elmiko and I (cdent) will be at summit, hosting an API-WG BOF session [4]. 
Please attend if you have the time and interest.

# Newly Published Guidelines

* "Define pagination guidelines" from https://review.openstack.org/#/c/446716/  
merged into 
http://specs.openstack.org/openstack/api-wg/guidelines/pagination_filter_sort.html
* "Recommend the correct HTTP method for tags" from 
https://review.openstack.org/#/c/451536/ merged into 
http://specs.openstack.org/openstack/api-wg/guidelines/tags.html and 
http://specs.openstack.org/openstack/api-wg/guidelines/http.html

# API Guidelines Proposed for Freeze

Guidelines that are ready for wider review by the whole community.

* Create a set of api interoperability guidelines: 
https://review.openstack.org/#/c/421846/
  This had been frozen before but it was referring to another guideline that 
will not merge for a while so we took that reference out.

# Guidelines Currently Under Review [3]

* Microversions: add next_min_version field in version body
  https://review.openstack.org/#/c/446138/

* A suite of five documents about version discovery.
  Start at https://review.openstack.org/#/c/459405/

* WIP: microversion architecture archival doc (very early; not yet ready for 
review)
  https://review.openstack.org/444892

# Highlighting your API impacting issues

If you seek further review and insight from the API WG, please address your concerns in 
an email to the OpenStack developer mailing list[1] with the tag "[api]" in the 
subject. In your email, you should include any relevant reviews, links, and comments to 
help guide the discussion of the specific challenge you are facing.

To learn more about the API WG mission and the work we do, see OpenStack API 
Working Group [2].

Thanks for reading and see you next week!

# References

[0] http://lists.openstack.org/pipermail/openstack-dev/2017-April/115921.html
[1] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[2] http://specs.openstack.org/openstack/api-wg/
[3] https://review.openstack.org/#/q/status:open+project:openstack/api-wg,n,z
[4] 
https://www.openstack.org/summit/boston-2017/summit-schedule/events/18679/api-working-group-update-and-bof

Meeting Agenda
https://wiki.openstack.org/wiki/Meetings/API-WG#Agenda
Past Meeting Records
http://eavesdrop.openstack.org/meetings/api_wg/
Open Bugs
https://bugs.launchpad.net/openstack-api-wg

--
Chris Dent  ┬──┬◡ﾉ(° -°ﾉ)   https://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

[openstack-dev] [all][api] POST /api-wg/news

2017-04-20 Thread Ed Leafe

Greetings OpenStack community,

A bit of a lonely meeting today, as only cdent and edleafe were present for 
most of it, although having elmiko join at the end brightened all of our days. 
The main item of discussion was the status of the various project liaisons to 
the API WG [0], and how to handle that. edleafe agreed to ping the current 
liaisons to get an update as to their status.

Due to the lack of feeback from the liaisons, we agreed to postpone merging the 
three frozen guidelines for another week to make sure that there are no 
objections. After all, it was Easter and all, so perhaps lots of people are in 
chocolate-induced comas.

# Newly Published Guidelines

Nothing new this week.

# API Guidelines Proposed for Freeze

Guidelines that are ready for wider review by the whole community.

* Define pagination guidelines
  https://review.openstack.org/#/c/446716/

* Create a set of api interoperability guidelines
  https://review.openstack.org/#/c/421846/

* Recommend the correct HTTP method for tags
  https://review.openstack.org/451536

# Guidelines Currently Under Review [3]

* Microversions: add next_min_version field in version body
  https://review.openstack.org/#/c/446138/

* Mention max length limit information for tags
  https://review.openstack.org/#/c/447344/

* Add API capabilities discovery guideline
  https://review.openstack.org/#/c/386555/
  On hold.

* WIP: microversion architecture archival doc (very early; not yet ready for 
review)
  https://review.openstack.org/444892

# Highlighting your API impacting issues

If you seek further review and insight from the API WG, please address your 
concerns in an email to the OpenStack developer mailing list[1] with the tag 
"[api]" in the subject. In your email, you should include any relevant reviews, 
links, and comments to help guide the discussion of the specific challenge you 
are facing.

To learn more about the API WG mission and the work we do, see OpenStack API 
Working Group [2].

Thanks for reading and see you next week!

# References

[0] http://lists.openstack.org/pipermail/openstack-dev/2017-April/115723.html
[1] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[2] http://specs.openstack.org/openstack/api-wg/
[3] https://review.openstack.org/#/q/status:open+project:openstack/api-wg,n,z

Meeting Agenda
https://wiki.openstack.org/wiki/Meetings/API-WG#Agenda
Past Meeting Records
http://eavesdrop.openstack.org/meetings/api_wg/
Open Bugs
https://bugs.launchpad.net/openstack-api-wg

-- Ed Leafe







signature.asc
Description: Message signed with OpenPGP
__
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-dev] [all][api] POST /api-wg/news

2017-04-13 Thread michael mccune


Greetings OpenStack community,

This week's meeting was lightly attended but provided a useful 
discussion about the future of the working group and how we will 
continue to improve the API experience for all OpenStack users. The 
group is considering its role with respect to the guidelines that it 
creates and how to not only increase our membership but also explore 
other options for improving the overall state of API usability and 
consistency within OpenStack. Although no firm actions have resulted 
from this discussion, we have agreed to keep the topic open, have more 
face to face conversations about it at the upcoming forum event, and to 
reach out to other working groups with the intent to learn more about 
community expectations and usages with regards to the APIs in OpenStack.


# Newly Published Guidelines

Nothing new this week.

# API Guidelines Proposed for Freeze

Guidelines that are ready for wider review by the whole community.

* Define pagination guidelines
  https://review.openstack.org/#/c/446716/

* Create a set of api interoperability guidelines
  https://review.openstack.org/#/c/421846/

* Recommend the correct HTTP method for tags
  https://review.openstack.org/451536

# Guidelines Currently Under Review [3]

* Microversions: add next_min_version field in version body
  https://review.openstack.org/#/c/446138/

* Mention max length limit information for tags
  https://review.openstack.org/#/c/447344/

* Add API capabilities discovery guideline
  https://review.openstack.org/#/c/386555/
  On hold.

* WIP: microversion architecture archival doc (very early; not yet ready 
for review)

  https://review.openstack.org/444892

# Highlighting your API impacting issues

If you seek further review and insight from the API WG, please address 
your concerns in an email to the OpenStack developer mailing list[1] 
with the tag "[api]" in the subject. In your email, you should include 
any relevant reviews, links, and comments to help guide the discussion 
of the specific challenge you are facing.


To learn more about the API WG mission and the work we do, see OpenStack 
API Working Group [2].


Thanks for reading and see you next week!

# References

[1] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[2] http://specs.openstack.org/openstack/api-wg/
[3] 
https://review.openstack.org/#/q/status:open+project:openstack/api-wg,n,z


Meeting Agenda
https://wiki.openstack.org/wiki/Meetings/API-WG#Agenda
Past Meeting Records
http://eavesdrop.openstack.org/meetings/api_wg/
Open Bugs
https://bugs.launchpad.net/openstack-api-wg

__
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-dev] [all][api] POST /api-wg/news

2017-04-06 Thread Chris Dent

Greetings OpenStack community,

In today's API-WG meeting we renamed the group twice. First to the "microversion support group".
This is because any conversation that is even tangentially related to microversions becomes rather involved,
leaking into metaphysics. Today involved some discussion on when a new or experimental service might like to
turn them on (if they ever plan to do so). The advice here is to implement version discovery and versioning
from the outset but don't start regularly bumping versions until after there has been an official release.
There's some discussion of this topic in the interoperability guideline (linked below), which also happens to
have been renamed (from "compatibility" to "interoperability").

The second group rename was to "Human Programming Interface Working Group" due
to a discussion on whether to use a 404 or 400 in the case of a bad marker when doing
pagination on a collection (guideline also linked below). 404 can be interpreted as
strictly correct, especially from the standpoint of thinking of URIs as relatively
strongly typed things. 400 may make more sense, however, to humans.

Both of these guidelines are subject to some debate, so if you have thoughts
about them, do everyone a great favor and provide your input.

Thanks to members of the Sahara project for coming to speak with the API-WG, it
made for some very interesting and fun discussions. We hope we were able to
provide some useful input.

# Newly Published Guidelines

Nothing new this week.

# API Guidelines Proposed for Freeze

Guidelines that are ready for wider review by the whole community.

None this week, although the pagination guideline below is close.

# Guidelines Currently Under Review [3]

* Define pagination guidelines
https://review.openstack.org/#/c/446716/
Stuck on whether to use 400 or 404.

* Create a set of api interoperability guidelines
https://review.openstack.org/#/c/421846/
This has been renamed to indicate its focus more clearly.

* Microversions: add next_min_version field in version body
https://review.openstack.org/#/c/446138/

* Mention max length limit information for tags
https://review.openstack.org/#/c/447344/

* Recommend the correct HTTP method for tags
https://review.openstack.org/451536
Very close but needs more eyes.

* Add API capabilities discovery guideline
https://review.openstack.org/#/c/386555/
On hold.

* WIP: microversion architecture archival doc (very early; not yet ready for
review)
https://review.openstack.org/444892

# Highlighting your API impacting issues

To learn more about the API WG mission and the work we do, see OpenStack API
Working Group [2].

Thanks for reading and see you next week!

# References

[1] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[2] http://specs.openstack.org/openstack/api-wg/
[3] https://review.openstack.org/#/q/status:open+project:openstack/api-wg,n,z

Meeting Agenda
https://wiki.openstack.org/wiki/Meetings/API-WG#Agenda
Past Meeting Records
http://eavesdrop.openstack.org/meetings/api_wg/
Open Bugs
https://bugs.launchpad.net/openstack-api-wg

--
Chris Dent ¯\_(ツ)_/¯ https://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

[openstack-dev] [all][api] POST /api-wg/news

2017-03-30 Thread Ed Leafe

Greetings OpenStack community,

Well, today's meeting was very brief. For the longest time, edleafe had the 
room to himself, and breezed through the prepared topics, until stevelle showed 
up. We had a good discussion about the stability guidelines and some of the 
issues in resolving the two different viewpoints. What came out of our 
discussion was the realization that these viewpoints weren't simply a matter of 
degree of strictness, but rather two different things: APIs that are stable to 
"robust" clients, and APIs that support cloud interoperability. So maybe the 
reason we have been having a hard time reaching agreement or compromise is that 
the two concepts are not congruent. edleafe agreed to try to write a blog post 
about this, so check out his blog [4] in the next day or so in case he actually 
does what he says he'll do.

# Newly Published Guidelines

Nothing new this week.

# API Guidelines Proposed for Freeze

Guidelines that are ready for wider review by the whole community.

None this week, although the pagination guideline below is close.

# Guidelines Currently Under Review [3]

* Define pagination guidelines
  https://review.openstack.org/#/c/446716/

* Create a new set of api stability guidelines
  https://review.openstack.org/#/c/421846/

* Microversions: add next_min_version field in version body
  https://review.openstack.org/#/c/446138/

* Mention max length limit information for tags
  https://review.openstack.org/#/c/447344/

* Add API capabilities discovery guideline
  https://review.openstack.org/#/c/386555/

* Recommend the correct HTTP method for tags
  https://review.openstack.org/451536

* Clarify the meaning of BODY (trivial fix)
  https://review.openstack.org/451568

* WIP: microversion architecture archival doc (very early; not yet ready for 
review)
  https://review.openstack.org/444892

# Highlighting your API impacting issues

If you seek further review and insight from the API WG, please address your 
concerns in an email to the OpenStack developer mailing list[1] with the tag 
"[api]" in the subject. In your email, you should include any relevant reviews, 
links, and comments to help guide the discussion of the specific challenge you 
are facing.

To learn more about the API WG mission and the work we do, see OpenStack API 
Working Group [2].

Thanks for reading and see you next week!

# References

[1] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[2] http://specs.openstack.org/openstack/api-wg/
[3] https://review.openstack.org/#/q/status:open+project:openstack/api-wg,n,z
[4] https://blog.leafe.com

Meeting Agenda
https://wiki.openstack.org/wiki/Meetings/API-WG#Agenda
Past Meeting Records
http://eavesdrop.openstack.org/meetings/api_wg/
Open Bugs
https://bugs.launchpad.net/openstack-api-wg


-- Ed Leafe







signature.asc
Description: Message signed with OpenPGP
__
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-dev] [all][api] POST /api-wg/news

2017-03-23 Thread Chris Dent

Greetings OpenStack community,

An after an initially slow start, today's meeting turned into a rollicking good
time. Probably because we talked about microversions.

First we discussed the need to clarify that the API-WG is governed by TC
(Technical Committee) not the UC (User Committee). The rule of thumb for
working groups is: did you go to the PTG or the Ops Meetup. We went to the PTG
and had two very productive days. Over the next few days we'll find the bits of
documentation that need to be cleared up and make sure pointers point the right
places.

We then discussed whether the point of the API-WG is the guidelines it creates
or the discussions that lead to the creation of those guidelines and the
overall better understanding of how to achieve consistency and correctness in
OpenStack APIs. What was first thought of as a fairly simple question turned
into a spirited debate spiralling out to a plan to audit the API-WG's mission
statement [2] for its own consistency and correctness. elmiko has the ball for
that, but since he'll be away next week we won't pick it up until the week
following.

We moved on from there to talk about the stability guidelines (linked in under
review below). We're getting very close, but are stuck on whether it is
worthwhile including some information about alternatives (either expressing
them as true alternatives, or explaining why they won't work). edleafe and
mugsie are going to work to bring this to a close next week. If you are
interested in this topic the logs at
http://eavesdrop.openstack.org/meetings/api_wg/2017/api_wg.2017-03-23-16.00.log.html#l-116
may be worth a look.

This summary does not do justice to the level of investment and interest that
was present in today's meeting. Thanks to everyone who showed up.

# Newly Published Guidelines

Nothing new this week.

# API Guidelines Proposed for Freeze

Guidelines that are ready for wider review by the whole community. Nothing at
the moment, but feel free to get in early on the reviews below.

# Guidelines Currently Under Review [3]

* Define pagination guidelines (recently rebooted)
https://review.openstack.org/#/c/446716/

* Create a new set of api stability guidelines
https://review.openstack.org/#/c/421846/

* Microversions: add next_min_version field in version body
https://review.openstack.org/#/c/446138/

* Mention max length limit information for tags
https://review.openstack.org/#/c/447344/

* Add API capabilities discovery guideline
https://review.openstack.org/#/c/386555/

* WIP: microversion architecture archival doc (very early; not yet ready for
review)
https://review.openstack.org/444892

# Highlighting your API impacting issues

To learn more about the API WG mission and the work we do, see OpenStack API
Working Group [2].

Thanks for reading and see you next week!

# References

[1] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[2] http://specs.openstack.org/openstack/api-wg/
[3] https://review.openstack.org/#/q/status:open+project:openstack/api-wg,n,z

Meeting Agenda
https://wiki.openstack.org/wiki/Meetings/API-WG#Agenda
Past Meeting Records
http://eavesdrop.openstack.org/meetings/api_wg/
Open Bugs
https://bugs.launchpad.net/openstack-api-wg

[openstack-dev] [all][api] POST /api-wg/news

2017-03-16 Thread Ed Leafe

Greetings OpenStack community,

Today's meeting was short and sweet. We lamented the decline in active 
membership in our group, and discussed ways to encourage more participation 
from others. So if you have an interest in helping OpenStack APIs become better 
and more consistent, please join us! We don't bite (except for cdent, 
sometimes).

We discussed the pagination spec [4] that was recently abandoned by its author. 
Seeing as it was very close to agreement, edleafe agreed to take over the spec 
and address the remaining questions.

The API Stability guideline was the next topic. One thing that was noted was 
that several people disagree with some of the wording, but are reluctant to 
speak out publicly because of potential loss of social capital. In other words, 
they feel that some of the big names of OpenStack are on one side of the 
discussion, so they feel intimidated about arguing for the other side. That's a 
real shame, as I know that no one involved would hold it against anyone for 
presenting a reasoned argument. Please, if you feel that part of the guideline 
is not reasonable to you, say so. No one will think less of you.

Lastly, we wished cdent a speedy recovery from whatever bug has taken over his 
body.

# Newly Published Guidelines

Nothing new this week.

# API Guidelines Proposed for Freeze

Guidelines that are ready for wider review by the whole community. Nothing at 
the moment, but feel free to get in early on the reviews below.

# Guidelines Currently Under Review [3]

* Add API capabilities discovery guideline
  https://review.openstack.org/#/c/386555/

* Refactor and re-validate api change guidelines
  https://review.openstack.org/#/c/421846/

* Microversions: add next_min_version field in version body
  https://review.openstack.org/#/c/446138/

* WIP: microversion architecture archival doc (very early; not yet ready for 
review)
  https://review.openstack.org/444892

# Highlighting your API impacting issues

If you seek further review and insight from the API WG, please address your 
concerns in an email to the OpenStack developer mailing list[1] with the tag 
"[api]" in the subject. In your email, you should include any relevant reviews, 
links, and comments to help guide the discussion of the specific challenge you 
are facing.

To learn more about the API WG mission and the work we do, see OpenStack API 
Working Group [2].

Thanks for reading and see you next week!

# References

[1] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[2] http://specs.openstack.org/openstack/api-wg/
[3] https://review.openstack.org/#/q/status:open+project:openstack/api-wg,n,z
[4] https://review.openstack.org/#/c/390973/

Meeting Agenda
https://wiki.openstack.org/wiki/Meetings/API-WG#Agenda
Past Meeting Records
http://eavesdrop.openstack.org/meetings/api_wg/
Open Bugs
https://bugs.launchpad.net/openstack-api-wg

-- Ed Leafe







signature.asc
Description: Message signed with OpenPGP
__
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] [all][api] POST /api-wg/news

2017-03-13 Thread Chris Dent


On Mon, 13 Mar 2017, Thierry Carrez wrote:


At the recent Board+TC+UC meeting, the User Committee presented the API
workgroup as a User Committee workgroup, based on data from:

https://wiki.openstack.org/wiki/Governance/Foundation/UserCommittee


Yeah, that's been ongoing for a while and not something any of us in
the working group have done anything about as it didn't seem to
cause any harm and it came with one benefit: We consistently get
handling for a room at Summit.

Since we haven't had any indications one way or another that it is
bad to be sort of multi-homed, we haven't bothered to change things.


That said, the API WG discussions seem to be mostly developer-driven,
happen on openstack-dev, and the openstack/api-wg repository is listed
under the TC-driven repositories:


It is certainly the case that we are mostly developers-of-openstack-
driven and we target those same developers as the audience for the
guidelines we create. However, it is also the case that the primary
reason we want to guide the developers is so they create APIs which
are consistent and usable by the end users.

So there's a bit of overlap.


It's not really a big deal (I'm fine with it either way), but since we
may want to list working groups on the governance website soon, it would
be great to clarify where that one falls...


Given the desire to have working groups that are TC governed and for
them to be listed, I think it would make sense to clarify the API-WG
as being governed by the TC. That's how we think and operate [1], so may
as well make it official. If we do so we'd still like to keep ties
with the User Committee strong.

Unless, of course, there's some objection from the User Committee or
edleafe and elmiko.

[1] In the sense that if it there is an unresolvable dispute, the TC
is the source of mediation and resolution.

--
Chris Dent ¯\_(ツ)_/¯   https://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] [all][api] POST /api-wg/news

2017-03-13 Thread Thierry Carrez

Ed Leafe wrote:
> On Mar 9, 2017, at 9:30 PM, Everett Toews  wrote:
> 
>>> For those who don't know, Everett and I started the API-WG a few years ago,
>>
>> Umm...given this statement, I feel I _must_ provide some clarity.
>>
>> The API WG was started by myself, Jay Pipes, and Chris Yeoh. The ball got 
>> rolling in this email thread [2]. One of our first artifacts was this wiki 
>> page [3]. The 3 of us were the original core members (I'm not sure if [4] is 
>> capable of displaying history). Then we started making commits to the repo 
>> [5]. I'll leave it as an exercise to the reader to determine who got 
>> involved, when they got involved, and in what capacity.
> 
> Sorry if my memory is shaky - mea culpa. I thought Everett and I had had 
> discussions about starting something like this in early 2014 back when we 
> were working at Rackspace and both fighting the inconsistency of the 
> OpenStack APIs. But true, nothing concrete was done at that time.
> 
> What I *do* remember quite clearly when I returned to the world of OpenStack 
> in late 2014 was that Everett was very active in making the group a relevant 
> force for improvement, and has been ever since then. That is the main point I 
> want to emphasize.

While we are exploring the history of the API WG, I'd like a quick fact
check...

At the recent Board+TC+UC meeting, the User Committee presented the API
workgroup as a User Committee workgroup, based on data from:

https://wiki.openstack.org/wiki/Governance/Foundation/UserCommittee

That said, the API WG discussions seem to be mostly developer-driven,
happen on openstack-dev, and the openstack/api-wg repository is listed
under the TC-driven repositories:

http://git.openstack.org/cgit/openstack/governance/tree/reference/technical-committee-repos.yaml

It's not really a big deal (I'm fine with it either way), but since we
may want to list working groups on the governance website soon, it would
be great to clarify where that one falls...

-- 
Thierry Carrez (ttx)



signature.asc
Description: OpenPGP digital signature
__
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] [all][api] POST /api-wg/news

2017-03-10 Thread Ed Leafe

On Mar 9, 2017, at 9:30 PM, Everett Toews  wrote:

>> For those who don't know, Everett and I started the API-WG a few years ago,
> 
> Umm...given this statement, I feel I _must_ provide some clarity.
> 
> The API WG was started by myself, Jay Pipes, and Chris Yeoh. The ball got 
> rolling in this email thread [2]. One of our first artifacts was this wiki 
> page [3]. The 3 of us were the original core members (I'm not sure if [4] is 
> capable of displaying history). Then we started making commits to the repo 
> [5]. I'll leave it as an exercise to the reader to determine who got 
> involved, when they got involved, and in what capacity.

Sorry if my memory is shaky - mea culpa. I thought Everett and I had had 
discussions about starting something like this in early 2014 back when we were 
working at Rackspace and both fighting the inconsistency of the OpenStack APIs. 
But true, nothing concrete was done at that time.

What I *do* remember quite clearly when I returned to the world of OpenStack in 
late 2014 was that Everett was very active in making the group a relevant force 
for improvement, and has been ever since then. That is the main point I want to 
emphasize.

-- Ed Leafe

signature.asc
Description: Message signed with OpenPGP
__
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] [all][api] POST /api-wg/news

2017-03-09 Thread Everett Toews

> On Mar 9, 2017, at 11:52 AM, Ed Leafe  wrote:
> 
> Greetings OpenStack community,
> 
> Today's meeting started on a heavyhearted note, as we hoisted our virtual 
> beers and gave a toast to Everett Toews, who recently had to step down from 
> his API-WG duties due to a job re-assignment.

I'm proud of everything we've accomplished to date and I know that there is a 
healthy future for the API Working Group. The API WG has made great strides in 
its mission [1]. Plus it sounds like the PTG sessions were very well attended 
and that's really heartening to hear after all of this time.

I wish the API WG all the best and it's been a pleasure working on this with 
everyone.

> For those who don't know, Everett and I started the API-WG a few years ago,

Umm...given this statement, I feel I _must_ provide some clarity.

The API WG was started by myself, Jay Pipes, and Chris Yeoh. The ball got 
rolling in this email thread [2]. One of our first artifacts was this wiki page 
[3]. The 3 of us were the original core members (I'm not sure if [4] is capable 
of displaying history). Then we started making commits to the repo [5]. I'll 
leave it as an exercise to the reader to determine who got involved, when they 
got involved, and in what capacity.

Ed has made a lot of contributions as of late and his efforts are genuinely 
appreciated. So much so that he became a core member and continues to drive the 
mission forward.

Cheers,
Everett

[1] http://specs.openstack.org/openstack/api-wg/#mission-statement
[2] 
http://lists.openstack.org/pipermail/openstack-dev/2014-September/thread.html#46482
[3] 
https://wiki.openstack.org/w/index.php?title=API_Working_Group=20141114155251=history
[4] https://review.openstack.org/#/admin/groups/
[5] http://git.openstack.org/cgit/openstack/api-wg/log/?ofs=200

__
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-dev] [all][api] POST /api-wg/news

2017-03-09 Thread Ed Leafe

Greetings OpenStack community,

Today's meeting started on a heavyhearted note, as we hoisted our virtual beers 
and gave a toast to Everett Toews, who recently had to step down from his 
API-WG duties due to a job re-assignment. For those who don't know, Everett and 
I started the API-WG a few years ago, but it was Everett who was the main 
driving force behind getting it to where it is today. His influence, energy, 
and personality will be missed.

We then moved on to discuss the revised API stability guidelines document [4] 
which is getting close to being ready, thanks to some excellent input we 
received at the recent PTG. A few more people have expressed that they have 
comments, so we'd like to get as much input from as broad an audience. If you 
have something to add, do it soon!

We then brainstormed ideas for how to increase participation in the group. 
Everett's recent departure brings the number of cores down to 3, and who knows 
what the future holds for us as the OpenStack job market winds keep changing 
direction. One issue that we noted is that most of the work that we set out to 
do when we formed has been largely completed, so there isn't much excitement 
out there for finishing the rest. We agreed to discuss this with the TC to let 
them know the situation, and to see if they had any ideas for future direction.

And as that topic wound down, we got to know knikolla (Kristi Nikolla), who is 
new to the group, but is interested in contributing because of his work on 
openstack/mixmatch [5], which aims to allow different OpenStack deployments to 
communicate with each other. As you can imagine, API inconsistencies make that 
an even harder task! So we look forward to further discussions with knikolla in 
the future.

# Newly Published Guidelines

Nothing new this week.

# API Guidelines Proposed for Freeze

Guidelines that are ready for wider review by the whole community. Nothing at 
the moment, but feel free to get in early on the reviews below.

# Guidelines Currently Under Review [3]

* Define pagination guidelines
  https://review.openstack.org/#/c/390973/

* Add API capabilities discovery guideline
  https://review.openstack.org/#/c/386555/

* Refactor and re-validate api change guidelines
  https://review.openstack.org/#/c/421846/

# Highlighting your API impacting issues

If you seek further review and insight from the API WG, please address your 
concerns in an email to the OpenStack developer mailing list[1] with the tag 
"[api]" in the subject. In your email, you should include any relevant reviews, 
links, and comments to help guide the discussion of the specific challenge you 
are facing.

To learn more about the API WG mission and the work we do, see OpenStack API 
Working Group [2].

Thanks for reading and see you next week!

# References

[1] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[2] http://specs.openstack.org/openstack/api-wg/
[3] https://review.openstack.org/#/q/status:open+project:openstack/api-wg,n,z
[4] https://review.openstack.org/#/c/421846/
[5] https://github.com/openstack/mixmatch

Meeting Agenda
https://wiki.openstack.org/wiki/Meetings/API-WG#Agenda
Past Meeting Records
http://eavesdrop.openstack.org/meetings/api_wg/
Open Bugs
https://bugs.launchpad.net/openstack-api-wg

-- Ed Leafe







signature.asc
Description: Message signed with OpenPGP
__
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-dev] [all][api] POST /api-wg/news

2017-03-02 Thread Chris Dent



Greetings OpenStack community,

Only two of us in attendance at today's API-WG meeting. We mostly reflected on 
the work that needs to be done to summarize activity at the PTG last week. 
Despite not having a room of our own until the last minute, on Monday and 
Tuesday we had a large gathering with lots of great input. We continued using 
the archiecture working groups etherpad [0] for planning and used three other 
topical etherpads:

* stability and compatibility guidelines:
  https://etherpad.openstack.org/p/api-stability-guidelines
* capabilities discovery:
  https://etherpad.openstack.org/p/capabilities-pike
* service catalog and service types:
  https://etherpad.openstack.org/p/service-catalog-pike

In the next 24 hours or so there will be an API-WG PTG recap posted to the 
os-dev list.

# Newly Published Guidelines

Nothing new this week.

# API Guidelines Proposed for Freeze

Guidelines that are ready for wider review by the whole community. Nothing at 
the moment, but feel free to get in early on the reviews below.

# Guidelines Currently Under Review [3]

* Define pagination guidelines
  https://review.openstack.org/#/c/390973/

* Add API capabilities discovery guideline
  https://review.openstack.org/#/c/386555/

* Refactor and re-validate api change guidelines
  https://review.openstack.org/#/c/421846/

# Highlighting your API impacting issues

If you seek further review and insight from the API WG, please address your concerns in 
an email to the OpenStack developer mailing list[1] with the tag "[api]" in the 
subject. In your email, you should include any relevant reviews, links, and comments to 
help guide the discussion of the specific challenge you are facing.

To learn more about the API WG mission and the work we do, see OpenStack API 
Working Group [2].

Thanks for reading and see you next week!

# References

[0] https://etherpad.openstack.org/p/ptg-architecture-workgroup
[1] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[2] http://specs.openstack.org/openstack/api-wg/
[3] https://review.openstack.org/#/q/status:open+project:openstack/api-wg,n,z

Meeting Agenda
https://wiki.openstack.org/wiki/Meetings/API-WG#Agenda
Past Meeting Records
http://eavesdrop.openstack.org/meetings/api_wg/
Open Bugs
https://bugs.launchpad.net/openstack-api-wg

--
Chris Dent ¯\_(ツ)_/¯   https://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

[openstack-dev] [all][api] POST /api-wg/news

2017-02-09 Thread michael mccune


Greetings OpenStack community,

This week's meeting[0] was relatively light, with some discussion about 
the recently released Ethercalc[4], and the first draft of the API 
compatiblity guideline[5] (many thanks to Chris Dent). The compatibility 
guideline lays out some concrete standards by which projects can 
definitely determine if they are following the API guidelines in 
general, and how closely their efforts track. This work is part of the 
foundation for creating an API compatiblity tag which projects can apply 
for.


One reminder: Projects should make sure that their liaison information 
is up to date at 
http://specs.openstack.org/openstack/api-wg/liaisons.html . If not, 
please provide a patch to doc/source/liaisons.json to update it.


One guideline was frozen this week.

# Newly Published Guidelines

* Add guideline for invalid query parameters
  https://review.openstack.org/#/c/417441/
* Add guidelines on usage of state vs. status
  https://review.openstack.org/#/c/411528/
* Clarify the status values in versions
  https://review.openstack.org/#/c/411849/

# API Guidelines Proposed for Freeze

Guidelines that are ready for wider review by the whole community.

* Add guidelines for boolean names
  https://review.openstack.org/#/c/411529/

# Guidelines Currently Under Review [3]

* Define pagination guidelines
  https://review.openstack.org/#/c/390973/

* Add API capabilities discovery guideline
  https://review.openstack.org/#/c/386555/

* Refactor and re-validate api change guidelines
  https://review.openstack.org/#/c/421846/

# Highlighting your API impacting issues

If you seek further review and insight from the API WG, please address 
your concerns in an email to the OpenStack developer mailing list[1] 
with the tag "[api]" in the subject. In your email, you should include 
any relevant reviews, links, and comments to help guide the discussion 
of the specific challenge you are facing.


To learn more about the API WG mission and the work we do, see OpenStack 
API Working Group [2].


Thanks for reading and see you next week!

# References

[0] 
http://eavesdrop.openstack.org/meetings/api_wg/2017/api_wg.2017-02-09-16.00.html

[1] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[2] http://specs.openstack.org/openstack/api-wg/
[3] 
https://review.openstack.org/#/q/status:open+project:openstack/api-wg,n,z

[4] https://ethercalc.openstack.org/
[5] https://review.openstack.org/#/c/421846/

Meeting Agenda
https://wiki.openstack.org/wiki/Meetings/API-WG#Agenda
Past Meeting Records
http://eavesdrop.openstack.org/meetings/api_wg/
Open Bugs
https://bugs.launchpad.net/openstack-api-wg

__
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] [all][api] POST /api-wg/news

2017-02-07 Thread Everett Toews

On Feb 6, 2017, at 3:28 PM, Ken'ichi Ohmichi 
> wrote:

2017-02-06 6:45 GMT-08:00 Brian Rosmaita 
>:
On 2/6/17 5:51 AM, Jordan Pittier wrote:
[super-enormous snip -- Chris, Ken, and Jordan make good points, I
encourage you to read the entire thread; I just want to concentrate on
one point]

I would say we should make compromise, not solve dilemma. I can live in a
world where we sometimes allow an API change and sometimes prevent it.

+1000

I agree with Jordan.  We need to look at the context of each specific
case and decide whether a change is OK based on the details.  We've
already got the guideline that says "in general", you shouldn't change
the response code, and we respect that.  The Glance team isn't claiming
that the guideline is incorrect--we're just saying that given the
context of this specific bug (that is, it's been documented for a long
time to return a 204, all other metadefs DELETE calls are documented to
return a 204, all the other metadefs DELETE calls do in fact return a
204, etc.), it makes sense that this case is an exception.

Granting an exception here doesn't mean that the floodgates have opened
for an "anything goes" approach to API changes.  It just means that an
exception is appropriate in this particular case.  I am being a bit
disingenuous there because if an exception is appropriate in this case,
then it will be appropriate in other relevantly similar cases.  But
"relevant similarity" will include the entire context of the case, for
example, whether there was a published API contract, whether the other
similar calls behave as documented, etc.  From 10,000 meters, it looks
like what we're advocating is "It's OK to change a response code".  But
when you look more closely, our claim is that given the details of this
particular bug, it makes sense to fix it in the code and not in the docs.

To summarize, my point is that we shouldn't be worried that this case is
going to set a precedent.  It would be worrisome if it were going to set
a *bad* precedent, but when you look at the details of the situation, I
don't think it will.  So it looks to me, anyway, that a compromise is in
order here.  (In case I'm being too obscure, what I mean is: we should
agree that it's OK for the Glance team to fix this bug in the code with
patch https://review.openstack.org/#/c/420038/.)

I feel this case is very common case when we want to chang success status code.
Because I cannot find the other motivation for changing success status
code except we are finding bugs like this case.

So if accepting this case, I guess we drop the following guideline completely[1]

 The following types of changes are generally *not* considered acceptable:
  Changing which response code is returned on success.

This isn't an all or nothing proposition and I don't think it needs to be 
dropped completely. Members of an OpenStack project that want to adhere to the 
guidelines can use their judgement and take the guidance, that those types of 
changes are generally not considered acceptable, into account.

Each and every OpenStack project are themselves responsible for providing a 
good UX for their users. They need to be willing to fix genuine code bugs in 
order to improve that UX. Human judgement is used to define "genuine" in this 
case.

If they become unwilling to fix bugs because it changes some aspect of the UX 
(the API in this case) and users have to react to that change then we'll 
eventually be left with a bug-ridden foundation. I abhor backwards incompatible 
changes as much as the next dev but building on buggy code is the worst UX of 
all. (Yes, I'm the one who made the Internet Explorer analogy.)

Discussion over this particular issue is helping us form the guideline. But 
please note how I specified "Members of an OpenStack project" above. I want to 
make it clear that it is not the API WG's role to adjudicate on particular 
issues. The API WG can offer opinions, clarify the intention of a guideline, 
adjust guidelines if they're not clear, etc. The responsibility lies with the 
project to make good decisions for their users.

Regards,
Everett

__
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] [all][api] POST /api-wg/news

2017-02-07 Thread Ken'ichi Ohmichi

2017-02-07 10:31 GMT-08:00 Ed Leafe :
> On Feb 6, 2017, at 3:28 PM, Ken'ichi Ohmichi  wrote:
>>
>>> To summarize, my point is that we shouldn't be worried that this case is
>>> going to set a precedent.  It would be worrisome if it were going to set
>>> a *bad* precedent, but when you look at the details of the situation, I
>>> don't think it will.  So it looks to me, anyway, that a compromise is in
>>> order here.  (In case I'm being too obscure, what I mean is: we should
>>> agree that it's OK for the Glance team to fix this bug in the code with
>>> patch https://review.openstack.org/#/c/420038/.)
>>
>> I feel this case is very common case when we want to chang success status 
>> code.
>> Because I cannot find the other motivation for changing success status
>> code except we are finding bugs like this case.
>
> Success codes are different than failure codes, because when you fail, you 
> need to know why. When your request succeeds, that’s pretty much all you need 
> to know. So the pain involved should be much less.
>
> But aside from this particular case, there are a lot of differing opinions on 
> how APIs should be treated, so I wrote up my take on things:
>
> https://blog.leafe.com/api-longevity/
>
>> So if accepting this case, I guess we drop the following guideline 
>> completely[1]
>>
>>  The following types of changes are generally *not* considered acceptable:
>>   Changing which response code is returned on success.
>
> I’ll propose a change to the wording for that, but dropping the guideline 
> completely would be an overreaction, IMO.

I am not sure what you mean, I feel you are saying it is meaningless
to specify particular success status code on each API..
One my stupid idea is it is good to specify HTTP200 only on all APIs
on the guideline.
It would be easy to make APIs consistent and avoid this kind of bugs.
I know many people don't prefer this idea ;)

Thanks
Ken Ohmichi

__
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] [all][api] POST /api-wg/news

2017-02-07 Thread Ken'ichi Ohmichi

2017-02-07 6:56 GMT-08:00 Brian Rosmaita :
> On 2/6/17 4:28 PM, Ken'ichi Ohmichi wrote:
>> 2017-02-06 6:45 GMT-08:00 Brian Rosmaita :
>>> On 2/6/17 5:51 AM, Jordan Pittier wrote:
>>> [super-enormous snip -- Chris, Ken, and Jordan make good points, I
>>> encourage you to read the entire thread; I just want to concentrate on
>>> one point]

 I would say we should make compromise, not solve dilemma. I can live in a
 world where we sometimes allow an API change and sometimes prevent it.

>>> +1000
>>>
>>> I agree with Jordan.  We need to look at the context of each specific
>>> case and decide whether a change is OK based on the details.  We've
>>> already got the guideline that says "in general", you shouldn't change
>>> the response code, and we respect that.  The Glance team isn't claiming
>>> that the guideline is incorrect--we're just saying that given the
>>> context of this specific bug (that is, it's been documented for a long
>>> time to return a 204, all other metadefs DELETE calls are documented to
>>> return a 204, all the other metadefs DELETE calls do in fact return a
>>> 204, etc.), it makes sense that this case is an exception.
>>>
>>> Granting an exception here doesn't mean that the floodgates have opened
>>> for an "anything goes" approach to API changes.  It just means that an
>>> exception is appropriate in this particular case.  I am being a bit
>>> disingenuous there because if an exception is appropriate in this case,
>>> then it will be appropriate in other relevantly similar cases.  But
>>> "relevant similarity" will include the entire context of the case, for
>>> example, whether there was a published API contract, whether the other
>>> similar calls behave as documented, etc.  From 10,000 meters, it looks
>>> like what we're advocating is "It's OK to change a response code".  But
>>> when you look more closely, our claim is that given the details of this
>>> particular bug, it makes sense to fix it in the code and not in the docs.
>>>
>>> To summarize, my point is that we shouldn't be worried that this case is
>>> going to set a precedent.  It would be worrisome if it were going to set
>>> a *bad* precedent, but when you look at the details of the situation, I
>>> don't think it will.  So it looks to me, anyway, that a compromise is in
>>> order here.  (In case I'm being too obscure, what I mean is: we should
>>> agree that it's OK for the Glance team to fix this bug in the code with
>>> patch https://review.openstack.org/#/c/420038/.)
>>
>> I feel this case is very common case when we want to chang success status 
>> code.
>> Because I cannot find the other motivation for changing success status
>> code except we are finding bugs like this case.
>>
>> So if accepting this case, I guess we drop the following guideline 
>> completely[1]
>>
>>   The following types of changes are generally *not* considered acceptable:
>>Changing which response code is returned on success.
>
> I think that's a separate discussion that shouldn't hold up whether we
> can get this particular bug properly fixed soon.
>
> It doesn't follow that if Glance makes this change, the guideline is
> pointless.  As I said earlier, given the context of this particular bug
> (the success code for the call has been documented as a 204, all the
> other metadefs DELETE calls return a 204, all the other calls are also
> documented to return 204s, etc.), one can argue that this is a
> legitimate exception allowed under the guideline.  And in fact the API
> Working Group has accepted that argument.  If the facts of the case were
> different, they might very well have told me to go boil my head.
>
> My point here is that we can accept the guideline *and* also accept this
> particular change.  Hence, worrying about the status of the guideline is
> not a reason to reject the fix proposed by the patch
> https://review.openstack.org/#/c/420038/ .

Again, this case is not particular case. Very common case.
It was just forgot to specify status code (204 in this case) in the
code, and the wsgi framework returns 200 as the default.
Nova also has multiple same bugs on the API, so I feel this is common case.

My point is "Do we really need to do that ?" with
- Possible to break the existing users APIs
- Break the OpenStack interoperability on multiple different version clouds
- Make the guideline fuzzy when facing the smiler issues

only for us, developers.

Thanks
Ken Ohmichi

---

__
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] [all][api] POST /api-wg/news

2017-02-07 Thread Ed Leafe

On Feb 6, 2017, at 3:28 PM, Ken'ichi Ohmichi  wrote:
> 
>> To summarize, my point is that we shouldn't be worried that this case is
>> going to set a precedent.  It would be worrisome if it were going to set
>> a *bad* precedent, but when you look at the details of the situation, I
>> don't think it will.  So it looks to me, anyway, that a compromise is in
>> order here.  (In case I'm being too obscure, what I mean is: we should
>> agree that it's OK for the Glance team to fix this bug in the code with
>> patch https://review.openstack.org/#/c/420038/.)
> 
> I feel this case is very common case when we want to chang success status 
> code.
> Because I cannot find the other motivation for changing success status
> code except we are finding bugs like this case.

Success codes are different than failure codes, because when you fail, you need 
to know why. When your request succeeds, that’s pretty much all you need to 
know. So the pain involved should be much less.

But aside from this particular case, there are a lot of differing opinions on 
how APIs should be treated, so I wrote up my take on things:

https://blog.leafe.com/api-longevity/

> So if accepting this case, I guess we drop the following guideline 
> completely[1]
> 
>  The following types of changes are generally *not* considered acceptable:
>   Changing which response code is returned on success.

I’ll propose a change to the wording for that, but dropping the guideline 
completely would be an overreaction, IMO.


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

Re: [openstack-dev] [all][api] POST /api-wg/news

2017-02-07 Thread Brian Rosmaita

On 2/6/17 4:28 PM, Ken'ichi Ohmichi wrote:
> 2017-02-06 6:45 GMT-08:00 Brian Rosmaita :
>> On 2/6/17 5:51 AM, Jordan Pittier wrote:
>> [super-enormous snip -- Chris, Ken, and Jordan make good points, I
>> encourage you to read the entire thread; I just want to concentrate on
>> one point]
>>>
>>> I would say we should make compromise, not solve dilemma. I can live in a
>>> world where we sometimes allow an API change and sometimes prevent it.
>>>
>> +1000
>>
>> I agree with Jordan.  We need to look at the context of each specific
>> case and decide whether a change is OK based on the details.  We've
>> already got the guideline that says "in general", you shouldn't change
>> the response code, and we respect that.  The Glance team isn't claiming
>> that the guideline is incorrect--we're just saying that given the
>> context of this specific bug (that is, it's been documented for a long
>> time to return a 204, all other metadefs DELETE calls are documented to
>> return a 204, all the other metadefs DELETE calls do in fact return a
>> 204, etc.), it makes sense that this case is an exception.
>>
>> Granting an exception here doesn't mean that the floodgates have opened
>> for an "anything goes" approach to API changes.  It just means that an
>> exception is appropriate in this particular case.  I am being a bit
>> disingenuous there because if an exception is appropriate in this case,
>> then it will be appropriate in other relevantly similar cases.  But
>> "relevant similarity" will include the entire context of the case, for
>> example, whether there was a published API contract, whether the other
>> similar calls behave as documented, etc.  From 10,000 meters, it looks
>> like what we're advocating is "It's OK to change a response code".  But
>> when you look more closely, our claim is that given the details of this
>> particular bug, it makes sense to fix it in the code and not in the docs.
>>
>> To summarize, my point is that we shouldn't be worried that this case is
>> going to set a precedent.  It would be worrisome if it were going to set
>> a *bad* precedent, but when you look at the details of the situation, I
>> don't think it will.  So it looks to me, anyway, that a compromise is in
>> order here.  (In case I'm being too obscure, what I mean is: we should
>> agree that it's OK for the Glance team to fix this bug in the code with
>> patch https://review.openstack.org/#/c/420038/.)
> 
> I feel this case is very common case when we want to chang success status 
> code.
> Because I cannot find the other motivation for changing success status
> code except we are finding bugs like this case.
> 
> So if accepting this case, I guess we drop the following guideline 
> completely[1]
> 
>   The following types of changes are generally *not* considered acceptable:
>Changing which response code is returned on success.

I think that's a separate discussion that shouldn't hold up whether we
can get this particular bug properly fixed soon.

It doesn't follow that if Glance makes this change, the guideline is
pointless.  As I said earlier, given the context of this particular bug
(the success code for the call has been documented as a 204, all the
other metadefs DELETE calls return a 204, all the other calls are also
documented to return 204s, etc.), one can argue that this is a
legitimate exception allowed under the guideline.  And in fact the API
Working Group has accepted that argument.  If the facts of the case were
different, they might very well have told me to go boil my head.

My point here is that we can accept the guideline *and* also accept this
particular change.  Hence, worrying about the status of the guideline is
not a reason to reject the fix proposed by the patch
https://review.openstack.org/#/c/420038/ .

cheers,
brian

> 
> Thanks
> Ken Ohmichi
> 
> ---
> [1]: 
> https://specs.openstack.org/openstack/api-wg/guidelines/evaluating_api_changes.html#guidance
> 
> __
> 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] [all][api] POST /api-wg/news

2017-02-06 Thread Ken'ichi Ohmichi

2017-02-06 6:45 GMT-08:00 Brian Rosmaita :
> On 2/6/17 5:51 AM, Jordan Pittier wrote:
> [super-enormous snip -- Chris, Ken, and Jordan make good points, I
> encourage you to read the entire thread; I just want to concentrate on
> one point]
>>
>> I would say we should make compromise, not solve dilemma. I can live in a
>> world where we sometimes allow an API change and sometimes prevent it.
>>
> +1000
>
> I agree with Jordan.  We need to look at the context of each specific
> case and decide whether a change is OK based on the details.  We've
> already got the guideline that says "in general", you shouldn't change
> the response code, and we respect that.  The Glance team isn't claiming
> that the guideline is incorrect--we're just saying that given the
> context of this specific bug (that is, it's been documented for a long
> time to return a 204, all other metadefs DELETE calls are documented to
> return a 204, all the other metadefs DELETE calls do in fact return a
> 204, etc.), it makes sense that this case is an exception.
>
> Granting an exception here doesn't mean that the floodgates have opened
> for an "anything goes" approach to API changes.  It just means that an
> exception is appropriate in this particular case.  I am being a bit
> disingenuous there because if an exception is appropriate in this case,
> then it will be appropriate in other relevantly similar cases.  But
> "relevant similarity" will include the entire context of the case, for
> example, whether there was a published API contract, whether the other
> similar calls behave as documented, etc.  From 10,000 meters, it looks
> like what we're advocating is "It's OK to change a response code".  But
> when you look more closely, our claim is that given the details of this
> particular bug, it makes sense to fix it in the code and not in the docs.
>
> To summarize, my point is that we shouldn't be worried that this case is
> going to set a precedent.  It would be worrisome if it were going to set
> a *bad* precedent, but when you look at the details of the situation, I
> don't think it will.  So it looks to me, anyway, that a compromise is in
> order here.  (In case I'm being too obscure, what I mean is: we should
> agree that it's OK for the Glance team to fix this bug in the code with
> patch https://review.openstack.org/#/c/420038/.)

I feel this case is very common case when we want to chang success status code.
Because I cannot find the other motivation for changing success status
code except we are finding bugs like this case.

So if accepting this case, I guess we drop the following guideline completely[1]

  The following types of changes are generally *not* considered acceptable:
   Changing which response code is returned on success.

Thanks
Ken Ohmichi

---
[1]: 
https://specs.openstack.org/openstack/api-wg/guidelines/evaluating_api_changes.html#guidance

__
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] [all][api] POST /api-wg/news

2017-02-06 Thread Ken'ichi Ohmichi

2017-02-06 2:51 GMT-08:00 Jordan Pittier :
>>
>> >> If we change the success status code (200 ->204) without any version
>> >> bumps, OpenStack clouds return different status codes on the same API
>> >> operations.
>> >> That will break OpenStack interoperability and clients' APPs need to
>> >> be changed for accepting 204 also as success operation.
>> >> That could make APPs code mudness.
>> >> I also think this is basically code bug, but this is hard to fix
>> >> because of big impact against the existing users.
>> >
>> >
>> > There have been lots of different opinions and perspective on this
>> > (in the reviews and elsewhere), all of which are pretty sensible but
>> > as a mass are hard to reconcile. The below is reporting evidence, not
>> > supporting a plan:
>> >
>> >   The API-WG is striving for OpenStack APIs to be consistent within
>> >   themselves, with each other and with the HTTP RFCs. This particular
>> >   issue is an example where none of those are satisfied.
>> >
>> > Yet it is true that if client code is specifically looking for a
>> > 200 response this change, without a version signal, will break
>> > that code.
>> >
>> >   But glance isn't set up with microversions or something like.
>> >
>> >   But isn't checking specifically for 200 as "success" unusual so
>> >   this is unlikely to be as bad as changing a 4xx to some other
>> >   4xx.
>> >
>> >   But correcting the docs so they indicate this one request out of
>> >   several in a group breaks the 204 pattern set by the rest of
>> >   the group and could easily be perceived as a typo and thus need
>> >   to be annotated as "special".
>> >
>> > How do we reconcile that?
>>
>> This API has been implemented since 2 years ago, and it is easy to
>> imagine many users are using the API.
>> If changing success status code like this, we send a message "status
>> code could be changed anytime" to users and users would recognize "the
>> success status code is unstable and it is better to check status code
>> range(20X) instead of a certain code(200, 201, etc) for long-term
>> maintenance".
>
>
> I think we should be pragmatic. There's a a difference between changing one
> return code from 200->204 (still in the 2XX range), for one endpoint
> exceptionally and saying "we keep changing status code, OpenStack is not
> stable".
>
> Microversions are great, but not all projects support them yet. In the mean
> time, if a project properly documents through a release note a minor API
> change (like this one), that sounds reasonable. Sure some user code will
> break, at upgrade, but let's be realistic here things get broken after a
> major upgrade of every software, that's why operators/deployers test the
> upgrades beforehand.

On the above scenario, I feel we need to distinguish users between
operators and API consumers.
It is true that operators tend to face upgrade issues many times and
they are testing on each upgrade.
They can see the corresponding release note because they upgrade the
cloud by themselves.
However, API consumers don't read release notes because they don't
maintain the used clouds, they just use clouds.
In addition, API consumers should be able to switch OpenStack clouds on-demand.
It is better that clouds do the same behaviors for the
interoperability even if the destination cloud is older version.

>> If the above is we expect/hope, why should we fix/change success code
>> to ideal one?
>> On the above scenario, we are expecting users should not check a certain
>> code.
>> So even if changing status code, users would not be affected by the
>> change.
>> Whom we are changing the status code for?
>
>
> That's a good question. In that case we should do it "for us, the
> developers". I prefer to work with a sane code base, sane API, small
> technical debt. But I also understand the users are paying us for stability.

Yeah, I can see the motivation as a developer.
However, I cannot be confident to say the impact of the change is
small for users.

Thanks
Ken Ohmichi

---


>> > Some opinions of my own:
>> >
>> > I worry that we're making it ever harder to fix bugs and technical
>> > debt in many areas of OpenStack. Sure, there are very good reasons
>> > for the constraints we build in, but how much tech debt are we
>> > making ourselves carry? We have the versioning concepts to help (for
>> > those projects that use them) but we haven't yet agreed how to
>> > cleanly deprecate past stuff or even if we can or should.
>> >
>> > I don't feel too bad about that worry, because I know there are
>> > plenty of people who worry about other things that balance it out
>> > for a reasonable compromise.
>> >
>> >
>> > --
>> > Chris Dent ¯\_(ツ)_/¯   https://anticdent.org/
>> > freenode: cdent tw: @anticdent
>> >
>> >
>> > __
>> > OpenStack

Re: [openstack-dev] [all][api] POST /api-wg/news

2017-02-06 Thread Monty Taylor

On 02/06/2017 08:45 AM, Brian Rosmaita wrote:
> On 2/6/17 5:51 AM, Jordan Pittier wrote:
> [super-enormous snip -- Chris, Ken, and Jordan make good points, I
> encourage you to read the entire thread; I just want to concentrate on
> one point]
>>
>> I would say we should make compromise, not solve dilemma. I can live in a
>> world where we sometimes allow an API change and sometimes prevent it.
>>
> +1000
> 
> I agree with Jordan.  We need to look at the context of each specific
> case and decide whether a change is OK based on the details.  We've
> already got the guideline that says "in general", you shouldn't change
> the response code, and we respect that.  The Glance team isn't claiming
> that the guideline is incorrect--we're just saying that given the
> context of this specific bug (that is, it's been documented for a long
> time to return a 204, all other metadefs DELETE calls are documented to
> return a 204, all the other metadefs DELETE calls do in fact return a
> 204, etc.), it makes sense that this case is an exception.

Agree.

I also agree with something from back in the thread - consumers are much
more likely to be checking for non-2xx statuses. In fact,
python-requests exception_from_request does exactly this- it checks to
see if the code is 4xx or 5xx and if so throws an appropriate exception.
Folks not using python requests are much more likely to be using a
similar approach (checking for return codes generally before looking for
specific reasons in switching logic) than to actually have an explicit
implementation for each REST call with an active check that the status
code was 200 vs 204.

> Granting an exception here doesn't mean that the floodgates have opened
> for an "anything goes" approach to API changes.  It just means that an
> exception is appropriate in this particular case.  I am being a bit
> disingenuous there because if an exception is appropriate in this case,
> then it will be appropriate in other relevantly similar cases.  But
> "relevant similarity" will include the entire context of the case, for
> example, whether there was a published API contract, whether the other
> similar calls behave as documented, etc.  From 10,000 meters, it looks
> like what we're advocating is "It's OK to change a response code".  But
> when you look more closely, our claim is that given the details of this
> particular bug, it makes sense to fix it in the code and not in the docs.
> 
> To summarize, my point is that we shouldn't be worried that this case is
> going to set a precedent.  It would be worrisome if it were going to set
> a *bad* precedent, but when you look at the details of the situation, I
> don't think it will.  So it looks to me, anyway, that a compromise is in
> order here.  (In case I'm being too obscure, what I mean is: we should
> agree that it's OK for the Glance team to fix this bug in the code with
> patch https://review.openstack.org/#/c/420038/.)

Yup. Totally agree.


__
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] [all][api] POST /api-wg/news

2017-02-06 Thread Brian Rosmaita

On 2/6/17 5:51 AM, Jordan Pittier wrote:
[super-enormous snip -- Chris, Ken, and Jordan make good points, I
encourage you to read the entire thread; I just want to concentrate on
one point]
> 
> I would say we should make compromise, not solve dilemma. I can live in a
> world where we sometimes allow an API change and sometimes prevent it.
> 
+1000

I agree with Jordan.  We need to look at the context of each specific
case and decide whether a change is OK based on the details.  We've
already got the guideline that says "in general", you shouldn't change
the response code, and we respect that.  The Glance team isn't claiming
that the guideline is incorrect--we're just saying that given the
context of this specific bug (that is, it's been documented for a long
time to return a 204, all other metadefs DELETE calls are documented to
return a 204, all the other metadefs DELETE calls do in fact return a
204, etc.), it makes sense that this case is an exception.

Granting an exception here doesn't mean that the floodgates have opened
for an "anything goes" approach to API changes.  It just means that an
exception is appropriate in this particular case.  I am being a bit
disingenuous there because if an exception is appropriate in this case,
then it will be appropriate in other relevantly similar cases.  But
"relevant similarity" will include the entire context of the case, for
example, whether there was a published API contract, whether the other
similar calls behave as documented, etc.  From 10,000 meters, it looks
like what we're advocating is "It's OK to change a response code".  But
when you look more closely, our claim is that given the details of this
particular bug, it makes sense to fix it in the code and not in the docs.

To summarize, my point is that we shouldn't be worried that this case is
going to set a precedent.  It would be worrisome if it were going to set
a *bad* precedent, but when you look at the details of the situation, I
don't think it will.  So it looks to me, anyway, that a compromise is in
order here.  (In case I'm being too obscure, what I mean is: we should
agree that it's OK for the Glance team to fix this bug in the code with
patch https://review.openstack.org/#/c/420038/.)

cheers,
brian

__
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] [all][api] POST /api-wg/news

2017-02-06 Thread Jordan Pittier

On Fri, Feb 3, 2017 at 7:51 PM, Ken'ichi Ohmichi 
wrote:

> 2017-02-03 9:56 GMT-08:00 Chris Dent :
> > On Thu, 2 Feb 2017, Ken'ichi Ohmichi wrote:
> >>>
> >>> In today's meeting [0] after briefly covering old business we spent
> >>> nearly
> >>> 50 minutes going round in circles discussing the complex interactions
> of
> >>> expectations of API stability, the need to fix bugs and the costs and
> >>> benefits of microversions. We didn't make a lot of progress on the
> >>> general
> >>> issues, but we did #agree that a glance issue [4] should be treated as
> a
> >>> code bug (not a documentation bug) that should be fixed. In some ways
> >>> this
> >>> position is not aligned with the ideal presented by stability
> guidelines
> >>> but
> >>> it is aligned with an original goal of the API-WG: consistency. It's
> >>> unclear
> >>> how to resolve this conflict, either in this specific instance or in
> the
> >>> guidelines that the API-WG creates. As stated in response to one of the
> >>> related reviews [5]: "If bugs like this don't get fixed properly in the
> >>> code, OpenStack risks going down the path of Internet Explorer and
> people
> >>> wind up writing client code to the bugs and that way lies madness."
> >>
> >>
> >> I am not sure the code change can avoid the madness.
> >
> >
> > Just for the record, I'm not the speaker of that quote. I included
> > it because I think it does a good job of representing the complexity
> > and confusion that we have going on or at least in inspiring
> > responses that help to do so.
> >
> > Which is a round about way of saying: Thank you very much for
> > responding.
>
> Haha, I see.
>
> >> If we change the success status code (200 ->204) without any version
> >> bumps, OpenStack clouds return different status codes on the same API
> >> operations.
> >> That will break OpenStack interoperability and clients' APPs need to
> >> be changed for accepting 204 also as success operation.
> >> That could make APPs code mudness.
> >> I also think this is basically code bug, but this is hard to fix
> >> because of big impact against the existing users.
> >
> >
> > There have been lots of different opinions and perspective on this
> > (in the reviews and elsewhere), all of which are pretty sensible but
> > as a mass are hard to reconcile. The below is reporting evidence, not
> > supporting a plan:
> >
> >   The API-WG is striving for OpenStack APIs to be consistent within
> >   themselves, with each other and with the HTTP RFCs. This particular
> >   issue is an example where none of those are satisfied.
> >
> > Yet it is true that if client code is specifically looking for a
> > 200 response this change, without a version signal, will break
> > that code.
> >
> >   But glance isn't set up with microversions or something like.
> >
> >   But isn't checking specifically for 200 as "success" unusual so
> >   this is unlikely to be as bad as changing a 4xx to some other
> >   4xx.
> >
> >   But correcting the docs so they indicate this one request out of
> >   several in a group breaks the 204 pattern set by the rest of
> >   the group and could easily be perceived as a typo and thus need
> >   to be annotated as "special".
> >
> > How do we reconcile that?
>
> This API has been implemented since 2 years ago, and it is easy to
> imagine many users are using the API.
> If changing success status code like this, we send a message "status
> code could be changed anytime" to users and users would recognize "the
> success status code is unstable and it is better to check status code
> range(20X) instead of a certain code(200, 201, etc) for long-term
> maintenance".
>

I think we should be pragmatic. There's a a difference between changing one
return code from 200->204 (still in the 2XX range), for one endpoint
exceptionally and saying "we keep changing status code, OpenStack is not
stable".

Microversions are great, but not all projects support them yet. In the mean
time, if a project properly documents through a release note a minor API
change (like this one), that sounds reasonable. Sure some user code will
break, at upgrade, but let's be realistic here things get broken after a
major upgrade of every software, that's why operators/deployers test the
upgrades beforehand.


>
> If the above is we expect/hope, why should we fix/change success code
> to ideal one?
> On the above scenario, we are expecting users should not check a certain
> code.
> So even if changing status code, users would not be affected by the change.
> Whom we are changing the status code for?
>

That's a good question. In that case we should do it "for us, the
developers". I prefer to work with a sane code base, sane API, small
technical debt. But I also understand the users are paying us for
stability.


> That seems a dilemma.
>

I would say we should make compromise, not solve dilemma. I can live in a
world where we sometimes

Re: [openstack-dev] [all][api] POST /api-wg/news

2017-02-03 Thread Ken'ichi Ohmichi

2017-02-03 9:56 GMT-08:00 Chris Dent :
> On Thu, 2 Feb 2017, Ken'ichi Ohmichi wrote:
>>>
>>> In today's meeting [0] after briefly covering old business we spent
>>> nearly
>>> 50 minutes going round in circles discussing the complex interactions of
>>> expectations of API stability, the need to fix bugs and the costs and
>>> benefits of microversions. We didn't make a lot of progress on the
>>> general
>>> issues, but we did #agree that a glance issue [4] should be treated as a
>>> code bug (not a documentation bug) that should be fixed. In some ways
>>> this
>>> position is not aligned with the ideal presented by stability guidelines
>>> but
>>> it is aligned with an original goal of the API-WG: consistency. It's
>>> unclear
>>> how to resolve this conflict, either in this specific instance or in the
>>> guidelines that the API-WG creates. As stated in response to one of the
>>> related reviews [5]: "If bugs like this don't get fixed properly in the
>>> code, OpenStack risks going down the path of Internet Explorer and people
>>> wind up writing client code to the bugs and that way lies madness."
>>
>>
>> I am not sure the code change can avoid the madness.
>
>
> Just for the record, I'm not the speaker of that quote. I included
> it because I think it does a good job of representing the complexity
> and confusion that we have going on or at least in inspiring
> responses that help to do so.
>
> Which is a round about way of saying: Thank you very much for
> responding.

Haha, I see.

>> If we change the success status code (200 ->204) without any version
>> bumps, OpenStack clouds return different status codes on the same API
>> operations.
>> That will break OpenStack interoperability and clients' APPs need to
>> be changed for accepting 204 also as success operation.
>> That could make APPs code mudness.
>> I also think this is basically code bug, but this is hard to fix
>> because of big impact against the existing users.
>
>
> There have been lots of different opinions and perspective on this
> (in the reviews and elsewhere), all of which are pretty sensible but
> as a mass are hard to reconcile. The below is reporting evidence, not
> supporting a plan:
>
>   The API-WG is striving for OpenStack APIs to be consistent within
>   themselves, with each other and with the HTTP RFCs. This particular
>   issue is an example where none of those are satisfied.
>
> Yet it is true that if client code is specifically looking for a
> 200 response this change, without a version signal, will break
> that code.
>
>   But glance isn't set up with microversions or something like.
>
>   But isn't checking specifically for 200 as "success" unusual so
>   this is unlikely to be as bad as changing a 4xx to some other
>   4xx.
>
>   But correcting the docs so they indicate this one request out of
>   several in a group breaks the 204 pattern set by the rest of
>   the group and could easily be perceived as a typo and thus need
>   to be annotated as "special".
>
> How do we reconcile that?

This API has been implemented since 2 years ago, and it is easy to
imagine many users are using the API.
If changing success status code like this, we send a message "status
code could be changed anytime" to users and users would recognize "the
success status code is unstable and it is better to check status code
range(20X) instead of a certain code(200, 201, etc) for long-term
maintenance".

If the above is we expect/hope, why should we fix/change success code
to ideal one?
On the above scenario, we are expecting users should not check a certain code.
So even if changing status code, users would not be affected by the change.
Whom we are changing the status code for?
That seems a dilemma.

Thanks
Ken Ohmichi

---

> Some opinions of my own:
>
> I worry that we're making it ever harder to fix bugs and technical
> debt in many areas of OpenStack. Sure, there are very good reasons
> for the constraints we build in, but how much tech debt are we
> making ourselves carry? We have the versioning concepts to help (for
> those projects that use them) but we haven't yet agreed how to
> cleanly deprecate past stuff or even if we can or should.
>
> I don't feel too bad about that worry, because I know there are
> plenty of people who worry about other things that balance it out
> for a reasonable compromise.
>
>
> --
> Chris Dent ¯\_(ツ)_/¯   https://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
>

__
OpenStack Development Mailing List (not for usage questions)

Re: [openstack-dev] [all][api] POST /api-wg/news

2017-02-03 Thread Chris Dent


On Thu, 2 Feb 2017, Ken'ichi Ohmichi wrote:

2017-02-02 9:38 GMT-08:00 Chris Dent :


Greetings OpenStack community,

In today's meeting [0] after briefly covering old business we spent nearly
50 minutes going round in circles discussing the complex interactions of
expectations of API stability, the need to fix bugs and the costs and
benefits of microversions. We didn't make a lot of progress on the general
issues, but we did #agree that a glance issue [4] should be treated as a
code bug (not a documentation bug) that should be fixed. In some ways this
position is not aligned with the ideal presented by stability guidelines but
it is aligned with an original goal of the API-WG: consistency. It's unclear
how to resolve this conflict, either in this specific instance or in the
guidelines that the API-WG creates. As stated in response to one of the
related reviews [5]: "If bugs like this don't get fixed properly in the
code, OpenStack risks going down the path of Internet Explorer and people
wind up writing client code to the bugs and that way lies madness."


I am not sure the code change can avoid the madness.


Just for the record, I'm not the speaker of that quote. I included
it because I think it does a good job of representing the complexity
and confusion that we have going on or at least in inspiring
responses that help to do so.

Which is a round about way of saying: Thank you very much for
responding.


If we change the success status code (200 ->204) without any version
bumps, OpenStack clouds return different status codes on the same API
operations.
That will break OpenStack interoperability and clients' APPs need to
be changed for accepting 204 also as success operation.
That could make APPs code mudness.
I also think this is basically code bug, but this is hard to fix
because of big impact against the existing users.


There have been lots of different opinions and perspective on this
(in the reviews and elsewhere), all of which are pretty sensible but
as a mass are hard to reconcile. The below is reporting evidence, not
supporting a plan:

  The API-WG is striving for OpenStack APIs to be consistent within
  themselves, with each other and with the HTTP RFCs. This particular
  issue is an example where none of those are satisfied.

Yet it is true that if client code is specifically looking for a
200 response this change, without a version signal, will break
that code.

  But glance isn't set up with microversions or something like.

  But isn't checking specifically for 200 as "success" unusual so
  this is unlikely to be as bad as changing a 4xx to some other
  4xx.

  But correcting the docs so they indicate this one request out of
  several in a group breaks the 204 pattern set by the rest of
  the group and could easily be perceived as a typo and thus need
  to be annotated as "special".

How do we reconcile that?

Some opinions of my own:

I worry that we're making it ever harder to fix bugs and technical
debt in many areas of OpenStack. Sure, there are very good reasons
for the constraints we build in, but how much tech debt are we
making ourselves carry? We have the versioning concepts to help (for
those projects that use them) but we haven't yet agreed how to
cleanly deprecate past stuff or even if we can or should.

I don't feel too bad about that worry, because I know there are
plenty of people who worry about other things that balance it out
for a reasonable compromise.

--
Chris Dent ¯\_(ツ)_/¯   https://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] [all][api] POST /api-wg/news

2017-02-02 Thread Ken'ichi Ohmichi

2017-02-02 9:38 GMT-08:00 Chris Dent :
>
> Greetings OpenStack community,
>
> In today's meeting [0] after briefly covering old business we spent nearly
> 50 minutes going round in circles discussing the complex interactions of
> expectations of API stability, the need to fix bugs and the costs and
> benefits of microversions. We didn't make a lot of progress on the general
> issues, but we did #agree that a glance issue [4] should be treated as a
> code bug (not a documentation bug) that should be fixed. In some ways this
> position is not aligned with the ideal presented by stability guidelines but
> it is aligned with an original goal of the API-WG: consistency. It's unclear
> how to resolve this conflict, either in this specific instance or in the
> guidelines that the API-WG creates. As stated in response to one of the
> related reviews [5]: "If bugs like this don't get fixed properly in the
> code, OpenStack risks going down the path of Internet Explorer and people
> wind up writing client code to the bugs and that way lies madness."

I am not sure the code change can avoid the madness.
If we change the success status code (200 ->204) without any version
bumps, OpenStack clouds return different status codes on the same API
operations.
That will break OpenStack interoperability and clients' APPs need to
be changed for accepting 204 also as success operation.
That could make APPs code mudness.
I also think this is basically code bug, but this is hard to fix
because of big impact against the existing users.

Thanks
Ken Ohmichi

---

__
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-dev] [all][api] POST /api-wg/news

2017-02-02 Thread Chris Dent



Greetings OpenStack community,

In today's meeting [0] after briefly covering old business we spent nearly 50 minutes 
going round in circles discussing the complex interactions of expectations of API 
stability, the need to fix bugs and the costs and benefits of microversions. We didn't 
make a lot of progress on the general issues, but we did #agree that a glance issue [4] 
should be treated as a code bug (not a documentation bug) that should be fixed. In some 
ways this position is not aligned with the ideal presented by stability guidelines but it 
is aligned with an original goal of the API-WG: consistency. It's unclear how to resolve 
this conflict, either in this specific instance or in the guidelines that the API-WG 
creates. As stated in response to one of the related reviews [5]: "If bugs like this 
don't get fixed properly in the code, OpenStack risks going down the path of Internet 
Explorer and people wind up writing client code to the bugs and that way lies 
madness."

One reminder: Projects should make sure that their liaison information is up to 
date at http://specs.openstack.org/openstack/api-wg/liaisons.html . If not, 
please provide a patch to doc/source/liaisons.json to update it.

Three guidelines were merged. None were frozen. Four are being worked on. See 
below.

# Newly Published Guidelines

* Add guideline for invalid query parameters
  https://review.openstack.org/#/c/417441/
* Add guidelines on usage of state vs. status
  https://review.openstack.org/#/c/411528/
* Clarify the status values in versions
  https://review.openstack.org/#/c/411849/

# API Guidelines Proposed for Freeze

Guidelines that are ready for wider review by the whole community.

Nothing newly frozen.

# Guidelines Currently Under Review [3]

* Add guidelines for boolean names
  https://review.openstack.org/#/c/411529/

* Define pagination guidelines
  https://review.openstack.org/#/c/390973/

* Add API capabilities discovery guideline
  https://review.openstack.org/#/c/386555/

* [WIP] Refactor and re-validate api change guidelines
  https://review.openstack.org/#/c/421846/

# Highlighting your API impacting issues

If you seek further review and insight from the API WG, please address your concerns in 
an email to the OpenStack developer mailing list[1] with the tag "[api]" in the 
subject. In your email, you should include any relevant reviews, links, and comments to 
help guide the discussion of the specific challenge you are facing.

To learn more about the API WG mission and the work we do, see OpenStack API 
Working Group [2].

Thanks for reading and see you next week!

# References

[0] 
http://eavesdrop.openstack.org/meetings/api_wg/2017/api_wg.2017-02-02-16.00.html
[1] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[2] http://specs.openstack.org/openstack/api-wg/
[3] https://review.openstack.org/#/q/status:open+project:openstack/api-wg,n,z
[4] https://bugs.launchpad.net/glance/+bug/1656183
[5] https://review.openstack.org/#/c/425487/

Meeting Agenda
https://wiki.openstack.org/wiki/Meetings/API-WG#Agenda
Past Meeting Records
http://eavesdrop.openstack.org/meetings/api_wg/
Open Bugs
https://bugs.launchpad.net/openstack-api-wg

--
Chris Dent ¯\_(ツ)_/¯   https://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

[openstack-dev] [all][api] POST /api-wg/news

2017-01-26 Thread Chris Dent



Greetings OpenStack community,

Today's meeting [0] covered two main topics: Making sure we get input on the 
process for refactoring the api compatibility guidelines [4] and whether we 
should have some official time at the PTG. Rather than having official time we 
decided that the best thing to do was make sure we are available for those 
topics which are relevant (such as discussion of capabilities [5] and service 
catalog and version endpoint clarification [6]) and to hang out with the 
architecture working group. Of the API-WG cores, edleafe and I (cdent) will be 
at the PTG. Find one of us if there's something that ought to be discussed 
there and we'll try to set something up.

# Newly Published Guidelines

Nothing recently published.

# API Guidelines Proposed for Freeze

Guidelines that are ready for wider review by the whole community.

* Add guidelines on usage of state vs. status
  https://review.openstack.org/#/c/411528/

* Clarify the status values in versions
  https://review.openstack.org/#/c/411849/

* Add guideline for invalid query parameters
  https://review.openstack.org/417441

# Guidelines Currently Under Review [3]

* Add guidelines for boolean names
  https://review.openstack.org/#/c/411529/

* Define pagination guidelines
  https://review.openstack.org/#/c/390973/

* Add API capabilities discovery guideline
  https://review.openstack.org/#/c/386555/

# Highlighting your API impacting issues

If you seek further review and insight from the API WG, please address your concerns in 
an email to the OpenStack developer mailing list[1] with the tag "[api]" in the 
subject. In your email, you should include any relevant reviews, links, and comments to 
help guide the discussion of the specific challenge you are facing.

To learn more about the API WG mission and the work we do, see OpenStack API 
Working Group [2].

Thanks for reading and see you next week!

# References

[0] 
http://eavesdrop.openstack.org/meetings/api_wg/2017/api_wg.2017-01-26-16.00.log.html
[1] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[2] http://specs.openstack.org/openstack/api-wg/
[3] https://review.openstack.org/#/q/status:open+project:openstack/api-wg,n,z
[4] https://review.openstack.org/#/c/421846/ and 
http://lists.openstack.org/pipermail/openstack-dev/2017-January/110384.html
[5] https://review.openstack.org/#/c/386555/
[6] http://lists.openstack.org/pipermail/openstack-dev/2017-January/110043.html

Meeting Agenda
https://wiki.openstack.org/wiki/Meetings/API-WG#Agenda
Past Meeting Records
http://eavesdrop.openstack.org/meetings/api_wg/
Open Bugs
https://bugs.launchpad.net/openstack-api-wg

--
Chris Dent ¯\_(ツ)_/¯   https://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

[openstack-dev] [all][api] POST /api-wg/news

2017-01-12 Thread Chris Dent



Greetings OpenStack community,

Exciting meeting today, lots of people, lots of discussion[0]. We started out 
talking about the service-types-authority[4] and whether the api-wg should be 
more directly involved in it. Since there's a fair bit of overlap between 
participants in both groups, we decided that while it is very important for the 
api-wg to help ensure good use and form of the service catalog (and guidelines 
should be created stating as much) there was no particular need to do anything 
more than be present and aware. However this did lead to talk about wanting 
consistent unversioned endpoints in the service catalog. scottda was 
volunteered to follow up on getting some discussion about this happening at the 
PTG (with moral support from edleafe, mordred, and dtroyer).

We then talked about the ongoing issues with the visibility changes in glance. 
There's consensus that the changes (in glance and tempest) are necessary.

Finally we talked about some guidelines, notably ongoing interest in the 
capabilities review https://review.openstack.org/#/c/386555/ and what the 
api-wg's role should be in reviewing and discussing it. If you're curious about 
this it's probably easiest to have a look at the IRC log as there's no simple 
summary: 
http://eavesdrop.openstack.org/meetings/api_wg/2017/api_wg.2017-01-12-16.00.log.html#l-202

Lots of other guidelines in progress and awaiting your feedback if you have 
time to give it (see below).

# Newly Published Guidelines

Nothing new

# API Guidelines Proposed for Freeze

Guidelines that are ready for wider review by the whole community.

None at the moment, but you are always very welcome to review stuff in the next 
section.

# Guidelines Currently Under Review [3]

* Add guidelines on usage of state vs. status
  https://review.openstack.org/#/c/411528/

* Add guidelines for boolean names
  https://review.openstack.org/#/c/411529/

* Clarify the status values in versions
  https://review.openstack.org/#/c/411849/

* Define pagination guidelines
  https://review.openstack.org/#/c/390973/

* Add API capabilities discovery guideline
  https://review.openstack.org/#/c/386555/

* Add guideline for invalid query parameters
  https://review.openstack.org/417441

# Highlighting your API impacting issues

If you seek further review and insight from the API WG, please address your concerns in 
an email to the OpenStack developer mailing list[1] with the tag "[api]" in the 
subject. In your email, you should include any relevant reviews, links, and comments to 
help guide the discussion of the specific challenge you are facing.

To learn more about the API WG mission and the work we do, see OpenStack API 
Working Group [2].

Thanks for reading and see you next week!

# References

[0] 
http://eavesdrop.openstack.org/meetings/api_wg/2017/api_wg.2017-01-12-16.00.html
[1] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[2] http://specs.openstack.org/openstack/api-wg/
[3] https://review.openstack.org/#/q/status:open+project:openstack/api-wg,n,z
[4] https://github.com/openstack/service-types-authority

Meeting Agenda
https://wiki.openstack.org/wiki/Meetings/API-WG#Agenda
Past Meeting Records
http://eavesdrop.openstack.org/meetings/api_wg/
Open Bugs
https://bugs.launchpad.net/openstack-api-wg

--
Chris Dent ¯\_(ツ)_/¯   https://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

[openstack-dev] [all][api] POST /api-wg/news

2017-01-05 Thread Chris Dent



Greetings OpenStack community,

Our first meeting for 2017 opened with a bang. Lots of people in attendance to 
talk about the ongoing adventure of trying to improve the handling of the 
concept of visibility in Glance. If we had had more time we could have 
continued talking about it for a long time. We touched on issues of backwards 
compatibility in the face of semantic confusion, microversions, the value and 
strength of guidelines, and the impact of API changes on users. The current 
blocking issue is described at 
https://etherpad.openstack.org/p/glance-ocata-community-images-api-stability . 
We mostly agreed that the long term satisfaction of all users, existing and 
future, trumps anything else. Further discussion will continue on the review 
mentioned in the etherpad: https://review.openstack.org/#/c/412731/

We also had some pretty strenuous discussion about the pagination review at 
https://review.openstack.org/#/c/390973/ but ran out of time before getting 
into any true discussion of the capabilities review 
https://review.openstack.org/#/c/386555/ .

All of this suggests we've got some useful work to look forward to.

# Newly Published Guidelines

Nothing new

# API Guidelines Proposed for Freeze

Guidelines that are ready for wider review by the whole community.

None at the moment, but you are always very welcome to review stuff in the next 
section.

# Guidelines Currently Under Review [3]

* Add guidelines on usage of state vs. status
  https://review.openstack.org/#/c/411528/

* Add guidelines for boolean names
  https://review.openstack.org/#/c/411529/

* Clarify the status values in versions
  https://review.openstack.org/#/c/411849/

* Define pagination guidelines
  https://review.openstack.org/#/c/390973/

* Add API capabilities discovery guideline
  https://review.openstack.org/#/c/386555/

# Highlighting your API impacting issues

If you seek further review and insight from the API WG, please address your concerns in 
an email to the OpenStack developer mailing list[1] with the tag "[api]" in the 
subject. In your email, you should include any relevant reviews, links, and comments to 
help guide the discussion of the specific challenge you are faciing.

To learn more about the API WG mission and the work we do, see OpenStack API 
Working Group [2].

Thanks for reading and see you next week!

# References

[1] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[2] http://specs.openstack.org/openstack/api-wg/
[3] https://review.openstack.org/#/q/status:open+project:openstack/api-wg,n,z

Meeting Agenda
https://wiki.openstack.org/wiki/Meetings/API-WG#Agenda
Past Meeting Records
http://eavesdrop.openstack.org/meetings/api_wg/
Open Bugs
https://bugs.launchpad.net/openstack-api-wg

--
Chris Dent ¯\_(ツ)_/¯   https://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

[openstack-dev] [all][api] POST /api-wg/news

2016-12-15 Thread Chris Dent

Greetings OpenStack community,

This week we have the pleasure of adding Ed Leafe as a core. Ed has been a
consistent and positive presence for quite some time and he'll be good, by hook
or crook.

Our discussion today was focused in two areas:

* The developing capabilities guideline (at
https://review.openstack.org/#/c/386555/ ). This is something that is likely to
impact many projects but has different levels of socialization between
projects. It needs wide review before it gets too far down into the
implementation details to make sure that the use cases it is trying to address
are well understood and enumerated. The goal is to have a consistent way to
inspect what a cloud can do. Yes, that's a very broad thing that involves user
authorization, cloud deployment hardware and configuration, usage quotas, and
policy. There should be agreement as to whether the answer given is for a
particular user at a particular point in time, or general capabilities for that
particular cloud.

* How to do deal with booleans and concepts of "state" or "status" consistently
in query strings and representations across all the APIs. Ed's going to do some investigation and
produce some strawman proposals as grist for discussion.

Please note that the API-WG meetings scheduled for the 22nd and 29th of
December will be cancelled and thus there will be no more newsletters this
year. Thanks to everyone for helping out this year. See in you January.

# Newly Published Guidelines

* Add clarification on 400 vs. 404 guideline
https://review.openstack.org/#/c/405515/1

# API Guidelines Proposed for Freeze

Guidelines that are ready for wider review by the whole community.

None at the moment.

# Guidelines Currently Under Review [3]

These first two are going to require quite a bit of input from a wide audience.
Both have been tried a few times in the past.

* Define pagination guidelines
https://review.openstack.org/#/c/390973/
This one is a bit stuck, any volunteers to pick it up?

* Add API capabilities discovery guideline
https://review.openstack.org/#/c/386555/

* correct names of capitalization styles
https://review.openstack.org/#/c/411391/

# Highlighting your API impacting issues

To learn more about the API WG mission and the work we do, see OpenStack API
Working Group [2].

Thanks for reading and see you next week!

# References

[1] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[2] http://specs.openstack.org/openstack/api-wg/
[3] https://review.openstack.org/#/q/status:open+project:openstack/api-wg,n,z

Meeting Agenda
https://wiki.openstack.org/wiki/Meetings/API-WG#Agenda
Past Meeting Records
http://eavesdrop.openstack.org/meetings/api_wg/
Open Bugs
https://bugs.launchpad.net/openstack-api-wg

[openstack-dev] [all][api] POST /api-wg/news

2016-12-08 Thread Chris Dent



Greetings OpenStack community,

A new guideline merged this week, describing the "not in" operator for query 
strings, and some clarification of when to use 400 vs 404 is ready for wider review. See 
below for links to both. Other than that, not a lot going on. If you're aware of a 
missing, misleading, or just plain wrong guideline please start a review to fix it, or 
create a bug so that we can remember to do it later.

Please note that the API-WG meetings scheduled for the 22nd and 29th of 
December will be cancelled.

# New guidelines

* Add the operator for "not in" to the filter guideline
  https://review.openstack.org/#/c/399131/

# API guidelines proposed for freeze

Guidelines that are ready for wider review by the whole community.

* Add clarification on 400 vs. 404 guideline
  https://review.openstack.org/#/c/405515/1

# Guidelines currently under review [3]

Both of these are going to require quite a bit of input from a wide audience. 
Both have been tried a few times in the past.

* Define pagination guidelines
  https://review.openstack.org/#/c/390973/
  This one is a bit stuck, any volunteers to pick it up?

* Add API capabilities discovery guideline
  https://review.openstack.org/#/c/386555/

# Highlighting your API impacting issues

If you seek further review and insight from the API WG, please address your concerns in 
an email to the OpenStack developer mailing list[1] with the tag "[api]" in the 
subject. In your email, you should include any relevant reviews, links, and comments to 
help guide the discussion of the specific challenge you are faciing.

To learn more about the API WG mission and the work we do, see OpenStack API 
Working Group [2].

Thanks for reading and see you next week!

## References

[1] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[2] http://specs.openstack.org/openstack/api-wg/
[3] https://review.openstack.org/#/q/status:open+project:openstack/api-wg,n,z

Meeting Agenda
https://wiki.openstack.org/wiki/Meetings/API-WG#Agenda
Past Meeting Records
http://eavesdrop.openstack.org/meetings/api_wg/
Open Bugs
https://bugs.launchpad.net/openstack-api-wg

--
Chris Dent ¯\_(ツ)_/¯   https://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

[openstack-dev] [all][api] POST /api-wg/news

2016-12-01 Thread Chris Dent



Greetings OpenStack community,

Some good attendance and discussion this week. For many months the API-WG has been 
claiming that it would try to review any commit that contained an 'APIImpact' tag. This 
has proven impractical so instead of maintaining a task on our list that we know we're 
not going to do, we've decided to make it official that we aren't doing that anymore (see 
below about "Highlighting your API impacting issues"). Though APIImpact is 
still meaningful within the projects that use it, it should no longer be considered a bat 
signal for the API-WG.

We also discussed the continued ambiguity of when to use a 404 or a 400 
response code when making an incorrect reference to a resource in the body of a 
request. A cinder review[4] started the conversation and the conversation 
(resolving to use 400) led to a proposed adjustment to the guidelines[5].

# New guidelines

No newly merged guidelines this week.

# API guidelines that have been recently merged

Nothing in the recent past.

# API guidelines proposed for freeze

Guidelines that are ready for wider review by the whole community.

* Add the operator for "not in" to the filter guideline
  https://review.openstack.org/#/c/399131/

# Guidelines currently under review [3]

Both of these are going to require quite a bit of input from a wide audience. 
Both have been tried a few times in the past.

* Define pagination guidelines
  https://review.openstack.org/#/c/390973/
  This one is a bit stuck, any volunteers to pick it up?

* Add API capabilities discovery guideline
  https://review.openstack.org/#/c/386555/

# Highlighting your API impacting issues

If you seek further review and insight from the API WG, please address your concerns in 
an email to the OpenStack developer mailing list[1] with the tag "[api]" in the 
subject. In your email, you should include any relevant reviews, links, and comments to 
help guide the discussion of the specific challenge you are faciing.

To learn more about the API WG mission and the work we do, see OpenStack API 
Working Group [2].

Thanks for reading and see you next week!

## References

[1] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[2] http://specs.openstack.org/openstack/api-wg/
[3] https://review.openstack.org/#/q/status:open+project:openstack/api-wg,n,z
[4] https://review.openstack.org/#/c/401941/
[5] https://review.openstack.org/#/c/405515/

Meeting Agenda
https://wiki.openstack.org/wiki/Meetings/API-WG#Agenda
Past Meeting Records
http://eavesdrop.openstack.org/meetings/api_wg/
Open Bugs
https://bugs.launchpad.net/openstack-api-wg

--
Chris Dent ¯\_(ツ)_/¯   https://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

[openstack-dev] [all][api] POST /api-wg/news

2016-11-17 Thread Chris Dent



Greetings OpenStack community,

A pleasant but short meeting this week. During the open discussion we all 
agreed that the increased activity on the mailing list using the [api] tag -- 
with explicit invitations to engage in discussions -- was great to see 
happening and great to participate in. At least as great is the open discussion 
about how to do negation [7] which has led to a proposed guideline [8].

The pagination and capabilities guidelines (below) mentioned last week as being 
important and difficult continue to be actively discussed but have not yet 
reached consensus.

# New guidelines

No newly merged guidelines this week.

# API guidelines that have been recently merged

* Clarify why CRUD is not a great descriptor
  https://review.openstack.org/#/c/392156/
* Add guidelines for complex queries
  https://review.openstack.org/#/c/386614/
* Specify time intervals based filtering queries
  https://review.openstack.org/#/c/383862/

# API guidelines proposed for freeze

No guidelines are frozen at the moment.

# Guidelines currently under review [6]

Both of these are going to require quite a bit of input from a wide audience. 
Both have been tried a few times in the past.

* Define pagination guidelines
  https://review.openstack.org/#/c/390973/

* WIP Add API capabilities discovery guideline
  https://review.openstack.org/#/c/386555/

This one is new:

* Add the operator for "not in" to the filter guideline
  https://review.openstack.org/#/c/399131/

# API Impact reviews currently open

Reviews marked as APIImpact [1] are meant to help inform the working group 
about changes which would benefit from wider inspection by group members and 
liaisons. While the working group will attempt to address these reviews 
whenever possible, it is highly recommended that interested parties attend the 
API WG meetings [2] to promote communication surrounding their reviews.

To learn more about the API WG mission and the work we do, see OpenStack API 
Working Group [3].

Thanks for reading and see you next week!

[1] 
https://review.openstack.org/#/q/status:open+AND+(message:ApiImpact+OR+message:APIImpact),n,z
[2] https://wiki.openstack.org/wiki/Meetings/API-WG#Agenda
[3] http://specs.openstack.org/openstack/api-wg/
[4]: https://bugs.launchpad.net/openstack-api-wg
[5]: http://eavesdrop.openstack.org/meetings/api_wg/
[6]: https://review.openstack.org/#/q/status:open+project:openstack/api-wg,n,z
[7]: http://markmail.org/message/yr3ex6u6kcv4itty
[8]: https://review.openstack.org/#/c/399131/

--
Chris Dent ¯\_(ツ)_/¯   https://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

[openstack-dev] [all][api] POST /api-wg/news

2016-11-10 Thread Chris Dent

Greetings OpenStack community,

Just me (cdent) and edleafe today. We burned through the agenda, quickly
merging the frozen guidelines that were ready to merge. See below. If you think
they are not complete please considering submitting a patch or bug [4] to get
them cleaned up.

The guidelines listed in the "currently under review" section below are
important. If you are itching to participate this would be a great time.

# New guidelines

The following guidelines merged this week:

* Clarify why CRUD is not a great descriptor
https://review.openstack.org/#/c/392156/

* Add guidelines for complex queries
https://review.openstack.org/#/c/386614/

* Specify time intervals based filtering queries
https://review.openstack.org/#/c/383862/

# API guidelines that have been recently merged

No recent guidelines.

# API guidelines proposed for freeze

No guidelines are frozen at the moment.

# Guidelines currently under review [6]

Both of these are going to require quite a bit of input from a wide audience.
Both have been tried a few times in the past.

* Define pagination guidelines
https://review.openstack.org/#/c/390973/

* WIP Add API capabilities discovery guideline
https://review.openstack.org/#/c/386555/

# API Impact reviews currently open

Reviews marked as APIImpact [1] are meant to help inform the working group
about changes which would benefit from wider inspection by group members and
liaisons. While the working group will attempt to address these reviews
whenever possible, it is highly recommended that interested parties attend the
API WG meetings [2] to promote communication surrounding their reviews.

To learn more about the API WG mission and the work we do, see OpenStack API
Working Group [3].

Thanks for reading and see you next week!

[1]
https://review.openstack.org/#/q/status:open+AND+(message:ApiImpact+OR+message:APIImpact),n,z
[2] https://wiki.openstack.org/wiki/Meetings/API-WG#Agenda
[3] http://specs.openstack.org/openstack/api-wg/
[4]: https://bugs.launchpad.net/openstack-api-wg
[5]: http://eavesdrop.openstack.org/meetings/api_wg/
[6]: https://review.openstack.org/#/q/status:open+project:openstack/api-wg,n,z

--
Chris Dent ┬─┬ノ( º _ ºノ)https://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

[openstack-dev] [all][api] POST /api-wg/news

2016-11-03 Thread Chris Dent

Greetings OpenStack community,

This week's meeting of the working group talked about the discussion at the API-WG
"birds of a feather" at last week's summit in Barcelona. Thanks to everyone who
showed up for that. I hope it was interesting and useful. Also thanks very much to all
the people who participated in the API UX feedback sessions[8]. Piet has gathered the raw
data together and will be producing a digested summary soon. From looking at the raw data
it is clear people get a lot of value out of the APIs and while we still have work to do
to make them excellent, the directions we're moving to do so (e.g., consistency, better
error information) are good.

There are a few new guidelines and newly frozen guidelines this week. See
below. Thanks to everyone who has helped to create and refine those.

# New guidelines

There are no new guidelines that have been merged this week.

# API guidelines that have been recently merged

No recent guidelines.

# API guidelines proposed for freeze

The following guidelines are available for broader review by interested
parties. These will be merged in one week if there is no further feedback.

* Add guidelines for complex queries
https://review.openstack.org/#/c/386614/

* Specify time intervals based filtering queries
https://review.openstack.org/#/c/383862/

* Clarify why CRUD is not a great descriptor
https://review.openstack.org/#/c/392156/

# Guidelines currently under review [6]

* Define pagination guidelines
https://review.openstack.org/#/c/390973/

* WIP Add API capabilities discovery guideline
https://review.openstack.org/#/c/386555/

# API Impact reviews currently open

To learn more about the API WG mission and the work we do, see OpenStack API
Working Group [3].

Thanks for reading and see you next week!

[openstack-dev] [all][api] POST /api-wg/news

2016-10-20 Thread michael mccune


Greetings OpenStack community,

This week's meeting of the working group saw some conversation about 
activities related to API topics at the upcoming OpenStack summit. There 
will be a "birds of a feather" session for the working group on 
Wednesday from 12:15-12:55, please see our etherpad for topics[7]. There 
will also an API usability study being done on Monday, for more 
information please see the official wiki[8] and the etherpad with 
suggested topics[9].


We also have frozen 2 guidelines for review by the OpenStack community, 
please see the section below for links.


Finally, there will be no meeting of the working group next week Oct 27 
as most of the community will be focusing on the summit.


# New guidelines

There are no new guidelines that have been merged this week.

# API guidelines that have been recently merged

* add a warning about json expectations
  https://review.openstack.org/#/c/364460/

# API guidelines proposed for freeze

The following guidelines are available for broader review by interested 
parties. These will be merged in one week if there is no further feedback.


* Add guidelines for complex queries
https://review.openstack.org/#/c/386614/

* Specify time intervals based filtering queries
https://review.openstack.org/#/c/383862/

# Guidelines currently under review [6]

There are no other guidelines currently under active review by the 
working group.


# API Impact reviews currently open

Reviews marked as APIImpact [1] are meant to help inform the working 
group about changes which would benefit from wider inspection by group 
members and liaisons. While the working group will attempt to address 
these reviews whenever possible, it is highly recommended that 
interested parties attend the API WG meetings [2] to promote 
communication surrounding their reviews.


To learn more about the API WG mission and the work we do, see OpenStack 
API Working Group [3].


Thanks for reading and see you next week!

[1] 
https://review.openstack.org/#/q/status:open+AND+(message:ApiImpact+OR+message:APIImpact),n,z

[2] https://wiki.openstack.org/wiki/Meetings/API-WG#Agenda
[3] http://specs.openstack.org/openstack/api-wg/
[4]: https://bugs.launchpad.net/openstack-api-wg
[5]: http://eavesdrop.openstack.org/meetings/api_wg/
[6]: 
https://review.openstack.org/#/q/status:open+project:openstack/api-wg,n,z

[7]: https://etherpad.openstack.org/p/api-wg-ocata-bof
[8]: 
https://wiki.openstack.org/wiki/UX#Participate_in_a_usability_study_being_conducted_at_the_Barcelona_Summit.21

[9]: https://etherpad.openstack.org/p/osux-api-oct2016



__
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-dev] [all][api] POST /api-wg/news

2016-10-13 Thread michael mccune


Greetings OpenStack community,

Today's meeting began with a quick review of the API usability tests 
that are being conducted at the Barcelona Summit[7]. We also had two 
lively discussions which took up most of the meeting: one about 
collecting and improving error messages across OpenStack, and the other 
about request semantics with regards to GET and body processing. All 
interested parties can find the logs in the usual place [5] for the full 
details.


In the first conversation, Eddie Ramirez shared some work that he and 
his team have been creating to help improve how we consume errors in 
OpenStack. So far, they have done work collecting errors from a few of 
the most common projects and have incorporated this effort into an error 
knowledge base website[8]. There is some great work here, and we look 
forward to this process advancing with help from the greater OpenStack 
community, here is an etherpad where some ideas have been collected[9].


The other conversation was brought by Ed Leafe and concerns how GET 
requests can be filtered by using either request URL parameters or by 
adding a body to the request. This topic is in relation to a spec[10] 
currently winding its way through the Nova project, and the sincere 
desire of that team to create an API guideline to help define their process.


All in all, a great meeting with good participation and several 
interesting topics.


# New guidelines

There are no new guidelines that have been merged this week, but we did 
accept a change to the landing page.


* add a warning about json expectations
  https://review.openstack.org/#/c/364460/

# API guidelines that have been recently merged

Nothing new in the recent past.

# API guidelines proposed for freeze

The following guidelines are available for broader review by interested 
parties. These will be merged in one week if there is no further feedback.


No new guidelines proposed for freeze this week

# Guidelines currently under review [6]

* Specify time intervals based filtering queries
https://review.openstack.org/#/c/383862/

# API Impact reviews currently open

Reviews marked as APIImpact [1] are meant to help inform the working 
group about changes which would benefit from wider inspection by group 
members and liaisons. While the working group will attempt to address 
these reviews whenever possible, it is highly recommended that 
interested parties attend the API WG meetings [2] to promote 
communication surrounding their reviews.


To learn more about the API WG mission and the work we do, see OpenStack 
API Working Group [3].


Thanks for reading and see you next week!

[1] 
https://review.openstack.org/#/q/status:open+AND+(message:ApiImpact+OR+message:APIImpact),n,z

[2] https://wiki.openstack.org/wiki/Meetings/API-WG#Agenda
[3] http://specs.openstack.org/openstack/api-wg/
[4]: https://bugs.launchpad.net/openstack-api-wg
[5]: http://eavesdrop.openstack.org/meetings/api_wg/
[6]: 
https://review.openstack.org/#/q/status:open+project:openstack/api-wg,n,z
[7]: 
https://wiki.openstack.org/wiki/UX#Participate_in_a_usability_study_being_conducted_at_the_Barcelona_Summit.21

[8]: http://172.99.106.155/exceptions/
[9]: https://etherpad.openstack.org/p/api-error-messages
[10]: https://review.openstack.org/#/c/300178/



__
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-dev] [all][api] POST /api-wg/news

2016-10-06 Thread Chris Dent

Greetings OpenStack community,

Today's meeting we welcomed back the long lost etoews. In addition to the usual
checking up on pending guidelines (there's one newly frozen) we also discussed
a posting made to the mailing list about how best to represent time intervals
[7] and the need to follow up on what, if anything, will be happening at summit
with regard to the API-WG.

The meeting logs are in the usual place [5]. If you find an issue with an
existing guideline [3] or think of one that needs to exist, make a bug [4].
Also, please feel free to review the bugs that are there and if you think there
is one you can resolve, please assign yourself and make it happen. If you have
questions, ask in the #openstack-sdks IRC channel.

# New guidelines

No new guidelines have been merged this week.

# API guidelines that have been recently merged

Nothing new in the recent past.

# API guidelines proposed for freeze

The following guidelines are available for broader review by interested
parties. These will be merged in one week if there is no further feedback.

* add a warning about json expectations
https://review.openstack.org/#/c/364460/

# Guidelines currently under review [6]

There are no new guidelines this week.

# API Impact reviews currently open

To learn more about the API WG mission and the work we do, see OpenStack API
Working Group [3].

Thanks for reading and see you next week!

[openstack-dev] [all][api] POST /api-wg/news

2016-09-22 Thread Chris Dent

Greetings OpenStack community,

Today's meeting was lightly attended and somewhat short, due to scheduling
conflicts. Thanks to those who were able attend. To those who weren't able to
make it: we missed you. The main new area of business was a need to discuss the
planned API usability testing at summit [7].

# New guidelines

No new guidelines have been merged this week.

# API guidelines that have been recently merged

Nothing new in the recent past.

# API guidelines proposed for freeze

The following guidelines are available for broader review by interested
parties. These will be merged in one week if there is no further feedback.

Nothing new this week.

# Guidelines currently under review [6]

There are no new guidelines this week, there is one proposal open for comments
though.

* add a warning about json expectations
https://review.openstack.org/#/c/364460/

# API Impact reviews currently open

To learn more about the API WG mission and the work we do, see OpenStack API
Working Group [3].

Thanks for reading and see you next week!

[openstack-dev] [all][api] POST /api-wg/news

2016-09-15 Thread michael mccune


Greetings OpenStack community,

There was no meeting of the working group this week as several of our 
members have scheduling conflicts.


The meeting logs are in the usual place [5]. If you find an issue with 
an existing guideline [3] or think of one that needs to exist, make a 
bug [4].


# New guidelines

No new guidelines have been merged this week.

# API guidelines that have been recently merged

* Add the beginning of a set of guidlines for URIs
  https://review.openstack.org/322194
* A guideline for links
  https://review.openstack.org/354266
* Clear the case if the version string isn't parsable
  https://review.openstack.org/346846

# API guidelines proposed for freeze

The following guidelines are available for broader review by interested 
parties. These will be merged in one week if there is no further feedback.


Nothing new this week.

# Guidelines currently under review [6]

There are no new guidelines this week, there is one proposal open for 
comments though.


* add a warning about json expectations
  https://review.openstack.org/#/c/364460/

# API Impact reviews currently open

Reviews marked as APIImpact [1] are meant to help inform the working 
group about changes which would benefit from wider inspection by group 
members and liaisons. While the working group will attempt to address 
these reviews whenever possible, it is highly recommended that 
interested parties attend the API WG meetings [2] to promote 
communication surrounding their reviews.


To learn more about the API WG mission and the work we do, see OpenStack 
API Working Group [3].


Thanks for reading and see you next week!

[1] 
https://review.openstack.org/#/q/status:open+AND+(message:ApiImpact+OR+message:APIImpact),n,z

[2] https://wiki.openstack.org/wiki/Meetings/API-WG#Agenda
[3] http://specs.openstack.org/openstack/api-wg/
[4]: https://bugs.launchpad.net/openstack-api-wg
[5]: http://eavesdrop.openstack.org/meetings/api_wg/
[6]: 
https://review.openstack.org/#/q/status:open+project:openstack/api-wg,n,z


__
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-dev] [all][api] POST /api-wg/news

2016-09-08 Thread michael mccune


Greetings OpenStack community,

This week the working group has been discussing an interesting topic 
raised by Michael Krotscheck on the devel mailing list[7]. This 
discussion is mainly about how we can create a more consistent API 
version discovery mechanism across the OpenStack projects, and whether 
the discovery endpoints should be restricted by authenticated access. As 
with any cross-project effort, this topic has many nuances and we are 
hopeful that there will be a path forward to making version discovery a 
more smooth process in the future.


The meeting logs are in the usual place [5]. If you find an issue with 
an existing guideline [3] or think of one that needs to exist, make a 
bug [4].


# New guidelines

No new guidelines have been merged this week.

# API guidelines that have been recently merged

* Add the beginning of a set of guidlines for URIs
  https://review.openstack.org/322194
* A guideline for links
  https://review.openstack.org/354266
* Clear the case if the version string isn't parsable
  https://review.openstack.org/346846

# API guidelines proposed for freeze

The following guidelines are available for broader review by interested 
parties. These will be merged in one week if there is no further feedback.


Nothing new this week.

# Guidelines currently under review [6]

There are no new guidelines, but a change is being proposed to add a 
notice about the intent of the guidelines based on some comments from 
John Dickinson[8][9].


* add a warning about json expectations
  https://review.openstack.org/#/c/364460/

# API Impact reviews currently open

Reviews marked as APIImpact [1] are meant to help inform the working 
group about changes which would benefit from wider inspection by group 
members and liaisons. While the working group will attempt to address 
these reviews whenever possible, it is highly recommended that 
interested parties attend the API WG meetings [2] to promote 
communication surrounding their reviews.


To learn more about the API WG mission and the work we do, see OpenStack 
API Working Group [3].


Thanks for reading and see you next week!

[1] 
https://review.openstack.org/#/q/status:open+AND+(message:ApiImpact+OR+message:APIImpact),n,z

[2] https://wiki.openstack.org/wiki/Meetings/API-WG#Agenda
[3] http://specs.openstack.org/openstack/api-wg/
[4]: https://bugs.launchpad.net/openstack-api-wg
[5]: http://eavesdrop.openstack.org/meetings/api_wg/
[6]: 
https://review.openstack.org/#/q/status:open+project:openstack/api-wg,n,z

[7]: http://markmail.org/message/o4k7wd7vqxon2ypk
[8]: https://review.openstack.org/#/c/322194/
[9]: https://review.openstack.org/#/c/354266/

__
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-dev] [all][api] POST /api-wg/news

2016-09-01 Thread Everett Toews

Subject: [all][api] POST /api-wg/news

Greetings OpenStack community,

Today we were joined by Scott DAngelo (scottda) who has graciously taken over 
the liaison role for Cinder as Alex Meade steps down. Thanks for stepping up 
Scott and welcome to the API WG!

We also cleaned house today and merged the 3 guidelines below. Mike McCune made 
plans to dirty up our clean house and will begin work on one of bugs.

The meeting logs are in the usual place [5]. If you find an issue with an 
existing guideline [3] or think of one that needs to exist, make a bug [4].

# New guidelines

Nothing new this week.

# API guidelines that have been recently merged

* Add the beginning of a set of guidlines for URIs
  https://review.openstack.org/322194
* A guideline for links
  https://review.openstack.org/354266
* Clear the case if the version string isn't parsable
  https://review.openstack.org/346846

# API guidelines proposed for freeze

The following guidelines are available for broader review by interested 
parties. These will be merged in one week if there is no further feedback.

Nothing new this week.

# Guidelines currently under review [7]

Nothing new this week.

# API Impact reviews currently open

Reviews marked as APIImpact [1] are meant to help inform the working group 
about changes which would benefit from wider inspection by group members and 
liaisons. While the working group will attempt to address these reviews 
whenever possible, it is highly recommended that interested parties attend the 
API WG meetings [2] to promote communication surrounding their reviews.

To learn more about the API WG mission and the work we do, see OpenStack API 
Working Group [3].

Thanks for reading and see you next week!

[1] 
https://review.openstack.org/#/q/status:open+AND+(message:ApiImpact+OR+message:APIImpact),n,z
[2] https://wiki.openstack.org/wiki/Meetings/API-WG#Agenda
[3] http://specs.openstack.org/openstack/api-wg/
[4]: https://bugs.launchpad.net/openstack-api-wg
[5]: http://eavesdrop.openstack.org/meetings/api_wg/
[7]: https://review.openstack.org/#/q/status:open+project:openstack/api-wg,n,z
__
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-dev] [all][api] POST /api-wg/news

2016-08-25 Thread Chris Dent



Greetings OpenStack community,

Just me (cdent) and etoews today. We merged one guideline, froze some others 
and worked on making some links to the links guideline from other guidelines:

[5:40pm] cdent: hypermedia everywhere!
[5:41pm] etoews: it's the HT in HTML and HTTP!
[5:41pm] cdent: ™

The meeting logs are in the usual place [5]. If you find an issue with an 
existing guideline [3] or think of one that needs to exist, make a bug [4].

# New guidelines

Nothing new this week.

# API guidelines that have been recently merged

* Clarify backslash usage for 'in' operator
  https://review.openstack.org/#/c/353396/

# API guidelines proposed for freeze

The following guidelines are available for broader review by interested 
parties. These will be merged in one week if there is no further feedback.

* Add the beginning of a set of guidlines for URIs
  https://review.openstack.org/#/c/322194/
* Clarify handling of bad microversion strings
  https://review.openstack.org/#/c/346846/
* A guideline for links
  https://review.openstack.org/354266

# Guidelines currently under review [7]

At the moment everything is either frozen or merged.

# API Impact reviews currently open

Reviews marked as APIImpact [1] are meant to help inform the working group 
about changes which would benefit from wider inspection by group members and 
liaisons. While the working group will attempt to address these reviews 
whenever possible, it is highly recommended that interested parties attend the 
API-WG meetings [2] to promote communication surrounding their reviews.

To learn more about the API WG mission and the work we do, see OpenStack API 
Working Group [3].

Thanks for reading and see you next week!

[1] 
https://review.openstack.org/#/q/status:open+AND+(message:ApiImpact+OR+message:APIImpact),n,z
[2] https://wiki.openstack.org/wiki/Meetings/API-WG#Agenda
[3] http://specs.openstack.org/openstack/api-wg/
[4]: https://bugs.launchpad.net/openstack-api-wg
[5]: http://eavesdrop.openstack.org/meetings/api_wg/
[7]: https://review.openstack.org/#/q/status:open+project:openstack/api-wg,n,z

--
Chris Dent   ┬─┬ノ( º _ ºノ)https://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

[openstack-dev] [all][api] POST /api-wg/news

2016-08-18 Thread michael mccune

Greetings OpenStack community,

Today's open discussion centered around the concept of capabilities and
the need to ensure that however we end up doing them in APIs there
should be consistency amongst the existing OpenStack services. In fact,
it would be great if there were consistency between how OpenStack
chooses to do it and how it is done on the rest of the web. More
research required.

Brian Rosmaita visited to discuss similar issues around discovery of
detailed functionality in the glance import API[6]. It's unclear if
these details are the same as capabilities. What's clear is that we'll
need to be tracking this carefully to avoid creating confusion.

The meeting logs are in the usual place. [5]

# New guidelines

* A guideline for links
https://review.openstack.org/354266

# API guidelines proposed for freeze

The following guidelines are available for broader review by interested
parties. These will be merged in one week if there is no further feedback.

* Add the beginning of a set of guidlines for URIs
https://review.openstack.org/#/c/322194/
* Clarify backslash usage for 'in' operator
https://review.openstack.org/#/c/353396/

# Guidelines currently under review

These are guidelines that the working group are debating and working on
for consistency and language. We encourage any interested parties to
join in the conversation.

* Clear the case if the version string isn't parsable
https://review.openstack.org/#/c/346846/

# API Impact reviews currently open

Reviews marked as APIImpact [1] are meant to help inform the working
group about changes which would benefit from wider inspection by group
members and liaisons. While the working group will attempt to address
these reviews whenever possible, it is highly recommended that
interested parties attend the API-WG meetings [2] to promote
communication surrounding their reviews.

To learn more about the API WG mission and the work we do, see OpenStack
API Working Group [3].

Thanks for reading and see you next week!

[1]
https://review.openstack.org/#/q/status:open+AND+(message:ApiImpact+OR+message:APIImpact),n,z

[2] https://wiki.openstack.org/wiki/Meetings/API-WG#Agenda
[3] http://specs.openstack.org/openstack/api-wg/
[4]: https://bugs.launchpad.net/openstack-api-wg
[5]: http://eavesdrop.openstack.org/meetings/api_wg/
[6]:
https://specs.openstack.org/openstack/glance-specs/specs/mitaka/approved/image-import/image-import-refactor.html#discovery

__
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-dev] [all][api] POST /api-wg/news

2016-08-11 Thread Everett Toews

Greetings OpenStack community,

Our main new topic for today was making sure that we take a more active role in 
curating the bugs that are now being kept in launchpad [4] by including review 
of those bugs in the workshopping that we do in each meeting. If you find 
issues in the existing guidelines or think a guideline is missing, make a bug.

The meeting logs are in the usual place. [5]

# New guidelines

* A guideline for links
  https://review.openstack.org/354266

# API guidelines proposed for freeze

The following guidelines are available for broader review by interested 
parties. These will be merged in one week if there is no further feedback.

* Add the beginning of a set of guidlines for URIs
  https://review.openstack.org/#/c/322194/

# Guidelines currently under review

These are guidelines that the working group are debating and working on for 
consistency and language. We encourage any interested parties to join in the 
conversation.

* Clarify backslash usage for 'in' operator
  https://review.openstack.org/#/c/353396/
* Clear the case if the version string isn't parsable
  https://review.openstack.org/#/c/346846/

# API Impact reviews currently open

Reviews marked as APIImpact [1] are meant to help inform the working group 
about changes which would benefit from wider inspection by group members and 
liaisons. While the working group will attempt to address these reviews 
whenever possible, it is highly recommended that interested parties attend the 
API-WG meetings [2] to promote communication surrounding their reviews.

To learn more about the API WG mission and the work we do, see OpenStack API 
Working Group [3].

Thanks for reading and see you next week!

[1] 
https://review.openstack.org/#/q/status:open+AND+(message:ApiImpact+OR+message:APIImpact),n,z
[2] https://wiki.openstack.org/wiki/Meetings/API-WG#Agenda
[3] http://specs.openstack.org/openstack/api-wg/
[4]: https://bugs.launchpad.net/openstack-api-wg
[5]: http://eavesdrop.openstack.org/meetings/api_wg/
__
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-dev] [all][api] POST /api-wg/news

2016-08-04 Thread michael mccune


Greetings OpenStack community,

This week, the API-WG was visited by Deepti Ramakrishna from the Cinder 
project. Deepti brought up a spec currently being implemented by the 
Cinder team about resource capabilities, "New public core APIs to expose 
system capabilities"[5][6]. The result of this was a great discussion[7] 
about the possibility of creating a new guideline for projects that may 
wish to expose capability specific information in their REST API servers.


I'd like to thank Deepti for bringing this up, and I encourage anyone 
who is interested to have a look at the Cinder spec and hopefully share 
their input about how this might be used by other projects in the 
OpenStack ecosystem.


No new guidelines have been merged or proposed for freeze this week.

# Recently merged guidelines

None

# API guidelines proposed for freeze

The following guidelines are available for broader review by interested 
parties. These will be merged in one week if there is no further feedback.


None this week

# Guidelines currently under review

These are guidelines that the working group are debating and working on 
for consistency and language. We encourage any interested parties to 
join in the conversation.


* Add the beginning of a set of guidlines for URIs
  https://review.openstack.org/#/c/322194/
* Add description of pagination parameters
  https://review.openstack.org/190743

Note that some of these guidelines were introduced quite a long time ago 
and need to either be refreshed by their original authors, or adopted by 
new interested parties. If you're the author of one of these older 
reviews, please come back to it or we'll have to mark it abandoned.


# API Impact reviews currently open

Reviews marked as APIImpact [1] are meant to help inform the working 
group about changes which would benefit from wider inspection by group 
members and liaisons. While the working group will attempt to address 
these reviews whenever possible, it is highly recommended that 
interested parties attend the API-WG meetings [2] to promote 
communication surrounding their reviews.


To learn more about the API WG mission and the work we do, see OpenStack 
API Working Group [3].


Thanks for reading and see you next week!

[1] 
https://review.openstack.org/#/q/status:open+AND+(message:ApiImpact+OR+message:APIImpact),n,z

[2] https://wiki.openstack.org/wiki/Meetings/API-WG#Agenda
[3] http://specs.openstack.org/openstack/api-wg/
[4]: https://bugs.launchpad.net/openstack-api-wg
[5]: https://review.openstack.org/#/c/306930/
[6]: https://review.openstack.org/#/c/350310/
[7]: 
http://eavesdrop.openstack.org/irclogs/%23openstack-meeting-3/%23openstack-meeting-3.2016-08-04.log.html#t2016-08-04T16:07:40


__
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-dev] [all] [api] POST /api-wg/news

2016-07-14 Thread michael mccune


Greetings OpenStack community,

No new guidelines have been merged or proposed for freeze this week.

There are 19 outstanding issues in the launchpad bug tracker for the 
working group[4], and we are always looking for more help from the 
community. A few hot issues currently are the need for an acceptable 
guideline on pagination, and some history and advice on why extensions 
have not worked and should not be used. If you are interested in helping 
the effort, please take a look at the issues and reach out to the group.


# Recently merged guidelines

No new guidelines in the last two weeks but the following fixes were merged:

* Get rid of the DRAFT warning at the top of guidelines
  https://review.openstack.org/#/c/330687/
* Remove "Conveying error/fault information" section
  https://review.openstack.org/#/c/330876/

# API guidelines proposed for freeze

The following guidelines are available for broader review by interested 
parties. These will be merged in one week if there is no further feedback.


None this week

# Guidelines currently under review

These are guidelines that the working group are debating and working on 
for consistency and language. We encourage any interested parties to 
join in the conversation.


* Add the beginning of a set of guidlines for URIs
  https://review.openstack.org/#/c/322194/
* Add description of pagination parameters
  https://review.openstack.org/190743

Note that some of these guidelines were introduced quite a long time ago 
and need to either be refreshed by their original authors, or adopted by 
new interested parties. If you're the author of one of these older 
reviews, please come back to it or we'll have to mark it abandoned.


# API Impact reviews currently open

Reviews marked as APIImpact [1] are meant to help inform the working 
group about changes which would benefit from wider inspection by group 
members and liaisons. While the working group will attempt to address 
these reviews whenever possible, it is highly recommended that 
interested parties attend the API-WG meetings [2] to promote 
communication surrounding their reviews.


To learn more about the API WG mission and the work we do, see OpenStack 
API Working Group [3].


Thanks for reading and see you next week!

[1] 
https://review.openstack.org/#/q/status:open+AND+(message:ApiImpact+OR+message:APIImpact),n,z

[2] https://wiki.openstack.org/wiki/Meetings/API-WG#Agenda
[3] http://specs.openstack.org/openstack/api-wg/
[4]: https://bugs.launchpad.net/openstack-api-wg


__
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-dev] [all][api] POST /api-wg/news

2016-07-07 Thread michael mccune


Greetings OpenStack community,

No new guidelines have been merged or proposed for freeze this week, but 
we have cleaned up some of the language in the guideline pages and have 
had some productive discussions initiated by the Glance team about 
changes they are working towards.


# Recently merged guidelines

No new guidelines in the last two weeks but the following fixes were merged:

* Get rid of the DRAFT warning at the top of guidelines
  https://review.openstack.org/#/c/330687/
* Remove "Conveying error/fault information" section
  https://review.openstack.org/#/c/330876/

# API guidelines proposed for freeze

The following guidelines are available for broader review by interested 
parties. These will be merged in one week if there is no further feedback.


None this week

# Guidelines currently under review

These are guidelines that the working group are debating and working on 
for consistency and language. We encourage any interested parties to 
join in the conversation.


* Add the beginning of a set of guidlines for URIs
  https://review.openstack.org/#/c/322194/
* Add description of pagination parameters
  https://review.openstack.org/190743

Note that some of these guidelines were introduced quite a long time ago 
and need to either be refreshed by their original authors, or adopted by 
new interested parties. If you're the author of one of these older 
reviews, please come back to it or we'll have to mark it abandoned.


# API Impact reviews currently open

Reviews marked as APIImpact [1] are meant to help inform the working 
group about changes which would benefit from wider inspection by group 
members and liaisons. While the working group will attempt to address 
these reviews whenever possible, it is highly recommended that 
interested parties attend the API-WG meetings [2] to promote 
communication surrounding their reviews.


To learn more about the API WG mission and the work we do, see OpenStack 
API Working Group [3].


Thanks for reading and see you next week!

[1] 
https://review.openstack.org/#/q/status:open+AND+(message:ApiImpact+OR+message:APIImpact),n,z

[2] https://wiki.openstack.org/wiki/Meetings/API-WG#Agenda
[3] http://specs.openstack.org/openstack/api-wg/



__
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-dev] [all][api] POST /api-wg/news

2016-06-30 Thread Everett Toews

Greetings OpenStack community,

A few interesting developments in the API WG this week.

The API WG reviewed the new Glance Artifact Repository (aka Glare) API [4]. The
team was already adhering to most of the API WG guidelines [3] and after some
reviews they were able to get excellent coverage of the guidelines for their
API. Kudos to the team!

Based on some new information, a couple of guildelines have been abandoned. The
"Add version discovery guideline" [5] was abandoned when we realized we have a
very high level conflict here with the microversion version discovery
guideline. The "Add guideline for Experimental APIs" [6] was abandoned when the
author decided to discuss it further and explore the alternate direction
pointed in the reviews.

# Recently merged guidelines

Nothing new in the last two weeks.

# API guidelines proposed for freeze

The following guidelines are available for broader review by interested
parties. These will be merged in one week if there is no further feedback.

None this week

# Guidelines currently under review

These are guidelines that the working group are debating and working on for
consistency and language. We encourage any interested parties to join in the
conversation.

* Get rid of the DRAFT warning at the top of guidelines
https://review.openstack.org/#/c/330687/
* Remove "Conveying error/fault information" section
https://review.openstack.org/#/c/330876/
* Add the beginning of a set of guidlines for URIs
https://review.openstack.org/#/c/322194/
* Add description of pagination parameters
https://review.openstack.org/190743

Note that some of these guidelines were introduced quite a long time ago and
need to either be refreshed by their original authors, or adopted by new
interested parties. If you're the author of one of these older reviews, please
come back to it or we'll have to mark it abandoned.

# API Impact reviews currently open

Reviews marked as APIImpact [1] are meant to help inform the working group
about changes which would benefit from wider inspection by group members and
liaisons. While the working group will attempt to address these reviews
whenever possible, it is highly recommended that interested parties attend the
API-WG meetings [2] to promote communication surrounding their reviews.

To learn more about the API WG mission and the work we do, see OpenStack API
Working Group [3].

Thanks for reading and see you next week!

[openstack-dev] [all] [api] POST /api-wg/news

2016-06-16 Thread Chris Dent

Greetings OpenStack community,

No new guidelines this week but we did have a very productive time creating
launchpad bugs for all the TODOs that are in the existing guidelines. The idea
is that using launchpad will help to keep the TODOs visible and encourage
action. See them at
https://bugs.launchpad.net/openstack-api-wg/+bugs?field.tag=todo

And, of course, if you think there are bugs in the guidelines, report them.

We also decided that the great big "THIS A DRAFT" warning at the start of the
guidelines [1] suggests that the guidelines are not ready. They are ready but they are
also live documents that evolve. A review is in place to remove the warning [2].

# Recently merged guidelines

Nothing new in the last two weeks.

# API guidelines proposed for freeze

The following guidelines are available for broader review by interested
parties. These will be merged in one week if there is no further feedback.

None this week

# Guidelines currently under review

These are guidelines that the working group are debating and working on for
consistency and language. We encourage any interested parties to join in the
conversation.

* Add the beginning of a set of guidlines for URIs
https://review.openstack.org/#/c/322194/
* Add description of pagination parameters
https://review.openstack.org/190743
* Add guideline for Experimental APIs
https://review.openstack.org/273158
* Add version discovery guideline
https://review.openstack.org/254895

# API Impact reviews currently open

Reviews marked as APIImpact [3] are meant to help inform the working group
about changes which would benefit from wider inspection by group members and
liaisons. While the working group will attempt to address these reviews
whenever possible, it is highly recommended that interested parties attend the
API-WG meetings [4] to promote communication surrounding their reviews.

Thanks for reading and see you next week!

[1] http://specs.openstack.org/openstack/api-wg/
[2] https://review.openstack.org/#/c/330687/
[3]
https://review.openstack.org/#/q/status:open+AND+(message:ApiImpact+OR+message:APIImpact),n,z
[4] https://wiki.openstack.org/wiki/Meetings/API-WG#Agenda

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

[openstack-dev] [all] [api] POST /api-wg/news

2016-06-09 Thread Chris Dent



Greetings OpenStack community,

Nothing new for guidelines this week. In this week's api-wg meeting we had some 
good dicussions about the API for image visibility in glance[1] and the 
forthcoming Glare API[2], including the wisdom: If you're ever going to do 
microversions, then you better microversion
now.

# Recently merged guidelines

Nothing new in the last two weeks.

# API guidelines proposed for freeze

The following guidelines are available for broader review by interested 
parties. These will be merged in one week if there is no further feedback.

None this week

# Guidelines currently under review

These are guidelines that the working group are debating and working on for 
consistency and language. We encourage any interested parties to join in the 
conversation.

* Add the beginning of a set of guidlines for URIs
   https://review.openstack.org/#/c/322194/
* Add description of pagination parameters
   https://review.openstack.org/190743
* Add guideline for Experimental APIs
   https://review.openstack.org/273158
* Add version discovery guideline
   https://review.openstack.org/254895

Note that some of these guidelines were introduced quite a long time ago and 
need to either be refreshed by their original authors, or adopted by new 
interested parties.

# API Impact reviews currently open

Reviews marked as APIImpact [3] are meant to help inform the working group 
about changes which would benefit from wider inspection by group members and 
liaisons. While the working group will attempt to address these reviews 
whenever possible, it is highly recommended that interested parties attend the 
API-WG meetings [4] to promote communication surrounding their reviews.

Thanks for reading and see you next week!

[1] https://review.openstack.org/#/c/271019/
[2] https://review.openstack.org/#/c/283136/
[3] 
https://review.openstack.org/#/q/status:open+AND+(message:ApiImpact+OR+message:APIImpact),n,z
[4] https://wiki.openstack.org/wiki/Meetings/API-WG#Agenda

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

[openstack-dev] [all][api] POST /api-wg/news

2016-06-02 Thread michael mccune


Greetings OpenStack community,

This week there are no new merged guidelines nor guidelines proposed for 
freeze but there is a new guideline discussing ways to ensure that URIs 
are semantically consistent: https://review.openstack.org/#/c/322194/


# Recently merged guidelines

These guidelines have been recently merged by the group.

* Delete multiple metadata items with a single request
  https://review.openstack.org/281511
* Description of how to use etags to avoid lost updates
  https://review.openstack.org/301846

# API guidelines proposed for freeze

The following guidelines are available for broader review by interested 
parties. These will be merged in one week if there is no further feedback.


* None this week

# Guidelines currently under review

These are guidelines that the working group are debating and working on 
for consistency and language. We encourage any interested parties to 
join in the conversation.


* Add the beginning of a set of guidlines for URIs
  https://review.openstack.org/#/c/322194/
* Add description of pagination parameters
  https://review.openstack.org/190743
* Add guideline for Experimental APIs
  https://review.openstack.org/273158
* Add version discovery guideline
  https://review.openstack.org/254895

Note that some of these guidelines were introduced quite a long time ago 
and need to either be refreshed by their original authors, or adopted by 
new interested parties.


# API Impact reviews currently open

Reviews marked as APIImpact [1] are meant to help inform the working 
group about changes which would benefit from wider inspection by group 
members and liaisons. While the working group will attempt to address 
these reviews whenever possible, it is highly recommended that 
interested parties attend the API-WG meetings [2] to promote 
communication surrounding their reviews.


Thanks for reading and see you next week!

[1] 
https://review.openstack.org/#/q/status:open+AND+(message:ApiImpact+OR+message:APIImpact),n,z

[2] https://wiki.openstack.org/wiki/Meetings/API-WG#Agenda


__
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-dev] [all][api] POST /api-wg/news

2016-05-26 Thread michael mccune


Greetings OpenStack community,

Welcome to another edition of the API working group's weekly newsletter.

# Recently merged guidelines

These guidelines have been recently merged by the group.

* Description of how to use etags to avoid lost updates
  https://review.openstack.org/#/c/301846
* Delete multiple metadata items with a single request
  https://review.openstack.org/#/c/281511

# API guidelines proposed for freeze

The following guidelines are available for broader review by interested 
parties. These will be merged in one week if there is no further feedback.


* None this week

# Guidelines currently under review

These are guidelines that the working group are debating and working on 
for consistency and language. We encourage any interested parties to 
join in the conversation.


* Actions guideline
  https://review.openstack.org/234994
* Add description of pagination parameters
  https://review.openstack.org/190743
* Add guideline for Experimental APIs
  https://review.openstack.org/273158
* Add version discovery guideline
  https://review.openstack.org/254895

# APIImpact reviews currently open

Reviews marked as APIImpact are meant to help inform the working group 
about changes which would benefit from wider inspection by group members 
and liaisons. While the working group will attempt to address these 
reviews whenever possible, it is highly recommended that interested 
parties attend the API-WG meetings [1] to promote communication 
surrounding their reviews.


https://review.openstack.org/#/q/status:open+AND+(message:ApiImpact+OR+message:APIImpact),n,z

Thanks for reading and see you next week!

[1] https://wiki.openstack.org/wiki/Meetings/API-WG#Agenda


__
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

70 matches

Mail list logo