Re: salsa.debian.org maintenance (GitLab 11.1.4 upgrade, external storage migration)
On 08/18/2018 01:11 PM, Bastian Blank wrote:
>> Also, using a free
>> implementation avoids vendor lock-in,
>
> Could you please be more specific on what vendor lock-in you mean?
>
> If I build an application using Kubernetes and Helm, I'm using only free
> components, but I'm still locked-in, as there is only one
> implementation. If I do the same using the OpenStack API, I'm locked-in
> as there exist only one implementation of this API.
First, there's dozens of OpenStack public cloud out there, so you're not
locked-in with a single operator. Then there's not a single contributor
to the OpenStack source code, the contributors are quite diverse.
To the contrary, if you're using a proprietary cloud like AWS, you have
no choice but to continue with them.
> In our case all the components can utilize multiple backends, so we can
> freely choose which one to use. Including completely free alternatives
> like ceph with radosgw or minio.
I'd like to understand better what the need and usage is. Could you
please expand? Do you need to store blobs, like with Swift? Maybe swift
is more adapted to the use case, if we only need to store blobs? Swift
is also a way more easy to deploy and maintain than a Ceph cluster,
which requires careful monitoring of daemons if you don't want it to
fall apart.
>> and provides proven (and tested on
>> a CI, for the case of OpenStack) interoperability.
>
> I'm pretty sure all the Cloud vendors do heavy tests on all sorts. To
> be exact, I know they do. They just don't show you all of it. So this
> is no unique selling point for OpenStack.
I was talking specifically about interoperability tests from one
OpenStack version to the next. OpenStack clients are designed to work
with *any* version of OpenStack, and they are supposed to work even some
very old deployments. And that's the thing that is tested in the CI. I
may be wrong, but so far, I haven't head that any of the big 4 non-free
clouds having such thing for their client API, and even if they did, it
would make little sense, as they don't have the interoperability problem
to take care of (they just need to be compatible with themselves).
Other free IaaS implementation may have the feature also, but
free-software public cloud providers are almost always using OpenStack
anyway, so interoperability, really, is a unique selling point here for
OpenStack.
>> And there's what Jeremy replied to you. We shall not endorse non-free.
>
> No, he just said we should prefer to use free ones.
>
> Endorse is something different, please read yourself
> https://www.merriam-webster.com/dictionary/endorse or
> http://www.learnersdictionary.com/definition/endorse
Well, it's a question of view. To me, having Salsa to host some of its
data on Google is a kind of tacit endorsement. Even worse, it gives the
message that, from the viewpoint of the whole Debian community, it's ok
to host there. Clearly, I'm not the only one bothered in this way.
>> Though what I agree very much about, is that we'd get more freedom if we
>> were self-hosting fully. One always do.
>
> You primarily got more work to do.
Sure, of course.
Reply to: