Re: [openstack-dev] [TripleO] Tuskar CLI UX
On 02/27/2014 04:30 PM, Dougal Matthews wrote: On 27/02/14 15:08, Ladislav Smola wrote: Hello, I think if we will use Openstack CLI, it has to be something like this https://github.com/dtroyer/python-oscplugin. Otherwise we are not Openstack on Openstack. Btw. abstracting it all to one big CLI will be just more confusing when people will debug issues. So it would have to be done very good. E.g calling 'openstack-client net-create' fails. Where do you find error log? Are you using nova-networking or Neutron? I would at least expect the debug/log of the tuskar client to show what calls its making on other clients so following this trail wouldn't be too hard. Well sure, this is part of 'being done very good'. Though a lot of calls makes some asynchronous jobs, that can result in errors you will just not see when you call the clients. So you will need to know where to look depending on what is acting weird. What I am trying to say is, the Openstack is just complex, there is no way around, sysadmins just need to understand, what they are doing. If we are going to simplify that, we would need to build something like we have in UI. So some abstraction layer that leads the user and won't let him break it. Though this leads to limited functionality we are able to control. Which I am not entirely convinced is what CLI users want. ___ 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] [TripleO] Tuskar CLI UX
On 02/27/2014 05:02 PM, Ana Krivokapic wrote: On 02/27/2014 04:41 PM, Tzu-Mainn Chen wrote: Hello, I think if we will use Openstack CLI, it has to be something like this https://github.com/dtroyer/python-oscplugin. Otherwise we are not Openstack on Openstack. Btw. abstracting it all to one big CLI will be just more confusing when people will debug issues. So it would have to be done very good. E.g calling 'openstack-client net-create' fails. Where do you find error log? Are you using nova-networking or Neutron? .. Calli 'neutron net-create' and you just know. Btw. who would actually hire a sysadmin that will start to use CLI and have no idea what is he doing? They need to know what each service do, how to correctly use them and how do debug it when something is wrong. For flavors just use flavors, we call them flavors in code too. It has just nicer face in UI. Actually, don't we called them node_profiles in the UI code? We do: https://github.com/openstack/tuskar-ui/tree/master/tuskar_ui/infrastructure/node_profiles Personally, I'd much prefer that we call them flavors in the code. I agree, keeping the name "flavor" makes perfect sense here, IMO. The only benefit of using "node profile" seems to be that it is more descriptive. However, as already mentioned, admins are well used to the name "flavor". It seems to me that this change introduces more confusion than it serves to clear things up. In other words, it brings more harm than good. I see, we have brought an API flavor wrapper https://github.com/openstack/tuskar-ui/blob/master/tuskar_ui/api.py#L91 Nevertheless keeping 'flavor' make sense. Mainn ___ 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] [TripleO] Tuskar CLI UX
On 27/02/14 15:08, Ladislav Smola wrote: Hello, I think if we will use Openstack CLI, it has to be something like this https://github.com/dtroyer/python-oscplugin. Otherwise we are not Openstack on Openstack. Btw. abstracting it all to one big CLI will be just more confusing when people will debug issues. So it would have to be done very good. E.g calling 'openstack-client net-create' fails. Where do you find error log? Are you using nova-networking or Neutron? I would at least expect the debug/log of the tuskar client to show what calls its making on other clients so following this trail wouldn't be too hard. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] Tuskar CLI UX
On 02/27/2014 04:41 PM, Tzu-Mainn Chen wrote: Hello, I think if we will use Openstack CLI, it has to be something like this https://github.com/dtroyer/python-oscplugin. Otherwise we are not Openstack on Openstack. Btw. abstracting it all to one big CLI will be just more confusing when people will debug issues. So it would have to be done very good. E.g calling 'openstack-client net-create' fails. Where do you find error log? Are you using nova-networking or Neutron? .. Calli 'neutron net-create' and you just know. Btw. who would actually hire a sysadmin that will start to use CLI and have no idea what is he doing? They need to know what each service do, how to correctly use them and how do debug it when something is wrong. For flavors just use flavors, we call them flavors in code too. It has just nicer face in UI. Actually, don't we called them node_profiles in the UI code? We do: https://github.com/openstack/tuskar-ui/tree/master/tuskar_ui/infrastructure/node_profiles Personally, I'd much prefer that we call them flavors in the code. I agree, keeping the name "flavor" makes perfect sense here, IMO. The only benefit of using "node profile" seems to be that it is more descriptive. However, as already mentioned, admins are well used to the name "flavor". It seems to me that this change introduces more confusion than it serves to clear things up. In other words, it brings more harm than good. Mainn ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Regards, Ana Krivokapic Associate Software Engineer OpenStack team Red Hat Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] Tuskar CLI UX
> Hello, > > I think if we will use Openstack CLI, it has to be something like this > https://github.com/dtroyer/python-oscplugin. > Otherwise we are not Openstack on Openstack. > > Btw. abstracting it all to one big CLI will be just more confusing when > people will debug issues. So it would > have to be done very good. > > E.g calling 'openstack-client net-create' fails. > Where do you find error log? > Are you using nova-networking or Neutron? > .. > > Calli 'neutron net-create' and you just know. > > Btw. who would actually hire a sysadmin that will start to use CLI and > have no > idea what is he doing? They need to know what each service do, how to > correctly > use them and how do debug it when something is wrong. > > > For flavors just use flavors, we call them flavors in code too. It has > just nicer face in UI. Actually, don't we called them node_profiles in the UI code? Personally, I'd much prefer that we call them flavors in the code. Mainn ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] Tuskar CLI UX
Hello, I think if we will use Openstack CLI, it has to be something like this https://github.com/dtroyer/python-oscplugin. Otherwise we are not Openstack on Openstack. Btw. abstracting it all to one big CLI will be just more confusing when people will debug issues. So it would have to be done very good. E.g calling 'openstack-client net-create' fails. Where do you find error log? Are you using nova-networking or Neutron? .. Calli 'neutron net-create' and you just know. Btw. who would actually hire a sysadmin that will start to use CLI and have no idea what is he doing? They need to know what each service do, how to correctly use them and how do debug it when something is wrong. For flavors just use flavors, we call them flavors in code too. It has just nicer face in UI. Kind regards, Ladislav On 02/26/2014 02:34 PM, Jiří Stránský wrote: Hello, i went through the CLI way of deploying overcloud, so if you're interested what's the workflow, here it is: https://gist.github.com/jistr/9228638 I'd say it's still an open question whether we'll want to give better UX than that ^^ and at what cost (this is very much tied to the benefits and drawbacks of various solutions we discussed in December [1]). All in all it's not as bad as i expected it to be back then [1]. The fact that we keep Tuskar API as a layer in front of Heat means that CLI user doesn't care about calling merge.py and creating Heat stack manually, which is great. In general the CLI workflow is on the same conceptual level as Tuskar UI, so that's fine, we just need to use more commands than "tuskar". There's one naming mismatch though -- Tuskar UI doesn't use Horizon's Flavor management, but implements its own and calls it Node Profiles. I'm a bit hesitant to do the same thing on CLI -- the most obvious option would be to make python-tuskarclient depend on python-novaclient and use a renamed Flavor management CLI. But that's wrong and high cost given that it's only about naming :) The above issue is once again a manifestation of the fact that Tuskar UI, despite its name, is not a UI for Tuskar, it is UI for a bit more services. If this becomes a greater problem, or if we want a top-notch CLI experience despite reimplementing bits that can be already done (just not in a super-friendly way), we could start thinking about building something like OpenStackClient CLI [2], but directed specifically at Undercloud/Tuskar needs and using undercloud naming. Another option would be to get Tuskar UI a bit closer back to the fact that Undercloud is OpenStack too, and keep the name "Flavors" instead of changing it to "Node Profiles". I wonder if that would be unwelcome to the Tuskar UI UX, though. Jirka [1] http://lists.openstack.org/pipermail/openstack-dev/2013-December/021919.html [2] https://wiki.openstack.org/wiki/OpenStackClient ___ 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] [TripleO] Tuskar CLI UX
Yeah. This is a double bladed axe but i'm leaning towards naming flavors consistently a bit more too. Here's an attempt at +/- summary: "node profile" + a bit more descriptive for a newcomer imho - CLI renaming/reimplementing mentioned before - inconsistency dangers lurking in the deep - e.g. if an error message bubbles up from Nova all the way to the user, it might mention flavors, and if we talk 99% of time about node profiles, then user will not know what is meant in the error message. I'm a bit worried that we'll keep hitting things like this in the long run. While I agree with all of your points, this is the one that resonates with me the most. We won't be able to be 100% consistent with a rename (exceptions are a great example). It's already irritating to the user to have to see an error, having to then see it in terms they aren't familiar with is an added headache. - developers still often call them "flavors", because that's what Nova calls them "flavor" + fits with the rest, does not cause communication or development problems - not so descriptive (but i agree with you - OpenStack admins will already be familiar what "flavor" means in the overcloud, and i think they'd be able to infer what it means in the undercloud) I'm CCing Jarda as this affects his work quite a lot and i think he'll have some insight+opinion (he's on PTO now so it might take some time before he gets to this). One other thing, I've looked at my own examples so far, so I didn't really think about this but seeing it written down, I've realised the way we specify the roles in the Tuskar CLI really bugs me. --roles 1=1 \ --roles 2=1 I know what this means, but even reading it now I think: One equals one? Two equals one? What? I think we should probably change the arg name and also refer to roles by name. --role-count compute=10 and a shorter option -R compute=10 Yeah this is https://bugs.launchpad.net/tuskar/+bug/1281051 I agree with you on the solution (rename long option, support lookup by names, add a short option). Thanks Jirka ___ 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] [TripleO] Tuskar CLI UX
On Thu, Feb 27, 2014 at 6:36 AM, Jiří Stránský wrote: > Thanks for bringing this up. It looks really interesting. Is it possible > to not only add commands to the OpenStackClient, but also purposefully > blacklist some from appearing? As Jay mentioned in his reply, we don't make > use of many commands in the undercloud and having the others appear in > --help is just confusing. E.g. there's a lot of commands in Nova CLI that > we'll not use and we have no use for Cinder CLI at all. > I didn't consider removing other API's commands as a use case, it might work but whether that is a Good Thing is TBD from our/user's point of view. If you are trying to hide the rest of the APIs then this is not the CLI that you seek. OSC doesn't assume that a user has access to only one or one type of cloud, so disabling/removing commands simply based on package installation is not a good user experience. Everything after that requires authentication to get server API versions and a service catalog to know what a specific cloud offers. Even if we decided to build TripleO CLI separate from OpenStackClient, i > think being able to consume this plugin API would help us. We could plug in > the particular commands we want (and rename them if we want "node profiles" > instead of "flavors") and hopefully not reimplement everything. > The command names themselves are easy to change as they are just the key in the entry point key=value pair. Everything else about them, including the help text would be code changes. It sounds like you may be wanting something parallel to OSC, ie, a Tuskar-specific rebranding of it with a overlapping-but-different command set. 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] [TripleO] Tuskar CLI UX
On 26.2.2014 21:34, Dean Troyer wrote: On Wed, Feb 26, 2014 at 1:43 PM, Jay Dobies wrote: I like the notion of OpenStackClient. I'll talk ideals for a second. If we had a standard framework and each project provided a command abstraction that plugged in, we could pick and choose what we included under the Tuskar umbrella. Advanced users with particular needs could go directly to the project clients if needed. This is a thing. https://github.com/dtroyer/python-oscplugin is an example of a stand-alone OSC plugin that only needs to be installed to be recognized. FWIW, four of the built-in API command sets in OSC also are loaded in this manner even though they are in the OSC repo so they represent additional examples of writing plugins. Thanks for bringing this up. It looks really interesting. Is it possible to not only add commands to the OpenStackClient, but also purposefully blacklist some from appearing? As Jay mentioned in his reply, we don't make use of many commands in the undercloud and having the others appear in --help is just confusing. E.g. there's a lot of commands in Nova CLI that we'll not use and we have no use for Cinder CLI at all. Even if we decided to build TripleO CLI separate from OpenStackClient, i think being able to consume this plugin API would help us. We could plug in the particular commands we want (and rename them if we want "node profiles" instead of "flavors") and hopefully not reimplement everything. Thanks Jirka ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] Tuskar CLI UX
On 27.2.2014 10:16, Dougal Matthews wrote: On 26/02/14 13:34, Jiří Stránský wrote: get Tuskar UI a bit closer back to the fact that Undercloud is OpenStack too, and keep the name "Flavors" instead of changing it to "Node Profiles". I wonder if that would be unwelcome to the Tuskar UI UX, though. I can imagine we would constantly explain it by saying its the same as flavors because people will be familiar with this. So maybe being consistent would help. Yeah. This is a double bladed axe but i'm leaning towards naming flavors consistently a bit more too. Here's an attempt at +/- summary: "node profile" + a bit more descriptive for a newcomer imho - CLI renaming/reimplementing mentioned before - inconsistency dangers lurking in the deep - e.g. if an error message bubbles up from Nova all the way to the user, it might mention flavors, and if we talk 99% of time about node profiles, then user will not know what is meant in the error message. I'm a bit worried that we'll keep hitting things like this in the long run. - developers still often call them "flavors", because that's what Nova calls them "flavor" + fits with the rest, does not cause communication or development problems - not so descriptive (but i agree with you - OpenStack admins will already be familiar what "flavor" means in the overcloud, and i think they'd be able to infer what it means in the undercloud) I'm CCing Jarda as this affects his work quite a lot and i think he'll have some insight+opinion (he's on PTO now so it might take some time before he gets to this). One other thing, I've looked at my own examples so far, so I didn't really think about this but seeing it written down, I've realised the way we specify the roles in the Tuskar CLI really bugs me. --roles 1=1 \ --roles 2=1 I know what this means, but even reading it now I think: One equals one? Two equals one? What? I think we should probably change the arg name and also refer to roles by name. --role-count compute=10 and a shorter option -R compute=10 Yeah this is https://bugs.launchpad.net/tuskar/+bug/1281051 I agree with you on the solution (rename long option, support lookup by names, add a short option). Thanks Jirka ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] Tuskar CLI UX
On 26.2.2014 20:43, Jay Dobies wrote: I'd say it's still an open question whether we'll want to give better UX than that ^^ and at what cost (this is very much tied to the benefits and drawbacks of various solutions we discussed in December [1]). All in all it's not as bad as i expected it to be back then [1]. The fact that we keep Tuskar API as a layer in front of Heat means that CLI user doesn't care about calling merge.py and creating Heat stack manually, which is great. I agree that it's great that Heat is abstracted away. I also agree that it's not as bad as I too expected it to be. But generally speaking, I think it's not an ideal user experience. A few things jump out at me: * We currently have glance, nova, and tuskar represented. We'll likely need something to ceilometer as well for gathering metrics and configuring notifications (I assume the notifications will fall under that, but come with me on it). That's a lot for an end user to comprehend and remember, which concerns me for both adoption and long term usage. Even in the interim when a user remembers nova is related to node stuff, doing a --help on nova is huge. +1 That's going to put a lot of stress on our ability to document our prescribed path. It will be tricky for us to keep track of the relevant commands and still point to the other project client documentation so as to not duplicate it all. +1 * Even at this level, it exposes the underlying guts. There are calls to nova baremetal listed in there, but eventually those will turn into ironic calls. It doesn't give us a ton of flexibility in terms of underlying technology if that knowledge bubbles up to the end user that way. * This is a good view into what third-party integrators are going to face if they choose to skip our UIs and go directly to the REST APIs. I like the notion of OpenStackClient. I'll talk ideals for a second. If we had a standard framework and each project provided a command abstraction that plugged in, we could pick and choose what we included under the Tuskar umbrella. Advanced users with particular needs could go directly to the project clients if needed. I think this could go beyond usefulness for Tuskar as well. On a previous project, I wrote a pluggable client framework, allowing the end user to add their own commands that put a custom spin on what data was returned or how it was rendered. That's a level between being locked into what we decide the UX should be and having to go directly to the REST APIs themselves. That said, I know that's a huge undertaking to get OpenStack in general to buy into. I'll leave it more that I think it is a lesser UX (not even saying bad, just not great) to have so much for the end user to digest to attempt to even play with it. I'm more of the mentality of a unified TripleO CLI that would be catered towards handling TripleO stuffs. Short of OpenStackClient, I realize I'm not exactly in the majority here, but figured it didn't hurt to spell out my opinion :) Yeah i think having a unified TripleO CLI would be a great boost for the CLI user experience, and it would solve the problems we pointed out. It's another thing that we'd have to commit to maintain, but i hope CLI UX is enough priority that it should be fine to spend the dev time there. Thanks Jirka ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] Tuskar CLI UX
On 26/02/14 13:34, Jiří Stránský wrote: Hello, i went through the CLI way of deploying overcloud, so if you're interested what's the workflow, here it is: https://gist.github.com/jistr/9228638 This is great, thanks for taking the time to put it together. Another thing to add to my list of stuff to try :) I'd say it's still an open question whether we'll want to give better UX than that ^^ and at what cost (this is very much tied to the benefits and drawbacks of various solutions we discussed in December [1]). All in all it's not as bad as i expected it to be back then [1]. The fact that we keep Tuskar API as a layer in front of Heat means that CLI user doesn't care about calling merge.py and creating Heat stack manually, which is great. It does look pretty good, and also simpler than I expected. At the moment it seems we only really need to interact with glance, nova and tuskar. However, presumably this will only get more complicated over time which could become a problem. In general the CLI workflow is on the same conceptual level as Tuskar UI, so that's fine, we just need to use more commands than "tuskar". I wonder if this would become a documentation/support nightmare. get Tuskar UI a bit closer back to the fact that Undercloud is OpenStack too, and keep the name "Flavors" instead of changing it to "Node Profiles". I wonder if that would be unwelcome to the Tuskar UI UX, though. I can imagine we would constantly explain it by saying its the same as flavors because people will be familiar with this. So maybe being consistent would help. One other thing, I've looked at my own examples so far, so I didn't really think about this but seeing it written down, I've realised the way we specify the roles in the Tuskar CLI really bugs me. --roles 1=1 \ --roles 2=1 I know what this means, but even reading it now I think: One equals one? Two equals one? What? I think we should probably change the arg name and also refer to roles by name. --role-count compute=10 and a shorter option -R compute=10 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] Tuskar CLI UX
On 26/02/14 19:43, Jay Dobies wrote: * Even at this level, it exposes the underlying guts. There are calls to nova baremetal listed in there, but eventually those will turn into ironic calls. It doesn't give us a ton of flexibility in terms of underlying technology if that knowledge bubbles up to the end user that way. This is a good point, and it maybe highlights that when we don't abstract away these concepts it becomes much harder for us to make changes under the hood. Rather than handling that on our own we would need to provide "migration" steps for people to follow. * This is a good view into what third-party integrators are going to face if they choose to skip our UIs and go directly to the REST APIs. I like the notion of OpenStackClient. I'll talk ideals for a second. If we had a standard framework and each project provided a command abstraction that plugged in, we could pick and choose what we included under the Tuskar umbrella. Advanced users with particular needs could go directly to the project clients if needed. I think this could go beyond usefulness for Tuskar as well. On a previous project, I wrote a pluggable client framework, allowing the end user to add their own commands that put a custom spin on what data was returned or how it was rendered. That's a level between being locked into what we decide the UX should be and having to go directly to the REST APIs themselves. That said, I know that's a huge undertaking to get OpenStack in general to buy into. I'll leave it more that I think it is a lesser UX (not even saying bad, just not great) to have so much for the end user to digest to attempt to even play with it. I'm more of the mentality of a unified TripleO CLI that would be catered towards handling TripleO stuffs. Short of OpenStackClient, I realize I'm not exactly in the majority here, but figured it didn't hurt to spell out my opinion :) There is a renewed effort to create a unified client for OpenStack. I'm not sure if this exactly matches what your thinking but it may be worth checking out. I've only seen it in passing. They seem to be in the early stages but there is quite a bit of motivation/backing AFAICT. https://wiki.openstack.org/wiki/SDK-Development/PythonOpenStackSDK ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] Tuskar CLI UX
On Wed, Feb 26, 2014 at 1:43 PM, Jay Dobies wrote: > > I like the notion of OpenStackClient. I'll talk ideals for a second. If we > had a standard framework and each project provided a command abstraction > that plugged in, we could pick and choose what we included under the Tuskar > umbrella. Advanced users with particular needs could go directly to the > project clients if needed. > This is a thing. https://github.com/dtroyer/python-oscplugin is an example of a stand-alone OSC plugin that only needs to be installed to be recognized. FWIW, four of the built-in API command sets in OSC also are loaded in this manner even though they are in the OSC repo so they represent additional examples of writing plugins. 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] [TripleO] Tuskar CLI UX
Hello, i went through the CLI way of deploying overcloud, so if you're interested what's the workflow, here it is: https://gist.github.com/jistr/9228638 This is excellent to see it all laid out like this, thanks for writing it up. I'd say it's still an open question whether we'll want to give better UX than that ^^ and at what cost (this is very much tied to the benefits and drawbacks of various solutions we discussed in December [1]). All in all it's not as bad as i expected it to be back then [1]. The fact that we keep Tuskar API as a layer in front of Heat means that CLI user doesn't care about calling merge.py and creating Heat stack manually, which is great. I agree that it's great that Heat is abstracted away. I also agree that it's not as bad as I too expected it to be. But generally speaking, I think it's not an ideal user experience. A few things jump out at me: * We currently have glance, nova, and tuskar represented. We'll likely need something to ceilometer as well for gathering metrics and configuring notifications (I assume the notifications will fall under that, but come with me on it). That's a lot for an end user to comprehend and remember, which concerns me for both adoption and long term usage. Even in the interim when a user remembers nova is related to node stuff, doing a --help on nova is huge. That's going to put a lot of stress on our ability to document our prescribed path. It will be tricky for us to keep track of the relevant commands and still point to the other project client documentation so as to not duplicate it all. * Even at this level, it exposes the underlying guts. There are calls to nova baremetal listed in there, but eventually those will turn into ironic calls. It doesn't give us a ton of flexibility in terms of underlying technology if that knowledge bubbles up to the end user that way. * This is a good view into what third-party integrators are going to face if they choose to skip our UIs and go directly to the REST APIs. I like the notion of OpenStackClient. I'll talk ideals for a second. If we had a standard framework and each project provided a command abstraction that plugged in, we could pick and choose what we included under the Tuskar umbrella. Advanced users with particular needs could go directly to the project clients if needed. I think this could go beyond usefulness for Tuskar as well. On a previous project, I wrote a pluggable client framework, allowing the end user to add their own commands that put a custom spin on what data was returned or how it was rendered. That's a level between being locked into what we decide the UX should be and having to go directly to the REST APIs themselves. That said, I know that's a huge undertaking to get OpenStack in general to buy into. I'll leave it more that I think it is a lesser UX (not even saying bad, just not great) to have so much for the end user to digest to attempt to even play with it. I'm more of the mentality of a unified TripleO CLI that would be catered towards handling TripleO stuffs. Short of OpenStackClient, I realize I'm not exactly in the majority here, but figured it didn't hurt to spell out my opinion :) In general the CLI workflow is on the same conceptual level as Tuskar UI, so that's fine, we just need to use more commands than "tuskar". There's one naming mismatch though -- Tuskar UI doesn't use Horizon's Flavor management, but implements its own and calls it Node Profiles. I'm a bit hesitant to do the same thing on CLI -- the most obvious option would be to make python-tuskarclient depend on python-novaclient and use a renamed Flavor management CLI. But that's wrong and high cost given that it's only about naming :) The above issue is once again a manifestation of the fact that Tuskar UI, despite its name, is not a UI for Tuskar, it is UI for a bit more services. If this becomes a greater problem, or if we want a top-notch CLI experience despite reimplementing bits that can be already done (just not in a super-friendly way), we could start thinking about building something like OpenStackClient CLI [2], but directed specifically at Undercloud/Tuskar needs and using undercloud naming. Another option would be to get Tuskar UI a bit closer back to the fact that Undercloud is OpenStack too, and keep the name "Flavors" instead of changing it to "Node Profiles". I wonder if that would be unwelcome to the Tuskar UI UX, though. Jirka [1] http://lists.openstack.org/pipermail/openstack-dev/2013-December/021919.html [2] https://wiki.openstack.org/wiki/OpenStackClient ___ 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
