On Mon, Mar 10, 2014 at 8:26 PM, Steven Dake <sdake@redhat.com> wrote:<br>
<blockquote type="cite"><div class="plaintext" style="white-space: pre-wrap;"><br></div></blockquote><blockquote type="cite"><div class="plaintext" style="white-space: pre-wrap;">If these are removed from a guest operating system, the guest won't be
able to function with TripleO, Heat, or anyone that depends on
cloud-init. Removing cloud-init support effectively kills any
motivation for AWS adoption of a guest operating system that we may produce.</div></blockquote><div><br></div><div>I would say that there are many valid ways to provision and manage machines, of which Heat/CloudFormation is one. min-metadata-service does exactly what it needs to do to provide the fundamental basis for secure remote access to the machine, and with</div><div><a href="https://github.com/cgwalters/min-metadata-service/issues/2">https://github.com/cgwalters/min-metadata-service/issues/2</a></div><div>the guest will also be able to reach out and register on bootup (perhaps by first pulling a docker container), which is all one needs to implement higher order management tools.</div><div><br></div><div>And there implementation will stop =)</div><div><br></div><div>But I'd agree with you (and others have expressed this sentiment) that we should be conservative with backing away from cloud-init in the near future.</div><div><br></div><div>At least for Fedora Cloud. That said, I am trying to create momentum for a smaller but still useful core, ideally written in lovingly hand crafted C code, with languages like Python and Ruby still *available*.</div><br><blockquote type="cite"><div class="plaintext" style="white-space: pre-wrap;">I am a bit confused at the scope because min-metadata-server was
mentioned early on, but is unnecessary if the target of this OS is to
only run on hosts.</div></blockquote><div><br></div><div>Running as a guest is definitely in scope.</div><br><blockquote type="cite"><div class="plaintext" style="white-space: pre-wrap;">Ideally a python run time would still be available to run virtualization
platforms like OpenStack. </div></blockquote><div><br></div><div>Sure, of course. No one is talking about making python unavailable. Just possibly not installed by default in all builds.</div><br><blockquote type="cite"><div class="plaintext" style="white-space: pre-wrap;"> Such a bare-bones operating system would make
alot of sense, but I've copied a TripleO upstream developer (James) for
his thoughts on atomic + ostree and its relationship to how TripleO
handles continuous deployment through imaging.</div></blockquote><br><div>I'm certainly interested in the discussion! OSTree was made from the very start to do continuous deployment - at the moment with rpm-ostree I am restricting myself to merely accepting RPMs as input, so no continuous integration. But gnome-continuous is a custom build system that takes git repositories and writes to the OSTree repository directly (with no intermediate package step).</div><div><br></div><div><br></div>