Open Stack

On Mon, Oct 1, 2018 at 10:13 AM Jay Pipes <jaypipes at gmail.com> wrote:

> On 10/01/2018 09:01 AM, Jim Rollenhagen wrote:
> > On Mon, Oct 1, 2018 at 8:03 AM Jay Pipes <jaypipes at gmail.com
> > <mailto:jaypipes at gmail.com>> wrote:
> >
> >     On 10/01/2018 04:36 AM, John Garbutt wrote:
> >      > On Fri, 28 Sep 2018 at 00:46, Jay Pipes <jaypipes at gmail.com
> >     <mailto:jaypipes at gmail.com>
> >      > <mailto:jaypipes at gmail.com <mailto:jaypipes at gmail.com>>> wrote:
> >      >
> >      >     On 09/27/2018 06:23 PM, Matt Riedemann wrote:
> >      >      > On 9/27/2018 3:02 PM, Jay Pipes wrote:
> >      >      >> A great example of this would be the proposed "deploy
> >     template"
> >      >     from
> >      >      >> [2]. This is nothing more than abusing the placement
> >     traits API in
> >      >      >> order to allow passthrough of instance configuration data
> >     from the
> >      >      >> nova flavor extra spec directly into the
> nodes.instance_info
> >      >     field in
> >      >      >> the Ironic database. It's a hack that is abusing the
> entire
> >      >     concept of
> >      >      >> the placement traits concept, IMHO.
> >      >      >>
> >      >      >> We should have a way *in Nova* of allowing instance
> >     configuration
> >      >      >> key/value information to be passed through to the virt
> >     driver's
> >      >      >> spawn() method, much the same way we provide for
> >     user_data that
> >      >     gets
> >      >      >> exposed after boot to the guest instance via configdrive
> >     or the
> >      >      >> metadata service API. What this deploy template thing is
> >     is just a
> >      >      >> hack to get around the fact that nova doesn't have a
> >     basic way of
> >      >      >> passing through some collated instance configuration
> >     key/value
> >      >      >> information, which is a darn shame and I'm really kind of
> >      >     annoyed with
> >      >      >> myself for not noticing this sooner. :(
> >      >      >
> >      >      > We talked about this in Dublin through right? We said a
> good
> >      >     thing to do
> >      >      > would be to have some kind of
> template/profile/config/whatever
> >      >     stored
> >      >      > off in glare where schema could be registered on that
> >     thing, and
> >      >     then
> >      >      > you pass a handle (ID reference) to that to nova when
> >     creating the
> >      >      > (baremetal) server, nova pulls it down from glare and
> hands it
> >      >     off to
> >      >      > the virt driver. It's just that no one is doing that work.
> >      >
> >      >     No, nobody is doing that work.
> >      >
> >      >     I will if need be if it means not hacking the placement API
> >     to serve
> >      >     this purpose (for which it wasn't intended).
> >      >
> >      >
> >      > Going back to the point Mark Goddard made, there are two things
> here:
> >      >
> >      > 1) Picking the correct resource provider
> >      > 2) Telling Ironic to transform the picked node in some way
> >      >
> >      > Today we allow the use Capabilities for both.
> >      >
> >      > I am suggesting we move to using Traits only for (1), leaving (2)
> in
> >      > place for now, while we decide what to do (i.e. future of "deploy
> >      > template" concept).
> >      >
> >      > It feels like Ironic's plan to define the "deploy templates" in
> >     Ironic
> >      > should replace the dependency on Glare for this use case, largely
> >      > because the definition of the deploy template (in my mind) is very
> >      > heavily related to inspector and driver properties, etc. Mark is
> >     looking
> >      > at moving that forward at the moment.
> >
> >     That won't do anything about the flavor explosion problem, though,
> >     right
> >     John?
> >
> >
> > Does nova still plan to allow passing additional desired traits into the
> > server create request?
> > I (we?) was kind of banking on that to solve the Baskin Robbins thing.
>
> That's precisely what I've been looking into.


Right, well aware of that.


> From what I can tell,
> Ironic was planning on using these CUSTOM_DEPLOY_TEMPLATE_XXX traits in
> two ways:
>
> 1) To tell Nova what scheduling constraints the instance needed -- e.g.
> "hey Nova, make sure I land on a node that supports UEFI boot mode
> because my boot image relies on that".
>
> 2) As a convenient (because it would require no changes to Nova) way of
> passing instance pre-spawn configuration data to the Ironic virt driver
> -- e.g. pass the entire set of traits that are in the RequestSpec's
> flavor and image extra specs to Ironic before calling the Ironic node
> provision API.
>
> #1 is fine IMHO, since it (mostly) represents a "capability" that the
> resource provider (the Ironic baremetal node) must support in order for
> the instance to successfully boot.
>

This is the sort of thing I want to initially target. I understand the
deploy templates thing proposes solving both #1 and #2, but I want to back
up a bit.

So say the user requests a node that supports UEFI because their image
needs UEFI. Which workflow would you want here?

1) The operator (or ironic?) has already configured the node to boot in
UEFI mode. Only pre-configured nodes advertise the "supports UEFI" trait.

2) Any node that supports UEFI mode advertises the trait. Ironic ensures
that UEFI mode is enabled before provisioning the machine.

I imagine doing #2 by passing the traits which were specifically requested
by the user, from Nova to Ironic, so that Ironic can do the right thing for
the user.

Your proposal suggests that the user request the "supports UEFI" trait, and
*also* pass some glance UUID which the user understands will make sure the
node actually boots in UEFI mode. Something like:

openstack server create --flavor METAL_12CPU_128G --trait SUPPORTS_UEFI
--config-data $TURN_ON_UEFI_UUID

Note that I pass --trait because I hope that will one day be supported and
we can slow down the flavor explosion. But I'm not sure if that's still
planned because I think you misunderstood my question or wanted to talk
more about RAID. :)

Anyway, it seems like a pretty lame user experience to be able to
explicitly request UEFI, but get a server that doesn't actually come up
because I forgot to also tell it to turn on UEFI mode.

FWIW, I do really like what you're proposing, for complex things like RAID
(or really. But for the simple cases (UEFI being one that many people use
today, VT bit being another example), feels a bit overkill.

// jim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20181001/4b77cd73/attachment.html>