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  
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  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 > 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 mailto:e...@leafe.com>> a écrit :

On May 2, 2018, at 2:40 AM, Gilles Dubreuil
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://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] [nova] A short guide to adding privsep'ed methods in Nova

[Michael Still]

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 new project as well, but I'll
do that separately later.

Michael

-- 
Did this email leave you hoping to cause me pain? Good news!
Sponsor me in city2surf 2018 and I promise to suffer greatly.
http://www.madebymikal.com/city2surf-2018/
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Eric Fried]

>> 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 one API call and bail early
if it fails; but if it passes, we have to do #2 anyway, which is
multiple steps.  So would we rather save one step in the "good path" or
potentially N-1 steps in the failure case?  IMO the cost of the
additional dev/test to implement #1 is higher than that of the potential
extra API calls.  (TL;DR: just implement #2.)

-efried

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

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

[Matt Riedemann]

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, or conservatively
rejecting the request and being potentially wrong about that is not
reasonable, IMHO.


The upside to doing the check in conductor is we have a specific code 
flow for rebuild in conductor and we should be able to just put a 
private method off to the side for this validation scenario. That's 
preferable to baking more rebuild logic into the scheduler. It also 
means we are always going to do this validation regardless of whether or 
not the ImagePropertiesFilter is enabled, but that (1) seems OK and (2) 
no one probably ever disables the ImagePropertiesFilter anyway.


--

Thanks,

Matt

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

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

[Dan Smith]

> 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 allocations. Instead of making an assumption based on
> "last image" vs "new image" and artificially limiting a rebuild that
> should be valid to go ahead. I can imagine scenarios where a user is
> trying to do a rebuild that their cloud admin says should be perfectly
> valid on their hypervisor, but it's getting rejected because old image
> traits != new image traits. It seems like unnecessary user and admin
> pain.

Yeah, I think we have to do this.

> It doesn't seem correct to reject the request if the current compute
> host can fulfill it, and if I understood correctly, we have placement
> APIs we can call from the conductor to verify the image traits
> requested for the rebuild can be fulfilled. Is there a reason not to
> do that?

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, or conservatively
rejecting the request and being potentially wrong about that is not
reasonable, IMHO.

--Dan

__
OpenStack Development Mailing 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] [keystone][monasca][congress][senlin][telemetry] authenticated webhook notifications

[Eric K]

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 consume and send webhook notifications.

I know some people are working on adding the keystone auth option to
Monasca's webhook framework. If there is a project that already does it,
it could be a very helpful reference.


Thanks very much!



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

[Fox, Kevin M]

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

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

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

[Flint WALRUS]

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 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  a écrit :
>
>> 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 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://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] REST limitations and GraghQL inception?

[Flint WALRUS]

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  a écrit :

> 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 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://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] REST limitations and GraghQL inception?

[Ed Leafe]

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 such an effort without first 
demonstrating some tangible results. Hence the idea for an experiment with just 
a single service, done by those interested in seeing it happen. If GraphQL can 
do what they imagine it could do, then they would be able to demonstrate the 
benefit that you (and everyone else) would want to see.


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

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

[Jay Pipes]

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 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-dev] [all][api] POST /api-sig/news

[Ed Leafe]

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 OpenStack APIs/SDKs. None of us are familiar with 
GraphQL in more than a cursory way, so we thought it would be best to propose 
starting with a limited proof-of-concept test. This would involve a team of 
people interested in GraphQL to work separately to wrap a single OpenStack 
service, and then, based on the results, either make it something we embrace 
OpenStack-wide, or chalk up as another interesting experiment. mordred 
suggested that they use Neutron as the test case, as their API requires a lot 
of client-side work for many typical queries. edleafe agreed to respond on the 
mailing list with these thoughts. We also agreed that edleafe needs to be more 
mindful of his phrasing in emails.

Due to the late interest of Gilles and others, we decided to resurrect our BoF 
session at the upcoming Vancouver Forum. If you will be there, and you have an 
interest in anything API- or SDK-related, please plan on joining us!

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

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

# Newly Published Guidelines

None

# API Guidelines Proposed for Freeze

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

