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

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"

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

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

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

+1 for a PoC On 04/05/18 03:56, Flint WALRUS wrote: Exactly ! Le jeu. 3 mai 2018 à 19:55, Flint WALRUS > 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

[openstack-dev] [nova] A short guide to adding privsep'ed methods in Nova

I was asked yesterday for a guide on how to write new escalated methods with oslo privsep, so I wrote up a blog post about it this morning. It might be useful to others here. http://www.madebymikal.com/how-to-make-a-privileged-call-with-oslo-privsep/ I intend to write up how to add privsep to a

Re: [openstack-dev] [nova][placement] Trying to summarize bp/glance-image-traits scheduling alternatives for rebuild

>> verify with placement >> whether the image traits requested are 1) supported by the compute >> host the instance is residing on and 2) coincide with the >> already-existing allocations. Note that #2 is a subset of #1. The only potential advantage of including #1 is efficiency: We can do #1 in

Re: [openstack-dev] [nova][placement] Trying to summarize bp/glance-image-traits scheduling alternatives for rebuild

On 5/3/2018 3:26 PM, Dan Smith wrote: Well, it's a little itcky in that it makes a random part of conductor a bit like the scheduler in its understanding of and iteraction with placement. I don't love it, but I think it's what we have to do. Trying to do the trait math with what was used before,

Re: [openstack-dev] [nova][placement] Trying to summarize bp/glance-image-traits scheduling alternatives for rebuild

> I'm late to this thread but I finally went through the replies and my > thought is, we should do a pre-flight check to verify with placement > whether the image traits requested are 1) supported by the compute > host the instance is residing on and 2) coincide with the > already-existing

[openstack-dev] [keystone][monasca][congress][senlin][telemetry] authenticated webhook notifications

Question to the projects which send or consume webhook notifications (telemetry, monasca, senlin, vitrage, etc.), what are your supported/preferred authentication mechanisms? Bearer token (e.g. Keystone)? Signing? Any pointers to past discussions on the topic? My interest here is having Congress

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

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. Even without using GraphQL, Making the api more declarative anyway, has

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

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

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

Exactly ! Le jeu. 3 mai 2018 à 19:55, Flint WALRUS 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

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

On May 3, 2018, at 12:50 PM, Jay Pipes wrote: > > 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. That was our thinking: no one would agree to

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

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

Greetings OpenStack community, A well-attended meeting today. I'm pleased to report that a good time was had by all. The discussion centered primarily on the email to the dev list [7] from Gilles Dubreuil regarding the possibility of using GraphQL [8] as a wrapper/replacement for the

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

On May 2, 2018, at 2:40 AM, Gilles Dubreuil 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

[openstack-dev] [tripleo] Retirement of tripleo-incubator

We haven't used tripleo-incubator in some time and it is no longer maintained. We are planning on officially retiring it ASAP[0]. We had previously said we would do it for the pike py35 goals[1] but we never got around to removing it. Efforts have begun to officially retire it. Please let us

Re: [openstack-dev] [TripleO] container-to-container-upgrades CI job and tripleo-common versions

On Thu, May 3, 2018 at 8:29 AM, John Fulton wrote: > We hit a bug [1] in CI job container-to-container-upgrades because a > workflow that was needed only for Pike and Queens was removed [2] as > clean up for the migration to external_deploy_tasks. > > As we need to support an

[openstack-dev] [TripleO] container-to-container-upgrades CI job and tripleo-common versions

We hit a bug [1] in CI job container-to-container-upgrades because a workflow that was needed only for Pike and Queens was removed [2] as clean up for the migration to external_deploy_tasks. As we need to support an n undercloud deploying an n-1 overcloud and then upgrading it to an n overcloud,

Re: [openstack-dev] Is there any way to recheck only one job?

Hi, > Wiadomość napisana przez Martin André w dniu 03.05.2018, > o godz. 15:01: > > On Mon, Apr 30, 2018 at 10:41 AM, Jens Harbott wrote: >> 2018-04-30 7:12 GMT+00:00 Slawomir Kaplonski : >>> Hi, >>> >>> I wonder if there is any

Re: [openstack-dev] [tripleo] [heat-templates] Deprecated environment files

On Thu, Apr 26, 2018 at 6:08 AM, Waleed Musa wrote: > Hi guys, > > > I'm wondering, what is the plan of having these environments/*.yaml and > enviroments/services-baremetal/*.yaml. > > It seems that it's deprecated files, Please advice here. > The services-baremetal were

Re: [openstack-dev] Is there any way to recheck only one job?

On Mon, Apr 30, 2018 at 10:41 AM, Jens Harbott wrote: > 2018-04-30 7:12 GMT+00:00 Slawomir Kaplonski : >> Hi, >> >> I wonder if there is any way to recheck only one type of job instead of >> rechecking everything. >> For example sometimes I have to debug

Re: [openstack-dev] [ironic] Monthly bug day?

Thanks Dmitry! We'll be meeting on Dmitry's bluejeans line very soon. Hope to see everyone there! -Mike On 4/30/18 12:00 PM, Dmitry Tantsur wrote: I've created a bluejeans channel for this meeting: https://bluejeans.com/309964257. I may be late for it, but I've set it up to be usable

[openstack-dev] [release] Release countdown for week R-16, May 7-11

Just what you've been waiting for, our regular release countdown email. Development Focus - With Rocky-1 passed, teams should be focusing on feature development and release goals. The Forum [1] schedule [2] is set and hopefully teams are preparing for some good discussions in

Re: [openstack-dev] Is there any way to recheck only one job?

Thanks for help. > Wiadomość napisana przez Jens Harbott w dniu 30.04.2018, > o godz. 10:41: > > 2018-04-30 7:12 GMT+00:00 Slawomir Kaplonski : >> Hi, >> >> I wonder if there is any way to recheck only one type of job instead of >> rechecking

Re: [openstack-dev] [kolla][vote]Core nomination for Mark Goddard (mgoddard) as kolla core member

+1 for `mgoddard` On Thu, May 3, 2018 at 1:21 PM, duon...@vn.fujitsu.com < duon...@vn.fujitsu.com> wrote: > +1 > > > > Sorry for my late reply, thank you for your contribution in Kolla. > > > > Regards, > > Duong > > > > *From:* Jeffrey Zhang [mailto:zhang.lei@gmail.com] > *Sent:* Thursday,

Re: [openstack-dev] [openstack-ansible] Implement rotations for meetings handling

Hi Mike – please see my responses in-line. From: Mike Carden Reply-To: "OpenStack Development Mailing List (not for usage questions)" Date: Thursday, May 3, 2018 at 9:42 AM To: "OpenStack Development Mailing List (not for usage

Re: [openstack-dev] [kolla][vote]Core nomination for Mark Goddard (mgoddard) as kolla core member

+1 On Thu, May 3, 2018 at 9:51 AM, duon...@vn.fujitsu.com wrote: > +1 > > > > Sorry for my late reply, thank you for your contribution in Kolla. > > > > Regards, > > Duong > > > > From: Jeffrey Zhang [mailto:zhang.lei@gmail.com] > Sent: Thursday, April 26, 2018 10:31

Re: [openstack-dev] [octavia] Sometimes amphoras are not re-created if they are not reached for more than heartbeat_timeout

Hi Michael, I build a new amphora image with the latest patches and I reproduced two different bugs that I see in my environment. One of them is similar to the one initially described in this thread. I opened two stories as you advised: https://storyboard.openstack.org/#!/story/2001960

Re: [openstack-dev] [openstack-ansible] Implement rotations for meetings handling

Hi OSA peeps. I apologise in advance for what may seem like an impertinent question. And for those playing along at home, I was just getting the hang of contributing to OSA when last year my employer decided that some of us were no longer needed, and OpenStack lost quite a few full time employed

Re: [openstack-dev] [openstack-ansible] Implement rotations for meetings handling

> > > Now that we are all part-time, I'd like to toy with a new idea, > proposed in the past by Jesse, to rotate the duties with people who > are involved in OSA, or want to get involved more (it's not restricted > to core developers!). > > One of the first duties to be handled this way could be

Re: [openstack-dev] [kolla][vote]Core nomination for Mark Goddard (mgoddard) as kolla core member

+1 Sorry for my late reply, thank you for your contribution in Kolla. Regards, Duong From: Jeffrey Zhang [mailto:zhang.lei@gmail.com] Sent: Thursday, April 26, 2018 10:31 PM To: OpenStack Development Mailing List Subject: [openstack-dev] [kolla][vote]Core

Re: [openstack-dev] [Designate] Plan for OSM

Hi Ben, >>On 04/25/2018 11:31 PM, daidv at vn.fujitsu.com wrote: >> Hi forks, >> >> We tested and completed our process with OVO migration in Queens cycle. >> Now, we can continue with OSM implementation for Designate. >> Actually, we have pushed some patches related to OSM[1] and it's ready to