[Date Prev][Date Next] [Thread Prev][Thread Next]
Re: [fab] Secondary Arches
- From: Jeremy Katz <katzj redhat com>
- To: fedora-advisory-board redhat com
- Subject: Re: [fab] Secondary Arches
- Date: Wed, 15 Nov 2006 23:15:54 -0500
On Wed, 2006-11-15 at 20:51 -0600, Josh Boyer wrote:
> On Wed, 2006-11-15 at 17:33 -0500, Jeremy Katz wrote:
> > On Tue, 2006-11-14 at 20:11 -0600, Josh Boyer wrote:
> > > That being said, I agree with spot. There are two key issues that are
> > > essentially taking a great idea and sinking it immediately. In order
> > > for secondary arches to really work, I believe the arch teams need to be
> > > able to host repositories along side the primary arches on
> > > fedoraproject.org, and binary isos for the arches (if available) should
> > > also be hosted.
> > While in I agree that we _want_ to be able to do this, do we want to
> > hold up any progress on secondary arches on a) ensuring available
> > space and b) setting up a sane infrastructure for handling the
> > putting up of the arch trees/ISOs? I don't personally think so.
> What progress? Seriously. Take two of the proposed secondary arches.
> Sparc isn't held up because basically Aurora is doing about 90% of the
> work already anyway. It's just doesn't have the Fedora name. Making
> those builds use the Fedora buildsys (via shadow builds) and putting
> those rpms on the fedoraproject.org servers is the final step in the
> evolution of that project.
Yes, and Aurora is able to do it due to heroic efforts. It shouldn't be
as hard as it is! We want to make it easier now as well as let them use
the name (as well as pointing to them on the "Get Fedora" pages in
bright red letters :)
While hosting is important, I didn't/don't see it as the primary thing
stopping these other arch efforts from occurring. And hosting is a
pretty significant amount of effort to get going. It's definitely
something that is going to have to be tackled a little further into the
future for a number of the things we discussed.
> Then look at PPC. How can you expect me to believe that taking an arch
> that _already_ has storage and ISOs and just dropping that off of
> fedoraproject.org because the buildsys can now send out shadow builds is
I think that trying to lump PPC in here has perhaps made the issue a
little bit more muddled. So ignore PPC for a minute -- does this not
start to improve things for arches like sparc? It's not the whole
answer, but it's a start.
For PPC, things are a little bit more complicated and it's really just a
matter of how much demand the platform is seeing vs the effort required
to sustain it. So does it make things less good for ppc? Definitely.
But the impetus isn't the existence of secondary arches and shoving the
round peg in the square hole. Instead, it's the fact that the number of
ppc downloads is very small and the community of people actively testing
and fixing things is quite small.
> > [snip easily avoidable bit :-]
> You snipped something I wish you would have commented on. The wiki page
> has "we can't BUILD these packages because we don't have the hardware"
> as reason to not host the builds. Explain to me why that matters if
> those exact same builds are good enough to carry the Fedora name?
If we don't have the hardware, how does the admin team maintain the
machines? How do we deal with a build for a single arch failing?
If your question is just "why don't the bits end up on fp.org", the
reason is purely one of "we're not attacking that problem first". And
realistically, setting the expectation that we're not going to solve
that problem in the next six months is a far better thing to do IMHO.
> > > However, it hints at another
> > > issue which is the fact that people go to http://fedoraproject.org/ to
> > > download Fedora. If they now have to go to foo.bar.com to download it,
> > > you lose brand distinction.
> > Except that even now to download Fedora, you go to mirror.kernel.org (or
> > other local mirror site of your choice). We're not saying that we're
> > not going to prominently link on the "Download Fedora" page.
> For ISOs. For yum repos, we'd lose the mirroring structure already in
> place for Fedora. I find that to be quite bad.
We can still have the mirror CGI URLs work; so we don't necessarily lose
anything for yum repos either. And hopefully, we can enable an easy way
for mirrors to opt-in tied in with the rest of the mirror
infrastructure. Realistically, though, a lot of mirrors aren't going to
carry all the arches even if they _were_ hosted on fedoraproject.org.
The amount of space that is required for a full mirror continues to grow
at an astonishing rate.
> >  And sending 160GB drives doesn't help ;-) That's not the sort of
> > available and mirrorable space that's really needed to be able to work
> > within the existing infrastructure we've got for hosting content
> Then tell me what is. I want to know. What _would_ you need to keep
> the secondary arch builds on fedoraproject.org?
The backend storage of download.fedora is netapps at this point. So
that's where the expansion has to happen.
> >  I really don't want more instances along the lines of how Extras
> > packages get up now. In fact, I hope that we manage to "fix" that with
> > some of the other pieces in play.
> I don't follow what you mean here.
There's crazy shenanigans to get packages from the needsign queue on the
buildsys master to download.fedora.
> And here's another question... where do bugs for secondary arches get
> reported? Is the Fedora bugzilla still used? Or will arches be
> required create and host their own bugzilla instances?
Centralized information -- Get the bugs in our bugzilla! Get the
source in our SCM! Key off of build requests in our build
infrastructure! Use the same tools to build the release!
And yes, eventually, host the bits on our servers. But I just don't see
how we make that happen in the short (~ 6-ish months) term with all of
the other infrastructure things that are underway.
[Date Prev][Date Next] [Thread Prev][Thread Next]