[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Proposal to replace/extend current armhf builders



On Fri, 15 Nov 2013 00:23:55 +0000
Wookey <wookey@wookware.org> wrote:
> Arm64 kit will be even more expensive/unobtanium for a while.
> Although I expect the situation to be very different laster next year.

We can schedule a reevaluation of getting server class hardware next
year then. Until then however, we still have to fix the current
situation.

> It's expensive, but not that bad. Or are you talking about 64-bit
> hardware? Has anyoneannounced prices for that yet?

No that was the price estimate I heard from Hector a while back for the
Calxeda boards (is that the highbank ones that Arnaud mentioned?
probably but not sure). I'm pretty sure that was the price, but I might
be wrong as to what that price involved (ie chassis with boards or
single board). Anyway it's expensive, and it's still the matter of
redundancy, you can't just buy one.

> I think that's nonsense. If we had a box we could find somewhere to
> house it.

Fine then, I still think the situation would be more complicated, but
I'll take your word for it that it's a non-issue.

> There was very strong resistance in the room to the use of buildds
> without debian kernel support, because it's a major hassle and
> security risk. That rules out odroid for the time being.

That's fine, I'm not the one to do the security upgrades so I can't
possibly insist on putting more burden on other people's shoulders. I'd
fancy the idea of super fast builders, but not at the cost of other
people doing the grunt work for one port's convenience.

> Or Wanda or the Nitrogen6x we've just kindly been offered.

Or those, yes. One of the issues is getting boards with more RAM than
the current 1GB that the MX53 Locos have, so only the wandboard quad
and the utilite fall in that criteria, I see that the Nitrogen6X has
only 1GB RAM, so even if it's a nice and tempting offer, I'd still
think we need to evaluate this better. It would definitely improve the
situation immensely, but builds might still break due to OutOfMemory
errors (like iceweasel), but we would definitely get rid of tons of
timeout errors that currently need special casing.

> What's the mainline status of those?

I was going to answer I don't really know, but I just saw that Arnaud
just answered that, thanks :)

> I think we need to bash out some criteria for deciding  during the
> mini-debconf. i.e deciding how we decide (or just make a decision if
> possible).

Better to decide now rather than wait for the perfect solution next
year (which might have other problems other than price). Better is
Good's worst enemy.

> e.g hold out for server-grade kit for a while - if so how long? (0
> months, 3 months, 6months, longer?)

If it was a vote, I'd say get some cheap hardware now to replace the
current builders, say costing under an absolute limit of 1000GBP
(total: disks, boards, cases, PSU, multiserial terminals, etc). That
might even get lower if we accept the Nitrogen6X offer. And reevaluate
the situation in 12 months when arm server class becomes available
(arm64 or arm32).

> Is debian kernel an absolute requirement, or are we prepared to risk a
> custom kernel if we think it'll only be for 6 months? 

If DSA absolutely requires kernel support then I don't think there is
much we can do. And I don't think that's a promise anyone could actually
make, that we expect mainline support to be fixed in the next 6 months.
It might take a year or more for that matter and I wouldn't want to be
the one to tell DSA "just a couple of weeks more!" :)

Though to be honest, I think the main issues, disk, network and SATA
should already be working, iMX6 is pretty well supported currently,
afaik.

> Rate the other options. (Sponsored kit immediately has a significant
> advantage :-)
> 
> Markos- as driver on this, could you summarise the relevant features
> of odroid, N6x, wanda, utilite?)
>
> Speed, specs, cost, remote serial, remote power cycle, mounting,
> kernel status, availability, power consumption. Anything else
> important.

I'll prepare a wiki page and post here soon.

Regards

Konstantinos




Attachment: pgp3YWymLh4d4.pgp
Description: PGP signature


Reply to: