Re: [openstack-dev] [goals][tc][ptl][uc] starting goal selection for T series
Ack - thanks for the clarification, Tim. On Thu, Sep 27, 2018 at 12:10 PM Tim Bell wrote: > > > Lance, > > > > The comment regarding ‘readers’ is more to explain that the distinction > between ‘admin’ and ‘user’ commands is gradually reducing, where OSC has > been prioritising ‘user’ commands. > > > > As an example, we give the CERN security team view-only access to many > parts of the cloud. This allows them to perform their investigations > independently. Thus, many commands which would be, by default, admin only > are also available to roles such as the ‘readers’ (e.g. list, show, … of > internals or projects which they are not in the members list) > > > > I don’t think there is any implications for Keystone (and the readers role > is a nice improvement to replace the previous manual policy definitions) > but more of a question of which subcommands we should aim to support in OSC. > > > > The *-manage commands such as nova-manage, I would consider, out of scope > for OSC. Only admins would be migrating between versions or DB schemas. > > > > Tim > > > > *From: *Lance Bragstad > *Reply-To: *"OpenStack Development Mailing List (not for usage > questions)" > *Date: *Thursday, 27 September 2018 at 15:30 > *To: *"OpenStack Development Mailing List (not for usage questions)" < > openstack-dev@lists.openstack.org> > *Subject: *Re: [openstack-dev] [goals][tc][ptl][uc] starting goal > selection for T series > > > > > > On Wed, Sep 26, 2018 at 1: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) > > > > Sorry to back up the conversation a bit, but does reader role require work > in the clients? Last release we incorporated three roles by default during > keystone's installation process [0]. Is the definition in the specification > what you mean by reader role, or am I on a different page? > > > > [0] > http://specs.openstack.org/openstack/keystone-specs/specs/keystone/rocky/define-default-roles.html#default-roles > > > > 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)" < > openstack-dev@lists.openstack.org> > 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,
Re: [openstack-dev] [goals][tc][ptl][uc] starting goal selection for T series
Lance, The comment regarding ‘readers’ is more to explain that the distinction between ‘admin’ and ‘user’ commands is gradually reducing, where OSC has been prioritising ‘user’ commands. As an example, we give the CERN security team view-only access to many parts of the cloud. This allows them to perform their investigations independently. Thus, many commands which would be, by default, admin only are also available to roles such as the ‘readers’ (e.g. list, show, … of internals or projects which they are not in the members list) I don’t think there is any implications for Keystone (and the readers role is a nice improvement to replace the previous manual policy definitions) but more of a question of which subcommands we should aim to support in OSC. The *-manage commands such as nova-manage, I would consider, out of scope for OSC. Only admins would be migrating between versions or DB schemas. Tim From: Lance Bragstad Reply-To: "OpenStack Development Mailing List (not for usage questions)" Date: Thursday, 27 September 2018 at 15:30 To: "OpenStack Development Mailing List (not for usage questions)" Subject: Re: [openstack-dev] [goals][tc][ptl][uc] starting goal selection for T series On Wed, Sep 26, 2018 at 1:56 PM Tim Bell mailto:tim.b...@cern.ch>> 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) Sorry to back up the conversation a bit, but does reader role require work in the clients? Last release we incorporated three roles by default during keystone's installation process [0]. Is the definition in the specification what you mean by reader role, or am I on a different page? [0] http://specs.openstack.org/openstack/keystone-specs/specs/keystone/rocky/define-default-roles.html#default-roles 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 mailto:d...@doughellmann.com>> Reply-To: "OpenStack Development Mailing List (not for usage questions)" mailto:openstack-dev@lists.openstack.org>> Date: Wednesday, 26 September 2018 at 18:00 To: openstack-dev mailto:openstack-dev@lists.openstack.org>>, openstack-operators mailto:openstack-operat...@lists.openstack.org>>, openstack-sigs mailto:openstack-s...@lists.openstack.org>> 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/sum
Re: [openstack-dev] [goals][tc][ptl][uc] starting goal selection for T series
On Wed, Sep 26, 2018 at 1: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) > > Sorry to back up the conversation a bit, but does reader role require work in the clients? Last release we incorporated three roles by default during keystone's installation process [0]. Is the definition in the specification what you mean by reader role, or am I on a different page? [0] http://specs.openstack.org/openstack/keystone-specs/specs/keystone/rocky/define-default-roles.html#default-roles > 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)" < > openstack-dev@lists.openstack.org> > 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 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] [goals][tc][ptl][uc] starting goal selection for T series
On 09/26/2018 04:12 PM, Dean Troyer wrote: On Wed, Sep 26, 2018 at 3:01 PM, Doug Hellmann wrote: Would it be useful to have the SDK work in OSC as a prerequisite to the goal work? I would hate to have folks have to write a bunch of things twice. I don't think this is necessary, once we have the auth and service discovery/version negotiation plumbing in OSC properly new things can be done in OSC without having to wait for conversion. Any of the existing client libs that can utilize an adapter form the SDK makes this even simpler for conversion. As one might expect, I agree with Dean. I don't think we need to wait on it. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [goals][tc][ptl][uc] starting goal selection for T series
On Wed, Sep 26, 2018 at 3:01 PM, Doug Hellmann wrote: > Would it be useful to have the SDK work in OSC as a prerequisite to the > goal work? I would hate to have folks have to write a bunch of things > twice. I don't think this is necessary, once we have the auth and service discovery/version negotiation plumbing in OSC properly new things can be done in OSC without having to wait for conversion. Any of the existing client libs that can utilize an adapter form the SDK makes this even simpler for conversion. > Do we have any sort of list of which projects aren't currently being > handled by OSC? If we could get some help building such a list, that > would help us understand the scope of the work. We have asked plugins to maintain their presence in the OSC docs [0], there are three listed there as not having plugins but I wouldn't consider that exhaustive. We also ask them to list their resource names in [1] to reserve the name to help prevent name collisions. > As far as admin features, I think we've been hesitant to add those to > OSC in the past, but I can see the value. I wonder if having them in a > separate library makes sense? Or is it better to have commands in the > tool that regular users can't access, and just report the permission > error when they try to run the command? The admin/non-admin distinction has not been a hard rule in most places, we have plenty of admin commands in OSC. At times we have talked about pulling those out of the OSC repo into an admin plugin, I haven't encouraged that as I am not convinced of the value enough to put aside other things to do it. Due to configurable policy it also is not clear what to include and exclude, to me it is a better user experience, and more interoperable between cloud deployments, to correctly handle when admin/policy refuses to do something and let the user sort it out as necessary. [0] https://docs.openstack.org/python-openstackclient/latest/contributor/plugins.html#adoption [1] https://docs.openstack.org/python-openstackclient/latest/cli/commands.html#plugin-objects 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] [goals][tc][ptl][uc] starting goal selection for T series
On 9/26/2018 3:01 PM, Doug Hellmann wrote: Monty Taylor writes: On 09/26/2018 01:55 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. I would personally like to thank the person that put that goal in the etherpad...they must have had amazing foresight and unparalleled modesty. 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. ++ It's also worth noting that we're REALLY close to a 1.0 of openstacksdk (all the patches are in flight, we just need to land them) - and once we've got that we'll be in a position to start shifting python-openstackclient to using openstacksdk instead of python-*client. This will have the additional benefit that, once we've migrated CLIs to python-openstackclient as per this goal, and once we've migrated openstackclient itself to openstacksdk, the number of different libraries one needs to install to interact with openstack will be _dramatically_ lower. Would it be useful to have the SDK work in OSC as a prerequisite to the goal work? I would hate to have folks have to write a bunch of things twice. Do we have any sort of list of which projects aren't currently being handled by OSC? If we could get some help building such a list, that would help us understand the scope of the work. 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. As far as admin features, I think we've been hesitant to add those to OSC in the past, but I can see the value. I wonder if having them in a separate library makes sense? Or is it better to have commands in the tool that regular users can't access, and just report the permission error when they try to run the command? 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 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 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/c
Re: [openstack-dev] [goals][tc][ptl][uc] starting goal selection for T series
Monty Taylor writes: > On 09/26/2018 01:55 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. > > ++ > > It's also worth noting that we're REALLY close to a 1.0 of openstacksdk > (all the patches are in flight, we just need to land them) - and once > we've got that we'll be in a position to start shifting > python-openstackclient to using openstacksdk instead of python-*client. > > This will have the additional benefit that, once we've migrated CLIs to > python-openstackclient as per this goal, and once we've migrated > openstackclient itself to openstacksdk, the number of different > libraries one needs to install to interact with openstack will be > _dramatically_ lower. Would it be useful to have the SDK work in OSC as a prerequisite to the goal work? I would hate to have folks have to write a bunch of things twice. Do we have any sort of list of which projects aren't currently being handled by OSC? If we could get some help building such a list, that would help us understand the scope of the work. As far as admin features, I think we've been hesitant to add those to OSC in the past, but I can see the value. I wonder if having them in a separate library makes sense? Or is it better to have commands in the tool that regular users can't access, and just report the permission error when they try to run the command? Doug > >> -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]
Re: [openstack-dev] [goals][tc][ptl][uc] starting goal selection for T series
On 09/26/2018 01:55 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. ++ It's also worth noting that we're REALLY close to a 1.0 of openstacksdk (all the patches are in flight, we just need to land them) - and once we've got that we'll be in a position to start shifting python-openstackclient to using openstacksdk instead of python-*client. This will have the additional benefit that, once we've migrated CLIs to python-openstackclient as per this goal, and once we've migrated openstackclient itself to openstacksdk, the number of different libraries one needs to install to interact with openstack will be _dramatically_ lower. -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 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] [goals][tc][ptl][uc] starting goal selection for T series
+1 -Original Message- From: Tim Bell [mailto:tim.b...@cern.ch] Sent: Wednesday, September 26, 2018 1:56 PM To: OpenStack Development Mailing List (not for usage questions); openstack-operators; openstack-sigs Subject: Re: [Openstack-sigs] [openstack-dev] [goals][tc][ptl][uc] starting goal selection for T series [EXTERNAL EMAIL] Please report any suspicious attachments, links, or requests for sensitive information. 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
Re: [openstack-dev] [goals][tc][ptl][uc] starting goal selection for T series
+1 :) From: Tim Bell [tim.b...@cern.ch] Sent: Wednesday, September 26, 2018 11:55 AM To: OpenStack Development Mailing List (not for usage questions); openstack-operators; openstack-sigs Subject: Re: [Openstack-sigs] [openstack-dev] [goals][tc][ptl][uc] starting goal selection for T series 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
Re: [openstack-dev] [goals][tc][ptl][uc] starting goal selection for T series
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 Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [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
