Git Product home page Git Product logo

wins's Introduction

Rancher Wins

Build Status Go Report Card

wins is a way to operate the Windows host inside the Windows container.

How to use

Modules

> wins.exe -h
NAME:
   rancher-wins - A way to operate the Windows host inside the Windows container

USAGE:
   wins.exe [global options] command [command options] [arguments...]

VERSION:
   ...

DESCRIPTION:
   Rancher Wins Component (...)

COMMANDS:
   srv, server
   cli, client
   up, upgrade  Manage Rancher Wins Application
   help, h      Shows a list of commands or help for one command

GLOBAL OPTIONS:
   --debug        Turn on verbose debug logging
   --quiet        Turn on off all logging
   --help, -h     show help
   --version, -v  print the version

Server (run on Windows host)

> wins.exe srv -h
NAME:
   rancher-wins srv - The server side commands of Rancher Wins

USAGE:
   rancher-wins srv command [command options] [arguments...]

COMMANDS:
     app, application  Manage Rancher Wins Application

OPTIONS:
   --help, -h  show help

Client (run inside Windows container)

> wins.exe cli -h
NAME:
   rancher-wins cli - The client side commands of Rancher Wins

USAGE:
   rancher-wins cli command [command options] [arguments...]

COMMANDS:
     hns               Manage Host Networking Service
     hst, host         Manage Host
     net, network      Manage Network Adapter
     prc, process      Manage Processes
     route             Manage Routes
     app, application  Manage Rancher Wins Application

OPTIONS:
   --help, -h  show help

Examples

# [host] start the wins server
> wins.exe --debug srv app run --listen rancher_wins

# [host] verify the created npipe
> Get-ChildItem //./pipe/ | Where-Object Name -eq "rancher_wins"

Developer Documentation

# [host] build local wins and run it as a service for testing/debugging
git clone https://github.com/rancher/wins.git
Set-Location wins
Set-Location $(Get-Location).path

# build the project using the magefile
go run mage.go build

copy-item bin/wins.exe .
$WINS_PATH = $(Get-Location).Path

New-Service -Name rancher-wins -BinaryPathName "$WINS_PATH\wins.exe --debug srv app run" -DisplayName "Rancher Wins" -StartupType Manual
Set-Service -Name "rancher-wins" -Status Running -PassThru # start the rancher-wins service and output servicecontroller[]
$(Get-Service -name "rancher-wins").Status # verify that the new rancher-wins service is running

# [host] how to replace the wins.exe binary the service uses during active development
Set-Service -Name "rancher-wins" -Status Stopped
$(Get-Service -name "rancher-wins").Status # verify the service stopped
Set-Service -Name "rancher-wins" -Status Running -PassThru # restart the service with the freshly built wins binary

# change the startup type of rancher-wins from automatic to manual
Set-Service -Name "rancher-wins" -StartupType Manual

Query the host network adapter

# [host] start a container
> $WINS_BIN_PATH=<...>; docker run --rm -it -v //./pipe/rancher_wins://./pipe/rancher_wins -v "$($WINS_BIN_PATH):c:\host\wins" -w c:\host\wins --entrypoint powershell mcr.microsoft.com/windows/servercore:ltsc2019

# [inside container] query the host network adapter
>> .\wins.exe cli network get
{"InterfaceIndex":"7","GatewayAddress":"10.170.0.1","SubnetCIDR":"10.170.0.0/20","HostName":"frank-wins-dev","AddressCIDR":"10.170.15.229/32"}

Enabling Process and Port Access

To configure wins properly to break out of a container you need to configure a list of processes and ports which are granted permission for wins to use. This is done with the white_list configuration options.

white_list:
  processPaths:
   - c:\path\to\my.exe
  proxyPorts
   - 8888

Start a process on the host

# [host] download nginx 
> Invoke-WebRequest -UseBasicParsing -OutFile nginx.zip -Uri http://nginx.org/download/nginx-1.21.3.zip

# [host] expand nginx in the current directory
> Expand-Archive -Force -Path nginx.zip -Destination c:\nginx

# [host] start a container
> $WINS_BIN_PATH=<...>; echo "`$NGINX_BIND_DIR=$NGINX_BIND_DIR"; docker run --rm -it -v //./pipe/rancher_wins://./pipe/rancher_wins -v "$($WINS_BIN_PATH):c:\host\wins" -v "c:\nginx:c:\nginx" -w c:\host\wins --entrypoint powershell mcr.microsoft.com/windows/servercore:ltsc2019

