Re: [openstack-dev] [Openstack-sigs] [goals][tc][ptl][uc] starting goal selection for T series
Its the commons problem again. Either we encourage folks to contribute a little bit to the commons (review a few other peoples noncompute cli thingies. in doing so, you learn how to better do the cli in the generic/user friendly ways), to further their own project goals (get easier access to contribute to the cli of the compute stuff), or we do what we've always done. Let each project maintain their own cli and have no uniformity at all. Why are the walls in OpenStack so high? Kevin From: Matt Riedemann [mriede...@gmail.com] Sent: Thursday, September 27, 2018 12:35 PM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Openstack-sigs] [goals][tc][ptl][uc] starting goal selection for T series On 9/27/2018 2:33 PM, Fox, Kevin M wrote: > If the project plugins were maintained by the OSC project still, maybe there > would be incentive for the various other projects to join the OSC project, > scaling things up? Sure, I don't really care about governance. But I also don't really care about all of the non-compute API things in OSC either. -- 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 __ 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-sigs] [goals][tc][ptl][uc] starting goal selection for T series
On 9/27/2018 2:33 PM, Fox, Kevin M wrote: If the project plugins were maintained by the OSC project still, maybe there would be incentive for the various other projects to join the OSC project, scaling things up? Sure, I don't really care about governance. But I also don't really care about all of the non-compute API things in OSC either. -- 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] [Openstack-sigs] [goals][tc][ptl][uc] starting goal selection for T series
If the project plugins were maintained by the OSC project still, maybe there would be incentive for the various other projects to join the OSC project, scaling things up? Thanks, Kevin From: Matt Riedemann [mriede...@gmail.com] Sent: Thursday, September 27, 2018 12:12 PM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Openstack-sigs] [goals][tc][ptl][uc] starting goal selection for T series On 9/27/2018 10:13 AM, Dean Troyer wrote: > On Thu, Sep 27, 2018 at 9:10 AM, Doug Hellmann wrote: >> Monty Taylor writes: >>> Main difference is making sure these new deconstructed plugin teams >>> understand the client support lifecycle - which is that we don't drop >>> support for old versions of services in OSC (or SDK). It's a shift from >>> the support lifecycle and POV of python-*client, but it's important and >>> we just need to all be on the same page. >> That sounds like a reason to keep the governance of the libraries under >> the client tool project. > Hmmm... I think that may address a big chunk of my reservations about > being able to maintain consistency and user experience in a fully > split-OSC world. > > dt My biggest worry with splitting everything out into plugins with new core teams, even with python-openstackclient-core as a superset, is that those core teams will all start approving things that don't fit with the overall guidelines of how OSC commands should be written. I've had to go to the "Dean well" several times when reviewing osc-placement commands. But the python-openstackclient-core team probably isn't going to scale to fit the need of all of these gaps that need closing from the various teams, either. So how does that get fixed? I've told Dean and Steve before that if they want me to review / ack something compute-specific in OSC that they can call on me, like a liaison. Maybe that's all we need to start? Because I've definitely disagreed with compute CLI changes in OSC that have a +2 from the core team because of a lack of understanding from both the contributor and the reviewers about what the compute API actually does, or how a microversion behaves. Or maybe we just do some kind of subteam thing where OSC core doesn't look at a change until the subteam has +1ed it. We have a similar concept in nova with virt driver subteams. -- 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 __ 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-sigs] [goals][tc][ptl][uc] starting goal selection for T series
On 9/27/2018 10:13 AM, Dean Troyer wrote: On Thu, Sep 27, 2018 at 9:10 AM, Doug Hellmann wrote: Monty Taylor writes: Main difference is making sure these new deconstructed plugin teams understand the client support lifecycle - which is that we don't drop support for old versions of services in OSC (or SDK). It's a shift from the support lifecycle and POV of python-*client, but it's important and we just need to all be on the same page. That sounds like a reason to keep the governance of the libraries under the client tool project. Hmmm... I think that may address a big chunk of my reservations about being able to maintain consistency and user experience in a fully split-OSC world. dt My biggest worry with splitting everything out into plugins with new core teams, even with python-openstackclient-core as a superset, is that those core teams will all start approving things that don't fit with the overall guidelines of how OSC commands should be written. I've had to go to the "Dean well" several times when reviewing osc-placement commands. But the python-openstackclient-core team probably isn't going to scale to fit the need of all of these gaps that need closing from the various teams, either. So how does that get fixed? I've told Dean and Steve before that if they want me to review / ack something compute-specific in OSC that they can call on me, like a liaison. Maybe that's all we need to start? Because I've definitely disagreed with compute CLI changes in OSC that have a +2 from the core team because of a lack of understanding from both the contributor and the reviewers about what the compute API actually does, or how a microversion behaves. Or maybe we just do some kind of subteam thing where OSC core doesn't look at a change until the subteam has +1ed it. We have a similar concept in nova with virt driver subteams. -- 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] [Openstack-sigs] [goals][tc][ptl][uc] starting goal selection for T series
On Thu, Sep 27, 2018 at 9:10 AM, Doug Hellmann wrote: > Monty Taylor writes: >> Main difference is making sure these new deconstructed plugin teams >> understand the client support lifecycle - which is that we don't drop >> support for old versions of services in OSC (or SDK). It's a shift from >> the support lifecycle and POV of python-*client, but it's important and >> we just need to all be on the same page. > > That sounds like a reason to keep the governance of the libraries under > the client tool project. Hmmm... I think that may address a big chunk of my reservations about being able to maintain consistency and user experience in a fully split-OSC world. dt -- Dean Troyer dtro...@gmail.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] [Openstack-sigs] [goals][tc][ptl][uc] starting goal selection for T series
On Thu, Sep 27, 2018 at 9:06 AM, Doug Hellmann wrote: > I definitely think having details about the gaps would be a prerequisite > for approving a goal, but I wonder if that's something 1 person could > even do alone. Is this an area where a small team is needed? Maybe, but it does break down along project/API lines for the most part, only crossing in places like Matt mentioned where compute+volume interact in server create, etc. For the purposes of a goal, I think we need to be thinking more about structural things than specific command changes. Things like Monty mentioned elsewhere in the thread about getting all of the exiting client libs to correctly use an SDK adapter then behaviours converge and the details of command changes become project-specific. > We built cliff to be based on plugins to support this sort of work > distribution, right? We did, my concerns about splitting the OSC in-repo plugins out is frankly more around losing control of things like command structure and consistency, not about the code. Looking at the loss of consistency in plugins shows that is a hard thing to maintain across a distributed set of groups. >> One thing I don't like about that is we just replace N client libs >> with N (or more) plugins now and the number of things a user must >> install doesn't go down. I would like to hear from anyone who deals >> with installing OSC if that is still a big deal or should I let go of >> that worry? > > Don't package managers just deal with this? I can pip/yum/apt install > something and get all of its dependencies, right? For those using that, yes. The set of folks interacting with OpenStack from a Windows desktop is not as large but their experience is sometimes a painful one...although wheels were just becoming a thing when I last tried to bundle OSC into a py2exe-style thing so the pains of things like OpenSSL may be fewer now. dt -- Dean Troyer dtro...@gmail.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] [Openstack-sigs] [goals][tc][ptl][uc] starting goal selection for T series
Monty Taylor writes: > Main difference is making sure these new deconstructed plugin teams > understand the client support lifecycle - which is that we don't drop > support for old versions of services in OSC (or SDK). It's a shift from > the support lifecycle and POV of python-*client, but it's important and > we just need to all be on the same page. That sounds like a reason to keep the governance of the libraries under the client tool project. Doug __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Openstack-sigs] [goals][tc][ptl][uc] starting goal selection for T series
Dean Troyer writes: > On Wed, Sep 26, 2018 at 3:44 PM, Matt Riedemann wrote: >> I started documenting the compute API gaps in OSC last release [1]. It's a >> big gap and needs a lot of work, even for existing CLIs (the cold/live >> migration CLIs in OSC are a mess, and you can't even boot from volume where >> nova creates the volume for you). That's also why I put something into the >> etherpad about the OSC core team even being able to handle an onslaught of >> changes for a goal like this. > > The OSC core team is very thin, yes, it seems as though companies > don't like to spend money on client-facing things...I'll be in the > hall following this thread should anyone want to talk... > > The migration commands are a mess, mostly because I got them wrong to > start with and we have only tried to patch it up, this is one area I > think we need to wipe clean and fix properly. Yay! Major version > release! I definitely think having details about the gaps would be a prerequisite for approving a goal, but I wonder if that's something 1 person could even do alone. Is this an area where a small team is needed? >> I thought the same, and we talked about this at the Austin summit, but OSC >> is inconsistent about this (you can live migrate a server but you can't >> evacuate it - there is no CLI for evacuation). It also came up at the Stein >> PTG with Dean in the nova room giving us some direction. [2] I believe the >> summary of that discussion was: > >> a) to deal with the core team sprawl, we could move the compute stuff out of >> python-openstackclient and into an osc-compute plugin (like the >> osc-placement plugin for the placement service); then we could create a new >> core team which would have python-openstackclient-core as a superset > > This is not my first choice but is not terrible either... We built cliff to be based on plugins to support this sort of work distribution, right? >> b) Dean suggested that we close the compute API gaps in the SDK first, but >> that could take a long time as well...but it sounded like we could use the >> SDK for things that existed in the SDK and use novaclient for things that >> didn't yet exist in the SDK > > Yup, this can be done in parallel. The unit of decision for use sdk > vs use XXXclient lib is per-API call. If the client lib can use an > SDK adapter/session it becomes even better. I think the priority for > what to address first should be guided by complete gaps in coverage > and the need for microversion-driven changes. > >> This might be a candidate for one of these multi-release goals that the TC >> started talking about at the Stein PTG. I could see something like this >> being a goal for Stein: >> >> "Each project owns its own osc- plugin for OSC CLIs" >> >> That deals with the core team and sprawl issue, especially with stevemar >> being gone and dtroyer being distracted by shiny x-men bird related things. >> That also seems relatively manageable for all projects to do in a single >> release. Having a single-release goal of "close all gaps across all service >> types" is going to be extremely tough for any older projects that had CLIs >> before OSC was created (nova/cinder/glance/keystone). For newer projects, >> like placement, it's not a problem because they never created any other CLI >> outside of OSC. Yeah, I agree this work is going to need to be split up. I'm still not sold on the idea of multi-cycle goals, personally. > I think the major difficulty here is simply how to migrate users from > today state to future state in a reasonable manner. If we could teach > OSC how to handle the same command being defined in multiple plugins > properly (hello entrypoints!) it could be much simpler as we could > start creating the new plugins and switch as the new command > implementations become available rather than having a hard cutover. > > Or maybe the definition of OSC v4 is as above and we just work at it > until complete and cut over at the end. Note that the current APIs > that are in-repo (Compute, Identity, Image, Network, Object, Volume) > are all implemented using the plugin structure, OSC v4 could start as > the breaking out of those without command changes (except new > migration commands!) and then the plugins all re-write and update at > their own tempo. Dang, did I just deconstruct my project? It sure sounds like it. Congratulations! I like the idea of moving the existing code into libraries, having python-openstackclient depend on them, and then asking project teams for more help with them. > One thing I don't like about that is we just replace N client libs > with N (or more) plugins now and the number of things a user must > install doesn't go down. I would like to hear from anyone who deals > with installing OSC if that is still a big deal or should I let go of > that worry? Don't package managers just deal with this? I can pip/yum/apt install something and get all of its dependencies, right? Doug
Re: [openstack-dev] [Openstack-sigs] [goals][tc][ptl][uc] starting goal selection for T series
First I think that is a great goal, but I want to pick up on Dean's comment: Dean Troyer wrote: [...] The OSC core team is very thin, yes, it seems as though companies don't like to spend money on client-facing things...I'll be in the hall following this thread should anyone want to talk... I think OSC (and client-facing tooling in general) is a great place for OpenStack users (deployers of OpenStack clouds) to contribute. It's a smaller territory, it's less time-consuming than the service side, they are the most obvious interested party, and a small, 20% time investment would have a dramatic impact. It's arguably difficult for OpenStack users to get involved in "OpenStack development": keeping track of what's happening in a large team is already likely to consume most of the time you can dedicate to it. But OSC is a specific, smaller area which would be a good match for the expertise and time availability of anybody running an OpenStack cloud that wants to contribute back and make OpenStack better. Shameless plug: I proposed a Forum session in Berlin to discuss "Getting OpenStack users involved in the project" -- and we'll discuss such areas that are a particularly good match for users to get involved. -- Thierry Carrez (ttx) __ 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-sigs] [goals][tc][ptl][uc] starting goal selection for T series
On 09/26/2018 04:33 PM, Dean Troyer wrote: On Wed, Sep 26, 2018 at 3:44 PM, Matt Riedemann wrote: I started documenting the compute API gaps in OSC last release [1]. It's a big gap and needs a lot of work, even for existing CLIs (the cold/live migration CLIs in OSC are a mess, and you can't even boot from volume where nova creates the volume for you). That's also why I put something into the etherpad about the OSC core team even being able to handle an onslaught of changes for a goal like this. The OSC core team is very thin, yes, it seems as though companies don't like to spend money on client-facing things...I'll be in the hall following this thread should anyone want to talk... The migration commands are a mess, mostly because I got them wrong to start with and we have only tried to patch it up, this is one area I think we need to wipe clean and fix properly. Yay! Major version release! I thought the same, and we talked about this at the Austin summit, but OSC is inconsistent about this (you can live migrate a server but you can't evacuate it - there is no CLI for evacuation). It also came up at the Stein PTG with Dean in the nova room giving us some direction. [2] I believe the summary of that discussion was: a) to deal with the core team sprawl, we could move the compute stuff out of python-openstackclient and into an osc-compute plugin (like the osc-placement plugin for the placement service); then we could create a new core team which would have python-openstackclient-core as a superset This is not my first choice but is not terrible either... b) Dean suggested that we close the compute API gaps in the SDK first, but that could take a long time as well...but it sounded like we could use the SDK for things that existed in the SDK and use novaclient for things that didn't yet exist in the SDK Yup, this can be done in parallel. The unit of decision for use sdk vs use XXXclient lib is per-API call. If the client lib can use an SDK adapter/session it becomes even better. I think the priority for what to address first should be guided by complete gaps in coverage and the need for microversion-driven changes. This might be a candidate for one of these multi-release goals that the TC started talking about at the Stein PTG. I could see something like this being a goal for Stein: "Each project owns its own osc- plugin for OSC CLIs" That deals with the core team and sprawl issue, especially with stevemar being gone and dtroyer being distracted by shiny x-men bird related things. That also seems relatively manageable for all projects to do in a single release. Having a single-release goal of "close all gaps across all service types" is going to be extremely tough for any older projects that had CLIs before OSC was created (nova/cinder/glance/keystone). For newer projects, like placement, it's not a problem because they never created any other CLI outside of OSC. I think the major difficulty here is simply how to migrate users from today state to future state in a reasonable manner. If we could teach OSC how to handle the same command being defined in multiple plugins properly (hello entrypoints!) it could be much simpler as we could start creating the new plugins and switch as the new command implementations become available rather than having a hard cutover. Or maybe the definition of OSC v4 is as above and we just work at it until complete and cut over at the end. I think that sounds pretty good, actually. We can also put the 'just get the sdk Connection' code in. You mentioned earlier that python-*client that can take an existing ksa Adapter as a constructor parameter make this easier - maybe let's put that down as a workitem for this? Becuase if we could do that- then we know we've got discovery and config working consistently across the board no matter if a call is using sdk or python-*client primitives under the cover - so everything will respond to env vars and command line options and clouds.yaml consistently. For that to work, a python-*client Client that took an keystoneauth1.adapter.Adapter would need to take it as gospel and not do further processing of config, otherwise the point is defeated. But it should be straightforward to do in most cases, yeah? Note that the current APIs that are in-repo (Compute, Identity, Image, Network, Object, Volume) are all implemented using the plugin structure, OSC v4 could start as the breaking out of those without command changes (except new migration commands!) and then the plugins all re-write and update at their own tempo. Dang, did I just deconstruct my project? Main difference is making sure these new deconstructed plugin teams understand the client support lifecycle - which is that we don't drop support for old versions of services in OSC (or SDK). It's a shift from the support lifecycle and POV of python-*client, but it's important and we just need to all be on the same page. One thing I don't like
Re: [openstack-dev] [Openstack-sigs] [goals][tc][ptl][uc] starting goal selection for T series
Oh, very definitely +1000 -- Rochelle Grober Rochelle Grober M: +1-6508889722(preferred) E: rochelle.gro...@huawei.com<mailto:rochelle.gro...@huawei.com> 2012实验室-硅谷研究所技术规划及合作部 2012 Laboratories-Silicon Valley Technology Planning & Cooperation,Silicon Valley Research Center From:Mathieu Gagné To:openstack-s...@lists.openstack.org, Cc:OpenStack Development Mailing List (not for usage questions),OpenStack Operators, Date:2018-09-26 12:41:24 Subject:Re: [Openstack-sigs] [openstack-dev] [goals][tc][ptl][uc] starting goal selection for T series +1 Yes please! -- Mathieu On Wed, Sep 26, 2018 at 2:56 PM Tim Bell wrote: > > > Doug, > > Thanks for raising this. I'd like to highlight the goal "Finish moving legacy > python-*client CLIs to python-openstackclient" from the etherpad and propose > this for a T/U series goal. > > To give it some context and the motivation: > > At CERN, we have more than 3000 users of the OpenStack cloud. We write an > extensive end user facing documentation which explains how to use the > OpenStack along with CERN specific features (such as workflows for requesting > projects/quotas/etc.). > > One regular problem we come across is that the end user experience is > inconsistent. In some cases, we find projects which are not covered by the > unified OpenStack client (e.g. Manila). In other cases, there are subsets of > the function which require the native project client. > > I would strongly support a goal which targets > > - All new projects should have the end user facing functionality fully > exposed via the unified client > - Existing projects should aim to close the gap within 'N' cycles (N to be > defined) > - Many administrator actions would also benefit from integration (reader > roles are end users too so list and show need to be covered too) > - Users should be able to use a single openrc for all interactions with the > cloud (e.g. not switch between password for some CLIs and Kerberos for OSC) > > The end user perception of a solution will be greatly enhanced by a single > command line tool with consistent syntax and authentication framework. > > It may be a multi-release goal but it would really benefit the cloud > consumers and I feel that goals should include this audience also. > > Tim > > -Original Message- > From: Doug Hellmann > Reply-To: "OpenStack Development Mailing List (not for usage questions)" > > Date: Wednesday, 26 September 2018 at 18:00 > To: openstack-dev , openstack-operators > , openstack-sigs > > Subject: [openstack-dev] [goals][tc][ptl][uc] starting goal selection for T > series > > It's time to start thinking about community-wide goals for the T series. > > We use community-wide goals to achieve visible common changes, push for > basic levels of consistency and user experience, and efficiently improve > certain areas where technical debt payments have become too high - > across all OpenStack projects. Community input is important to ensure > that the TC makes good decisions about the goals. We need to consider > the timing, cycle length, priority, and feasibility of the suggested > goals. > > If you are interested in proposing a goal, please make sure that before > the summit it is described in the tracking etherpad [1] and that you > have started a mailing list thread on the openstack-dev list about the > proposal so that everyone in the forum session [2] has an opportunity to > consider the details. The forum session is only one step in the > selection process. See [3] for more details. > > Doug > > [1] https://etherpad.openstack.org/p/community-goals > [2] https://www.openstack.org/summit/berlin-2018/vote-for-speakers#/22814 > [3] https://governance.openstack.org/tc/goals/index.html > > __ > 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-sigs mailing list > openstack-s...@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs ___ openstack-sigs mailing list openstack-s...@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs __ 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-sigs] [goals][tc][ptl][uc] starting goal selection for T series
On Wed, Sep 26, 2018 at 3:44 PM, Matt Riedemann wrote: > I started documenting the compute API gaps in OSC last release [1]. It's a > big gap and needs a lot of work, even for existing CLIs (the cold/live > migration CLIs in OSC are a mess, and you can't even boot from volume where > nova creates the volume for you). That's also why I put something into the > etherpad about the OSC core team even being able to handle an onslaught of > changes for a goal like this. The OSC core team is very thin, yes, it seems as though companies don't like to spend money on client-facing things...I'll be in the hall following this thread should anyone want to talk... The migration commands are a mess, mostly because I got them wrong to start with and we have only tried to patch it up, this is one area I think we need to wipe clean and fix properly. Yay! Major version release! > I thought the same, and we talked about this at the Austin summit, but OSC > is inconsistent about this (you can live migrate a server but you can't > evacuate it - there is no CLI for evacuation). It also came up at the Stein > PTG with Dean in the nova room giving us some direction. [2] I believe the > summary of that discussion was: > a) to deal with the core team sprawl, we could move the compute stuff out of > python-openstackclient and into an osc-compute plugin (like the > osc-placement plugin for the placement service); then we could create a new > core team which would have python-openstackclient-core as a superset This is not my first choice but is not terrible either... > b) Dean suggested that we close the compute API gaps in the SDK first, but > that could take a long time as well...but it sounded like we could use the > SDK for things that existed in the SDK and use novaclient for things that > didn't yet exist in the SDK Yup, this can be done in parallel. The unit of decision for use sdk vs use XXXclient lib is per-API call. If the client lib can use an SDK adapter/session it becomes even better. I think the priority for what to address first should be guided by complete gaps in coverage and the need for microversion-driven changes. > This might be a candidate for one of these multi-release goals that the TC > started talking about at the Stein PTG. I could see something like this > being a goal for Stein: > > "Each project owns its own osc- plugin for OSC CLIs" > > That deals with the core team and sprawl issue, especially with stevemar > being gone and dtroyer being distracted by shiny x-men bird related things. > That also seems relatively manageable for all projects to do in a single > release. Having a single-release goal of "close all gaps across all service > types" is going to be extremely tough for any older projects that had CLIs > before OSC was created (nova/cinder/glance/keystone). For newer projects, > like placement, it's not a problem because they never created any other CLI > outside of OSC. I think the major difficulty here is simply how to migrate users from today state to future state in a reasonable manner. If we could teach OSC how to handle the same command being defined in multiple plugins properly (hello entrypoints!) it could be much simpler as we could start creating the new plugins and switch as the new command implementations become available rather than having a hard cutover. Or maybe the definition of OSC v4 is as above and we just work at it until complete and cut over at the end. Note that the current APIs that are in-repo (Compute, Identity, Image, Network, Object, Volume) are all implemented using the plugin structure, OSC v4 could start as the breaking out of those without command changes (except new migration commands!) and then the plugins all re-write and update at their own tempo. Dang, did I just deconstruct my project? One thing I don't like about that is we just replace N client libs with N (or more) plugins now and the number of things a user must install doesn't go down. I would like to hear from anyone who deals with installing OSC if that is still a big deal or should I let go of that worry? dt -- Dean Troyer dtro...@gmail.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] [Openstack-sigs] [goals][tc][ptl][uc] starting goal selection for T series
On 26/09/18 18:55 +, Tim Bell wrote: Doug, Thanks for raising this. I'd like to highlight the goal "Finish moving legacy python-*client CLIs to python-openstackclient" from the etherpad and propose this for a T/U series goal. To give it some context and the motivation: At CERN, we have more than 3000 users of the OpenStack cloud. We write an extensive end user facing documentation which explains how to use the OpenStack along with CERN specific features (such as workflows for requesting projects/quotas/etc.). One regular problem we come across is that the end user experience is inconsistent. In some cases, we find projects which are not covered by the unified OpenStack client (e.g. Manila). Tim, First, I endorse this goal. That said, lack of coverage of Manila in the OpenStack client was articulated as a need (by CERN and others) during the Vancouver Forum. At the recent Manila PTG we set addressing this technical debt as a Stein cycle goal, as well as OpenStack SDK integration for Manila. -- Tom Barron (tbarron) In other cases, there are subsets of the function which require the native project client. I would strongly support a goal which targets - All new projects should have the end user facing functionality fully exposed via the unified client - Existing projects should aim to close the gap within 'N' cycles (N to be defined) - Many administrator actions would also benefit from integration (reader roles are end users too so list and show need to be covered too) - Users should be able to use a single openrc for all interactions with the cloud (e.g. not switch between password for some CLIs and Kerberos for OSC) The end user perception of a solution will be greatly enhanced by a single command line tool with consistent syntax and authentication framework. It may be a multi-release goal but it would really benefit the cloud consumers and I feel that goals should include this audience also. Tim -Original Message- From: Doug Hellmann Reply-To: "OpenStack Development Mailing List (not for usage questions)" Date: Wednesday, 26 September 2018 at 18:00 To: openstack-dev , openstack-operators , openstack-sigs Subject: [openstack-dev] [goals][tc][ptl][uc] starting goal selection for T series It's time to start thinking about community-wide goals for the T series. We use community-wide goals to achieve visible common changes, push for basic levels of consistency and user experience, and efficiently improve certain areas where technical debt payments have become too high - across all OpenStack projects. Community input is important to ensure that the TC makes good decisions about the goals. We need to consider the timing, cycle length, priority, and feasibility of the suggested goals. If you are interested in proposing a goal, please make sure that before the summit it is described in the tracking etherpad [1] and that you have started a mailing list thread on the openstack-dev list about the proposal so that everyone in the forum session [2] has an opportunity to consider the details. The forum session is only one step in the selection process. See [3] for more details. Doug [1] https://etherpad.openstack.org/p/community-goals [2] https://www.openstack.org/summit/berlin-2018/vote-for-speakers#/22814 [3] https://governance.openstack.org/tc/goals/index.html __ 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-sigs mailing list openstack-s...@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs __ 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-sigs] [goals][tc][ptl][uc] starting goal selection for T series
+1 Yes please! -- Mathieu On Wed, Sep 26, 2018 at 2:56 PM Tim Bell wrote: > > > Doug, > > Thanks for raising this. I'd like to highlight the goal "Finish moving legacy > python-*client CLIs to python-openstackclient" from the etherpad and propose > this for a T/U series goal. > > To give it some context and the motivation: > > At CERN, we have more than 3000 users of the OpenStack cloud. We write an > extensive end user facing documentation which explains how to use the > OpenStack along with CERN specific features (such as workflows for requesting > projects/quotas/etc.). > > One regular problem we come across is that the end user experience is > inconsistent. In some cases, we find projects which are not covered by the > unified OpenStack client (e.g. Manila). In other cases, there are subsets of > the function which require the native project client. > > I would strongly support a goal which targets > > - All new projects should have the end user facing functionality fully > exposed via the unified client > - Existing projects should aim to close the gap within 'N' cycles (N to be > defined) > - Many administrator actions would also benefit from integration (reader > roles are end users too so list and show need to be covered too) > - Users should be able to use a single openrc for all interactions with the > cloud (e.g. not switch between password for some CLIs and Kerberos for OSC) > > The end user perception of a solution will be greatly enhanced by a single > command line tool with consistent syntax and authentication framework. > > It may be a multi-release goal but it would really benefit the cloud > consumers and I feel that goals should include this audience also. > > Tim > > -Original Message- > From: Doug Hellmann > Reply-To: "OpenStack Development Mailing List (not for usage questions)" > > Date: Wednesday, 26 September 2018 at 18:00 > To: openstack-dev , openstack-operators > , openstack-sigs > > Subject: [openstack-dev] [goals][tc][ptl][uc] starting goal selection for T > series > > It's time to start thinking about community-wide goals for the T series. > > We use community-wide goals to achieve visible common changes, push for > basic levels of consistency and user experience, and efficiently improve > certain areas where technical debt payments have become too high - > across all OpenStack projects. Community input is important to ensure > that the TC makes good decisions about the goals. We need to consider > the timing, cycle length, priority, and feasibility of the suggested > goals. > > If you are interested in proposing a goal, please make sure that before > the summit it is described in the tracking etherpad [1] and that you > have started a mailing list thread on the openstack-dev list about the > proposal so that everyone in the forum session [2] has an opportunity to > consider the details. The forum session is only one step in the > selection process. See [3] for more details. > > Doug > > [1] https://etherpad.openstack.org/p/community-goals > [2] https://www.openstack.org/summit/berlin-2018/vote-for-speakers#/22814 > [3] https://governance.openstack.org/tc/goals/index.html > > __ > 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-sigs mailing list > openstack-s...@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs __ 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
