Tagging via vRO, issues with similar entries overwriting

[Dlally1]

I'm having some issues and I feel like it might be an easy fix, just not for me 🙂

I'm running a simple workflow to apply vsphere tags to a deployment.  The issue is any similar entry just overwrites the previous entry.

var tags = inputProperties.tags || new Properties();

tags.put("Test",123);
tags.put("Test",456);

The example above, only the values Test 456 would pass to the tags properties since they both use the same key "Test" and the 456 was the last one that ran.

Is there a way I can append this so it would add an entry per?

[eoinbyrne]

If that's Javscript then the Properties map is functioning correctly here - Properties is a HashMap so each key points to one and only one value

i.e., you have a map with the following initially

"Test" --> "123"

When you use put("Test", "456") your map changes to

"Test" --> "456"

As your put() call sets the value referred to by the key "Test" to a new value

I'm not sure how your tagging workflow operates as you haven't said, but, I would think that if the tagging system supports multiple tags for the same key/name then you could try this?

tags.put("Test", ["123", "456"])

That is to say, put an array of values for the tag name.

[Dlally1]

So my workflow is pretty basic as I put in the original post.  I dabble in javascript and am usually pretty good at googling what I want to do and adjusting the code to work for me.  However this is not one of those times 🙂

Your idea didn't work as vRA expects a string, and that passes an array

[Dlally1]

So my workflow is pretty basic as I put in the original post.  It's literally just pushing the value's I want into the tag properties.

I dabble in javascript and am usually pretty good at googling what I want to do and adjusting the code to work for me.  However this is not one of those times 🙂

Your idea didn't work as vRA expects a string, and that passes an array

[eoinbyrne]

OK, like I said, I have no idea what your workflow does. If you're sure that the target tag can hold multiple values (is it vCenter tags?)  then why not just call your tag function/action/workflow twice for two different tag values

e.g

tags.put("Test", 123);

tagIt(tags); // no idea what your tag function is called but put what call you need to here to deliver the tag to the target

// then repeat with the 2nd value

tags.put("Test", 456);

tagIt(tags);

This should be viable if the target supports multiple values. If not then the second call will overwrite the first value and at least you'll know where you are then

[Dlally1]

Sorry maybe I'm not understanding.  There's not really anything else to add to the workflow.  I have logic to define what tags to assign.  But the code in the original post is really all it does.  Pushes a tag to the properties and then applies it.  The category in vcenter (key in vRA) are all under the same category name.   These are being kicked off during compute allocation in extensibility to update the tags.  

I've literally broke out each tag into their own workflow and they run one after another.  However even doing it that way, the last workflow ran value takes.  So each time the workflow runs, they still overwrite the previous entry. 

[eoinbyrne]

I guess I'd really have to see what your workflow does to be able to progress. When I did this for VM tags I used the vCenter CIS REST API and it's able to create multiple tags in the same category for the VM

e.g.,

OS / WIndows & OS / Windows2016

My approach was to locate (or create) the Category by name, then locate (or create) the Tag value in the Category, then attach that Tag ID to the VM object.

It sounds to me like the workflow does not have clean way to differentiate between different Tag values for the same Category, or perhaps takes a blanket view of the Tag set and does a remove-all-existing-tags first and then adds whatever is in the Property map provided by the caller.

You could try drilling into the workflow code or logs to see what sequence of operations it follows for it's execution - you may be able to either confirm the approach used or ideally, spot a way to pass data in a form that will permit what you want