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:
1) 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
 
2) 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.
 
3) 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.

 
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.

+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)
 
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.


+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.