Just as an FYI, we're continuing our investigation and exploration of this under ticket EDO-5623 UPDATE: we've addressed a lot of these in the current version of Otter.

Adding for ideas: Will need cmdlets to create, edit, delete, start and stop configuration and orchestration work. Allow to accept pipeline input. That way I can schedule at that time, to run an orchestration job, pick the servers based on the results of the orchestration, and run a job at that time for those servers, environments, or roles that fit the criteria.

Thanks for the report; I've logged this as OT-280

John, while on the subject of execution ID's and such, during the logging of a psensure, can we add the psensure key to the log so it always outputs what it is checking and validating? How it is now: INFO : 2018-12-11 20:31:07Z - Configuration drift detected. DEBUG: 2018-12-11 20:31:07Z - Adding to execution plan. DEBUG: 2018-12-11 20:31:11Z - Collecting configuration... DEBUG: 2018-12-11 20:31:11Z - Comparing configuration... INFO : 2018-12-11 20:31:11Z - Configuration matches template. DEBUG: 2018-12-11 20:31:14Z - Collecting configuration... DEBUG: 2018-12-11 20:31:14Z - Comparing configuration... INFO : 2018-12-11 20:31:14Z - Configuration matches template. and so on. Maybe it could log something like "Collecting configuration <key>" and "<key> matches template". That way it would make each line meaningful and bring more value into keeping the logs. Eventually I would like to have a way to save a copy of the txt execution into servicenow so we have a record of it in change management system as well. The url you shared previously will help in doing that I think. This improvement would help as documentation for each change. Thanks!

update: we will be addressing this in Otter 2.2, and rafts will now only sync as needed. This will significantly reduce the time required.

Ticket is submitted along with additional information

I finally bypass this limitation by using adding an argument to the module

Hello Ben Thank you

This problem was linked to https://inedo.com/support/questions/9521

Thanks, I've filed this as OT-275

There have been no changes to the way our products connect to databases in many years, so this is unrelated to an upgrade. However, it seems to be some sort of indication that SQL Server must be overloaded, or a network problem. This can typically be diagnosed / reviewed by the SQL Server DBA, who can see incoming connections, and which queries are taking too long, etc. But in my experience, just restarting the server you have SQL Server installed on fixes it like 80% of the time.

I have emailed you the white paper that has a hands-on example for this.

Apparently this was updated in BuildMaster but not Otter, here is the documentation for the updated version that also applies to yours, substituting $CredentialProperty for $GetCredentialProperty: # ProGetCreds is an instance of Inedo Product Credentials (i.e. InedoProduct::ProGetCreds) with 'Allow encrypted properties...' checked set $key = $CredentialProperty(ProGetCreds, ApiKey); set $host = $CredentialProperty(ProGetCreds, Host); Log-Debug Getting ProGet package from $host with API key: $key; ProGet::Get-Package( Credentials: ProGetCreds, Feed: hdars-1k, Name: hdars, Directory: $WorkingDirectory ); Additionally, I will notify our product director to add an issue to fix this in Otter (it would still be backwards compatible, but the canonical name would become $CredentialProperty)

Those are handled at different abstraction layers; the agent code doesn't have any knowledge of the context its being run in (i.e. OtterScript, the Service, etc). That's the intent of that "with credentials" setup, to allow this information to pass down.

Hi Upgrade Path : Serveur Run the Hub installer on your Otter server -> https://s3.amazonaws.com/cdn.inedo.com/downloads/desktophub/OtterInstaller.exe Extensions (In Admin Menu) /!\ Git Extension shows 1.0.3 after its upgrade while it is expected 1.0.4. but it is working fine Agents. Do not update agent using Otter (Upgrade Agent). I had some trouble with this option. I'd rather upgrade using my software deploiement tools - (Remove old agent, cleanup folder, install new agent) Best Regards Philippe

Thanks, I've accepted and released this change in the Windows extension v1.0.10

You can download the latest (v41 at the time of this post) from here: https://inedo.com/support/documentation/inedoagent/versions

Hello Philippe, If the example code is identical to what you're running, the 10GB is misspelled as 1OGB (with the letter O instead of a zero).

Alright, after messing around with that information, I was able to get it to work. I am able to update the variables. Interesting thing is that it doesn't appear I can change just one variable, I have to change all of them, or at least enter all of them as they are? Thanks for your help!

Hi Jim, Apologies for the lack of response here, but I wanted to let you know that we had quite a bit of back-and-forth internally on this post and implemented nearly all of your expectations: you are absolutely correct about the variable context not behaving as expected, and the biggest problem was that the behavior of certain variables (particularly $RoleName) was undefined we've updated the docs to reflect the "new" behavior in the latest version (v2.1.0 at the time of this post): https://inedo.com/support/documentation/otter/core-concepts/jobs#orchestration-job-context we release v2.1.0 last night with these changes included Thank you again for the detailed report and reproduction steps.