FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor


 
 
LinkBack Thread Tools
 
Old 08-18-2011, 11:15 AM
Pierre-Yves Chibon
 
Default Hosted plans

On Mon, 2011-08-08 at 10:54 -0600, Kevin Fenzi wrote:
> * Adding more/different services.
> IRC commit bot
> redmine (still not in fedora, but people are working on it)
If we move from python/trac I'd suggest that we have a look at indefero
as well, being php it might be easier to deploy/integrate in our current
infrastructure.

Pierre
_______________________________________________
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure
 
Old 08-18-2011, 03:29 PM
Kevin Fenzi
 
Default Hosted plans

On Wed, 17 Aug 2011 13:01:42 -0600
Stephen John Smoogen <smooge@gmail.com> wrote:

> On Wed, Aug 17, 2011 at 12:24, seth vidal <skvidal@fedoraproject.org>
> wrote:
> > On Mon, 2011-08-08 at 10:54 -0600, Kevin Fenzi wrote:
> >> Greetings.
> >>
> >> I thought I would throw out some plans for hosted moving forward
> >> and see if we could hash out a plan and some timetable for
> >> implementing things.
> >>
> >
> >> Some things we talked about:
> >>
> >> * A caching frontend of some kind. Could cache web requests and
> >> take load off the main machines.
> >> * Some way to distribute the data, so if serverbeach were off line
> >> we could still switch to and use another machine.
> >> * Adding more/different services.
> >> * * * IRC commit bot
> >> * * * redmine (still not in fedora, but people are working on it)
> >> * * * your idea here.
> >
> >
> > We talked a bit about this yesterday and I wanted to write it up
> > here:
> >
> > 1. move the mailman instance over to collab1 and have them share an
> > infrastructure - mailman is not (usually) easy to spread to lots of
> > servers in a very clean way and it is not (usually) the source of a
> > massive load (the archiver not withstanding)
> >
> > 2. I think we should seriously consider building things for hosted
> > 2.0 such that slices are possible:
> >
> > *you still go to fedorahosted.org/projectname
> >
> > *but it redirects you to project-##.fedorahosted.org - based on the
> > *first 2 letters of the name of your project or what not.
>
> Just an idea to bring up when we implement:
>
> Due to the fact that we would have huge groupings on certain letters (
> re, fe, li py, sy) use the first 2 letters of the md5sum of the name.
> Hopefully that would spread out the load across enough. The project
> build script would automate this so people don't have to figure it
> out.

How about just even more simple:

01
02
03

when 01 fills up/gets loaded, move to 02, or add start just cycling
thru them...

kevin
_______________________________________________
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure
 
Old 08-18-2011, 03:30 PM
Kevin Fenzi
 
Default Hosted plans

On Thu, 18 Aug 2011 13:15:22 +0200
Pierre-Yves Chibon <pingou@pingoured.fr> wrote:

> On Mon, 2011-08-08 at 10:54 -0600, Kevin Fenzi wrote:
> > * Adding more/different services.
> > IRC commit bot
> > redmine (still not in fedora, but people are working on it)
> If we move from python/trac I'd suggest that we have a look at
> indefero as well, being php it might be easier to deploy/integrate in
> our current infrastructure.

Yeah, currently redmine in a nonstarter due to not being in fedora, but
I think some folks are working on that.

I'd think we would want to look over any replacement with the same eye
we do to any new resources we need to support...

kevin
_______________________________________________
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure
 
Old 08-18-2011, 03:39 PM
seth vidal
 
Default Hosted plans

On Thu, 2011-08-18 at 09:29 -0600, Kevin Fenzi wrote:

> How about just even more simple:
>
> 01
> 02
> 03
>
> when 01 fills up/gets loaded, move to 02, or add start just cycling
> thru them...

works for me - the only reason I suggested:

git-$projectname.fedorahosted.org

is so I don't have to constantly go lookup which numbered machine a
project is on before I can go check something out.

-sv


_______________________________________________
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure
 
Old 08-18-2011, 03:41 PM
Kevin Fenzi
 
Default Hosted plans

On Wed, 17 Aug 2011 14:24:12 -0400
seth vidal <skvidal@fedoraproject.org> wrote:

> We talked a bit about this yesterday and I wanted to write it up here:
>
> 1. move the mailman instance over to collab1 and have them share an
> infrastructure - mailman is not (usually) easy to spread to lots of
> servers in a very clean way and it is not (usually) the source of a
> massive load (the archiver not withstanding)

Yeah, I think this will be a win... althought it means more eggs in one
basket.

> 2. I think we should seriously consider building things for hosted 2.0
> such that slices are possible:
>
> you still go to fedorahosted.org/projectname
>
> but it redirects you to project-##.fedorahosted.org - based on the
> first 2 letters of the name of your project or what not.
>
> for commits you have to commit to:
> git-##.fedorahosted.org (for example)
> or svn-##.fedorahosted.org
>
> it would allow us to expand out horizontally as things get busier.
>
> It would require a config change and/or a flag day for our users
> but it's not the end of the world now.
> Advantages:
> a. this keeps all of our eggs out of one basket
> b. it means replicating the infrastructure is important,
> repeatedly
>
> it seems like an obvious course of action that scales well for what
> we need.

> Actually - on further thought just making it work for:
>
> git-$projectname.fedorahosted.org (for example)
>
> should work just fine and be no more effort - just an CNAME on the
> backend
>
> Easier to document, too

Sounds reasonable. We can setup the new hosted machines to use this,
and when we move over everything we convert them?

> 3. Think HARD about limiting support for additional services on
> hosted.

Sure, I think we should use the same methods for any request for
resource. Ie, we need someone able to support it, it's got an upstream,
it's in epel, we have sop's for it, etc.

> thoughts?
>
> -sv

kevin
_______________________________________________
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure
 
Old 08-18-2011, 04:18 PM
Toshio Kuratomi
 
Default Hosted plans

On Thu, Aug 18, 2011 at 11:39:08AM -0400, seth vidal wrote:
> On Thu, 2011-08-18 at 09:29 -0600, Kevin Fenzi wrote:
>
> > How about just even more simple:
> >
> > 01
> > 02
> > 03
> >
> > when 01 fills up/gets loaded, move to 02, or add start just cycling
> > thru them...
>
> works for me - the only reason I suggested:
>
> git-$projectname.fedorahosted.org
>
> is so I don't have to constantly go lookup which numbered machine a
> project is on before I can go check something out.
>
+1 for cnames.

We get a lot of "Why can't I git pull foobar today? I was able to
do that yesterday." If we can avoid having to lookup which machine is
serving that it'll make things easier.

-Toshio
_______________________________________________
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure
 
Old 08-18-2011, 04:36 PM
Kevin Fenzi
 
Default Hosted plans

On Thu, 18 Aug 2011 09:18:06 -0700
Toshio Kuratomi <a.badger@gmail.com> wrote:

> On Thu, Aug 18, 2011 at 11:39:08AM -0400, seth vidal wrote:
> > On Thu, 2011-08-18 at 09:29 -0600, Kevin Fenzi wrote:
> >
> > > How about just even more simple:
> > >
> > > 01
> > > 02
> > > 03
> > >
> > > when 01 fills up/gets loaded, move to 02, or add start just
> > > cycling thru them...
> >
> > works for me - the only reason I suggested:
> >
> > git-$projectname.fedorahosted.org
> >
> > is so I don't have to constantly go lookup which numbered machine a
> > project is on before I can go check something out.
> >
> +1 for cnames.
>
> We get a lot of "Why can't I git pull foobar today? I was able to
> do that yesterday." If we can avoid having to lookup which machine is
> serving that it'll make things easier.

Yeah, I am fine with that too. I made my 01/02/03 suggestion before I
read down to the $scm-$projectname idea. Makes sense to me.

kevin
_______________________________________________
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure
 
Old 08-18-2011, 05:11 PM
Stephen John Smoogen
 
