[Airship-discuss] Divestiture

[Stephen Nemeth]

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/). 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>, 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
> and you’re most welcome to join the design discussion as well (times listed on our wiki https://wiki.openstack.org/wiki/Airship)
>
> Thanks,
> Matt
>
> From: Stephen Nemeth <kbaegis at gmail.com>
> Sent: Wednesday, June 19, 2019 5:17 AM
> To: 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/aecab33f/attachment.html>