Open Stack

Hi Mark,

thanks for your insight, I mostly agree. Just few points below.

On 2013/27/11 21:54, Mark McLoughlin wrote:
> Hi Jarda,
...
> Yes, I buy this. And I think it's the point worth dwelling on.
>
> It would be quite a bit of work to substantiate the point with hard data
> - e.g. doing user testing of mockups with and without placement control
> - so we have to at least try to build some consensus without that.
I agree here. It will be a lot of work. I'd love to have that, but 
creating distinct designs, finding users for real testing and testing 
with them will consume big amount of time and in this agile approach we 
can't afford it.

I believe that we are not very distinct in our goals and that we can get 
to consensus without that.

There was smaller confusion which I tried to clarify in answer to Rob's 
response.

> We could do some work on a more detailed description of the persona and
> their basic goals. This would clear up whether we're designing for the
> case where one persona owns the undercloud and there's another overcloud
> operator persona.
Yes, we need to have this written down. Or at least get to consensus if 
we can quickly get there and document it then. Whatever works and 
doesn't block us.

> We could also look at other tools targeted to similar use cases and see
> what they do.
I looked and they all do it very manual way. (or at least those which I 
have seen from Mirantis, Huawei, etc) - and there is some reason for 
this. As I wrote into Robert's answer, we can do much more, we can be 
smart, but we can't think that we are the smartest.

> But yeah - my instinct is that all of that would show that we'd be
> fighting an uphill battle to persuade our users that this type of magic
> is what they want.
That's exactly my point. Thanks for saying that.

We want to help them and feed them with ready-to-deploy solution. But 
they need to have feeling that they have things under control (maybe 
just check the solution and/or allow to change).

> ...
>> === Implementation ===
>>
>> Above mentioned approach shouldn't lead to reimplementing scheduler. We
>> can still use nova-scheduler, but we can take advantage of extra params
>> (like unique identifier), so that we specify more concretely what goes
>> where.
> It's hard to see how what you describe doesn't ultimately mean we
> completely by pass the Nova scheduler. Yes, if you request placement on
> a specific node, it does still go through the scheduler ... but it
> doesn't do any actual scheduling.
>
> Maybe we should separate the discussion/design around control nodes and
> resource (i.e. compute/storage) nodes. Mostly because there should be a
> large ratio of the latter to the former, so you'd expect it to be less
> likely for such fine grained control over resource nodes to be useful.
>
> e.g. maybe adding more compute nodes doesn't involve the user doing any
> placement, and we just let the nova scheduler choose from the available
> nodes which are suitable for compute workloads.
Yes, controller nodes will need to get better treatment, but I think not 
in our first steps. I believe that for now we are fine with going with 
generic controller node which is running all controller services.

I think what would be great to have is to let nova-scheduler to do its 
job (dry-run), show the distribution and just confirm (or do some change 
in there).

-- Jarda
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131128/e6d27545/attachment.html>