draft cloud wg governance document
by Matthew Miller
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>
10 years, 5 months
food for thought - article on OS for web-scale/cloud/unicorns
by Robyn Bergeron
Okay, maybe not unicorns. :)
http://blog.hendrikvolkmer.de/2013/10/11/the-missing-piece-operating-syst...
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
10 years, 5 months
Cloud WG initial IRC meeting
by Matthew Miller
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>
10 years, 5 months
Re: Attention Cloud WG nominees
by James Antill
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.).
10 years, 5 months
Fedora 20-Beta TC6 AMIS
by Dennis Gilmore
-----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-...
http://dl.fedoraproject.org/pub/alt/stage/20-Beta-TC6/Images/x86_64/Fedor...
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-----
10 years, 5 months
Cloud image partition size
by Sandro "red" Mathys
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
10 years, 5 months
Announcing the Cloud Working Group
by Matthew Miller
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>
10 years, 5 months
Fedora Cloud Working Group (members, everyone, and what's next)
by Matthew Miller
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>
10 years, 5 months
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
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
10 years, 6 months
