Re: [openstack-dev] [TripleO] [Tuskar] Terminology Revival #1 - Roles
I've spent some time thinking about this, and I have a clarification. I don't like the use of the word 'deployment', because it's not exact enough for me. Future plans for the tuskar-ui include management of the undercloud as well, and at that point, 'deployment role' becomes vague, as it could also logically apply to the undercloud. For that reason, I think we should call it an 'overcloud deployment role', or 'overcloud role' for short. That being said, I think that the UI could get away with just displaying 'Role', as presumably the user would be in a page with enough context to make it clear that he's in the overcloud section. Mainn - Original Message - I'd argue that we should call it 'overcloud role' - at least from the modeling point of view - since the tuskar-api calls a deployment an overcloud. But I like the general direction of the term-renaming! Mainn - Original Message - Based on this thread which didn't seem to get clear outcome, I have one last suggestion: * Deployment Role It looks that it might satisfy participants of this discussion. When I internally talked to people it got the best reactions from already suggested terms. Depending on your reactions for this suggestion, if we don't get to agreement of majority by the end of the week, I would call for voting starting next week. Thanks -- Jarda On 2014/21/01 15:19, Jaromir Coufal wrote: Hi folks, when I was getting feedback on wireframes and we talked about Roles, there were various objections and not much suggestions. I would love to call for action and think a bit about the term for concept currently known as Role (= Resource Category). Definition: Role is a representation of a group of nodes, with specific behavior. Each role contains (or will contain): * one or more Node Profiles (which specify HW which is going in) * association with image (which will be provisioned on new coming nodes) * specific service settings So far suggested terms: * Role * - short name - plus points - quite overloaded term (user role, etc) * Resource Category * - pretty long (devs already shorten it - confusing) - Heat specific term * Resource Class * - older term Are there any other suggestions (ideally something short and accurate)? Or do you prefer any of already suggested terms? Any ideas are welcome - we are not very good in finding the best match for this particular term. Thanks -- Jarda ___ 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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] [Tuskar] Terminology Revival #1 - Roles
I thought we were avoiding using overcloud and undercloud within the UI? -J On 01/28/2014 03:04 AM, Tzu-Mainn Chen wrote: I've spent some time thinking about this, and I have a clarification. I don't like the use of the word 'deployment', because it's not exact enough for me. Future plans for the tuskar-ui include management of the undercloud as well, and at that point, 'deployment role' becomes vague, as it could also logically apply to the undercloud. For that reason, I think we should call it an 'overcloud deployment role', or 'overcloud role' for short. That being said, I think that the UI could get away with just displaying 'Role', as presumably the user would be in a page with enough context to make it clear that he's in the overcloud section. Mainn - Original Message - I'd argue that we should call it 'overcloud role' - at least from the modeling point of view - since the tuskar-api calls a deployment an overcloud. But I like the general direction of the term-renaming! Mainn -- Jason E. Rist Senior Software Engineer OpenStack Management UI Red Hat, Inc. +1.919.754.4048 Freenode: jrist github/identi.ca: knowncitizen ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] [Tuskar] Terminology Revival #1 - Roles
Yep, although the reason why - that no end-user will know what these terms mean - has never been entirely convincing to me. But even if we don't use the word 'overcloud', I think we should use *something*. Deployment is just so vague that without some context, it could refer to anything. As a side note, the original terminology thread ended with a general upstream consensus that we should call things what they are in OpenStack. That's why the 'deployment' model is actually called 'overcloud' in the UI/api; others strongly favored using that term to make it clear to developers what we were modeling. Part of the difficulty here is the perception that developers and end-users have different needs when it comes to terminology. Mainn - Original Message - I thought we were avoiding using overcloud and undercloud within the UI? -J On 01/28/2014 03:04 AM, Tzu-Mainn Chen wrote: I've spent some time thinking about this, and I have a clarification. I don't like the use of the word 'deployment', because it's not exact enough for me. Future plans for the tuskar-ui include management of the undercloud as well, and at that point, 'deployment role' becomes vague, as it could also logically apply to the undercloud. For that reason, I think we should call it an 'overcloud deployment role', or 'overcloud role' for short. That being said, I think that the UI could get away with just displaying 'Role', as presumably the user would be in a page with enough context to make it clear that he's in the overcloud section. Mainn - Original Message - I'd argue that we should call it 'overcloud role' - at least from the modeling point of view - since the tuskar-api calls a deployment an overcloud. But I like the general direction of the term-renaming! Mainn -- Jason E. Rist Senior Software Engineer OpenStack Management UI Red Hat, Inc. +1.919.754.4048 Freenode: jrist github/identi.ca: knowncitizen ___ 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] Terminology Revival #1 - Roles
On Tue, 2014-01-28 at 10:02 -0500, Tzu-Mainn Chen wrote: Yep, although the reason why - that no end-user will know what these terms mean - has never been entirely convincing to me. Well, tenants would never see any of the Tuskar UI, so I don't think we need worry about them. And if a deployer is enabling Tuskar -- and using Tuskar/Triple-O for undercloud deployment -- then I would think that the deployer would understand the concept/terminology of undercloud and overcloud, since it's an essential concept in deploying with Triple-O. :) So, in short, I don't see a problem with using the terms undercloud and overcloud. Best, -jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] [Tuskar] Terminology Revival #1 - Roles
On 01/28/2014 11:42 AM, Jay Pipes wrote: On Tue, 2014-01-28 at 10:02 -0500, Tzu-Mainn Chen wrote: Yep, although the reason why - that no end-user will know what these terms mean - has never been entirely convincing to me. Well, tenants would never see any of the Tuskar UI, so I don't think we need worry about them. And if a deployer is enabling Tuskar -- and using Tuskar/Triple-O for undercloud deployment -- then I would think that the deployer would understand the concept/terminology of undercloud and overcloud, since it's an essential concept in deploying with Triple-O. :) So, in short, I don't see a problem with using the terms undercloud and overcloud. Best, -jay +1, I was going to say the same thing. Someone installing and using Tuskar will have to be sold on the concept of it, and I'm not sure how we'd describe what it does without using those terms. ___ 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] Terminology Revival #1 - Roles
Based on this thread which didn't seem to get clear outcome, I have one last suggestion: * Deployment Role It looks that it might satisfy participants of this discussion. When I internally talked to people it got the best reactions from already suggested terms. Depending on your reactions for this suggestion, if we don't get to agreement of majority by the end of the week, I would call for voting starting next week. Thanks -- Jarda On 2014/21/01 15:19, Jaromir Coufal wrote: Hi folks, when I was getting feedback on wireframes and we talked about Roles, there were various objections and not much suggestions. I would love to call for action and think a bit about the term for concept currently known as Role (= Resource Category). Definition: Role is a representation of a group of nodes, with specific behavior. Each role contains (or will contain): * one or more Node Profiles (which specify HW which is going in) * association with image (which will be provisioned on new coming nodes) * specific service settings So far suggested terms: * Role * - short name - plus points - quite overloaded term (user role, etc) * Resource Category * - pretty long (devs already shorten it - confusing) - Heat specific term * Resource Class * - older term Are there any other suggestions (ideally something short and accurate)? Or do you prefer any of already suggested terms? Any ideas are welcome - we are not very good in finding the best match for this particular term. Thanks -- Jarda ___ 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] Terminology Revival #1 - Roles
I'd argue that we should call it 'overcloud role' - at least from the modeling point of view - since the tuskar-api calls a deployment an overcloud. But I like the general direction of the term-renaming! Mainn - Original Message - Based on this thread which didn't seem to get clear outcome, I have one last suggestion: * Deployment Role It looks that it might satisfy participants of this discussion. When I internally talked to people it got the best reactions from already suggested terms. Depending on your reactions for this suggestion, if we don't get to agreement of majority by the end of the week, I would call for voting starting next week. Thanks -- Jarda On 2014/21/01 15:19, Jaromir Coufal wrote: Hi folks, when I was getting feedback on wireframes and we talked about Roles, there were various objections and not much suggestions. I would love to call for action and think a bit about the term for concept currently known as Role (= Resource Category). Definition: Role is a representation of a group of nodes, with specific behavior. Each role contains (or will contain): * one or more Node Profiles (which specify HW which is going in) * association with image (which will be provisioned on new coming nodes) * specific service settings So far suggested terms: * Role * - short name - plus points - quite overloaded term (user role, etc) * Resource Category * - pretty long (devs already shorten it - confusing) - Heat specific term * Resource Class * - older term Are there any other suggestions (ideally something short and accurate)? Or do you prefer any of already suggested terms? Any ideas are welcome - we are not very good in finding the best match for this particular term. Thanks -- Jarda ___ 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] [TripleO] [Tuskar] Terminology Revival #1 - Roles
On 2014/22/01 19:46, Tzu-Mainn Chen wrote: - Original Message - Oh dear user... :) I'll step a little bit back. We need to agree if we want to name concepts one way in the background and other way in the UI for user (did we already agree on this point?). We all know pros and cons. And I will still fight for users to get global infrastructure terminology (e.g. he is going to define Node Profiles instead of Flavors). Because I received Jarda, sidepoint - could you explain again what the attributes of a node profile are? Beyond the Flavor, does it also define an image. . . ? Mainn So... For now, the attributes are: - Name - Description - Image (Image was discussed on the level of a Role, not Node Profile) - Node Profile(s) Future: + Service Specific Configuration (?) + Policies (spin up new instance, if...) -- Jarda ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] [Tuskar] Terminology Revival #1 - Roles
On 22 January 2014 12:05, Liz Blanchard lsure...@redhat.com wrote: How about Instance Type? I’m looking at page 10 of the latest wireframes [1] and I see we are using the terms “Resource”, “Node”, and “Instance” to labels certain items. I’m pretty sure Node and Instance are different, but I’m wondering if we need to introduce Resource as a new term. It's not a new term, its generic in Heat, but it's also arguably incorrect here because as Jay says, this isn't the resource itself, its a description of what will go in the template definition to request that heat deploy instances. Instance Type would be horribly confusing IMNSHO - too close to http://aws.amazon.com/ec2/instance-types/ - which it is not at all like. -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] [Tuskar] Terminology Revival #1 - Roles
On 23 January 2014 21:39, Jaromir Coufal jcou...@redhat.com wrote: On 2014/22/01 19:46, Tzu-Mainn Chen wrote: So... For now, the attributes are: - Name - Description - Image (Image was discussed on the level of a Role, not Node Profile) - Node Profile(s) Future: + Service Specific Configuration (?) + Policies (spin up new instance, if...) http://docs.openstack.org/developer/heat/template_guide/openstack.html Is the list of 'resource types' in heat. You can see that a resource is [roughly] anything that can be addressed by an API. The instances we deploy are indeed resources, but not all resources are instances. It seems to me that there are two ways to think about the naming problem. A) What if we were writing (we're not, but this is a gedanken) a generic Heat deployment designer. B) What if we are not :) If we are, not only should we use heat terms, we should probably use the most generic ones, because we need to expose all of heat. However, we aren't. So while I think we *should* use heat terms when referring to something heat based, we don't need to use the most generic such term: Instances is fine to describe what we deploy. Instances on nodes. Separately, what we've got in the template is essentially a tree: root: parameters: resources: thing: type: OS::Service::Thing ... thing2: type: OS::Service::Thing And Tuskar's job is to hide the plumbing from that tree (e.g. that we need an OS::Heat::AccessPolicy there, because there is a single right answer for our case, and we can programatically generate it. The implementation is going to change as we move from merge.py to HOT etc, but in principle we have one key under resources for each thing that we scale out. I don't know if that helps with the naming of things,but there you go :) -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] [Tuskar] Terminology Revival #1 - Roles
- Original Message - On 23 January 2014 21:39, Jaromir Coufal jcou...@redhat.com wrote: On 2014/22/01 19:46, Tzu-Mainn Chen wrote: So... For now, the attributes are: - Name - Description - Image (Image was discussed on the level of a Role, not Node Profile) - Node Profile(s) Future: + Service Specific Configuration (?) + Policies (spin up new instance, if...) http://docs.openstack.org/developer/heat/template_guide/openstack.html Is the list of 'resource types' in heat. You can see that a resource is [roughly] anything that can be addressed by an API. The instances we deploy are indeed resources, but not all resources are instances. It seems to me that there are two ways to think about the naming problem. A) What if we were writing (we're not, but this is a gedanken) a generic Heat deployment designer. B) What if we are not :) If we are, not only should we use heat terms, we should probably use the most generic ones, because we need to expose all of heat. However, we aren't. So while I think we *should* use heat terms when referring to something heat based, we don't need to use the most generic such term: Instances is fine to describe what we deploy. Instances on nodes. The issue I have with Instances is that it gets fairly confusing when working within the UI. From the UI, we have calls to the Heat client grabbing Resources; we also have calls to the Nova client from which we get Instances. When we get information about the Overcloud, we query from Stack - Resources - Instance - Node So calling it Instancesomething would imply (to me) that a Resource has no specificity - which I don't think is the case, as there are attributes to a Heat Resource that mark it as a Compute/Controller/whatever. Calling it Instancesomething and explaining that it *does* apply to a Heat resource (but that we just renamed it) feels simply confusing. Mainn Separately, what we've got in the template is essentially a tree: root: parameters: resources: thing: type: OS::Service::Thing ... thing2: type: OS::Service::Thing And Tuskar's job is to hide the plumbing from that tree (e.g. that we need an OS::Heat::AccessPolicy there, because there is a single right answer for our case, and we can programatically generate it. The implementation is going to change as we move from merge.py to HOT etc, but in principle we have one key under resources for each thing that we scale out. I don't know if that helps with the naming of things,but there you go :) -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud ___ 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] Terminology Revival #1 - Roles
On 2014/22/01 00:56, Tzu-Mainn Chen wrote: Hiya - Resource is actually a Heat term that corresponds to what we're deploying within the Overcloud Stack - i.e., if we specify that we want an Overcloud with 1 Controller and 3 Compute, Heat will create a Stack that contains 1 Controller and 3 Compute Resources. Then a quick question - why do we design deployment by increasing/decreasing number of *instances* instead of resources? -- Jarda ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] [Tuskar] Terminology Revival #1 - Roles
On 2014/22/01 00:56, Tzu-Mainn Chen wrote: Hiya - Resource is actually a Heat term that corresponds to what we're deploying within the Overcloud Stack - i.e., if we specify that we want an Overcloud with 1 Controller and 3 Compute, Heat will create a Stack that contains 1 Controller and 3 Compute Resources. Then a quick question - why do we design deployment by increasing/decreasing number of *instances* instead of resources? -- Jarda ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] [Tuskar] Terminology Revival #1 - Roles
On 2014/22/01 10:00, Jaromir Coufal wrote: On 2014/22/01 00:56, Tzu-Mainn Chen wrote: Hiya - Resource is actually a Heat term that corresponds to what we're deploying within the Overcloud Stack - i.e., if we specify that we want an Overcloud with 1 Controller and 3 Compute, Heat will create a Stack that contains 1 Controller and 3 Compute Resources. Then a quick question - why do we design deployment by increasing/decreasing number of *instances* instead of resources? -- Jarda And one more thing - Resource is very broad term as well as Role is. The only difference is that Heat accepted 'Resource' as specific term for them (you see? they used broad term for their concept). So I am asking myself, where is difference between generic term Resource and Role? Why cannot we accept Roles? It's short, well describing... I am leaning towards Role. We can be more specific with adding some extra word, e.g.: * Node Role * Deployment Role ... and if we are in the context of undercloud, people can shorten it to just Roles. But 'Resource Category' seems to me that it doesn't solve anything. -- Jarda ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] [Tuskar] Terminology Revival #1 - Roles
Hello, Jaromir On Wed, Jan 22, 2014 at 4:09 PM, Jaromir Coufal jcou...@redhat.com wrote: I am leaning towards Role. We can be more specific with adding some extra word, e.g.: * Node Role We use this term a lot internally for the very similar purpose, so it looks reasonable to me. Just my 2c. -- Best regards, Oleg Gelbukh * Deployment Role ... and if we are in the context of undercloud, people can shorten it to just Roles. But 'Resource Category' seems to me that it doesn't solve anything. -- Jarda ___ 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] Terminology Revival #1 - Roles
That's a fair question; I'd argue that it *should* be resources. When we update an overcloud deployment, it'll create additional resources. Mainn - Original Message - On 2014/22/01 00:56, Tzu-Mainn Chen wrote: Hiya - Resource is actually a Heat term that corresponds to what we're deploying within the Overcloud Stack - i.e., if we specify that we want an Overcloud with 1 Controller and 3 Compute, Heat will create a Stack that contains 1 Controller and 3 Compute Resources. Then a quick question - why do we design deployment by increasing/decreasing number of *instances* instead of resources? -- Jarda ___ 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] Terminology Revival #1 - Roles
- Original Message - On 2014/22/01 10:00, Jaromir Coufal wrote: On 2014/22/01 00:56, Tzu-Mainn Chen wrote: Hiya - Resource is actually a Heat term that corresponds to what we're deploying within the Overcloud Stack - i.e., if we specify that we want an Overcloud with 1 Controller and 3 Compute, Heat will create a Stack that contains 1 Controller and 3 Compute Resources. Then a quick question - why do we design deployment by increasing/decreasing number of *instances* instead of resources? -- Jarda And one more thing - Resource is very broad term as well as Role is. The only difference is that Heat accepted 'Resource' as specific term for them (you see? they used broad term for their concept). So I am asking myself, where is difference between generic term Resource and Role? Why cannot we accept Roles? It's short, well describing... True, but Heat was creating something new, while it seems like (to me), our intention is mostly to consume other Openstack APIs and expose the results in the UI. If I call a Heat API which returns something that they call a Resource, I think it's confusing to developers to rename that. I am leaning towards Role. We can be more specific with adding some extra word, e.g.: * Node Role * Deployment Role ... and if we are in the context of undercloud, people can shorten it to just Roles. But 'Resource Category' seems to me that it doesn't solve anything. I'd be okay with Resource Role! -- Jarda ___ 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] Terminology Revival #1 - Roles
On 2014/22/01 10:00, Jaromir Coufal wrote: On 2014/22/01 00:56, Tzu-Mainn Chen wrote: Hiya - Resource is actually a Heat term that corresponds to what we're deploying within the Overcloud Stack - i.e., if we specify that we want an Overcloud with 1 Controller and 3 Compute, Heat will create a Stack that contains 1 Controller and 3 Compute Resources. Then a quick question - why do we design deployment by increasing/decreasing number of *instances* instead of resources? -- Jarda And one more thing - Resource is very broad term as well as Role is. The only difference is that Heat accepted 'Resource' as specific term for them (you see? they used broad term for their concept). So I am asking myself, where is difference between generic term Resource and Role? Why cannot we accept Roles? It's short, well describing... True, but Heat was creating something new, while it seems like (to me), our intention is mostly to consume other Openstack APIs and expose the results in the UI. If I call a Heat API which returns something that they call a Resource, I think it's confusing to developers to rename that. I am leaning towards Role. We can be more specific with adding some extra word, e.g.: * Node Role * Deployment Role ... and if we are in the context of undercloud, people can shorten it to just Roles. But 'Resource Category' seems to me that it doesn't solve anything. I'd be okay with Resource Role! Actually - didn't someone raise the objection that Role was a defined term within Keystone and potentially a source of confusion? Mainn -- Jarda ___ 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] [TripleO] [Tuskar] Terminology Revival #1 - Roles
On 22/01/14 14:31, Tzu-Mainn Chen wrote: On 2014/22/01 10:00, Jaromir Coufal wrote: On 2014/22/01 00:56, Tzu-Mainn Chen wrote: Hiya - Resource is actually a Heat term that corresponds to what we're deploying within the Overcloud Stack - i.e., if we specify that we want an Overcloud with 1 Controller and 3 Compute, Heat will create a Stack that contains 1 Controller and 3 Compute Resources. Then a quick question - why do we design deployment by increasing/decreasing number of *instances* instead of resources? -- Jarda And one more thing - Resource is very broad term as well as Role is. The only difference is that Heat accepted 'Resource' as specific term for them (you see? they used broad term for their concept). So I am asking myself, where is difference between generic term Resource and Role? Why cannot we accept Roles? It's short, well describing... True, but Heat was creating something new, while it seems like (to me), our intention is mostly to consume other Openstack APIs and expose the results in the UI. If I call a Heat API which returns something that they call a Resource, I think it's confusing to developers to rename that. I am leaning towards Role. We can be more specific with adding some extra word, e.g.: * Node Role * Deployment Role ... and if we are in the context of undercloud, people can shorten it to just Roles. But 'Resource Category' seems to me that it doesn't solve anything. I'd be okay with Resource Role! Actually - didn't someone raise the objection that Role was a defined term within Keystone and potentially a source of confusion? Mainn Yup, I think the concern was that it could be confused with User Roles. However, Resource Role is probably clear enough IMO. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] [Tuskar] Terminology Revival #1 - Roles
On Jan 22, 2014, at 4:02 AM, Jaromir Coufal jcou...@redhat.com wrote: On 2014/22/01 00:56, Tzu-Mainn Chen wrote: Hiya - Resource is actually a Heat term that corresponds to what we're deploying within the Overcloud Stack - i.e., if we specify that we want an Overcloud with 1 Controller and 3 Compute, Heat will create a Stack that contains 1 Controller and 3 Compute Resources. Then a quick question - why do we design deployment by increasing/decreasing number of *instances* instead of resources? Yeah, great question Jarda. When I test out the “Stacks” functionality in Horizon the user doesn’t create a Stack that spins up resources, it spins up instances. Maybe there is a difference around the terms being used behind the scenes and in Horizon? Liz -- Jarda ___ 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] Terminology Revival #1 - Roles
On Jan 22, 2014, at 9:52 AM, Dougal Matthews dou...@redhat.com wrote: On 22/01/14 14:31, Tzu-Mainn Chen wrote: On 2014/22/01 10:00, Jaromir Coufal wrote: On 2014/22/01 00:56, Tzu-Mainn Chen wrote: Hiya - Resource is actually a Heat term that corresponds to what we're deploying within the Overcloud Stack - i.e., if we specify that we want an Overcloud with 1 Controller and 3 Compute, Heat will create a Stack that contains 1 Controller and 3 Compute Resources. Then a quick question - why do we design deployment by increasing/decreasing number of *instances* instead of resources? -- Jarda And one more thing - Resource is very broad term as well as Role is. The only difference is that Heat accepted 'Resource' as specific term for them (you see? they used broad term for their concept). So I am asking myself, where is difference between generic term Resource and Role? Why cannot we accept Roles? It's short, well describing... True, but Heat was creating something new, while it seems like (to me), our intention is mostly to consume other Openstack APIs and expose the results in the UI. If I call a Heat API which returns something that they call a Resource, I think it's confusing to developers to rename that. I am leaning towards Role. We can be more specific with adding some extra word, e.g.: * Node Role * Deployment Role ... and if we are in the context of undercloud, people can shorten it to just Roles. But 'Resource Category' seems to me that it doesn't solve anything. I'd be okay with Resource Role! Actually - didn't someone raise the objection that Role was a defined term within Keystone and potentially a source of confusion? Yeah, that was me :) Mainn Yup, I think the concern was that it could be confused with User Roles. However, Resource Role is probably clear enough IMO. Exactly. If we add something to make “Role” more specific to the user it would be much more clear. Liz ___ 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] Terminology Revival #1 - Roles
On Jan 22, 2014, at 7:09 AM, Jaromir Coufal jcou...@redhat.com wrote: On 2014/22/01 10:00, Jaromir Coufal wrote: On 2014/22/01 00:56, Tzu-Mainn Chen wrote: Hiya - Resource is actually a Heat term that corresponds to what we're deploying within the Overcloud Stack - i.e., if we specify that we want an Overcloud with 1 Controller and 3 Compute, Heat will create a Stack that contains 1 Controller and 3 Compute Resources. Then a quick question - why do we design deployment by increasing/decreasing number of *instances* instead of resources? -- Jarda And one more thing - Resource is very broad term as well as Role is. The only difference is that Heat accepted 'Resource' as specific term for them (you see? they used broad term for their concept). So I am asking myself, where is difference between generic term Resource and Role? Why cannot we accept Roles? It's short, well describing... I am leaning towards Role. We can be more specific with adding some extra word, e.g.: * Node Role +1 to Node Role. I agree that “role” is being used as a generic term here. I’m still convinced it’s important to use “Node” in the name since this is the item we are describing by assigning it a certain type of role. Liz * Deployment Role ... and if we are in the context of undercloud, people can shorten it to just Roles. But 'Resource Category' seems to me that it doesn't solve anything. -- Jarda ___ 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] Terminology Revival #1 - Roles
On Jan 22, 2014, at 7:09 AM, Jaromir Coufal jcou...@redhat.com wrote: On 2014/22/01 10:00, Jaromir Coufal wrote: On 2014/22/01 00:56, Tzu-Mainn Chen wrote: Hiya - Resource is actually a Heat term that corresponds to what we're deploying within the Overcloud Stack - i.e., if we specify that we want an Overcloud with 1 Controller and 3 Compute, Heat will create a Stack that contains 1 Controller and 3 Compute Resources. Then a quick question - why do we design deployment by increasing/decreasing number of *instances* instead of resources? -- Jarda And one more thing - Resource is very broad term as well as Role is. The only difference is that Heat accepted 'Resource' as specific term for them (you see? they used broad term for their concept). So I am asking myself, where is difference between generic term Resource and Role? Why cannot we accept Roles? It's short, well describing... I am leaning towards Role. We can be more specific with adding some extra word, e.g.: * Node Role +1 to Node Role. I agree that “role” is being used as a generic term here. I’m still convinced it’s important to use “Node” in the name since this is the item we are describing by assigning it a certain type of role. I'm *strongly* against Node Role. In Ironic, a Node has no explicit Role assigned to it; whatever Role it has is implicit through the Instance running on it (which maps to a Heat Resource). In that sense, we're not really monitoring Nodes; we're monitoring Resources, and a Node just happens to be one attribute of a Resource. Mainn Liz * Deployment Role ... and if we are in the context of undercloud, people can shorten it to just Roles. But 'Resource Category' seems to me that it doesn't solve anything. -- Jarda ___ 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] [TripleO] [Tuskar] Terminology Revival #1 - Roles
On Jan 22, 2014, at 4:02 AM, Jaromir Coufal jcou...@redhat.com wrote: On 2014/22/01 00:56, Tzu-Mainn Chen wrote: Hiya - Resource is actually a Heat term that corresponds to what we're deploying within the Overcloud Stack - i.e., if we specify that we want an Overcloud with 1 Controller and 3 Compute, Heat will create a Stack that contains 1 Controller and 3 Compute Resources. Then a quick question - why do we design deployment by increasing/decreasing number of *instances* instead of resources? Yeah, great question Jarda. When I test out the “Stacks” functionality in Horizon the user doesn’t create a Stack that spins up resources, it spins up instances. Maybe there is a difference around the terms being used behind the scenes and in Horizon? Maybe we're looking at different parts of the UI, but when I look at a Stack detail page in Horizon, I see a tab for Resources, and not Instances. The resource table might link to an Instance, but that information is retrieved from the Resource. Mainn Liz -- Jarda ___ 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] [TripleO] [Tuskar] Terminology Revival #1 - Roles
Oh dear user... :) I'll step a little bit back. We need to agree if we want to name concepts one way in the background and other way in the UI for user (did we already agree on this point?). We all know pros and cons. And I will still fight for users to get global infrastructure terminology (e.g. he is going to define Node Profiles instead of Flavors). Because I received a lot of negative feedback on mixing overcloud terms into undercloud, confusion about overcloud/undercloud term itself, etc. If it would be easier for developers to name the concepts in the background differently then it's fine - we just need to talk about 2 terms per concept then. And I would be a bit afraid of schizophrenia... On 2014/22/01 15:10, Tzu-Mainn Chen wrote: That's a fair question; I'd argue that it *should* be resources. When we update an overcloud deployment, it'll create additional resources. Honestly it would get super confusing for me, if somebody tells me - you have 5 compute resources. (And I am talking from user's world, not from developers one). But resource itself can be anything. -- Jarda ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] [Tuskar] Terminology Revival #1 - Roles
On Jan 22, 2014, at 10:53 AM, Jaromir Coufal jcou...@redhat.com wrote: Oh dear user... :) I'll step a little bit back. We need to agree if we want to name concepts one way in the background and other way in the UI for user (did we already agree on this point?). We all know pros and cons. And I will still fight for users to get global infrastructure terminology (e.g. he is going to define Node Profiles instead of Flavors). Because I received a lot of negative feedback on mixing overcloud terms into undercloud, confusion about overcloud/undercloud term itself, etc. If it would be easier for developers to name the concepts in the background differently then it's fine - we just need to talk about 2 terms per concept then. And I would be a bit afraid of schizophrenia… Haha, sorry if this is my fault for reviving this whole thread :) Terminology is always tough. It probably makes sense to start with where we initially agreed and get some Operators eyes on the design so that they can weigh in. Liz On 2014/22/01 15:10, Tzu-Mainn Chen wrote: That's a fair question; I'd argue that it *should* be resources. When we update an overcloud deployment, it'll create additional resources. Honestly it would get super confusing for me, if somebody tells me - you have 5 compute resources. (And I am talking from user's world, not from developers one). But resource itself can be anything. -- Jarda ___ 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] Terminology Revival #1 - Roles
- Original Message - Oh dear user... :) I'll step a little bit back. We need to agree if we want to name concepts one way in the background and other way in the UI for user (did we already agree on this point?). We all know pros and cons. And I will still fight for users to get global infrastructure terminology (e.g. he is going to define Node Profiles instead of Flavors). Because I received Jarda, sidepoint - could you explain again what the attributes of a node profile are? Beyond the Flavor, does it also define an image. . . ? Mainn a lot of negative feedback on mixing overcloud terms into undercloud, confusion about overcloud/undercloud term itself, etc. If it would be easier for developers to name the concepts in the background differently then it's fine - we just need to talk about 2 terms per concept then. And I would be a bit afraid of schizophrenia... On 2014/22/01 15:10, Tzu-Mainn Chen wrote: That's a fair question; I'd argue that it *should* be resources. When we update an overcloud deployment, it'll create additional resources. Honestly it would get super confusing for me, if somebody tells me - you have 5 compute resources. (And I am talking from user's world, not from developers one). But resource itself can be anything. -- Jarda ___ 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] [TripleO] [Tuskar] Terminology Revival #1 - Roles
Hi folks, when I was getting feedback on wireframes and we talked about Roles, there were various objections and not much suggestions. I would love to call for action and think a bit about the term for concept currently known as Role (= Resource Category). Definition: Role is a representation of a group of nodes, with specific behavior. Each role contains (or will contain): * one or more Node Profiles (which specify HW which is going in) * association with image (which will be provisioned on new coming nodes) * specific service settings So far suggested terms: * Role * - short name - plus points - quite overloaded term (user role, etc) * Resource Category * - pretty long (devs already shorten it - confusing) - Heat specific term * Resource Class * - older term Are there any other suggestions (ideally something short and accurate)? Or do you prefer any of already suggested terms? Any ideas are welcome - we are not very good in finding the best match for this particular term. Thanks -- Jarda ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] [Tuskar] Terminology Revival #1 - Roles
Thanks for starting this! Comments in-line: Hi folks, when I was getting feedback on wireframes and we talked about Roles, there were various objections and not much suggestions. I would love to call for action and think a bit about the term for concept currently known as Role (= Resource Category). Definition: Role is a representation of a group of nodes, with specific behavior. I don't think this is technically correct; according to the wireframes, a 'Role' is a representation of a group of Heat resources from an overcloud stack - a Controller Resource, Compute Resource, etc. Free nodes have no Role. Each role contains (or will contain): * one or more Node Profiles (which specify HW which is going in) * association with image (which will be provisioned on new coming nodes) * specific service settings So far suggested terms: * Role * - short name - plus points - quite overloaded term (user role, etc) * Resource Category * - pretty long (devs already shorten it - confusing) - Heat specific term That's why I suggested this term after others objected to Role; it seems to me that whatever term we use should have the world 'Resource' in it, in order to make the correspondence clear. Mainn * Resource Class * - older term Are there any other suggestions (ideally something short and accurate)? Or do you prefer any of already suggested terms? Any ideas are welcome - we are not very good in finding the best match for this particular term. Thanks -- Jarda ___ 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] Terminology Revival #1 - Roles
On 21/01/14 14:19, Jaromir Coufal wrote: when I was getting feedback on wireframes and we talked about Roles, there were various objections and not much suggestions. I would love to call for action and think a bit about the term for concept currently known as Role (= Resource Category). This indeed a bit confusing, I think Role has mostly been rejected and I've seen Resource Category used the most since. So far suggested terms: * Role * - short name - plus points - quite overloaded term (user role, etc) -1 for Role, I don't think short is a good enough reason. * Resource Category * - pretty long (devs already shorten it - confusing) - Heat specific term +0, I'ge gotten used to this, its quite long, but its not that bad. * Resource Class * - older term -0, this strikes me as confusing as what we are defining now is somewhat different to what a Resource Class was. However, if we can clear it up this name is otherwise fine. Are there any other suggestions (ideally something short and accurate)? I'll throw out a couple to start ideas - - Resource Role (people seem to like Resource and role! ;-) ) - Resource Group - Role Type ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] [Tuskar] Terminology Revival #1 - Roles
On Jan 21, 2014, at 9:40 AM, Dougal Matthews dou...@redhat.com wrote: On 21/01/14 14:19, Jaromir Coufal wrote: when I was getting feedback on wireframes and we talked about Roles, there were various objections and not much suggestions. I would love to call for action and think a bit about the term for concept currently known as Role (= Resource Category). This indeed a bit confusing, I think Role has mostly been rejected and I've seen Resource Category used the most since. So far suggested terms: * Role * - short name - plus points - quite overloaded term (user role, etc) -1 for Role, I don't think short is a good enough reason. Agreed. Role is overloaded IMO. * Resource Category * - pretty long (devs already shorten it - confusing) - Heat specific term +0, I'ge gotten used to this, its quite long, but its not that bad. * Resource Class * - older term -0, this strikes me as confusing as what we are defining now is somewhat different to what a Resource Class was. However, if we can clear it up this name is otherwise fine. Are there any other suggestions (ideally something short and accurate)? I'll throw out a couple to start ideas - - Resource Role (people seem to like Resource and role! ;-) ) - Resource Group - Role Type How about Instance Type? I’m looking at page 10 of the latest wireframes [1] and I see we are using the terms “Resource”, “Node”, and “Instance” to labels certain items. I’m pretty sure Node and Instance are different, but I’m wondering if we need to introduce Resource as a new term. My thoughts, Liz [1]http://people.redhat.com/~jcoufal/openstack/tripleo/2014-01-20_tripleo-ui-icehouse.pdf ___ 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] Terminology Revival #1 - Roles
On Jan 21, 2014, at 9:40 AM, Dougal Matthews dou...@redhat.com wrote: On 21/01/14 14:19, Jaromir Coufal wrote: when I was getting feedback on wireframes and we talked about Roles, there were various objections and not much suggestions. I would love to call for action and think a bit about the term for concept currently known as Role (= Resource Category). This indeed a bit confusing, I think Role has mostly been rejected and I've seen Resource Category used the most since. So far suggested terms: * Role * - short name - plus points - quite overloaded term (user role, etc) -1 for Role, I don't think short is a good enough reason. Agreed. Role is overloaded IMO. * Resource Category * - pretty long (devs already shorten it - confusing) - Heat specific term +0, I'ge gotten used to this, its quite long, but its not that bad. * Resource Class * - older term -0, this strikes me as confusing as what we are defining now is somewhat different to what a Resource Class was. However, if we can clear it up this name is otherwise fine. Are there any other suggestions (ideally something short and accurate)? I'll throw out a couple to start ideas - - Resource Role (people seem to like Resource and role! ;-) ) - Resource Group - Role Type How about Instance Type? I’m looking at page 10 of the latest wireframes [1] and I see we are using the terms “Resource”, “Node”, and “Instance” to labels certain items. I’m pretty sure Node and Instance are different, but I’m wondering if we need to introduce Resource as a new term. Hiya - Resource is actually a Heat term that corresponds to what we're deploying within the Overcloud Stack - i.e., if we specify that we want an Overcloud with 1 Controller and 3 Compute, Heat will create a Stack that contains 1 Controller and 3 Compute Resources. Mainn My thoughts, Liz [1]http://people.redhat.com/~jcoufal/openstack/tripleo/2014-01-20_tripleo-ui-icehouse.pdf ___ 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] [TripleO][Tuskar] Terminology
On 12/17/2013 04:20 PM, Tzu-Mainn Chen wrote: On 2013/13/12 23:11, Jordan OMara wrote: On 13/12/13 16:20 +1300, Robert Collins wrote: However, on instance - 'instance' is a very well defined term in Nova and thus OpenStack: Nova boot gets you an instance, nova delete gets rid of an instance, nova rebuild recreates it, etc. Instances run [virtual|baremetal] machines managed by a hypervisor. So nova-scheduler is not ever going to be confused with instance in the OpenStack space IMO. But it brings up a broader question, which is - what should we do when terms that are well defined in OpenStack - like Node, Instance, Flavor - are not so well defined for new users? We could use different terms, but that may confuse 'stackers, and will mean that our UI needs it's own dedicated terminology to map back to e.g. the manuals for Nova and Ironic. I'm inclined to suggest that as a principle, where there is a well defined OpenStack concept, that we use it, even if it is not ideal, because the consistency will be valuable. I think this is a really important point. I think the consistency is a powerful tool for teaching new users how they should expect tripleo/tuskar to work and should lessen the learning curve, as long they've used openstack before. I don't 100% agree here. Yes it is important for user to keep consistency in naming - but as long as he is working within the same domain. Problem is that our TripleO/Tuskar UI user is very different from OpenStack UI user. They are operators, and they might be very often used to different terminology - globally used and known in their field (for example Flavor is very OpenStack specific term, they might better see HW profile, or similar). I think that mixing these terms in overcloud and undercloud might lead to problems and users' confusion. They already are confused about the whole 'over/under cloud' stuff. They are not working with this approach daily as we are. They care about deploying OpenStack, not about how it works under the hood. Bringing another more complicated level of terminology (explaining what is and belongs to under/overcloud) will increase the confusion here. For developers, it might be easier to deal with the same terms as OpenStack already have or what is used in the background to make that happen. But for user - it will be confusing going to infrastructure/hardware management part and see the very same terms. Therefor I incline more to broadly accepted general terminology and not reusing OpenSTack terms (at least in the UI). -- Jarda I think you're correct with respect to the end-user, and I can see the argument for terminology changes at the view level; it is important not to confuse the end-user. But at the level where developers are working with OpenStack APIs, I think it's important not to confuse the developers and reviewers, and that's most easily done by sticking with established OpenStack terminology. Mainn I think we are assuming a lot here. I would rather keep the same naming Openstack use and possibly rename it later based on users real feedback. There is not only UI, sysadmins will work with CLI, using Openstack services, using Openstack naming. So naming it differently will be confusing. Btw. I would never hire a sysadmin that should be managing my 100s nodes cloud and have no idea what is happening under the hood. :-D Ladislav ___ 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] Terminology
On Wed, Dec 18, 2013 at 10:44:46AM +0100, Ladislav Smola wrote: On 12/17/2013 04:20 PM, Tzu-Mainn Chen wrote: On 2013/13/12 23:11, Jordan OMara wrote: On 13/12/13 16:20 +1300, Robert Collins wrote: However, on instance - 'instance' is a very well defined term in Nova and thus OpenStack: Nova boot gets you an instance, nova delete gets rid of an instance, nova rebuild recreates it, etc. Instances run [virtual|baremetal] machines managed by a hypervisor. So nova-scheduler is not ever going to be confused with instance in the OpenStack space IMO. But it brings up a broader question, which is - what should we do when terms that are well defined in OpenStack - like Node, Instance, Flavor - are not so well defined for new users? We could use different terms, but that may confuse 'stackers, and will mean that our UI needs it's own dedicated terminology to map back to e.g. the manuals for Nova and Ironic. I'm inclined to suggest that as a principle, where there is a well defined OpenStack concept, that we use it, even if it is not ideal, because the consistency will be valuable. I think this is a really important point. I think the consistency is a powerful tool for teaching new users how they should expect tripleo/tuskar to work and should lessen the learning curve, as long they've used openstack before. I don't 100% agree here. Yes it is important for user to keep consistency in naming - but as long as he is working within the same domain. Problem is that our TripleO/Tuskar UI user is very different from OpenStack UI user. They are operators, and they might be very often used to different terminology - globally used and known in their field (for example Flavor is very OpenStack specific term, they might better see HW profile, or similar). I think that mixing these terms in overcloud and undercloud might lead to problems and users' confusion. They already are confused about the whole 'over/under cloud' stuff. They are not working with this approach daily as we are. They care about deploying OpenStack, not about how it works under the hood. Bringing another more complicated level of terminology (explaining what is and belongs to under/overcloud) will increase the confusion here. For developers, it might be easier to deal with the same terms as OpenStack already have or what is used in the background to make that happen. But for user - it will be confusing going to infrastructure/hardware management part and see the very same terms. Therefor I incline more to broadly accepted general terminology and not reusing OpenSTack terms (at least in the UI). -- Jarda I think you're correct with respect to the end-user, and I can see the argument for terminology changes at the view level; it is important not to confuse the end-user. But at the level where developers are working with OpenStack APIs, I think it's important not to confuse the developers and reviewers, and that's most easily done by sticking with established OpenStack terminology. Mainn I think we are assuming a lot here. I would rather keep the same naming Openstack use and possibly rename it later based on users real feedback. Generally, I'm +1 here. I do however see a couple of downsides with it: - OpenStack concepts, while they may be well defined and understood in the developer community, that doesn't always mean they make sense, and so to a new user they could be confusing (a few others already pointed this out). For example, using Instance, I *think* (no hard data really) most people assume virtual when you say Instance. Nova can obviously do baremetal, but that may not be clear to everyone at first. I mean, I assume Ironic is named Ironic for a reason :). That should tell you right there that it's doing something different, and not what's necessarily expected. - Internal OpenStack terminology can change. We'd need to update the UI for those changes if we wanted to stay up to date, or we're back to having a UI that doesn't match internal concepts. If we compromised in the beginning by using an internal concept that wasn't necessarily clear, we're then even worse off. For example, isn't there a push now to update the usage of tenant in some places? I know we're not calling that term out specifically, but it's just an example. There is not only UI, sysadmins will work with CLI, using Openstack services, using Openstack naming. So naming it differently will be confusing. Btw. I would never hire a sysadmin that should be managing my 100s nodes cloud and have no idea what is happening under the hood. :-D Ladislav ___ 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
Re: [openstack-dev] [TripleO][Tuskar] Terminology
On 2013/13/12 23:11, Jordan OMara wrote: On 13/12/13 16:20 +1300, Robert Collins wrote: However, on instance - 'instance' is a very well defined term in Nova and thus OpenStack: Nova boot gets you an instance, nova delete gets rid of an instance, nova rebuild recreates it, etc. Instances run [virtual|baremetal] machines managed by a hypervisor. So nova-scheduler is not ever going to be confused with instance in the OpenStack space IMO. But it brings up a broader question, which is - what should we do when terms that are well defined in OpenStack - like Node, Instance, Flavor - are not so well defined for new users? We could use different terms, but that may confuse 'stackers, and will mean that our UI needs it's own dedicated terminology to map back to e.g. the manuals for Nova and Ironic. I'm inclined to suggest that as a principle, where there is a well defined OpenStack concept, that we use it, even if it is not ideal, because the consistency will be valuable. I think this is a really important point. I think the consistency is a powerful tool for teaching new users how they should expect tripleo/tuskar to work and should lessen the learning curve, as long they've used openstack before. I don't 100% agree here. Yes it is important for user to keep consistency in naming - but as long as he is working within the same domain. Problem is that our TripleO/Tuskar UI user is very different from OpenStack UI user. They are operators, and they might be very often used to different terminology - globally used and known in their field (for example Flavor is very OpenStack specific term, they might better see HW profile, or similar). I think that mixing these terms in overcloud and undercloud might lead to problems and users' confusion. They already are confused about the whole 'over/under cloud' stuff. They are not working with this approach daily as we are. They care about deploying OpenStack, not about how it works under the hood. Bringing another more complicated level of terminology (explaining what is and belongs to under/overcloud) will increase the confusion here. For developers, it might be easier to deal with the same terms as OpenStack already have or what is used in the background to make that happen. But for user - it will be confusing going to infrastructure/hardware management part and see the very same terms. Therefor I incline more to broadly accepted general terminology and not reusing OpenSTack terms (at least in the UI). -- Jarda ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO][Tuskar] Terminology
On 2013/13/12 23:11, Jordan OMara wrote: On 13/12/13 16:20 +1300, Robert Collins wrote: However, on instance - 'instance' is a very well defined term in Nova and thus OpenStack: Nova boot gets you an instance, nova delete gets rid of an instance, nova rebuild recreates it, etc. Instances run [virtual|baremetal] machines managed by a hypervisor. So nova-scheduler is not ever going to be confused with instance in the OpenStack space IMO. But it brings up a broader question, which is - what should we do when terms that are well defined in OpenStack - like Node, Instance, Flavor - are not so well defined for new users? We could use different terms, but that may confuse 'stackers, and will mean that our UI needs it's own dedicated terminology to map back to e.g. the manuals for Nova and Ironic. I'm inclined to suggest that as a principle, where there is a well defined OpenStack concept, that we use it, even if it is not ideal, because the consistency will be valuable. I think this is a really important point. I think the consistency is a powerful tool for teaching new users how they should expect tripleo/tuskar to work and should lessen the learning curve, as long they've used openstack before. I don't 100% agree here. Yes it is important for user to keep consistency in naming - but as long as he is working within the same domain. Problem is that our TripleO/Tuskar UI user is very different from OpenStack UI user. They are operators, and they might be very often used to different terminology - globally used and known in their field (for example Flavor is very OpenStack specific term, they might better see HW profile, or similar). I think that mixing these terms in overcloud and undercloud might lead to problems and users' confusion. They already are confused about the whole 'over/under cloud' stuff. They are not working with this approach daily as we are. They care about deploying OpenStack, not about how it works under the hood. Bringing another more complicated level of terminology (explaining what is and belongs to under/overcloud) will increase the confusion here. For developers, it might be easier to deal with the same terms as OpenStack already have or what is used in the background to make that happen. But for user - it will be confusing going to infrastructure/hardware management part and see the very same terms. Therefor I incline more to broadly accepted general terminology and not reusing OpenSTack terms (at least in the UI). -- Jarda I think you're correct with respect to the end-user, and I can see the argument for terminology changes at the view level; it is important not to confuse the end-user. But at the level where developers are working with OpenStack APIs, I think it's important not to confuse the developers and reviewers, and that's most easily done by sticking with established OpenStack terminology. 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] Terminology
Thanks for the reply! Let me try and address one particular section for now, since it seems to be the part causing the most confusion: * SERVICE CLASS - a further categorization within a service role for a particular deployment. * NODE PROFILE - a set of requirements that specify what attributes a node must have in order to be mapped to a service class I think I still need some more information about the above two. They sound vaguely like Cobbler's system profiles... :) I admit that this concept was a bit fuzzy for me as well, but after a few IRC chats, I think I have a better handle on this. Let me begin with my understanding of what happens in Heat, using Heat terminology: A Heat stack template defines RESOURCES. When a STACK is deployed using that template, the resource information in the template is used to instantiate an INSTANCE of that resource on a NODE. Heat can pass a FLAVOR (flavors?) to nova-scheduler in order to filter for appropriate nodes. So: based on that explanation, here's what Tuskar has been calling the above: HEAT TERM == TUSKAR TERM NODE == NODE STACK == DEPLOYMENT INSTANCE == INSTANCE RESOURCE == SERVICE CLASS (at the very least, it's a one-to-one correspondence) FLAVOR == NODE PROFILE ???== ROLE The ??? is because ROLE is entirely a Tuskar concept, based on what TripleO views as the fundamental kinds of building blocks for an overcloud: Compute, Controller, Object Storage, Block Storage. A ROLE essentially categorizes RESOURCES/SERVICE CLASSES; for example, the Control ROLE might contain a control-db resource, control-secure resource, control-api resource, etc. Heat cares only about the RESOURCE and not the ROLE; if the roles were named Foo1, Foo2, Foo3, and Barney, Heat would not care. Also, if the UI miscategorized, say, the control-db resource under the Block Storage category - Heat would again not care, and the deploy action would work. From that perspective, I think the above terminology should either *be* the Heat term, or be a word that closely corresponds to the intended purpose. For example, I think DEPLOYMENT reasonably describes a STACK, but I don't think SERVICE CLASS works for RESOURCE. I also think ROLE should be RESOURCE CATEGORY, since that seems to me to be the most straightforward description of its purpose. People with more experience in Heat, please correct any of my misunderstandings! Mainn Best, -jay ___ 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] Terminology
Thanks Mainn, comments inline :) On Fri, 2013-12-13 at 19:31 -0500, Tzu-Mainn Chen wrote: Thanks for the reply! Let me try and address one particular section for now, since it seems to be the part causing the most confusion: * SERVICE CLASS - a further categorization within a service role for a particular deployment. * NODE PROFILE - a set of requirements that specify what attributes a node must have in order to be mapped to a service class I think I still need some more information about the above two. They sound vaguely like Cobbler's system profiles... :) I admit that this concept was a bit fuzzy for me as well, but after a few IRC chats, I think I have a better handle on this. Let me begin with my understanding of what happens in Heat, using Heat terminology: A Heat stack template defines RESOURCES. When a STACK is deployed using that template, the resource information in the template is used to instantiate an INSTANCE of that resource on a NODE. Heat can pass a FLAVOR (flavors?) to nova-scheduler in order to filter for appropriate nodes. So: based on that explanation, here's what Tuskar has been calling the above: HEAT TERM == TUSKAR TERM NODE == NODE STACK == DEPLOYMENT INSTANCE == INSTANCE RESOURCE == SERVICE CLASS (at the very least, it's a one-to-one correspondence) FLAVOR == NODE PROFILE ???== ROLE The ??? is because ROLE is entirely a Tuskar concept, based on what TripleO views as the fundamental kinds of building blocks for an overcloud: Compute, Controller, Object Storage, Block Storage. A ROLE essentially categorizes RESOURCES/SERVICE CLASSES; for example, the Control ROLE might contain a control-db resource, control-secure resource, control-api resource, etc. So, based on your explanation above, perhaps it makes sense to just ditch the concept of roles entirely? Is the concept useful more than just being a list of workloads that a node is running? Heat cares only about the RESOURCE and not the ROLE; if the roles were named Foo1, Foo2, Foo3, and Barney, Heat would not care. Also, if the UI miscategorized, say, the control-db resource under the Block Storage category - Heat would again not care, and the deploy action would work. From that perspective, I think the above terminology should either *be* the Heat term, or be a word that closely corresponds to the intended purpose. For example, I think DEPLOYMENT reasonably describes a STACK, but I don't think SERVICE CLASS works for RESOURCE. I also think ROLE should be RESOURCE CATEGORY, since that seems to me to be the most straightforward description of its purpose. I agree with you that either the Tuskar terminology should match the Heat terminology, or there should be a good reason for it not to match the Heat terminology. With regards to stack vs. deployment, perhaps it's best to just stick with stack. For service class, node profile, and role, perhaps it may be useful to scrap those terms entirely and use a term that the Solum project has adopted for describing an application deployment: the plan. In Solum-land, the plan is simply the instructions for deploying the application. In Tuskar-land, the plan would simply be the instructions for setting up the undercloud. So, instead of SIZE THE ROLES, you would just be defining the plan in Tuskar. Thoughts? -jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO][Tuskar] Terminology
On 12/11/2013 08:59 PM, James Slagle wrote: This is really helpful, thanks for pulling it together. comment inline... On Wed, Dec 11, 2013 at 2:15 PM, Tzu-Mainn Chen tzuma...@redhat.com wrote: * NODE a physical general purpose machine capable of running in many roles. Some nodes may have hardware layout that is particularly useful for a given role. * REGISTRATION - the act of creating a node in Ironic * ROLE - a specific workload we want to map onto one or more nodes. Examples include 'undercloud control plane', 'overcloud control plane', 'overcloud storage', 'overcloud compute' etc. * MANAGEMENT NODE - a node that has been mapped with an undercloud role * SERVICE NODE - a node that has been mapped with an overcloud role * COMPUTE NODE - a service node that has been mapped to an overcloud compute role * CONTROLLER NODE - a service node that has been mapped to an overcloud controller role * OBJECT STORAGE NODE - a service node that has been mapped to an overcloud object storage role * BLOCK STORAGE NODE - a service node that has been mapped to an overcloud block storage role * UNDEPLOYED NODE - a node that has not been mapped with a role This begs the question (for me anyway), why not call it UNMAPPED NODE? If not, can we s/mapped/deployed in the descriptions above instead? It might make sense then to define mapped and deployed in technical terms as well. Is mapped just the act of associating a node with a role in the UI, or does it mean that bits have actually been transferred across the wire to the node's disk and it's now running? The way I see it, it depends where we have the node. So Registered/Unregistered means the node is or is not in the 'nova baremetal-list' (Ironic). (we can't really have unregistered unless we can call autodiscover that just shows not registered nodes) Registering is done via 'nova baremetal-node-create' And Provisioned/Unprovisioned(Deployed, Booted, Mapped ??) means that the node is or is not in 'nova list' Provisioning is done via 'nova boot'. Not sure about calling it mapping. Basically, deciding what role the baremetal have is: if it was booted with image that is considered to be Compute Node image, then it's compute node. Right? Other thing is whether the service it provides runs correctly. * another option - UNALLOCATED NODE - a node that has not been allocated through nova scheduler (?) - (after reading lifeless's explanation, I agree that allocation may be a misleading term under TripleO, so I personally vote for UNDEPLOYED) * INSTANCE - A role deployed on a node - this is where work actually happens. * DEPLOYMENT * SIZE THE ROLES - the act of deciding how many nodes will need to be assigned to each role * another option - DISTRIBUTE NODES (?) - (I think the former is more accurate, but perhaps there's a better way to say it?) * SCHEDULING - the process of deciding which role is deployed on which node * SERVICE CLASS - a further categorization within a service role for a particular deployment. * NODE PROFILE - a set of requirements that specify what attributes a node must have in order to be mapped to a service class ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO][Tuskar] Terminology
On 12/11/2013 08:54 PM, Jay Dobies wrote: So glad we're hashing this out now. This will save a bunch of headaches in the future. Good call pushing this forward. On 12/11/2013 02:15 PM, Tzu-Mainn Chen wrote: Hi, I'm trying to clarify the terminology being used for Tuskar, which may be helpful so that we're sure that we're all talking about the same thing :) I'm copying responses from the requirements thread and combining them with current requirements to try and create a unified view. Hopefully, we can come to a reasonably rapid consensus on any desired changes; once that's done, the requirements can be updated. * NODE a physical general purpose machine capable of running in many roles. Some nodes may have hardware layout that is particularly useful for a given role. Do we ever need to distinguish between undercloud and overcloud nodes? * REGISTRATION - the act of creating a node in Ironic DISCOVERY - The act of having nodes found auto-magically and added to Ironic with minimal user intervention. * ROLE - a specific workload we want to map onto one or more nodes. Examples include 'undercloud control plane', 'overcloud control plane', 'overcloud storage', 'overcloud compute' etc. * MANAGEMENT NODE - a node that has been mapped with an undercloud role * SERVICE NODE - a node that has been mapped with an overcloud role * COMPUTE NODE - a service node that has been mapped to an overcloud compute role * CONTROLLER NODE - a service node that has been mapped to an overcloud controller role * OBJECT STORAGE NODE - a service node that has been mapped to an overcloud object storage role * BLOCK STORAGE NODE - a service node that has been mapped to an overcloud block storage role * UNDEPLOYED NODE - a node that has not been mapped with a role * another option - UNALLOCATED NODE - a node that has not been allocated through nova scheduler (?) - (after reading lifeless's explanation, I agree that allocation may be a misleading term under TripleO, so I personally vote for UNDEPLOYED) Undeployed still sounds a bit odd to me when paired with the word role. I could see deploying a workload bundle or something, but a role doesn't feel like a tangible thing that is pushed out somewhere. Unassigned? As in, it hasn't been assigned a role yet. * INSTANCE - A role deployed on a node - this is where work actually happens. I'm fine with instance, but the the phrasing a role deployed on a node feels odd to me in the same way undeployed does. Maybe a slight change to A node that has been assigned a role, but that also may be me being entirely too nit-picky. To put it in context, on a scale of 1-10, my objection to this and undeployed is around a 2, so don't let me come off as strenuously objecting. * DEPLOYMENT * SIZE THE ROLES - the act of deciding how many nodes will need to be assigned to each role * another option - DISTRIBUTE NODES (?) - (I think the former is more accurate, but perhaps there's a better way to say it?) * SCHEDULING - the process of deciding which role is deployed on which node I know this derives from a Nova term, but to me, the idea of scheduling carries a time-in-the-future connotation to it. The interesting part of what goes on here is the assignment of which roles go to which instances. * SERVICE CLASS - a further categorization within a service role for a particular deployment. I don't understand this one, can you add a few examples? See wireframes [1] page 19, says Compute Nodes which is the default service class. Box below Create New Compute Class serves to creation of new service class. Nodes in Service Classes are differentiated by Node Profiles. [1] http://people.redhat.com/~jcoufal/openstack/tripleo/2013-12-03_tripleo-ui_03-deployment.pdf http://people.redhat.com/%7Ejcoufal/openstack/tripleo/2013-12-03_tripleo-ui_03-deployment.pdf * NODE PROFILE - a set of requirements that specify what attributes a node must have in order to be mapped to a service class Even without knowing what service class is, I like this one. :) Does this seem accurate? All feedback is appreciated! Mainn Thanks again :D ___ 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 Jirka ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org
Re: [openstack-dev] [TripleO][Tuskar] Terminology
Thanks for all the replies so far! Let me try and distill the thread down to the points of interest and contention: 1) NODE vs INSTANCE This is a distinction that Robert brings up, and I think it's a good one that people agree with. The various ROLES can apply to either. What isn't clear to me (and it's orthogonal to this particular thread) is whether the wireframes are correct in classifying things by NODES, when it feels like we might want to classify things by INSTANCE? 2) UNDEPLOYED NODE - a node that has not been deployed with an instance Other suggestions included UNASSIGED, UNMAPPED, FREE, and AVAILABLE. Some people (I'm one of them) find AVAILABLE to be a bit of an overloaded term, as it can also be construed to mean that, say, a service instance is now running on a node and is now available for use. I'm in favor of an UN word, and it sounds like UNDEPLOYED was the most generally acceptable? 3) SIZE THE DEPLOYMENT - the act of deciding how many nodes will need to be assigned to each role in a deployment Other suggestions included SET NODE COUNT, DESIGN THE DEPLOYMENT, SIZE THE CLOUD. SIZE THE DEPLOYMENT sounds like the suggested option that used the most words from the other choices, so I picked it as a likely candidate :) I also like that it uses the word deployment, as that's what we're calling the end result. 4) SERVICE CLASS/RESOURCE CLASS/ROLE CONFIGURATION So, an example of this was KVM Compute is a role configuration. KVM compute(GPU) might be another I'm personally somewhat averse to role configuration. Although there are aspects of configuration to this, configuration seems somewhat misleading to me when the purpose of this classification is something more like - a subrole? 5) NODE PROFILE/FLAVOR Flavor seemed generally acceptable, although there was some mention of it being an overloaded term. Is there a case for using a more user-friendly term in the UI (like node profile or hardware configuration or. . .)? Or should we just expect users to be familiar with OpenStack terminology? Please feel free to correct me if I've left anything out or misrepresented anything! Mainn - Original Message - Hi, I'm trying to clarify the terminology being used for Tuskar, which may be helpful so that we're sure that we're all talking about the same thing :) I'm copying responses from the requirements thread and combining them with current requirements to try and create a unified view. Hopefully, we can come to a reasonably rapid consensus on any desired changes; once that's done, the requirements can be updated. * NODE a physical general purpose machine capable of running in many roles. Some nodes may have hardware layout that is particularly useful for a given role. * REGISTRATION - the act of creating a node in Ironic * ROLE - a specific workload we want to map onto one or more nodes. Examples include 'undercloud control plane', 'overcloud control plane', 'overcloud storage', 'overcloud compute' etc. * MANAGEMENT NODE - a node that has been mapped with an undercloud role * SERVICE NODE - a node that has been mapped with an overcloud role * COMPUTE NODE - a service node that has been mapped to an overcloud compute role * CONTROLLER NODE - a service node that has been mapped to an overcloud controller role * OBJECT STORAGE NODE - a service node that has been mapped to an overcloud object storage role * BLOCK STORAGE NODE - a service node that has been mapped to an overcloud block storage role * UNDEPLOYED NODE - a node that has not been mapped with a role * another option - UNALLOCATED NODE - a node that has not been allocated through nova scheduler (?) - (after reading lifeless's explanation, I agree that allocation may be a misleading term under TripleO, so I personally vote for UNDEPLOYED) * INSTANCE - A role deployed on a node - this is where work actually happens. * DEPLOYMENT * SIZE THE ROLES - the act of deciding how many nodes will need to be assigned to each role * another option - DISTRIBUTE NODES (?) - (I think the former is more accurate, but perhaps there's a better way to say it?) * SCHEDULING - the process of deciding which role is deployed on which node * SERVICE CLASS - a further categorization within a service role for a particular deployment. * NODE PROFILE - a set of requirements that specify what attributes a node must have in order to be mapped to a service class
Re: [openstack-dev] [TripleO][Tuskar] Terminology
Hi 2) UNDEPLOYED NODE - a node that has not been deployed with an instance Other suggestions included UNASSIGED, UNMAPPED, FREE, and AVAILABLE. Some people (I'm one of them) find AVAILABLE to be a bit of an overloaded term, as it can also be construed to mean that, say, a service instance is now running on a node and is now available for use. I'm in favor of an UN word, and it sounds like UNDEPLOYED was the most generally acceptable? Maybe unprovisioned would be a better description? Meaning the node has been discovered but not yet configured. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO][Tuskar] Terminology
On 12 December 2013 21:59, Jaromir Coufal jcou...@redhat.com wrote: On 2013/12/12 01:21, Robert Collins wrote: On 12 December 2013 08:15, Tzu-Mainn Chen tzuma...@redhat.com * MANAGEMENT NODE - a node that has been mapped with an undercloud role Pedantically, this is 'A node with an instance of a management role running on it'. I think calling it 'management node' is too sticky. What if we cold migrate it to another machine when a disk fails and we want to avoid dataloss if another disk were to fail? Management instance? I think the difference here is if I am looking on Nodes as HW stuff or if I am interested in services running on it. In the first case, I want to see 'Management Node', in the second case I want to see 'Management Instance'. So in the terms of Resources/Nodes it is valid to say 'Management Node'. mmm, I don't really agree, I mean, I agree that if you're looking at HW you want to look at Nodes. But we might migrate services between nodes while keeping the same instance. Nodes should only be surfaced when folk are actually addressing hardware IMO. * SERVICE NODE - a node that has been mapped with an overcloud role Again, the binding to node is too sticky IMNSHO. Service instance? Cloud instance? Same as above - depends on context of what I want to see. Service Instance is misleading. One service instance is for example nova-scheduler, not the whole node itself. I would avoid 'cloud' wording here. Service Node sounds fine for me, since the context is within Nodes/Resources. Avoiding cloud - ack. However, on instance - 'instance' is a very well defined term in Nova and thus OpenStack: Nova boot gets you an instance, nova delete gets rid of an instance, nova rebuild recreates it, etc. Instances run [virtual|baremetal] machines managed by a hypervisor. So nova-scheduler is not ever going to be confused with instance in the OpenStack space IMO. But it brings up a broader question, which is - what should we do when terms that are well defined in OpenStack - like Node, Instance, Flavor - are not so well defined for new users? We could use different terms, but that may confuse 'stackers, and will mean that our UI needs it's own dedicated terminology to map back to e.g. the manuals for Nova and Ironic. I'm inclined to suggest that as a principle, where there is a well defined OpenStack concept, that we use it, even if it is not ideal, because the consistency will be valuable. ... * BLOCK STORAGE NODE - a service node that has been mapped to an overcloud block storage role s/Node/instance/ ? Within deployment section, +1 for substitution. However with respect to my note above (service instance meaning). Yeah - but see above, I don't think there is room for confusion with e.g. nova-compute. However there may be room for confusion between instance-running-on-baremetal and instance-deployed-as-virt - but TBH I don't think that matters too much, if we go to docker or something in future, we'd have physical and container instances both serving stuff out, but it's not clear to me that we'd want to show these things up as separate at the top level. -1. Availability is very broad term and might mean various things. I can have assigned nodes with some role which are available for me - in terms of reachability for example. I vote for unallocated, unassigned, free? Free nodes works well IMO. It's a positive, direct statement. * INSTANCE - A role deployed on a node - this is where work actually happens. Yes. However this term is overloaded as well. Can we find something better? See above - it is, but I think something different would cause confusion, not reduce it. * DEPLOYMENT * SIZE THE ROLES - the act of deciding how many nodes will need to be assigned to each role * another option - DISTRIBUTE NODES (?) - (I think the former is more accurate, but perhaps there's a better way to say it?) Perhaps 'Size the cloud' ? How big do you want your cloud to be? * Design the deployment? (I am sorry for the aversion for 'cloud' - it's just used everywhere :)) I get that - thats fine. * SCHEDULING - the process of deciding which role is deployed on which node This possible should be a sub step of deployment. * SERVICE CLASS - a further categorization within a service role for a particular deployment. See the other thread where I suggested perhaps bringing the image + config aspects all the way up - I think that renames 'service class' to 'Role configuration'. KVM Compute is a role configuration. KVM compute(GPU) might be another. Role configuration sounds good to me. My only concern is - if/when we add multiple classes, role configuration doesn't sound accurate to me. Because Compute is a Role and if I have multiple Compute classes I feel it is still the same Role for me (Compute). Or would you expect it to be a different
[openstack-dev] [TripleO][Tuskar] Terminology
Hi, I'm trying to clarify the terminology being used for Tuskar, which may be helpful so that we're sure that we're all talking about the same thing :) I'm copying responses from the requirements thread and combining them with current requirements to try and create a unified view. Hopefully, we can come to a reasonably rapid consensus on any desired changes; once that's done, the requirements can be updated. * NODE a physical general purpose machine capable of running in many roles. Some nodes may have hardware layout that is particularly useful for a given role. * REGISTRATION - the act of creating a node in Ironic * ROLE - a specific workload we want to map onto one or more nodes. Examples include 'undercloud control plane', 'overcloud control plane', 'overcloud storage', 'overcloud compute' etc. * MANAGEMENT NODE - a node that has been mapped with an undercloud role * SERVICE NODE - a node that has been mapped with an overcloud role * COMPUTE NODE - a service node that has been mapped to an overcloud compute role * CONTROLLER NODE - a service node that has been mapped to an overcloud controller role * OBJECT STORAGE NODE - a service node that has been mapped to an overcloud object storage role * BLOCK STORAGE NODE - a service node that has been mapped to an overcloud block storage role * UNDEPLOYED NODE - a node that has not been mapped with a role * another option - UNALLOCATED NODE - a node that has not been allocated through nova scheduler (?) - (after reading lifeless's explanation, I agree that allocation may be a misleading term under TripleO, so I personally vote for UNDEPLOYED) * INSTANCE - A role deployed on a node - this is where work actually happens. * DEPLOYMENT * SIZE THE ROLES - the act of deciding how many nodes will need to be assigned to each role * another option - DISTRIBUTE NODES (?) - (I think the former is more accurate, but perhaps there's a better way to say it?) * SCHEDULING - the process of deciding which role is deployed on which node * SERVICE CLASS - a further categorization within a service role for a particular deployment. * NODE PROFILE - a set of requirements that specify what attributes a node must have in order to be mapped to a service class Does this seem accurate? All feedback is appreciated! 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] Terminology
On 11/12/13 14:15 -0500, Tzu-Mainn Chen wrote: Hi, I'm trying to clarify the terminology being used for Tuskar, which may be helpful so that we're sure that we're all talking about the same thing :) I'm copying responses from the requirements thread and combining them with current requirements to try and create a unified view. Hopefully, we can come to a reasonably rapid consensus on any desired changes; once that's done, the requirements can be updated. * NODE a physical general purpose machine capable of running in many roles. Some nodes may have hardware layout that is particularly useful for a given role. * REGISTRATION - the act of creating a node in Ironic * ROLE - a specific workload we want to map onto one or more nodes. Examples include 'undercloud control plane', 'overcloud control plane', 'overcloud storage', 'overcloud compute' etc. * MANAGEMENT NODE - a node that has been mapped with an undercloud role * SERVICE NODE - a node that has been mapped with an overcloud role * COMPUTE NODE - a service node that has been mapped to an overcloud compute role * CONTROLLER NODE - a service node that has been mapped to an overcloud controller role * OBJECT STORAGE NODE - a service node that has been mapped to an overcloud object storage role * BLOCK STORAGE NODE - a service node that has been mapped to an overcloud block storage role * UNDEPLOYED NODE - a node that has not been mapped with a role * another option - UNALLOCATED NODE - a node that has not been allocated through nova scheduler (?) - (after reading lifeless's explanation, I agree that allocation may be a misleading term under TripleO, so I personally vote for UNDEPLOYED) * INSTANCE - A role deployed on a node - this is where work actually happens. * DEPLOYMENT * SIZE THE ROLES - the act of deciding how many nodes will need to be assigned to each role * another option - DISTRIBUTE NODES (?) - (I think the former is more accurate, but perhaps there's a better way to say it?) * SCHEDULING - the process of deciding which role is deployed on which node * SERVICE CLASS - a further categorization within a service role for a particular deployment. * NODE PROFILE - a set of requirements that specify what attributes a node must have in order to be mapped to a service class Does this seem accurate? All feedback is appreciated! Mainn Thanks for doing this! Presumably this is going to go on a wiki where we can look at it forever and ever? -- Jordan O'Mara jomara at redhat.com Red Hat Engineering, Raleigh pgpn_aW3DEuC0.pgp Description: PGP signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO][Tuskar] Terminology
Hi, I'm trying to clarify the terminology being used for Tuskar, which may be helpful so that we're sure that we're all talking about the same thing :) I'm copying responses from the requirements thread and combining them with current requirements to try and create a unified view. Hopefully, we can come to a reasonably rapid consensus on any desired changes; once that's done, the requirements can be updated. * NODE a physical general purpose machine capable of running in many roles. Some nodes may have hardware layout that is particularly useful for a given role. * REGISTRATION - the act of creating a node in Ironic * ROLE - a specific workload we want to map onto one or more nodes. Examples include 'undercloud control plane', 'overcloud control plane', 'overcloud storage', 'overcloud compute' etc. * MANAGEMENT NODE - a node that has been mapped with an undercloud role * SERVICE NODE - a node that has been mapped with an overcloud role * COMPUTE NODE - a service node that has been mapped to an overcloud compute role * CONTROLLER NODE - a service node that has been mapped to an overcloud controller role * OBJECT STORAGE NODE - a service node that has been mapped to an overcloud object storage role * BLOCK STORAGE NODE - a service node that has been mapped to an overcloud block storage role * UNDEPLOYED NODE - a node that has not been mapped with a role * another option - UNALLOCATED NODE - a node that has not been allocated through nova scheduler (?) - (after reading lifeless's explanation, I agree that allocation may be a misleading term under TripleO, so I personally vote for UNDEPLOYED) * INSTANCE - A role deployed on a node - this is where work actually happens. * DEPLOYMENT * SIZE THE ROLES - the act of deciding how many nodes will need to be assigned to each role * another option - DISTRIBUTE NODES (?) - (I think the former is more accurate, but perhaps there's a better way to say it?) * SCHEDULING - the process of deciding which role is deployed on which node * SERVICE CLASS - a further categorization within a service role for a particular deployment. * NODE PROFILE - a set of requirements that specify what attributes a node must have in order to be mapped to a service class Does this seem accurate? All feedback is appreciated! Mainn Thanks for doing this! Presumably this is going to go on a wiki where we can look at it forever and ever? Yep, if consensus is reached, I'd replace the current tuskar glossary on the wiki with this (as well as update the requirements). Mainn -- Jordan O'Mara jomara at redhat.com Red Hat Engineering, Raleigh ___ 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] Terminology
So glad we're hashing this out now. This will save a bunch of headaches in the future. Good call pushing this forward. On 12/11/2013 02:15 PM, Tzu-Mainn Chen wrote: Hi, I'm trying to clarify the terminology being used for Tuskar, which may be helpful so that we're sure that we're all talking about the same thing :) I'm copying responses from the requirements thread and combining them with current requirements to try and create a unified view. Hopefully, we can come to a reasonably rapid consensus on any desired changes; once that's done, the requirements can be updated. * NODE a physical general purpose machine capable of running in many roles. Some nodes may have hardware layout that is particularly useful for a given role. Do we ever need to distinguish between undercloud and overcloud nodes? * REGISTRATION - the act of creating a node in Ironic DISCOVERY - The act of having nodes found auto-magically and added to Ironic with minimal user intervention. * ROLE - a specific workload we want to map onto one or more nodes. Examples include 'undercloud control plane', 'overcloud control plane', 'overcloud storage', 'overcloud compute' etc. * MANAGEMENT NODE - a node that has been mapped with an undercloud role * SERVICE NODE - a node that has been mapped with an overcloud role * COMPUTE NODE - a service node that has been mapped to an overcloud compute role * CONTROLLER NODE - a service node that has been mapped to an overcloud controller role * OBJECT STORAGE NODE - a service node that has been mapped to an overcloud object storage role * BLOCK STORAGE NODE - a service node that has been mapped to an overcloud block storage role * UNDEPLOYED NODE - a node that has not been mapped with a role * another option - UNALLOCATED NODE - a node that has not been allocated through nova scheduler (?) - (after reading lifeless's explanation, I agree that allocation may be a misleading term under TripleO, so I personally vote for UNDEPLOYED) Undeployed still sounds a bit odd to me when paired with the word role. I could see deploying a workload bundle or something, but a role doesn't feel like a tangible thing that is pushed out somewhere. Unassigned? As in, it hasn't been assigned a role yet. * INSTANCE - A role deployed on a node - this is where work actually happens. I'm fine with instance, but the the phrasing a role deployed on a node feels odd to me in the same way undeployed does. Maybe a slight change to A node that has been assigned a role, but that also may be me being entirely too nit-picky. To put it in context, on a scale of 1-10, my objection to this and undeployed is around a 2, so don't let me come off as strenuously objecting. * DEPLOYMENT * SIZE THE ROLES - the act of deciding how many nodes will need to be assigned to each role * another option - DISTRIBUTE NODES (?) - (I think the former is more accurate, but perhaps there's a better way to say it?) * SCHEDULING - the process of deciding which role is deployed on which node I know this derives from a Nova term, but to me, the idea of scheduling carries a time-in-the-future connotation to it. The interesting part of what goes on here is the assignment of which roles go to which instances. * SERVICE CLASS - a further categorization within a service role for a particular deployment. I don't understand this one, can you add a few examples? * NODE PROFILE - a set of requirements that specify what attributes a node must have in order to be mapped to a service class Even without knowing what service class is, I like this one. :) Does this seem accurate? All feedback is appreciated! Mainn Thanks again :D ___ 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] Terminology
This is really helpful, thanks for pulling it together. comment inline... On Wed, Dec 11, 2013 at 2:15 PM, Tzu-Mainn Chen tzuma...@redhat.com wrote: * NODE a physical general purpose machine capable of running in many roles. Some nodes may have hardware layout that is particularly useful for a given role. * REGISTRATION - the act of creating a node in Ironic * ROLE - a specific workload we want to map onto one or more nodes. Examples include 'undercloud control plane', 'overcloud control plane', 'overcloud storage', 'overcloud compute' etc. * MANAGEMENT NODE - a node that has been mapped with an undercloud role * SERVICE NODE - a node that has been mapped with an overcloud role * COMPUTE NODE - a service node that has been mapped to an overcloud compute role * CONTROLLER NODE - a service node that has been mapped to an overcloud controller role * OBJECT STORAGE NODE - a service node that has been mapped to an overcloud object storage role * BLOCK STORAGE NODE - a service node that has been mapped to an overcloud block storage role * UNDEPLOYED NODE - a node that has not been mapped with a role This begs the question (for me anyway), why not call it UNMAPPED NODE? If not, can we s/mapped/deployed in the descriptions above instead? It might make sense then to define mapped and deployed in technical terms as well. Is mapped just the act of associating a node with a role in the UI, or does it mean that bits have actually been transferred across the wire to the node's disk and it's now running? * another option - UNALLOCATED NODE - a node that has not been allocated through nova scheduler (?) - (after reading lifeless's explanation, I agree that allocation may be a misleading term under TripleO, so I personally vote for UNDEPLOYED) * INSTANCE - A role deployed on a node - this is where work actually happens. * DEPLOYMENT * SIZE THE ROLES - the act of deciding how many nodes will need to be assigned to each role * another option - DISTRIBUTE NODES (?) - (I think the former is more accurate, but perhaps there's a better way to say it?) * SCHEDULING - the process of deciding which role is deployed on which node * SERVICE CLASS - a further categorization within a service role for a particular deployment. * NODE PROFILE - a set of requirements that specify what attributes a node must have in order to be mapped to a service class -- -- James Slagle -- ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO][Tuskar] Terminology
On Wed Dec 11 14:15:22 2013, Tzu-Mainn Chen wrote: Hi, I'm trying to clarify the terminology being used for Tuskar, which may be helpful so that we're sure that we're all talking about the same thing :) I'm copying responses from the requirements thread and combining them with current requirements to try and create a unified view. Hopefully, we can come to a reasonably rapid consensus on any desired changes; once that's done, the requirements can be updated. Your mail client seems to wrap lines awkwardly, well past the standard length. Just seems kinda odd. * UNDEPLOYED NODE - a node that has not been mapped with a role * another option - UNALLOCATED NODE - a node that has not been allocated through nova scheduler (?) - (after reading lifeless's explanation, I agree that allocation may be a misleading term under TripleO, so I personally vote for UNDEPLOYED) Not to muddy the waters further, but 'undeployed' sounds a little bit to me like the node was deployed, and then we un-deployed it. I think 'nondeployed' eliminates that, but makes it sound fairly odd. I like James' unmapped, FWIW. Though I guess it leaves the same ambiguity about whether it was mapped and then un-mapped, or if it's yet to be mapped. * SIZE THE ROLES - the act of deciding how many nodes will need to be assigned to each role * another option - DISTRIBUTE NODES (?) - (I think the former is more accurate, but perhaps there's a better way to say it?) I don't love 'size the roles', though I'm not sure that 'distribute' has the same meaning. If I didn't already know what you meant, and you asked me what 'size the nodes' meant, I'd assume it was about the size of a given instance -- e.g., does node X need 2GB RAM or should I give it 4GB? What you're really doing is setting the 'count' of nodes, right? Set Node Count? (I don't love that particular phrasing either, but it seems more accurate/precise.) Does this seem accurate? All feedback is appreciated! Thanks for starting this discussing, Mainn. I agree with the others that it's a good idea to get this stuff nailed down early on. -- Matt Wagner Software Engineer, Red Hat signature.asc Description: OpenPGP digital signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO][Tuskar] Terminology
On 12 December 2013 08:15, Tzu-Mainn Chen tzuma...@redhat.com wrote: Hi, I'm trying to clarify the terminology being used for Tuskar, which may be helpful so that we're sure that we're all talking about the same thing :) I'm copying responses from the requirements thread and combining them with current requirements to try and create a unified view. Hopefully, we can come to a reasonably rapid consensus on any desired changes; once that's done, the requirements can be updated. * NODE a physical general purpose machine capable of running in many roles. Some nodes may have hardware layout that is particularly useful for a given role. * REGISTRATION - the act of creating a node in Ironic * ROLE - a specific workload we want to map onto one or more nodes. Examples include 'undercloud control plane', 'overcloud control plane', 'overcloud storage', 'overcloud compute' etc. * MANAGEMENT NODE - a node that has been mapped with an undercloud role Pedantically, this is 'A node with an instance of a management role running on it'. I think calling it 'management node' is too sticky. What if we cold migrate it to another machine when a disk fails and we want to avoid dataloss if another disk were to fail? Management instance? * SERVICE NODE - a node that has been mapped with an overcloud role Again, the binding to node is too sticky IMNSHO. Service instance? Cloud instance? * COMPUTE NODE - a service node that has been mapped to an overcloud compute role * CONTROLLER NODE - a service node that has been mapped to an overcloud controller role * OBJECT STORAGE NODE - a service node that has been mapped to an overcloud object storage role * BLOCK STORAGE NODE - a service node that has been mapped to an overcloud block storage role s/Node/instance/ ? * UNDEPLOYED NODE - a node that has not been mapped with a role * another option - UNALLOCATED NODE - a node that has not been allocated through nova scheduler (?) - (after reading lifeless's explanation, I agree that allocation may be a misleading term under TripleO, so I personally vote for UNDEPLOYED) I like 'available' because it is a direct statement that doesn't depend on how things are utilised - mapping or allocation or deployment or whatever. It is available for us to do something with it. 'Available nodes'. * INSTANCE - A role deployed on a node - this is where work actually happens. * DEPLOYMENT * SIZE THE ROLES - the act of deciding how many nodes will need to be assigned to each role * another option - DISTRIBUTE NODES (?) - (I think the former is more accurate, but perhaps there's a better way to say it?) Perhaps 'Size the cloud' ? How big do you want your cloud to be? * SCHEDULING - the process of deciding which role is deployed on which node This possible should be a sub step of deployment. * SERVICE CLASS - a further categorization within a service role for a particular deployment. See the other thread where I suggested perhaps bringing the image + config aspects all the way up - I think that renames 'service class' to 'Role configuration'. KVM Compute is a role configuration. KVM compute(GPU) might be another. * NODE PROFILE - a set of requirements that specify what attributes a node must have in order to be mapped to a service class Today the implementation at the plumbing layer can only do 'flavour', though Heat is open to letting us to 'find an instance from any of X flavors' in future. Lets not be -too- generic: 'Flavor': The Nova description of a particular machine configuration, and choosing one is part of setting up the 'role configuration'. Thanks for drafting this! -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
