[Airship-discuss] Divestiture

[MCEUEN, MATT]

Gotcha.  Yes, I think this is something we could discuss in our design calls, starting with the use case and working out from there.  This Thursday’s call is cancelled but we’ll pick back up next week.  However, I don’t think we’d want to sidestep a containerized approach for Ironic, since that is one of Airship’s core principles for dependency management/distribution.  E.g., we put quite a bit of effort into containerizing maas for Airship 1.x.

In any case, keep in mind that the Airship 2.0 design is modular, and if you’d like to use something other than Airship to manage host provisioning, that should be fine – you’ll still be able manage workloads on top of the cluster via Airship.

Thanks,
Matt

From: Stephen Nemeth <kbaegis at gmail.com>
Sent: Wednesday, June 19, 2019 10:01 AM
To: MCEUEN, MATT <MM9745 at att.com>
Cc: airship-discuss at lists.airshipit.org
Subject: RE: [Airship-discuss] Divestiture

Thank you for the inclusion and the links!

My core concern with this approach is that it excludes or invalidates use-cases for airship; hence the title.

Is it possible to design the inclusion of M^3 and cluster-api in a manner that doesn’t preclude using an ironic-drydock integration in the future that’s more lightweight (absent the chicken/egg issue)?

Ironic standalone is incredibly lightweight and flexible. The footprint doesn’t require any complex clustering, key exchange, etc and it makes a very nice starting point for bootstrapping infrastructure. You can get started with some image blobs and a python venv.

By comparison, a multi-tiered or ephemeral kubernetes clustering schema is going to give a lot of folks headaches trying to wrap their heads around and troubleshoot. As a consequence, it’s going to be more difficult to maintain and support. It may also couple your solutions to particular versions, operating systems, or network architectures with fewer workarounds as a side-effect.

In my particular case, I use ironic-standalone on a MacBook. I made efforts to containerize it, however my container runtime doesn’t play nice with dhcp/tftp in particular (https://docs.docker.com/docker-for-mac/networking/<https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.docker.com_docker-2Dfor-2Dmac_networking_&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=_C5hC_103uW491yNPPpNmA&m=cRkGmlZcpZtsQpGbDcwFYWT1s6STlD6AvUdIHAzV8mY&s=6Fh0WCMM35ZA0n4M76-_1Q92f-x91RQoCMqsHjqHfIQ&e=>). Fortunately, everything is nicely decoupled and the pxe/ipxe interfaces for ironic just need to be pointed at a directory to function. If we start from the assumption that everything is operating in a container provided by a particular registry then this would invalidate my approach and I believe that I would be blocked on using airship for a deployment.

I’ll try to make that meeting and maybe we can figure this out then.

Thanks,

Stephen
On Jun 19, 2019, 8:31 AM -0600, MCEUEN, MATT <MM9745 at att.com<mailto:MM9745 at att.com>>, wrote:

Hi Stephen,

Don’t worry, the discussion is still very active.  But yes, we still are planning to incorporate ironic using metal kubed.  A driver for that to reduce the amount of custom code that Airship needs to drive provisioning – in the target state, the plan is metal kubed + cluster API will care for,

  *   Ironic-based machine provisioning
  *   Kubeadm-based cluster management
  *   Declarative interfaces for the above

Like you said, this does present a chicken and egg problem around using a k8s cluster to provision a k8s cluster.  We’re designing for that now – in some use cases an ephemeral cluster can be spun up, and in some there would be a centralized management cluster (we call this “cloud harbor”) already.  We have notes, draft design docs, and design meeting recordings if you’re interested,  https://etherpad.openstack.org/p/Airship_OpenDesignDiscussions<https://urldefense.proofpoint.com/v2/url?u=https-3A__etherpad.openstack.org_p_Airship-5FOpenDesignDiscussions&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=_C5hC_103uW491yNPPpNmA&m=cRkGmlZcpZtsQpGbDcwFYWT1s6STlD6AvUdIHAzV8mY&s=VoF2KZbdvzoxORWwgxwC49pmFjBv7R6GrtihqkPqZkE&e=>
and you’re most welcome to join the design discussion as well (times listed on our wiki https://wiki.openstack.org/wiki/Airship<https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.openstack.org_wiki_Airship&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=_C5hC_103uW491yNPPpNmA&m=cRkGmlZcpZtsQpGbDcwFYWT1s6STlD6AvUdIHAzV8mY&s=MNdTYyWwCnpIUVS_lGB5MJsiEmGEM2yqs7v7jCNES24&e=>)

Thanks,
Matt

From: Stephen Nemeth <kbaegis at gmail.com<mailto:kbaegis at gmail.com>>
Sent: Wednesday, June 19, 2019 5:17 AM
To: airship-discuss at lists.airshipit.org<mailto:airship-discuss at lists.airshipit.org>
Subject: [Airship-discuss] Divestiture

Hi there everyone,

Is airship still interested in incorporating openstack ironic for deployments? While metal kubed and cluster-api are cool, this simply increases the dependencies to run airship to begin with doesn’t it? It functionally assumes that you already have kubernetes available just to deploy a new kubernetes environment. Am I missing something critical here?

Sorry in advance for being late to the discussion.

Thanks,

Stephen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.airshipit.org/pipermail/airship-discuss/attachments/20190619/056a74b8/attachment-0001.html>