Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.project > #12042 > unrolled thread

Debian.net Team

Back to article view | Back to linux.debian.project

Contents

  Debian.net Team Jonathan Carter <jcc@debian.org> - 2020-08-31 18:40 +0200
    Re: Debian.net Team Lucas Nussbaum <lucas@debian.org> - 2020-09-01 09:30 +0200
      Re: Debian.net Team Sam Hartman <hartmans@debian.org> - 2020-09-01 15:30 +0200
        Re: Debian.net Team Jonathan Carter <jcc@debian.org> - 2020-09-01 15:40 +0200
      Re: Debian.net Team Jonathan Carter <jcc@debian.org> - 2020-09-01 15:40 +0200
        Re: Debian.net Team Lucas Nussbaum <lucas@debian.org> - 2020-09-01 16:30 +0200
          Re: Debian.net Team Jonathan Carter <jcc@debian.org> - 2020-09-02 14:00 +0200
            Re: Debian.net Team Sam Hartman <hartmans@debian.org> - 2020-09-02 14:20 +0200
            Re: Debian.net Team Lucas Nussbaum <lucas@debian.org> - 2020-09-02 17:20 +0200
              Re: Debian.net Team Dominic Hargreaves <dom@earth.li> - 2020-09-04 14:00 +0200
      Re: Debian.net Team Noah Meyerhans <noahm@debian.org> - 2020-09-09 23:00 +0200
    Re: Debian.net Team Bastian Blank <waldi@debian.org> - 2020-09-01 11:00 +0200
    Re: Debian.net Team Bastian Blank <waldi@debian.org> - 2021-02-10 22:00 +0100

#12042 — Debian.net Team

Hi Debianites

I'd like to talk about an idea that needs some more thought, but that
has been floating in my head for a while and I think it could benefit
from some further discussion. Ideally we could've had a BoF about it
during DebConf, but my plate was full already.

We have a bunch of services currently hosted on the debian.net domain.
There's a list of these domains at:

    https://wiki.debian.org/DebianNetDomains

The services ran under the debian.net domain are typically run by
individual Debian Developers or small teams, and range from a toy
service to something that's short lived or even a service that's even
considered important and used daily by people in the project.

Some people have argued that some of these services should move to DSA,
but, even if we feel that a service is important, it's still not the
responsibility of DSA. DSA takes ownership of the core Debian
infrastructure, which is already a huge undertaking. For interest, you
can get a list of DSA managed machines here:

    https://db.debian.org/machines.cgi

While the current structure for debian.net services allow a lot of
flexibility and very little admin to get something set up (you basically
just send one email to set up DNS), I do think that the project can
benefit if we formalize things a bit more.

At the same time, a regular theme in my DPL work is that someone is
looking to find hosting for a project and not having much luck. Last
night I learned of a DD who's been paying more than $200 a year for
hosting on their own account. While this is a manageable amount for
Debian to pay in a year, it can be quite a lot for an individual, and
I'd rather have us have a better story for that.

We have some lists of hosting providers for projects like those listed on:


https://wiki.debian.org/ServicesHosting#Outside_the_Debian_infrastructure

But what I've found is that people find it cumbersome to figure out who
to contact, how to contact them and whether the details listed there is
even still valid (there are also services like fosshost.org that are
Debian friendly that should probably be added to that list).

So, what I'm considering is something along the lines of:

1. Let things continue to work the way they're working now for the most
part (no need for any disruptive changes in this proposal)

2. Create a new team to organise some aspects of everything under
debian.net, which would include:

  * Keeping the domain list on the above mentioned
    DebianNet page maintained on a regular basis
  * Maintain external contacts/relationships with
    people and providers who we have special arrangements
    with
  * Help maintain the list of hosting providers listed
    on the wiki page above
  * Have accounts with the major hosting providers so that
    they can also create new instances whenever there's a
    new request from a developer

There's more ideas that could follow too, but aren't essential right
now. For example, hosting some backup service for all these services (we
really have no idea if the people running them keep backups, or where
they keep them) and maybe assigning some emergency contacts who have
login credentials for at least important (debian.net) services seem like
a good idea.

That's it in a nutshell for now. Any thoughts... or volunteers?

-Jonathan

