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

[Michael McCune]

Greetings OpenStack community,

This week's meeting was mostly ceremonial, with the main topic of
discussion being the office hours for the SIG. If you have not heard
the news about the API-SIG, we are converting from a regular weekly
meeting time to a set of scheduled office hours. This change was
discussed over the course of meeting leading up to the PTG and was
finalized last week. The reasoning behind this decision was summarized
nicely by edleafe in the last newsletter:

We, as a SIG, have recognized that we have moved into a new phase.
With most of the API guidelines that we needed to write having been
written, there is not "new stuff" to make demands on our time. In
recognition of this, we are changing how we will work.


How can you find the API-SIG?

We have 2 office hours that we will hold in the #openstack-sdks
channel on freenode:
* Thursdays 0900-1000 UTC
* Thursdays 1600-1700 UTC

Additionally, there is usually someone from the API-SIG hanging out in
the #openstack-sdks channel. Please feel free to ping dtanstur,
edleafe, or elmiko as direct contacts.

Although this marks the end of our weekly meetings, the API-SIG will
continue to be active in the community and we would like to extend a
hearty "huzzah!" to all the OpenStack contributors, operators, and
users who have helped to create the guidelines and guidance that we
all share.

Huzzah!

If you're interested in helping out, here are some things to get you started:

* The list of bugs [5] indicates several missing or incomplete guidelines.
* The existing guidelines [2] always need refreshing to account for
changes over time. If you find something that's not quite right,
submit a patch [6] to fix it.
* Have you done something for which you think guidance would have made
things easier but couldn't find any? Submit a patch and help others
[6].

# Newly Published Guidelines

* None

# API Guidelines Proposed for Freeze

* None

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

* None

# Guidelines Currently Under Review [3]

* Add an api-design doc with design advice
  https://review.openstack.org/592003

* Update parameter names in microversion sdk spec
  https://review.openstack.org/#/c/557773/

* Add API-schema guide (still being defined)
  https://review.openstack.org/#/c/524467/

* Version and service discovery series
  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 SIG about APIs
that you are developing or changing, 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 SIG mission and the work we do, see our
wiki page [4] and guidelines [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-sig,n,z
[4] https://wiki.openstack.org/wiki/API_SIG
[5] https://storyboard.openstack.org/#!/project/1039
[6] https://git.openstack.org/cgit/openstack/api-sig


Past Meeting Records
http://eavesdrop.openstack.org/meetings/api_sig/
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-sig/news

[Michael McCune]

Greetings OpenStack community,

This week's meeting brings the return of the full SIG core-quartet as
all core members were in attendance. The main topics were the agenda
[7] for the upcoming Denver PTG [8], and the API-SIG still being
listed as TC working group in the governance repository reference
files. We also pushed a minor technical change related to the
reorganization of the project-config for the upcoming Python 3
transition [9]

On the topic of the PTG, there were no new items added or comments
about the current list [7]. There was brief talk about who will be
attending the gathering, but the details have not been finalized yet.

As always if you're interested in helping out, in addition to coming
to the meetings, there's also:

* The list of bugs [5] indicates several missing or incomplete guidelines.
* The existing guidelines [2] always need refreshing to account for
changes over time. If you find something that's not quite right,
submit a patch [6] to fix it.
* Have you done something for which you think guidance would have made
things easier but couldn't find any? Submit a patch and help others
[6].

# Newly Published Guidelines

* None

# API Guidelines Proposed for Freeze

* None

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

* None

# Guidelines Currently Under Review [3]

* Add an api-design doc with design advice
  https://review.openstack.org/592003

* Update parameter names in microversion sdk spec
  https://review.openstack.org/#/c/557773/

* Add API-schema guide (still being defined)
  https://review.openstack.org/#/c/524467/

* 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 SIG about APIs
that you are developing or changing, 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 SIG mission and the work we do, see our
wiki page [4] and guidelines [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://wiki.openstack.org/wiki/API_SIG
[5] https://bugs.launchpad.net/openstack-api-wg
[6] https://git.openstack.org/cgit/openstack/api-wg
[7] https://etherpad.openstack.org/p/api-sig-stein-ptg
[8] https://www.openstack.org/ptg/
[9] https://review.openstack.org/#/c/593943/

Meeting Agenda
https://wiki.openstack.org/wiki/Meetings/API-SIG#Agenda
Past Meeting Records
http://eavesdrop.openstack.org/meetings/api_sig/
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-sig/news

[Michael McCune]

Greetings OpenStack community,

Today's meeting was primarily focused around two topics: the IETF[7]
draft proposal for Best Practices when building HTTP protocols[8], and
the upcoming OpenStack Project Teams Gathering (PTG)[9].

The group had taken a collective action to read the aforementioned
draft[8], and as such we were well prepared to discuss its nuances.
For the most part, we agreed that the draft is a good prepartory text
when approaching HTTP APIs and that we should provide a link to it
from the guidelines. Although there are a few areas that we identified
as points of discussion regarding the text of the draft, on balance it
was seen as helpful to the OpenStack community and consistent with our
established guidelines.

On the topic of the PTG, the group has started planning for the event
and is in the early stages gathering content. We will soon have an
etherpad available for topic collection and as an added bonus mordred
himself made a pronouncement about the API-SIG meeting being a
priority in his schedule for this PTG. We hope to see you all there!

The OpenStack infra team will be doing the final rename from API-WG to
API-SIG this Friday. Although there are not expected to be any issues
from this rename, we will be updating documentation references, and
appreciate any help in chasing down bugs.

There were no new guidelines to discuss, nor bugs that have arisen
since last week.

As always if you're interested in helping out, in addition to coming
to the meetings, there's also:

* The list of bugs [5] indicates several missing or incomplete guidelines.
* The existing guidelines [2] always need refreshing to account for
changes over time. If you find something that's not quite right,
submit a patch [6] to fix it.
* Have you done something for which you think guidance would have made
things easier but couldn't find any? Submit a patch and help others
[6].

# Newly Published Guidelines

* None

# API Guidelines Proposed for Freeze

* None

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

* None

# Guidelines Currently Under Review [3]

* Update parameter names in microversion sdk spec
  https://review.openstack.org/#/c/557773/

* Add API-schema guide (still being defined)
  https://review.openstack.org/#/c/524467/

* 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 SIG about APIs
that you are developing or changing, 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 SIG mission and the work we do, see our
wiki page [4] and guidelines [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://wiki.openstack.org/wiki/API_SIG
[5] https://bugs.launchpad.net/openstack-api-wg
[6] https://git.openstack.org/cgit/openstack/api-wg
[7] https://ietf.org/
[8] https://tools.ietf.org/html/draft-ietf-httpbis-bcp56bis-06
[9] https://www.openstack.org/ptg/

Meeting Agenda
https://wiki.openstack.org/wiki/Meetings/API-SIG#Agenda
Past Meeting Records
http://eavesdrop.openstack.org/meetings/api_sig/
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-sig/news

[Michael McCune]

Greetings OpenStack community,

Today's meeting was very brief as both cdent and dtantsur were out.
There were no major items of discussion, but we did acknowledge the
efforts of the GraphQL proof of concept work[7] being led by Gilles
Dubreuil. This work continues to make progress and should provide an
interesting data point for the possibiity of future GraphQL usages.

In addition to the light discussion there was also one guideline
update that was merged this week, and a small infrastructure-related
patch that was merged.

As always if you're interested in helping out, in addition to coming
to the meetings, there's also:

* The list of bugs [5] indicates several missing or incomplete guidelines.
* The existing guidelines [2] always need refreshing to account for
changes over time. If you find something that's not quite right,
submit a patch [6] to fix it.
* Have you done something for which you think guidance would have made
things easier but couldn't find any? Submit a patch and help others
[6].

# Newly Published Guidelines

* Expand error code document to expect clarity
  https://review.openstack.org/#/c/577118/

# API Guidelines Proposed for Freeze

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

None

# Guidelines Currently Under Review [3]

* Add links to errors-example.json
  https://review.openstack.org/#/c/578369/

* Update parameter names in microversion sdk spec
  https://review.openstack.org/#/c/557773/

* Add API-schema guide (still being defined)
  https://review.openstack.org/#/c/524467/

* 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 SIG about APIs
that you are developing or changing, 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 SIG mission and the work we do, see our
wiki page [4] and guidelines [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://wiki.openstack.org/wiki/API_SIG
[5] https://bugs.launchpad.net/openstack-api-wg
[6] https://git.openstack.org/cgit/openstack/api-wg
[7] https://storyboard.openstack.org/#!/story/2002782


Meeting Agenda
https://wiki.openstack.org/wiki/Meetings/API-SIG#Agenda
Past Meeting Records
http://eavesdrop.openstack.org/meetings/api_sig/
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-sig/news

[Michael McCune]

Greetings OpenStack community,

Today's meeting covered a few topics, but was mainly focused on a few
updates to the errors guideline.

We began with a review of last week's actions. Ed Leafe has sent an
email[7] to mailing list to let the folks working on the GraphQL
experiments know that the API-SIG StoryBoard was available for them to
use to track their progress.

We mentioned the proposed time slot[7] for the API-SIG at the upcoming
PTG, but as we are still a few months out from that event no other
actions were proposed.

Next we moved into a discussion of two guideline updates[8][9] that
Chris Dent is proposing. The first review adds concrete examples for
the error responses described in the guideline, and the second adds
some clarifying language and background on the intent of error codes.
During discussion among the group, a few minor areas of improvement
were identified and recorded on the reviews with updates to be made by
Chris.

We discussed the transition to StoryBoard[10] during our bug
discussion, noting the places where the workflow differs from
Launchpad. Chris also showed us a Board[11] that he created to help
figure out how to best use this new tool.

As always if you're interested in helping out, in addition to coming
to the meetings, there's also:

* The list of bugs [5] indicates several missing or incomplete guidelines.
* The existing guidelines [2] always need refreshing to account for
changes over time. If you find something that's not quite right,
submit a patch [6] to fix it.
* Have you done something for which you think guidance would have made
things easier but couldn't find any? Submit a patch and help others
[6].

# Newly Published Guidelines

None

# API Guidelines Proposed for Freeze

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

None

# Guidelines Currently Under Review [3]

* Add links to errors-example.json
  https://review.openstack.org/#/c/578369/

* Expand error code document to expect clarity
  https://review.openstack.org/#/c/577118/

* Update parameter names in microversion sdk spec
  https://review.openstack.org/#/c/557773/

* Add API-schema guide (still being defined)
  https://review.openstack.org/#/c/524467/

* 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 SIG about APIs
that you are developing or changing, 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 SIG mission and the work we do, see our
wiki page [4] and guidelines [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://wiki.openstack.org/wiki/API_SIG
[5] https://bugs.launchpad.net/openstack-api-wg
[6] https://git.openstack.org/cgit/openstack/api-wg
[7] http://lists.openstack.org/pipermail/openstack-dev/2018-June/131881.html
[8] https://review.openstack.org/#/c/578369/
[9] https://review.openstack.org/#/c/577118/
[10] https://storyboard.openstack.org/#!/project/1039
[11] https://storyboard.openstack.org/#!/board/91

Meeting Agenda
https://wiki.openstack.org/wiki/Meetings/API-SIG#Agenda
Past Meeting Records
http://eavesdrop.openstack.org/meetings/api_sig/
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-sig/news

[Michael McCune]

Greetings OpenStack community,

Today's meeting was on the shorter side but covered several topics. We
discussed the migration to StoryBoard, and noted that we need to send
word to Gilles and the GraphQL experimentors that the board is in
place and ready for their usage. The GraphQL work was also highlighted
as there has been a review[7] posted along with an update[8] to the
mailing list. This work is in its early stages, but significant
progress has already been made. Kudos to Gilles and the neutron team!

We talked briefly about the upcoming PTG and which days might be
available for the SIG, but it is too early for such speculation and
the group has tabled the idea for now.

The API-SIG StoryBoard is now live[9], although it still has the old
"api-wg" name. That will be updated when the infra team does the
project rename for us. We encourage all new activity to take place
here and we are in the process of cleaning up the older links; stay
tuned for more information.

There is one new guideline change that is just starting its life in
the review process[10]. This is an addition to the guideline on errors
and although this review is still in the early stages of development
any comments are greatly appreciated.

As always if you're interested in helping out, in addition to coming
to the meetings, there's also:

* The list of bugs [5] indicates several missing or incomplete guidelines.
* The existing guidelines [2] always need refreshing to account for
changes over time. If you find something that's not quite right,
submit a patch [6] to fix it.
* Have you done something for which you think guidance would have made
things easier but couldn't find any? Submit a patch and help others
[6].

# Newly Published Guidelines

None

# API Guidelines Proposed for Freeze

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

None

# Guidelines Currently Under Review [3]

* Expand error code document to expect clarity
  https://review.openstack.org/#/c/577118/

* Update parameter names in microversion sdk spec
  https://review.openstack.org/#/c/557773/

* Add API-schema guide (still being defined)
  https://review.openstack.org/#/c/524467/

* 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 SIG about APIs
that you are developing or changing, 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 SIG mission and the work we do, see our
wiki page [4] and guidelines [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://wiki.openstack.org/wiki/API_SIG
[5] https://bugs.launchpad.net/openstack-api-wg
[6] https://git.openstack.org/cgit/openstack/api-wg
[7] https://review.openstack.org/575120
[8] http://lists.openstack.org/pipermail/openstack-dev/2018-June/131557.html
[9] https://storyboard.openstack.org/#!/project/1039
[10] https://review.openstack.org/#/c/577118/

Meeting Agenda
https://wiki.openstack.org/wiki/Meetings/API-SIG#Agenda
Past Meeting Records
http://eavesdrop.openstack.org/meetings/api_sig/
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-sig/news

[Michael McCune]

Greetings OpenStack community,

Today's meeting was brief, covering only 1 major topic.

The main topic for the SIG today was the migration of bug tracking
from Launchpad to StoryBoard[7]. No firm plans were made to migrate
yet, but the group agreed that this migration would be positive from a
community alignment perspective and that the number of bugs in
conjunction with a low rate of bug addition would make the migration
less risky. There was no opposition to the migration, but it was noted
that the shift from Launchpad to StoryBoard does represent a paradigm
shift and that there is not a 1:1 equivalency between the two. Expect
the SIG to continue researching the migration and put forth a plan to
shift at some point in the future.

Although not a full discussion topic, Chris Dent reinforced the SIG's
commitment to attending the forthcoming writeup about micrversion bump
plans by mordred.

There being no recent changes to pending guidelines nor to bugs, we
ended the meeting early.

As always if you're interested in helping out, in addition to coming
to the meetings, there's also:

* The list of bugs [5] indicates several missing or incomplete guidelines.
* The existing guidelines [2] always need refreshing to account for
changes over time. If you find something that's not quite right,
submit a patch [6] to fix it.
* Have you done something for which you think guidance would have made
things easier but couldn't find any? Submit a patch and help others
[6].

# Newly Published Guidelines

None

# API Guidelines Proposed for Freeze

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

None

# Guidelines Currently Under Review [3]

* Update parameter names in microversion sdk spec
  https://review.openstack.org/#/c/557773/

* Add API-schema guide (still being defined)
  https://review.openstack.org/#/c/524467/

* 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 SIG about APIs
that you are developing or changing, 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 SIG mission and the work we do, see our
wiki page [4] and guidelines [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://wiki.openstack.org/wiki/API_SIG
[5] https://bugs.launchpad.net/openstack-api-wg
[6] https://git.openstack.org/cgit/openstack/api-wg
[7] https://storyboard.openstack.org/#!/page/about

Meeting Agenda
https://wiki.openstack.org/wiki/Meetings/API-SIG#Agenda
Past Meeting Records
http://eavesdrop.openstack.org/meetings/api_sig/
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] [api] notes from api-sig forum meeting on graphql experiment

[Michael McCune]

hi everybody,

i have added my notes to the etherpad[1] from summit.

briefly, we had a great meeting about creating a graphql experiment in
openstack and i tried to capture some of the questions and comments
that flew back and forth.

there seems to be a good consensus that a proof of concept will be
created on the neutron server, most likely in an experimental feature
branch. Gilles Dubreuil has volunteered to lead this effort (thank you
Gilles!), hopefully with some help from a few neutron savy folks ;)

it is still very early in this experiment, but i think there was a
good feeling that if this works it could create some great
opportunities for improvement across the openstack ecosystem. i really
hope it does!

peace o/


[1]: https://etherpad.openstack.org/p/YVR18-API-SIG-forum

__
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-sig/news

[Michael McCune]

Greetings OpenStack community,

Today's meeting was brief, primarily focused on planning for the
summit sessions[7][8] that the SIG will host and facilitate.

The first session[7], will be a Birds of a Feather (BoF) gathering
where the topics will be determined by the attendees. One topic that
will surely make that list is the GraphQL proof of concept for Neutron
that has been discussed on the mailing list[9].

The second session[8], will be a directed discussion addressing
technical debt in the REST APIs of OpenStack.  We're now at the point
where people would like to start removing old code. This session will
give interested parties details about how they can leverage
microversions and the guidelines of the SIG to reduce their debt, drop
old functionality, and improve the consistency of their APIs. It will
also clarify what it means when we bump the minimum microversion for a
service in the future and discuss plans for creating an OpenStack
community goal.

For both sessions, the SIG has aligned itself towards helping
coordinate discussions, clear up misunderstandings, and generally be
helpful in ensuring that all voices are heard and cross-cutting
concerns are addressed. If you are heading to summit, we hope to see
you there!

There being no recent changes to pending guidelines nor to bugs, we
ended the meeting early.

As always if you're interested in helping out, in addition to coming
to the meetings, there's also:

* The list of bugs [5] indicates several missing or incomplete guidelines.
* The existing guidelines [2] always need refreshing to account for
changes over time. If you find something that's not quite right,
submit a patch [6] to fix it.
* Have you done something for which you think guidance would have made
things easier but couldn't find any? Submit a patch and help others
[6].

# Newly Published Guidelines

None

# API Guidelines Proposed for Freeze

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

None

# Guidelines Currently Under Review [3]

* Update parameter names in microversion sdk spec
  https://review.openstack.org/#/c/557773/

* Add API-schema guide (still being defined)
  https://review.openstack.org/#/c/524467/

* 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 SIG about APIs
that you are developing or changing, 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 SIG mission and the work we do, see our
wiki page [4] and guidelines [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://wiki.openstack.org/wiki/API_SIG
[5] https://bugs.launchpad.net/openstack-api-wg
[6] https://git.openstack.org/cgit/openstack/api-wg
[7] 
https://www.openstack.org/summit/vancouver-2018/summit-schedule/events/21798/api-special-interest-group-session
[8] 
https://www.openstack.org/summit/vancouver-2018/summit-schedule/events/21881/api-debt-cleanup
[9] http://lists.openstack.org/pipermail/openstack-dev/2018-May/130219.html

Meeting Agenda
https://wiki.openstack.org/wiki/Meetings/API-SIG#Agenda
Past Meeting Records
http://eavesdrop.openstack.org/meetings/api_sig/
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-sig/news

[Michael McCune]

Greetings OpenStack community,

Today's meeting was quite short and saw a review of everyone's status
and the merging of one guideline.

We began by sharing our current work and plans for the near future.
Although everyone is on tight schedules currently, we discussed the
next steps for the work on the OpenAPI proposal [7] and elmiko has
mentioned that he will return to updating the microversion patch [8]
in the near future.

Next was our standard business of reviewing the frozen and open
guidelines. The guideline on cache-control headers, which had been
frozen last week, received no negative responses from the community,
so it was merged. You can find the link to the merged guideline in the
section below.

As we reviewed our bug status, the group agreed that at some point in
the near future we should take another pass at triaging our bugs. This
work will take place after the upcoming Vancouver forum.

As always if you're interested in helping out, in addition to coming
to the meetings, there's also:

* The list of bugs [5] indicates several missing or incomplete guidelines.
* The existing guidelines [2] always need refreshing to account for
changes over time. If you find something that's not quite right,
submit a patch [6] to fix it.
* Have you done something for which you think guidance would have made
things easier but couldn't find any? Submit a patch and help others
[6].

# Newly Published Guidelines

* Add guidance on needing cache-control headers
  https://review.openstack.org/550468

# API Guidelines Proposed for Freeze

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

None

# Guidelines Currently Under Review [3]

* Update parameter names in microversion sdk spec
  https://review.openstack.org/#/c/557773/

* Add API-schema guide (still being defined)
  https://review.openstack.org/#/c/524467/

* 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 SIG about APIs
that you are developing or changing, 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 SIG mission and the work we do, see our
wiki page [4] and guidelines [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://wiki.openstack.org/wiki/API_SIG
[5] https://bugs.launchpad.net/openstack-api-wg
[6] https://git.openstack.org/cgit/openstack/api-wg
[7] https://gist.github.com/elmiko/7d97fef591887aa0c594c3dafad83442
[8] https://review.openstack.org/#/c/444892/

Meeting Agenda
https://wiki.openstack.org/wiki/Meetings/API-SIG#Agenda
Past Meeting Records
http://eavesdrop.openstack.org/meetings/api_sig/
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-sig/news

[Michael McCune]

Greetings OpenStack community,

Today's meeting was quite lively with a good discussion about versions
and microversions across OpenStack and their usage within the API
schema world. We began with a review of outstanding work: elmiko is
continuing to work on an update to the microversion history doc[7],
and edleafe has reached out[8] to the SDK community to gauge interest
in a session for the upcoming Vancouver forum. dtanstur has also also
made an update[9] to the HTTP guideline layout that is currently under
review. The change was already largely approved; this just improves
the appearance of the refactored guidelines.

The API-SIG has not confirmed any sessions for the Vancouver forum
yet, but we continue to reach out[8] and would ideally like to host a
session including the API, SDK and user community groups. The topics
and schedule for this session will be highly influenced by input from
the larger OpenStack community. If you are interested in seeing this
event happen, please add your thoughts to the mailing sent out by
edleafe[8].

The next chunk of the meeting was spent discussing the OpenAPI
proposal[10] that elmiko has created. The discussion went well and
several new ideas were exposed. Additionally, a deep dive into
version/microversion usage across the OpenStack ecosystem was exposed
with several points being raised about how microversions are used and
how they are perceived by end users. There is no firm output from this
discussion yet, but elmiko is going to contact interested parties and
continue to update the proposal.

mordred informed the SIG that he has started working on
discover/version things in keystoneauth and should be returning to the
related specs within the next few days. and there was much rejoicing.
\o/

On the topic of reviews, the SIG has identified one[11] that is ready
for freeze this week.

Lastly, the SIG reviewed a newly opened bug[12] asking to add a
"severity" field to the error structure. After a short discussion, the
group agreed that this was not something that should be accepted and
have marked it as "won't fix". For more details please see the
comments on the bug review.

As always if you're interested in helping out, in addition to coming
to the meetings, there's also:

* The list of bugs [5] indicates several missing or incomplete guidelines.
* The existing guidelines [2] always need refreshing to account for
changes over time. If you find something that's not quite right,
submit a patch [6] to fix it.
* Have you done something for which you think guidance would have made
things easier but couldn't find any? Submit a patch and help others
[6].

# Newly Published Guidelines

* Add guideline on exposing microversions in SDKs
  https://review.openstack.org/#/c/532814

# API Guidelines Proposed for Freeze

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

* Update the errors guidance to use service-type for code
  https://review.openstack.org/#/c/554921/

# Guidelines Currently Under Review [3]

* Break up the HTTP guideline into smaller documents
  https://review.openstack.org/#/c/554234/

* Add guidance on needing cache-control headers
  https://review.openstack.org/550468

* Update parameter names in microversion sdk spec
  https://review.openstack.org/#/c/557773/

* Add API-schema guide (still being defined)
  https://review.openstack.org/#/c/524467/

* 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 SIG about APIs
that you are developing or changing, 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 SIG mission and the work we do, see our
wiki page [4] and guidelines [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://wiki.openstack.org/wiki/API_SIG
[5] https://bugs.launchpad.net/openstack-api-wg
[6] https://git.openstack.org/cgit/openstack/api-wg
[7] https://review.openstack.org/444892
[8] http://lists.openstack.org/pipermail/openstack-sigs/2018-March/000353.html
[9] https://review.openstack.org/#/c/554234/
[10] https://gist.github.com/elmiko/7d97fef591887aa0c594c3dafad83442
[11] https://review.openstack.org/#/c/554921/
[12] https://bugs.launchpad.net/openstack-api-wg/+bug/1761475

Meeting Agenda
https://wiki.openstack.org/wiki/Meetings/API-SIG#Agenda
Past Meeting Records

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

[Michael McCune]

Greetings OpenStack community,

Another jovial meeting of the API-SIG was convened today. We began with a
few housekeeping notes and then moved into a discussion of the api-ref work
and how we might continue to assist Graham Hayes with the os-api-ref
changes[7] that will output a machine-readable format for the API schemas.
The group generally agrees that the SIG should continue to assist in moving
these changes forward, there are concerns about the inclusion of
microversions and how best to capture these, but for the time being the SIG
will engage with the review and the parties interested in seeing this work
through to completion.

We then talked about the new reviews which have been added recently to the
queue. The SIG has decided to freeze the proposed guidance[8] on exposing
microversions in SDKs created by Dmitry Tantsur. There is also a review[9]
from Ed Leafe to split up the current HTTP guidance document into separate
documents to help improve the readability and presence of this material,
this should be ready for freeze soon.

Lastly, we discussed a new bug[10] concerning how services should be
referenced in error messages. The current guidance specifies that a service
name should be used and the proposed bug by Chris Dent is that the service
type should be used instead. Chris has also created a review[11] to address
this but the SIG would like more opinions on this change and how it might
impact consuming the error messages.

As always if you're interested in helping out, in addition to coming to the
meetings, there's also:

* The list of bugs [5] indicates several missing or incomplete guidelines.
* The existing guidelines [2] always need refreshing to account for changes
over time. If you find something that's not quite right, submit a patch [6]
to fix it.
* Have you done something for which you think guidance would have made
things easier but couldn't find any? Submit a patch and help others [6].

# Newly Published Guidelines

None this week.

# API Guidelines Proposed for Freeze

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

* Add guideline on exposing microversions in SDKs
  https://review.openstack.org/#/c/532814

# Guidelines Currently Under Review [3]

* Break up the HTTP guideline into smaller documents
  https://review.openstack.org/#/c/554234/

* Add guidance on needing cache-control headers
  https://review.openstack.org/550468

* Add API-schema guide (still being defined)
  https://review.openstack.org/#/c/524467/

* 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 SIG about APIs that you
are developing or changing, 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 SIG mission and the work we do, see our wiki
page [4] and guidelines [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://wiki.openstack.org/wiki/API_SIG
[5] https://bugs.launchpad.net/openstack-api-wg
[6] https://git.openstack.org/cgit/openstack/api-wg
[7] https://review.openstack.org/#/c/528801/
[8] https://review.openstack.org/#/c/532814/
[9] https://review.openstack.org/#/c/554234/
[10] https://bugs.launchpad.net/openstack-api-wg/+bug/1756464
[11] https://review.openstack.org/#/c/554921/

Meeting Agenda
https://wiki.openstack.org/wiki/Meetings/API-SIG#Agenda
Past Meeting Records
http://eavesdrop.openstack.org/meetings/api_sig/
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] [Openstack-sigs] [all][api] POST /api-sig/news

[Michael McCune]

On Fri, Mar 16, 2018 at 4:55 AM, Chris Dent  wrote:

> 
>
>> So summarize and clarify, we are talking about SDK being able to build
>> their interface to Openstack APIs in an automated way but statically from
>> API Schema generated by every project. Such API Schema is already built in
>> memory during API reference documentation generation and could be saved in
>> JSON format (for instance) (see [5]).
>>
>
> What do you see as the current roadblocks preventing this work from
> continuing to make progress?
>
>
>
Gilles, i'm very curious about how we can help as well.

i am keenly interested in the api-schema work that is happening and i am
coming up to speed with the work that Graham has done, and which previously
existed, on os-api-ref. although i don't have a *ton* of spare free time, i
would like to help as much as i can.

thanks for bringing this up again,

peace o/
__
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-sig/news

[michael mccune]

Greetings OpenStack community,

Today's meeting was brief and primarily covered planning for the PTG. 
Here's a quick recap.


We began by continuing to discuss the bug [8] that is the result of the 
Nova API not properly including caching information in the headers of 
its replies. Dmitry Tantsur has added comments to the bug and the SIG 
will most likely have more input on that report. The SIG has agreed with 
the position described by Chris Dent in the bug report, that this is bug 
and should be remedied as soon as possible. If you have thoughts on 
this, please add your perspective to that bug report.


Next we reviewed the etherpad[7] of topics for the upcoming PTG, with 
the entire group taking an action item to prioritize the issues. If you 
are interested in the topics listed on that etherpad, we invite you to 
please add a "+1" next to anything that you would like to discuss, or a 
-1 if you don't think that topic deserves discussion time.


Lastly, there was some talk of an informal API-SIG meetup for the PTG 
with no firm plans confirmed. Beers may or may not have been discussed.


As always if you're interested in helping out, in addition to coming to 
the meetings, there's also:


* The list of bugs [5] indicates several missing or incomplete guidelines.
* The existing guidelines [2] always need refreshing to account for 
changes over time. If you find something that's not quite right, submit 
a patch [6] to fix it.
* Have you done something for which you think guidance would have made 
things easier but couldn't find any? Submit a patch and help others [6].


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

* Add guideline on exposing microversions in SDKs
  https://review.openstack.org/#/c/532814/

* Add API-schema guide (still being defined)
  https://review.openstack.org/#/c/524467/

* 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 SIG about APIs that 
you are developing or changing, 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 SIG mission and the work we do, see our wiki 
page [4] and guidelines [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://wiki.openstack.org/wiki/API_SIG
[5] https://bugs.launchpad.net/openstack-api-wg
[6] https://git.openstack.org/cgit/openstack/api-wg
[7] https://etherpad.openstack.org/p/api-sig-ptg-rocky
[8] https://bugs.launchpad.net/nova/+bug/1747935

Meeting Agenda
https://wiki.openstack.org/wiki/Meetings/API-SIG#Agenda
Past Meeting Records
http://eavesdrop.openstack.org/meetings/api_sig/
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-sig/news

[michael mccune]

Greetings OpenStack community,

Today's meeting was primarily focused on a request for guidance related 
to action endpoints and on planning topics for the upcoming PTG.


Tommy Hu has sent an email to the developer list[7] describing how 
several types of actions are currently being handled through the cinder 
and nova REST interfaces. In specific this is related to how APIs are 
registered with a gateway service. The current methodology within cinder 
and nova has been to use generic action endpoints, allowing the body of 
the request to further define the action. These overloaded endpoints 
cause difficulty when using an API gateway. The SIG has taken up 
discussion about how this could be improved and what guidance can be 
created for the community. Although no firm plan has been derived yet, 
the SIG will join the conversation on the mailing list and also discuss 
the wider topic of actions at the PTG.


On the topic of the PTG, the SIG has created an etherpad[8] where agenda 
items are starting to be proposed. If you have any topic that you would 
like to discuss, or see discussed, please add it to that etherpad.


As always if you're interested in helping out, in addition to coming to 
the meetings, there's also:


* The list of bugs [5] indicates several missing or incomplete guidelines.
* The existing guidelines [2] always need refreshing to account for 
changes over time. If you find something that's not quite right, submit 
a patch [6] to fix it.
* Have you done something for which you think guidance would have made 
things easier but couldn't find any? Submit a patch and help others [6].


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

* Add guideline on exposing microversions in SDKs
  https://review.openstack.org/#/c/532814/

* 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

* WIP: Add API-schema guide (still being defined)
  https://review.openstack.org/#/c/524467/

# Highlighting your API impacting issues

If you seek further review and insight from the API SIG about APIs that 
you are developing or changing, 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 SIG mission and the work we do, see our wiki 
page [4] and guidelines [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://wiki.openstack.org/wiki/API_SIG
[5] https://bugs.launchpad.net/openstack-api-wg
[6] https://git.openstack.org/cgit/openstack/api-wg
[7] 
http://lists.openstack.org/pipermail/openstack-dev/2018-January/126334.html

[8[ https://etherpad.openstack.org/p/api-sig-ptg-rocky


Meeting Agenda
https://wiki.openstack.org/wiki/Meetings/API-SIG#Agenda
Past Meeting Records
http://eavesdrop.openstack.org/meetings/api_sig/
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-sig/news

[michael mccune]

Greetings OpenStack community,

Happy new year to all and welcome to the first API-SIG meeting of 2018. 
As the SIG is ramping back up after the holiday break we had a few 
topics to kick off the new year and get the ball rolling.


The SIG is working to complete our year in review report that will be 
collected and distributed by the OpenStack foundation. Without spoiling 
the report, 2017 was a year of steady progress for the SIG with several 
efforts aimed at improving interoperability and expanding the 
inclusiveness of the group.


Graham Hayes(mugsie) shared his in-progress work[7][8] towards 
generating machine readable output for API schemas. This is a topic that 
the SIG has studied in the past and that continues to generate interest 
from the community. At the core of this issue is the idea that if a 
project can provide API schemas in a common format with their 
documentation then the job of SDK implementors and other integrators 
will be greatly eased. If you have thoughts or opinions on this topic, 
please review mugsie's proposals and add your input.


Monty Taylor(mordred) has been investigating how pagination is 
implemented across the OpenStack ecosystem. It appears that there are 
several differing implementations that exist and this is causing some 
friction in the SDK development process. Although there is already a 
guideline about pagination, the SIG is examining how best they can help 
projects move towards consistency in this area and will continue to 
discuss solutions in the next meeting.



* The list of bugs [5] indicates several missing or incomplete guidelines.
* The existing guidelines [2] always need refreshing to account for 
changes over time. If you find something that's not quite right, submit 
a patch [6] to fix it.
* Have you done something for which you think guidance would have made 
things easier but couldn't find any? Submit a patch and help others [6].


# 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

* WIP: Add API-schema guide (still being defined)
  https://review.openstack.org/#/c/524467/

# Highlighting your API impacting issues

If you seek further review and insight from the API SIG about APIs that 
you are developing or changing, 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 SIG mission and the work we do, see our wiki 
page [4] and guidelines [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://wiki.openstack.org/wiki/API_SIG
[5] https://bugs.launchpad.net/openstack-api-wg
[6] https://git.openstack.org/cgit/openstack/api-wg
[7] https://review.openstack.org/#/c/524467/
[8] https://review.openstack.org/#/c/528801/


Meeting Agenda
https://wiki.openstack.org/wiki/Meetings/API-SIG#Agenda
Past Meeting Records
http://eavesdrop.openstack.org/meetings/api_sig/
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-sig/news

[michael mccune]

Greetings OpenStack community,

Today's meeting was relatively short and covered a few topics 
surrounding OpenStack SDKs and expanding the meeting times.


On the topic of OpenStack SDKs, there is a proposal [7] being crafted 
for an SDK certification program. Our discussions mainly centered around 
the question of involvement from the SIG in the process and also what 
definitions would be used for a baseline certification. Although no 
clear answer was reached on the latter topic, the group agreed that we 
should watch the proposal status and become involved if it grows and 
progresses.


There has been an outstanding request to the SIG for hosting a meeting 
in a more APAC friendly time. Ed Leafe has posted an email [8] and 
created a survey [9] to help narrow down times that might work for 
potential attendees. If you are interested in attending a meeting that 
would fit in the APAC time zones, please add your comments to the email 
thread and respond to the survey with your preferences. The SIG has 
received low responses to both surveys that have been created on this 
issue so if you are passionate about seeing meetings occur in a more 
friendly time zone please add your response and tell your friends to do 
the same!


As the holiday season is nearly upon us, the API-SIG will host its next 
meeting on January 4, 2018. Hope to see you then!


* The list of bugs [5] indicates several missing or incomplete guidelines.
* The existing guidelines [2] always need refreshing to account for 
changes over time. If you find something that's not quite right, submit 
a patch [6] to fix it.
* Have you done something for which you think guidance would have made 
things easier but couldn't find any? Submit a patch and help others [6].


# 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

* WIP: Add API-schema guide (still being defined)
  https://review.openstack.org/#/c/524467/

# Highlighting your API impacting issues

If you seek further review and insight from the API SIG about APIs that 
you are developing or changing, 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 SIG mission and the work we do, see our wiki 
page [4] and guidelines [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://wiki.openstack.org/wiki/API_SIG
[5] https://bugs.launchpad.net/openstack-api-wg
[6] https://git.openstack.org/cgit/openstack/api-wg
[7] http://lists.openstack.org/pipermail/openstack/2017-December/045844.html
[8] 
http://lists.openstack.org/pipermail/openstack-dev/2017-December/125304.html

[9] https://doodle.com/poll/bec9gfff38zvh3ud

Meeting Agenda
https://wiki.openstack.org/wiki/Meetings/API-SIG#Agenda
Past Meeting Records
http://eavesdrop.openstack.org/meetings/api_sig/
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] [api] api-sig weekly meeting time change request

[michael mccune]

On 12/03/2017 10:26 PM, Gilles Dubreuil wrote:

Hi,

Could we please change the API SIG weekly meeting time from 16pm UTC to 
19pm UTC  [1]?

To give a chance for those down under to attend?


hey Gilles,

we have proposed adding another meeting time to make things easier for 
folks in the APAC regions. sadly, every time we have brought this up the 
response has been lackluster from people in that region.


i think the group is willing to discuss having a meeting time to enable 
APAC but it would be helpful to have a good indication of who the 
meeting would serve as pushing the time back by 3 hours will negatively 
impact the EMEA folks. i had sent this survey[1] to the mailing list but 
didn't get much response.


peace o/

[1]: https://goo.gl/forms/0mVV4TGT7bZGAK323



Cheers,
Gilles

[1] 
https://www.timeanddate.com/worldclock/meetingtime.html?iso=20171204=195=137=240 






__
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-sig/news

[michael mccune]

Greetings OpenStack community,

Today's meeting was relatively short, with a few important topics taking 
the spotlight.


cdent has posted a message[5] seeking feedback and discussion about a 
session for the SIG at the upcoming Sydney Forum. If you will be in 
Sydney, or have topics that should be addressed, please review this 
message and leave your thoughts.


There was also discussion about mordred's proposed guidelines on service 
discovery[6]. This is still very much a work in progress but there has 
been work done on keystoneauth to support the proposal. During that work 
on keystoneauth, there have been discoveries which have reflected on 
ideas in the original proposal. Expect that this proposal will be 
updated within the next week or two as the zuul v3 work finishes.


The idea was floated about creating a sort of "cheat sheet" that could 
help newcomers and veterans alike in navigating and quickly finding 
specific guidance. This idea was well-accepted by the group and will 
continue to be investigated in an exploratory manner.


# Newly Published Guidelines

None

# API Guidelines Proposed for Freeze

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

None this week

# Guidelines Currently Under Review [3]

* Updates for rename to SIG
  https://review.openstack.org/#/c/508242/

* 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 SIG about APIs that 
you are developing or changing, 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 SIG mission and the work we do, see our wiki 
page [4] and guidelines [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://wiki.openstack.org/wiki/API_SIG
[5] http://forumtopics.openstack.org/cfp/details/52
[6] https://review.openstack.org/#/c/459405/

Meeting Agenda
https://wiki.openstack.org/wiki/Meetings/API-SIG#Agenda
Past Meeting Records
http://eavesdrop.openstack.org/meetings/api_sig/
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-sig/news

[michael mccune]

Greetings OpenStack community,

This week's meeting was primarily focused on reviewing the discussions 
and plans that were proposed at the PTG. We also merged one new 
guideline which was frozen prior to the PTG.


For a review of PTG activity, please see the etherpad[4]

One of the big takeaways from the PTG for the API-SIG was how the SIG is 
perceived by the user community. We had not realized that the user 
community considered us 'dev-only', which was never our intent. We 
agreed that it is in the best interest of all to become more inclusive 
of SDK and user-related concerns. This spurred a good deal of 
conversation at the PTG, and the SIG is starting to make plans about how 
we can best meet the user community's needs, and include their concerns 
in our guidance.


Another big topic from the PTG was a discussion around capabilities and 
how they should be included in OpenStack APIs. There are no concrete 
plans yet, but the conversation in Denver exposed many issues related to 
the techinical and social sides of creating a defining capabilities 
guideline.


Microversions also reared their head in the form of a long discussion 
about how SDK developers and users are consuming microversions at a very 
granular level. This discussion opened many surprised eyes as we learned 
how different SDK platforms deal with microversions, and what exactly 
are the best practices. We agreed that it is generally good for an SDK 
to shield its users from the details of microversions, but to allow 
power users to access them if they care to.


During the Queens cycle you can expect the API-SIG to be taking up these 
issues from the PTG, and become a more open forum for not only API 
consumers, but also to the wider SDK community.


# Newly Published Guidelines

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

# 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://etherpad.openstack.org/p/api-ptg-queens

Meeting Agenda
https://wiki.openstack.org/wiki/Meetings/API-WG#Agenda
Past Meeting Records
http://eavesdrop.openstack.org/meetings/api_sig/
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-sig/news

[michael mccune]

Greetings OpenStack community,

This week's meeting was mainly focused on discussion of plans for the 
PTG and about improving the outreach efforts of the SIG.


The API-SIG will have a room on Monday and Tuesday at the PTG. In 
addition to the guided review process [6] we've mentioned before, 
there's an etherpad [5] where an agenda of topics is being planned. We 
will be sharing some of the time with people interested in SDKs and 
other issues related to consuming APIs. If there are gaps we will be 
performing live readings of mordred's version and service discovery epic 
[4].These readings may or may not involve hand puppets.  If you would 
like to propose a topic for the PTG, please add it to the aforementioned 
etherpad.


In addition to our discussion of events for the PTG, we also talked 
about how we can improve our outreach and messaging to the wider 
OpenStack community. This was predicated by a review of our email 
advertising the guided review process. Although we have talked about 
this topic and taken steps to advance the SIG in the past, a fresh take 
on this discussion revolved around the notion of reaching project teams 
earlier in their API design process. Starting after the PTG, the API-SIG 
will investigate reaching out to projects which are still incubating 
with the hope that interacting with these teams early in their lifecycle 
will be of maximum benefit.


# Newly Published Guidelines

None this week.

# API Guidelines Proposed for Freeze

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

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

# 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] 
http://specs.openstack.org/openstack/api-wg/guidelines/consuming-catalog.html

[5] https://etherpad.openstack.org/p/api-ptg-queens
[6] http://specs.openstack.org/openstack/api-wg/guidedreview.html
[7] https://bugs.launchpad.net/openstack-api-wg/+bug/1593310

Meeting Agenda
https://wiki.openstack.org/wiki/Meetings/API-WG#Agenda
Past Meeting Records
http://eavesdrop.openstack.org/meetings/api_sig/
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-sig/news

[michael mccune]

Greetings OpenStack community,

This week's meeting centered around two main topics; the Guided Review 
Process[0] and the inclusion of guidance to discourage extension 
usage[4]. As the working group has now become a Special Interest Group, 
we have begun the work of changing the documentation and infra services 
over to use the new naming (with many thanks to Ed Leafe).


The Guided Review Process document has been accepted by the SIG as a 
document describing an activity that we will be hosting at PTG events, 
and also as requested by teams. Emails will be sent out this week to all 
the project PTLs with instructions about the review process and how they 
can be prepared to participate at the Queens PTG. If you have not seen 
this document yet, you can find it in the review[0], or on the API-SIG 
specs site[2] once it is redeployed.


Work on the guidance to discourage extension usage[4] continues and 
there have been some comments by members of the community to help drive 
this process along. This topic continues to be a tricky discussion, but 
the SIG is making progress in defining a guideline that will be ready 
for community approval. As with last week, we still haven't fully 
decided how these issues will be explained, but we are getting closer 
and continue to hold the ideal that extension URIs are not helpful for 
creating interoperable APIs.


On the topic of the PTG, there was some minor discussion about what we 
will be talking about beyond guided reviews but this is still in the 
nascent stages. Stay tuned for more information about the API-SIG PTG 
events.


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

__
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

[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

[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

[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

[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

[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

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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[openstack-dev] [all][api] New guidelines ready for cross project review

[michael mccune]

The following proposed API guidelines are available for broader
review by interested parties.

* https://review.openstack.org/#/c/301846
  Description of how to use etags to avoid lost updates

* https://review.openstack.org/#/c/281511
  Delete multiple metadata items with a single request

these will be merged on May 26 id there is no further feedback.

regards,
mike

__
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] [sahara] Nominating new members to Sahara Core

[michael mccune]

On 05/13/2016 11:33 AM, Vitaly Gridnev wrote:

I'd like to bring the following folks to Sahara Core:

1. Lu Huichun


+2


2. Nikita Konovalov


+2


3. Chad Roberts


+2

regards,
mike

__
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] [api] API-WG summit session recap

[michael mccune]

hello all,

We had a great session for the API working group in Austin, and I wanted 
to give a brief recap and extend a thank you to all who attended.


There were about 20-30 people in attendance for the double session 
fishbowl that took place on monday. This turnout was one of the larger 
we have had for the past few summits and it was exciting to see this 
level of engagement from the community. again, thank you =)


Full notes from the session can be found on the etherpad from summit[1].

The session began with a recap of the group's activities for the Mitaka 
cycle. We discussed the guidelines that have been added, as well as our 
success stories with regards to projects that have sought advice from 
the group.


With the old business out of the way, we moved on to discuss topics that 
are of importance to the group moving forward.


Promoting the guidelines


The heart of the API-WG has always been the guidelines that are 
produced, we had a nice discussion about how we can increase the 
awareness and usage of the guidelines.


One big request that came out of this discussion is the need to cleanup 
the group's guideline page to make it clearer which pages are just place 
holders and which contain guidelines.


The group talked about if, and how, we can better integrate with other 
working groups to help create a broader network for the guidelines and 
better APIs in general. The two main groups that were identified as 
possible partners are the Application Ecosystem WG and the SDK WG. 
Although these groups have different focuses than just APIs, there is 
certainly some room for collaboration and consensus among all the groups.


There was also a strong discussion about how the group could advocate 
for more projects to use the guidelines. The main result of this talk 
was the idea of an API-WG related governance tag. Having this tag would 
make a nice signal to end-users about the maturity and development 
status of a project's APIs. Although the details are still in flux, the 
main criteria of a tag were related to projects self-electing into the 
tag, and then creating a series of tests that would prove how their APIs 
follow the guidelines, as well as providing proper API documentation. 
This is still very much a work in progress.


Reviewing the guideline process
===

If the guidelines are the heart of the WG, then our review process is 
the pacemaker ;)


Within the group, a discussion had started before summit about the level 
of email we produce and if it is sufficient. When brought to the table 
at summit, this conversation continued and was well received by the 
audience.


There were several good suggestions about how we can more easily 
communicate what is happening within the group, the state of guidelines 
and reviews that need attention from the group.


the ultimate result of this discussion is that the API-WG will work over 
the Newton cycle to create a weekly email similar to the "What's Up Doc" 
emails from the doc team. These emails will include a summary of 
guidelines that are in freeze, those that have been recently merged, and 
a list of reviews with APIImpact as well as any other business the WG 
might have.


Improving WG participation
==

A constant note from many groups within the OpenStack community is 
participation. The API-WG is no stranger to this topic as we have 
continually searched for methods of improving participation from 
interested parties.


Although there were no clear solutions on this topic, there was wide 
agreement that relying on the CPLs for better engagement with the WG is 
a strong way forward. To this end, the WG will work to make it easier 
for CPLs to bring their APIImpact reviews, and their special interest 
topics, to the group. The methods for doing this will mainly center 
around being more focused in our mailings, and improving our 
communication with respect to guideline reviews.


Dropping the UTC meeting


Somewhere around the Kilo cycle, the API-WG added a second meeting time 
to help our friends in the Asian and Pacific regions join the 
discussion. Unfortunately, after a few cycles of this meeting, its 
attendance is nearly always zero. After some discussion during the 
summit, we have agreed to remove this meeting and return to a single 
weekly meeting at 1600UTC on Thursdays. If the need arises in the 
future, the API-WG will be more than happy to reinstate this meeting.



That about wraps up the review from our summit session, hopefully I 
haven't left out too many details ;)


Thanks again to everyone who attended the session, and thanks to the 
OpenStack community for another excellent summit.


regards,
mike

[1]: https://etherpad.openstack.org/p/austin-api-wg-session-plans

__
OpenStack Development Mailing List (not for usage questions)

Re: [openstack-dev] [kolla][ssecurity] Threat Analysis Design Session

[michael mccune]

On 04/16/2016 02:19 PM, Steven Dake (stdake) wrote:

If the security team has a conflict  with this slot that I didn't see or
am unaware of, please speak up so I can have it corrected in the main
schedule.  Our schedule is here:


sadly, i will miss the beginning of this as i have a conflicting 
presentation.


as much as i'd like to participate, i don't think my absence should 
necessitate a reschedule. just wanted to give a heads up.


regards,
mike


__
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] [neutron] [API]Make API errors conform to the common error message without microversion

[michael mccune]

please forgive my lack of direct knowledge about the neutron process and 
how this fits in. i'm just commenting from the perspective of someone 
looking at this from the api-wg.


On 04/11/2016 09:52 AM, Duncan Thomas wrote:

So by adding the handling of a header to change the behaviour of the
API, you're basically implementing a subset of microversions, with a
non-standard header (See the API WG spec on non-proliferation of
headers). You'll find it takes much of the work that implementing
microversions does, and explodes your API test matrix some more.

Sounds like something that should go on hold until microversions is
done, assuming that microversions are desired anyway. Standard error
messages are not such a big win that they're worth non-standard headers
and yet more API weirdness that needs to sit around potentially for a
very long time (see the API WG rules on removing APIs, which is
basically never)



i think this advice sounds reasonable. adding a side-channel around 
microversions sounds like work that would itself need a microversion 
bump when it is finally removed ;)


i also agree with the reasoning about the benefit from the standardized 
error messages. it is nice to get a standard error message produced, but 
i think adding microversions is probably a bigger win in the near term 
because it will make these other transitions smoother.



On 8 April 2016 at 11:23, Xie, Xianshan > wrote:

Hi, all,

We are attempting to make the neutron API conform to the common
error message format recommended by API-WG [1]. As this change will
introduce a new error format into neutron which is different from
existing  format [2], we should think of some solutions to preserve
the backward compat.

The easiest way to do that is microversion, just like the cinder
does [3] although which is still in progress. But unfortunately,
there are many projects in which the microversion haven't been
landed yet, e.g. neutron,  glance, keystone etc. Thus during the
interim period we have to find other approaches to keep the backward
compat.

According to the discussion, a new header would be a good idea to
resolve this issue [4], we think.
For instance:
curl -X DELETE "http://xxx:9696/v2.0/networks/xxx; -H
"Neutron-Common-Error-Format: True"

But we haven't decided which header name will be used yet.
So how do you think which is the best appropriate one?
A: Neutron-Common-Error-Format
B: OpenStack-Neutron-Common-Error-Format
C: other (Could you please specify it? Thanks in advance)

Any comments would be appreciated.

[1] http://specs.openstack.org/openstack/api-wg/guidelines/errors.html
[2] https://review.openstack.org/#/c/113570/
[3] https://review.openstack.org/#/c/293306/
[4] https://bugs.launchpad.net/neutron/+bug/1554869

Best regards,
xiexs


__
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




--
--
Duncan Thomas


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




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

[openstack-dev] [all][api] Recently accepted API-WG guidelines

[michael mccune]

hello all,

this is a friendly update about guidelines that the API working group 
has recently accepted:


1. version discover guideline for API microversions
https://review.openstack.org/243429

2. client interaction guideline for API microversions
https://review.openstack.org/243414

3. versioning guideline for API microversions
https://review.openstack.org/243041

4. unexpected attribute guideline
https://review.openstack.org/260292


additionally, we have updated our process slightly to better reflect 
ownership of merges.

https://review.openstack.org/#/c/299416/

thanks,
mike

__
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] [sahara][release] missing build artifacts

[michael mccune]

On 04/05/2016 03:56 AM, Thierry Carrez wrote:

We seem to have a sahara-extra build alright:
http://tarballs.openstack.org/sahara-extra/

Please ignore the noise :)



ah, excellent!

thanks for the clarification Thierry


regards,
mike

__
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] [sahara][release] missing build artifacts

[michael mccune]

On 04/01/2016 04:48 PM, Doug Hellmann wrote:

Excerpts from Doug Hellmann's message of 2016-04-01 16:27:42 -0400:

Sahara team,

We noticed in our audit of the links on
http://releases.openstack.org/mitaka/index.html that the links to
the build artifacts for sahara-extras point to missing files. The
repository doesn't seem to have any real build jobs configured in
openstack-infra/project-config/zuul/layout.yaml, so it's not clear
how tagging is producing a release for you.

For now, we are disabling links to the artifacts for those repos
via https://review.openstack.org/300457 but we're also planning to
remove them from the official Mitaka page since there don't appear
to be any actual related deliverables
(https://review.openstack.org/300647).

It would be good to understand what your intent is for builds. Can
you follow up here on this thread with some details?


the sahara-extras repository holds mainly examples for working with 
sahara. it does, however, contain a crucial part of our image 
deployments, namely the hadoop-openstack connector for accessing swift 
with keystone v3 authentication from within hadoop.


with that said though, i think you are correct that we do not actually 
produce a build from this repo. i'm not 100% sure on that, and would 
like to hear from our build wizards. this repository is useful to our 
users though, i'm just not sure how we should be fitting it into the 
larger picture of releases.




Thanks,
Doug



I forgot to mention that https://review.openstack.org/#/c/300474
includes some changes to add the simple server publishing jobs. If you
want to use those, please +1 the patch.

Doug

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




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

[openstack-dev] [security] threat analysis, tags, and the road ahead

[michael mccune]

hey all,

at the most recent ossp meeting[1], there was some extended discussion 
about threat analysis and the work that is being done to push this forward.


in this discussion, there were several topics brought up around the 
process for doing these analyses on current projects and how the ossp 
should proceed especially with respect to the "vulnerability:managed" 
tag[2].


as for the threat analysis process, there are still several questions 
which need to be answered:


* what is the process for performing an analysis

* how will an analysis be formally recognized and approved

* who will be doing these analyses

* does it make sense to keep the analysis process strictly limited to 
the vmt


* how to address commonalities and differences between a developer 
oriented analysis and a deployer oriented analysis


these questions all feed into another related topic, which is the 
proposed initial threat analysis for kolla which has been suggested to 
start at the upcoming austin summit.


i wanted to capture some of the discussion happening around this topic, 
and continue the ball rolling as to how we will solve these questions as 
we head to summit.


one of the big questions seems to be who should be doing these analysis, 
especially given that the ossp has not formally codified the practice 
yet, and the complexity involved. although currently the 
vulnerability:managed tag suggests that a third party review should be 
done, this may prove difficult to scale in practice. i feel that it 
would be in the best interests of the wider openstack community if the 
ossp works towards creating instructional material that can empower the 
project teams to start their own analyses.


ultimately, having a third-party review of a project is worthy goal, but 
this has to be tempered with the reality that a single team will not be 
able to scale out and provide thorough analyses for all projects. to 
that extent, the ossp should work, initially, to help a few teams get 
these analyses completed and in the process create a set of useful tools 
(docs, guides, diagrams, foil-hat wearing pamphlets) to help further the 
effort.


i would like to propose that the threat analysis portion of the 
vulnerability:managed tag be modified with the goal of having the 
project teams create their own analyses, with an extended third-party 
review to be performed afterwards. in this respect, the scale issue can 
be addressed, as well as the issue of project domain knowledge. it makes 
much more sense to me to have the project team creating the initial work 
here as they will know the areas, and architectures, that will need the 
most attention.


as the ossp build better tools for generating these analyses they will 
be in a much better position to guide project teams in their initial 
analyses, with the ultimate goal of having the ossp, and/or vmt, perform 
the third-party audit for application of the tag. i have a feeling we 
will also discover much overlap between the developer and deployer 
oriented analyses, and these overlaps will help to strengthen the 
process for all involved.


finally, the austin summit, and proposed kolla review, provide a great 
opportunity for the ossp to put "rubber on the road" with respect to 
this process. although a full analysis may not be accomplished during 
the summit, we can definitely achieve the goal of defining this process 
much better and creating more guidance for all projects that wish to 
follow this path, as well as having kolla solidly on the way to having a 
full threat analysis ready for third-party review.


thoughts?


regards,
mike


[1]: 
http://eavesdrop.openstack.org/meetings/security/2016/security.2016-03-31-17.00.log.txt


[2]: 
http://governance.openstack.org/reference/tags/vulnerability_managed.html


[3]: https://review.openstack.org/#/c/220712/

__
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] [sahara] PTL non-candidacy

[michael mccune]

i know you are not leaving the project Sergey, but i just wanted to say 
that it's been a true pleasure working with you as the PTL.


regards,
mike

On 03/15/2016 07:33 PM, Sergey Lukjanov wrote:

Hi folks,

the PTL self-nomination period is opened and I want to note that I won’t
be running again as the Data Processing PTL. I’ve been the Sahara PTL
from the beginning of the project (oh, already more then 3 years) and
I’m very proud of the things we’ve achieved over this time. The project
community grown from a few people working not always in open source way
to the successfully incubated and then integrated OpenStack project.

The main reason I’m stepping down is that I have another inter-company
priorities and don’t have enough time to continue being the good PTL.
Another reason - I've started thinking that it’s a healthy flow to
change PTLs each cycle and I’m going to propose this approach on the
upcoming summit for Sahara community.

I’m not planning to fully leave project, I’d like to keep reviewing
(especially specs) and helping with release management, so, I’ll be
around and will help the next PTLs make a transitions where it’ll be needed.

Thanks.

--
Sincerely yours,
Sergey Lukjanov
Principal Software Engineer
Mirantis Inc.


__
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] Reminder: WSME is not being actively maintained

[michael mccune]

On 03/08/2016 04:44 PM, Doug Hellmann wrote:

it seems like the main reason there are so many projects leveraging WSME
is because everyone is just using Ironic or Ceilometer as the starting
point for their APIs. can we officially say to all new projects who plan
on copying API logic of Ironic et al.: 'stop'.


Sure. We should probably provide an alternative suggestion.


just wanted to mention, for the record, that sahara is using flask for 
it's http impl. i am also working on some example usages of flask that 
show off the api-wg guidelines. i'd be happy to help any projects that 
are looking to move in this direction.


regards,
mike


__
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] [sahara][sahara-tests] Sahara-tests release and launchpad project

[michael mccune]

On Fri, Mar 4, 2016 at 12:29 AM, Evgeny Sikachev > wrote:

Hi, sahara folks!

I would like to propose release sahara-tests. All steps from spec
implemented except releases and packaging.[0]

Release criteria: framework ready for testing a new release of Sahara.

Next step: build a package and publish to PyPI.


no objection from me on creating a release, i am curious how we will 
plan future releases though.




Also, I think we need to create a separate Launchpad project (like
python-saharaclient[1]) for correct bugs tracking process. This adds
ability nominate bugs to releases andwill not be a confusion with
Sahara bugs.



i don't have strong opinions about creating a new launchpad. on one 
hand, i can see the value of keeping these bugs separate and having a 
specific location for the project. on the other hand, i generally like 
being able to see all the sahara projects in one place.


thanks for bringing this up Evgeny

regards,
mike



[0]

https://github.com/openstack/sahara-specs/blob/master/specs/mitaka/move-scenario-tests-to-separate-repository.rst
[1] https://bugs.launchpad.net/python-saharaclient





__
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] A proposal to separate the design summit

[michael mccune]

On 02/22/2016 11:33 AM, Jay Pipes wrote:

OpenStack:How <-- The developer planning event.

:)


very nice ;)


__
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] A proposal to separate the design summit

[michael mccune]

On 02/22/2016 11:06 AM, Dmitry Tantsur wrote:

+1 here. I got an impression that midcycles now usually happen in the
US. Indeed, it's probably much cheaper for the majority of contributors,
but would make things worse for non-US folks.


cost of travel has been a big reason we have never managed to have a 
sahara mid-cycle, as the team is evenly split across the world.


mike


__
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] A proposal to separate the design summit

[michael mccune]

On 02/22/2016 10:14 AM, Thierry Carrez wrote:

Hi everyone,

TL;DR: Let's split the events, starting after Barcelona.


as a developer, i'm +1 for this. thanks for all the hard work putting 
this together Thierry.


mike


__
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] [api] header non proliferation (that naming thing, _again_)

[michael mccune]

On 02/22/2016 07:00 AM, Sean Dague wrote:

On 02/21/2016 01:41 PM, Jay Pipes wrote:

On 02/21/2016 12:50 PM, Chris Dent wrote:


In a recent api-wg meeting I set forth the idea that it is both a
bad idea to add lots of different headers and to add headers which
have meaning in the name of the header (rather than just the value).
This proved to a bit confusing, so I was asked to write it up. I
did:

  https://review.openstack.org/#/c/280381/

When I did, the best example for how _not_ to do things is the way in
which we are currently doing microversion headers.

So two questions:

* Is my position on header non proliferation right?


Yes, I believe so.


+1




* Is it so right that we should consider doing microversions
differently?


Ship has sailed on a number of things, including this. I *do* think it
would be great to just use OpenStack-API-Version: $SERVICE_TYPE X.Y,
however we'll need to add another microversion to support that of
course. Isn't it ironic? Don't you think?


i'm wondering if the ship hasn't sailed on this as well. i also think it 
might be a little thrashing for us to oscillate back and forth on these 
headers. otoh, they aren't *widely* implemented yet, still i'm not even 
sure we could put this genie back in the bottle.


i think it might be nice to discuss this one more time at the next meeting.



Actually, the headers can't be fully fixed in a microversion, because
they are deep in the negotiation. We're stuck maintaining the old
headers pretty much forever.


i not following the "deep in the negotation" part, would you mind 
expanding on this idea a little more?



regards,
mike

__
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] [docs] [api] Why WADL when you can Swagger

[michael mccune]

On 02/12/2016 04:45 PM, Anne Gentle wrote:


What's new?

This week, with every build of the api-site, we are now running
fairy-slipper to migrate from WADL to Swagger for API reference
information. Those migrated Swagger files are then copied to
developer.openstack.org/draft/swagger
.

We know that not all files migrate smoothly. We'd love to get teams
looking at these migrated files. Thank you to those of you already
submitting fixes!

In addition, the infra team is reviewing a spec now so that we can serve
API reference information from the developer.openstack.org
 site:
https://review.openstack.org/#/c/276484/



Anne, this is a great update!

love to see the progress on swagger integration.




Last but not least, if you want to learn more about Swagger in the
upstream contributors track at the Summit, vote for this session:
https://www.openstack.org/summit/austin-2016/vote-for-speakers/presentation/7723


sweet, +1

regards,
mike


__
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] RFC - service naming registry under API-WG

[michael mccune]

On 02/10/2016 03:03 PM, Sean Dague wrote:

On 02/04/2016 06:38 AM, Sean Dague wrote:

2) Have a registry of "common" names.

Upside, we can safely use common names everywhere and not fear collision
down the road.

Downside, yet another contention point.

A registry would clearly be under TC administration, though all the
heavy lifting might be handed over to the API working group. I still
imagine collision around some areas might be contentious.


We had a good discussion last week here on the list, and I think the
consensus was that:

1) We should use option #2 and have standard service types

2) The API Working Group was probably as good a place as any to own /
drive this.

I'd like to follow on with the following recommendations:

3) This be a dedicated repository 'openstack/service-registry'. The API
WG will have votes on it (I would also suggest the folks that have been
working on Service Catalog TNG - myself, Anne Gentle, Brant Knudson, and
Chris Dent be added to this). The actual registry will be some
structured file that supports comments (probably yaml).

4) We seed it with the 'well known' service types from current devstack.
Then we patch in services one at a time after that as requested.
Basically sift through all the non controversial stuff first. Let debate
happen on the more contentious ones later.

5) We'll build up guidelines in this repo about the kinds of service
types names which we think are good. We may dedicate some reserve words
that are too highly confusing in the OpenStack space to be used (policy
comes to mind).

If there are concerns with this approach let me know. Otherwise I'll
propose the repo tomorrow and try to keep this ball rolling.

-Sean



i think this sounds like a fine idea. +1

mike

__
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] [keystone] Usage of trusts with v2.0 authentication

[michael mccune]

On 02/09/2016 12:06 PM, Lance Bragstad wrote:

The keystone team is curious if there is anyone creating trusts using v3
and then using them against version 2.0. If not, we'd like to
remove/deprecate support for that case in v2.0. If so, then we'll have
to add official documentation for trusts against v2.0 and incorporate
that case into fernet.


i'm curious if this will affect the usage of trusts through the python 
keystoneclient?


the sahara projects creates several trusts through the python client, 
and this seems to work regardless of the version endpoint we use. we 
aren't specifically using these trusts against a v2 endpoint, but we do 
use whatever endpoint is provided in our configuration for the identity 
endpoint.


thanks for bringing this up.

regards,
mike


__
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] the trouble with names

[michael mccune]

On 02/05/2016 04:36 PM, Chris Dent wrote:

On Fri, 5 Feb 2016, Sean Dague wrote:

I'd ask for folks to try to stay on the original question:

What possible naming standards could we adopt, and what are the
preferences.


1. service type as described in option 2
2. managed by the api-wg with appeal to the TC
3. be limited to those services that (wish to/need to/should) be present
in the service catalog

