Re: Where to upload the Octavia image for Bullseye? Should I continue within the team?
Hi Ross,
Thanks for your very nice answer.
On 4/27/21 8:22 AM, Ross Vandegrift wrote:
> 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.
Bastian complained that the octavia-agent has too many dependencies,
some of which are useless. That's probably truth, though raising this as
an excuse to close the merge request is not welcome because:
- the remark could have been done back in Boston at the MIT meeting. The
team has literally more than a year to warn about it.
- we're in freeze, and I simply can't revisit the Octavia agent at this
point of the cycle, and don't want to wait another 2 years for bookworms
to be out. If I ask the release team to remove some of the dependencies
from the octavia-agent, at this point of the Debian release cycle, I'm
almost certain the answer will be a plain *NO* (and at this point, I
would also agree with the reasoning *AND* the no answer itself).
- when I'm done complying with "the Bastian policy" (or the team's
policy, as you like...), what will be next? Will something else be
found? Is this going to take another 2 years?
I've been patient enough, and waited a full release cycle already (all
of Buster). I need the image to be built automatically, so I can use
them for the company I work for, and deploy load-balancer-as-a-service
in a secure way. We need automated updates when they come (and get the
updated image uploaded to our public cloud, and the Haproxy VM of that
cloud automatically rolled-back using the "openstack loadbalancer
failover" command). To do that, we need stable URLs, and something
better than just dailies (ie: we need to know when we need an update).
I need this for production, and I must do it anyways. I see no reason to
do that work privately, and not share it with everyone else in Debian
and OpenStack. So if it doesn't happen within the team because of social
reason, I *must* (as in: professionally, for our public cloud
infrastructure) come with a solution.
> 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 wont do this, as I've lost confidence it will ever be merged in time,
and my production cannot wait for that long. I'm past this moment
already where I can afford to wait for 2 years to do the things the way
the team likes. My mail isn't begging for help, I'm *telling* that I'm
going to implement other options to get the work done, as what I've done
in the past doesn't seem to be of the taste of the team, and that I need
things now.
So I'm not asking the team for approval to do things myself, I'm asking
the team if the work is completely rejected, and I should be using a
debian.net domain (I probably will do this anyways as a start...), or if
I should try building stuff from Casulana, to push to
cdimage.debian.org/cdimage.
Going forward, please either:
- reopen my merge request and merge it *AS IS* (and don't ask for
something impossible to do at this time of the freeze, or ask me to wait
for Bookworms...), and let's have it happen within a few weeks, or...
- answer to my specific question on where I should push my Octavia
image, if it's ok to use the cdimage.debian.org/cdimage/cloud namespace
even if I'm using a different tooling.
> 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
Ok, so are you suggesting that I use my own build script, to build
Octavia images on Casulana? That'd be probably a good outcome too, but
I'm not really sure how to do that and get things published on
patterson. So the debian.net approach probably will be the first thing
I'll do.
> 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.
I very much like the generic images, especially because they are a lot
smaller than the images I've been producing. But no good URL *AND* no
image finder with a workable API is a show stopper for writing a script
to automatically upload images in an OpenStack deployment.
I've been also thinking about rewriting from scratch an image finder.
Why rewrite? Because I've tried to push for changes in the Arturo
version [1], and:
1/ the fixes to deploy aren't happening
2/ I still couldn't figure out how to initialize the db, so I can't push
the flask app in production because of this
3/ there's still no data feeding
I don't think it should be so hard to rewrite something, it probably
would be easier and faster than waiting on Arturo, literally for years,
and probably more easy to maintain.
Your thoughts?
[1] https://salsa.debian.org/cloud-team/image-finder/-/merge_requests/89
> 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.
I'm sorry it feel like I can't figure out what's going on there, and it
became too complex for the little time I have on this.
> We could debate about which route is better
This was not at all what I wanted to do. I was merely pointing out my
own failures to dive into what's been done.
> but I hope this helps show that it's not just over-engineering.
I still think the code is largely needs too much effort to understand,
when it's doing things that aren't that complicated. Probably it's
because I hate when there's too much of an object oriented design, and
no clearly defined functions. For example, there's class derivation at
many levels, and one need to read 3 files to understand the codepath.
Probably it fits the skills and coding habits of the team. But at least,
it doesn't work for me, who prefer functional, linear style.
> 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.
Thanks, Ross. Every time, I enjoyed communicating with you, because it
really feels like you are at least attempting to understand what I'm
trying to say.
Again, I have no anger what so ever, with what's going on within the
team, and what's been done in the past. I just don't think anymore that
it's going on a path where I can be useful.
I've been frustrated to only be able to complain about things I
disliked, instead of being able to contribute constructive changes. It's
probably my fault, and some lack of skills, or communication mistakes,
or not enough will to invest time trying to understand the direction
that is taken. Being aware of this, my reasoning are pushing me to try
other ways at this point.
>> 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.
The fact that the whole team is being paid by "the big 3" to produce
what they need, and that I've been unable to contribute enough, drove us
where we are now.
I don't think it's the fault of any individual team members except
myself. It's just the way things are. And I have serious doubts it's
going to change anytime, as I saw myself completely fail all the
objectives I had, as I spent most of my time on OCI [1] (which I am
super proud of, and I believe is a much greater success), and couldn't
find enough time for the debian-cloud team.
Cheers,
Thomas Goirand (zigo)
[1]
https://salsa.debian.org/openstack-team/debian/openstack-cluster-installer
Reply to: