Re: [vdsm] vdsm networking changes proposal
Hi, Alon Bar-Lev píše v Ne 17. 02. 2013 v 15:57 -0500: Hello Antoni, Great work! I am very excited we are going this route, it is first of many to allow us to be run on different distributions. I apologize I got to this so late. Notes for the model, I am unsure if someone already noted. I think that the abstraction should be more than entity and properties. For example: nic is a network interface bridge is a network interface and ports network interfaces bound is a network interface and slave network interfaces vlan is a network interface and vlan id network interface can have: - name - ip config - state - mtu this way it would be easier to share common code that handle pure interfaces. I don't quite understand the 'Team' configurator, are you suggesting a provider for each technology? Team is a new implementation of bonding in Linux kernel IIRC. bridge - iproute2 provider - ovs provider - ifcfg provider bond - iproute2 - team - ovs - ifcfg vlan - iproute2 - ovs - ifcfg So we can get a configuration of: bridge:iproute2 bond:team vlan:ovs ? I also would like us to explore a future alternative of the network configuration via crypto vpn directly from qemu to another qemu, the idea is to have a kerberos like key per layer3(or layer2) destination, while communication is encrypted at user space and sent to a flat network. The advantage of this is that we manage logical network and not physical network, while relaying on hardware to find the best route to destination. The question is how and if we can provide this via the suggestion abstraction. But maybe it is too soon to address this kind of future. Isn't it better to separate the two goals and persuade qemu developers to implement TLS for migration connections? David For the open questions: 1. Yes, I think that mode should be non-persistence, persistence providers should emulate non-persistence operations by diff between what they have and the goal. 2. Once vdsm is installed, the mode it runs should be fixed. So the only question is what is the selected profile during host deployment. 3. I think that if we can avoid aliases it would be nice. 4. Keeping the least persistence information would be flexible. I would love to see a zero persistence mode available, for example if management interface is dhcp or manually configured. I am very fond of the iproute2 configuration, and don't mind if administrator configures the management interface manually. I think this can supersede the ifcfg quite easily in most cases. In these rare cases administrator use ovirt to modify the network interface we may consider delegating persistence to totally different model. But as far as I understand the problem is solely related to the management connectivity, so we can implement a simple bootstrap of non-persistence module to reconstruct the management network setup from vdsm configuration instead of persisting it to the distribution width configuration. Regards, Alon Bar-Lev - Original Message - From: Antoni Segura Puimedon asegu...@redhat.com To: a...@ovirt.org, vdsm-de...@fedorahosted.org Sent: Friday, February 8, 2013 12:54:23 AM Subject: vdsm networking changes proposal Hi fellow oVirters! The network team and a few others have toyed in the past with several important changes like using open vSwitch, talking D-BUS to NM, making the network non-persistent, etc. It is with some of this changes in mind that we (special thanks go to Livnat Peer, Dan Kenigsberg and Igor Lvovsky) have worked in a proposal for a new architecture for vdsm's networking part. This proposal is intended to make our software more adaptable to new components and use cases, eliminate distro dependancies as much as possible and improve the responsiveness and scalability of the networking operations. To do so, it proposes an object oriented representation of the different elements that come into play in our networking use cases. But enough of introduction, please go to the feature page that we have put together and help us with your feedback, questions proposals and extensions. http://www.ovirt.org/Feature/NetworkReloaded Best regards, Toni ___ Arch mailing list a...@ovirt.org http://lists.ovirt.org/mailman/listinfo/arch ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel -- David Jaša, RHCE SPICE QE based in Brno GPG Key: 22C33E24 Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24 ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] VDSM Repository Reorganization
Hi everyone, It would be nice to come to an agreement any time soon. I would like to apply all the change as soon as possible. I would not like to see this go into the depth of a dead hole. Thanks. On 02/13/2013 03:54 PM, Vinzenz Feenstra wrote: On 02/13/2013 03:08 PM, Yaniv Bronheim wrote: First lets illustrate the current repository structure: - tests - vdsm - storage - gluster - betterPopen ... and more unused directories - vdsm_api - vdsm_cli - vdsm_hooks - vdsm_log - vdsm_reg - vdsm_tools - vds_bootstrap - contrib As I understand your proposal, you added 'common' and 'deamon' and left the rest the way it is. So vdsm can be renamed to vdsm_core and can include sub folders for deamon and common\lib python files. It'll be something like: - vdsm_core - deamon - vdsmd .. - more deamon scripts - lib - independent tools - can also be part of vdsm_tools, as it doesn't part of the vdsm_core - utils.py - betterPopen - dmidecode ... - more unrelated utils that vdsm uses - core - vdsm - API.py - clientIF.py - config.py defines.py constants.py ... should be part of vdsm_core - libvirtconnection.py ... core files of vdsm - storage ... as it now without files that can be and should be moved to lib folder (e.g. threadPool, task, taskManager and inc..) the rest we'll stay the same. about the installation location it something else.. In my opinion this arrangement is nice to have, but not a must - we'll still need to set PYTHONPATH when we run from different locations (what you called making an hack), so as I see it, it just for comfort.. no? Maybe I missed something.. (And tests can be split to subfolders for each part - core\tests lib\tests and inc..) - Original Message - From: Federico Simoncelli fsimo...@redhat.com To: Adam Litke a...@us.ibm.com Cc: VDSM Project Development vdsm-devel@lists.fedorahosted.org Sent: Wednesday, February 13, 2013 1:06:55 AM Subject: Re: [vdsm] VDSM Repository Reorganization - Original Message - From: Adam Litke a...@us.ibm.com To: Federico Simoncelli fsimo...@redhat.com Cc: VDSM Project Development vdsm-devel@lists.fedorahosted.org, Dan Kenigsberg dan...@redhat.com, Saggi Mizrahi smizr...@redhat.com, Vinzenz Feenstra vfeen...@redhat.com, Ayal Baron aba...@redhat.com Sent: Tuesday, February 12, 2013 9:08:09 PM Subject: Re: VDSM Repository Reorganization On Mon, Feb 11, 2013 at 12:17:39PM -0500, Federico Simoncelli wrote: It is some time now that we are discussing an eventual repository reorganization for vdsm. In fact I'm sure that we all experienced at least once the discomfort of having several modules scattered around the tree. The main goal of the reorganization would be to place the modules in their proper location so that they can be used (imported) without any special change (or hack) even when the code is executed inside the development repository (e.g. tests). Recently there has been an initial proposal about moving some of these modules: http://gerrit.ovirt.org/#/c/11858/ That spawned an interesting discussion that must involve the entire community; in fact before starting any work we should try to converge on a decision for the final repository structure in order to minimize the discomfort for the contributors that will be forced to rebase their pending gerrit patches. Even if the full reorganization won't happen in a short time I think we should plan the entire structure now and then eventually move only few relevant modules to their final location. To start the discussion I'm attaching here a sketch of the vdsm repository structure that I envision: . |-- client | |-- [...] | `-- vdsClient.py |-- common | |-- [...] | |-- betterPopen | | `-- [...] | `-- vdsm | |-- [...] | `-- config.py |-- contrib | |-- [...] | |-- nfs-check.py | `-- sos |-- daemon | |-- [...] | |-- supervdsm.py | `-- vdsmd `-- tool |-- [...] `-- vdsm-tool The schema file vdsmapi-schema.json (as well as the python module to parse it) are needed by the server and clients. Initially I'd think it should be installed in 'common', but a client does not need things like betterPopen. Any recommendation on where the schema/API definition should live? The problem is that betterPopen is misplaced as it's used only by the daemon. Anyway let's not mix the three different aspects: +1 - repository structure Well that's what is supposed to be the topic. - installation location - packaging Those are supposed to be off topic considerint $SUBJECT That said in my opinion it can remain in common (which can be renamed to lib as Ewoud suggested) and be installed in the site-lib *but* be packaged only with the daemon (while we're waiting for it to become fully independent and be moved out of the repo). Where such things could be put in a folder 'extra' for now. (As an example) I suppose that the code
Re: [vdsm] VDSM Repository Reorganization
- Original Message - From: Adam Litke a...@us.ibm.com To: Federico Simoncelli fsimo...@redhat.com Cc: VDSM Project Development vdsm-devel@lists.fedorahosted.org, Dan Kenigsberg dan...@redhat.com, Saggi Mizrahi smizr...@redhat.com, Vinzenz Feenstra vfeen...@redhat.com, Ayal Baron aba...@redhat.com Sent: Tuesday, February 12, 2013 3:08:09 PM Subject: Re: VDSM Repository Reorganization On Mon, Feb 11, 2013 at 12:17:39PM -0500, Federico Simoncelli wrote: It is some time now that we are discussing an eventual repository reorganization for vdsm. In fact I'm sure that we all experienced at least once the discomfort of having several modules scattered around the tree. The main goal of the reorganization would be to place the modules in their proper location so that they can be used (imported) without any special change (or hack) even when the code is executed inside the development repository (e.g. tests). Recently there has been an initial proposal about moving some of these modules: http://gerrit.ovirt.org/#/c/11858/ That spawned an interesting discussion that must involve the entire community; in fact before starting any work we should try to converge on a decision for the final repository structure in order to minimize the discomfort for the contributors that will be forced to rebase their pending gerrit patches. Even if the full reorganization won't happen in a short time I think we should plan the entire structure now and then eventually move only few relevant modules to their final location. To start the discussion I'm attaching here a sketch of the vdsm repository structure that I envision: . |-- client | |-- [...] | `-- vdsClient.py |-- common | |-- [...] | |-- betterPopen | | `-- [...] | `-- vdsm | |-- [...] | `-- config.py |-- contrib | |-- [...] | |-- nfs-check.py | `-- sos |-- daemon | |-- [...] | |-- supervdsm.py | `-- vdsmd `-- tool |-- [...] `-- vdsm-tool The schema file vdsmapi-schema.json (as well as the python module to parse it) are needed by the server and clients. Initially I'd think it should be installed in 'common', but a client does not need things like betterPopen. Any recommendation on where the schema/API definition should live? Well they both should have the file but when installed both should have their own version of the file depending on the version installed of the client or the server. This is so that vdsm-cli doesn't depend on vdsm or vice-versa. You can't have them share the file since if one is installed with a version of the schema where the schema syntax changed the client\server will fail to parse the schema. As for development, I think the least bad solution is to put it in contrib with symlinks that have relative paths. |--daemon | |-- [...] | `-- vdsmapi-schema.json - ../contrib/vdsmapi-schema.json |--client | |-- [...] | `-- vdsmapi-schema.json - ../contrib/vdsmapi-schema.json |--contrib | |-- [...] | `-- vdsmapi-schema.json : . Git knows how to handle symlinks and symlinks are relative to the location of the symlink. We could also just select the daemon or the client folder and put the real file there and a symlink in the other but I feel it's like choosing which one of your children is the main user of a schema file. -- Adam Litke a...@us.ibm.com IBM Linux Technology Center ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
