On 11/08/17 18:31, KatolaZ wrote:
> On Fri, Aug 11, 2017 at 11:16:36AM +1200, Daniel Reurich wrote:
>
> [cut]
>
>>
>> Jaromil your not helping. Stop throwing your weight around and putting
>> pressure on nextime. It won't solve things, just adds to his stress and
>> given his recent situ I expect it's unwelcome and uncaring. Besides
>> he's kindly built and hosted the CI infrastructure that devuan relies
>> upon, and if you piss him off and he turns it off Devuan is dead in the
>> water. So don't start sidelining him because he's got time difficulties
>> at the moment.
>>
>
> This is indeed what really scares me, tbh. That one of us, a single
> point of failure, can be pissed off at any time by a discussion on a
> mailing list and decide to shoot Devuan dead, just because he/she
> feels like it and can do it. Do you reckon what you are talking about?
> And are you really comfortable with what you are envisaging? :(

What I'm not comfortable with is the shit that you and parazyd have
expressed about nextimes stirling efforts to stand up and host a
platform that has allowed Devuan to come to fruition, but now you guys
continue to insult him and his approach which in my opinion is actually
really optimal, even if the minimal bits of glue he's written aren't
examples of perfect programming. Nextime built the ci system single
handledly and you continue to shit all over his work. I'm not concerned
about Nextime reacting badly, but you guys continuing to insult his
efforts to stand up a build system in short order.
>
> I have been saying that having single points of faults is too risky
> for Devuan. In theory, it should not be a problem among trusted adults
> committed to a single shared cause. In practice, I am afraid that you
> are talking quite childish here, and I don't think that the future of
> Devuan can rely on the childish decisions of any single person.

I've worked hard to bring people like yourself on board to deal with the
biggest risk factor I see with Devuan, and that is the absence of people
like me and nextime preventing other people from working. I brought you
in to help with getting people working with the build system we have -
not to upend it with fanciful ideas of boutique alternative solutions.
You repay that trust I extended and repay us by insulting nextime and me
thinking you know better and have better solutions whilst in the same
breath continue to ask me to explain how things work. It's not like you
didn't have the source code for releasebot to study... but no that's too
hard for you, ask Dan instead because he did work with it and study it,
and took the time to understand how it functions.
>
> But that's only my humble opinion. I have no power on deciding where
> Devuan should go. The only thing I know is that Devuan cannot
> fail. What you are talking about seems to go in another direction,
> unfortunately :(
>
Actually what I say doesn't go in another direction. I want to point
the focus back to developing devuan, and if you'd stop with this 'I"m
not in love with scorsh unless you tell me I'm wrong then your evil and
childish' bullshit. It doesn't wash KatolaZ.


>> We are not dealing with a broken CI system here, it still works fine for
>> Devuan. Most of the issues scorsh is meant to deal with is wishlist
>> items that IHMO can be better addressed by either patching existing
>> tools or writing focused single purpose tools.
>>
>
> You keep saying that, but we have not seen a single solution. I posted
> an RFC, and received no technical comments on it. Only hate, and
> uninformed prejudices. scorsh is a focused single-purpose tool. It
> does just one thing (command authentication). I don't know if it does
> it well. But there is no wishlist item there.

And when I started to pick the RFC to bits because it's most glaring
problem was that it did not describe the particular problem is that it
doesn't describe the problem (and you refuse to provide a clear
statement on that), and I challenged the fundamental assumptions, you
get all shitty saying we haven't provided a single solution. Well I'm
not the programmer, but I have laid out clearly how the solution would
look and what's minimally required to resolve each issue.
>
>> KatolaZ, I'm sorry, but I still fundamentally disagree with scorsh, and
>> see it as a systemd like exploit being foisted on our CI system. It's
>> bad engineering in this context.
>
> Centurion, I have not yet understood why you disagree with scorsh, and
> I would be more careful comparing scorsh with systemd, or to a
> systemd-like "exploit", as a motivation. I simply expect more than
> that from a technically skilled person like you :(

I compare it with systemd because it exposes a style of engineering that
is similar to Lennart Poetterings style. Not Invented Here syndrome
comes to mind. It's an apt comparison as your proposing to replace a
very minimalist tool missing some little features with a suite that
includes it's own authentication and permissions system which and
centralises control of the entire CI on itself. It's simmly the wrong
approach at the wrong layer and absolutely reject any claim that it is
single purpose, minimalist and focused.
>
> Scorsh is a single tool, that exactly does one thing, in 500 lines of
> code, so I don't see any resemblance to the systemd-monster you are
> talking about. Anyone who has looked into the code can understand
> that.

Really... Scorsh provides:

1) an authentication system,
2) a permissions model of it's own
3) a tool that embeds json encoded commands in the git commits of the
project using it.
4) a daemon waiting for a signal from a post commit hook from the git
repsitory
5) a database of project specific configuration (replicating what can
already be derived from gitlab and is stored in jenkins).
6) a unique command protocol all of it's own not based any common
approach I've seen before.
>
> I am not in love with scorsh. I don't get paid for it. I don't get
> royalties out of it. We don't need to adopt scorsh at all costs. But
> we agreed that we need to solve the current problems in the CI
> infrastructure. scorsh provides a solution. You can ignore it, and go
> for something else. I am totally fine with that. Only, I would
> appreciate a technical motivation, if possible. If it's impossible to
> have a technical motivation, I will live with that.
> a
If you weren't so committed to scorsh why did you not dig into
releasebot and implement my simple suggested solutions to your clained
issues... most of them being figments of you imagination:

"One of the problems that scorsh is trying to solve is that at the
moment only two people can issue build requests on gitlab, besides you
and nextime, and these two people are me and Lydia_K. This is simply
not sustainable, and the permission system of gitlab does not seem to
be flexible enough." (KatolaZ in email 25th August to devuan-dev)

FACT: Anybody with greater then Master permissions on their own project
if it is setup in jenkins, can build the project. This includes also
masters in the group the project resides int

"The other problem scorsh is trying to solve is the fact that there is
no privilege separation between who can issue a build and who can
modify a Jenkins job." (same email as above)

FACT: Only those with greater then Master permissions in the blessed
gitlab group - configurable in the releasebot - can add, modify or
delete a project from jenkins.

>>
>> I strongly object to scorsh having it's own authentication/permissions
>> system built in. We already have a sufficient system for that in gitlab
>> and which do not belong in a tool that should be a thin layer between
>> gitlab and the ci system. And if we were to replace gitlab, we should
>> move to a separate tool for providing federated authentication and
>> permissions.
>>
>
> Scorsh is exactly that. A separate tool which does only and
> exclusively authentication of actions. But again, I am not in love
> with scorsh. I saw a series of problems in our current infrastructure,
> mainly related to authentication and privilege separation. I saw
> nothing git-based around and decided to write scorsh. I beg your
> pardon for not having asked you the permission to do so, but you know,
> programmers program for the joy of programming, expecially when they
> code in their unpaid spare time :)
>
I have no issue with your desire and ability, but most of the problems
you claim scorsh fix are only problems in your mind because you refused
and continue to refuse to read the documentation I pointed you to about
how the CI system authentication worked.
    
> scorsh will still use releasebot, the current one, just refactored by
> parazyd to eliminate a few of those long lists of ifs. The code is
> available here:
>
> https://github.com/parazyd/devuan-releasebot

great, I'll look at it. And test it with my test suite to see if it's
broken anything.
>
> Apparently, this scorsh-based solution is in line with what you are
> now envisaging as a long-term plan. We don't have to adopt scorsh, and
> noone is forcing anything. nextime agreed to provide an alternative
> based on releasebot (btw, I hope that the alternative will *separate*
> the authentication from the logic of releasebot, otherwise releasebot
> will probably become a hairball).
>
releasebot does not do authentication (except authenticating to gitlab
and jenkins so it can do it's job). It simply checks the permissions in
gitlab are appropriate for the commands it is given.

>> With regards to the website stuff, lets either fix the gitlab ci job or
>> abandon it and go to the static html site.
>>
>>
>
> OK. When will this happen? Who is in charge of it? Or more simply,
> when will golinux be able to push those damn changes to the website?
> Jaromil has become another single point of fault there, and this is
> not sustainable. We simply can't wait for jaromil to have time to look
> at it every few weeks or so. Devuan cannot remain stuck because any of
> us is having a bad month at work :(

Obviously it's entirely opaque to you too and therefore I will have to
do it.
>
>> Now if we are going to do anything to releasebot to fix it's glaring
>> flaws fine. Lets define the issues and deal with them as should have
>> been done properly before scorsh was ever started.
>>
>> I'll start:
>>
>> * has no test suite. (I've started writing one). This is top of the
>> list as it reduces the chances of a patches breaking existing functionality
>>
>> * can't support multiple distro's - this can be resolved in 2 ways -
>> either run a separate releasebot for each distro (requires a small
>> patching to add the distro name to the job name) or adding support
>> for distro handling.
>>
>> * architectures shouldn't be hard coded at job creation - they should be
>> detected during source build
>>
>> * architecture should be a build time option (especially for initial
>> build testing or rebuild of previously failed archs)
>>
>> * it doesn't have a listener daemon that can be used to trigger a build
>> ( this would allow gitlab on commit webhooks to trigger builds or maybe
>> a cutdown scorsh like tool). Could also be solved by a direct hook in
>> jenkins.
>
> I would add privilege separation to this list, which is a quite
> important lack at the moment, since only gitlab project masters can
> build a package, and once they can build it for a suite, they can
> build it for any suite, potentially dropping shit in a production
> release without any control at all.**** deunked as above ****

> No need to say that scorsh already provides support for those things
> (and has a testsuite, which I am expanding further to cover the
> specific needs of Devuan's CI) together with the slightly refactored
> version of releasebot provided by parazyd. So I have already done
> that. But you don't like scorsh, I got it (even if I don't get why, to
> be honest. The only clear motivation so far is that scorsh was not
> written by either you or nextime, who are the gurus of the building
> infrastructure. Which is fine as a motivation, but again a childish
> one.)

My objection is that scorsh is a huge complex beast that has it's own
authentication system that replicates project state data. It's not
simple, it's not clean functional design and it's not based an proper
evaluation of the issues.

This is obvious as your continuing to lie about what releasebot can and
cannot do and the separation of privileges it provides. You still don't
understand the fundamental problems, so you can't possibly provide a
valid solution!!
>
> It seems to me that we are going backwards here. We had already
> decided during the Devuan meeting on Wed 26th July that nextime was
> having a go at refactoring releasebot to address the points above, and
> we would have decided once we had seen his solution. nextime himself
> said that the solution he had in mind (which is still pretty
> misterious) would have convinced everybody. I am eager to be convinced
> by nextime's solution.
> There is nothing mysterious at all about nextimes solution, because I
have already multiple times exactly what is entailed. And we aren't
going backwards, but we are wasting time discussing a non-solution to a
largely imaginary problem.

As I have said all along, define the problem and the solution will
likely be obvious and simple.



--
Daniel Reurich
Centurion Computer Technology (2005) Ltd.
021 797 722