[
https://issues.apache.org/jira/browse/CLOUDSTACK-9383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Tutkowski updated CLOUDSTACK-9383:
---------------------------------------
Description:
Change variable names back to fix communication with Hyper-V Agent.
More detail on the matter per e-mails to dev@:
Tutkowski, Mike <mike.tutkow...@netapp.com>
Thu 5/19/2016 10:53 PM
Thanks for sending out this e-mail, Anshul.
This is a bit of a strange situation because we need to make sure people are
either aware of the fact that properties in Command classes are serialized (and
not change existing variable names) or come up with a less fragile way of
choosing property names when sending data (perhaps using annotations).
At the very least, we should have comments in these classes indicating the
dangers of changing property names. It might also be beneficial to have unit
tests in place that expect certain variable names and assert if they are not as
expected.
In the meanwhile, I plan to change the variable names back that were changed in
PR #816.
Additional thoughts on how this should be addressed long term?
Thanks!
Mike
Anshul Gangwar <anshul.gang...@accelerite.com>
Thu 5/19/2016 10:47 PM
To:
d...@cloudstack.apache.org;
You replied on 5/19/2016 10:53 PM.
Hi,
We should not allow renaming of variables in classes which ends with Command
and TO. As these objects are meant to be consumed by Agents.
Agents may not be written in java so relying on these variable names to get the
info. One such example is Hyper-V agent.
Hyper-V support is currently broken as there are some variables renamed in PR
https://github.com/apache/cloudstack/pull/816.
Regards,
Anshul
was:
Per e-mails to dev@:
Tutkowski, Mike <mike.tutkow...@netapp.com>
Thu 5/19/2016 10:53 PM
Thanks for sending out this e-mail, Anshul.
This is a bit of a strange situation because we need to make sure people are
either aware of the fact that properties in Command classes are serialized (and
not change existing variable names) or come up with a less fragile way of
choosing property names when sending data (perhaps using annotations).
At the very least, we should have comments in these classes indicating the
dangers of changing property names. It might also be beneficial to have unit
tests in place that expect certain variable names and assert if they are not as
expected.
In the meanwhile, I plan to change the variable names back that were changed in
PR #816.
Additional thoughts on how this should be addressed long term?
Thanks!
Mike
Anshul Gangwar <anshul.gang...@accelerite.com>
Thu 5/19/2016 10:47 PM
To:
d...@cloudstack.apache.org;
You replied on 5/19/2016 10:53 PM.
Hi,
We should not allow renaming of variables in classes which ends with Command
and TO. As these objects are meant to be consumed by Agents.
Agents may not be written in java so relying on these variable names to get the
info. One such example is Hyper-V agent.
Hyper-V support is currently broken as there are some variables renamed in PR
https://github.com/apache/cloudstack/pull/816.
Regards,
Anshul
> Hyper-V communication broken by change in variable names
> --------------------------------------------------------
>
> Key: CLOUDSTACK-9383
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9383
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
> Affects Versions: 4.9.0
> Environment: N/A
> Reporter: Mike Tutkowski
> Fix For: 4.9.0
>
>
> Change variable names back to fix communication with Hyper-V Agent.
> More detail on the matter per e-mails to dev@:
> Tutkowski, Mike <mike.tutkow...@netapp.com>
> Thu 5/19/2016 10:53 PM
> Thanks for sending out this e-mail, Anshul.
> This is a bit of a strange situation because we need to make sure people are
> either aware of the fact that properties in Command classes are serialized
> (and not change existing variable names) or come up with a less fragile way
> of choosing property names when sending data (perhaps using annotations).
> At the very least, we should have comments in these classes indicating the
> dangers of changing property names. It might also be beneficial to have unit
> tests in place that expect certain variable names and assert if they are not
> as expected.
> In the meanwhile, I plan to change the variable names back that were changed
> in PR #816.
> Additional thoughts on how this should be addressed long term?
> Thanks!
> Mike
> Anshul Gangwar <anshul.gang...@accelerite.com>
> Thu 5/19/2016 10:47 PM
> To:
> d...@cloudstack.apache.org;
> You replied on 5/19/2016 10:53 PM.
> Hi,
> We should not allow renaming of variables in classes which ends with Command
> and TO. As these objects are meant to be consumed by Agents.
> Agents may not be written in java so relying on these variable names to get
> the info. One such example is Hyper-V agent.
> Hyper-V support is currently broken as there are some variables renamed in PR
> https://github.com/apache/cloudstack/pull/816.
> Regards,
> Anshul
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
