All,
I finally found the time to do some testing with the F20 image in HP Cloud Beta which runs some sort of OpenStack Havana. Here are my comments (which are obviously very OpenStack centric):
Overall it looks very sound. Good job, Matt!
As mentioned by others, logging could be improved. Currently, only kernel messages are written to the (serial) console log. If something goes wrong higher up in the stack (like cloud-init is unable to contact the metadata service or a crucial initrd process fails) we can't tell, unless there's access to the virtual console of the instance which not every cloud operator provides. If we reverse the 'console' options of the kernel command line, we get those messages on the serial console which helps with debugging boot issues. Also, I'm not sure how useful the 115200n8 ttyS0 option is, it's a virtual port after all. Lastly, Ubuntu uses console=tty1 instead of tty0 for reasons explained in https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1016695. I admit I do not fully understand the impact of using tty1 (first console) vs tty0 (foreground console) and neither do I think we need to blindly copy Ubuntu but they are the cloud-init guys after all and they do provide very solid OpenStack cloud images so it seems like they know what they're doing :-) Given that, my proposal is to use the following console kernel command line options: 'console=tty1 console=ttyS0'
I was quite surprised to learn that the image can be enlarged to 2TB. Other images fail because the ext4 journal is too small. I haven't looked into it in detail but do you use special parameters when formatting the root partition?
...Juerg
On Mon, Nov 25, 2013 at 06:12:57PM +0100, Juerg Haefliger wrote:
they do provide very solid OpenStack cloud images so it seems like they know what they're doing :-) Given that, my proposal is to use the following console kernel command line options: 'console=tty1 console=ttyS0'
We currently have this the other way around, and indeed, in OpenStack as we're doing it currently, this means that, for example, cloud-init output goes to the vnc console rather than the log. Should we flip it?
On Tue, Dec 10, 2013 at 01:47:25PM -0500, Matthew Miller wrote:
We currently have this the other way around, and indeed, in OpenStack as we're doing it currently, this means that, for example, cloud-init output goes to the vnc console rather than the log. Should we flip it?
Having console output on the virtual serial port is great because it becomes accessible via the api (or via "nova console-log"), whereas on the VNC console it's basically discarded.
On Wed, Dec 11, 2013 at 12:28 AM, Lars Kellogg-Stedman lars@redhat.com wrote:
Having console output on the virtual serial port is great because it becomes accessible via the api (or via "nova console-log"), whereas on the VNC console it's basically discarded.
+1
Kushal
On Dec 10, 2013 7:58 PM, "Lars Kellogg-Stedman" lars@redhat.com wrote:
On Tue, Dec 10, 2013 at 01:47:25PM -0500, Matthew Miller wrote:
We currently have this the other way around, and indeed, in OpenStack as we're doing it currently, this means that, for example, cloud-init
output
goes to the vnc console rather than the log. Should we flip it?
Having console output on the virtual serial port is great because it becomes accessible via the api (or via "nova console-log"), whereas on the VNC console it's basically discarded.
+1
-- Lars Kellogg-Stedman lars@redhat.com | larsks @ irc Cloud Engineering / OpenStack | " " @ twitter
cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
On 2013-12-10 10:58, Lars Kellogg-Stedman wrote:
On Tue, Dec 10, 2013 at 01:47:25PM -0500, Matthew Miller wrote:
We currently have this the other way around, and indeed, in OpenStack as we're doing it currently, this means that, for example, cloud-init output goes to the vnc console rather than the log. Should we flip it?
Having console output on the virtual serial port is great because it becomes accessible via the api (or via "nova console-log"), whereas on the VNC console it's basically discarded.
Yep, that's how it works in eucalyptus as well. We're already special-casing EC2 anyway, so I say go for it. 8^)
-- Garrett Holmstrom
On Tue, Dec 10, 2013 at 11:53:07AM -0800, Garrett Holmstrom wrote:
Yep, that's how it works in eucalyptus as well. We're already special-casing EC2 anyway, so I say go for it. 8^)
Okay, done in rawhide. I'll ask for a freeze exception for f20. (And apologize for not doing this sooner.)