cloud October 2013

cloud@lists.fedoraproject.org

33 participants
35 discussions

Agenda for Today's Cloud WG Meeting (2013-10-30 19:00 UTC)
by Matthew Miller 30 Oct '13

30 Oct '13

Hello everyone. Our initial Cloud WG meeting today is today at 19:00 UTC (3pm EDT). We'll use #fedora-meeting-1 (because the FESCo meeting in #fedora-meeting has been running more than an hour). All are welcome. == Communications == - mailing list vs. irc meetings - trac instance == Next Steps == - draft governance <https://fedoraproject.org/wiki/Cloud_WG> - PRD framework <https://fedoraproject.org/wiki/Cloud_PRD> == Open Floor == -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>

1 0

draft cloud wg governance document
by Matthew Miller 30 Oct '13

30 Oct '13

https://fedoraproject.org/wiki/Cloud_WG If this seems short for the amount of time I put into it, that's because it was about three times longer and I ripped most of it out after reading it over. There are still some wordy bits left that could be put on a diet. And there are some parts to decide yet. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>

2 1

food for thought - article on OS for web-scale/cloud/unicorns
by Robyn Bergeron 29 Oct '13

29 Oct '13

Okay, maybe not unicorns. :) http://blog.hendrikvolkmer.de/2013/10/11/the-missing-piece-operating-system… So while some of this is fairly high-level/explanatory (which in itself is still useful, of course) - I thought some of this brought up some decent points around software delivery, deployment, config mgmt, etc. Just thought it might get some thoughts moving in people's heads around use cases and different goals in usage - I think folks are going to continue to basically go with "best tool for the job" (where the job == their job and its associated requirements, which may not necessarily be technology-related requirements), so I think it might be useful to have some good thought around how to make ... what we wind up making :) ... fairly flexible, or maybe "re-composable" is the word i'm looking for. Images, guests, containers, etc... how to build them similarly enough to make them consistent enough to test, how to make the building simple enough for build them themselves (and applying config mgmt of sorts either as part of the build, or afterwards) ... I don't want us to necessarily think about this in terms of "for developers" vs. "for sysadmins" - there are lots of different workflows, or drivers to do things one way vs. another (caring about scalability vs. performance vs. $somethingelse). Thoughts, anyone? Like I said, just looking to get us to think about things from different POV... (I realize I'm sort of babbling, it's still really early here.) -robyn

3 2

Cloud WG initial IRC meeting
by Matthew Miller 28 Oct '13

28 Oct '13

Hi everyone. It looks like it works for most of the WG members to meet at 19:00 GMT (3pm EDT) this week. We'll use #fedora-meeting-1 (because the FESCo meeting in #fedora-meeting has been running more than an hour) and I'll say something on #fedora-cloud a few minutes before it starts. I'll also send out a brief agenda / topic list sometime before. This is a public meeting; all are welcome. If we get to the point of voting on anything, only WG members should actually vote. Also, if you're not familiar with Fedora's normal online meeting practices, we use the Freenode IRC system. (And many of us hang out on #fedora-cloud.) -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>

7 9

Re: Attention Cloud WG nominees
by James Antill 28 Oct '13

28 Oct '13

Matthew Miller wrote: > I've been the defacto maintainer of the Fedora cloud image kickstart > for the past year or so (I have commit access, and I use it!), and I > think that's gotten into fairly decent shape. This WG will be about > going beyond decent and into something that's actually both very useful > and well-used. I have some ideas for what that'd look like, but I'd > like to hear yours too. And, I'm interested in hearing where you'd like > to contribute in specific. [...] > I posted a few weeks ago about possible directions for the cloud > product. [...] > I've also heard a few comments suggesting that the cloud guest should > basically just be the server product in image form, with cloud-init. > This is a model where cloud computing is basically seen as providing > "servers in the sky"; I think there's a place for that, but again, I > don't think it's what we should be aiming at. And from the previous emails, the proposals were basically (feel free to correct me if I'm wrong): 1. Cloud image is the Fedora Server OS, but tailored to run in a virtual environment and with cloud-init. (roughly what you do now). 2. A lightweight distribution made for running containers on top of. Likely would not look much like a normal Fedora Sever, no docs., maybe even no rpm/yum, etc. etc. 3. Tools to help Fedora users generate their own images, based upon either #1 or #2. ...I was mostly assuming I could help with #2, and maybe #3, but probably not as much with #1 (at least atm.).

4 3

Fedora 20-Beta TC6 AMIS
by Dennis Gilmore 26 Oct '13

