10:38 p.m.
On lip 08, Imre Jonk wrote:
> This is very impressive! I suspect that you had to write at
least
> dozen additional roles to manage things that are not yet in DebOps
> itself, but some of that effort could probably be offloaded to
> already existing roles like nginx, ferm, sysctl, postfix, etc. That's
> what I was aiming for with the project from the start and I'm very
> glad that you were able to make it work.
Something like a dozen roles, yeah. You'd be surprised about all the
things I managed to do with some clever variable tricks and existing
DebOps roles. Some of the roles I wrote for CipherMail (built to be
compatible with DebOps) can be found here:
https://gitlab.com/ciphermail?filter=debops
Good to know. I will have to mine that for some ideas.
DebOps joining Debian would be a great move. I'm really not sure
when
it would be the right time for that, so we'll better start preparing I
guess ;)
I discussed DebOps with a Debian developer (a project member with many
rights regarding the Debian project) during the launch party for Buster
in Amsterdam. He was interested but was not too familiar with
automation tools like Ansible, so this unfortunately didn't result in
fruitful cooperation.
I'm contacting a few people involved with the Debian project about
this. Let's see what happens.
I can see some friction in that the current "feedback loop" looks like this:
- Debian Stable is released
- DebOps is upgraded to support new Debian Stable release
- Issues are found in Debian which are mitigated in DebOps over time
- Hopefully the workarounds to issues find their way into next Debian Stable
Because DebOps is focused on Debian Stable and not the development release,
the feedback loop being outside Debian itself works pretty well for Stable
users. I'm not sure how that would change if DebOps is incorporated into the
Debian development process, but perhaps something like this - a "feedback
loop" of sorts which can be used to develop solutions that can then be
incorporated into Debian would be benefical to the community.
It's similar to how Debian treats upstream applications with fixes found in
Debian being pushed upstream so that eventually Debian patches can be dropped
entirely. This is what happens with downstream distributions like Ubuntu or
Mint, but DebOps is not a Linux distribution per se.
> At the moment DebOps is in a quasi-like state where more and
more
> people start depending on it, but the project itself is not really a
> legal entity. I'm currently covering the bills for the DNS domain and
> VPS hosting where various sevices are kept, like this mailing list
> for example. These costs are manageable right now, so I'm not worried
> about requiring any donations, especially that this would require me
> to set up some kind of company to handle taxes in Poland, and other
> such things I'm currently not in a capacity to handle myself.
If setting up something like a foundation works the same way in Poland
as in the Netherlands (having founding documents notarized for a
substantial price, needing to find a secretary and treasurer, as well
as handling taxes), then I can strongly imagine that this is not
something that you'd desire. I'll leave this decision to you.
Sponsoring should be fine though. Hmm...
Yes, it works pretty similarly in Poland as well. But I think that we can
leave this as-is for now. If online meetings work out to something bigger and
a large number of interested people show up, we can then think about
a solution.
Now I feel bad about not using the debops.gitlab role to manage our
internal GitLab installation. I really contemplated it, but the Omnibus
package is just so damn convenient :/
I would say don't worry about it. :) The official Omnibus packages probably
have a more reliable upgrade path than the role in DebOps. Omnibus also
provides various dependencies internally which might be important in
production if you want to get the latest GitLab release; the version in DebOps
will not be updated as frequently.
And you should still be able to use GitLab Runners managed by DebOps with the
Omnibus GitLab install.
> I guess a real life meeting of some sort would be a first step
> towards that, to estabilish such relationships Web-of-Trust style,
> similar to how Debian does it. They seem to handle much larger
> project just fine this way, and probably are a good example to
> follow.
I'm all in favour of meeting each other in real-life. Let's make that a
major milestone for us in 2021, possibly sooner. I have doubts if the
Chaos Communication Congress is happening this year, but if it is, then
that would be an awesome opportunity for this.
I was invided to CCC a few times already, unfortunately at the time the event
was happening around Christmas which I usually spend with my family. So it's
a very hard pick... Let's see how the situation evolves, though. 2021 will
probably be a major milestone for everybody.
> Actually, I was wondering if creating a new mailing list for
such
> people interested in maintaining the project and giving it direction
> would be a good idea. Say, 'debops-devel'? I'm sure that not every
> user would be interested in such discussions, this would let them
> have a choice if they want to keep tabs on them or not.
I'm okay with having this on debops-users, it's not like there is too
much list traffic here. We can always move it to another list if things
really take off.
Very well. I'll try to write some more focused messages in the near future.
That last part can translate to project management methods that I
don't
want to spend too much time on discussing, but keeping something like a
todo list up-to-date could be considered essential.
I've started to write down the things I'm working on in a Project page
(kanban-like) on GitHub: https://github.com/debops/debops/projects/5
Small steps, but hopefully this will help improve the project.
I think we should help you here, you're obviously too busy with
other
things. I guess everyone is in some way, but reviewing PRs and
prioritizing them sounds like easy money to me. You can of course still
leave the final merge decision up to yourself, but more public
discussion on PRs can't do much harm. And you'll be able to make a more
informed decision.
Thanks! Of course I don't want to force anybody to do this if they don't want
to. Pull request reviews are pretty easy to do on GitHub and you don't need rw
access to the repository to do them. Every little bit helps. :-)
> An online meetup is an interesting idea, this would definitely
help
> put some faces to the nicks. I'm up for it if anyone else wants to
> meet up. We can arrange a time and method later via the mailing list;
> it should be easy to do using some of the many online services.
Let me propose a proposal. Let's propose next Wednesday at 18:00 *UTC*.
Let's also keep the expectation that it will be relatively short (~30
mins) so that many people will join. We can do a little meet&greet and
discuss plans. I can take the lead if you want, or you can do it
yourself.
Sounds good to me, you can take a lead if you want. Any preference in regards
to the platform? https://meet.jit.si/ is probably an interesting choice, and
we can test its capabilities at the same time. We can prepare a room on the
day before and send a separate e-mail with the link to the mailing list..
Well that's something I can help out with. You'll get a 2
vCPU VM with
4 GB RAM, 50 GB storage and unfiltered Internet access with a public
/29 and /64. Everything is easily expandable if need be. We're just
waiting on the (likely overworked) colocation provider to assign the
subnets. I like you Maciej, but I don't want to put you in our
business-critical production VLAN just yet ;)
You forgot - I'm already there. ;-)
As for the proposed setup - access to the IPv6 network will be interesting
since I don't have that now. But otherwise it seems that this would converge
to another set of LXC containers. But it will be interesting to see the
network layout.
That mentality can really suck sometimes. But hey, so far I've
been
boasting around how successful one can be automating their
infrastructure with DebOps, so maybe that will help a little. And then
there's that blog post that I'm writing anyway. My employer has also
been boasting around about the automation tech we use, so I can imagine
that at least some people around us are very interested right now :)
Having more users is the first step to having more contributors!
That's true. Looking forward to the blog post. :-)
Cheers,
Maciej