Right now, the example use case we have is "cloud image on AWS". This suggests that we should have a parallel "cloud image on OpenStack" as another primary target, but then as I went to fill that in, I thought... maybe this is going about this wrong. I think this is a step or two too low level. How about instead, we make the use case be
* Web Application Deployment in a Public Cloud
Modern web applications are deployed as a collection of interconnected services, including parts like web servers, application servers, databases, and caching layers. Fault tolerance is handled at the overall orchestration level rather than by individual instances Fedora Cloud can be the base of each of these parts, providing recent libraries, server software, and language toolchains. Each system will be managed using the public cloud's own management tools plus a configuration management system like Puppet, Chef, or Ansible.
* Web Application Deployment in Hybrid Cloud
As above, but rather than a single cloud provider, the application seamlessly takes advantage of resources in both a private and public cloud.
* Separate use case for Private Cloud?
_______________ (Or combine into one of the above?)
* Non-web applications? Data crunching?
_______________
* Docker Container Host
Docker is a technology for running applications inside a protected container. These containers run under the host kernel, but otherwise are self-contained. The Fedora Cloud image running in either a private or public cloud can provide the host level, including basic docker management tools plus tools for security and for access to storage.
* Something with Vagrant?
___________
On 12/09/2013 08:39 PM, Matthew Miller wrote:
Right now, the example use case we have is "cloud image on AWS". This suggests that we should have a parallel "cloud image on OpenStack" as another primary target, but then as I went to fill that in, I thought... maybe this is going about this wrong. I think this is a step or two too low level. How about instead, we make the use case be
- Web Application Deployment in a Public Cloud
- Web Application Deployment in Hybrid Cloud
- Separate use case for Private Cloud?
- Non-web applications? Data crunching?
- Docker Container Host
- Something with Vagrant?
Two short thoughts about this: - do we really need to distinguish between public, private and hybrid cloud? IMHO that shouldn't really matter for the image.
Additional use cases: * Database application * mail server (yes, that's really old school), like smtp, imap, spamassassin, etc. * is there a use case for virtual desktops?
In General, I'd say, everything the server WG targets to would be applicable for the cloud image, too (except cloud infra providing).
Matthias
On 12/10/2013 04:45 AM, Matthias Runge wrote:
Two short thoughts about this:
- do we really need to distinguish between public, private and hybrid
cloud? IMHO that shouldn't really matter for the image.
It matters for the image format (AMI vs. qcow2, etc.) and may matter for packages that are included in the image as well.
Best,
jzb
On Tue, Dec 10, 2013 at 3:21 PM, Joe Brockmeier jzb@redhat.com wrote:
On 12/10/2013 04:45 AM, Matthias Runge wrote:
Two short thoughts about this:
- do we really need to distinguish between public, private and hybrid
cloud? IMHO that shouldn't really matter for the image.
It matters for the image format (AMI vs. qcow2, etc.) and may matter for packages that are included in the image as well.
Why would it matter for the format? AMI or qcow2 both work in public, private and hybrid clouds. Or am I missing something?
Any examples what should be different in terms of packages? I can't think of anything that is public/private/hybrid specific.
-- Sandro
On 12/10/2013 08:45 AM, Sandro "red" Mathys wrote:
On Tue, Dec 10, 2013 at 3:21 PM, Joe Brockmeier jzb@redhat.com wrote:
On 12/10/2013 04:45 AM, Matthias Runge wrote:
Two short thoughts about this:
- do we really need to distinguish between public, private and hybrid
cloud? IMHO that shouldn't really matter for the image.
It matters for the image format (AMI vs. qcow2, etc.) and may matter for packages that are included in the image as well.
Why would it matter for the format? AMI or qcow2 both work in public, private and hybrid clouds. Or am I missing something?
AMI is preferred on Amazon. Don't think it's a supported format for CloudStack, not sure about OpenStack. I don't think you can directly import qcow2 to EC2.
Also: we're already producing these images. I'm guessing we didn't do so randomly.
Any examples what should be different in terms of packages? I can't think of anything that is public/private/hybrid specific.
EC2 has its own tools that, IIRC, are bundled with the AMI. (ec2-utils) Not sure whether we can ship that package or not, I don't see it currently.
(It seems I only just sent the message below to Joe instead of the list 18 minutes ago. So here it is and I hope Joe doesn't mind to re-send his reply, which also missed to hit the list, too. Apologies for the mistake and the extra-noise.)
On Tue, Dec 10, 2013 at 3:57 PM, Joe Brockmeier jzb@redhat.com wrote:
On 12/10/2013 08:45 AM, Sandro "red" Mathys wrote:
On Tue, Dec 10, 2013 at 3:21 PM, Joe Brockmeier jzb@redhat.com wrote:
On 12/10/2013 04:45 AM, Matthias Runge wrote:
Two short thoughts about this:
- do we really need to distinguish between public, private and hybrid
cloud? IMHO that shouldn't really matter for the image.
It matters for the image format (AMI vs. qcow2, etc.) and may matter for packages that are included in the image as well.
Why would it matter for the format? AMI or qcow2 both work in public, private and hybrid clouds. Or am I missing something?
AMI is preferred on Amazon. Don't think it's a supported format for CloudStack, not sure about OpenStack. I don't think you can directly import qcow2 to EC2.
OpenStack can import AMI but will probably convert it (automagically) before using it. I'd guess Eucalyptus can make use of AMI too, since they strive for AWS compatibility.
Now while AWS is exclusively a public cloud, OpenStack, Eucalyptus and I'd guess also CloudStack and OpenNebula can make up a public, private or hybrid cloud. Particularly OpenStack is used in all three ways.
So if at all, it should probably not be distinguished by public/private/hybrid but rather by AWS/others (or split "others" further, if there's any reason to do so).
Also: we're already producing these images. I'm guessing we didn't do so randomly.
Any examples what should be different in terms of packages? I can't think of anything that is public/private/hybrid specific.
EC2 has its own tools that, IIRC, are bundled with the AMI. (ec2-utils) Not sure whether we can ship that package or not, I don't see it currently.
Which I think are <1MB in size, hardly a reason to distinguish anything. Also, that'd still be AWS-specific, not public-specific.
-- Sandro
----- Original Message -----
From: "Matthias Runge" mrunge@matthias-runge.de To: cloud@lists.fedoraproject.org Sent: Tuesday, December 10, 2013 5:45:13 AM Subject: Re: PRD use cases
On 12/09/2013 08:39 PM, Matthew Miller wrote:
Right now, the example use case we have is "cloud image on AWS". This suggests that we should have a parallel "cloud image on OpenStack" as another primary target, but then as I went to fill that in, I thought... maybe this is going about this wrong. I think this is a step or two too low level. How about instead, we make the use case be
- Web Application Deployment in a Public Cloud
- Web Application Deployment in Hybrid Cloud
- Separate use case for Private Cloud?
- Non-web applications? Data crunching?
- Docker Container Host
- Something with Vagrant?
Two short thoughts about this:
- do we really need to distinguish between public, private and hybrid
cloud? IMHO that shouldn't really matter for the image.
In my opinion there really should be different images for the public cloud (and maybe even cloud-specific images) and private cloud. This is actually a whole other discussion that's gone on in the past, so this might not be the best place for the discussion about splitting out the images, though. My general take on it is that there are fundamental things (like enabling iptables by default) that need to happen on only on one "type" of cloud. The alternative to creating completely separate images is using cloud-init to alter what's running in the image at boot.
Additional use cases:
- Database application
- mail server (yes, that's really old school), like smtp, imap,
spamassassin, etc.
- is there a use case for virtual desktops?
+1 to all of these use cases. There's another important one that I don't think we've touched on yet, which is short-lived nodes used for data-processing as part of a pipeline. IMO we should put particular focus on that type of workload because Fedora is the first distro that has lots of pieces of the needed infrastructure for pipeline "big data" processing available in our repos.
In General, I'd say, everything the server WG targets to would be applicable for the cloud image, too (except cloud infra providing).
Matthias
cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
On 10.12.2013 12:45, Matthias Runge wrote:
Additional use cases:
- Database application
- mail server (yes, that's really old school), like smtp, imap,
spamassassin, etc.
- is there a use case for virtual desktops?
Apologies for the late note. IMHO, there should be a marketing opportunity in the virtual desktop option too. I do not have the necessary numbers to back this opinion, but what follows are some local (micro) observations:
Many friends of mine had migrated to OSX notebooks in the recent years (the reasons are different subject, discussed already, and mostly addressed with Fedora.next strategy and point of view). Many of them are relatively experienced Linux developers and sysadmins and _all_ of them have _Linux_ as deployment target - mostly CentOS (hopefully Fedora Server 1.0 next year ;-), when the community succeeds with the whole technical and marketing effort).
But in OSX they do not have more than terminal, browser and text editor as environment - not the same compilers out of the box, no Spice client, nor any advanced development tools. To reduce the inconvenience, currently they spending fair amount of time to search and install modules and other things i.e. to mimic something "near" to the CentOS production environment locally on their Apple calculators.
My current development environment is Fedora VM with enabled xrdp/vnc. So, I have personal experience how convenient is that setup - access to a _live_ session with few clicks from practically everywhere - customer site, home, office. I not have installed Guacamole yet (the HTML5 RD client), but have this in my todo too.
I hope 4-5 Fedora formulas, targeted to different stacks (Python, Java, Perl, etc.) with 1-2 formulas available as prebuild images (intended for easy testing, and with installed formula-to-image tool for bootstrapping other flavors), ready to be used in public/private cloud and/or with e.g. Vagrant locally, might have chance to attract number of devs/sysadmins and to bring positive effect on their performance.
Kind Regards, Alek
-
Alek Paunov -
Joe Brockmeier -
Matthew Miller -
Matthias Runge -
Sam Kottler -
Sandro "red" Mathys