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
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 deploy
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 s
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 pla
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 a
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 out
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 f
- 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
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 No
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
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
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
- 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 g
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 st
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 (
> 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
> >> Co
> 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
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 specif
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
>> deplo
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
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 Con
> > 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
- 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 O
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 w
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 re
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
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 Com
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 Com
> 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 th
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
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 Cate
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 in
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 (= Res
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 representatio
On Wed, Dec 18, 2013 at 10:44:46AM +0100, Ladislav Smola wrote:
> On 12/17/2013 04:20 PM, Tzu-Mainn Chen wrote:
> >>On 2013/13/12 23:11, Jordan OMara wrote:
> >>>On 13/12/13 16:20 +1300, Robert Collins wrote:
> However, on instance - 'instance' is a very well defined term in Nova
> and thus
On 12/17/2013 04:20 PM, Tzu-Mainn Chen wrote:
On 2013/13/12 23:11, Jordan OMara wrote:
On 13/12/13 16:20 +1300, Robert Collins wrote:
However, on instance - 'instance' is a very well defined term in Nova
and thus OpenStack: Nova boot gets you an instance, nova delete gets
rid of an instance, no
> On 2013/13/12 23:11, Jordan OMara wrote:
> > On 13/12/13 16:20 +1300, Robert Collins wrote:
> >> However, on instance - 'instance' is a very well defined term in Nova
> >> and thus OpenStack: Nova boot gets you an instance, nova delete gets
> >> rid of an instance, nova rebuild recreates it, etc.
On 2013/13/12 23:11, Jordan OMara wrote:
On 13/12/13 16:20 +1300, Robert Collins wrote:
However, on instance - 'instance' is a very well defined term in Nova
and thus OpenStack: Nova boot gets you an instance, nova delete gets
rid of an instance, nova rebuild recreates it, etc. Instances run
[
> Thanks Mainn, comments inline :)
>
> On Fri, 2013-12-13 at 19:31 -0500, Tzu-Mainn Chen wrote:
> > Thanks for the reply! Let me try and address one particular section for
> > now,
> > since it seems to be the part causing the most confusion:
> >
> > > > * SERVICE CLASS - a further categori
Thanks Mainn, comments inline :)
On Fri, 2013-12-13 at 19:31 -0500, Tzu-Mainn Chen wrote:
> Thanks for the reply! Let me try and address one particular section for now,
> since it seems to be the part causing the most confusion:
>
> > > * SERVICE CLASS - a further categorization within a se
Thanks for the reply! Let me try and address one particular section for now,
since it seems to be the part causing the most confusion:
> > * SERVICE CLASS - a further categorization within a service role for a
> > particular deployment.
> >
> > * NODE PROFILE - a set of requi
On Wed, 2013-12-11 at 14:15 -0500, Tzu-Mainn Chen wrote:
> Hi,
>
> I'm trying to clarify the terminology being used for Tuskar, which may be
> helpful so that we're sure
> that we're all talking about the same thing :) I'm copying responses from
> the requirements thread
> and combining them wi
On 13/12/13 16:20 +1300, Robert Collins wrote:
On 12 December 2013 21:59, Jaromir Coufal wrote:
On 2013/12/12 01:21, Robert Collins wrote:
Avoiding cloud - ack.
However, on instance - 'instance' is a very well defined term in Nova
and thus OpenStack: Nova boot gets you an instance, nova de
On 12 December 2013 21:59, Jaromir Coufal wrote:
> On 2013/12/12 01:21, Robert Collins wrote:
>>
>> On 12 December 2013 08:15, Tzu-Mainn Chen >>
>>> * MANAGEMENT NODE - a node that has been mapped with an
>>> undercloud role
>>
>>
>> Pedantically, this is 'A node with an instance of a ma
Hi
2) UNDEPLOYED NODE - a node that has not been deployed with an instance
>
> Other suggestions included UNASSIGED, UNMAPPED, FREE, and AVAILABLE.
> Some people (I'm one of them)
> find AVAILABLE to be a bit of an overloaded term, as it can also be
> construed to mean that, say,
> a service ins
Thanks for all the replies so far! Let me try and distill the thread down to
the points of
interest and contention:
1) NODE vs INSTANCE
This is a distinction that Robert brings up, and I think it's a good one that
people agree
with. The various ROLES can apply to either.
What isn't clear to
On 12/11/2013 08:54 PM, Jay Dobies wrote:
So glad we're hashing this out now. This will save a bunch of
headaches in the future. Good call pushing this forward.
On 12/11/2013 02:15 PM, Tzu-Mainn Chen wrote:
Hi,
I'm trying to clarify the terminology being used for Tuskar, which
may be helpf
On 12/11/2013 08:59 PM, James Slagle wrote:
This is really helpful, thanks for pulling it together.
comment inline...
On Wed, Dec 11, 2013 at 2:15 PM, Tzu-Mainn Chen wrote:
* NODE a physical general purpose machine capable of running in many roles.
Some nodes may have hardware layout that is
On 2013/12/12 01:21, Robert Collins wrote:
On 12 December 2013 08:15, Tzu-Mainn Chen
* MANAGEMENT NODE - a node that has been mapped with an undercloud
role
Pedantically, this is 'A node with an instance of a management role
running on it'. I think calling it 'management node' is to
On 12 December 2013 08:15, Tzu-Mainn Chen wrote:
> Hi,
>
> I'm trying to clarify the terminology being used for Tuskar, which may be
> helpful so that we're sure
> that we're all talking about the same thing :) I'm copying responses from
> the requirements thread
> and combining them with curre
On Wed Dec 11 14:15:22 2013, Tzu-Mainn Chen wrote:
> Hi,
>
> I'm trying to clarify the terminology being used for Tuskar, which
> may be helpful so that we're sure that we're all talking about the
> same thing :) I'm copying responses from the requirements thread and
> combining them with current
This is really helpful, thanks for pulling it together.
comment inline...
On Wed, Dec 11, 2013 at 2:15 PM, Tzu-Mainn Chen wrote:
> * NODE a physical general purpose machine capable of running in many roles.
> Some nodes may have hardware layout that is particularly
>useful for a given r
So glad we're hashing this out now. This will save a bunch of headaches
in the future. Good call pushing this forward.
On 12/11/2013 02:15 PM, Tzu-Mainn Chen wrote:
Hi,
I'm trying to clarify the terminology being used for Tuskar, which may be
helpful so that we're sure
that we're all talkin
> >Hi,
> >
> >I'm trying to clarify the terminology being used for Tuskar, which may be
> >helpful so that we're sure
> >that we're all talking about the same thing :) I'm copying responses from
> >the requirements thread
> >and combining them with current requirements to try and create a unified
On 11/12/13 14:15 -0500, Tzu-Mainn Chen wrote:
Hi,
I'm trying to clarify the terminology being used for Tuskar, which may be
helpful so that we're sure
that we're all talking about the same thing :) I'm copying responses from the
requirements thread
and combining them with current requirement
Hi,
I'm trying to clarify the terminology being used for Tuskar, which may be
helpful so that we're sure
that we're all talking about the same thing :) I'm copying responses from the
requirements thread
and combining them with current requirements to try and create a unified view.
Hopefully,
56 matches
Mail list logo
