Constant instability, Service unavailable errors, System cannot find the file specified.

[lynkz-matt-psaltis]

I'm trying to work out if this is specifically related to our machines, our setup using podman desktop or something else I haven't put my finger on.

Essentially how stable is everyone finding the Linux container for the CosmosDb emulator? We're finding this causing daily impacts at the moment for team members. The windows emulator (non-container) seems to work much more consistently

It doesn't seem to be resources related (cpu/ram) are all in abundance and we're seeing this across a wide range of different hardware vendors.

I realise technical information is light on here and I will gather that, just trying to gauge if other people are pushing through the pain so to speak with this?

[razvangoga]

on what distribution are you? it has a known issue on ubuntu > 18

in general is, sadly, a buggy unmaintained mess... there is this issue rounding up all theproblems https://github.com/Azure/azure-cosmos-db-emulator-docker/issues/86

[lynkz-matt-psaltis]

Thanks @razvangoga seems like a lot of issues we've experienced recently.

[lynkz-matt-psaltis]

Hosts are Windows 11 with WSL2 or Mac OS running podman desktop. Did you mean host distribution or cosmosdb docker image? I wasn't aware there are published images on top of other distributions for the docker image?

[razvangoga]

I've tried to use it on

• Win11 via Docker Desktop on WSL => usable but it's slow and sometimes unstable),
• MacOS on an M1 Pro via Docker Desktop : container starts ok but seems stuck on an internal starting loop => unusable
• Ubunutu 22 in an Azure Devops pipeline via Docker : container is unreachable => unusable

have not tried Podman, but i wouldn't put money on it working...

:(

[jahmai-ca]

I'm also struggling with the Linux container mostly in Azure devops pipelines on Ubuntu. I've been able to connect to it if I set the environment variable AZURE_COSMOS_EMULATOR_IP_ADDRESS_OVERRIDE=127.0.0.1 on the container definition, but it's still slow and gives random service unavailable and request timeouts making the pipeline job get killed at the 60 minute mark.

[adamzest]

I'm trying to work out if this is specifically related to our machines, our setup using podman desktop or something else I haven't put my finger on.

Essentially how stable is everyone finding the Linux container for the CosmosDb emulator? We're finding this causing daily impacts at the moment for team members. The windows emulator (non-container) seems to work much more consistently

It doesn't seem to be resources related (cpu/ram) are all in abundance and we're seeing this across a wide range of different hardware vendors.

I realise technical information is light on here and I will gather that, just trying to gauge if other people are pushing through the pain so to speak with this?

yes - its massively unreliable (on Ubuntu devops build agent). A bunch of our unit tests randomly fail with things like this.

Microsoft.Azure.Cosmos.CosmosException : Response status code does not indicate success: NotFound (404); Substatus: 1013; ActivityId: 7e4d51b2-94be-4721-9ae1-beb0128dbcba; Reason: ( code : NotFound message : Collection is not yet available for read. Please retry in some time. ActivityId: 7e4d51b2-94be-4721-9ae1-beb0128dbcba, Microsoft.Azure.Documents.Common/2.14.0 );

[pvpmartins]

forget it man... basically all issues here are related to this. the azure team simply will not fix it

[raghuAtRA]

There is general apathy and near zero development on the emulator.

Issues languish wtihout any response & updates are rarely provided; We kept getting told that updates are in the offing but no new releases or even an ETA for any fixes. And no amount of nudges/pushes (public or private) seem to have any effect.

I have stopped recommending cosmos because DX is definitely not a priority. This repo is nothing but window dressing

[lynkz-matt-psaltis]

Yeah we've just finished migrating to Postgres because of this. CI/CD testing is possible again. Container startups < 15seconds Everything's better and when YugabyteDb's PG uplift is ready, we'll have a cloud agnostic approach. Good luck out there Tech leads and Architects. This one I'll chalk up to a costly mistake and good lessoned learned.

[diegosasw]

Microsoft/Azure does not want to invest in creating/maintaining docker images of their services. That's why there is no image available for Azure Service Bus and that's why the CosmosDB emulator image is unreliable and abandoned.

Good luck out there Tech leads and Architects. This one I'll chalk up to a costly mistake and good lessoned learned.

PS: There is a new preview of docker image for linux, but it's far from being enough, as it does not support basic things such as Change Feed https://learn.microsoft.com/en-us/azure/cosmos-db/emulator-linux

[jaydavid]

+1

We've already got Azure infrastructure and pipelines set up, so using those resources makes sense for us, but as far as development goes it's a real pain.

Service Bus recently got a local emulator, finally, and I was excited to be able to just take that, cosmosDB, azurite, etc... and place them all into a docker compose to simplify the dev process.

Started off great, but we're pretty consistently hitting issues now. There really has to be a reliable offline dev setup, I don't find it feasible to have every dev point to their own Cosmos DB, Service Bus, Blob Storage etc...