Device-registry merge into Director

[HeineVorsterDSA]

I would like to know how the merger of the Device-Registry into the Director affect running it with other components. Currently I am trying to run all of the OTA services together but by using the latest Director image that was built 5 months ago, I am getting the following error.

If I use an older image from before the point that the Device-Registry was merged into the Director, then this error does not occur, and the Director functions as expected.

@simao I am tagging you as I see you are quite responsive.

[simao]

Hi,
Looks like an error with the migration. Do you have the logs of when the migration was executed and failed?

It would help if you can provide the output of the following:

MariaDB [director_v2]> select * from schema_version;

mysqldump -u director_v2 -pdirector_v2 --no-data --databases director_v2 -h <your db host>

if you don't have the logs of the migration error, you could delete the migration row in schema_version and run the latest image again to see what error occurs.

[HeineVorsterDSA]

Hi,

I took a look at the database. There is no director_v2 database and only a director database.

The output of select * from schema_version; gave the following output;

I removed the version 9 migration and started the Director and its daemon again but got the same problem.
Here is the SQL dump as well.

sql_dump.txt

Also to add, here are the logs of the director container and director daemon container

director_daemon_logs.txt
director_logs.txt

[simao]

Ok that is strange, all the migrations were executed now? Are you starting from an empty database?

The logs you sent are after the migration already sent, can you send the log for director-daemon, after you delete the line for version nine from that table?

[HeineVorsterDSA]

I see the following in the director-daemon log now which is more telling

daemon_logs.txt

Seems to be a permissions issue?

[simao]

Yes unfortunately the migrations assume you were running device registry in the same database and director has access to it.

There are a few options here, but easiest would be to:

1. create a database named device_registry and give director access to it
2. Import this schema into that database: device-registy.sql.txt
3. delete that line from schema version and try again

This assumes all your databases are empty and you are just starting director fresh. Otherwise, if you need to migrate real data, you need to give director access to your device_registry database.

[HeineVorsterDSA]

I granted the necessary privileges for director on the device_registry database. But now the logs are complaining about the table device_registry.DeviceHibernationStatus not existing.

My question is, I am doing a brand new deployment of OTA with an empty database. Is it possible for me to skip the V9 migration step? If so, which of the migrations are important to execute for a fresh new deployment?

[simao]

I won't be near my laptop for a few days so I can't provide exact instructions, but yes this is possible. You need to initialize the director database and then initialize the schema table using flyway baseline. To get an empty schema ddl the easiest might be to run the tests and get the empty schema from the test database. Otherwise I can get an empty schema sometime next week. 10 Apr 2025 07:37:54 Heine Vorster ***@***.***>:

…

[Image]*HeineVorsterDSA* left a comment (uptane/director#250)[#250 (comment)] I granted the necessary privileges for director on the *device_registry* database. But now the logs are complaining about the table *device_registry.DeviceHibernationStatus* not existing. My question is, I am doing a brand new deployment of OTA with an empty database. Is it possible for me to skip the V9 migration step? IF show, which of the migrations are important to execute for a fresh new deployment? — Reply to this email directly, view it on GitHub[#250 (comment)], or unsubscribe[https://github.com/notifications/unsubscribe-auth/AABRWNZ3F6K63FBN2N7TQ3L2YYGUBAVCNFSM6AAAAAB2YBEKR2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDOOJRG4YDOMBXGY]. You are receiving this because you were mentioned.

[HeineVorsterDSA]

Do I still run the device_registry container and the device_registry-daemon or only the director and director-daemon?

If the device_registry container is not needed anymore, how does that affect the campaigner? Because the Campaigner container communicates with the device_registry container?

[simao]

Hi, Ah yes, if you could run device registry before upgrading that would fix it :) No, you don't need to run device registry anymore since the upgrade. That functionality is now included in director 10 Apr 2025 13:35:44 Heine Vorster ***@***.***>:

…

[Image]*HeineVorsterDSA* left a comment (uptane/director#250)[#250 (comment)] Do I still run the device_registry container and the device_registry-daemon or only the director and director-daemon? — Reply to this email directly, view it on GitHub[#250 (comment)], or unsubscribe[https://github.com/notifications/unsubscribe-auth/AABRWN7PUZUQQDOHKRSQ2IT2YZJQ5AVCNFSM6AAAAAB2YBEKR2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDOOJSGQ2DQNZYGI]. You are receiving this because you were mentioned.

[HeineVorsterDSA]

Hi,

I will try that, thank you.

For the Campaigner, do I set the DEVICE_REGISTRY_HOST and DEVICE_REGISTRY_PORT empty?

ats.campaigner = { 
    http.client = {
        deviceRegistry = {
             host = "localhost"
             host = ${?DEVICE_REGISTRY_HOST}
             port = 8083
             port = ${?DEVICE_REGISTRY_PORT}
             uri = "http://"${ats.campaigner.http.client.deviceRegistry.host}":"${ats.campaigner.http.client.deviceRegistry.port}
        }  
    }
}

Because if device registry is not running anymore, how will the campaigner communicate?

[simao]

Campaigner is deprecated and is no longer supported. Fleet/device group functionality is supported in director now. Not all campaign functionality is supported yet though. 11 Apr 2025 09:31:48 Heine Vorster ***@***.***>:

…

[Image]*HeineVorsterDSA* left a comment (uptane/director#250)[#250 (comment)] Hi, I will try that, thank you. For the Campaigner, do I set the *DEVICE_REGISTRY_HOST* and *DEVICE_REGISTRY_PORT* empty? *ats.campaigner = { http.client = { deviceRegistry = { host = "localhost" host = ${?DEVICE_REGISTRY_HOST} port = 8083 port = ${?DEVICE_REGISTRY_PORT} uri = "http://"${ats.campaigner.http.client.deviceRegistry.host}":"${ats.campaigner.http.client.deviceRegistry.port} } } } * Because if device registry is not running anymore, how will the campaigner communicate? — Reply to this email directly, view it on GitHub[#250 (comment)], or unsubscribe[https://github.com/notifications/unsubscribe-auth/AABRWN6RDQGMLLBEOCRQPBT2Y5VWFAVCNFSM6AAAAAB2YBEKR2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDOOJWGA4DMNJYHE]. You are receiving this because you were mentioned.

[HeineVorsterDSA]

I see now, that makes sense.

Thank you for all your help.