One of the general questions that's coming up across the working groups is product lifecycle. We should talk about what we would like to see for the Fedora cloud.
I often hear that a longer lifecycle would be beneficial, and if Fedora as a whole goes for that I think we would take advantage, but more important, I think, is the ability to move to a newer version without hassle -- application stack works on one version and also on the next, or at least only requires minor changes.
I also _really_ think we need to do periodic respins including updates, and we could possibly call these point releases. I think monthly would be ideal but every 3 months might be a more managable bite.
Matthew Miller mattdm@fedoraproject.org writes:
One of the general questions that's coming up across the working groups is product lifecycle. We should talk about what we would like to see for the Fedora cloud.
I often hear that a longer lifecycle would be beneficial, and if Fedora as a whole goes for that I think we would take advantage, but more important, I think, is the ability to move to a newer version without hassle -- application stack works on one version and also on the next, or at least only requires minor changes.
I think we're kinda unique here in Fedora cloud: our 'lifecycle' understanding is slightly different from "How long can I keep installed system without scary upgrade procedure". Cloud instances tend to live short but exciting life. What we need to do is to simplify 'switch' procedure for our users, e.g. yesterday user was using F19 image for his tasks and today he switched to F20. How can we lower the pain? I would suggest the following: 1) We stick to Fedora's basic lifecycle, no bold moves required. 2) We provide 'support' for all supported Fedora releases (not only the latest one) by doing regular image builds including all current updates. 3) We try to identify and fix 'cloud image API' (package set, basic behavour, ...) across all Fedora releases and try to make changes 'conservative'. 4) We try to identify reasons why users tend to stick to particular Fedora version instead of using the current one. Let's treat any report like 'my workflow is broken with new version' as a bug. 5) (I've already suggested that once) Let's work on providing our users with infrastructure for building their own images. Infrastructure is better than tools.
I also _really_ think we need to do periodic respins including updates, and we could possibly call these point releases. I think monthly would be ideal but every 3 months might be a more managable bite.
Why can't this process be fully automated? Let's think about it as 'yum update is forbidden for cloud images, running fresh image is the only way of doing updates'. Are we ok with updates once in 3 month? I don't think so.
Just my $0.02. But I'm ready to participate in any 'automation' activities.
2013/11/28 Vitaly Kuznetsov vitty@redhat.com
Matthew Miller mattdm@fedoraproject.org writes:
One of the general questions that's coming up across the working groups
is
product lifecycle. We should talk about what we would like to see for the Fedora cloud.
I often hear that a longer lifecycle would be beneficial, and if Fedora
as a
whole goes for that I think we would take advantage, but more important,
I
think, is the ability to move to a newer version without hassle -- application stack works on one version and also on the next, or at least only requires minor changes.
I think we're kinda unique here in Fedora cloud: our 'lifecycle' understanding is slightly different from "How long can I keep installed system without scary upgrade procedure". Cloud instances tend to live short but exciting life. What we need to do is to simplify 'switch' procedure for our users, e.g. yesterday user was using F19 image for his tasks and today he switched to F20. How can we lower the pain? I would suggest the following:
- We stick to Fedora's basic lifecycle, no bold moves required.
Fedora lifecycle is currently *changing*, fedora.next is about rethinking the whole process. We should focus on the product and the needs of our users, if a shorter or longer lifecycle make sense, we should explore that way. Off course, we should collaborate with the whole Fedora community, but we should allow ourselves some room to our specific needs.
Since we have close ties with the server WG, i suggest that we take a peek at their ongoing proposal and try to coordinate with them. https://fedoraproject.org/wiki/Server/Proposals/Server_Lifecycle
- We provide 'support' for all supported Fedora releases (not only the
latest one) by doing regular image builds including all current updates.
Yes, i agree that we should be able to refresh images at a regular basis. Ubuntu does it weekly and it's a good cadence.
- We try to identify and fix 'cloud image API' (package set, basic
behavour, ...) across all Fedora releases and try to make changes 'conservative'.
Another possibility is to identify images with a longer lifecycle (and a more conservative updates behavior) and test the upgrade path.
- We try to identify reasons why users tend to stick to particular
Fedora version instead of using the current one. Let's treat any report like 'my workflow is broken with new version' as a bug.
+1 We don't have enough workforce for maintaining multiple versions like RHEL, that's why i'm a proponent of relying on SCLs (or any technology that relieve our maintenance load)
- (I've already suggested that once) Let's work on providing our users
with infrastructure for building their own images. Infrastructure is better than tools.
+1 There were many trials to build a tool like Suse studio (a great tool) for fp.o but most of them didn't go well. /me wishes that someone picks up boxgrinder and get it to the next level or at least build a similar tool up to the web UI
I also _really_ think we need to do periodic respins including updates,
and
we could possibly call these point releases. I think monthly would be
ideal
but every 3 months might be a more managable bite.
With Fedora updates frequency, monthly is not even usable, we *must* automate image generation, testing and uploading. Rel-eng has limited output, so automation is here a "do or die" thing.
Why can't this process be fully automated? Let's think about it as 'yum update is forbidden for cloud images, running fresh image is the only way of doing updates'. Are we ok with updates once in 3 month? I don't think so.
Just my $0.02. But I'm ready to participate in any 'automation' activities.
-- Vitaly Kuznetsov
You're welcome :) Try to contact Frankie who has taken the lead on cooperating with rel-eng, so you could coordinate.
@+ H.
2013/11/28 H. Guémar hguemar@fedoraproject.org:
- We provide 'support' for all supported Fedora releases (not only the
latest one) by doing regular image builds including all current updates.
Yes, i agree that we should be able to refresh images at a regular basis. Ubuntu does it weekly and it's a good cadence.
+1 Please note there might be other refresh-triggers besides the "weekly timeout" such as: - new kernel - yum update would fetch more than 50MB - OpenSSL security issue
Any chance we could implement some rule-based policy rather than a plain timeout here?
On 12/02/2013 01:54 PM, milanisko k wrote:
Please note there might be other refresh-triggers besides the "weekly timeout" such as:
..
- yum update would fetch more than 50MB
.. That's an interesting thought.
The image is currently about 300 megs, compared to that, 50 megs seems to be much.
It's probably better to rebuild weekly than daily. Then someone would have a chance to test and report issues.
Matthias
-
Haïkel -
Matthew Miller -
Matthias Runge -
milanisko k -
Vitaly Kuznetsov