On Mon, Mar 10, 2014 at 8:26 PM, Steven Dake &lt;sdake@redhat.com&gt; 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. &nbsp;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. &nbsp;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. &nbsp;No one is talking about making python unavailable. &nbsp;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! &nbsp;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. &nbsp;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>