After poking around the code a bit, this is purely an API issue (was
worried there was more). When I made the change I explicitly *didn't*
change the actual method names so for example there is still a
getXenLabel() call on the physical network traffic API calls. That's
probably why we didn't see
Hi Tim,
You may be right on this one, we just want to make sure. Feel free to
revert the fix is there is a better way around. I personally would like
to avoid string changes because as Geoff mentions it changes the
interface for 3rd party consumers such as CLI scripts, custom UI and
possibly othe
t; geoff.higginbot...@shapeblue.com
>
>
>
> *From:* Tim Mackey [mailto:tmac...@gmail.com]
> *Sent:* 02 February 2015 11:05
> *To:* Rohit Yadav
> *Cc:* Geoff Higginbottom; dev@cloudstack.apache.org
> *Subject:* Re: [DISCUSS] Important: XenServer labels reverted for
> backward compatibility
geoff.higginbot...@shapeblue.com<mailto:geoff.higginbot...@shapeblue.com>
From: Tim Mackey [mailto:tmac...@gmail.com]
Sent: 02 February 2015 11:05
To: Rohit Yadav
Cc: Geoff Higginbottom; dev@cloudstack.apache.org
Subject: Re: [DISCUSS] Important: XenServer labels reverted for backward
compati
Rohit, how does the issue manifest itself? I ask because I thought I'd
taken care of every scenario during upgrade.
On Feb 2, 2015 10:52 AM, "Rohit Yadav" wrote:
> Hi Tim,
>
> Geoff found a issue today that breaks backward compatibility for
> XenServer users.
>
> Until 4.4, XenServer traffic la
Hi Tim,
Geoff found a issue today that breaks backward compatibility for
XenServer users.
Until 4.4, XenServer traffic label was xennetworklabel but in 4.5/master
it is xenservernetworklabel. To keep backward compatibility I'm
reverting such changes introduced in
a8212d9ef458dd7ac64b021e6fa33fcf
