Aldo Bucchi wrote:
Kingsley,
On Wed, Dec 3, 2008 at 11:52 AM, Kingsley Idehen <kide...@openlinksw.com> wrote:
Aldo Bucchi wrote:
Hi All,
= About Data and State =
Using any of the Virtuoso Universal Sever AMIs for Amazon EC2, what
are the recommended guidelines for persistence?
I can see that you suggest creating an S3 account ( but there's no
further touching on the topic ), which brings me to the following set
of questions:
How do data lifecycle and AMI lifecycles play along?.
Can something be expected to happen transparently? What, exactly?
You can set up online incremental backups that go to an FTP, WebDAV, or S3
Server (choice is yours).
Beautiful ;).
The EC2 Extension vad provides the UI for configuring the backup syncs to
the destinations you choose.
What has to be done manually?
Just setting up the Backup Sync Job.
Any tricks for using an EBS?
We need to make a note about this. All you do is:
1. Instantiate AMI
2. Allocate the EBS volumes
3. Update your INI so that the DB is stripped across the EBS volumes
4. Reboot AMI or just log into the AMI and restart the Virtuoso instance
Best practices? etc.
The usecase I have is fairly common. I would like to have an instance
up in the cloud but not necessarily up 24/7 for any number of reasons.
At any point in time, I would like to bring it back to life at the
point ( packages, data, users, apps, etc ) where I left it to keep on
working.
This is a Virtuoso instance startup and shutdown matter within an AMI.
If you want to put the AMI off and on, then you must be ready to restore
from backup each time.
Before this I had built my own AMIs and I just moved some files around.
But now that this thing is plug & play, I wonder what the "official" idea
is.
As expressed above :-)
If there is more than one viable option, then I would love to see an
extra step where I could tell my "Virtuoso Cloud Edition" about my
persistence strategy(ies).
= About Configuration =
Another probably useful idea would be to allow all ( or partial )
config of a Virtuoso instance to be represented as RDF. That way, I
could launch a virtuoso AMI with a certain state just by passing the
URL to an RDF document (
http://foo.com/virtuoso-xx-xx-xx-with-ods-safe-sparql-config-data.rdf
) or the data contained inside, which in turn allows me to pipeline
this into more complex, SW/REST friendly architectures.
This would be feasible once we implement the Backup to RDF dump feature :-)
For example:
http://foo.com/privateAPI/launchVOS?ElasticIP=x.x.x.x&config={urlToConfig}
could be the
Which is in turn a URL, etc. I could create a simple ontology where
this could be the value of a "turnOn" property.
And so the power of we architecture and REST stacks up.
Anyway, the sole fact that there is ONE step by step instructions page
smells that there might be something unRESTful about this.
Yet another place for innovation, perhaps.
Yes, the current deliverable is more about the AMI in the Clouds and less
about REST.
Yup, one step at a time. Alas, this is a major step.
At some point we will all get some REST, won't we...
Certainly :-)
BTW. The Backup to RDF dump feature by itself is more than enough if
you provide a simple way to restore after launching an AMI. Anyone
operating at this level should be able to take it from there.
Yes, one of our USPs is the fact that you Restore via a Web Page and
never go into the AMI :-)
We have by far the simplest EC2 AMI setup (as far as I know).
I was just getting exquisite with REST. I don't have the clear use case yet.
The real obstacle here in terms of customized Virtuoso recruitment
automation is the User step involved.
As usual, you are already ahead in that road, first step is providing
the two base binaries... then dump/restore, declarative, world
domination, etc.
:-)
Kingsley
Thanks,
A
Kingsley
Best,
A
--
Regards,
Kingsley Idehen Weblog: http://www.openlinksw.com/blog/~kidehen
President & CEO OpenLink Software Web: http://www.openlinksw.com
--
Regards,
Kingsley Idehen Weblog: http://www.openlinksw.com/blog/~kidehen
President & CEO
OpenLink Software Web: http://www.openlinksw.com
