OVH Public Cloud: new endpoints for Object Storage APIs

Support
1

Hi Evrybody,

It seems that OVH is changing its endpoints:

Dear customer,

Few weeks ago, we notified you by email[1] that we are switching to new endpoints on Object Storage APIs.
New URLs are already in production since mid-October 2019 and old ones will be shut off on February 18 2020.

You have to switch to new ones as soon as possible. This is a breaking change.

Here is the list of endpoints that will change:

   Previous One  --------->  New One

You can follow the status for this change: Public Cloud Status - Object Storage numbered endpoints

Thank you once again for choosing OVHcloud.

The Public Cloud Team

I would like to know if this affect Duplicati User using OVH Cloud storage V.2.0

Thank you.

2

Anyone has any idea?

Maybe updating Container Region from “UK1” to “UK”

3

If you’ll settle for “any idea” (asking OVH might be better), here are my thoughts and observations:

Display DNS cache on Windows can be used to see if it’s doing name lookups, and which version.

C:\>nslookup storage.uk1.cloud.ovh.net
Server:  dns.google
Address:  8.8.8.8

Non-authoritative answer:
Name:    storage.uk1.cloud.ovh.net
Addresses:  51.77.99.32
          51.77.97.0


C:\>nslookup storage.uk.cloud.ovh.net
Server:  dns.google
Address:  8.8.8.8

Non-authoritative answer:
Name:    storage.uk.cloud.ovh.net
Addresses:  51.77.99.32
          51.77.97.0


C:\>

show both names have the same IP (which isn’t true of all of their naming changes, but is for yours).

netstat or Sysinternals Process Explorer can show you what address or DNS name you’re talking to.

FS#40834 — global endpoints talks about steps of endpoint change, eventually making them visible.

OVH Community is not talking about this change at all. It might be more transparent than email says.

OpenStack Object Storage / Swift

--openstack-region (String) Supplies the region used for creating a container. This option is only used when creating a container, and is used to indicate where the container should be placed. Consult your provider for a list of valid regions, or leave empty for the default region.

The only hardcoded OVH name I could find in source code is https://auth.cloud.ovh.net/v2.0

Feel free to Export your configuration to see if you might have entered in some endpoint name earlier.

Keystone – OpenStack Identity Service seems to say the endpoint name is given to you from remote.

When a client communicates with the OpenStack environment that runs the OpenStack Identity service, it is this service that returns the endpoint URLs that the user can use in an OpenStack environment.

Access and Security in Horizon gives an Object Store URL starting with endpoint. What’s yours now? Perhaps you’re already migrated and using the new name.

4

As always, thanks @ts678 for your support and detailed answers.
I will have a look to Horizon to see if I am already migrated.

5

Hello,

Just to chime in: as said, simply updating Container Region (deleting the number at the end) did it for me.

I was on http://storage.sbg1.cloud.ovh.net and the new endpoint is http://storage.sbg.cloud.ovh.net
So I set the Container Region from SBG1 to SBG.

6

Also, FYI OVH is updating to Keystone v3, see this topic: OVH Public Cloud: new Keystone API

7

Thanks for the input. It’s nice to get some from an actual OVH user. What exactly does “did it” mean?

Things are still supposed to be working, the documentation (which may or may not be right) indicates Container Region is for initial creation only. I almost suggested changing it to some nonsense string to determine whether it makes any difference now, but that seemed like it might be inviting some trouble.

and what changed in terms of operation, or things that you can see on some OVH endpoint web page? While I’m not saying the change was harmful, I’m still curious whether it was proven to be necessary…

8

Sorry I wasn’t very clear.

By “did it”, I meant “allowed me to set the new endpoint and successfully connected to it”

So I think I’m set for the February 18th deadline when the other endpoints are stopped.

image

I’m not sure I understand your question. Nothing has changed much, the backup worked the same as before.

Regarding the “why did OVH did this”, I guess they want to rationalize their naming scheme. Before, it seems that each server farm got their own endpoints, even though they were on the same location (SBG1, SBG3, … (SBG being Strasboug, east of France) …). So it’s just a matter of simplifying the naming to avoid confusion (and potentially move people between farms more easily).

Note that it is all wild guess from my part :smiley_cat:

9

How can you tell what you connect to without some of the low-level tests I showed?
At least your endpoint actually changed address, so network-level tools may reveal:

C:\>nslookup storage.sbg1.cloud.ovh.net
Server:  dns.google
Address:  8.8.8.8

Non-authoritative answer:
Name:    storage.sbg1.cloud.ovh.net
Address:  217.182.130.166


C:\>nslookup storage.sbg.cloud.ovh.net
Server:  dns.google
Address:  8.8.8.8

Non-authoritative answer:
Name:    storage.sbg.cloud.ovh.net
Address:  54.38.230.76


C:\>

How do you know endpoint changed? My first guess was it’s done to you, and visible in OVH web UI.

Comment by OVH - Tuesday, 15 October 2019, 18:30PM
Global endpoints are created for object-store and identity but disabled, then not visible/accessible for now.

Comment by OVH - Tuesday, 15 October 2019, 18:35PM
Projects created before now are being assigned to global endpoints, by batches.

Comment by OVH - Wednesday, 16 October 2019, 15:24PM
Global endpoints for region SBG are now enabled.

10

Ah, you seem to be correct, I can see this in the OVH admin panel:

image
image772×98 12.2 KB

So I guess it’s a matter of knowing if your endpoint has actually migrated or not.