As discussed elsewhere 3 is a feature not a bug. We should endeavor
to keep the service catalog clean, tidy, and limited as a control on
OpenStack itself is clean, tidy and limited.


i think this sounds very reasonable

regards,
mike


__
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] [api] microversion spec

[michael mccune]

On 02/03/2016 10:23 AM, Morgan Fainberg wrote:



On Wed, Feb 3, 2016 at 3:49 AM, Sean Dague > wrote:

I've been looking through the reviews on and where it's gotten to -

https://review.openstack.org/#/c/243429/4/guidelines/microversion_specification.rst


A couple of questions / concerns.

There was major push back from API-WG on 'API' itself being in the
headers. What is the data on what services are already doing? My
understanding is this is convention for all every service so far, mostly
because that's how we did it in Nova. Forcing a header change for that
seems massively bike shed. There is zero value gained in such a change
by anyone, and just confusion.



i don't see a conflict with the guideline proposing removing API from 
the header. if nova moves to support both headers in the future that 
would be awesome, but not strictly necessary.


i think what we wanted was to make sure that new projects will be on the 
same page about this. (although, i can understand that they will cry 
"but nova doesn't do that")



On moving from code names to service types, I'm completely onboard with
that providing value. However there is a bigger issue about the fact
that service types don't really have a central registry. That's why Nova
didn't do this up front because that's a whole other thing to figure out
which has some really big implications on our community.

Code names are self namespaced because they are based on git repo -
openstack/nova, openstack/ironic. We get a registry for free that won't
have conflicts.

I actually agree these should be service types, however, that requires
understanding how service types are going to be handed out. Having a
project just start using 'monitoring' or 'policy' as a service type is
going to go poorly in the long term when they get told they have to
change that, and now all their clients are broken.


As part of the new catalog (x-project) spec we will also need the
central registry for deconflicting. If you're talking to "compute" via
the catalog, it needs to always be nova. I would like to see this be the
service types. For the projects that have used the code-names for now
they can support either/or favouring the new service type one in the
long term.

Since we already need to solve this one way, we should use the same data
that is going to be in the catalog for this header.


agreed about the need for a registry, or something, to help coordinate 
the service type names. as stated in the other thread about naming[1], 
i'm ok with starting to work on some sort of plan for the api-wg to 
assist in the registration efforts, but that will take some time.


in the short term, i think we should forge ahead with standardizing on 
service type, and when the registry, or w/e, exists we can start to 
bring things into congruence with each other.


regards,
mike

[1]: 
http://lists.openstack.org/pipermail/openstack-dev/2016-February/085748.html



__
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] the trouble with names

[michael mccune]

On 02/04/2016 12:57 PM, Hayes, Graham wrote:

On 04/02/2016 15:40, Ryan Brown wrote:

On 02/04/2016 09:32 AM, michael mccune wrote:

On 02/04/2016 08:33 AM, Thierry Carrez wrote:

Hayes, Graham wrote:

On 04/02/2016 13:24, Doug Hellmann wrote:

Excerpts from Hayes, Graham's message of 2016-02-04 12:54:56 +:

On 04/02/2016 11:40, Sean Dague wrote:

2) Have a registry of "common" names.

Upside, we can safely use common names everywhere and not fear
collision down the road.

Downside, yet another contention point.

A registry would clearly be under TC administration, though all the
heavy lifting might be handed over to the API working group. I still
imagine collision around some areas might be contentious.


++ to a central registry. It could easily be added to the
projects.yaml
file, and is a single source of truth.


Although I realized that the projects.yaml file only includes official
projects right now, which would mean new projects wouldn't have a place
to register terms. Maybe that's a feature?


That is a good point - should we be registering terms for non tent
projects? Or do projects get terms when they get accepted into the tent?


I don't see why we would register terms for non-official projects. I
don't see under what authority we would do that, or where it would end.
So yes, that's a feature.



i have a question about this, as new, non-official, projects start to
spin up there will be questions about the naming conventions they will
use within the project as to headers and the like. given that the
current guidance trend in the api-wg is towards using "service type" in
these cases, how would these projects proceed?