# [inside container] start nginx and receive the running output
>> .\wins.exe cli app run --path c:\nginx\nginx-1.21.3\nginx.exe --exposes TCP:80

# [host] verify the process
> Get-Process rancher-wins-*
> curl.exe 127.0.0.1

Enabling System Agent functionality

The system agent functionality will only be enabled if the configuration section for the system agent is found in the config file. To enable it, provide the following configuration section with the required settings. If remoteEnabled is set to true then connectionInfoFile will need to be configured.

systemagent:
  appliedPlanDirectory: <agent dir>/applied
  connectionInfoFile: <agent dir>/connection.yaml
  localEnabled: <bool>
  localPlanDirectory: <agent dir>/plans
  preserveWorkDirectory: <bool>
  remoteEnabled: <bool>
  workDirectory: <agent dir>/work

Enabling CSI Proxy functionality

The CSI Proxy will only be enabled if the configuration section is found in the config file. To enable it, provide the following configuration section with the required settings. The url setting is expected to be formatted for use in a Go's sprintf format. An example is provided below for the formatting. Once enabled Wins will download the CSI Proxy, create the Windows service, and start the service.

csi-proxy:
  url: <url to download the CSI Proxy binary>
  version: <version to download>
  kubeletPath: <path to kubelet>

Example:

csi-proxy:
  url: https://acs-mirror.azureedge.net/csi-proxy/%[1]s/binaries/csi-proxy-%[1]s.tar.gz
  version: v1.1.1
  kubeletPath: c:/etc/kubelet.exe

Enabling Certificate Support for Wins

Wins now supports consuming a certificate when it is required for pulling the CSI proxy tarball from a Rancher Server. Common situations where this is required are airgapped Rancher environments and self-signed Rancher installations.

tls-config:
  insecure: <true/false>
  certFilePath: <path to local certificate>

Example:

tls-config:
  insecure: false
  certFilePath: c:/etc/rancher/agent/ranchercert

Build

This project uses magefile to build. The default target is build.

> go run mage.go <target>

Testing

There are not any Docker-in-Docker supported Windows images for now, rancher/wins has to separate the validation test and integration test.

For validation test, which could be embedded into a containerized CI flow, please run the below command in PowerShell:

> go run mage.go validate

For integration test, please run the below command in PowerShell:

> go run mage.go integration

Note: Don't use bin/wins.exe after integration testing. Please go run mage.go build again.

If want both of them, please run the below command in PowerShell:

> go run mage.go TestAll

License

Copyright (c) 2014-2023 Rancher Labs, Inc.

Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at

http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an " AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.

wins's People

Contributors

aiyengar2 avatar billhong-just avatar harrisonwaffel avatar jakefhyde avatar luthermonson avatar macedogm avatar mweibel avatar oats87 avatar pennyscissors avatar phillipsj avatar pjbgf avatar renovate-rancher[bot] avatar rosskirkpat avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

wins's Issues

wins cli proxy: error in remotedialer server [500]: connect not allowed

Context in https://github.com/rancher/rancher/issues/32535#issuecomment-832362462.

PS C:\Users\Administrator> Get-EventLog -LogName Application -Source rancher-wins -ErrorAction Ignore | Sort-Obj
ect Index | %{ $_.Message }
Stackdump - waiting signal at Global\stackdump-3592
Listening on \\.\pipe\rancher_wins_proxy
Listening on \\.\pipe\rancher_wins
currentVersion.Major > versionRange.MaxVersion.Major: 11, 9
currentVersion.Major > versionRange.MaxVersion.Major: 11, 9
currentVersion.Major < versionRange.MinVersion.Major: 11, 12
currentVersion.Major > versionRange.MaxVersion.Major: 11, 10
currentVersion.Major < versionRange.MinVersion.Major: 11, 12
currentVersion.Major < versionRange.MinVersion.Major: 11, 13
currentVersion.Major > versionRange.MaxVersion.Major: 11, 9
currentVersion.Major > versionRange.MaxVersion.Major: 11, 10
currentVersion.Minor < versionRange.MinVersion.Major: 10, 11
currentVersion.Major < versionRange.MinVersion.Major: 11, 12
currentVersion.Major < versionRange.MinVersion.Major: 11, 13
currentVersion.Major < versionRange.MinVersion.Major: 11, 13
currentVersion.Major > versionRange.MaxVersion.Major: 11, 9
currentVersion.Major > versionRange.MaxVersion.Major: 11, 9
currentVersion.Major < versionRange.MinVersion.Major: 11, 12
currentVersion.Major > versionRange.MaxVersion.Major: 11, 10
currentVersion.Major < versionRange.MinVersion.Major: 11, 12
currentVersion.Major < versionRange.MinVersion.Major: 11, 13
currentVersion.Major > versionRange.MaxVersion.Major: 11, 9
currentVersion.Major > versionRange.MaxVersion.Major: 11, 10
currentVersion.Minor < versionRange.MinVersion.Major: 10, 11
currentVersion.Major < versionRange.MinVersion.Major: 11, 12
currentVersion.Major < versionRange.MinVersion.Major: 11, 13
currentVersion.Major < versionRange.MinVersion.Major: 11, 13
could not get checksum for "c:\\etc\\rancher\\wins\\wins.exe": open c:\etc\rancher\wins\wins.exe: The process ca
nnot access the file because it is being used by another process.
could not get checksum for "c:\\etc\\rancher\\wins\\wins.exe": open c:\etc\rancher\wins\wins.exe: The process ca
nnot access the file because it is being used by another process.
Handling backend connection request [rancher-monitoring-windows-exporter-ldck9]
error in remotedialer server [500]: connect not allowed

