I was able to reproduce this, it only happens when a child environment is created for first time. The case is OTTER-121, and wil be resolved in a future maintenance release.

Pb solved with the 1.5.2

Hi Philippe , I think i understand, but it's much easier to visualize :) Especially once we see your data. could you send a screenshot to us via support - at Inedo - dot com? And feel free to hilite the areas, etc. you suggest to improve.

Hello Thank you for the reply. I use OTTER for a few weeks now, So I have to understand the otter model :) I will apply my DSC in a classical way (start-DSCconfiguration script) Regards Philippe

The easiest option would just be to use the PowerShell Agent, which does not require any installation and simply uses remote PowerShell. However, if you can't use this or don't want to due to performance issues, you can manually install the Otter/Inedo agent by downloading the manual install package for the latest version of Otter here: http://inedo.com/otter/versions The instructions for installing the agent manually can be found here: http://inedo.com/support/documentation/otter/installation/manual

Thanks Philippe, looks like you identified the bug and workaround. It will be addressed as OTTER-119

Wow, cool usage! That sound something fairly general-purpose, so we might be able to incorporate it in the InedoCore extension as well. But yes, you can certainly use Variable Functions for that purpose; I don't believe we have anything that's quite as advanced, but we had definitely intended for usage like that. We just hadn't put in the logging facilities because none of the functions required logging (and the out-of-order logging may seem very strange). But as Dean mentioned, it's definitely doable. Note there is a EvaluateAsync method that might be more suitable for situations like this as well.

There might not be a single API call for this, but there is the Variables Management API (were you can get the variables data), or you could use the Native API to list the deployables.

If restarting fixed it, then the "hanging" was in the service, likely the agent never reported back that the "job" (a very small unit of work, not an Otter job) was complete. Once we add cancellation to the UI, you could confirm that to be the case... Note that, as soon as the Otter service stops, the job will stop running, so the service won't be able to start itself back up. So you will need to have an external process running that will handle the restart, like this: $script = " sleep 10 `$svc = (Get-Service -ComputerName 'inedoappsv1' -Name 'INEDOBMSVC') Try { `$svc.Stop() } Catch { } `$svc.WaitForStatus([System.ServiceProcess.ServiceControllerStatus]::Stopped) `$svc.Start() " Start-Process -FilePath 'powershell.exe' -WorkingDirectory 'C:\Projects\BuildMaster' -ArgumentList @('-NoProfile', '-ExecutionPolicy', 'unrestricted', '-Command', $script) Write-Output 'BuildMaster will be deployed in 10 seconds' It is the relevant parts of a PS script we use to have BuildMaster deploy to itself; it seems to work pretty well.

Thanks Steve! That solved the issue.

Good question; I'm not familiar enough w/ splunk to give a definite answer, but I would assume: the Windows agent and the Linux agent are different binaries the configuration is non-trivial (i.e. more than a couple operations) there is effectively no shared configuration/operations in the plans there is minimal shared configuration (ApiKey or AcocuntNumber) Based on that, I would probably do two separate roles, splunk-linux and splunk-windows or something like that. Of course, if there was mostly shared configuration, or if only a few operations were operating-system dependent (be it Linux or Windows 2003 vs 2008), then having an if/else sort of thing seems fine. One major benefit of the roles here will be, someone looks at it from the dashboard and says "oh ok, Splunk is installed". It's already obvious that it's a Linux vs Windows server. And to me, the ApiKey/AccountNumber/whatever seem like variables on the role (or maybe environment, if it's different in Prod and Integration). Down the line, we'll probably have something to deal with nested roles, role dependencies, those sorts of thing. Really need to see what the data in the field looks like!

Hi Hans... this requires WMF5.0 : https://www.microsoft.com/en-us/download/details.aspx?id=50395

Maybe some kind of checkbox in existing UserNamePassword would be a good solution? For example, a checkbox that clearly indicates that these credentials can only be used in PowerShell?

Whoops, seems like we forgot to update the operations documentation on the site after 1.3. The function is renamed to $GetCredentialProperty (though the old alias should still work) and you can access it like: <code>set $password = $GetCredentialProperty(MyCredential,Password);</code> Note you can see the generated documentation: http://<otter-host-name>/reference/functions

Thanks for the pointer. I noticed if I edit the Job Template it doesn't seem to have the right plan 'selected' in the Plan Name dropdown (it defaults to the first in the list every time). I think I saved it without noticing and it ended up attached to the wrong one. Maybe review the edit code that generates this page: https://url/job-templates/edit?jobTemplateId=x

Looks like there was a packaging issue with the 1.2.0 installer. We'll get a fixed installer posted right away, but you can fix in the meantime by going to the Otter install directory (default is Program Files\Otter) and copying the lib and NativeBinaries directories from the Service directory to the Web\bin directory.

I was able to get Otter to work with TFS Git on-premises. All I needed to do was set the Otter website and service to run as a specific domain user that has rights to the TFS Git repository. Then in the Raft settings, leave the username and password empty. The Otter code will use the "DefaultCredentials" in LibGit2Sharp., which are the credentials of the currently executing service user. This is slightly sub-optimal, but it works. The next thing I would like to understand is why Git rafts are so slow (going to assets is fairly slow to load, ~10 sec) P.S. I never tried setting the "Basic Authentication" in TFS you recommended, as it is a fundamental change that could affect other users and services.

It looks like you probably mean to use an assembly-qualified name instead of the .Name property on line 68: So it probably should be something like: writer.Write(resultType.FullName + "," + resultType.Assembly.GetName().Name); That would generally be the minimum information you'd need to get the type with Type.GetType. That said, as you've discovered, RemoteJob is a pretty low-level interface, meant to give complete control over any over-the-wire serialization. You may want to look at the RemoteEnsureOperation as a base class to use instead, which handles the RemoteJob details internally - you just add the [SlimSerializable] attribute to properties that you want to be serialized and it takes care of the rest. You also may find the SlimBinaryFormatter class useful - it is the class that RemoteEnsureOperation uses to perform its serialization. Hope this helps!

Thanks; logged as [OTTER-77] and we will fix in next maintenace release!

We have identified and fixed the bug responsible for this, and will have it fixed in the next maintenance release (Otter 1.1.5). Thanks for the bug report!