Fedora.NEXT Products and the fate of Spins

Stephen John Smoogen smooge at gmail.com
Thu Jan 30 01:17:04 UTC 2014


On 29 January 2014 16:48, inode0 <inode0 at gmail.com> wrote:

> On Wed, Jan 29, 2014 at 5:19 PM, Stephen John Smoogen <smooge at gmail.com>
> wrote:
> > On 29 January 2014 15:49, inode0 <inode0 at gmail.com> wrote:
> >> On Wed, Jan 29, 2014 at 4:39 PM, Jon <jdisnard at gmail.com> wrote:
> >> > Putting on my rel-eng hat I can say that any spin that fails to
> >> > compose will be dropped.
> >> >
> >> > I believe we also encourage or even require the spin maintainers to
> >> > test their spin as functional.
> >> > (To work out if the spin succeeds to compose but fails to actually
> work)
> >> >
> >> > The idea is to encourage active spin process, inactive spins will auto
> >> > retire by policy if they fail.
> >> >
> >> > Another aspect I worry about is the mirroring stuff.
> >> > With the coming WGs I fear the rsync mirroring will grow very large,
> >> > and spins are an attractive piece of fat to cut.
> >>
> >> You probably didn't mean for that to sound so negative but a piece of
> >> fat to cut is how rel-eng thinks of spins?
> >>
> >> I recall being assured at the beginning that some interested company
> >> was willing to provide the necessary support for us to give this a
> >> fair try.
> >>
> >
> > How long is a fair try? It would help to define that before people go on
> a
> > rant about doing it for a couple of years now.
>
> I meant giving our new adventure a fair try, not giving spins a fair
> try. I also really did not mean to go on a rant.
>
>
My apologies, we were talking about spins so I figured that was what you
were asking. In any case, it will be an important point for us to pin down
for the .Next.. how long are we committed to doing it and figuring out it
is working? I figure a minimum of 18-24 months would be needed but if it
needs to be longer then it needs to be guessed at so that expectations up
and down the tree are the same.



> I think we have a group that sees little benefit to spins and another
> that sees a lot of benefit to spins. The former wants to get rid of
> them, the latter wants to keep them. We won't ever quantify the amount
> of benefit they bring so we are probably at a stalemate on the benefit
> question.
>
>
Well to quantify it, we need to measure it. First off that probably means
tieing in some sort of 'check-in' counter to know what ones are run, how
much they are run, how many are installed, and how long are they installed.
That gets pretty intrusive to a lot of people. Then we make it opt in and
we get a count so low and manipulative that it becomes worthless otherwise.



> On the resources question we can either ask for them in order to allow
> us to do both or we can look for new ways to reduce the cost of spins
> to those complaining about the burden they impose. I'm open to either
> of those approaches. Getting rid of them to me would be an admission
> that are unwilling or unable to continue supporting something that is
> valuable to our users and our community (just my subjective opinion
> and I know not everyone shares it).
>
>
>From a pure infrastructure point of view, the spins have the following
major costs:

1) Disk space. Disks are not cheap in the world of data-access ready disks.
The 4 TB SATAs sound nice but when you try serving FTP off them you find
that you have to raid more than you did of the expensive SAS disks and your
effective amount of disk space you can use is in the range of 1-10% of the
disk space before you end up losing to speed of access, time to send, and
general disk drive latency. After that you have to replace the disks quite
often as they fail much sooner than any manufacturer says they will.

2) Our disk space goal for mirrors is 1 TB of disk space for the main
releases. That means N-1, N, and N+1 (alpha/beta/release).  We skim that
and every iso, architecture, and extra makes it harder to keep.

3) Net access. Large file sharing (500+ MB iso)  costs more than small file
sharing (rpms). It takes up  'streams' for longer in modern
routers/firewalls and thus you can fill up your pipe without saturating
your pipe. This used to be gotten around via various file sharing
mechanisms but these are increasingly getting shut down at the ISP and
Universities for any content.

4) Many mirrors skip the spins. That means the cost gets eaten up by those
that do and then they run into the top issues above which makes it more
likely they don't want to mirror them.

These are costs that all the mirrors have to pay on this and those are
things that are 'hidden' when people think 'oh we can make another spin, it
only takes me an hour to spin it up and test it.'

By the way, I am not anti-spin and consider the above costs to be things
that can't be paid now or in the future.. I am just wanting people to
realize that even beyond releng/qa resources this is not a 'freebie'.

-- 
Stephen J Smoogen.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20140129/30f5d6b8/attachment.html>


More information about the devel mailing list