Git Integration in vRO

[emacintosh]

Hi all, is anyone successfully using the GIT integration in vRO?  We are trying to implement it, but the functionality is confusing or counter intuitive, and I can't find any documentation on how it's supposed to actually work.

Today, we use LCM to migrate vRO objects between environments.  But we are moving to the SaaS offering and would love to be able to retire our on-prem LCM and IDM boxes.  If we can use the built-in git integration, that would be perfect.

We're not new to git, but we are new to the vRO implementation.  Our plan was to do our dev in one vRO then push those changes to a branch, then merge that branch with master.  Then in our prod vRO, we would pull from master.  And maybe occassionally in the dev vRO we may discard any local changes and pull from master as well - as a sort of reset.

But we're finding that if we try to push a changed object to git, we start getting merge conflicts for objects we didn't select.  We've also seen other behavior like a bunch of built-in workflows getting deleted during a Push.  Not a pull, but while pushing.  

And then we've seen a Pull not overwrite local objects with those in the git repository, which seems to defeat the purpose.

So for us, it doesn't seem like this implementation of git works at all like what we're used to.  And we haven't even got to the complicated parts yet, e.g. syncing a config element so the IDs are the same between environments, but not syncing the attributes/variables because those are unique between environments.

Has anyone figured this out?  Are there any resources out there that actually describe how this is supposed to work?  Seems like yet another area where VMware is like "here's a neat thing....but we won't document it well, so good luck figuring out how it works".  Or maybe it's just a checkbox so that they can say they have git integration even if it's not really a viable option.

[Dimitar Ivanov]

Hi  ,

To address you first concern I am sharing this blog post on the topic for Git integration in vRO https://blogs.vmware.com/management/2022/05/git-repository-integration-in-vrealize-orchestrator.html Please, report back if you see anything not working as described here.

I'm sorry you have faced so many issues.

I can suggest to start with one of them and provide more details and step-by-step instructions of how it can be reproduced. I'll see whether someone from the vRO team can provide some guidance.

[emacintosh]

Thanks  .... i don't think we've come across that blog post in our googling yet, which is weird.  And trying to navigate the docs is never easy - like in the 8.0 docs there's article about setting things up but in the 8.10 docs there is only some gitlab example about updating a python workflow or something.  I don't know...it's odd that there isn't just a page in the docs describing how this all works.  I guess I'm not used the "document by blog" approach that vmware seems to take sometimes.

 

What we have found so far is that if we want to ignore objects, like environment-specific ones or out of the box ones, then we have to ensure that we ignore them off the jump.  So in our case, we have an on-prem vro environment that we want to use to populate the repo initially.  But if we just point it at an empty repo, then we really need to first have a .gitignore in there with all of the things we don't want to track.  Then we do a pull to get the gitignore down locally to vro.  Then the local changes are updated accordingly to not linclude those.  And then we can do our initial push.  

But it's almost like we need to know which objects are tracked out of the box so we know what to ignore from the beginning.

 

And I don't think we'll have any luck syncing configuration element ids w/o syncing their content.  So we may have to do some package export/imports for those, which is sort of disappointing.  We'll keep trying to figure it out for now though.

 

And still no idea how a push resulted in local objects getting deleted at one point, but I don't know if I can reproduce that behavior.  But this is a sample of what we see in the audit logs

 

[emacintosh]

I wanted to follow up here to share where we landed with this.  Although not exactly the vRO sync we want, it is working well enough at the moment.  Make in change in dev -> push it github -> PR to master -> Pull down in prod.  

 

We are using a .gitignore to exclude pretty much everything except for our workflows and actions.  Yes, we do lose local git control of all of that content as well since they are ignored, but the only one remotely problematic is configuration elements.  And most of ours are populated with workflows anyway.  When needed, we'll create them in our dev env, create package, export/import to other env and populate them in those env if needed.  

We specifically chose to ignore as much as possible initially, because it's easier to add an object to be tracked than it is to stop tracking an object that already is.

As a side note, while trying to figure this all out, we kept running into scenarios where our vRO was in some given git state that we didn't want anymore.  We needed to effectively remove any git config and start from scratch.  If you find yourself in that position, there may be a better or more appropriate way to handle, but we just deleted the local git folder on the appliance.  Use with caution of course.

/data/vco/usr/lib/vco/app-server/data/git/__SYSTEM.git

 

Here's out .gitignore if anyone is interested

# ignore built-in links
\.o11n/

# ignore all packages
Packages/

# ignore all resources
Resources/

# ignore all config elements
Configurations/

# include only acme actions by ignoring them all and then negating just the acme ones
Actions/*

!Actions/com/
Actions/com/*
!Actions/com/acme/

# exclude non acme workflows, e.g. oob, plugins, etc.
Workflows/*

!Workflows/ACME*/

 

[Thy Do]

Hi there, 

Did we get around to mitigate id conflict with git controlling Config Elements? Wasn't able to find anything useful when searching around.

Thanks

[aenagy]

Dealing with Config Elements and git integration can be tricky. After seeing what actually gets checked into git I concluded that Configuration Elements fall into three categories: plain text, passwords and inventory pointers. For best results I separated the Configuration Elements into three root level folders to keep them separate. The plain text is self explanatory. The passwords are stored in git without values -- for obvious reasons and were excluded in gitignore. The inventory pointers refer to the endpoints in Inventory such as vCenter or Active Directory were not excluded as we had code that would update the sdkObject (?) ID from one environment to the next.