Apparently appliance-tools is not working properly. This leads to either:
* Cannot start doing updates for F17 until EC2 images are
* No EC2 for F17 Alpha (because updates will be in, and EC2 F17 alpha
would be different from Other Alphas)
I'm recommending going with the latter option, simply because there is
no criteria at all right now for making EC2 a blocker. Your (very
immediate) thoughts are welcomed. I'm not particularly interested in
slipping all of alpha after it met all of the shipping criteria and was
announced to be shippable.
Dennis, do you have a bug number for this (appliance-tools brokenness) yet?
I'm open to future recommendations, including doing a test
compose/upload of EC2 images so that we know this before we have a
go/no-go meeting, at the bare minimum. Please feel free to pipe in. :D
I'm looking to provide some feedback on cloud-init and the F16 AMI's. I'm not sure the proper place to file the bug against. I'm attempting to place a simple shell script in user data to perform post-boot configuration. This fails since I'm unable to execute anything within user data. (I'm hoping eventually to use cloud-config syntax)
The cloud-init startup process (sometime after placing the ssh keys) at one point runs: /usr/bin/cloud-init-cfg all final During this stage, run-parts gets run to actually execute the downloaded user data. It fails with the following:
CalledProcessError: Command '['run-parts', '--regex', '.*', '/var/lib/cloud/instance/scripts']
The --regex flag is not accepted by the Fedora version of run-parts. Debian/Ubuntu both have a compiled binary of run-parts that accepts this flag.
Here is a reproduction of it on an already booted machine:
I've got two solutions that seem to work in initial testing.
1) Backing in a copy of run-parts that accepts the additional arguments into a new ami.
2) Removing the regex flag + expression out of /usr/lib/python2.7/site-packages/cloudinit/util.py
So my question to the group. What is a better fix to peruse, adding functionality to run-parts, or patching util.py to not use the regex?
The new keystone (KSL) config file defaults to a key/value stores by default.
Should we update the default keystone config file so that it uses the SQL backend by default instead?
< driver = keystone.identity.backends.sql.Identity
> driver = keystone.identity.backends.kvs.Identity
I am trying to upgrade an AWS EC2 f16 to f17 following these instructions:
I start with AMI: ami-0316d86a as listed here:
The instructions describe:
"Change the following kernel commandline parameter directly in the bootloader menu, which
is shown during bootup, or edit the line in /etc/grub*.cfg to remove ro and rhgb and append rw
rd.info rd.convertfs enforcing=0"
However /etc/grub*.cfg is empty:
[root@domU-12-31-39-04-F1-72 etc]# file /etc/grub2.cfg
/etc/grub2.cfg: symbolic link to `../boot/grub2/grub.cfg'
[root@domU-12-31-39-04-F1-72 etc]# file ../boot/grub2/grub.cfg
Am I doing something wrong?
How can one get a f17 EC2 instance?
Thanks in advance for any help/suggestions.
For OpenStack Essex in Fedora 17, I thought it was worth discussing:
1) Should we switch to the new --config-file format by default? I
think we discussed this briefly before and decided we would. We
should probably go ahead to have it settled in before the test day.
2) I see we've added support for force_dhcp_release=True; should we
make it the default?
3) 'root_helper=sudo nova-rootwrap' is the default now, right? All
the test cases still work fine? No user impact?
4) 'rpc_backend=nova.rpc.impl_qpid' is also the default now? I think
we had some debate about whether we should require any of the
messaging libs by default? Did we come to a conclusion? My
instinct it to require the default lib only
I have posted a review request for a new package, ovirt-engine-cli.
You can find out more about it here:
The reason this is Cloud SIG related is that ovirt-engine-cli is an interface for the oVirt engine platform (www.ovirt.org), which is an open virtualization engine, used to manage a feature rich virtualization environment.
This review is part of the attempt to get oVirt into Fedora.
If it's necessary, I'd be happy to do a review in return.