from:"Everett Toews"

[jira] [Commented] (JCLOUDS-114) Support OpenStack Keystone v3 API

2017-07-03 Thread Everett Toews (JIRA)


[ 
https://issues.apache.org/jira/browse/JCLOUDS-114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16072604#comment-16072604
 ] 

Everett Toews commented on JCLOUDS-114:
---

Apologies but I won't be able to help out here. 

> Support OpenStack Keystone v3 API
> -
>
> Key: JCLOUDS-114
> URL: https://issues.apache.org/jira/browse/JCLOUDS-114
> Project: jclouds
>  Issue Type: New Feature
>  Components: jclouds-blobstore, jclouds-compute, 
> jclouds-labs-openstack
>Affects Versions: 1.7.0
>Reporter: Jeremy Daggett
>Priority: Critical
>  Labels: oak, openstack-keystone
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

2017-03-09 Thread Everett Toews

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

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

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

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

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

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

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

Cheers,
Everett

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

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

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

2017-02-07 Thread Everett Toews

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

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

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

+1000

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

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

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

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

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

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

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

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

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

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

Regards,
Everett

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

Re: [openstack-dev] [ironic] [API] Evolving our REST API

2016-10-21 Thread Everett Toews

On Oct 13, 2016, at 10:00 AM, Devananda van der Veen  
wrote:
> 
> So I have finalized five proposals of substantial changes we can make, that
> folks agreed were important to work on, and which I believe we can do within 
> the
> microversion framework starting immediately. Four of them will, I think, be
> fairly straight forward. The fifth, adding a /tasks/ resource, has the most
> challenges, and its own session planned.

I just want to point out some prior art for a tasks resource [1] in Glance. It 
might help inform your discussion a bit. I can understand how it will be 
challenging. If an API guideline for tasks eventually came out as a result of 
this discussion, it would reduce the challenges for future projects. ;)

Cheers,
Everett

[1] http://developer.openstack.org/api-ref/image/v2/#tasks


__
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 WG] How does one best express a time interval as an API filtering query?

2016-10-06 Thread Everett Toews


> On Oct 6, 2016, at 10:43 AM, Jeremy Stanley  wrote:
> 
> On 2016-10-06 10:30:30 -0500 (-0500), Kevin L. Mitchell wrote:
> [...]
>> Problem with that is that ':' is a valid character within an ISO date,
>> though I do like the 'between' prefix.  Now, '/' can be used if it's URL
>> encoded, but I agree that that is non-ideal.  How about a syntax
>> something like:
>> 
>>
>> ?finished_at=between:ISO_DATE_A@ISO_DATE_B_at=between:ISO_DATE_C@ISO_DATE_D
> 
> I'll admit I'm not up on the intricacies of URL expectations for
> APIs, but why not just use a comma? That's not an unusual meaning
> for it as punctuation (at least in English), and has the property
> that it's not overloading a typical field separator within either
> 8601 or HTTP encodings. (Now I've fulfilled my bikeshed quota for
> the month.)

We chatted about this at the API WG meeting today. This seems reasonable to us 
too.

?finished_at=between:ISO_DATE_A,ISO_DATE_B

@milanisko I encourage you to propose this change to the filtering guideline! 
[1]

Contributing is easy, same as any other OpenStack project. See #2 under How to 
Contribute. [2]

[1] 
https://github.com/openstack/api-wg/blob/master/guidelines/pagination_filter_sort.rst#filtering
[2] https://wiki.openstack.org/wiki/API_Working_Group#How_to_Contribute




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

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

2016-09-01 Thread Everett Toews

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

Greetings OpenStack community,

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

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

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

# New guidelines

Nothing new this week.

# API guidelines that have been recently merged

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

# API guidelines proposed for freeze

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

Nothing new this week.

# Guidelines currently under review [7]

Nothing new this week.

# API Impact reviews currently open

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

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

Thanks for reading and see you next week!

[1] 
https://review.openstack.org/#/q/status:open+AND+(message:ApiImpact+OR+message:APIImpact),n,z
[2] https://wiki.openstack.org/wiki/Meetings/API-WG#Agenda
[3] http://specs.openstack.org/openstack/api-wg/
[4]: https://bugs.launchpad.net/openstack-api-wg
[5]: http://eavesdrop.openstack.org/meetings/api_wg/
[7]: https://review.openstack.org/#/q/status:open+project:openstack/api-wg,n,z
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova][API] Need naming suggestions for "capabilities"

2016-08-25 Thread Everett Toews

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

2016-08-11 Thread Everett Toews

Greetings OpenStack community,

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

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

# New guidelines

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

# API guidelines proposed for freeze

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

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

# Guidelines currently under review

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

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

# API Impact reviews currently open

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

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

Thanks for reading and see you next week!

[1] 
https://review.openstack.org/#/q/status:open+AND+(message:ApiImpact+OR+message:APIImpact),n,z
[2] https://wiki.openstack.org/wiki/Meetings/API-WG#Agenda
[3] http://specs.openstack.org/openstack/api-wg/
[4]: https://bugs.launchpad.net/openstack-api-wg
[5]: http://eavesdrop.openstack.org/meetings/api_wg/
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [Openstack-operators] [User-committee] ACTION Needed - All WGs Chairs

2016-08-06 Thread Everett Toews

Hi Edgar,

The API Working Group is alive and well. We meet weekly on IRC and send a 
newsletter to openstack-dev@ for all to stay updated on our progress. I've 
added us back to the User Committee wiki page.

Mission Statement

To improve the developer experience of API users by converging the OpenStack 
API to a consistent and pragmatic RESTful design. The working group creates 
guidelines that all OpenStack projects should follow for new development, and 
promotes convergence of new APIs and future versions of existing APIs.

Co-chairs:

Chris Dent
Michael McCune
Everett Toews

Guidelines: http://specs.openstack.org/openstack/api-wg/
Repo: http://git.openstack.org/cgit/openstack/api-wg/
Gerrit: 
https://review.openstack.org/#/q/status:open+project:openstack/api-wg,n,z
Wiki: https://wiki.openstack.org/wiki/API_Working_Group (Communication, 
Deliverables, How to Contribute, Scope)

Cheers,
Everett


On Jul 7, 2016, at 9:13 PM, Edgar Magana 
<edgar.mag...@workday.com<mailto:edgar.mag...@workday.com>> wrote:

Dear Working Groups Chairs,

As you know WGs present an opportunity to consolidate and increase the 
Community around OpenStack from the User and Operator perspective. One of the 
goals of the User Committee is to help WGs to have the resources needed to 
achieve their specific goals and exactly as the TC validates and accepts 
development projects the UC needs to validate and accept WGs before they be 
granted with resources and support from UC and the OpenStack Foundation. 
(https://wiki.openstack.org/wiki/Procedure_for_Creating_a_New_Working_Group)

In order to validate the current work and progress of the existing WGs 
under:https://wiki.openstack.org/wiki/Governance/Foundation/UserCommittee#Working_Groups
The UC would like to have all chairs to reply to this thread with the status of 
the WG and their plans for the Barcelona summit. This is also an opportunity to 
have a space allocated to get together and discuss about work and activities. 
This is only for existing WGs not for new ones. If we do not hear from WG 
Chairs, we will assume that those WGs are no longer active and therefore they 
will be removed from UC documentation.

Please, reach out to us with a short report of the activities (wikis, 
etherpads, repos, etc).

Thanks,

Edgar, Shilla and Jon
UC Members.

___
User-committee mailing list
user-commit...@lists.openstack.org<mailto:user-commit...@lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/user-committee

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [openstack-dev] [api] APIs for exposing resource capabilities

2016-08-03 Thread Everett Toews


On Aug 3, 2016, at 12:59 AM, Ramakrishna, Deepti 
> wrote:

Hi,

I would like to bring your attention to my spec [1] (already approved) on 
capability APIs and would like to get feedback from API WG.

To summarize, I propose defining a capability API for every resource in a REST 
API where it makes sense and is needed. In the context of Cinder, we would have 
a capability API at the root resource level (GET 
/v3.x/{tenant_id}/capabilities) that would return, e.g., [“volume-backup", 
“other-capability”]. Similarly, we could have a capability API on the volume 
types resource (GET /v3.x/{tenant_id}/types/{volume_type_id}/capabilities) that 
would return all the features supported by a volume type and so on.

I believe that this API pattern solves the problem of exposing capabilities and 
could be used for enabling/disabling UI widgets on Horizon and other clients. 
This pattern cleanly translates to all OpenStack projects which all face the 
general problem.

Can you please look at the spec (and the implementation for Cinder [2]) and let 
me know if you have any feedback? I would be most interested in knowing your 
thoughts about cross-project suitability of this solution.

Thanks,
Deepti

[1] https://review.openstack.org/#/c/306930/
[2] https://review.openstack.org/#/c/350310/

I added this topic to the API WG meeting tomorrow.

https://wiki.openstack.org/wiki/Meetings/API-WG

Everett

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

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

2016-06-30 Thread Everett Toews

Greetings OpenStack community,

A few interesting developments in the API WG this week.

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

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

# Recently merged guidelines

Nothing new in the last two weeks.

# API guidelines proposed for freeze

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

None this week

# Guidelines currently under review

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

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

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

# API Impact reviews currently open

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

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

Thanks for reading and see you next week!

[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://review.openstack.org/#/c/283136/
[5] https://review.openstack.org/#/c/254895/
[6] https://review.openstack.org/#/c/273158/

Re: [openstack-dev] [nova] API changes on limit / marker / sort in Newton

2016-06-02 Thread Everett Toews


> On Jun 1, 2016, at 2:01 PM, Matt Riedemann  wrote:
> 
> Agree with Sean, I'd prefer separate microversions since it makes getting 
> these in easier since they are easier to review (and remember we make changes 
> to python-novaclient for each of these also).
> 
> Also agree with using a single spec in the future, like Sean did with the API 
> deprecation spec - deprecating multiple APIs but a single spec since the 
> changes are the same.

I appreciate that Nova has a long and storied history around it's API. 
Nonetheless, since it seems you're considering moving to  a new microversion, 
we'd appreciate it if you would consider adhering to the Sorting guideline [1] 
and helping drive consensus into the Pagination guideline [2].

Thanks,
Everett

[1] 
http://specs.openstack.org/openstack/api-wg/guidelines/pagination_filter_sort.html#sorting
[2] 
https://review.openstack.org/#/c/190743/21/guidelines/pagination_filter_sort.rst
__
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-WG summit session recap

2016-05-09 Thread Everett Toews


> On May 9, 2016, at 10:12 AM, michael mccune  wrote:
> 
> 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.

We've started an issue to track this at Guideline compliance doc [1]. We'd be 
interested to get feedback on the issue before forging ahead with the doc.

Thanks,
Everett

[1] https://bugs.launchpad.net/openstack-api-wg/+bug/1578728


__
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

2016-03-10 Thread Everett Toews

Hi All,

The following API guideline is ready for final review. It will be merged on 
March 18, if there's no further feedback.

1. Header non-proliferation guideline
https://review.openstack.org/#/c/280381/

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

Re: [openstack-dev] [all] [api] API Working Group Refresher

2016-01-18 Thread Everett Toews


On Jan 17, 2016, at 8:56 PM, Qiming Teng 
> wrote:

On Fri, Jan 15, 2016 at 12:48:51PM +, Chris Dent wrote:

At yesterday's API Working Group meeting we decided it would be a
good idea to send out a refresher on the existence of the group,
its goals and activities. If you have interest in the improvement
and standardization of OpenStack APIs please take this as an
invitation to participate.

The group meets once a week in openstack-meeting-3 on Thursdays
alternating between 00:00 UTC and 16:00 UTC[0].

The meeting time is quite confusing based on info on the wiki. It says
that 'next' meeting would be 2016-01-28 at 00:00UTC, previous meeting
was 2016-01-14 at 16:00UTC. Do we have a meeting on 2016-01-21? What
timeslot should it be? 16:00UTC or 00:00UTC?

I updated the meeting page to have the correct next meeting at 2016-01-21 at 
00:00 UTC.

Apologies for the confusion.

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

Re: [openstack-dev] [magnum][api] Looking for a Cross-Project Liaison for the API Working Group

2015-12-02 Thread Everett Toews

On Dec 2, 2015, at 12:32 AM, 王华 
> wrote:

Adrian,
I would like to be an alternate.

Regards
Wanghua

On Wed, Dec 2, 2015 at 10:19 AM, Adrian Otto 
> wrote:
Everett,

Thanks for reaching out. Eli is a good choice for this role. We should also 
identify an alternate as well.

Adrian

--
Adrian

> On Dec 1, 2015, at 6:15 PM, Qiao,Liyong 
> > wrote:
>
> hi Everett
> I'd like to take it.
>
> thanks
> Eli.

Great!

Eli and Wanghua, clone the api-wg repo as you would any repo and add yourselves 
to this file

http://git.openstack.org/cgit/openstack/api-wg/tree/doc/source/liaisons.json

Please make sure you use your name *exactly* as it appears in Gerrit. It should 
be the same as the name that appears in the Reviewer field on any review in 
Gerrit. Also, double check that you have only one account in Gerrit.

If you need help, just ask in #openstack-sdks where the API WG hangs out on IRC.

Cheers,
Everett

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

[openstack-dev] [magnum][api] Looking for a Cross-Project Liaison for the API Working Group

2015-12-01 Thread Everett Toews

Hello Magnumites,

The API Working Group [1] is looking for a Cross-Project Liaison [2] from the 
Magnum project.

What does such a role entail?

The API Working Group seeks API subject matter experts for each project to 
communicate plans for API updates, review API guidelines with their project’s 
view in mind, and review the API Working Group guidelines as they are drafted. 
The Cross-Project Liaison (CPL) should be familiar with the project’s REST API 
design and future planning for changes to it.

Please let us know if you're interested and we'll bring you on board!

Cheers,
Everett

[1] http://specs.openstack.org/openstack/api-wg/
[2] http://specs.openstack.org/openstack/api-wg/liaisons.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] consolidate IRC change with #openstack-sdk?

2015-12-01 Thread Everett Toews

On Nov 30, 2015, at 7:58 AM, michael mccune  wrote:
> 
> 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.

I updated the couple of places I could find on the wiki. I also sent out a 
personalized message to everyone in the now defunct #openstack-api channel on 
Freenode.

See you in #openstack-sdks (don't forget it's plural!)

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

[openstack-dev] [all][api] New API Guidelines Ready for Cross Project Review

2015-11-13 Thread Everett Toews

Hi All,

The following API guidelines are ready for cross project review. They will be 
merged on Nov. 20 if there's no further feedback.

1. Add introduction for API micro version guideline
https://review.openstack.org/#/c/187112/

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

3. A guideline for errors
https://review.openstack.org/#/c/167793/

Cheers,
Everett


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

Re: [openstack-dev] [all][api] New API Guidelines Ready for Cross Project Review

2015-11-13 Thread Everett Toews


> On Nov 13, 2015, at 12:01 PM, John Dickinson <m...@not.mn> wrote:
> 
> 
> 
> On 13 Nov 2015, at 9:42, Everett Toews wrote:
> 
>> Hi All,
>> 
>> The following API guidelines are ready for cross project review. They will 
>> be merged on Nov. 20 if there's no further feedback.
>> 
>> 1. Add introduction for API micro version guideline
>> https://review.openstack.org/#/c/187112/
> 
> Specifically this patch, or the ones dependent on it? Because this specific 
> patch doesn't actually say anything.

Specifically this patch. Just looking to initially move forward in some small 
way on this.

Everett


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

Re: [openstack-dev] [api] consolidate IRC change with #openstack-sdk?

2015-11-13 Thread Everett Toews

Please note that should be #openstack-sdks (plural) !

> On Nov 13, 2015, at 6: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. :)

A little bit of data to inform the decision. I threw together a quick n' dirty 
spreadsheet [1] to see what the user overlap is like.

16 of the 39 in #openstack-api are already in #openstack-sdks.

I'm actually not super opinionated on it. But I suppose I'd lean towards 
folding it in.

Would like to hear what others in the API WG think.

Everett

[1] 
https://docs.google.com/spreadsheets/d/12i1bSIu38yLXnAiasNjb4Nzhy1yaHmVOQ3kFr1GIFIk/edit?usp=sharing
__
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] [nova][api]

2015-11-09 Thread Everett Toews

On Nov 9, 2015, at 12:29 AM, Tony Breeds  wrote:
> 
> On Fri, Nov 06, 2015 at 12:30:19PM +, John Garbutt wrote:
> 
>> Ideally, I would like us to fill out that pagination part first.
> 
> It seems the person leading this within the API-WG is AWOL so ...

A couple of patch sets were just sent. Please review!

Everett


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

Re: [openstack-dev] [nova][api]

2015-11-06 Thread Everett Toews

On Nov 6, 2015, at 6:30 AM, John Garbutt 
> wrote:

On 6 November 2015 at 12:11, Sean Dague > 
wrote:
On 11/06/2015 04:13 AM, Salvatore Orlando wrote:
It makes sense to have a single point were response pagination is made
in API processing, rather than scattering pagination across Nova REST
controllers; unfortunately if I am not really able to comment how
feasible that would be in Nova's WSGI framework.

However, I'd just like to add that there is an approved guideline for
API response pagination [1], and if would be good if all these effort
follow the guideline.

Salvatore

[1] 
https://specs.openstack.org/openstack/api-wg/guidelines/pagination_filter_sort.html

The pagination part is just a TODO in there.

Ideally, I would like us to fill out that pagination part first.

If we can't get global agreement quickly, we should at least get a
Nova API wide standard pattern.

Am I missing something here?

When I sent my initial reply to this thread, I Cc'd the author of the 
pagination guideline at wu...@unitedstack.com. 
However, I got a bounce message so it's a bit unclear if wuhao is still working 
on this. If someone knows this person, can you please highlight this thread?

If we don't hear a response on this thread or the review, we can move forward 
another way.

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

Re: [openstack-dev] [all][api][tc][perfromance] API for getting only status of resources

2015-11-05 Thread Everett Toews

On Nov 3, 2015, at 11:46 PM, John Griffith 
> wrote:

On Tue, Nov 3, 2015 at 4:57 PM, michael mccune 
> wrote:
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?

Yes, we already have that capability and it's used in a number of places.

Relevant API guideline

http://specs.openstack.org/openstack/api-wg/guidelines/pagination_filter_sort.html#filtering

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

Re: [openstack-dev] [nova][api] Pagination in thre API

2015-11-05 Thread Everett Toews

On Nov 5, 2015, at 5:44 AM, John Garbutt 
> wrote:

On 5 November 2015 at 09:46, Richard Jones 
> wrote:
As a consumer of such APIs on the Horizon side, I'm all for consistency in
pagination, and more of it, so yes please!

On 5 November 2015 at 13:24, Tony Breeds 
> wrote:

On Thu, Nov 05, 2015 at 01:09:36PM +1100, Tony Breeds wrote:
Hi All,
   Around the middle of October a spec [1] was uploaded to add
pagination
support to the os-hypervisors API.  While I recognize the use case it
seemed
like adding another pagination implementation wasn't an awesome idea.

Today I see 3 more requests to add pagination to APIs [2]

Perhaps I'm over thinking it but should we do something more strategic
rather
than scattering "add pagination here".

+1

The plan, as I understand it, is to first finish off this API WG guideline:
http://specs.openstack.org/openstack/api-wg/guidelines/pagination_filter_sort.html

An attempt at an API guideline for pagination is here [1] but hasn't received 
any updates in over a month, which can be understandable as sometimes other 
work takes precedence.

Perhaps we can get that guideline moving again?

If it's becoming difficult to reach agreement on that approach in the 
guideline, it could be worthwhile to take a step back and do some analysis on 
the way pagination is done in the more established APIs. I've found that such 
analysis can be very helpful as you're moving forward from a known state.

The place for that analysis is in Current Design [2] by filling in the 
Pagination page. You can find many examples of such analysis from the Current 
Design like Sorting [3].

Cheers,
Everett

[1] https://review.openstack.org/#/c/190743/
[2] https://wiki.openstack.org/wiki/API_Working_Group/Current_Design
[3] https://wiki.openstack.org/wiki/API_Working_Group/Current_Design/Sorting

__
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] service catalog: TNG

2015-10-09 Thread Everett Toews

On Oct 9, 2015, at 9:39 AM, Sean Dague  wrote:
> 
> It looks like some great conversation got going on the service catalog
> standardization spec / discussion at the last cross project meeting.
> Sorry I wasn't there to participate.
> 
> A lot of that ended up in here (which was an ether pad stevemar and I
> started working on the other day) -
> https://etherpad.openstack.org/p/mitaka-service-catalog which is great.
> 
> A couple of things that would make this more useful:
> 
> 1) if you are commenting, please (ircnick) your comments. It's not easy
> to always track down folks later if the comment was not understood.
> 
> 2) please provide link to code when explaining a point. Github supports
> the ability to very nicely link to (and highlight) a range of code by a
> stable object ref. For instance -
> https://github.com/openstack/nova/blob/2dc2153c289c9d5d7e9827a4908b0ca61d87dabb/nova/context.py#L126-L132
> 
> That will make comments about X does Y, or Z can't do W, more clear
> because we'll all be looking at the same chunk of code and start to
> build more shared context here. One of the reasons this has been long
> and difficult is that we're missing a lot of that shared context between
> projects. Reassembling that by reading each other's relevant code will
> go a long way to understanding the whole picture.
> 
> 
> Lastly, I think it's pretty clear we probably need a dedicated workgroup
> meeting to keep this ball rolling, come to a reasonable plan that
> doesn't break any existing deployed code, but lets us get to a better
> world in a few cycles. annegentle, stevemar, and I have been pushing on
> that ball so far, however I'd like to know who else is willing to commit
> a chunk of time over this cycle to this. Once we know that we can try to
> figure out when a reasonable weekly meeting point would be.

It's likely you're already aware of it but see

https://wiki.openstack.org/wiki/API_Working_Group/Current_Design/Service_Catalog

for many examples of service catalogs from both public and private OpenStack 
clouds.

Everett


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

[openstack-dev] [all][api] New API Guidelines Ready for Cross Project Review

2015-10-08 Thread Everett Toews

Hi All,

The following API guidelines are ready for cross project review. They will be 
merged on Oct. 16 if there's no further feedback.

1. Adds an API documentation guideline document
https://review.openstack.org/#/c/214817/

2. Add http400 for nonexistent resource
https://review.openstack.org/#/c/221163/

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

Re: [openstack-dev] [api][keystone][openstackclient] Standards for object name attributes and filtering

2015-09-06 Thread Everett Toews

On Sep 1, 2015, at 8:36 PM, Dolph Mathews  wrote:

> Does anyone have an example of an API outside of OpenStack that would return 
> 400 in this situation (arbitrary query string parameters)? Based on my past 
> experience, I'd expect them to be ignored, but I can't think of a reason why 
> a 400 would be a bad idea (but I suspect there's some prior art / discussion 
> out there).

Good question! I think it’s a great idea to look outside OpenStack-land to see 
what’s going on in the wider world of APIs.

One example is listing containers in the Docker API [1]. A number of other 
resources will also return a 400 if a bad parameter is used.

Everett

[1] 
https://docs.docker.com/reference/api/docker_remote_api_v1.20/#list-containers

__
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

2015-09-04 Thread Everett Toews

On Aug 27, 2015, at 10:48 AM, Everett Toews <everett.to...@rackspace.com> wrote:

> Hi All,
> 
> The following API guidelines are ready for cross project review. They will be 
> merged on Sept. 4 if there's no further feedback.
> 
> 1. Add description of pagination parameters
> https://review.openstack.org/#/c/190743/
> 
> 2. Require "OpenStack-" in headers
> https://review.openstack.org/#/c/215683/
> 
> 3. Add the condition for using a project term
> https://review.openstack.org/#/c/208264/
> 
> 4. Added note about caching of responses when using https
> https://review.openstack.org/#/c/185288/
> 
> 5. add section describing 501 common mistake
> https://review.openstack.org/#/c/183456/

API guidelines 2-5 above have been merged. Guideline 1 needs further work.

Thanks for you feedback,
Everett


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

Re: [openstack-dev] [api] [wsme] [ceilometer] Replacing WSME with _____ ?

2015-08-28 Thread Everett Toews

On Aug 28, 2015, at 6:10 PM, Morgan Fainberg morgan.fainb...@gmail.com wrote:

 It seems like Flask has a reasonable amount of support and there is a good 
 ecosystem around it but that aside (as Jay said)... I definitely support 
 exposing the schema to the end user; making it easier for the end user to 
 validate input / model outputs for their integration with OpenStack services 
 is an important feature of whatever is selected. 
 
 I admit I am intrigued by the swagger things (and I expect to be spending 
 some serious time considering it) that Monty linked (especially relating to 
 Flask, but there is a bias as Keystone is moving to flask).

With respect to Swagger, we have a guideline [1] in flight from Anne that 
involves it for API docs.

Everett

[1] https://review.openstack.org/#/c/214817/
__
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

2015-08-27 Thread Everett Toews

Hi All,

The following API guidelines are ready for cross project review. They will be 
merged on Sept. 4 if there's no further feedback.

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

2. Require OpenStack- in headers
https://review.openstack.org/#/c/215683/

3. Add the condition for using a project term
https://review.openstack.org/#/c/208264/

4. Added note about caching of responses when using https
https://review.openstack.org/#/c/185288/

5. add section describing 501 common mistake
https://review.openstack.org/#/c/183456/

Cheers,
Everett


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

Re: [openstack-dev] [api][keystone][openstackclient] Standards for object name attributes and filtering

2015-08-27 Thread Everett Toews

On Aug 26, 2015, at 4:45 AM, Henry Nash hen...@linux.vnet.ibm.com wrote:

 Hi
 
 With keystone, we recently came across an issue in terms of the assumptions 
 that the openstack client is making about the entities it can show - namely 
 that is assumes all entries have a ‘name’ attribute (which is how the 
 openstack show command works). Turns out, that not all keystone entities 
 have such an attribute (e.g. IDPs for federation) - often the ID is really 
 the name. Is there already agreement across our APIs that all first class 
 entities should have a ‘name’ attribute?  If we do, then we need to change 
 keystone, if not, then we need to change openstack client to not make this 
 assumption (and perhaps allow some kind of per-entity definition of which 
 attribute should be used for ‘show’).

AFAICT, there’s no such agreement in the API WG guidelines [1].

 A follow on (and somewhat related) question to this, is whether we have 
 agreed standards for what should happen if some provides an unrecognized 
 filter to a list entities API request at the http level (this is related 
 since this is also the hole osc fell into with keystone since, again, ‘name’ 
 is not a recognized filter attribute). Currently keystone ignores filters it 
 doesn’t understand (so if that was your only filter, you would get back all 
 the entities). The alternative approach would of course be to return no 
 entities if the filter is on an attribute we don’t recognize (or even issue a 
 validation or bad request exception).  Again, the question is whether we have 
 agreement across the projects for how such unrecognized filtering should be 
 handled?

The closest thing we have is the Filtering guideline [2] but it doesn’t account 
for this particular case.

Client tool developers would be quite frustrated by a service ignoring filters 
it doesn’t understand or returning no entities if the filter isn’t recognized. 
In both cases, the developer isn’t getting the expected result but you’re 
masking the error made by the developer. 

Much better to return a 400 so the problem can be fixed immediately. Somewhat 
related is this draft [3].

Everett

[1] http://specs.openstack.org/openstack/api-wg/
[2] 
http://specs.openstack.org/openstack/api-wg/guidelines/pagination_filter_sort.html#filtering
[3] https://tools.ietf.org/html/draft-thomson-postel-was-wrong-00


__
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] [Resend] [api] Who owns API versioning and deprecation policy?

2015-08-21 Thread Everett Toews

On Aug 21, 2015, at 3:13 PM, Geoff Arnold ge...@geoffarnold.com wrote:

 After reading the following pages, it’s unclear what the current API 
 deprecation policy is and who owns it. (The first spec implies that a change 
 took place in May 2015, but is silent on what and why.) Any hints? An 
 authoritative doc would be useful, something other than an IRC log or mailing 
 list reference.
 
 Geoff
 
 http://specs.openstack.org/openstack/api-wg/guidelines/evaluating_api_changes.html
 
 https://wiki.openstack.org/wiki/API_Working_Group
 
 https://wiki.openstack.org/wiki/Application_Ecosystem_Working_Group

The API Working Group does. 

Guidelines for microversioning [1] and when to bump a microversion [2] are 
currently in review. Naturally your feedback is welcome.

We have yet to provide guidance on deprecation. If you’d like to create a 
guideline on deprecation, here’s How to Contribute [3]. If you want to throw 
some ideas around we’re in #openstack-api or feel free to drop by one of our 
meetings [4].

Everett

[1] https://review.openstack.org/#/c/187112/
[2] https://review.openstack.org/#/c/187896/
[3] https://wiki.openstack.org/wiki/API_Working_Group#How_to_Contribute
[4] https://wiki.openstack.org/wiki/Meetings/API-WG


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

Re: [openstack-dev] [api] [all] To changes-since or not to changes-since

2015-08-10 Thread Everett Toews

On Aug 9, 2015, at 11:03 PM, hao wang 
sxmatch1...@gmail.commailto:sxmatch1...@gmail.com wrote:

Hi, stackers

Since now we have merged filtering guideline[1], is that said we should 
implement this feature according this guideline?  like this:

GET /app/items?f_updated_at=gte:some_timestamp

Do we have reached a consensus about this?

You’ll definitely want to drop the “f_” prefix from your filter name, see the 
about-to-be-merged guideline No project uses f_ prefix in filter params [1].

Everett

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

__
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

2015-07-06 Thread Everett Toews

Hi All,

We have 7 API Guidelines that are ready for a final review.

1. Add section clarifying PUT vs PATCH semantics
https://review.openstack.org/#/c/183945/

2. Adding 5xx guidance
https://review.openstack.org/#/c/183698/

3. Adds a small update to tagging guidance
https://review.openstack.org/#/c/187891/

4. Add the description of GET method
https://review.openstack.org/#/c/185180/

5. Adds clarification and example to 500 guidance
https://review.openstack.org/#/c/190064/

6. add subsection around caching behavior and http
https://review.openstack.org/#/c/183523/

7. add section describing method use in http
https://review.openstack.org/#/c/189738/

If the API Working Group hasn’t received any further feedback, we’ll merge them 
on July 13.

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

Re: [openstack-dev] [api][Solum] Request for feedback on new API resource

2015-06-23 Thread Everett Toews

On Jun 18, 2015, at 3:07 PM, Devdatta Kulkarni 
devdatta.kulka...@rackspace.commailto:devdatta.kulka...@rackspace.com wrote:

Hi, API WG team,

In Solum, recently we have been working on some changes to our REST API.

Basically, we have introduced a new resource ('app'). The spec for this has 
been accepted by Solum cores.
https://github.com/stackforge/solum-specs/blob/master/specs/liberty/app-resource.rst

Right now we have a patch for review implementing this spec:
https://review.openstack.org/#/c/185147/

If it is not too much to request, I was wondering if someone from your team can 
take a look
at the spec and the review, to see if we are not violating any of your 
guidelines.

Thank you for your help.

- Devdatta

Do you have this API documented anywhere?

Is there a spec or similar for this API change?

In our experience, it’s best to consider the API design apart from the 
implementation. The separation of concerns makes for a cleaner review and a 
better design. The Glance team did a good job of this in their Artifact 
Repository API specification [1].

Regards,
Everett

[1] https://review.openstack.org/#/c/177397/
__
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

2015-06-19 Thread Everett Toews

Hi All,

We have 3 API Guidelines that are ready for a final review.

1. Add section on filtering
https://review.openstack.org/#/c/177468/

2. http guideline expansion: background
https://review.openstack.org/#/c/181931/

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

If the API Working Group hasn’t received any further feedback, we’ll merge them 
on June 26.

Thanks,
Everett


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

Re: [openstack-dev] [monasca] [java]

2015-05-15 Thread Everett Toews

On May 15, 2015, at 3:49 AM, Thierry Carrez thie...@openstack.org wrote:

 Dieterly, Deklan wrote:
 We’ve seen that Swift has introduced components in Go. So, this looks like a 
 precedent for allowing other languages where deemed appropriate. Before we 
 spend many man-hours hacking on the Python components, it seems reasonable 
 to determine if there really exists a reason to do so. I’m interested in 
 soliciting any feedback from the community be it pleasant or unpleasant.
 
 Swift has not introduced components in Go. It is at the early stages of
 *exploring* the possibility of doing so, through a specific feature branch.
 
 The Technical Committee position has always been python unless there is
 a compelling reason otherwise. Every language supported increases
 fragmentation of our community and increases the CI effort. The argument
 for adding a language has to be pretty compelling to counterbalance the
 damage it does to OpenStack as a development community.
 
 In Monasca's case, there is always the possibility to stay out of the
 OpenStack tent and stay in Java. There is the possibility to rewrite
 things in Python. And there is the possibility to convince the Technical
 Committee that (1) we want Monasca featureset in so badly we would add
 Java as a supported language just so that can happen and (2) Monasca
 featureset can't be written in Python.

Not to move this discussion off-list but I feel the need to at least point out 
a highly relevant summit session.

Is it time to have more than just Python in OpenStack?
https://libertydesignsummit.sched.org/event/6bb3f4fe34a4a0236266d99a2039c963

Everett


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

Re: [openstack-dev] [nova][cinder] can we deprecate the volume CLIs in novaclient?

2015-05-15 Thread Everett Toews

On May 15, 2015, at 10:28 AM, John Griffith 
john.griffi...@gmail.commailto:john.griffi...@gmail.com wrote:



On Thu, May 14, 2015 at 8:29 PM, Matt Riedemann 
mrie...@linux.vnet.ibm.commailto:mrie...@linux.vnet.ibm.com wrote:
This came up while talking about bug 1454369 [1].  This also came up at one 
point in kilo when we found out the volume CLIs in novaclient didn't work at 
one point and we broke the cells devstack exercises job because of it.

python-novaclient uses cinder API to handle the volume CLI rather than going to 
the nova volume API.  There are issues with this because novaclient needs a 
certain endpoint/service_type setup in the service catalog to support cinder 
v1/v2 APIs (whatever devstack sets up today).  novaclient defaults to volume 
(v1) and if you disable that in cinder then novaclient doesn't work because 
it's not using volumev2.

So like anyone might ask, why doesn't novaclient talk to nova volume APIs to do 
volume thingies and the answer is because the nova volume API doesn't handle 
all of the volume thingies like snapshots and volume types.

So I got to to thinking, why the hell are we still supporting volume operations 
via novaclient anyway?  Isn't that cinderclient's job?  Or 
python-openstackclient's job?  Can't we deprecate the volume CLIs in novaclient 
and tell people to use cinderclient instead since it now has version discovery 
[2] so that problem would be handled for us.

Since we have nova volume APIs maybe we can't remove the volume CLIs in 
novaclient, but could they be limited to just operations that the nova API 
supports and then we make novaclient talk to nova volume APIs rather than 
cinder APIs (because the nova API will talk to cinderclient which again has the 
version discovery done for us).

Or assuming we could deprecate the volume CLIs in novaclient, what would the 
timeline on deprecation be since it's not a server project with a 6 month 
release cycle?  I'm assuming we'd still have 6-12 months deprecation on a 
client like this because of all of the tooling potentially written around it.

[1] https://bugs.launchpad.net/python-novaclient/+bug/1454369
[2] https://review.openstack.org/#/c/145613/

I can't speak for the nova folks, however i do think removing the volume calls 
from novaclient seems ok.  It was always sort of left for compat I think, and 
not sure any of us really thought about just removing it.  At this point it 
probably just introduces confusion and as you're running into problems.

Seems like a good plan, and somewhat less confusing.  On a side note, might be 
some other *things* in novaclient that we could look at as well, particularly 
around networking.  

FWIW, this is already underway in jclouds-land. After a lengthy deprecation 
period (still ongoing actually), we’ll be removing the Nova volume calls but 
obviously keeping the volume attachment stuff.

Both the Nova and Cinder calls have coexisted for over a year with 
documentation pointing from Nova to Cinder. The deprecation annotations handle 
emitting warnings for the deprecated calls to increase visibility.

Everett

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

Re: [openstack-dev] [api] Proposing Michael McCune as an API Working Group core

2015-05-14 Thread Everett Toews

Top posting to make it official...Michael McCune (elmiko) is an API Working 
Group core!

Cheers,
Everett


On May 11, 2015, at 8:57 PM, Ryan Brown rybr...@redhat.com wrote:

 On 05/11/2015 04:18 PM, Everett Toews wrote:
 I would like to propose Michael McCune (elmiko) as an API Working Group core.
 
 Not core, but +1 from me!
 
 -- 
 Ryan Brown / Software Engineer, Openstack / Red Hat, 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

[openstack-dev] [all][api] State of the OpenStack API Working Group: Liberty Edition

2015-05-14 Thread Everett Toews

This blog post is basically a preview of our cross-project session.

http://blog.phymata.com/2015/05/14/state-of-the-api-wg-liberty-edition/


The API WG will also be busy bunch at the Summit.

1 cross-project session

  API Working Group: State of the Group [1]

2 working group sessions

  API Working Group: Working Session 1 [2]
  API Working Group: Working Session 2 [3]

2 summit sessions related to the API WG.

  APIs Matter [4]
  The Good and the Bad of the OpenStack REST APIs [5]

If you're attending the summit, we hope to see you there!

Cheers,
Everett


[1] https://libertydesignsummit.sched.org/event/e14d84514003140fe30e984027299a44
[2] https://libertydesignsummit.sched.org/event/3fe7ba65fed52540e6116f7bee2392a6
[3] https://libertydesignsummit.sched.org/event/c02c575cd390b71d5e17a3f27f6b5806
[4] https://libertydesignsummit.sched.org/event/bf6f86afe58148a96ab9d1dd0d30a554
[5] https://libertydesignsummit.sched.org/event/602a2acdca6f546cef89dc0c4356e3d8


__
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] [nova][api] Allow passing body for more API methods

2015-05-11 Thread Everett Toews

On May 11, 2015, at 1:05 PM, Dean Troyer 
dtro...@gmail.commailto:dtro...@gmail.com wrote:

On Mon, May 11, 2015 at 11:44 AM, Rosa, Andrea (HP Cloud Services) 
andrea.r...@hp.commailto:andrea.r...@hp.com wrote:
 Agreed. Violating the HTTP spec is something that should be avoided.

Actually it is not violating the HTTP spec, from RFC:
  A payload within a DELETE request message has no defined semantics;
   sending a payload body on a DELETE request might cause some existing
   implementations to reject the request.

The RFC prohibit the use of a body just for the TRACE:
 A client MUST NOT send a message body in a TRACE request.


When playing in undefined areas such as this it is best to keep in ming Jon 
Postel's RFC 1122 principle: Be liberal in what you accept, and conservative 
in what you send.

I'll put it this way:  An RFC not prohibiting something does not make it a good 
idea.  This is not how we build a robust API that developers and user can 
easily adopt.

