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 prepare_pxe.sh and baremetal_snat.sh 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.


Cheers,

Hugo


On 2 okt. 2014, at 02:04, Frank Zhang <frank.zh...@citrix.com> 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 [mailto:trip...@gmail.com] 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 <frank.zh...@citrix.com> 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 [mailto:trip...@gmail.com] 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 
>>>> that.
>>>> 
>>>> 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 <trip...@gmail.com> 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 <frank.zh...@citrix.com> wrote:
>>>>>> 
>>>>>> 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 [mailto:trip...@gmail.com] 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/id_rsa.cloud".
>>>>>>> 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. Also
>>>>>>> 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 <frank.zh...@citrix.com>
>>>>>>> Date:   Thu Sep 25 10:35:33 2014 -0700
>>>>>>> 
>>>>>>> CLOUDSTACK-6278
>>>>>>> Baremetal Advanced Networking support
>>>>>>> 
>>>>>>> 
>>>>>>> Cheers,
>>>>>>> 
>>>>>>> Hugo
>>>>>> 
>>> 
> 

Reply via email to