-- 
  ⢀⣴⠾⠻⢶⣦⠀  Jonathan Carter (highvoltage) <jcc>
  ⣾⠁⢠⠒⠀⣿⡁  https://wiki.debian.org/highvoltage
  ⢿⡄⠘⠷⠚⠋   https://debian.org | https://jonathancarter.org
  ⠈⠳⣄⠀⠀⠀⠀  Debian, the universal operating system.

[toc] | [next] | [standalone]

#12043

Hi,

On 31/08/20 at 18:21 +0200, Jonathan Carter wrote:
> 2. Create a new team to organise some aspects of everything under
> debian.net, which would include:
> 
>   * Keeping the domain list on the above mentioned
>     DebianNet page maintained on a regular basis
>   * Maintain external contacts/relationships with
>     people and providers who we have special arrangements
>     with
>   * Help maintain the list of hosting providers listed
>     on the wiki page above
>   * Have accounts with the major hosting providers so that
>     they can also create new instances whenever there's a
>     new request from a developer
> 
> There's more ideas that could follow too, but aren't essential right
> now. For example, hosting some backup service for all these services (we
> really have no idea if the people running them keep backups, or where
> they keep them) and maybe assigning some emergency contacts who have
> login credentials for at least important (debian.net) services seem like
> a good idea.
> 
> That's it in a nutshell for now. Any thoughts... or volunteers?

I think that this proposal combines two quite different aspects, and
that it might be better to keep them separate.

1. Maintaining contacts with infrastructure providers that are willing
to help Debian. That's of course useful, but not limited to debian.net
services. For example, some QA tasks could benefit from access to cloud
resources.

2. Keeping our important services sanely maintained. Your proposal is to
sanitize *.debian.net a bit. I wonder if instead, we should have a list
of requirements for *.debian.org that does not include "hosted on a
machine managed by DSA". People would then continue to use debian.net as
they do currently, but once the service grows to something really
useful, it gets a review to ensure that it is maintainable, and can move
to the debian.org without necessarily putting more load on DSA.

Lucas

[toc] | [prev] | [next] | [standalone]

#12045

>>>>> "Lucas" == Lucas Nussbaum <lucas@debian.org> writes:

    Lucas> I think that this proposal combines two quite different
    Lucas> aspects, and that it might be better to keep them separate.

    Lucas> 1. Maintaining contacts with infrastructure providers that
    Lucas> are willing to help Debian. That's of course useful, but not
    Lucas> limited to debian.net services. For example, some QA tasks
    Lucas> could benefit from access to cloud resources.

    Lucas> 2. Keeping our important services sanely maintained. Your
    Lucas> proposal is to sanitize *.debian.net a bit. I wonder if
    Lucas> instead, we should have a list of requirements for
    Lucas> *.debian.org that does not include "hosted on a machine
    Lucas> managed by DSA". People would then continue to use debian.net
    Lucas> as they do currently, but once the service grows to something
    Lucas> really useful, it gets a review to ensure that it is
    Lucas> maintainable, and can move to the debian.org without
    Lucas> necessarily putting more load on DSA.

I agree with the above.
In general, I like Jonathan's idea (although I also like Lucas's idea
about making it easier to get things under debian.org).
I think Jonathan's idea would be better if it did not conflate contacts
for hosting providers so much with debian.net.

I think it would be fine if the same team handled both aspects of the
proposal, although I'd prefer that the name be different than debian.net
team if that's the case.

I think the common element is assisting community members set up
services.

[toc] | [prev] | [next] | [standalone]

#12046

On 2020/09/01 15:18, Sam Hartman wrote:
> I think it would be fine if the same team handled both aspects of the
> proposal, although I'd prefer that the name be different than debian.net
> team if that's the case.

Sure, the name doesn't matter at all that much to me. Any other
suggestions for a name for a team for "Help co-ordinating hosting of
services that's not managed by DSA"?

thanks,

-Jonathan

-- 
  ⢀⣴⠾⠻⢶⣦⠀  Jonathan Carter (highvoltage) <jcc>
  ⣾⠁⢠⠒⠀⣿⡁  https://wiki.debian.org/highvoltage
  ⢿⡄⠘⠷⠚⠋   https://debian.org | https://jonathancarter.org
  ⠈⠳⣄⠀⠀⠀⠀  Debian, the universal operating system.

[toc] | [prev] | [next] | [standalone]

#12047

