Re: UDD access from Alioth(s children) (Was: Alioth status update, take 3)
On 14/06/11 at 21:03 +0100, Stephen Gran wrote:
> This one time, at band camp, Gerfried Fuchs said:
> > Hi!
> >
> > * Stephen Gran <sgran@debian.org> [2011-06-11 16:06:58 CEST]:
> > > This one time, at band camp, Andreas Tille said:
> > > > I would like to repeat my question about UDD access from alioth (or one
> > > > / both of its successors): Is there anybody working to reenable the UDD
> > > > access?
> > >
> > > This is now reenabled. I had hoped to get postgres streaming
> > > replication working, but unfortunately udd is running on a 32bit system,
> > > while wagner and vasks are 64bit, so it didn't work out. localhost/5441
> > > will get you access to udd over a tunnel for now until we can think of
> > > something better/different.
> >
> > Thanks. Some findings about this: Formerly a plain "service=udd" was
> > working as convenience. Is it planned to put the pg_service.conf into
> > place again? That way the backend connection could be transparently
> > switched (though, my guess would be that the tunnel is there for the
> > same purpose)
>
> I've restored the pg_service config now. Sorry, I forgot that that had
> been set up in the first place, so it dropped off my todo list.
>
> > Also, it is working on wagner, but not on vasks. As I understood it
> > this is intentional. On the other hand, the public_html sites are hosted
> > on vasks, not on wagner, so services that would want to query UDD and
> > offer results are out of scope in the new alioth setup.
>
> [ lot more good reasons snipped ]
>
> <alioth admin hat>
> I have to say that I'm not very happy about general purpose hosting on
> the 'alioth' servers. While I agree QA work is useful and should be
> encouraged rather than discouraged, I don't know if alioth is the place
> for development work of this sort.
> </alioth admin hat>
>
> <dsa hat>
> qa.d.o has a dedicated machine, udd has a dedicated machine, and I'm
> sure it would be straight forward enough to set up a playpen on one
> or the other of those machines for DDs who want to do QA tasks without
> formally joining the QA team (just a gid debian writable subdirectory
> of the web root where users could create their own spaces would probably
> be sufficient?). This is just musing off the top of my head - I don't
> speak for the QA team or lucas about access to these services - the
> machines are open to all DDs, however, so I don't see any compelling
> issues to be resolved off hand.
> </dsa hat>
Well, there are a few reasons why this would be suboptimal:
- both qa.debian.org and udd.debian.org websites are managed using SVN,
so it's a bit inconvenient to create a playpen as a subdirectory.
- I have the impression that most of the work that people were doing on
alioth cannot be labelled as QA. For example, in the ruby team, we
are running a daily cronjob that creates a web page about a
transition.
- qa and udd are not accessible to non-DDs. There are some teams that
rely on a large number of non-DDs, and I don't like the idea of
limiting the ability to update some script to DDs. (re-using the
example of the ruby cronjob above, it was developed by Antonio
Terceiro, who is still in NM).
- qa and udd don't know about alioth teams.
While I understand that it's not desirable to have the load induced by
those third-party scripts affect the performance of alioth like it used
to be the case, I think that it's very important for Debian to have a
machine accessible to packaging team members (including non-DDs) where
they can easily develop and run team-specific infrastructure. It would
be a big regression if such infrastructure would have to be hosted
outside Debian.
- Lucas
Reply to: