[Openstack-operators] [nova][ironic][scheduler][placement] IMPORTANT: Getting rid of the automated reschedule functionality

Curtis serverascode at gmail.com
Tue May 23 20:09:57 UTC 2017


On Tue, May 23, 2017 at 1:20 PM, Edward Leafe <ed at leafe.com> wrote:
> On May 23, 2017, at 1:27 PM, James Penick <jpenick at gmail.com> wrote:
>
>>  Perhaps this is a place where the TC and Foundation should step in and foster the existence of a porcelain API. Either by constructing something new, or by growing Nova into that thing.
>
>
> Oh please, not Nova. The last word that comes to mind when thinking about Nova code is “porcelain”.
>

I keep seeing the word "porcelain", but I'm not sure what it means in
this context. Could someone help me out here and explain what that is?
:)

For my $0.02 as an operator, most of the time I see retries they are
all failures, but I haven't run as big of clouds as a lot of people on
this list. I have certainly seen IPMI fail intermittently (I have a
script that logs in to a bunch of service processors and restarts
them) and would very much like to use Ironic to manage large pools of
baremetal nodes, so I could see that being an issue.

As a user of cloud resources though I always use some kind of
automation tooling with some form of looping for retries, but that
it's not always easy to get customers/users to use that kind of
tooling. For NFV workloads/clouds there almost always be some kind of
higher level abstraction (eg. as mentioned MANO) managing the
resources and it can retry (thought not all of them actually have that
functionality...yet).

So, as an operator and a user, I would personally be Ok with Nova
retries if it significantly adds to the complexity of Nova. I
certainly would not abandon Ironic if Nova didn't retry. I do wonder
what custom code might be required in say a public cloud providing
Ironic nodes though.

Thanks,
Curtis.

>
> -- Ed Leafe
>
>
>
>
>
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators



More information about the OpenStack-operators mailing list