Older blog entries for skvidal (starting at number 455)

openstack and resizing qcow-based instances

So – the trick with resizing a qcow based instances is this:

1. either you have to resize the partitions in the initramfs of the instance (which is not yet available as something we can easily do, but we’re working on it :)

2. you have to resize the partition on the live instance and then reboot the instance.

Since 1 is going to take more time/testing – I went ahead to make 2 as painless as possible.

using the cloud-utils and ansible I came up with this:

http://skvidal.fedorapeople.org/misc/openstack-qcow-disk-resize.yml

Put in the hosts you want to run it against. It installs cloud-utils, resizes the partitions using growpart, reboots, waits for the instance to come back alive, then does the fs resizing.

I timed it – it took a total of 1m2s and that includes installing cloud-utils, waiting at minimum 10s for the instance to reboot and then resizing the  actual fs.

The example I gave checks the values from growpart – so it  won’t run more than once (and it won’t run if you cannot resize). So you can run this play over and over and not reboot it all the time. I’m thinking I’ll probably include this as a tasklist for a quick instance provisioning playbook.

 


Syndicated 2013-02-21 22:37:55 from journal/notes

1 step forward 2 steps back? openstack and img creation suck

dealing with image creation in all clouds is completely full of suck. I’d more or less come to terms on it with euca but now I’m trying to do the same thing with openstack and encountering some super-duper happy fun times.

I have a rhel6 img which works and boots – it is qcow2 based so it handles kernel updates, etc properly, yay. However it handles resizing  the / filesystem exactly not at all.

If I make the rhel6 img an ami and upload kernel/ramdisk – it’ll resize (well dump it out) into a large filesystem – no problem – but it handles kernel updates not at all.

 

I would like to have both, I think I deserve to have both, i’ll be damned if any of my testing comes up with both. I’ve done a fair amount of googling and LOTS of things I’ve found say that the qcow2 or raw img should just work in either openstack essex or folsom but I am not having that experience.

Anyone have a suggestion?


Syndicated 2013-02-20 05:52:12 from journal/notes

hubris

Is thinking that because something is working well that it will continue to do so.

 

Silly me.

 

 


Syndicated 2013-02-19 18:43:15 from journal/notes

coprs and buildsystems and a question I was asked today.

Work continues on coprs but today someone asked me if I knew of a simpler buildsystem that would let them spin up a builder, stuff a bunch of packages at it, and return a pile of results.

I said well… ansible and mockremote could do it.

I started thinking about HOW that would work and realized I have all the pieces – but not a lot of motivation to put it together at the moment.

So I thought I’d tell folks how I would do it and maybe someone will:

 

1. write a playbook to spin up an instance in one of the public clouds using ansible and it’s ec2 module:

http://skvidal.fedorapeople.org/misc/ansible-euca-transient.yml

2. then provision the system with mock, a mockbuilder user and mockchain.

3. tell the user the ip the instance has

4. user submits jobs to it with:

mockremote.py -r chroot -b ip –destdir=/somewhere/ -c –recurse pkg1 pkg2 pkg3

5. user comes back whenever it feels like it

6. user runs a terminate playbook like:

http://infrastructure.fedoraproject.org/infra/ansible/files/copr/provision/terminatepb.yml

which shuts down the instance they had spun up.

I can see wrapping that whole thing in a single script or just letting the user do it a bit at a time. Either way – trivial to setup your own personal, temporary and pristine builder.

 


Syndicated 2013-02-01 21:38:17 from journal/notes

coprs and fudcon

I’m still working on recaps from fudcon but I wanted to mention this to anyone who asked:

 

If you asked for access to coprs and you haven’t received a reply from me that is b/c I forgot that you asked. Please drop me an email and I can add you.

 

Thanks


Syndicated 2013-01-22 16:53:16 from journal/notes

copr status

We’ve gone through about 45 individual builds of a goodly number of pkgs thanks to the help of the testing volunteers. We’ve found a bunch of bugs and fixed many of them.

Here’s what’s changed:

1. we’re working on cli for copr – more info in this thread: https://lists.fedorahosted.org/pipermail/copr-devel/2013-January/000216.html

2. we’ve got some mockups from the UI team which should help mold where things can go

3. better logs and results for multiple builds

4. I took a first cut of an outline for setting up copr: http://git.fedorahosted.org/cgit/copr.git/tree/copr-setup.txt

 


Syndicated 2013-01-15 20:12:03 from journal/notes

fudcon tips and the flu

Hi everyone, it is time for my annual plea to everyone going to fudcon to wash their hands many many times, try not to cough or sneeze on anyone and to do their best to not touch me at all.

It is winter and we’re in the middle of a massive flu and norovirus outbreak here in the US.

http://www.nytimes.com/2013/01/10/health/flu-widespread-leading-a-range-of-winters-ills.html?hp&_r=0

If at all possible I would like to come back from fudcon without bringing any sort of pestilence with me.

This is just a reminder that if you see me incased in a plastic ball don’t be alarmed just smile and wave. :)

 

 

 


Syndicated 2013-01-10 15:15:01 from journal/notes

coprs status

My call for testers was successful. We have 21 people now who have access to coprs and a number of folks have started testing builds out. We’ve found some bugs and some feature enhancements needed. Also discussion has started on the copr devel mailing list and we’ve gotten some patches contributed to help us make a cli come to pass.

If anyone else wants to take a look at the code and help out, you can see it all here in copr cgit.

thanks to all the folks who are helping test and develop the copr code.

 

 


Syndicated 2013-01-08 18:30:00 from journal/notes

call for serious testers

Right now, we have coprs working. It’s not fancy or beautiful and I am POSITIVE many bugs are lurking there (and some aren’t lurking at all just sitting there). So, we need people who will seriously undertake testing. I don’t want people who want to build things and don’t care about reporting issues. I also don’t want people who are going to be filled with destructive criticism.

If you want to test it out and cite issues please email me: skvidal at fedoraproject.org

you must already have an active fas account and some srpms you want to build.

I only need maybe 10 or 20 people at the moment. Not looking to overdo it :)

Thanks

 


Syndicated 2013-01-02 20:09:02 from journal/notes

jenkins and ansible and ‘the cloud’

Working with Pingou on this I merged the playbooks into a single playbook. We were setting up jenkins and wanted a way of putting all the systems together quickly and easily. All it does is spin up a master instance, provision it, spin up 2 workers (one in el6 the other f17) provision them and end:

It could easily be done in ec2, euca, openstack or pretty much any system. I know there are more ways to skin this cat but I thought this was simple enough to follow along and others might find it interesting.

This is the playbook:

http://infrastructure.fedoraproject.org/infra/ansible/playbooks/groups/jenkins-cloud.yml

 

all of our ansible playbooks and inventory files are available here:

http://infrastructure.fedoraproject.org/infra/ansible/

 


Syndicated 2012-12-19 06:15:18 from journal/notes

446 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!