
Repos are disappearing from Gitlab - kaishiro
https://gitlab.com/gitlab-com/support-forum/issues/2320
======
mrmondo
Title reads as clickbait, while repos didn’t appear due to the caching issue
it was quickly resolved and they didn’t disappear and it isn’t still
happening.

------
hardwaresofton
Disclaimer: I don't work for Gitlab.

The problem seems to be resolved now, seems like a problem with invalidated
cache on a heavily loaded server ( official tweet:
[https://twitter.com/gitlabstatus/status/897375110205722624](https://twitter.com/gitlabstatus/status/897375110205722624))
-- not data destruction.

Gitlab Issue: [https://gitlab.com/gitlab-com/support-
forum/issues/2320](https://gitlab.com/gitlab-com/support-forum/issues/2320)

------
laumars
I really really want to like Gitlab, I love their openness and I love having
the competition with Github. But it seems like every 6 months they have an
issue of some description.

It's unfortunate the expectations we place on cloud providers but my clients
have similar expectations from me so I need to work with providers that can
assure me they can offer the kind of uptime I'm expected to provide. Plus the
modern way of pipelining code means git is seldom a static silo like it once
was which only compounds things when one of your links in the chain has
multiple glitches a year.

edit:

I thought I would get downvoted into oblivion for this but I felt it was a
discussion worth having since they relate directly to my experiences with
working at scale. So I "took one for the team" \- so to speak.

Anyhow to answer a few points:

* Yes I'm aware git is a distributed VCS but like I said, git is seldom a silo so you'd need to reconfigure your pipeline to point to the new git origin or have your pipeline already configured to accept fallback systems. Quickly your configuration spirals in complexity.

* Yes I'm also aware you can self host. This is actually what we did do before moving to a cloud hosted solution. This added complications with our AWS pipelining. Problems that were solvable but again, with additional complexity compared with cloud hosted solutions.

At the end of the day all problems can be addressed with enough time and
resources however the reason people typically opt for hosted solutions is to
reduce complexity not increase it.

~~~
amelius
But git is a decentralized system/protocol, so in theory if Gitlab is down,
you could very easily resort to using a different origin.

~~~
laumars
In theory yes. But in practice it's not quite so straightforward. If you're
working to tight deadlines then having to reconfigure your pipeline because of
an outage is both scary and a huge pain in the arse.

The reason people opt for cloud solutions is to decrease complexity, not
increase it. So if I'm having to run multiple git origins then I would be
better off self hosting and just moving those complexities in house.

~~~
jacquesm
That's exactly why you can run your own gitlab instance. The thing to do when
you don't want dependencies is to reduce your dependencies, not complain about
a third party service that offers their software for free so you can run it
yourself.

~~~
laumars
> _That 's exactly why you can run your own gitlab instance._

You're oversimplifying things there. It's not just about the physical instance
- I could just run git "naked" without Gitlab's tooling if it were just an
issue of installing Git. The complexities arise when you then need to have Git
exposed to the internet to allow AWS pipelining to operate. We then have
gateway into your internal network that needs to be PCI-compliant (for our
retail sites), audited by the Gambling Commission (for our online games) and
ISO nnnn (I forget what standard we meet off hand).

It's fair that most organisations might not have these hoops to jump through,
but we do and hence why we migrated to hosted providers to remove some of our
complexity.

> * The thing to do when you don't want dependencies is to reduce your
> dependencies, not complain about a third party service that offers their
> software for free so you can run it yourself.*

I think this is grossly unfair. For starters I'm not complaining about Gitlab,
I was opening a discussion about them. You might disagree with my points and I
welcome your opinion - otherwise it would be a dull and pointless discussion.
:)

Secondly your point about "The thing to do when you don't want dependencies is
to reduce your dependencies" is entirely the point I'm making. Perhaps you've
missed some of the issues I've raised or perhaps I've explained myself badly.
But I have explored a number of options and not just blindly talking out of my
arse (which I appreciate there's no way for you to know this given the
anonymous nature of the internet).

Lastly why would I be only interested in free solutions given the expectations
I have? Currently we do pay for our Git hosting because of our requirements -
and my expectations include paying a fee for a service if it solves a few
problems. After all we are talking about enterprise systems - any reasonable
costs are consolidated and billed back to the client.

~~~
jacquesm
> I think this is grossly unfair.

No, I think you are grossly unfair. You write that you 'really, really want to
like gitlab', harp on them having 'issues every few months' (as if there is
any online service that does not have issues every few months, and which blows
this particular issue up to a magnitude it does not deserve) and then present
a use-case that gitlab offers the perfect solution for, which you reject for
reasons all your own.

Sounds to me like you are making a problem rather than using tools in the ways
they are intended. Whether the solution is paid or not is not the relevant
bit, the relevant bit is that you have the option to self-host which you do
not with gitlab's main competitors.

Your AWS complexities are not gitlab's problem, they are yours.

~~~
laumars
Like I said before, we were already self hosting (albeit not with Gitlab's
tooling) before moving to a hosted solution. If it were as easy as you claim
it to be then we would never have switched aware from self hosting. I am a
control freak so I actually prefer self hosting myself. But it was steadily
becoming impractical.

I apologize if I've badly explained the problems we encountered. But please
don't assume I'm some idiot who doesn't know what I'm doing just because your
business has it's own different set of requirements than ours.

> "Your AWS complexities are not gitlab's problem, they are yours.*

I'm not blaming Gitlab. I'm saying AWS complexities make some solutions
infeasible. I also said some of the compliance regulations we adhere to also
add complexities that make some solutions less practical. I really don't
understand why are you being so abrasive about this.

~~~
jacquesm
Because your initial comment pans gitlab quite extensively without them
necessarily being the party that deserves your scorn.

~~~
laumars
> _Because your initial comment pans gitlab quite extensively_

I said they have 2 issues arise a year (which, by the way, was already counter
argued before you joined the thread). I did also compliment 2 other aspects of
their business. So to say my "initial comment pans gitlab quite extensively"
and "your scorn" is needlessly sensationalising things.

We are all professionals so can we please have a grounded discussion?

~~~
jacquesm
> which, by the way, was already counter argued before you joined the thread

I tend to open a bunch of tabs and go through them one-by-one so apologies for
the duplicates.

> I did also compliment 2 other aspects of their business.

The proper description of that is 'damning with faint praise', of which your
comment is an excellent example.

> So to say my "initial comment pans gitlab quite extensively" and "your
> scorn" is needlessly sensationalising things.

No, I think it is a quite accurate description of your comment. Whether you
agree with that or not is up to you, but just take the fact that I read it as
such as a datapoint.

> We are all professionals so can we please have a grounded discussion?

That's an assumption that I won't comment on.

------
DiabloD3
Official response:
[https://twitter.com/gitlabstatus/status/897375110205722624](https://twitter.com/gitlabstatus/status/897375110205722624)

------
cottsak
Resolved
[https://twitter.com/gitlabstatus/status/897382564020793345](https://twitter.com/gitlabstatus/status/897382564020793345)

------
OskarS
And now gitlab.com returns 403 forbidden for me. Wonderful!

~~~
cmatija
Sorry about that. Could you provide more context about it? We'd love to help.

Are you already logged in when that happens to you? If so, you should open an
issue in [https://gitlab.com/gitlab-com/support-
forum/issues](https://gitlab.com/gitlab-com/support-forum/issues) with as much
info as possible so we can look into it.

If you're getting that when you're trying to log-in, then you're having
trouble accessing your GitLab.com account, with which our support team can
help you - [https://support.gitlab.com](https://support.gitlab.com)

