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

Re: Python buildd (was Re: let me help you with progressing bikesheds)

On 2018-03-27 14:29, Wookey wrote:
On 2018-03-22 22:31 +0100, Aurelien Jarno wrote:
On 2018-03-07 12:08, Hector Oron wrote:
> 2018-03-07 12:01 GMT+01:00 Philipp Kern <pkern@debian.org>:

To do more tests I agree that we should deploy it on more buildds. For
*this phase*, I believe enabling lingering and deploying it by hand is
the best. Is it something acceptable?

Anything is OK for _testing_, but I think it's always been a problem
that we don't use packaged code to do our build infrastrucutre,
because this makes it very hard to reproduce. And thre are lots of
reasons why people do want to have their own build infra of various

So if we are having a re-arrange, I think we should try very hard to
use our own mechanisms and package this just like we package
everything else, not because it's easier for us, but because it's
easier for everyone else.

I relate with that. However this particular setup is not really intended to be reproducible by others at this point. I needed to cut the knot somewhere first, but wanna-build really is a pain to keep running. Once we are rewriting that, it might make more sense. As it stands it's pretty specific to our needs, unfortunately.

But as it turns out it shows rather nicely how the reality of providing a service and using raw packages from Debian don't really work. It works for the most basic case (e.g. "I just need a DNS/DHCP server"). But as soon as you scale that out or add some kind of high availability, you run into the need to orchestrate using Puppet or so, or even need to run your own custom-built solution on top of everything else Debian provides.

If you have a setup where DSA provides the VMs and does not want to give out root access and you have no access to the orchestration tools either, it's hard to keep a service running unless you run to DSA for each and every request. It's not surprising that they don't want that either if it can be avoided. Plus making changes hard by requiring that every change goes to testing and then backports isn't really feasible either.

Kind regards
Philipp Kern

Reply to: