I agree that would be a bug Ivan, but please try to confirm what happened actually through logs ?
Now that I checked, I do recall one similar case actually, where template seems to be present physically on storage (images itself that is - can you also confirm your templates are present on SS, beside template.properties being nulled ???) - and also template is present in template_zone_ref. Can you please do the check above ? I'm wondering what else you might be missing (if anything) in DB or on SS filesystem, beside the row in the template_store_ref. On Mon, 15 Apr 2019 at 18:38, Ivan Kudryavtsev <[email protected]> wrote: > Well, we don't remove templates usually, just rename them and reset public, > featured flags. > > I'll check, but suppose, that template api removal call shouldn't produce > the case like this? How this could be achieved thru API, when storage_ref > is removed, but template is in place? > > The records for certain templates are absent in template_store_ref, while > others are just fine... it looks like a very serious bug for regular users, > who don't manage templates and ISO programmatically. > > пн, 15 апр. 2019 г., 12:21 Andrija Panic <[email protected]>: > > > Assuming it's not Assange :), perhaps check with teammates if any changes > > on these templates were done - are your records completely missing or > just > > altered in bad way ? > > > > Can you double check the API log for any delete template API calls ? > > > > > > On Mon, 15 Apr 2019 at 17:39, Ivan Kudryavtsev <[email protected] > > > > wrote: > > > > > Andrija, > > > > > > yes, I have the case with missing records in 'template_store_ref'. > What I > > > don't get is how it could happen... > > > > > > пн, 15 апр. 2019 г. в 11:24, Andrija Panic <[email protected]>: > > > > > > > Hi Ivan, > > > > > > > > is it possible that your DB got somehow corrupted or that you are > > missing > > > > records in template_store_ref etc - this might be the reason why > SSVM > > is > > > > trying to download templates again - if you check the logs for > > > > non-problematic templates, you will see something like "template > > already > > > on > > > > store this and that, no need to download again, skipping". For the > rest > > > > (which are considered not downloaded), it will try to download again > > from > > > > the URL in the main vm_template table. > > > > > > > > Can you also check for the records on the template_spool_ref (Primary > > > > Storage) - I assume these might be OK, ca you spin new VM from an > > > existing > > > > (problematic) template ? > > > > > > > > Behavior (from your second email) is expected - same kind of errors > you > > > > would get if you just added another Secondary Storage to your > > CloudStack > > > > setup, but original URL is unavailable (you could play with hacking > MD5 > > > in > > > > DB, but that is not a solution at all). > > > > > > > > As for the restoration of the template.properties - do you have a > > backup > > > ? > > > > > > > > Best, > > > > Andrija > > > > > > > > On Mon, 15 Apr 2019 at 16:26, Ivan Kudryavtsev < > > [email protected] > > > > > > > > wrote: > > > > > > > > > To follow up. When SSVM boots it tries to redownload all the > > templates > > > > from > > > > > original sources this leads to next oucomes: > > > > > - if the source is not available, the result is: > > > > > No route to host (Host unreachable) - If the template is changed on > > > > source: > > > > > then it leads to MD5 sum error. > > > > > > > > > > Any ideas, why SSVM tries to download all the templates on SSVM > > again? > > > > > Never seen that before. > > > > > > > > > > > > > > > пн, 15 апр. 2019 г. в 09:40, Ivan Kudryavtsev < > > > [email protected] > > > > >: > > > > > > > > > > > Hello, community. > > > > > > > > > > > > Today, We've met the problem with ACS SS, which looks like a > > critical > > > > > > error. In some point of time, new templates stopped to upload and > > the > > > > old > > > > > > ones were unable to be removed. > > > > > > > > > > > > After the SSVM recreation, I've met the situation when some > > templates > > > > are > > > > > > not activated and have their "template.properties" size set to 0. > > > > > > > > > > > > More to add, certain already working templates were tried to be > > > > > > redownloaded and got errors like: > > > > > > Failed post download script: checksum > > > > > > "{MD5}9f8c94ed7e4b19a78d4f0e3fc406d81b" didn't match the given > > value, > > > > > > "{MD5}7eed347f4cc7e66f55e4f668cd9a5151" > > > > > > I've checked the following: > > > > > > - no lack of spare space on SS; > > > > > > - no problems with management servers in the last months; > > > > > > - no problems with SSVM. > > > > > > > > > > > > It's ACS 4.11.2, all VMs are working, of course as templates are > > > copied > > > > > to > > > > > > primary, but we've lost almost half of the template repository. > > > > > > > > > > > > Is there a way to recreate "template.properties" from DB or > another > > > > > > approach? All the templates are still in place, but they are not > > > > > activated > > > > > > upon SSVM start. > > > > > > > > > > > > Many thanks. > > > > > > > > > > > > > > > > > > -- > > > > > > With best regards, Ivan Kudryavtsev > > > > > > Bitworks LLC > > > > > > Cell RU: +7-923-414-1515 > > > > > > Cell USA: +1-201-257-1512 > > > > > > WWW: http://bitworks.software/ <http://bw-sw.com/> > > > > > > > > > > > > > > > > > > > > > > -- > > > > > With best regards, Ivan Kudryavtsev > > > > > Bitworks LLC > > > > > Cell RU: +7-923-414-1515 > > > > > Cell USA: +1-201-257-1512 > > > > > WWW: http://bitworks.software/ <http://bw-sw.com/> > > > > > > > > > > > > > > > > > -- > > > > > > > > Andrija Panić > > > > > > > > > > > > > -- > > > With best regards, Ivan Kudryavtsev > > > Bitworks LLC > > > Cell RU: +7-923-414-1515 > > > Cell USA: +1-201-257-1512 > > > WWW: http://bitworks.software/ <http://bw-sw.com/> > > > > > > > > > -- > > > > Andrija Panić > > > -- Andrija Panić