(i'm not suggesting these projects should be registered, just curious)


This isn't a perfect solution, but maybe instead of projects.yml there
could be a `registry.yml` project that would (of course) have all the
project.yml "in-tent" projects, but also merge in external project
requests for namespaces?


Where ever it is stored, could this be a solid place for the api-wg to
codify the string that should be shown in the catalog / headers /
other places by services?



this seems like a reasonable approach, the big downside might be 
grooming the "dibs" list. we could have projects that expect to go 
somewhere, register their name, then never achieve "lift-off". in these 
cases we would need to release those names back into the free pool.



Say there's an LDAP aaS project, it could ask to reserve "directory" or
whatever and have a reasonable hope that when they're tented they'll be
able to use it. This would help avoid having multiple projects expecting
to use the same name, while also not meaning we force anyone to use or
not use some name.

Effectively, it's a gerrit-backed version of "dibs".


I think solution 2 is the best. To avoid too much contention, that can
easily be delegated to the API WG, and escalated to the TC for
resolution only in case of conflict between projects (or between a
project and the API WG).



i'm +1 for solution 2 as well. as to the api-wg participation in the
name registration side of things , i don't have an objection but i am
very curious to hear Everett's and Chris' opinions.

regards,
mike

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





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




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

Re: [openstack-dev] [all] the trouble with names

[michael mccune]

On 02/05/2016 07:56 AM, Chris Dent wrote:

On Thu, 4 Feb 2016, Sean Dague wrote:


2) Have a registry of "common" names.

Upside, we can safely use common names everywhere and not fear collision
down the road.


This is the only option presented thus far which meets the needs of
end users and also some of our stated goals about creating
interoperable OpenStack-based clouds.

It does, however, require some integration and orchestration between
TC, Service Catalog work, and API-WG guidelines.


Downside, yet another contention point.


What's the issue with contention? Contention is one of several tools
that humans use to resolve disagreement and reached a shared
understanding of the problem space. Without shared understanding
in a community there's zero chance a community will create and work
towards shared goals. Because even if everyone is using the same
words for the goals, if they aren't using the same meanings, it's
all bunk.

When we, as a group, start to contend over terms and identifiers
that's just a signal that we don't really know what we're trying to
do and need to work at it. A lot of people, frustrated with all this
talk, will call it bikeshedding and then go off and do their own
thing, potentially not in concert with other people's goals. Making
all that talk is sometimes necessary if we want to be headed in the
same direction[1].

The economics of our situation often make that kind of cross-project
noodling challenging. As a group of open source devs we likely need
to keep our patrons clearly aware of the value and amount of what
some would call overhead.

It is not overhead. It's a major part of the work.

The big tent, in some sense, has been an invitation to allow people
to work on a more diverse set of goals. At the edge this is
beneficial as it means more useful stuff, but it has diffused
understanding of what "OpenStack" is. For consumers of OpenStack (and
for devs who are primarily concerned with making a thing called
OpenStack that is useful for those consumers) there needs to be a
thing which is OpenStack and that thing needs to be consistent and
coherent. And limited[2].



well said


A tool we have at our disposal for creating that consistency is the
service catalog and specifically the service catalog types.

Some will argue that this will lead to people contending over who
should occupy a type, as if that were a bad thing. It is not. Having
that discussion will help identify the flaws in the proposed
occupiers and keep the discussion of "what are we" alive and
healthy[3].


A registry would clearly be under TC administration, though all the
heavy lifting might be handed over to the API working group. I still
imagine collision around some areas might be contentious.


I'm happy for the API-wg to handle some of this if mike and Everett
are as well. Making it work well will require everybody plays well
with the service catalog too[4]



i'm open to this, assuming we create a well defined process to keeping 
the names in order.



The biggest challenge I predict is when we need to change things, as
we inevitably will. Many currently hold dear that we cannot impose
change upon the existing user base. Sometimes you do and really it's
not that much of a big deal compared to the pain of running
OpenStack in the first place.

[1] It's perfectly okay for tools to not head in the same
direction, especially if they can be consumed as independent
libraries or services and are not embedded in the world of
OpenStack. This is a good thing. There's far too much stuff _in_
OpenStack that should just be _used by_ OpenStack (or used by
OpenStack users).

[2] Yes, this means we need to have an opinion about what OpenStack
is and build that opinion into the system. That's good. OpenStack is
insufficiently generic to be unopinionated. Let's just get over
that.

[3] At the moment it appears that much of the time the goal of
OpenStack is to keep the gate running. This is classic statism at
its worst. Straight out of the movie Brazil.

[4]
http://specs.openstack.org/openstack/openstack-specs/specs/service-catalog.html




__
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] the trouble with names

[michael mccune]

On 02/04/2016 08:33 AM, Thierry Carrez wrote:

Hayes, Graham wrote:

On 04/02/2016 13:24, Doug Hellmann wrote:

Excerpts from Hayes, Graham's message of 2016-02-04 12:54:56 +:

On 04/02/2016 11:40, Sean Dague wrote:

2) Have a registry of "common" names.

Upside, we can safely use common names everywhere and not fear
collision down the road.

Downside, yet another contention point.

A registry would clearly be under TC administration, though all the
heavy lifting might be handed over to the API working group. I still
imagine collision around some areas might be contentious.


++ to a central registry. It could easily be added to the projects.yaml
file, and is a single source of truth.


Although I realized that the projects.yaml file only includes official
projects right now, which would mean new projects wouldn't have a place
to register terms. Maybe that's a feature?


That is a good point - should we be registering terms for non tent
projects? Or do projects get terms when they get accepted into the tent?


I don't see why we would register terms for non-official projects. I
don't see under what authority we would do that, or where it would end.
So yes, that's a feature.



i have a question about this, as new, non-official, projects start to 
spin up there will be questions about the naming conventions they will 
use within the project as to headers and the like. given that the 
current guidance trend in the api-wg is towards using "service type" in 
these cases, how would these projects proceed?


(i'm not suggesting these projects should be registered, just curious)


I think solution 2 is the best. To avoid too much contention, that can
easily be delegated to the API WG, and escalated to the TC for
resolution only in case of conflict between projects (or between a
project and the API WG).



i'm +1 for solution 2 as well. as to the api-wg participation in the 
name registration side of things , i don't have an objection but i am 
very curious to hear Everett's and Chris' opinions.


regards,
mike

__
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] New API Guidelines Ready for Cross Project Review

[michael mccune]

hi all,

The following API guideline is ready for cross project review. It will 
be merged on Feb. 9 if there is no further feedback.


1. Must not return server-side tracebacks
https://review.openstack.org/#/c/183599

regards,
mike

__
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] [api] service type vs. project name for use in headers

[michael mccune]

On 01/28/2016 06:32 AM, Jay Pipes wrote:

Couldn't agree more, Chris.

-jay

On 01/28/2016 11:06 AM, Chris Dent wrote:

On Wed, 27 Jan 2016, Dean Troyer wrote:


I think we would be better served in selecting these things thinking
about
the API consumers first.  We already have  enough for them to wade
through,
the API-WG is making great gains in herding those particular cats, I
would
hate to see giving back some of that here.


I think it is high time we resolve the question of whether the
api-wg guidelines are evaluating existing behaviors in OpenStack and
blessing the best or providing aspirational guidelines of practices
which are considered best at a more universal level.

Within the group many of our debates pivot around the above issue.
There is some fear that if we choose the latter none of the
guidelines will be followed.

I think that's pretty weak sauce and we need to take both a more
assertive and more aggressive stance with regard to achieving
quality and consistency in the APIs[1]. Reaching consistency is the
primary mission of the group but consistent crap is still crap and
our API consumers deserve better.

The thread about Ekko which has spawned a subthread about the
collision between the ceilometer and monasca APIs should be a
good learning moment™: Having some rigor and vision in our
guidelines would allow us to state things like:

* The APIs are services (for which there could potentially be other
   implementations but the service represents a namespace)
* Identifiers used in that service are service related, not project
   related.
* More specifically: URIs are signifiers of a service, not a project.

The guidelines should be one (of several) ways in which a project
can ask itself "are we being OpenStack?". If there is a collision
with the guidelines, that provides a clue that the thing being
considered is out of alignment. It should be an excuse to change or
create new guidelines.


In this case, the use of service type as the primary identifier for
endpoints and API services is well established, and is how the service
catalog has and will always work.


For the specific issue of the headers, I think the above is the crux of
the biscuit. The service catalog is intended to be a source of truth;
that truth should be reflected in the guidelines. If the API being
considered isn't (planned to be) in the service catalog does that
API need to even be thinking about adhering to OpenStack guidelines?

[1] Choosing to be more rigorous in the guidelines puts a large
burden on the group to not simply rubberstamp incoming guidelines
and also be more selective about what actually matters in terms of
the guidelines. This is challenging because it became clear early on
that adherence to correct HTTP in existing APIs was weak and there
was an opportunity for the group to be a fount of knowledge and
wisdom and distill best practices.

That work still needs to go on, but it is also time to align
the work with some of the main themes in today's OpenStack:

* alignment with the service catalog and what it is trying to
   accomplish
* effective use of APIs when re-using real users' client code amongst a
   diversity of clouds

Just those two things can help us evaluate proposals with some
useful constraints.


i agree as well Chris, and well said.

thanks to everyone for commenting on this issue. i agree with the 
sentiments that are being voiced here, and i think the arguments for 
sticking to service type make a good deal of sense.


my main concern was that there had been some pushback on the idea of 
service type for headers. i like the notion that we are hewing closer to 
the service catalog ideals, that makes good sense to me. i just wanted 
to leave room for projects to make their own path if necessary, i guess 
this option is always there by default.


again, thanks for the insights. i will back off my concerns on the 
outstanding reviews based on this issue, and work towards helping us 
stay closer to service type for the guidelines.


regards,
mike


__
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] [api] service type vs. project name for use in headers

[michael mccune]

hi all,

there have been a few reviews recently where the issue of service type 
versus project name have come up for use in the headers. as usual this 
conversation can get quite murky as there are several good examples 
where service type alone is not sufficient (for example if a service 
exposes several api controllers), and as has been pointed out project 
name can also be problematic (for example projects can change name).


i'm curious if we could come to a consensus regarding the use of service 
type *or* project name for headers. i propose leaving the ultimate 
decision up to the projects involved to choose the most appropriate 
identifier for their custom headers.


i am not convinced that we would ever need to have a standard on how 
these names are chosen for the header values, or if we would even need 
to have header names that could be deduced. for me, it would be much 
better for the projects use an identifier that makes sense to them, 
*and* for each project to have good api documentation.


so, instead of using examples where we have header names like 
"OpenStack-Some-[SERVICE_TYPE]-Header", maybe we should suggest 
"OpenStack-Some-[SERVICE_TYPE or PROJECT_NAME]-Header" as our guideline.


for reference, here are the current reviews that are circling around 
this issue:


https://review.openstack.org/#/c/243429
https://review.openstack.org/#/c/273158
https://review.openstack.org/#/c/243414

and one that has already been merged:

https://review.openstack.org/#/c/196918

thoughts?

regards,
mike

__
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] [api] api working group proposed actions guideline needs input

[michael mccune]

On 01/18/2016 10:05 AM, Michael Krotscheck wrote:

Also: I like using the same word for things. Is there a meaningful
enough difference between "Actions", "Transitions", and "Tasks", that
requires different words?


not that i have detected, although i would love hear other opinions on this.

i have to admit that this is the first time i'm hearing "transitions", 
and i feel it could be looked at separately from "actions" or "tasks". 
but i think this is largely a semantic debate.


i do think it would be useful to coalesce on a standard term for what we 
are talking about.


regards,
mike


__
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] New API Guidelines Ready for Cross Project Review

[michael mccune]

hi all,

The following API guideline is ready for cross project review. It will 
be merged on Jan. 21 if there is no further feedback.


1. Add description of pagination parameters
https://review.openstack.org/#/c/190743

regards,
mike

__
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] [api][all] api variation release by release

[michael mccune]

On 01/12/2016 09:55 PM, Matt Riedemann wrote:

Nova and Ironic already support microversioned APIs. Cinder and Neutron
are working on it I think, and there could be others.


just as a heads up, sahara is also working towards implementing 
microversions in its next api[1]


regards,
mike

[1]: https://review.openstack.org/#/c/212172/


__
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] [trove][neutron][cinder][swift][ceilometer][nova][keystone][sahara][glance][neutron-lbaas][imm] stylistic changes to code, how do we handle them?

[michael mccune]

On 01/12/2016 08:51 AM, Amrith Kumar wrote:

My question to the ML is this, should stylistic changes of this kind be handled 
in a consistent way across all projects, maybe with a hacking rule and some 
discussion on the ML first? After all, if this change is worthwhile, it is 
worth ensuring that this construct that we are seeking to eliminate, does not 
reenter the code base.


in general, i would prefer to leave these stylistic choices up to 
individual projects. the specific change that is being proposed may make 
sense for some projects but not for others.


i like the idea of a "hacking rule" or some sort of coding style guides, 
but i'm sceptical about creating some sort of openstack coding guide. 
i'm happy with us continuing to use pep8 and the individual projects' 
guidance as the bar.



For what it is worth, I agree with Vitaly Grindev [sahara, in review 
https://review.openstack.org/#/c/266230/1]. I think the code before the change 
was more intuitive and readable.


+1

regards,
mike

__
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] [trove] [sahara] Adding support for HBase in Trove

[michael mccune]

On 01/08/2016 08:34 AM, Amrith Kumar wrote:

As Kevin suggests, I'm adding [sahara] to the subject line.

Others in sahara who now see this thread, apologies for sending you a delayed 
invitation to the party. There's still lots of food and beer so come on in!


Amrith,

thanks for reposting this, some of our team was on holiday during the 
last week (jan 3-8).


regards,
mike


__
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] [doc] [api] Vision and changes for OpenStack API Guides

[michael mccune]

On 01/08/2016 04:39 PM, Anne Gentle wrote:

Join me next week at the first pop-up Cross Project meeting, Tuesday at
1700, in #openstack-meeting-cp. Feel free to add to the agenda at


i'll definitely be there Anne, i'm very curious about this topic but 
sadly have not had the extra cycles to commit to it.


regards,
mike


__
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] making project_id optional in API URLs

[michael mccune]

On 12/08/2015 05:59 PM, Adam Young wrote:

