[WOK RFC] Update objectstore information while migrating to new structure.
Hello guys. Doing some tests in the new Wok and Kimchi (as plugin) code I discovered something that can cause some issues for us. Let'me show a possible user case to explain better: The user uses some version of the current Kimchi (previous of 1.5.1 and called for now as, Kimchi_old) totally functional and operating. The user has a few templates created, which are stored in the the objectstore function of Kimchi, and for each template has the storagepool URI allocated for that template. The storagepool information has the following properties in Kimchi-old: "storagepool": { "description": "Location of the storage pool", "type": "string", "pattern": "^/storagepools/[^/]+/?$", "error": "KCHTMPL0015E" } However, the new Wok+Kimchi_plugin structure changed the URI for all virtualization features and the pattern now is: "^/plugins/kimchi/storagepools/[^/]+/?$" There's an issue when getting the information of all Kimchi-old templates from the objectstore, the URI information continues with the older pattern and some checks in the code will fail. My suggestion is to create an info-update process when the user upgrade from Kimchi-old to Wok+Kimchi_plugin, modifying the storagepool information of all templates that not follow the new pattern in the database already created. I'd like to know what do you guys think about and ask for more suggestions also. Best regards, -- Paulo Ricardo Paz Vital <pvital@linux.vnet.ibm.com> IBM Linux Technology Center
Hi Paulo, Good catch! I also found a similar issue related to the virtual machines. We currently save the OS icon for each guest in the objectstore. Originally, it refereed to /images/icon-<os>.png and this path changed in the wok+kimchi infrastructure to /plugins/kimchi/images/icon-<os>.png So while loading the the guests tab a lot of JS errors are displayed because /images/icon-<os>.png returns 404. I liked your idea and we could do it on RPM/DEB post installation, but in this case, users running from local source would not be able to get the database updated. So probably, on Kimchi starting up would be better. We just need to make sure the code would run once to update the database. For that we can add a tag to the database to identified it is already updated or not. Regards, Aline Manera On 22/09/2015 18:38, Paulo Ricardo Paz Vital wrote:
Hello guys.
Doing some tests in the new Wok and Kimchi (as plugin) code I discovered something that can cause some issues for us. Let'me show a possible user case to explain better:
The user uses some version of the current Kimchi (previous of 1.5.1 and called for now as, Kimchi_old) totally functional and operating. The user has a few templates created, which are stored in the the objectstore function of Kimchi, and for each template has the storagepool URI allocated for that template.
The storagepool information has the following properties in Kimchi-old:
"storagepool": { "description": "Location of the storage pool", "type": "string", "pattern": "^/storagepools/[^/]+/?$", "error": "KCHTMPL0015E" }
However, the new Wok+Kimchi_plugin structure changed the URI for all virtualization features and the pattern now is:
"^/plugins/kimchi/storagepools/[^/]+/?$"
There's an issue when getting the information of all Kimchi-old templates from the objectstore, the URI information continues with the older pattern and some checks in the code will fail.
My suggestion is to create an info-update process when the user upgrade from Kimchi-old to Wok+Kimchi_plugin, modifying the storagepool information of all templates that not follow the new pattern in the database already created.
I'd like to know what do you guys think about and ask for more suggestions also.
Best regards,
On Tue, 2015-09-29 at 11:37 -0300, Aline Manera wrote:
Hi Paulo,
Good catch!
I also found a similar issue related to the virtual machines. We currently save the OS icon for each guest in the objectstore. Originally, it refereed to /images/icon-<os>.png and this path changed in the wok+kimchi infrastructure to /plugins/kimchi/images/icon -<os>.png So while loading the the guests tab a lot of JS errors are displayed because /images/icon-<os>.png returns 404.
Hum! That explain why I'm not seeing the distros logos anymore :-P
I liked your idea and we could do it on RPM/DEB post installation, but in this case, users running from local source would not be able to get the database updated. So probably, on Kimchi starting up would be better. We just need to make sure the code would run once to update the database. For that we can add a tag to the database to identified it is already updated or not.
Yeah, the idea is to execute it once when Wok with Kimchi as plugin start up. The idea of tag is nice, and it's similar to what I was planning to do. May be we can store the version of the database (same version of the Kimchi running) and then it's executed only once.
Regards, Aline Manera
On 22/09/2015 18:38, Paulo Ricardo Paz Vital wrote:
Hello guys.
Doing some tests in the new Wok and Kimchi (as plugin) code I discovered something that can cause some issues for us. Let'me show a possible user case to explain better:
The user uses some version of the current Kimchi (previous of 1.5.1 and called for now as, Kimchi_old) totally functional and operating. The user has a few templates created, which are stored in the the objectstore function of Kimchi, and for each template has the storagepool URI allocated for that template.
The storagepool information has the following properties in Kimchi -old:
"storagepool": { "description": "Location of the storage pool", "type": "string", "pattern": "^/storagepools/[^/]+/?$", "error": "KCHTMPL0015E" }
However, the new Wok+Kimchi_plugin structure changed the URI for all virtualization features and the pattern now is:
"^/plugins/kimchi/storagepools/[^/]+/?$"
There's an issue when getting the information of all Kimchi-old templates from the objectstore, the URI information continues with the older pattern and some checks in the code will fail.
My suggestion is to create an info-update process when the user upgrade from Kimchi-old to Wok+Kimchi_plugin, modifying the storagepool information of all templates that not follow the new pattern in the database already created.
I'd like to know what do you guys think about and ask for more suggestions also.
Best regards,
On 29/09/2015 11:52, Paulo Ricardo Paz Vital wrote:
On Tue, 2015-09-29 at 11:37 -0300, Aline Manera wrote:
Hi Paulo,
Good catch!
I also found a similar issue related to the virtual machines. We currently save the OS icon for each guest in the objectstore. Originally, it refereed to /images/icon-<os>.png and this path changed in the wok+kimchi infrastructure to /plugins/kimchi/images/icon -<os>.png So while loading the the guests tab a lot of JS errors are displayed because /images/icon-<os>.png returns 404. Hum! That explain why I'm not seeing the distros logos anymore :-P
I liked your idea and we could do it on RPM/DEB post installation, but in this case, users running from local source would not be able to get the database updated. So probably, on Kimchi starting up would be better. We just need to make sure the code would run once to update the database. For that we can add a tag to the database to identified it is already updated or not.
Yeah, the idea is to execute it once when Wok with Kimchi as plugin start up. The idea of tag is nice, and it's similar to what I was planning to do. May be we can store the version of the database (same version of the Kimchi running) and then it's executed only once.
+1 for the version in the DB (version > 1.5.1 will have the new API structure)
Regards, Aline Manera
On 22/09/2015 18:38, Paulo Ricardo Paz Vital wrote:
Hello guys.
Doing some tests in the new Wok and Kimchi (as plugin) code I discovered something that can cause some issues for us. Let'me show a possible user case to explain better:
The user uses some version of the current Kimchi (previous of 1.5.1 and called for now as, Kimchi_old) totally functional and operating. The user has a few templates created, which are stored in the the objectstore function of Kimchi, and for each template has the storagepool URI allocated for that template.
The storagepool information has the following properties in Kimchi -old:
"storagepool": { "description": "Location of the storage pool", "type": "string", "pattern": "^/storagepools/[^/]+/?$", "error": "KCHTMPL0015E" }
However, the new Wok+Kimchi_plugin structure changed the URI for all virtualization features and the pattern now is:
"^/plugins/kimchi/storagepools/[^/]+/?$"
There's an issue when getting the information of all Kimchi-old templates from the objectstore, the URI information continues with the older pattern and some checks in the code will fail.
My suggestion is to create an info-update process when the user upgrade from Kimchi-old to Wok+Kimchi_plugin, modifying the storagepool information of all templates that not follow the new pattern in the database already created.
I'd like to know what do you guys think about and ask for more suggestions also.
Best regards,
On 29-09-2015 13:36, Aline Manera wrote:
On 29/09/2015 11:52, Paulo Ricardo Paz Vital wrote:
On Tue, 2015-09-29 at 11:37 -0300, Aline Manera wrote:
Hi Paulo,
Good catch!
I also found a similar issue related to the virtual machines. We currently save the OS icon for each guest in the objectstore. Originally, it refereed to /images/icon-<os>.png and this path changed in the wok+kimchi infrastructure to /plugins/kimchi/images/icon -<os>.png So while loading the the guests tab a lot of JS errors are displayed because /images/icon-<os>.png returns 404. Hum! That explain why I'm not seeing the distros logos anymore :-P
I liked your idea and we could do it on RPM/DEB post installation, but in this case, users running from local source would not be able to get the database updated. So probably, on Kimchi starting up would be better. We just need to make sure the code would run once to update the database. For that we can add a tag to the database to identified it is already updated or not.
Yeah, the idea is to execute it once when Wok with Kimchi as plugin start up. The idea of tag is nice, and it's similar to what I was planning to do. May be we can store the version of the database (same version of the Kimchi running) and then it's executed only once.
+1 for the version in the DB (version > 1.5.1 will have the new API structure)
When my patch ML "[Kimchi-devel] [PATCH] Fix issue #738 - Split Wok and Kimchi object stores" is accepted, there will be an additional requirement here: - Split object store contents between Wok and Kimchi. Wok uses its objstore to store async tasks, which perhaps is not important for this migration script. There may be other Wok uses which need to be investigated. -- Lucio Correia Software Engineer IBM LTC Brazil
On Tue, 2015-10-13 at 19:02 -0300, Lucio Correia wrote:
On 29-09-2015 13:36, Aline Manera wrote:
On 29/09/2015 11:52, Paulo Ricardo Paz Vital wrote:
On Tue, 2015-09-29 at 11:37 -0300, Aline Manera wrote:
Hi Paulo,
Good catch!
I also found a similar issue related to the virtual machines. We currently save the OS icon for each guest in the objectstore. Originally, it refereed to /images/icon-<os>.png and this path changed in the wok+kimchi infrastructure to /plugins/kimchi/images/icon -<os>.png So while loading the the guests tab a lot of JS errors are displayed because /images/icon-<os>.png returns 404. Hum! That explain why I'm not seeing the distros logos anymore : -P
I liked your idea and we could do it on RPM/DEB post installation, but in this case, users running from local source would not be able to get the database updated. So probably, on Kimchi starting up would be better. We just need to make sure the code would run once to update the database. For that we can add a tag to the database to identified it is already updated or not.
Yeah, the idea is to execute it once when Wok with Kimchi as plugin start up. The idea of tag is nice, and it's similar to what I was planning to do. May be we can store the version of the database (same version of the Kimchi running) and then it's executed only once.
+1 for the version in the DB (version > 1.5.1 will have the new API structure)
When my patch ML "[Kimchi-devel] [PATCH] Fix issue #738 - Split Wok and Kimchi object stores" is accepted, there will be an additional requirement here:
- Split object store contents between Wok and Kimchi. Wok uses its objstore to store async tasks, which perhaps is not important for this migration script. There may be other Wok uses which need to be investigated.
Got it! I'm finishing the changes into objectstore update to support the versioning information and the migration script and can submit this new request in the same patch-set.
participants (3)
-
Aline Manera -
Lucio Correia -
Paulo Ricardo Paz Vital