Re: [openstack-dev] [Programs] Client Tools program discussion
For anyone following along this will be discussed in the OpenStackClient and SDKs and project libraries sessions [1] [2]. Everett [1] http://junodesignsummit.sched.org/event/ae9afc77278abb98f0fc35a540a1bb0b [2] http://junodesignsummit.sched.org/event/9c99888fba09c643834d4ef9241cc90a On May 7, 2014, at 6:21 PM, Joe Gordon joe.gord...@gmail.commailto:joe.gord...@gmail.com wrote: On Wed, May 7, 2014 at 3:33 PM, Dean Troyer dtro...@gmail.commailto:dtro...@gmail.com wrote: On Wed, May 7, 2014 at 5:05 PM, Joe Gordon joe.gord...@gmail.commailto:joe.gord...@gmail.com wrote: Would client tools be limited to only a pythonSDK or in the future could it potentially have other languages? There are a handful of other language projects active on Stackforge that have expressed interest in joining the program when they reach some state of maturity. That is a big part of the reason for structuring things the way we have. If any were ready today they would be included in the initial proposal. https://git.openstack.org/cgit/stackforge/python-openstacksdkhttps://github.com/stackforge/python-openstacksdk https://git.openstack.org/cgit/stackforge/openstack-sdk-php/http://git.openstack.org/cgit/stackforge/openstack-sdk-php/ https://git.openstack.org/cgit/stackforge/openstack-sdk-dotnet/http://git.openstack.org/cgit/stackforge/openstack-sdk-dotnet/ https://git.openstack.org/cgit/stackforge/golang-client/http://git.openstack.org/cgit/stackforge/golang-client/ https://git.openstack.org/cgit/stackforge/openstack-cli-powershell/http://git.openstack.org/cgit/stackforge/openstack-cli-powershell/ Awesome. Thanks for all the clarifications. I for one welcome the our new ClientTools overloard. dt -- Dean Troyer dtro...@gmail.commailto:dtro...@gmail.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Programs] Client Tools program discussion
On Tue, May 6, 2014 at 5:45 PM, Joe Gordon joe.gord...@gmail.com wrote: On Tue, May 6, 2014 at 6:54 AM, Dean Troyer dtro...@gmail.com wrote: On Tue, May 6, 2014 at 7:02 AM, Thierry Carrez thie...@openstack.org wrote: Would you take over the Python client libraries as well ? On one hand they need /some/ domain expertise, but on the other I see no reason to special-case Python against other SDKs, and that may give the libraries a bit more attention and convergence (they currently are the ugly stepchild in some programs, and vary a lot). The future of the existing client libs has not been settled, my working assumption is that they would remain with their home programs as they are now. From the start OpenStackClient was meant to be a clean-slate for the CLI and the Python SDK is taking the same basic approach. Very excited for the OpenStackClient, it is already way nicer then the existing clients. Just working this out in my head. So the work flow would be: 1. At first ClientTools consist of just the OpenStackClient 2. When the pythonSDK is ready to move off of stackforge, it will live in ClientTools 3. Specific python-*clients will be rewritten (from scratch?) to use the PythonSDK. But this time they won't have a built in CLI. These libraries will live along side the respective servers (so nova's python-novaclient will live in Compute)? All while moving OpenStackClient to the new libraries Is that what you are proposing? My understanding is that the SDK aims to be a ground-up replacement for the existing disparate client libraries. Whether that replacement is appropriate for use inside OpenStack may be up for debate (I think I remember someone saying that wasn't necessarily a goal, with the focus being on end users, but I haven't been able to attend many of the meetings so my information may be out of date). In the case you'd absorb the Python client libraries, it might make sense to ship the keystone middleware in a separate package that would still live in the Identity program. This needs to happen anyway, it's time for my semi-annual request to dolphm... I think we need people caring for the end user and their experience of interacting with an OpenStack-backed cloud. I understand that CLI/SDK specialists and GUI-oriented specialists are different crowds, but they share the same objective and would benefit IMHO from being in the same program. There could be two subteams to care for specialists in both areas (or even 3 if you separate the CLI and SDK folks). Overall from the TC perspective it would make a much stronger proposal if you somehow could present a united (and without overlap) proposal. To be honest, until the most recent ML thread I hadn't thought about the UX team or even if they were active. We have three basic categories of projects delivering code: web UI (Horizon), CLI (OpenStackClient) and SDK (at least three active language-based teams). They all should consume the output from a UX RD effort, I guess I am open on the program structure to make that work. Horizon is already a part of a program, OSC needs to be and the SDKs will also need to be in the near future. dt -- Dean Troyer dtro...@gmail.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Programs] Client Tools program discussion
On Wed, May 7, 2014 at 7:38 AM, Doug Hellmann doug.hellm...@dreamhost.com wrote: On Tue, May 6, 2014 at 5:45 PM, Joe Gordon joe.gord...@gmail.com wrote: On Tue, May 6, 2014 at 6:54 AM, Dean Troyer dtro...@gmail.com wrote: On Tue, May 6, 2014 at 7:02 AM, Thierry Carrez thie...@openstack.org wrote: Would you take over the Python client libraries as well ? On one hand they need /some/ domain expertise, but on the other I see no reason to special-case Python against other SDKs, and that may give the libraries a bit more attention and convergence (they currently are the ugly stepchild in some programs, and vary a lot). The future of the existing client libs has not been settled, my working assumption is that they would remain with their home programs as they are now. From the start OpenStackClient was meant to be a clean-slate for the CLI and the Python SDK is taking the same basic approach. Very excited for the OpenStackClient, it is already way nicer then the existing clients. Just working this out in my head. So the work flow would be: 1. At first ClientTools consist of just the OpenStackClient 2. When the pythonSDK is ready to move off of stackforge, it will live in ClientTools 3. Specific python-*clients will be rewritten (from scratch?) to use the PythonSDK. But this time they won't have a built in CLI. These libraries will live along side the respective servers (so nova's python-novaclient will live in Compute)? All while moving OpenStackClient to the new libraries Is that what you are proposing? My understanding is that the SDK aims to be a ground-up replacement for the existing disparate client libraries. Whether that replacement is appropriate for use inside OpenStack may be up for debate (I think I remember someone saying that wasn't necessarily a goal, with the focus being on end users, but I haven't been able to attend many of the meetings so my information may be out of date). Ideally the python-openstacksdk becomes the one-stop shop for interacting with OpenStack as an OpenStack contributor, an operator, an end-user of an OpenStack cloud, etc. If you're writing Python code to work with OpenStack, that would be the place to go for code, tools, examples, and documentation. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Programs] Client Tools program discussion
On Apr 28, 2014, at 8:20 AM, Dean Troyer dtro...@gmail.commailto:dtro...@gmail.com wrote: I want to open the discussion of an OpenStack Client Tools program proposal to a wider audience. It would initially consist of OpenStackClient and eventually add the existing SDK projects as they are ready to join. The initial wiki page is at https://wiki.openstack.org/wiki/ClientTools. I do want to have the proposal made before the summit, but not necessarily the TC consideration. There has recently been some discussion (specifically around summit sessions) regarding the overlap of client code and the user experience team. This is one of the things I want to get some feedback on before making a formal proposal. The mission statement and description are written with the anticipation of one or more SDK projects joining the program during the Juno cycle. Hi Dean, This is great. We’ve been working towards providing a better developer experience (DX) in OpenStack over the past few Summits. To give you some background there have been design summit sessions like the SDK Discussion [1] [2] and Documenting Application Developer Resources [3] [4] as well as summit sessions like The OpenStack Community Welcomes Developers in All Languages [5]. We’ve also got some summit sessions for Juno in You Sir, Sir Vey [6] and Focusing on Developer Experience and Announcing developer.openstack.orghttp://developer.openstack.org [7]. We would definitely like to discuss your proposal and join together for a DX related program, whether that’s part of a larger DX/UX program or not. I think calling it just “Client Tools” is too limiting because it’s about more than just tools. Considering how close we are to the summit, is there a time/place/particular session where you’d like to discuss it? Thanks, Everett [1] http://openstacksummitfall2012.sched.org/event/2215363b1716a519e786e126b493e3a3 [2] https://etherpad.openstack.org/p/sdk-documentation [3] http://icehousedesignsummit.sched.org/event/d5ad5bd83247868ff07b59ea4384b307 [4] https://etherpad.openstack.org/p/icehouse-doc-app-devs [5] http://openstacksummitnovember2013.sched.org/event/41b333a6736a92f4056246719deec1fc [6] http://openstacksummitmay2014atlanta.sched.org/event/f2675464b7624775f9f0accb78e34259 [7] http://openstacksummitmay2014atlanta.sched.org/event/f1ee610553f3c64296eb1f82ae6bf73d ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Programs] Client Tools program discussion
On Wed, May 7, 2014 at 8:32 AM, Brian Curtin br...@python.org wrote: On Wed, May 7, 2014 at 7:38 AM, Doug Hellmann doug.hellm...@dreamhost.com wrote: On Tue, May 6, 2014 at 5:45 PM, Joe Gordon joe.gord...@gmail.com wrote: On Tue, May 6, 2014 at 6:54 AM, Dean Troyer dtro...@gmail.com wrote: On Tue, May 6, 2014 at 7:02 AM, Thierry Carrez thie...@openstack.org wrote: Would you take over the Python client libraries as well ? On one hand they need /some/ domain expertise, but on the other I see no reason to special-case Python against other SDKs, and that may give the libraries a bit more attention and convergence (they currently are the ugly stepchild in some programs, and vary a lot). The future of the existing client libs has not been settled, my working assumption is that they would remain with their home programs as they are now. From the start OpenStackClient was meant to be a clean-slate for the CLI and the Python SDK is taking the same basic approach. Very excited for the OpenStackClient, it is already way nicer then the existing clients. Just working this out in my head. So the work flow would be: 1. At first ClientTools consist of just the OpenStackClient 2. When the pythonSDK is ready to move off of stackforge, it will live in ClientTools 3. Specific python-*clients will be rewritten (from scratch?) to use the PythonSDK. But this time they won't have a built in CLI. These libraries will live along side the respective servers (so nova's python-novaclient will live in Compute)? All while moving OpenStackClient to the new libraries Is that what you are proposing? My understanding is that the SDK aims to be a ground-up replacement for the existing disparate client libraries. Whether that replacement is appropriate for use inside OpenStack may be up for debate (I think I remember someone saying that wasn't necessarily a goal, with the focus being on end users, but I haven't been able to attend many of the meetings so my information may be out of date). Ideally the python-openstacksdk becomes the one-stop shop for interacting with OpenStack as an OpenStack contributor, an operator, an end-user of an OpenStack cloud, etc. If you're writing Python code to work with OpenStack, that would be the place to go for code, tools, examples, and documentation. Cool, that is even better. So then step 3 would be: * Each project can continue maintaining there existing python-*client or just deprecate it in favor of the what ClientTools will have. If so that sounds great. Would client tools be limited to only a pythonSDK or in the future could it potentially have other languages? ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Programs] Client Tools program discussion
On Wed, May 7, 2014 at 5:05 PM, Joe Gordon joe.gord...@gmail.com wrote: Would client tools be limited to only a pythonSDK or in the future could it potentially have other languages? There are a handful of other language projects active on Stackforge that have expressed interest in joining the program when they reach some state of maturity. That is a big part of the reason for structuring things the way we have. If any were ready today they would be included in the initial proposal. https://git.openstack.org/cgit/stackforge/python-openstacksdkhttps://github.com/stackforge/python-openstacksdk https://git.openstack.org/cgit/stackforge/openstack-sdk-php/http://git.openstack.org/cgit/stackforge/openstack-sdk-php/ https://git.openstack.org/cgit/stackforge/openstack-sdk-dotnet/http://git.openstack.org/cgit/stackforge/openstack-sdk-dotnet/ https://git.openstack.org/cgit/stackforge/golang-client/http://git.openstack.org/cgit/stackforge/golang-client/ https://git.openstack.org/cgit/stackforge/openstack-cli-powershell/http://git.openstack.org/cgit/stackforge/openstack-cli-powershell/ dt -- Dean Troyer dtro...@gmail.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Programs] Client Tools program discussion
On Wed, May 7, 2014 at 3:33 PM, Dean Troyer dtro...@gmail.com wrote: On Wed, May 7, 2014 at 5:05 PM, Joe Gordon joe.gord...@gmail.com wrote: Would client tools be limited to only a pythonSDK or in the future could it potentially have other languages? There are a handful of other language projects active on Stackforge that have expressed interest in joining the program when they reach some state of maturity. That is a big part of the reason for structuring things the way we have. If any were ready today they would be included in the initial proposal. https://git.openstack.org/cgit/stackforge/python-openstacksdkhttps://github.com/stackforge/python-openstacksdk https://git.openstack.org/cgit/stackforge/openstack-sdk-php/http://git.openstack.org/cgit/stackforge/openstack-sdk-php/ https://git.openstack.org/cgit/stackforge/openstack-sdk-dotnet/http://git.openstack.org/cgit/stackforge/openstack-sdk-dotnet/ https://git.openstack.org/cgit/stackforge/golang-client/http://git.openstack.org/cgit/stackforge/golang-client/ https://git.openstack.org/cgit/stackforge/openstack-cli-powershell/http://git.openstack.org/cgit/stackforge/openstack-cli-powershell/ Awesome. Thanks for all the clarifications. I for one welcome the our new ClientTools overloard. dt -- Dean Troyer dtro...@gmail.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Programs] Client Tools program discussion
Dean Troyer wrote: I want to open the discussion of an OpenStack Client Tools program proposal to a wider audience. It would initially consist of OpenStackClient and eventually add the existing SDK projects as they are ready to join. The initial wiki page is at https://wiki.openstack.org/wiki/ClientTools. I do want to have the proposal made before the summit, but not necessarily the TC consideration. Would you take over the Python client libraries as well ? On one hand they need /some/ domain expertise, but on the other I see no reason to special-case Python against other SDKs, and that may give the libraries a bit more attention and convergence (they currently are the ugly stepchild in some programs, and vary a lot). In the case you'd absorb the Python client libraries, it might make sense to ship the keystone middleware in a separate package that would still live in the Identity program. There has recently been some discussion (specifically around summit sessions) regarding the overlap of client code and the user experience team. This is one of the things I want to get some feedback on before making a formal proposal. I think we need people caring for the end user and their experience of interacting with an OpenStack-backed cloud. I understand that CLI/SDK specialists and GUI-oriented specialists are different crowds, but they share the same objective and would benefit IMHO from being in the same program. There could be two subteams to care for specialists in both areas (or even 3 if you separate the CLI and SDK folks). Overall from the TC perspective it would make a much stronger proposal if you somehow could present a united (and without overlap) proposal. -- Thierry Carrez (ttx) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Programs] Client Tools program discussion
On Tue, May 6, 2014 at 7:02 AM, Thierry Carrez thie...@openstack.orgwrote: Dean Troyer wrote: I want to open the discussion of an OpenStack Client Tools program proposal to a wider audience. It would initially consist of OpenStackClient and eventually add the existing SDK projects as they are ready to join. The initial wiki page is at https://wiki.openstack.org/wiki/ClientTools. I do want to have the proposal made before the summit, but not necessarily the TC consideration. Would you take over the Python client libraries as well ? On one hand they need /some/ domain expertise, but on the other I see no reason to special-case Python against other SDKs, and that may give the libraries a bit more attention and convergence (they currently are the ugly stepchild in some programs, and vary a lot). In the case you'd absorb the Python client libraries, it might make sense to ship the keystone middleware in a separate package that would still live in the Identity program. There has recently been some discussion (specifically around summit sessions) regarding the overlap of client code and the user experience team. This is one of the things I want to get some feedback on before making a formal proposal. I think we need people caring for the end user and their experience of interacting with an OpenStack-backed cloud. I understand that CLI/SDK specialists and GUI-oriented specialists are different crowds, but they share the same objective and would benefit IMHO from being in the same program. There could be two subteams to care for specialists in both areas (or even 3 if you separate the CLI and SDK folks). Overall from the TC perspective it would make a much stronger proposal if you somehow could present a united (and without overlap) proposal. I believe that UX and DevEx are different areas of expertise and OpenStack could benefit more from a separate focused DevEx program. I'm not sure Dean's proposal is quite DevEx though, and I don't know if a rename alone would take care of what I think it is. - SDK maintenance and testing - App-dev focus on docs - Focus on improving automation tasks with unified CLI - Processes and governance that could be separate from contrib devs - Releases separate from the every six month timed release in order to serve app devs better with quicker turnaround (similar to the CLIs now) - Integrated client with the goal of eliminating the client-per-project mess Dean, what do you think of these ideas? Is there enough in common with the CLI user and app dev to consider this DevEx umbrella the program? Do you plan to get rid of project-clients, and does it make sense to do so? Also how do you plan to transition away from DevStack PTL role, have you found a replacement? Thanks for asking early, sure saves that Summit energy for me, Anne -- Thierry Carrez (ttx) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Programs] Client Tools program discussion
On Tue, May 6, 2014 at 8:02 AM, Thierry Carrez thie...@openstack.org wrote: Dean Troyer wrote: I want to open the discussion of an OpenStack Client Tools program proposal to a wider audience. It would initially consist of OpenStackClient and eventually add the existing SDK projects as they are ready to join. The initial wiki page is at https://wiki.openstack.org/wiki/ClientTools. I do want to have the proposal made before the summit, but not necessarily the TC consideration. I've been looking forward to this day for a long time! :-) Would you take over the Python client libraries as well ? On one hand they need /some/ domain expertise, but on the other I see no reason to special-case Python against other SDKs, and that may give the libraries a bit more attention and convergence (they currently are the ugly stepchild in some programs, and vary a lot). If I understand the mission of the new Python SDK team, they plan to build a new library with more consistency that may eventually replace the project-specific libraries. (Maybe someone on that team can check my facts there?) If that's correct, then it could make sense for that SDK project to fold into a client tools program when it reaches some definition of done. In the case you'd absorb the Python client libraries, it might make sense to ship the keystone middleware in a separate package that would still live in the Identity program. +1 -- Every consumer of the middleware needs a keystone client, but not every keystone client user needs the middleware and its dependencies. There has recently been some discussion (specifically around summit sessions) regarding the overlap of client code and the user experience team. This is one of the things I want to get some feedback on before making a formal proposal. I think we need people caring for the end user and their experience of interacting with an OpenStack-backed cloud. I understand that CLI/SDK specialists and GUI-oriented specialists are different crowds, but they share the same objective and would benefit IMHO from being in the same program. There could be two subteams to care for specialists in both areas (or even 3 if you separate the CLI and SDK folks). Overall from the TC perspective it would make a much stronger proposal if you somehow could present a united (and without overlap) proposal. If we intend to have official SDKs in multiple languages, we'll likely have multiple teams working on those as well. The model emerging in Oslo, based on similar sub-team models in Nova and Neutron, is to allow a separate lead and review team for each new library, with oslo-core participating in all repos/projects. A similar model seems like it would fit well here, too. Doug -- Thierry Carrez (ttx) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Programs] Client Tools program discussion
On Tue, May 6, 2014 at 7:02 AM, Thierry Carrez thie...@openstack.orgwrote: Would you take over the Python client libraries as well ? On one hand they need /some/ domain expertise, but on the other I see no reason to special-case Python against other SDKs, and that may give the libraries a bit more attention and convergence (they currently are the ugly stepchild in some programs, and vary a lot). The future of the existing client libs has not been settled, my working assumption is that they would remain with their home programs as they are now. From the start OpenStackClient was meant to be a clean-slate for the CLI and the Python SDK is taking the same basic approach. In the case you'd absorb the Python client libraries, it might make sense to ship the keystone middleware in a separate package that would still live in the Identity program. This needs to happen anyway, it's time for my semi-annual request to dolphm... I think we need people caring for the end user and their experience of interacting with an OpenStack-backed cloud. I understand that CLI/SDK specialists and GUI-oriented specialists are different crowds, but they share the same objective and would benefit IMHO from being in the same program. There could be two subteams to care for specialists in both areas (or even 3 if you separate the CLI and SDK folks). Overall from the TC perspective it would make a much stronger proposal if you somehow could present a united (and without overlap) proposal. To be honest, until the most recent ML thread I hadn't thought about the UX team or even if they were active. We have three basic categories of projects delivering code: web UI (Horizon), CLI (OpenStackClient) and SDK (at least three active language-based teams). They all should consume the output from a UX RD effort, I guess I am open on the program structure to make that work. Horizon is already a part of a program, OSC needs to be and the SDKs will also need to be in the near future. dt -- Dean Troyer dtro...@gmail.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Programs] Client Tools program discussion
On Tue, May 6, 2014 at 8:38 AM, Doug Hellmann doug.hellm...@dreamhost.com wrote: On Tue, May 6, 2014 at 8:02 AM, Thierry Carrez thie...@openstack.org wrote: Dean Troyer wrote: I want to open the discussion of an OpenStack Client Tools program proposal to a wider audience. It would initially consist of OpenStackClient and eventually add the existing SDK projects as they are ready to join. The initial wiki page is at https://wiki.openstack.org/wiki/ClientTools. I do want to have the proposal made before the summit, but not necessarily the TC consideration. I've been looking forward to this day for a long time! :-) Would you take over the Python client libraries as well ? On one hand they need /some/ domain expertise, but on the other I see no reason to special-case Python against other SDKs, and that may give the libraries a bit more attention and convergence (they currently are the ugly stepchild in some programs, and vary a lot). If I understand the mission of the new Python SDK team, they plan to build a new library with more consistency that may eventually replace the project-specific libraries. (Maybe someone on that team can check my facts there?) If that's correct, then it could make sense for that SDK project to fold into a client tools program when it reaches some definition of done. Yep. Dean and I talked very briefly about this maybe a month ago, and the python-openstacksdk would fall under this at some point in the future. The same would likely be true for other similar projects, e.g., the PHP SDK that is also under way. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Programs] Client Tools program discussion
On Tue, May 6, 2014 at 7:38 AM, Anne Gentle a...@openstack.org wrote: I believe that UX and DevEx are different areas of expertise and OpenStack could benefit more from a separate focused DevEx program Agreed. I'm not sure Dean's proposal is quite DevEx though, and I don't know if a rename alone would take care of what I think it is. - SDK maintenance and testing - App-dev focus on docs - Focus on improving automation tasks with unified CLI - Processes and governance that could be separate from contrib devs - Releases separate from the every six month timed release in order to serve app devs better with quicker turnaround (similar to the CLIs now) - Integrated client with the goal of eliminating the client-per-project mess Dean, what do you think of these ideas? Is there enough in common with the CLI user and app dev to consider this DevEx umbrella the program? Do you plan to get rid of project-clients, and does it make sense to do so? Also how do you plan to transition away from DevStack PTL role, have you found a replacement? Anne, this is why you are a writer and I am not. ;) I may steal that list... What you have listed fits with what I see happening as the Client Tools adds the SDK projects (#1 and 2). #3, 5 and 6 are already goals for OSC[1]; and #4 is what we are here talking about now. [1] I expect OSC to switch to use the Python OpenStack SDK as it becomes ready rather than attempt to salvage the existing client libs. dt -- Dean Troyer dtro...@gmail.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Programs] Client Tools program discussion
On Tue, May 6, 2014 at 9:54 AM, Dean Troyer dtro...@gmail.com wrote: On Tue, May 6, 2014 at 7:02 AM, Thierry Carrez thie...@openstack.org wrote: Would you take over the Python client libraries as well ? On one hand they need /some/ domain expertise, but on the other I see no reason to special-case Python against other SDKs, and that may give the libraries a bit more attention and convergence (they currently are the ugly stepchild in some programs, and vary a lot). The future of the existing client libs has not been settled, my working assumption is that they would remain with their home programs as they are now. From the start OpenStackClient was meant to be a clean-slate for the CLI and the Python SDK is taking the same basic approach. In the case you'd absorb the Python client libraries, it might make sense to ship the keystone middleware in a separate package that would still live in the Identity program. This needs to happen anyway, it's time for my semi-annual request to dolphm... Oslo has a nice shiny script that can be modified to extract the history of whichever part you want to export into a separate library. Right now it assumes you're making an oslo lib, but that part should be easy to strip out. See http://git.openstack.org/cgit/openstack/oslo-incubator/tree/tools/graduate.sh I think we need people caring for the end user and their experience of interacting with an OpenStack-backed cloud. I understand that CLI/SDK specialists and GUI-oriented specialists are different crowds, but they share the same objective and would benefit IMHO from being in the same program. There could be two subteams to care for specialists in both areas (or even 3 if you separate the CLI and SDK folks). Overall from the TC perspective it would make a much stronger proposal if you somehow could present a united (and without overlap) proposal. To be honest, until the most recent ML thread I hadn't thought about the UX team or even if they were active. We have three basic categories of projects delivering code: web UI (Horizon), CLI (OpenStackClient) and SDK (at least three active language-based teams). They all should consume the output from a UX RD effort, I guess I am open on the program structure to make that work. Horizon is already a part of a program, OSC needs to be and the SDKs will also need to be in the near future. dt -- Dean Troyer dtro...@gmail.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Programs] Client Tools program discussion
On Tue, May 6, 2014 at 6:54 AM, Dean Troyer dtro...@gmail.com wrote: On Tue, May 6, 2014 at 7:02 AM, Thierry Carrez thie...@openstack.orgwrote: Would you take over the Python client libraries as well ? On one hand they need /some/ domain expertise, but on the other I see no reason to special-case Python against other SDKs, and that may give the libraries a bit more attention and convergence (they currently are the ugly stepchild in some programs, and vary a lot). The future of the existing client libs has not been settled, my working assumption is that they would remain with their home programs as they are now. From the start OpenStackClient was meant to be a clean-slate for the CLI and the Python SDK is taking the same basic approach. Very excited for the OpenStackClient, it is already way nicer then the existing clients. Just working this out in my head. So the work flow would be: 1. At first ClientTools consist of just the OpenStackClient 2. When the pythonSDK is ready to move off of stackforge, it will live in ClientTools 3. Specific python-*clients will be rewritten (from scratch?) to use the PythonSDK. But this time they won't have a built in CLI. These libraries will live along side the respective servers (so nova's python-novaclient will live in Compute)? All while moving OpenStackClient to the new libraries Is that what you are proposing? In the case you'd absorb the Python client libraries, it might make sense to ship the keystone middleware in a separate package that would still live in the Identity program. This needs to happen anyway, it's time for my semi-annual request to dolphm... I think we need people caring for the end user and their experience of interacting with an OpenStack-backed cloud. I understand that CLI/SDK specialists and GUI-oriented specialists are different crowds, but they share the same objective and would benefit IMHO from being in the same program. There could be two subteams to care for specialists in both areas (or even 3 if you separate the CLI and SDK folks). Overall from the TC perspective it would make a much stronger proposal if you somehow could present a united (and without overlap) proposal. To be honest, until the most recent ML thread I hadn't thought about the UX team or even if they were active. We have three basic categories of projects delivering code: web UI (Horizon), CLI (OpenStackClient) and SDK (at least three active language-based teams). They all should consume the output from a UX RD effort, I guess I am open on the program structure to make that work. Horizon is already a part of a program, OSC needs to be and the SDKs will also need to be in the near future. dt -- Dean Troyer dtro...@gmail.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Programs] Client Tools program discussion
On Tue, May 6, 2014 at 4:45 PM, Joe Gordon joe.gord...@gmail.com wrote: 1. At first ClientTools consist of just the OpenStackClient 2. When the pythonSDK is ready to move off of stackforge, it will live in ClientTools Yes to both of these 3. Specific python-*clients will be rewritten (from scratch?) to use the PythonSDK. But this time they won't have a built in CLI. These libraries will live along side the respective servers (so nova's python-novaclient will live in Compute)? All while moving OpenStackClient to the new libraries I have no plans for the existing client libs. If it makes sense to consolidate them in Client Tools that is fine with me. Historically there has been pushback on suggestions of that sort so I have not included them here. OSC will use the SDK when it becomes viable to do so. No matter where the existing clients fit organizationally, I see their future use diminishing over time. dt -- Dean Troyer dtro...@gmail.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Programs] Client Tools program discussion
I want to open the discussion of an OpenStack Client Tools program proposal to a wider audience. It would initially consist of OpenStackClient and eventually add the existing SDK projects as they are ready to join. The initial wiki page is at https://wiki.openstack.org/wiki/ClientTools. I do want to have the proposal made before the summit, but not necessarily the TC consideration. There has recently been some discussion (specifically around summit sessions) regarding the overlap of client code and the user experience team. This is one of the things I want to get some feedback on before making a formal proposal. The mission statement and description are written with the anticipation of one or more SDK projects joining the program during the Juno cycle. dt Mission Statement The OpenStack Client Tools mission is to provide clean and consistent interfaces to OpenStack services via the published REST APIs. The intended audiences are command-line users (OpenStackClient) and application developers (SDKs as they join the program). Description The OpenStack Client Tools program encompasses a number of related projects that have both common contributors and common consumer interests regarding OpenStack services. The existing OpenStackClient project is targeted at command-line users: end-users as well as cloud operators, devops, system administrators or anyone needing a shell interface to OpenStack. The SDK projects (expected to join the program as they mature) implement bindings to the OpenStack REST APIs in multiple languages. Deliverables Releases for the Client Tools projects are on an independent schedule from the OpenStack integrated release just as the existing client CLI/libraries do today. - OpenStackClient delivers an integrated CLI as a PyPI package and the usual OpenStack tarballs. -- Dean Troyer dtro...@gmail.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