I think it is kindof irrelevant.  It can be there or not be there in the
URL itself, so long as it does not show up in the service catalog. From
an policy standpoint, having the project in the URL means that you can
do an access control check without fetching the object from the
database; you should, however, confirm that the object return belongs to
the project at a later point.


from the policy standpoint does it matter if the project id appears in 
the url or in the headers?


mike


__
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] making project_id optional in API URLs

[michael mccune]

On 12/03/2015 12:06 PM, Sean Dague wrote:

So, for Cinder, Glance, Ironic, Manila, Magnum (and others I might have
missed) where are you standing on this one? And are there volunteers in
those projects to help move this forward?


i'm +1 for removing the project_id from the url.

sahara uses it in the url for the v1 and v1.1 apis, but we are planning 
to remove it for the v2 api[1].


mike

[1]: https://review.openstack.org/#/c/212172/


__
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] [cross-project] Cross-project Liaisons

[michael mccune]

On 11/30/2015 08:30 PM, Mike Perez wrote:

Hello all,

Currently for cross-project specs, the author of the spec spends the time to
explain why a certain feature makes sense to be across multiple projects. This
also includes giving technical solutions for it working with a variety of
services and making sure everyone is happy.

Today we have the following problems:

* Authors of specs can't progress forward with specs because of lack of
   attention. Eventually getting frustrated and giving up.
* Some projects could miss a cross-project spec being approved by the TC.

It has been expressed to me at the previous Cross-Project Communication Tokyo
summit session that PTLs don't have time for cross-project issues. I agree, as
being a previous PTL your time is thin. However, I do think someone from each
project needs to be aware and involved with cross-project initiatives.

I would like to propose cross-project liaisons which would have the following
duties:

* Watching the cross-project spec repo [1].
   - Comment on specs that involve your project. +1 to carry forward for TC
 approval.
 -- If you're not able to provide technical guidance on certain specs for
your project, it's up to you to get the right people involved.
 -- Assuming you get someone else involved, it's up to you to make sure they
keep up with communication.
   - Communicate back to your project's meeting on certain cross-project specs
 when necessary. This is also good for the previous bullet point of sourcing
 who would have technical knowledge for certain specs.
* Attend the cross-project meeting when it's called for [2].


[1] - 
https://review.openstack.org/#/q/project:+openstack/openstack-specs+status:+open,n,z
[2] - https://wiki.openstack.org/wiki/Meetings/CrossProjectMeeting



this sounds like a nice idea. it will still be an added layer of work to 
get visibility/approval for cross-project specs, but defining the 
process a little more thoroughly might help with the visibility issues.


it does seems like there might be an ever-expanding list of project 
liaisons to work with as the openstack community grows, do you envision 
any mechanisms outside the usual channels of communication to aid this 
effort?


regards,
mike

__
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] [api] consolidate IRC change with #openstack-sdk?

[michael mccune]

On 11/30/2015 08:45 AM, Sean Dague wrote:

Ok, I'm going to assume with no real disagreement we're agreed here. I'm
moving the api-wg notifications to #openstack-sdks now -
https://review.openstack.org/#/c/251357/1/gerritbot/channels.yaml,cm


ok, i think we've got a few spots in the documentation that refer to 
openstack-api. we can start the process of adjusting all those to 
openstack-sdks.


mike


__
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] [api] link definitions guideline to help align differing styles

[michael mccune]

hello all,

there has recently been some activity in the guidelines surrounding the 
use of links embedded in response objects. it appears that with the 
recently merged error guideline[1] and the currently frozen pagination 
guideline[2], that we are on the precipice of introducing a bifurcation 
with respect to link usage.


i think we should discuss the differences and create a guideline for 
link style, and then fixup whichever guideline(s) may be out of 
alignment with regards to our decision.


with that said, there appears to be two main implementations that we are 
looking at; the json hyper-schema link description objects[3] (hereafter 
referred to as the LDO approach), and the json hypertext application 
language link objects[4] (hereafter referred to the HAL approach).


on first inspection it would appear that the HAL approach provides more 
options for decorating the link with metadata. i'm not sure if this 
makes it a win in and of itself, but we should juxtapose that against 
the idea that we currently have several examples of the LDO style in use[5].


i'm curious to open this topic up for discussion to help forge a path 
forward.


thoughts?

regards,
mike

[1]: http://specs.openstack.org/openstack/api-wg/guidelines/errors.html
[2]: https://review.openstack.org/#/c/190743
[3]: http://json-schema.org/latest/json-schema-hypermedia.html#anchor17
[4]: https://tools.ietf.org/html/draft-kelly-json-hal-07#section-5
[5]: https://wiki.openstack.org/wiki/API_Working_Group/Current_Design/Links

__
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] [security][sahara] creating a threat analysis to aid operators

[michael mccune]

hello all,

during the security midcycle meetup we had a session about creating 
threat analysis for openstack projects. the folks at HPE were kind 
enough to offer their documentation and examples as an aid to creating 
these analysis.


after talking with the sahara team, i am confident that we can create an 
example threat analysis for our installers and operators to use as a 
reference in their deployments.


my goal in this is not to create a roadmap of current vulnerabilities 
within sahara, but to produce a working document that can be used as a 
guide for any users wishing to secure their sahara installations. i 
think there is value in creating these type of guides for all openstack 
projects, and i'm hopeful that the sahara team could take the lead in 
this process.


i'm reaching out in this email to help renew interest in the threat 
analysis work, and to possibly collate the material that is available 
and help define some spaces online where we might coordinate these efforts.


regards,
mike

__
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] [api] consolidate IRC change with #openstack-sdk?

[michael mccune]

On 11/16/2015 09:42 AM, Sean Dague wrote:

On 11/16/2015 09:34 AM, michael mccune wrote:

On 11/13/2015 07:58 AM, Sean Dague wrote:

The #openstack-api IRC channel is quite quiet most days. As such it's
not something that people are regularly checking in on, or often forget
about (I know I've been guilty of that). Plus we don't always have the
right people in a conversation to make a decision.

I'd like to propose we drop the channel entirely and make #openstack-sdk
the home of API working group conversations. That's where all the
openstackclient, openstackclientconfig, and sdk conversations are
happening. It's where the end consumers of any API WG effort are, so are
incredibly good sounding boards for things we are doing. There is
already a large overlap between the two channels, so just pushing
forward on that means more critical mass for conversations around the
whole space of a more usable API for users.

This came up at the last API WG meeting, but those are pretty low quorum
events, so this is a thing we should definitely decide over ML instead.

Please express your feelings here and lets make it happen. :)


i don't necessarily have an outright objection to this, but i would like
explore the future possibilities of this change.

i think there is possibility for the api-wg to grow and take on more
responsibility within the openstack community and i'm curious about the
net effect down the road if that expansion were to occur. are there any
side-effects we should be aware of as we merge the two
channels/communities into one namespace?

i realize there is some overlap of engineering/design that takes place
on these channels, i'm just concerned about the idea of merging the two
and then at some point in the future wanting to separate them. i'm not
proposing these thoughts to quash the idea of joining, i'd just like to
more fully understand the longer term implications of a merge.

anyone with more experience in this community-oriented side of things
have some light to shed?


Typically the only real reason to spin off another channel is that there
are now too many conversations happening all at once that are unrelated
and people are finding it is impeding their ability to get work done. I
can't imagine this happening any time within the next couple of years.
An average day in #openstack-api is < 20 messages (from a quick spot
check in IRC logs).

I feel there is a lot of benefits in having these groups that do related
work all doing it in one channel. Even though it's a number of discreet
outputs, the "hallway track" of having api producers and consumers doing
their business all in front of each other should quite help in ensuring
that we all make something better.


thanks for the clarifications Sean, i appreciate the extra resolution 
and i agree that having both these groups able to comment on similar 
issues in a common place seems ideal.


regards,
mike


__
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] [api] consolidate IRC change with #openstack-sdk?

[michael mccune]

On 11/13/2015 07:58 AM, Sean Dague wrote:

The #openstack-api IRC channel is quite quiet most days. As such it's
not something that people are regularly checking in on, or often forget
about (I know I've been guilty of that). Plus we don't always have the
right people in a conversation to make a decision.

I'd like to propose we drop the channel entirely and make #openstack-sdk
the home of API working group conversations. That's where all the
openstackclient, openstackclientconfig, and sdk conversations are
happening. It's where the end consumers of any API WG effort are, so are
incredibly good sounding boards for things we are doing. There is
already a large overlap between the two channels, so just pushing
forward on that means more critical mass for conversations around the
whole space of a more usable API for users.

This came up at the last API WG meeting, but those are pretty low quorum
events, so this is a thing we should definitely decide over ML instead.

Please express your feelings here and lets make it happen. :)


i don't necessarily have an outright objection to this, but i would like 
explore the future possibilities of this change.


i think there is possibility for the api-wg to grow and take on more 
responsibility within the openstack community and i'm curious about the 
net effect down the road if that expansion were to occur. are there any 
side-effects we should be aware of as we merge the two 
channels/communities into one namespace?


i realize there is some overlap of engineering/design that takes place 
on these channels, i'm just concerned about the idea of merging the two 
and then at some point in the future wanting to separate them. i'm not 
proposing these thoughts to quash the idea of joining, i'd just like to 
more fully understand the longer term implications of a merge.


anyone with more experience in this community-oriented side of things 
have some light to shed?


thanks,
mike


__
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][tc][perfromance] API for getting only status of resources

[michael mccune]

On 11/03/2015 05:20 PM, Boris Pavlovic wrote:

What if we add new API method that will just resturn resource status by
UUID? Or even just extend get request with the new argument that returns
only status?

Thoughts?


not sure i understand the resource status by UUID, could you explain 
that a little more.


as for changing the get request to return only the status, can't you 
have a filter on the get url that instructs it to return only the status?


mike

__
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] [security] The first version of the Logo for Openstack Security Project

[michael mccune]

On 10/21/2015 05:11 PM, Michael Xin wrote:

Rob and Michael:
Thanks for the update. We will probably not use any Openstack Logo.

Here is the first draft of the flyer:

http://5a6aa6580e900b8e8020-e5e45c5cb10329ebc9fb69948bb1b1a5.r65.cf1.rackcdn.com/ossp-flag-flyer.pdf


Please send us your feedback.


i think my only suggestion on the text would be to slightly alter the 
second sentence of the "What's the OSSP?" section.


currently it is:

"The Security Project undertakes both technical and governance 
activities within OpenStack, aiming to provide guidance, information and 
code that enhances the overall security of the OpenStack ecosystem"


i would change the beginning to:

"The Security Project undertakes both technical and governance 
activities for the OpenStack community, aiming to provide guidance, 
information and code that enhances the overall security of the OpenStack 
ecosystem"


but i think this is a pretty minor nit.

regards,
mike

__
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] [security] The first version of the Logo for Openstack Security Project

[michael mccune]

On 10/21/2015 03:54 AM, Michael Xin wrote:

Hi, guys:
Thanks for your help. We are designing a logo and a flyer for Openstack
Security Project. Rachel helped us with the task. Attached is her first
version of the logo. Please let us know your feedback.

http://5d100f09242e1d85fe65-9262bad2bd2ce9d805c21cb30838f376.r18.cf1.rackcdn.com/os-security-project-logo.png
Thanks and have a great day.


hi Michael, thanks to Rachel for putting this together. i like the 
general concept of the openstack logo as a lock. i think the "lock 
parts" could have a little more depth on them.


you had asked in irc about usage of the openstack logo, i'm not sure. 
but this page, https://www.openstack.org/brand/openstack-logo/ , seems 
to indicate that the usage is pretty limited. in specific, this section 
"You agree that you will not (i) alter or modify the OpenStack Logo as 
provided by the OpenStack Foundation; " seems to indicate that we may 
not be able to use the logo like this. we should probably ask someone 
from the foundation.


all in all though, a nice effort. many thanks =)

mike


__
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] [security] The first version of the Logo for Openstack Security Project

[michael mccune]

On 10/21/2015 05:11 PM, Michael Xin wrote:

Rob and Michael:
Thanks for the update. We will probably not use any Openstack Logo.

Here is the first draft of the flyer:

http://5a6aa6580e900b8e8020-e5e45c5cb10329ebc9fb69948bb1b1a5.r65.cf1.rackcdn.com/ossp-flag-flyer.pdf


Please send us your feedback.


+1, i like the look of this flyer. especially the flag logo thingie, 
nicely done!


mike


__
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] [sahara] Proposing Vitaly Gridnev to core reviewer team

[michael mccune]

congrats Vitaly!

On 10/15/2015 10:38 AM, Sergey Lukjanov wrote:

I think we have a quorum.

Vitaly, congrats!

On Tue, Oct 13, 2015 at 6:39 PM, Matthew Farrellee > wrote:

+1!

On 10/12/2015 07:19 AM, Sergey Lukjanov wrote:

Hi folks,

I'd like to propose Vitaly Gridnev as a member of the Sahara core
reviewer team.

Vitaly contributing to Sahara for a long time and doing a great
job on
reviewing and improving Sahara. Here are the statistics for reviews
[0][1][2] and commits [3].

Existing Sahara core reviewers, please vote +1/-1 for the
addition of
Vitaly to the core reviewer team.

Thanks.

[0]

https://review.openstack.org/#/q/reviewer:%22Vitaly+Gridnev+%253Cvgridnev%2540mirantis.com%253E%22,n,z
[1] http://stackalytics.com/report/contribution/sahara-group/180
[2] http://stackalytics.com/?metric=marks_id=vgridnev
[3]

https://review.openstack.org/#/q/status:merged+owner:%22Vitaly+Gridnev+%253Cvgridnev%2540mirantis.com%253E%22,n,z

--
Sincerely yours,
Sergey Lukjanov
Sahara Technical Lead
(OpenStack Data Processing)
Principal Software Engineer
Mirantis Inc.



__
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




--
Sincerely yours,
Sergey Lukjanov
Sahara Technical Lead
(OpenStack Data Processing)
Principal Software Engineer
Mirantis Inc.


__
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] [sahara] Proposing Vitaly Gridnev to core reviewer team

[michael mccune]