Related Issue: https://github.com/rancher/rancher/issues/32535

Slight confusion with version requirements

Hello All,

Please help and clarify this requirement.

Most of us have probably come to this helm chart via:

https://rancher.com/docs/rancher/v2.5/en/monitoring-alerting/windows-clusters/#cluster-requirements

And the need to upgrade to a wins version >= v0.1.0.

The helm Readme requirements state:

"A Windows Service called rancher-wins is currently running on each Windows host that is running a wins server version of v0.1.0+."

I have a wins version of 0.0.4 running on my nodes.. so please confirm if it's possible for me to use this Helm chart or not.

Thank you

Parse Args with Spaces

Per another issue in kubernetes-sigs/sig-windows-tools wins will parse the --args flag by a space which makes it impossible to pass in args with spaces e.g. --interface=Ethernet2 0.

gz#12873

in widows container , wins cli process run error ( rpc error: code = Unavailable desc = transport is closing )

rancher-wins version v0.0.4
winodws server 1809
1๏ผš start srv
Write-Host "Registering wins service"
wins.exe srv app run --register
start-service rancher-wins

2: start client
wins cli process run --path /k/flannel/flanneld.exe --args "--kube-subnet-mgr --kubeconfig-file /k/flannel/kubeconfig.yml" --envs "POD_NAME=$env:POD_NAME POD_NAMESPACE=$env:POD_NAMESPACE"

error:
FATA[2021-12-14T10:10:33+08:00] rpc error: code = Unavailable desc = transport is closing

landing page/wiki

Hi folks.

Was thinking as a starter to make a github.io page or something , would that be acceptable?

Wins crashing

Hi,

I seem to have an issue with wins crashing about 30minutes after starting it. Usually I start it as a service in windows but since its crashing I started trying to start it from cmd.

This log is from wins v0.1.2-rc2, however the crash occurs in v0.1.1 as well but cmd crashed/disappeared when running that version so I have no logs from v0.1.1.

Additionally I would like to add that setting log-level doesn't work either, I get "flag provided but not defined: -log-level" when trying to run: "wins.exe srv app run --log-level debug"

>wins.exe srv app run
WARN[2021-12-03T14:40:16+01:00] cannot upgrade unless the current process is being executed as a Windows service
INFO[2021-12-03T14:40:16+01:00] listening for tcp requests on rancher_wins_proxy destined for: []
INFO[2021-12-03T14:40:16+01:00] Rancher System Agent configuration now found, not starting system agent.
INFO[2021-12-03T14:40:16+01:00] Listening on \\.\pipe\rancher_wins_proxy
INFO[2021-12-03T14:40:16+01:00] Listening on \\.\pipe\rancher_wins
WARN[2021-12-03T14:44:33+01:00] [Process] Found stale process rancher-wins-flanneld(7124), try to recreate a new process
WARN[2021-12-03T14:44:50+01:00] [Process] Found stale process rancher-wins-ngin(360), try to recreate a new process
panic: sync: negative WaitGroup counter

goroutine 752 [running]:
sync.(*WaitGroup).Add(0xc0004007f0, 0xffffffffffffffff)
        c:/go/src/sync/waitgroup.go:74 +0x147
sync.(*WaitGroup).Done(0xc0004007f0)
        c:/go/src/sync/waitgroup.go:99 +0x3b
