You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Rohit Yadav <ro...@shapeblue.com> on 2021/09/08 08:19:55 UTC
Re: [cloudstack-go] sdk releasing
+1
That makes sense. In the go-sdk we've a generator that consumes the listApis output of a ACS release and generates the library - https://github.com/apache/cloudstack-go/tree/main/generate
I suppose for every ACS release, we can update go-sdk with release-specific API list, test it, release and tag it. Even automate this?
I would say - no need to vote it unless the SDK is manually changed. Since it is used with the k8s provider or the terraform provider so tags on go-sdk may go in-line with tags/release of these users.
Regards.
________________________________
From: Pierre-Luc Dion <pd...@apache.org>
Sent: Friday, August 27, 2021 17:57
To: Rohit Yadav <ro...@shapeblue.com>; dev <de...@cloudstack.apache.org>
Subject: [cloudstack-go] sdk releasing
I've messing around with cloudstack-go
Did a fix that rohit merged yesturday for hostsservices, but this fix will only work for acs4.15, I'd like to fix it for previous acs version too, but look like the version of the SDK depend on acs version;
Example; for the hostservices, the host attribute managementserverid is a UUID in 4.15, but an integer in an older version of xenserver. This breaks the structs,or map, we must have some other similar issue.
so I'd like to help on creating a tag or version of the SDK so they would match acs version target,
ie: SDK version = v4.15-0; where the last digit would define the sdk version or increase with fixes.
Current versioning in use = https://github.com/apache/cloudstack-go/releases
The issue I'm expecting to face is if we create a release , let's say v4.15-0 from main branch today, if we want to create v4.14.0, it will not be possible from the main branch because we need to revert the last commit but also fix hostservices.
Here are a bunch of questions I have:
1. Should we create a branch for older ACS versions and keep main for latest fixes and future releases ?
2. Do we need to vote for such changes?
3. Does such releases could impact other Go projects that use this one, such as terraform and kubernetes drivers?
4. Should we provide similar versioning on our kubernetes driver?
Re: [cloudstack-go] sdk releasing
Posted by Rohit Yadav <ro...@shapeblue.com>.
Hi PL,
I don't have an issue with the versioning/tagging of releases, I think we can continue to do the v2 for example for ACS 4.15.2 I see Pearl did https://github.com/apache/cloudstack-go/releases/tag/v2.11.0
My email was requesting community for comments/objections if we continue the approach you started do the tags without an explicit vote required. My suggestion is that it's not needed as the go-sdk can then in turn voted/tested with its currently known consumers:
https://github.com/apache/cloudstack-terraform-provider
https://github.com/apache/cloudstack-kubernetes-provider
Regards.
________________________________
From: Pierre-Luc Dion <pd...@cloud.ca>
Sent: Wednesday, October 20, 2021 22:13
To: Rohit Yadav <ro...@shapeblue.com>
Cc: dev <de...@cloudstack.apache.org>
Subject: Re: [cloudstack-go] sdk releasing
Hi Rohit,
I've tried the approach when I did the release of cloudstack-go SDK v4.15.1. I had to remove it and create v2.10.0; The reason is captured here [1]
Basically, because we call our go module cloudstack/v2 if we want to have release v4.x we would need to change our module to cloudstack/v4.
I don't know how big of a deal this is to move from /v2 to /v4, on the other hand, why not get rid of the version in the module definition instead ?
[1] https://github.com/apache/cloudstack-go/pull/7#issuecomment-918225329
[2] https://go.dev/blog/publishing-go-modules
Regards,
On Tue, Oct 19, 2021 at 3:57 AM Rohit Yadav <ro...@shapeblue.com>> wrote:
Hi All, cc PL
I thought to check with the community for any objections, following PL's approach for ACS 4.15.2 we've created:
https://github.com/apache/cloudstack-go/releases/tag/v2.11.0
Explicit testing/voting may not be necessary as it's largely autogenerated against API of an ACS release and further it doesn't serve purpose in itself but currently used by the CloudStack k8s provider and terrraform provider which will be tested/voted against (indirectly testing/voting these projects will also validate/test the go-sdk).
Unless there are any objections, do we agree to tag the cloudstack-go repo with tags against ACS releases using the approach PL started?
Regards.
________________________________
From: Rohit Yadav <ro...@shapeblue.com>>
Sent: Wednesday, September 8, 2021 13:49
To: Pierre-Luc Dion <pd...@apache.org>>; dev <de...@cloudstack.apache.org>>
Subject: Re: [cloudstack-go] sdk releasing
+1
That makes sense. In the go-sdk we've a generator that consumes the listApis output of a ACS release and generates the library - https://github.com/apache/cloudstack-go/tree/main/generate
I suppose for every ACS release, we can update go-sdk with release-specific API list, test it, release and tag it. Even automate this?
I would say - no need to vote it unless the SDK is manually changed. Since it is used with the k8s provider or the terraform provider so tags on go-sdk may go in-line with tags/release of these users.
Regards.
________________________________
From: Pierre-Luc Dion <pd...@apache.org>>
Sent: Friday, August 27, 2021 17:57
To: Rohit Yadav <ro...@shapeblue.com>>; dev <de...@cloudstack.apache.org>>
Subject: [cloudstack-go] sdk releasing
I've messing around with cloudstack-go
Did a fix that rohit merged yesturday for hostsservices, but this fix will only work for acs4.15, I'd like to fix it for previous acs version too, but look like the version of the SDK depend on acs version;
Example; for the hostservices, the host attribute managementserverid is a UUID in 4.15, but an integer in an older version of xenserver. This breaks the structs,or map, we must have some other similar issue.
so I'd like to help on creating a tag or version of the SDK so they would match acs version target,
ie: SDK version = v4.15-0; where the last digit would define the sdk version or increase with fixes.
Current versioning in use = https://github.com/apache/cloudstack-go/releases
The issue I'm expecting to face is if we create a release , let's say v4.15-0 from main branch today, if we want to create v4.14.0, it will not be possible from the main branch because we need to revert the last commit but also fix hostservices.
Here are a bunch of questions I have:
1. Should we create a branch for older ACS versions and keep main for latest fixes and future releases ?
2. Do we need to vote for such changes?
3. Does such releases could impact other Go projects that use this one, such as terraform and kubernetes drivers?
4. Should we provide similar versioning on our kubernetes driver?
Re: [cloudstack-go] sdk releasing
Posted by Pierre-Luc Dion <pd...@cloud.ca.INVALID>.
Hi Rohit,
I've tried the approach when I did the release of cloudstack-go SDK
v4.15.1. I had to remove it and create v2.10.0; The reason is captured here
[1]
Basically, because we call our go module cloudstack/v2 if we want to have
release v4.x we would need to change our module to cloudstack/v4.
I don't know how big of a deal this is to move from /v2 to /v4, on the
other hand, why not get rid of the version in the module definition instead
?
[1] https://github.com/apache/cloudstack-go/pull/7#issuecomment-918225329
[2] https://go.dev/blog/publishing-go-modules
Regards,
On Tue, Oct 19, 2021 at 3:57 AM Rohit Yadav <ro...@shapeblue.com>
wrote:
> Hi All, cc PL
>
> I thought to check with the community for any objections, following PL's
> approach for ACS 4.15.2 we've created:
> https://github.com/apache/cloudstack-go/releases/tag/v2.11.0
>
> Explicit testing/voting may not be necessary as it's largely autogenerated
> against API of an ACS release and further it doesn't serve purpose in
> itself but currently used by the CloudStack k8s provider and terrraform
> provider which will be tested/voted against (indirectly testing/voting
> these projects will also validate/test the go-sdk).
>
> Unless there are any objections, do we agree to tag the cloudstack-go repo
> with tags against ACS releases using the approach PL started?
>
> Regards.
>
>
>
>
>
> ------------------------------
> *From:* Rohit Yadav <ro...@shapeblue.com>
> *Sent:* Wednesday, September 8, 2021 13:49
> *To:* Pierre-Luc Dion <pd...@apache.org>; dev <
> dev@cloudstack.apache.org>
> *Subject:* Re: [cloudstack-go] sdk releasing
>
> +1
>
> That makes sense. In the go-sdk we've a generator that consumes the
> listApis output of a ACS release and generates the library -
> https://github.com/apache/cloudstack-go/tree/main/generate
>
> I suppose for every ACS release, we can update go-sdk with
> release-specific API list, test it, release and tag it. Even automate this?
>
> I would say - no need to vote it unless the SDK is manually changed. Since
> it is used with the k8s provider or the terraform provider so tags on
> go-sdk may go in-line with tags/release of these users.
>
> Regards.
>
> ________________________________
> From: Pierre-Luc Dion <pd...@apache.org>
> Sent: Friday, August 27, 2021 17:57
> To: Rohit Yadav <ro...@shapeblue.com>; dev <
> dev@cloudstack.apache.org>
> Subject: [cloudstack-go] sdk releasing
>
> I've messing around with cloudstack-go
>
> Did a fix that rohit merged yesturday for hostsservices, but this fix will
> only work for acs4.15, I'd like to fix it for previous acs version too, but
> look like the version of the SDK depend on acs version;
>
> Example; for the hostservices, the host attribute managementserverid is a
> UUID in 4.15, but an integer in an older version of xenserver. This breaks
> the structs,or map, we must have some other similar issue.
>
> so I'd like to help on creating a tag or version of the SDK so they would
> match acs version target,
> ie: SDK version = v4.15-0; where the last digit would define the sdk
> version or increase with fixes.
> Current versioning in use =
> https://github.com/apache/cloudstack-go/releases
>
> The issue I'm expecting to face is if we create a release , let's say
> v4.15-0 from main branch today, if we want to create v4.14.0, it will not
> be possible from the main branch because we need to revert the last commit
> but also fix hostservices.
>
> Here are a bunch of questions I have:
> 1. Should we create a branch for older ACS versions and keep main for
> latest fixes and future releases ?
> 2. Do we need to vote for such changes?
> 3. Does such releases could impact other Go projects that use this one,
> such as terraform and kubernetes drivers?
> 4. Should we provide similar versioning on our kubernetes driver?
>
>
>
>
>
Re: [cloudstack-go] sdk releasing
Posted by Rohit Yadav <ro...@shapeblue.com>.
Hi All, cc PL
I thought to check with the community for any objections, following PL's approach for ACS 4.15.2 we've created:
https://github.com/apache/cloudstack-go/releases/tag/v2.11.0
Explicit testing/voting may not be necessary as it's largely autogenerated against API of an ACS release and further it doesn't serve purpose in itself but currently used by the CloudStack k8s provider and terrraform provider which will be tested/voted against (indirectly testing/voting these projects will also validate/test the go-sdk).
Unless there are any objections, do we agree to tag the cloudstack-go repo with tags against ACS releases using the approach PL started?
Regards.
________________________________
From: Rohit Yadav <ro...@shapeblue.com>
Sent: Wednesday, September 8, 2021 13:49
To: Pierre-Luc Dion <pd...@apache.org>; dev <de...@cloudstack.apache.org>
Subject: Re: [cloudstack-go] sdk releasing
+1
That makes sense. In the go-sdk we've a generator that consumes the listApis output of a ACS release and generates the library - https://github.com/apache/cloudstack-go/tree/main/generate
I suppose for every ACS release, we can update go-sdk with release-specific API list, test it, release and tag it. Even automate this?
I would say - no need to vote it unless the SDK is manually changed. Since it is used with the k8s provider or the terraform provider so tags on go-sdk may go in-line with tags/release of these users.
Regards.
________________________________
From: Pierre-Luc Dion <pd...@apache.org>
Sent: Friday, August 27, 2021 17:57
To: Rohit Yadav <ro...@shapeblue.com>; dev <de...@cloudstack.apache.org>
Subject: [cloudstack-go] sdk releasing
I've messing around with cloudstack-go
Did a fix that rohit merged yesturday for hostsservices, but this fix will only work for acs4.15, I'd like to fix it for previous acs version too, but look like the version of the SDK depend on acs version;
Example; for the hostservices, the host attribute managementserverid is a UUID in 4.15, but an integer in an older version of xenserver. This breaks the structs,or map, we must have some other similar issue.
so I'd like to help on creating a tag or version of the SDK so they would match acs version target,
ie: SDK version = v4.15-0; where the last digit would define the sdk version or increase with fixes.
Current versioning in use = https://github.com/apache/cloudstack-go/releases
The issue I'm expecting to face is if we create a release , let's say v4.15-0 from main branch today, if we want to create v4.14.0, it will not be possible from the main branch because we need to revert the last commit but also fix hostservices.
Here are a bunch of questions I have:
1. Should we create a branch for older ACS versions and keep main for latest fixes and future releases ?
2. Do we need to vote for such changes?
3. Does such releases could impact other Go projects that use this one, such as terraform and kubernetes drivers?
4. Should we provide similar versioning on our kubernetes driver?