Re: Where to upload the Octavia image for Bullseye? Should I continue within the team?
Hello,
Sorry you're feeling frustrated - your message raises some good points, and
some things that I think are worth a second look.
On Mon, Apr 26, 2021 at 10:40:25PM +0200, Thomas Goirand wrote:
> Hi there,
>
> I took some time off the team, to think a little bit about what to do
> next, and not react out of anger. I believe I passed that period since a
> long time already (months? years?), and it is with a lot of zen that I'm
> writing these words.
>
> Since Waldi, unilaterally, decided to close again the Octavia image
> patch for a 2nd time (for new reasons he didn't tell since we met
> Boston... yeah, just a new reason he found out!), I wonder where the
> cloud team would advise that I upload my work. It doesn't seem that
> anyone cared that it happened a 2nd time, and in fact, I wouldn't be
> surprised if the majority discovers this when reading this message.
I'm surprised to hear your reaction - your last message on the MR was that you
were putting it on hold pending some improvement to Salsa's artifact size I
didn't think you were waiting for further feedback.
I know it can feel weird to have an issue or merge request closed. But the
closure is not final. For better or worse, lots of projects have started
proactively closing issues or merge requests that aren't active. All this does
is move where the issue appears in the UI. Anyone should be able to reopen,
and you should feel free to do so if you're ready to work or discuss it more.
> I probably should just leave the team, and do my work on an unofficial
> debian.net domain. It probably will be a lot more restful, and I'll be
> free to do what I want. This feels bitter to write I should move to a
> debian.net, knowing that I was the first person in Debian building cloud
> images, and that I've been doing so for the last 3 releases. Then, will
> I still have the rights to call the then generated images "official"?
> Please let me know, that's important for me. I don't think I'm left with
> many options. The more I think about it, the more it feels like that's
> the easy path for me.
I don't think you necessarily need to depart from the team or migate to a
debian.net domain to work in the way you'd prefer. The requirements to be an
official image from [1] boil down to:
1) be built by a debian team or member
2) be built on casulana or pettison
You're good on #1. For most people, all the setup for #2 is a lot of work.
Perhaps the main value to debian-cloud-images is that it provides a framework
for Debian members to build images on casulana without all of the setup. But I
think you already have access to casulana, so that's not a compelling feature.
So IMO, you could continue to use your tools and work as a member of the cloud
team. I think you could do this largely independently of debian-cloud-images,
even though more folks are working in that repo.
Personally, I think it'd be great if debian-cloud-images could be beneficial
enough that you'd want to use it. But it's still missing some features. And
you have some use-cases where Salsa is a problem, and I don't think that'll
improve anytime soon. So it's a hard dilemma.
[1] - https://wiki.debian.org/Teams/DPL/OfficialImages
> I'm also thinking about continuing to generate my own OpenStack images
> on my own (not only the Octavia ones), as I am strongly in the opinion
> that everything is becoming *A WAY* over-engineer in the current images,
> to the point that the Python code of the team has became unreadable.
> Just look at the numbers. We're up to:
> - 68 .py files
> - 5k lines of python
> - 93 files in the config_space folder, so having cryptic content
> - I haven't dug into FAI, but itself it's ... big! 254 files...
>
> Compare this to the simplicity of just a single shell script of 2k
> lines, out of which 500 is just argument parsing, and another 645 are
> there to just handle weirdo networking for bare metal installation...
> (so basically, 800 lines of shell script).
This comparison isn't really apples-to-apples - debian-cloud-images also
handles interacting with the public clouds (converting and uploading images,
publishing, allowing public access, etc). Instead of requiring each cloud
provider's SDK, it builds tools on top of apache libcloud. So the trade off
here is: more code, more uniformity, and a packaged library vs. less code, less
uniformity, and less Debianized tools.
We could debate about which route is better, but I hope this helps show that
it's not just over-engineering.
> Don't get me wrong, I'm not saying what the team has done isn't good.
> Just simply that I don't see myself doing more as:
> - the tooling isn't fit for me (or the other way around)
> - some of the things I've proposed are just plainly rejected
> - there's still no feature parity and I have no time to invest
> - I do not want to deal with the aggressive take over and unilateral
> decision from other team members anymore
> - I don't feel like spending a single second explaining things again is
> worse of my (precious) time that I'd rather spend with my kids, or doing
> more constructive stuff
No free software project is as important as feeling good about your work or
enjoying time with your family. So if working outside of debian-cloud-images
is better for your life, it's okay to do that. And I think it's okay even if
it means the team output isn't as elegant as it theoretically might be. Given
the above, you might even be in a position to still publish official images.
> I also increasingly distrust that this team is going on the direction of
> promoting free software, and free cloud.
Well, I don't understand the distrust about the team's promotion of free
software. We publish free tools for building Debian images - I haven't seen or
heard anything different since I've been involved.
As far as promoting free cloud - the team rejected the proposed delegation text
with this demand. Some team members want to provide images for proprietary
clouds. I know close to nothing about openstack. So if you're expecting
everyone the team to promote free cloud platforms, I think your expectations
are misplaced.
Now I'm often aware that you're the only one really working on a free cloud,
and I feel sorry about that. Speaking for myself, I just don't have any
opportunity to use or learn anything about it at work.
> I'm not sure why the word
> OpenStack seems completely banned from our team. Just a simple fact
> probably will make the team think a little bit in what kind of mindset I
> am. If you grep "openstack" on our debian-cloud-images (master), here's
> what you get:
>
> debian-cloud-images (master)$ grep -r -i openstack *
> debian/control: * OpenStack
> doc/details.md:Example 2 genericcloud (OpenStack):
>
> The first entry where it's written "OpenStack", is useless because the
> package is gone from Bullseye. Is the 2nd one published anywhere? We're
> gone from a "cdimage.debian.org/cdimage/openstack" to a thing called
> http://cdimage.debian.org/cdimage/cloud where the word "OpenStack" is
> never even mentioned anywhere. OpenStack is *not* a swear word. It's ok
> to call our OpenStack images the way they should...
>
> Our Debian users do not understand it, and I have to (very often)
> explain on IRC... An occurrence of this explanation happened just today,
> and that pushed me to write this mail.
I feel your frustration here too. Our documentation is not in great shape, so
we don't even have something to point folks to. But it's hard to sit down and
write it - I've been trying and failing recently.
As long as we continue to publish both images, the different names might be
good - at least the names are different.
> What should I do for Bullseye? Ask Steve to continue to generate "my"
> OpenStack images so they stay in the debian.org domain, and maybe add
> images for appliances like Octavia? Or open a new debian.net hostname,
> and do it unofficially? Or generate only unofficial Octavia images? As
> Bullseye is coming, I'm leaning toward doing everything by my own.
>
> Your thoughts? Nothing is written into a stone yet, I will try (again)
> to listen to advice, as I really feel lost in the team at the moment.
>
> Cheers,
>
> Thomas Goirand (zigo)
>
>
Ross
Reply to: