Virtualization Plugins

 View Only

Access to all schema objects from each plugin method?

  • 1.  Access to all schema objects from each plugin method?

    Posted 07-02-2019 03:10:00 PM
    Is there a way in Python/SDK to get access to all the schema objects from each of the plugin methods?

    Use case : SDK to virtualize a source MongoDB instance as a VDB with the same characteristics on a different target host.. 
    My source_config requires path, which is used to rsync, and service which needs to be started/stopped as part of refresh/snapshots/etc.  I want to setup the VDB the exact same way on a different host.  My preference would be not to require the user to re-enter this information for the virtual source.

    The issue is that the virtual.configure method does not pass in source_config so it does not have access to it's data, but yet it needs to return a new source_config object for the VDB.  This means that we need to basically replicate all required source_config fields in the virtual_config schema/screens, even though it is repetitive, and introduces confusion/issues if they are not entered exactly the same.  Note that I do not care if the connection to the dSource is active, I just need access to it's metadata, which I'd think should always be available. 

    Also note that it is confusing that you do not pass source_config into virtual.configure, but you do pass it into virtual.reconfigure, virtual.pre_snapshot, and virtual.post_snapshot.  I assume these are probably for the VDB and not the dSource, but the naming is misleading.

    Instead of thinking of outlier cases of when a method may need a particular metadata object, which there will probably always be some case, why not just pass a global schemas object to each method that contains all the metadata (i.e. the entire schema.json definition)?  And then perhaps rename source_config for the VDB to actually be vdb_config or something that is more indicative to what it actually is.  This would really simplify/streamline the usage and reduce potential outlier cases like the one I just ran into.

    Note that I do have an interim work around which saves the values that I need in a .txt file on the staging mount, that is then read by the virtual.configure method when a VDB is created.  This works, but is not optimal.  

    Another related use case would be if you wanted to default to the source values, but allow the user to optionally override.  If the methods had access to both we could look at the virtual_config and if there is no value for a particular attribute we could read it from the source_config.  Or is there already a way to do this?


    Paul Jauquet
    Senior Data Services Consultant
    Axis Technology, LLC