13:01:55 <alinefm> #startmeeting
13:01:55 <kimchi-bot> Meeting started Wed Apr 16 13:01:55 2014 UTC.  The chair is alinefm. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:01:55 <kimchi-bot> Useful Commands: #action #agreed #help #info #idea #link #topic.
13:01:55 <alinefm> #meetingname scrum
13:01:55 <kimchi-bot> The meeting name has been set to 'scrum'
13:02:13 <alinefm> #info Agenda 1) Status 2) Open discussion
13:02:13 <alinefm> anything else?
13:04:49 <royce> Hi there?
13:04:57 <alinefm> hi royce
13:05:07 <alinefm> #topic Status
13:05:07 <alinefm> #info Please provide your status using the #info command: #info <nickname> <status>
13:05:24 <royce> Hi alinefm, how are you doing?
13:05:46 <alinefm> royce, good and you?
13:06:13 <alinefm> #info alinefm added mechanism to translate help pages
13:06:13 <YuXin> #info YuXin Edit Guest Network Interface, Patch V1 sent, need to discuss the interface model
13:06:30 <rotru> #info rotru  is working in new patches of "edit vm cpu/memory" feature
13:06:37 <royce> #info royce finished guest disks manage backend patch v1, merged ide support 4 disks patch, now working on the UI for disk manage slowly...
13:06:42 <alinefm> #info alinefm created API to add users/groups to the vms
13:06:49 <royce> Doing good, alinefm
13:07:15 <alinefm> #info alinefm now I am working on a API to list all system users and groups - it will be useful when user will update the vm users/groups from UI
13:08:13 <shaohef> #info shaohef send version API support.
13:09:59 <alinefm> great, team!
13:10:08 <alinefm> we still have a lot to do in a week
13:10:14 <alinefm> next week is the end of sprint 1
13:10:55 <alinefm> I still need to send a first version of history data view
13:11:04 <alinefm> I plan to do it by tomorrow
13:11:34 <alinefm> anyone has blockers?
13:12:51 <alinefm> anyonde has concerns about the time to deliver all tasks planned?
13:14:14 <royce> alinefm, me, I'm not familiar with js so I'm not sure I can finish the backend and frontend of manage guest disk in time
13:14:50 <alinefm> adamkingit, YuXin, hlwanghl, anyone can help royce on it?
13:15:12 <royce> hlwanghl gave me help on that, thanks to him
13:15:52 <royce> but since the backend is just on v1
13:16:09 <alinefm> royce, I will review your patches today
13:16:19 <alinefm> so you can get feedback soon
13:16:20 <royce> and I plan to submit v1 of UI tomorrow
13:16:25 <royce> Thanks alinefm
13:16:28 <alinefm> royce, good
13:16:47 <royce> I'll try my best
13:16:57 <alinefm> royce, I know =)
13:17:02 <adamkingit> looking at the sprint plan, we have come completes to go
13:17:12 <alinefm> don't hesitate to ask help
13:17:27 <adamkingit> https://github.com/kimchi-project/kimchi/wiki/Todo-1.2.1
13:17:47 <danielhb> #info danielhb submitted a 5th version of "kimchi must not run as root" with the FABULOUS help of alinefm . Patch is waiting for review/approval
13:18:17 <alinefm> danielhb, ;-)
13:19:19 <alinefm> adamkingit, yes
13:19:33 <alinefm> I'd like to see more patches on ML
13:19:51 <alinefm> maybe it can help us get all done in time
13:21:06 <alinefm> ok - let's move on to open discussion section
13:21:10 <alinefm> #topic Open Discussion
13:21:12 <rotru> #info rotru investigated and helped to fix problems when create multiple templates
13:21:31 <alinefm> YuXin, do you want to discuss about the interface model?
13:21:45 <YuXin> yes
13:22:20 <YuXin> from shao he, I got to know that the backend only select a model that can work with all operating systems
13:22:37 <YuXin> it will not be the best, so user may need to update it
13:23:16 <YuXin> I suggest to reserve the model, but make the most compatible model to be defaut when create guest network interface
13:24:41 <alinefm> YuXin, by reserve do you mean keep showing it when creating the interface?
13:24:51 <YuXin> yes
13:25:21 <YuXin> make the most compatible one to be default option for model field
13:26:41 <alinefm> YuXin, ok
13:26:47 <YuXin> ok
13:26:51 <alinefm> shaohef, the default one will be virtio?
13:27:20 <YuXin> no
13:27:33 <YuXin> as far as I know, virtio only works for linux
13:28:06 <alinefm> YuXin, so which model will be the default?
13:28:07 <YuXin> just checked mail, default is rtl8139
13:28:17 <alinefm> ok
13:28:30 <YuXin> virtio is the best for linux, but will not work for windows
13:28:43 <shaohef> alinefm: no the default is not virtio.
13:28:47 <alinefm> YuXin, did you see my comment about the UI consistence ? to make storage and interface views similar
13:28:58 <adamkingit> can we default based on detected OS?
13:29:29 <YuXin> update storage UI to make it consistent need to be in another patch
13:29:37 <shaohef> rtl8139 emulates a physical NIC.
13:29:41 <YuXin> I will check it tomorrow to figure out the design
13:29:48 <shaohef> virtio  is a para-virtualization NIC, high performance than an emulated  physical NIC.
13:30:40 <shaohef> For the VM will not store any template information, after it is create.
13:30:40 <shaohef> The backend do not know which the model type is the best after we has  install OS on VM.
13:31:05 <shaohef> we only know the best model type  when we create a VM.
13:31:05 <shaohef> That's because, the template tell us the guest OS and the best model for  this OS.
13:31:43 <alinefm> shaohef, maybe would be good to store that info when creating the vm
13:31:51 <alinefm> and the objectstore
13:31:58 <alinefm> *in the objectstore
13:32:10 <shaohef> So has discussed with alinefm before, at last we let libvirt to choose a model for interface.
13:32:36 <alinefm> shaohef, it is also a good option
13:32:50 <alinefm> do you know the libvirt criterias to choose the model?
13:32:53 <adamkingit> Will relying on objectstore impede vm migration?
13:33:13 <shaohef> alinefm: libvirt only choose rtl8139
13:33:33 <royce> I stored this info when creating vm for cdrom bus and disk bus too
13:33:45 <shaohef> alinefm: I can store the template information for VM
13:34:16 <alinefm> adamkingit, I don't think so
13:34:30 <royce> Or we cannot choose proper disk bus for a vm, especially when some vm's not creating on x86, the bus type's different
13:34:41 <alinefm> we already use the objectstore to store some vm info - like icon
13:34:57 <adamkingit> Storing the template with the VM may break our mental model. The cookie doesn't change shape once cut, even if the cutter gets bent
13:35:48 <adamkingit> hmm, I think that will be a problem for migration. At least consistency, unless we require a shared DB which we don't want
13:35:49 <royce> I stored distro and version not the template, shaohef do you need the same?
13:35:51 <alinefm> adamkingit, we will not store the all template info
13:35:56 <shaohef> YuXin, then what about if user reinstall OS on a guest. This new OS maybe different with the old one.
13:35:57 <alinefm> just the iface model
13:36:14 <adamkingit> Can we store what we need in the vm definition metadata?
13:36:47 <YuXin> shaohef, correct, model will need to be updated
13:36:53 <alinefm> royce, and then you use osdistro to get the properly bus?
13:37:00 <shaohef> seems metadata is a option
13:37:05 <royce> that'll be a problem, shaohef
13:37:23 <YuXin> fuctonality will be limited if model is transparent to user
13:37:27 <royce> yes, alinefm, I used it as a suggestion if user not pass this info
13:37:35 <royce> pass the bus info
13:38:29 <adamkingit> I feel like I need to see a picture. yuxin: would you take screenshots of the relevent screens, and just use OpenOffice to draw in the things you propose to change?
13:39:02 <YuXin> let me try to connect to my office desktop
13:40:31 <YuXin> how can paste screen-shot
13:41:24 <YuXin> let me send a mail to mail list
13:41:44 <shaohef> YuXin: http://picpaste.com
13:43:26 <YuXin> Guest Network Interface Design
13:43:28 <YuXin> check mail
13:44:46 <YuXin> mail sent failed
13:45:41 <alinefm> YuXin, I received it
13:46:05 <YuXin> shaohef, pretty slow to load kimchi-devel@ovirt.org
13:46:18 <adamkingit> i got it
13:46:26 <YuXin> ok
13:47:10 <adamkingit> so we choose a defualt model at VM create time based on what shuold be good for the installed guest OS, but we allow edits here in the event an override is needed?
13:48:30 <alinefm> adamkingit, we choose the default value which is rtl8139
13:48:37 <alinefm> independent of guest OS
13:48:53 <adamkingit> ah, so we always default to rtl8139
13:49:04 <adamkingit> making it more likely someone would want to change this?
13:49:27 <shaohef> virtio as default?
13:49:38 <royce> Is that the same for disk bus? IDE by default, this will disable hot plug
13:50:21 <royce> or virtio by default?
13:50:36 <YuXin> rtl8139 works for all OS, but not the best for a certain OS like linux
13:50:49 <YuXin> virtio is the best for linux but do not work for windows
13:51:04 <adamkingit> perhaps we should choose virtio when we know its a linux vm
13:51:18 <alinefm> adamkingit, yes
13:51:24 <alinefm> and keep rtl8139 to windows
13:51:44 <adamkingit> fall back to rtl8139 when we can't tell or we know its windows, unless there is a better chioce for windows too
13:51:59 <YuXin> shaohef, can you handle this at backend, then we can make model to be transparent to user
13:52:39 <royce> by tell os version is that mean we need to store it? or choose is let user choose it
13:53:27 <adamkingit> We create the network when we create the VM. I don't think we would need to store it w/ the VM, only with the template
13:53:56 <shaohef> YuXin: sure.
13:54:05 <alinefm> adamkingit, we can add networks interfaces after vm is created
13:54:27 <adamkingit> true, though we should already have 1
13:54:39 <adamkingit> use the same model for 2-n?
13:54:46 <YuXin> ok, since backend can intelligently select for the best model, then I will remove model to make it transparent
13:54:59 <shaohef> adamkingit: yes. this is my first design.
13:55:06 <adamkingit> :-)
13:55:17 <alinefm> YuXin, ok
13:55:39 <alinefm> shaohef, it is implemented that way?
13:55:50 <royce> Ok, I'm in that one
13:56:01 <shaohef> adamkingit: alinefm: I have send it to mail-list.
13:56:10 <royce> I'm on that one
13:56:19 <shaohef> alinefm: but later, you and me discuss this problem. we change it.
13:57:05 <shaohef> alinefm: for we decided to libvirt choose the model.
13:57:32 <adamkingit> sounds like we since discovered libvirt does so much choose, as default to most common
13:57:33 <shaohef> alinefm: adamkingit: but I can change it.  :)
13:57:49 <adamkingit> **doesn't**
13:57:57 <alinefm> shaohef, do you remember why we decided to change? some special reason?
13:58:30 <royce> when all removed?
13:58:57 <shaohef> alinefm: a long time ago. I need to check the log.
14:00:28 <YuXin> shaohef, remember to add "update interface" api
14:01:06 <alinefm> royce, good point
14:01:32 <royce> when no interface exist, we lack of reference, then fall back to the emulated one
14:01:53 <alinefm> yes
14:01:59 <alinefm> shaohef, adamkingit, ^ what do you think?
14:02:01 <adamkingit> or we could take your 1st suggestion and store the model in the metadata
14:03:20 <shaohef> alinefm:  store in metadata? but when user re-install other OS different with tho older OS.
14:03:45 <adamkingit> why would a user reinstall a VM instead of deleting it and creating a new one?
14:03:59 <alinefm> shaohef, royce, adamkingit, for power: nic_model='spapr-vlan'
14:04:38 <alinefm> adamkingit, keep /home intact?
14:05:10 <shaohef> adamkingit: we suggest to  delete  create a new one
14:05:15 <adamkingit> which implies same type os?
14:06:18 <alinefm> adamkingit, no - you can have 2 partitions
14:06:30 <alinefm> 1 for /home and other for linux itself
14:06:42 <alinefm> reinstall the linux partition keep /home intact
14:06:50 <adamkingit> yes, but if you do that you aren't very likely to be installing windows on the 1st partition
14:07:11 <royce> And upgrade?
14:07:36 <royce> like upgrade a old model linux to a model one
14:07:57 <royce> moden
14:08:04 <adamkingit> would a change in linux versions indicate a need to change the network model?
14:08:28 <alinefm> yes
14:08:32 <alinefm> in some times
14:09:04 <royce> adamkingit, because some qemu/kernel lack of full virtio support, we use emulated one
14:09:05 <alinefm> from vm xml we can get the arch:
14:09:09 <alinefm> <os>
14:09:09 <alinefm> <type arch='x86_64' machine='pc-1.2'>hvm</type>
14:09:09 <alinefm> <boot dev='cdrom'/>
14:09:09 <alinefm> </os>
14:09:21 <alinefm> that way we can differ power and X systems
14:09:23 <shaohef> royce:  in src/kimchi/osinfo.py
14:09:29 <royce> right, shaohef
14:09:46 <shaohef> modern_spec = dict(common_spec, disk_bus='virtio', nic_model='virtio')
14:10:04 <shaohef> modern_spec is virtio
14:10:35 <adamkingit> ok, so based on what is installed at the time we can choose something that will work well for that installation
14:11:03 <adamkingit> if the user chooses to install a diff OS inside the VM, then we may no longer have the optimal chioce
14:11:54 <alinefm> adamkingit, are you saying to store os/version and based on that get the proper model?
14:12:23 <adamkingit> I WAS, but I think you changed my mind...
14:12:30 <alinefm> hehehe
14:12:33 <alinefm> why?
14:12:50 <adamkingit> We know enough at the template level to choose the right model when we create the VM
14:13:25 <adamkingit> IF the user chooses to reinstall teh OS inside the VM, we may not have the optimal model
14:13:52 <adamkingit> but if the user deletes the VM and creates a new one from a diff template we are back in the land of the good
14:15:11 <YuXin> I think reinstall OS will be quite rare
14:15:29 <adamkingit> so I think you talked me into: we store the network model in the metadata at VM create timem and we use that choice whenever creating new networks for a VM
14:16:13 <alinefm> adamkingit, but in a reinstall the metadata is lost with the network model
14:16:22 <royce> hehheh
14:16:50 <alinefm> in this case back to the default? virtio for linux and rtl8139 for win?
14:17:08 <adamkingit> alinefm: The VM metadata shouldnt be affected by what happens INSIDE the VM
14:17:09 <alinefm> royce, we are talking and always block in same point
14:17:12 <alinefm> hehehe
14:17:49 <shaohef> template_specs = {'x86': {'old': dict(common_spec, disk_bus='ide',
14:17:49 <shaohef> nic_model='e1000', sound_model='ich6'),
14:18:12 <alinefm> adamkingit, good point =)
14:18:20 <alinefm> and the same for the networks interfaces
14:18:21 <shaohef> not sure which is better rtl8139 and e1000. they are both emulate nic.
14:18:38 <alinefm> reinstall will not remove them
14:18:58 <adamkingit> so the guest would come up on the same networks it was on before
14:19:32 <alinefm> adamkingit, but we need metadata to know which model to use when user deletes all networks interfaces
14:20:06 <adamkingit> which is where I was proposing we choose the network model when we create the VM, and store that info in metadata
14:20:34 <alinefm> I am OK with it
14:20:37 <alinefm> shaohef, royce ^
14:20:38 <alinefm> ?
14:20:44 <royce> +1
14:21:06 <shaohef> I'm Ok
14:22:19 <adamkingit> I think we have been in circles a bit because we are trying to combine 2 things into one simple concept
14:22:43 <adamkingit> virtually
14:22:45 <adamkingit> 1)what kind of, and how many NICs are in the machine
14:23:03 <adamkingit> 2) What networks are those cards connected to.
14:23:21 <adamkingit> In the physical world, you open the case and put a card in a slot for 1
14:23:43 <adamkingit> and you put a cable from the card to some switch
14:24:21 <adamkingit> I think we arrived at an acceptable simplification, which we hope works for people
14:24:45 <alinefm> yeap - it was  good discussion
14:24:52 <alinefm> shaohef, are you going to address it on backend?
14:25:14 <adamkingit> If we learn that people really want to control  those 2 things sepaately, we can revisit
14:25:39 <shaohef> alinefm:  yes.
14:25:39 <alinefm> shaohef, in my patches to add users/groups to vms I used the metadata tag but I always rebuild it
14:25:43 <alinefm> need to update it as well
14:25:58 <alinefm> to only update the <access> element
14:26:29 <alinefm> ok
14:26:35 <alinefm> let's finish for today
14:26:52 <alinefm> if anyone has more topics I will be here
14:27:00 <alinefm> I will just end the meeting
14:27:05 <alinefm> thanks all for joining
14:27:09 <alinefm> #endmeeting