On Tue, May 23, 2017 at 1:20 PM, Edward Leafe <[email protected]> wrote: > On May 23, 2017, at 1:27 PM, James Penick <[email protected]> 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 > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators _______________________________________________ OpenStack-operators mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
