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
34 matches
Mail list logo