<div dir="ltr">Then maybe it's just a terminology issue, I'm aware of the different Base projects under the Cloud SIG, but it's not always clear in email which Base is being discussed.<div><br></div><div>Unless the two bullets in the list apply to the Cloud Base, which I'd then question.</div><div><br></div><div>- Matt M</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jun 2, 2015 at 12:28 PM, M. Edward (Ed) Borasky <span dir="ltr"><<a href="mailto:znmeb@znmeb.net" target="_blank">znmeb@znmeb.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Tue, Jun 2, 2015 at 8:19 AM, Matt Micene <<a href="mailto:nzwulfin@gmail.com">nzwulfin@gmail.com</a>> wrote:<br>
> I'm curious about the drive to make the "base cloud image" as small as<br>
> possible and remove things like the Python stack. It could be that I've got<br>
> a terminology issue (which also could be the case) tracking threads.<br>
><br>
> What's the expected use of the "base cloud image"? The relevant download<br>
> page states:<br>
> "Everything you need, and nothing you don't."<br>
> "images for creating general purpose virtual machines (VMs)"<br>
><br>
> The drive to a small as possible and stripped down base image doesn't make<br>
> sense to me in that context. General purpose compute for a modern system<br>
> would include things like dnf, python, full logging capabilities, without a<br>
> need to add a large number of packages.<br>
><br>
> If the drive to make the base image as small as possible is for docker<br>
> containers (as I've seen in other threads), there already exists a Docker<br>
> Base image.<br>
><br>
> What is base functionality in a container isn't the same as base<br>
> functionality for a general purpose system in AWS or OpenStack.<br>
><br>
> I guess I'm saying I'd like to be clear when we are talking about Cloud Base<br>
> vs Docker Base and make sure the relationship between them is clear and the<br>
> goals for each are clear. Especially where changes could harm adoption<br>
> (Cloud Images without Python in AWS would be bad ).<br>
><br>
> -Matt M<br>
<br>
</span>There are two-and-a-half "Cloud" images:<br>
1. Docker Base: this is a "minimum viable Fedora" and is usually run<br>
via 'docker pull' from Docker Hub, where it goes by the name<br>
'<a href="http://docker.io/fedora:22" target="_blank">docker.io/fedora:22</a>'. Currently it's 186.5 MB. It has dnf, which<br>
depends on Python. I don't think you can remove Python but I believe<br>
there are no Perl or Ruby dependencies in it.<br>
2. Cloud Base: this lives in a Platform-as-a-Service environment and<br>
IIRC is a stripped-down Server. It can host containers but IIRC it can<br>
do more. I've never used Cloud Base but I'm pretty sure it has dnf and<br>
Python.<br>
2.5. Project Atomic: this was released in Fedora 22 but the project<br>
team has decoupled from Fedora's main six-month cycle in favor of a<br>
faster two-week release cycle. It uses rpm-ostree to manage RPMs<br>
rather than dnf so it may not need Python. It's mainly for hosting<br>
Docker containers, and its main end user is the OpenShift<br>
Platform-as-a-Service.<br>
<br>
So I don't think there's any risk that an AWS Fedora won't have<br>
Python. However, I believe there's a move to guarantee that all<br>
Python-dependent software runs with Python 3 and only the Python 3<br>
runtime is present on Fedora Cloud products.<br>
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
cloud mailing list<br>
<a href="mailto:cloud@lists.fedoraproject.org">cloud@lists.fedoraproject.org</a><br>
<a href="https://admin.fedoraproject.org/mailman/listinfo/cloud" target="_blank">https://admin.fedoraproject.org/mailman/listinfo/cloud</a><br>
Fedora Code of Conduct: <a href="http://fedoraproject.org/code-of-conduct" target="_blank">http://fedoraproject.org/code-of-conduct</a><br>
</div></div></blockquote></div><br></div>