On 2020/09/01 09:14, Lucas Nussbaum wrote:
> 2. Keeping our important services sanely maintained. Your proposal is to
> sanitize *.debian.net a bit. I wonder if instead, we should have a list
> of requirements for *.debian.org that does not include "hosted on a
> machine managed by DSA". People would then continue to use debian.net as
> they do currently, but once the service grows to something really
> useful, it gets a review to ensure that it is maintainable, and can move
> to the debian.org without necessarily putting more load on DSA.

That's really a discussion you'll want to have with DSA, and it doesn't
seem that the project is in a position currently to add any more load to
the DSA team at this point.

-Jonathan

-- 
  ⢀⣴⠾⠻⢶⣦⠀  Jonathan Carter (highvoltage) <jcc>
  ⣾⠁⢠⠒⠀⣿⡁  https://wiki.debian.org/highvoltage
  ⢿⡄⠘⠷⠚⠋   https://debian.org | https://jonathancarter.org
  ⠈⠳⣄⠀⠀⠀⠀  Debian, the universal operating system.

[toc] | [prev] | [next] | [standalone]

#12048

Hi

On 01/09/20 at 15:29 +0200, Jonathan Carter wrote:
> On 2020/09/01 09:14, Lucas Nussbaum wrote:
> > 2. Keeping our important services sanely maintained. Your proposal is to
> > sanitize *.debian.net a bit. I wonder if instead, we should have a list
> > of requirements for *.debian.org that does not include "hosted on a
> > machine managed by DSA". People would then continue to use debian.net as
> > they do currently, but once the service grows to something really
> > useful, it gets a review to ensure that it is maintainable, and can move
> > to the debian.org without necessarily putting more load on DSA.
> 
> That's really a discussion you'll want to have with DSA, and it doesn't
> seem that the project is in a position currently to add any more load to
> the DSA team at this point.

How does it add more load on the DSA team?

Lucas

[toc] | [prev] | [next] | [standalone]

#12049

Hey Lucas

On 2020/09/01 16:05, Lucas Nussbaum wrote:
> On 01/09/20 at 15:29 +0200, Jonathan Carter wrote:
>> On 2020/09/01 09:14, Lucas Nussbaum wrote:
>>> 2. Keeping our important services sanely maintained. Your proposal is to
>>> sanitize *.debian.net a bit. I wonder if instead, we should have a list
>>> of requirements for *.debian.org that does not include "hosted on a
>>> machine managed by DSA". People would then continue to use debian.net as
>>> they do currently, but once the service grows to something really
>>> useful, it gets a review to ensure that it is maintainable, and can move
>>> to the debian.org without necessarily putting more load on DSA.
>> That's really a discussion you'll want to have with DSA, and it doesn't
>> seem that the project is in a position currently to add any more load to
>> the DSA team at this point.
>
> How does it add more load on the DSA team?

If you intend to make decisions or set up additional policy regarding
how debian.org subdomains are used, then you're going to have to involve
the DSA with that.

-Jonathan

-- 
  ⢀⣴⠾⠻⢶⣦⠀  Jonathan Carter (highvoltage) <jcc>
  ⣾⠁⢠⠒⠀⣿⡁  https://wiki.debian.org/highvoltage
  ⢿⡄⠘⠷⠚⠋   https://debian.org | https://jonathancarter.org
  ⠈⠳⣄⠀⠀⠀⠀  Debian, the universal operating system.

[toc] | [prev] | [next] | [standalone]

#12050

I've been thinking about your question about alternate names for the
debian.net team.
Everything I come up with would be confusing with regard to DSA--like
the Debian services team.

Perhaps something like Services Facilitators.

Or just go with debian.net team and be clear in the description  what's
going on.

Thanks for your willingness to consider alternatives.

[toc] | [prev] | [next] | [standalone]

#12051

On 02/09/20 at 13:49 +0200, Jonathan Carter wrote:
> Hey Lucas
> 
> On 2020/09/01 16:05, Lucas Nussbaum wrote:
> > On 01/09/20 at 15:29 +0200, Jonathan Carter wrote:
> >> On 2020/09/01 09:14, Lucas Nussbaum wrote:
> >>> 2. Keeping our important services sanely maintained. Your proposal is to
> >>> sanitize *.debian.net a bit. I wonder if instead, we should have a list
> >>> of requirements for *.debian.org that does not include "hosted on a
> >>> machine managed by DSA". People would then continue to use debian.net as
> >>> they do currently, but once the service grows to something really
> >>> useful, it gets a review to ensure that it is maintainable, and can move
> >>> to the debian.org without necessarily putting more load on DSA.
> >> That's really a discussion you'll want to have with DSA, and it doesn't
> >> seem that the project is in a position currently to add any more load to
> >> the DSA team at this point.
> >
> > How does it add more load on the DSA team?
> 
> If you intend to make decisions or set up additional policy regarding
> how debian.org subdomains are used, then you're going to have to involve
> the DSA with that.

My understanding is that the current situation is that we have two
categories of services:

1/ official services, under the debian.org domain, hosted on machines
managed by DSA, where some recommended practices[1] are enforced.

2/ unofficial services, under the debian.net domain, where all DDs can
add their own services, with no control/review. It has happened in the
past that such services were lost because the maintainer went MIA, or
the machine was lost, or....

I think that we agree that the problem you are trying to solve here is
that some of the unofficial services are important services for Debian,
and probably desserve more attention from the project. Also, we should
avoid increasing the workload of DSA.

What you are proposing is building a team that manages unofficial
services on the debian.net domain. It might help services maintainers a
bit, but I'm not sure it really helps the project enforce good practices
for its services.

My proposal was to keep debian.net for unofficial services, and instead
make it easier to promote unofficial services to official services on
the debian.org domain, by lifting the requirement that they need to be
hosted on machines managed by DSA (and instead rely on cloud providers,
for example), and designing a simple review process for candidate
official services. This process would check things like: is the service
sufficiently relevant/useful? is there a small team behind the service,
or is it a one person's job? Is the code available and free? Are there
critical design issues?

DSA could of course participate in the review (and it would be great if
they did), but it doesn't have to be their sole responsibility. And I
don't think that managing DNS entries for those services would really be
a huge workload. So I don't see a big increase on DSA's load here...

Lucas

[1] https://wiki.debian.org/ServicesHosting#Recommended_practices_for_Debian_services

[toc] | [prev] | [next] | [standalone]

#12053

On Wed, Sep 02, 2020 at 05:10:18PM +0200, Lucas Nussbaum wrote:
> On 02/09/20 at 13:49 +0200, Jonathan Carter wrote:
> > Hey Lucas
> > 
> > On 2020/09/01 16:05, Lucas Nussbaum wrote:
> > > On 01/09/20 at 15:29 +0200, Jonathan Carter wrote:
> > >> On 2020/09/01 09:14, Lucas Nussbaum wrote:
> > >>> 2. Keeping our important services sanely maintained. Your proposal is to
> > >>> sanitize *.debian.net a bit. I wonder if instead, we should have a list
> > >>> of requirements for *.debian.org that does not include "hosted on a
> > >>> machine managed by DSA". People would then continue to use debian.net as
> > >>> they do currently, but once the service grows to something really
> > >>> useful, it gets a review to ensure that it is maintainable, and can move
> > >>> to the debian.org without necessarily putting more load on DSA.
> > >> That's really a discussion you'll want to have with DSA, and it doesn't
> > >> seem that the project is in a position currently to add any more load to
> > >> the DSA team at this point.
> > >
> > > How does it add more load on the DSA team?
> > 
> > If you intend to make decisions or set up additional policy regarding
> > how debian.org subdomains are used, then you're going to have to involve
> > the DSA with that.
> 
> My understanding is that the current situation is that we have two
> categories of services:
> 
> 1/ official services, under the debian.org domain, hosted on machines
> managed by DSA, where some recommended practices[1] are enforced.
> 
> 2/ unofficial services, under the debian.net domain, where all DDs can
> add their own services, with no control/review. It has happened in the
> past that such services were lost because the maintainer went MIA, or
> the machine was lost, or....
> 
> I think that we agree that the problem you are trying to solve here is
> that some of the unofficial services are important services for Debian,
> and probably desserve more attention from the project. Also, we should
> avoid increasing the workload of DSA.
> 
> What you are proposing is building a team that manages unofficial
> services on the debian.net domain. It might help services maintainers a
> bit, but I'm not sure it really helps the project enforce good practices
> for its services.
> 
> My proposal was to keep debian.net for unofficial services, and instead
> make it easier to promote unofficial services to official services on
> the debian.org domain, by lifting the requirement that they need to be
> hosted on machines managed by DSA (and instead rely on cloud providers,
> for example), and designing a simple review process for candidate
> official services. This process would check things like: is the service
> sufficiently relevant/useful? is there a small team behind the service,
> or is it a one person's job? Is the code available and free? Are there
> critical design issues?
> 
> DSA could of course participate in the review (and it would be great if
> they did), but it doesn't have to be their sole responsibility. And I
> don't think that managing DNS entries for those services would really be
> a huge workload. So I don't see a big increase on DSA's load here...

