> Would it be acceptable to move ntpdate to the desktop-common
seed or something?
Could we just switch everything over to ntp? Is their a downside to
this I'm missing?
Thanks,
Bryan
On Wed, Oct 22, 2014 at 9:51 AM, Robie Basak <robie.basak@ubuntu.com> wrote:
> I'd like to seed ntp in both server and cloud-image in Vivid. Servers
> should maintain the correct time by default. Please make any objections
> now.
>
> Right now, ntpdate is seeded in minimal. It makes little sense to have
> both ntpdate and ntp installed.
>
> So is there some mechanism I can use to have ntpdate not appear in
> server and cloud images? I think we need to move ntpdate out of minimal
> for this. Would it be acceptable to move ntpdate to the desktop-common
> seed or something?
>
> To try and confirm that this is sensible for all use cases, here's a
> brainstromed list. It seems to me that the only downside is a little
> extra used space in the LXC case.
>
> * "Traditional" bare metal server installation from server ISO
>
> It makes sense to be running ntp here.
>
> * MAAS-deployed server using d-i
>
> It makes sense to be running ntp here. Additionally, MAAS can choose to
> configure the system to point at a MAAS-managed NTP server.
>
> * MAAS-deployed server using curtin
>
> It makes sense to be running ntp here. Additionally, MAAS can choose to
> configure the system to point at a MAAS-managed NTP server.
>
> * Hand (or other tool) -deployed VM using a cloud image
>
> It makes sense to be running ntp here[3].
>
> * Hand (or other tool) -deployed VM using d-i or a debootstrapped image
>
> It makes sense to be running ntp here[3].
>
> * Juju-deployed VM using a cloud image
>
> It makes sense to be running ntp here[3]. There may be some interference
> with existing charms. When these charms are updated to Vivid (or to X),
> then they can start assuming that ntp is already available. A
> hypothetical "ntp" subordinate charm could be used in cases where some
> other NTP server should be used and the deployer wants to manage it more
> directly via a relation; in this case, the subordinate charm could just
> rewrite /etc/ntp.conf to change the default accordingtly.
>
> * Hand (or other tool) -deployed LXC using a cloud image
>
> It probably doesn't make sense to run ntp here. We could amend the ntp
> init script to skip startup when in a container by default.
>
> * Hand (or other tool) -deployed LXC using a debootstrapped image
>
> It probably doesn't make sense to run ntp here. We could amend the ntp
> init script to skip startup when in a container by default.
>
> * Juju-deployed LXC using a cloud image
>
> It probably doesn't make sense to run ntp here. We could amend the ntp
> init script to skip startup when in a container by default.
>
> Are there any use cases I've missed here?
>
> Previous discussions:
>
> [1] https://lists.ubuntu.com/archives/ubuntu-server/2013-April/006556.html
> [2] https://lists.ubuntu.com/archives/ubuntu-devel/2013-December/037874.html
> [3] https://help.ubuntu.com/community/KVM/FAQ#Should_NTP_be_used_for_time_synchronisation.3F
>
> --
> ubuntu-devel mailing list
> ubuntu-devel@lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
>
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
