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
