Re: Proposed automatic update of packages in default GCE image; was "Re: Updating images on GCE to address CVE-2014-0160"
Dnia 2014-04-12, sob o godzinie 15:12 +0900, Charles Plessy pisze:
> Le Fri, Apr 11, 2014 at 10:30:13AM -0700, Tyler Riddle a écrit :
> >
> > 2) Debian is the universal operating system. Debian Stable doesn't change.
> > The Debian cloud images have been anything but stable. What is being released
> > as Debian/Wheezy cloud images is forming into a Debian derivative with a far
> > faster release cycle than anyone who is familiar with Debian Stable would be
> > expecting yet the labeling is still Debian.
>
> Hi Tyler,
>
> I think that there is at least a “broad consensus” that Debian cloud images
> should not behave differently than standard Debian installations. However, I
> think that most if not all cloud images developed here are still in testing
> phase, even if they can be quite usable and even if they are based on Debian
> stable. Thus, the fast release cycle is not a design goal, it only reflects
> the state of our cloud projects in general.
You are right that we are experimenting, trying to come with the best
solution for the cloud images.
I'm speaking here from the perspective of someone new to the cloud,
although I'm active in this group and involved in development of
bootstrap-vz. I even added ability to create testing and unstable
images, with or without contrin and non-free sections; it was
intended to help with testing CUDA-related code on the cloud.
But that's my only contact with the cloud; I'm not using it in my
day job, so take my words with the grain of salt.
I also do not think that rejecting proposals just because
they suit needs of Google, or Amazon, or Azure clouds
would be wise. Please do not consider this an attack,
but whether we want it or not cloud is gaining popularity,
and we (as Debian, and as individual developers) need to
live with it. Just as we need to live with UEFI and problems
it brings to booting. I would not want for Debian as a whole
to start ignoring cloud just because it is (currently) governed
by large commercial entities. I felt sadness when OpenMoko died
and we were left without fully free phone. I want for Debian
to have its role in the cloud.
At the same time I do not want for this discussion
to become flame war, so I move to other aspects.
Deploying to the cloud is different from deploying for physical
hardware. We can make one image and use it on as many machines
as you want to. But at the same time this is just an image;
when you run it on the machine, apt-get upgrade to have
security updates, and create image, you get different image.
That's why having testing (or even unstable) images is hard.
When combined with load balancing (fully automatic, like with
Amazon, or something different) cloud could allow for migration
of systems to newer images. I do not know whether this is possible
with Amazon Load Balancer and other solutions. But this also requires
having different images, one with and one without updates.
Updating systems while they are running is hard, and it is not
unique to Debian. PostgreSQL also has such a problem, and they
try to solve it by using some connection poolers or replication.
That's why it is important to have discussion how such problems
are solved in different software stacks, and what can we
use in Debian.
I like proposal of two images; this acknowledges that people
have different needs when it comes to the operating systems
on the cloud. There is question of naming them and configuring,
but I would like such images to require as little of configuration
from the end user as possible - at least in the beginning.
After user is more proficient with Debian and cloud, he/she
can start experimenting.
Oh, this sounds like echo of recent discussion from debian-devel
about default Desktop Environments; I also remember voices about
providing easy defaults, sane defaults, popular defaults,
or even no defaults at all, forcing users to choose
(and assume that they know what they are doing) from the very
beginning.
In summary - I do not believe there will be one solution;
I'm for having at least two images, properly described
so users know what they are using.
Best regards.
--
Tomasz Rybak <tomasz.rybak@post.pl> GPG/PGP key ID: 2AD5 9860
Fingerprint A481 824E 7DD3 9C0E C40A 488E C654 FB33 2AD5 9860
http://member.acm.org/~tomaszrybak
Reply to: