On 2017-01-14 10:55:14 +0100 (+0100), Bálint Réczey wrote:
[...]
> Providing a puppet module could be a criterion for accepting new
> services
[...]
This is how we do it for the OpenStack community infrastructure. If
you're proposing a new service, automate its deployment with a
Puppet module or c
Hi,
2016-12-08 23:24 GMT+01:00 Paul Wise :
> On Mon, Nov 28, 2016 at 8:04 PM, Ian Jackson wrote:
>
>> Should we not have public test instances of all these things ?
>
> If this will increase the bus factor of Debian services, that would be great.
> If this will just be a time sink for the people i
On Thu, Dec 8, 2016 at 10:24 PM, Javier Fernandez-Sanguino wrote:
> ... and there are no real requirements to
> test the current setup with new Debian releases.
You may want to subscribe to debian-services-admin, where DSA have
requested testing of services against Debian stretch:
https://lists.
On Mon, Nov 28, 2016 at 8:04 PM, Ian Jackson wrote:
> Should we not have public test instances of all these things ?
If this will increase the bus factor of Debian services, that would be great.
If this will just be a time sink for the people involved, that would
be less great.
On balance, it sou
Dear Ian,
I just thought I could give my 2c to this idea (which I like and share).
On 28 November 2016 at 13:04, Ian Jackson
wrote:
> Should we not have public test instances of all these things ?
Yes.
> I suggest we should declare (perhaps as a DEP?) a systematic scheme
> which recommends to
On Thu, 08 Dec 2016 at 07:55:33 +0100, Lucas Nussbaum wrote:
> [0] for services that currently run via cron, it would be interesting to
> transition to running them using systemd service + timer, so that it's
> easy to run the service manually in the same environment when run
> manually (systemctl
On 07/12/16 at 20:27 +, Niels Thykier wrote:
> Lucas Nussbaum:
> > Hi,
> >
> > On 28/11/16 at 12:04 +, Ian Jackson wrote:
> >> [...]
> >
> > No.
> >
> > I think that we should rather push for using tools such as Vagrant or
> > Docker to provide a way to easily create development environm
Lucas Nussbaum writes:
> On 28/11/16 at 12:04 +, Ian Jackson wrote:
>> We are running a multitude of services.
>> Our usual approach to these services is that we fix things when they
>> break, test our client code against the live instance (with perhaps a
>> special area of the database - eg
Lucas Nussbaum:
> Hi,
>
> On 28/11/16 at 12:04 +, Ian Jackson wrote:
>> [...]
>
> No.
>
> I think that we should rather push for using tools such as Vagrant or
> Docker to provide a way to easily create development environments for
> services.
>
> [...]
>
> Lucas
>
So I happily agree tha
Hi,
On 28/11/16 at 12:04 +, Ian Jackson wrote:
> We are running a multitude of services.
>
> Our usual approach to these services is that we fix things when they
> break, test our client code against the live instance (with perhaps a
> special area of the database - eg the `experimental' suit
Holger Levsen writes ("Re: Test instance of our infrastructure"):
> On Mon, Nov 28, 2016 at 12:04:17PM +, Ian Jackson wrote:
> > I suggest we should declare (perhaps as a DEP?)
>
> or a wiki page, at least at first…?
Sure, whatever.
> > * Most of our services
Ian Jackson:
> We are running a multitude of services.
>
> [...]
>
> Should we not have public test instances of all these things ?
>
> [...]
>
> My starting points for answers to these questions are something like
> this:
>
> [...]
>
> If we wrote some of this down then infrastructure opera
Hi Ian,
On Mon, Nov 28, 2016 at 12:04:17PM +, Ian Jackson wrote:
> Should we not have public test instances of all these things ?
seems like a great idea, thanks for bringing this up! a few minor comments:
> I suggest we should declare (perhaps as a DEP?)
or a wiki page, at least at first…?
We are running a multitude of services.
Our usual approach to these services is that we fix things when they
break, test our client code against the live instance (with perhaps a
special area of the database - eg the `experimental' suite). I have
found writing server-side software in this environ
14 matches
Mail list logo
