[GitHub] [cloudstack-documentation] rhtyd commented on pull request #215: Modernizing "Create linux template" guide + Cloud-init integration steps

2021-11-26 Thread GitBox


rhtyd commented on pull request #215:
URL: 
https://github.com/apache/cloudstack-documentation/pull/215#issuecomment-980506813


   Hi @dredknight a user from mailing list has given following suggestion:
   ```
   > Hello everyone.
   >
   > I've been following the Cloud-init integration guides in the ACS 4.16
   > documentation and noticed a problem with Ubuntu Server 20.04 LTS. In
   > particular, the section "Specify the managed user" shows:
   >
   > system_info : default_user : name : cloud - user lock_passwd : false # 
disable
   > user password login - true/false sudo : [ \ "ALL=(ALL) ALL \" ]   # 
User
   > permissions disable_root : 0 # root remote login is 0 - enabled, 1 - 
disabled
   > ssh_pwauth : 1 # password login is 0 - disabled, 1- enabled
   >
   > Adding this produces an error message when trying to use sudo. The error 
message
   > is:
   >
   > $ sudo su
    /etc/sudoers.d/90-cloud-init-users: syntax error near line 4 <<<
   > sudo: parse error in /etc/sudoers.d/90-cloud-init-users near line 4
   > sudo: no valid sudoers sources found, quitting
   > sudo: unable to initialize policy plugin
   >
   > Removing the "\" in
   > sudo : [ \ "ALL=(ALL) ALL \" ]
   > seem to fix the problem for me.
   ```
   
   Mailing list thread reference: https://markmail.org/message/ruxyqzs44lqjtqpf


-- 
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-unsubscr...@cloudstack.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org




Re: ACS 4.16 documentation issue/error

2021-11-26 Thread Rohit Yadav
Hi Andrei,

Thanks for sharing, we'll see what to do about QA/testing links coming up in 
Google results. If you read the link, it's not from our official docs website 
(docs.cloudstack.apache.org). This is from this pull request which hasn't been 
merged yet: https://github.com/apache/cloudstack-documentation/pull/215

I'll pass your feedback to the PR's author.


Regards.


From: Andrei Mikhailovsky 
Sent: Friday, November 26, 2021 17:28
To: dev 
Subject: Re: ACS 4.16 documentation issue/error

Hi Rohit,

this is the link where I've found the guides:

http://qa.cloudstack.cloud/docs/WIP-PROOFING/pr/215/adminguide/templates/_cloud_init.html#linux-with-cloud-init

I got the above link from google when I was searching for cloud-init and 
cloudstack templates or something like that.

Sorry, I am not a contributor/developer. Perhaps one of the dev people who are 
doing the templates/documentation could double check the guides and make the 
necessary correction. I've tested it only on Ubuntu Server 20.04 LTS and found 
the problem.

Andrei


 

- Original Message -
> From: "Rohit Yadav" 
> To: "dev" 
> Sent: Friday, 26 November, 2021 09:33:46
> Subject: Re: ACS 4.16 documentation issue/error

> Hi Andrei,
>
> Thanks for sharing. Can you share which page/link you found the error, the
> cloud-init docs I found were at:
> https://docs.cloudstack.apache.org/en/latest/adminguide/virtual_machines/user-data.html#using-cloud-init
>
> You may also raise a pull request and propose changes at
> https://github.com/apache/cloudstack-documentation
>
>
> Regards.
>
> 
> From: Andrei Mikhailovsky 
> Sent: Thursday, November 25, 2021 16:25
> To: dev 
> Subject: ACS 4.16 documentation issue/error
>
> Hello everyone.
>
> I've been following the Cloud-init integration guides in the ACS 4.16
> documentation and noticed a problem with Ubuntu Server 20.04 LTS. In
> particular, the section "Specify the managed user" shows:
>
> system_info : default_user : name : cloud - user lock_passwd : false # disable
> user password login - true/false sudo : [ \ "ALL=(ALL) ALL \" ]   # User
> permissions disable_root : 0 # root remote login is 0 - enabled, 1 - disabled
> ssh_pwauth : 1 # password login is 0 - disabled, 1- enabled
>
> Adding this produces an error message when trying to use sudo. The error 
> message
> is:
>
> $ sudo su
 /etc/sudoers.d/90-cloud-init-users: syntax error near line 4 <<<
> sudo: parse error in /etc/sudoers.d/90-cloud-init-users near line 4
> sudo: no valid sudoers sources found, quitting
> sudo: unable to initialize policy plugin
>
> Removing the "\" in
> sudo : [ \ "ALL=(ALL) ALL \" ]
> seem to fix the problem for me.
>
> Could you please test this part again to make sure the users are producing
> working templates after following the instructions.
>
> Thanks
>
> Andrei


Unable to create a deployment for VM

2021-11-26 Thread technologyrss.mail

*Hi, *

Please see error log:

(logid:9bd01412) Searching all possible resources under this Zone: 1
2021-11-26 18:47:42,554 DEBUG [c.c.d.FirstFitPlanner] 
(API-Job-Executor-8:ctx-dfeedfec job-16 ctx-0f3c8323) (logid:9bd01412) 
Listing clusters in order of aggregate capacity, that have (at least one 
host with) enough CPU and RAM capacity under this Zone: 1
2021-11-26 18:47:42,561 DEBUG [c.c.d.FirstFitPlanner] 
(API-Job-Executor-8:ctx-dfeedfec job-16 ctx-0f3c8323) (logid:9bd01412) 
Removing from the clusterId list these clusters from avoid set: []
2021-11-26 18:47:42,582 DEBUG [c.c.d.FirstFitPlanner] 
(API-Job-Executor-8:ctx-dfeedfec job-16 ctx-0f3c8323) (logid:9bd01412) 
Cannot allocate cluster list [1] for vm creation since their allocated 
percentage crosses the disable capacity threshold defined at each 
cluster/ at global value for capacity Type : 0, skipping these clusters
2021-11-26 18:47:42,582 DEBUG [c.c.d.FirstFitPlanner] 
(API-Job-Executor-8:ctx-dfeedfec job-16 ctx-0f3c8323) (logid:9bd01412) 
No clusters found after removing disabled clusters and clusters in avoid 
list, returning.
2021-11-26 18:47:42,590 DEBUG [c.c.v.UserVmManagerImpl] 
(API-Job-Executor-8:ctx-dfeedfec job-16 ctx-0f3c8323) (logid:9bd01412) 
Destroying vm VM[User|i-2-3-VM] as it failed to create on Host with Id:null
2021-11-26 18:47:42,626 DEBUG [c.c.c.CapacityManagerImpl] 
(API-Job-Executor-8:ctx-dfeedfec job-16 ctx-0f3c8323) (logid:9bd01412) 
VM state transitted from :Stopped to Error with event: 
OperationFailedToErrorvm's original host id: null new host id: null host 
id before state transition: null
2021-11-26 18:47:42,659 DEBUG [c.c.r.ResourceLimitManagerImpl] 
(API-Job-Executor-8:ctx-dfeedfec job-16 ctx-0f3c8323) (logid:9bd01412) 
Updating resource Type = volume count for Account = 2 Operation = 
decreasing Amount = 1
2021-11-26 18:47:42,680 DEBUG [c.c.r.ResourceLimitManagerImpl] 
(API-Job-Executor-8:ctx-dfeedfec job-16 ctx-0f3c8323) (logid:9bd01412) 
Updating resource Type = primary_storage count for Account = 2 Operation 
= decreasing Amount = (20.00 GB) 21474836480
2021-11-26 18:47:42,714 WARN  [c.c.a.AlertManagerImpl] 
(API-Job-Executor-8:ctx-dfeedfec job-16 ctx-0f3c8323) (logid:9bd01412) 
AlertType:: 8 | dataCenterId:: 1 | podId:: null | clusterId:: null | 
message:: Failed to deploy Vm with Id: 3, on Host with Id: null
2021-11-26 18:47:42,727 DEBUG [c.c.r.ResourceLimitManagerImpl] 
(API-Job-Executor-8:ctx-dfeedfec job-16 ctx-0f3c8323) (logid:9bd01412) 
Updating resource Type = user_vm count for Account = 2 Operation = 
decreasing Amount = 1
2021-11-26 18:47:42,737 DEBUG [c.c.r.ResourceLimitManagerImpl] 
(API-Job-Executor-8:ctx-dfeedfec job-16 ctx-0f3c8323) (logid:9bd01412) 
Updating resource Type = cpu count for Account = 2 Operation = 
decreasing Amount = 1
2021-11-26 18:47:42,748 DEBUG [c.c.r.ResourceLimitManagerImpl] 
(API-Job-Executor-8:ctx-dfeedfec job-16 ctx-0f3c8323) (logid:9bd01412) 
Updating resource Type = memory count for Account = 2 Operation = 
decreasing Amount = 1024
2021-11-26 18:47:42,768 INFO  [o.a.c.a.c.u.v.DeployVMCmd] 
(API-Job-Executor-8:ctx-dfeedfec job-16 ctx-0f3c8323) (logid:9bd01412) 
com.cloud.exception.InsufficientServerCapacityException: Unable to 
create a deployment for VM[User|i-2-3-VM]Scope=interface 
com.cloud.dc.DataCenter; id=1
2021-11-26 18:47:42,768 INFO  [o.a.c.a.c.u.v.DeployVMCmd] 
(API-Job-Executor-8:ctx-dfeedfec job-16 ctx-0f3c8323) (logid:9bd01412) 
Unable to create a deployment for VM[User|i-2-3-VM]
com.cloud.exception.InsufficientServerCapacityException: Unable to 
create a deployment for VM[User|i-2-3-VM]Scope=interface 
com.cloud.dc.DataCenter; id=1
    at 
org.apache.cloudstack.engine.cloud.entity.api.VMEntityManagerImpl.reserveVirtualMachine(VMEntityManagerImpl.java:225)
    at 
org.apache.cloudstack.engine.cloud.entity.api.VirtualMachineEntityImpl.reserve(VirtualMachineEntityImpl.java:202)
    at 
com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:4929)
    at 
com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:4466)
    at 
com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:4455)
    at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native 
Method)
    at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

    at java.base/java.lang.reflect.Method.invoke(Method.java:566)
    at 
org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:344)
    at 
org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:198)
    at 
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:163)
    at 

[GitHub] [cloudstack-go] rhtyd commented on pull request #21: handle type compatibilty for 4.x baseline

2021-11-26 Thread GitBox


rhtyd commented on pull request #21:
URL: https://github.com/apache/cloudstack-go/pull/21#issuecomment-979946839


   Considering all the discussions we've had, I think it's safe to say that 
moving forward the specific datatype of the mgmt server ID is string. The only 
cons are that whoever may be using this response attribute will have to handle 
the typecast of how it is consumed by their code, however, this is not 
something most people would use out of an API request. I think it makes sense 
to rename the struct to something like ManagementServerID or UUID and have the 
changes such that at least it can handle all past/new ACS releases wherein the 
response object was integer and string. 


-- 
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-unsubscr...@cloudstack.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org




Re: ACS 4.16 documentation issue/error

2021-11-26 Thread Andrei Mikhailovsky
Hi Rohit,

this is the link where I've found the guides:

http://qa.cloudstack.cloud/docs/WIP-PROOFING/pr/215/adminguide/templates/_cloud_init.html#linux-with-cloud-init

I got the above link from google when I was searching for cloud-init and 
cloudstack templates or something like that.

Sorry, I am not a contributor/developer. Perhaps one of the dev people who are 
doing the templates/documentation could double check the guides and make the 
necessary correction. I've tested it only on Ubuntu Server 20.04 LTS and found 
the problem.

Andrei

- Original Message -
> From: "Rohit Yadav" 
> To: "dev" 
> Sent: Friday, 26 November, 2021 09:33:46
> Subject: Re: ACS 4.16 documentation issue/error

