Re: Where to upload the Octavia image for Bullseye? Should I continue within the team?
On Tue, Apr 27, 2021 at 02:57:28PM +0200, Thomas Goirand wrote:
> On 4/27/21 8:22 AM, Ross Vandegrift wrote:
> 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).
Yes, the freeze probably makes this impossible. But I think reducing the
dependencies was the last idea to get the image artifacts under the salsa
artifact size limit. So without some reduction to the dependencies, I don't
think the builds could possibly work anyhow.
Unfortuantely, that means that merging it as-is isn't really a useful option.
[snip]
> > 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.
Sorry if I was unclear - I was trying to explain that the closed merge request
does not mean that some work is completely rejected. It just means that it's
not appropriate in the current state. But if you don't want to reopen or
continue that work, I understand.
> 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.
Would it make sense to continue to use the OpenStack directory for that?
> > 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.
Yes, I was suggesting that - I thought you already had something setup that was
doing builds on casulana for the images under OpenStack/?
[snip]
> 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?
It'd be great to have a full feature image finder, but I don't think I have the
time to do it. I was hopeful that Arturo's project would be successful but I
assume he got busy, like the rest of us.
If I were going to work on it, I'd aim for something simpler:
1. a cron job that scrapes the latest images from cloud.d.o and writes a small
json description to a fixed public url.
2. a very simple front-end that downloads that static json file and allows
filtering/searching.
The ability to search all of the older images is neat, but maybe too ambitious.
Ross
> [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.
Maybe there's some truth to this, but I think your description isn't quite
right. It's not about what Microsoft, Amazon, and Google want. It's about
what their users want - and their users are often Debian users.
> 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: