[sdk] Establishing SDK Validation Baseline
Hi everyone, We have spent some time working to get an idea of what official SDKs would look like. We had some sessions during the Berlin summit[0][1] and there was a lot of great feedback. Currently the following SDKs are generally considered usable for their respective language; there are others of course: openstacksdk (Python) gophercloud (Go) pkgcloud (JavaScript) openstack4j (Java) rust-openstack (Rust) fog-openstack (Ruby) php-opencloud (PHP) After many discussions it seems SDK validation essentially should be about confirming cloud state pre/post SDK interaction rather than API support. An example is that when I use pkgcloud and ask that a VM be created, does the VM exist, in the way I asked it exist, rather than are there specific API calls that are being hit along the way to creating my VM. I am putting this email out to keep the community informed of what has been discussed in this space but also and most importantly to get feedback and support for this work. It would be great to get a set of official and community SDKs, get them setup with CI testing for validation (not changing their current CI for unit/functional/acceptance testing; unless asked to help do this), and connect the results to the updated project navigator SDK section. A list of scenarios has been provided as a good starting point for cloud state checks.[2] Essentially the proposal is to deploy OpenStack from upstream (devstack or other), stand up a VM within the cloud, grab all the SDKs, run acceptance tests, report pass/fail results, update project navigator. Of course there are details to be worked out and I do have a few questions that I hope would help get everyone interested on the same page via this thread. 1. Does this make sense? 1. Would folks be interested in a SDK SIG or does it make more sense to request an item on the API SIG's agenda? 1. Bi-weekly discussions a good cadence? 1. Who is interested in tackling this together? [0] https://etherpad.openstack.org/p/BER-better-expose-what-we-produce [1] https://etherpad.openstack.org/p/BER-sdk-certification [2] https://docs.google.com/spreadsheets/d/1cdzFeV5I4Wk9FK57yqQmp5JJdGfKzEOdB3Vt... -- Kind regards, Melvin Hillsman mrhillsman@gmail.com mobile: (832) 264-2646
thanks for bringing this up Melvin. On Thu, Dec 6, 2018 at 1:13 PM Melvin Hillsman <mrhillsman@gmail.com> wrote:
Essentially the proposal is to deploy OpenStack from upstream (devstack or other), stand up a VM within the cloud, grab all the SDKs, run acceptance tests, report pass/fail results, update project navigator. Of course there are details to be worked out and I do have a few questions that I hope would help get everyone interested on the same page via this thread.
Does this make sense?
makes sense to me, and sounds like a good idea provided we have the people ready to maintain the testing infra and patches for this (which i assume we do).
Would folks be interested in a SDK SIG or does it make more sense to request an item on the API SIG's agenda?
i don't have a strong opinion either way, but i will point out that the API-SIG has migrated to office hours instead of a weekly meeting. if you expect that the proposed SDK work will have a strong cadence then it might make more practical sense to create a new SIG, or really even a working group until the objective of the testing is reached. the only reason i bring up working groups here is that there seems like a clearly stated goal for the initial part of this work. namely creating the testing and validation infrastructure described. it might make sense to form a working group until the initial work is complete and then move continued discussion under the API-SIG for organization.
Bi-weekly discussions a good cadence?
that sounds reasonable for a start, but i don't have a strong opinion here.
Who is interested in tackling this together?
if you need any help from API-SIG, please reach out. i would be willing to help with administrative/governance type stuff. peace o/
On Thu, Dec 6, 2018 at 12:36 PM Michael McCune <msm@redhat.com> wrote:
thanks for bringing this up Melvin.
Essentially the proposal is to deploy OpenStack from upstream (devstack or other), stand up a VM within the cloud, grab all the SDKs, run acceptance tests, report pass/fail results, update project navigator. Of course there are details to be worked out and I do have a few questions
On Thu, Dec 6, 2018 at 1:13 PM Melvin Hillsman <mrhillsman@gmail.com> wrote: that I hope would help get everyone interested on the same page via this thread.
Does this make sense?
makes sense to me, and sounds like a good idea provided we have the people ready to maintain the testing infra and patches for this (which i assume we do).
I think we have a good base to build on, should get started, keep everyone informed, and we can continue to work to recruit more interested folks. I think if we work especially hard to streamline the entire process so it is as automated as possible.
Would folks be interested in a SDK SIG or does it make more sense to request an item on the API SIG's agenda?
i don't have a strong opinion either way, but i will point out that the API-SIG has migrated to office hours instead of a weekly meeting. if you expect that the proposed SDK work will have a strong cadence then it might make more practical sense to create a new SIG, or really even a working group until the objective of the testing is reached.
the only reason i bring up working groups here is that there seems like a clearly stated goal for the initial part of this work. namely creating the testing and validation infrastructure described. it might make sense to form a working group until the initial work is complete and then move continued discussion under the API-SIG for organization.
Working group actually makes a lot more sense, thanks for the suggestion, I agree with you; anyone else?
Bi-weekly discussions a good cadence?
that sounds reasonable for a start, but i don't have a strong opinion here.
Who is interested in tackling this together?
if you need any help from API-SIG, please reach out. i would be willing to help with administrative/governance type stuff.
peace o/
-- Kind regards, Melvin Hillsman mrhillsman@gmail.com mobile: (832) 264-2646
On 12/7/18 1:09 AM, Melvin Hillsman wrote:
On Thu, Dec 6, 2018 at 12:36 PM Michael McCune <msm@redhat.com <mailto:msm@redhat.com>> wrote:
thanks for bringing this up Melvin.
On Thu, Dec 6, 2018 at 1:13 PM Melvin Hillsman <mrhillsman@gmail.com <mailto:mrhillsman@gmail.com>> wrote: > Essentially the proposal is to deploy OpenStack from upstream (devstack or other), stand up a VM within the cloud, grab all the SDKs, run acceptance tests, report pass/fail results, update project navigator. Of course there are details to be worked out and I do have a few questions that I hope would help get everyone interested on the same page via this thread. > > Does this make sense? >
makes sense to me, and sounds like a good idea provided we have the people ready to maintain the testing infra and patches for this (which i assume we do).
I think we have a good base to build on, should get started, keep everyone informed, and we can continue to work to recruit more interested folks. I think if we work especially hard to streamline the entire process so it is as automated as possible.
> Would folks be interested in a SDK SIG or does it make more sense to request an item on the API SIG's agenda? >
i don't have a strong opinion either way, but i will point out that the API-SIG has migrated to office hours instead of a weekly meeting. if you expect that the proposed SDK work will have a strong cadence then it might make more practical sense to create a new SIG, or really even a working group until the objective of the testing is reached.
the only reason i bring up working groups here is that there seems like a clearly stated goal for the initial part of this work. namely creating the testing and validation infrastructure described. it might make sense to form a working group until the initial work is complete and then move continued discussion under the API-SIG for organization.
Working group actually makes a lot more sense, thanks for the suggestion, I agree with you; anyone else?
I disagree :) I think back around Dublin we agreed that SDKs are in scope of API SIG, since they help people consume our API. And given that the API SIG is barely alive, it may be give it a chance to become active again.
> Bi-weekly discussions a good cadence? >
that sounds reasonable for a start, but i don't have a strong opinion here.
> Who is interested in tackling this together? >
if you need any help from API-SIG, please reach out. i would be willing to help with administrative/governance type stuff.
As an author of a young SDK, I'm certainly in, be it within or outside of the API SIG. Dmitry
peace o/
-- Kind regards,
Melvin Hillsman mrhillsman@gmail.com <mailto:mrhillsman@gmail.com> mobile: (832) 264-2646
On 12/6/2018 12:10 PM, Melvin Hillsman wrote:
After many discussions it seems SDK validation essentially should be about confirming cloud state pre/post SDK interaction rather than API support. An example is that when I use pkgcloud and ask that a VM be created, does the VM exist, in the way I asked it exist, rather than are there specific API calls that are being hit along the way to creating my VM.
I am putting this email out to keep the community informed of what has been discussed in this space but also and most importantly to get feedback and support for this work. It would be great to get a set of official and community SDKs, get them setup with CI testing for validation (not changing their current CI for unit/functional/acceptance testing; unless asked to help do this), and connect the results to the updated project navigator SDK section. A list of scenarios has been provided as a good starting point for cloud state checks.[2]
Essentially the proposal is to deploy OpenStack from upstream (devstack or other), stand up a VM within the cloud, grab all the SDKs, run acceptance tests, report pass/fail results, update project navigator. Of course there are details to be worked out and I do have a few questions that I hope would help get everyone interested on the same page via this thread.
1. Does this make sense?
Makes sense to me. Validating the end result of some workflow makes sense to me. One thing I'm wondering about is what you'd start with for basic scenarios. It might make sense to start with some of the very basic kinds of things that openstack interoperability certification requires, like create a VM, attach a volume and port, and then delete it all. Then I guess you'd build from there?
2. Would folks be interested in a SDK SIG or does it make more sense to request an item on the API SIG's agenda?
No opinion.
3. Bi-weekly discussions a good cadence?
Again no opinion but I wanted to say thanks for communicating this for others less involved in this space - it's good to know *something* is going on.
4. Who is interested in tackling this together?
Again, no real opinion from me. :) Hopefully that other person that I just saw run away over there... -- Thanks, Matt
On Thu, Dec 6, 2018 at 4:56 PM Matt Riedemann <mriedemos@gmail.com> wrote:
On 12/6/2018 12:10 PM, Melvin Hillsman wrote:
After many discussions it seems SDK validation essentially should be about confirming cloud state pre/post SDK interaction rather than API support. An example is that when I use pkgcloud and ask that a VM be created, does the VM exist, in the way I asked it exist, rather than are there specific API calls that are being hit along the way to creating my VM.
I am putting this email out to keep the community informed of what has been discussed in this space but also and most importantly to get feedback and support for this work. It would be great to get a set of official and community SDKs, get them setup with CI testing for validation (not changing their current CI for unit/functional/acceptance testing; unless asked to help do this), and connect the results to the updated project navigator SDK section. A list of scenarios has been provided as a good starting point for cloud state checks.[2]
Essentially the proposal is to deploy OpenStack from upstream (devstack or other), stand up a VM within the cloud, grab all the SDKs, run acceptance tests, report pass/fail results, update project navigator. Of course there are details to be worked out and I do have a few questions that I hope would help get everyone interested on the same page via this thread.
1. Does this make sense?
Makes sense to me. Validating the end result of some workflow makes sense to me. One thing I'm wondering about is what you'd start with for basic scenarios. It might make sense to start with some of the very basic kinds of things that openstack interoperability certification requires, like create a VM, attach a volume and port, and then delete it all. Then I guess you'd build from there?
Yes sir the scenarios you mention are exactly what we have in the spreadsheet and want to add more. I did not think about it but maybe this ethercalc is better for everyone to collaborate on - https://ethercalc.org/q4nklltf21nz
2. Would folks be interested in a SDK SIG or does it make more sense to request an item on the API SIG's agenda?
No opinion.
3. Bi-weekly discussions a good cadence?
Again no opinion but I wanted to say thanks for communicating this for others less involved in this space - it's good to know *something* is going on.
4. Who is interested in tackling this together?
Again, no real opinion from me. :) Hopefully that other person that I just saw run away over there...
--
Thanks,
Matt
-- Kind regards, Melvin Hillsman mrhillsman@gmail.com mobile: (832) 264-2646
Melvin Hillsman wrote:
We have spent some time working to get an idea of what official SDKs would look like. We had some sessions during the Berlin summit[0][1] and there was a lot of great feedback.
Currently the following SDKs are generally considered usable for their respective language; there are others of course:
openstacksdk (Python) gophercloud (Go) pkgcloud (JavaScript) openstack4j (Java) rust-openstack (Rust) fog-openstack (Ruby) php-opencloud (PHP)
As a sidenote, we also want to show those SDKs on openstack.org/software alongside openstacksdk, so having validation that they actually do what they are supposed to do is really critical.
After many discussions it seems SDK validation essentially should be about confirming cloud state pre/post SDK interaction rather than API support. An example is that when I use pkgcloud and ask that a VM be created, does the VM exist, in the way I asked it exist, rather than are there specific API calls that are being hit along the way to creating my VM.
I am putting this email out to keep the community informed of what has been discussed in this space but also and most importantly to get feedback and support for this work. It would be great to get a set of official and community SDKs, get them setup with CI testing for validation (not changing their current CI for unit/functional/acceptance testing; unless asked to help do this), and connect the results to the updated project navigator SDK section. A list of scenarios has been provided as a good starting point for cloud state checks.[2]
Essentially the proposal is to deploy OpenStack from upstream (devstack or other), stand up a VM within the cloud, grab all the SDKs, run acceptance tests, report pass/fail results, update project navigator. Of course there are details to be worked out and I do have a few questions that I hope would help get everyone interested on the same page via this thread.
1. Does this make sense?
Yes.
2. Would folks be interested in a SDK SIG or does it make more sense to request an item on the API SIG's agenda?
As others mentioned, there is lots of overlap between API SIG and SDK work, but that would be a stretch of the API SIG mission, which they might or might not be interested in doing. If they'd rather have the groups separated, I still think the SIG group format applies better than a "workgroup" as caring about SDKs and their quality will be an ongoing effort, it's not just about setting up tests and then forgetting about them. So I'd encourage the formation of a SDK SIG if that work can't be included in the existing API SIG.
3. Bi-weekly discussions a good cadence?
No strong opinion, but bi-weekly sounds good.
4. Who is interested in tackling this together?
As mentioned above, I'll be involved in the promotion of the result of that effort, by making sure the openstack.org/software pages evolve a way to list "verified" SDKs alongside the one that is produced locally. -- Thierry Carrez (ttx)
On Fri, Dec 7, 2018 at 8:40 AM Thierry Carrez <thierry@openstack.org> wrote:
Melvin Hillsman wrote:
2. Would folks be interested in a SDK SIG or does it make more sense to request an item on the API SIG's agenda?
As others mentioned, there is lots of overlap between API SIG and SDK work, but that would be a stretch of the API SIG mission, which they might or might not be interested in doing.
i don't necessarily have an objection to modifying the API SIG mission to be more inclusive of the SDK work. i think this is something we had actually hoped for after discussions a few cycles ago about how we could be welcoming to the operators and users with SDK specific issues. i think for this expansion/inclusion to be optimally successful we will need to consider re-starting a regular meeting and also getting some new blood on the API SIG core team. we are currently at 3 cores (Ed Leafe, Dmitry Tantsur, and myself) and the reasoning for our meetings evolving into office hours was that it was just the three of us (and Chris Dent usually) coming to those meetings. ideally with new work being done around the SDKs these meetings would become more active again. peace o/
hey folks, i realized after some discussion with the other API SIG cores that i might not have been clear enough in my responses. for the record, i _do not_ have an objection to bringing the SDK work into the mission of the API SIG. further, i think it does make good sense to rally all these concerns in one place and will reduce the confusion that coalesces around new SIG formations. i do maintain that we will need to do some work and bring on fresh bodies into the SIG to ensure the best outcomes. for transparency sake, here is a link[0] to the chat we had in #openstack-sdk among the API SIG cores. peace o/ [0]: http://eavesdrop.openstack.org/irclogs/%23openstack-sdks/%23openstack-sdks.2...
Hi everyone, I would hate for this fade away as I think we have support to keep this moving forward even if it is very slowly. What should be the next step? OpenLab can provide the infrastructure needed to run pretty much anything as folks need without disturbing any existing production environments. Honestly if folks interested in seeing this happen can help draft the scope of work and a roadmap to get it done that would be great. I personally do not want to be the primary person to handle this as it is not my strength but I can help make sure the environment(s) needed are available, work on recruiting help once we have some things outlined, keep communication available, facilitate meetings (even in different time zones), etc. Thoughts? On Fri, Dec 7, 2018 at 1:13 PM Michael McCune <msm@redhat.com> wrote:
hey folks,
i realized after some discussion with the other API SIG cores that i might not have been clear enough in my responses.
for the record, i _do not_ have an objection to bringing the SDK work into the mission of the API SIG. further, i think it does make good sense to rally all these concerns in one place and will reduce the confusion that coalesces around new SIG formations. i do maintain that we will need to do some work and bring on fresh bodies into the SIG to ensure the best outcomes.
for transparency sake, here is a link[0] to the chat we had in #openstack-sdk among the API SIG cores.
peace o/
[0]: http://eavesdrop.openstack.org/irclogs/%23openstack-sdks/%23openstack-sdks.2...
-- Kind regards, Melvin Hillsman mrhillsman@gmail.com mobile: (832) 264-2646
On Sun, Dec 16, 2018 at 5:08 PM Melvin Hillsman <mrhillsman@gmail.com> wrote:
I would hate for this fade away as I think we have support to keep this moving forward even if it is very slowly. What should be the next step? OpenLab can provide the infrastructure needed to run pretty much anything as folks need without disturbing any existing production environments. Honestly if folks interested in seeing this happen can help draft the scope of work and a roadmap to get it done that would be great. I personally do not want to be the primary person to handle this as it is not my strength but I can help make sure the environment(s) needed are available, work on recruiting help once we have some things outlined, keep communication available, facilitate meetings (even in different time zones), etc. Thoughts?
under the assumption that the SDK work could be brought in to the API SIG charter, i think another important step in this process is finding someone who is able and willing to join the API SIG as a core member to represent the SDK side of the story. peace o/
On Mon, 17 Dec 2018, 16:56 Michael McCune, <msm@redhat.com> wrote:
On Sun, Dec 16, 2018 at 5:08 PM Melvin Hillsman <mrhillsman@gmail.com> wrote:
I would hate for this fade away as I think we have support to keep this moving forward even if it is very slowly. What should be the next step? OpenLab can provide the infrastructure needed to run pretty much anything as folks need without disturbing any existing production environments. Honestly if folks interested in seeing this happen can help draft the scope of work and a roadmap to get it done that would be great. I personally do not want to be the primary person to handle this as it is not my strength but I can help make sure the environment(s) needed are available, work on recruiting help once we have some things outlined, keep communication available, facilitate meetings (even in different time zones), etc. Thoughts?
under the assumption that the SDK work could be brought in to the API SIG charter, i think another important step in this process is finding someone who is able and willing to join the API SIG as a core member to represent the SDK side of the story.
I am willing to. Artem
Thanks Artem for stepping up; please know I will be available as much as humanly possible to assist you. On Mon, Dec 17, 2018 at 10:11 AM Artem Goncharov <artem.goncharov@gmail.com> wrote:
On Mon, 17 Dec 2018, 16:56 Michael McCune, <msm@redhat.com> wrote:
On Sun, Dec 16, 2018 at 5:08 PM Melvin Hillsman <mrhillsman@gmail.com> wrote:
I would hate for this fade away as I think we have support to keep this moving forward even if it is very slowly. What should be the next step? OpenLab can provide the infrastructure needed to run pretty much anything as folks need without disturbing any existing production environments. Honestly if folks interested in seeing this happen can help draft the scope of work and a roadmap to get it done that would be great. I personally do not want to be the primary person to handle this as it is not my strength but I can help make sure the environment(s) needed are available, work on recruiting help once we have some things outlined, keep communication available, facilitate meetings (even in different time zones), etc. Thoughts?
under the assumption that the SDK work could be brought in to the API SIG charter, i think another important step in this process is finding someone who is able and willing to join the API SIG as a core member to represent the SDK side of the story.
I am willing to.
Artem
-- Kind regards, Melvin Hillsman mrhillsman@gmail.com mobile: (832) 264-2646
On Mon, Dec 17, 2018 at 11:11 AM Artem Goncharov <artem.goncharov@gmail.com> wrote:
I am willing to.
awesome, this is great to hear Artem. would you be willing to stop by our office hours in #openstack-sdks this thursday at 1600UTC to meet the rest of the SIG? assuming there are no objections we can add you to the SIG wiki and related governance stuff. peace o/
+michael mccune <msm@redhat.com> I will be sure to stop by as well. On Mon, Dec 17, 2018 at 12:49 PM Michael McCune <msm@redhat.com> wrote:
On Mon, Dec 17, 2018 at 11:11 AM Artem Goncharov <artem.goncharov@gmail.com> wrote:
I am willing to.
awesome, this is great to hear Artem. would you be willing to stop by our office hours in #openstack-sdks this thursday at 1600UTC to meet the rest of the SIG?
assuming there are no objections we can add you to the SIG wiki and related governance stuff.
peace o/
-- Kind regards, Melvin Hillsman mrhillsman@gmail.com mobile: (832) 264-2646
participants (6)
-
Artem Goncharov
-
Dmitry Tantsur
-
Matt Riedemann
-
Melvin Hillsman
-
Michael McCune
-
Thierry Carrez