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
