cloud October 2013

cloud@lists.fedoraproject.org

33 participants
35 discussions

F19 AMI Cloud Images - how to su? (sudo works)
by Philip Rhoades 22 Oct '13

22 Oct '13

People, Am I forced to use sudo all the time? Is it possible to "su -" somehow? Thanks, Phil. -- Philip Rhoades GPO Box 3411 Sydney NSW 2001 Australia E-mail: phil(a)pricom.com.au

4 4

Attention Cloud WG nominees
by Matthew Miller 22 Oct '13

22 Oct '13

This is a message for people who have self-nominated for the Fedora Cloud Product Working Group (FCPWG?). As the FESCo coordinator for the group, it's my job to narrow down the list to the initial 9 voting members. I was going to send this individually, but then I thought, eh, let's do it in public. If you want to send me other thoughts off-line too, go for it. And if you're not in the list of nominees I'd still value your input into some of the concepts. 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 didn't see anyone mention QA on the nomination list, for example, and we'll need to find someone to take ownership of that. Our actual deliverables are listed here: https://fedoraproject.org/wiki/Fedora.next/boardproposal#Product_Working_Gr… and they start with: * Governance plan and documents * A product definition -- target audience and so on * A list of changes from existing procedures * Actually doing things You may notice that "actually doing things" is kind of far down the list, and there's some degree of.... procedural overhead. If you really hate that kind of thing, speak up now, because maybe this isn't the best use of your time. Although the voting membership is going to be limited, and focused on these things, we actually also need a broader, involved community, so not being on the WG doesn't mean you can't be involved in a meaningful way. I posted a few weeks ago about possible directions for the cloud product. I am, by the way, pretty sure that we are talking about a cloud _guest_, and that being a base for cloud infrastructure systems like OpenStack or Eucalyptus is in the realm of the Server product (or possibly new, secondary products focused specifically on those use-cases). 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. The point of having this product as something different is so we can actually better address the different needs. What that actually looks like is to be determined. The current target is basically "as minimal as possible, but not so minimal that we break stuff or make people's life harder". In the absence of better idea about what we're doing or what we're providing this image _for_, that's a fine, generic base. We have the opportunity now to write the better story, though... so, what are your ideas? -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>

5 15

Re: Vagrant in Fedoraff Fedorraf we did is xdwdxwnmpc
by Nathanael D. Noblet 19 Oct '13

19 Oct '13

Alex Drahon <adrahon(a)redhat.com> wrote: >On 16/10/13 23:54, Nathanael D. Noblet wrote: >> On 10/15/2013 01:06 PM, Alex Drahon wrote: >> >>> Hope some of you can test it. >> >> After doing a vagrant up --provider=kvm I get prompted via polkit and >> then the terminal output is as follows: >> >> >> [gnat@iridium kvm]$ vagrant up --provider=kvm >> Bringing machine 'default' up with 'kvm' provider... >> [default] Importing base box 'precise32'... >> WARNING: Nokogiri was built against LibXML version 2.9.0, but has >> dynamically loaded 2.9.1 >> qemu-img: >> /home/gnat/.vagrant.d/tmp/storage-pool/box-disk1-1381964017.img: error >> while converting raw: Permission denied >> >> /usr/share/gems/gems/vagrant-kvm-0.1.4/lib/vagrant-kvm/driver/driver.rb:145:in >> `lookup_volume_by_name': Call to virStorageVolLookupByName failed: >> Storage volume not found: no storage vol with matching name >> 'box-disk1-1381964017.img' (Libvirt::RetrieveError) >> from >> /usr/share/gems/gems/vagrant-kvm-0.1.4/lib/vagrant-kvm/driver/driver.rb:145:in >> `import_ovf' >> from >> /usr/share/gems/gems/vagrant-kvm-0.1.4/lib/vagrant-kvm/action/import.rb:27:in >> `call' >> from >> /usr/share/gems/gems/vagrant-1.3.3/lib/vagrant/action/warden.rb:34:in >> `call' >> from >> /usr/share/gems/gems/vagrant-kvm-0.1.4/lib/vagrant-kvm/action/check_box.rb:31:in >> `call' >> from >> /usr/share/gems/gems/vagrant-1.3.3/lib/vagrant/action/warden.rb:34:in >> `call' >> from >> /usr/share/gems/gems/vagrant-1.3.3/lib/vagrant/action/runner.rb:61:in >> `block in run' >> from >> /usr/share/gems/gems/vagrant-1.3.3/lib/vagrant/util/busy.rb:19:in `busy' >> from >> /usr/share/gems/gems/vagrant-1.3.3/lib/vagrant/action/runner.rb:61:in >> `run' >> from >> /usr/share/gems/gems/vagrant-1.3.3/lib/vagrant/action/builtin/call.rb:51:in >> `call' >> from >> /usr/share/gems/gems/vagrant-1.3.3/lib/vagrant/action/warden.rb:34:in >> `call' >> from >> /usr/share/gems/gems/vagrant-kvm-0.1.4/lib/vagrant-kvm/action/init_storage_pool.rb:14:in >> `call' >> from >> /usr/share/gems/gems/vagrant-1.3.3/lib/vagrant/action/warden.rb:34:in >> `call' >> from >> /usr/share/gems/gems/vagrant-1.3.3/lib/vagrant/action/builtin/config_validate.rb:25:in >> `call' >> from >> /usr/share/gems/gems/vagrant-1.3.3/lib/vagrant/action/warden.rb:34:in >> `call' >> from >> /usr/share/gems/gems/vagrant-kvm-0.1.4/lib/vagrant-kvm/action/set_name.rb:25:in >> `call' >> from >> /usr/share/gems/gems/vagrant-1.3.3/lib/vagrant/action/warden.rb:34:in >> `call' >> from >> /usr/share/gems/gems/vagrant-kvm-0.1.4/lib/vagrant-kvm/action/check_kvm.rb:18:in >> `call' >> from >> /usr/share/gems/gems/vagrant-1.3.3/lib/vagrant/action/warden.rb:34:in >> `call' >> from >> /usr/share/gems/gems/vagrant-1.3.3/lib/vagrant/action/builder.rb:116:in `call' >> >> from >> /usr/share/gems/gems/vagrant-1.3.3/lib/vagrant/action/runner.rb:61:in >> `block in run' >> from >> /usr/share/gems/gems/vagrant-1.3.3/lib/vagrant/util/busy.rb:19:in `busy' >> from >> /usr/share/gems/gems/vagrant-1.3.3/lib/vagrant/action/runner.rb:61:in >> `run' >> from >> /usr/share/gems/gems/vagrant-1.3.3/lib/vagrant/machine.rb:147:in `action' >> from >> /usr/share/gems/gems/vagrant-1.3.3/lib/vagrant/batch_action.rb:63:in >> `block (2 levels) in run' >> >> >I updated the package, but this is still not solved, though it works on >F18. If the directory is owned by the user then the image gets copied >but libvirt then can't access it... Not sure where to begin with that. >

1 0

please help test beta test candidate cloud images
by Matthew Miller 17 Oct '13

17 Oct '13

These are available from https://dl.fedoraproject.org/pub/alt/stage/20-Beta-TC5/Images/x86_64/ and https://dl.fedoraproject.org/pub/alt/stage/20-Beta-TC5/Images/i386/ Please help test these, either in OpenStack (or other private cloud systems, like Eucalyptus), or in EC2 -- the AMI ids are ami-e7a1f38e : us-east-1 image for x86_64 ami-6ba6f402 : us-east-1 image for i386 (you can confirm this by looking at files on the staging server) The test cases are here: https://fedoraproject.org/wiki/Test_Results:Fedora_20_Beta_TC5_Install?rd=T… and the more people we have looking the better. In particular beyond that basic smoketest, cloud-init has been updated to a new release with a lot of changes, and those things could stand to be exercised. See https://admin.fedoraproject.org/updates/FEDORA-2013-17760/cloud-init-0.7.2-… Thanks! -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>

5 6

Disabling firewalld on AWS?
by Sam Kottler 17 Oct '13

17 Oct '13

Greetings, Given the deny-by-default nature of security groups I think it makes sense to disable firewalld in the AMI's. I haven't seen any other AMI's that have a firewall enabled by default and we probably shouldn't break that pattern IMO. Thoughts? -Sam

8 20

F20 Beta test qcow2 (testers wanted please)
by Matthew Miller 15 Oct '13

15 Oct '13

https://dl.fedoraproject.org/pub/alt/stage/20-Beta-TC4/Images/x86_64/ I tried out the x86_64 image and it seems to be basically sound, with one big caveat. Cloud-init is still waiting to be updated -- see https://admin.fedoraproject.org/updates/FEDORA-2013-17760/cloud-init-0.7.2-… and test and give karma, please. (This is why, for example, the root partition isn't growing.) -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>

1 0

2 commits - container/buildcontainers.sh container/container-medium-19.ks container/container-medium-20.ks
by Matthew Miller 14 Oct '13

14 Oct '13

container/buildcontainers.sh | 8 +++++++- container/container-medium-19.ks | 2 +- container/container-medium-20.ks | 1 + 3 files changed, 9 insertions(+), 2 deletions(-) New commits: commit 420acb16982c7643185d7bb0b36c48ff57571f50 Author: Matthew Miller <mattdm(a)mattdm.org> Date: Mon Oct 14 18:30:14 2013 -0400 no rsyslog inside the container diff --git a/container/container-medium-19.ks b/container/container-medium-19.ks index ebdedff..44df6f4 100644 --- a/container/container-medium-19.ks +++ b/container/container-medium-19.ks @@ -50,9 +50,9 @@ firewalld -parted -plymouth -policycoreutils +-rsyslog -selinux-policy-targeted - %end diff --git a/container/container-medium-20.ks b/container/container-medium-20.ks index b9a9cbe..a644264 100644 --- a/container/container-medium-20.ks +++ b/container/container-medium-20.ks @@ -50,6 +50,7 @@ firewalld -parted -plymouth -policycoreutils +-rsyslog -selinux-policy-targeted commit 91a6d05b1c450b9c09e459899b1c329393bb2032 Author: Matthew Miller <mattdm(a)mattdm.org> Date: Mon Oct 14 18:29:33 2013 -0400 tag containers with my repo, for now. again, this is a kludgey script not meant for real use diff --git a/container/buildcontainers.sh b/container/buildcontainers.sh index 90e3d49..e99b8d6 100755 --- a/container/buildcontainers.sh +++ b/container/buildcontainers.sh @@ -1,10 +1,16 @@ #!/bin/bash -x +repoowner=mattdm for size in small medium; do for ver in 19 20; do + if [[ "$size" == 'medium' ]]; then + repo=$repoowner/fedora + else + repo=$repoowner/fedora-$size + fi appliance-creator -c container-$size-$ver.ks -d -v -t /tmp \ -o /tmp/f$ver$size --name "fedora-$ver-$size" --release $ver \ --format=qcow2 && virt-tar-out -a /tmp/f$ver$size/fedora-$ver-$size/fedora-$ver-$size-sda.qcow2 / - | - docker import - fedora$ver-$size + docker import - $repo f$ver done done

1 0

container/description-medium.md container/description-minimal.md
by Matthew Miller 14 Oct '13

14 Oct '13

container/description-medium.md | 3 +++ container/description-minimal.md | 3 +++ 2 files changed, 6 insertions(+) New commits: commit 963439126a7e7180fe7384adad4e8f55895814e2 Author: Matthew Miller <mattdm(a)mattdm.org> Date: Mon Oct 14 14:47:01 2013 -0400 add descriptions for the container images diff --git a/container/description-medium.md b/container/description-medium.md new file mode 100644 index 0000000..74b0b91 --- /dev/null +++ b/container/description-medium.md @@ -0,0 +1,3 @@ +A basic Fedora image corresponding roughly to a minimal install, minus some things which don't make sense in a container. Use tag `f19` for Fedora 19. + +Generated from https://git.fedorahosted.org/cgit/cloud-kickstarts.git/tree/container/conta… via `appliance-creator`. \ No newline at end of file diff --git a/container/description-minimal.md b/container/description-minimal.md new file mode 100644 index 0000000..bbe1718 --- /dev/null +++ b/container/description-minimal.md @@ -0,0 +1,3 @@ +A small Fedora image on which to build. Contains just enough that you'll be able to run `yum install` in your dockerfiles to create something useful. Use tag `f19` for Fedora 19. + +Generated from <https://git.fedorahosted.org/cgit/cloud-kickstarts.git/tree/container/conta…> via `appliance-creator`. \ No newline at end of file

1 0

generic/fedora-20-cloud.ks
by Dennis Gilmore 14 Oct '13

14 Oct '13

generic/fedora-20-cloud.ks | 15 +++++++++++---- 1 file changed, 11 insertions(+), 4 deletions(-) New commits: commit 3eb95005f76ed2af8253f635be70dd94e292a171 Author: Dennis Gilmore <dennis(a)ausil.us> Date: Sun Oct 13 23:27:00 2013 -0500 Breaks comppses Revert "anaconda no longer requires firewalld" This reverts commit c3df27a4f11705831502415a5e03b0fe3a19383d. diff --git a/generic/fedora-20-cloud.ks b/generic/fedora-20-cloud.ks index 62582a8..2c9294e 100644 --- a/generic/fedora-20-cloud.ks +++ b/generic/fedora-20-cloud.ks @@ -19,8 +19,9 @@ auth --useshadow --enablemd5 selinux --enforcing rootpw --lock --iscrypted locked -# a static firewall allowing ssh is configured below -firewall --disabled +# this is actually not used, but a static firewall +# matching these rules is generated below. +firewall --service=ssh bootloader --timeout=1 --append="console=ttyS0,115200n8 console=tty0" extlinux @@ -65,10 +66,11 @@ dracut-config-generic # by anaconda, but appliance-creator needs the hint 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 iptables-services. --firewalld +# security groups you can remove this. iptables-services # cherry-pick a few things from @standard @@ -134,6 +136,11 @@ echo . echo "Removing linux-firmware package." yum -C -y remove linux-firmware +# Remove firewalld; was supposed to be optional in F18+, but is required to +# be present for install/image building. +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

1 0

3.11.1 kernel upgrade fails: any way to use former kernel?
by sean darcy 14 Oct '13

14 Oct '13

Using Fedora-x86_64-19-20130627-sda (ami-10cce555) on us-west-1b, I updated to the recent kernel. Now it won't boot. It seems initrd is fried. Anyway to get in to make it to boot from a previous kernel? Or is this another argument for making more frequent snapshots? BTW, this kernel worked with another instance in asia. Perhaps it's an aws issue in us-west? sean syslog: [J Booting 'Fedora (3.11.2-201.fc19.x86_64) 19 (Schrödinger’s Cat)' root (hd0) Filesystem type is ext2fs, using whole disk kernel /boot/vmlinuz-3.11.2-201.fc19.x86_64 ro root=UUID=e3577648-5703-459d-b55 7-b3947684f8ab serial=tty0 console=ttyS0,115200n8 console=hvc0 console=tty1 LAN G=en_US.UTF-8 initrd /boot/initramfs-3.11.2-201.fc19.x86_64.img block error -1 for op 0 Error 3: Bad or corrupt data while decompressing file Press any key to continue...Xen Minimal OS! start_info: 0xac4000(VA) nr_pages: 0x26700 shared_inf: 0x8c534000(MA) pt_base: 0xac7000(VA) nr_pt_frames: 0x9 mfn_list: 0x990000(VA) mod_start: 0x0(VA) mod_len: 0 flags: 0x0 cmd_line: root=/dev/sda1 ro 4 stack: 0x94f860-0x96f860 MM: Init _text: 0x0(VA) _etext: 0x5ff6d(VA) _erodata: 0x78000(VA) _edata: 0x80b00(VA) stack start: 0x94f860(VA) _end: 0x98fe68(VA) start_pfn: ad3 max_pfn: 26700 Mapping memory range 0xc00000 - 0x26700000 setting 0x0-0x78000 readonly skipped 0x1000 MM: Initialise page allocator for c01000(c01000)-26700000(26700000) MM: done Demand map pfns at 26701000-2026701000. Heap resides at 2026702000-4026702000. Initialising timer interface Initialising console ... done. gnttab_table mapped at 0x26701000. Initialising scheduler Thread "Idle": pointer: 0x2026702010, stack: 0x26640000 Initialising xenbus Thread "xenstore": pointer: 0x20267027c0, stack: 0x26650000 Dummy main: start_info=0x96f960 Thread "main": pointer: 0x2026702f70, stack: 0x26660000 "main" "root=/dev/sda1" "ro" "4" vbd 2049 is hd0 ******************* BLKFRONT for device/vbd/2049 ********** backend at /local/domain/0/backend/vbd/544/2049 Failed to read /local/domain/0/backend/vbd/544/2049/feature-barrier. Failed to read /local/domain/0/backend/vbd/544/2049/feature-flush-cache. 4194304 sectors of 512 bytes ************************** Thread "kbdfront": pointer: 0x2026830010, stack: 0x26680000 ******************* FBFRONT for device/vfb/0 ********** ******************* KBDFRONT for device/vkbd/0 ********** Failed to read device/vfb/0/backend-id. Failed to read device/vkbd/0/backend-id. Error ENOENT when reading the backend path device/vkbd/0/backend Thread "kbdfront" exited. Error ENOENT when reading the backend path device/vfb/0/backend

3 4

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cloud October 2013