You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Min Chen <mi...@citrix.com> on 2013/05/24 00:38:45 UTC
Convention on UUID column
Hi there,
During API refactoring efforts, Rohit and I run into several issues due to empty UUID column for existing DB entries. Since UUID was introduced later in 3.0.x, we have to always conditionally handle existing customers with empty UUID columns for different entities, causing much headache for various upgrade cases. To make sure that we have a consistent upgrade base for all 4.1 customers later, in schema-410to420.sql, we have added sql scripts to populate UUID column of all pre-4.1 schema tables with values from their ID column if UUID column is NULL. To make this work properly, we require that all UUID columns should be populated with values when you add new data into both pre-4.1 schema or post-4.1 schema. I just noticed that this assumption may not be well known to community, since I am seeing this sql in schema-410to420.sql:
INSERT INTO `cloud`.`vm_template` (id, unique_name, name, public, created, type, hvm, bits, account_id, url, checksum, enable_password, display_text, format, guest_os_id, featured, cross_zones, hypervisor_type)
VALUES (10, 'routing-10', 'SystemVM Template (LXC)', 0, now(), 'SYSTEM', 0, 64, 1, 'http://download.cloud.com/templates/acton/acton-systemvm-02062012.qcow2.bz2', '2755de1f9ef2ce4d6f2bee2efbb4da92', 0, 'SystemVM Template (LXC)', 'QCOW2', 15, 0, 1, 'LXC');
Instead, this should be modified as:
INSERT INTO `cloud`.`vm_template` (id, uuid, unique_name, name, public, created, type, hvm, bits, account_id, url, checksum, enable_password, display_text, format, guest_os_id, featured, cross_zones, hypervisor_type)
VALUES (10, UUID(), 'routing-10', 'SystemVM Template (LXC)', 0, now(), 'SYSTEM', 0, 64, 1, 'http://download.cloud.com/templates/acton/acton-systemvm-02062012.qcow2.bz2', '2755de1f9ef2ce4d6f2bee2efbb4da92', 0, 'SystemVM Template (LXC)', 'QCOW2', 15, 0, 1, 'LXC');
I have made this fix in master, but want to raise this topic to get community's attention on this.
Thanks
-min
Re: Convention on UUID column
Posted by Rohit Yadav <bh...@apache.org>.
On Fri, May 24, 2013 at 9:24 PM, Min Chen <mi...@citrix.com> wrote:
> +1 on enforcing it through db constraints. Create a JIRA ticket
> https://issues.apache.org/jira/browse/CLOUDSTACK-2676 to track this issue.
>
+1 enforce db constraints. May be have an options/feature in dbcreator to
enforce this check and populate in case it's missing or wrong.
Cheers.
>
> Thanks
> -min
>
> On 5/24/13 6:20 AM, "Alex Huang" <Al...@citrix.com> wrote:
>
> >+1 on adding the constraints. Just make sure you add them after
> >upgrading the data.
> >
> >Populating with id in the upgrade prevents exactly the problem you've
> >described. That's why we're doing it.
> >
> >
> >--Alex
> >
> >> -----Original Message-----
> >> From: Nitin Mehta [mailto:Nitin.Mehta@citrix.com]
> >> Sent: Thursday, May 23, 2013 11:09 PM
> >> To: dev@cloudstack.apache.org
> >> Subject: Re: Convention on UUID column
> >>
> >> Agree with Koushik. Lets enforce the not null constraint on all the
> >>UUID fields
> >> now that we are populating it.
> >>
> >> Also wanted to ask why we are populating it with the ID and not a
> >>generated
> >> UUID ? Doesn't break the backward compatibilty going either ways but the
> >> later is more consistent right and can be used in future as they are
> >>always
> >> unique across the system - say for storing templates directly under
> >>?UUID of
> >> the template/vol/snapshot on sec. storage than using the folder
> >>structure of
> >> templates/account_id/template_id/real_template ?
> >> Clients who have hardcoded against CS for system vm ids, service
> >>offering ids
> >> etc. will break definitely though - is that ok ?
> >>
> >> Thanks,
> >> -Nitin
> >>
> >> On 24/05/13 9:26 AM, "Koushik Das" <ko...@citrix.com> wrote:
> >>
> >> >
> >> >It is better to add constraints in the db for all uuid fields. That way
> >> >uuid field will never get missed out. I see that for some tables there
> >> >is a NOT NULL constraint.
> >> >
> >> >-Koushik
> >> >
> >> >> -----Original Message-----
> >> >> From: Min Chen [mailto:min.chen@citrix.com]
> >> >> Sent: Friday, May 24, 2013 4:09 AM
> >> >> To: dev@cloudstack.apache.org
> >> >> Subject: Convention on UUID column
> >> >>
> >> >> Hi there,
> >> >>
> >> >> During API refactoring efforts, Rohit and I run into several issues
> >> >>due to empty UUID column for existing DB entries. Since UUID was
> >> >>introduced later in 3.0.x, we have to always conditionally handle
> >> >>existing customers with empty UUID columns for different entities,
> >> >>causing much headache for various upgrade cases. To make sure that we
> >> >>have a consistent upgrade base for all 4.1 customers later, in
> >> >>schema-410to420.sql, we have added sql scripts to populate UUID
> >> >>column of all pre-4.1 schema tables with values from their ID column
> >> >>if UUID column is NULL. To make this work properly, we require that
> >> >>all UUID columns should be populated with values when you add new
> >> >>data into both pre-4.1 schema or post-4.1 schema. I just noticed that
> >> >>this assumption may not be well known to community, since I am seeing
> >> >>this sql in schema-410to420.sql:
> >> >>
> >> >>
> >> >> INSERT INTO `cloud`.`vm_template` (id, unique_name, name, public,
> >> >>created, type, hvm, bits, account_id, url, checksum, enable_password,
> >> >>display_text, format, guest_os_id, featured, cross_zones,
> >> >>hypervisor_type)
> >> >>
> >> >> VALUES (10, 'routing-10', 'SystemVM Template (LXC)', 0, now(),
> >> >>'SYSTEM', 0, 64, 1,
> >> >>'http://download.cloud.com/templates/acton/acton-systemvm-
> >> >> 02062012.qcow2.bz2', '2755de1f9ef2ce4d6f2bee2efbb4da92', 0,
> >> 'SystemVM
> >> >>Template (LXC)', 'QCOW2', 15, 0, 1, 'LXC');
> >> >>
> >> >>
> >> >> Instead, this should be modified as:
> >> >>
> >> >>
> >> >> INSERT INTO `cloud`.`vm_template` (id, uuid, unique_name, name,
> >> >>public, created, type, hvm, bits, account_id, url, checksum,
> >> >>enable_password, display_text, format, guest_os_id, featured,
> >> >>cross_zones,
> >> >>hypervisor_type)
> >> >>
> >> >> VALUES (10, UUID(), 'routing-10', 'SystemVM Template (LXC)', 0,
> >> >>now(), 'SYSTEM', 0, 64, 1,
> >> >>'http://download.cloud.com/templates/acton/acton-
> >> >> systemvm-02062012.qcow2.bz2', '2755de1f9ef2ce4d6f2bee2efbb4da92', 0,
> >> >>'SystemVM Template (LXC)', 'QCOW2', 15, 0, 1, 'LXC');
> >> >>
> >> >> I have made this fix in master, but want to raise this topic to get
> >> >>community's attention on this.
> >> >>
> >> >> Thanks
> >> >> -min
> >> >>
> >> >
> >
>
>
Re: Convention on UUID column
Posted by Min Chen <mi...@citrix.com>.
+1 on enforcing it through db constraints. Create a JIRA ticket
https://issues.apache.org/jira/browse/CLOUDSTACK-2676 to track this issue.
Thanks
-min
On 5/24/13 6:20 AM, "Alex Huang" <Al...@citrix.com> wrote:
>+1 on adding the constraints. Just make sure you add them after
>upgrading the data.
>
>Populating with id in the upgrade prevents exactly the problem you've
>described. That's why we're doing it.
>
>
>--Alex
>
>> -----Original Message-----
>> From: Nitin Mehta [mailto:Nitin.Mehta@citrix.com]
>> Sent: Thursday, May 23, 2013 11:09 PM
>> To: dev@cloudstack.apache.org
>> Subject: Re: Convention on UUID column
>>
>> Agree with Koushik. Lets enforce the not null constraint on all the
>>UUID fields
>> now that we are populating it.
>>
>> Also wanted to ask why we are populating it with the ID and not a
>>generated
>> UUID ? Doesn't break the backward compatibilty going either ways but the
>> later is more consistent right and can be used in future as they are
>>always
>> unique across the system - say for storing templates directly under
>>?UUID of
>> the template/vol/snapshot on sec. storage than using the folder
>>structure of
>> templates/account_id/template_id/real_template ?
>> Clients who have hardcoded against CS for system vm ids, service
>>offering ids
>> etc. will break definitely though - is that ok ?
>>
>> Thanks,
>> -Nitin
>>
>> On 24/05/13 9:26 AM, "Koushik Das" <ko...@citrix.com> wrote:
>>
>> >
>> >It is better to add constraints in the db for all uuid fields. That way
>> >uuid field will never get missed out. I see that for some tables there
>> >is a NOT NULL constraint.
>> >
>> >-Koushik
>> >
>> >> -----Original Message-----
>> >> From: Min Chen [mailto:min.chen@citrix.com]
>> >> Sent: Friday, May 24, 2013 4:09 AM
>> >> To: dev@cloudstack.apache.org
>> >> Subject: Convention on UUID column
>> >>
>> >> Hi there,
>> >>
>> >> During API refactoring efforts, Rohit and I run into several issues
>> >>due to empty UUID column for existing DB entries. Since UUID was
>> >>introduced later in 3.0.x, we have to always conditionally handle
>> >>existing customers with empty UUID columns for different entities,
>> >>causing much headache for various upgrade cases. To make sure that we
>> >>have a consistent upgrade base for all 4.1 customers later, in
>> >>schema-410to420.sql, we have added sql scripts to populate UUID
>> >>column of all pre-4.1 schema tables with values from their ID column
>> >>if UUID column is NULL. To make this work properly, we require that
>> >>all UUID columns should be populated with values when you add new
>> >>data into both pre-4.1 schema or post-4.1 schema. I just noticed that
>> >>this assumption may not be well known to community, since I am seeing
>> >>this sql in schema-410to420.sql:
>> >>
>> >>
>> >> INSERT INTO `cloud`.`vm_template` (id, unique_name, name, public,
>> >>created, type, hvm, bits, account_id, url, checksum, enable_password,
>> >>display_text, format, guest_os_id, featured, cross_zones,
>> >>hypervisor_type)
>> >>
>> >> VALUES (10, 'routing-10', 'SystemVM Template (LXC)', 0, now(),
>> >>'SYSTEM', 0, 64, 1,
>> >>'http://download.cloud.com/templates/acton/acton-systemvm-
>> >> 02062012.qcow2.bz2', '2755de1f9ef2ce4d6f2bee2efbb4da92', 0,
>> 'SystemVM
>> >>Template (LXC)', 'QCOW2', 15, 0, 1, 'LXC');
>> >>
>> >>
>> >> Instead, this should be modified as:
>> >>
>> >>
>> >> INSERT INTO `cloud`.`vm_template` (id, uuid, unique_name, name,
>> >>public, created, type, hvm, bits, account_id, url, checksum,
>> >>enable_password, display_text, format, guest_os_id, featured,
>> >>cross_zones,
>> >>hypervisor_type)
>> >>
>> >> VALUES (10, UUID(), 'routing-10', 'SystemVM Template (LXC)', 0,
>> >>now(), 'SYSTEM', 0, 64, 1,
>> >>'http://download.cloud.com/templates/acton/acton-
>> >> systemvm-02062012.qcow2.bz2', '2755de1f9ef2ce4d6f2bee2efbb4da92', 0,
>> >>'SystemVM Template (LXC)', 'QCOW2', 15, 0, 1, 'LXC');
>> >>
>> >> I have made this fix in master, but want to raise this topic to get
>> >>community's attention on this.
>> >>
>> >> Thanks
>> >> -min
>> >>
>> >
>
RE: Convention on UUID column
Posted by Alex Huang <Al...@citrix.com>.
+1 on adding the constraints. Just make sure you add them after upgrading the data.
Populating with id in the upgrade prevents exactly the problem you've described. That's why we're doing it.
--Alex
> -----Original Message-----
> From: Nitin Mehta [mailto:Nitin.Mehta@citrix.com]
> Sent: Thursday, May 23, 2013 11:09 PM
> To: dev@cloudstack.apache.org
> Subject: Re: Convention on UUID column
>
> Agree with Koushik. Lets enforce the not null constraint on all the UUID fields
> now that we are populating it.
>
> Also wanted to ask why we are populating it with the ID and not a generated
> UUID ? Doesn't break the backward compatibilty going either ways but the
> later is more consistent right and can be used in future as they are always
> unique across the system - say for storing templates directly under UUID of
> the template/vol/snapshot on sec. storage than using the folder structure of
> templates/account_id/template_id/real_template ?
> Clients who have hardcoded against CS for system vm ids, service offering ids
> etc. will break definitely though - is that ok ?
>
> Thanks,
> -Nitin
>
> On 24/05/13 9:26 AM, "Koushik Das" <ko...@citrix.com> wrote:
>
> >
> >It is better to add constraints in the db for all uuid fields. That way
> >uuid field will never get missed out. I see that for some tables there
> >is a NOT NULL constraint.
> >
> >-Koushik
> >
> >> -----Original Message-----
> >> From: Min Chen [mailto:min.chen@citrix.com]
> >> Sent: Friday, May 24, 2013 4:09 AM
> >> To: dev@cloudstack.apache.org
> >> Subject: Convention on UUID column
> >>
> >> Hi there,
> >>
> >> During API refactoring efforts, Rohit and I run into several issues
> >>due to empty UUID column for existing DB entries. Since UUID was
> >>introduced later in 3.0.x, we have to always conditionally handle
> >>existing customers with empty UUID columns for different entities,
> >>causing much headache for various upgrade cases. To make sure that we
> >>have a consistent upgrade base for all 4.1 customers later, in
> >>schema-410to420.sql, we have added sql scripts to populate UUID
> >>column of all pre-4.1 schema tables with values from their ID column
> >>if UUID column is NULL. To make this work properly, we require that
> >>all UUID columns should be populated with values when you add new
> >>data into both pre-4.1 schema or post-4.1 schema. I just noticed that
> >>this assumption may not be well known to community, since I am seeing
> >>this sql in schema-410to420.sql:
> >>
> >>
> >> INSERT INTO `cloud`.`vm_template` (id, unique_name, name, public,
> >>created, type, hvm, bits, account_id, url, checksum, enable_password,
> >>display_text, format, guest_os_id, featured, cross_zones,
> >>hypervisor_type)
> >>
> >> VALUES (10, 'routing-10', 'SystemVM Template (LXC)', 0, now(),
> >>'SYSTEM', 0, 64, 1,
> >>'http://download.cloud.com/templates/acton/acton-systemvm-
> >> 02062012.qcow2.bz2', '2755de1f9ef2ce4d6f2bee2efbb4da92', 0,
> 'SystemVM
> >>Template (LXC)', 'QCOW2', 15, 0, 1, 'LXC');
> >>
> >>
> >> Instead, this should be modified as:
> >>
> >>
> >> INSERT INTO `cloud`.`vm_template` (id, uuid, unique_name, name,
> >>public, created, type, hvm, bits, account_id, url, checksum,
> >>enable_password, display_text, format, guest_os_id, featured,
> >>cross_zones,
> >>hypervisor_type)
> >>
> >> VALUES (10, UUID(), 'routing-10', 'SystemVM Template (LXC)', 0,
> >>now(), 'SYSTEM', 0, 64, 1,
> >>'http://download.cloud.com/templates/acton/acton-
> >> systemvm-02062012.qcow2.bz2', '2755de1f9ef2ce4d6f2bee2efbb4da92', 0,
> >>'SystemVM Template (LXC)', 'QCOW2', 15, 0, 1, 'LXC');
> >>
> >> I have made this fix in master, but want to raise this topic to get
> >>community's attention on this.
> >>
> >> Thanks
> >> -min
> >>
> >
Re: Convention on UUID column
Posted by Nitin Mehta <Ni...@citrix.com>.
Agreed with Koushik. Now that the UUId is going to be populated for every
table lets keep it as not null else we will keep running into these issues.
Also whats the reason for populating the UUID column with ID ? Is it for
clients who have hardcoded values for system vms, service offerings etc.
or do we really break some backward compatibility ? I would have still
preferred populating it with UUID else you call the api with Ids (for
preexisting resources) and UUIds which is confusing. Also since UUIds are
unique across the board we wouldn't have to keep folder structures like
template/account_id/template_id or snapshots/volume_id etc. This is just
an example.
Thanks,
Nitin
On 24/05/13 9:26 AM, "Koushik Das" <ko...@citrix.com> wrote:
>
>It is better to add constraints in the db for all uuid fields. That way
>uuid field will never get missed out. I see that for some tables there is
>a NOT NULL constraint.
>
>-Koushik
>
>> -----Original Message-----
>> From: Min Chen [mailto:min.chen@citrix.com]
>> Sent: Friday, May 24, 2013 4:09 AM
>> To: dev@cloudstack.apache.org
>> Subject: Convention on UUID column
>>
>> Hi there,
>>
>> During API refactoring efforts, Rohit and I run into several issues due
>>to
>> empty UUID column for existing DB entries. Since UUID was introduced
>>later
>> in 3.0.x, we have to always conditionally handle existing customers with
>> empty UUID columns for different entities, causing much headache for
>> various upgrade cases. To make sure that we have a consistent upgrade
>>base
>> for all 4.1 customers later, in schema-410to420.sql, we have added sql
>>scripts
>> to populate UUID column of all pre-4.1 schema tables with values from
>>their
>> ID column if UUID column is NULL. To make this work properly, we require
>> that all UUID columns should be populated with values when you add new
>> data into both pre-4.1 schema or post-4.1 schema. I just noticed that
>>this
>> assumption may not be well known to community, since I am seeing this
>>sql
>> in schema-410to420.sql:
>>
>>
>> INSERT INTO `cloud`.`vm_template` (id, unique_name, name, public,
>> created, type, hvm, bits, account_id, url, checksum, enable_password,
>> display_text, format, guest_os_id, featured, cross_zones,
>>hypervisor_type)
>>
>> VALUES (10, 'routing-10', 'SystemVM Template (LXC)', 0, now(),
>>'SYSTEM',
>> 0, 64, 1, 'http://download.cloud.com/templates/acton/acton-systemvm-
>> 02062012.qcow2.bz2', '2755de1f9ef2ce4d6f2bee2efbb4da92', 0, 'SystemVM
>> Template (LXC)', 'QCOW2', 15, 0, 1, 'LXC');
>>
>>
>> Instead, this should be modified as:
>>
>>
>> INSERT INTO `cloud`.`vm_template` (id, uuid, unique_name, name, public,
>> created, type, hvm, bits, account_id, url, checksum, enable_password,
>> display_text, format, guest_os_id, featured, cross_zones,
>>hypervisor_type)
>>
>> VALUES (10, UUID(), 'routing-10', 'SystemVM Template (LXC)', 0,
>>now(),
>> 'SYSTEM', 0, 64, 1, 'http://download.cloud.com/templates/acton/acton-
>> systemvm-02062012.qcow2.bz2', '2755de1f9ef2ce4d6f2bee2efbb4da92', 0,
>> 'SystemVM Template (LXC)', 'QCOW2', 15, 0, 1, 'LXC');
>>
>> I have made this fix in master, but want to raise this topic to get
>>community's
>> attention on this.
>>
>> Thanks
>> -min
>>
>
Re: Convention on UUID column
Posted by Nitin Mehta <Ni...@citrix.com>.
Agree with Koushik. Lets enforce the not null constraint on all the UUID
fields now that we are populating it.
Also wanted to ask why we are populating it with the ID and not a
generated UUID ? Doesn't break the backward compatibilty going either ways
but the later is more consistent right and can be used in future as they
are always unique across the system - say for storing templates directly
under UUID of the template/vol/snapshot on sec. storage than using the
folder structure of templates/account_id/template_id/real_template ?
Clients who have hardcoded against CS for system vm ids, service offering
ids etc. will break definitely though - is that ok ?
Thanks,
-Nitin
On 24/05/13 9:26 AM, "Koushik Das" <ko...@citrix.com> wrote:
>
>It is better to add constraints in the db for all uuid fields. That way
>uuid field will never get missed out. I see that for some tables there is
>a NOT NULL constraint.
>
>-Koushik
>
>> -----Original Message-----
>> From: Min Chen [mailto:min.chen@citrix.com]
>> Sent: Friday, May 24, 2013 4:09 AM
>> To: dev@cloudstack.apache.org
>> Subject: Convention on UUID column
>>
>> Hi there,
>>
>> During API refactoring efforts, Rohit and I run into several issues due
>>to
>> empty UUID column for existing DB entries. Since UUID was introduced
>>later
>> in 3.0.x, we have to always conditionally handle existing customers with
>> empty UUID columns for different entities, causing much headache for
>> various upgrade cases. To make sure that we have a consistent upgrade
>>base
>> for all 4.1 customers later, in schema-410to420.sql, we have added sql
>>scripts
>> to populate UUID column of all pre-4.1 schema tables with values from
>>their
>> ID column if UUID column is NULL. To make this work properly, we require
>> that all UUID columns should be populated with values when you add new
>> data into both pre-4.1 schema or post-4.1 schema. I just noticed that
>>this
>> assumption may not be well known to community, since I am seeing this
>>sql
>> in schema-410to420.sql:
>>
>>
>> INSERT INTO `cloud`.`vm_template` (id, unique_name, name, public,
>> created, type, hvm, bits, account_id, url, checksum, enable_password,
>> display_text, format, guest_os_id, featured, cross_zones,
>>hypervisor_type)
>>
>> VALUES (10, 'routing-10', 'SystemVM Template (LXC)', 0, now(),
>>'SYSTEM',
>> 0, 64, 1, 'http://download.cloud.com/templates/acton/acton-systemvm-
>> 02062012.qcow2.bz2', '2755de1f9ef2ce4d6f2bee2efbb4da92', 0, 'SystemVM
>> Template (LXC)', 'QCOW2', 15, 0, 1, 'LXC');
>>
>>
>> Instead, this should be modified as:
>>
>>
>> INSERT INTO `cloud`.`vm_template` (id, uuid, unique_name, name, public,
>> created, type, hvm, bits, account_id, url, checksum, enable_password,
>> display_text, format, guest_os_id, featured, cross_zones,
>>hypervisor_type)
>>
>> VALUES (10, UUID(), 'routing-10', 'SystemVM Template (LXC)', 0,
>>now(),
>> 'SYSTEM', 0, 64, 1, 'http://download.cloud.com/templates/acton/acton-
>> systemvm-02062012.qcow2.bz2', '2755de1f9ef2ce4d6f2bee2efbb4da92', 0,
>> 'SystemVM Template (LXC)', 'QCOW2', 15, 0, 1, 'LXC');
>>
>> I have made this fix in master, but want to raise this topic to get
>>community's
>> attention on this.
>>
>> Thanks
>> -min
>>
>
RE: Convention on UUID column
Posted by Koushik Das <ko...@citrix.com>.
It is better to add constraints in the db for all uuid fields. That way uuid field will never get missed out. I see that for some tables there is a NOT NULL constraint.
-Koushik
> -----Original Message-----
> From: Min Chen [mailto:min.chen@citrix.com]
> Sent: Friday, May 24, 2013 4:09 AM
> To: dev@cloudstack.apache.org
> Subject: Convention on UUID column
>
> Hi there,
>
> During API refactoring efforts, Rohit and I run into several issues due to
> empty UUID column for existing DB entries. Since UUID was introduced later
> in 3.0.x, we have to always conditionally handle existing customers with
> empty UUID columns for different entities, causing much headache for
> various upgrade cases. To make sure that we have a consistent upgrade base
> for all 4.1 customers later, in schema-410to420.sql, we have added sql scripts
> to populate UUID column of all pre-4.1 schema tables with values from their
> ID column if UUID column is NULL. To make this work properly, we require
> that all UUID columns should be populated with values when you add new
> data into both pre-4.1 schema or post-4.1 schema. I just noticed that this
> assumption may not be well known to community, since I am seeing this sql
> in schema-410to420.sql:
>
>
> INSERT INTO `cloud`.`vm_template` (id, unique_name, name, public,
> created, type, hvm, bits, account_id, url, checksum, enable_password,
> display_text, format, guest_os_id, featured, cross_zones, hypervisor_type)
>
> VALUES (10, 'routing-10', 'SystemVM Template (LXC)', 0, now(), 'SYSTEM',
> 0, 64, 1, 'http://download.cloud.com/templates/acton/acton-systemvm-
> 02062012.qcow2.bz2', '2755de1f9ef2ce4d6f2bee2efbb4da92', 0, 'SystemVM
> Template (LXC)', 'QCOW2', 15, 0, 1, 'LXC');
>
>
> Instead, this should be modified as:
>
>
> INSERT INTO `cloud`.`vm_template` (id, uuid, unique_name, name, public,
> created, type, hvm, bits, account_id, url, checksum, enable_password,
> display_text, format, guest_os_id, featured, cross_zones, hypervisor_type)
>
> VALUES (10, UUID(), 'routing-10', 'SystemVM Template (LXC)', 0, now(),
> 'SYSTEM', 0, 64, 1, 'http://download.cloud.com/templates/acton/acton-
> systemvm-02062012.qcow2.bz2', '2755de1f9ef2ce4d6f2bee2efbb4da92', 0,
> 'SystemVM Template (LXC)', 'QCOW2', 15, 0, 1, 'LXC');
>
> I have made this fix in master, but want to raise this topic to get community's
> attention on this.
>
> Thanks
> -min
>