Re: [openstack-dev] [neutron][neutron-release] feature/graphql branch rebase

[Gilles Dubreuil]

On 10/11/18 12:03 am, Jeremy Stanley wrote:

On 2018-11-09 16:35:22 +1100 (+1100), Gilles Dubreuil wrote:

Could you please provide permission [1] to upload commit merges?

I'm getting the following error after merging HEAD:

$ git review -R feature/graphql
remote:
remote: Processing changes: refs: 1
remote: Processing changes: refs: 1, done
To ssh://review.openstack.org:29418/openstack/neutron.git
  ! [remote rejected]   HEAD -> refs/publish/feature/graphql/bug/1802101
(you are not allowed to upload merges)
error: failed to push some refs to
'ssh://q-1ille...@review.openstack.org:29418/openstack/neutron.git'

[...]

Per openstack/neutron's ACL[*] you need to be made a member of the
neutron-release group in Gerrit[**]. (This permission is tightly
controlled to avoid people accidentally pushing merge commits, which
is all too easy if you're not careful to keep your branches clean.)


That's fair enough.

I'll ask the neutron-release group then.

Thanks



[*] 
https://git.openstack.org/cgit/openstack-infra/project-config/tree/gerrit/acls/openstack/neutron.config
[**] https://review.openstack.org/#/admin/groups/neutron-release

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


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

Re: [openstack-dev] [neutron][neutron-release] feature/graphql branch rebase

[Gilles Dubreuil]

Hi Miguel,

Could you please provide permission [1] to upload commit merges?

I'm getting the following error after merging HEAD:

$ git review -R feature/graphql
remote:
remote: Processing changes: refs: 1
remote: Processing changes: refs: 1, done
To ssh://review.openstack.org:29418/openstack/neutron.git
 ! [remote rejected]   HEAD -> 
refs/publish/feature/graphql/bug/1802101 (you are not allowed to upload 
merges)
error: failed to push some refs to 
'ssh://q-1ille...@review.openstack.org:29418/openstack/neutron.git'


Thanks,
Gilles

[1] 
https://github.com/openstack-infra/gerrit/blob/master/Documentation/error-not-allowed-to-upload-merges.txt



On 23/10/18 7:30 pm, Gilles Dubreuil wrote:


Hi Miguel,

Thank you for your help.

I'll use those precious instructions next time.

Cheers,
Gilles

On 16/10/18 1:32 am, Miguel Lavalle wrote:

Hi Gilles,

The merge of master into feature/graphql  has been approved: 
https://review.openstack.org/#/c/609455. In the future, you can 
create your own merge patch following the instructions here: 
https://docs.openstack.org/infra/manual/drivers.html#merge-master-into-feature-branch. 
The Neutron team will catch it in Gerrit and review it


Regards

Miguel

On Thu, Oct 4, 2018 at 11:44 PM Gilles Dubreuil <mailto:gdubr...@redhat.com>> wrote:


Hey Neutron folks,

I'm just reiterating the request.

Thanks


On 20/06/18 11:34, Gilles Dubreuil wrote:
> Could someone from the Neutron release group rebase
feature/graphql
> branch against master/HEAD branch please?
>
> Regards,
> Gilles
>
>


--
Gilles Dubreuil
Senior Software Engineer - Red Hat - Openstack DFG Integration
Email:gil...@redhat.com
GitHub/IRC: gildub
Mobile: +61 400 894 219


--
Gilles Dubreuil
Senior Software Engineer - Red Hat - Openstack DFG Integration
Email: gil...@redhat.com
GitHub/IRC: gildub
Mobile: +61 400 894 219

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

Re: [openstack-dev] [neutron][neutron-release] feature/graphql branch rebase

[Gilles Dubreuil]

Hi Miguel,

Thank you for your help.

I'll use those precious instructions next time.

Cheers,
Gilles

On 16/10/18 1:32 am, Miguel Lavalle wrote:

Hi Gilles,

The merge of master into feature/graphql  has been approved: 
https://review.openstack.org/#/c/609455. In the future, you can create 
your own merge patch following the instructions here: 
https://docs.openstack.org/infra/manual/drivers.html#merge-master-into-feature-branch. 
The Neutron team will catch it in Gerrit and review it


Regards

Miguel

On Thu, Oct 4, 2018 at 11:44 PM Gilles Dubreuil <mailto:gdubr...@redhat.com>> wrote:


Hey Neutron folks,

I'm just reiterating the request.

Thanks


On 20/06/18 11:34, Gilles Dubreuil wrote:
> Could someone from the Neutron release group rebase feature/graphql
> branch against master/HEAD branch please?
>
> Regards,
> Gilles
>
>


--
Gilles Dubreuil
Senior Software Engineer - Red Hat - Openstack DFG Integration
Email: gil...@redhat.com
GitHub/IRC: gildub
Mobile: +61 400 894 219

__
OpenStack Development Mailing 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] Open API 3.0 for OpenStack API

[Gilles Dubreuil]

On 11/10/18 00:18, Jeremy Stanley wrote:

On 2018-10-10 13:24:28 +1100 (+1100), Gilles Dubreuil wrote:

On 09/10/18 23:58, Jeremy Stanley wrote:

On 2018-10-09 08:52:52 -0400 (-0400), Jim Rollenhagen wrote:
[...]

It seems to me that a major goal of openstacksdk is to hide
differences between clouds from the user. If the user is meant
to use a GraphQL library themselves, we lose this and the user
needs to figure it out themselves. Did I understand that
correctly?

This is especially useful where the SDK implements business
logic for common operations like "if the user requested A and
the cloud supports features B+C+D then use those to fulfil the
request, otherwise fall back to using features E+F".

The features offered to the user don't have to change, it's just a
different architecture.

The user doesn't have to deal with a GraphQL library, only the
client applications (consuming OpenStack APIs). And there are also
UI tools such as GraphiQL which allow to interact directly with
GraphQL servers.

My point was simply that SDKs provide more than a simple translation
of network API calls and feature discovery. There can also be rather
a lot of "business logic" orchestrating multiple primitive API calls
to reach some more complex outcome. The services don't want to embed
this orchestrated business logic themselves, and it makes little
sense to replicate the same algorithms in every single application
which wants to make use of such composite functionality. There are
common actions an application might wish to take which involve
speaking to multiple APIs for different services to make specific
calls in a particular order, perhaps feeding the results of one into
the next.

Can you explain how GraphQL eliminates the above reasons for an SDK?


What I meant is the communication part of any SDK interfacing between 
clients and API services can be handled by GraphQL client librairies.
So instead of having to rely on modules (imported or native) to carry 
the REST communications, we're dealing with data provided by GraphQL 
libraries (which are also modules but standardized as GraphQL is a 
specification).
So as you mentioned there is still need to provide the data wrap in 
objects or any adequate struct to present to the consumers.


Having a Schema helps both API and clients developers because the data 
is clearly typed and graphed. Backend devs can focus on resolving the 
data for each node/leaf while the clients can focus on what they need 
and not how to get it.


To relate to $subject, by building the data model (graph) we obtain a 
schema and introspection. That's a big saver in term of resources.







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


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

Re: [openstack-dev] [api] Open API 3.0 for OpenStack API

[Gilles Dubreuil]

On 09/10/18 23:58, Jeremy Stanley wrote:

On 2018-10-09 08:52:52 -0400 (-0400), Jim Rollenhagen wrote:
[...]

It seems to me that a major goal of openstacksdk is to hide differences
between clouds from the user. If the user is meant to use a GraphQL library
themselves, we lose this and the user needs to figure it out themselves.
Did I understand that correctly?

This is especially useful where the SDK implements business logic
for common operations like "if the user requested A and the cloud
supports features B+C+D then use those to fulfil the request,
otherwise fall back to using features E+F".



The features offered to the user don't have to change, it's just a 
different architecture.


The user doesn't have to deal with a GraphQL library, only the client 
applications (consuming OpenStack APIs).
And there are also UI tools such as GraphiQL which allow to interact 
directly with GraphQL servers.



__
OpenStack Development Mailing 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] Open API 3.0 for OpenStack API

[Gilles Dubreuil]

On 05/10/18 21:54, Jim Rollenhagen wrote:
GraphQL has introspection features that allow clients to pull the 
schema (types, queries, mutations, etc): 
https://graphql.org/learn/introspection/


That said, it seems like using this in a client like OpenStackSDK 
would get messy quickly. Instead of asking for which versions are 
supported, you'd have to fetch the schema, map it to actual features 
somehow, and adjust queries based on this info.




A main difference in software architecture when using GraphQL is that a 
client makes use of a GraphQL client library instead of relaying on a SDK.



I guess there might be a middleground where we could fetch the REST 
API version, and know from that what GraphQL queries can be made.


// jim



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

Re: [openstack-dev] [api] Open API 3.0 for OpenStack API

[Gilles Dubreuil]

Hi Edison,

Sorry for the delay.

Please see inline...

Cheers,
Gilles

On 07/09/18 12:03, Edison Xiang wrote:

Hey gilles,

Thanks your introduction for GraphQL and Relay.

> GraphQL and OpenAPI have a different feature scope and both have pros and 
cons.

I totally agree with you. They can work together.
Right now, I think we have no more work to adapt OpenStack APIs for 
Open API.
Firstly we could sort out Open API schemas base on the current 
OpenStack APIs.

and then we can discuss how to use it.


I think a big question is going to be about the effort required to bring 
OpenStack API to be Open API v3.0 compliant.
This is challenging because the various projects involved and the need 
to validate a new solution across all the projects.
The best approach is likely to first demonstrate a new solution is 
viable and then eventually bring it to be accepted globally.
Also because we don't have unlimited resources, I doubt we're going to 
be able to bring both Open API and GraphQL to the table(s).


There no doubts how OpenStack APIs can benefit from features such as 
schema definitions, self documentation and better performance especially 
if they are built-in or derived from a standard.
Meanwhile a practical example shows those features in action (for the 
skeptical) but also demonstrate how to do it which clarify the effort 
involved along with pros and cons.I want to make clear that I'm not 
against OpenAPI, I was actually keen to get it on board because of the 
benefits


And it will also helps compare solutions (Open API, GraphQL).

So, what do you think about an Open API proof of concept with Neutron?


About the micro version, we discuss with your team mate dmitry in 
another email [1]


Obviously micro version is a point of contention.
My take on this is because consuming them has been proven harder than 
developing them.

The beauty of GraphQL is that there is no need to deal with version at all.
New fields appears when needed and old one are marked deprecated.




[1] 
http://lists.openstack.org/pipermail/openstack-dev/2018-September/134202.html


Best Regards,
Edison Xiang

On Tue, Sep 4, 2018 at 8:37 AM Gilles Dubreuil <mailto:gdubr...@redhat.com>> wrote:




On 30/08/18 13:56, Edison Xiang wrote:

Hi Ed Leafe,

Thanks your reply.
Open API defines a standard interface description for REST APIs.
Open API 3.0 can make a description(schema) for current OpenStack
REST API.
It will not change current OpenStack API.
I am not a GraphQL expert. I look up something about GraphQL.
In my understanding, GraphQL will get current OpenAPI together
and provide another APIs based on Relay,


Not sure what you mean here, could you please develop?



and Open API is used to describe REST APIs and GraphQL is used to
describe Relay APIs.


There is no such thing as "Relay APIs".
GraphQL povides a de-facto API Schema and Relay provides
extensions on top to facilitate re-fetching, paging and more.
GraphQL and OpenAPI have a different feature scope and both have
pros and cons.
GraphQL is delivering API without using REST verbs as all requests
are undone using POST and its data.
Beyond that what would be great (and it will ultimately come) is
to have both of them working together.

The idea of the GraphQL Proof of Concept is see what it can bring
and at what cost such as effort and trade-offs.
And to compare this against the effort to adapt OpenStack APIs to
use Open API.

BTW what's the status of Open API 3.0 in regards of Microversion?

Regards,
Gilles



Best Regards,
Edison Xiang

On Wed, Aug 29, 2018 at 9:33 PM Ed Leafe mailto:e...@leafe.com>> wrote:

On Aug 29, 2018, at 1:36 AM, Edison Xiang
mailto:xiang.edi...@gmail.com>> wrote:
>
> As we know, Open API 3.0 was released on July, 2017, it is
about one year ago.
> Open API 3.0 support some new features like anyof, oneof
and allof than Open API 2.0(Swagger 2.0).
> Now OpenStack projects do not support Open API.
> Also I found some old emails in the Mail List about
supporting Open API 2.0 in OpenStack.

There is currently an effort by some developers to
investigate the possibility of using GraphQL with OpenStack
APIs. What would Open API 3.0 provide that GraphQL would not?
I’m asking because I don’t know enough about Open API to
compare them.


-- Ed Leafe







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

Re: [openstack-dev] [neutron][neutron-release] feature/graphql branch rebase

[Gilles Dubreuil]

Hey Neutron folks,

I'm just reiterating the request.

Thanks


On 20/06/18 11:34, Gilles Dubreuil wrote:
Could someone from the Neutron release group rebase feature/graphql 
branch against master/HEAD branch please?


Regards,
Gilles





__
OpenStack Development Mailing 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] Open API 3.0 for OpenStack API

[Gilles Dubreuil]

On 30/08/18 13:56, Edison Xiang wrote:

Hi Ed Leafe,

Thanks your reply.
Open API defines a standard interface description for REST APIs.
Open API 3.0 can make a description(schema) for current OpenStack REST 
API.

It will not change current OpenStack API.
I am not a GraphQL expert. I look up something about GraphQL.
In my understanding, GraphQL will get current OpenAPI together and 
provide another APIs based on Relay,


Not sure what you mean here, could you please develop?


and Open API is used to describe REST APIs and GraphQL is used to 
describe Relay APIs.


There is no such thing as "Relay APIs".
GraphQL povides a de-facto API Schema and Relay provides extensions on 
top to facilitate re-fetching, paging and more.
GraphQL and OpenAPI have a different feature scope and both have pros 
and cons.
GraphQL is delivering API without using REST verbs as all requests are 
undone using POST and its data.
Beyond that what would be great (and it will ultimately come) is to have 
both of them working together.


The idea of the GraphQL Proof of Concept is see what it can bring and at 
what cost such as effort and trade-offs.
And to compare this against the effort to adapt OpenStack APIs to use 
Open API.


BTW what's the status of Open API 3.0 in regards of Microversion?

Regards,
Gilles



Best Regards,
Edison Xiang

On Wed, Aug 29, 2018 at 9:33 PM Ed Leafe <mailto:e...@leafe.com>> wrote:


On Aug 29, 2018, at 1:36 AM, Edison Xiang mailto:xiang.edi...@gmail.com>> wrote:
>
> As we know, Open API 3.0 was released on July, 2017, it is about
one year ago.
> Open API 3.0 support some new features like anyof, oneof and
allof than Open API 2.0(Swagger 2.0).
> Now OpenStack projects do not support Open API.
> Also I found some old emails in the Mail List about supporting
Open API 2.0 in OpenStack.

There is currently an effort by some developers to investigate the
possibility of using GraphQL with OpenStack APIs. What would Open
API 3.0 provide that GraphQL would not? I’m asking because I don’t
know enough about Open API to compare them.


-- Ed Leafe






__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
<http://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


--
Gilles Dubreuil
Senior Software Engineer - Red Hat - Openstack DFG Integration
Email: gil...@redhat.com
GitHub/IRC: gildub
Mobile: +61 400 894 219

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

Re: [openstack-dev] [neutron][api][grapql] Proof of Concept

[Gilles Dubreuil]

On 24/08/18 04:58, Slawomir Kaplonski wrote:

Hi Miguel,

I’m not sure but maybe You were looking for those patches:

https://review.openstack.org/#/q/project:openstack/neutron+branch:feature/graphql



Yes that's the one, it's under Tristan Cacqueray name as he helped 
getting started.



Wiadomość napisana przez Miguel Lavalle  w dniu 
23.08.2018, o godz. 18:57:

Hi Gilles,

Ed pinged me earlier today in IRC in regards to this topic. After reading your 
message, I assumed that you had patches up for review in Gerrit. I looked for 
them, with the intent to list them in the agenda of the next Neutron team 
meeting, to draw attention to them. I couldn't find any, though: 
https://review.openstack.org/#/q/owner:%22Gilles+Dubreuil+%253Cgdubreui%2540redhat.com%253E%22

So, how can we help? This is our meetings schedule: 
http://eavesdrop.openstack.org/#Neutron_Team_Meeting. Given that you are Down 
Under at UTC+10, the most convenient meeting for you is the one on Monday (even 
weeks), which would be Tuesday at 7am for you. Please note that we have an on 
demand section in our agenda: 
https://wiki.openstack.org/wiki/Network/Meetings#On_Demand_Agenda. Feel free to 
add topics in that section when you have something to discuss with the Neutron 
team.


Now that we have a working base API serving GraphQL requests we need to 
do provide the data in respect of Oslo Policy and such.


Thanks for the pointers, I'll add the latter to the Agenda and will be 
at next meeting.





Best regards

Miguel

On Sun, Aug 19, 2018 at 10:57 PM, Gilles Dubreuil  wrote:


On 25/07/18 23:48, Ed Leafe wrote:
On Jun 6, 2018, at 7:35 PM, Gilles Dubreuil  wrote:
The branch is now available under feature/graphql on the neutron core 
repository [1].
I wanted to follow up with you on this effort. I haven’t seen any activity on 
StoryBoard for several weeks now, and wanted to be sure that there was nothing 
blocking you that we could help with.


-- Ed Leafe



Hi Ed,

Thanks for following up.

There has been 2 essential counterproductive factors to the effort.

The first is that I've been busy attending issues on other part of my job.
The second one is the lack of response/follow-up from the Neutron core team.

We have all the plumbing in place but we need to layer the data through oslo 
policies.

Cheers,
Gilles


__
OpenStack Development Mailing 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

—
Slawek Kaplonski
Senior software engineer
Red Hat


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


--
Gilles Dubreuil
Senior Software Engineer - Red Hat - Openstack DFG Integration
Email: gil...@redhat.com
GitHub/IRC: gildub
Mobile: +61 400 894 219


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

Re: [openstack-dev] [neutron][api][grapql] Proof of Concept

[Gilles Dubreuil]

On 25/07/18 23:48, Ed Leafe wrote:

On Jun 6, 2018, at 7:35 PM, Gilles Dubreuil  wrote:

The branch is now available under feature/graphql on the neutron core 
repository [1].

I wanted to follow up with you on this effort. I haven’t seen any activity on 
StoryBoard for several weeks now, and wanted to be sure that there was nothing 
blocking you that we could help with.


-- Ed Leafe




Hi Ed,

Thanks for following up.

There has been 2 essential counterproductive factors to the effort.

The first is that I've been busy attending issues on other part of my job.
The second one is the lack of response/follow-up from the Neutron core team.

We have all the plumbing in place but we need to layer the data through 
oslo policies.


Cheers,
Gilles

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

Re: [openstack-dev] [neutron][graphql] PoC with Oslo integration

[Gilles Dubreuil]

Hi,

We're going to reschedule this one.

Sorry for the inconvenience.

Regards,
Gilles


On 02/07/18 15:17, Gilles Dubreuil wrote:

Hi,

We now have an initial base for using GraphQL [1] as you can see from 
[2].

What we need now is too use Oslo properly to police the requests.

The best way to achieve that would likely to use a similar approach as 
the pecan hooks which are in place for v2.0.
Ultimately some of the code could be share between v2.0 and graphql 
but that's not a goal or either a priority for now.


We need Neutron developers to help with the design and to get this 
moving in the right direction.


I'm scheduling an on-line working session for next week (using either 
BlueJeans or Google Hangouts)?
Please vote on doodle [2] on the best time for you (please understand 
that we have to cover all time zones).


Thanks,
Gilles

[1] https://storyboard.openstack.org/#!/story/2002782
[2] https://review.openstack.org/#/c/575898/
[3] https://doodle.com/poll/43kx8nfpe6w6pvia



--
Gilles Dubreuil
Senior Software Engineer - Red Hat - Openstack DFG Integration
Email: gil...@redhat.com
GitHub/IRC: gildub
Mobile: +61 400 894 219


__
OpenStack Development Mailing 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] [neutron][graphql] PoC with Oslo integration

[Gilles Dubreuil]

Hi,

We now have an initial base for using GraphQL [1] as you can see from [2].
What we need now is too use Oslo properly to police the requests.

The best way to achieve that would likely to use a similar approach as 
the pecan hooks which are in place for v2.0.
Ultimately some of the code could be share between v2.0 and graphql but 
that's not a goal or either a priority for now.


We need Neutron developers to help with the design and to get this 
moving in the right direction.


I'm scheduling an on-line working session for next week (using either 
BlueJeans or Google Hangouts)?
Please vote on doodle [2] on the best time for you (please understand 
that we have to cover all time zones).


Thanks,
Gilles

[1] https://storyboard.openstack.org/#!/story/2002782
[2] https://review.openstack.org/#/c/575898/
[3] https://doodle.com/poll/43kx8nfpe6w6pvia


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

Re: [openstack-dev] [neutron][api[[graphql] A starting point

[Gilles Dubreuil]

Great, thanks to the API SIG!


On 23/06/18 06:53, Flint WALRUS wrote:
Oh! That’s its truly a sweet sweet attention, that will indeed really 
help us to focus on what we have to do without having to goes through 
an extensive email back and forth :-)


Thanks a lot!!
Le ven. 22 juin 2018 à 22:48, Ed Leafe <mailto:e...@leafe.com>> a écrit :


On Jun 15, 2018, at 5:42 PM, Gilles Dubreuil mailto:gdubr...@redhat.com>> wrote:
>
> This initial patch [1]  allows to retrieve networks, subnets.
>
> This is very easy, thanks to the graphene-sqlalchemy helper.
>
> The edges, nodes layer might be confusing at first meanwhile
they make the Schema Relay-compliant in order to offer
re-fetching, pagination features out of the box.
>
> The next priority is to set the unit test in order to implement
mutations.
>
> Could someone help provide a base in order to respect Neutron
test requirements?

Glad to see some progress!

We have migrated the API-SIG from Launchpad to StoryBoard [0],
specifically so that your group has a place to record stories,
tasks, etc. Please feel free to use this to help coordinated your
work.

[0] https://storyboard.openstack.org/#!/project/1039
<https://storyboard.openstack.org/#%21/project/1039>


-- Ed Leafe






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



--
Gilles Dubreuil
Senior Software Engineer - Red Hat - Openstack DFG Integration
Email: gil...@redhat.com
GitHub/IRC: gildub
Mobile: +61 400 894 219

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

Re: [openstack-dev] [neutron][api[[graphql] A starting point

[Gilles Dubreuil]

On 22/06/18 15:57, Flint WALRUS wrote:

Hi everyone,

Thanks for the updates and support, that appreciated.

@Gilles, did you already implemented all the service types?


We have query types for networks and subnets for now.
Before we add more we are going to focus on oslo policies so we can 
access and modify those items in respect of the existing security approach.

Then we will have a solid foundation to add more types.



What is left to do? You already want to merge the feature branch with 
master?


The feature branch graphql is the Proof of Concept and won't be merged 
to master until we have it full ready to share/demonstrate it to others.
So we're pushing patches against that branch. The initial one to be 
hopefully merged soon.




@tristan I’d like to work on the feature branch but I’ll wait for 
gilles answers as I don’t want to mess up having pieces of code 
everywhere.


Thanks!
Le ven. 22 juin 2018 à 06:44, Gilles Dubreuil <mailto:gdubr...@redhat.com>> a écrit :



On 22/06/18 09:21, Tristan Cacqueray wrote:

Hi Flint,

On June 21, 2018 5:32 pm, Flint WALRUS wrote:

Hi everyone, sorry for the late answer but I’m currently trapped
into a
cluster issue with cinder-volume that doesn’t give me that much
time.

That being said, I’ll have some times to work on this feature
during the
summer (July/August) and so do some coding once I’ll have
catched up with
your work.


That's great to hear! The next step is to understand how to deal
with
oslo policy and control objects access/modification.


Did you created a specific tree or did you created a new graphql
folder
within the neutron/neutron/api/ path regarding the schemas etc?


There is a feature/graphql branch were an initial patch[1] adds a
new
neutron/api/graphql directory as well as a new test_graphql.py
functional tests.
The api-paste is also updated to expose the '/graphql' http
endpoint.

Not sure if we want to keep on updating that change, or propose
further
code as new change on top of this skeleton?



Makes sense to merge it, I think we have the base we needed to get
going.
I'll make it green so we can get merge it.



Regards,
-Tristan



Le sam. 16 juin 2018 à 08:42, Tristan Cacqueray
 <mailto:tdeca...@redhat.com> a
écrit :


On June 15, 2018 10:42 pm, Gilles Dubreuil wrote:
> Hello,
>
> This initial patch [1]  allows to retrieve networks, subnets.
>
> This is very easy, thanks to the graphene-sqlalchemy helper.
>
> The edges, nodes layer might be confusing at first meanwhile
they make
> the Schema Relay-compliant in order to offer re-fetching,
pagination
> features out of the box.
>
> The next priority is to set the unit test in order to implement
mutations.
>
> Could someone help provide a base in order to respect Neutron
test
> requirements?
>
>
> [1] [abandoned]

Actually, the correct review (proposed on the feature/graphql
branch)
is:

[1] https://review.openstack.org/575898

>
> Thanks,
> Gilles
>
>
__

> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
<mailto: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
<mailto: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
<mailto: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
<mailto:openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


-- 
Gilles Dubreuil

Senior Software Engineer - Red Hat - Openstack DFG 

Re: [openstack-dev] [neutron][api[[graphql] A starting point

[Gilles Dubreuil]

On 22/06/18 09:21, Tristan Cacqueray wrote:

Hi Flint,

On June 21, 2018 5:32 pm, Flint WALRUS wrote:

Hi everyone, sorry for the late answer but I’m currently trapped into a
cluster issue with cinder-volume that doesn’t give me that much time.

That being said, I’ll have some times to work on this feature during the
summer (July/August) and so do some coding once I’ll have catched up 
with

your work.


That's great to hear! The next step is to understand how to deal with
oslo policy and control objects access/modification.


Did you created a specific tree or did you created a new graphql folder
within the neutron/neutron/api/ path regarding the schemas etc?


There is a feature/graphql branch were an initial patch[1] adds a new
neutron/api/graphql directory as well as a new test_graphql.py
functional tests.
The api-paste is also updated to expose the '/graphql' http endpoint.

Not sure if we want to keep on updating that change, or propose further
code as new change on top of this skeleton?



Makes sense to merge it, I think we have the base we needed to get going.
I'll make it green so we can get merge it.



Regards,
-Tristan



Le sam. 16 juin 2018 à 08:42, Tristan Cacqueray  a
écrit :


On June 15, 2018 10:42 pm, Gilles Dubreuil wrote:
> Hello,
>
> This initial patch [1]  allows to retrieve networks, subnets.
>
> This is very easy, thanks to the graphene-sqlalchemy helper.
>
> The edges, nodes layer might be confusing at first meanwhile they 
make

> the Schema Relay-compliant in order to offer re-fetching, pagination
> features out of the box.
>
> The next priority is to set the unit test in order to implement
mutations.
>
> Could someone help provide a base in order to respect Neutron test
> requirements?
>
>
> [1] [abandoned]

Actually, the correct review (proposed on the feature/graphql branch)
is:

[1] https://review.openstack.org/575898

>
> Thanks,
> Gilles
>
>
__ 


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


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__ 


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




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


--
Gilles Dubreuil
Senior Software Engineer - Red Hat - Openstack DFG Integration
Email: gil...@redhat.com
GitHub/IRC: gildub
Mobile: +61 400 894 219

__
OpenStack Development Mailing 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] Puppet debugging help?

[Gilles Dubreuil]

On 19/06/18 01:59, Alex Schultz wrote:

On Mon, Jun 18, 2018 at 9:13 AM, Lars Kellogg-Stedman  wrote:

Hey folks,

I'm trying to patch puppet-keystone to support multi-valued
configuration options (like trusted_dashboard).  I have a patch that
works, mostly, but I've run into a frustrating problem (frustrating
because it would seem to be orthogonal to my patches, which affect the
keystone_config provider and type).

During the initial deploy, running tripleo::profile::base::keystone
fails with:

   "Error: Could not set 'present' on ensure: undefined method `new'
   for nil:NilClass at
   /etc/puppet/modules/tripleo/manifests/profile/base/keystone.pp:274",


It's likely erroring in the keystone_domain provider.

https://github.com/openstack/puppet-keystone/blob/master/lib/puppet/provider/keystone_domain/openstack.rb#L115-L122
or
https://github.com/openstack/puppet-keystone/blob/master/lib/puppet/provider/keystone_domain/openstack.rb#L155-L161

Providers are notoriously bad at their error messaging.   Usually this
error happens when we get a null back from the underlying command and
we're still trying to do something.  This could point to a
misconfiguration of keystone if it's not getting anything back.


Per Alex comment, the keystone_domain class is definitely involved.

The provider fails: "Could not set 'present' on ensure"
And the propagated error seems to be because the provider could not be 
set up for some dependent reason and came back empty.


$ irb
irb(main):001:0> nil.new
NoMethodError: undefined method `new' for nil:NilClass

The second pass worked because the missing "dependent" bit was set up 
(in the meantime) and the provider creation was satisfied.


To investigate dependent cause within the provider, you could use 
'notice("Value: ${variable}")'




The line in question is:

   70: if $step == 3 and $manage_domain {
   71:   if hiera('heat_engine_enabled', false) {
   72: # create these seperate and don't use ::heat::keystone::domain since
   73: # that class writes out the configs
   74: keystone_domain { $heat_admin_domain:
 ensure  => 'present',
 enabled => true
   }

The thing is, despite the error...it creates the keystone domain
*anyway*, and a subsequent run of the module will complete without any
errors.

I'm not entirely sure that the error is telling me, since *none* of
the puppet types or providers have a "new" method as far as I can see.
Any pointers you can offer would be appreciated.

Thanks!

--
Lars Kellogg-Stedman  | larsks @ {irc,twitter,github}
http://blog.oddbit.com/|

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

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


--
Gilles Dubreuil
Senior Software Engineer - Red Hat - Openstack DFG Integration
Email: gil...@redhat.com
GitHub/IRC: gildub
Mobile: +61 400 894 219


__
OpenStack Development Mailing 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] [neutron][neutron-release] feature/graphql branch rebase

[Gilles Dubreuil]

Could someone from the Neutron release group rebase feature/graphql 
branch against master/HEAD branch please?


Regards,
Gilles



__
OpenStack Development Mailing 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] [neutron][api[[graphql] A starting point

[Gilles Dubreuil]

Hello,

This initial patch [1]  allows to retrieve networks, subnets.

This is very easy, thanks to the graphene-sqlalchemy helper.

The edges, nodes layer might be confusing at first meanwhile they make 
the Schema Relay-compliant in order to offer re-fetching, pagination 
features out of the box.


The next priority is to set the unit test in order to implement mutations.

Could someone help provide a base in order to respect Neutron test 
requirements?



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

Thanks,
Gilles

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

Re: [openstack-dev] [neutron][api][grapql] Proof of Concept

[Gilles Dubreuil]

The branch is now available under feature/graphql on the neutron core 
repository [1].


Just to summarize our initial requirements:

- GraphQL endpoint to be added through a new WeBoB/WSGI stack
- Add graphene library [2]
- Unit tests and implementation for GraphQL schema for networks, subnets 
and ports Types.


I think we should support Relay by making the Schema Relay compliant and 
support Node ID, cursor connections and .
This will offer re-fetch, automated pagination and caching out of the 
box and not only will show the power of GraphQL but also because on the 
long run it would more likely what would be needed for complex API 
structures like we have across the board.


Any thoughts?

[1] https://git.openstack.org/cgit/openstack/neutron/log/?h=feature/graphql
[2] http://graphene-python.org/

On 31/05/18 17:27, Flint WALRUS wrote:

Hi Gilles, Ed,

I’m really glad and thrilled to read such good news!

At this point it’s cool to see that many initiatives have the same 
convergent needs regarding GraphQL as it will give us a good traction 
from the beginning if our PoC manage to sufficiently convince our peers.


Let me know as soon as the branch have been made, I’ll work on it.

Regards,
Fl1nt.
Le jeu. 31 mai 2018 à 09:17, Gilles Dubreuil <mailto:gdubr...@redhat.com>> a écrit :


Hi Flint,

I wish it was "my" summit ;)
In the latter case I'd make the sessions an hour and not 20 or 40
minutes, well at least for the Forum part. And I will also make
only one summit a year instead of two (which is also a feed back I
got from the Market place). I've passed that during the user
feedback session.

Sorry for not responding earlier, @elmiko is going to send the
minutes of the API SIG forum session we had.

We confirmed Neutron to be the PoC.
We are going to use a feature branch, waiting for Miguel Lavalle
to confirm the request has been acknowledge by the Infra group.
The PoC goal is to show GraphQL efficiency.
So we're going to make something straightforward, use Neutron
existing server by  adding the graphQL endpoint and cover few core
items such as network, subnets and ports (for example).

Also the idea of having a central point of access for OpenStack
APIs using GrahpQL stitching and delegation is exciting for
everyone (and I had obviously same feedback off the session) and
that's something that could happen once the PoC has convinced.

During the meeting, Jiri Tomasek explained how GraphQL could help
TripleO UI. Effectively they struggle with APIs requests and had
to create a middle(ware) module in JS to do API work and
reconstruction before the Javascript client can use it. GraphQL
would simplify the process and allow to get rid of the module. He
also explained, after the meeting, how Horizon could benefit as
well, allowing to use only JS and avoid Django altogether!

I've also been told that Zuul nees GraphQL.

Well basically the question is who doesn't need it?

Cheers,
Gilles



On 31/05/18 03:34, Flint WALRUS wrote:

Hi Gilles, I hope you enjoyed your Summit!?

Did you had any interesting talk to report about our little
initiative ?
Le dim. 6 mai 2018 à 15:01, Gilles Dubreuil mailto:gdubr...@redhat.com>> a écrit :


Akihiro, thank you for your precious help!

Regarding the choice of Neutron as PoC, I'm sorry for not
providing much details when I said "because of its specific
data model",
effectively the original mention was  "its API exposes things
at an individual table level, requiring the client to join
that information to get the answers they need".
I realize now such description probably applies to many
OpenStack APIs.
So I'm not sure what was the reason for choosing Neutron.
I suppose Nova is also a good candidate because API is quite
complex too, in a different way, and need to expose the data
API and the control API plane as we discussed.

After all Neutron is maybe not the best candidate but it
seems good enough.

And as Flint say the extension mechanism shouldn't be an issue.

So if someone believe there is a better candidate for the
PoC, please speak now.

Thanks,
Gilles

PS: Flint,  Thank you for offering to be the advocate for
Berlin. That's great!


On 06/05/18 02:23, Flint WALRUS wrote:

Hi Akihiro,

Thanks a lot for this insight on how neutron behave.

We would love to get support and backing from the neutron
team in order to be able to get the best PoC possible.

Someone suggested neutron as a good choice because of it
simple database model. As GraphQL can manage your behavior
of an extension declaring its own schemes I don’t think it
would take tha

Re: [openstack-dev] [neutron][api][graphql] Feature branch creation please (PTL/Core)

[Gilles Dubreuil]

On 05/06/18 13:02, Akihiro Motoki wrote:

Hi Gilles,

2018年6月5日(火) 10:46 Gilles Dubreuil <mailto:gdubr...@redhat.com>>:




On 04/06/18 22:20, Doug Hellmann wrote:
>> On Jun 4, 2018, at 7:57 AM, Gilles Dubreuil
mailto:gdubr...@redhat.com>> wrote:
>>
>> Hi,
>>
>> Can someone from the core team request infra to create a
feature branch for the Proof of Concept we agreed to do during API
SIG forum session [1] a Vancouver?
>>
>> Thanks,
>> Gilles
>>
>> [1] https://etherpad.openstack.org/p/YVR18-API-SIG-forum
> You can do this through the releases repo now. See the README
for instructions.
>
> Doug

Great, thanks Doug!

What about the UUID associated? Do I generate one?:

branches:
   - name: feature/graphql
 location:
   openstack/neutron: 


This needs to be a valid commit hash.
You can specify the latest conmit ID of the neutron repo.

Akihiro


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

Re: [openstack-dev] [neutron][api][graphql] Feature branch creation please (PTL/Core)

[Gilles Dubreuil]

On 04/06/18 22:20, Doug Hellmann wrote:

On Jun 4, 2018, at 7:57 AM, Gilles Dubreuil  wrote:

Hi,

Can someone from the core team request infra to create a feature branch for the 
Proof of Concept we agreed to do during API SIG forum session [1] a Vancouver?

Thanks,
Gilles

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

You can do this through the releases repo now. See the README for instructions.

Doug


Great, thanks Doug!

What about the UUID associated? Do I generate one?:

branches:
  - name: feature/graphql
    location:
  openstack/neutron: 




__
OpenStack Development Mailing 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] [neutron][api][graphql] Feature branch creation please (PTL/Core)

[Gilles Dubreuil]

Hi,

Can someone from the core team request infra to create a feature branch 
for the Proof of Concept we agreed to do during API SIG forum session 
[1] a Vancouver?


Thanks,
Gilles

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

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

Re: [openstack-dev] [neutron][api][grapql] Proof of Concept

[Gilles Dubreuil]

On 31/05/18 13:08, Ed Leafe wrote:

On May 6, 2018, at 8:01 AM, Gilles Dubreuil  wrote:


Regarding the choice of Neutron as PoC, I'm sorry for not providing much details when I 
said "because of its specific data model",
effectively the original mention was  "its API exposes things at an individual table 
level, requiring the client to join that information to get the answers they need".
I realize now such description probably applies to many OpenStack APIs.
So I'm not sure what was the reason for choosing Neutron.

Blame Monty!

It was Monty who suggested Neutron due to his particular experience working 
with the API. Since none of the rest of us in the API-SIG had any better 
suggestions, that was what we passed on to you. But I think that any target 
that demonstrates the advantages to be had by adopting GraphQL is fine. So if 
the team working on this think they can create a more impressive PoC with 
another API, the API-SIG will support that.


-- Ed Leafe





Well after being explained the story of the duck versus the duck parts 
(liver, heart, etc) it makes sense. With Neutron the API provides lots 
of parts but consumers have to put the part together to get the whole.


So Neutron is a good candidate as GraphQL will be able to show how it 
can fetch several parts at once (maybe not the whole beast since the PoC 
will cover only a fraction of the API).


And as you said as any API it should allow for GraphQL to show it's 
performance anyway.


So I believe we're good.

Cheers,
Gilles

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

Re: [openstack-dev] [neutron][api][grapql] Proof of Concept

[Gilles Dubreuil]

Hi Flint,

I wish it was "my" summit ;)
In the latter case I'd make the sessions an hour and not 20 or 40 
minutes, well at least for the Forum part. And I will also make only one 
summit a year instead of two (which is also a feed back I got from the 
Market place). I've passed that during the user feedback session.


Sorry for not responding earlier, @elmiko is going to send the minutes 
of the API SIG forum session we had.


We confirmed Neutron to be the PoC.
We are going to use a feature branch, waiting for Miguel Lavalle to 
confirm the request has been acknowledge by the Infra group.

The PoC goal is to show GraphQL efficiency.
So we're going to make something straightforward, use Neutron existing 
server by  adding the graphQL endpoint and cover few core items such as 
network, subnets and ports (for example).


Also the idea of having a central point of access for OpenStack APIs 
using GrahpQL stitching and delegation is exciting for everyone (and I 
had obviously same feedback off the session) and that's something that 
could happen once the PoC has convinced.


During the meeting, Jiri Tomasek explained how GraphQL could help 
TripleO UI. Effectively they struggle with APIs requests and had to 
create a middle(ware) module in JS to do API work and reconstruction 
before the Javascript client can use it. GraphQL would simplify the 
process and allow to get rid of the module. He also explained, after the 
meeting, how Horizon could benefit as well, allowing to use only JS and 
avoid Django altogether!


I've also been told that Zuul nees GraphQL.

Well basically the question is who doesn't need it?

Cheers,
Gilles


On 31/05/18 03:34, Flint WALRUS wrote:

Hi Gilles, I hope you enjoyed your Summit!?

Did you had any interesting talk to report about our little initiative ?
Le dim. 6 mai 2018 à 15:01, Gilles Dubreuil <mailto:gdubr...@redhat.com>> a écrit :



Akihiro, thank you for your precious help!

Regarding the choice of Neutron as PoC, I'm sorry for not
providing much details when I said "because of its specific data
model",
effectively the original mention was  "its API exposes things at
an individual table level, requiring the client to join that
information to get the answers they need".
I realize now such description probably applies to many OpenStack
APIs.
So I'm not sure what was the reason for choosing Neutron.
I suppose Nova is also a good candidate because API is quite
complex too, in a different way, and need to expose the data API
and the control API plane as we discussed.

After all Neutron is maybe not the best candidate but it seems
good enough.

And as Flint say the extension mechanism shouldn't be an issue.

So if someone believe there is a better candidate for the PoC,
please speak now.

Thanks,
Gilles

PS: Flint,  Thank you for offering to be the advocate for Berlin.
That's great!


On 06/05/18 02:23, Flint WALRUS wrote:

Hi Akihiro,

Thanks a lot for this insight on how neutron behave.

We would love to get support and backing from the neutron team in
order to be able to get the best PoC possible.

Someone suggested neutron as a good choice because of it simple
database model. As GraphQL can manage your behavior of an
extension declaring its own schemes I don’t think it would take
that much time to implement it.

@Gilles, if I goes to the berlin summitt I could definitely do
the networking and relationship work needed to get support on our
PoC from different teams members. This would help to spread the
world multiple time and don’t have a long time before someone
come to talk about this subject as what happens with the 2015
talk of the Facebook speaker.

Le sam. 5 mai 2018 à 18:05, Akihiro Motoki mailto:amot...@gmail.com>> a écrit :

Hi,

I am happy to see the effort to explore a new API mechanism.
I would like to see good progress and help effort as API
liaison from the neutron team.

> Neutron has been selected for the PoC because of its
specific data model

On the other hand, I am not sure this is the right reason to
choose 'neutron' only from this reason. I would like to note
"its specific data model" is not the reason that makes the
progress of API versioning slowest in the OpenStack
community. I believe it is worth recognized as I would like
not to block the effort due to the neutron-specific reasons.
The most complicated point in the neutron API is that the
neutron API layer allows neutron plugins to declare which
features are supported. The neutron API is a collection of
API extensions defined in the neutron-lib repo and each
neutron plugin can declare which subset(s) of the neutron
APIs are supported. (For more d

Re: [openstack-dev] [neutron][api][grapql] Proof of Concept

[Gilles Dubreuil]

Akihiro, thank you for your precious help!

Regarding the choice of Neutron as PoC, I'm sorry for not providing much 
details when I said "because of its specific data model",
effectively the original mention was  "its API exposes things at an 
individual table level, requiring the client to join that information to 
get the answers they need".

I realize now such description probably applies to many OpenStack APIs.
So I'm not sure what was the reason for choosing Neutron.
I suppose Nova is also a good candidate because API is quite complex 
too, in a different way, and need to expose the data API and the control 
API plane as we discussed.


After all Neutron is maybe not the best candidate but it seems good enough.

And as Flint say the extension mechanism shouldn't be an issue.

So if someone believe there is a better candidate for the PoC, please 
speak now.


Thanks,
Gilles

PS: Flint,  Thank you for offering to be the advocate for Berlin. That's 
great!



On 06/05/18 02:23, Flint WALRUS wrote:

Hi Akihiro,

Thanks a lot for this insight on how neutron behave.

We would love to get support and backing from the neutron team in 
order to be able to get the best PoC possible.


Someone suggested neutron as a good choice because of it simple 
database model. As GraphQL can manage your behavior of an extension 
declaring its own schemes I don’t think it would take that much time 
to implement it.


@Gilles, if I goes to the berlin summitt I could definitely do the 
networking and relationship work needed to get support on our PoC from 
different teams members. This would help to spread the world multiple 
time and don’t have a long time before someone come to talk about this 
subject as what happens with the 2015 talk of the Facebook speaker.


Le sam. 5 mai 2018 à 18:05, Akihiro Motoki <amot...@gmail.com 
<mailto:amot...@gmail.com>> a écrit :


Hi,

I am happy to see the effort to explore a new API mechanism.
I would like to see good progress and help effort as API liaison
from the neutron team.

> Neutron has been selected for the PoC because of its specific
data model

On the other hand, I am not sure this is the right reason to
choose 'neutron' only from this reason. I would like to note "its
specific data model" is not the reason that makes the progress of
API versioning slowest in the OpenStack community. I believe it is
worth recognized as I would like not to block the effort due to
the neutron-specific reasons.
The most complicated point in the neutron API is that the neutron
API layer allows neutron plugins to declare which features are
supported. The neutron API is a collection of API extensions
defined in the neutron-lib repo and each neutron plugin can
declare which subset(s) of the neutron APIs are supported. (For
more detail, you can check how the neutron API extension mechanism
is implemented). It is not defined only by the neutron API layer.
We need to communicate which API features are supported by
communicating enabled service plugins.

I am afraid that most efforts to explore a new mechanism in
neutron will be spent to address the above points which is not
directly related to GraphQL itself.
Of course, it would be great if you overcome long-standing
complicated topics as part of GraphQL effort :)

I am happy to help the effort and understand how the neutron API
is defined.

Thanks,
Akihiro


2018年5月5日(土) 18:16 Gilles Dubreuil <gdubr...@redhat.com
<mailto:gdubr...@redhat.com>>:

Hello,

Few of us recently discussed [1] how GraphQL [2], the next
evolution
from REST, could transform OpenStack APIs for the better.
Effectively we believe OpenStack APIs provide perfect use
cases for
GraphQL DSL approach, to bring among other advantages, better
performance and stability, easier developments and
consumption, and with
GraphQL Schema provide automation capabilities never achieved
before.

The API SIG suggested to start an API GraphQL Proof of Concept
(PoC) to
demonstrate the capabilities before eventually extend GraphQL
to other
projects.
Neutron has been selected for the PoC because of its specific
data model.

So if you are interested, please join us.
For those who can make it, we'll also discuss this during the
SIG API
BoF at OpenStack Summit at Vancouver [3]

To learn more about GraphQL, check-out howtographql.com
<http://howtographql.com> [4].

So let's get started...


[1]
http://lists.openstack.org/pipermail/openstack-dev/2018-May/130054.html
[2] http://graphql.org/
[3]

https://www.openstack.org/summit/vancouver-2018/summit-schedule/events/21798/api-special-

Re: [openstack-dev] [api] REST limitations and GraghQL inception?

[Gilles Dubreuil]

On 05/05/18 09:42, Flint WALRUS wrote:
I will not attend the vancouver summit but I’ll try to attend the 
berlin one as it’s closer to me.


No worries, I hope "networking" at Vancouver will allow to grab good 
support and rocket the momentum :).
Unfortunately I'm not sure to make it to Berlin time wise and distance 
wise too.




However I’ll be happy to join the conversation and give a hand, 
especially if you need an operational point of view as our Openstack 
usage is constantly growing within an heterogeneous environment 
ranging from a grizzly cluster (deprecating it this year) to a shiny 
Queens one on multiple geographic area.


I think our setup gives us a really good point of view of what are the 
Openstack PITA and what operators are expecting the foundation to do 
with such challenges.


Flint, I think that's an invaluable experience. Thank you for bringing 
in and also what you've expressed is very important too. I believe there 
are needs to be addressed.
The viewpoint of consumers has been lacking. And the API SIG exists to 
take it in consideration but we need more people involved.
It seems the ransom of the success hitting as now a critical mass of 
supporters is needed to be able to get any requirement accepted.
Especially such requirements touch project wide components (API) living 
inside the entropy of the cloud structural complexity.
This is why there is no doubt GraphQL data model simplification can 
bring only good.


From my side, I'm not core, just been consuming OpenStack APIs for SDKs 
for the last 2 years and I feel we're stalling.


So I'm more than happy to help and get more involved but we're going to 
need neutron core and other APIs core members believers.


Thanks,
Gilles


Le sam. 5 mai 2018 à 01:18, Gilles Dubreuil <gdubr...@redhat.com 
<mailto:gdubr...@redhat.com>> a écrit :


Right, let's announce the Proof of Concept project as of Neutron,
invite anyone interested and start it.

There is an API SIG BoF at Vancouver, where we will announce it
too. And for everyone who can attend, to be welcome to discuss it:

https://www.openstack.org/summit/vancouver-2018/summit-schedule/events/21798/api-special-interest-group-session

Yeah, Graphene is the only one listed by GraphQL organization for
Python: http://graphql.org/code/#python.

I think we should take this discussion on the coming project thread.

Thank you everyone and see you there.

Cheers,
Gilles


On 04/05/18 23:16, Flint WALRUS wrote:

As clarify by Gilles and Kevin we absolutely can  get GraphQL
with the control plan API and the workers api.

Ok, how do start to work on that? What’s the next step?

Which server library do we want to use?
I personally use graphene with python as it is the library listed
by the official GraphQL website. I don’t even know if there is
another library available indeed.

Are we ok to try to use neutron as a PoC service?

Le ven. 4 mai 2018 à 06:41, Gilles Dubreuil <gdubr...@redhat.com
<mailto:gdubr...@redhat.com>> a écrit :

Actually Mutations fields are only data to be displayed, if
needed, by
the response.
The data changes comes with the parameters.
So the correct mutation syntax is:

mutation rebootServer {
   updateServer(id: ) {
 reboot(type: "HARD")
   }
}

Also the latter example would be a "data API" equivalent
using CRUD
function like "updateServer"

And the following example would be a "plane API" equivalent
approach
with an action function:

mutation hardReboot {
   rebootServer(id: , type: "HARD")
}

Sorry for the initial confusion but I think this is important
because
    GraphQL schema helps clarify data and the operations.


On 04/05/18 13:20, Gilles Dubreuil wrote:
>
> On 04/05/18 05:34, Fox, Kevin M wrote:
>> k8s does that I think by separating desired state from
actual state
>> and working to bring the two inline. the same could (maybe
even
>> should) be done to openstack. But your right, that is not
a small
>> amount of work.
>
> K8s makes perfect sense to follow declarative approach.
>
> That said a mutation following control plane API action
semantic could
> be very similar:
>
> mutation rebootServer {
>   Server(id: ) {
>     reboot: {
>   type: "HARD"
>     }
>   }
> }
>
>
> "rebootServer" being an alias to name the request.
>
   

[openstack-dev] [neutron][api][grapql] Proof of Concept

[Gilles Dubreuil]

Hello,

Few of us recently discussed [1] how GraphQL [2], the next evolution 
from REST, could transform OpenStack APIs for the better.
Effectively we believe OpenStack APIs provide perfect use cases for 
GraphQL DSL approach, to bring among other advantages, better 
performance and stability, easier developments and consumption, and with 
GraphQL Schema provide automation capabilities never achieved before.


The API SIG suggested to start an API GraphQL Proof of Concept (PoC) to 
demonstrate the capabilities before eventually extend GraphQL to other 
projects.

Neutron has been selected for the PoC because of its specific data model.

So if you are interested, please join us.
For those who can make it, we'll also discuss this during the SIG API 
BoF at OpenStack Summit at Vancouver [3]


To learn more about GraphQL, check-out howtographql.com [4].

So let's get started...


[1] http://lists.openstack.org/pipermail/openstack-dev/2018-May/130054.html
[2] http://graphql.org/
[3] 
https://www.openstack.org/summit/vancouver-2018/summit-schedule/events/21798/api-special-interest-group-session

[4] https://www.howtographql.com/

Regards,
Gilles



__
OpenStack Development Mailing 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] REST limitations and GraghQL inception?

[Gilles Dubreuil]

Right, let's announce the Proof of Concept project as of Neutron, invite 
anyone interested and start it.


There is an API SIG BoF at Vancouver, where we will announce it too. And 
for everyone who can attend, to be welcome to discuss it:

https://www.openstack.org/summit/vancouver-2018/summit-schedule/events/21798/api-special-interest-group-session

Yeah, Graphene is the only one listed by GraphQL organization for 
Python: http://graphql.org/code/#python.


I think we should take this discussion on the coming project thread.

Thank you everyone and see you there.

Cheers,
Gilles


On 04/05/18 23:16, Flint WALRUS wrote:
As clarify by Gilles and Kevin we absolutely can  get GraphQL with the 
control plan API and the workers api.


Ok, how do start to work on that? What’s the next step?

Which server library do we want to use?
I personally use graphene with python as it is the library listed by 
the official GraphQL website. I don’t even know if there is another 
library available indeed.


Are we ok to try to use neutron as a PoC service?

Le ven. 4 mai 2018 à 06:41, Gilles Dubreuil <gdubr...@redhat.com 
<mailto:gdubr...@redhat.com>> a écrit :


Actually Mutations fields are only data to be displayed, if
needed, by
the response.
The data changes comes with the parameters.
So the correct mutation syntax is:

mutation rebootServer {
   updateServer(id: ) {
 reboot(type: "HARD")
   }
}

Also the latter example would be a "data API" equivalent using CRUD
function like "updateServer"

And the following example would be a "plane API" equivalent approach
with an action function:

mutation hardReboot {
   rebootServer(id: , type: "HARD")
}

Sorry for the initial confusion but I think this is important because
GraphQL schema helps clarify data and the operations.


On 04/05/18 13:20, Gilles Dubreuil wrote:
>
> On 04/05/18 05:34, Fox, Kevin M wrote:
>> k8s does that I think by separating desired state from actual
state
>> and working to bring the two inline. the same could (maybe even
>> should) be done to openstack. But your right, that is not a small
>> amount of work.
>
> K8s makes perfect sense to follow declarative approach.
>
> That said a mutation following control plane API action semantic
could
> be very similar:
>
> mutation rebootServer {
>   Server(id: ) {
>     reboot: {
>   type: "HARD"
>     }
>   }
> }
>
>
> "rebootServer" being an alias to name the request.
>
>
>> Even without using GraphQL, Making the api more declarative
anyway,
>> has advantages.
>
> +1
>
>> Thanks,
>> Kevin
>> 
>> From: Jay Pipes [jaypi...@gmail.com <mailto:jaypi...@gmail.com>]
>> Sent: Thursday, May 03, 2018 10:50 AM
>> To: openstack-dev@lists.openstack.org
    <mailto:openstack-dev@lists.openstack.org>
>> Subject: Re: [openstack-dev] [api] REST limitations and GraghQL
>> inception?
>>
>> On 05/03/2018 12:57 PM, Ed Leafe wrote:
>>> On May 2, 2018, at 2:40 AM, Gilles Dubreuil
<gdubr...@redhat.com <mailto:gdubr...@redhat.com>>
>>> wrote:
>>>>> • We should get a common consensus before all projects start to
>>>>> implement it.
>>>> This is going to be raised during the API SIG weekly meeting
later
>>>> this week.
>>>> API developers (at least one) from every project are strongly
>>>> welcomed to participate.
>>>> I suppose it makes sense for the API SIG to be the place to
discuss
>>>> it, at least initially.
>>> It was indeed discussed, and we think that it would be a
worthwhile
>>> experiment. But it would be a difficult, if not impossible,
proposal
>>> to have adopted OpenStack-wide without some data to back it
up. So
>>> what we thought would be a good starting point would be to have a
>>> group of individuals interested in GraphQL form an informal
team and
>>> proceed to wrap one OpenStack API as a proof-of-concept. Monty
>>> Taylor suggested Neutron as an excellent candidate, as its API
>>> exposes things at an individual table level, requiring the
client to
>>> join that information to get the answers they need.
>>>
>>> Once that is done, we could examine the results, and use them
as the
>>&

Re: [openstack-dev] [api] REST limitations and GraghQL inception?

[Gilles Dubreuil]

Actually Mutations fields are only data to be displayed, if needed, by 
the response.

The data changes comes with the parameters.
So the correct mutation syntax is:

mutation rebootServer {
  updateServer(id: ) {
    reboot(type: "HARD")
  }
}

Also the latter example would be a "data API" equivalent using CRUD 
function like "updateServer"


And the following example would be a "plane API" equivalent approach 
with an action function:


mutation hardReboot {
  rebootServer(id: , type: "HARD")
}

Sorry for the initial confusion but I think this is important because 
GraphQL schema helps clarify data and the operations.



On 04/05/18 13:20, Gilles Dubreuil wrote:


On 04/05/18 05:34, Fox, Kevin M wrote:
k8s does that I think by separating desired state from actual state 
and working to bring the two inline. the same could (maybe even 
should) be done to openstack. But your right, that is not a small 
amount of work.


K8s makes perfect sense to follow declarative approach.

That said a mutation following control plane API action semantic could 
be very similar:


mutation rebootServer {
  Server(id: ) {
    reboot: {
  type: "HARD"
    }
  }
}


"rebootServer" being an alias to name the request.


Even without using GraphQL, Making the api more declarative anyway, 
has advantages.


+1


Thanks,
Kevin

From: Jay Pipes [jaypi...@gmail.com]
Sent: Thursday, May 03, 2018 10:50 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [api] REST limitations and GraghQL 
inception?


On 05/03/2018 12:57 PM, Ed Leafe wrote:
On May 2, 2018, at 2:40 AM, Gilles Dubreuil <gdubr...@redhat.com> 
wrote:
• We should get a common consensus before all projects start to 
implement it.
This is going to be raised during the API SIG weekly meeting later 
this week.
API developers (at least one) from every project are strongly 
welcomed to participate.
I suppose it makes sense for the API SIG to be the place to discuss 
it, at least initially.
It was indeed discussed, and we think that it would be a worthwhile 
experiment. But it would be a difficult, if not impossible, proposal 
to have adopted OpenStack-wide without some data to back it up. So 
what we thought would be a good starting point would be to have a 
group of individuals interested in GraphQL form an informal team and 
proceed to wrap one OpenStack API as a proof-of-concept. Monty 
Taylor suggested Neutron as an excellent candidate, as its API 
exposes things at an individual table level, requiring the client to 
join that information to get the answers they need.


Once that is done, we could examine the results, and use them as the 
basis for proceeding with something more comprehensive. Does that 
sound like a good approach to (all of) you?

Did anyone bring up the differences between control plane APIs and data
APIs and the applicability of GraphQL to the latter and not the former?

For example, a control plane API to reboot a server instance looks like
this:

POST /servers/{uuid}/action
{
  "reboot" : {
  "type" : "HARD"
  }
}

how does that map to GraphQL? Via GraphQL's "mutations" [0]? That
doesn't really work since the server object isn't being mutated. I mean,
the state of the server will *eventually* be mutated when the reboot
action starts kicking in (the above is an async operation returning a
202 Accepted). But the act of hitting POST /servers/{uuid}/action
doesn't actually mutate the server's state.

This is just one example of where GraphQL doesn't necessarily map well
to control plane APIs that happen to be built on top of REST/HTTP [1]

Bottom line for me would be what is the perceivable benefit that all of
our users would receive given the (very costly) overhaul of our APIs
that would likely be required.

Best,
-jay

[0] http://graphql.org/learn/queries/#mutations
[1] One could argue (and I have in the past) that POST
/servers/{uuid}/action isn't a RESTful interface at all...

__ 


OpenStack Development Mailing 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




--
Gilles Dubreuil
Senior Software Engineer - Red Hat - Openstack DFG Integration
Email: gil...@redhat.com
GitHub/IRC: gildub
Mobile: +61 400 894 219


__
OpenStack Development Mailing 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] REST limitations and GraghQL inception?

[Gilles Dubreuil]

On 04/05/18 05:34, Fox, Kevin M wrote:

k8s does that I think by separating desired state from actual state and working 
to bring the two inline. the same could (maybe even should) be done to 
openstack. But your right, that is not a small amount of work.


K8s makes perfect sense to follow declarative approach.

That said a mutation following control plane API action semantic could 
be very similar:


mutation rebootServer {
  Server(id: ) {
reboot: {
  type: "HARD"
}
  }
}


"rebootServer" being an alias to name the request.



Even without using GraphQL, Making the api more declarative anyway, has 
advantages.


+1


Thanks,
Kevin

From: Jay Pipes [jaypi...@gmail.com]
Sent: Thursday, May 03, 2018 10:50 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [api] REST limitations and GraghQL inception?

On 05/03/2018 12:57 PM, Ed Leafe wrote:

On May 2, 2018, at 2:40 AM, Gilles Dubreuil <gdubr...@redhat.com> wrote:

• We should get a common consensus before all projects start to implement it.

This is going to be raised during the API SIG weekly meeting later this week.
API developers (at least one) from every project are strongly welcomed to 
participate.
I suppose it makes sense for the API SIG to be the place to discuss it, at 
least initially.

It was indeed discussed, and we think that it would be a worthwhile experiment. 
But it would be a difficult, if not impossible, proposal to have adopted 
OpenStack-wide without some data to back it up. So what we thought would be a 
good starting point would be to have a group of individuals interested in 
GraphQL form an informal team and proceed to wrap one OpenStack API as a 
proof-of-concept. Monty Taylor suggested Neutron as an excellent candidate, as 
its API exposes things at an individual table level, requiring the client to 
join that information to get the answers they need.

Once that is done, we could examine the results, and use them as the basis for 
proceeding with something more comprehensive. Does that sound like a good 
approach to (all of) you?

Did anyone bring up the differences between control plane APIs and data
APIs and the applicability of GraphQL to the latter and not the former?

For example, a control plane API to reboot a server instance looks like
this:

POST /servers/{uuid}/action
{
  "reboot" : {
  "type" : "HARD"
  }
}

how does that map to GraphQL? Via GraphQL's "mutations" [0]? That
doesn't really work since the server object isn't being mutated. I mean,
the state of the server will *eventually* be mutated when the reboot
action starts kicking in (the above is an async operation returning a
202 Accepted). But the act of hitting POST /servers/{uuid}/action
doesn't actually mutate the server's state.

This is just one example of where GraphQL doesn't necessarily map well
to control plane APIs that happen to be built on top of REST/HTTP [1]

Bottom line for me would be what is the perceivable benefit that all of
our users would receive given the (very costly) overhaul of our APIs
that would likely be required.

Best,
-jay

[0] http://graphql.org/learn/queries/#mutations
[1] One could argue (and I have in the past) that POST
/servers/{uuid}/action isn't a RESTful interface at all...

__
OpenStack Development Mailing 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


--
Gilles Dubreuil
Senior Software Engineer - Red Hat - Openstack DFG Integration
Email: gil...@redhat.com
GitHub/IRC: gildub
Mobile: +61 400 894 219


__
OpenStack Development Mailing 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] REST limitations and GraghQL inception?

[Gilles Dubreuil]

+1 for a PoC


On 04/05/18 03:56, Flint WALRUS wrote:

Exactly !
Le jeu. 3 mai 2018 à 19:55, Flint WALRUS <gael.ther...@gmail.com 
<mailto:gael.ther...@gmail.com>> a écrit :


It seems to be a fair way to do it. I do second the Neutron API as
a good candidate.

I’ll be happy to give a hand.

@jay I’ve already sum my points upper, but I could definitely have
better exemples if needed.

I’m operating and dealing with a large (really) Openstack platform
and GraphQL would have tremendous performances impacts for sure.
But you’re right proof have to be made.
Le jeu. 3 mai 2018 à 18:57, Ed Leafe <e...@leafe.com
<mailto:e...@leafe.com>> a écrit :

On May 2, 2018, at 2:40 AM, Gilles Dubreuil
<gdubr...@redhat.com <mailto:gdubr...@redhat.com>> wrote:
>
>> • We should get a common consensus before all projects
start to implement it.
>
> This is going to be raised during the API SIG weekly meeting
later this week.
> API developers (at least one) from every project are
strongly welcomed to participate.
> I suppose it makes sense for the API SIG to be the place to
discuss it, at least initially.

It was indeed discussed, and we think that it would be a
worthwhile experiment. But it would be a difficult, if not
impossible, proposal to have adopted OpenStack-wide without
some data to back it up. So what we thought would be a good
starting point would be to have a group of individuals
interested in GraphQL form an informal team and proceed to
wrap one OpenStack API as a proof-of-concept. Monty Taylor
suggested Neutron as an excellent candidate, as its API
exposes things at an individual table level, requiring the
client to join that information to get the answers they need.

Once that is done, we could examine the results, and use them
as the basis for proceeding with something more comprehensive.
Does that sound like a good approach to (all of) you?

-- Ed Leafe







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



--
Gilles Dubreuil
Senior Software Engineer - Red Hat - Openstack DFG Integration
Email: gil...@redhat.com
GitHub/IRC: gildub
Mobile: +61 400 894 219

__
OpenStack Development Mailing 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] The Forum Schedule is now live

[Gilles Dubreuil]

Jimmy,

Fantastic! Thank you.

Cheers,
Gilles


On 02/05/18 22:25, Jimmy McArthur wrote:

Gilles,

Just responded to the ZenDesk ticket :)

Cheers,
Jimmy


Gilles Dubreuil <mailto:gdubr...@redhat.com>
May 2, 2018 at 12:09 AM
Hi Jimmy,

Do you have an update about the API SIG slot?

Thanks,
Gilles





__ 


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Jimmy McArthur <mailto:ji...@openstack.org>
April 27, 2018 at 11:04 AM
Hello all -

Please take a look here for the posted Forum schedule: 
https://www.openstack.org/summit/vancouver-2018/summit-schedule#track=224 
You should also see it update on your Summit App.


Thank you and see you in Vancouver!
Jimmy


__ 


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




--
Gilles Dubreuil
Senior Software Engineer - Red Hat - Openstack DFG Integration
Email: gil...@redhat.com
GitHub/IRC: gildub
Mobile: +61 400 894 219

__
OpenStack Development Mailing 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] REST limitations and GraghQL inception?

[Gilles Dubreuil]

I fixed the GraphQL typo (my mistake) in $subject to help with future ML 
searches.


Please see inline too.


On 02/05/18 07:37, Flint WALRUS wrote:
Ok, here are my two cents regarding GraphQL integration within 
Openstack and some thoughts around this topic.


1°/- Openstack SDK should still exist and should be in my humble 
opinion a critical focus as it allow following benefits for large and 
medium companies :


• It provide a common and clean structure for Openstack developments 
and should be used either by projects or tools willing to integrate 
Openstack as it will then create some sort of standard.


For instance, here in my job we have A LOT (More than 10 000 peoples 
working within around 130 teams) of teams developing over Openstack 
using the SDK as a common shared base layout.
That allow for teams to easily share and co-develop on projects. Those 
teams are spread around the world and so need to have clean guidelines 
as it avoid them reinventing the wheel, they’re not stuck with someone 
else obscure code created by another persons on the other side of the 
world or within a different timezone.

Additionally it streamline our support and debug processes.


I'm assuming you're talking about the Python SDK (Shade) which would 
make sense because it's the "lingua franca" of all projects.


Nevertheless, for any SDKs/Languages, if adopted then GraphQL is likely 
to replace its REST SDK on the long run. GraphQL is a DSL bypassing a 
SDK need which get replaced with GraphQL client library. Basically the 
change, not a rewrite, is inevitable. But I insist on "the long run" 
part, initially both in parallel one wrapping the other, then 
progressively the REST content moving across to GraphQL.




• We should get a common consensus before all projects start to 
implement it.



This is going to be raised during the API SIG weekly meeting later this 
week.
API developers (at least one) from every project are strongly welcomed 
to participate.
I suppose it makes sense for the API SIG to be the place to discuss it, 
at least initially.





This point is for me the most important one as it will fix flaws we 
get currently with the rest APIs development within Openstack.


First it will avoid a fresh developer to be confused by too many 
options. Honestly, I know we are open etc, but this point really need 
to be addressed as it is the main issue that I face with Openstack 
advocacy since many years now.


Having too many options even if explained within the documentation 
daunt a lot of people to quickly give a hand with projects.


For instance I have a workmate that is currently working on an 
internal tool which ask me how should he implement its project REST 
interfaces.


I told him TO NOT use WSME and to stick with what have been done by a 
major project. Unfortunately he choose to copy what have been done by 
Octavia which is actually using... WSME...


GraphQL gives us the opportunity and ability to fix Openstack 
development inconsistencies by providing and enforcing a clean 
guideline regarding which library should be used and in which way.


That would also have the side effect to easy the entry level for a new 
Openstack developer.


I couldn't agree more!



• New architecture opportunities.

For sure that will bring new architecture opportunities, but the 
broker thing is not a good idea as each project should be able to be 
autonomous.


I personally don’t like centralized services as it bring SPOF.

Let’s take the AMQP example. For now most of Openstack deployments use 
a RabbitMQ or broker like system.
Even if each (well at least major vanilla projects) services can (and 
should) use ZeroMQ.
I do myself use RabbitMQ but my last weeks were so much 
debugging/investigation hell that we now plan to have a serious 
benchmark and test of ZMQ.


One thing that I would love to see with GraphQL is a better 
distributed and traceable model.




Exactly and the term broker I used is far from ideal,  I meant it in the 
context of a broker pattern providing distributed API service. GraphQL 
has "stiching" capabilities allowing to forward request to diverse 
GraphQL service, kind of a proxy, ideally such service to be distributed 
itself.


The idea behind is a GraphQL proxy offering a single point of entry for 
OpenStack entire stack and of course leaving complete autonomy to the 
all services.


https://blog.graph.cool/graphql-schema-stitching-explained-schema-delegation-4c6caf468405

Anyway, I’m glad someone started this discussion as I feel it is a 
really important topic that would highly help Openstack on more than 
just interfacing topics.
Le mar. 1 mai 2018 à 05:00, Gilles Dubreuil <gdubr...@redhat.com 
<mailto:gdubr...@redhat.com>> a écrit :




On 01/05/18 11:31, Flint WALRUS wrote:

Yes, that’s was indeed the sens of my point.


I was just enforcing it, no worries! ;)




Openstack have to provide both endpoints type for a whi

Re: [openstack-dev] The Forum Schedule is now live

[Gilles Dubreuil]

Hi Jimmy,

Do you have an update about the API SIG slot?

Thanks,
Gilles


On 28/04/18 02:04, Jimmy McArthur wrote:

Hello all -

Please take a look here for the posted Forum schedule: 
https://www.openstack.org/summit/vancouver-2018/summit-schedule#track=224 
You should also see it update on your Summit App.


Thank you and see you in Vancouver!
Jimmy


__ 


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



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

Re: [openstack-dev] [All] [Elections] Rocky TC Election Results

[Gilles Dubreuil]

Bravo, well done!

On 01/05/18 14:14, Zhipeng Huang wrote:

Congratulations to the newly elected TC members !

On Tue, May 1, 2018 at 2:17 AM, Amy <a...@demarco.com 
<mailto:a...@demarco.com>> wrote:


Congrats to all who were elected!

Amy (spotz)

Sent from my iPhone

On Apr 30, 2018, at 7:02 PM, Kendall Nelson <kennelso...@gmail.com
<mailto:kennelso...@gmail.com>> wrote:


Hello Everyone :)

Please join me in congratulating the 7 newly elected members of
the Technical Committee (TC)!

  * Thierry Carrez (ttx)]
  * Chris Dent (cdent)
  * Sean McGinnis (smcginnis)
  * Davanum Srinivas (dims)
  * Zane Bitter (zaneb)
  * Graham Hayes (mugsie)
  * Mohammed Naser (mnaser)


Full results:
https://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_98430d99fc2ed59d
<https://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_98430d99fc2ed59d>


Election process details and results are also available here:
https://governance.openstack.org/election/
<https://governance.openstack.org/election/>

Thank you to all of the candidates, having a good group of
candidates helps engage the community in our democratic process.

Thank you to all who voted and who encouraged others to vote. We
need to ensure your voices are heard!

Thank you for another great round.

-Kendall Nelson (diablo_rojo)

[1] https://review.openstack.org/#/c/565368/
<https://review.openstack.org/#/c/513881/>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org
<mailto:openstack-dev-requ...@lists.openstack.org>?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
<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://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>




--
Zhipeng (Howard) Huang

Standard Engineer
IT Standard & Patent/IT Product Line
Huawei Technologies Co,. Ltd
Email: huangzhip...@huawei.com <mailto:huangzhip...@huawei.com>
Office: Huawei Industrial Base, Longgang, Shenzhen

(Previous)
Research Assistant
Mobile Ad-Hoc Network Lab, Calit2
University of California, Irvine
Email: zhipe...@uci.edu <mailto:zhipe...@uci.edu>
Office: Calit2 Building Room 2402

OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado


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


--
Gilles Dubreuil
Senior Software Engineer - Red Hat - Openstack DFG Integration
Email: gil...@redhat.com
GitHub/IRC: gildub
Mobile: +61 400 894 219

__
OpenStack Development Mailing 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] REST limitations and GraghGL inception?

[Gilles Dubreuil]

On 01/05/18 11:31, Flint WALRUS wrote:

Yes, that’s was indeed the sens of my point.


I was just enforcing it, no worries! ;)



Openstack have to provide both endpoints type for a while for backward 
compatibility in order to smooth the transition.


For instance, that would be a good idea to contact postman devteam 
once GraphQL will start to be integrated as it will allow a lot of ops 
to keep their day to day tools by just having to convert their 
existing collections of handful requests.


Shouldn't we have a common consensus before any project start pushing 
its own GraphQL wheel?


Also I wonder how GraphQL could open new architecture avenues for OpenStack.
For example, would that make sense to also have a GraphQL broker linking 
OpenStack services?





Or alternatively to provide a tool with similar features at least.
Le mar. 1 mai 2018 à 03:18, Gilles Dubreuil <gdubr...@redhat.com 
<mailto:gdubr...@redhat.com>> a écrit :




On 30/04/18 20:16, Flint WALRUS wrote:

I would very much second that question! Indeed it have been one
of my own wondering since many times.

Of course GraphQL is not intended to replace REST as is and have
to live in parallel 


Effectively a standard initial architecture is to have GraphQL
sitting aside (in parallel) and wrapping REST and along the way
develop GrapgQL Schema.

It's seems too early to tell but GraphQL being the next step in
API evolution it might ultimately replace REST.



but it would likely and highly accelerate all requests within
heavily loaded environments


+1



.

So +1 for this question.
Le lun. 30 avr. 2018 à 05:53, Gilles Dubreuil
<gdubr...@redhat.com <mailto:gdubr...@redhat.com>> a écrit :

Hi,

Remember Boston's Summit presentation [1] about GraphQL [2]
and how it
addresses REST limitations.
I wonder if any project has been thinking about using
GraphQL. I haven't
find any mention or pointers about it.

GraphQL takes a complete different approach compared to REST.
So we can
finally forget about REST API Description languages
(OpenAPI/Swagger/WSDL/WADL/JSON-API/ETC) and HATEOS (the
hypermedia
approach which doesn't describe how to use it).

So, once passed the point where 'REST vs GraphQL' is like
comparing SQL
and no-SQL DBMS and therefore have different applications,
there are no
doubt the complexity of most OpenStack projects are good
candidates for
GraphQL.

Besides topics such as efficiency, decoupling, no version
management
need there many other powerful features such as API Schema
out of the
box and better automation down that track.

It looks like the dream of a conduit between API services and
consumers
might have finally come true so we could move-on an worry
about other
things.

So has anyone already starting looking into it?

[1]

https://www.openstack.org/videos/boston-2017/building-modern-apis-with-graphql
[2] http://graphql.org




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



-- 
Gilles Dubreuil

Senior Software Engineer - Red Hat - Openstack DFG Integration
Email:gil...@redhat.com <mailto:gil...@redhat.com>
GitHub/IRC: gildub
Mobile: +61 400 894 219



--
Gilles Dubreuil
Senior Software Engineer - Red Hat - Openstack DFG Integration
Email: gil...@redhat.com
GitHub/IRC: gildub
Mobile: +61 400 894 219

__
OpenStack Development Mailing 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] REST limitations and GraghGL inception?

[Gilles Dubreuil]

On 01/05/18 07:21, Matt Riedemann wrote:

On 4/29/2018 10:53 PM, Gilles Dubreuil wrote:
Remember Boston's Summit presentation [1] about GraphQL [2] and how 
it addresses REST limitations.
I wonder if any project has been thinking about using GraphQL. I 
haven't find any mention or pointers about it.


GraphQL takes a complete different approach compared to REST. So we 
can finally forget about REST API Description languages 
(OpenAPI/Swagger/WSDL/WADL/JSON-API/ETC) and HATEOS (the hypermedia 
approach which doesn't describe how to use it).


So, once passed the point where 'REST vs GraphQL' is like comparing 
SQL and no-SQL DBMS and therefore have different applications, there 
are no doubt the complexity of most OpenStack projects are good 
candidates for GraphQL.


Besides topics such as efficiency, decoupling, no version management 
need there many other powerful features such as API Schema out of the 
box and better automation down that track.


It looks like the dream of a conduit between API services and 
consumers might have finally come true so we could move-on an worry 
about other things.


So has anyone already starting looking into it?

[1] 
https://www.openstack.org/videos/boston-2017/building-modern-apis-with-graphql 


[2] http://graphql.org


Not to speak for him, but Sean Dague had a blog post about REST API 
microversions in OpenStack and there is a Q bit at the bottom about 
GraphQL replacing the need for microversions:


https://dague.net/2017/12/11/rest-api-microversions/

Since I don't expect Sean to magically appear to reply to this thread, 
I thought I'd pass this along.




Thanks Matt for the link.

During Denver's PTG we effectively discovered consumers tend to use 3rd 
party SDK and we also discovered that, ironically, nobody - besides Sean 
;) - has the bandwidth to work full time on SDK either. That was and 
still is the driver for more automation and therefore for having 
projects to produce an API Schema.


Once aspect is about GraphQL being a descriptive language. It allow to 
decouple entirely consumers from producers. So instead of SDK, consumers 
rely on GraphQL client library (which are standardized [1]). The focus 
becomes the data and not how to transfer the data.
Effectively, services make their data available through a Schema and 
clients request a tree of data against it. Sure, at the end of the day, 
it's still a HTTP conversation taking place and returning a JSON 
structure (when not up/down loading a file or so). The big difference 
(among other things) is one and only one transaction is used.


The second aspect is about automation which can take place because the 
Schema is provided up-front, it's the Graph part.


In the Q, Sean said SDK "build their object models", yes that's true 
with GraphQL we have "fat clients" but as we've also seen the SDK is 
replaced with a GraphQL client., cutting the "man in the middle" off!


As per the rest of the Answer, it seems to me there are other aspects to 
be looked at it from different angles.


Cheers

[1] http://graphql.org/code/



__
OpenStack Development Mailing 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] REST limitations and GraghGL inception?

[Gilles Dubreuil]

On 30/04/18 20:16, Flint WALRUS wrote:
I would very much second that question! Indeed it have been one of my 
own wondering since many times.


Of course GraphQL is not intended to replace REST as is and have to 
live in parallel 


Effectively a standard initial architecture is to have GraphQL sitting 
aside (in parallel) and wrapping REST and along the way develop GrapgQL 
Schema.


It's seems too early to tell but GraphQL being the next step in API 
evolution it might ultimately replace REST.


but it would likely and highly accelerate all requests within heavily 
loaded environments


+1


.

So +1 for this question.
Le lun. 30 avr. 2018 à 05:53, Gilles Dubreuil <gdubr...@redhat.com 
<mailto:gdubr...@redhat.com>> a écrit :


Hi,

Remember Boston's Summit presentation [1] about GraphQL [2] and
how it
addresses REST limitations.
I wonder if any project has been thinking about using GraphQL. I
haven't
find any mention or pointers about it.

GraphQL takes a complete different approach compared to REST. So
we can
finally forget about REST API Description languages
(OpenAPI/Swagger/WSDL/WADL/JSON-API/ETC) and HATEOS (the hypermedia
approach which doesn't describe how to use it).

So, once passed the point where 'REST vs GraphQL' is like
comparing SQL
and no-SQL DBMS and therefore have different applications, there
are no
doubt the complexity of most OpenStack projects are good
candidates for
GraphQL.

Besides topics such as efficiency, decoupling, no version management
need there many other powerful features such as API Schema out of the
box and better automation down that track.

It looks like the dream of a conduit between API services and
consumers
might have finally come true so we could move-on an worry about other
things.

So has anyone already starting looking into it?

[1]

https://www.openstack.org/videos/boston-2017/building-modern-apis-with-graphql
[2] http://graphql.org



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



--
Gilles Dubreuil
Senior Software Engineer - Red Hat - Openstack DFG Integration
Email: gil...@redhat.com
GitHub/IRC: gildub
Mobile: +61 400 894 219

__
OpenStack Development Mailing 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] REST limitations and GraghGL inception?

[Gilles Dubreuil]

Hi,

Remember Boston's Summit presentation [1] about GraphQL [2] and how it 
addresses REST limitations.
I wonder if any project has been thinking about using GraphQL. I haven't 
find any mention or pointers about it.


GraphQL takes a complete different approach compared to REST. So we can 
finally forget about REST API Description languages 
(OpenAPI/Swagger/WSDL/WADL/JSON-API/ETC) and HATEOS (the hypermedia 
approach which doesn't describe how to use it).


So, once passed the point where 'REST vs GraphQL' is like comparing SQL 
and no-SQL DBMS and therefore have different applications, there are no 
doubt the complexity of most OpenStack projects are good candidates for 
GraphQL.


Besides topics such as efficiency, decoupling, no version management 
need there many other powerful features such as API Schema out of the 
box and better automation down that track.


It looks like the dream of a conduit between API services and consumers 
might have finally come true so we could move-on an worry about other 
things.


So has anyone already starting looking into it?

[1] 
https://www.openstack.org/videos/boston-2017/building-modern-apis-with-graphql

[2] http://graphql.org



__
OpenStack Development Mailing 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] Adding a SDK to developer.openstack.org pages

[Gilles Dubreuil]

On 06/04/18 22:37, Jeremy Stanley wrote:

On 2018-04-06 12:00:24 +1000 (+1000), Gilles Dubreuil wrote:

I'd like to update the developer.openstack.org to add details about a new
SDK.

What would be the corresponding repo? My searches landed me into
https://docs.openstack.org/doc-contrib-guide/ which is about updating the
docs.openstack.org but not developer.openstack.org. Is the developer section
inside the docs section?

Looks like we could do a better job of linking to the relevant git
repositories from some documents.

I think the file you're looking for is probably:

 https://git.openstack.org/cgit/openstack/api-site/tree/www/index.html

Happy hacking!


That's the one!

Thank you



__
OpenStack Development Mailing 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] Adding a SDK to developer.openstack.org pages

[Gilles Dubreuil]

Hi,

I'd like to update the developer.openstack.org to add details about a 
new SDK.


What would be the corresponding repo? My searches landed me into 
https://docs.openstack.org/doc-contrib-guide/ which is about updating 
the docs.openstack.org but not developer.openstack.org. Is the developer 
section inside the docs section?


Thanks,
Gilles


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

Re: [openstack-dev] [Openstack-sigs] [all][api] POST /api-sig/news

[Gilles Dubreuil]

On 20/03/18 08:26, Michael McCune wrote:



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




So summarize and clarify, we are talking about SDK being able
to build their interface to Openstack APIs in an automated way
but statically from API Schema generated by every project.
Such API Schema is already built in memory during API
reference documentation generation and could be saved in JSON
format (for instance) (see [5]).


What do you see as the current roadblocks preventing this work from
continuing to make progress?



Gilles, i'm very curious about how we can help as well.

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


Hi Michael,

Thank you very much for jumping in. Your interest shows the demand for 
such feature, which is what we need the most at the moment. The more 
people the better the momentum and likelihood of getting more help. 
Let's blow the horn!


As you probably already know, the real work is Graham's PR [1] where the 
magic is going to happen and where you can help.
Graham who has been involved and working with the Sphinx library offered 
to 'dump' the API schema which is already in memory, what I call the 
de-facto API Schema, which is needed to generate the API Reference 
guides. So instead of asking developers of each project to change their 
habits and write an API schema up front, it seemed easier to just use 
the current work flow in place with the documentation (API Ref) and 
generate the API schema which can be stored in every project Git.


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

Cheers,
Gilles




thanks for bringing this up again,

peace o/



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


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

[Gilles Dubreuil]

On 16/03/18 19:55, Chris Dent wrote:


Meta: When responding to lists, please do not cc individuals, just
repond to the list. Thanks, response within.



+1


On Fri, 16 Mar 2018, Gilles Dubreuil wrote:

In order to continue and progress on the API Schema guideline [1] as 
mentioned in [2] to make APIs more machine-discoverable and also 
discussed during [3].


Unfortunately until a new or either a second meeting time slot has 
been allocated,  inconveniently for everyone, have to be done by emails.


I'm sorry that the meeting time is excluding you and others, but our
efforts to have either a second meeting or to change the time have
met with limited response (except from you).

In any case, the meeting are designed to be checkpoints where we
resolve stuck questions and checkpoint where we are on things. It is
better that most of the work be done in emails and on reviews as
that's the most inclusive, and is less dependent on time-related
variables.


I agree in general most of our work can be done "off-line" meanwhile 
there are times were interaction is preferable especially in early 
phases of conception in order to provide appropriate momentum.




So moving the discussion about schemas here is the right thing and
the fact that it hasn't happened (until now) is the reason for what
appears to be a rather lukewarm reception from the people writing
the API-SIG newsletter: if there's no traffic on either the gerrit
review or here in email then there's no evidence of demand. You're
asserting here that there is; that's great.


Yes, and some of those believers are to either jump-on this thread or 
add comment to related reviews in order to confirm this.
Of course one cannot expect them to be active participants as I'm 
delegated to be the interface for this feature.




Of course new features have to be decided (voted) by the community 
but how does that work when there are not enough people voting in?
It seems unfair to decide not to move forward and ignore the request 
because the others people interested are not participating at this 
level.


In a world of limited resources we can't impose work on people. The
SIG is designed to be a place where people can come to make progress
on API-related issues. If people don't show up, progress can't be
made. Showing up doesn't have to mean show up at an IRC meeting. In
fact I very much hope that it never means that. Instead it means
writing things (like your email message) and seeking out
collaborators to push your idea(s) forward.


This comforts me about more automation to help ;)


It's very important  to consider the fact "I" am representing more 
than just myself but an Openstack integration team, whose members are 
supporting me, and our work impacts others teams involved in their 
open source product consuming OpenStack. I'm sorry if I haven't made 
this more clear from the beginning, I guess I'm still learning on the 
particiaption process. So from now on, I'm going to use "us" instead.


Can some of those "us" show up on the mailing list, the gerrit
reviews, and prototype work that Graham has done?


Yes absolutely, as I just mentioned above.



Also from discussions with other developers from AT (OpenStack 
summit in Sydney) and SAP (Misty project) who are already using 
automation to consume APIs, this is really needed.


Them too.


For the first ones, I've tried without success (tweeter), unfortunately 
I don't have their email addresses, let me ask Openstack Organizers if 
they can pass it along...

I'll poke the second ones.



I've also mentioned the now known fact that no SDK has full time 
resources to maintain it (which was the initial trigger for us) more 
automation is the only sustainable way to continue the journey.


Finally how can we dare say no to more automation? Unless of course, 
only artisan work done by real hipster is allowed ;)


Nobody is saying no to automation (as far as I'm aware). Some people
(e.g., me, but not just me) are saying "unless there's an active
community to do this work and actively publish about it and the
related use cases that drive it it's impossible to make it a
priority". Some other people (also me, but not just me) are also
saying "schematizing API client generation is not my favorite thing"
but that's just a personal opinion and essentially meaningless
because yet other people are saying "I love API schema!".

What's missing, though, is continuous enagement on producing
children of that love.


Well I believe, maybe because I kind of belong to the second group, that 
the whole API definition is upside-down.
If we had API schema from day one we would have more children of love 
and many many more grand children of Openstack users.





Furthermore, API-Schema will be problematic for services that use 
microversions. If you have some insight or opinions on this, please 
add your comments to that review.


I understand microvers

Re: [openstack-dev] [api] APAC-friendly API-SIG meeting times

[Gilles Dubreuil]

On 17/03/18 02:53, Ed Leafe wrote:

On Mar 15, 2018, at 10:31 PM, Gilles Dubreuil <gdubr...@redhat.com> wrote:

Any chance we can progress on this one?

I believe there are not enough participants to split the API SIG meeting in 2, 
and also more likely because of the same lack of people across the 2 it could 
make it pretty inefficient. Therefore I think changing the main meeting time to 
another might be better but I could be wrong.

Anyway in all cases I can't make progress with a meeting in the middle of the 
night for me so I would appreciate if we could re-activate this discussion.

What range of times would work for you?

-- Ed Leafe





I can do very early (like 6am), or alternatively late (10pm) if needed 
to avoid others to be in the red zone:

https://www.timeanddate.com/worldclock/meetingtime.html?day=31=3=2018=240=195=137=0

Of course assuming we're talking about spreading across the globe for a 
single meeting, otherwise that would be easier as I'm quite flex.




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

[Gilles Dubreuil]

 you find something that's not quite right, 
submit a patch [6] to fix it.
* Have you done something for which you think guidance would have made 
things easier but couldn't find any? Submit a patch and help others [6].


# Newly Published Guidelines

None this week.

# API Guidelines Proposed for Freeze

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

None this week.

# Guidelines Currently Under Review [3]

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

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

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

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

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

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

  https://review.openstack.org/444892

# Highlighting your API impacting issues

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


To learn more about the API SIG mission and the work we do, see our 
wiki page [4] and guidelines [2].


Thanks for reading and see you next week!

# References

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

[4] https://wiki.openstack.org/wiki/API_SIG
[5] https://bugs.launchpad.net/openstack-api-wg
[6] https://git.openstack.org/cgit/openstack/api-wg
[7] 
http://specs.openstack.org/openstack/api-wg/guidelines/http.html#http-methods
[8] 
http://lists.openstack.org/pipermail/openstack-dev/2018-March/128023.html


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



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


--
Gilles Dubreuil
Senior Software Engineer, Openstack DFG Integration
Mobile: +61 400 894 219
Email: gil...@redhat.com
GitHub/IRC: gildub


__
OpenStack Development Mailing 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] APAC-friendly API-SIG meeting times

[Gilles Dubreuil]

Hi,

Any chance we can progress on this one?

I believe there are not enough participants to split the API SIG meeting 
in 2, and also more likely because of the same lack of people across the 
2 it could make it pretty inefficient. Therefore I think changing the 
main meeting time to another might be better but I could be wrong.


Anyway in all cases I can't make progress with a meeting in the middle 
of the night for me so I would appreciate if we could re-activate this 
discussion.


Thanks,
Gilles


On 13/12/17 02:22, Ed Leafe wrote:

Re-sending this in the hope of getting more responses. If you’re in the APAC 
region and interested in contributing to our discussions, please indicate your 
preferences on the link below.


That brought up another issue: the current meeting time for the API-SIG is 
1600UTC, which is not very convenient for APAC contributors. Gilles is in 
Australia, and so it was the middle of the night for him! As one of the goals 
for the API-SIG is to expand our audience and membership, edleafe committed to 
seeing if there is an available meeting slot at 2200UTC, which would be 
convenient for APAC, and still early enough for US people to attend. If an 
APAC-friendly meeting time would be good for you, please keep an eye out on the 
mailing list for an announcement if we are able to set that up, and then please 
attend and participate!

Looking at the current meeting schedule, there are openings at 2200UTC  on 
Tuesday, Wednesday, and Thursday mornings in APAC (Monday, Tuesday, and 
Wednesday afternoons in the US).

I’ve set up a doodle so that people can record their preferences:

https://doodle.com/poll/bec9gfff38zvh3ud

If you’re interested in attending API-SIG meetings, please fill out the form at 
that URL with your preferences. I’ll summarize the results at the next API-SIG 
meeting.


-- Ed Leafe






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


-- Ed Leafe






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


--
Gilles Dubreuil
Senior Software Engineer, Openstack DFG Integration
Mobile: +61 400 894 219
Email: gil...@redhat.com
GitHub/IRC: gildub



__
OpenStack Development Mailing 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-wg] [api] [cinder] [nova] Support specify action name in request url

[Gilles Dubreuil]

As you said RESTful is not a standard but brings guidelines of good 
practices. Which in turn doesn't preclude adding ideas, as long as 
respecting RESTful approach. So we get from both sides.


Therefore a good schema structure adds to a de-facto standard, once the 
practice is commonly used.



On 02/02/18 19:11, Duncan Thomas wrote:
So I guess my question here is why is being RESTful good? Sure it's 
(very, very loosely) a standard, but what are the actual advantages? 
Standards come and go, what we want most of all is a good quality, 
easy to use API.


I'm not saying that going RESTful is wrong, but I don't see much 
discussion about what the advantages are, only about how close we are 
to implementing it.


On 1 Feb 2018 10:55 pm, "Ed Leafe" > wrote:


On Jan 18, 2018, at 4:07 AM, TommyLike Hu > wrote:

>    Recently We found an issue related to our OpenStack action
APIs. We usually expose our OpenStack APIs by registering them to
our API Gateway (for instance Kong [1]), but it becomes very
difficult when regarding to action APIs. We can not register and
control them seperately because them all share the same request
url which will be used as the identity in the gateway service, not
say rate limiting and other advanced gateway features, take a look
at the basic resources in OpenStack

We discussed your email at today’s API-SIG meeting [0]. This is an
area that is always contentious in the RESTful world. Actions,
tasks, and state changes are not actual resources, and in a pure
REST design they should never be part of the URL. Instead, you
should POST to the actual resource, with the desired action in the
body. So in your example:

> URL:/volumes/{volume_id}/action
> BODY:{'extend':{}}

the preferred way of achieving this is:

URL: POST /volumes/{volume_id}
BODY: {‘action’: ‘extend’, ‘params’: {}}

The handler for the POST action should inspect the body, and call
the appropriate method.

Having said that, we realize that a lot of OpenStack services have
adopted the more RPC-like approach that you’ve outlined. So while
we strongly recommend a standard RESTful approach, if you have
already released an RPC-like API, our advice is:

a) avoid having every possible verb in the URL. In other words,
don’t use:
  /volumes/{volume_id}/mount
  /volumes/{volume_id}/umount
  /volumes/{volume_id}/extend
This moves you further into RPC-land, and will make updating your
API to a more RESTful design more difficult.

b) choose a standard term for the item in the URL. In other words,
always use ‘action’ or ‘task’ or whatever else you have adopted.
Don’t mix terminology. Then pass the action to perform, along with
any parameters in the body. This will make it easier to transition
to a RESTful design by later updating the handlers to first
inspect the BODY instead of relying upon the URL to determine what
action to perform.

You might also want to contact the Kong developers to see if there
is a way to work with a RESTful API design.

-- Ed Leafe

[0]

http://eavesdrop.openstack.org/meetings/api_sig/2018/api_sig.2018-02-01-16.02.log.html#l-28






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

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




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


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

Re: [openstack-dev] [api] APAC-friendly API-SIG meeting times

[Gilles Dubreuil]

Obviously, I'm interested and I voted.

Thanks,
Gilles


On 13/12/17 02:22, Ed Leafe wrote:

Re-sending this in the hope of getting more responses. If you’re in the APAC 
region and interested in contributing to our discussions, please indicate your 
preferences on the link below.


That brought up another issue: the current meeting time for the API-SIG is 
1600UTC, which is not very convenient for APAC contributors. Gilles is in 
Australia, and so it was the middle of the night for him! As one of the goals 
for the API-SIG is to expand our audience and membership, edleafe committed to 
seeing if there is an available meeting slot at 2200UTC, which would be 
convenient for APAC, and still early enough for US people to attend. If an 
APAC-friendly meeting time would be good for you, please keep an eye out on the 
mailing list for an announcement if we are able to set that up, and then please 
attend and participate!

Looking at the current meeting schedule, there are openings at 2200UTC  on 
Tuesday, Wednesday, and Thursday mornings in APAC (Monday, Tuesday, and 
Wednesday afternoons in the US).

I’ve set up a doodle so that people can record their preferences:

https://doodle.com/poll/bec9gfff38zvh3ud

If you’re interested in attending API-SIG meetings, please fill out the form at 
that URL with your preferences. I’ll summarize the results at the next API-SIG 
meeting.


-- Ed Leafe






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


-- Ed Leafe






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


--
Gilles Dubreuil
Senior Software Engineer, Openstack DFG Integration
Mobile: +61 400 894 219
Email: gil...@redhat.com
GitHub/IRC: gildub



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

Re: [openstack-dev] [api] api-sig weekly meeting time change request

[Gilles Dubreuil]

On 05/12/17 01:55, michael mccune wrote:

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

Hi,

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

To give a chance for those down under to attend?


hey Gilles,

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


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




Two meetings makes sense to avoid stretching the first one out of normal 
hours (not even talking about business hours).
Although I'm not sure how active is the APAC region on either producer 
or consumer sides. Well there is me at least, +1 for the survey.



Thanks,
Gilles


peace o/

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



Cheers,
Gilles

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








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

Re: [openstack-dev] [api] api-sig weekly meeting time change request

[Gilles Dubreuil]

Never mind, I just the schedule document [1].

I'll push a request there.

[1] http://eavesdrop.openstack.org/#API_Working_Group


On 04/12/17 14:26, Gilles Dubreuil wrote:

Hi,

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

To give a chance for those down under to attend?

Cheers,
Gilles

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




--
Gilles Dubreuil
Senior Software Engineer, Openstack DFG Integration
Mobile: +61 400 894 219
Email: gil...@redhat.com
GitHub/IRC: gildub



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

[openstack-dev] [api] api-sig weekly meeting time change request

[Gilles Dubreuil]

Hi,

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

To give a chance for those down under to attend?

Cheers,
Gilles

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



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

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

[Gilles Dubreuil]

On 02/12/17 04:26, Chris Dent wrote:

On Fri, 1 Dec 2017, Gilles Dubreuil wrote:


Hi Chris,

Thank you for those precious details.

I just added https://review.openstack.org/#/c/524467/ to augment the 
existing guidelines [2] and to get started with the API Schema 
(consumption) topic.


Cool, thanks for doing that. I suspect comments should start rolling in
next week.

It would be great if that topic could be added to the agenda, can you 
please help?


Feel free to add any topics that you (or anyone else) wants to the
API-SIG agenda: https://wiki.openstack.org/wiki/Meetings/API-SIG#Agenda


Thanks!



If you don't have and can't get editing rights on the wiki, let me
know and I can make the addition.



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


--
Gilles Dubreuil
Senior Software Engineer, Openstack DFG Integration
Mobile: +61 400 894 219
Email: gil...@redhat.com
GitHub/IRC: gildub


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

[Gilles Dubreuil]

Hi Chris,

Thank you for those precious details.

I just added https://review.openstack.org/#/c/524467/ to augment the 
existing guidelines [2] and to get started with the API Schema 
(consumption) topic.


It would be great if that topic could be added to the agenda, can you 
please help?


Cheers,
Gilles


On 01/12/17 04:17, Chris Dent wrote:


Greetings OpenStack community,

With this week, the API-SIG had its first real meeting since before 
the summit in Sydney. Travel and US holidays have meant not enough 
people were around to make a meeting worth having.


This week there were. First order of business was to officially make 
Dmitry Tantsur "core". In the context of the API-SIG that means he has 
the power to freeze and merge guidelines, run the meetings, and write 
this newsletter. For many months he's been providing excellent reviews 
on the guidelines that the SIG produces, and excellent and regular 
input in the discussions we have during the meetings. Welcome Dmitry!


This week's excellent discussion [5] was centered around effective 
ways of dealing with versions in client code. One of the things that 
was remarkable about the conversation is that many things that a few 
years ago were often subject to debate are now fairly commonly 
accepted as good behavior: service discovery, version discovery, 
microversions, microversioning per-request (rather than per-session). 
As the SIG expands into working with SDK developers, being able to 
talk about and demonstrate these behaviors as "normal" will be very 
useful.


There has not, of late, been much progress on new (or improved) 
guidelines, but there are plenty of opportunities. Those of us who are 
regulars are full of good intentions but in recent months have had too 
many other obligations. If you are interested in helping out there are 
three entry points:


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


# Newly Published Guidelines

None this week.

# API Guidelines Proposed for Freeze

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

None this week

# Guidelines Currently Under Review [3]

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

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

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

  https://review.openstack.org/444892

# Highlighting your API impacting issues

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


To learn more about the API SIG mission and the work we do, see our 
wiki page [4] and guidelines [2].


Thanks for reading and see you next week!

# References

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

[4] https://wiki.openstack.org/wiki/API_SIG
[5] 
http://eavesdrop.openstack.org/meetings/api_sig/2017/api_sig.2017-11-30-16.01.log.html#l-71

[6] https://bugs.launchpad.net/openstack-api-wg
[7] https://git.openstack.org/cgit/openstack/api-wg

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



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


--
Gilles Dubreuil
Senior Software Engineer, Openstack DFG Integration
Mobile: +61 400 894 219
Email: gil...@redhat.com
GitHub/IRC: gildub


__
OpenStack Development Mailing 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] [E] Re: nova diagnostics in client library/SDK

[Gilles Dubreuil]

On 01/12/17 03:47, Monty Taylor wrote:

On 11/29/2017 12:49 PM, Gordon, Kent S wrote:


On Tue, Nov 28, 2017 at 2:15 PM, Monty Taylor <mord...@inaugust.com 
<mailto:mord...@inaugust.com>> wrote:


    On 11/03/2017 11:31 AM, Gordon, Kent S wrote:

    Do any of the python client libraries implement the nova
    diagnostics API?

https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.openstack.org_wiki_Nova-5FVM-5FDiagnostics=DwIGaQ=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ=Xkn6r0Olgrmyl97VKakpX0o-JiB_old4u22bFbcLdRo=p2ULfonZvWd4C82lmFExdHuyh-NeUTzyu-q5M0kTDNg=RI4HTKLenL00VdvmCqFfjr5IMJV4HfWW_UkH1R1BWSU=
<https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.openstack.org_wiki_Nova-5FVM-5FDiagnostics=DwIGaQ=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ=Xkn6r0Olgrmyl97VKakpX0o-JiB_old4u22bFbcLdRo=p2ULfonZvWd4C82lmFExdHuyh-NeUTzyu-q5M0kTDNg=RI4HTKLenL00VdvmCqFfjr5IMJV4HfWW_UkH1R1BWSU=>


    Not to my knowledge, no. However, adding support for it should be
    easy enough to accomplish and would be a welcome addition.

    This is the API you're talking about?

https://urldefense.proofpoint.com/v2/url?u=https-3A__developer.openstack.org_api-2Dref_compute_-23servers-2Ddiagnostics-2Dservers-2Ddiagnostics=DwIGaQ=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ=Xkn6r0Olgrmyl97VKakpX0o-JiB_old4u22bFbcLdRo=p2ULfonZvWd4C82lmFExdHuyh-NeUTzyu-q5M0kTDNg=2GH64mANdI_uV67Gt2YvoBJlR7uHHl17EB-URrOMN-E=
<https://urldefense.proofpoint.com/v2/url?u=https-3A__developer.openstack.org_api-2Dref_compute_-23servers-2Ddiagnostics-2Dservers-2Ddiagnostics=DwIGaQ=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ=Xkn6r0Olgrmyl97VKakpX0o-JiB_old4u22bFbcLdRo=p2ULfonZvWd4C82lmFExdHuyh-NeUTzyu-q5M0kTDNg=2GH64mANdI_uV67Gt2YvoBJlR7uHHl17EB-URrOMN-E=>

yes

    If you feel like hacking on it, a patch to
    openstack/python-openstacksdk would be the best way to go.

    However, this is microversion-protected, and this would be the first
    such feature in the SDK. So if diving that far down the rabbithole
    sounds like too much, either bug me until I get around to it - or do
    as much of it as makes sense (like adding a Resource class based on
    openstack.resource2) but ignore the microversion bit and I can help
    finish it off.


It has been a while since I did a lot of development.  Let me see how 
far I can get.


No worries - I can also just knock it out for you ... mostly wanted to 
be welcoming in case you *wanted* to add it. (it's no fun if I swoop 
in and steal people's hacking projects)





Well Misty does:

htps://github.com/flystack/misty/blob/master/lib/misty/openstack/nova/nova_v2_1.rb#L58

Meanwhile I've never tested that part so any feedback more than welcome 
and I'll be happy to promptly help if there are any issues.


Cheers,
Gilles

PS: This is exactly why wee need to get more attention on the `API 
Schema` because of the *desperate* need for more APIs automation!



__ 


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


--
Gilles Dubreuil
Senior Software Engineer, Openstack DFG Integration
Mobile: +61 400 894 219
Email: gil...@redhat.com
GitHub/IRC: gildub



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

Re: [openstack-dev] [docs] "Show all" buttons broken for api-guide

[Gilles Dubreuil]

Hi Andreas,

So wasn't just me, thanks.

https://bugs.launchpad.net/openstack-doc-tools/+bug/1734075

- Gil


On 23/11/17 18:39, Andreas Jaeger wrote:

On 2017-11-23 08:06, Gilles Dubreuil wrote:


On 23/11/17 18:03, Gilles Dubreuil wrote:

Hi,

Is that just me?

The "Show all" button for any of the
"https://developer.openstack.org/api-guide/quick-start/*; pages is

*not*


working.
It normally expands (and collapses with the "Hide all" button) all the
resources for the specific guide.

please file a bugreport against os-api-ref, for details see
https://docs.openstack.org/os-api-ref/latest/contributing.html

andreas


--
Gilles Dubreuil
Senior Software Engineer, Openstack DFG Integration
Mobile: +61 400 894 219
Email: gil...@redhat.com
GitHub/IRC: gildub



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

Re: [openstack-dev] [docs] "Show all" buttons broken for api-guide

[Gilles Dubreuil]

On 23/11/17 18:03, Gilles Dubreuil wrote:

Hi,

Is that just me?

The "Show all" button for any of the 
"https://developer.openstack.org/api-guide/quick-start/*; pages is 


*not*


working.
It normally expands (and collapses with the "Hide all" button) all the 
resources for the specific guide.


--
Gil



--
Gilles Dubreuil
Senior Software Engineer, Openstack DFG Integration
Mobile: +61 400 894 219
Email: gil...@redhat.com
GitHub/IRC: gildub



__
OpenStack Development Mailing 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] [docs] "Show all" buttons broken for api-guide

[Gilles Dubreuil]

Hi,

Is that just me?

The "Show all" button for any of the 
"https://developer.openstack.org/api-guide/quick-start/*; pages is working.
It normally expands (and collapses with the "Hide all" button) all the 
resources for the specific guide.


--
Gil


__
OpenStack Development Mailing 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] APIs schema consumption discussion

[Gilles Dubreuil]

On 23/11/17 07:04, Graham Hayes wrote:


On 16/11/17 01:56, Gilles Dubreuil wrote:

On 15/11/17 03:07, Doug Hellmann wrote:

Excerpts from Gilles Dubreuil's message of 2017-11-14 10:15:02 +1100:

Hi,

Follow-up conversation from our last "API SIG feedback and discussion
session" at Sydney Summit [1], about APIs schema consumption.

Let's summarize the current situation.

Each OpenStack project has an "API-source" folder containing RST files
describing its API structure ([2] for example). Those files are in turn
consumed by the Sphinx library to generate each project's API reference
manual which are then available in the API guide documentation [3]. Such
effort has made the APIs harmoniously consistent across all OpenStack
projects and has also created a "de-facto" API schema.

While the RST files are used by the documentation, they are not readily
consumable by SDKs. Of course the APIs schema can be extracted by web
crawling the Reference guides, which in turn can be used by any
language. Such approach works [4] and help the Misty project [5] (Ruby
SDK) started with more languages to exploit the same approach.

Therefore to allow better automation, the next step would be to have the
APIs schema stored directly into each project's repo so the SDKs could
consume them straight from the source. This is why we've started
discussing how to have the schema either extracted from the RST files or
alternatively having the API described directly into its own file. The
latter would provide a different work flow: "Yaml -> RST -> Reference
doco" instead of "RST -> Reference doco -> Yaml".

So the question at this stage is: "Which of the work flow to choose
from?".

To clarify the needs, it's important to note that we found out that none
of the SDKs project, besides OSC (OpenStack Client, thanks to Dean),
have full time working teams to maintain each SDK, which besides the
natural structural complexity inherent to the cloud context, makes the
task of keeping a SDK up to date very difficult. Especially as projects
moves forward. Automatically managing Openstack APIs is inevitable for
consumers. Another example/feedback was provided by the presenters of
"AT’s Strategy for Implementing a Next Generation OpenStack Cloud"
session during Sydney Keynotes, as they don't handle the Openstack API
manually!

APIs consumers and providers, any thoughts?

[1]
https://www.openstack.org/summit/sydney-2017/summit-schedule/events/20442/api-sig-feedback-and-discussion-session

[2] https://github.com/openstack/nova/tree/master/api-guide/source
[3] https://developer.openstack.org/api-guide/quick-start/index.html
[4] https://github.com/flystack/openstack-APIs
[5] https://github.com/flystack/misty

Regards,
Gilles

Please do not build something that looks like SOAP based on parsing RST
files. Surely we can at least work directly from JSONSchema inputs?

I'm glad you said that :).
Working directly from YAML or JSON files (format to be discussed) to
maintain the schema seems (to me too) the natural approach.

Meaning every project to change current practice: maintain the schema
files instead of maintaining RST files.
I suppose there has been suggestion to do it the other way (parse the
RST files) because of the latter impact on the current practice, but it
shouldn't be a blocker.

Gil


When I was talking to Gil about it, I suggested writing a new sphinx /
docutils formatter. I am not sure how feasible it would be, but it could
be possible (as sphinx has the whole page tree in memory when writing it
out, we may be able to output it in some sort of structured format.


That makes sense if the tree is already loaded, could you please provide 
a pointer?




I would be hesitant to change how we write docs - this change took long
enough to get in place, and the ability to add / remove bits to suit
different projects is a good thing. Pages like [1] would be hard to do
in a standard machine readable format, and I think they definitely make
the docs better.


First off, let me insist: "The reference guides are absolutely great". I 
guess that's the ransom of the success! :)
So, from outside (as a blackbox) the doc generation process, it made 
sense to have a work flow going from a structured tree to the docs, 
meanwhile if the same information can be obtained from the existing that 
sounds good.




- Graham

1 - https://developer.openstack.org/api-ref/compute/#servers-servers



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


--
Gil

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

[Gilles Dubreuil]

Hi,

Any chance the meeting this week to be moved on the Thursday instead?

Cheers,
Gilles


On 17/11/17 03:12, Ed Leafe wrote:

Greetings OpenStack community,

No meeting this week, as people are still straggling back after the Sydney 
summit. There will also be no meeting next week, due to the US Thanksgiving 
holiday. So I guess we'll see you all again in December!

# Newly Published Guidelines

None this week.

# API Guidelines Proposed for Freeze

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

None this week

# Guidelines Currently Under Review [3]

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

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

# Highlighting your API impacting issues

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

To learn more about the API SIG mission and the work we do, see our wiki page 
[4] and guidelines [2].

Thanks for reading and see you next week!

# References

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


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

-- Ed Leafe






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


--
Gilles Dubreuil
Senior Software Engineer, Openstack DFG Integration
Mobile: +61 400 894 219
Email: gil...@redhat.com
GitHub/IRC: gildub



__
OpenStack Development Mailing 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] APIs schema consumption discussion

[Gilles Dubreuil]

On 15/11/17 03:07, Doug Hellmann wrote:

Excerpts from Gilles Dubreuil's message of 2017-11-14 10:15:02 +1100:

Hi,

Follow-up conversation from our last "API SIG feedback and discussion
session" at Sydney Summit [1], about APIs schema consumption.

Let's summarize the current situation.

Each OpenStack project has an "API-source" folder containing RST files
describing its API structure ([2] for example). Those files are in turn
consumed by the Sphinx library to generate each project's API reference
manual which are then available in the API guide documentation [3]. Such
effort has made the APIs harmoniously consistent across all OpenStack
projects and has also created a "de-facto" API schema.

While the RST files are used by the documentation, they are not readily
consumable by SDKs. Of course the APIs schema can be extracted by web
crawling the Reference guides, which in turn can be used by any
language. Such approach works [4] and help the Misty project [5] (Ruby
SDK) started with more languages to exploit the same approach.

Therefore to allow better automation, the next step would be to have the
APIs schema stored directly into each project's repo so the SDKs could
consume them straight from the source. This is why we've started
discussing how to have the schema either extracted from the RST files or
alternatively having the API described directly into its own file. The
latter would provide a different work flow: "Yaml -> RST -> Reference
doco" instead of "RST -> Reference doco -> Yaml".

So the question at this stage is: "Which of the work flow to choose from?".

To clarify the needs, it's important to note that we found out that none
of the SDKs project, besides OSC (OpenStack Client, thanks to Dean),
have full time working teams to maintain each SDK, which besides the
natural structural complexity inherent to the cloud context, makes the
task of keeping a SDK up to date very difficult. Especially as projects
moves forward. Automatically managing Openstack APIs is inevitable for
consumers. Another example/feedback was provided by the presenters of
"AT’s Strategy for Implementing a Next Generation OpenStack Cloud"
session during Sydney Keynotes, as they don't handle the Openstack API
manually!

APIs consumers and providers, any thoughts?

[1]
https://www.openstack.org/summit/sydney-2017/summit-schedule/events/20442/api-sig-feedback-and-discussion-session
[2] https://github.com/openstack/nova/tree/master/api-guide/source
[3] https://developer.openstack.org/api-guide/quick-start/index.html
[4] https://github.com/flystack/openstack-APIs
[5] https://github.com/flystack/misty

Regards,
Gilles

Please do not build something that looks like SOAP based on parsing RST
files. Surely we can at least work directly from JSONSchema inputs?


I'm glad you said that :).
Working directly from YAML or JSON files (format to be discussed) to 
maintain the schema seems (to me too) the natural approach.


Meaning every project to change current practice: maintain the schema 
files instead of maintaining RST files.
I suppose there has been suggestion to do it the other way (parse the 
RST files) because of the latter impact on the current practice, but it 
shouldn't be a blocker.


Gil



Doug

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


--
Gilles Dubreuil
Senior Software Engineer, Openstack DFG Integration
Mobile: +61 400 894 219
Email: gil...@redhat.com
GitHub/IRC: gildub



__
OpenStack Development Mailing 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] APIs schema consumption discussion

[Gilles Dubreuil]

Hi,

Follow-up conversation from our last "API SIG feedback and discussion 
session" at Sydney Summit [1], about APIs schema consumption.


Let's summarize the current situation.

Each OpenStack project has an "API-source" folder containing RST files 
describing its API structure ([2] for example). Those files are in turn 
consumed by the Sphinx library to generate each project's API reference 
manual which are then available in the API guide documentation [3]. Such 
effort has made the APIs harmoniously consistent across all OpenStack 
projects and has also created a "de-facto" API schema.


While the RST files are used by the documentation, they are not readily 
consumable by SDKs. Of course the APIs schema can be extracted by web 
crawling the Reference guides, which in turn can be used by any 
language. Such approach works [4] and help the Misty project [5] (Ruby 
SDK) started with more languages to exploit the same approach.


Therefore to allow better automation, the next step would be to have the 
APIs schema stored directly into each project's repo so the SDKs could 
consume them straight from the source. This is why we've started 
discussing how to have the schema either extracted from the RST files or 
alternatively having the API described directly into its own file. The 
latter would provide a different work flow: "Yaml -> RST -> Reference 
doco" instead of "RST -> Reference doco -> Yaml".


So the question at this stage is: "Which of the work flow to choose from?".

To clarify the needs, it's important to note that we found out that none 
of the SDKs project, besides OSC (OpenStack Client, thanks to Dean), 
have full time working teams to maintain each SDK, which besides the 
natural structural complexity inherent to the cloud context, makes the 
task of keeping a SDK up to date very difficult. Especially as projects 
moves forward. Automatically managing Openstack APIs is inevitable for 
consumers. Another example/feedback was provided by the presenters of 
"AT’s Strategy for Implementing a Next Generation OpenStack Cloud" 
session during Sydney Keynotes, as they don't handle the Openstack API 
manually!


APIs consumers and providers, any thoughts?

[1] 
https://www.openstack.org/summit/sydney-2017/summit-schedule/events/20442/api-sig-feedback-and-discussion-session

[2] https://github.com/openstack/nova/tree/master/api-guide/source
[3] https://developer.openstack.org/api-guide/quick-start/index.html
[4] https://github.com/flystack/openstack-APIs
[5] https://github.com/flystack/misty

Regards,
Gilles

__
OpenStack Development Mailing 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-WG] Schema like aws-sdk and API capabilities discovery

[Gilles Dubreuil]

On 15/03/17 01:21, Chris Dent wrote:

On Fri, 10 Mar 2017, Gilles Dubreuil wrote:

On a different list we're talking about improving/new features on the 
client side of OpenStack APIs and this one came up (please see below).


Although API-ref is doing a great job, I believe the question is: Can 
we achieve an equivalent of aws-sdk? For instance could we have each 
project's API to publish its own schema?


I'm not sure if I fully understand what you're asking about or for?
Is the request that the various OpenStack APIs publish some kind of
structure API description (using something like
https://www.openapis.org/ )? Various people did some exploration of
this, trying to use swagger (as it was called then) to help with
documenting the APIs. What we discovered at the time was a) using
swagger on existing APIs didn't work as well as using it when
creating new ones, b) microversions and swagger don't play as well
together as we'd like.

If you mean something like WADL or WSDL, the general decision has
been that such things only work if there is sufficient tooling on
the client side, and we don't want to require our users to have that
kind of tooling. Instead we'd prefer that the APIs converge toward
being relatively comprehensible and usable by humans.

If you mean something else (like perhaps using json-home?) please
explain what it is.

Yes I meant one of such approaches to be able to retrieve an API 
structure dynamically.
I'm not familiar with WADL or WSDL, but looking at it, I don't see why 
it imposes anything on the client side.
What's precludes a client to make a request without having retrieved the 
API structure before end?


Anyway, my approach has been very practical, sort of bottom up, using 
API-ref to web crawl the API structures.


Look at this to get an idea: 
https://github.com/flystack/misty/blob/master/lib/misty/openstack/nova/nova_v2_1.rb


From that experience I believe we must be able to go to the next level.
In any case, the API-WG has not taken upon itself to make any.


assertions or statements about facilitating client creation
automation. Our position is that the APIs should be something you
can consume without a great deal of intermediation and we work
towards ensuring that. That's not a fixed decision, but is certainly
the case for now.


Yes and as I said API structures don't have to be used but if available 
then we could enter a new automation level.




I suppose this would fit under the API-WG umbrella. Would that be 
correct? Could someone in the group provide feedback please?


It could well do if we can figure out what we're all talking about
:)


Thanks for taking the time ;)



Trying to find current work around this, I can see the API 
capabilities discovery [1] & [2] is great but, it seems to me that 
part of the challenge for the WG is a lack of schema too. Wouldn't it 
make sense to have a standardized way for all services APIs (at least 
on the public side) to publish their schema (including 
version/microversions details) before going any further?


The capabilities work is oriented towards determining what features
are available either "in this cloud" or "on this specific resource".



I understand the capabilities are providing a different feature. From 
the current efforts about it, it seems to me that it would benefit from 
an API structure advertisement.



I guess the most important questions I can ask at this point are "Can
you please define what you mean by schema?" and "If I had one, what
could I do with it?". That will go a long way to making sure we're
near to the same page. I can make some guesses, but better to be
sure.


Absolutely, I think we're getting there. Thank you for being patient :)




__
OpenStack Development Mailing 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-WG] Schema like aws-sdk and API capabilities discovery

[Gilles Dubreuil]

Hi,

On a different list we're talking about improving/new features on the 
client side of OpenStack APIs and this one came up (please see below).


Although API-ref is doing a great job, I believe the question is: Can we 
achieve an equivalent of aws-sdk? For instance could we have each 
project's API to publish its own schema?


I suppose this would fit under the API-WG umbrella. Would that be 
correct? Could someone in the group provide feedback please?


Trying to find current work around this, I can see the API capabilities 
discovery [1] & [2] is great but, it seems to me that part of the 
challenge for the WG is a lack of schema too. Wouldn't it make sense to 
have a standardized way for all services APIs (at least on the public 
side) to publish their schema (including version/microversions details) 
before going any further?


Thanks,
Gilles

[1] https://etherpad.openstack.org/p/ptg-architecture-workgroup
[2] https://review.openstack.org/#/c/386555/




 Forwarded Message 
Subject:Re: Misty 0.2.0
Date:   Fri, 10 Mar 2017 09:19:44 +0100
From:   Ladislav Smola <lsm...@redhat.com>
To:     Gilles Dubreuil <gil...@redhat.com>
CC: 	Marek Aufart <mauf...@redhat.com>, Tzu-Mainn Chen 
<tzuma...@redhat.com>, Petr Blaho <pbl...@redhat.com>




Hola,

would be nice to see this moving in the direction of aws-sdk, where it 
just holds API schema (that you would get from OpenStack itself) and 
the whole client is generated from it. But I assume this needs the 
API-ref to be in a good shape.


Ladislav


__
OpenStack Development Mailing 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] Automation and self described APIs

[Gilles Dubreuil]

Ok, OpenStack ransom of success means the APIs request list is growing.
So what's the plan for self-described APIs?
Do we have a standardized solution exposing the requests' methods, 
parameters to other program to exploit?


Sure, some OpenStack APIs advertise their interface using GET method 
such as {"show api version", "/v1/"}.
Although consistent in the format but not available across all projects, 
it doesn't seem to be following a standard anyway, right?
Besides and more importantly it isn't suitable to fully expose the 
requests interfaces.


We know REST is not a standard in itself, but RESTful implementations 
make use of standards, such as HTTP, URI, JSON and XML [1]
This have brought an excellent candidate tailored for the job, the HTTP 
OPTION, please see RFC2616 [2] for more details.
Using such an approach would allow OpenStack APIs requests interfaces 
(methods, parameters and items) to be advertised to other programs.
By offering a new level of API automation, almost over are the days of 
tedious work for every OpenStack client of creating or adding every 
interface corresponding code and its test code.

The next generation of RESTful clients could get up to date automatically.

In the meantime that happens, the only comprehensive APIs reference 
source I've found is developer.openstack.org/api-ref.html 
 [2].

BTW, great work Oslo Sphinx team, thank you!
The API-ref allows most of APIs interfaces to be partly generated using 
web crawlers.
Unfortunately, there a still missing projects from the reference so the 
rest still has to be manually produced and for the one automatically 
generated there are various flaws which require manual intervention.


The flaws I've found:
- Missing requests from API ref: Only a few (example? Ironic: heartbeat  
POST, "/v1/heartbeat/{node_ident}")
- API Inconsistencies: For instance, the call a method for Node Vendor 
[3] or Driver Vendor [4] Passthru is the same, which create a conflict 
for REST Clients.


So again, the API-ref is great and allow to cover the requests list but 
that's not good enough for automation where the requests capabilities 
need to be advertised properly and comprehensively through a standard, 
such as the HTTP Option. Actually the API-ref could benefit from it too 
and consume the latter.


Cheers,
Gilles

PS: In an ideal world, the API is built first and the rest upon.

[1] https://en.wikipedia.org/wiki/Representational_state_transfer
[2] https://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html
[3] 
http://developer.openstack.org/api-ref/baremetal/?expanded=call-a-method-detail

[4] http://developer.openstack.org/api-ref/baremetal/?expanded=id73-detail

__
OpenStack Development Mailing 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] [puppet][keystone] Choose domain names with 'composite namevar' or 'meaningless name'?

[Gilles Dubreuil]

On 16/10/15 00:14, Emilien Macchi wrote:
> This thread is really huge and only 3 people are talking.
> Why don't you continue on an etherpad and do some brainstorm on it?
> If you do so, please share the link here.
> 
> It would be much more effective in my opinion.

I think we're almost there (Please read on)
Harder at this stage to summarize this in an etherpad.
But we'll certainly do that or either start a new thread/topic if needed.

> 
> On 10/15/2015 08:26 AM, Sofer Athlan-Guyot wrote:
>> Gilles Dubreuil <gil...@redhat.com> writes:
>>
>>> On 08/10/15 03:40, Rich Megginson wrote:
>>>> On 10/07/2015 09:08 AM, Sofer Athlan-Guyot wrote:
>>>>> Rich Megginson <rmegg...@redhat.com> writes:
>>>>>
>>>>>> On 10/06/2015 02:36 PM, Sofer Athlan-Guyot wrote:
>>>>>>> Rich Megginson <rmegg...@redhat.com> writes:
>>>>>>>
>>>>>>>> On 09/30/2015 11:43 AM, Sofer Athlan-Guyot wrote:
>>>>>>>>> Gilles Dubreuil <gil...@redhat.com> writes:
>>>>>>>>>
>>>>>>>>>> On 30/09/15 03:43, Rich Megginson wrote:
>>>>>>>>>>> On 09/28/2015 10:18 PM, Gilles Dubreuil wrote:
>>>>>>>>>>>> On 15/09/15 19:55, Sofer Athlan-Guyot wrote:
>>>>>>>>>>>>> Gilles Dubreuil <gil...@redhat.com> writes:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 15/09/15 06:53, Rich Megginson wrote:
>>>>>>>>>>>>>>> On 09/14/2015 02:30 PM, Sofer Athlan-Guyot wrote:
>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Gilles Dubreuil <gil...@redhat.com> writes:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> A. The 'composite namevar' approach:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> keystone_tenant {'projectX::domainY': ... }
>>>>>>>>>>>>>>>>>   B. The 'meaningless name' approach:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>keystone_tenant {'myproject': name='projectX',
>>>>>>>>>>>>>>>>> domain=>'domainY',
>>>>>>>>>>>>>>>>> ...}
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Notes:
>>>>>>>>>>>>>>>>>   - Actually using both combined should work too with
>>>>>>>>>>>>>>>>> the domain
>>>>>>>>>>>>>>>>> supposedly overriding the name part of the domain.
>>>>>>>>>>>>>>>>>   - Please look at [1] this for some background
>>>>>>>>>>>>>>>>> between the two
>>>>>>>>>>>>>>>>> approaches:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> The question
>>>>>>>>>>>>>>>>> -
>>>>>>>>>>>>>>>>> Decide between the two approaches, the one we would like to
>>>>>>>>>>>>>>>>> retain for
>>>>>>>>>>>>>>>>> puppet-keystone.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Why it matters?
>>>>>>>>>>>>>>>>> ---
>>>>>>>>>>>>>>>>> 1. Domain names are mandatory in every user, group or
>>>>>>>>>>>>>>>>> project.
>>>>>>>>>>>>>>>>> Besides
>>>>>>>>>>>>>>>>> the backward compatibility period mentioned earlier, where
>>>>>>>>>>>>>>>>> no domain
>>>>>>>>>>

Re: [openstack-dev] [puppet][keystone] Choose domain names with 'composite namevar' or 'meaningless name'?

[Gilles Dubreuil]

On 29/10/15 17:32, Gilles Dubreuil wrote:
> 
> 
> On 16/10/15 00:14, Emilien Macchi wrote:
>> This thread is really huge and only 3 people are talking.
>> Why don't you continue on an etherpad and do some brainstorm on it?
>> If you do so, please share the link here.
>>
>> It would be much more effective in my opinion.
> 
> I think we're almost there (Please read on)
> Harder at this stage to summarize this in an etherpad.
> But we'll certainly do that or either start a new thread/topic if needed.

For those interested, the discussion is now happening here
https://etherpad.openstack.org/p/keystone_no_domain

> 
>>
>> On 10/15/2015 08:26 AM, Sofer Athlan-Guyot wrote:
>>> Gilles Dubreuil <gil...@redhat.com> writes:
>>>
>>>> On 08/10/15 03:40, Rich Megginson wrote:
>>>>> On 10/07/2015 09:08 AM, Sofer Athlan-Guyot wrote:
>>>>>> Rich Megginson <rmegg...@redhat.com> writes:
>>>>>>
>>>>>>> On 10/06/2015 02:36 PM, Sofer Athlan-Guyot wrote:
>>>>>>>> Rich Megginson <rmegg...@redhat.com> writes:
>>>>>>>>
>>>>>>>>> On 09/30/2015 11:43 AM, Sofer Athlan-Guyot wrote:
>>>>>>>>>> Gilles Dubreuil <gil...@redhat.com> writes:
>>>>>>>>>>
>>>>>>>>>>> On 30/09/15 03:43, Rich Megginson wrote:
>>>>>>>>>>>> On 09/28/2015 10:18 PM, Gilles Dubreuil wrote:
>>>>>>>>>>>>> On 15/09/15 19:55, Sofer Athlan-Guyot wrote:
>>>>>>>>>>>>>> Gilles Dubreuil <gil...@redhat.com> writes:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 15/09/15 06:53, Rich Megginson wrote:
>>>>>>>>>>>>>>>> On 09/14/2015 02:30 PM, Sofer Athlan-Guyot wrote:
>>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Gilles Dubreuil <gil...@redhat.com> writes:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> A. The 'composite namevar' approach:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> keystone_tenant {'projectX::domainY': ... }
>>>>>>>>>>>>>>>>>>   B. The 'meaningless name' approach:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>keystone_tenant {'myproject': name='projectX',
>>>>>>>>>>>>>>>>>> domain=>'domainY',
>>>>>>>>>>>>>>>>>> ...}
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Notes:
>>>>>>>>>>>>>>>>>>   - Actually using both combined should work too with
>>>>>>>>>>>>>>>>>> the domain
>>>>>>>>>>>>>>>>>> supposedly overriding the name part of the domain.
>>>>>>>>>>>>>>>>>>   - Please look at [1] this for some background
>>>>>>>>>>>>>>>>>> between the two
>>>>>>>>>>>>>>>>>> approaches:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> The question
>>>>>>>>>>>>>>>>>> -
>>>>>>>>>>>>>>>>>> Decide between the two approaches, the one we would like to
>>>>>>>>>>>>>>>>>> retain for
>>>>>>>>>>>>>>>>>> puppet-keystone.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Why it matters?
>>>>>>>>>>>>>>>>>> ---
>>>>>>>>>>>>>>>>>> 1. Domain names are mandatory in every user, group or
>>>>>>

Re: [openstack-dev] correction: Re: [puppet][keystone] Keystone resource naming with domain support - no '::domain' if 'Default'

[Gilles Dubreuil]

On 02/09/15 12:26, Rich Megginson wrote:
> Slight correction below:
> 
> On 09/01/2015 10:56 AM, Rich Megginson wrote:
>> To close this thread:
>> http://lists.openstack.org/pipermail/openstack-dev/2015-August/072878.html
>>
>>
>> puppet-openstack will support Keystone domain scoped resource names
>> without a '::domain' in the name, only if the 'default_domain_id'
>> parameter in Keystone has _not_ been set.
> 
> Or if the 'default_domain_id' parameter has been set to 'default'.
> 
>> That is, if the default domain is 'Default'.  This means that if the
>> user/operator doesn't care about domains at all, the operator doesn't
>> have to deal with them.  However, once the user/operator uses
>> `keystone_domain`, and uses `is_default => true`, this means the
>> user/operator _must_ use '::domain' with _all_ domain scoped Keystone
>> resource names.
> 
> Note that the domain named 'Default' with the UUID 'default' is created
> automatically by Keystone, so no need for puppet to create it or ensure
> that it exists.
> 
>>
>> In addition:
>>
>> * In the OpenStack L release:
>>If 'default_domain_id' is set,
> or if 'default_domain_id' is not 'default',
>> puppet will issue a warning if a name is used without '::domain'. I
>> think this is a good thing to do, just in case someone sets the
>> default_domain_id by mistake.
>>
>> * In OpenStack M release:
>>Puppet will issue a warning if a name is used without '::domain'.
>>
>> * From Openstack N release:
>>A name must be used with '::domain'.
>>
>>

In the light of the composite namevar solution things have evolved a bit.

The rule has slightly changed but the depecration warnings should be put
in place.

For those interested, the discussion is now happening here
https://etherpad.openstack.org/p/keystone_no_domain

Thanks,
Gilles

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

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

Re: [openstack-dev] [Fuel] [Puppet] Potential critical issue, due Puppet mix stderr and stdout while execute commands

[Gilles Dubreuil]

On 23/10/15 01:59, Matt Fischer wrote:
> On Thu, Oct 22, 2015 at 12:52 AM, Sergey Vasilenko
> > wrote:
> 
> 
> On Thu, Oct 22, 2015 at 6:16 AM, Matt Fischer  > wrote:
> 
> I thought we had code in other places that split out stderr and
> only logged it if there was an actual error but I cannot find
> the reference now. I think that matches the original proposal.
> Not sure I like idea #3.
> 
> 
> Matthew, this topic not about SSL. ANY warnings, ANY output to
> stderr from CLI may corrupt work of providers from puppet-* modules
> for openstack components. 
> 
> IMHO it's a very serious bug, that potential affect openstack puppet
> modules.
> 
> I see 3 way for fix it:
> 
>  1. Long way. big patch to puppet core for add ability to collect
> stderr and stdout separately. But most of existing puppet
> providers waits that stderr and stdout was mixed when handle
> errors of execution (non-zero return code). Such patch will
> broke backward compatibility, if will be enabled by default.
>  2. Middle way. We should write code for redefine 'commands' method.
> New commands should collect stderr and stdout separately, but if
> error happens return stderr (with ability access to stdout too).
>  3. Short way. Modify existing providers to use json output instead
> plain-text or csv. JSON output may be separated from any garbage
> (warnings) slightly. I make this patch as example of this
> way: https://review.openstack.org/#/c/238156/ . Anyway json more
> formalized format for data exchange, than plain text.
> 
> IMHO way #1 is a best solution, but not easy.
> 
There is another middle way: using neutron API directly.
Because from what I've experienced anything JSON we pass/receive to/from
the API is directly converted in hashes, no processing to be done. But
more importantly in the case of the issue here, the errors/responses are
clearly separated from the beginning.


> 
> I must confess that I'm a bit confused about this. It wasn't a secret
> that we're calling out to commands and parsing the output. It's been
> discussed over and over on this list as recently as last week, so this
> has been a known possible issue for quite a long time. In my original
> email I was agreeing with you, so I'm not sure why we're arguing now.
> Anyway...
> 
> I think we need to split stderr and stdout and log stderr on errors,
> your idea #2. Using json like openstack-client can do does not solve
> this problem for us, you still can end up with a bunch of junk on stderr.
> 
> This would be a good quick discussion in Tokyo if you guys will be there.
>  

Unfortunately I won't be there but I believe this should be added to the
"Scalability issues - Ruby library VS OSclient" topic to be discussed on
Wednesday/Thursday.



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

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

Re: [openstack-dev] [puppet] Proposing Denis Egorenko core

[Gilles Dubreuil]

On 15/10/15 02:19, Ricardo Carrillo Cruz wrote:
> From my few changes on puppet-openstack I've got several reviews from
> Dennis,
> and they were always insightful.
> 
> +1
> 
> Regards
> 
> 2015-10-14 17:13 GMT+02:00 Sebastien Badia  >:
> 
> On Wed, Oct 14, 2015 at 09:07:04AM (+0200), Yanis Guenane wrote:
> > On 10/13/2015 11:02 PM, Matt Fischer wrote:
> > > On Tue, Oct 13, 2015 at 2:29 PM, Emilien Macchi
> > wrote:
> > >
> > >> Denis Egorenko (degorenko) is working on Puppet OpenStack
> modules for
> > >> quite some time now.
> > >>
> > >> Some statistics [1] about his contributions (last 6 months):
> > >> * 270 reviews
> > >> * 49 negative reviews
> > >> * 216 positive reviews
> > >> * 36 disagreements
> > >> * 30 commits
> > >>
> > >> Beside stats, Denis is always here on IRC participating to
> meetings,
> > >> helping our group discussions, and is always helpful with our
> community.
> > >>
> > >> I honestly think Denis is on the right path to become a good
> core member
> > >> team, he has strong knowledge in OpenStack deployments, knows
> enough
> > >> about our coding style and his involvement in the project is really
> > >> great. He's also a huge consumer of our modules since he's
> working on Fuel.
> > >>
> > >> I would like to open the vote to promote Denis part of Puppet
> OpenStack
> > >> core reviewers.
> > >>
> > >> [1]
> http://stackalytics.com/report/contribution/puppetopenstack-group/180
> > >> --
> > >> Emilien Macchi
> > >>
> > >>
> > >>
> > > Denis has given me some great feedback on reviews and has shown
> a good
> > > understanding of puppet-openstack.
> > >
> > > +1
> >
> > +1
> >

+1

> > He has been really involved and proactive (reviews + commits) in the
> > community during the past months.
> 
> A big +1 also!
> 
> Denis is very involved in our community, and he has a very valuable
> feedback!
> 
> Thanks!
> 
> Seb
> 
> --
> Sebastien Badia
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

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

Re: [openstack-dev] [puppet][Fuel] Using Native Ruby Client for Openstack Providers

[Gilles Dubreuil]

On 19/10/15 22:04, Tom Fifield wrote:
> On 13/10/15 21:13, Vladimir Kuklin wrote:
>> Puppetmaster and Fuelers,
>>
>> Last week I mentioned that I would like to bring the theme of using
>> native ruby OpenStack client and use it within the providers.
>>
>> Emilien told me that I had already been late and the decision was made
>> that puppet-openstack decided to not work with Aviator based on [0]. I
>> went through this thread and did not find any unresolvable issues with
>> using Aviator in comparison with potential benefits it could have
>> brought up.
>>
>> What I saw actually was like that:
>>
>> * Pros
>>
>> 1) It is a native ruby client
>> 2) We can import it in puppet and use all the power of Ruby
>> 3) We will not need to have a lot of forks/execs for puppet
>> 4) You are relying on negotiated and structured output provided by API
>> (JSON) instead of introducing workarounds for client output like [1]
>>
>> * Cons
>>
>> 1) Aviator is not actively supported
>> 2) Aviator does not track all the upstream OpenStack features while
>> native OpenStack client does support them
>> 3) Ruby community is not really interested in OpenStack (this one is
>> arguable, I think)
>>
>> * Proposed solution
>>
>> While I completely understand all the cons against using Aviator right
>> now, I see that Pros above are essential enough to change our mind and
>> invest our own resources into creating really good OpenStack binding in
>> Ruby.
>> Some are saying that there is not so big involvement of Ruby into
>> OpenStack. But we are actually working with Puppet/Ruby and are invloved
>> into community. So why should not we own this by ourselves and lead by
>> example here?
>>
>> I understand that many of you do already have a lot of things on their
>> plate and cannot or would not want to support things like additional
>> library when native OpenStack client is working reasonably well for you.
>> But if I propose the following scheme to get support of native Ruby
>> client for OpenStack:
>>
>> 1) we (community) have these resources (speaking of the company I am
>> working for, we at Mirantis have a set of guys who could be very
>> interested in working on Ruby client for OpenStack)
>> 2) we gradually improve Aviator code base up to the level that it
>> eliminates issues that are mentioned in  'Cons' section
>> 3) we introduce additional set of providers and allow users and
>> operators to pick whichever they want
>> 4) we leave OpenStackClient default one
>>
>> Would you support it and allow such code to be merged into upstream
>> puppet-openstack modules?
> 
> Hi,
> 
> I'm just throwing this out there since I didn't see it mentioned in
> either this thread or the linked one on the puppet-openstack ML, but ...
> 
> ... has anyone looked into fog (http://fog.io/ ) ?
> 
> 
> In my experience it generally works, and is updated fairly frequently.
> 
> 

Fog is an interesting and I think very exciting and ambitious project.

Meanwhile I'm not sure it could be a candidate to go along Net/HTTP or
Faraday because it's cloud generic, so quite high level, bringing many
things we don't need at all, unless we could use only the fog/openstack
part.


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

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

Re: [openstack-dev] [puppet][Fuel] Using Native Ruby Client for Openstack Providers

[Gilles Dubreuil]

On 21/10/15 00:56, Sofer Athlan-Guyot wrote:
> Gilles Dubreuil <gil...@redhat.com> writes:
> 
>> On 14/10/15 17:15, Gilles Dubreuil wrote:
>>>
>>>
>>> On 14/10/15 10:36, Colleen Murphy wrote:
>>>>
>>>>
>>>> On Tue, Oct 13, 2015 at 6:13 AM, Vladimir Kuklin <vkuk...@mirantis.com
>>>> <mailto:vkuk...@mirantis.com>> wrote:
>>>>
>>>> Puppetmaster and Fuelers,
>>>>
>>>> Last week I mentioned that I would like to bring the theme of using
>>>> native ruby OpenStack client and use it within the providers.
>>>>
>>>> Emilien told me that I had already been late and the decision was
>>>> made that puppet-openstack decided to not work with Aviator based on
>>>> [0]. I went through this thread and did not find any unresolvable
>>>> issues with using Aviator in comparison with potential benefits it
>>>> could have brought up.
>>>>
>>>> What I saw actually was like that:
>>>>
>>>> * Pros
>>>>
>>>> 1) It is a native ruby client
>>>> 2) We can import it in puppet and use all the power of Ruby
>>>> 3) We will not need to have a lot of forks/execs for puppet 
>>>> 4) You are relying on negotiated and structured output provided by
>>>> API (JSON) instead of introducing workarounds for client output like 
>>>> [1]
>>>>
>>>> * Cons
>>>>
>>>> 1) Aviator is not actively supported 
>>>> 2) Aviator does not track all the upstream OpenStack features while
>>>> native OpenStack client does support them
>>>> 3) Ruby community is not really interested in OpenStack (this one is
>>>> arguable, I think)
>>>>
>>>> * Proposed solution
>>>>
>>>> While I completely understand all the cons against using Aviator
>>>> right now, I see that Pros above are essential enough to change our
>>>> mind and invest our own resources into creating really good
>>>> OpenStack binding in Ruby.
>>>> Some are saying that there is not so big involvement of Ruby into
>>>> OpenStack. But we are actually working with Puppet/Ruby and are
>>>> invloved into community. So why should not we own this by ourselves
>>>> and lead by example here?
>>>>
>>>> I understand that many of you do already have a lot of things on
>>>> their plate and cannot or would not want to support things like
>>>> additional library when native OpenStack client is working
>>>> reasonably well for you. But if I propose the following scheme to
>>>> get support of native Ruby client for OpenStack:
>>>>
>>>> 1) we (community) have these resources (speaking of the company I am
>>>> working for, we at Mirantis have a set of guys who could be very
>>>> interested in working on Ruby client for OpenStack)
>>>> 2) we gradually improve Aviator code base up to the level that it
>>>> eliminates issues that are mentioned in  'Cons' section
>>>> 3) we introduce additional set of providers and allow users and
>>>> operators to pick whichever they want
>>>> 4) we leave OpenStackClient default one
>>>>
>>>> Would you support it and allow such code to be merged into upstream
>>>> puppet-openstack modules?
>>>>
>>>>
>>>> [0] 
>>>> https://groups.google.com/a/puppetlabs.com/forum/#!searchin/puppet-openstack/aviator$20openstackclient/puppet-openstack/GJwDHNAFVYw/ayN4cdg3EW0J
>>>> [1] 
>>>> https://github.com/openstack/puppet-swift/blob/master/lib/puppet/provider/swift_ring_builder.rb#L21-L86
>>>> -- 
>>>> Yours Faithfully,
>>>> Vladimir Kuklin,
>>>> Fuel Library Tech Lead,
>>>> Mirantis, Inc.
>>>> +7 (495) 640-49-04 <tel:%2B7%20%28495%29%20640-49-04>
>>>> +7 (926) 702-39-68 <tel:%2B7%20%28926%29%20702-39-68>
>>>> Skype kuklinvv
>>>> 35bk3, Vorontsovskaya Str.
>>>> Moscow, Russia,
>>>> www.mirantis.com <http://www.mirantis.ru/>
>>>> www.mirantis.ru <http://www.mirantis.ru/>
>>>> vkuk...@mirantis.com <mailto:vkuk

Re: [openstack-dev] [puppet][Fuel] Using Native Ruby Client for Openstack Providers

[Gilles Dubreuil]

On 14/10/15 17:15, Gilles Dubreuil wrote:
> 
> 
> On 14/10/15 10:36, Colleen Murphy wrote:
>>
>>
>> On Tue, Oct 13, 2015 at 6:13 AM, Vladimir Kuklin <vkuk...@mirantis.com
>> <mailto:vkuk...@mirantis.com>> wrote:
>>
>> Puppetmaster and Fuelers,
>>
>> Last week I mentioned that I would like to bring the theme of using
>> native ruby OpenStack client and use it within the providers.
>>
>> Emilien told me that I had already been late and the decision was
>> made that puppet-openstack decided to not work with Aviator based on
>> [0]. I went through this thread and did not find any unresolvable
>> issues with using Aviator in comparison with potential benefits it
>> could have brought up.
>>
>> What I saw actually was like that:
>>
>> * Pros
>>
>> 1) It is a native ruby client
>> 2) We can import it in puppet and use all the power of Ruby
>> 3) We will not need to have a lot of forks/execs for puppet 
>> 4) You are relying on negotiated and structured output provided by
>> API (JSON) instead of introducing workarounds for client output like [1]
>>
>> * Cons
>>
>> 1) Aviator is not actively supported 
>> 2) Aviator does not track all the upstream OpenStack features while
>> native OpenStack client does support them
>> 3) Ruby community is not really interested in OpenStack (this one is
>> arguable, I think)
>>
>> * Proposed solution
>>
>> While I completely understand all the cons against using Aviator
>> right now, I see that Pros above are essential enough to change our
>> mind and invest our own resources into creating really good
>> OpenStack binding in Ruby.
>> Some are saying that there is not so big involvement of Ruby into
>> OpenStack. But we are actually working with Puppet/Ruby and are
>> invloved into community. So why should not we own this by ourselves
>> and lead by example here?
>>
>> I understand that many of you do already have a lot of things on
>> their plate and cannot or would not want to support things like
>> additional library when native OpenStack client is working
>> reasonably well for you. But if I propose the following scheme to
>> get support of native Ruby client for OpenStack:
>>
>> 1) we (community) have these resources (speaking of the company I am
>> working for, we at Mirantis have a set of guys who could be very
>> interested in working on Ruby client for OpenStack)
>> 2) we gradually improve Aviator code base up to the level that it
>> eliminates issues that are mentioned in  'Cons' section
>> 3) we introduce additional set of providers and allow users and
>> operators to pick whichever they want
>> 4) we leave OpenStackClient default one
>>
>> Would you support it and allow such code to be merged into upstream
>> puppet-openstack modules?
>>
>>
>> [0] 
>> https://groups.google.com/a/puppetlabs.com/forum/#!searchin/puppet-openstack/aviator$20openstackclient/puppet-openstack/GJwDHNAFVYw/ayN4cdg3EW0J
>> [1] 
>> https://github.com/openstack/puppet-swift/blob/master/lib/puppet/provider/swift_ring_builder.rb#L21-L86
>> -- 
>> Yours Faithfully,
>> Vladimir Kuklin,
>> Fuel Library Tech Lead,
>> Mirantis, Inc.
>> +7 (495) 640-49-04 <tel:%2B7%20%28495%29%20640-49-04>
>> +7 (926) 702-39-68 <tel:%2B7%20%28926%29%20702-39-68>
>> Skype kuklinvv
>> 35bk3, Vorontsovskaya Str.
>> Moscow, Russia,
>> www.mirantis.com <http://www.mirantis.ru/>
>> www.mirantis.ru <http://www.mirantis.ru/>
>> vkuk...@mirantis.com <mailto:vkuk...@mirantis.com>
>>
>>
>> The scale-tipping reason we went with python-openstackclient over the
>> Aviator library was that at the same time we were trying to switch, we
>> were also developing keystone v3 features and we could only get those
>> features from python-openstackclient.
>>
>> For the first two pros you listed, I'm not convinced they're really
>> pros. Puppet types and providers are actually extremely well-suited to
>> shelling out to command-line clients. There are existing, documented
>> puppet APIs to do it and we get automatic debug output with it. Nearly
>> every existing type and provider does this. It is not well-suited to
>> call out to other non-standard ruby libraries because they need to be
>> added as a

Re: [openstack-dev] [puppet][Fuel] OpenstackLib Client Provider Better Exception Handling

[Gilles Dubreuil]

On 15/10/15 12:42, Matt Fischer wrote:
> 
> 
> On Thu, Oct 8, 2015 at 5:38 AM, Vladimir Kuklin  > wrote:
> 
> Hi, folks
> 
> * Intro
> 
> Per our discussion at Meeting #54 [0] I would like to propose the
> uniform approach of exception handling for all puppet-openstack
> providers accessing any types of OpenStack APIs.
> 
> * Problem Description
> 
> While working on Fuel during deployment of multi-node HA-aware
> environments we faced many intermittent operational issues, e.g.:
> 
> 401/403 authentication failures when we were doing scaling of
> OpenStack controllers due to difference in hashing view between
> keystone instances
> 503/502/504 errors due to temporary connectivity issues

The 5xx errors are not connectivity issues:

500 Internal Server Error
501 Not Implemented
502 Bad Gateway
503 Service Unavailable
504 Gateway Timeout
505 HTTP Version Not Supported

I believe nothing should be done to trap them.

The connectivity issues are different matter (to be addressed as
mentioned by Matt)

> non-idempotent operations like deletion or creation - e.g. if you
> are deleting an endpoint and someone is deleting on the other node
> and you get 404 - you should continue with success instead of
> failing. 409 Conflict error should also signal us to re-fetch
> resource parameters and then decide what to do with them.
> 
> Obviously, it is not optimal to rerun puppet to correct such errors
> when we can just handle an exception properly.
> 
> * Current State of Art
> 
> There is some exception handling, but it does not cover all the
> aforementioned use cases.
> 
> * Proposed solution
> 
> Introduce a library of exception handling methods which should be
> the same for all puppet openstack providers as these exceptions seem
> to be generic. Then, for each of the providers we can introduce
> provider-specific libraries that will inherit from this one.
> 
> Our mos-puppet team could add this into their backlog and could work
> on that in upstream or downstream and propose it upstream.
> 
> What do you think on that, puppet folks?
> 

The real issue is because we're dealing with openstackclient, a CLI tool
and not an API. Therefore no error propagation is expected.

Using REST interfaces for all Openstack API would provide all HTTP errors:

Check for "HTTP Response Classes" in
http://ruby-doc.org/stdlib-2.2.3/libdoc/net/http/rdoc/Net/HTTP.html


> [0] 
> http://eavesdrop.openstack.org/meetings/puppet_openstack/2015/puppet_openstack.2015-10-06-15.00.html
> 
> 
> I think that we should look into some solutions here as I'm generally
> for something we can solve once and re-use. Currently we solve some of
> this at TWC by serializing our deploys and disabling puppet site wide
> while we do so. This avoids the issue of Keystone on one node removing
> and endpoint while the other nodes (who still have old code) keep trying
> to add it back.
> 
> For connectivity issues especially after service restarts, we're using
> puppet-healthcheck [0] and I'd like to discuss that more in Tokyo as an
> alternative to explicit retries and delays. It's in the etherpad so
> hopefully you can attend.

+1

> 
> [0] - https://github.com/puppet-community/puppet-healthcheck
> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

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

Re: [openstack-dev] [puppet][Fuel] OpenstackLib Client Provider Better Exception Handling

[Gilles Dubreuil]

On 15/10/15 21:10, Vladimir Kuklin wrote:
> Gilles,
> 
> 5xx errors like 503 and 502/504 could always be intermittent operational
> issues. E.g. when you access your keystone backends through some proxy
> and there is a connectivity issue between the proxy and backends which
> disappears in 10 seconds, you do not need to rerun the puppet completely
> - just retry the request.
> 

Look, I don't have much experience with those errors in real case
scenarios. And this is just a details for my understanding,  those
errors are coming from a running HTTP service, therefore this is not a
connectivity issue to the service but something wrong beyond that.

> Regarding "REST interfaces for all Openstack API" - this is very close
> to another topic that I raised ([0]) - using native Ruby application and
> handle the exceptions. Otherwise whenever we have an OpenStack client
> (generic or neutron/glance/etc. one) sending us a message like '[111]
> Connection refused' this message is very much determined by the
> framework that OpenStack is using within this release for clients. It
> could be `requests` or any other type of framework which sends different
> text message depending on its version. So it is very bothersome to write
> a bunch of 'if' clauses or gigantic regexps instead of handling simple
> Ruby exception. So I agree with you here - we need to work with the API
> directly. And, by the way, if you also support switching to native Ruby
> OpenStack API client, please feel free to support movement towards it in
> the thread [0]
> 

Yes, I totally agree with you on that approach (native Ruby lib).
This why I mentioned it here because for me the exception handling would
be solved at once.

> Matt and Gilles,
> 
> Regarding puppet-healthcheck - I do not think that puppet-healtcheck
> handles exactly what I am mentioning here - it is not running exactly at
> the same time as we run the request.
> 
> E.g. 10 seconds ago everything was OK, then we had a temporary
> connectivity issue, then everything is ok again in 10 seconds. Could you
> please describe how puppet-healthcheck can help us solve this problem? 
> 
> Or another example - there was an issue with keystone accessing token
> database when you have several keystone instances running, or there was
> some desync between these instances, e.g. you fetched the token at
> keystone #1 and then you verify it again keystone #2. Keystone #2 had
> some issues verifying it not due to the fact that token was bad, but due
> to the fact that that keystone #2 had some issues. We would get 401
> error and instead of trying to rerun the puppet we would need just to
> handle this issue locally by retrying the request.
> 
> [0] http://permalink.gmane.org/gmane.comp.cloud.openstack.devel/66423
> 
> On Thu, Oct 15, 2015 at 12:23 PM, Gilles Dubreuil <gil...@redhat.com
> <mailto:gil...@redhat.com>> wrote:
> 
> 
> 
> On 15/10/15 12:42, Matt Fischer wrote:
> >
> >
> > On Thu, Oct 8, 2015 at 5:38 AM, Vladimir Kuklin <vkuk...@mirantis.com 
> <mailto:vkuk...@mirantis.com>
> > <mailto:vkuk...@mirantis.com <mailto:vkuk...@mirantis.com>>> wrote:
> >
> > Hi, folks
> >
> > * Intro
> >
> > Per our discussion at Meeting #54 [0] I would like to propose the
> > uniform approach of exception handling for all puppet-openstack
> > providers accessing any types of OpenStack APIs.
> >
> > * Problem Description
> >
> > While working on Fuel during deployment of multi-node HA-aware
> > environments we faced many intermittent operational issues, e.g.:
> >
> > 401/403 authentication failures when we were doing scaling of
> > OpenStack controllers due to difference in hashing view between
> > keystone instances
> > 503/502/504 errors due to temporary connectivity issues
> 
> The 5xx errors are not connectivity issues:
> 
> 500 Internal Server Error
> 501 Not Implemented
> 502 Bad Gateway
> 503 Service Unavailable
> 504 Gateway Timeout
> 505 HTTP Version Not Supported
> 
> I believe nothing should be done to trap them.
> 
> The connectivity issues are different matter (to be addressed as
> mentioned by Matt)
> 
> > non-idempotent operations like deletion or creation - e.g. if you
> > are deleting an endpoint and someone is deleting on the other node
> > and you get 404 - you should continue with success instead of
> > failing. 409 Conflict error should also signal us to re-fetch
> > resour

Re: [openstack-dev] [puppet][Fuel] Using Native Ruby Client for Openstack Providers

[Gilles Dubreuil]

On 14/10/15 10:36, Colleen Murphy wrote:
> 
> 
> On Tue, Oct 13, 2015 at 6:13 AM, Vladimir Kuklin  > wrote:
> 
> Puppetmaster and Fuelers,
> 
> Last week I mentioned that I would like to bring the theme of using
> native ruby OpenStack client and use it within the providers.
> 
> Emilien told me that I had already been late and the decision was
> made that puppet-openstack decided to not work with Aviator based on
> [0]. I went through this thread and did not find any unresolvable
> issues with using Aviator in comparison with potential benefits it
> could have brought up.
> 
> What I saw actually was like that:
> 
> * Pros
> 
> 1) It is a native ruby client
> 2) We can import it in puppet and use all the power of Ruby
> 3) We will not need to have a lot of forks/execs for puppet 
> 4) You are relying on negotiated and structured output provided by
> API (JSON) instead of introducing workarounds for client output like [1]
> 
> * Cons
> 
> 1) Aviator is not actively supported 
> 2) Aviator does not track all the upstream OpenStack features while
> native OpenStack client does support them
> 3) Ruby community is not really interested in OpenStack (this one is
> arguable, I think)
> 
> * Proposed solution
> 
> While I completely understand all the cons against using Aviator
> right now, I see that Pros above are essential enough to change our
> mind and invest our own resources into creating really good
> OpenStack binding in Ruby.
> Some are saying that there is not so big involvement of Ruby into
> OpenStack. But we are actually working with Puppet/Ruby and are
> invloved into community. So why should not we own this by ourselves
> and lead by example here?
> 
> I understand that many of you do already have a lot of things on
> their plate and cannot or would not want to support things like
> additional library when native OpenStack client is working
> reasonably well for you. But if I propose the following scheme to
> get support of native Ruby client for OpenStack:
> 
> 1) we (community) have these resources (speaking of the company I am
> working for, we at Mirantis have a set of guys who could be very
> interested in working on Ruby client for OpenStack)
> 2) we gradually improve Aviator code base up to the level that it
> eliminates issues that are mentioned in  'Cons' section
> 3) we introduce additional set of providers and allow users and
> operators to pick whichever they want
> 4) we leave OpenStackClient default one
> 
> Would you support it and allow such code to be merged into upstream
> puppet-openstack modules?
> 
> 
> [0] 
> https://groups.google.com/a/puppetlabs.com/forum/#!searchin/puppet-openstack/aviator$20openstackclient/puppet-openstack/GJwDHNAFVYw/ayN4cdg3EW0J
> [1] 
> https://github.com/openstack/puppet-swift/blob/master/lib/puppet/provider/swift_ring_builder.rb#L21-L86
> -- 
> Yours Faithfully,
> Vladimir Kuklin,
> Fuel Library Tech Lead,
> Mirantis, Inc.
> +7 (495) 640-49-04 
> +7 (926) 702-39-68 
> Skype kuklinvv
> 35bk3, Vorontsovskaya Str.
> Moscow, Russia,
> www.mirantis.com 
> www.mirantis.ru 
> vkuk...@mirantis.com 
> 
> 
> The scale-tipping reason we went with python-openstackclient over the
> Aviator library was that at the same time we were trying to switch, we
> were also developing keystone v3 features and we could only get those
> features from python-openstackclient.
> 
> For the first two pros you listed, I'm not convinced they're really
> pros. Puppet types and providers are actually extremely well-suited to
> shelling out to command-line clients. There are existing, documented
> puppet APIs to do it and we get automatic debug output with it. Nearly
> every existing type and provider does this. It is not well-suited to
> call out to other non-standard ruby libraries because they need to be
> added as a dependency somehow, and doing this is not well-established in
> puppet. There are basically two options to do this:
> 
>  1) Add a gem as a package resource and make sure the package resource
> is called before any of the openstack resources. I could see this
> working as an opt-in thing, but not as a default, for the same reason we
> don't require our users to install pip libraries - there is less
> security guarantees from pypi and rubygems than from distro packages,
> plus corporate infrastructure may not allow pulling packages from these
> types of sources. (I don't see this policy documented anywhere, this was
> just something that's been instilled in me since I started working on
> this team. If we want to revisit it, formalize 

Re: [openstack-dev] [puppet][keystone] Choose domain names with 'composite namevar' or 'meaningless name'?

[Gilles Dubreuil]

On 08/10/15 03:40, Rich Megginson wrote:
> On 10/07/2015 09:08 AM, Sofer Athlan-Guyot wrote:
>> Rich Megginson <rmegg...@redhat.com> writes:
>>
>>> On 10/06/2015 02:36 PM, Sofer Athlan-Guyot wrote:
>>>> Rich Megginson <rmegg...@redhat.com> writes:
>>>>
>>>>> On 09/30/2015 11:43 AM, Sofer Athlan-Guyot wrote:
>>>>>> Gilles Dubreuil <gil...@redhat.com> writes:
>>>>>>
>>>>>>> On 30/09/15 03:43, Rich Megginson wrote:
>>>>>>>> On 09/28/2015 10:18 PM, Gilles Dubreuil wrote:
>>>>>>>>> On 15/09/15 19:55, Sofer Athlan-Guyot wrote:
>>>>>>>>>> Gilles Dubreuil <gil...@redhat.com> writes:
>>>>>>>>>>
>>>>>>>>>>> On 15/09/15 06:53, Rich Megginson wrote:
>>>>>>>>>>>> On 09/14/2015 02:30 PM, Sofer Athlan-Guyot wrote:
>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Gilles Dubreuil <gil...@redhat.com> writes:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> A. The 'composite namevar' approach:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> keystone_tenant {'projectX::domainY': ... }
>>>>>>>>>>>>>>   B. The 'meaningless name' approach:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>keystone_tenant {'myproject': name='projectX',
>>>>>>>>>>>>>> domain=>'domainY',
>>>>>>>>>>>>>> ...}
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Notes:
>>>>>>>>>>>>>>   - Actually using both combined should work too with
>>>>>>>>>>>>>> the domain
>>>>>>>>>>>>>> supposedly overriding the name part of the domain.
>>>>>>>>>>>>>>   - Please look at [1] this for some background
>>>>>>>>>>>>>> between the two
>>>>>>>>>>>>>> approaches:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The question
>>>>>>>>>>>>>> -
>>>>>>>>>>>>>> Decide between the two approaches, the one we would like to
>>>>>>>>>>>>>> retain for
>>>>>>>>>>>>>> puppet-keystone.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Why it matters?
>>>>>>>>>>>>>> ---
>>>>>>>>>>>>>> 1. Domain names are mandatory in every user, group or
>>>>>>>>>>>>>> project.
>>>>>>>>>>>>>> Besides
>>>>>>>>>>>>>> the backward compatibility period mentioned earlier, where
>>>>>>>>>>>>>> no domain
>>>>>>>>>>>>>> means using the default one.
>>>>>>>>>>>>>> 2. Long term impact
>>>>>>>>>>>>>> 3. Both approaches are not completely equivalent which
>>>>>>>>>>>>>> different
>>>>>>>>>>>>>> consequences on the future usage.
>>>>>>>>>>>>> I can't see why they couldn't be equivalent, but I may be
>>>>>>>>>>>>> missing
>>>>>>>>>>>>> something here.
>>>>>>>>>>>> I think we could support both.  I don't see it as an either/or
>>>>>>>>>>>> situation.
>>>>>>>>>>>>
>>>>>>>>>>>>>> 4. Being consistent
>>>>>>>>>>>>>> 5. Therefore the community to decide
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Pros/Cons
>>>>>>>>>>>>>> --
>>>>>

Re: [openstack-dev] [puppet] WARNING - breaking backwards compatibility in puppet-keystone

[Gilles Dubreuil]

On 08/10/15 07:17, Rich Megginson wrote:
> On 10/07/2015 03:54 PM, Matt Fischer wrote:
>>
>> I thought the agreement was that default would be assumed so that we
>> didn't break backwards compatibility?
>>
> 
> puppet-heat had already started using domains, and had already written
> their code based on the implementation where an unqualified name was
> allowed if it was unique among all domains.  That code will need to
> change to specify the domain.  Any other code that was already using
> domains (which I'm assuming is hardly any, if at all) will also need to
> change.
> 
> 

Patch for puppet-heat: https://review.openstack.org/232366

The indirection patch depends on it and both would have to be merged
together.


>> On Oct 7, 2015 10:35 AM, "Rich Megginson" > > wrote:
>>
>> tl;dr You must specify a domain when using domain scoped resources.
>>
>> If you are using domains with puppet-keystone, there is a proposed
>> patch that will break backwards compatibility.
>>
>> https://review.openstack.org/#/c/226624/ Replace indirection calls
>>
>> "Indirection calls are replaced with #fetch_project and
>> #fetch_user methods
>> using python-openstackclient (OSC).
>>
>> Also removes the assumption that if a resource is unique within a
>> domain space
>> then the domain doesn't have to be specified."
>>
>> It is the last part which is causing backwards compatibility to be
>> broken.  This patch requires that a domain scoped resource _must_
>> be qualified with the domain name if _not_ in the 'Default'
>> domain.  Previously, you did not have to qualify a resource name
>> with the domain if the name was unique in _all_ domains.  The
>> problem was this code relied heavily on puppet indirection, and
>> was complex and difficult to maintain.  We removed it in favor of
>> a very simple implementation: if the name is not qualified with a
>> domain, it must be in the 'Default' domain.
>>

Matt,

The current implementation is *real* pain and slowing us down.


>> Here is an example from puppet-heat - the 'heat_admin' user has
>> been created in the 'heat_stack' domain previously.
>>
>> ensure_resource('keystone_user_role', 
>> 'heat_admin@::heat_stack", {
>>   'roles' => ['admin'],
>> })
>>
>> This means "assign the user 'heat_admin' in the unspecified domain
>> to have the domain scoped role 'admin' in the 'heat_stack'
>> domain". It is a domain scoped role, not a project scoped role,
>> because in "@::heat_stack" there is no project, only a domain.
>> Note that the domain for the 'heat_admin' user is unspecified. In
>> order to specify the domain you must use
>> 'heat_admin::heat_stack@::heat_stack'. This is the recommended fix
>> - to fully qualify the user + domain.
>>
>> The breakage manifests itself like this, from the logs::
>>
>> 2015-10-02 06:07:39.574 | Debug: Executing '/usr/bin/openstack
>> user show --format shell heat_admin --domain Default'
>> 2015-10-02 06:07:40.505 | Error:
>> 
>> /Stage[main]/Heat::Keystone::Domain/Keystone_user_role[heat_admin@::heat]:
>> Could not evaluate: No user heat_admin with domain  found
>>
>> This is from the keystone_user_role code. Since the role user was
>> specified as 'heat_admin' with no domain, the keystone_user_role
>> code looks for 'heat_admin' in the 'Default' domain and can't find
>> it, and raises an error.
>>
>> Right now, the only way to specify the domain is by adding
>> '::domain_name' to the user name, as
>> 'heat_admin::heat_stack@::heat_stack'.  Sofer is working on a way
>> to add the domain name as a parameter of keystone_user_role -
>> https://review.openstack.org/226919 - so in the near future you
>> will be able to specify the resource like this:
>>
>>
>> ensure_resource('keystone_user_role', 
>> 'heat_admin@::heat_stack", {
>>   'roles' => ['admin'],
>>   'user_domain_name' => 'heat_stack',
>> })
>>
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

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

Re: [openstack-dev] [puppet][keystone] Choose domain names with 'composite namevar' or 'meaningless name'?

[Gilles Dubreuil]

On 30/09/15 03:43, Rich Megginson wrote:
> On 09/28/2015 10:18 PM, Gilles Dubreuil wrote:
>>
>> On 15/09/15 19:55, Sofer Athlan-Guyot wrote:
>>> Gilles Dubreuil <gil...@redhat.com> writes:
>>>
>>>> On 15/09/15 06:53, Rich Megginson wrote:
>>>>> On 09/14/2015 02:30 PM, Sofer Athlan-Guyot wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Gilles Dubreuil <gil...@redhat.com> writes:
>>>>>>
>>>>>>> A. The 'composite namevar' approach:
>>>>>>>
>>>>>>>  keystone_tenant {'projectX::domainY': ... }
>>>>>>>B. The 'meaningless name' approach:
>>>>>>>
>>>>>>> keystone_tenant {'myproject': name='projectX',
>>>>>>> domain=>'domainY',
>>>>>>> ...}
>>>>>>>
>>>>>>> Notes:
>>>>>>>- Actually using both combined should work too with the domain
>>>>>>> supposedly overriding the name part of the domain.
>>>>>>>- Please look at [1] this for some background between the two
>>>>>>> approaches:
>>>>>>>
>>>>>>> The question
>>>>>>> -
>>>>>>> Decide between the two approaches, the one we would like to
>>>>>>> retain for
>>>>>>> puppet-keystone.
>>>>>>>
>>>>>>> Why it matters?
>>>>>>> ---
>>>>>>> 1. Domain names are mandatory in every user, group or project.
>>>>>>> Besides
>>>>>>> the backward compatibility period mentioned earlier, where no domain
>>>>>>> means using the default one.
>>>>>>> 2. Long term impact
>>>>>>> 3. Both approaches are not completely equivalent which different
>>>>>>> consequences on the future usage.
>>>>>> I can't see why they couldn't be equivalent, but I may be missing
>>>>>> something here.
>>>>> I think we could support both.  I don't see it as an either/or
>>>>> situation.
>>>>>
>>>>>>> 4. Being consistent
>>>>>>> 5. Therefore the community to decide
>>>>>>>
>>>>>>> Pros/Cons
>>>>>>> --
>>>>>>> A.
>>>>>> I think it's the B: meaningless approach here.
>>>>>>
>>>>>>> Pros
>>>>>>>   - Easier names
>>>>>> That's subjective, creating unique and meaningful name don't look
>>>>>> easy
>>>>>> to me.
>>>>> The point is that this allows choice - maybe the user already has some
>>>>> naming scheme, or wants to use a more "natural" meaningful name -
>>>>> rather
>>>>> than being forced into a possibly "awkward" naming scheme with "::"
>>>>>
>>>>>keystone_user { 'heat domain admin user':
>>>>>  name => 'admin',
>>>>>  domain => 'HeatDomain',
>>>>>  ...
>>>>>}
>>>>>
>>>>>keystone_user_role {'heat domain admin user@::HeatDomain':
>>>>>  roles => ['admin']
>>>>>  ...
>>>>>}
>>>>>
>>>>>>> Cons
>>>>>>>   - Titles have no meaning!
>>>>> They have meaning to the user, not necessarily to Puppet.
>>>>>
>>>>>>>   - Cases where 2 or more resources could exists
>>>>> This seems to be the hardest part - I still cannot figure out how
>>>>> to use
>>>>> "compound" names with Puppet.
>>>>>
>>>>>>>   - More difficult to debug
>>>>> More difficult than it is already? :P
>>>>>
>>>>>>>   - Titles mismatch when listing the resources (self.instances)
>>>>>>>
>>>>>>> B.
>>>>>>> Pros
>>>>>>>   - Unique titles guaranteed
>>>>>>>   - No ambiguity between resource found and their title
>>>>>>> Cons
>>>>>>>   - More complicated titles
>>>>>>> My vote
>&g

Re: [openstack-dev] [puppet][keystone] Choose domain names with 'composite namevar' or 'meaningless name'?

[Gilles Dubreuil]

On 15/09/15 19:55, Sofer Athlan-Guyot wrote:
> Gilles Dubreuil <gil...@redhat.com> writes:
> 
>> On 15/09/15 06:53, Rich Megginson wrote:
>>> On 09/14/2015 02:30 PM, Sofer Athlan-Guyot wrote:
>>>> Hi,
>>>>
>>>> Gilles Dubreuil <gil...@redhat.com> writes:
>>>>
>>>>> A. The 'composite namevar' approach:
>>>>>
>>>>> keystone_tenant {'projectX::domainY': ... }
>>>>>   B. The 'meaningless name' approach:
>>>>>
>>>>>keystone_tenant {'myproject': name='projectX', domain=>'domainY',
>>>>> ...}
>>>>>
>>>>> Notes:
>>>>>   - Actually using both combined should work too with the domain
>>>>> supposedly overriding the name part of the domain.
>>>>>   - Please look at [1] this for some background between the two
>>>>> approaches:
>>>>>
>>>>> The question
>>>>> -
>>>>> Decide between the two approaches, the one we would like to retain for
>>>>> puppet-keystone.
>>>>>
>>>>> Why it matters?
>>>>> ---
>>>>> 1. Domain names are mandatory in every user, group or project. Besides
>>>>> the backward compatibility period mentioned earlier, where no domain
>>>>> means using the default one.
>>>>> 2. Long term impact
>>>>> 3. Both approaches are not completely equivalent which different
>>>>> consequences on the future usage.
>>>> I can't see why they couldn't be equivalent, but I may be missing
>>>> something here.
>>>
>>> I think we could support both.  I don't see it as an either/or situation.
>>>
>>>>
>>>>> 4. Being consistent
>>>>> 5. Therefore the community to decide
>>>>>
>>>>> Pros/Cons
>>>>> --
>>>>> A.
>>>> I think it's the B: meaningless approach here.
>>>>
>>>>>Pros
>>>>>  - Easier names
>>>> That's subjective, creating unique and meaningful name don't look easy
>>>> to me.
>>>
>>> The point is that this allows choice - maybe the user already has some
>>> naming scheme, or wants to use a more "natural" meaningful name - rather
>>> than being forced into a possibly "awkward" naming scheme with "::"
>>>
>>>   keystone_user { 'heat domain admin user':
>>> name => 'admin',
>>> domain => 'HeatDomain',
>>> ...
>>>   }
>>>
>>>   keystone_user_role {'heat domain admin user@::HeatDomain':
>>> roles => ['admin']
>>> ...
>>>   }
>>>
>>>>
>>>>>Cons
>>>>>  - Titles have no meaning!
>>>
>>> They have meaning to the user, not necessarily to Puppet.
>>>
>>>>>  - Cases where 2 or more resources could exists
>>>
>>> This seems to be the hardest part - I still cannot figure out how to use
>>> "compound" names with Puppet.
>>>
>>>>>  - More difficult to debug
>>>
>>> More difficult than it is already? :P
>>>
>>>>>  - Titles mismatch when listing the resources (self.instances)
>>>>>
>>>>> B.
>>>>>Pros
>>>>>  - Unique titles guaranteed
>>>>>  - No ambiguity between resource found and their title
>>>>>Cons
>>>>>  - More complicated titles
>>>>> My vote
>>>>> 
>>>>> I would love to have the approach A for easier name.
>>>>> But I've seen the challenge of maintaining the providers behind the
>>>>> curtains and the confusion it creates with name/titles and when not sure
>>>>> about the domain we're dealing with.
>>>>> Also I believe that supporting self.instances consistently with
>>>>> meaningful name is saner.
>>>>> Therefore I vote B
>>>> +1 for B.
>>>>
>>>> My view is that this should be the advertised way, but the other method
>>>> (meaningless) should be there if the user need it.
>>>>
>>>> So as far as I'm concerned the two idioms should co-exist.  This would
>>>> mimic what is possible with all puppet resources.  For instance you can

Re: [openstack-dev] [puppet][keystone] Choose domain names with 'composite namevar' or 'meaningless name'?

[Gilles Dubreuil]

On 17/09/15 06:58, Cody Herriges wrote:
> I wrote my first composite namevar type a few years and ago and all the
> magic is basically a single block of code inside the type...
> 
> https://github.com/puppetlabs/puppetlabs-java_ks/blob/master/lib/puppet/type/java_ks.rb#L145-L169
> 
> It basically boils down to these three things:
> 
> * Pick your namevars
> (https://github.com/puppetlabs/puppetlabs-java_ks/blob/master/lib/puppet/type/java_ks.rb#L49-L64)
> * Pick a delimiter
>   - Personally I'd use @ here since we are talking about domains
> * Build your self.title_patterns method, accounting for delimited names
> and arbitrary names.
> 
> While it looks like the README never got updated, the java_ks example
> supports both meaningful titles and arbitrary ones.
> 
> java_ks { 'activemq_puppetca_keystore':
>   ensure   => latest,
>   name => 'puppetca',
>   certificate  => '/etc/puppet/ssl/certs/ca.pem',
>   target   => '/etc/activemq/broker.ks',
>   password => 'puppet',
>   trustcacerts => true,
> }
> 
> java_ks { 'broker.example.com:/etc/activemq/broker.ks':
>   ensure  => latest,
>   certificate =>
> '/etc/puppet/ssl/certs/broker.example.com.pe-internal-broker.pem',
>   private_key =>
> '/etc/puppet/ssl/private_keys/broker.example.com.pe-internal-broker.pem',
>   password=> 'puppet',
> }
> 
> You'll notice the first being an arbitrary title and the second
> utilizing a ":" as a delimiter and omitting the name and target parameters.
> 
> Another code example can be found in the package type.
> 
> https://github.com/puppetlabs/puppet/blob/master/lib/puppet/type/package.rb#L268-L291.
> 

Hi Cody,

Thank you for the example!

That's going to help as the expected returned array from
#self.title_pattern is effectively not intuitive!

Cheers,
Gilles


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

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

Re: [openstack-dev] [puppet][keystone] Choose domain names with 'composite namevar' or 'meaningless name'?

[Gilles Dubreuil]

On 15/09/15 06:53, Rich Megginson wrote:
> On 09/14/2015 02:30 PM, Sofer Athlan-Guyot wrote:
>> Hi,
>>
>> Gilles Dubreuil <gil...@redhat.com> writes:
>>
>>> A. The 'composite namevar' approach:
>>>
>>> keystone_tenant {'projectX::domainY': ... }
>>>   B. The 'meaningless name' approach:
>>>
>>>keystone_tenant {'myproject': name='projectX', domain=>'domainY',
>>> ...}
>>>
>>> Notes:
>>>   - Actually using both combined should work too with the domain
>>> supposedly overriding the name part of the domain.
>>>   - Please look at [1] this for some background between the two
>>> approaches:
>>>
>>> The question
>>> -
>>> Decide between the two approaches, the one we would like to retain for
>>> puppet-keystone.
>>>
>>> Why it matters?
>>> ---
>>> 1. Domain names are mandatory in every user, group or project. Besides
>>> the backward compatibility period mentioned earlier, where no domain
>>> means using the default one.
>>> 2. Long term impact
>>> 3. Both approaches are not completely equivalent which different
>>> consequences on the future usage.
>> I can't see why they couldn't be equivalent, but I may be missing
>> something here.
> 
> I think we could support both.  I don't see it as an either/or situation.
> 
>>
>>> 4. Being consistent
>>> 5. Therefore the community to decide
>>>
>>> Pros/Cons
>>> --
>>> A.
>> I think it's the B: meaningless approach here.
>>
>>>Pros
>>>  - Easier names
>> That's subjective, creating unique and meaningful name don't look easy
>> to me.
> 
> The point is that this allows choice - maybe the user already has some
> naming scheme, or wants to use a more "natural" meaningful name - rather
> than being forced into a possibly "awkward" naming scheme with "::"
> 
>   keystone_user { 'heat domain admin user':
> name => 'admin',
> domain => 'HeatDomain',
> ...
>   }
> 
>   keystone_user_role {'heat domain admin user@::HeatDomain':
> roles => ['admin']
> ...
>   }
> 
>>
>>>Cons
>>>  - Titles have no meaning!
> 
> They have meaning to the user, not necessarily to Puppet.
> 
>>>  - Cases where 2 or more resources could exists
> 
> This seems to be the hardest part - I still cannot figure out how to use
> "compound" names with Puppet.
> 
>>>  - More difficult to debug
> 
> More difficult than it is already? :P
> 
>>>  - Titles mismatch when listing the resources (self.instances)
>>>
>>> B.
>>>Pros
>>>  - Unique titles guaranteed
>>>  - No ambiguity between resource found and their title
>>>Cons
>>>  - More complicated titles
>>> My vote
>>> 
>>> I would love to have the approach A for easier name.
>>> But I've seen the challenge of maintaining the providers behind the
>>> curtains and the confusion it creates with name/titles and when not sure
>>> about the domain we're dealing with.
>>> Also I believe that supporting self.instances consistently with
>>> meaningful name is saner.
>>> Therefore I vote B
>> +1 for B.
>>
>> My view is that this should be the advertised way, but the other method
>> (meaningless) should be there if the user need it.
>>
>> So as far as I'm concerned the two idioms should co-exist.  This would
>> mimic what is possible with all puppet resources.  For instance you can:
>>
>>file { '/tmp/foo.bar': ensure => present }
>>
>> and you can
>>
>>file { 'meaningless_id': name => '/tmp/foo.bar', ensure => present }
>>
>> The two refer to the same resource.
> 
> Right.
> 

I disagree, using the name for the title is not creating a composite
name. The latter requires adding at least another parameter to be part
of the title.

Also in the case of the file resource, a path/filename is a unique name,
which is not the case of an Openstack user which might exist in several
domains.

I actually added the meaningful name case in:
http://lists.openstack.org/pipermail/openstack-dev/2015-September/074325.html

But that doesn't work very well because without adding the domain to the
name, the following fails:

keystone_tenant {'project_1': domain => 'domain_A', ...}
keystone_tenant {'project_1': domain => 'domain_B', ...}

And addin

Re: [openstack-dev] [puppet][keystone] Choose domain names with 'composite namevar' or 'meaningless name'?

[Gilles Dubreuil]

On 12/09/15 00:52, Morgan Fainberg wrote:
> On Fri, Sep 11, 2015 at 4:25 AM, Gilles Dubreuil <gil...@redhat.com
> <mailto:gil...@redhat.com>> wrote:
> 
> 
> 
> On 11/09/15 20:17, David Chadwick wrote:
> > Whichever approach is adopted you need to consider the future and the
> > longer term objective of moving to fully hierarchical names. I believe
> > the current Keystone approach is only an interim one, as it only
> > supports partial hierarchies. Fully hierarchical names has been
> > discussed in the Keystone group, but I believe that this has been
> > shelved until later in order to get a quick fix released now.
> >
> > regards
> >
> > David
> >
> 
> Thanks David,
> 
> That's interesting.
> So sub projects are pushing the issue further down.
> And maybe one day sub domains and sub users?
> 
> keystone_role_user {
> 'user.subuser::domain1@project.subproject.subsubproject::domain2':
> roles => [...]
> }
> 
> or
> 
> keystone_role_user {'user.subuser':
>   user_domain => 'domain1',
>   tenant => 'project.subproject',
>   tenant_domain => 'domain2',
>   roles => [...]
> }
> 
> I tend to think the domain must stick with the name it's associated
> with, otherwise we have to say 'here the domain for this and that, etc'.
> 
> 
> 
> > On 11/09/2015 08:03, Gilles Dubreuil wrote:
> >> Hi,
> >>
> >> Today in the #openstack-puppet channel a discussion about the pro and
> >> cons of using domain parameter for Keystone V3 has been left opened.
> >>
> >> The context
> >> 
> >> Domain names are needed in Openstack Keystone V3 for identifying
> users
> >> or groups (of users) within different projects (tenant).
> >> Users and groups are uniquely identified within a domain (or a
> realm as
> >> opposed to project domains).
> >> Then projects have their own domain so users or groups can be
> assigned
> >> to them through roles.
> >>
> >> In Kilo, Keystone V3 have been introduced as an experimental feature.
> >> Puppet providers such as keystone_tenant, keystone_user,
> >> keystone_role_user have been adapted to support it.
> >> Also new ones have appeared (keystone_domain) or are their way
> >> (keystone_group, keystone_trust).
> >> And to be backward compatible with V2, the default domain is used
> when
> >> no domain is provided.
> >>
> >> In existing providers such as keystone_tenant, the domain can be
> either
> >> part of the name or provided as a parameter:
> >>
> >> A. The 'composite namevar' approach:
> >>
> >>keystone_tenant {'projectX::domainY': ... }


> >> B. The 'meaningless name' approach:
> >>
> >>   keystone_tenant {'myproject': name='projectX',
> domain=>'domainY', ...}
> >>

Just for the sake of the discussion, I should have mentioned the
'classic' approach using a meaningful title (where name = title) which
doesn't work for the domain scope:

A first project comes with:
keystone_tenant {'projectX', domain=>'domainY', ...}

Another tenant with same name in a different domain cannot be created:

keystone_tenant {'projectX', domain=>'domainZ', ...}

> >> Notes:
> >>  - Actually using both combined should work too with the domain
> >> supposedly overriding the name part of the domain.
> >>  - Please look at [1] this for some background between the two
> approaches:
> >>
> >> The question
> >> -
> >> Decide between the two approaches, the one we would like to
> retain for
> >> puppet-keystone.
> >>
> >> Why it matters?
> >> ---
> >> 1. Domain names are mandatory in every user, group or project.
> Besides
> >> the backward compatibility period mentioned earlier, where no domain
> >> means using the default one.
> >> 2. Long term impact
> >> 3. Both approaches are not completely equivalent which different
> >> consequences on the future usage.
> >> 4. Being consistent
> >> 5. Therefore the community to decide
> >>
> >> The two approaches are not technically equivalent and it also depends
>  

[openstack-dev] [puppet][keystone] Choose domain names with 'composite namevar' or 'meaningless name'?

[Gilles Dubreuil]

Hi,

Today in the #openstack-puppet channel a discussion about the pro and
cons of using domain parameter for Keystone V3 has been left opened.

The context

Domain names are needed in Openstack Keystone V3 for identifying users
or groups (of users) within different projects (tenant).
Users and groups are uniquely identified within a domain (or a realm as
opposed to project domains).
Then projects have their own domain so users or groups can be assigned
to them through roles.

In Kilo, Keystone V3 have been introduced as an experimental feature.
Puppet providers such as keystone_tenant, keystone_user,
keystone_role_user have been adapted to support it.
Also new ones have appeared (keystone_domain) or are their way
(keystone_group, keystone_trust).
And to be backward compatible with V2, the default domain is used when
no domain is provided.

In existing providers such as keystone_tenant, the domain can be either
part of the name or provided as a parameter:

A. The 'composite namevar' approach:

   keystone_tenant {'projectX::domainY': ... }
 B. The 'meaningless name' approach:

  keystone_tenant {'myproject': name='projectX', domain=>'domainY', ...}

Notes:
 - Actually using both combined should work too with the domain
supposedly overriding the name part of the domain.
 - Please look at [1] this for some background between the two approaches:

The question
-
Decide between the two approaches, the one we would like to retain for
puppet-keystone.

Why it matters?
---
1. Domain names are mandatory in every user, group or project. Besides
the backward compatibility period mentioned earlier, where no domain
means using the default one.
2. Long term impact
3. Both approaches are not completely equivalent which different
consequences on the future usage.
4. Being consistent
5. Therefore the community to decide

The two approaches are not technically equivalent and it also depends
what a user might expect from a resource title.
See some of the examples below.

Because OpenStack DB tables have IDs to uniquely identify objects, it
can have several objects of a same family with the same name.
This has made things difficult for Puppet resources to guarantee
idem-potency of having unique resources.
In the context of Keystone V3 domain, hopefully this is not the case for
the users, groups or projects but unfortunately this is still the case
for trusts.

Pros/Cons
--
A.
  Pros
- Easier names
  Cons
- Titles have no meaning!
- Cases where 2 or more resources could exists
- More difficult to debug
- Titles mismatch when listing the resources (self.instances)

B.
  Pros
- Unique titles guaranteed
- No ambiguity between resource found and their title
  Cons
- More complicated titles

Examples
--
= Meaningless name example 1=
Puppet run:
  keystone_tenant {'myproject': name='project_A', domain=>'domain_1', ...}

Second run:
  keystone_tenant {'myproject': name='project_A', domain=>'domain_2', ...}

Result/Listing:

  keystone_tenant { 'project_A::domain_1':
ensure  => 'present',
domain  => 'domain_1',
enabled => 'true',
id  => '7f0a2b670f48437ba1204b17b7e3e9e9',
  }
   keystone_tenant { 'project_A::domain_2':
ensure  => 'present',
domain  => 'domain_2',
enabled => 'true',
id  => '4b8255591949484781da5d86f2c47be7',
  }

= Composite name example 1  =
Puppet run:
  keystone_tenant {'project_A::domain_1', ...}

Second run:
  keystone_tenant {'project_A::domain_2', ...}

# Result/Listing
  keystone_tenant { 'project_A::domain_1':
ensure  => 'present',
domain  => 'domain_1',
enabled => 'true',
id  => '7f0a2b670f48437ba1204b17b7e3e9e9',
   }
  keystone_tenant { 'project_A::domain_2':
ensure  => 'present',
domain  => 'domain_2',
enabled => 'true',
id  => '4b8255591949484781da5d86f2c47be7',
   }

= Meaningless name example 2  =
Puppet run:
  keystone_tenant {'myproject1': name='project_A', domain=>'domain_1', ...}
  keystone_tenant {'myproject2': name='project_A', domain=>'domain_1',
description=>'blah'...}

Result: project_A in domain_1 has a description

= Composite name example 2  =
Puppet run:
  keystone_tenant {'project_A::domain_1', ...}
  keystone_tenant {'project_A::domain_1', description => 'blah', ...}

Result: Error because the resource must be unique within a catalog

My vote

I would love to have the approach A for easier name.
But I've seen the challenge of maintaining the providers behind the
curtains and the confusion it creates with name/titles and when not sure
about the domain we're dealing with.
Also I believe that supporting self.instances consistently with
meaningful name is saner.
Therefore I vote B

Finally
--
Thanks for reading that far!
To choose, please provide feedback with more pros/cons, examples and
your vote.

Thanks,
Gilles


PS:
[1] https://groups.google.com/forum/#!topic/puppet-dev/CVYwvHnPSMc

Re: [openstack-dev] [puppet][keystone] Choose domain names with 'composite namevar' or 'meaningless name'?

[Gilles Dubreuil]

On 11/09/15 20:17, David Chadwick wrote:
> Whichever approach is adopted you need to consider the future and the
> longer term objective of moving to fully hierarchical names. I believe
> the current Keystone approach is only an interim one, as it only
> supports partial hierarchies. Fully hierarchical names has been
> discussed in the Keystone group, but I believe that this has been
> shelved until later in order to get a quick fix released now.
> 
> regards
> 
> David
> 

Thanks David,

That's interesting.
So sub projects are pushing the issue further down.
And maybe one day sub domains and sub users?

keystone_role_user {
'user.subuser::domain1@project.subproject.subsubproject::domain2':
roles => [...]
}

or

keystone_role_user {'user.subuser':
  user_domain => 'domain1',
  tenant => 'project.subproject',
  tenant_domain => 'domain2',
  roles => [...]
}

I tend to think the domain must stick with the name it's associated
with, otherwise we have to say 'here the domain for this and that, etc'.



> On 11/09/2015 08:03, Gilles Dubreuil wrote:
>> Hi,
>>
>> Today in the #openstack-puppet channel a discussion about the pro and
>> cons of using domain parameter for Keystone V3 has been left opened.
>>
>> The context
>> 
>> Domain names are needed in Openstack Keystone V3 for identifying users
>> or groups (of users) within different projects (tenant).
>> Users and groups are uniquely identified within a domain (or a realm as
>> opposed to project domains).
>> Then projects have their own domain so users or groups can be assigned
>> to them through roles.
>>
>> In Kilo, Keystone V3 have been introduced as an experimental feature.
>> Puppet providers such as keystone_tenant, keystone_user,
>> keystone_role_user have been adapted to support it.
>> Also new ones have appeared (keystone_domain) or are their way
>> (keystone_group, keystone_trust).
>> And to be backward compatible with V2, the default domain is used when
>> no domain is provided.
>>
>> In existing providers such as keystone_tenant, the domain can be either
>> part of the name or provided as a parameter:
>>
>> A. The 'composite namevar' approach:
>>
>>keystone_tenant {'projectX::domainY': ... }
>>  B. The 'meaningless name' approach:
>>
>>   keystone_tenant {'myproject': name='projectX', domain=>'domainY', ...}
>>
>> Notes:
>>  - Actually using both combined should work too with the domain
>> supposedly overriding the name part of the domain.
>>  - Please look at [1] this for some background between the two approaches:
>>
>> The question
>> -
>> Decide between the two approaches, the one we would like to retain for
>> puppet-keystone.
>>
>> Why it matters?
>> ---
>> 1. Domain names are mandatory in every user, group or project. Besides
>> the backward compatibility period mentioned earlier, where no domain
>> means using the default one.
>> 2. Long term impact
>> 3. Both approaches are not completely equivalent which different
>> consequences on the future usage.
>> 4. Being consistent
>> 5. Therefore the community to decide
>>
>> The two approaches are not technically equivalent and it also depends
>> what a user might expect from a resource title.
>> See some of the examples below.
>>
>> Because OpenStack DB tables have IDs to uniquely identify objects, it
>> can have several objects of a same family with the same name.
>> This has made things difficult for Puppet resources to guarantee
>> idem-potency of having unique resources.
>> In the context of Keystone V3 domain, hopefully this is not the case for
>> the users, groups or projects but unfortunately this is still the case
>> for trusts.
>>
>> Pros/Cons
>> --
>> A.
>>   Pros
>> - Easier names
>>   Cons
>> - Titles have no meaning!
>> - Cases where 2 or more resources could exists
>> - More difficult to debug
>> - Titles mismatch when listing the resources (self.instances)
>>
>> B.
>>   Pros
>> - Unique titles guaranteed
>> - No ambiguity between resource found and their title
>>   Cons
>> - More complicated titles
>>
>> Examples
>> --
>> = Meaningless name example 1=
>> Puppet run:
>>   keystone_tenant {'myproject': name='project_A', domain=>'domain_1', ...}
>>
>> Second run:
>>   keystone_tenant {'myproject': name='project_A', domain=>'domain_2', ...}
>>
>> Result/Listing:
>>
>>   k

Re: [openstack-dev] [puppet][keystone] Keystone resource naming with domain support - no '::domain' if 'Default'

[Gilles Dubreuil]

On 27/08/15 16:59, Gilles Dubreuil wrote:
 
 
 On 26/08/15 06:30, Rich Megginson wrote:
 This concerns the support of the names of domain scoped Keystone
 resources (users, projects, etc.) in puppet.

 At the puppet-openstack meeting today [1] we decided that
 puppet-openstack will support Keystone domain scoped resource names
 without a '::domain' in the name, only if the 'default_domain_id'
 parameter in Keystone has _not_ been set.  That is, if the default
 domain is 'Default'.  In addition:

 * In the OpenStack L release, if 'default_domain_id' is set, puppet will
 issue a warning if a name is used without '::domain'.

The default domain is always set to 'default' unless overridden to
something else.

 * In the OpenStack M release, puppet will issue a warning if a name is
 used without '::domain', even if 'default_domain_id' is not set.

Therefore the 'default_domain_id' is never 'not set'.

 * In N (or possibly, O), resource names will be required to have
 '::domain'.


I understand, from Openstack N release and ongoing, the domain would be
mandatory.

So I would like to revisit the list:

* In OpenStack L release:
  Puppet will issue a warning if a name is used without '::domain'.

* In OpenStack M release:
  Puppet will issue a warning if a name is used without '::domain'.

* From Openstack N release:
  A name must be used with '::domain'.


 
 +1
 
 The current spec [2] and current code [3] try to support names without a
 '::domain' in the name, in non-default domains, provided the name is
 unique across _all_ domains.  This will have to be changed in the
 current code and spec.

 
 Ack
 

 [1]
 http://eavesdrop.openstack.org/meetings/puppet_openstack/2015/puppet_openstack.2015-08-25-15.01.html

 [2]
 http://specs.openstack.org/openstack/puppet-openstack-specs/specs/kilo/api-v3-support.html

 [3]
 https://github.com/openstack/puppet-keystone/blob/master/lib/puppet/provider/keystone_user/openstack.rb#L217



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

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

Re: [openstack-dev] [puppet][keystone] Keystone resource naming with domain support - no '::domain' if 'Default'

[Gilles Dubreuil]

On 27/08/15 22:40, Gilles Dubreuil wrote:
 
 
 On 27/08/15 16:59, Gilles Dubreuil wrote:


 On 26/08/15 06:30, Rich Megginson wrote:
 This concerns the support of the names of domain scoped Keystone
 resources (users, projects, etc.) in puppet.

 At the puppet-openstack meeting today [1] we decided that
 puppet-openstack will support Keystone domain scoped resource names
 without a '::domain' in the name, only if the 'default_domain_id'
 parameter in Keystone has _not_ been set.  That is, if the default
 domain is 'Default'.  In addition:

 * In the OpenStack L release, if 'default_domain_id' is set, puppet will
 issue a warning if a name is used without '::domain'.
 
 The default domain is always set to 'default' unless overridden to
 something else.

Just to clarify, I don't see any logical difference between the
default_domain_id to be 'default' or something else.

Per keystone.conf comment (as seen below) the default_domain_id,
whatever its value, is created as a valid domain.

# This references the domain to use for all Identity API v2 requests
(which are not aware of domains). A domain with this ID will be created
for you by keystone-manage db_sync in migration 008. The domain
referenced by this ID cannot be deleted on the v3 API, to prevent
accidentally breaking the v2 API. There is nothing special about this
domain, other than the fact that it must exist to order to maintain
support for your v2 clients. (string value)
#default_domain_id = default

To be able to test if a 'default_domain_id' is set or not, actually
translates to checking if the id is 'default' or something else.
But I don't see the point here. If a user decides to change default' to
'This_is_the_domain_id_for_legacy_v2, how does this help?

If that makes sense then I would actually avoid the intermediate stage:

* In OpenStack L release:
Puppet will issue a warning if a name is used without '::domain'.

* From Openstack M release:
A name must be used with '::domain'.

 
 * In the OpenStack M release, puppet will issue a warning if a name is
 used without '::domain', even if 'default_domain_id' is not set.
 
 Therefore the 'default_domain_id' is never 'not set'.
 
 * In N (or possibly, O), resource names will be required to have
 '::domain'.

 
 I understand, from Openstack N release and ongoing, the domain would be
 mandatory.
 
 So I would like to revisit the list:
 
 * In OpenStack L release:
   Puppet will issue a warning if a name is used without '::domain'.
 
 * In OpenStack M release:
   Puppet will issue a warning if a name is used without '::domain'.
 
 * From Openstack N release:
   A name must be used with '::domain'.
 
 

 +1

 The current spec [2] and current code [3] try to support names without a
 '::domain' in the name, in non-default domains, provided the name is
 unique across _all_ domains.  This will have to be changed in the
 current code and spec.


 Ack


 [1]
 http://eavesdrop.openstack.org/meetings/puppet_openstack/2015/puppet_openstack.2015-08-25-15.01.html

 [2]
 http://specs.openstack.org/openstack/puppet-openstack-specs/specs/kilo/api-v3-support.html

 [3]
 https://github.com/openstack/puppet-keystone/blob/master/lib/puppet/provider/keystone_user/openstack.rb#L217



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

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

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

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

Re: [openstack-dev] [puppet][keystone] Keystone resource naming with domain support - no '::domain' if 'Default'

[Gilles Dubreuil]

On 28/08/15 00:53, Rich Megginson wrote:
 On 08/27/2015 07:00 AM, Gilles Dubreuil wrote:

 On 27/08/15 22:40, Gilles Dubreuil wrote:

 On 27/08/15 16:59, Gilles Dubreuil wrote:

 On 26/08/15 06:30, Rich Megginson wrote:
 This concerns the support of the names of domain scoped Keystone
 resources (users, projects, etc.) in puppet.

 At the puppet-openstack meeting today [1] we decided that
 puppet-openstack will support Keystone domain scoped resource names
 without a '::domain' in the name, only if the 'default_domain_id'
 parameter in Keystone has _not_ been set.  That is, if the default
 domain is 'Default'.  In addition:

 * In the OpenStack L release, if 'default_domain_id' is set, puppet
 will
 issue a warning if a name is used without '::domain'.
 The default domain is always set to 'default' unless overridden to
 something else.
 Just to clarify, I don't see any logical difference between the
 default_domain_id to be 'default' or something else.
 
 There is, however, a difference between explicitly setting the value to
 something other than 'default', and not setting it at all.
 
 That is, if a user/operator specifies
 
   keystone_domain { 'someotherdomain':
 is_default = true,
   }
 
 then the user/operation is explicitly telling puppet-keystone that a
 non-default domain is being used, and that the user/operator is aware of
 domains, and will create domain scoped resources with the '::domain' in
 the name.
 

That makes sense.

Let's chase down the default 'default' domain then.


 Per keystone.conf comment (as seen below) the default_domain_id,
 whatever its value, is created as a valid domain.

 # This references the domain to use for all Identity API v2 requests
 (which are not aware of domains). A domain with this ID will be created
 for you by keystone-manage db_sync in migration 008. The domain
 referenced by this ID cannot be deleted on the v3 API, to prevent
 accidentally breaking the v2 API. There is nothing special about this
 domain, other than the fact that it must exist to order to maintain
 support for your v2 clients. (string value)
 #default_domain_id = default

 To be able to test if a 'default_domain_id' is set or not, actually
 translates to checking if the id is 'default' or something else.
 
 Not exactly.  There is a difference between explicitly setting the
 value, and implicitly relying on the default 'default' value.
 
 But I don't see the point here. If a user decides to change default' to
 'This_is_the_domain_id_for_legacy_v2, how does this help?
 
 If the user changes that, then that means the user has also decided to
 explicitly provided '::domain' in all domain scoped resource names.
 

 If that makes sense then I would actually avoid the intermediate stage:

 * In OpenStack L release:
 Puppet will issue a warning if a name is used without '::domain'.

 * From Openstack M release:
 A name must be used with '::domain'.

 * In the OpenStack M release, puppet will issue a warning if a name is
 used without '::domain', even if 'default_domain_id' is not set.
 Therefore the 'default_domain_id' is never 'not set'.

 * In N (or possibly, O), resource names will be required to have
 '::domain'.

 I understand, from Openstack N release and ongoing, the domain would be
 mandatory.

 So I would like to revisit the list:

 * In OpenStack L release:
Puppet will issue a warning if a name is used without '::domain'.

 * In OpenStack M release:
Puppet will issue a warning if a name is used without '::domain'.

 * From Openstack N release:
A name must be used with '::domain'.


 +1

 The current spec [2] and current code [3] try to support names
 without a
 '::domain' in the name, in non-default domains, provided the name is
 unique across _all_ domains.  This will have to be changed in the
 current code and spec.

 Ack

 [1]
 http://eavesdrop.openstack.org/meetings/puppet_openstack/2015/puppet_openstack.2015-08-25-15.01.html


 [2]
 http://specs.openstack.org/openstack/puppet-openstack-specs/specs/kilo/api-v3-support.html


 [3]
 https://github.com/openstack/puppet-keystone/blob/master/lib/puppet/provider/keystone_user/openstack.rb#L217




 __

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

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

 __

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

Re: [openstack-dev] [puppet][keystone] Keystone resource naming with domain support - no '::domain' if 'Default'

[Gilles Dubreuil]

On 26/08/15 06:30, Rich Megginson wrote:
 This concerns the support of the names of domain scoped Keystone
 resources (users, projects, etc.) in puppet.
 
 At the puppet-openstack meeting today [1] we decided that
 puppet-openstack will support Keystone domain scoped resource names
 without a '::domain' in the name, only if the 'default_domain_id'
 parameter in Keystone has _not_ been set.  That is, if the default
 domain is 'Default'.  In addition:
 
 * In the OpenStack L release, if 'default_domain_id' is set, puppet will
 issue a warning if a name is used without '::domain'.
 * In the OpenStack M release, puppet will issue a warning if a name is
 used without '::domain', even if 'default_domain_id' is not set.
 * In N (or possibly, O), resource names will be required to have
 '::domain'.
 

+1

 The current spec [2] and current code [3] try to support names without a
 '::domain' in the name, in non-default domains, provided the name is
 unique across _all_ domains.  This will have to be changed in the
 current code and spec.
 

Ack

 
 [1]
 http://eavesdrop.openstack.org/meetings/puppet_openstack/2015/puppet_openstack.2015-08-25-15.01.html
 
 [2]
 http://specs.openstack.org/openstack/puppet-openstack-specs/specs/kilo/api-v3-support.html
 
 [3]
 https://github.com/openstack/puppet-keystone/blob/master/lib/puppet/provider/keystone_user/openstack.rb#L217
 
 
 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [Fuel][Puppet] Keystone V2/V3 service endpoints

[Gilles Dubreuil]

On 15/08/15 00:23, Rich Megginson wrote:
 On 08/14/2015 06:51 AM, Matthew Mosesohn wrote:
 Gilles,

 I already considered this when looking at another openstackclient
 issue. Version 1.0.4 has almost no changes from 1.0.3, which is the
 official release for Kilo. Maybe we can get this keystone URL handling
 fix backported to the 1.0.X branch of openstackclient?
 
 I think we need some sort of fix in openstacklib and/or puppet-keystone
 so that v3 providers that use token auth can replace any /v2.0 in the
 url with /v3, to override any settings of OS_URL or OS_AUTH_URL in ENV
 or openrc.
 

I've broken down https://review.openstack.org/212523 (now abandoned) in
three pieces:

The first 2 ones can be backported to Kilo.
1. https://review.openstack.org/213598
 https://review.openstack.org/213938
2. https://review.openstack.org/213603
 Once 1. gets merged in Liberty, we'll be able to cherry pick it.

That won't necessarily fix the issue but it won't hurt but more
importantly it's making things a bit easier with clear separation
between url assignments and getting endpoints.

The last and next coming piece removes the API version numbers from the
Endpoints. Meanwhile that one won't be 'back-portable' unless OSC
version on Kilo gets bumped up which not likely to happen.

I hope it helps.

Let's take it from there and see what else we can do to address those
v2/v3.0 issues.

Cheers,
Gilles


 -Matthew

 On Fri, Aug 14, 2015 at 3:47 PM, Gilles Dubreuil gil...@redhat.com
 mailto:gil...@redhat.com wrote:



 On 14/08/15 20:45, Gilles Dubreuil wrote:
 
 
  On 13/08/15 23:29, Rich Megginson wrote:
  On 08/13/2015 12:41 AM, Gilles Dubreuil wrote:
  Hi Matthew,
 
  On 11/08/15 01:14, Rich Megginson wrote:
  On 08/10/2015 07:46 AM, Matthew Mosesohn wrote:
  Sorry to everyone for bringing up this old thread, but it
 seems we may
  need more openstackclient/keystone experts to settle this.
 
  I'm referring to the comments in
  https://review.openstack.org/#/c/207873/
  Specifically comments from Richard Megginson and Gilles Dubreuil
  indicating openstackclient behavior for v3 keystone API.
 
 
  A few items seem to be under dispute:
  1 - Keystone should be able to accept v3 requests at
 
 
 http://keystone-server:5000/http://keystone-server:5000/http://keystone-server:5000/
  I don't think so.  Keystone requires the version suffix
 /v2.0 or
  /v3.
 
  Yes, if the public endpoint is set without a version then the
 service
  can deal with either version.
 
  http://paste.openstack.org/raw/412819/
 
  That is not true for the admin endpoint (authentication is
 already done,
  the admin services deals only with tokens), at least for now,
 Keystone
  devs are working on it.
 
  I thought it worked like this - the openstack cli will infer
 from the
  arguments if it should do v2 or v3 auth.  In the above case for v3,
  since you specify the username/password, osc knows it has to use
  password auth (as opposed to token auth), and since all of the
 required
  v3 arguments are provided (v3 api version, domains for
 user/project), it
  can use v3 password auth.  It knows it has to use the
 /v3/auth/token
  path to get a token.
 
  Similarly for v2, since it only has username/password, no v3
 api or v3
  domain arguments, it knows it has to use v2 password auth.  It
 knows it
  has to use /v2.0/token to get a token.
 
  With the puppet-keystone code, since it uses TOKEN/URL, osc
 cannot infer
  if it can use v2 or v3, so it requires the /v2.0 or /v3
 suffix, and
  the api version.
 
 
  First of my apologies because I confused admin enpdoint with the
 admin
  service (or whatever that's dubbed).
 
  As of Keystone v3 (not the API, the latest version of Keystone which
  supports both API v2.0 and V3), the OS_AUTH_URL doesn't need the
  version. That can be effectively any of the endpoints, either
 the main
  (or public) by default on port 5000 or the admin by default on port
  35357, the third one internal pointing to either of the first
 two ones.
 
  This is a behavior at Keystone level not at the OSC. I mean OSC will
  just reflect the http-api behavior.
 
  Now the admin service, the one needed for the OS-TOKEN (used for
  bootstrapping) needs a URL (OS_URL) with a version to work.
 
  ATM, the issue with puppet keystone is that endpoints, OS_URL and
  OS_AUTH_URL are walking on each others.
 
 

 My latest update on this one, is that I found out while testing beaker
 which is using OSC 1.0.3 is not handling OS_AUTH_URL properly.

 I had been testing with OSC 1.5.1 and now latest 1.6.1 from Dolerean
 repo, where the version-less URLs are working, but not with OSC 1.0.1

Re: [openstack-dev] [Fuel][Puppet] Keystone V2/V3 service endpoints

[Gilles Dubreuil]

On 13/08/15 23:29, Rich Megginson wrote:
 On 08/13/2015 12:41 AM, Gilles Dubreuil wrote:
 Hi Matthew,

 On 11/08/15 01:14, Rich Megginson wrote:
 On 08/10/2015 07:46 AM, Matthew Mosesohn wrote:
 Sorry to everyone for bringing up this old thread, but it seems we may
 need more openstackclient/keystone experts to settle this.

 I'm referring to the comments in
 https://review.openstack.org/#/c/207873/
 Specifically comments from Richard Megginson and Gilles Dubreuil
 indicating openstackclient behavior for v3 keystone API.


 A few items seem to be under dispute:
 1 - Keystone should be able to accept v3 requests at
 http://keystone-server:5000/http://keystone-server:5000/
 I don't think so.  Keystone requires the version suffix /v2.0 or
 /v3.

 Yes, if the public endpoint is set without a version then the service
 can deal with either version.

 http://paste.openstack.org/raw/412819/

 That is not true for the admin endpoint (authentication is already done,
 the admin services deals only with tokens), at least for now, Keystone
 devs are working on it.
 
 I thought it worked like this - the openstack cli will infer from the
 arguments if it should do v2 or v3 auth.  In the above case for v3,
 since you specify the username/password, osc knows it has to use
 password auth (as opposed to token auth), and since all of the required
 v3 arguments are provided (v3 api version, domains for user/project), it
 can use v3 password auth.  It knows it has to use the /v3/auth/token
 path to get a token.
 
 Similarly for v2, since it only has username/password, no v3 api or v3
 domain arguments, it knows it has to use v2 password auth.  It knows it
 has to use /v2.0/token to get a token.
 
 With the puppet-keystone code, since it uses TOKEN/URL, osc cannot infer
 if it can use v2 or v3, so it requires the /v2.0 or /v3 suffix, and
 the api version.
 

First of my apologies because I confused admin enpdoint with the admin
service (or whatever that's dubbed).

As of Keystone v3 (not the API, the latest version of Keystone which
supports both API v2.0 and V3), the OS_AUTH_URL doesn't need the
version. That can be effectively any of the endpoints, either the main
(or public) by default on port 5000 or the admin by default on port
35357, the third one internal pointing to either of the first two ones.

This is a behavior at Keystone level not at the OSC. I mean OSC will
just reflect the http-api behavior.

Now the admin service, the one needed for the OS-TOKEN (used for
bootstrapping) needs a URL (OS_URL) with a version to work.

ATM, the issue with puppet keystone is that endpoints, OS_URL and
OS_AUTH_URL are walking on each others.



 2 - openstackclient should be able to interpret v3 requests and append
 v3/ to OS_AUTH_URL=http://keystone-server.5000/ or rewrite the URL
 if it is set as
 OS_AUTH_URL=http://keystone-server.5000/http://keystone-server.5000/
 It does, if it can determine from the given authentication arguments if
 it can do v3 or v2.0.

 It effectively does, again, assuming the path doesn't contain a version
 number (x.x.x.x:5000)

 3 - All deployments require /etc/keystone/keystone.conf with a token
 (and not simply use openrc for creating additional endpoints, users,
 etc beyond keystone itself and an admin user)
 No.  What I said about this issue was Most people using
 puppet-keystone, and realizing Keystone resources on nodes that are not
 the Keystone node, put a /etc/keystone/keystone.conf on that node with
 the admin_token in it.

 That doesn't mean the deployment requires /etc/keystone/keystone.conf.
 It should be possible to realize Keystone resources on non-Keystone
 nodes by using ENV or openrc or other means.

 Agreed. Also keystone.conf is used only to bootstrap keystone
 installation and create admin users, etc.


 I believe it should be possible to set v2.0 keystone OS_AUTH_URL in
 openrc and puppet-keystone + puppet-openstacklib should be able to
 make v3 requests sensibly by manipulating the URL.
 Yes.  Because for the puppet-keystone resource providers, they are coded
 to a specific version of the api, and therefore need to be able to
 set/override the OS_IDENTITY_API_VERSION and the version suffix in
 the URL.

 No. To support V2 and V3, the OS_AUTH_URL must not contain any version
 in order.

 The less we deal with the version number the better!

 Additionally, creating endpoints/users/roles shouldbe possible via
 openrc alone.
 Yes.

 Yes, the openrc variables are used, if not available then the service
 token from the keystone.conf is used.

 It's not possible to write single node tests that can demonstrate this
 functionality, which is why it probably went undetected for so long.
 And since this is supported, we need tests for this.
 I'm not sure what's the issue besides the fact keystone_puppet doesn't
 generate a RC file once the admin user has been created. That is left to
 be done by the composition layer. Although we might want to integrate
 that.

 If that issue persists

Re: [openstack-dev] [Fuel][Puppet] Keystone V2/V3 service endpoints

[Gilles Dubreuil]

On 14/08/15 20:45, Gilles Dubreuil wrote:
 
 
 On 13/08/15 23:29, Rich Megginson wrote:
 On 08/13/2015 12:41 AM, Gilles Dubreuil wrote:
 Hi Matthew,

 On 11/08/15 01:14, Rich Megginson wrote:
 On 08/10/2015 07:46 AM, Matthew Mosesohn wrote:
 Sorry to everyone for bringing up this old thread, but it seems we may
 need more openstackclient/keystone experts to settle this.

 I'm referring to the comments in
 https://review.openstack.org/#/c/207873/
 Specifically comments from Richard Megginson and Gilles Dubreuil
 indicating openstackclient behavior for v3 keystone API.


 A few items seem to be under dispute:
 1 - Keystone should be able to accept v3 requests at
 http://keystone-server:5000/http://keystone-server:5000/
 I don't think so.  Keystone requires the version suffix /v2.0 or
 /v3.

 Yes, if the public endpoint is set without a version then the service
 can deal with either version.

 http://paste.openstack.org/raw/412819/

 That is not true for the admin endpoint (authentication is already done,
 the admin services deals only with tokens), at least for now, Keystone
 devs are working on it.

 I thought it worked like this - the openstack cli will infer from the
 arguments if it should do v2 or v3 auth.  In the above case for v3,
 since you specify the username/password, osc knows it has to use
 password auth (as opposed to token auth), and since all of the required
 v3 arguments are provided (v3 api version, domains for user/project), it
 can use v3 password auth.  It knows it has to use the /v3/auth/token
 path to get a token.

 Similarly for v2, since it only has username/password, no v3 api or v3
 domain arguments, it knows it has to use v2 password auth.  It knows it
 has to use /v2.0/token to get a token.

 With the puppet-keystone code, since it uses TOKEN/URL, osc cannot infer
 if it can use v2 or v3, so it requires the /v2.0 or /v3 suffix, and
 the api version.

 
 First of my apologies because I confused admin enpdoint with the admin
 service (or whatever that's dubbed).
 
 As of Keystone v3 (not the API, the latest version of Keystone which
 supports both API v2.0 and V3), the OS_AUTH_URL doesn't need the
 version. That can be effectively any of the endpoints, either the main
 (or public) by default on port 5000 or the admin by default on port
 35357, the third one internal pointing to either of the first two ones.
 
 This is a behavior at Keystone level not at the OSC. I mean OSC will
 just reflect the http-api behavior.
 
 Now the admin service, the one needed for the OS-TOKEN (used for
 bootstrapping) needs a URL (OS_URL) with a version to work.
 
 ATM, the issue with puppet keystone is that endpoints, OS_URL and
 OS_AUTH_URL are walking on each others.
 
 

My latest update on this one, is that I found out while testing beaker
which is using OSC 1.0.3 is not handling OS_AUTH_URL properly.

I had been testing with OSC 1.5.1 and now latest 1.6.1 from Dolerean
repo, where the version-less URLs are working, but not with OSC 1.0.1:

--

# cat openrc
export OS_AUTH_URL=http://127.0.0.1:5000
export OS_USERNAME=adminv3
export OS_PASSWORD=testing
export OS_PROJECT_NAME=openstackv3
export OS_USER_DOMAIN_NAME=admin_domain
export OS_PROJECT_DOMAIN_NAME=admin_domain
export OS_IDENTITY_API_VERSION=3

# openstack endpoint list -f csv
ID,Region,Service Name,Service Type,Enabled,Interface,URL
87b7db1b23df487bb4ec96de5aa3c271,RegionOne,keystone,identity,True,internal,http://127.0.0.1:5000;
d9b345109d8a4320ac0dd832d2532cce,RegionOne,keystone,identity,True,admin,http://127.0.0.1:35357;
f3a579a64f0241ef9aef3dc983e0fd4a,RegionOne,keystone,identity,True,public,http://127.0.0.1:5000;

--

# cat openrc_v2
export OS_AUTH_URL=http://[::1]:5000
export OS_USERNAME=admin
export OS_PASSWORD=a_big_secret
export OS_TENANT_NAME=openstack

# openstack endpoint list -f csv --long
ID,Region,Service Name,Service
Type,PublicURL,AdminURL,InternalURL
cf8825c44bd041109d5c7438ba9db8f3,RegionOne,keystone,identity,http://127.0.0.1:5000,http://127.0.0.1:35357,http://127.0.0.1:5000;





 2 - openstackclient should be able to interpret v3 requests and append
 v3/ to OS_AUTH_URL=http://keystone-server.5000/ or rewrite the URL
 if it is set as
 OS_AUTH_URL=http://keystone-server.5000/http://keystone-server.5000/
 It does, if it can determine from the given authentication arguments if
 it can do v3 or v2.0.

 It effectively does, again, assuming the path doesn't contain a version
 number (x.x.x.x:5000)

 3 - All deployments require /etc/keystone/keystone.conf with a token
 (and not simply use openrc for creating additional endpoints, users,
 etc beyond keystone itself and an admin user)
 No.  What I said about this issue was Most people using
 puppet-keystone, and realizing Keystone resources on nodes that are not
 the Keystone node, put a /etc/keystone/keystone.conf on that node with
 the admin_token in it.

 That doesn't mean the deployment requires /etc/keystone/keystone.conf.
 It should

Re: [openstack-dev] [Fuel][Puppet] Keystone V2/V3 service endpoints

[Gilles Dubreuil]

Hi Matthew,

On 11/08/15 01:14, Rich Megginson wrote:
 On 08/10/2015 07:46 AM, Matthew Mosesohn wrote:
 Sorry to everyone for bringing up this old thread, but it seems we may
 need more openstackclient/keystone experts to settle this.

 I'm referring to the comments in https://review.openstack.org/#/c/207873/
 Specifically comments from Richard Megginson and Gilles Dubreuil
 indicating openstackclient behavior for v3 keystone API.


 A few items seem to be under dispute:
 1 - Keystone should be able to accept v3 requests at
 http://keystone-server:5000/http://keystone-server:5000/
 
 I don't think so.  Keystone requires the version suffix /v2.0 or /v3.
 

Yes, if the public endpoint is set without a version then the service
can deal with either version.

http://paste.openstack.org/raw/412819/

That is not true for the admin endpoint (authentication is already done,
the admin services deals only with tokens), at least for now, Keystone
devs are working on it.

 2 - openstackclient should be able to interpret v3 requests and append
 v3/ to OS_AUTH_URL=http://keystone-server.5000/ or rewrite the URL
 if it is set as
 OS_AUTH_URL=http://keystone-server.5000/http://keystone-server.5000/
 
 It does, if it can determine from the given authentication arguments if
 it can do v3 or v2.0.
 

It effectively does, again, assuming the path doesn't contain a version
number (x.x.x.x:5000)

 3 - All deployments require /etc/keystone/keystone.conf with a token
 (and not simply use openrc for creating additional endpoints, users,
 etc beyond keystone itself and an admin user)
 
 No.  What I said about this issue was Most people using
 puppet-keystone, and realizing Keystone resources on nodes that are not
 the Keystone node, put a /etc/keystone/keystone.conf on that node with
 the admin_token in it.
 
 That doesn't mean the deployment requires /etc/keystone/keystone.conf. 
 It should be possible to realize Keystone resources on non-Keystone
 nodes by using ENV or openrc or other means.
 

Agreed. Also keystone.conf is used only to bootstrap keystone
installation and create admin users, etc.



 I believe it should be possible to set v2.0 keystone OS_AUTH_URL in
 openrc and puppet-keystone + puppet-openstacklib should be able to
 make v3 requests sensibly by manipulating the URL.
 
 Yes.  Because for the puppet-keystone resource providers, they are coded
 to a specific version of the api, and therefore need to be able to
 set/override the OS_IDENTITY_API_VERSION and the version suffix in the URL.
 

No. To support V2 and V3, the OS_AUTH_URL must not contain any version
in order.

The less we deal with the version number the better!

 Additionally, creating endpoints/users/roles shouldbe possible via
 openrc alone.
 
 Yes.
 

Yes, the openrc variables are used, if not available then the service
token from the keystone.conf is used.

 It's not possible to write single node tests that can demonstrate this
 functionality, which is why it probably went undetected for so long.
 
 And since this is supported, we need tests for this.

I'm not sure what's the issue besides the fact keystone_puppet doesn't
generate a RC file once the admin user has been created. That is left to
be done by the composition layer. Although we might want to integrate that.

If that issue persists, assuming the AUTH_URL is free for a version
number and having an openrc in place, we're going to need a bug number
to track the investigation.


 If anyone can speak up on these items, it could help influence the
 outcome of this patch.

 Thank you for your time.

 Best Regards,
 Matthew Mosesohn


Thanks,
Gilles


 On Fri, Jul 31, 2015 at 6:32 PM, Rich Megginson rmegg...@redhat.com
 mailto:rmegg...@redhat.com wrote:

 On 07/31/2015 07:18 AM, Matthew Mosesohn wrote:

 Jesse, thanks for raising this. Like you, I should just track
 upstream
 and wait for full V3 support.

 I've taken the quickest approach and written fixes to
 puppet-openstacklib and puppet-keystone:
 https://review.openstack.org/#/c/207873/
 https://review.openstack.org/#/c/207890/

 and again to Fuel-Library:
 https://review.openstack.org/#/c/207548/1

 I greatly appreciate the quick support from the community to
 find an
 appropriate solution. Looks like I'm just using a weird edge case
 where we're creating users on a separate node from where
 keystone is
 installed and it never got thoroughly tested, but I'm happy to fix
 bugs where I can.


 Most puppet deployments either realize all keystone resources on
 the keystone node, or drop an /etc/keystone/keystone.conf with
 admin token onto non-keystone nodes where additional keystone
 resources need to be realized.



 -Matthew

 On Fri, Jul 31, 2015 at 3:54 PM, Jesse Pretorius
 jesse.pretor...@gmail.com mailto:jesse.pretor...@gmail.com
 wrote

[openstack-dev] [puppet][keystone] To always use or not use domain name?

[Gilles Dubreuil]

While working on trust provider for the Keystone (V3) puppet module, a
question about using domain names came up.

Shall we allow or not to use names without specifying the domain name in
the resource call?

I have this trust case involving a trustor user, a trustee user and a
project.

For each user/project the domain can be explicit (mandatory):

trustor_name::domain_name

or implicit (optional):

trustor_name[::domain_name]

If a domain isn't specified the domain name can be assumed (intuited)
from either the default domain or the domain of the corresponding
object, if unique among all domains.

Although allowing to not use the domain might seems easier at first, I
believe it could lead to confusion and errors. The latter being harder
for the user to detect.

Therefore it might be better to always pass the domain information.

I believe using the full domain name approach is better.
But it's difficult to tell because in puppet-keystone and
puppet-openstacklib now rely on python-openstackclient (OSC) to
interface with Keystone. Because we can use OSC defaults
(OS_DEFAULT_DOMAIN or equivalent to set the default domain) doesn't
necessarily makes it the best approach. For example hard coded value [1]
makes it flaky.

[1]
https://github.com/openstack/python-openstackclient/blob/master/openstackclient/shell.py#L40

To help determine the approach to use, any feedback will be appreciated.

Thanks,
Gilles


__
OpenStack Development Mailing 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] [puppet][keystone] To always use or not use domain name?

[Gilles Dubreuil]

On 06/08/15 10:16, Jamie Lennox wrote:
 
 
 - Original Message -
 From: Adam Young ayo...@redhat.com
 To: openstack-dev@lists.openstack.org
 Sent: Thursday, August 6, 2015 1:03:55 AM
 Subject: Re: [openstack-dev] [puppet][keystone] To always use or not use 
 domain name?

 On 08/05/2015 08:16 AM, Gilles Dubreuil wrote:
 While working on trust provider for the Keystone (V3) puppet module, a
 question about using domain names came up.

 Shall we allow or not to use names without specifying the domain name in
 the resource call?

 I have this trust case involving a trustor user, a trustee user and a
 project.

 For each user/project the domain can be explicit (mandatory):

 trustor_name::domain_name

 or implicit (optional):

 trustor_name[::domain_name]

 If a domain isn't specified the domain name can be assumed (intuited)
 from either the default domain or the domain of the corresponding
 object, if unique among all domains.
 If you are specifying project by name, you must specify domain either
 via name or id.  If you specify proejct by ID, you run the risk of
 conflicting if you provide a domain speciffiedr (ID or name).


 Although allowing to not use the domain might seems easier at first, I
 believe it could lead to confusion and errors. The latter being harder
 for the user to detect.

 Therefore it might be better to always pass the domain information.

 Probably a good idea, as it will catch if you are making some
 assumption.  IE, I say  DomainX  ProejctQ  but I mean DomainQ ProjectQ.
 
 Agreed. Like it or not domains are a major part of using the v3 api and if 
 you want to use project names and user names we should enforce that domains 
 are provided. 
 Particularly at the puppet level (dealing with users who should understand 
 this stuff) anything that tries to guess what the user means is a bad idea 
 and going to lead to confusion when it breaks.
 

I totally agree.

Thanks for participating


 I believe using the full domain name approach is better.
 But it's difficult to tell because in puppet-keystone and
 puppet-openstacklib now rely on python-openstackclient (OSC) to
 interface with Keystone. Because we can use OSC defaults
 (OS_DEFAULT_DOMAIN or equivalent to set the default domain) doesn't
 necessarily makes it the best approach. For example hard coded value [1]
 makes it flaky.

 [1]
 https://github.com/openstack/python-openstackclient/blob/master/openstackclient/shell.py#L40

 To help determine the approach to use, any feedback will be appreciated.

 Thanks,
 Gilles

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

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

Re: [openstack-dev] [puppet] Re: Puppet-OpenStack API providers - Follow up

[Gilles Dubreuil]

Hi,

Just wanted to add, for clarification, the need to restructure the
openstacklib.

The use of resource[:auth] parameter is causing the providers to behave
differently depending on the context, as expressed earlier in this thread.

I would to highlight the fact that this change is driven by design.
Therefore the need for a fix, sooner than later, especially at a time of
the entire stack of provider to shift to Keystone V3. And this is
actually a critical time because of patches waiting upon this structural
change.

The bp/auth-consolidation (sorry for the *bad* name) patches show
authentication doesn't have to be using parameters, the latter was a
mistake from a types/providers suitability viewpoint.

The restructure (bp/auth-consolidation) is not only working but also
simplifies the code which is going to make the development/maintenance
of types/providers faster.

If anyone has issues/questions with this please speak up!

Thank you,
Gilles

On 07/05/15 11:50, Gilles Dubreuil wrote:
 
 
 On 07/05/15 11:33, Colleen Murphy wrote:


 On Wed, May 6, 2015 at 6:26 PM, Gilles Dubreuil gil...@redhat.com
 mailto:gil...@redhat.com wrote:

 It seems ~/.openrc is the only default [...]

 The extras module places it at '/root/openrc' [1], so either the extras
 module should be changed or the providers should look in /root/openrc,
 either way it should be consistent.

 
 Agreed.
 
 Let's use ~/openrc for now then.
 
 Colleen

 [1] 
 http://git.openstack.org/cgit/stackforge/puppet-openstack_extras/tree/manifests/auth_file.pp#n86


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

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

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

Re: [openstack-dev] [puppet] Re: Puppet-OpenStack API providers - Follow up

[Gilles Dubreuil]

It seems ~/.openrc is the only default, so just replacing the RC file
default:

Workflow to find credentials details:
1. From environment (ENV[token] or ENV[project] in short)
2. From a RC file located by convention in current user homedir:
   ~/.openrc
3. From an openstack configuration file such as keystone.conf,
   glance.conf, etc.


Thanks,
Gilles
On 06/05/15 12:49, Gilles Dubreuil wrote:
 Hi,
 
 To summarize from latest 2 discussions about this matter.
 
 Workflow to find credentials details:
 1. From environment (ENV[token] or ENV[project] in short)
 2. From a RC file located by convention in current user homedir:
 ~/openstackrc
 3. From an openstack configuration file such as keystone.conf,
 glance.conf, etc.
 
 Just to avoid confusion, any user/tenant and password or token details
 could be used but they have to come from above list.
 
 The change, impacting openstacklib and the current reviews depending on
 it, is therefore to remove any other way besides above list of passing
 the credentials.
 And more specifically remove passing authenticattion dynamically to the
 provider because of the many reasons evoked.
 
 Also note that 3. would need to be added afterward as this represent a
 factorization work away from the providers.
 
 Regards,
 Gilles
 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 

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

Re: [openstack-dev] [puppet] Re: Puppet-OpenStack API providers - Follow up

[Gilles Dubreuil]

On 07/05/15 11:33, Colleen Murphy wrote:
 
 
 On Wed, May 6, 2015 at 6:26 PM, Gilles Dubreuil gil...@redhat.com
 mailto:gil...@redhat.com wrote:
 
 It seems ~/.openrc is the only default [...]
 
 The extras module places it at '/root/openrc' [1], so either the extras
 module should be changed or the providers should look in /root/openrc,
 either way it should be consistent.
 

Agreed.

Let's use ~/openrc for now then.

 Colleen
 
 [1] 
 http://git.openstack.org/cgit/stackforge/puppet-openstack_extras/tree/manifests/auth_file.pp#n86
 
 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 

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

Re: [openstack-dev] [puppet] Re: Puppet-OpenStack API providers - Follow up

[Gilles Dubreuil]

Hi,

To summarize from latest 2 discussions about this matter.

Workflow to find credentials details:
1. From environment (ENV[token] or ENV[project] in short)
2. From a RC file located by convention in current user homedir:
~/openstackrc
3. From an openstack configuration file such as keystone.conf,
glance.conf, etc.

Just to avoid confusion, any user/tenant and password or token details
could be used but they have to come from above list.

The change, impacting openstacklib and the current reviews depending on
it, is therefore to remove any other way besides above list of passing
the credentials.
And more specifically remove passing authenticattion dynamically to the
provider because of the many reasons evoked.

Also note that 3. would need to be added afterward as this represent a
factorization work away from the providers.

Regards,
Gilles

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