After upgrading to v1.0.2 I cannot access the “settings” page, it just comes up blank, and this error is in the console -
Uncaught TypeError: Cannot read property 'split' of null machinedriver.js:15
After upgrading to v1.0.2 I cannot access the “settings” page, it just comes up blank, and this error is in the console -
Uncaught TypeError: Cannot read property 'split' of null machinedriver.js:15
This is fixed in master for 1.1 already but it’s dying because the uri
for a driver is null instead of a string. You should be able to
/v1/machinedrivers
uri: null
and click the ID to go to the individual driverI think i’m following, but the last step is unclear. Here is the aws driver -
{ "id": "1md3", "type": "machineDriver", "links": { "self": "…/v1/machinedrivers/1md3", }, "actions": { "remove": "…/v1/machinedrivers/1md3/?action=remove", "retry": "…/v1/machinedrivers/1md3/?action=retry", }, "name": "amazonec2", "state": "error", "accountId": null, "created": "2016-05-27T02:51:13Z", "createdTS": 1464317473000, "data": { "fields": { "builtin": true, "checksum": "", "url": "local://", "defaultActive": false, "errorMessage": "open /tmp/gms-930837763/: is a directory", }, }, "description": null, "errorMessage": "open /tmp/gms-930837763/: is a directory", "kind": "machineDriver", "md5checksum": null, "removeTime": null, "removed": null, "transitioning": "no", "transitioningMessage": null, "transitioningProgress": null, "uiUrl": null, "uri": null, "uuid": "39106401", }
The last step says to “click the edit button” to change the uri, but i don’t see that, I have this -
Did you upgrade to v1.1-dev2
(or latest
) and then go back to 1.0.x
? That JSON contains fields that were added in v1.1-dev2
, and an entry for amazonec2
shouldn’t exist at all in versions before then.
In 1.0.x
the drivers aren’t editable yet, so scratch what I said about editing; You can delete any that are in state: error
though with the blue Delete button.
Yes, I had mistakenly pulled rancher/latest
instead of rancher/latest:stable
. It seems backwards to me that the generic tag latest
pulls the dev release, yet I have to specify a tag for the main release?
IMO, a tag as generic as latest
should always default to the stable release, if people want the latest dev release, that is when you should be required to specify rancher/latest:dev
or rancher/1.1.0-dev3
Is there anything else i’ll need to be aware of from the inadvertent startup of the dev container?
stable
is the newest stable release, by which we mean we provide support for it to customers. It will change on the order of quarterly, except for bug-fixes as needed. (1.1 being mid-June)
We did weekly(-ish) releases before 1.0 and continue to do that (probably bi-weekly to monthly) for open-source users. These are still QA-ed and what we want typical people using. For one because it gets more eyes on new things, but mainly because people go to meetups, see articles, etc, that are always showing features that aren’t in stable
yet. That’s why it’s tagged latest
.
We will be changing the naming scheme after 1.1 though as -devX
was not a great choice.
Ok… probably the best thing to do at this point is empty out that table in the database; If you’re using the built-in database you can do
docker run -it <id of rancher/server container> mysql cattle
and then run
DELETE FROM machinedriver;
Then restart the rancher/server container.
My DB is an AWS RDS instance, i connected to the db from Navicat, looks like the table is called machine_driver
, shall I just delete those entries and bounce the container?
Yes, since it’s an external DB you can actually stop the container first, then delete the rows, then start it back up again
Thanks, all good now.