hrak opened a new pull request, #44:
URL: https://github.com/apache/cloudstack-kubernetes-provider/pull/44
This PR is a continuation of the work in #32 and contains the following
changes:
- Use Go 1.18
- Update Kubernetes deps to 1.26.2
- Move the cloudstack-go dep to its new ho
+1 (binding)
I’ve done manual upgrades from the last couple of versions on various
hypervisors and didn’t had any issues.
Also basic lifecycle operations seems to be working.
Bobby.
From: Nux
Date: Tuesday, 28 February 2023, 11:32
To: dev@cloudstack.apache.org
Cc: users
Subject: Re: [4.18][
hrak commented on PR #44:
URL:
https://github.com/apache/cloudstack-kubernetes-provider/pull/44#issuecomment-1450156357
Please let me know if 1.26 i a bit too ambitious, i will gladly adapt for
1.24 or 1.25.
--
This is an automated message from the Apache Git Service.
To respond to the m
joschi36 commented on PR #44:
URL:
https://github.com/apache/cloudstack-kubernetes-provider/pull/44#issuecomment-1450260367
If you have the time I would really appreciate if there is a version in
between. For instance 1.24.
--
This is an automated message from the Apache Git Service.
To
hrak commented on PR #44:
URL:
https://github.com/apache/cloudstack-kubernetes-provider/pull/44#issuecomment-1450281799
> If you have the time I would really appreciate if there is a version in
between. For instance 1.24.
yeah i was afraid of that already, i suddenly realized that co
hrak commented on PR #44:
URL:
https://github.com/apache/cloudstack-kubernetes-provider/pull/44#issuecomment-1450369462
Updated PR to use Kubernetes v1.24.11 instead
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
Hi all,
+1, I tested different upgrades (from 4.15, 4.16 and 4.17 using different
hypervisors) and the common operations and found no issues.
Best wishes,
Vladi
Daan Hoogland wrote:
Hi All,
some small errata,
- I added my key
- I will keep this vote open till friday, we've had a weekend and
serverchief opened a new issue, #125:
URL: https://github.com/apache/cloudstack-cloudmonkey/issues/125
Lets take listHosts as an example, when running list hosts
resourcestate=Enabled state=Up, requires for end user to memorize (or lookup)
and separately query other states.
Perhaps w
serverchief opened a new issue, #126:
URL: https://github.com/apache/cloudstack-cloudmonkey/issues/126
In large environments specific API calls take too long to respond because
the query was not fine tuned. However - there is no way to terminate the
existing running cmk command - as CTRL-C
rohityadavcloud commented on issue #125:
URL:
https://github.com/apache/cloudstack-cloudmonkey/issues/125#issuecomment-1451370387
`cmk` is fundamentally a dumb CLI that just calls an API and processes the
API response, and for API requests it doesn't know what a non-Enabled
resourcestate c
rohityadavcloud commented on issue #126:
URL:
https://github.com/apache/cloudstack-cloudmonkey/issues/126#issuecomment-1451373274
I couldn't reproduce this with the QA server, http://qa.cloudstack.cloud/,
using latest cmk for osx/darwin (arm64). I tried the listEvents and listAlerts
APIs.
borisstoyanov merged PR #124:
URL: https://github.com/apache/cloudstack-cloudmonkey/pull/124
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubsc
12 matches
Mail list logo
