cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hugo Trippaers <>
Subject Re: commit 44a4158c4854d85e4c234655e375fe0c631507d5
Date Thu, 02 Oct 2014 08:58:44 GMT
You can see that the Vmware resource provides the VirtualRouterDeployer interface. So all communication
with the VR is triggered by the VirtualRoutingResource based on commands send using the agent
framework. The vmware resource then only deals with execution and file copy as directed by
the interface. This way the communication between the VR and cloudstack can be determined
per type of hypervisor.

Looking at you code it is fairly easy to replace what you currently do with agent based communication.
If the virtual routingresource knows about the PrepareKickstartPxeServerCommand command and
triggers the correct scripts with the right parameters we are pretty much done. I’m already
writing a small prototype to see if my thinking on this is correct.

One thing i’m wondering about is how do the scripts get on the VR? I think they are currently
not included in the regular systemvm build right? Should we add the scripts
and to the regular systemvm and maybe add all the bits for bare metal?

As discussed a CC to the dev list so more people can think with us on this.



On 2 okt. 2014, at 02:04, Frank Zhang <> wrote:

> Yes please.
> I totally don't know we have changed to agent in vmware VR. I need to confirm with some
vmware/VR guys.
>> -----Original Message-----
>> From: Trippie [] On Behalf Of Hugo Trippaers
>> Sent: Wednesday, October 01, 2014 1:11 AM
>> To: Frank Zhang
>> Subject: Re: commit 44a4158c4854d85e4c234655e375fe0c631507d5
>> Vmware also mainly uses the agent system for communicating with the virtual
>> routers as far as i can see.
>> There are only a few instances i could find that have resources directly talking
>> to the VR instead of going through the proper interfaces.
>> But you are right we should bring this to the community, are you ok if i forward
>> this thread to the dev list?
>> Cheers,
>> Hugo
>> On 30 sep. 2014, at 19:23, Frank Zhang <> wrote:
>>> I think we should open a discussion in community.
>>> I am not aware anything for redundant VPC router. But if what you say
>> happens, it certainly breaks vmware VR communication.
>>> Though I am not vmware guy, I am sure vmware is designed to use this way
>> to communicate to VR.
>>>> -----Original Message-----
>>>> From: Trippie [] On Behalf Of Hugo Trippaers
>>>> Sent: Tuesday, September 30, 2014 6:43 AM
>>>> To: Frank Zhang
>>>> Subject: Re: commit 44a4158c4854d85e4c234655e375fe0c631507d5
>>>> Frank,
>>>> Amy more thoughts on this? This way of directly accessing the virtual
>>>> router will probably break anyway when the refactoring for the
>>>> redundant VPC router is done, so it would be nice to have it fixed before
>>>> I don't mind helping out with moving the commands to the ConfigHelper
>>>> if you need  a hand?
>>>> Cheers,
>>>> Hugo
>>>> On 27 sep. 2014, at 14:04, Hugo Trippaers <> wrote:
>>>>> Hey Frank,
>>>>> The keyfile should be on the class path. The entire script directory
>>>>> is on there
>>>> afaik.
>>>>> Besides that isn't it possible to program the VR using the regular
>>>>> agent
>>>> methods? If we don't we might break stuff in the future when rewrites
>>>> happen to the VR.
>>>>> Cheers,
>>>>> Hugo
>>>>> Sent from my iPhone
>>>>>> On 27 sep. 2014, at 01:03, Frank Zhang <>
>>>>>> Hmm, I follow the same code in vmware, it's not baremetal invention.
>>>>>> Do we have these keys on classpath?
>>>>>> Baremetal need to login vmware virtual router to program some PXE
>>>>>> stuff, that's why we need the key file
>>>>>>> -----Original Message-----
>>>>>>> From: Trippie [] On Behalf Of Hugo
>>>>>>> Trippaers
>>>>>>> Sent: Friday, September 26, 2014 2:00 AM
>>>>>>> To: Frank Zhang
>>>>>>> Subject: commit 44a4158c4854d85e4c234655e375fe0c631507d5
>>>>>>> Hey Frank,
>>>>>>> The following commit includes a fixed path name
>>>>>>> "/usr/share/cloudstack- common/scripts/vm/systemvm/".
>>>>>>> Can you rewrite this to not use a fixed path? Fixed paths will
>>>>>>> eventually lead to bugs as we can't guarantee people using
>>>>>>> CloudStack will use our packaging formats and our locations.
>>>>>>> if the class loader can't find the file, it's not there and
>>>>>>> referencing it directly
>>>> should not make any difference.
>>>>>>> On a side note, what does this have to do with Baremetal Advanced
>>>> Networking?
>>>>>>> commit 44a4158c4854d85e4c234655e375fe0c631507d5
>>>>>>> Author: Frank Zhang <>
>>>>>>> Date:   Thu Sep 25 10:35:33 2014 -0700
>>>>>>> CLOUDSTACK-6278
>>>>>>> Baremetal Advanced Networking support
>>>>>>> Cheers,
>>>>>>> Hugo

View raw message