7:44 p.m.
Hi all,
TL;DR: we need to talk about keeping DebOps the awesome and healthy
project that it is today, for many years to come. Please voice any
concerns you may have. Also, some battle history, cuz' Maciej is a
sucker for war stories.
Let me start off this lengthy email by congratulating everyone involved
in this project with the sheer progress that we made since DebOps
0.8.1, which is the first DebOps release I got to use. In production
mind you, which may or may not have pressed Maciej to pull forward his
1.0.0 release [1].
There has been even more progress since genesis [2] (is that where the
'ginas' name came from, Maciej?). I had just started my System and
Network Engineering education at the AUAS and landed my first job as a
Debian (or initially, Ubuntu) system administrator at Bits of Freedom.
It would have been good to know a thing or two about Ansible and IT
automation back then. But I got an O'Reilly book on that subject a few
months into the job, so that was nice.
After some time I had been using Ansible for about half a year at Bits
of Freedom, but wrote all playbooks from scratch. They weren't exactly
the best quality and I still felt like I was working hard, not smart. I
had trouble reusing my own roles and had difficulty solving some
automation problems which resulted in me still doing a lot of manual
sysadmin work. This of course felt more like putting out fires instead
of real progress. I thought that Docker could save me, but no, that
only made it worse because now I still had the exact same automation
problems, but with the added complexity of container lifecycle
management.
Then, somewhere at the end of february (or beginning of march) 2019, I
decided to give this "data center in a box" thingy a try. I had just
landed my second sysadmin job at CipherMail, where the previous admin
had been doing everything by hand. Long story short, I turned off the
very last legacy, hand-managed VM last week. We now run ~45 servers
across multiple data center locations and cloud providers. There are
high availability setups in there, like our DNS, LDAP, RADIUS, mail and
web clusters. We have firewalls, load balancers, DNSSEC, Let's Encrypt
and IPv6 everywhere. Our office wifi has WPA2 Enterprise with EAP-TTLS
for authentication against our LDAP database. Our VPN setup is
incredibly easy to enroll for new users and allows login with LDAP
username, password and Yubikey OTP. Simply removing a user from our
LDAP database immediately revokes their access to almost every IT
system we have. Everything is all meticulously monitored with Icinga
and its agents. Security patching takes minutes instead of hours. And
the best thing? It is *all* automated. And that leaves me with lots of
time to automate even more, like our continuous integration setup and
an upcoming cloud service. I actually have the time to visit customers
on-site now, which happened last week for the first time and was really
inspiring to me!
I truly feel like I am in full control of the whole IT infrastructure
at my place of work, which is something that I had definitely not felt
before. That data center in a box thingy, combined with some additional
roles I wrote, has been a major game changer for me. It became the only
open source project that I regularly contribute to, although I don't
put nearly as much time in it as I would want. The small but capable
community around it is just great. I feel indebted to many of you,
especially to Maciej.
Which is why I never want this adventure to end.
Honestly, even the thought of the possibility of this great project
ceasing to exist makes me sweat. I know that DebOps has brought a lot
of joy to many system administrators and homelab hobbyists out there.
CipherMail has also benefited greatly from the steady development over
the last few years. Of course there won't be an immediate operational
or security issue for us if all development would cease, but our
automation progress would most certainly be heavily impacted by it.
So consider this a check-in round. What I would like is an honest
'temperature' reading of all contributors. Not your actual temperature
(although it would be nice to hear that you're COVID-free), but more
how you currently see the future of DebOps and your involvement. Is
there anything you would like to see improved? And, even more important
but not as pleasant to discuss, what would happen if you were to cease
spending time on DebOps due to other priorities or unforeseen
circumstances? Do you feel like the project is (heavily) dependent on
you? Is your involvement causing you any sort of stress?
Lastly I'd like to lend a proverbial ear to any suggestion or comment
on this email. I want to know if I can do something more to ensure the
continued success of this project. I am certainly able to arrange
things like publicity and sponsoring of infrastructural services, and
will probably be able to organize a meetup for all of us once these
tougher times are behind us. Or maybe we should do regular online
meetups. Let me know what you think. My employer and I both recognize
the importance of our shared adventure.
Yours truly, and truly yours,
Imre
[1]
https://lists.debops.org/hyperkitty/list/debops-users@lists.debops.org/me...
[2]
https://github.com/debops/debops/commit/a214ab2c2f1f28d072456204477bd040a...
11:23 p.m.
On lip 06, Imre Jonk wrote:
Hi all,
Hello!
Also, some battle history, cuz' Maciej is a sucker for war
stories.
Indeed, I am. :-)
There has been even more progress since genesis [2] (is that where
the
'ginas' name came from, Maciej?).
The "ginas" name was a backronym, from "ginas is not a server" - since
it was
meant to manage a cluster from the start, contrary to other such projects
being worked on at the time (2013) which focused on everything done on single
hosts. But, a better name came along and I switched it.
I thought that Docker could save me, but no, that only made it worse
because
now I still had the exact same automation problems, but with the added
complexity of container lifecycle management.
I think that Docker is a great solution in a narrow field of stateless
applications, as long as you have everything that is needed underneath Docker
for it to work under control. There are of course solutions for that like
Docker Machine (more for development), Rancher, now Kubernetes and other
orchestration platforms, but these are great when you use them as managed
services. When you try to host them yourself, the problems of setting
everything from the ground up come back again. And without solid foundation,
it's only a matter of time when something breaks under Docker and everything
comes down. Building everything properly takes time and effort.
Long story short, I turned off the very last legacy, hand-managed VM
last
week.
Congratulations! :-)
We now run ~45 servers across multiple data center locations and
cloud
providers. There are high availability setups in there, like our DNS, LDAP,
RADIUS, mail and web clusters. We have firewalls, load balancers, DNSSEC,
Let's Encrypt and IPv6 everywhere. Our office wifi has WPA2 Enterprise with
EAP-TTLS for authentication against our LDAP database. Our VPN setup is
incredibly easy to enroll for new users and allows login with LDAP username,
password and Yubikey OTP. Simply removing a user from our LDAP database
immediately revokes their access to almost every IT system we have.
Everything is all meticulously monitored with Icinga and its agents.
Security patching takes minutes instead of hours. And the best thing? It is
*all* automated.
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.
I would love to see some of these things in DebOps someday - putting roles
upstream will definitely benefit other users and will make the code resilient
and easier to maintain when big changes happen. Of course dumping everything
at once will probably break some things, and you probably would want to clean
up secrets or stuff meant only for your own environment, so it will take time.
Still, if you plan to contribute some of your solutions to DebOps, that will
be awesome.
And that leaves me with lots of time to automate even more, like our
continuous integration setup and an upcoming cloud service. I actually have
the time to visit customers on-site now, which happened last week for the
first time and was really inspiring to me!
Did you just found a way to beat https://xkcd.com/1319/? I guess sharing
automation solution between organizations will do it...
I truly feel like I am in full control of the whole IT
infrastructure
at my place of work, which is something that I had definitely not felt
before. That data center in a box thingy, combined with some additional
roles I wrote, has been a major game changer for me. It became the only
open source project that I regularly contribute to, although I don't
put nearly as much time in it as I would want. The small but capable
community around it is just great. I feel indebted to many of you,
especially to Maciej.
It's great to hear that a project that I started long ago helped you in such
a way. This tells me that my decision to make it open by default and work on
it essentially "from outside in" to ensure that other people would be able to
mold it for their own needs was a correct one.
Of course don't forget that DebOps is just essentially an icing and a cherry
on a very big cake which is other Open Source and Free Software projects,
especially the whole Debian ecosystem, whthout which DebOps probably would not
exist today, and Ansible which is THE tool which made such a thing possible in
the first place. I'm not sure if DebOps could be recreated using other
configuration engines such as Puppet or Saltstack - maybe, maybe not.
Which is why I never want this adventure to end.
Honestly, even the thought of the possibility of this great project
ceasing to exist makes me sweat. I know that DebOps has brought a lot
of joy to many system administrators and homelab hobbyists out there.
CipherMail has also benefited greatly from the steady development over
the last few years. Of course there won't be an immediate operational
or security issue for us if all development would cease, but our
automation progress would most certainly be heavily impacted by it.
I was aware pretty early that making DebOps an open project worked on by lots
of people from different organizations will eventually require some kind of
stewardship over it to keep it going. Usually projects like these end up with
a foundation of some sort behind them (Apache Foundation, Mozilla Foundation,
GNOME Foundation, I can keep going...), or a separate corporation is formed to
perform the role of a steward (Software in the Public Interest, Software
Freedom Conservancy). I always thought that at some point DebOps could join
the Debian project in some way, not just as a package in the repositories, but
as a platform to give users as a stepping stone for "what to do after
installing Debian". But I feel that it is still too early for that to happen,
there are lots of things to clean up and improve. Some roles haven't been
revisited in years due to lack of time or user interest.
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.
Various other services like Travis-CI, GitHub, GitLab CI, ReadTheDocs.org
provide a free tier which seems to be sufficient for now. DebOps is
intentionally designed to be as much self-contained as possible - users are
able to set up their own GitLab CI pipeline to faciliate the tests, code and
documentation linting performed on Travis-CI for each pull request can be done
locally as well after all needed tools are installed (need to make this
process easier). I intentionally don't want to depend on any specific SaaS or
cloud service to keep the project self-contained and focused on selfhosting.
So consider this a check-in round. What I would like is an honest
'temperature' reading of all contributors. Not your actual temperature
(although it would be nice to hear that you're COVID-free), but more
how you currently see the future of DebOps and your involvement.
First of all, thanks for starting this thread! I know that I'm really bad at
mailing list discussions, I still need to work on some kind of initiative
skills... After the mailing list server was upgraded to Mailman 3 I hoped that
the rate of discussions here would increase a bit, so it's good to see such an
e-mail.
I will have to write down some messages around current problems I see in
various roles in the project, but usually I prefer to just work on fixing them
instead. I'm afraid that this impacts the development culture around DebOps
- not much discussion about problems and how to fix them collectively. Perhaps
this can be improved in the future.
Is there anything you would like to see improved?
I would like to hear the answers to that question as well! One problem I can
definitely see impacting the project is keeping the codebase secure and
trustworthy. I tried to solve this problem by limiting the number of people
that can merge pull requests to the main repository, requiring (but not
enforcing as of yet) signed commits to allow code authorship tracking,
carefully reviewing each pull request and trying it out when needed before
merging, but I think that this made the development process very slow, some
pull requests are waiting years to be resolved. Sorry about that.
I'm not really sure how to solve this problem yet. Most likely more people
would have to be involved in the review and testing process, with some kind of
trusted relationship formed between those who can merge PRs into master.
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.
Now that I think about it, DebOps actually is a combination of two things
- the existing Ansible and Python codebase which lets you manage
infrastructure, and a virtual "blueprint" of an IDEAL infrastructure the
project strives to implement - what software to use for various services,
the configuration order of different services, what protocols to use, etc.
Perhaps such a "blueprint" could help with development and design of DebOps
codebase and provide guidelines for role authors to follow. I know that there
are some beginnings of it in various parts of the DebOps documentation that
describe how the roles should be written, etc. but that's probably not enough
to be such a blueprint. I've meant to write an Admin Guide in the docs to
describe to how to set up an infrastructure with DebOps but it still hasn't
happened yet. Imre, you seem to have done a very good job without it - perhaps
a more in-depth guide on how you modeled your infrastructure and what choices
you made along the way would be a good starting point?
And, even more important but not as pleasant to discuss, what would
happen
if you were to cease spending time on DebOps due to other priorities or
unforeseen circumstances?
I'm in a position where I have been actively using DebOps at my workplace for
several years and essentially doing my work "through it" as much as possible.
I definitely don't plan to stop that any time soon - I don't see myself going
back to managing Linux infrastructure entirely by hand again, and switching to
a different project like this is probably impossible - I don't see any modern
alternatives that would handle the scope that I need. So, in essence - I'm
stuck with you for the forseeable future. ;-)
But if I stop for any reason, I plan to give reins of the project to somebody
else, of course. Who will that be, I'm not sure yet. I'll probably look
closely at the list of contributors to the project[1], not only at the number
of commits but at recent activity as well. Or perhaps over time we can form
a larger group of people that can maintain the project as a team. 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.
[1]: https://github.com/debops/debops/graphs/contributors
Do you feel like the project is (heavily) dependent on you?
It is, a bit by my own design, and this probably creates a bottleneck in the
speed of changes and new features impelemnted in DebOps. I'm not sure what
pace of development would be expected from such a project; Debian Stable
releases happen about every two years and it is considered very slow by Linux
community standards. I implemented a four stable releases per year model
which kind of fell apart a bit over time, totally by my own hand. I need to
better take care of it in the future, but if this model proves unsustainable
I'm not against changing it. I guess more discussions about it will be needed.
Is your involvement causing you any sort of stress?
Hmm, maybe a bit. I definitely feel guilty of not handling incoming pull
requests or issues on GitHub in a timely manner, I will have to work on that.
Other than this, the scope of what the project does really broadened over the
years and the development pace slowed down as a result. On each stable release
I try to set a few goals for myself for the next one, some of them are made,
some not. I definitely try to focus on lower-level stuff, roles that are used
in many different places (think firewall, LDAP, various databases) rather than
specific user-facing applications so that development efforts can be
multiplied over multiple roles at a time. On top of all that is all of the
non-Ansible related things and management of the project itself (DNS, various
services used for DebOps development, etc.). Of course on top of that is my
regular workplace stuff which sometimes needs to take precedence.
Lastly I'd like to lend a proverbial ear to any suggestion or
comment
on this email. I want to know if I can do something more to ensure the
continued success of this project. I am certainly able to arrange
things like publicity and sponsoring of infrastructural services, and
will probably be able to organize a meetup for all of us once these
tougher times are behind us. Or maybe we should do regular online
meetups. Let me know what you think. My employer and I both recognize
the importance of our shared adventure.
It's definitely good to hear that your employer is aware that it's not all in
your fingertips, but you use open projects for your work. I think that's an
excellent example to follow.
Currently most of the real-time communications within the project is done on
IRC, but there's no logging involved and the format of an IRC conversation is
probably not very good for some things. More focus on the mailing lists would
probably benefit most current and future DebOps users, especially that we now
have proper search UI in Mailman 3.
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.
What I would be interested in is access to more varied infrastructure for
development. At the moment I have limited resources at home, and development
boxes that are available to me at work are extremely slow (How slow? the
common playbook on my home workstation takes about 4 minutes to finish. On the
development server at work? 35 minutes.). Due to what I have available, I'm
doing my development using LXC containers which introduces a bias in what I'm
currently working on. Some things are not possible using containers
exclusively, for example NFS infrastructure needs at least VM-level setup
since you cannot mount filesystems in unprivileged containers. A VM management
platform like OpenNebula requires either hardware-level access or
virtualization nesting which introduces speed penality as well (that for
example would grind my development boxes to a halt). It would be interesting
to have access to some boxes and a subnet, of course if latency over SSH is
reasonable.
Publicity... I really suck at it. And then there's the mentality on the Net
(for example Reddit) where advertising your own work can be considered akin to
shilling... So I just don't do it. But if you think that DebOps is worth it,
and you have some good ideas on how to do it - be my guest. :-) Let me know if
you need some pointers about various aspects of the project. Just be aware
that this will bring more users to DebOps which will result in more issue
reports and pull requests which might be good or bad - who knows. :)
Yours truly, and truly yours,
Imre
Again, thanks for starting the thread and have a nice day,
Maciej
9:04 p.m.
Hi Maciej, thanks for the great reply. I hope that others on this list
will chip in as well.
Sorry for the late response by the way, I am way too much of a
perfectionist to be able to slam an email out of my brain just like
that. But I'll surely miss something no matter how hard I try, so here
goes...
On Mon, 2020-07-06 at 23:23 +0200, Maciej Delmanowski wrote:
> Also, some battle history, cuz' Maciej is a sucker for war
stories.
Indeed, I am. :-)
Pay attention y'all! The man says he wants *war stories*, so give him
all you got!
The "ginas" name was a backronym, from "ginas is not a
server" -
since it was meant to manage a cluster from the start, contrary to
other such projects being worked on at the time (2013) which focused
on everything done on single hosts. But, a better name came along and
I switched it.
DebOps is a better name indeed. But let us not forget the ginas
genesis, for it be our lexical legacy.
...or something like that ¯\_(ツ)_/¯
I think that Docker is a great solution in a narrow field of
stateless applications, as long as you have everything that is needed
underneath Docker for it to work under control. There are of course
solutions for that like Docker Machine (more for development),
Rancher, now Kubernetes and other orchestration platforms, but these
are great when you use them as managed services. When you try to host
them yourself, the problems of setting everything from the ground up
come back again. And without solid foundation, it's only a matter of
time when something breaks under Docker and everything comes down.
Building everything properly takes time and effort.
Yeah, I made a few painful design decisions with the Docker
infrastructure at Bits of Freedom at the time. I still feel bad about
my successor having to clean it all up.
> Long story short, I turned off the very last legacy,
hand-managed
> VM last week.
Congratulations! :-)
Thanks a lot! It was an awesome and fulfilling journey. Which will not
be over for a long time, thankfully. There's always more to be
automated.
> [..]
> And the best thing? It is *all* automated.
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
I would love to see some of these things in DebOps someday - putting
roles upstream will definitely benefit other users and will make the
code resilient and easier to maintain when big changes happen. Of
course dumping everything at once will probably break some things,
and you probably would want to clean up secrets or stuff meant only
for your own environment, so it will take time.
Still, if you plan to contribute some of your solutions to DebOps,
that will be awesome.
You bet that integrating these roles into DebOps mainline are very high
on my whishlist. You'll be seeing PRs for these roles in the coming
months, starting with the largely rewritten debops.dhcpd role.
Did you just found a way to beat https://xkcd.com/1319/? I guess
sharing automation solution between organizations will do it...
Haha, maybe so! And OMG that title text is the best!!!
It's great to hear that a project that I started long ago helped
you
in such a way. This tells me that my decision to make it open by
default and work on it essentially "from outside in" to ensure that
other people would be able to mold it for their own needs was a
correct one.
Which is exactly the reason why I decided to give that project a try.
Thanks a lot :)
Of course don't forget that DebOps is just essentially an icing
and a
cherry on a very big cake which is other Open Source and Free
Software projects, especially the whole Debian ecosystem, whthout
which DebOps probably would not exist today, and Ansible which is THE
tool which made such a thing possible in the first place. I'm not
sure if DebOps could be recreated using other configuration engines
such as Puppet or Saltstack - maybe, maybe not.
You're absolutely right and I am well aware of the importance of free
and open source software. I'm glad to be working for a company that
makes (mostly) FOSS, which in itself is also based on other open source
projects.
I was aware pretty early that making DebOps an open project worked
on
by lots of people from different organizations will eventually
require some kind of stewardship over it to keep it going. Usually
projects like these end up with a foundation of some sort behind them
(Apache Foundation, Mozilla Foundation, GNOME Foundation, I can keep
going...), or a separate corporation is formed to perform the role of
a steward (Software in the Public Interest, Software Freedom
Conservancy). I always thought that at some point DebOps could join
the Debian project in some way, not just as a package in the
repositories, but as a platform to give users as a stepping stone for
"what to do after installing Debian". But I feel that it is still too
early for that to happen, there are lots of things to clean up and
improve. Some roles haven't been revisited in years due to lack of
time or user interest.
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.
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...
Various other services like Travis-CI, GitHub, GitLab CI,
ReadTheDocs.org provide a free tier which seems to be sufficient for
now. DebOps is intentionally designed to be as much self-contained as
possible - users are able to set up their own GitLab CI pipeline to
faciliate the tests, code and documentation linting performed on
Travis-CI for each pull request can be done locally as well after all
needed tools are installed (need to make this process easier). I
intentionally don't want to depend on any specific SaaS or cloud
service to keep the project self-contained and focused on
selfhosting.
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 :/
First of all, thanks for starting this thread! I know that I'm
really
bad at mailing list discussions, I still need to work on some kind of
initiative skills... After the mailing list server was upgraded to
Mailman 3 I hoped that the rate of discussions here would increase a
bit, so it's good to see such an e-mail.
It's always nice to see your work pay off :)
(not sure if this is due to the new mailing list software, but anyhow)
I will have to write down some messages around current problems I
see
in various roles in the project, but usually I prefer to just work on
fixing them instead. I'm afraid that this impacts the development
culture around DebOps - not much discussion about problems and how to
fix them collectively. Perhaps this can be improved in the future.
Thanks for raising this issue. Contributor engagement is something that
a lot of open source projects seem to struggle with. Which is
definitely not saying that there isn't enough engagement amongst DebOps
contributors, but like you are indicating, it's often about engaging in
very specific tasks that are necessary to bring the project as a whole
further. Writing our challenges down for all to see may be a good first
step.
This reminds of rule 3 of the Debian Social Contract: "We will not hide
problems".
> Is there anything you would like to see improved?
I would like to hear the answers to that question as well! One
problem I can definitely see impacting the project is keeping the
codebase secure and trustworthy. I tried to solve this problem by
limiting the number of people that can merge pull requests to the
main repository, requiring (but not enforcing as of yet) signed
commits to allow code authorship tracking, carefully reviewing each
pull request and trying it out when needed before merging, but I
think that this made the development process very slow, some pull
requests are waiting years to be resolved. Sorry about that.
It's a really good thing if there are at least two contributors with
write access to the mainline repository. Those are you and Robin right
now, so that should be alright. Robin has, as far as I can remember,
not approved any of my PRs though, those were all yours.
I'm not really sure how to solve this problem yet. Most likely
more
people would have to be involved in the review and testing process,
with some kind of trusted relationship formed between those who can
merge PRs into master.
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.
Now that I think about it, DebOps actually is a combination of two
things - the existing Ansible and Python codebase which lets you
manage infrastructure, and a virtual "blueprint" of an IDEAL
infrastructure the project strives to implement - what software to
use for various services, the configuration order of different
services, what protocols to use, etc.
Perhaps such a "blueprint" could help with development and design of
DebOps codebase and provide guidelines for role authors to follow. I
know that there are some beginnings of it in various parts of the
DebOps documentation that describe how the roles should be written,
etc. but that's probably not enough to be such a blueprint. I've
meant to write an Admin Guide in the docs to describe to how to set
up an infrastructure with DebOps but it still hasn't happened yet.
Imre, you seem to have done a very good job without it - perhaps a
more in-depth guide on how you modeled your infrastructure and what
choices you made along the way would be a good starting point?
It's funny, I've discussed writing about our virtualization and email
infrastructure automation with my employer a couple of days ago. It
would be something for our technical blog, but it should be easy to
modify for usage as documentation for DebOps.
Our clustered, highly available email infrastructure is extreme
overkill for the amount of mail that flows through it. That's because
we're trying to eat more of our proverbial dog food. It would however
be a nice showcase of what's possible with DebOps.
I'm in a position where I have been actively using DebOps at my
workplace for several years and essentially doing my work "through
it" as much as possible.
I definitely don't plan to stop that any time soon - I don't see
myself going back to managing Linux infrastructure entirely by hand
again, and switching to a different project like this is probably
impossible - I don't see any modern alternatives that would handle
the scope that I need. So, in essence - I'm stuck with you for the
forseeable future. ;-)
That's great to hear :)
The same applies to me, every change I make revolves around DebOps
roles and playbooks. I'm absolutely hooked.
But if I stop for any reason, I plan to give reins of the project to
somebody else, of course. Who will that be, I'm not sure yet. I'll
probably look closely at the list of contributors to the project[1],
not only at the number of commits but at recent activity as well. Or
perhaps over time we can form a larger group of people that can
maintain the project as a team.
Every team needs a leader, and right now that team is all who regularly
contribute to DebOps and its leader is you. I'm not sure if creating
another team within said team would change that much. More involvement
in testing/approving PRs however might.
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.
> Do you feel like the project is (heavily) dependent on you?
It is, a bit by my own design, and this probably creates a bottleneck
in the speed of changes and new features impelemnted in DebOps. I'm
not sure what pace of development would be expected from such a
project; Debian Stable releases happen about every two years and it
is considered very slow by Linux community standards. I implemented a
four stable releases per year model which kind of fell apart a bit
over time, totally by my own hand. I need to better take care of it
in the future, but if this model proves unsustainable I'm not against
changing it. I guess more discussions about it will be needed.
I'm all in favour of the "It's done when it's done" mentality. This
of
course only works when there are enought people working on getting it
done. So if you ask me, the most important drivers of a new release are
the people who work on it, and the system they use to make the time
they assign to the project as worthwhile as possible.
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.
> Is your involvement causing you any sort of stress?
Hmm, maybe a bit. I definitely feel guilty of not handling incoming
pull requests or issues on GitHub in a timely manner, I will have to
work on that.
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.
Other than this, the scope of what the project does really broadened
over the years and the development pace slowed down as a result. On
each stable release I try to set a few goals for myself for the next
one, some of them are made, some not. I definitely try to focus on
lower-level stuff, roles that are used in many different places
(think firewall, LDAP, various databases) rather than specific user-
facing applications so that development efforts can be multiplied
over multiple roles at a time. On top of all that is all of the non-
Ansible related things and management of the project itself (DNS,
various services used for DebOps development, etc.). Of course on top
of that is my regular workplace stuff which sometimes needs to take
precedence.
I'm jealous of the amount of work-hour time you can (seamingly) put
into this project. Maybe I should allocate some block of hours every
week to improving DebOps roles. I've been doing it between other things
until now, and always in relation to some automation problem I've been
having at work. The DHCP role would be a great starter.
The improvements to lower-level roles indeed sound like a great way to
multiply your efforts.
It's definitely good to hear that your employer is aware that
it's
not all in your fingertips, but you use open projects for your work.
I think that's an excellent example to follow.
Haha, it's like I said. My employer writes a lot of open source
software that in itself leans on other open source software. It's the
open source redistribute-athon :)
Currently most of the real-time communications within the project is
done on IRC, but there's no logging involved and the format of an IRC
conversation is probably not very good for some things. More focus on
the mailing lists would probably benefit most current and future
DebOps users, especially that we now have proper search UI in Mailman
3.
It would benefit me a lot, I'm not really the IRC type. I know how to
idle there but am almost never actively online.
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.
What I would be interested in is access to more varied
infrastructure
for development. At the moment I have limited resources at home, and
development boxes that are available to me at work are extremely slow
(How slow? the common playbook on my home workstation takes about 4
minutes to finish. On the development server at work? 35 minutes.).
Due to what I have available, I'm doing my development using LXC
containers which introduces a bias in what I'm currently working on.
Some things are not possible using containers exclusively, for
example NFS infrastructure needs at least VM-level setup since you
cannot mount filesystems in unprivileged containers. A VM management
platform like OpenNebula requires either hardware-level access or
virtualization nesting which introduces speed penality as well (that
for example would grind my development boxes to a halt). It would be
interesting to have access to some boxes and a subnet, of course if
latency over SSH is reasonable.
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 ;)
Publicity... I really suck at it. And then there's the mentality
on
the Net (for example Reddit) where advertising your own work can be
considered akin to shilling... So I just don't do it. But if you
think that DebOps is worth it, and you have some good ideas on how to
do it - be my guest. :-) Let me know if you need some pointers about
various aspects of the project. Just be aware that this will bring
more users to DebOps which will result in more issue reports and pull
requests which might be good or bad - who knows. :)
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!
Cheers,
Imre
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
2 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Hi,
TL;DR: The other DebOps Developer here. SaltStack at work for SUSE SLES
systems. DebOps with Ansible for my private self hosting. I am not leaving
DebOps and therefore also not Ansible for the foreseeable future so you will
have to stick with me :) I don’t regret the learning curve and the commitment
to excellence of DebOps when I joined early 2015.
Can DebOps be done with SaltStack
I at first answered this here but I guess it is better to move it out into an
issue to not make this email even longer.
Tracked in: https://github.com/debops/debops/issues/1415
Which is why I never want this adventure to end.
Agreed. And let me use that opportunity to thank mainly Maciej for his never
ending great work on DebOps! Not to forget maintaining it which is not to
underestimate work that hardly anybody thanks one for. Thank you!
And, even more important but not as pleasant to discuss, what would
happen
if you were to cease spending time on DebOps due to other priorities or
unforeseen circumstances?
That would mean one DebOps Developer less. But on the good side, I don’t hold
any keys/accesses exclusively that are needed to continue DebOps. But moving
forward, there should be more support for Macjei here.
Do you feel like the project is (heavily) dependent on you?
Not so much currently now that all my work on DebOps is done in my spare time,
and I am thankful for that. I recently turned off email notifications for
GitHub activity which helped me greatly stay focused. Now I have dedicated
(spare) time where I work on my off-work projects.
I try to maintain a few DebOps roles that I really care about. They are mostly
the security, crypto, self-hosting kind of roles like debops.cryptsetup and
debops.etesync for example. Also, I see myself as an independent reviewer of
all of the core code changes and a lot of roles that enter master, for years.
And there is cryptographic proof of it.
Is your involvement causing you any sort of stress?
It is fine. But I cannot take much more responsibility right now due to other
projects I maintain also, other side projects and so on.
Something which would cause me stress is being in real-time chat all the time
like IRC which is why I much prefer structured hands-on discussion in issues
and PR. So you don’t see me in IRC. Sorry for that.
It is *all* automated.
Impressive setup at work, Imre! Also that you can work mostly with FOSS.
Unreleased roles laying around
Writing proper DebOps roles takes time as we have high standards and long
documentation detailing it so I think just put the unfinished roles somewhere
and link them in the issue tracker or as PR. This at least prevents someone
else needing such a role from writing it from scratch and instead improving
the existing role bringing it a bit closer to being DebOps ready.
Also, one thing I would propose is more hands-on code reviews. Instead of
commenting "this thing should be changed", maybe the reviewer can just fix it
themselves if there is no need for discussion (typos or the like) or even
propose changes that need discussions. I hope the learning effect is the same.
If contributors try to exploit this we could stop it on case-by-case basis. I
often do this in the form of checking out a PR hands-on, working on it and
opening a PR against the fork. I do this in the hope of increasing
productivity for everyone involved.
Sponsoring, Foundation
I am also not really eager to take the time for the tax/legal stuff right now.
But I also understand that something like this could help the project move
forward.
Making DebOps more widely known
I still want DebOps t-shirts :) Ref: https://github.com/debops/docs/issues/221
But I much rather work on technical stuff than do marketing/design. I have the
hope that people who know what they want will find DebOps on their own. I
guess that is how I got involved. But I know of course that this is wishful
thinking.
> 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.
Very true :)
online meetup
2020-07-15T18:00Z works for me and I will try to make it. I would also propose
Jitsi.
- --
Live long and prosper
Robin `ypid` Schneider -- https://me.ypid.de/
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEE7eE3HRuH0o2l6AUVhv2YC78aQPgFAl8HBs4ACgkQhv2YC78a
QPgumhAAsw3AtzVD93K17JM1QzaTVHMN4HHR7aknTr7Q8NWexHiUDgxa0gYtNOcF
a/97A76x/6IFPfgJ38JnRApuBdcnPCMwjkYIC164+PIBFahhLILbTBglJ7IkMg2/
WsC9RRMKbS3r1CkIeA/B8uC+Mc0MonFzGOP5eTVCcQN7N/EQjzGkeR3DPabWLonL
L/s903zdt3YUoY41Kt3UERC6DP/ZYQywTpkGF4jPkNNKGKf4o+TXB5DB8FJGJnBN
d00xo7eDuhHk50tMrpZyTkG2bT4LqDJglFzO5zFBph2diZfULW9XkZucbilQpYcO
j9vT+YFjw29ia1u+Buvti/p/4ki4peBJxcHgVjnSWYtMFc1FfTbZaJ+Nf1CBO61Q
rKNiBwaZC+ABT8TeuqbG209rroZ/iUNDXeI//jVPdvkLyMGQJ9eUHTszUZRxpL2k
+aBVHqLQ6e2gHV92GqivXaT6Mibxwejow14TOIZXRoK9hki9shZ0MpAecDsAk6pf
AOJCl/n5uQ34QafwJpRvtlXJja7tnZpknhm1j3MmJr/SsT592u6F37SYBS70zy1E
m3N+s3ybDPrm7qtN5Vvebev8d6t6wZnZfcNt2uTZSVD/lPM1N29jXZLfqnWuOphw
XoxV4N/6h5GlVqxhW0DJk9hKCZ/xWlZRv2PV+pOOR415yb5xrJY=
=Fo1O
-----END PGP SIGNATURE-----
7:29 a.m.
Hi,
On 08/07/2020 21:04, Imre Jonk wrote:
Hi Maciej, thanks for the great reply. I hope that others on this
list
will chip in as well.
A little bit busy right now but I agree with what you mentioned Imre.
I'm in !
--
Nicolas Quiniou-Briand
Messagerie instantanée (Jabber) : nqb(a)azyx.fr
Tél : 06 75 84 56 74
6:54 p.m.
On Wed, 2020-07-08 at 21:04 +0200, Imre Jonk wrote:
It's funny, I've discussed writing about our virtualization
and email
infrastructure automation with my employer a couple of days ago. It
would be something for our technical blog, but it should be easy to
modify for usage as documentation for DebOps.
Our clustered, highly available email infrastructure is extreme
overkill for the amount of mail that flows through it. That's because
we're trying to eat more of our proverbial dog food. It would however
be a nice showcase of what's possible with DebOps.
For whoever is interested, you can find the blog post here:
https://www.ciphermail.com/blog/eating-our-own-dog-food.html
11:02 a.m.
On Wed, 2020-07-08 at 21:04 +0200, Imre Jonk wrote:
For whoever is interested, you can find the blog post here:
https://www.ciphermail.com/blog/eating-our-own-dog-food.html
The Dovecot bug we discussed before (the one that caused sieve script
synchronization with dsync to fail) has been fixed in Debian 10.6! We
no longer have to use custom-built packages for this.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928492
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=930919
Thanks Noah :)
11:32 a.m.
Hi Maciej,
On Wed, 2020-07-08 at 21:04 +0200, Imre Jonk wrote:
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 ;)
Well that subnet assignment took quite a bit longer than expected, but
it's done. You now have root(a)debops.ciphermail-demo.com (that domain
name is just one we have laying around, feel free to change it). I
pulled your public SSH key from GitHub.
Here are the SSH host key fingerprints:
256 SHA256:Nrw40T164/ZsBW9braPacXCsVa01D0tV22dBOBTtQ64 root@debops
(ECDSA)
256 SHA256:5oveoUe60p4qxMIXwY7CogzFkbj6j2JX9gYOXLhHWfk root@debops
(ED25519)
2048 SHA256:oI0WQ6C8kDTbj+gOtnd0T5N5b5KypAYglPLUtpMNv7U root@debops
(RSA)
You can freely use IP addresses in 87.233.82.200/29 and
2001:9a8:17b::/64, except for the first address in each range, those
are the gateway addresses. Let me know if you need changes to the
reverse DNS records.
I hope you'll find a good use for it (like testing IPv6 support in
DebOps or something). Let me know if you have any questions regarding
the VM or network.
Imre
12:13 p.m.
On lip 30, Imre Jonk wrote:
Well that subnet assignment took quite a bit longer than expected,
but
it's done. You now have root(a)debops.ciphermail-demo.com (that domain
name is just one we have laying around, feel free to change it). I
pulled your public SSH key from GitHub.
You can freely use IP addresses in 87.233.82.200/29 and
2001:9a8:17b::/64, except for the first address in each range, those
are the gateway addresses. Let me know if you need changes to the
reverse DNS records.
I hope you'll find a good use for it (like testing IPv6 support in
DebOps or something). Let me know if you have any questions regarding
the VM or network.
Thanks! Access seem to be working fine.
I'm not sure what could be done with a host like this... I'll probably start
with LXD support to be able to spin up containers. One idea is to set up LDAP
service which we could then use in other services used by the project, like
the wiki. It's a VM, so we cannot really go wild with virtual machines, normal
containers will have to do. If somebody has some ideas for the server, let me
know.
I'll try to see if the resulting DebOps project directory can be published.
Let's see how git-crypt fares in practice.
-- Maciej
4:20 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Hi all,
I don’t regret the learning curve
Tasos, resident noob.
My comfort zone is usually way higher up the stack, but I've been happily
chewing away at the learning curve, reading up on things I never knew I
wanted
before I ran into debops. :)
I run (am?) a solo web/design/game dev shop, mostly targeted towards small
business clients.
War stories
My old infra was managed by Python ServerScripts (`pyss`), a custom python
module built on top of `fabric`. I had built it as an experiment for using
multiple inheritance in a "mixin" architecture.
It was as horrible as it sounds. I'm glad I didn't set it loose on the
world.
So anyway, I think I learned something about dogfood.
Imre, we both write long emails but I believe our naming styles differ. ;)
My deployment
I haven't yet replaced my old infra with debops, but hey, got a pretty real
deadline in 10 days. All my testing is done on vagrant/libvirt.
My motivation is to provide small-scale projects with a setup that
facilitates
digital sovereignty, can be accountable to the GDPR and has the ability to
scale from a shared host to its own deployment.
All my IT-conscious friends think I'm wasting time I don't have but it's
gonna
be great, they'll see. xD
My 'temperature' reading
I'm certainly here to stay; I like the project's goals, Maciej is amazing,
and I prefer my solutions to live upstream than as little tech debt booby
traps
in my codebase.
My time, however, is a bit spotty, since I have to wear all sorts of hats.
Right now I've been working on a role to set up `bind`, but it'll be a while
until I can afford to put in this kind of hours again.
I currently watch the issues, mostly being surprised by how much stuff I'm
not
qualified to help with. I doubt I'll be much more help when I'm a week deep
in
shader code. Also I bite people. :)
More on contributions
The main domain I see myself contributing to the project is documentation.
I document my procedures anyway, just in case I need to delegate something,
so I'm happy to push chunks of that when they have a place in debops.
I have a bunch more ideas about the doc, generally aimed at making some high
level debops concepts (such as `parse_kv_config`) explicit.
On balancing the workload
Sometimes I've felt like doing some gruntwork but couldn't spot any
low-hanging
fruit. I'm pretty sure it's because Maciej fixes easy stuff on the spot. :)
I've attempted to expose some easy but boring stuff to do in the doc contrib
page, but spotting those required asking Maciej in the first place.
The Godot community marks "documentation" and "junior jobs" issues
and
suggests
them in their issue main page. Perhaps letting some of those hang for a few
days
would at least clarify how much the existing dev community is able to take
on.
A user mailing list
I'm not sure segregating a user community has any benefits with the current
levels of traffic. If it would give Maciej some peace and quiet, sure, but
I bet
he would just answer stuff there, too. :p
I also think that with enough of a framework about debops architecture and
best
practices, we can aim to lower the barrier between user and contributor.
After all, debops end users are ansible users.
debian-testing
It would make sense to me to aim to support stable and testing instead of
targeting flavors like Ubuntu. Especially as it is diverging pretty heavily
these days, with stuff like netplan and snapd.
Just sayin' the stuff Ubuntu does for desktops, DebOps does for servers.
No need for both. ;)
I mean, ok, it would hurt galaxy tag SEO, but how important is that?
Anyway my point is that tightening the project's scope to debian could end
up
being less work even if we also ran against testing.
It would give us a clear spec and allow us to reliably support a debian
upgrade
path, perhaps even preemptively as testing becomes stable. It would
certainly
give me more utility as an end user than knowing it can also set up Mint.
Also I'm debian fanboy, down to the social contract, so a relationship with
them
sounds pretty good. At least in theory we're bound to have something usable
upstream every now and then.
I still want DebOps t-shirts :)
I shall be wearing my branding-person hat pretty soon, right after I deploy.
This and a logo are stuff I can happily help with.
Yo are we working-from-home?
I must figure out webcam, headphones and mic, otherwise I hope that
video-thingy
has spectator mode. I might try from my phone but it's pretty lousy, too.
It makes me happy to see everyone's mails sticking to the 80 character
limit,
even though it makes text wrap funnily on mobile. :)
I like async too but more than half the debops I know I learned by watching
the
IRC.
Tasos
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEEXbaOHtREtFSBLXcdOXguVye2c7EFAl8H0AYACgkQOXguVye2
c7FGtQ/9HBkI7qS/tX8cE12yxJk1HzJ7AX7AKhWirE0rjOKTD9H54hm7iF/4eaVU
MrTW8UjfCKHaYkVFRAmRDqcW7m1P1yDCxAYVKwriXfyDwo+Hy6JYVMViyp6aRF5w
nZZHQYS/7/uga2eZHIIIjuqpLZFES4BHQauQ9eu8l75klut7AX5YJdftsgAXf3DA
QVp2gVIppwhYdCGfDhfBK1aKnmF35h9PZZP4vGKNWwVH6kPLj9w7P6DC/B7+OdQi
O+h1I7rIIlhHcgYif0GTbZADyRfC518I3NXniz6Wg2BT6nXTRheIYgnTpbIsU+YY
L6S3ARAS9Upp7798I7Beb9L91FDKhpuY52wUcX8o/TCTSmmRAelfGJCTTN91mrSj
88xgCD4GBplvoSv+Khmuiju+gSAtgoWnXL7m3gjiQoErAMT0hTchfCRbio0QZiRL
X8TareS/+eg0k0g0GlVZFeddmkOr8FxIoU9/HQVBOJwTgR7lgOrZgls0EpW1gwNn
pEvuUE1Em2bWj+dthM3W5SKFH6wGkHzVgm4RSL7DGR7g7lCaLmwDPgMeGWBQMMK/
nefThjl12xXkirfH/usi1vC9hFgEJpWxAihI50JgCkVhFeWA9g6PeuEgNjQ1icVq
0VWp6EieLpaNJm/kvwK4KBHrnhH+ept7lQ9QzsymyaVp+SyH87Y=
=z0CR
-----END PGP SIGNATURE-----
2:43 p.m.
On 06/07/2020 19:44, Imre Jonk wrote:
Hi all,
Hello Imre, Dam here. Thank you for this awesome thread.
TL;DR: we need to talk about keeping DebOps the awesome and healthy
project that it is today, for many years to come.
Debops is truly a gem. It's definitely one of my dearest open source
projects along with Debian, QubesOs, Ansible, Nextcloud, LineageOs,
Firefox and a few others. Definitely in my top ten.
I truly feel like I am in full control of the whole IT infrastructure
at my place of work,
I'm still not in that situation but I'm longing for it.
Honestly, even the thought of the possibility of this great project
ceasing to exist makes me sweat.
you are not alone but the fact that it's open source reduces a lot the
pressure.
---
https://dam.venturin.net
1545
days inactive
1629
days old
11 comments
6 participants
participants (6)
-
Damiano Venturin -
Imre Jonk -
Maciej Delmanowski -
Nicolas Quiniou-Briand -
Robin Schneider -
Tasos Alvas