New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

remote rock-on info not updating deprecated volumes #1294

Closed
phillxnet opened this Issue Apr 26, 2016 · 8 comments

Comments

Projects
None yet
2 participants
@phillxnet
Member

phillxnet commented Apr 26, 2016

A system that had previously retrieved the older version of the plex rock-on had plex installed and then un-installed still shows the older plex config volume options, ie transcode share is requested. This share is not present in the new plex.json rock-on definition. This persists after deleting and recreating the rock-ons-root and repeated used of the Update button / browser refresh and rebooting. The system still prompts for the older plex info, ie the transcode share.
I have confirmed that the url is correct and that the new definitions are available via the generated url's.

[26/Apr/2016 17:08:47] DEBUG [storageadmin.views.rockon:361] we are looking to retrieve the following url =http://rockstor.com/rockons/plex.json
[26/Apr/2016 17:08:48] DEBUG [storageadmin.views.rockon:365] this is the json retrieved <Response [200]>

This was observed in a system updated to 3.8-13.03.

phillxnet added a commit to phillxnet/rockstor-core that referenced this issue Apr 26, 2016

@phillxnet

This comment has been minimized.

Member

phillxnet commented Apr 26, 2016

Had a quick look and can't see what's causing this:-
@schakrava Could the following commit be throwing things off, don't quite see it myself:
f8f1251

@phillxnet

This comment has been minimized.

Member

phillxnet commented May 3, 2016

I see this also in 3.8-13.07, any workaround for the time being as haven't yet worked out how to fix it.
Plex install still asks for the transcoding directory!! Seems to be ignoring the rockstor-registry changes. Pointers on where else to look maybe.

@phillxnet

This comment has been minimized.

Member

phillxnet commented May 4, 2016

Posting as I've just check it.
SELECT id, name, state, status FROM storageadmin_rockon WHERE name = 'Plex';

 id | name |   state   | status  
----+------+-----------+---------
  3 | Plex | available | stopped
(1 row)

State and status are the same as all the other rockons which are also not installed.

phillxnet added a commit to phillxnet/rockstor-core that referenced this issue May 4, 2016

@phillxnet

This comment has been minimized.

Member

phillxnet commented May 4, 2016

Looks like storageadmin_dvolume still contains the db entry for /transcode
So we are updating the same info as the existing db entries I think but are failing to remove previous entries; such as this old volume reference which only existed on a previous plex rock-on definition. But these old references are being associated with the updated rock-on data, presumably where they are not overwritten.

phillxnet added a commit to phillxnet/rockstor-core that referenced this issue May 4, 2016

log currently known volumes rockstor#1294
These are volumes that have been previously associated
with rock-ons / containers.

phillxnet added a commit to phillxnet/rockstor-core that referenced this issue May 4, 2016

log retrieved rock-on volume data rockstor#1294
The vol info gained via update mechanism.
@phillxnet

This comment has been minimized.

Member

phillxnet commented May 4, 2016

So we read the updated info correctly and have the previous info to compare against.

- container description volumes = {u'/config': {u'description': u'Choose a Share for Plex configuration. Eg: create a Share called plex-config for this purpose alone.', u'label': u'Config Storage'}, u'/data': {u'description': u'Choose a Share for Plex content(your media). Eg: create a Share called plex-data for this purpose alone. You can also assign other media Shares on the system after installation.', u'label': u'Data Storage'}}
- cur_vols _create_update_meta = [u'/config', u'/transcode', u'/data']

and with listing just the indecies for volumes in container description:

- container description volumes = [u'/config', u'/data']
- cur_vols _create_update_meta = [u'/config', u'/data', u'/transcode']

phillxnet added a commit to phillxnet/rockstor-core that referenced this issue May 4, 2016

phillxnet added a commit to phillxnet/rockstor-core that referenced this issue May 6, 2016

improve volume info update for rock-ons rockstor#1294
When we refresh Rock-on info make sure to re-sync
volume info in the case of deprecated volumes. Ie
for non installed Rock-ons account for newer rock-on
definitions that have fewer volume requirements.

@phillxnet phillxnet changed the title from remote rock-on info not updated to remote rock-on info not updating deprecated volumes May 6, 2016

@phillxnet

This comment has been minimized.

Member

phillxnet commented May 6, 2016

dealing with updating ovpn-data
[06/May/2016 19:56:38] DEBUG [storageadmin.views.rockon:250] container description volumes = []
[06/May/2016 19:56:38] DEBUG [storageadmin.views.rockon:251] cur_vols _create_update_meta = []
[06/May/2016 19:56:38] DEBUG [storageadmin.views.rockon:249] dealing with updating openvpn
[06/May/2016 19:56:38] DEBUG [storageadmin.views.rockon:250] container description volumes = []
[06/May/2016 19:56:38] DEBUG [storageadmin.views.rockon:251] cur_vols _create_update_meta = []
Noting potential db anomaly indicated by the above logging to data.
ie I don't see what this ovpn-data container is. However I don't think this is related to this issue.

Anomaly now understood as multiple containers in a single rock-on definition, each with potential volumes entries, but in this case no volumes entries for either container.

@phillxnet

This comment has been minimized.

Member

phillxnet commented May 6, 2016

Currently testing prior to submitting pr.

phillxnet added a commit to phillxnet/rockstor-core that referenced this issue May 7, 2016

phillxnet added a commit to phillxnet/rockstor-core that referenced this issue May 8, 2016

correct logical error on removing mdraid member role rockstor#1294
Previously we only alterred the mdraid member flag to a disks role
when it's fstype, as reported by scan_disks, indicated the need.
However this was done within a conditional that precluded
examining a 'None' fstype which is what scan_disks translates an
empty string into. Hence we never updated a role db entry for a
previous mdraid member once that member no longer returned an
fstype. Resolved by moving the role label logic outside the
previous conditional such that it now applies to all disks even if
they return no fstype from scan_disks.
Also added debug logging to help test this new arrangement.
@phillxnet

This comment has been minimized.

Member

phillxnet commented May 8, 2016

above "correct logical error on removing mdraid member role #1294" linked to this issue in error.

schakrava added a commit that referenced this issue May 11, 2016

Merge pull request #1309 from phillxnet/1294_remote_rock-on_info_not_…
…updated

remote rock-on info not updating deprecated volumes. Fixes #1294

@schakrava schakrava added the bug label Jun 17, 2016

@schakrava schakrava added this to the Looney Bean milestone Jun 17, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment