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

Hi All, I am here with attaching the mockup screens for the proposed changes for s390x platform. Regards Chandra On 8/16/16 10:05 PM, Daniel Henrique Barboza wrote: > Hi Chandra, > > I like the option (2) you provided in all cases, because, as I've > said, it's a way to > add the new functionality without changing the existing API/code. If > libvirt for s390x > covers the gap and we decide that this new feature is now obsolete, > it is easier > to remove it too. > > Let's wait for Aline's feedback before deciding which API strategy > we're going to > use. Meanwhile I think you can start working in the backend modules > that will > add the interface XML to the VM XML (I consider this work to be > independent > of how the API will change). > > > Daniel > > > > On 08/16/2016 10:33 AM, Chandra Shekhar Reddy Potula wrote: >> >> Hi Daniel, >> >> Thanks for prompt inputs !!! >> >> Please see my further inputs. >> >> Regards >> Chandra >> On 8/15/16 7:40 PM, Daniel Henrique Barboza wrote: >>> Hi Chandra, >>> >>> Thanks for this detailed summary. I have a better idea of the >>> problem and the proposal now. >>> >>> First a generic comment: Kimchi also supports a libvirt network >>> called passthrough. >>> >>> Second, I think we may have a different approach here. I am seeing >>> that the 'network' >>> key isn't required in those APIs, they are optional. If we're going >>> into the trouble of changing >>> an existing API why not add a new optional parameter 'interface' to >>> attach the interface >>> into the VM without relying on libvirt networks? >>> >> We had thought about this option too but we were thinking in >> consolidating all the network attributes together. We were thinking >> too many attributes to deal with adding more of them. But I like >> your idea too. >> >>> This way you have a clearer functionality difference in the API and >>> it will be easier to code >>> because you will not mess with existing code that relies on libvirt >>> networks. And, in my opinion, >>> it can be used not only by s390x but for everyone that, for any >>> given reason, might want >>> to attach directly an interface to the VM instead of relying in a >>> libvirt network. >>> >>> Most of the work will be in adapting the existing UI to provide >>> both options (with or without >>> libvirt network) and show the user that they are mutually exclusive. >>> >>> Is the idea feasible? Making the 2 approaches coexist? >>> >>> >> See if Proposal 2 provided below looks good. >> >>> Daniel >>> >>> On 08/12/2016 10:45 AM, Chandra Shekhar Reddy Potula wrote: >>>> >>>> Hi All, >>>> >>>> Let me put the detailed summary !!! >>>> >>>> In case of platform s390x, any of the libvirt networks are not >>>> supported. The only way is attaching the physical interface >>>> macvtap or attaching ovs bridge directly to the guest at this >>>> point of time. >>>> >>>> *Expectation of the RFC is to attach macvtap and ovs directly to >>>> the guest with out libvirt API calls.* >>>> >>>> Example domain xml translations of macvtap and ovs (with out any >>>> libvirt calls): >>>> >>>> *OVS: * >>>> <interface type="bridge"> >>>> <source bridge="vswitch0"/> >>>> <virtualport type="openvswitch"/> >>>> <model type="virtio"/> >>>> </interface> >>>> >>>> *Macvtap:* >>>> 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> >>>> >>>> In order to achieve above functionality on s390x, recommend the >>>> following proposal to the templates and guest networking API’s >>>> (/templates and /vms/:name/ifaces): >>>> **Note : the same functionality can also exploited on other >>>> platforms too like on x86/ppc etc…* >>>> >>>> *1. Templates* >>>> A. Current : template.conf contains the following details for >>>> networks : >>>> >>>> [main] >>>> >>>> 
# List of networks separated by comma
# Represents the virtual >>>> network interfaces to be assigned to guest
#networks = default, >>>> >>>> Proposal : is to have dictionary based network details in the conf >>>> file similar to storage pools. >>>> >>>> [interfaces]
 >>>> >>>> # List of interfaces in the form of dictionary 
# Supports >>>> attaching virtual networks, macvtap and ovs bridge to the guest. >>>> # type can be of ‘network’ | ‘macvtap’ | ‘ovs’ >>>> # source can be list network or interface or resource bridge name. >>>> Comma separated values allowed if they are of same type. >>>> # mode required only for macvtap. mode can be either bridge or vepa >>>> >>>> [interfaces.0] >>>> #type=network >>>> #source=default >>>> #mode=NA >>>> >>>> For example to understand other possible types: >>>> [interfaces.1] >>>> #type=macvtap >>>> #source=eth0, eth1 >>>> #mode=bridge or vepa >>>> >>>> [interfaces.2] >>>> #type=ovs >>>> #source=ovsswitch1 >>>> #mode=NA >>>> >> Proposal 2: to have existing attribute /networks/ as list of virtual >> network as it is, and have additional attribute /interfaces/ for >> direct network connections (no libvirt calls). >> >> [main] >> # List of virtual/libvirt networks separated by comma
 >> # Represents the virtual/libvirt network interfaces to be assigned >> to guest
, by default default virtual network attached. >> # On s390x if attribute /networks/ commented out then no virtual >> network will be attached by default. >> #networks = default 
 >> >> Along with existing configuration additional attribute /interfaces/ >> for direct network interfaces >> >> [interfaces]
 >> # List of network interfaces in the form of dictionary >> 
