[Kimchi-devel] RFC: Templates API changes for 'networks' attribute

[Suresh Babu Angadi]

On 08/10/2016 11:56 PM, Daniel Henrique Barboza wrote:
> A lot of changes to be made.
>
> The changes in Ginger -> Gingerbase regarding OVS bridges is the simplest
> to do. Gingerbase already has some OVS legacy functions from before 
> Ginger
> developed the OVS bridges backend in the module netinfo.py. We can see if
> there's something there to list OVS interfaces (can't recall now) and, 
> if not, we
> can add it.
>
> The remaining Kimchi changes will need to either do in small chunks, 
> avoiding
> changing the working code we have today, or all at once with UI 
> changes included
> to avoid breaking the existing UI with the API change. I'll leave it 
> up to you which
> approach to go, as long as we don't break the existing network support 
> in Kimchi
> in the process.
Agree.
>
> Assuming that all this precautions are made, I approve this RFC. 
> However, note that
> this is *my* opinion. I am not the official maintainer of this plug-in 
> and it would
> be unwise to rely solely on it. It is safer to wait for Aline's 
> opinion in this
> RFC before taking any step toward the implementation.
To support s390x architecture which doesn't support libvirt virtual 
networks as of today,, its necessary to allow attaching physical 
interface to guest. Hence would start implementing, however any 
changes/suggestions can be accommodated.
>
>
> Daniel
>
> On 08/10/2016 05:46 AM, Archana Singh wrote:
>>
>> On 08/10/2016 12:23 PM, Suresh Babu Angadi wrote:
>>>
>>>
>>> On 08/10/2016 12:24 AM, Daniel Henrique Barboza wrote:
>>>> I am worried not only by the API.json changes but also in the
>>>> potential backend changes required. Do you have any prediction of
>>>> how far these changes might go?
>>> from backend, it would remain same for virtual network. For macvtap, 
>>> validation of interface would be okay since interfaces listing is 
>>> moved to gingerbase and kimchi is using it for networks hence same 
>>> code can be utilized. For openvswitch, ginger code will have to be 
>>> moved to gingerbase to enable kimchi to list host ovs interfaces.
>> On high level I guess below needs to be done, and both point below 
>> are independent of each-other.
>> 1) Listing of networks based on selected type. (This will mostly use 
>> to show list in UI, based on type).
>> 2) Once network is selected/provided, an REST API call which will 
>> land to control and model. From control point of view it will be 
>> addition of parameters. And from model point of view, we need to add 
>> if and else to check type.
>> And for virtual type, existing code implementation should work. And 
>> for other two type, we need add code for addition of these options in 
>> template params. And also code to generate corresponding xml based on 
>> type.
>> It will be mostly on template/guest edit/create code and network 
>> add/remove from guest/template.
>>
>> May be validation of network(s) to check if network(s) exist( for 
>> type macvtap and ovs) or not can be done as improvement to feature.
>>
>>>>
>>>> On 08/09/2016 06:12 AM, Suresh Babu Angadi wrote:
>>>>> Hi All,
>>>>> To support, attaching a physical interface to guest as macvtap or 
>>>>> attaching ovs bridge to guest without creating libvirt network, I 
>>>>> propose following changes to 'networks' attribute of templates josn.
>>>>>
>>>>> current implementation:
>>>>> 'networks' attribute expects list of virtual network names
>>>>>
>>>>> changes:
>>>>> 'networks': list of dictionary
>>>>>                 type: can be direct, network or bridge
Small change in type, to be explicit, its good to have type as 
macvtap(instead of direct), ovs(instead of bridge) and 
virtualnetwork(instead of network).
>>>>>                 interface: name of physical interface(type=direct) 
>>>>> or ovs (type=bridge) or virtual network(type=direct)
>>>>>                 mode(required if type=direct): bridge or vepa
>>>>>
>>>>> for macvtap: type is direct and mode can be bridge or vepa
>>>>> for ovs: type is bridge and mode is not required
>>>>> for virtual network: type=network(current implementation)
>>>>>
>>>>> Examples of network xml for attaching macvtap and ovs to guest 
>>>>> without libvirt:
>>>>> OVS:
>>>>> <interface type="bridge">
>>>>>   <source bridge="vswitch0"/>
>>>>>   <virtualport type="openvswitch"/>
>>>>>   <model type="virtio"/>
>>>>> </interface>
>>>>>
>>>>> macvtap with bridge mode:
>>>>> <interface type="direct">
>>>>>   <source dev="eth0" mode="bridge"/>
>>>>>   <model type="virtio"/>
>>>>> </interface>
>>>>>
>>>>>  macvtap with vepa mode:
>>>>> <interface type="direct">
>>>>>   <source dev="bond0" mode="vepa"/>
>>>>>   <model type="virtio"/>
>>>>> </interface>
>>>>>
>>>>
>>>> _______________________________________________
>>>> Kimchi-devel mailing list
>>>> Kimchi-devel at ovirt.org
>>>> http://lists.ovirt.org/mailman/listinfo/kimchi-devel
>>>>
>>>
>>
>> _______________________________________________
>> Kimchi-devel mailing list
>> Kimchi-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/kimchi-devel
>
> _______________________________________________
> Kimchi-devel mailing list
> Kimchi-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/kimchi-devel
>

-- 
Regards,
Suresh Babu Angadi