Hi Thomas.
> 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 don't think it was unilateral. There was never concensus within the
team that we should be offering application-specific images in the first
place, and then there were technical issues with the implementation. I
have no doubt the issues could have been communicated better, and in
part the problem is due to our recent use of Jitsi instead of IRC for
our team meetings. We naturally don't collect as detailed notes from
our Jitsi meetings, and it's likely that this was discussed in a meeting
that you did not attend. I am sorry for that. Jitsi meetings are great
for the people in attendance, but not so good for the people who can't
be there.
> 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.
Obviously that's something that you're free to do, but I'd argue
strongly doing so would ultimately create more work for you and more
confusion for our users. This team would become "cloud except
openstack", and your OpenStack work would naturally diverge from what
we produce. The experience would remain fairly consistent across the
non-OpenStack environments, but OpenStack users may experience something
entirely different. Or worse, some OpenStack users will run our images
(I assume we would continue generating them) and others would run your
alternative images, resulting in a different experience even for people
running within ostensibly the same cloud environment.
> 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).
I don't think that's remotely a fair comparison. The code in the
debian-cloud-images provides extremely useful integration with GitLab,
allowing us to generate images for multiple Debian releases for multiple
architectures targeting multiple different cloud environments (including
OpenStack!) on a daily basis. It publishes these images to multiple
commercial clouds, while also making them available for direct download
via cloud.debian.org. It provides a simple "1 click" interface for us
to publish new release images to several commercial clouds, including
updating marketplace listings where feasible. It provides a testing
framework that lets us validate the contents of the images we generate
before we publish them. That's more than a shell script's worth of
work, and I don't think it's over engineered at all.
> I also increasingly distrust that this team is going on the direction of
> promoting free software, and free cloud.
Franky, I think you're out of line with statements like that. Everybody
involved in the Debian cloud team has committed significant portions of
their lives to Free Software, cloud and otherwise. There are multiple
members of the team whose debian.org accounts date to the previous
century. Collectively, the people in regular attendance at the team
meetings probably have 75 years of committment to Debian and Free
Software.
> 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.
It's really not relevant that the package isn't it bullseye. It never
made sense there, and was impossible to keep up-to-date. People who
want to build their own images will have a better experience if they use
the same code and configuration that this team uses, which is available
on salsa. This was discussed on debian-release.
> 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...
OpenStack is mentioned in multiple places on
https://{cloud,cdimage}.debian.org/cdimage/cloud
> 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.
Is the issue that the image files themselves have "generic" rather than
"openstack" in their name? If so, this is literally the first time that
I can recall you raising this as an issue. If it has been a problem for
so long, why have you not opened a bug, a salsa issue, or (better yet) a
merge request proposing an alternative name?
At this point, we've been generating and documenting the "generic"
images for long enough that I'm not sure changing their names is a great
idea. It may be best to clarify our documentation around what images
target OpenStack.
> 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.
To reiterate what I said earlier, you are of course free to build
whatever you want. However, in the interest of providing Debian users
with the best possible experience, I don't think that's the best course
of action for you to take.
Following the most recent team meeting, Bastian implemented one of the
features that you've long requested for OpenStack users in
https://salsa.debian.org/cloud-team/debian-cloud-images/-/merge_requests/249/diffs
(Note that the submodule in the project that actually runs this code
hasn't been updated yet, so the symlinks aren't being created yet, but
we can fix that soon). So I don't think your despair is entirely
warranted.
Regarding the Octavia images, I remain unconvinced that we need to be
generating them, but if you truly believe it's important, then I suggest
that you do two things: 1. Document exactly what is needed in the image
and why it's necessary to generate an application specific image rather
than have users install after the fact (or generate their own images,
which isn't hard). 2. Create a change to the debian-cloud-images
repository and run the build on salsa to generate the images. Show that
it works and that it generates something of reasonable quality that is
targeted to a particular need. As I recall, the issues with it in the
past were that the proposed images ended up including lots of
unnecessary packages, making them large and complex. If you can provide
a compelling reason and a good implementation, then I think you'll find
it easier to convince people.
noah
Attachment:
signature.asc
Description: PGP signature