Re: esxthin.pm username/password/filer ip variables
Hi Toks,
The thinking is mainly to relieve developers from having to extend the schema
for everything/anything they want to save in the database.
The table should work for static or dynamic variables. The data you save would
persist across invocations of the provisioning module.
There currently isn't a Perl subroutine to delete a variable. It's a good idea
and would be trivial to add. I can do this once 2.1 is released. This will
make it possible to clean up dynamic variables.
The table can be as dynamic as you'd like. The only real requirement is that
variable.name be unique. If you had a provisioning module and wanted to store
different data for every reservation, you could name the variable dynamically by
appending the reservation ID. You could store data specific to a management
node, image, version of Windows, etc by naming the variable accordingly.
Once $self->data->delete_variable() is added, you could call it from a DESTROY
subroutine in your provisioning module to automatically delete any dynamic
variables which you had created for the reservation whenever its process exits.
-Andy
Toks Adeshiyan wrote:
Andy,
Is the thinking here that this new function is geared more towards
static variables? I would imagine that developers may want to
update/remove variables over the course of several invocations of a
given provisioning module. Is this inherently built in?
Toks
Andy Kurth wrote:
The backend has been updated to handle the serialization column in the
variable table. You will need to update DataStructure.pm and make
sure your variable table matches its definition in vcl.sql.
The variable table's purpose is just as its name implies - stores
variables of arbitrary purpose or form. Anyone developing a module or
working on the core code can utilize this table.
The columns in the variable table are:
* id - autoincremented row ID, primary key
* name - string representing friendly name of variable chosen by
developer, must be unique
* serialization - indicates method used to serialize the data stored
in the value column, can be 'none', 'yaml', or 'phpserialize' (Note:
the backend does not yet support 'phpserialize')
* value - actual data, can be a simple string if serialize=none, can
be a data structure if serialize=yaml
* setby - indicates the module and line number which set the variable
if the backend set_variable() function was used, automatically
populated, can be null
* timestamp - when variable was created or last updated
Variable names (name column) should be specific to avoid conflicts in
the future. I would include the module name in the variable name if
possible/applicable.
Data can be stored by either manually adding a row or by using
$self->data->set_variable(name, data). If you are storing simple
scalar data such as a username, the serialization column should be set
to 'none' and the raw data should be stored in the value column.
Complex data structures can also be stored in the table but the
set_variable() function should be used rather they trying to manually
add it to the database. The set_variable() function serializes the
data using YAML before storing it. For example, if you had an array of
hashes called %mydata, you can store the entire data structure by
passing a reference to set_variable():
$self->data->set_variable('myvar', \%mydata);
Data can be retrieved via $self->data->get_variable(name). You could
retrieve the exact data structure stored above at any time in the
future via:
my $mydata = $self->data->get_variable('myvar');
(Note: get_data() would return a reference)
The frontend and backend can store and utilize each other's variables
even if the data is a relatively complex data structure. If the
frontend PHP code stores an array in the variable table serialized via
YAML, the backend Perl code could retrieve the same exact array via
get_variable().
Hope this helps,
Andy
Andy Kurth wrote:
Hi Brian,
You can use the variable table. This table was added in order allow
an easy way to store such things without having to extend the
schema. One of the main goals of the variable table was to give
module developers a way to store data.
This reminded me of some updates that need to be made to the backend
DataStructure.pm file before 2.1 is released. A serialization column
was recently added to the variable table. The get_variable() and
set_variable() subroutines in DataStructure.pm need to be extended to
handle the additional column. I'm working on this now and will
commit the changes this morning. I'll follow up with additional
details once this is ready.
-Andy
Brian Bouterse wrote:
Currently in the netapp based, esxthin.pm the username/password/and
filer ip are hardcoded. I want to get those variables to not be
hardcoded, but passed into the module. Should we put it in the db,
a special config file, or in the vcld.conf?
I will post the preliminary code to the SVN as soon
Re: esxthin.pm username/password/filer ip variables
Andy,
Is the thinking here that this new function is geared more towards
static variables? I would imagine that developers may want to
update/remove variables over the course of several invocations of a
given provisioning module. Is this inherently built in?
Toks
Andy Kurth wrote:
The backend has been updated to handle the serialization column in the
variable table. You will need to update DataStructure.pm and make
sure your variable table matches its definition in vcl.sql.
The variable table's purpose is just as its name implies - stores
variables of arbitrary purpose or form. Anyone developing a module or
working on the core code can utilize this table.
The columns in the variable table are:
* id - autoincremented row ID, primary key
* name - string representing friendly name of variable chosen by
developer, must be unique
* serialization - indicates method used to serialize the data stored
in the value column, can be 'none', 'yaml', or 'phpserialize' (Note:
the backend does not yet support 'phpserialize')
* value - actual data, can be a simple string if serialize=none, can
be a data structure if serialize=yaml
* setby - indicates the module and line number which set the variable
if the backend set_variable() function was used, automatically
populated, can be null
* timestamp - when variable was created or last updated
Variable names (name column) should be specific to avoid conflicts in
the future. I would include the module name in the variable name if
possible/applicable.
Data can be stored by either manually adding a row or by using
$self->data->set_variable(name, data). If you are storing simple
scalar data such as a username, the serialization column should be set
to 'none' and the raw data should be stored in the value column.
Complex data structures can also be stored in the table but the
set_variable() function should be used rather they trying to manually
add it to the database. The set_variable() function serializes the
data using YAML before storing it. For example, if you had an array of
hashes called %mydata, you can store the entire data structure by
passing a reference to set_variable():
$self->data->set_variable('myvar', \%mydata);
Data can be retrieved via $self->data->get_variable(name). You could
retrieve the exact data structure stored above at any time in the
future via:
my $mydata = $self->data->get_variable('myvar');
(Note: get_data() would return a reference)
The frontend and backend can store and utilize each other's variables
even if the data is a relatively complex data structure. If the
frontend PHP code stores an array in the variable table serialized via
YAML, the backend Perl code could retrieve the same exact array via
get_variable().
Hope this helps,
Andy
Andy Kurth wrote:
Hi Brian,
You can use the variable table. This table was added in order allow
an easy way to store such things without having to extend the
schema. One of the main goals of the variable table was to give
module developers a way to store data.
This reminded me of some updates that need to be made to the backend
DataStructure.pm file before 2.1 is released. A serialization column
was recently added to the variable table. The get_variable() and
set_variable() subroutines in DataStructure.pm need to be extended to
handle the additional column. I'm working on this now and will
commit the changes this morning. I'll follow up with additional
details once this is ready.
-Andy
Brian Bouterse wrote:
Currently in the netapp based, esxthin.pm the username/password/and
filer ip are hardcoded. I want to get those variables to not be
hardcoded, but passed into the module. Should we put it in the db,
a special config file, or in the vcld.conf?
I will post the preliminary code to the SVN as soon as it does
something useful.
Best,
Brian
Brian Bouterse
NEXT Services
919.698.8796
Re: esxthin.pm username/password/filer ip variables
The backend has been updated to handle the serialization column in the variable
table. You will need to update DataStructure.pm and make sure your variable
table matches its definition in vcl.sql.
The variable table's purpose is just as its name implies - stores variables of
arbitrary purpose or form. Anyone developing a module or working on the core
code can utilize this table.
The columns in the variable table are:
* id - autoincremented row ID, primary key
* name - string representing friendly name of variable chosen by developer, must
be unique
* serialization - indicates method used to serialize the data stored in the
value column, can be 'none', 'yaml', or 'phpserialize' (Note: the backend does
not yet support 'phpserialize')
* value - actual data, can be a simple string if serialize=none, can be a data
structure if serialize=yaml
* setby - indicates the module and line number which set the variable if the
backend set_variable() function was used, automatically populated, can be null
* timestamp - when variable was created or last updated
Variable names (name column) should be specific to avoid conflicts in the
future. I would include the module name in the variable name if
possible/applicable.
Data can be stored by either manually adding a row or by using
$self->data->set_variable(name, data). If you are storing simple scalar data
such as a username, the serialization column should be set to 'none' and the raw
data should be stored in the value column.
Complex data structures can also be stored in the table but the set_variable()
function should be used rather they trying to manually add it to the database.
The set_variable() function serializes the data using YAML before storing it.
For example, if you had an array of hashes called %mydata, you can store the
entire data structure by passing a reference to set_variable():
$self->data->set_variable('myvar', \%mydata);
Data can be retrieved via $self->data->get_variable(name). You could retrieve
the exact data structure stored above at any time in the future via:
my $mydata = $self->data->get_variable('myvar');
(Note: get_data() would return a reference)
The frontend and backend can store and utilize each other's variables even if
the data is a relatively complex data structure. If the frontend PHP code
stores an array in the variable table serialized via YAML, the backend Perl code
could retrieve the same exact array via get_variable().
Hope this helps,
Andy
Andy Kurth wrote:
Hi Brian,
You can use the variable table. This table was added in order allow an
easy way to store such things without having to extend the schema. One
of the main goals of the variable table was to give module developers a
way to store data.
This reminded me of some updates that need to be made to the backend
DataStructure.pm file before 2.1 is released. A serialization column
was recently added to the variable table. The get_variable() and
set_variable() subroutines in DataStructure.pm need to be extended to
handle the additional column. I'm working on this now and will commit
the changes this morning. I'll follow up with additional details once
this is ready.
-Andy
Brian Bouterse wrote:
Currently in the netapp based, esxthin.pm the username/password/and
filer ip are hardcoded. I want to get those variables to not be
hardcoded, but passed into the module. Should we put it in the db, a
special config file, or in the vcld.conf?
I will post the preliminary code to the SVN as soon as it does
something useful.
Best,
Brian
Brian Bouterse
NEXT Services
919.698.8796
--
Andy Kurth
Virtual Computing Lab
Office of Information Technology
North Carolina State University
andy_ku...@ncsu.edu
919.513.4090
Re: esxthin.pm username/password/filer ip variables
Hi Brian, You can use the variable table. This table was added in order allow an easy way to store such things without having to extend the schema. One of the main goals of the variable table was to give module developers a way to store data. This reminded me of some updates that need to be made to the backend DataStructure.pm file before 2.1 is released. A serialization column was recently added to the variable table. The get_variable() and set_variable() subroutines in DataStructure.pm need to be extended to handle the additional column. I'm working on this now and will commit the changes this morning. I'll follow up with additional details once this is ready. -Andy Brian Bouterse wrote: Currently in the netapp based, esxthin.pm the username/password/and filer ip are hardcoded. I want to get those variables to not be hardcoded, but passed into the module. Should we put it in the db, a special config file, or in the vcld.conf? I will post the preliminary code to the SVN as soon as it does something useful. Best, Brian Brian Bouterse NEXT Services 919.698.8796 -- Andy Kurth Virtual Computing Lab Office of Information Technology North Carolina State University andy_ku...@ncsu.edu 919.513.4090
esxthin.pm username/password/filer ip variables
Currently in the netapp based, esxthin.pm the username/password/and filer ip are hardcoded. I want to get those variables to not be hardcoded, but passed into the module. Should we put it in the db, a special config file, or in the vcld.conf? I will post the preliminary code to the SVN as soon as it does something useful. Best, Brian Brian Bouterse NEXT Services 919.698.8796
