[tc][all] Train Community Goals
Hi all,
The purpose of this thread is to have a more focused discussion about what we'd like to target for Train community goals, bootstrapped with the outcomes from the session in Berlin [0].
During the session, we went through each item as a group and let the person who added it share why they thought it would be a good community goal candidate for the next release. Most goals have feedback captured in etherpad describing next steps, but the following stuck out as top contenders from the session (rated by upvotes):
1. Moving legacy clients to python-openstackclient 2. Cleaning up resources when deleting a project 3. Service-side health checks
I don't think I missed any goals from the session, but if I did, please let me know and I'll add it to the list so that we can discuss it here.
Does anyone have strong opinions either way about the goals listed above?
Off-hand, I think there needs to be a few more words agreed upon for each in terms of what each item practically means.
In other words, does #1 mean each python-clientlibrary's OSC plugin is ready to rock and roll, or we talking about everyone rewriting all client interactions in to openstacksdk, and porting existing OSC plugins use that different python sdk.
In other words, some projects could find it very easy or that they are already done, where as others could find themselves with a huge lift that is also dependent upon review bandwidth that is outside of their control or influence which puts such a goal at risk if we try and push too hard.
-Julia
On Tue, Dec 4, 2018 at 9:43 AM Lance Bragstad lbragstad@gmail.com wrote:
Hi all,
The purpose of this thread is to have a more focused discussion about what we'd like to target for Train community goals, bootstrapped with the outcomes from the session in Berlin [0].
During the session, we went through each item as a group and let the person who added it share why they thought it would be a good community goal candidate for the next release. Most goals have feedback captured in etherpad describing next steps, but the following stuck out as top contenders from the session (rated by upvotes):
- Moving legacy clients to python-openstackclient
- Cleaning up resources when deleting a project
- Service-side health checks
I don't think I missed any goals from the session, but if I did, please let me know and I'll add it to the list so that we can discuss it here.
Does anyone have strong opinions either way about the goals listed above?
On 12/4/18 7:08 PM, Julia Kreger wrote:
Off-hand, I think there needs to be a few more words agreed upon for each in terms of what each item practically means.
In other words, does #1 mean each python-clientlibrary's OSC plugin is ready to rock and roll, or we talking about everyone rewriting all client interactions in to openstacksdk, and porting existing OSC plugins use that different python sdk.
In other words, some projects could find it very easy or that they are already done, where as others could find themselves with a huge lift that is also dependent upon review bandwidth that is outside of their control or influence which puts such a goal at risk if we try and push too hard.
If the goal is to make all client interactions use openstacksdk, we may indeed lack review throughput. It looks like we have 4 active reviewers this cycle: http://stackalytics.com/?module=openstacksdk
-Julia
On Tue, Dec 4, 2018 at 9:43 AM Lance Bragstad <lbragstad@gmail.com mailto:lbragstad@gmail.com> wrote:
Hi all, The purpose of this thread is to have a more focused discussion about what we'd like to target for Train community goals, bootstrapped with the outcomes from the session in Berlin [0]. During the session, we went through each item as a group and let the person who added it share why they thought it would be a good community goal candidate for the next release. Most goals have feedback captured in etherpad describing next steps, but the following stuck out as top contenders from the session (rated by upvotes): 1. Moving legacy clients to python-openstackclient 2. Cleaning up resources when deleting a project 3. Service-side health checks I don't think I missed any goals from the session, but if I did, please let me know and I'll add it to the list so that we can discuss it here. Does anyone have strong opinions either way about the goals listed above? [0] https://etherpad.openstack.org/p/BER-t-series-goals
Julia Kreger juliaashleykreger@gmail.com writes:
Off-hand, I think there needs to be a few more words agreed upon for each in terms of what each item practically means.
In other words, does #1 mean each python-clientlibrary's OSC plugin is ready to rock and roll, or we talking about everyone rewriting all client interactions in to openstacksdk, and porting existing OSC plugins use that different python sdk.
We talked about those things as separate phases. IIRC, the first phase was to include ensuring that python-openstackclient has full feature coverage for non-admin operations for all microversions, using the existing python-${service}client library or SDK as is appropriate. The next phase was to ensure that the SDK has full feature coverage for all microversions. After that point we could update OSC to use the SDK and start deprecating the service-specific client libraries.
In other words, some projects could find it very easy or that they are already done, where as others could find themselves with a huge lift that is also dependent upon review bandwidth that is outside of their control or influence which puts such a goal at risk if we try and push too hard.
-Julia
On Tue, Dec 4, 2018 at 9:43 AM Lance Bragstad lbragstad@gmail.com wrote:
Hi all,
The purpose of this thread is to have a more focused discussion about what we'd like to target for Train community goals, bootstrapped with the outcomes from the session in Berlin [0].
During the session, we went through each item as a group and let the person who added it share why they thought it would be a good community goal candidate for the next release. Most goals have feedback captured in etherpad describing next steps, but the following stuck out as top contenders from the session (rated by upvotes):
- Moving legacy clients to python-openstackclient
- Cleaning up resources when deleting a project
- Service-side health checks
I don't think I missed any goals from the session, but if I did, please let me know and I'll add it to the list so that we can discuss it here.
Does anyone have strong opinions either way about the goals listed above?
In other words, does #1 mean each python-clientlibrary's OSC plugin is ready to rock and roll, or we talking about everyone rewriting all client interactions in to openstacksdk, and porting existing OSC plugins use that different python sdk.
We talked about those things as separate phases. IIRC, the first phase was to include ensuring that python-openstackclient has full feature coverage for non-admin operations for all microversions, using the existing python-${service}client library or SDK as is appropriate. The next phase was to ensure that the SDK has full feature coverage for all microversions. After that point we could update OSC to use the SDK and start deprecating the service-specific client libraries.
That was my recollection as well.
In other words, some projects could find it very easy or that they are already done, where as others could find themselves with a huge lift that is also dependent upon review bandwidth that is outside of their control or influence which puts such a goal at risk if we try and push too hard.
-Julia
I do think there is still a lot of foundation work that needs to be done before we can make it a cycle goal to move more completely to osc. Before we get there, I think we need to see more folks involved on the project to be ready for the increased attention.
Right now, I would classify this goal as a "huge lift".
Sean
Today in the TC meeting, we discussed the status of the three candidate goals [0]. Ultimately, we as the TC, are wondering who would be willing to drive the goal work.
Having a champion step up early on will help us get answers to questions about the feasibility of the goal, it's impact across OpenStack, among other things that will help us, as a community, make an informed decision.
Remember, championing a goal doesn't need to fall on a single individual. With proper communication, work can be spread out to lighten the load.
What I'd like is to open this up to the community and see who would be willing to drive the proposed goals. If you have any questions about championing a goal, please don't hesitate to swing by #openstack-tc, or you can ping me privately.
[0] http://eavesdrop.openstack.org/meetings/tc/2018/tc.2018-12-06-14.00.log.html...
On Thu, Dec 6, 2018 at 12:20 AM Sean McGinnis sean.mcginnis@gmx.com wrote:
In other words, does #1 mean each python-clientlibrary's OSC plugin is ready to rock and roll, or we talking about everyone rewriting all
client
interactions in to openstacksdk, and porting existing OSC plugins use
that
different python sdk.
We talked about those things as separate phases. IIRC, the first phase was to include ensuring that python-openstackclient has full feature coverage for non-admin operations for all microversions, using the existing python-${service}client library or SDK as is appropriate. The next phase was to ensure that the SDK has full feature coverage for all microversions. After that point we could update OSC to use the SDK and start deprecating the service-specific client libraries.
That was my recollection as well.
In other words, some projects could find it very easy or that they are already done, where as others could find themselves with a huge lift
that
is also dependent upon review bandwidth that is outside of their
control or
influence which puts such a goal at risk if we try and push too hard.
-Julia
I do think there is still a lot of foundation work that needs to be done before we can make it a cycle goal to move more completely to osc. Before we get there, I think we need to see more folks involved on the project to be ready for the increased attention.
Right now, I would classify this goal as a "huge lift".
Sean
On Thu, Dec 6, 2018, 16:19 Lance Bragstad lbragstad@gmail.com wrote:
Today in the TC meeting, we discussed the status of the three candidate goals [0]. Ultimately, we as the TC, are wondering who would be willing to drive the goal work.
Having a champion step up early on will help us get answers to questions about the feasibility of the goal, it's impact across OpenStack, among other things that will help us, as a community, make an informed decision.
Remember, championing a goal doesn't need to fall on a single individual. With proper communication, work can be spread out to lighten the load.
What I'd like is to open this up to the community and see who would be willing to drive the proposed goals. If you have any questions about championing a goal, please don't hesitate to swing by #openstack-tc, or you can ping me privately.
I was waiting for the start of switching osc "services" to SDK for quite a while now. I am definitely interested and committed to support the real coding work here. I would also like to volunteer driving the goal if noone objects.
[0] http://eavesdrop.openstack.org/meetings/tc/2018/tc.2018-12-06-14.00.log.html...
On Thu, Dec 6, 2018 at 12:20 AM Sean McGinnis sean.mcginnis@gmx.com wrote:
In other words, does #1 mean each python-clientlibrary's OSC plugin is ready to rock and roll, or we talking about everyone rewriting all
client
interactions in to openstacksdk, and porting existing OSC plugins use
that
different python sdk.
We talked about those things as separate phases. IIRC, the first phase was to include ensuring that python-openstackclient has full feature coverage for non-admin operations for all microversions, using the existing python-${service}client library or SDK as is appropriate. The next phase was to ensure that the SDK has full feature coverage for all microversions. After that point we could update OSC to use the SDK and start deprecating the service-specific client libraries.
That was my recollection as well.
In other words, some projects could find it very easy or that they are already done, where as others could find themselves with a huge lift
that
is also dependent upon review bandwidth that is outside of their
control or
influence which puts such a goal at risk if we try and push too hard.
-Julia
I do think there is still a lot of foundation work that needs to be done before we can make it a cycle goal to move more completely to osc. Before we get there, I think we need to see more folks involved on the project to be ready for the increased attention.
Right now, I would classify this goal as a "huge lift".
Sean
Artem
On Thu, Dec 6, 2018 at 11:29 AM Artem Goncharov artem.goncharov@gmail.com wrote:
On Thu, Dec 6, 2018, 16:19 Lance Bragstad lbragstad@gmail.com wrote:
Today in the TC meeting, we discussed the status of the three candidate goals [0]. Ultimately, we as the TC, are wondering who would be willing to drive the goal work.
Having a champion step up early on will help us get answers to questions about the feasibility of the goal, it's impact across OpenStack, among other things that will help us, as a community, make an informed decision.
Remember, championing a goal doesn't need to fall on a single individual. With proper communication, work can be spread out to lighten the load.
What I'd like is to open this up to the community and see who would be willing to drive the proposed goals. If you have any questions about championing a goal, please don't hesitate to swing by #openstack-tc, or you can ping me privately.
I was waiting for the start of switching osc "services" to SDK for quite a while now. I am definitely interested and committed to support the real coding work here. I would also like to volunteer driving the goal if noone objects.
Thanks chiming in, Artem!
As others in the thread have eluded to, this could very well be a multi-step effort. A big part of that is going to be figuring out where the different projects are in relation to the desired end state.
Would you be open to starting some preliminary work to help collect some of that information? Matt's etherpad for the compute API gap analysis with OSC is a good example.
[0] http://eavesdrop.openstack.org/meetings/tc/2018/tc.2018-12-06-14.00.log.html...
On Thu, Dec 6, 2018 at 12:20 AM Sean McGinnis sean.mcginnis@gmx.com wrote:
In other words, does #1 mean each python-clientlibrary's OSC plugin
is
ready to rock and roll, or we talking about everyone rewriting all
client
interactions in to openstacksdk, and porting existing OSC plugins
use that
different python sdk.
We talked about those things as separate phases. IIRC, the first phase was to include ensuring that python-openstackclient has full feature coverage for non-admin operations for all microversions, using the existing python-${service}client library or SDK as is appropriate. The next phase was to ensure that the SDK has full feature coverage for all microversions. After that point we could update OSC to use the SDK and start deprecating the service-specific client libraries.
That was my recollection as well.
In other words, some projects could find it very easy or that they
are
already done, where as others could find themselves with a huge lift
that
is also dependent upon review bandwidth that is outside of their
control or
influence which puts such a goal at risk if we try and push too hard.
-Julia
I do think there is still a lot of foundation work that needs to be done before we can make it a cycle goal to move more completely to osc. Before we get there, I think we need to see more folks involved on the project to be ready for the increased attention.
Right now, I would classify this goal as a "huge lift".
Sean
Artem
On 12/6/2018 9:15 AM, Lance Bragstad wrote:
Today in the TC meeting, we discussed the status of the three candidate goals [0]. Ultimately, we as the TC, are wondering who would be willing to drive the goal work.
Having a champion step up early on will help us get answers to questions about the feasibility of the goal, it's impact across OpenStack, among other things that will help us, as a community, make an informed decision.
Remember, championing a goal doesn't need to fall on a single individual. With proper communication, work can be spread out to lighten the load.
What I'd like is to open this up to the community and see who would be willing to drive the proposed goals. If you have any questions about championing a goal, please don't hesitate to swing by #openstack-tc, or you can ping me privately.
Regarding the legacy/OSC one, there was a TODO from Berlin for Monty and I think dtantsur (volunteered by Monty) to do some documentation (or something) about what some of this would look like? If that isn't done, it might be good to get done first to help make an informed decision.
Otherwise my recollection was the same as Doug's and that we need to be working on closing gaps in OSC regardless of what the underlying code is doing (using the SDK or e.g. python-novaclient). Once that is done we can start working on shifting the underlying stuff from legacy clients to SDK.
To make that more digestible, I would also suggest that the goal could aim for some specific release of compatibility as a minimum, e.g. make sure OSC supports all compute API microversions up through Mitaka since lots of clouds are still running Mitaka*. Trying to scope this to "let's get parity up to what the server supported 2 years ago" rather than all of it and fail would be beneficial for projects with bigger gaps.
*In fact, according to https://www.openstack.org/analytics Mitaka is the #1 release being used in deployments right now.
We talked about those things as separate phases. IIRC, the first phase was to include ensuring that python-openstackclient has full feature coverage for non-admin operations for all microversions, using the existing python-${service}client library or SDK as is appropriate. The next phase was to ensure that the SDK has full feature coverage for all microversions. After that point we could update OSC to use the SDK and start deprecating the service-specific client libraries.
That was my recollection as well.
This was my understanding as well and I think the phased approach is important to take given that I don't know that we have as many people with SDK experience. At least that is the case in Cinder.
I do think there is still a lot of foundation work that needs to be done
before
we can make it a cycle goal to move more completely to osc. Before we get there, I think we need to see more folks involved on the project to be
ready
for the increased attention.
Right now, I would classify this goal as a "huge lift".
I think that moving to OSC and away from the other client interfaces is a good goal. It will make for a better user experience and would hopefully help make documentation easier to understand.
With that said, I know that there is a sizable gap between what OSC has for Cinder and what is available for python-cinderclient. If we make this a goal we are doing to need good organization and documentation of those gaps and volunteers to help make this change happen.
On Thu, Dec 6, 2018 at 12:21 AM Sean McGinnis sean.mcginnis@gmx.com wrote:
In other words, does #1 mean each python-clientlibrary's OSC plugin is ready to rock and roll, or we talking about everyone rewriting all
client
interactions in to openstacksdk, and porting existing OSC plugins use
that
different python sdk.
We talked about those things as separate phases. IIRC, the first phase was to include ensuring that python-openstackclient has full feature coverage for non-admin operations for all microversions, using the existing python-${service}client library or SDK as is appropriate. The next phase was to ensure that the SDK has full feature coverage for all microversions. After that point we could update OSC to use the SDK and start deprecating the service-specific client libraries.
That was my recollection as well.
In other words, some projects could find it very easy or that they are already done, where as others could find themselves with a huge lift
that
is also dependent upon review bandwidth that is outside of their
control or
influence which puts such a goal at risk if we try and push too hard.
-Julia
I do think there is still a lot of foundation work that needs to be done before we can make it a cycle goal to move more completely to osc. Before we get there, I think we need to see more folks involved on the project to be ready for the increased attention.
Right now, I would classify this goal as a "huge lift".
Sean
Suggest we get User community involved. If a user have tools written to current client libraries it will be impacted. So getting their feedback on impact and, for sure, continues reminder that this is coming and when will be good.
From: Jay Bryant [mailto:jsbryant@electronicjungle.net] Sent: Thursday, December 6, 2018 9:31 AM To: Sean McGinnis <sean. mcginnis@gmx. com> Cc: openstack-discuss@lists.openstack.org Subject: Re: [tc][all] Train Community Goals
[EXTERNAL EMAIL]
We talked about those things as separate phases. IIRC, the first phase was to include ensuring that python-openstackclient has full feature coverage for non-admin operations for all microversions, using the existing python-${service}client library or SDK as is appropriate. The next phase was to ensure that the SDK has full feature coverage for all microversions. After that point we could update OSC to use the SDK and start deprecating the service-specific client libraries.
That was my recollection as well.
This was my understanding as well and I think the phased approach is important to take given that I don't know that we have as many people with SDK experience. At least that is the case in Cinder.
I do think there is still a lot of foundation work that needs to be done before we can make it a cycle goal to move more completely to osc. Before we get there, I think we need to see more folks involved on the project to be ready for the increased attention.
Right now, I would classify this goal as a "huge lift".
I think that moving to OSC and away from the other client interfaces is a good goal. It will make for a better user experience and would hopefully help make documentation easier to understand.
With that said, I know that there is a sizable gap between what OSC has for Cinder and what is available for python-cinderclient. If we make this a goal we are doing to need good organization and documentation of those gaps and volunteers to help make this change happen.
On Thu, Dec 6, 2018 at 12:21 AM Sean McGinnis <sean.mcginnis@gmx.commailto:sean.mcginnis@gmx.com> wrote:
In other words, does #1 mean each python-clientlibrary's OSC plugin is ready to rock and roll, or we talking about everyone rewriting all client interactions in to openstacksdk, and porting existing OSC plugins use that different python sdk.
We talked about those things as separate phases. IIRC, the first phase was to include ensuring that python-openstackclient has full feature coverage for non-admin operations for all microversions, using the existing python-${service}client library or SDK as is appropriate. The next phase was to ensure that the SDK has full feature coverage for all microversions. After that point we could update OSC to use the SDK and start deprecating the service-specific client libraries.
That was my recollection as well.
In other words, some projects could find it very easy or that they are already done, where as others could find themselves with a huge lift that is also dependent upon review bandwidth that is outside of their control or influence which puts such a goal at risk if we try and push too hard.
-Julia
I do think there is still a lot of foundation work that needs to be done before we can make it a cycle goal to move more completely to osc. Before we get there, I think we need to see more folks involved on the project to be ready for the increased attention.
Right now, I would classify this goal as a "huge lift".
Sean
-- jsbryant@electronicjungle.netmailto:jsbryant@electronicjungle.net
On 12/6/2018 9:30 AM, Jay Bryant wrote:
With that said, I know that there is a sizable gap between what OSC has for Cinder and what is available for python-cinderclient. If we make this a goal we are doing to need good organization and documentation of those gaps and volunteers to help make this change happen.
Get someone to start doing this:
https://etherpad.openstack.org/p/compute-api-microversion-gap-in-osc
It's not hard, doesn't take (too) long, and would give you an idea of what your target goal should be. That's why I keep harping on Mitaka as a goal for parity with the compute API.
Lance Bragstad lbragstad@gmail.com wrote:
Hi all,
The purpose of this thread is to have a more focused discussion about what we'd like to target for Train community goals, bootstrapped with the outcomes from the session in Berlin [0].
During the session, we went through each item as a group and let the person who added it share why they thought it would be a good community goal candidate for the next release. Most goals have feedback captured in etherpad describing next steps, but the following stuck out as top contenders from the session (rated by upvotes):
- Moving legacy clients to python-openstackclient
- Cleaning up resources when deleting a project
- Service-side health checks
I don't think I missed any goals from the session, but if I did, please let me know and I'll add it to the list so that we can discuss it here.
Does anyone have strong opinions either way about the goals listed above?
I'm a fan of 3. service-side health checks, since I've been having discussions about this with various parties at the last 3--6 (I lost count) Forum / PTG events, and every time there seems to have been a decent amount of interest, e.g.
- Deployment solutions have a clear motive for being able to programmatically determine a more accurate picture of the health of services, e.g. k8s-based deployments like Airship where containers would benefit from more accurate liveness probes.
- The Self-healing SIG is obviously a natural customer for this functionality, since before you can heal you need to know what exactly needs healing.
- It could benefit specific projects such as Vitrage, Horizon, and Monasca, and also automated tests / CI.
Other factors it has in its favour as a community goal is that it's not too ambitious as to prevent a significant amount of progress in one cycle, and also progress should be easily measurable.
FWIW here's some history ... For a good while we got stuck bike-shedding the spec:
https://review.openstack.org/#/c/531456/
but in the API SIG session in Denver, we managed to break the deadlock and agreed to do the simplest thing which could possibly work in order to move forwards:
https://etherpad.openstack.org/p/api-sig-stein-ptg
Yes, there are many unresolved questions about the long-term design, but we decided to avoid any further paralysis and instead forge ahead based on the following principles:
- The existing oslo.middleware mechanism is a good start, so just add a /v2 endpoint to avoid breaking existing consumers.
- Only worry about API services for now.
- Don't worry about authentication yet.
- Endpoints should only report on their own health, not on the health of dependencies / related services.
In Berlin Graham (@mugsie) pushed a very rough prototype to Gerrit:
https://review.openstack.org/#/c/617924/
There's a story in StoryBoard tracking all of this. I've just updated it in an attempt to capture all the relevant history:
Hello everyone,
We are looking for volunteers and potential future champions, particularily to assist in completing prerequisite work for service- side healthchecks and cleaning up resources when deleting a project.
Goals are more likely to be successful if there is someone to drive the work. Having an accurate assessment of the prerequisite work before the goals even make it into review will help with scope and possibly finding ways to break the work into more manageable pieces. So far, the service-side health checks goal requires some oslo work for the framework that services would use to implement the goal. The cleanup of resources when deleting a project goal requires some anaylsis on what the interface would look like for both os-purge and an API in each service.
Is anyone interested in driving the prerequisite work for these two proposals? Ideally, it would be great if we could have the work done by the middle of January, which gives us enough time to discuss prior to putting proposals in review.
This note is specific to the most popular goals from the summit session in Berlin and prerequisite work for those goals. That said, it's certainly not too late to propose other ideas or goals for Train.
Thoughts?
Lance (lbragstad) and JP (evrardjp)
Jean-Philippe Evrard jean-philippe@evrard.me writes:
Hello everyone,
We are looking for volunteers and potential future champions, particularily to assist in completing prerequisite work for service- side healthchecks and cleaning up resources when deleting a project.
Goals are more likely to be successful if there is someone to drive the work. Having an accurate assessment of the prerequisite work before the goals even make it into review will help with scope and possibly finding ways to break the work into more manageable pieces. So far, the service-side health checks goal requires some oslo work for the framework that services would use to implement the goal.
The service health check goal is an *excellent* example of an area where a relatively small number of people can have a big impact on the entire project. We need someone to spend the time to think about how the health check middleware knows which checks to run, and then to ensure that the middleware is added to all the services' WSGI stacks. I think a small team of 2-3 people could make quick work of this one.
The cleanup of resources when deleting a project goal requires some anaylsis on what the interface would look like for both os-purge and an API in each service.
I would like to see the folks asking for this one contribute to working out those details, with help from project team experts.
Is anyone interested in driving the prerequisite work for these two proposals? Ideally, it would be great if we could have the work done by the middle of January, which gives us enough time to discuss prior to putting proposals in review.
This note is specific to the most popular goals from the summit session in Berlin and prerequisite work for those goals. That said, it's certainly not too late to propose other ideas or goals for Train.
Thoughts?
Lance (lbragstad) and JP (evrardjp)
I put my hand up during the summit for being at least one of the champions for the deletion of project resources effort.
I have been meaning to do a follow up email and options as well as steps for how the goal might go, but my working holiday in Europe after the summit turned into more of a holiday than originally planned.
I'll get a thread going around what I (and the public cloud working group) think project resource deletion should look like, and what the options are, and where we should aim to be with it. We can then turn that discussion into a final 'spec' of sorts.
On 14/12/18 5:06 AM, Jean-Philippe Evrard wrote:
Hello everyone,
We are looking for volunteers and potential future champions, particularily to assist in completing prerequisite work for service- side healthchecks and cleaning up resources when deleting a project.
Goals are more likely to be successful if there is someone to drive the work. Having an accurate assessment of the prerequisite work before the goals even make it into review will help with scope and possibly finding ways to break the work into more manageable pieces. So far, the service-side health checks goal requires some oslo work for the framework that services would use to implement the goal. The cleanup of resources when deleting a project goal requires some anaylsis on what the interface would look like for both os-purge and an API in each service.
Is anyone interested in driving the prerequisite work for these two proposals? Ideally, it would be great if we could have the work done by the middle of January, which gives us enough time to discuss prior to putting proposals in review.
This note is specific to the most popular goals from the summit session in Berlin and prerequisite work for those goals. That said, it's certainly not too late to propose other ideas or goals for Train.
Thoughts?
Lance (lbragstad) and JP (evrardjp)
On Wed, 2018-12-19 at 06:58 +1300, Adrian Turjak wrote:
I put my hand up during the summit for being at least one of the champions for the deletion of project resources effort.
I have been meaning to do a follow up email and options as well as steps for how the goal might go, but my working holiday in Europe after the summit turned into more of a holiday than originally planned.
I'll get a thread going around what I (and the public cloud working group) think project resource deletion should look like, and what the options are, and where we should aim to be with it. We can then turn that discussion into a final 'spec' of sorts.
Great news!
Do you need any help to get started there?
Regards, JP
Hello everyone,
I thought it would be good to have a quick recap of the various goal proposals.
*Project clean-up*
Adrian and Tobias Rydberg have volunteered to champion the goal. There has also been some productive discussion around the approaches detailed in the etherpad [0]. At this point is it safe to assume we've come to a conclusion on the proposed approach? If so, I think the next logical step would be to do a gap analysis on what the proposed approach would mean work-wise for all projects. Note, Assaf Muller brought the approach Neutron takes to my attention [1] and I wanted to highlight this here since it establishes a template for us to follow, or at least look at. Note, Neutron's approach is client-based, which might not be orthogonal with the client goal. Just something to keep in mind if those two happen to be accepted for the same release.
[0] https://etherpad.openstack.org/p/community-goal-project-deletion [1] https://github.com/openstack/python-neutronclient/blob/master/neutronclient/...
*Moving legacy clients to python-openstackclient*
Artem has done quite a bit of pre-work here [2], which has been useful in understanding the volume of work required to complete this goal in its entirety. I suggest we look for seams where we can break this into more consumable pieces of work for a given release.
For example, one possible goal would be to work on parity with python-openstackclient and openstacksdk. A follow-on goal would be to move the legacy clients. Alternatively, we could start to move all the project clients logic into python-openstackclient, and then have another goal to implement the common logic gaps into openstacksdk. Arriving at the same place but using different paths. The approach still has to be discussed and proposed. I do think it is apparent that we'll need to break this up, however.
[2] https://etherpad.openstack.org/p/osc-gaps-analysis
*Healthcheck middleware*
There is currently no volunteer to champion for this goal. The first iteration of the work on the oslo.middleware was updated [3], and a gap analysis was started on the mailing lists [4]. If you want to get involved in this goal, don't hesitate to answer on the ML thread there.
[3] https://review.openstack.org/#/c/617924/2 [4] https://ethercalc.openstack.org/di0mxkiepll8
Just a reminder that we would like to have all potential goals proposed for review in openstack/governance by the middle of this month, giving us 6 weeks to hash out details in Gerrit if we plan to have the goals merged by the end of March. This timeframe should give us 4 weeks to prepare any discussions we'd like to have in-person pertaining to those goals.
Thanks for the time,
Lance
On Tue, Jan 8, 2019 at 4:11 AM Jean-Philippe Evrard jean-philippe@evrard.me wrote:
On Wed, 2018-12-19 at 06:58 +1300, Adrian Turjak wrote:
I put my hand up during the summit for being at least one of the champions for the deletion of project resources effort.
I have been meaning to do a follow up email and options as well as steps for how the goal might go, but my working holiday in Europe after the summit turned into more of a holiday than originally planned.
I'll get a thread going around what I (and the public cloud working group) think project resource deletion should look like, and what the options are, and where we should aim to be with it. We can then turn that discussion into a final 'spec' of sorts.
Great news!
Do you need any help to get started there?
Regards, JP
Hi Lance and everybody
thanks for recap.
With respect to *moving legacy clients to python-openstackclient*. At the page Lance already mentioned [1] bottom I have listed different options and a small volunteering table to understand what will be feasible to achieve. If people are interested and ready to contribute - please fill yourself in. I personally do not think any target is reachable, unless people start picking things to be done.
[1] https://etherpad.openstack.org/p/osc-gaps-analysis
Regards, Artem
On Thu, Jan 31, 2019 at 5:03 PM Lance Bragstad lbragstad@gmail.com wrote:
Hello everyone,
I thought it would be good to have a quick recap of the various goal proposals.
*Project clean-up*
Adrian and Tobias Rydberg have volunteered to champion the goal. There has also been some productive discussion around the approaches detailed in the etherpad [0]. At this point is it safe to assume we've come to a conclusion on the proposed approach? If so, I think the next logical step would be to do a gap analysis on what the proposed approach would mean work-wise for all projects. Note, Assaf Muller brought the approach Neutron takes to my attention [1] and I wanted to highlight this here since it establishes a template for us to follow, or at least look at. Note, Neutron's approach is client-based, which might not be orthogonal with the client goal. Just something to keep in mind if those two happen to be accepted for the same release.
[0] https://etherpad.openstack.org/p/community-goal-project-deletion [1] https://github.com/openstack/python-neutronclient/blob/master/neutronclient/...
*Moving legacy clients to python-openstackclient*
Artem has done quite a bit of pre-work here [2], which has been useful in understanding the volume of work required to complete this goal in its entirety. I suggest we look for seams where we can break this into more consumable pieces of work for a given release.
For example, one possible goal would be to work on parity with python-openstackclient and openstacksdk. A follow-on goal would be to move the legacy clients. Alternatively, we could start to move all the project clients logic into python-openstackclient, and then have another goal to implement the common logic gaps into openstacksdk. Arriving at the same place but using different paths. The approach still has to be discussed and proposed. I do think it is apparent that we'll need to break this up, however.
[2] https://etherpad.openstack.org/p/osc-gaps-analysis
*Healthcheck middleware*
There is currently no volunteer to champion for this goal. The first iteration of the work on the oslo.middleware was updated [3], and a gap analysis was started on the mailing lists [4]. If you want to get involved in this goal, don't hesitate to answer on the ML thread there.
[3] https://review.openstack.org/#/c/617924/2 [4] https://ethercalc.openstack.org/di0mxkiepll8
Just a reminder that we would like to have all potential goals proposed for review in openstack/governance by the middle of this month, giving us 6 weeks to hash out details in Gerrit if we plan to have the goals merged by the end of March. This timeframe should give us 4 weeks to prepare any discussions we'd like to have in-person pertaining to those goals.
Thanks for the time,
Lance
On Tue, Jan 8, 2019 at 4:11 AM Jean-Philippe Evrard < jean-philippe@evrard.me> wrote:
On Wed, 2018-12-19 at 06:58 +1300, Adrian Turjak wrote:
I put my hand up during the summit for being at least one of the champions for the deletion of project resources effort.
I have been meaning to do a follow up email and options as well as steps for how the goal might go, but my working holiday in Europe after the summit turned into more of a holiday than originally planned.
I'll get a thread going around what I (and the public cloud working group) think project resource deletion should look like, and what the options are, and where we should aim to be with it. We can then turn that discussion into a final 'spec' of sorts.
Great news!
Do you need any help to get started there?
Regards, JP
cc aspiers, who sounded interested in leading this work, pending discussion with his employer[1].
1: http://lists.openstack.org/pipermail/openstack-discuss/2019-January/001750.h...
On 1/31/19 9:59 AM, Lance Bragstad wrote:
*Healthcheck middleware*
There is currently no volunteer to champion for this goal. The first iteration of the work on the oslo.middleware was updated [3], and a gap analysis was started on the mailing lists [4]. If you want to get involved in this goal, don't hesitate to answer on the ML thread there.
[3] https://review.openstack.org/#/c/617924/2 [4] https://ethercalc.openstack.org/di0mxkiepll8
Yeah thanks - I'm well looped in here through my colleague JP[1] :-)
Still hoping to find some more time for this very soon, although right now I'm focused on some pressing nova work ...
[1] http://lists.openstack.org/pipermail/openstack-discuss/2019-January/002089.h...
Ben Nemec openstack@nemebean.com wrote:
cc aspiers, who sounded interested in leading this work, pending discussion with his employer[1].
1: http://lists.openstack.org/pipermail/openstack-discuss/2019-January/001750.h...
On 1/31/19 9:59 AM, Lance Bragstad wrote:
*Healthcheck middleware*
There is currently no volunteer to champion for this goal. The first iteration of the work on the oslo.middleware was updated [3], and a gap analysis was started on the mailing lists [4]. If you want to get involved in this goal, don't hesitate to answer on the ML thread there.
[3] https://review.openstack.org/#/c/617924/2 [4] https://ethercalc.openstack.org/di0mxkiepll8
On 1/31/19 9:59 AM, Lance Bragstad wrote:
Hello everyone,
I thought it would be good to have a quick recap of the various goal proposals.
*Project clean-up*
Adrian and Tobias Rydberg have volunteered to champion the goal. There has also been some productive discussion around the approaches detailed in the etherpad [0]. At this point is it safe to assume we've come to a conclusion on the proposed approach? If so, I think the next logical step would be to do a gap analysis on what the proposed approach would mean work-wise for all projects. Note, Assaf Muller brought the approach Neutron takes to my attention [1] and I wanted to highlight this here since it establishes a template for us to follow, or at least look at. Note, Neutron's approach is client-based, which might not be orthogonal with the client goal. Just something to keep in mind if those two happen to be accepted for the same release.
Is there anything preventing this goal from making its way into review? The goal has champions and a plan for implementation.
[0] https://etherpad.openstack.org/p/community-goal-project-deletion [1] https://github.com/openstack/python-neutronclient/blob/master/neutronclient/...
*Moving legacy clients to python-openstackclient*
Artem has done quite a bit of pre-work here [2], which has been useful in understanding the volume of work required to complete this goal in its entirety. I suggest we look for seams where we can break this into more consumable pieces of work for a given release.
For example, one possible goal would be to work on parity with python-openstackclient and openstacksdk. A follow-on goal would be to move the legacy clients. Alternatively, we could start to move all the project clients logic into python-openstackclient, and then have another goal to implement the common logic gaps into openstacksdk. Arriving at the same place but using different paths. The approach still has to be discussed and proposed. I do think it is apparent that we'll need to break this up, however.
Artem's call for help is still open [0]. Artem, has anyone reached out to you about co-championing the goal? Do you have suggestions for how you'd like to break up the work to make the goal more achievable, especially if you're the only one championing the initiative?
http://lists.openstack.org/pipermail/openstack-discuss/2019-January/002275.html
[2] https://etherpad.openstack.org/p/osc-gaps-analysis
*Healthcheck middleware*
There is currently no volunteer to champion for this goal. The first iteration of the work on the oslo.middleware was updated [3], and a gap analysis was started on the mailing lists [4]. If you want to get involved in this goal, don't hesitate to answer on the ML thread there.
This goal still needs at least one champion. Based on recent feedback and discussions, we still need to smooth out some wrinkles in the implementation (see cdent's note about checks [1]). Regardless, it sounds like this effort is still in the prework phase and would greatly benefit from a PoC before pushing this as a Train goal for review. Should we consider that goal for U instead?
Just a reminder that we would like to have all potential goals proposed for review in governance in the next days,giving us 6 weeks to hash out details in Gerrit if we plan to have the goals merged bythe end of March. This should give us 4 weeks to prepare anydiscussions we'd like to have in-person pertaining to those goals.
Thanks for the time,
Jean-Philippe & Lance
[0] http://lists.openstack.org/pipermail/openstack-discuss/2019-January/002275.h... [1] http://lists.openstack.org/pipermail/openstack-discuss/2019-January/002126.h...
[3] https://review.openstack.org/#/c/617924/2 [4] https://ethercalc.openstack.org/di0mxkiepll8
Just a reminder that we would like to have all potential goals proposed for review in openstack/governance by the middle of this month, giving us 6 weeks to hash out details in Gerrit if we plan to have the goals merged by the end of March. This timeframe should give us 4 weeks to prepare any discussions we'd like to have in-person pertaining to those goals.
Thanks for the time,
Lance
On Tue, Jan 8, 2019 at 4:11 AM Jean-Philippe Evrard <jean-philippe@evrard.me mailto:jean-philippe@evrard.me> wrote:
On Wed, 2018-12-19 at 06:58 +1300, Adrian Turjak wrote: > I put my hand up during the summit for being at least one of the > champions for the deletion of project resources effort. > > I have been meaning to do a follow up email and options as well as > steps > for how the goal might go, but my working holiday in Europe after the > summit turned into more of a holiday than originally planned. > > I'll get a thread going around what I (and the public cloud working > group) think project resource deletion should look like, and what the > options are, and where we should aim to be with it. We can then turn > that discussion into a final 'spec' of sorts. > > Great news! Do you need any help to get started there? Regards, JP
On Thu, Feb 14, 2019 at 9:29 AM Lance Bragstad lbragstad@gmail.com wrote:
On 1/31/19 9:59 AM, Lance Bragstad wrote: Moving legacy clients to python-openstackclient
Artem has done quite a bit of pre-work here [2], which has been useful in understanding the volume of work required to complete this goal in its entirety. I suggest we look for seams where we can break this into more consumable pieces of work for a given release.
For example, one possible goal would be to work on parity with python-openstackclient and openstacksdk. A follow-on goal would be to move the legacy clients. Alternatively, we could start to move all the project clients logic into python-openstackclient, and then have another goal to implement the common logic gaps into openstacksdk. Arriving at the same place but using different paths. The approach still has to be discussed and proposed. I do think it is apparent that we'll need to break this up, however.
Artem's call for help is still open [0]. Artem, has anyone reached out to you about co-championing the goal? Do you have suggestions for how you'd like to break up the work to make the goal more achievable, especially if you're the only one championing the initiative?
I'll outline my thoughts on how to break these down in that etherpad. Fortunately there are a lot of semi-independent parts here depending on how we want to slice the work (ie, do everything for a small number of projects or do one part for all projects).
I am planning to scale back some involvement in StarlingX in 2019 to free up some time for this sort of thing and am willing to co-champion this with Artem. I'm likely to be involved anyway. :)
dt
On 2/14/19 3:30 PM, Dean Troyer wrote:
On Thu, Feb 14, 2019 at 9:29 AM Lance Bragstad lbragstad@gmail.com wrote:
On 1/31/19 9:59 AM, Lance Bragstad wrote: Moving legacy clients to python-openstackclient
Artem has done quite a bit of pre-work here [2], which has been useful in understanding the volume of work required to complete this goal in its entirety. I suggest we look for seams where we can break this into more consumable pieces of work for a given release.
For example, one possible goal would be to work on parity with python-openstackclient and openstacksdk. A follow-on goal would be to move the legacy clients. Alternatively, we could start to move all the project clients logic into python-openstackclient, and then have another goal to implement the common logic gaps into openstacksdk. Arriving at the same place but using different paths. The approach still has to be discussed and proposed. I do think it is apparent that we'll need to break this up, however.
Artem's call for help is still open [0]. Artem, has anyone reached out to you about co-championing the goal? Do you have suggestions for how you'd like to break up the work to make the goal more achievable, especially if you're the only one championing the initiative?
I'll outline my thoughts on how to break these down in that etherpad. Fortunately there are a lot of semi-independent parts here depending on how we want to slice the work (ie, do everything for a small number of projects or do one part for all projects).
I am planning to scale back some involvement in StarlingX in 2019 to free up some time for this sort of thing and am willing to co-champion this with Artem. I'm likely to be involved anyway. :)
Awesome - that'll be a huge help, Dean! If you need help getting things proposed as a goal, just let me or JP know.
dt
thanks Dean. I have seen also Matt also joined etherpad - thanks as well.
Monty has promised a R1.0 soon ;-), but there are still some issues to be covered before. That's why I wanted to try probably complete couple of services before R1.0 (Object and Image). I am also currently trying to bring DNS into the SDK (when I would have at least 30 hours in a day would be faster) and I have a skeleton of the CLI binding for it as well (would like to upstream it from downstream).
Dean, are you ok in receiving changes for switch to SDK before we get R1.0?
Let us really just focus on few services as a target and then hopefully achieve more. What do you think?
My suggestion would be to focus on: - novaclient - glanceclient - swiftclient
Regards, Artem
On Thu, Feb 14, 2019 at 10:49 PM Lance Bragstad lbragstad@gmail.com wrote:
On 2/14/19 3:30 PM, Dean Troyer wrote:
On Thu, Feb 14, 2019 at 9:29 AM Lance Bragstad lbragstad@gmail.com
wrote:
On 1/31/19 9:59 AM, Lance Bragstad wrote: Moving legacy clients to python-openstackclient
Artem has done quite a bit of pre-work here [2], which has been useful
in understanding the volume of work required to complete this goal in its entirety. I suggest we look for seams where we can break this into more consumable pieces of work for a given release.
For example, one possible goal would be to work on parity with
python-openstackclient and openstacksdk. A follow-on goal would be to move the legacy clients. Alternatively, we could start to move all the project clients logic into python-openstackclient, and then have another goal to implement the common logic gaps into openstacksdk. Arriving at the same place but using different paths. The approach still has to be discussed and proposed. I do think it is apparent that we'll need to break this up, however.
Artem's call for help is still open [0]. Artem, has anyone reached out
to you about co-championing the goal? Do you have suggestions for how you'd like to break up the work to make the goal more achievable, especially if you're the only one championing the initiative?
I'll outline my thoughts on how to break these down in that etherpad. Fortunately there are a lot of semi-independent parts here depending on how we want to slice the work (ie, do everything for a small number of projects or do one part for all projects).
I am planning to scale back some involvement in StarlingX in 2019 to free up some time for this sort of thing and am willing to co-champion this with Artem. I'm likely to be involved anyway. :)
Awesome - that'll be a huge help, Dean! If you need help getting things proposed as a goal, just let me or JP know.
dt
On Fri, Feb 15, 2019 at 2:42 AM Artem Goncharov artem.goncharov@gmail.com wrote:
Dean, are you ok in receiving changes for switch to SDK before we get R1.0?
I suppose we should just go ahead and do that. We've been burnt twice since we started doing the Network commands by changes, there was a lot of compatibility stuff on both sides for the last one, I don't want either project to have to do that again. Monty told me a while back that he didn't expect any more compat-impacting changes, if that is still true I'd say we should start...
Let us really just focus on few services as a target and then hopefully achieve more. What do you think?
My suggestion would be to focus on:
- novaclient
- glanceclient
- swiftclient
I had been planning to do glance first for a number of reasons, one being the number of unique dependencies glanceclient bring in to OSC.
Swift is a special case, we don't use swiftclient at all, I used what I had originally proposed to the SDK (a really long time ago now) for a low-level API and copied the useful functions directly from swift (this was even before swiftclient was a thing). The core of what is in OSC for swift is swift code, way out of date now, which is one reason so much of that API is not implemented.
Both of those have notiecable returns to do first although it could also be argued that due to the above history of swift support in OSC not a lot of users are relying on that.
For this to make sense as a community goal, I want to support projects that want to do similar things themselves too, although much of that is in plugins. Being around for spiritual support and getting the SDK updated would be the need from my point of view here.
dt
On 12/4/18 6:38 PM, Lance Bragstad wrote:
Hi all,
The purpose of this thread is to have a more focused discussion about what we'd like to target for Train community goals, bootstrapped with the outcomes from the session in Berlin [0].
During the session, we went through each item as a group and let the person who added it share why they thought it would be a good community goal candidate for the next release. Most goals have feedback captured in etherpad describing next steps, but the following stuck out as top contenders from the session (rated by upvotes):
- Moving legacy clients to python-openstackclient
- Cleaning up resources when deleting a project
- Service-side health checks
I don't think I missed any goals from the session, but if I did, please let me know and I'll add it to the list so that we can discuss it here.
Does anyone have strong opinions either way about the goals listed above?
It'd be nice if we could have decent support for uwsgi for Glance. With the move to Py3, there's no other way if we want SSL. There are other projects still missing it completely (like Designate).
Cheers,
Thomas Goirand (zigo)
participants (15)
-
Adam Spiers
-
Adrian Turjak
-
Arkady.Kanevsky＠dell.com
-
Artem Goncharov
-
Ben Nemec
-
Dean Troyer
-
Dmitry Tantsur
-
Doug Hellmann
-
Jay Bryant
-
Jean-Philippe Evrard
-
Julia Kreger
-
Lance Bragstad
-
Matt Riedemann
-
Sean McGinnis
-
Thomas Goirand