google.golang.org/grpc.(*Server).serveStreams.func1.2(0xc0004007f0, 0xc00034ce00, 0x28fb0b8, 0xc000055e00, 0xc00028a000)        C:/gopath/pkg/mod/google.golang.org/[email protected]/server.go:879 +0xc5
created by google.golang.org/grpc.(*Server).serveStreams.func1
        C:/gopath/pkg/mod/google.golang.org/[email protected]/server.go:876 +0x1fd

rancher-windows-exporter not working on AWS EKS

Rancher windows exporter is running AWS EKS with wins version 0.1.3. However, we see the following with exporter-node-proxy:

INFO[2022-02-03T18:22:38-05:00] Connecting to proxy                           url="ws://rancher_wins_proxy"
ERRO[2022-02-03T18:23:48-05:00] Error writing ping                            error="i/o timeout"
ERRO[2022-02-03T18:23:48-05:00] Error writing ping                            error="i/o timeout"
FATA[2022-02-03T18:23:48-05:00] i/o timeout
2022/02/03 18:23:48 tcpproxy: for incoming conn 10.136.180.113:43510, error dialing "": i/o timeout
2022/02/03 18:23:48 tcpproxy: for incoming conn 10.136.185.172:46670, error dialing "": i/o timeout
2022/02/03 18:23:48 tcpproxy: for incoming conn 10.136.185.172:45154, error dialing "": i/o timeout

The bottom three IPs are prometheus. However, I can get onto the EC2 instance hosting the rancher-windows-exporter pod and curl http://localhost:9796/metrics and can get all the metrics. If I exec into another node in any namespace and curl the EC2 instance primary IP such as http://10.136.111.222:9796/metrics it works. The servicemonitor picks up the IP of the pod running rancher-windows-exporter which doesn't work.

rancher-wins service crashing on windows server 2019

rancher-wins service is crashlooping. Appreciate any guidance / insight on this issue.

system details

  • windows server 2019 in vmware
  • latest version of vmware tools installed
  • all windows updates / patches applied
  • rancher-wins v0.0.4 installed via usual PrepareNode.ps1 v0.1.6

issue

  • rancher-wins windows service starts up, then crashes inconsistently when firing a test command wins cli net get
  • errors are not consistent
  • errors appear to be originating from something in windows runtime

please see the following gist of errors

image

Add support for publishing ports

Wins currently supports exposing ports on the host via an --exposes "{TCP|UDP}:{Port}" option on a running process.

There should be a similar option available for --publishes "{TCP|UDP}:{Port}" that allows a container to publish a port available on the host network as a container port. This would allow privileged containers using wins to avoid exposing a port on the host itself when it only needs to be exposed on a container-level (e.g. inter-Pod communication for Kubernetes vs. inter-Node communication).

wins.exe does not work on nanoserver

Command wins cli net get failed with error:

FATA[2020-11-14T13:09:42+03:00] rpc error: code = Unavailable desc = all SubConns are in TransientFailure, latest connection error: connection error: desc = "transport: Error while dialing open \\\\.\\pipe\\rancher_wins: Access is denied."

when it run on nanoserver as ContainerUser.
It works fine when it run on servercore or on nanoserver as ContainerAdministrator.

cli prc command checks Container Pathing

there's been a usability problem with wins for quite some time regarding the cli prc command. the idea is youre calling out to the host via grpc to execute the exe on the host. the process to do this is from a container and since this code here

func GetBinaryPath(binaryName string) (string, error) {
// find service abs path
p, err := exec.LookPath(binaryName)
if err != nil {
return "", err
}
p, err = filepath.Abs(p)
if err != nil {
return "", err
}
// detect service is file or not
fi, err := os.Stat(p)
if err == nil {
if !fi.IsDir() {
return p, nil
}
err = errors.Errorf("%s is directory", p)
}
if filepath.Ext(p) == "" {
p += ".exe"
fi, err := os.Stat(p)
if err == nil {
if !fi.IsDir() {
return p, nil
}
return "", errors.Errorf("%s is directory", p)
}
}
return "", err
}

this code is run in the container via cli prc and it checks the container for the binary and then calls the binary via grpc on the host meaning the binary has to be in both locations. in the container and on the host. we've basically been getting around this problem with copying files everywhere in run.ps1 powershell scripts.

proposal... add grpc logic so the cli prc command asks the host via the socket if the binary is there, is the right hash etc.

Wins Installer Script needs to test for registry key first.

