<div dir="ltr"><div><div>On Tue, Apr 8, 2014 at 2:24 PM, Nux! <<a href="mailto:nux@li.nux.ro">nux@li.nux.ro</a>> wrote:<br>><br>> Hello,<br>><br>> While the Cloud SIG is still being established, let's get to actual<br>
> work and think of a set of features for a CentOS cloud template.<br>> I am referring here to VMs, not containers (e.g. docker).<br>><br>> This is how I see it so far, please feel free to come with<br>> suggestions/comments/questions.<br>
><br>> A - Single partition for simplicity (and lack of good arguments against<br>> it)<br><br></div>I was wondering about LVM. It makes reconfiguration much easier (like adding swap). But growroot doesn't support LVM.<br>
<br><div><br>>      - dracut-modules-growroot included so the template partition will<br>> expand to match target, cloud-init in charge of resize2fs<br><br></div><div>Only required for kernel < 3.8. Later kernels can do online partition resizing (handled by cloud-init post initrd).<br>
</div><div><br><br>> B - To swap or not to swap?<br><br></div><div>Some service providers charge for disk IOs and nobody wants to pay for swap activity, so I vote against swap.<br><br></div><div><br>> C - "tuned-adm profile virtual-host" which translates to:<br>
>      - kern.sched_min_granularity_ns 10ms<br>>      - kernel.sched_wakeup_granularity_ns 15ms<br>>      - vm.dirty_ratio 40%<br>>      - vm.swappiness 30<br>>      - IO scheduler "deadline"<br>>      - fs barriers off<br>
>      - CPU governor "performance"<br>>      - disk readahead 4x<br><br></div><div>Where do these come from? What's the rational?<br><br></div><div><br>> D - tso and gso off on the network interfaces <a href="http://s.nux.ro/gsotso">http://s.nux.ro/gsotso</a><br>
<br></div><div>These seem to be settings on the host, not the guest.<br><br></div><div><br>> E - network interface remapping (75-persistent-net-generator.rules, BZ<br>> 912801)<br><br></div><div>Not authorized to access that bug.<br>
</div><div><br><br>> F - Selinux on. Do we relabel for uniqueness? Seen small VMs run out of<br>> memory while relabelling..<br></div><br></div>Ack.<br><br><br><div><div>> G - PERSISTENT_DHCLIENT="1" (BZ 1011013)<br>
<br>Ack.<br><br><br>> H - Bundle all the paravirt drivers in the ramdisk<br>> (virtio/xen/vmware/hyperv) so the same image can boot everywhere?<br><br></div><div>Seems reasonable. What's the impact on the initrd size?<br>
<br></div><div><br>> I - Per "stack" requirements (e.g. cloudstack relies a lot on root user<br>> and password logins, openstack tends not to, SSH key only logins etc<br>> etc)<br><br></div><div>Can we have a single image that fits all the different requirements?<br>
</div><div><br><br>> That's about all that crosses my mind for now.<br><br></div><div>K - No firwall. Handled by the service provider.<br><br></div><div>L - Timezone is set to UTC, Hostname is set to 'centos', lang is en_US.UTF-8, keyboard is us (or whatever you guys think makes sense).<br>
<br></div><div>M - NOZEROCONF=yes<br><br></div><div>N - Along with the image, we'll also provide md5/sha1/sha256 checksums, gpg signed files and a manifest (list of installed packages and their versions).<br></div><div>
<br></div><div><br></div><div>...Juerg<br><br></div><div><br>> Thoughts?<br>><br>> Lucian<br>><br>> --<br>> Sent from the Delta quadrant using Borg technology!<br>><br>> Nux!<br>> <a href="http://www.nux.ro">www.nux.ro</a><br>
> _______________________________________________<br>> CentOS-devel mailing list<br>> <a href="mailto:CentOS-devel@centos.org">CentOS-devel@centos.org</a><br>> <a href="http://lists.centos.org/mailman/listinfo/centos-devel">http://lists.centos.org/mailman/listinfo/centos-devel</a><br>
<br></div></div></div>