hi
I've just pushed a GenericCloud image, that will become the gold standard to build all varients and environ specific images from. Requesting people to help test this image :
http://cloud.centos.org/centos/7/devel/CentOS-7-x86_64-GenericCloud-20140826... ( ~ 922 MB) or http://cloud.centos.org/centos/7/devel/CentOS-7-x86_64-GenericCloud-20140826... ( 261 MB)
Sha256's;
3c049c21c19fb194cefdddbac2e4eb6a82664c043c7f2c7261bbeb32ec64023f CentOS-7-x86_64-GenericCloud-20140826_02.qcow2 4a16ca316d075b30e8fdc36946ebfd76c44b6882747a6e0c0e2a47a8885323b1 CentOS-7-x86_64-GenericCloud-20140826_02.qcow2.xz
please note: these images contain unsigned content ( cloud-init and cloud-utils-* ), and are therefore unsuiteable for use beyond validation on your environment.
Also note, that the desktop Generic image will eventually have cloud-init removed ( but not cloud-utils ). If thats hard to achieve, then we might want to ship a pre-setup config drive or a built in datasource in the image itself.
regards,
On 27 Aug 2014, at 11:42, Karanbir Singh mail-lists@karan.org wrote:
http://cloud.centos.org/centos/7/devel/CentOS-7-x86_64-GenericCloud-20140826...
I’ve registered the image as 'img-c3f00’ on Brightbox Cloud for those that fancy taking it for a spin.
The disk expands correctly, and the centos user picks up metadata just fine. Both IPv6 and IPv4 are working.
Initial look suggests the following potential issues:
The system is not taking note of the domain issued via DHCP. The system journal is showing ‘local domain’ as the domain.
Aug 27 11:02:54 srv-28qnz.localdomain NetworkManager[447]: <info> Setting system hostname to 'srv-28qnz.localdomain' (from system configuration)
Additional the avahi daemon is running but appears to start before DHCP/cloud-init has assigned the hostname, or doesn’t reinitialise on the change of hostname.
Those are very minor issues that don’t really detract from the usability of the image.
Looks very good here.
Rgs
Neil
http://cloud.centos.org/centos/7/devel/CentOS-7-x86_64-GenericCloud-20140826... ( ~ 922 MB)
The qcow2 filesize looks unreasonably large compared to the xz compressed version. Zero-filling and qcow2-compressing the image reduced its size to ~350MB.
On Wed, Aug 27, 2014 at 1:28 PM, Neil Wilson neil@brightbox.co.uk wrote:
On 27 Aug 2014, at 11:42, Karanbir Singh mail-lists@karan.org wrote:
http://cloud.centos.org/centos/7/devel/CentOS-7-x86_64-GenericCloud-20140826...
I've registered the image as 'img-c3f00' on Brightbox Cloud for those
that fancy taking it for a spin.
The disk expands correctly, and the centos user picks up metadata just
fine. Both IPv6 and IPv4 are working.
Initial look suggests the following potential issues:
The system is not taking note of the domain issued via DHCP. The system
journal is showing 'local domain' as the domain.
Aug 27 11:02:54 srv-28qnz.localdomain NetworkManager[447]: <info> Setting
system hostname to 'srv-28qnz.localdomain' (from system configuration)
Additional the avahi daemon is running but appears to start before
DHCP/cloud-init has assigned the hostname, or doesn't reinitialise on the change of hostname.
cloud-init debug messages don't show up on the console and are also not logged in /var/log/cloud-init.log. I don't claim I understand cloud-init's logging crazyness but there's some unfortunate interaction with systemd. I *think* the problem is that systemd swallows console messages from legacy services and only writes them to the journal but not the console. In fact, no output from any of the other legacy services appear on the console which could help with debugging boot issues. Setting "ForwardToConsole=yes" in /etc/systemd/journald.conf 'fixes' the issues.
Other than that: Ship it!
...Juerg
Those are very minor issues that don't really detract from the usability
of the image.
Looks very good here.
Rgs
Neil
CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
On 08/27/2014 02:09 PM, Juerg Haefliger wrote:
http://cloud.centos.org/centos/7/devel/CentOS-7-x86_64-GenericCloud-20140826... ( ~ 922 MB)
The qcow2 filesize looks unreasonably large compared to the xz compressed version. Zero-filling and qcow2-compressing the image reduced its size to ~350MB.
adding in a dd bs=4096 if=/dev/zero of=/var/tmp/zeros thing... but how wildely accepted is the qcow2c format ? I recall feedback from people saying that those were causing issues in some places, and most folks just wanted qcow2
cloud-init debug messages don't show up on the console and are also not logged in /var/log/cloud-init.log. I don't claim I understand cloud-init's logging crazyness but there's some unfortunate interaction with systemd. I *think* the problem is that systemd swallows console messages from legacy services and only writes them to the journal but not the console. In fact, no output from any of the other legacy services appear on the console which could help with debugging boot issues. Setting "ForwardToConsole=yes" in /etc/systemd/journald.conf 'fixes' the issues.
will experiment.
Other than that: Ship it!
Depending on how things go - I will move to signing the cloud-init rpms, releasing them, and then doing another build on Friday AM UTC.
- KB
On 08/27/2014 12:28 PM, Neil Wilson wrote:
On 27 Aug 2014, at 11:42, Karanbir Singh <mail-lists@karan.org mailto:mail-lists@karan.org> wrote:
http://cloud.centos.org/centos/7/devel/CentOS-7-x86_64-GenericCloud-20140826...
I’ve registered the image as 'img-c3f00’ on Brightbox Cloud for those that fancy taking it for a spin.
being able to just ftp an image over is... very nice :)
The disk expands correctly, and the centos user picks up metadata just fine. Both IPv6 and IPv4 are working.
Initial look suggests the following potential issues:
The system is not taking note of the domain issued via DHCP. The system journal is showing ‘local domain’ as the domain.
the hostname setting code in cloud-init needed some patching to make work in centos7, let me go back and look at it.
Aug 27 11:02:54 srv-28qnz.localdomain NetworkManager[447]: <info> Setting system hostname to 'srv-28qnz.localdomain' (from system configuration)
Additional the avahi daemon is running but appears to start before DHCP/cloud-init has assigned the hostname, or doesn’t reinitialise on the change of hostname.
Zeroconf / Avahi should be turned off. will investigate
Hi,
2 questions:
- are these "generic" images supposed to work correctly in EC2 and Openstack environments?
- where's the kickstart? I want to use it to build Cloudstack templates
-- Sent from the Delta quadrant using Borg technology!
Nux! www.nux.ro
----- Original Message -----
From: "Karanbir Singh" mail-lists@karan.org To: "The CentOS developers mailing list." centos-devel@centos.org Sent: Wednesday, 27 August, 2014 11:42:44 AM Subject: [CentOS-devel] Request for testing / validation for GenericCloud image
hi
I've just pushed a GenericCloud image, that will become the gold standard to build all varients and environ specific images from. Requesting people to help test this image :
http://cloud.centos.org/centos/7/devel/CentOS-7-x86_64-GenericCloud-20140826... ( ~ 922 MB) or http://cloud.centos.org/centos/7/devel/CentOS-7-x86_64-GenericCloud-20140826... ( 261 MB)
Sha256's;
3c049c21c19fb194cefdddbac2e4eb6a82664c043c7f2c7261bbeb32ec64023f CentOS-7-x86_64-GenericCloud-20140826_02.qcow2 4a16ca316d075b30e8fdc36946ebfd76c44b6882747a6e0c0e2a47a8885323b1 CentOS-7-x86_64-GenericCloud-20140826_02.qcow2.xz
please note: these images contain unsigned content ( cloud-init and cloud-utils-* ), and are therefore unsuiteable for use beyond validation on your environment.
Also note, that the desktop Generic image will eventually have cloud-init removed ( but not cloud-utils ). If thats hard to achieve, then we might want to ship a pre-setup config drive or a built in datasource in the image itself.
regards,
-- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
On Wed, Aug 27, 2014 at 4:23 PM, Nux! nux@li.nux.ro wrote:
Hi,
2 questions:
- are these "generic" images supposed to work correctly in EC2 and
Openstack environments?
Forgot to mention, my testing was done in OpenStack.
- where's the kickstart? I want to use it to build Cloudstack templates
Yeah would be nice to maybe include it in the image itself.
...Juerg
-- Sent from the Delta quadrant using Borg technology!
Nux! www.nux.ro
----- Original Message -----
From: "Karanbir Singh" mail-lists@karan.org To: "The CentOS developers mailing list." centos-devel@centos.org Sent: Wednesday, 27 August, 2014 11:42:44 AM Subject: [CentOS-devel] Request for testing / validation for
GenericCloud image
hi
I've just pushed a GenericCloud image, that will become the gold standard to build all varients and environ specific images from. Requesting people to help test this image :
http://cloud.centos.org/centos/7/devel/CentOS-7-x86_64-GenericCloud-20140826...
( ~ 922 MB) or
http://cloud.centos.org/centos/7/devel/CentOS-7-x86_64-GenericCloud-20140826...
( 261 MB)
Sha256's;
3c049c21c19fb194cefdddbac2e4eb6a82664c043c7f2c7261bbeb32ec64023f CentOS-7-x86_64-GenericCloud-20140826_02.qcow2 4a16ca316d075b30e8fdc36946ebfd76c44b6882747a6e0c0e2a47a8885323b1 CentOS-7-x86_64-GenericCloud-20140826_02.qcow2.xz
please note: these images contain unsigned content ( cloud-init and cloud-utils-* ), and are therefore unsuiteable for use beyond validation on your environment.
Also note, that the desktop Generic image will eventually have cloud-init removed ( but not cloud-utils ). If thats hard to achieve, then we might want to ship a pre-setup config drive or a built in datasource in the image itself.
regards,
-- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
On 08/27/2014 02:51 PM, Juerg Haefliger wrote:
On Wed, Aug 27, 2014 at 4:23 PM, Nux! <nux@li.nux.ro mailto:nux@li.nux.ro> wrote:
Hi,
2 questions:
- are these "generic" images supposed to work correctly in EC2 and
Openstack environments?
Forgot to mention, my testing was done in OpenStack.
this image should work in most places where cloud-init works, I've tested in ec2 and eucalyptus - and also on a local virt-manager setup with a fudged config drive iso attached in.
At this point, we will likely need a custom variant for cloudstack, ovirt, vmware etc. but as much as possible, it would be great to have a common generic one that works everywhere.
- where's the kickstart? I want to use it to build Cloudstack templates
Cloudstack should really just try and get cloud-init working. I still dont understand what the challenge there is.
Yeah would be nice to maybe include it in the image itself.
I'll need to clean it up a bit, at the moment its got lots of private stuff from the buildsys in there, plus a bunch of things are done after the build is finished.
I guess all the bits can be squashed into a tarball and left in /root - will investigate that as well.
- KB
On 08/27/2014 09:15 AM, Karanbir Singh wrote:
I'll need to clean it up a bit, at the moment its got lots of private stuff from the buildsys in there, plus a bunch of things are done after the build is finished.
I guess all the bits can be squashed into a tarball and left in /root - will investigate that as well.
Or thrown into the git repo at > https://github.com/CentOS/sig-cloud-instance-build/
That would be quite useful as well.
Cloudstack should really just try and get cloud-init working. I still dont understand what the challenge there is.
For cloud-init to play ball with Cloudstack 3 things need to happen:
1 - This patch https://bugs.launchpad.net/cloud-init/+bug/1356855/ (should not affect anything else and also should not be needed in later versions, ie 0.7.6+)
2 - As it is, cloud-init will use the Openstack data source by default and it will not work in a Cloudstack environment, it needs to be told to use the Cloudstack data source in the cfg file
3 - The data source is not capable of setting the user/root password, a 3rd party script needs to be bundled in - this step can be optional if ssh keys are the only means allowed for authentication, but this would also make the image pretty useless in many ACS environs that AFAIK do use the feature
We are working on fixing point 3, but it will not happen "tomorrow" and even if it did the cfg still needs to be modified to use the ACS data source.
This is why I proposed a cloud-init-cloudstack subpackage, even if we fix 3, 2 will still get in the way.
Let me know if you have other questions.
Lucian
On 08/27/2014 04:12 PM, Nux! wrote:
Cloudstack should really just try and get cloud-init working. I still dont understand what the challenge there is.
For cloud-init to play ball with Cloudstack 3 things need to happen:
1 - This patch https://bugs.launchpad.net/cloud-init/+bug/1356855/ (should not affect anything else and also should not be needed in later versions, ie 0.7.6+)
well, cloudstack fixed their bug as well to not need this patch anymore, admittedly - this happened yesterday:
https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=blobdiff;f=system...
2 - As it is, cloud-init will use the Openstack data source by default and it will not work in a Cloudstack environment, it needs to be told to use the Cloudstack data source in the cfg file
But, its able to consume all the other datasources without needing to set priority order. Can you verify this is still the case with cloud-init 0.7.5 and propose a patch against the cloud.cfg file in https://git.centos.org/summary/rpms!cloud-init.git in branch c7-extras ?
3 - The data source is not capable of setting the user/root password, a 3rd party script needs to be bundled in - this step can be optional if ssh keys are the only means allowed for authentication, but this would also make the image pretty useless in many ACS environs that AFAIK do use the feature
but you can set a password using user-data scripts right ? so if we were to support ssh-keys out of the box, with the site specific admin being able to default a user-data script, that would resolve the equation from both sides.
regards
1 - This patch https://bugs.launchpad.net/cloud-init/+bug/1356855/ (should not affect anything else and also should not be needed in later versions, ie 0.7.6+)
well, cloudstack fixed their bug as well to not need this patch anymore, admittedly - this happened yesterday:
https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=blobdiff;f=system...
Yes, indeed, but this is for the unreleased version of Cloudstack, all the existing deployments will not be capable of this and the patch is required, probably the main reason upstream has accepted it.
2 - As it is, cloud-init will use the Openstack data source by default and it will not work in a Cloudstack environment, it needs to be told to use the Cloudstack data source in the cfg file
But, its able to consume all the other datasources without needing to set priority order. Can you verify this is still the case with cloud-init 0.7.5 and propose a patch against the cloud.cfg file in https://git.centos.org/summary/rpms!cloud-init.git in branch c7-extras ?
Sure, will do. 0.7.4 was not capable of this, which is why I haven't even thought of attempting it. I'll update you with my findings.
3 - The data source is not capable of setting the user/root password, a 3rd party script needs to be bundled in - this step can be optional if ssh keys are the only means allowed for authentication, but this would also make the image pretty useless in many ACS environs that AFAIK do use the feature
but you can set a password using user-data scripts right ? so if we were to support ssh-keys out of the box, with the site specific admin being able to default a user-data script, that would resolve the equation from both sides.
In theory yes, but this feature, while proposed - still needs to be approved and the software modified for it. There is a relatively tight integration of the UI and the feature, so multiple components need to be modified. It will take time and needless to say existing deployments will not have it.
Lucian
Hi,
The Generic image fails to work in Cloudstack because of the trailing slash issue. This patch is required: http://tmp.nux.ro/Hg4-cloud-init-centos-cloudstack-trailingslash.patch
(I've rebuilt your cloud-init with this patch and I can confirm ssh key authentication works OK)
https://bugs.launchpad.net/cloud-init/+bug/1356855/
But, its able to consume all the other datasources without needing to set priority order. Can you verify this is still the case with cloud-init 0.7.5 and propose a patch against the cloud.cfg file in https://git.centos.org/summary/rpms!cloud-init.git in branch c7-extras ?
Sure, will do. 0.7.4 was not capable of this, which is why I haven't even thought of attempting it. I'll update you with my findings.
Hello,
I've tested the image with OpenNebula 4.8 and qemu/kvm. It does not contextualize as is. Commenting the requiretty line from sudoers file makes both the network and the SSH key installation for "centos" user work.
It is tested both with rtl and virtio networks.
Cheers
On Wed, Aug 27, 2014 at 12:42 PM, Karanbir Singh mail-lists@karan.org wrote:
hi
I've just pushed a GenericCloud image, that will become the gold standard to build all varients and environ specific images from. Requesting people to help test this image :
http://cloud.centos.org/centos/7/devel/CentOS-7-x86_64-GenericCloud-20140826... ( ~ 922 MB) or http://cloud.centos.org/centos/7/devel/CentOS-7-x86_64-GenericCloud-20140826... ( 261 MB)
Sha256's;
3c049c21c19fb194cefdddbac2e4eb6a82664c043c7f2c7261bbeb32ec64023f CentOS-7-x86_64-GenericCloud-20140826_02.qcow2 4a16ca316d075b30e8fdc36946ebfd76c44b6882747a6e0c0e2a47a8885323b1 CentOS-7-x86_64-GenericCloud-20140826_02.qcow2.xz
please note: these images contain unsigned content ( cloud-init and cloud-utils-* ), and are therefore unsuiteable for use beyond validation on your environment.
Also note, that the desktop Generic image will eventually have cloud-init removed ( but not cloud-utils ). If thats hard to achieve, then we might want to ship a pre-setup config drive or a built in datasource in the image itself.
regards,
-- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
On 08/27/2014 04:34 PM, Javier Fontan wrote:
Hello,
I've tested the image with OpenNebula 4.8 and qemu/kvm. It does not contextualize as is. Commenting the requiretty line from sudoers file makes both the network and the SSH key installation for "centos" user work.
It is tested both with rtl and virtio networks.
is it possible to use runuser rather than sudo ? that way, we wont need to patch out the requiretty section ?
Having said that : https://bugzilla.redhat.com/show_bug.cgi?id=1020147 - so maybe losing the requirtty might be the way forward anyway. I sort of agree with the overall direction of that bugreport. How does everyone else feel ?
regards,
I suppose we can use runuser but I don't know it it's available in other distros by default and may break compatibility. If this is needed I can change it, is only one line.
On Wed, Aug 27, 2014 at 5:36 PM, Karanbir Singh mail-lists@karan.org wrote:
On 08/27/2014 04:34 PM, Javier Fontan wrote:
Hello,
I've tested the image with OpenNebula 4.8 and qemu/kvm. It does not contextualize as is. Commenting the requiretty line from sudoers file makes both the network and the SSH key installation for "centos" user work.
It is tested both with rtl and virtio networks.
is it possible to use runuser rather than sudo ? that way, we wont need to patch out the requiretty section ?
Having said that : https://bugzilla.redhat.com/show_bug.cgi?id=1020147 - so maybe losing the requirtty might be the way forward anyway. I sort of agree with the overall direction of that bugreport. How does everyone else feel ?
regards,
-- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
-
Javier Fontan -
Jim Perrin -
Juerg Haefliger -
Karanbir Singh -
Neil Wilson -
Nux!