Default Hosted plans

On Wed, Aug 17, 2011 at 15:49, Luke Macken <lmacken@redhat.com> wrote:
> Excerpts from seth vidal's message of Wed Aug 17 15:53:42 -0400 2011:
>> On Wed, 2011-08-17 at 13:01 -0600, Stephen John Smoogen wrote:
>> > 4. Talk to something like github if we can meet up and grow something togehter?
>>
>> I agree with jesse that github, being closed source, is a complete
>> non-starter.
>
> Allura, the code behind the shiny new SourceForge, is open source.
>
> * *http://sourceforge.net/p/allura
>
> Based on the many conversations I've had with them at PyCons, they would
> definitely be interested in working together with us on hosting.

This does look interesting. I am going to see what it would take to get going.

> luke
> _______________________________________________
> infrastructure mailing list
> infrastructure@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/infrastructure
>



--
Stephen J Smoogen.
"The core skill of innovators is error recovery, not failure avoidance."
Randy Nelson, President of Pixar University.
"Let us be kind, one to another, for most of us are fighting a hard
battle." -- Ian MacLaren
_______________________________________________
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure
 
Old 08-24-2011, 06:16 PM
Mike McGrath
 
Default Hosted plans

On Wed, 10 Aug 2011, Stephen Gallagher wrote:

> On Wed, 2011-08-10 at 09:15 -0600, Kevin Fenzi wrote:
> > > 3) Turn ReviewBoard into a turnkey OpenShift virtual instance and
> > > allow any Fedora Hosted project to spin one up. This instance would
> > > use standard enrollment (rather than FAS integration, which is
> > > impossible outside the Infra firewall). Each project could have its
> > > own complete instance to maintain on its own. Upsides: less work for
> > > Fedora Admins, support for email and better performance. Downsides: no
> > > centrally-managed user accounts and projects need to do more of the
> > > maintaining of the system themselves.
> >
> > This is pretty interesting... I assume after following the steps they
> > would have a persistent instance they could use moving forward. It
> > doesn't need anything special to talk to their project on hosted?
> > Does it end up costing the end project anything?
>
> I've submitted a patch upstream to ReviewBoard to add easy configuration
> of Fedora Hosted source repositories:
> http://reviews.reviewboard.org/r/2505/
>
> I have confirmation from Christian Hammond (the upstream project lead)
> that it will be included in the 1.5.6 and 1.6.0 releases (aka
> imminently).
>
> So there's very little that the projects need to do in order to connect
> to the hosted repo. As I said above, they lose the centrally-managed
> users available to FAS, so they'd need to manage their own groups
> themselves. On the other side, this does mean that they gain much finer
> control over permissions (since they can define their own
> project-specific groups rather than relying on FAS groups).
>
> >
> > What happens if someone sets up an instance and then disappears?
> > Does the project have any way to deal with that? Or just make a new one?
> >
>
> That's a good question for Mike McGrath. I suspect that it would be
> prudent to recommend that projects set up several administrators so that
> a disappearance of one doesn't result in the loss of all administrators.
>
> Also, it's possible to promote a user to admin status if you have
> database privileges as well by setting the admin flag on their user
> account, but of course that assumes you have access to a DB admin.
>
> A final option would be to modify the openshift instance to always
> install a recovery admin with a random password that was escrowed by the
> Fedora project, but I'm not sure whether that's realistic. Mike, can you
> speak to that?
>

We should have multiple ssh key support soon to allow multiple admins of a
single project. Having said that the apps are tied to an individual user
account. At the moment if someone wanted to move it they'd have to make a
snapshot and restore it elsewhere (if for some reason the app needed to
change owners or something)

To do the "fedora project recovery" bits, we'd have to setup the fedora
project as an intermediary (basically running everything as a fedora
user). The rest could all be scripted fairly easily. At the moment
though there's a limit of 5 apps per account so the best bet is to have
users setup their own for the time being.

-Mike
_______________________________________________
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure
 

Thread Tools




All times are GMT. The time now is 07:12 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org