Speaking as someone who helps (with a small team) to manage
alioth-lists.debian.net which is a bit unusual (it's considered
part of the Debian Project on https://www.debian.org/legal/privacy; it
handles mail for lists.alioth.debian.org) I think your proposal makes
a lot of sense. I'd also add a security and privacy review, and a data
integrity review, to your list.

I can't promise to offer a lot of round tuits in the immediate future, but
I'd be happy to be part of a team running such a process.

Best
Dominic

[toc] | [prev] | [next] | [standalone]

#12054

On Tue, Sep 01, 2020 at 09:14:30AM +0200, Lucas Nussbaum wrote:
> > That's it in a nutshell for now. Any thoughts... or volunteers?
> 
> I think that this proposal combines two quite different aspects, and
> that it might be better to keep them separate.
> 
> 1. Maintaining contacts with infrastructure providers that are willing
> to help Debian. That's of course useful, but not limited to debian.net
> services. For example, some QA tasks could benefit from access to cloud
> resources.

This is something that the formally delegated cloud team members are
already responsible for.  If we broaden the scope of that team a bit, we
can avoid creating additional organizational structure.  Most of the
technical work that the cloud team does doesn't require any formal
delegation, so in theory you could split the delegated part of the team
out into something like a general "infrastructure service provider" team
or something.

Of course, that assumes that the current cloud team delegates are
interested in signing up for extra work. :)

noah

[toc] | [prev] | [next] | [standalone]

#12044

Hi Jonathan

On Mon, Aug 31, 2020 at 06:21:10PM +0200, Jonathan Carter wrote:
> The services ran under the debian.net domain are typically run by
> individual Debian Developers or small teams, and range from a toy
> service to something that's short lived or even a service that's even
> considered important and used daily by people in the project.

The IMHO largest problem with debian.net is currently:  All entries are
assigned to single people.  However we try to create more teams which do
things together and avoid single people dropping out.

Also it's currently a mix of services people can use and internal
domains that just exists because they need a name.  So it's not an easy
task to collect what is what without asking.

For the productive Salsa domains, we opted in to just assign them to the
service user instead of one of the developers.  This however means that
only DSA can actually change entries, which somewhat negates the
original purpose of debian.net.

> 2. Create a new team to organise some aspects of everything under
> debian.net, which would include:
> 
>   * Keeping the domain list on the above mentioned
>     DebianNet page maintained on a regular basis

I miss a bit what they would actually do here.  It also depends on what
this page should be about.  Services that people can use?  Services that
exist?

>   * Maintain external contacts/relationships with
>     people and providers who we have special arrangements
>     with
>   * Help maintain the list of hosting providers listed
>     on the wiki page above

This sounds more like donation stuff, but yes, it would be helpful.

>   * Have accounts with the major hosting providers so that
>     they can also create new instances whenever there's a
>     new request from a developer

How would you devise the relationship with the cloud team, which
currently holds the accounts and does the more privileged stuff with
them?  (And also is tasked to actually procure contracts with those
vendors.)

Regards,
Bastian

-- 
She won' go Warp 7, Cap'n!  The batteries are dead!

[toc] | [prev] | [next] | [standalone]

#12151

Hi Jonathan

On Mon, Aug 31, 2020 at 06:21:10PM +0200, Jonathan Carter wrote:
>   * Have accounts with the major hosting providers so that
>     they can also create new instances whenever there's a
>     new request from a developer

I opened an issue for the AWS side of that:
https://salsa.debian.org/cloud-admin-team/debian-cloud-aws-setup/-/issues/12

Regards,
Bastian

-- 
Spock: The odds of surviving another attack are 13562190123 to 1, Captain.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.project

csiph-web