Open Stack

On 11/02/2015 05:07 PM, Sam Betts (sambetts) wrote:
> Auto discovery is a topic which has been discussed a few times in the
> past for
>
> Ironic, and its interesting to solve because its a bit of a chicken and egg
>
> problem. The ironic inspector allows us to inspect nodes that we don't know
>
> the mac addresses for yet, to do this we run a global DHCP PXE rule that
> will
>
> respond to all mac addresses and PXE boot any machine that requests it,
>
> this means its possible for machines that we haven't been asked to
>
> inspect to boot into the inspector ramdisk and send their information to
>
> inspector's API. To prevent this data from being processed further by
>
> inspector if its a machine we shouldn't care about, we do a node lookup.
> If the data
>
> fails this node lookup we used to drop this data and continue no further, in
>
> release 2.0.0 we added a hook point to intercept this state called the
> Node Not
>
> Found hook point which allows us to run some python code at this point in
>
> processing before failing and dropping the inspection data. Something we've
>
> discussed as a use for this hook point is, enrolling a node that fails the
>
> lookup into Ironic, and then having inspector continue to process the
>
> inspection data as we would for any other node that had inspection requested
>
> for it, this allows us to auto-discover unknown nodes into Ironic.
>
>
> If this auto discovery hook was enabled this would be the flow when
> inspector
>
> receives inspection data from the inspector ramdisk:
>
>
> - Run pre-process on the inspection data to sanitise the data and ready
> it for
>
>    the rest of the process
>
>
> - Node lookup using fields from the inspection data:
>
>    - If in inspector node cache return node info
>
>
>    - If not in inspector node cache and but is in ironic node database, fail
>
>      inspection because its a known node and inspection hasn't been
> requested
>
>      for it.
>
>
>    - If not in inspector node cache or ironic node database, enroll the
> node in
>
>      ironic and return node info
>
>
> - Process inspection data
>
>
> The remaining question for this idea is how to handle the driver
> settings for
>
> each node that we discover, we've currently discussed 3 different options:
>
>
> 1. Enroll the node in ironic using the fake driver, and leave it to the
> operator
>
>     to set the driver type and driver info before they move the node
> from enroll
>
>     to manageable.

I'm -1 to this because it requires a manual step. We already have a 
process requiring 1 manual step - inspection :) I'd like autodiscovery 
to turn it to 0.

>
>
> 2. Allow for the default driver and driver info information to be set in
> the
>
>     ironic inspector configuration file, this will be set on every node
> that is
>
>     auto discovered. Possible config file example:
>
>
>     [autodiscovery]
>
>     driver = pxe_ipmitool
>
>     address_field = <ipmi_address>
>
> username_field = <ipmi_username>
>
>     password_field = <ipmi_password>

This is my favorite one. We'll also need to provide the default user 
name/password. We can try to advance a node to MANAGEABLE state after 
enrolling it. If the default credentials don't work, node would stay in 
ENROLL state, and this will be a signal to an operator to check them.

>
>
> 3. A possibly vendor specific option that was suggested at the summit was to
>
>     provide an ability to look up out of band credentials from an
> external CMDB.

We already have an extension point for discovery. If we know more about 
CMDB interfaces, we can extend it, but it's already possible to use.

>
>
> The first option is technically possible using the second option, by setting
>
> the driver to fake and leaving the driver info blank.

+1

>
>
> With IPMI based drivers most IPMI related information can be retrieved
> from the
>
> node by the inspector ramdisk, however for non-ipmi based drivers such
> as the
>
> cimc/ucs drivers this information isn't accessible from an in-band OS
> command.
>
>
> A problem with option 2 is that it can not account for a mixed driver
>
> environment.
>
>
> We have also discussed for IPMI based drivers inspector could set a new
>
> randomly generated password on to the freshly discovered node, with the idea
>
> being fresh hardware often comes with a default password, and if you used
>
> inspector to discover it then it could set a unique password on it and
>
> automatically make ironic aware of that.
>
>
> We're throwing this idea out onto the mailer because we'd like to get
> feedback
>
> from the community to see if this would be useful for people using
> inspector,
>
> and to see if people have any opinions on what the right way to handle
> the node
>
> driver settings is.

Yeah, I'm not decided on this one. Sounds cool but dangerous :)

>
>
> Sam (sambetts)
>
>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>