> Hi Andrei,
> 
> Thanks for sharing. Can you share which page/link you found the error, the
> cloud-init docs I found were at:
> https://docs.cloudstack.apache.org/en/latest/adminguide/virtual_machines/user-data.html#using-cloud-init
> 
> You may also raise a pull request and propose changes at
> https://github.com/apache/cloudstack-documentation
> 
> 
> Regards.
> 
> 
> From: Andrei Mikhailovsky 
> Sent: Thursday, November 25, 2021 16:25
> To: dev 
> Subject: ACS 4.16 documentation issue/error
> 
> Hello everyone.
> 
> I've been following the Cloud-init integration guides in the ACS 4.16
> documentation and noticed a problem with Ubuntu Server 20.04 LTS. In
> particular, the section "Specify the managed user" shows:
> 
> system_info : default_user : name : cloud - user lock_passwd : false # disable
> user password login - true/false sudo : [ \ "ALL=(ALL) ALL \" ]   # User
> permissions disable_root : 0 # root remote login is 0 - enabled, 1 - disabled
> ssh_pwauth : 1 # password login is 0 - disabled, 1- enabled
> 
> Adding this produces an error message when trying to use sudo. The error 
> message
> is:
> 
> $ sudo su
 /etc/sudoers.d/90-cloud-init-users: syntax error near line 4 <<<
> sudo: parse error in /etc/sudoers.d/90-cloud-init-users near line 4
> sudo: no valid sudoers sources found, quitting
> sudo: unable to initialize policy plugin
> 
> Removing the "\" in
> sudo : [ \ "ALL=(ALL) ALL \" ]
> seem to fix the problem for me.
> 
> Could you please test this part again to make sure the users are producing
> working templates after following the instructions.
> 
> Thanks
> 
> Andrei


[GitHub] [cloudstack-go] psycofdj edited a comment on pull request #21: handle type compatibilty for 4.x baseline

2021-11-26 Thread GitBox


psycofdj edited a comment on pull request #21:
URL: https://github.com/apache/cloudstack-go/pull/21#issuecomment-979866201


   I now understand your problem and, unfortunately,  I have no solution to 
this.
   
   So, what should we do now ? What are the other solutions to handle past and 
future type breaking changes in the cloudstack API ?


-- 
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-unsubscr...@cloudstack.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org




[GitHub] [cloudstack-go] psycofdj commented on pull request #21: handle type compatibilty for 4.x baseline

2021-11-26 Thread GitBox


psycofdj commented on pull request #21:
URL: https://github.com/apache/cloudstack-go/pull/21#issuecomment-979866201


   I now understand your problem and, unfortunately,  I have no solution to 
this.
   
   So, want should we do now ? What are the other solutions to handle past and 
future type breaking changes in the cloudstack API ?


-- 
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-unsubscr...@cloudstack.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org




Re: Live migration between AMD Epyc and Ubuntu 18.04 and 20.04

2021-11-26 Thread Andrija Panic
Cant help, but I've seen this exact issue (if not mistaken) - a CPU flag
that DOES exist on the destination KVM host, but libvirt complaining it
doesn't - I would guess some kernel issue, as I've seen those.

On Wed, 24 Nov 2021 at 22:36, Wei ZHOU  wrote:

> Hi Wido,
>
> I think it is not good to run an environment with two ubuntu/qemu versions.
> It always happens that some cpu features are supported in the higher
> version but not supported in the older version.
> From my experience, the migration from older version to higher version
> works like a charm, but there were many issues in migration from higher
> version to older version.
>
> I do not have a solution for you. I have tried to hack
> /etc/libvirt/hooks/qemu but it didn't work.
> Have you tried with other cpu models like x86_Opteron_G5 ? you can find the
> cpu features of each cpu model in /usr/share/libvirt/cpu_map/
>
> Anyway, even if the vm migration succeeds, you do not know if vm works
> fine. I believe the best solution is upgrading all hosts to the same OS
> version.
>
> -Wei
>
> On Tue, 23 Nov 2021 at 16:31, Wido den Hollander  wrote:
>
> > Hi,
> >
> > I'm trying to debug an issue with live migrations between Ubuntu 18.04
> > and 20.04 machines each with different CPUs:
> >
> > - Ubuntu 18.04 with AMD Epyc 7552 (Rome)
> > - Ubuntu 20.04 with AMD Epyc 7662 (Milan)
> >
> > We are currently using this setting:
> >
> > guest.cpu.mode=custom
> > guest.cpu.model=EPYC
> >
> > This does not allow for live migrations:
> >
> > Ubuntu 20.04 with Epyc 7662 to Ubuntu 18.04 with Epyc 7552 fails
> >
> > "ExecutionException : org.libvirt.LibvirtException: unsupported
> > configuration: unknown CPU feature: npt"
> >
> > So we tried to define a set of features manually:
> >
> > guest.cpu.features=3dnowprefetch abm adx aes apic arat avx avx2 bmi1
> > bmi2 clflush clflushopt cmov cr8legacy cx16 cx8 de f16c fma fpu fsgsbase
> > fxsr fxsr_opt lahf_lm lm mca mce misalignsse mmx mmxext monitor movbe
> > msr mtrr nx osvw pae pat pclmuldq pdpe1gb pge pni popcnt pse pse36
> > rdrand rdseed rdtscp sep sha-ni smap smep sse sse2 sse4.1 sse4.2 sse4a
> > ssse3 svm syscall tsc vme xgetbv1 xsave xsavec xsaveopt -npt -x2apic
> > -hypervisor -topoext -nrip-save
> >
> > This results in this going into the XML:
> >
> > 
> >
> > You would say that works, but then the target host (18.04 with the 7552)
> > says it doesn't support the feature 'npt' and the migration still fails.
> >
> > Now we could ofcourse use the kvm64 CPU from Qemu, but that's lacking so
> > many features that for example TLS offloading isn't available.
> >
> > I also tried to set 'EPYC-Rome' on the Ubuntu 20.04 hypervisor, but it
> > then complains on the Ubuntu 18.04 hypervisor that the CPU 'EPYC-Rome'
> > is unknown as the 18.04 hypervisor doesn't have that profile.
> >
> > Any ideas on how to get this working?
> >
> > Wido
> >
>


-- 

Andrija Panić


[GitHub] [cloudstack-go] davidjumani edited a comment on pull request #21: handle type compatibilty for 4.x baseline

2021-11-26 Thread GitBox


davidjumani edited a comment on pull request #21:
URL: https://github.com/apache/cloudstack-go/pull/21#issuecomment-979854761


   That being said, I'm a +0 on this although I'd prefer if the name of the new 
data type is more intuitive such as UUID, etc


-- 
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-unsubscr...@cloudstack.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org




[GitHub] [cloudstack-go] davidjumani commented on pull request #21: handle type compatibilty for 4.x baseline

2021-11-26 Thread GitBox


davidjumani commented on pull request #21:
URL: https://github.com/apache/cloudstack-go/pull/21#issuecomment-979854761


   That being said, I'm a +0 on this although I'd prefer if the name of the new 
data type is more intuitive such as UUID, LongID, etc


-- 
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-unsubscr...@cloudstack.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org




[GitHub] [cloudstack-go] davidjumani commented on pull request #21: handle type compatibilty for 4.x baseline

2021-11-26 Thread GitBox


davidjumani commented on pull request #21:
URL: https://github.com/apache/cloudstack-go/pull/21#issuecomment-979853193


   This does handle and parse both int and string, but since the type of the 
Managementserverid has changed from string to CSLong, it can no longer be used 
as it was before, but rather needs to be explicitly converted to string which 
can break existing applications
   
   In the following example, the `msID` field is a string that is then used to 
store the `Managementserverid` and used later on in the program. Due to the 
change in the type of Managementserverid, it now throws the error or needs 
explicit conversion before it can be used to store the value of 
Managementserverid
   
   ```
   var msID string
   ...
   resp, err := cs.Host.ListHostsMetrics()
   msID = resp.HostsMetrics[1].Managementserverid <- 
resp.HostsMetrics[1].Managementserverid (type cloudstack.CSLong) as type string 
in assignment
   
   msID = string(resp.HostsMetrics[1].Managementserverid) <- works
   ```


-- 
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-unsubscr...@cloudstack.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org




[GitHub] [cloudstack-go] psycofdj commented on pull request #21: handle type compatibilty for 4.x baseline

2021-11-26 Thread GitBox


psycofdj commented on pull request #21:
URL: https://github.com/apache/cloudstack-go/pull/21#issuecomment-979843046


   @davidjumani I've spotted a problem with the parsing, can you retest with 
the latest commit ?


-- 
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-unsubscr...@cloudstack.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org




Re: ACS 4.16 documentation issue/error

2021-11-26 Thread Rohit Yadav
Hi Andrei,

Thanks for sharing. Can you share which page/link you found the error, the 
cloud-init docs I found were at:
https://docs.cloudstack.apache.org/en/latest/adminguide/virtual_machines/user-data.html#using-cloud-init

You may also raise a pull request and propose changes at 
https://github.com/apache/cloudstack-documentation


Regards.


From: Andrei Mikhailovsky 
Sent: Thursday, November 25, 2021 16:25
To: dev 
Subject: ACS 4.16 documentation issue/error

Hello everyone.

I've been following the Cloud-init integration guides in the ACS 4.16 
documentation and noticed a problem with Ubuntu Server 20.04 LTS. In 
particular, the section "Specify the managed user" shows:

system_info : default_user : name : cloud - user lock_passwd : false # disable 
user password login - true/false sudo : [ \ "ALL=(ALL) ALL \" ]   # User 
permissions disable_root : 0 # root remote login is 0 - enabled, 1 - disabled 
ssh_pwauth : 1 # password login is 0 - disabled, 1- enabled

Adding this produces an error message when trying to use sudo. The error 
message is:

$ sudo su
>>> /etc/sudoers.d/90-cloud-init-users: syntax error near line 4 <<<
sudo: parse error in /etc/sudoers.d/90-cloud-init-users near line 4
sudo: no valid sudoers sources found, quitting
sudo: unable to initialize policy plugin

Removing the "\" in
sudo : [ \ "ALL=(ALL) ALL \" ]
seem to fix the problem for me.

Could you please test this part again to make sure the users are producing 
working templates after following the instructions.

Thanks

Andrei

 



[GitHub] [cloudstack-go] psycofdj edited a comment on pull request #21: handle type compatibilty for 4.x baseline

2021-11-26 Thread GitBox


psycofdj edited a comment on pull request #21:
URL: https://github.com/apache/cloudstack-go/pull/21#issuecomment-979816808


   That is why I'm surprised. The goal of this new type is to handle **both** 
`string` (latest versions of CS api) and `long` (previous versions of CS api). 
With this type, it should have parsed correctly your json input.
   
   I'm aware that the json is not the probem, I was wondering if you could show 
me part of it so that I can test and understand why the `CSLong` type did not 
parse it correctly.


-- 
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-unsubscr...@cloudstack.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org




[GitHub] [cloudstack-go] psycofdj commented on pull request #21: handle type compatibilty for 4.x baseline

2021-11-26 Thread GitBox


psycofdj commented on pull request #21:
URL: https://github.com/apache/cloudstack-go/pull/21#issuecomment-979816808


   That is why I'm surprised. The goal of this new type is to handle **both** 
string (latest versions of CS api) and **long** (previous versions of CS api). 
With this type, it should have parsed correctly your json input.
   
   I'm aware that the json is not the probem, I was wondering if you could show 
me part of it so that I can test and understand why the `CSLong` type did not 
parse it correctly.


-- 
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-unsubscr...@cloudstack.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org




[GitHub] [cloudstack-go] davidjumani commented on pull request #21: handle type compatibilty for 4.x baseline

2021-11-26 Thread GitBox


davidjumani commented on pull request #21:
URL: https://github.com/apache/cloudstack-go/pull/21#issuecomment-979814465


   The input json isn't the error, it's the new type. The Managementserverid 
used to be a string and with this patch is now a CSLong. So trying to use the 
new type where a string used to be causes the error 
   
   ```
   var msID string
   ...
   resp, err := cs.Host.ListHostsMetrics()
   msID = resp.HostsMetrics[1].Managementserverid <- 
resp.HostsMetrics[1].Managementserverid (type cloudstack.CSLong) as type string 
in assignment
   ```
   


-- 
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-unsubscr...@cloudstack.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org




[GitHub] [cloudstack-go] psycofdj commented on pull request #21: handle type compatibilty for 4.x baseline

2021-11-26 Thread GitBox


psycofdj commented on pull request #21:
URL: https://github.com/apache/cloudstack-go/pull/21#issuecomment-979794967


   > cannot use resp.HostsMetrics[1].Managementserverid (type 
cloudstack.CSLong) as type string in assignment
   I'm surprised that this error occurs. Can you provide a sample of the input 
json that creates this error ?
   


-- 
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-unsubscr...@cloudstack.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org




[GitHub] [cloudstack-go] psycofdj edited a comment on pull request #21: handle type compatibilty for 4.x baseline

2021-11-26 Thread GitBox


psycofdj edited a comment on pull request #21:
URL: https://github.com/apache/cloudstack-go/pull/21#issuecomment-979794967


   > cannot use resp.HostsMetrics[1].Managementserverid (type 
cloudstack.CSLong) as type string in assignment
   
   I'm surprised that this error occurs. Can you provide a sample of the input 
json that creates this error ?
   


-- 
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-unsubscr...@cloudstack.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org