VMware Cloud Community
SeanKohler
Expert
Expert

VCO Script... Create ConfigurationElement in ConfigurationElementCategory


Anybody know how to do this?  I see no methods for creating a Configuration Element.

For that matter, there doesn't seem to be a fully complete way to create an Attribute within a Configuration Element.  By that, I mean you can add an attribute with key by doing this...

myConfigurationElement.setAttributeWithKey("mynewstring","Will it work");

... and you will get an attribute that looks like this... but notice that no description is set.  It seems to be kind of an overload since its purpose seems to be to set a value to an existing configuration element attribute, but it does create a new one.

writeConfigElements.jpg

14 Replies
qc4vmware
Virtuoso
Virtuoso

You have actually stumbled into some of my oldest gripes.  I have been asking for this functionality for years now but for some unknown reason they have dug their heels in on this one and won't allow for programatic creation of the configuration elements.  I have also been told that the creation of the attributes is actually considered a bug.  I think at this point they actually realize that they have a ton of customers that rely upon this "bug" as part of their solutions and that taking this away would be very disruptive to say the least.

I'd say open a feature request.  That is what I did many moons ago.

What you have illustrated is just the way they work today.  You can't set the description programmatically to my knowledge.  Just the value.  And no creation of the config elements. 

Paul.

SeanKohler
Expert
Expert


Thanks Paul.

It is a little bit strange.  I don't know if maybe they are concerned with some sort of variable sprawl if they make it too easy to leverage? They don't want these types to be used like a database?

It is apparent that they created the architecture to allow for variable constants that live outside of workflows/actions. It makes total sense having that capability, and it is a powerful mechanism for this tool. Why they wouldn't then provide full CRUD methods against those variables is mind-boggling.

Have you seen any limits regarding the quantity of "Attributes" you can have in a Configuration Element?  (Not that I am looking to use a CE with a large quantity of Attributes... just curious.)

Reply
0 Kudos
qc4vmware
Virtuoso
Virtuoso

I do not know what the (if any) limitations are around the number of attributes per element allowed are.  That would be good to know for sure.

Reply
0 Kudos
SeanKohler
Expert
Expert

Well 10,000 strings was successful....  I am running 100,000 strings now... should have an answer on that tomorrow.

If there was an Attribute Delete capability, I probably would consider doing something as crazy as having an Attribute per servername with an array of strings about each servername (to be used programmatically for other workflows).  Or other things like that.  It could be argued that such data could/should exist external to the system via plugin to datasources, but I think there might be something of value to some-select-use-cases where instance data is available to all workflows/actions on demand without relying on external data.

BlowUpVCO.jpg

BlowUpVCOElement.jpg

SeanKohler
Expert
Expert


Well 100K hasn't completed yet, unfortunately (16 hours later).  It has loaded up about 70,000 records and is still moving along slowly. It is probably possible that the client is receiving refreshes that is slowing the workflow down.  (As I left the client open last night, though it was on the workflow tab and not on the Elements tab... so it shouldn't have required refreshed data.)  I am running the last 30K with the client closed/disconnected.  I want to see how it behaves after the attributes are all in there.

It isn't looking good for 100K entries so far... at least not accessed via the GUI.  It may work perfectly well programmatically.

BlowUpVCO100K.jpg

tschoergez
Leadership
Leadership

moved to the Orchestrator communities...

Great discussion, folks! Smiley Happy

Joerg

Reply
0 Kudos
cdecanini_
VMware Employee
VMware Employee

I have the answer on this one.

The configuration elements were designed to create configuration set of attributes in the vCO client.

I was the one who requested this feature to engineering in 2006 ! The reason was that it was taking too much effort to edit workflow attributes including specific vCO server / environment configuration when sending packages back and forth from the Dunes office to customers / partners.

Once the feature was introduced I requested a way to update an existing attribute programatically so I could include a workflow wizard setting the not yet set attributes I delivered as part of a package.

Then one day by mistake I did a typo when setting a config element attribute and notived it created a new attribute. Since I wished I could specify the type of the created element instead on relying on the assumed type I had a chat with the engineer who worked on the config elements. Basically he said that the fact that the element was created was a bug, that the way the config elements were designed was not safe / scalable to handle the programmatic approach and that if I would open a bug they would certainly remove the ability to create attributes via the scripting ...

So I went back to my desk, resumed my work and never filled a bug since I had already delivered many projects using that bug / feature !

If I recall correctly these attributes are stored as part of an XML, each XML is a record in the DB (I do not have the time to check ATM). Changing elements in a loop may not be good for performance

There are alternatives that would be more suited to mass changes such as :

  • creating a new resource element, create a new JS objects where you set your many values and save this JS object as JSON in the resource element using string = JSON.stringify(jsObject). You can then pull all the properties back using JSON.parse(string) (using resourceElement.getContentAsMimeAttachment().content).
  • using the DB plug-in
If my answer resolved or helped you, please mark it as Correct or Helpful to award points. Thank you! Visit http://www.vcoteam.info & http://blogs.vmware.com/orchestrator for vCenter Orchestrator tips and tutorials - @vCOTeam on Twitter
cdecanini_
VMware Employee
VMware Employee

And also there is something that you should know :

When you use a configuration element attribute it is loaded when the workflow start. If during this workflow execution another workflow change an attribute in the config element the first workflow will not reload it.

The technique I used to avoid this is to get the config element in a nexted workflow in your main workflow.

Also the same issue exist when writing an attribute. The last workflow writing to the config element is the one who will save the whole set of attributes, loosing modifications done by other workflows. To avoid this you have to use the vCO locking system to make sure there is a lock set before the element is loaded and unlock after it has been written to / before the next workflow reloads it.

While I made this work it is a lot of extra efforts / possible issues to troubleshoot in order to use configuration elements for waht they were not designed in the first place.

If my answer resolved or helped you, please mark it as Correct or Helpful to award points. Thank you! Visit http://www.vcoteam.info & http://blogs.vmware.com/orchestrator for vCenter Orchestrator tips and tutorials - @vCOTeam on Twitter
robrtb12
Enthusiast
Enthusiast

Thanks for the background information as well as never filling the bug! 



Reply
0 Kudos
qc4vmware
Virtuoso
Virtuoso

I should probably start making more use of resource elements.  For some reason they always feel cumbersome/awkward to me to work with.  The simple key/value pairing I get with the configuration elements/attributes is nice plus i like being able to hop over there in the client and quickly edit something.

Seriously though don't take away any of the current abilities (the bug we've been referencing).  That would cause quite a sting for me!

Reply
0 Kudos
SeanKohler
Expert
Expert


So I have been quite a bit sick for a few days... but back to working speed now.

Thanks for the background Christophe.  It is really interesting.

I think it is unfortunate that the unintended result of your request for bound-workflow-external-elements isn't being looked at more closely as an important product capability to be refined with FULL CRUD methods.  This isn't just a bug... it is architecture elegance.  I think it is important to have data that can exist external to a workflow, internal to the overall VCO execution space.  You identified the need, and they implemented it.  Somewhat...

I don't think the capability was taken to its logical end, however.  If you can have a *widget*... you should be able to work with the widget in a meaningful way through defined methods against the widget class.  We have partial read, partial update, an overload create through the update method, and no delete.  It needs to be refined.  It needs to be made better!  Especially if we are relying on the capability for our production services, as it seems many people are.

>>>When you use a configuration element attribute it is loaded when the workflow start.

This is true when bound/linked to a workflow Attribute.  The bind capability is a good one, but that is certainly not the only use case. The "current" data that is held in the variable can be pulled at any time.  Here is an example where in a script, the data was one thing and then changed to another and the new data used...

System.log(ElementsDemos.getAttributeWithKey("changeMeString").value);

// Update changeMeString with new string value
ElementsDemos.setAttributeWithKey("changeMeString","this is my string");

// Get what it changed to....
System.log(ElementsDemos.getAttributeWithKey("changeMeString").value);

>>> The last workflow writing to the config element is the one who will save the whole set of attributes, loosing modifications done by other workflows. To avoid this you have to use the vCO locking system to make sure there is a lock set before the element is loaded and unlock after it has been written to / before the next workflow reloads it.

I am not seeing this so far.  I need to reproduce it.  The setAttributeWithKey method doesn't seem to do an entire CE rewrite  (all Attributes), but I will see if I can get some workflow concurrency going to validate.

As far as "last write wins" goes, I think that can be acceptable depending on what you are trying to do and how frequent you expect updates to occur.  For example, I have one use case where I merely want to allow a couple of Administrators have the ability to update an Array that holds Resource Actions.  That Array is then used to push out Entitled Actions to many business groups.  The Array update procedure would be infrequent as it would only be required when a new Resource Action was built... and it would only be done by a couple of select individuals.  Due to this, it would be less likely that there would be a "last write" concern for this particular process.

Thanks again for taking a moment to provide all the info.  I am going to continue to push for BETTER configuration elements, regardless of what the initial intent of the design was.  Redesign it if necessary.  It is the capability that is important: not the implementation.

Regards,

Sean

Reply
0 Kudos
SeanKohler
Expert
Expert


The result on the 100,000 Attributes in a Configuration Element = surprisingly pretty good.

BlowUpVCO100Kresult.jpg

1 Million Attributes next?  For the heck of it?

Reply
0 Kudos
mpuckett259
Contributor
Contributor

I wanted to jump in here, I know this is a really old post, but it looks like in vRO 7.x a function was created to accomplish this task.

Example:

Server.createConfigurationElement(configElementPath,configElementName);

The function is a member of the "Server" object which is the vRO server itself.

People that have already posted in this thread probably know this by now, but an FYI for anyone that happens upon this thread like I did.

qc4vmware
Virtuoso
Virtuoso

Heh... I'm not certain I was aware of this.  Thanks for sharing!

Reply
0 Kudos