None

# Guidelines Currently Under Review [3]

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

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

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

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

# Highlighting your API impacting issues

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

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

Thanks for reading and see you next week!

# References

[1] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[2] http://specs.openstack.org/openstack/api-wg/
[3] https://review.openstack.org/#/q/status:open+project:openstack/api-wg,n,z
[4] https://wiki.openstack.org/wiki/API_SIG
[5] https://bugs.launchpad.net/openstack-api-wg
[6] https://git.openstack.org/cgit/openstack/api-wg
[7] http://lists.openstack.org/pipermail/openstack-dev/2018-April/129987.html
[8] http://graphql.org/

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

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

[Ed Leafe]

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 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://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Alex Schultz]

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 know if there are any issues.

Thanks,
-Alex

[0] 
https://review.openstack.org/#/q/topic:bug/1768590+(status:open+OR+status:merged)
[1] 
http://git.openstack.org/cgit/openstack/governance/tree/goals/pike/python35.rst#n868

__
OpenStack Development Mailing 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] [TripleO] container-to-container-upgrades CI job and tripleo-common versions

[Alex Schultz]

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 n undercloud deploying an n-1 overcloud and
> then upgrading it to an n overcloud, the CI job deploys with Queens
> THT and master tripleo-common. I take this to be by design as per this
> support requirement.
>

I think we've always had to support this for mixed version installs.
We need to be able to manage n-1 with the latest undercloud bits. So
it does seem that tripleo-common needs to continue to be backwards
compatible for one release.  So let's restore the workflow and get an
upgrade job in place so we can detect these types of breakages.
Alternatively perhaps we need an n-1 deployment on a the latest
undercloud job.

Thanks,
-Alex

> An implication of this is that we need to keep tripleo-common
> backwards compatible for the n-1 release and thus we couldn't delete
> this workflow until Stein.
>
> An alternative is to require that tripleo-common be of the same
> version as tripleo-heat-templates.
>
> Recommendations?
>
>   John
>
> PS: for the sake of getting CI I think we should restore the workflow
> for now [3]
>
> [1] https://bugs.launchpad.net/tripleo/+bug/1768116
> [2] https://review.openstack.org/#/c/563047
> [3] https://review.openstack.org/#/c/565580
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

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

[John Fulton]

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, the CI job deploys with Queens
THT and master tripleo-common. I take this to be by design as per this
support requirement.

An implication of this is that we need to keep tripleo-common
backwards compatible for the n-1 release and thus we couldn't delete
this workflow until Stein.

An alternative is to require that tripleo-common be of the same
version as tripleo-heat-templates.

Recommendations?

  John

PS: for the sake of getting CI I think we should restore the workflow
for now [3]

[1] https://bugs.launchpad.net/tripleo/+bug/1768116
[2] https://review.openstack.org/#/c/563047
[3] https://review.openstack.org/#/c/565580

__
OpenStack Development Mailing 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] Is there any way to recheck only one job?

[Slawomir Kaplonski]

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 way to recheck only one type of job instead of 
>>> rechecking everything.
>>> For example sometimes I have to debug some random failure in specific job 
>>> type, like „neutron-fullstack” and I want to collect some additional data 
>>> or test something. So in such case I push some „Do not merge” patch and 
>>> waits for job result - but I really don’t care about e.g. pep8 or UT 
>>> results so would be good is I could run (recheck) only job which I want. 
>>> That could safe some resources for other jobs and speed up my tests a 
>>> little as I could be able to recheck only my job faster :)
>>> 
>>> Is there any way that I can do it with gerrit and zuul currently? Or maybe 
>>> it could be consider as a new feature to add? What do You think about it?
>> 
>> This is intentionally not implemented as it could be used to trick
>> patches leading to unstable behaviour into passing too easily, hiding
>> possible issues.
> 
> Perhaps for these type of patches aimed at gathering data in CI, we
> could make it easier for developers to selectively trigger jobs while
> still retaining the "all voting jobs must pass in the same run" policy
> in place.
> 
> I'm thinking maybe a specially formatted line in the commit message
> could do the trick:
> 
>  Trigger-Job: neutron-fullstack

