Re: [openstack-dev] [TripleO] [Tuskar] Terminology Revival #1 - Roles

2014-01-28 Thread Jay Dobies



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

2014-01-28 Thread Jay Pipes
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

2014-01-28 Thread Tzu-Mainn Chen
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

2014-01-28 Thread Jason Rist
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

2014-01-28 Thread Tzu-Mainn Chen
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

2014-01-27 Thread Tzu-Mainn Chen
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

2014-01-27 Thread Jaromir Coufal
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

2014-01-23 Thread Tzu-Mainn Chen


- Original Message -
> On 23 January 2014 21:39, Jaromir Coufal  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 Instance 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 Instance 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 
> 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

2014-01-23 Thread Radomir Dopieralski
On 23/01/14 10:46, Robert Collins wrote:
> On 22 January 2014 12:05, Liz Blanchard  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.

Instance Role then?

We could also have Instance Category, Instance Kind, Instance Purpose,
Instance Assignment, Instance Genre, Instance Class...

-- 
Radomir Dopieralski


___
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

2014-01-23 Thread Robert Collins
On 23 January 2014 21:39, Jaromir Coufal  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 
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

2014-01-23 Thread Robert Collins
On 22 January 2014 12:05, Liz Blanchard  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 
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

2014-01-23 Thread Jaromir Coufal

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

2014-01-22 Thread Tzu-Mainn Chen


- 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


Re: [openstack-dev] [TripleO] [Tuskar] Terminology Revival #1 - Roles

2014-01-22 Thread Liz Blanchard

On Jan 22, 2014, at 10:53 AM, Jaromir Coufal  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

2014-01-22 Thread Jaromir Coufal

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

2014-01-22 Thread Tzu-Mainn Chen
> On Jan 22, 2014, at 4:02 AM, 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?
> 
> 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

2014-01-22 Thread Tzu-Mainn Chen
> On Jan 22, 2014, at 7:09 AM, Jaromir Coufal  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

2014-01-22 Thread Liz Blanchard

On Jan 22, 2014, at 7:09 AM, Jaromir Coufal  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

2014-01-22 Thread Liz Blanchard

On Jan 22, 2014, at 9:52 AM, Dougal Matthews  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

2014-01-22 Thread Liz Blanchard

On Jan 22, 2014, at 4:02 AM, 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?

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

2014-01-22 Thread Dougal Matthews

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

2014-01-22 Thread Tzu-Mainn Chen
> > 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

2014-01-22 Thread Tzu-Mainn Chen


- 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

2014-01-22 Thread Tzu-Mainn Chen
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

2014-01-22 Thread Oleg Gelbukh
Hello, Jaromir

On Wed, Jan 22, 2014 at 4:09 PM, Jaromir Coufal  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

2014-01-22 Thread Jaromir Coufal



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

2014-01-22 Thread Jaromir Coufal



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

2014-01-22 Thread Jaromir Coufal



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

2014-01-21 Thread Tzu-Mainn Chen
> On Jan 21, 2014, at 9:40 AM, Dougal Matthews  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 Revival #1 - Roles

2014-01-21 Thread Liz Blanchard

On Jan 21, 2014, at 9:40 AM, Dougal Matthews  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

2014-01-21 Thread Jay Dobies

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.


I'd further disagree that the resource category is a group of nodes. 
It's a *definition* of what can be put onto a node. Then there will be 
nodes who are deployed with that resource category. The nodes themselves 
aren't part of the category, they just, for lack of a better term, use it.



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


There's also likely a versioning component that we haven't fully figured 
out yet.



So far suggested terms:
* Role *
- short name - plus points
- quite overloaded term (user role, etc)


Role immediately conjures up auth-related concepts in my head, so I 
think it has too many existing connotations to be used here.



* 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.


More than most people I've complained about having to type our "resource 
category" and my abbreviation of "res cat" is kinda lame. That said, I 
don't have any other ideas so by default I'm for sticking with what we 
have.  :D




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




___
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

2014-01-21 Thread Dougal Matthews

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

2014-01-21 Thread Tzu-Mainn Chen
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