<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#333333">
Hi Mark,<br>
<br>
thanks for your insight, I mostly agree. Just few points below.<br>
<br>
<div class="moz-cite-prefix">On 2013/27/11 21:54, Mark McLoughlin
wrote:<br>
</div>
<blockquote cite="mid:1385585698.9695.69.camel@sorcha" type="cite">
<pre wrap="">Hi Jarda,
</pre>
</blockquote>
...
<blockquote cite="mid:1385585698.9695.69.camel@sorcha" type="cite">
<pre wrap="">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.</pre>
</blockquote>
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.<br>
<br>
I believe that we are not very distinct in our goals and that we can
get to consensus without that.<br>
<br>
There was smaller confusion which I tried to clarify in answer to
Rob's response.<br>
<br>
<blockquote cite="mid:1385585698.9695.69.camel@sorcha" type="cite">
<pre wrap="">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.</pre>
</blockquote>
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.<br>
<br>
<blockquote cite="mid:1385585698.9695.69.camel@sorcha" type="cite">
<pre wrap="">We could also look at other tools targeted to similar use cases and see
what they do.</pre>
</blockquote>
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.<br>
<br>
<blockquote cite="mid:1385585698.9695.69.camel@sorcha" type="cite">
<pre wrap="">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.</pre>
</blockquote>
That's exactly my point. Thanks for saying that.<br>
<br>
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).<br>
<br>
<blockquote cite="mid:1385585698.9695.69.camel@sorcha" type="cite">
<pre wrap="">...
</pre>
<blockquote type="cite">
<pre wrap="">=== 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.
</pre>
</blockquote>
<pre wrap="">
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.</pre>
</blockquote>
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.<br>
<br>
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).<br>
<br>
-- Jarda<br>
</body>
</html>