Yes, IMO it would be great to have something like that available :)

> 
> Even better if we can automatically put a Workflow -1 on the patches
> that contains a job triggering marker to prevent them from
> accidentally merging, and indicate to reviewers they can skip these
> patches.
> It's not uncommon to see such DNM patches, so I imagine we can save
> quite a lot of CI resource by implementing a system like that. And
> devs will be happier too because it can also be tricky at times to
> find what triggers a given job.

That was my initial though when I wrote email about it :)
Solution proposed by Jens is (almost) fine for me as it allows me to skip many 
tests but there is bunch of jobs defined in zuul directly (like 
openstack-tox-py27 or tempest-full) which are still running for my DNM patch.

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

— 
Best regards
Slawek Kaplonski
skapl...@redhat.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

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

[Alex Schultz]

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 to allow for an end user to continue to
use the service on baremetal during the deprecation process.
Additionally it's when we switched over to containers by default. For
new services, I would recommend not creating the
services-baremetal/*.yaml file.  If you have to update an existing
service, please also update the baremetal equivalent at least for this
cycle. We can probably start removing services-baremetal/* in Stein.

Thanks,
-Alex

>
> Regards
>
> Waleed Mousa
>
> SW Engineer at Mellanox
>
>
> __
> OpenStack Development Mailing 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] Is there any way to recheck only one job?

[Martin André]

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 some random failure in specific job 
>> type, like „neutron-fullstack” and I want to collect some additional data or 
>> test something. So in such case I push some „Do not merge” patch and waits 
>> for job result - but I really don’t care about e.g. pep8 or UT results so 
>> would be good is I could run (recheck) only job which I want. That could 
>> safe some resources for other jobs and speed up my tests a little as I could 
>> be able to recheck only my job faster :)
>>
>> Is there any way that I can do it with gerrit and zuul currently? Or maybe 
>> it could be consider as a new feature to add? What do You think about it?
>
> This is intentionally not implemented as it could be used to trick
> patches leading to unstable behaviour into passing too easily, hiding
> possible issues.

Perhaps for these type of patches aimed at gathering data in CI, we
could make it easier for developers to selectively trigger jobs while
still retaining the "all voting jobs must pass in the same run" policy
in place.

I'm thinking maybe a specially formatted line in the commit message
could do the trick:

  Trigger-Job: neutron-fullstack

Even better if we can automatically put a Workflow -1 on the patches
that contains a job triggering marker to prevent them from
accidentally merging, and indicate to reviewers they can skip these
patches.
It's not uncommon to see such DNM patches, so I imagine we can save
quite a lot of CI resource by implementing a system like that. And
devs will be happier too because it can also be tricky at times to
find what triggers a given job.

Martin

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

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

[Michael Turek]

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 even without me.


On 04/30/2018 02:39 PM, Michael Turek wrote:
Just tried this and seems like Firefox does still require a browser 
plugin.


Julia, could we use your bluejeans line again?

Thanks!
Mike Turek 


On 4/30/18 7:33 AM, Dmitry Tantsur wrote:

Hi,

On 04/29/2018 10:17 PM, Michael Turek wrote:
Awesome! If everyone doesn't mind the short notice, we'll have it 
again this Thursday @ 1:00 PM to 3:00 PM UTC.


++



I can provide video conferencing through hangouts here 
https://goo.gl/xSKBS4

Let's give that a shot this time!


Note that the last time I checked Hangouts video messaging required 
a proprietary browser plugin (and hence did not work in Firefox). 
Using it may exclude people not accepting proprietary software 
and/or avoiding using Chromium.




We can adjust times, tooling, and regular agenda over the next 
couple meetings and see where we settle. If anyone has any 
questions or suggestions, don't hesitate to reach out to me!


Thanks,
Mike Turek 


On 4/25/18 12:11 PM, Julia Kreger wrote:

On Mon, Apr 23, 2018 at 12:04 PM, Michael Turek
 wrote:

What does everyone think about having Bug Day the first Thursday 
of every

month?

All for it!

__ 


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



__ 


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

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



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

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

[Sean McGinnis]

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 Vancouver. This is a great opportunity for getting feedback
on existing and planned features and bringing that feedback to the teams.

[1] https://wiki.openstack.org/wiki/Forum
[2] 
https://www.openstack.org/summit/vancouver-2018/summit-schedule/global-search?t=Forum

General Information
---

We have cycle-with-intermediary projects without a release yet. Please take a
look and see if these are ready to do a release for this cycle yet. It's best
to "release early, release often".

automaton
blazar-nova
castellan
ceilometermiddleware
cliff
debtcollector
glance-store
heat-translator
ironic-lib
kuryr
ldappool
oslo.context
ovsdbapp
pycadf
python-aodhclient
python-barbicanclient
python-blazarclient
python-brick-cinderclient-ext
python-cinderclient
python-cloudkittyclient
python-congressclient
python-cyborgclient
python-designateclient
python-ironic-inspector-client
python-karborclient
python-magnumclient
python-masakariclient
python-muranoclient
python-octaviaclient
python-pankoclient
python-qinlingclient
python-searchlightclient
python-senlinclient
python-solumclient
python-swiftclient
python-tricircleclient
python-vitrageclient
python-zaqarclient
requestsexceptions
stevedore
sushy
taskflow
tosca-parser

Some of these have significant changes merged, while some may just have things
like requirements updates or zuul job changes. Please take a look at what has
merged since the last release and see if it would be a good time to do another
release.

Also make sure to do regular stable releases, assuming there are bugfixes ready
to be made available.

Upcoming Deadlines & Dates
--

Forum at OpenStack Summit in Vancouver: May 21-24
Rocky-2 Milestone: June 7

-- 
Sean McGinnis (smcginnis)

__
OpenStack Development Mailing 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] Is there any way to recheck only one job?

[Slawomir Kaplonski]

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 everything.
>> For example sometimes I have to debug some random failure in specific job 
>> type, like „neutron-fullstack” and I want to collect some additional data or 
>> test something. So in such case I push some „Do not merge” patch and waits 
>> for job result - but I really don’t care about e.g. pep8 or UT results so 
>> would be good is I could run (recheck) only job which I want. That could 
>> safe some resources for other jobs and speed up my tests a little as I could 
>> be able to recheck only my job faster :)
>> 
>> Is there any way that I can do it with gerrit and zuul currently? Or maybe 
>> it could be consider as a new feature to add? What do You think about it?
> 
> This is intentionally not implemented as it could be used to trick
> patches leading to unstable behaviour into passing too easily, hiding
> possible issues.
> 
> As an alternative, you could include a change to .zuul.yaml into your
> test patch, removing all jobs except the one you are interested in.
> This would still run the jobs defined in project-config, but may be
> good enough for your scenario.

I did exactly that currently and it’s exactly what I expected. 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

— 
Best regards
Slawek Kaplonski
skapl...@redhat.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

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

[Goutham Pratapa]

+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, April 26, 2018 10:31 PM
> *To:* OpenStack Development Mailing List  openstack.org>
> *Subject:* [openstack-dev] [kolla][vote]Core nomination for Mark Goddard
> (mgoddard) as kolla core member
>
>
>
> Kolla core reviewer team,
>
> It is my pleasure to nominate
>
> ​
>
> mgoddard for kolla core team.
>
> ​
>
> Mark has been working both upstream and downstream with kolla and
> kolla-ansible for over two years, building bare metal compute clouds with
> ironic for HPC. He's been involved with OpenStack since 2014. He started
> the kayobe deployment project which complements kolla-ansible. He is
> also the most active non-core contributor for last 90 days[1]
>
> ​​
>
> Consider this nomination a +1 vote from me
>
> A +1 vote indicates you are in favor of
>
> ​
>
> mgoddard as a candidate, a -1
> is a
>
> ​​
>
> veto. Voting is open for 7 days until
>
> ​May
>
>
>
> ​4​
>
> th, or a unanimous
> response is reached or a veto vote occurs.
>
> [1] http://stackalytics.com/report/contribution/kolla-group/90
>
>
>
> --
>
> Regards,
>
> Jeffrey Zhang
>
> Blog: http://xcodest.me
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Cheers !!!
Goutham Pratapa
__
OpenStack Development Mailing 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-ansible] Implement rotations for meetings handling

[Jesse Pretorius]

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 questions)" 

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


  *   So my question is... what is the health status of OSA? Is there still a 
core of committed contributors? I only check in on OSA code reviews rarely now, 
but activity seems a lot less than it was.

I’m not sure how to answer this, really. OSA is used by a variety of 
organizations, and contributed to by a number of organizations. The health of 
the project depends on the contributions of those who consume it. A quick 
review of Stackalytics shows that OSA has multiple contributing stakeholders, 
which means that the risk of project failure is managed. See 
http://stackalytics.com/?metric=commits&module=openstack-ansible / 
http://stackalytics.com/?metric=person-day&module=openstack-ansible for Rocky 
stats, and you can look back in history using the ‘Release’ drop-down box on 
the left.


  *   Before you answer, imagine that I now work for a moderately large, 
potential consumer of OSA.

OK, you’d be in good company if you check the contributing companies in 
Stackalytics.


  *   Is OSA the future, or have other deployment projects made it less 
relevant?

OSA is one of many deployment projects. Each has their own style. Pick the one 
that suits your needs best.


Rackspace Limited is a company registered in England & Wales (company 
registered number 03897010) whose registered office is at 5 Millington Road, 
Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be 
viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may 
contain confidential or privileged information intended for the recipient. Any 
dissemination, distribution or copying of the enclosed material is prohibited. 
If you receive this transmission in error, please notify us immediately by 
e-mail at ab...@rackspace.com and delete the original message. Your cooperation 
is appreciated.
__
OpenStack Development Mailing 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] [kolla][vote]Core nomination for Mark Goddard (mgoddard) as kolla core member

[Martin André]

+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 PM
> To: OpenStack Development Mailing List 
> Subject: [openstack-dev] [kolla][vote]Core nomination for Mark Goddard
> (mgoddard) as kolla core member
>
>
>
> Kolla core reviewer team,
>
>
>
> It is my pleasure to nominate
>
> mgoddard for kolla core team.
>
> Mark has been working both upstream and downstream with kolla and
> kolla-ansible for over two years, building bare metal compute clouds with
> ironic for HPC. He's been involved with OpenStack since 2014. He started
> the kayobe deployment project which complements kolla-ansible. He is
> also the most active non-core contributor for last 90 days[1]
>
> Consider this nomination a +1 vote from me
>
> A +1 vote indicates you are in favor of
>
> mgoddard as a candidate, a -1
> is a
>
> veto. Voting is open for 7 days until
>
> May
>
>
>
> 4
>
> th, or a unanimous
> response is reached or a veto vote occurs.
>
> [1] http://stackalytics.com/report/contribution/kolla-group/90
>
>
>
> --
>
> Regards,
>
> Jeffrey Zhang
>
> Blog: http://xcodest.me
>
>
> __
> OpenStack Development Mailing 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] [octavia] Sometimes amphoras are not re-created if they are not reached for more than heartbeat_timeout

[mihaela.balas]

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
https://storyboard.openstack.org/#!/story/2001955

Meanwhile, can you provide some recommendation of values for the following 
parameters (maybe in relation with number of workers, cores, computes etc)?

[health_manager]
failover_threads
status_update_threads

[haproxy_amphora]
build_rate_limit
build_active_retries

[controller_worker]
workers
amp_active_retries
amp_active_wait_sec

[task_flow]
max_workers

Thank you for your help,
Mihaela Balas

-Original Message-
From: Michael Johnson [mailto:johnso...@gmail.com] 
Sent: Friday, April 27, 2018 8:24 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [octavia] Sometimes amphoras are not re-created if 
they are not reached for more than heartbeat_timeout

Hi Mihaela,

I am sorry to hear you are having trouble with the queens release of Octavia.  
It is true that a lot of work has gone into the failover capability, 
specifically working around a python threading issue and making it more 
resistant to certain neutron failure situations (missing ports, etc.).

I know of one open bug against the failover flows, 
https://storyboard.openstack.org/#!/story/2001481, "failover breaks in 
Active/Standby mode if both amphroae are down".

Unfortunately the log snippet above does not give me enough information about 
the problem to help with this issue. From the snippet it looks like the 
failovers were initiated, but the controllers are unable to reach the 
amphora-agent on the replacement amphora. It will continue those retry 
attempts, but eventually will fail the amphora into ERROR if it doesn't succeed.

One thought I have is if you created you amphora image in the last two weeks, 
you may have built an amphora using the master branch of octavia, which had a 
bug that impacted active/standby images. This was introduced working around the 
new pip 10 issues.  That patch has been
fixed: https://review.openstack.org/#/c/564371/

If neither of these situations match your environment, please open a story 
(https://storyboard.openstack.org/#!/dashboard/stories) for us and include the 
health manager logs from the point you delete the amphora up until it starts 
these connection attempts.  We will dig through those logs to see what the 
issue might be.

Michael (johnsom)

On Wed, Apr 25, 2018 at 4:07 AM,   wrote:
> Hello,
>
>
>
> I am testing Octavia Queens and I see that the failover behavior is 
> very much different than the one in Ocata (this is the version we are 
> currently running in production).
>
> One example of such behavior is:
>
>
>
> I create 4 load balancers and after the creation is successful, I shut 
> off all the 8 amphoras. Sometimes, even the health-manager agent does 
> not reach the amphoras, they are not deleted and re-created. The logs 
> look like shown below even when the heartbeat timeout is long passed. 
> Sometimes the amphoras are deleted and re-created. Sometimes,  they 
> are partially re-created – part of them remain in shut off.
>
> Heartbeat_timeout is set to 60 seconds.
>
>
>
>
>
>
>
> [octavia-health-manager-3662231220-nxnt3] 2018-04-25 10:57:26.244 11 
> WARNING octavia.amphorae.drivers.haproxy.rest_api_driver
> [req-339b54a7-ab0c-422a-832f-a444cd710497 - 
> a5f15235c0714365b98a50a11ec956e7
> - - -] Could not connect to instance. Retrying.: ConnectionError:
> HTTPSConnectionPool(host='192.168.0.15', port=9443): Max retries 
> exceeded with url:
> /0.5/listeners/285ad342-5582-423e-b654-1f0b50d91fb2/certificates/octav
> iasrv2.orange.com.pem (Caused by 
> NewConnectionError(' object at 0x7f559862c710>: Failed to establish a new connection: 
> [Errno 113] No route to host',))
>
> [octavia-health-manager-3662231220-3lssd] 2018-04-25 10:57:26.464 13 
> WARNING octavia.amphorae.drivers.haproxy.rest_api_driver
> [req-a63b795a-4b4f-4b90-a201-a4c9f49ac68b - 
> a5f15235c0714365b98a50a11ec956e7
> - - -] Could not connect to instance. Retrying.: ConnectionError:
> HTTPSConnectionPool(host='192.168.0.14', port=9443): Max retries 
> exceeded with url:
> /0.5/listeners/a45bdef3-e7da-4a18-9f1f-53d5651efe0f/1615c1ec-249e-4fa8
> -9d73-2397e281712c/haproxy (Caused by 
> NewConnectionError(' object at 0x7f8a0de95e10>: Failed to establish a new connection: 
> [Errno 113] No route to host',))
>
> [octavia-health-manager-3662231220-nxnt3] 2018-04-25 10:57:27.772 11 
> WARNING octavia.amphorae.drivers.haproxy.rest_api_driver
> [req-10febb10-85ea-4082-9df7-daa48894b004 - 
> a5f15235c0714365b98a50a11ec956e7
> - - -] Could not connect to instance. Retrying.: ConnectionError:
> HTTPSConnectionPool(host='192.168.0.19', port=9443): Max retries 
> exceeded with url:
> /0.5/listeners/96ce5862-d944-46cb-8809-e1e328268a66/fc5b79

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

[Mike Carden]

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

So my question is... what is the health status of OSA? Is there still a
core of committed contributors? I only check in on OSA code reviews rarely
now, but activity seems a lot less than it was.

Before you answer, imagine that I now work for a moderately large,
potential consumer of OSA.

Is OSA the future, or have other deployment projects made it less relevant?

-- 
MC



On Thu, May 3, 2018 at 6:13 PM, Andy McCrae  wrote:

>
>> 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 the weekly
>> meeting.
>>
>> Handling the meeting is not that hard, it just takes time to prepare,
>> and to facilitate.
>>
>> I think everyone should step into this, not only core developers, but
>> core developers are now expected to run the meetings when their turn
>> comes.
>>
>>
>> What are the actions to take:
>> - Prepare the triage. Generate the list of the bugs for the week.
>> - Ping people with the triage links around 1h before the weekly
>> meeting. It would give them time to get prepared for meeting,
>> eventually updating the agenda, and read the current bugs
>> - Ping people at the beginning of the meeting
>> - Chair the meeting: The structure of the meeting is now always
>> the same, a recap of the week, and handling the bug triage.
>> - After the meeting we would ask who is volunteer to run next
>> meeting, and if none, a meeting char will be selected amongst core
>> contributors at random.
>>
>> Thank you for your understanding.
>>
>> Jean-Philippe Evrard (evrardjp)
>>
>
> I will gladly pick up my well-used meeting chair hat.
> It's a great idea, I think it would help make our meetings more productive.
> Once you've been chair you have a different view of how the meetings work.
>
> Andy
>
> __
> OpenStack Development Mailing 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] [openstack-ansible] Implement rotations for meetings handling

[Andy McCrae]

>
>
> 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 the weekly meeting.
>
> Handling the meeting is not that hard, it just takes time to prepare,
> and to facilitate.
>
> I think everyone should step into this, not only core developers, but
> core developers are now expected to run the meetings when their turn
> comes.
>
>
> What are the actions to take:
> - Prepare the triage. Generate the list of the bugs for the week.
> - Ping people with the triage links around 1h before the weekly
> meeting. It would give them time to get prepared for meeting,
> eventually updating the agenda, and read the current bugs
> - Ping people at the beginning of the meeting
> - Chair the meeting: The structure of the meeting is now always
> the same, a recap of the week, and handling the bug triage.
> - After the meeting we would ask who is volunteer to run next
> meeting, and if none, a meeting char will be selected amongst core
> contributors at random.
>
> Thank you for your understanding.
>
> Jean-Philippe Evrard (evrardjp)
>

I will gladly pick up my well-used meeting chair hat.
It's a great idea, I think it would help make our meetings more productive.
Once you've been chair you have a different view of how the meetings work.

Andy
__
OpenStack Development Mailing 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] [kolla][vote]Core nomination for Mark Goddard (mgoddard) as kolla core member

[duon...@vn.fujitsu.com]

+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 nomination for Mark Goddard 
(mgoddard) as kolla core member

Kolla core reviewer team,

It is my pleasure to nominate
​
mgoddard for kolla core team.
​
Mark has been working both upstream and downstream with kolla and
kolla-ansible for over two years, building bare metal compute clouds with
ironic for HPC. He's been involved with OpenStack since 2014. He started
the kayobe deployment project which complements kolla-ansible. He is
also the most active non-core contributor for last 90 days[1]
​​
Consider this nomination a +1 vote from me

A +1 vote indicates you are in favor of
​
mgoddard as a candidate, a -1
is a
​​
veto. Voting is open for 7 days until
​May

​4​
th, or a unanimous
response is reached or a veto vote occurs.

[1] http://stackalytics.com/report/contribution/kolla-group/90

--
Regards,
Jeffrey Zhang
Blog: http://xcodest.me
__
OpenStack Development Mailing 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] [Designate] Plan for OSM

[duon...@vn.fujitsu.com]

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

> Out of curiosity, what does OSM stand for?  Based on the patches it 
> seems related to rolling upgrades, but a quick glance at them doesn't 
> make it obvious to me what's going on.  Thanks.

OSM stands for Online Schema Migration, which means that we can migrate 
database schema without
downtime for service.

> -Ben

Best regards,

Ha Quang Duong (Mr.)
PODC - Fujitsu Vietnam Ltd.


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