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

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

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

lob/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 mas

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

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

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

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

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

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

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

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

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

tml 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

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

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

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

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

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

. 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

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

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

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

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

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

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

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

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

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

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

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

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 the

Re: [openstack-dev] Puppet debugging help?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 Dubre

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

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,

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

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 Muta

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

nk 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

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

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

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

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

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

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,

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

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 :

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

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

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

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

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

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

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

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

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

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

[openstack-dev] [api] REST limitations and GraghGL inception?

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

Re: [openstack-dev] [api] Adding a SDK to developer.openstack.org pages

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

[openstack-dev] [api] Adding a SDK to developer.openstack.org pages

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

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

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

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

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

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

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

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

ack.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 f

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

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

Re: [openstack-dev] [api-wg] [api] [cinder] [nova] Support specify action name in request url

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.

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

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

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

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

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

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

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

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

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

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

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

.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

Re: [openstack-dev] [E] Re: nova diagnostics in client library/SDK

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

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

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

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

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 resourc

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

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

Re: [openstack-dev] [api] APIs schema consumption discussion

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"

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

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

Re: [openstack-dev] [api] APIs schema consumption discussion

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

[openstack-dev] [api] APIs schema consumption discussion

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

Re: [openstack-dev] [API-WG] Schema like aws-sdk and API capabilities discovery

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

[openstack-dev] [API-WG] Schema like aws-sdk and API capabilities discovery

ttps://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: Ma

[openstack-dev] [all] Automation and self described APIs

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

Re: [openstack-dev] [puppet][keystone] Choose domain names with 'composite namevar' or 'meaningless name'?

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

Re: [openstack-dev] [puppet][keystone] Choose domain names with 'composite namevar' or 'meaningless name'?

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.

Re: [openstack-dev] correction: Re: [puppet][keystone] Keystone resource naming with domain support - no '::domain' if 'Default'

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

Re: [openstack-dev] [Fuel] [Puppet] Potential critical issue, due Puppet mix stderr and stdout while execute commands

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

Re: [openstack-dev] [puppet] Proposing Denis Egorenko core

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

Re: [openstack-dev] [puppet][Fuel] Using Native Ruby Client for Openstack Providers

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

Re: [openstack-dev] [puppet][Fuel] Using Native Ruby Client for Openstack Providers

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,

Re: [openstack-dev] [puppet][Fuel] Using Native Ruby Client for Openstack Providers

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

Re: [openstack-dev] [puppet][Fuel] OpenstackLib Client Provider Better Exception Handling

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

Re: [openstack-dev] [puppet][Fuel] OpenstackLib Client Provider Better Exception Handling

> 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

Re: [openstack-dev] [puppet][Fuel] Using Native Ruby Client for Openstack Providers

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

Re: [openstack-dev] [puppet][keystone] Choose domain names with 'composite namevar' or 'meaningless name'?

>>>> >>>>> 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: >>>>>>&g

Re: [openstack-dev] [puppet] WARNING - breaking backwards compatibility in puppet-keystone

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

Re: [openstack-dev] [puppet][keystone] Choose domain names with 'composite namevar' or 'meaningless name'?

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

Re: [openstack-dev] [puppet][keystone] Choose domain names with 'composite namevar' or 'meaningless name'?

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 &

Re: [openstack-dev] [puppet][keystone] Choose domain names with 'composite namevar' or 'meaningless name'?

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

Re: [openstack-dev] [puppet][keystone] Choose domain names with 'composite namevar' or 'meaningless name'?

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 {'projec

Re: [openstack-dev] [puppet][keystone] Choose domain names with 'composite namevar' or 'meaningless name'?

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 ado

[openstack-dev] [puppet][keystone] Choose domain names with 'composite namevar' or 'meaningless name'?

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

Re: [openstack-dev] [puppet][keystone] Choose domain names with 'composite namevar' or 'meaningless name'?

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 ab

Re: [openstack-dev] [puppet][keystone] Keystone resource naming with domain support - no '::domain' if 'Default'

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

Re: [openstack-dev] [puppet][keystone] Keystone resource naming with domain support - no '::domain' if 'Default'

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

Re: [openstack-dev] [puppet][keystone] Keystone resource naming with domain support - no '::domain' if 'Default'

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

Re: [openstack-dev] [puppet][keystone] Keystone resource naming with domain support - no '::domain' if 'Default'

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

Re: [openstack-dev] [Fuel][Puppet] Keystone V2/V3 service endpoints

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

Re: [openstack-dev] [Fuel][Puppet] Keystone V2/V3 service endpoints

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

Re: [openstack-dev] [Fuel][Puppet] Keystone V2/V3 service endpoints

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

Re: [openstack-dev] [Fuel][Puppet] Keystone V2/V3 service endpoints

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

[openstack-dev] [puppet][keystone] To always use or not use domain name?

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

Re: [openstack-dev] [puppet][keystone] To always use or not use domain name?

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

Re: [openstack-dev] [puppet] Re: Puppet-OpenStack API providers - Follow up

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

Re: [openstack-dev] [puppet] Re: Puppet-OpenStack API providers - Follow up

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

Re: [openstack-dev] [puppet] Re: Puppet-OpenStack API providers - Follow up

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

Re: [openstack-dev] [puppet] Re: Puppet-OpenStack API providers - Follow up

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