# Supports attaching macvtap and ovs bridge to the guest. >> # type can be of ‘macvtap’ | ‘ovs’ >> # name can be of list network interface or ovs bridge name. Comma >> separated values allowed if they are of same type. >> # mode required only for macvtap. mode can be either bridge or vepa >> >> Please note by default no network interface will be attached to >> guest/template. >> >> For example to understand other possible types: >> [interfaces.1] >> #type=macvtap >> #name=eth0, eth1 >> #mode=bridge or vepa >> >> [interfaces.2] >> #type=ovs >> #name=ovsswitch1 >> #mode=NA >>>> >>>> B. API changes for the templates >>>> >>>> Current: network attributes for create/update of template >>>> networks (optional): list of networks will be assigned to the new VM. >>>> >>>> Proposal: >>>> networks (optional): list of dictionary of networks will be >>>> assigned to the new VM. >>>> type : ‘network’ | ‘macvtap’ | >>>> ‘ovs’. By specifying macvtap or ovs these interface will be >>>> attaching to guest directly. >>>> source : network or interface or >>>> resource bridge name >>>> mode(optional) : kimchi supports >>>> ’bridge’ or ‘vepa’. required only if type=‘macvtap’ >>>> >>>> >> Proposal 2: attribute /networks/ for get/create/update of template >> >> * networks (optional): list of virtual/libvirt networks will be >> assigned to the new VM. By default, /default virtual network/ >> will not be attached in case of s390x. >> >> ** >> In addition to the attribute /networks/, template API can have >> attribute /interfaces /to deal with direct network interfaces (no >> libvirt calls) >> >> * interfaces (optional) : list of dictionary of network interfaces >> to be assigned to the guest. By specifying macvtap or ovs these >> interface will be attaching to guest directly. >> >> type : ‘macvtap’ | ‘ovs’ >> name : network interface or ovs >> bridge name >> mode(optional) : kimchi supports >> ’bridge’ or ‘vepa’. required only if type=‘macvtap’ >> >> Please note by default no network interface will be attached to >> guest/template. >>>> >>>> *2. Virtual Machine Network Interfaces* >>>> *URI: */plugins/kimchi/vms/:name/ifaces >>>> >>>> Current: >>>> POST: attach a network interface to VM >>>> * model (optional): model of emulated network interface card. It >>>> can be one of these models: ne2k_pci, i82551, i82557b, i82559er, >>>> rtl8139, e1000, pcnet and virtio. When model is missing, libvirt >>>> will set 'rtl8139' as default value. >>>> * network (optional): the name of resource network, it is required >>>> when the interface type is network. >>>> * type: The type of VM network interface that libvirt supports. >>>> Now kimchi just supports 'network' type. >>>> >>>> Proposal: >>>> POST: attach a network interface to VM >>>> * model (optional): model of emulated network interface card. It >>>> can be one of these models: ne2k_pci, i82551, i82557b, i82559er, >>>> rtl8139, e1000, pcnet and virtio. When model is missing, libvirt >>>> will set 'rtl8139' as default value. >>>> * source : the name of resource network or interface or resource >>>> bridge name >>>> * type: kimchi supports 'network' | ‘macvtap’ | ‘ovs’ type. >>>> * mode : kimchi supports ’bridge’ or ‘vepa’. required only if >>>> type=‘macvtap’ >>>> >> Proposal 2: >> *GET*: >> >> * networks (optional): Retrieve a summarized list of all virtual >> network interfaces attached to a Virtual Machine. >> >> ** >> In addition to the attribute /networks/, API can have attribute >> /interfaces /to deal with direct network interfaces (no libvirt calls) >> >> * interfaces (optional): list of dictionary of network interfaces >> to be assigned to the Virtual Machine. By specifying macvtap or >> ovs, these interfaces will be attached to guest directly. >> >> type : ‘macvtap’ | ‘ovs’. >> name : network interface or ovs >> bridge name >> mode(optional) : kimchi supports >> ’bridge’ or ‘vepa’. required only if type=‘macvtap’ >> >> *POST*: attach a virtual network or direct interface to VM >> >> * model /(optional)/: model of emulated network interface card. It >> can be one of these models: ne2k_pci, i82551, i82557b, i82559er, >> rtl8139, e1000, pcnet and virtio. When model is missing, libvirt >> will set 'rtl8139' as default value. >> * network /(optional)/: the name of resource network, it is >> required when the interface type is network. >> * type: The type of VM network interface that libvirt supports. >> Now kimchi just supports 'network' type. >> >> In addition to the attribute /networks/, API can have attribute >> /interfaces /to deal with direct network interfaces (no libvirt calls) >> >> * interface (optional): network interface to be assigned to the >> Virtual Machine. By specifying macvtap or ovs, this interface >> will be attached to guest directly. >> type : ‘macvtap’ | ‘ovs’. >> name : network interface or ovs >> bridge name >> mode(optional) : kimchi supports >> ’bridge’ or ‘vepa’. required only if type=‘macvtap’ >> >>>> >>>> *3. Virtual Machine Network Interface** >>>> **URI:* /plugins/kimchi/vms/:name/ifaces/:mac >>>> >>>> Current: >>>> GET: Retrieve the full description of the VM network interface >>>> * bridge (optional): the name of resource bridge, only be >>>> available when the interface type is bridge. >>>> * mac: Media Access Control Address of the VM interface. >>>> * ips: A list of IP addresses associated with this MAC. >>>> * model (optional): model of emulated network interface card. It >>>> will be one of these models: ne2k_pci, i82551, i82557b, i82559er, >>>> rtl8139, e1000, pcnet and virtio. >>>> * network (optional): the name of resource network, only be >>>> available when the interface type is network. >>>> * type: The type of VM network interface that libvirt supports. It >>>> will be one of these types: 'network', 'bridge', >>>> 'user','ethernet', 'direct', 'hostdev', 'mcast', 'server' and >>>> 'client'. >>>> >>>> Proposal: >>>> GET: Retrieve the full description of the VM network interface >>>> * mac: Media Access Control Address of the VM interface. >>>> * ips: A list of IP addresses associated with this MAC. >>>> * model (optional): model of emulated network interface card. It >>>> will be one of these models: ne2k_pci, i82551, i82557b, i82559er, >>>> rtl8139, e1000, pcnet and virtio. >>>> * source: the name of resource network or resource bridge or interface >>>> * type: It will be one of these types: 'network', ‘macvtap’, >>>> ‘ovs’, ’bridge', 'user','ethernet', 'direct', 'hostdev', 'mcast', >>>> 'server' and 'client'. >>>> * mode : kimchi supports ’bridge’ or ‘vepa’. required only if >>>> type=‘macvtap’ >>>> >> Proposal 2: >> GET: Retrieve the full description of the VM network interface >> >> * bridge (optional): the name of resource bridge, only be >> available when the interface type is bridge. >> * mac: Media Access Control Address of the VM interface. >> * ips: A list of IP addresses associated with this MAC. >> * model (optional): model of emulated network interface card. It >> will be one of these models: ne2k_pci, i82551, i82557b, >> i82559er, rtl8139, e1000, pcnet and virtio. >> * network (optional): the name of resource network, only be >> available when the interface type is network. >> * type: The type of VM network interface that libvirt supports. It >> will be one of these types: 'network', 'bridge', >> 'user','ethernet', 'direct', 'hostdev', 'mcast', 'server' and >> 'client'. >> >> >> In addition to the attribute /networks/, API can have attribute >> /interfaces /to deal with direct network interfaces (no libvirt calls) >> >> * interface (optional): network interface to be assigned to the >> Virtual Machine. By specifying macvtap or ovs, this interface >> will be attached to guest directly. >> type : ‘macvtap’ | ‘ovs’. >> name : network interface or ovs >> bridge name >> mode(optional) : kimchi supports >> ’bridge’ or ‘vepa’. required only if type=‘macvtap’ >> >> >> *DELETE*: * >> * >> >> Deletion of network interfaces has to be supported along with >> virtual network deletions. >> >> >> *PUT*: >> >> * model /(optional)/: model of emulated network interface card. It >> will be one of these models: ne2k_pci, i82551, i82557b, >> i82559er, rtl8139, e1000, pcnet and virtio. This change is only >> on the persisted VM configuration. >> * network /(optional)/: the name of resource network, only be >> available when the interface type is network. This change is on >> the active VM instance and persisted VM configuration. >> >> In addition to the attribute /networks/, API can have attribute >> /interfaces /to deal with direct network interfaces (no libvirt calls) >> >> * interface (optional): network interface to be assigned to the >> Virtual Machine. By specifying macvtap or ovs, this interface >> will be attached to guest directly. >> type : ‘macvtap’ | ‘ovs’. >> name : network interface or ovs >> bridge name >> mode(optional) : kimchi supports >> ’bridge’ or ‘vepa’. required only if type=‘macvtap’ >> >> >>>> Please feel free to suggest any other better ways of doing !!! >>>> >>>> Regards >>>> Chandra >>>> On 8/11/16 4:46 PM, Suresh Babu Angadi wrote: >>>>> >>>>> >>>>> 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(a)ovirt.org >>>>>>>>> http://lists.ovirt.org/mailman/listinfo/kimchi-devel >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Kimchi-devel mailing list >>>>>>> Kimchi-devel(a)ovirt.org >>>>>>> http://lists.ovirt.org/mailman/listinfo/kimchi-devel >>>>>> >>>>>> _______________________________________________ >>>>>> Kimchi-devel mailing list >>>>>> Kimchi-devel(a)ovirt.org >>>>>> http://lists.ovirt.org/mailman/listinfo/kimchi-devel >>>>>> >>>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Kimchi-devel mailing list >>>> Kimchi-devel(a)ovirt.org >>>> http://lists.ovirt.org/mailman/listinfo/kimchi-devel >>> >>> >>> >>> _______________________________________________ >>> Kimchi-devel mailing list >>> Kimchi-devel(a)ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/kimchi-devel >> >> >> >> _______________________________________________ >> Kimchi-devel mailing list >> Kimchi-devel(a)ovirt.org >> http://lists.ovirt.org/mailman/listinfo/kimchi-devel > > > > _______________________________________________ > Kimchi-devel mailing list > Kimchi-devel(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/kimchi-devel