If registry key doesn't exist the following error occurs.

>>         $PROXY_ENV_INFO = Get-ChildItem env: | Where-Object { $_.Name -Match "^(NO|HTTP|HTTPS)_PROXY" } | ForEach-Object { "$($_.Name)=$($_.Value)" }
>>         if ($PROXY_ENV_INFO) {
>>             $newEnv += $PROXY_ENV_INFO
>>             Set-ItemProperty HKLM:SYSTEM\CurrentControlSet\Services\$serviceName -Name Environment -PropertyType MultiString -Value $newEnv
>>         }
Set-ItemProperty : A parameter cannot be found that matches parameter name 'PropertyType'.
At line:5 char:100
+ ... trolSet\Services\$serviceName -Name Environment -PropertyType MultiSt ...
+                                                     ~~~~~~~~~~~~~
    + CategoryInfo          : InvalidArgument: (:) [Set-ItemProperty], ParameterBindingException
    + FullyQualifiedErrorId : NamedParameterNotFound,Microsoft.PowerShell.Commands.SetItemPropertyCommand

Before calling Set-ItemProperty we need to test that it exists first and if it doesn't call New-ItemProperty, if it does, call Set-ItemProperty

Add Built-in Logging

Add the ability to run the rancher windows log collection script through wins

The end goal is to allow support log bundles for windows worker nodes to be generated from the Rancher UI, similar to Longhorn's support bundles.

EPIC [wins] Support upgrading wins version / config on Windows hosts

This issue is an Epic that tracks several other issues around supporting wins upgrades to the version or configuration across all hosts in a Windows cluster.