i'm +1 for this, Vitaly has been doing a great job contributing code and 
reviews to the project.


mike

On 10/12/2015 07:19 AM, Sergey Lukjanov wrote:

Hi folks,

I'd like to propose Vitaly Gridnev as a member of the Sahara core
reviewer team.

Vitaly contributing to Sahara for a long time and doing a great job on
reviewing and improving Sahara. Here are the statistics for reviews
[0][1][2] and commits [3].

Existing Sahara core reviewers, please vote +1/-1 for the addition of
Vitaly to the core reviewer team.

Thanks.

[0]
https://review.openstack.org/#/q/reviewer:%22Vitaly+Gridnev+%253Cvgridnev%2540mirantis.com%253E%22,n,z
[1] http://stackalytics.com/report/contribution/sahara-group/180
[2] http://stackalytics.com/?metric=marks_id=vgridnev
[3]
https://review.openstack.org/#/q/status:merged+owner:%22Vitaly+Gridnev+%253Cvgridnev%2540mirantis.com%253E%22,n,z

--
Sincerely yours,
Sergey Lukjanov
Sahara Technical Lead
(OpenStack Data Processing)
Principal Software Engineer
Mirantis Inc.


__
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] [Security] Weekly Meeting Agenda

[michael mccune]

On 09/23/2015 02:56 PM, Clark, Robert Graham wrote:

Hi All,

I won’t be available to run the weekly meeting tomorrow as I’m out
travelling, Michael McCune (elmiko) has volunteered to lead the meeting.

There’s IRC information on our wiki page :
https://wiki.openstack.org/wiki/Security

Agenda items (Please reply to add any more):

·PTL Shenanigans : https://review.openstack.org/#/c/224798/

·VMT Project Tracking : https://review.openstack.org/#/c/226869/

·Anchor (Ephemeral PKI)

·Bandit (Security Linter)

·Developer Guidance (Don’t do this)

·Security Documents (Do do this)

·Security Notes (Think about not doing this)

·Syntribos (API Fuzzing)

·Any Other Business

*//*

Have a good meeting all!

-Rob


thanks Rob


__
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] [Sahara] FFE request for improved secret storage

[michael mccune]

i am retracting this request, i think this feature would benefit from 
more time to test and review.


thanks for the consideration,
mike

On 09/09/2015 12:09 PM, michael mccune wrote:

hi all,

i am requesting an FFE for the improved secret storage feature.

this change will allow operators to utilize the key manager service for
offloading the passwords stored by sahara. this change does not
implement mandatory usage of barbican, and defaults to a backward
compatible behavior that requires no change to a stack.

there is currently 1 review up which addresses the main thrust of this
change, there will be 1 additional review which will include more
passwords being migrated to use the mechanisms for offloading.

i expect this work to be complete by sept. 25.

review
https://review.openstack.org/#/c/220680/

blueprint
https://blueprints.launchpad.net/sahara/+spec/improved-secret-storage

spec
http://specs.openstack.org/openstack/sahara-specs/specs/liberty/improved-secret-storage.html


thanks,
mike

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



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

[openstack-dev] [sahara] hadoop-openstack.jar and proxy users

[michael mccune]

hey all,

in doing some work recently with proxy users and hadoop deployments, i 
am noticing that the modified version of the hadoop-openstack.jar we 
package from the sahara-extras repo is not being used in our current images.


this jar file adds support for keystone v3 to the swift interface in 
hadoop. v3 support is needed for proxy users and i'm guessing we are 
going to want this included by default in the future.


what is the current process for bundling this jar file and which images 
should it be included on?


i know that the vanilla 2.7.1 image does not contain this jar, i am 
curious if we should re-address which hadoop/swift connector jar is 
being included.


thoughts?


regards,
mike

__
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] [sahara] mitaka summit session ideas

[michael mccune]

hey all,

i started an etherpad for us to collect ideas about our session for the 
mitaka summit.


https://etherpad.openstack.org/p/mitaka-sahara-session-plans

please drop any thoughts or suggestions about the summit there.

thanks,
mike

__
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] [Barbican] Nominating Dave Mccowan for Barbican core

[michael mccune]

i'm not a core, but +1 from me. Dave has made solid contributions and 
would be a great addition to the core team.


mike

On 09/08/2015 12:05 PM, Juan Antonio Osorio wrote:

I'd like to nominate Dave Mccowan for the Barbican core review team.

He has been an active contributor both in doing relevant code pieces and
making useful and thorough reviews; And so I think he would make a great
addition to the team.

Please bring the +1's :D

Cheers!

--
Juan Antonio Osorio R.
e-mail: jaosor...@gmail.com 



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




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

[openstack-dev] [Sahara] FFE request for improved secret storage

[michael mccune]

hi all,

i am requesting an FFE for the improved secret storage feature.

this change will allow operators to utilize the key manager service for 
offloading the passwords stored by sahara. this change does not 
implement mandatory usage of barbican, and defaults to a backward 
compatible behavior that requires no change to a stack.


there is currently 1 review up which addresses the main thrust of this 
change, there will be 1 additional review which will include more 
passwords being migrated to use the mechanisms for offloading.


i expect this work to be complete by sept. 25.

review
https://review.openstack.org/#/c/220680/

blueprint
https://blueprints.launchpad.net/sahara/+spec/improved-secret-storage

spec
http://specs.openstack.org/openstack/sahara-specs/specs/liberty/improved-secret-storage.html

thanks,
mike

__
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] [sahara] FFE request for nfs-as-a-data-source

[michael mccune]

i'm +1 for this feature as long as we talking about just the sahara 
controller and saharaclient. i agree we probably cannot get the horizon 
changes in before the final release.


mike

On 09/09/2015 03:33 AM, Chen, Weiting wrote:

Hi, all.

I would like to request FFE for nfs as a data source for sahara.

This bp originally should include a dashboard change to create nfs as a
data source.

I will register it as another bp and implement it in next version.

However, these patches have already done to put nfs-driver into
sahara-image-elements and enable it in the cluster.

By using this way, the user can use nfs protocol via command line in
Liberty release.

Blueprint:

https://blueprints.launchpad.net/sahara/+spec/nfs-as-a-data-source

Spec:

https://review.openstack.org/#/c/210839/

Patch:

https://review.openstack.org/#/c/218637/

https://review.openstack.org/#/c/218638/



__
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] Getting Started : OpenStack

[michael mccune]

On 09/08/2015 02:05 PM, Bhagyashree Uday wrote:

Hi Victoria ,

Thanks for the prompt reply. I go by Bee(IRC nick : bee2502) .There
doesn't seem to be much information regarding this project even on the
Ceilometer project page :( I will wait till the next Outreachy
applications begin though to check out any new developments. Thanks for
suggesting the IRC channel :) Btw, do you happen to know any other open
data analysis projects in OpenStack ?

Bee


hi Bee,

you may also be interested in the sahara project, the data processing 
service for openstack[1].


i am a developer with the project, and although we don't deal 
specifically in the analysis of data, we are addressing the issues of 
deploying popular data processing frameworks(Hadoop, Spark, Storm) into 
openstack.


if this sounds interesting, please stop by our channel, 
#openstack-sahara and chat us up. we are always looking for more people 
interested in contributing =)


regards,
mike

(elmiko on irc)

[1]: http://docs.openstack.org/developer/sahara/


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

Re: [openstack-dev] [Openstack] [Horizon] [Sahara] FFE request for Sahara unified job interface map UI

[michael mccune]

On 09/04/2015 10:40 AM, Ethan Gafford wrote:

Hello all,

I request a FFE for the change at: https://review.openstack.org/#/c/209683/

This change enables a significant improvement to UX in Sahara's elastic data 
processing flow which is already in the server and client layers of Sahara. 
Because it specifically aims at improving ease of use and comprehensibility, 
Horizon integration is critical to the success of the feature. The change 
itself is reasonably modular and thus low-risk; it will have no impact outside 
Sahara's job template creation and launch flow, and (failing unforseen issues) 
no impact to users of the existing flow who choose not to use this feature.

Thank you,
Ethan


+1 from me, this feature has received much attention and seems pretty 
low-risk of introducing critical errors.


mike


__
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] [sahara] FFE request for heat wait condition support

[michael mccune]

makes sense to me, +1

mike

On 09/04/2015 06:37 AM, Vitaly Gridnev wrote:

+1 for FFE, because of
  1. Low risk of issues, fully covered with current scenario tests;
  2. Implementation already on review

On Fri, Sep 4, 2015 at 12:54 PM, Sergey Reshetnyak
> wrote:

Hi,

I would like to request FFE for wait condition support for Heat engine.
Wait condition reports signal about booting instance.

Blueprint:
https://blueprints.launchpad.net/sahara/+spec/sahara-heat-wait-conditions

Spec:

https://github.com/openstack/sahara-specs/blob/master/specs/liberty/sahara-heat-wait-conditions.rst

Patch:
https://review.openstack.org/#/c/169338/

Thanks,
Sergey Reshetnyak

__
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




--
Best Regards,
Vitaly Gridnev
Mirantis, Inc


__
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] [sahara] Request for Feature Freeze Exception

[michael mccune]

On 09/03/2015 02:49 PM, Vitaly Gridnev wrote:

Hey folks!

I would like to propose to add to list of FFE's following blueprint:
https://blueprints.launchpad.net/sahara/+spec/drop-hadoop-1

Reasoning of that is following:

  1. HDP 1.3.2 and Vanilla 1.2.1 are not gated for a whole release
cycle, so it can be reason of several bugs in these versions;
  2. Minimal risk of removal: it doesn't touch versions that we already
have.
  3. All required changes was already uploaded to the review:
https://review.openstack.org/#/q/status:open+project:openstack/sahara+branch:master+topic:bp/drop-hadoop-1,n,z


this sounds reasonable to me

mike


__
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] [api] [wsme] [ceilometer] Replacing WSME with _____ ?

[michael mccune]

On 08/28/2015 10:36 AM, Lucas Alvares Gomes wrote:

So at the present moment the [micro]framework that comes to my mind -
without any testing or prototype of any sort - is Flask.


just wanted to add on here, sahara is using flask.

mike


__
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] [sahara] Bug triage/fix and doc update days in Liberty

[michael mccune]

hey Saharans,

with Doc fix day fast approaching i wanted to send out an email with the 
etherpad again,


https://etherpad.openstack.org/p/sahara-liberty-doc-update-day

it has been updated with all the docs and we are ready to roll starting 
on monday aug 31.


mike

On 08/24/2015 09:41 AM, Ethan Gafford wrote:

Hello all,

Bugfix days for Liberty's Sahara release have begun! Please sign up for bug 
fixes at:
https://etherpad.openstack.org/p/sahara-liberty-bug-fix-day

Cheers,
Ethan Gafford
Senior Software Engineer
OpenStack Sahara
Red Hat, Inc.

- Original Message -
From: Sergey Lukjanov slukja...@mirantis.com
To: OpenStack Development Mailing List openstack-dev@lists.openstack.org
Sent: Thursday, August 13, 2015 11:12:33 AM
Subject: [openstack-dev] [sahara] Bug triage/fix and doc update days in Liberty

Hi folks,

on todays IRC meeting [0] we've agreed to have:

1) Bug triage day on Aug 17
We're looking for the volunteer to coordinate it ;) If someone wants to do it, 
please, reply to this email.
http://etherpad.openstack.org/p/sahara-liberty-bug-triage-day


2) Bug fix day on Aug 24
Ethan (egafford) volunteered to coordinate it.
http://etherpad.openstack.org/p/sahara-liberty-bug-fix-day


3) Doc update day on Aug 31
Mike (elmiko) volunteered to coordinate it.
http://etherpad.openstack.org/p/sahara-liberty-doc-update-day


Coordinators, please, add some initial notes to the ether pads and ensure that 
folks will be using them to sync efforts. For communication let's use 
#openstack-sahara IRC channel as always.

Thanks.

[0] 
http://eavesdrop.openstack.org/meetings/sahara/2015/sahara.2015-08-13-14.00.html




__
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] [api] [docs] Generating API samples

[michael mccune]

On 08/24/2015 11:51 AM, Anne Gentle wrote:

Hi all,

I'm writing to find out how teams keep API sample requests and responses
up-to-date. I know the nova team has a sample generator [1] that they've
maintained for a few years now. Do other teams have something similar?
If so, is your approach like the nova one?


sahara keeps examples for some of it's calls in our repo, although they 
are not a full example of all calls. these have all been hand-crafted, 
and could use some updating to add examples for the missing calls.


we are currently evaluating a new major version for our api[1], and are 
talking about creating an api directory in our specs repo to have more 
up-to-date samples, and a descriptive explanation, of our api. i'm 
guessing that initially these examples will be hand-crafted.



regards,
mike

[1]: https://review.openstack.org/#/c/212172/

__
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] New API Guidelines ready for cross project review

[michael mccune]

On 08/11/2015 10:28 AM, michael mccune wrote:

1. Add new guideline for HTTP Headers
https://review.openstack.org/#/c/186526/

2. Add advice on when to use POST or PUT in create
https://review.openstack.org/#/c/181912/

3. Clarify the return code when server have hard-code length limit
https://review.openstack.org/#/c/181784/

if the API Working Group hasn't received any further feedback, we'll
merge them on August 18.


these are slated for merge today, but each has a few comments 
surrounding minor nit-type improvements. should we merge these as is and 
create fix patches, or can we add the changes and merge?


i realize that according to our process[1], these are technically good 
to merge as there is not enough -1 consensus to stop them. i just wanted 
to ask the group before pushing ahead.


mike

[1]: http://specs.openstack.org/openstack/api-wg/process.html

__
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] New API Guidelines ready for cross project review

[michael mccune]

On 08/11/2015 10:28 AM, michael mccune wrote:

1. Add new guideline for HTTP Headers
https://review.openstack.org/#/c/186526/

2. Add advice on when to use POST or PUT in create
https://review.openstack.org/#/c/181912/

3. Clarify the return code when server have hard-code length limit
https://review.openstack.org/#/c/181784/


these guidelines have been merged as per the freeze process guidelines.

guidelines #1 and #2, generated comments that should be addressed in 
follow-up patches.


thanks,
mike


__
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