26 Oct '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 hi all, Beta TC6 images have been uploaded to EC2 and are available at ami-69bfe000 : us-east-1 image for i386 ami-c5bfe0ac : us-east-1 image for x86_64 additionally if your looking to the AMI's they have been added to files in the release tree http://dl.fedoraproject.org/pub/alt/stage/20-Beta-TC6/Images/i386/Fedora-Im… http://dl.fedoraproject.org/pub/alt/stage/20-Beta-TC6/Images/x86_64/Fedora-… when we get to final alpha and the images are uploaded to all regions they will all be listed and the file will be signed in the final tree Dennis -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJSa9w1AAoJEH7ltONmPFDR5tcP/jW6C0G8idV1BfOjptf977/n hT7OvBhgSMrzC1tFvFeJ22iSFhEOov5mZwIZbNtlmenZFHCFcgqF6PZRt3HQ3GdY VsANYSFYdwuhFcaLYO+qSkZOUbS71J5fSAU/+M+Gem1GHKZsAfjqyUBS2gphT5iA LlmWFEd8um/3XLkFtoqy/cwyuisJFQEsJx3/fIIiWjei30kPfAN8dKOaecqB52go QhJpIDpkxcRQO9f9FFjBahwHlamQzV0bv7vMBVZ3xaSmkUWOWxOIWTaZwRlYLDd9 rCaNFcWSgEGET1AkVJc8yotzsAkjDjycCfjk3bY2rNOKuPc4HsxwBeFR6t1b14Lk 3cUHWYbcTJ2T3syeHfp0o+iRK3B9bDqixZ0lKFBqSSqwMZTfOvb8qegBNQpz+rNs T/fm9Sb0eZ6N5Ig9Au097VW8NdwqOJL+CpfnMVxdb4YVz2mvlDWeLZQMd4Sst+QK C+KsaNHN6mqxJha+KaYWfvuGXXVWrslurcrBVCvUGSNKjSTPm9m6Apg/jeN9/7OO YkVAQKJmrCCy6qUitYNzV/2p87DDtRph0xTAapv7co3UVwmIkIhiJyvxZrb6barB OeIOFhC8GWEV8V9YJ5OAX3f+67jCp9BzXle6/bf4U1PxobGKr2BjBCvebR11go0K yLXb2YyFthT9ynxKvwSn =sX9q -----END PGP SIGNATURE-----

2 1

Cloud image partition size
by Sandro "red" Mathys 26 Oct '13

26 Oct '13

The F19 and F20 (up until the current Beta TC5) cloud images use a partition size of 2GB while they only just use <600MB of storage space. Furthermore if qcow2 compressed, that's only ~200MB leading one to (correctly) think it can easily be started in an instance with a 1GB root disk. Now trying to launch the image as such (the m1.tiny flavor happens to come with a 1 GB root disk by default in OpenStack Havana), it will always fail. Therefore, I propose to change the partition size to 1024MB instead of 2048MB. Or even to just 600MB but clouds specify the root disk size in GBs rather than MBs anyway, and 600MB might limit further development stronger than really necessary. A bigger partition made sense back when we didn't have the tools in place to resize the partition during boot time, but not anymore. -- Sandro

3 5

Announcing the Cloud Working Group
by Matthew Miller 26 Oct '13

26 Oct '13

I sent a message about this yesterday to the Cloud SIG mailing list, but neglected to send to the wider community. Also, I just listed people without introductions, and although I think all of these names should be familiar to many of us, that seems like a nice thing. So: I'm pleased to annouce that the following people have agreed to be voting members of the initial working group: * James Antill -- FPC member, yum maintainer. Will help with the tools we'll need to build a brave new containerized world. * Robyn Bergeron -- Former Fedora Cloud SIG wrangler, now the FPL. Driver of Fedora for those who value mean time to recover over mean time between failure. Talks regularly with smart people in awesome innovative open software communities outside of our traditional comfort zone. * Joe Brockmeier -- Fedora Marketing contributor, and also member of the Apache CloudStack PMC. Will help with market research, marketing, communications, and as much as we can trick him into taking on. * Haïkel Guémar -- Longtime Fedora contributor (packager, ambassador, writer), and works on cloud computing for $DAYJOB, and so will provide a voice for real-world users. * Sam Kottler -- Works with Puppet and is a member of Bundler and RubyGems core teams. Has opinions, not afraid to use them. Does not sleep. * Sandro Mathys -- Another longtime contributor, active in OpenStack and RDO, also works on cloud computing for actual money; will provide real-world experience and contribute to QA. * Matthew Miller -- Me. FESCo coordinator, cheerleading, that sort of thing. * Frankie Onuonga -- Member of the Fedora Infrastructure team, interested in release engineering. Works for a public cloud startup hopefully going live next week with Fedora images. * Mattias Runge -- Fedora contributor and OpenStack developer. Has presented a somewhat different idea of where we should go with this than what I suggested, which is good in case I'm entirely wrong. As Josh noted in the Workstation WG announcement, I also want to strongly stress that while the above people are the initial voting members, we're looking for participation from anyone interested in helping Fedora succeed as a cloud operating system. We will be using using the existing Cloud SIG mailing list (cloud(a)lists.fedoraproject.org) and #fedora-cloud IRC channel for group communication. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>

2 1

Fedora Cloud Working Group (members, everyone, and what's next)
by Matthew Miller 24 Oct '13

24 Oct '13

Hello everyone. FESCo has approved the initial slate of voting members in the Fedora Cloud Working Group. That is: * James Antill * Robyn Bergeron * Joe Brockmeier * Haïkel Guémar * Sam Kottler * Sandro Mathys * Matthew Miller * Frankie Onuonga * Mattias Runge Our next two steps are to 1) document a governance model and 2) start working on a product requirements document. As we work on these things, we'll need a place to communicate. I suggest that we primarily use this list, plus chat on #fedora-cloud on Freenode. We have some geographical distribution -- I'm going to try to see if we can find a time for an IRC meeting at least initially. This doesn't mean that we're taking over this list for just this purpose -- the Cloud SIG remains a place to talk about and work on all things cloud, and I think we can handle the overlap (especially since it's not super-high traffic). Also, as I hope I've made clear, the working group can't possibly do all of the things that needs to be done; everyone on the committee will have an active role in actually doing things, but we also will act as enablers for other people's contributions. Unless anyone objects, or is really, really excited about doing it, I'm going to start on a basic strawman governance document. Things like what constitues a binding vote, how we handle succession that kind of thing. Then we can discuss and improve that. This needs to be done by November 15th, although I'm kind of hoping that it'll be so uncomplicated that it won't take that long. Likewise, I can start on a skeleton for a PRD, but if anyone in the group has more experience at doing that than I have (I come from a sysadmin background, not one where I've worked on shipping products) I'll happily and immediately defer. (This, by the way, needs to be done by January somethingth, which sounded a long way away when this idea was drafted but doesn't anymore when I look at the holiday calendar.) -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>

5 4

3 commits - container/container-medium-19.ks container/container-medium-20.ks container/container-small-19.ks container/container-small-20.ks generic/fedora-20-cloud.ks
by Matthew Miller 23 Oct '13

23 Oct '13

container/container-medium-19.ks | 1 - container/container-medium-20.ks | 1 - container/container-small-19.ks | 1 - container/container-small-20.ks | 1 - generic/fedora-20-cloud.ks | 34 +++------------------------------- 5 files changed, 3 insertions(+), 35 deletions(-) New commits: commit c7464dd3d99f03049708c4fbd3e280c53ac60a74 Author: Matthew Miller <mattdm(a)mattdm.org> Date: Wed Oct 23 13:53:52 2013 -0400 make / smaller so it will at least launch in openstack tiny instances. (note that in most cases growpart will take care of expanding this as approprate) diff --git a/generic/fedora-20-cloud.ks b/generic/fedora-20-cloud.ks index c0b986e..40e764d 100644 --- a/generic/fedora-20-cloud.ks +++ b/generic/fedora-20-cloud.ks @@ -29,7 +29,7 @@ services --enabled=network,sshd,rsyslog,cloud-init,cloud-init-local,cloud-config zerombr clearpart --all -part / --size 2048 --fstype ext4 +part / --size 1000 --fstype ext4 # Repositories repo --name=fedora --mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=fedora-20&arch=$basearch commit 211981ef0dcdc0a2e3992e15f15b3fdf25ea0e20 Author: Matthew Miller <mattdm(a)mattdm.org> Date: Wed Oct 23 13:50:28 2013 -0400 by popular demand, disable the iptables firewall entirely. diff --git a/generic/fedora-20-cloud.ks b/generic/fedora-20-cloud.ks index 2c9294e..c0b986e 100644 --- a/generic/fedora-20-cloud.ks +++ b/generic/fedora-20-cloud.ks @@ -19,14 +19,12 @@ auth --useshadow --enablemd5 selinux --enforcing rootpw --lock --iscrypted locked -# this is actually not used, but a static firewall -# matching these rules is generated below. -firewall --service=ssh +firewall --disabled bootloader --timeout=1 --append="console=ttyS0,115200n8 console=tty0" extlinux network --bootproto=dhcp --device=eth0 --onboot=on -services --enabled=network,sshd,rsyslog,iptables,cloud-init,cloud-init-local,cloud-config,cloud-final +services --enabled=network,sshd,rsyslog,cloud-init,cloud-init-local,cloud-config,cloud-final zerombr @@ -69,10 +67,6 @@ syslinux-extlinux # Needed initially, but removed below. firewalld -# Basic firewall. If you're going to rely on your cloud service's -# security groups you can remove this. -iptables-services - # cherry-pick a few things from @standard tar rsync @@ -141,28 +135,6 @@ yum -C -y remove linux-firmware echo "Removing firewalld." yum -C -y remove firewalld --setopt="clean_requirements_on_remove=1" -# Non-firewalld-firewall -echo -n "Writing static firewall" -cat <<EOF > /etc/sysconfig/iptables -# Simple static firewall loaded by iptables.service. Replace -# this with your own custom rules, run lokkit, or switch to -# shorewall or firewalld as your needs dictate. -*filter -:INPUT ACCEPT [0:0] -:FORWARD ACCEPT [0:0] -:OUTPUT ACCEPT [0:0] --A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT --A INPUT -p icmp -j ACCEPT --A INPUT -i lo -j ACCEPT --A INPUT -m conntrack --ctstate NEW -m tcp -p tcp --dport 22 -j ACCEPT -#-A INPUT -m conntrack --ctstate NEW -m tcp -p tcp --dport 80 -j ACCEPT -#-A INPUT -m conntrack --ctstate NEW -m tcp -p tcp --dport 443 -j ACCEPT --A INPUT -j REJECT --reject-with icmp-host-prohibited --A FORWARD -j REJECT --reject-with icmp-host-prohibited -COMMIT -EOF -echo . - # Another one needed at install time but not after that, and it pulls # in some unneeded deps (like, newt and slang) echo "Removing authconfig." commit a8d12254e33bd998bc6ad285c6b956917159e833 Author: Matthew Miller <mattdm(a)mattdm.org> Date: Tue Oct 22 12:34:26 2013 -0400 uh, don't create device file that i will then be just removing. diff --git a/container/container-medium-19.ks b/container/container-medium-19.ks index 44df6f4..484fb50 100644 --- a/container/container-medium-19.ks +++ b/container/container-medium-19.ks @@ -67,7 +67,6 @@ echo . # create devices which appliance-creator does not ln -s /proc/kcore /dev/core -mknod -m 600 /dev/console c 5 1 mknod -m 660 /dev/loop0 b 7 0 mknod -m 660 /dev/loop1 b 7 1 rm -rf /dev/console diff --git a/container/container-medium-20.ks b/container/container-medium-20.ks index a644264..05cd1b2 100644 --- a/container/container-medium-20.ks +++ b/container/container-medium-20.ks @@ -68,7 +68,6 @@ echo . # create devices which appliance-creator does not ln -s /proc/kcore /dev/core -mknod -m 600 /dev/console c 5 1 mknod -m 660 /dev/loop0 b 7 0 mknod -m 660 /dev/loop1 b 7 1 rm -rf /dev/console diff --git a/container/container-small-19.ks b/container/container-small-19.ks index 3fcd63d..5273bac 100644 --- a/container/container-small-19.ks +++ b/container/container-small-19.ks @@ -61,7 +61,6 @@ echo . # create devices which appliance-creator does not ln -s /proc/kcore /dev/core -mknod -m 600 /dev/console c 5 1 mknod -m 660 /dev/loop0 b 7 0 mknod -m 660 /dev/loop1 b 7 1 rm -rf /dev/console diff --git a/container/container-small-20.ks b/container/container-small-20.ks index bc44013..4cfad1a 100644 --- a/container/container-small-20.ks +++ b/container/container-small-20.ks @@ -61,7 +61,6 @@ echo . # create devices which appliance-creator does not ln -s /proc/kcore /dev/core -mknod -m 600 /dev/console c 5 1 mknod -m 660 /dev/loop0 b 7 0 mknod -m 660 /dev/loop1 b 7 1 rm -rf /dev/console

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cloud October 2013