<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title></title>
</head>
<body>
<div name="messageBodySection">
<div dir="auto">Thank you for the inclusion and the links!
<div dir="auto"><br /></div>
<div dir="auto">My core concern with this approach is that it excludes or invalidates use-cases for airship; hence the title. </div>
<div dir="auto"><br /></div>
<div dir="auto">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)? </div>
<div dir="auto"><br /></div>
<div dir="auto">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. </div>
<div dir="auto"><br /></div>
<div dir="auto">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. </div>
<div dir="auto"><br /></div>
<div dir="auto">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 (<a href="https://docs.docker.com/docker-for-mac/networking/">https://docs.docker.com/docker-for-mac/networking/</a>). 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. </div>
<div dir="auto"><br /></div>
<div dir="auto">I’ll try to make that meeting and maybe we can figure this out then. </div>
</div>
</div>
<div name="messageSignatureSection"><br />
<div class="matchFont">Thanks,<br />
<br />
Stephen</div>
</div>
<div name="messageReplySection">On Jun 19, 2019, 8:31 AM -0600, MCEUEN, MATT <MM9745@att.com>, wrote:<br />
<blockquote type="cite" class="spark_quote" style="margin: 5px 5px; padding-left: 10px; border-left: thin solid #1abc9c;">
<div class="WordSection1">
<p class="MsoNormal">Hi Stephen,</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">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,</p>
<ul style="margin-top:0in" type="disc">
<li class="MsoListParagraph" style="margin-left:0in;mso-list:l0 level1 lfo1">Ironic-based machine provisioning</li>
<li class="MsoListParagraph" style="margin-left:0in;mso-list:l0 level1 lfo1">Kubeadm-based cluster management</li>
<li class="MsoListParagraph" style="margin-left:0in;mso-list:l0 level1 lfo1">Declarative interfaces for the above</li>
</ul>
<p class="MsoNormal"> </p>
<p class="MsoNormal">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, <i><u><span style="color:blue"><a href="https://etherpad.openstack.org/p/Airship_OpenDesignDiscussions">https://etherpad.openstack.org/p/Airship_OpenDesignDiscussions</a></span></u></i></p>
<p class="MsoNormal">and you’re most welcome to join the design discussion as well (times listed on our wiki <a href="https://wiki.openstack.org/wiki/Airship">https://wiki.openstack.org/wiki/Airship</a>)</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">Thanks,</p>
<p class="MsoNormal">Matt</p>
<p class="MsoNormal"> </p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> Stephen Nemeth <kbaegis@gmail.com><br />
<b>Sent:</b> Wednesday, June 19, 2019 5:17 AM<br />
<b>To:</b> airship-discuss@lists.airshipit.org<br />
<b>Subject:</b> [Airship-discuss] Divestiture</p>
</div>
</div>
<p class="MsoNormal"> </p>
<div name="messageBodySection">
<div>
<p class="MsoNormal">Hi there everyone,</p>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">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? </p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">Sorry in advance for being late to the discussion. </p>
</div>
</div>
</div>
<div name="messageSignatureSection">
<p class="MsoNormal"> </p>
<div>
<p class="MsoNormal">Thanks,<br />
<br />
Stephen</p>
</div>
</div>
</div>
</blockquote>
</div>
</body>
</html>