I’m agreed that this is not a good idea. I’d also invoke the principle of least 
astonishment here. Because it’s a de facto standard (so much so that some proxy 
in the middle may alter or reject such a request), it would be surprising to 
developers to allow such requests.

REST APIs are difficult enough. Let’s avoid things with no defined semantics.

I’d comment on the review but Gerrit is having a fit so I filed a bug.

https://code.google.com/p/gerrit/issues/detail?id=3361

Everett

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

[openstack-dev] [api] Proposing Michael McCune as an API Working Group core

2015-05-11 Thread Everett Toews

I would like to propose Michael McCune (elmiko) as an API Working Group core.

Among Michael’s many fine qualities:

  * Active from the start
  * Highly available
  * Very knowledgable about APIs
  * Committed the guideline template 
  * Working on moving the API Guidelines wiki page
  * Lots of solid review work

Cheers,
Everett


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

Re: [openstack-dev] [api] Changing 403 Forbidden to 400 Bad Request for OverQuota was: [nova] Which error code should we return when OverQuota

2015-05-06 Thread Everett Toews

On May 6, 2015, at 1:58 PM, David Kranz 
dkr...@redhat.commailto:dkr...@redhat.com wrote:

+1
The basic problem is we are trying to fit a square (generic api) peg in a round 
(HTTP request/response) hole.
But if we do say we are recognizing sub-error-codes, it might be good to 
actually give them numbers somewhere in the response (maybe an error code 
header) rather than relying on string matching to determine the real error. 
String matching is fragile and has icky i18n implications.

There is an effort underway around defining such sub-error-codes” [1]. Those 
error codes would be surfaced in the REST API here [2]. Naturally feedback is 
welcome.

Everett


[1] https://review.openstack.org/#/c/167793/
[2] https://review.openstack.org/#/c/167793/
__
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] [nova][api] API working group liaisons and responsibilities

2015-05-01 Thread Everett Toews

On Apr 30, 2015, at 9:54 AM, Jay Pipes jaypi...@gmail.com wrote:

 Hi Stackers,
 
 OK, so Matthew Gilliard and Alex Xu have volunteered to be the Nova team's 
 liaisons to the API working group. Big thank you to Matthew and Alex for 
 volunteering for this important role.
 
 I've created a wiki page [1] that details the responsibilities of these 
 liaisons. If these duties work out for Nova, we'll recommend other projects 
 pick them up.
 
 Here are the responsibilities that the Nova/API working group liaisons have:
 
 1. Monitor the active patch queue in nova (and nova-specs) and look out for 
 any patch that adds or changes the REST API
 
 2. For each patch collected in #1, determine if the constructs used in the 
 patch (or proposed spec) match the guidance currently laid out in the API 
 working group repo's guidance documents.
 
 3. If the patch does NOT match the guidance from the API working group, do a 
 code review on the patch pointing to the guidance from the API working group, 
 and ask the author to align with that guidance. Include in your research 
 patches to the API working group that may actually be in review and not 
 merged. (An example of this recently occurred with Sergey Nikitin's 
 re-proposed instance tagging spec: https://review.openstack.org/#/c/177112/. 
 See Ryan Brown's reference to an in-progress API working group guidance on 
 tagging)
 
 4. If there is NO guidance in the API working group repo for a particular 
 proposed API change or addition, the liaison should **either** create a 
 proposed patch to the API working group with guidance that clarifies the 
 missing functionality that is introduced in the new Nova patch or spec patch, 
 and bring the proposed guidance to the attention of the API working group. 
 **or** the liaison should working with a member of the API working group to 
 draft such a guideline. The liaison should mark the corresponding Nova patch 
 with a -1 Code Review vote with a link to the proposed guideline, noting that 
 the patch should be put on hold (Work In Progress) until the guideline is 
 merged.
 
 Best,
 -jay
 
 [1] https://wiki.openstack.org/wiki/Nova/APIWGLiaisons

This is great. I’ve added a link to that page from the Cross-Project Liaisons 
page [2]. I also added Matthew and Alex as liaisons there. 

giiard and alex_xu: feel free to join us in #openstack-api on freenode too!

Everett

[2] https://wiki.openstack.org/wiki/CrossProjectLiaisons#API_Working_Group
__
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] 3 API Guidelines up for final review

2015-05-01 Thread Everett Toews

All 3 API guidelines have merged. Thanks everyone!

Everett


On Apr 22, 2015, at 2:08 PM, Everett Toews everett.to...@rackspace.com wrote:

 Hi All,
 
 We have 3 API Guidelines that are ready for a final review.
 
 1. Metadata guidelines document
 https://review.openstack.org/#/c/141229/
 
 2. Tagging guidelines
 https://review.openstack.org/#/c/155620/
 
 3. Guidelines on using date and time format
 https://review.openstack.org/#/c/159892/
 
 If the API Working Group hasn’t received any further feedback, we’ll merge 
 them on April 29.
 
 Thanks,
 Everett
 
 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
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] Missing meetings this week

2015-04-27 Thread Everett Toews

Hi All,

I’ll be out the next few days and will be missing our meetings. Specifically 
the cross-project meeting [1] and our API WG meeting [2].

On the plus side I got to my action items from the last meeting and “froze” the 
3 guidelines up for review and proposed a cross-project session [3] (row 22). I 
also booked some time for us in the working group sessions at the summit.

Thanks,
Everett

[1] https://wiki.openstack.org/wiki/Meetings/CrossProjectMeeting
[2] https://wiki.openstack.org/wiki/Meetings/API-WG
[3] 
https://docs.google.com/spreadsheets/d/1vCTZBJKCMZ2xBhglnuK3ciKo3E8UMFo5S5lmIAYMCSE/edit#gid=827503418


__
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-operators] [all][api] 3 API Guidelines up for final review

2015-04-22 Thread Everett Toews

Hi All,

We have 3 API Guidelines that are ready for a final review.

1. Metadata guidelines document
https://review.openstack.org/#/c/141229/

2. Tagging guidelines
https://review.openstack.org/#/c/155620/

3. Guidelines on using date and time format
https://review.openstack.org/#/c/159892/

If the API Working Group hasn’t received any further feedback, we’ll merge them 
on April 29.

Thanks,
Everett


___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[openstack-dev] [all][api] 3 API Guidelines up for final review

2015-04-22 Thread Everett Toews

Hi All,

We have 3 API Guidelines that are ready for a final review.

1. Metadata guidelines document
https://review.openstack.org/#/c/141229/

2. Tagging guidelines
https://review.openstack.org/#/c/155620/

3. Guidelines on using date and time format
https://review.openstack.org/#/c/159892/

If the API Working Group hasn’t received any further feedback, we’ll merge them 
on April 29.

Thanks,
Everett


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

Re: [openstack-dev] [api] Minor changes to API

2015-04-21 Thread Everett Toews

On Apr 20, 2015, at 7:07 PM, Ian Wells 
ijw.ubu...@cack.org.ukmailto:ijw.ubu...@cack.org.uk wrote:

On 20 April 2015 at 15:23, Matthew Treinish 
mtrein...@kortar.orgmailto:mtrein...@kortar.org wrote:
On Mon, Apr 20, 2015 at 03:10:40PM -0700, Ian Wells wrote:
 It would be nice to have a consistent policy here; it would make future
 decision making easier and it would make it easier to write specs if we
 knew what was expected and the possible implementations weren't up for
 (quite so much) debate.  For different reasons, Neutron extensions are also
 not favoured, so there's no clear cut choice to make.

Uhm, there is: https://wiki.openstack.org/wiki/APIChangeGuidelines
and if you read that adding attrs without advertising it (using an
extension, microversion, or whatever) is not an allowed change.

It is also not an unallowed change (given that there's a section that appears 
to define what an unallowed attribute change is).  The page reads very 
awkwardly.

Whatever your preference might be, I think it's best we lose the ambiguity.  
And perhaps advertise that page a little more widely, actually - I hadn't come 
across it in my travels.  And perhaps improve its air of authority: rules on 
this subject should probably live somewhere in a repo so that it's clear 
there's consensus for changes.  Currently anyone can change it for any reason, 
and two years after the last substantive change it's hard to say who even knew 
it was being changed, let alone whether they agreed.

Such a repo exists! [1]

You can see those docs rendered here. [2]

It’s under the purview of the API Working Group. [3] You’re most welcome to 
join us.

That APIChangeGuidelines wiki page really needs to be incorporated into the 
official repo [1]. I’ve added that as an agenda item to our next meeting on 
Thursday 2015-04-23 at 00:00 UTC [4].

[1] http://git.openstack.org/cgit/openstack/api-wg/
[2] http://specs.openstack.org/openstack/api-wg/
[3] https://wiki.openstack.org/wiki/API_Working_Group
[4] https://wiki.openstack.org/wiki/Meetings/API-WG

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

Re: [openstack-dev] [all] [api] gabbi: A tool for declarative testing of APIs

2015-04-21 Thread Everett Toews

On Apr 20, 2015, at 2:45 PM, Chris Dent chd...@redhat.com wrote:

 I wanted to make a quick update on the latest happenings with
 gabbi[0], the tool I've created to do declarative testing of
 OpenStack APIs (starting with Ceilometer and Gnocchi).
 
 * Jay Pipes and I are doing a presentation API Matters at summit.
  The latter of half of that will be me noodling about gabbi,
  including a demo.[1]

This is great! I'm looking forward to attending it.

Miguel and I are doing something similar with our The Good and the Bad of the 
OpenStack REST APIs” presentation [1]. Which is exactly 10 minutes after your 
presentation. :)

Cheers,
Everett

[1] 
https://openstacksummitmay2015vancouver.sched.org/event/6ce758d5c7340db74e0d432e138c6619
__
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] Minor changes to API

2015-04-21 Thread Everett Toews

On Apr 20, 2015, at 2:19 PM, Douglas Mendizabal
douglas.mendiza...@rackspace.commailto:douglas.mendiza...@rackspace.com
wrote:

Hi openstack-dev@