Tasks

  • Support .\wins.exe up[grade] (#23)
  • Create build images for wins (#24)
  • Add Helm chart for wins upgrade (#20)
  • Expose Helm chart on Rancher Helm repository (rancher/rancher#31504)

Note

Related to rancher/rancher#28327, which requires wins upgrades across Windows hosts in the cluster to be able to be deployed

processPrefix renames busybox64.exe, which breaks it

  1. Try to run busybox64.exe using wins.
  2. Observe it renames the executable to rancher-wins-busybox64.exe.
  3. This breaks busybox64.exe with error rancher-wins-busybox64: applet not found, because its functionality depends on the name of the command that executes it.

There should probably be a way to execute a file without renaming it.

Make a windows service package

processPrefix should be configurable

We may not want to expose "rancher-wins" names on a host in all cases, and in some cases, we may want to disable this renaming of the process (for example, if you want to hack a patch into a file, you might want rancher to just run the file as-is). Also there might be security or other reasons why you dont want to expose that as a process name.

Would it break anyhing to change https://github.com/rancher/wins/blob/master/pkg/apis/process_service.go#L20 to , say, a cmd line option or environment variable ?

Support upgrading wins via wins up

Adds support for running .\wins up[grade], which runs a Powershell script within wins that restarts the service with a different wins server binary.

This is an alternative to the current mechanism for upgrades that wins provides wherein it watches for a path and utilizes checksums to see whether the service should be modified / restarted and can also be used as an alternative method to enable wins on a Windows host (e.g. you can just run .\wins up instead of .\wins srv app run --register; Start-Service -Name rancher-wins).

The primary use case of this feature is to support a new Helm chart that will allow users to maintain wins configs / wins versions across entire clusters using just a Helm chart for configuration. This Helm chart uses wins (cli) to pass wins (upgrade) to wins (server) in order to update wins (server) on the host on demand. More succinctly it runs:

# Transfer the generated config to the directory
Transfer-File -Src "c:\scripts\config" -Dst "c:\host\etc\rancher\wins\config"
# Force a restart of wins server, which will naturally use the newly generated config
wins.exe cli prc run --path=$pathToWinsBinary --args="up --wins-args=`'--register --config=$pathToWinsBinaryDir\config`'"

Flapping Pod Access is Denied to the rancher-wins- prefixed executable

using wins server and a wins process run call you can get into a bad state where there's no access to a backup file we're putting in the temp folder for the system. The backup is not used again by wins and sits around for not much purpose or reason.

Logs look like this basically...

{"log":"\u001b[31mFATA\u001b[0m[2021-12-08T16:42:07-06:00] rpc error: code = Internal desc = could not rename binary: could not backup the existing target file: rename c:\\etc\\nginx\\rancher-wins-nginx.exe C:\\Windows\\TEMP\\rancher-wins-nginx.exe: Access is denied. \n","stream":"stdout","time":"2021-12-08T22:42:07.8392692Z"}

cause: wins takes the path you want to exec and copies it to a rancher-wins- prefixed exec and then calls that exec. wins is supposed to release this kill and release this process when the client disconnects but if you crash wins and some how get into a state where it's not running as admin and windows server put the the file in C:\Windows\TEMP it can spiral. On win10 it'll be in AppData with full access but the C:\Windows directory is pretty fickle on a datacenter os.

solution: We're going to stop using the os temp dir entirely and just delete the copied rancher-wins- prefixed file. if a process is still using by some errant wins process it could still be an issue but if it's being managed by the service manager this should be cleaner

Skip Checksum option?

Hi folks.

Would like an option to skip checksumming. My use case is ....

... in cases where i want to patch a binary on the host - i may want to start a process by simply calling wins from a container, without first copying my local contents over.

Workaround, in cases where you need to patch a container that is started from a ps1 script, you can add a wget or similar command into the containers startup, so that its path value is identical to what is on the host. of course this comes at the cost of having to mount/copy/upload your patched file somewhere.

Add Helm chart for wins upgrades

Packages #23 into a Helm chart that supports maintaining 1 or more configuration of wins across Windows hosts in a k8s cluster.

Requirements for Testing:

  • Need to be able to specify winsConfigs that should be applied to hosts based on nodeSelectors and tolerations
  • Need to be able to upgrade wins binary alone for a set of hosts
  • Need to be able to upgrade wins config alone for a set of hosts
  • Need to be able to upgrade both wins binary and wins config in one shot
  • Need to be able to take an existing Windows cluster and successfully deploy this chart even if the processPath for wins upgrade is not whitelisted (e.g. masquerading)

Masquerading

Instead of requiring a user who deploys this chart to have to manually upgrade every single windows host to whitelist the path that will contain the version of wins we plan to update to, users should be able to select one option that automatically masquerades the payload of wins upgrade under another whitelisted path. That way, you can bootstrap the upgrade processPath workflow on an existing cluster as a one time step and then switch to the normal upgrade path.

e.g.

masquerade:
  enabled: false  
  as: c:\\etc\wmi-exporter\wmi-exporter.exe 

application_test.ps1 fails when the version is dirty or a release version

The logic in the following code will always result in a failure when executing tests on a tagged commit since it checks that the reported version by the wins binary is equivalent to the commit hash.

$version = Execute-Binary -FilePath "git.exe" -ArgumentList @("rev-parse", "--short", "HEAD") -PassThru
if (-not $version.Ok) {
Log-Error $version.Output
$false | Should -Be $true
}

This results in the following error on jobs:

Starting discovery in 1 files.
Discovery found 3 tests in 1.02s.
Running tests.
Error: [-] application.upgrade.watching 39.52s (39.52s|3ms)
Message
Tests completed in 45.69s
Tests Passed: 2, Failed: 1, Skipped: 0 NotRun: 0
FATA Failed to pass D:\a\wins\wins\tests\integration\application_test.ps1
Error: running "powershell.exe tests\integration\integration_suite_test.ps1" failed with exit code 1
Error: Process completed with exit code 1.

Failed Job: https://github.com/rancher/wins/actions/runs/8851112339/job/24306934261

The fix for this issue should be to change the logic here to match the logic within the magefile:

func Version() error {
c, err := magetools.GetCommit()
if err != nil {
return err
}
commit = c
dt := os.Getenv("DRONE_TAG")
isClean, err := magetools.IsGitClean()
if err != nil {
return err
}
if dt != "" && isClean {
version = dt
return nil
}
tag, err := magetools.GetLatestTag()
if err != nil {
return err
}
if tag != "" && isClean {
version = tag
return nil
}
version = commit
if !isClean {
version = commit + "-dirty"
log.Printf("[Version] dirty version encountered: %s \n", version)
}
// check if this is a release version and fail if the version contains `dirty`
if strings.Contains(version, "dirty") && os.Getenv("DRONE_TAG") != "" || tag != "" {
return fmt.Errorf("[Version] releases require a non-dirty tag: %s", version)
}
log.Printf("[Version] version: %s \n", version)
return nil
}

Add built-in node cleaning

Allow wins to clean the windows node to prepare it to be re-joined to a rancher cluster. This is currently accomplished with a PowerShell script that is run manually by the end-user.

The end goal is to link this cleanup to the delete/drain function for a windows node so that nodes can be automatically cleaned without having to interact directly with wins

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.