I was wondering if the API Working Group had an opinion on how to deal with
minor changes to the api? For example, what if you wanted to add a new
attribute to a JSON response? I would think that a minor change like that
could be done without having to create a new versioned endpoint. So a newer
release would just add the new attribute without having to create a new /v1.1/
endpoint.

I’d suggest (like others have already) doing microversions like Nova [1].
Creating a new endpoint would be a cruel thing to do to your clients,
especially considering it’s a seemingly backwards compatible change.

However, minor changes like that could still possibly break clients that are
not expecting them. For example, a client that uses the json response as
arguments to a method via **kwargs would start seeing TypeErrors for unexpected
arguments.

And let us not forget statically typed languages. But even there adding a new
attribute isn’t that big of a deal. If there’s an unexpected attribute in a
response, it can simply be ignored. No harm done.

But the user might not even be aware the new attribute is available unless
they’re not looking at their request/response logs. Hence the need for
microversions.

Everett

[1]
http://specs.openstack.org/openstack/nova-specs/specs/kilo/implemented/api-microversions.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] API WG Meeting Time

2015-04-16 Thread Everett Toews

On Apr 1, 2015, at 10:12 AM, Ian Cordasco ian.corda...@rackspace.com wrote:

 
 
 On 4/1/15, 08:24, michael mccune m...@redhat.com wrote:
 
 On 04/01/2015 08:35 AM, Jay Pipes wrote:
 On 03/31/2015 10:13 PM, Everett Toews wrote:
 Ever since daylight savings time it has been increasing difficult for
 many API WG members to make it to the Thursday 00:00 UTC meeting time.
 
 Do we change it so there’s only the Thursday 16:00 UTC meeting time?
 
 On a related note, I can’t make it to tomorrow’s meeting. Can someone
 else please #startmeeting?
 
 We should value our Asian friends' input. I think Having multiple
 meeting times is appropriate. Perhaps not 00:00UTC, but maybe something
 more in their afternoon?
 
 although the 16:00UTC time works well for me, i agree with Jay's
 sentiment here.
 
 +1 for finding another alternating time
 
 Mike
 
 Not just Asia, but Australia and other parts of Europe. I’d like
 Christopher to weigh in since he was the person who had pushed for the
 00:00UTC meeting time.
 
 Is something like 02:00 UTC easier for them?
 
 If no one else volunteers, I’ll #startmeeting the meeting at 00:00UTC this
 week (tonight for the US folks).
 
 —
 Ian

We discussed the time change at yesterday’s API WG meeting on Thursday 00:00 
UTC (only 4 people present) [1]. We didn’t come to any sort of conclusion.

It would be good to hear from those in Asia, Australia, and Europe on the 
subject.

In the absence of consensus, I suppose we’ll leave things the way they are.

Everett

[1] 
http://eavesdrop.openstack.org/meetings/api_wg/2015/api_wg.2015-04-16-00.00.log.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] [Openstack-operators] [all][log] Openstack HTTP error codes

2015-04-08 Thread Everett Toews

On Jan 29, 2015, at 8:34 PM, Rochelle Grober 
rochelle.gro...@huawei.commailto:rochelle.gro...@huawei.com wrote:

Hi folks!

Changed the tags a bit because this is a discussion for all projects and 
dovetails with logging rationalization/standards/

At the Paris summit, we had a number of session on logging that kept circling 
back to Error Codes.  But, these codes would not be http codes, rather, as 
others have pointed out, codes related to the calling entities and referring 
entities and the actions that happened or didn’t.  Format suggestions were 
gathered from the Operators and from some senior developers.  The Logging 
Working Group is planning to put forth a spec for discussion on formats and 
standards before the Ops mid-cycle meetup.

Working from a Glance proposal on error codes:  
https://review.openstack.org/#/c/127482/ and discussions with operators and 
devs, we have a strawman to propose.  We also have a number of requirements 
from Ops and some Devs.

Here is the basic idea:

Code for logs would have four segments:
Project Vendor/Component  Error Catalog 
number Criticality
Def [A-Z] [A-Z] [A-Z]   -  [{0-9}|{A-Z}][A-Z] - 
[-]-   [0-9]
Ex.  CIN-   NA- 
   0001- 2
Cinder   NetApp 
   driver error no  Criticality
Ex.  GLA-  0A-  
   0051   3
Glance  Api 
error no   Criticality
Three letters for project,  Either a two letter vendor code or a number and 
letter for 0+letter for internal component of project (like API=0A, Controller 
=0C, etc),  four digit error number which could be subsetted for even finer 
granularity, and a criticality number.

This is for logging purposes and tracking down root cause faster for operators, 
but if an error is generated, why can the same codes be used internally for the 
code as externally for the logs?  This also allows for a unique message to be 
associated with the error code that is more descriptive and that can be pre 
translated.  Again, for logging purposes, the error code would not be part of 
the message payload, but part of the headers.  Referrer IDs and other info 
would still be expected in the payload of the message and could include 
instance ids/names, NICs or VIFs, etc.  The message headers is code in Oslo.log 
and when using the Oslo.log library, will be easy to use.

Since this discussion came up, I thought I needed to get this info out to folks 
and advertise that anyone will be able to comment on the spec to drive it to 
agreement.  I will be  advertising it here and on Ops and Product-WG mailing 
lists.  I’d also like to invite anyone who want to participate in discussions 
to join them.  We’ll be starting a bi-weekly or weekly IRC meeting (also 
announced in the stated MLs) in February.

And please realize that other than Oslo.log, the changes to make the errors 
more useable will be almost entirely community created standards with community 
created tools to help enforce them.  None of which exist yet, FYI.

Hi Rocky,

The API WG is trying to come up with a guideline for an error format for the 
HTTP APIs [1]. In that error format is a code field that I was hoping could 
match the code in the logs you mention above.

I noticed in the Logging WG meetings [2] that you mention an Error Code Spec”. 
I’d like to be able to use info from that spec in the example [2] of the error 
format.

Has there been any progress on that spec? Can you link me to it?

Also, if you have time for a review of the error format, I’d like to hear your 
thoughts.

Thanks,
Everett

[1] https://review.openstack.org/#/c/167793/
[2] https://wiki.openstack.org/wiki/Meetings/log-wg
[3] 
https://review.openstack.org/#/c/167793/4/guidelines/errors-example.json,unified


__
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: [jclouds-labs-openstack] OS Ceilometer API support (#166)

2015-04-03 Thread Everett Toews

Closed #166.

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-labs-openstack/pull/166#event-272752086

Re: [jclouds-site] add softlayer getting started (#134)

2015-04-03 Thread Everett Toews

@andreaturli The next release is out. ;) I'll leave this one up to you.

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-site/pull/134#issuecomment-89337328

Re: [jclouds-examples] Add layer 7 load balancer examples. (#61)

2015-04-03 Thread Everett Toews

Closed #61.

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-examples/pull/61#event-272780705

Re: [jclouds-site] Update compute.md (#130)

2015-04-03 Thread Everett Toews

Closed #130.

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-site/pull/130#event-272779175

Re: [jclouds-labs-openstack] Adds service predicates and more tests (#186)

2015-04-03 Thread Everett Toews

:+1: after a check for naming consistency is done.

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-labs-openstack/pull/186#issuecomment-89410171

Re: [jclouds-labs-openstack] Adds service predicates and more tests (#186)

2015-04-03 Thread Everett Toews

 +import static com.google.common.base.Preconditions.checkNotNull;
 +import static java.util.concurrent.TimeUnit.SECONDS;
 +import static org.jclouds.util.Predicates2.retry;
 +
 +import org.jclouds.openstack.poppy.v1.domain.Service;
 +import org.jclouds.openstack.poppy.v1.domain.ServiceStatus;
 +import org.jclouds.openstack.poppy.v1.features.ServiceApi;
 +import com.google.common.base.Predicate;
 +
 +public class ServicePredicates {
 +   public static PredicateService awaitDeployed(ServiceApi serviceApi) {
 +  StatusUpdatedPredicate statusPredicate = new 
 StatusUpdatedPredicate(serviceApi, ServiceStatus.DEPLOYED);
 +  return retry(statusPredicate, 1200, 15, 15, SECONDS);
 +   }
 +
 +   private static class StatusUpdatedPredicate implements PredicateService 
 {

Oops. I see that now. I think it was the name of the class that threw me. To me 
`StatusUpdatedPredicate` says it has to do with a 'Updated' status. Search the 
other predicates packages and see if this name is consistent with others. It 
should be inline with whatever is most consistent.

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-labs-openstack/pull/186/files#r27753065

Re: [jclouds] JCLOUDS-599 ability to execute function locally before initScript runs. (#406)

2015-04-03 Thread Everett Toews

Closed #406.

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/406#event-272756458

Re: [jclouds-labs-openstack] Adds service predicates and more tests (#186)

2015-04-03 Thread Everett Toews

 +import static com.google.common.base.Preconditions.checkNotNull;
 +import static java.util.concurrent.TimeUnit.SECONDS;
 +import static org.jclouds.util.Predicates2.retry;
 +
 +import org.jclouds.openstack.poppy.v1.domain.Service;
 +import org.jclouds.openstack.poppy.v1.domain.ServiceStatus;
 +import org.jclouds.openstack.poppy.v1.features.ServiceApi;
 +import com.google.common.base.Predicate;
 +
 +public class ServicePredicates {
 +   public static PredicateService awaitDeployed(ServiceApi serviceApi) {
 +  StatusUpdatedPredicate statusPredicate = new 
 StatusUpdatedPredicate(serviceApi, ServiceStatus.DEPLOYED);
 +  return retry(statusPredicate, 1200, 15, 15, SECONDS);
 +   }
 +
 +   private static class StatusUpdatedPredicate implements PredicateService 
 {

This should really be a more generalized status predicate like 
[ServerStatusPredicate](https://github.com/jclouds/jclouds/blob/master/apis/openstack-nova/src/main/java/org/jclouds/openstack/nova/v2_0/predicates/ServerPredicates.java#L92).
 The convenience method `awaitDeployed` can then be built on that.

I know it's unlikely that anyone would ever want to await on any of the other 
`ServiceStatus` in this particular case but the general style should still be 
followed.

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-labs-openstack/pull/186/files#r27735322

Re: [jclouds] JCLOUDS-670 Option force no password when launching images on providers (#486)

2015-04-03 Thread Everett Toews

Closed #486.

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/486#event-272758128

Re: [jclouds] Throw sane error if one of security groups is null (#515)

2015-04-03 Thread Everett Toews

Closed #515.

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/515#event-272760104

Re: [jclouds] Updated the requests in unit test case to include globalIdentifier (#531)

2015-04-03 Thread Everett Toews

Closed #531.

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/531#event-272761027

Re: [jclouds] Expecting 2 of 3 or the first flaky test to succeed (#577)

2015-04-03 Thread Everett Toews

Closed #577.

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/577#event-272761787

Re: [jclouds-site] Update aws.md (#129)

2015-04-03 Thread Everett Toews

Closed #129.

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-site/pull/129#event-272762945

[openstack-dev] [api] API WG Meeting Time

2015-03-31 Thread Everett Toews

Ever since daylight savings time it has been increasing difficult for many API 
WG members to make it to the Thursday 00:00 UTC meeting time.

Do we change it so there’s only the Thursday 16:00 UTC meeting time?

On a related note, I can’t make it to tomorrow’s meeting. Can someone else 
please #startmeeting?

Thanks,
Everett


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

[openstack-dev] [all] [api] Erring is Caring

2015-03-31 Thread Everett Toews

Hi All,

An API Working Group Guideline for Errors

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

Errors are a crucial part of the developer experience when using an API. As
developers learn the API they inevitably run into errors. The quality and
consistency of the error messages returned to them will play a large part in
how quickly they can learn the API, how they can be more effective with the
API, and how much they enjoy using the API.

We need consistency across all services for the error format returned in the
response body.

The Way Forward

I did a bit of research into the current state of consistency in errors across
OpenStack services [1]. Since no services seem to respond with a top-level
errors key, it's possible that they could just include this key in the
response body along with their usual response and the 2 can live side-by-side
for some deprecation period. Hopefully those services with unstructured errors
should okay with adding some structure. That said, the current error formats
aren't documented anywhere that I've seen so this all feels fair game anyway.

How this would get implemented in code is up to you. It could eventually be
implemented in all projects individually or perhaps a Oslo utility is called
for. However, this discussion is not about the implementation. This discussion
is about the error format.

The Review

I’ve explicitly added all of the API WG and Logging WG CPLs as reviewers to
that patch but feedback from all is welcome. You can find a more readable
version of patch set 4 at [2]. I see the id and “code” fields as the
connection point to what the logging working group is doing.

Thanks,
Everett

[1] https://wiki.openstack.org/wiki/API_Working_Group/Current_Design/Errors
[2]
http://docs-draft.openstack.org/93/167793/4/check/gate-api-wg-docs/e2f5b6e//doc/build/html/guidelines/errors.html

Re: [openstack-dev] [api][nova] Openstack HTTP error codes

2015-03-31 Thread Everett Toews

Top posting to continue the discussion in another thread.

[openstack-dev] [all] [api] Erring is Caring
http://lists.openstack.org/pipermail/openstack-dev/2015-March/060314.html

Everett


On Feb 4, 2015, at 10:29 AM, Duncan Thomas 
duncan.tho...@gmail.commailto:duncan.tho...@gmail.com wrote:

Ideally there would need to be a way to replicate 
errors.openstack.orghttp://errors.openstack.org/ and switch the url, for 
none-internet connected deployments, but TBH sites with that sort of 
requirement are used to weird breakages, so not a huge issue of it can't easily 
be done

On 3 February 2015 at 00:35, Jay Pipes 
jaypi...@gmail.commailto:jaypi...@gmail.com wrote:
On 01/29/2015 12:41 PM, Sean Dague wrote:
Correct. This actually came up at the Nova mid cycle in a side
conversation with Ironic and Neutron folks.

HTTP error codes are not sufficiently granular to describe what happens
when a REST service goes wrong, especially if it goes wrong in a way
that would let the client do something other than blindly try the same
request, or fail.

Having a standard json error payload would be really nice.

{
  fault: ComputeFeatureUnsupportedOnInstanceType,
  messsage: This compute feature is not supported on this kind of
instance type. If you need this feature please use a different instance
type. See your cloud provider for options.
}

That would let us surface more specific errors.
snip

Standardization here from the API WG would be really great.

What about having a separate HTTP header that indicates the OpenStack Error 
Code, along with a generated URI for finding more information about the error?

Something like:

X-OpenStack-Error-Code: 1234
X-OpenStack-Error-Help-URI: http://errors.openstack.org/1234

That way is completely backwards compatible (since we wouldn't be changing 
response payloads) and we could handle i18n entirely via the HTTP help service 
running on errors.openstack.orghttp://errors.openstack.org/.

Best,
-jay


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://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.orgmailto: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: [jclouds-site] Updated for 1.9.0 (#155)

2015-03-30 Thread Everett Toews

Merged and published.

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-site/pull/155#issuecomment-87833345

[jclouds-site] Updated for 1.9.0 (#155)

2015-03-27 Thread Everett Toews


You can view, comment on, or merge this pull request online at:

  https://github.com/jclouds/jclouds-site/pull/155

-- Commit Summary --

  * Updated for 1.9.0

-- File Changes --

M guides/openstack.md (20)

-- Patch Links --

https://github.com/jclouds/jclouds-site/pull/155.patch
https://github.com/jclouds/jclouds-site/pull/155.diff

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-site/pull/155

Re: [jclouds-labs] BlobStore API for Orion based back-ends (#45)

2015-03-26 Thread Everett Toews

I don't know the history of this PR but the fact that it's been open since Nov. 
30, 2013 is odd. 

@aledsage @demobox @andrewgaul Does it make sense to continue working on this?

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-labs/pull/45#issuecomment-86485058

Re: [openstack-dev] [API] Do we need to specify follow the HTTP RFCs?

2015-03-26 Thread Everett Toews

Top posting the relevant review https://review.openstack.org/#/c/161946/

Everett


On Feb 13, 2015, at 8:44 AM, michael mccune 
m...@redhat.commailto:m...@redhat.com wrote:

On 02/12/2015 02:20 PM, Ryan Brown wrote:
+1 I think the way to go would be:

We suggest (pretty please) that you comply with RFCs 7230-5 and if you
have any questions ask us. Also here are some examples of usage that
is/isn't RFC compliant for clarity


+1, i like the idea of pointing readers towards the RFCs but also providing 
examples.

mike

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.orgmailto: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: [VOTE] Release Apache jclouds 1.9.0 RC2

2015-03-25 Thread Everett Toews

+1 binding

Verified 1.9.0-rc2 with verify_jclouds_rc.sh [1]
SmokeTest ran with the PR [2]
ComputeService live tests on Rackspace 100% successful - run by Zack
BlobStore live tests on Rackspace 98% successful - run by Zack
  (when run with the PR [3] they’re 100% successful)

Thanks to everyone for the extra round of testing, fixing, and releasing.

Cheers,
Everett

[1] 
https://github.com/jclouds/jclouds/blob/master/scripts/release/verify_jclouds_rc.sh
[2] https://github.com/jclouds/jclouds-examples/pull/71
[3] https://github.com/jclouds/jclouds/pull/707


On Mar 24, 2015, at 9:33 AM, Ignasi Barrera n...@apache.org wrote:

 Hello,
 
 This is the second release candidate for Apache jclouds 1.9.0.
 
 Please use the separate [DISCUSS] thread for anything but votes.
 
 It fixes the following issues:
 https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12329006styleName=HtmlprojectId=12314430
 
 *** Please download, test and vote by Friday, March 27th, 03:00 PDT /
 06:00 EDT / 15:30 CET.
 
 Note that we are voting upon the source (tag), binaries are provided
 for convenience.
 
 Source and binary files:
 https://dist.apache.org/repos/dist/dev/jclouds/1.9.0-rc2/
 
 Maven staging repo:
 https://repository.apache.org/content/repositories/orgapachejclouds-1023
 
 The tags to be voted upon:
 - jclouds - 
 https://git-wip-us.apache.org/repos/asf?p=jclouds.git;a=tag;h=e0349061a2cc67390936fb6ba4c8ee5f4459ef6e
 (SHA-1: bb41ed43415c4c62085b7ff1d8e54eb9bba0b712)
 - jclouds-labs -
 https://git-wip-us.apache.org/repos/asf?p=jclouds-labs.git;a=tag;h=958dce9f45fd4ae87beef9841299a9ffc78f68bc
 (SHA-1: 1e238e64ba65817de889b31d850de43c6ad5deaa)
 - jclouds-labs-aws -
 https://git-wip-us.apache.org/repos/asf?p=jclouds-labs-aws.git;a=tag;h=508d29fdedb98b9e590f339d1de0137e7b80063e
 (SHA-1: 08e7d9bb83e4de35483ebebab034440f47f2b6c9)
 - jclouds-labs-google -
 https://git-wip-us.apache.org/repos/asf?p=jclouds-labs-google.git;a=tag;h=d48cd7bfd44926f4cce07a25c66344acd9e7da22
 (SHA-1: af716fc1029fce3506531d8cbede692fbc139928)
 - jclouds-labs-openstack -
 https://git-wip-us.apache.org/repos/asf?p=jclouds-labs-openstack.git;a=tag;h=deab53bcd46502beb1af9803cb212772ec5d5f88
 (SHA-1: c835aef051e219994da1f6554d37099b77deda57)
 - jclouds-karaf -
 https://git-wip-us.apache.org/repos/asf?p=jclouds-karaf.git;a=tag;h=f928069b84b5e7533ba0fb81a7e7c6ac818c18b7
 (SHA-1: 4c2d3c09b2c555f533413820d0b8e7751abff8f9)
 - jclouds-cli -
 https://git-wip-us.apache.org/repos/asf?p=jclouds-cli.git;a=tag;h=7a38090f03110a81537926ab0cad9bbd1458c37a
 (SHA-1: 74bde164ca17f456f636bb7d14dc4c8472ff725d)
 
 jclouds KEYS file containing PGP keys we use to sign the release:
 http://www.apache.org/dist/jclouds/KEYS
 
 [ ] +1
 [ ] 0  (explain why)
 [ ] -1 (explain why)

Re: [jclouds-labs] BlobStore API for Orion based back-ends (#45)

2015-03-24 Thread Everett Toews

Thanks for the pull request but it's release week in jclouds and that means 
it's time to clean up the PR queue. This PR will be over 6 months old as of 
April 1. If you intend to continue work on it, please make a comment by April 
2. Otherwise it will be closed on April 3.

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-labs/pull/45#issuecomment-85718559

Re: [jclouds] Support for OpenStack OS-Services API (#573)

2015-03-24 Thread Everett Toews

Thanks for the pull request but it's release week in jclouds and that means 
it's time to clean up the PR queue. This PR will be over 6 months old as of 
April 1. If you intend to continue work on it, please make a comment by April 
2. Otherwise it will be closed on April 3.

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/573#issuecomment-85716682

Re: [jclouds] JCLOUDS-670 Option force no password when launching images on providers (#486)

2015-03-24 Thread Everett Toews

Thanks for the pull request but it's release week in jclouds and that means 
it's time to clean up the PR queue. This PR will be over 6 months old as of 
April 1. If you intend to continue work on it, please make a comment by April 
2. Otherwise it will be closed on April 3.

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/486#issuecomment-85715089

Re: [jclouds] Add support for Azure Copy Blob (#514)

2015-03-24 Thread Everett Toews

Thanks for the pull request but it's release week in jclouds and that means 
it's time to clean up the PR queue. This PR will be over 6 months old as of 
April 1. If you intend to continue work on it, please make a comment by April 
2. Otherwise it will be closed on April 3.

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/514#issuecomment-85715395

Re: [jclouds] Introduce BlobstoreCli (#487)

2015-03-24 Thread Everett Toews

Thanks for the pull request but it's release week in jclouds and that means 
it's time to clean up the PR queue. This PR will be over 6 months old as of 
April 1. If you intend to continue work on it, please make a comment by April 
2. Otherwise it will be closed on April 3.

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/487#issuecomment-85715196

Re: [jclouds] JCLOUDS-642: InternalUrl fallback (#462)

2015-03-24 Thread Everett Toews

Thanks for the pull request but it's release week in jclouds and that means 
it's time to clean up the PR queue. This PR will be over 6 months old as of 
April 1. If you intend to continue work on it, please make a comment by April 
2. Otherwise it will be closed on April 3.

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/462#issuecomment-85714738

Re: [jclouds] Token based authentication in openstack-keystone (#433)

2015-03-24 Thread Everett Toews

Thanks for the pull request but it's release week in jclouds and that means 
it's time to clean up the PR queue. This PR will be over 6 months old as of 
April 1. If you intend to continue work on it, please make a comment by April 
2. Otherwise it will be closed on April 3.

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/433#issuecomment-85714569

Re: [jclouds-examples] Add an example to create/delete/list Google Cloud Storage buckets. (#64)

2015-03-24 Thread Everett Toews

Thanks for the pull request but it's release week in jclouds and that means 
it's time to clean up the PR queue. This PR will be over 6 months old as of 
April 1. If you intend to continue work on it, please make a comment by April 
2. Otherwise it will be closed on April 3.

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-examples/pull/64#issuecomment-85717886

Re: [jclouds-examples] GCS-Example initial commit (#66)

2015-03-24 Thread Everett Toews

Thanks for the pull request but it's release week in jclouds and that means 
it's time to clean up the PR queue. This PR will be over 6 months old as of 
April 1. If you intend to continue work on it, please make a comment by April 
2. Otherwise it will be closed on April 3.

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-examples/pull/66#issuecomment-85717959

Re: [jclouds-labs-openstack] OS Ceilometer API support (#166)

2015-03-24 Thread Everett Toews

Thanks for the pull request but it's release week in jclouds and that means 
it's time to clean up the PR queue. This PR will be over 6 months old as of 
April 1. If you intend to continue work on it, please make a comment by April 
2. Otherwise it will be closed on April 3.

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-labs-openstack/pull/166#issuecomment-85718143

Re: [jclouds-examples] Simplify interface of Google examples and fix the name and comment of userName variable (#63)

2015-03-24 Thread Everett Toews

@demobox Can this be closed?

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-examples/pull/63#issuecomment-85717848

Re: [jclouds-site] Update compute.md (#131)

2015-03-24 Thread Everett Toews

Merged.

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-site/pull/131#issuecomment-85720599

Re: [jclouds] Add copyBlob to portable abstraction and add S3-optimized variant (#511)

2015-03-24 Thread Everett Toews

Thanks for the pull request but it's release week in jclouds and that means 
it's time to clean up the PR queue. This PR will be over 6 months old as of 
April 1. If you intend to continue work on it, please make a comment by April 
2. Otherwise it will be closed on April 3.

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/511#issuecomment-85715297

Re: [jclouds] Updated the requests in unit test case to include globalIdentifier (#531)

2015-03-24 Thread Everett Toews

Thanks for the pull request but it's release week in jclouds and that means 
it's time to clean up the PR queue. This PR will be over 6 months old as of 
April 1. If you intend to continue work on it, please make a comment by April 
2. Otherwise it will be closed on April 3.

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/531#issuecomment-85715651

Re: [jclouds] Throw sane error if one of security groups is null (#515)

2015-03-24 Thread Everett Toews

Thanks for the pull request but it's release week in jclouds and that means 
it's time to clean up the PR queue. This PR will be over 6 months old as of 
April 1. If you intend to continue work on it, please make a comment by April 
2. Otherwise it will be closed on April 3.

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/515#issuecomment-85715464

Re: [jclouds-site] Update compute.md (#130)

2015-03-24 Thread Everett Toews

Thanks for the pull request but it's release week in jclouds and that means 
it's time to clean up the PR queue. This PR will be over 6 months old as of 
April 1. If you intend to continue work on it, please make a comment by April 
2. Otherwise it will be closed on April 3.

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-site/pull/130#issuecomment-85719600

Re: [jclouds-site] Update aws.md (#129)

2015-03-24 Thread Everett Toews

Thanks for the pull request but it's release week in jclouds and that means 
it's time to clean up the PR queue. This PR will be over 6 months old as of 
April 1. If you intend to continue work on it, please make a comment by April 
2. Otherwise it will be closed on April 3.

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-site/pull/129#issuecomment-85719557

Re: [jclouds-site] add softlayer getting started (#134)

2015-03-24 Thread Everett Toews

Thanks for the pull request but it's release week in jclouds and that means 
it's time to clean up the PR queue. This PR will be over 6 months old as of 
April 1. If you intend to continue work on it, please make a comment by April 
2. Otherwise it will be closed on April 3.

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-site/pull/134#issuecomment-85720981

Re: [jclouds] Expecting 2 of 3 or the first flaky test to succeed (#577)

2015-03-24 Thread Everett Toews

Thanks for the pull request but it's release week in jclouds and that means 
it's time to clean up the PR queue. This PR will be over 6 months old as of 
April 1. If you intend to continue work on it, please make a comment by April 
2. Otherwise it will be closed on April 3.

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/577#issuecomment-85717259

Re: [jclouds] Import rackspace-cloudfiles from labs (#565)

2015-03-24 Thread Everett Toews

Superseded by #705  

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/565#issuecomment-85716224

Re: [jclouds-examples] Add layer 7 load balancer examples. (#61)

2015-03-24 Thread Everett Toews

Thanks for the pull request but it's release week in jclouds and that means 
it's time to clean up the PR queue. This PR will be over 6 months old as of 
April 1. If you intend to continue work on it, please make a comment by April 
2. Otherwise it will be closed on April 3.

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-examples/pull/61#issuecomment-85717726

Re: [jclouds-karaf] JCLOUDS-85: Improving the creation of instance of PropertyShellTableFact... (#18)

2015-03-24 Thread Everett Toews

Thanks for the pull request but it's release week in jclouds and that means 
it's time to clean up the PR queue. This PR will be over 6 months old as of 
April 1. If you intend to continue work on it, please make a comment by April 
2. Otherwise it will be closed on April 3.

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-karaf/pull/18#issuecomment-85718822

Re: [jclouds] JCLOUDS-599 ability to execute function locally before initScript runs. (#406)

2015-03-24 Thread Everett Toews

Thanks for the pull request but it's release week in jclouds and that means 
it's time to clean up the PR queue. This PR will be over 6 months old as of 
April 1. If you intend to continue work on it, please make a comment by April 
2. Otherwise it will be closed on April 3.

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/406#issuecomment-85714023

Re: [jclouds-labs] JCLOUDS-664: Implemented Role represenstaion in API (#118)

2015-03-24 Thread Everett Toews

Thanks for the pull request but it's release week in jclouds and that means 
it's time to clean up the PR queue. This PR will be over 6 months old as of 
April 1. If you intend to continue work on it, please make a comment by April 
2. Otherwise it will be closed on April 3.

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-labs/pull/118#issuecomment-85718608

Re: [jclouds-labs-aws] JCLOUDS-750: Refactor glacier domain classes using @AutoValue (#64)

2015-03-24 Thread Everett Toews

Thanks for the pull request but it's release week in jclouds and that means 
it's time to clean up the PR queue. This PR will be over 6 months old as of 
April 1. If you intend to continue work on it, please make a comment by April 
2. Otherwise it will be closed on April 3.

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-labs-aws/pull/64#issuecomment-85718421

1 2 3 4 5 6 7 8 9 10 >

1 - 100 of 1710 matches

Mail list logo