Re: [vdsm] [VDSM][RFC] hsm service standalone
Saggi, It might be that the wiki page was a bit confusing. Let me articulate it again and help others to understand the intention of this project. 1) Now, HSM files here refers to the files under "vdsm/storage" which are storage service related code. And other VDSM files call into those functions in HSM files in local way(different from RPC). So in the production environment, HSM files are linked in the VDSM process and there is no additional HSM process standing in the ovirt node. 2) This project goal is to move all the HSM files into self-contained workspace and a new stand alone HSM process will be started from these HSM files. Also a new HSM package will be built from this new self-contained workspace. Also all of the HSM APIs are public to the original VDSM service by RPC calls. It is possible that the HSM standalone workspace and the original VDSM workspace may share some functions in misc.py,task.py&etc. We can move those common files to vdsm site packages as the other common files. After this goal is achieved, we have one more HSM process in production environment and one more release package for HSM files. For backward compatibility, vdsm will run in two possible modes. VDSM service will try to discover if HSM RPC APIs are available from the new HSM process. If the discovery is successful, VDSM service will make RPC calls to the HSM process. If the discovery fails, it will fall back the legacy way calling the HSM functions by local way. 3) In order to achieve this goal, we should remove the preconditions gradually and safely. The first step here is the patch http://gerrit.ovirt.org/#/c/9345/ That try to decouple the HSM configuration parameters from the vdsm.conf and store them into a new different conf file. Saggi Mizrahi: HSM is not a package it's an application. Currently it and the rest of VDSM share the same process but they use RPC to communicate. This is done so that one day we can actually have them run as different processes. HSM is not something you import, it's a daemon you communicate with. - Original Message - From: "Dan Kenigsberg" To: "Saggi Mizrahi" Cc: "Sheldon" , a...@linux.vnet.ibm.com, vdsm-devel@lists.fedorahosted.org, "Zheng Sheng ZS Zhou" Sent: Monday, December 3, 2012 12:01:28 PM Subject: Re: [vdsm] [VDSM][RFC] hsm service standalone On Mon, Dec 03, 2012 at 11:35:44AM -0500, Saggi Mizrahi wrote: There are a bunch of precondition to having HSM pulled out. On simple things is that someone needs to go through storage/misc.py and utils.py and move all the code out to logical packages. There also needs to be a bit of a rearrangement of the code files so they can import the reusable code properly. I am also still very much against putting core VDSM in to site-packages. Would you elaborate on your position? Do you mind the wrong implications this may give about API stability? ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel -- --- 舒明 Shu Ming Open Virtualization Engineerning; CSTL, IBM Corp. Tel: 86-10-82451626 Tieline: 9051626 E-mail: shum...@cn.ibm.com or shum...@linux.vnet.ibm.com Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District, Beijing 100193, PRC ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] RFC: New Storage API
On 12/04/2012 03:52 PM, Saggi Mizrahi wrote:
> I've been throwing a lot of bits out about the new storage API and I think
> it's time to talk a bit.
> I will purposefully try and keep implementation details away and concentrate
> about how the API looks and how you use it.
>
> First major change is in terminology, there is no long a storage domain but a
> storage repository.
> This change is done because so many things are already called domain in the
> system and this will make things less confusing for new-commers with a
> libvirt background.
>
> One other changes is that repositories no longer have a UUID.
> The UUID was only used in the pool members manifest and is no longer needed.
>
>
> connectStorageRepository(repoId, repoFormat, connectionParameters={}):
> repoId - is a transient name that will be used to refer to the connected
> domain, it is not persisted and doesn't have to be the same across the
> cluster.
> repoFormat - Similar to what used to be type (eg. localfs-1.0, nfs-3.4,
> clvm-1.2).
> connectionParameters - This is format specific and will used to tell VDSM how
> to connect to the repo.
>
> disconnectStorageRepository(self, repoId):
>
>
> In the new API there are only images, some images are mutable and some are
> not.
> mutable images are also called VirtualDisks
> immutable images are also called Snapshots
>
> There are no explicit templates, you can create as many images as you want
> from any snapshot.
>
> There are 4 major image operations:
>
>
> createVirtualDisk(targetRepoId, size, baseSnapshotId=None,
> userData={}, options={}):
>
> targetRepoId - ID of a connected repo where the disk will be created
> size - The size of the image you wish to create
> baseSnapshotId - the ID of the snapshot you want the base the new virtual
> disk on
> userData - optional data that will be attached to the new VD, could be
> anything that the user desires.
> options - options to modify VDSMs default behavior
>
> returns the id of the new VD
I'm guessing there will be a way to find out how much space is available
for a specified repo before you try to create a virtual disk on it?
>
> createSnapshot(targetRepoId, baseVirtualDiskId,
>userData={}, options={}):
> targetRepoId - The ID of a connected repo where the new sanpshot will be
> created and the original image exists as well.
> size - The size of the image you wish to create
> baseVirtualDisk - the ID of a mutable image (Virtual Disk) you want to
> snapshot
> userData - optional data that will be attached to the new Snapshot, could be
> anything that the user desires.
> options - options to modify VDSMs default behavior
>
> returns the id of the new Snapshot
>
> copyImage(targetRepoId, imageId, baseImageId=None, userData={}, options={})
> targetRepoId - The ID of a connected repo where the new image will be created
> imageId - The image you wish to copy
> baseImageId - if specified, the new image will contain only the diff between
> image and Id.
> If None the new image will contain all the bits of image Id.
> This can be used to copy partial parts of images for export.
> userData - optional data that will be attached to the new image, could be
> anything that the user desires.
> options - options to modify VDSMs default behavior
>
> return the Id of the new image. In case of copying an immutable image the ID
> will be identical to the original image as they contain the same data.
> However the user should not assume that and always use the value returned
> from the method.
Can the target repo id be itself? The case where a user wants to make a
copy of a virtual disk in the same repo. A caller could snapshot the
virtual disk and then create a virtual disk from the snapshot, but if
the target repo could be the same as source repo then they could use
this call as long as the returned ID was different.
Does imageId IO need to be quiesced before calling this or will that be
handled in the implementation (eg. snapshot first)?
> removeImage(repositoryId, imageId, options={}):
> repositoryId - The ID of a connected repo where the image to delete resides
> imageId - The id of the image you wish to delete.
>
What is the behavior if you delete snapshots or virtual disks that have
dependencies on one another? For example, delete the snapshot a virtual
disk is based on or delete the virtual disk a snapshot is based on?
>
>
> getImageStatus(repositoryId, imageId)
> repositoryId - The ID of a connected repo where the image to check resides
> imageId - The id of the image you wish to check.
>
> All operations return once the operations has been committed to disk NOT when
> the operation actually completes.
> This is done so that:
> - operation come to a stable state as quickly as possible.
> - In case where there is an SDM, only small portion of the operation actually
> needs to be performed on the SDM host.
> - No matter how many times the operation fai
Re: [vdsm] moving the collection of statistics to external process
On 12/05/2012 11:11 PM, Adam Litke wrote: On Wed, Dec 05, 2012 at 10:51:23PM +0200, Itamar Heim wrote: On 12/05/2012 10:33 PM, Adam Litke wrote: On Wed, Dec 05, 2012 at 10:21:39PM +0200, Itamar Heim wrote: On 12/05/2012 10:16 PM, Adam Litke wrote: On Wed, Dec 05, 2012 at 09:01:24PM +0200, Itamar Heim wrote: On 12/05/2012 08:57 PM, Adam Litke wrote: On Wed, Dec 05, 2012 at 08:30:10PM +0200, Itamar Heim wrote: On 12/05/2012 04:42 PM, Adam Litke wrote: I wanted to know what do you think about it and if you have better solution to avoid initiate so many threads? And if splitting vdsm is a good idea here? In first look, my opinion is that it can help and would be nice to have vmStatisticService that runs and writes to separate log the vms status. Vdsm recently started requiring the MOM package. MOM also performs some host and guest statistics collection as part of the policy framework. I think it would be a really good idea to consolidate all stats collection into MOM. Then, all stats become usable within the policy and by vdsm for its own internal purposes. Today, MOM has one stats collection thread per VM and one thread for the host stats. It has an API for gathering the most recently collected stats which vdsm can use. isn't this what collectd (and its libvirt plugin) or pcp are already doing? Lot's of things collect statistics, but as of right now, we're using MOM and we're not yet using collectd on the host, right? I think we should have a single stats collection service and clients for it. I think mom and vdsm should get their stats from that service, rather than have either beholden to any new stats something needs to collect. How would this work for collecting guest statistics? Would we require collectd to be installed in all guests running under oVirt? my understanding is collectd is installed on the host, and uses collects libvirt plugin to collect guests statistics? Yes, but some statistics can only be collected by making a call to the oVirt guest agent (eg. guest memory statistics). The logical next step would be to write a collectd plugin for ovirt-guest-agent, but vdsm owns the connections to the guest agents and probably does not want to multiplex those connections for many reasons (security being the main one). and some will come from qemu-ga which libvirt will support? maybe a collectd vdsm plugin for the guest agent stats? Then you still have vdsm plus one other entitity in the business of stats collection. I don't see how that's any better than what we have today. either more stats are moved to qemu-ga and libvirt gets them, or we decide long term we need them from ovirt-ga, and we split the channel so colelctd can get them directly. the benefit of using something like collectd is all the stats vdsm/mom don't care about ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] moving the collection of statistics to external process
On Wed, Dec 05, 2012 at 10:51:23PM +0200, Itamar Heim wrote: > On 12/05/2012 10:33 PM, Adam Litke wrote: > >On Wed, Dec 05, 2012 at 10:21:39PM +0200, Itamar Heim wrote: > >>On 12/05/2012 10:16 PM, Adam Litke wrote: > >>>On Wed, Dec 05, 2012 at 09:01:24PM +0200, Itamar Heim wrote: > On 12/05/2012 08:57 PM, Adam Litke wrote: > >On Wed, Dec 05, 2012 at 08:30:10PM +0200, Itamar Heim wrote: > >>On 12/05/2012 04:42 PM, Adam Litke wrote: > I wanted to know what do you think about it and if you have better > >solution to avoid initiate so many threads? And if splitting vdsm is > >a good idea here? > >In first look, my opinion is that it can help and would be nice to > >have vmStatisticService that runs and writes to separate log the vms > >status. > >>>Vdsm recently started requiring the MOM package. MOM also performs > >>>some host > >>>and guest statistics collection as part of the policy framework. I > >>>think it > >>>would be a really good idea to consolidate all stats collection into > >>>MOM. Then, > >>>all stats become usable within the policy and by vdsm for its own > >>>internal > >>>purposes. Today, MOM has one stats collection thread per VM and one > >>>thread for > >>>the host stats. It has an API for gathering the most recently > >>>collected stats > >>>which vdsm can use. > >>> > >> > >>isn't this what collectd (and its libvirt plugin) or pcp are already > >>doing? > > > >Lot's of things collect statistics, but as of right now, we're using MOM > >and > >we're not yet using collectd on the host, right? > > > > I think we should have a single stats collection service and clients for > it. > I think mom and vdsm should get their stats from that service, > rather than have either beholden to any new stats something needs to > collect. > >>> > >>>How would this work for collecting guest statistics? Would we require > >>>collectd > >>>to be installed in all guests running under oVirt? > >>> > >> > >>my understanding is collectd is installed on the host, and uses > >>collects libvirt plugin to collect guests statistics? > > > >Yes, but some statistics can only be collected by making a call to the oVirt > >guest agent (eg. guest memory statistics). The logical next step would be to > >write a collectd plugin for ovirt-guest-agent, but vdsm owns the connections > >to > >the guest agents and probably does not want to multiplex those connections > >for > >many reasons (security being the main one). > > > > and some will come from qemu-ga which libvirt will support? > maybe a collectd vdsm plugin for the guest agent stats? Then you still have vdsm plus one other entitity in the business of stats collection. I don't see how that's any better than what we have today. -- Adam Litke IBM Linux Technology Center ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] moving the collection of statistics to external process
On 12/05/2012 10:33 PM, Adam Litke wrote: On Wed, Dec 05, 2012 at 10:21:39PM +0200, Itamar Heim wrote: On 12/05/2012 10:16 PM, Adam Litke wrote: On Wed, Dec 05, 2012 at 09:01:24PM +0200, Itamar Heim wrote: On 12/05/2012 08:57 PM, Adam Litke wrote: On Wed, Dec 05, 2012 at 08:30:10PM +0200, Itamar Heim wrote: On 12/05/2012 04:42 PM, Adam Litke wrote: I wanted to know what do you think about it and if you have better solution to avoid initiate so many threads? And if splitting vdsm is a good idea here? In first look, my opinion is that it can help and would be nice to have vmStatisticService that runs and writes to separate log the vms status. Vdsm recently started requiring the MOM package. MOM also performs some host and guest statistics collection as part of the policy framework. I think it would be a really good idea to consolidate all stats collection into MOM. Then, all stats become usable within the policy and by vdsm for its own internal purposes. Today, MOM has one stats collection thread per VM and one thread for the host stats. It has an API for gathering the most recently collected stats which vdsm can use. isn't this what collectd (and its libvirt plugin) or pcp are already doing? Lot's of things collect statistics, but as of right now, we're using MOM and we're not yet using collectd on the host, right? I think we should have a single stats collection service and clients for it. I think mom and vdsm should get their stats from that service, rather than have either beholden to any new stats something needs to collect. How would this work for collecting guest statistics? Would we require collectd to be installed in all guests running under oVirt? my understanding is collectd is installed on the host, and uses collects libvirt plugin to collect guests statistics? Yes, but some statistics can only be collected by making a call to the oVirt guest agent (eg. guest memory statistics). The logical next step would be to write a collectd plugin for ovirt-guest-agent, but vdsm owns the connections to the guest agents and probably does not want to multiplex those connections for many reasons (security being the main one). and some will come from qemu-ga which libvirt will support? maybe a collectd vdsm plugin for the guest agent stats? ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] moving the collection of statistics to external process
On Wed, Dec 05, 2012 at 10:21:39PM +0200, Itamar Heim wrote: > On 12/05/2012 10:16 PM, Adam Litke wrote: > >On Wed, Dec 05, 2012 at 09:01:24PM +0200, Itamar Heim wrote: > >>On 12/05/2012 08:57 PM, Adam Litke wrote: > >>>On Wed, Dec 05, 2012 at 08:30:10PM +0200, Itamar Heim wrote: > On 12/05/2012 04:42 PM, Adam Litke wrote: > >>I wanted to know what do you think about it and if you have better > >>>solution to avoid initiate so many threads? And if splitting vdsm is > >>>a good idea here? > >>>In first look, my opinion is that it can help and would be nice to > >>>have vmStatisticService that runs and writes to separate log the vms > >>>status. > >Vdsm recently started requiring the MOM package. MOM also performs some > >host > >and guest statistics collection as part of the policy framework. I > >think it > >would be a really good idea to consolidate all stats collection into > >MOM. Then, > >all stats become usable within the policy and by vdsm for its own > >internal > >purposes. Today, MOM has one stats collection thread per VM and one > >thread for > >the host stats. It has an API for gathering the most recently collected > >stats > >which vdsm can use. > > > > isn't this what collectd (and its libvirt plugin) or pcp are already > doing? > >>> > >>>Lot's of things collect statistics, but as of right now, we're using MOM > >>>and > >>>we're not yet using collectd on the host, right? > >>> > >> > >>I think we should have a single stats collection service and clients for it. > >>I think mom and vdsm should get their stats from that service, > >>rather than have either beholden to any new stats something needs to > >>collect. > > > >How would this work for collecting guest statistics? Would we require > >collectd > >to be installed in all guests running under oVirt? > > > > my understanding is collectd is installed on the host, and uses > collects libvirt plugin to collect guests statistics? Yes, but some statistics can only be collected by making a call to the oVirt guest agent (eg. guest memory statistics). The logical next step would be to write a collectd plugin for ovirt-guest-agent, but vdsm owns the connections to the guest agents and probably does not want to multiplex those connections for many reasons (security being the main one). -- Adam Litke IBM Linux Technology Center ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] moving the collection of statistics to external process
On 12/05/2012 10:16 PM, Adam Litke wrote: On Wed, Dec 05, 2012 at 09:01:24PM +0200, Itamar Heim wrote: On 12/05/2012 08:57 PM, Adam Litke wrote: On Wed, Dec 05, 2012 at 08:30:10PM +0200, Itamar Heim wrote: On 12/05/2012 04:42 PM, Adam Litke wrote: I wanted to know what do you think about it and if you have better solution to avoid initiate so many threads? And if splitting vdsm is a good idea here? In first look, my opinion is that it can help and would be nice to have vmStatisticService that runs and writes to separate log the vms status. Vdsm recently started requiring the MOM package. MOM also performs some host and guest statistics collection as part of the policy framework. I think it would be a really good idea to consolidate all stats collection into MOM. Then, all stats become usable within the policy and by vdsm for its own internal purposes. Today, MOM has one stats collection thread per VM and one thread for the host stats. It has an API for gathering the most recently collected stats which vdsm can use. isn't this what collectd (and its libvirt plugin) or pcp are already doing? Lot's of things collect statistics, but as of right now, we're using MOM and we're not yet using collectd on the host, right? I think we should have a single stats collection service and clients for it. I think mom and vdsm should get their stats from that service, rather than have either beholden to any new stats something needs to collect. How would this work for collecting guest statistics? Would we require collectd to be installed in all guests running under oVirt? my understanding is collectd is installed on the host, and uses collects libvirt plugin to collect guests statistics? ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] moving the collection of statistics to external process
On Wed, Dec 05, 2012 at 09:01:24PM +0200, Itamar Heim wrote: > On 12/05/2012 08:57 PM, Adam Litke wrote: > >On Wed, Dec 05, 2012 at 08:30:10PM +0200, Itamar Heim wrote: > >>On 12/05/2012 04:42 PM, Adam Litke wrote: > I wanted to know what do you think about it and if you have better > >solution to avoid initiate so many threads? And if splitting vdsm is > >a good idea here? > >In first look, my opinion is that it can help and would be nice to > >have vmStatisticService that runs and writes to separate log the vms > >status. > >>>Vdsm recently started requiring the MOM package. MOM also performs some > >>>host > >>>and guest statistics collection as part of the policy framework. I think > >>>it > >>>would be a really good idea to consolidate all stats collection into MOM. > >>>Then, > >>>all stats become usable within the policy and by vdsm for its own internal > >>>purposes. Today, MOM has one stats collection thread per VM and one > >>>thread for > >>>the host stats. It has an API for gathering the most recently collected > >>>stats > >>>which vdsm can use. > >>> > >> > >>isn't this what collectd (and its libvirt plugin) or pcp are already doing? > > > >Lot's of things collect statistics, but as of right now, we're using MOM and > >we're not yet using collectd on the host, right? > > > > I think we should have a single stats collection service and clients for it. > I think mom and vdsm should get their stats from that service, > rather than have either beholden to any new stats something needs to > collect. How would this work for collecting guest statistics? Would we require collectd to be installed in all guests running under oVirt? -- Adam Litke IBM Linux Technology Center ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] moving the collection of statistics to external process
On 12/05/2012 08:57 PM, Adam Litke wrote: On Wed, Dec 05, 2012 at 08:30:10PM +0200, Itamar Heim wrote: On 12/05/2012 04:42 PM, Adam Litke wrote: I wanted to know what do you think about it and if you have better solution to avoid initiate so many threads? And if splitting vdsm is a good idea here? In first look, my opinion is that it can help and would be nice to have vmStatisticService that runs and writes to separate log the vms status. Vdsm recently started requiring the MOM package. MOM also performs some host and guest statistics collection as part of the policy framework. I think it would be a really good idea to consolidate all stats collection into MOM. Then, all stats become usable within the policy and by vdsm for its own internal purposes. Today, MOM has one stats collection thread per VM and one thread for the host stats. It has an API for gathering the most recently collected stats which vdsm can use. isn't this what collectd (and its libvirt plugin) or pcp are already doing? Lot's of things collect statistics, but as of right now, we're using MOM and we're not yet using collectd on the host, right? I think we should have a single stats collection service and clients for it. I think mom and vdsm should get their stats from that service, rather than have either beholden to any new stats something needs to collect. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] moving the collection of statistics to external process
On Wed, Dec 05, 2012 at 08:30:10PM +0200, Itamar Heim wrote: > On 12/05/2012 04:42 PM, Adam Litke wrote: > >>I wanted to know what do you think about it and if you have better > >>>solution to avoid initiate so many threads? And if splitting vdsm is > >>>a good idea here? > >>>In first look, my opinion is that it can help and would be nice to > >>>have vmStatisticService that runs and writes to separate log the vms > >>>status. > >Vdsm recently started requiring the MOM package. MOM also performs some host > >and guest statistics collection as part of the policy framework. I think it > >would be a really good idea to consolidate all stats collection into MOM. > >Then, > >all stats become usable within the policy and by vdsm for its own internal > >purposes. Today, MOM has one stats collection thread per VM and one thread > >for > >the host stats. It has an API for gathering the most recently collected > >stats > >which vdsm can use. > > > > isn't this what collectd (and its libvirt plugin) or pcp are already doing? Lot's of things collect statistics, but as of right now, we're using MOM and we're not yet using collectd on the host, right? -- Adam Litke IBM Linux Technology Center ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] moving the collection of statistics to external process
On 12/05/2012 04:42 PM, Adam Litke wrote: I wanted to know what do you think about it and if you have better >solution to avoid initiate so many threads? And if splitting vdsm is >a good idea here? >In first look, my opinion is that it can help and would be nice to >have vmStatisticService that runs and writes to separate log the vms >status. Vdsm recently started requiring the MOM package. MOM also performs some host and guest statistics collection as part of the policy framework. I think it would be a really good idea to consolidate all stats collection into MOM. Then, all stats become usable within the policy and by vdsm for its own internal purposes. Today, MOM has one stats collection thread per VM and one thread for the host stats. It has an API for gathering the most recently collected stats which vdsm can use. isn't this what collectd (and its libvirt plugin) or pcp are already doing? ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] [VDSM][RFC] hsm service standalone
On 12/03/2012 07:22 PM, Saggi Mizrahi wrote: HSM is not a package it's an application. Currently it and the rest of VDSM share the same process but they use RPC to communicate. This is done so that one day we can actually have them run as different processes. HSM is not something you import, it's a daemon you communicate with. - Original Message - From: "Dan Kenigsberg" To: "Saggi Mizrahi" Cc: "Sheldon" , a...@linux.vnet.ibm.com, vdsm-devel@lists.fedorahosted.org, "Zheng Sheng ZS Zhou" Sent: Monday, December 3, 2012 12:01:28 PM Subject: Re: [vdsm] [VDSM][RFC] hsm service standalone On Mon, Dec 03, 2012 at 11:35:44AM -0500, Saggi Mizrahi wrote: There are a bunch of precondition to having HSM pulled out. On simple things is that someone needs to go through storage/misc.py and utils.py and move all the code out to logical packages. There also needs to be a bit of a rearrangement of the code files so they can import the reusable code properly. I am also still very much against putting core VDSM in to site-packages. Would you elaborate on your position? Do you mind the wrong implications this may give about API stability? Contrary, It may help to split internal api and external (means rpc between vdsm to engine and rpc between vdsm and hsm), and it might be easier to understand the process flow and control the request from engine. For example, for migration you will receive vdsm request for migration, and that will initiate all the internal processes that we do during migration by sending requests to hsm service. The engine doesn't supposed to care about the internal rpc and those abilities does not supposed to be exposed via vdsm api if we don't allow those specific hsm operation from engine, but via HSM-python service that won't be available for the engine. Might be a good division. But lots of work indeed.. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel -- Yaniv Bronhaim. RedHat, Israel 09-7692289 054-7744187 ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] Host bios information
On Wed, Dec 05, 2012 at 05:25:10PM +0200, ybronhei wrote: > On 12/05/2012 04:32 PM, Adam Litke wrote: > >On Wed, Dec 05, 2012 at 11:05:21AM +0200, ybronhei wrote: > >>Today in the Api we display general information about the host that > >>vdsm export by getCapabilities Api. > >> > >>We decided to add bios information as part of the information that > >>is displayed in UI under host's general sub-tab. > >> > >>To summaries the feature - We'll modify General tab to Software > >>Information and add another tab for Hardware Information which will > >>include all the bios data that we'll decide to gather from the host > >>and display. > >> > >>Following this feature page: > >>http://www.ovirt.org/Features/Design/HostBiosInfo for more details. > >>All the parameters that can be displayed are mentioned in the wiki. > >> > >>I would greatly appreciate your comments and questions. > > > >Seems good to me but I would like to throw out one suggestion. > >getVdsCapabilities is already a huge command that does a lot of time > >consuming > >things. As part of the vdsm API refactoring, we are going to start favoring > >small and concise APIs over "bag" APIs. Perhaps we should just add a new > >verb: > >Host.getVdsBiosInfo() that returns only this information. > > > It leads to modification also in how the engine collects the > parameters with the new api request and I'm not sure if we should > get into this.. Now we have specific known way of how engine > requests for capabilities, when and how it effects the status of the > host that is shown via the UI. > To simplify this feature I prefer to use the current way of > gathering and providing host's information. If we'll decide to split > the host's capabilities api, it needs to get rfcs mail of its own > because it changes engine's internal flows and it makes this feature > to something much more influential. I don't understand. Why can't you just call both APIs, one after the other? -- Adam Litke IBM Linux Technology Center ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] Host bios information
On 12/05/2012 04:32 PM, Adam Litke wrote: On Wed, Dec 05, 2012 at 11:05:21AM +0200, ybronhei wrote: Today in the Api we display general information about the host that vdsm export by getCapabilities Api. We decided to add bios information as part of the information that is displayed in UI under host's general sub-tab. To summaries the feature - We'll modify General tab to Software Information and add another tab for Hardware Information which will include all the bios data that we'll decide to gather from the host and display. Following this feature page: http://www.ovirt.org/Features/Design/HostBiosInfo for more details. All the parameters that can be displayed are mentioned in the wiki. I would greatly appreciate your comments and questions. Seems good to me but I would like to throw out one suggestion. getVdsCapabilities is already a huge command that does a lot of time consuming things. As part of the vdsm API refactoring, we are going to start favoring small and concise APIs over "bag" APIs. Perhaps we should just add a new verb: Host.getVdsBiosInfo() that returns only this information. It leads to modification also in how the engine collects the parameters with the new api request and I'm not sure if we should get into this.. Now we have specific known way of how engine requests for capabilities, when and how it effects the status of the host that is shown via the UI. To simplify this feature I prefer to use the current way of gathering and providing host's information. If we'll decide to split the host's capabilities api, it needs to get rfcs mail of its own because it changes engine's internal flows and it makes this feature to something much more influential. -- Yaniv Bronhaim. RedHat, Israel 09-7692289 054-7744187 ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] VDSM tasks, the future
I'm sorry but your email client messed up the formatting and I can't figure out
what are you comments.
Could you please use text only emails.
- Original Message -
> From: "ybronhei"
> To: "Saggi Mizrahi"
> Cc: "Adam Litke" , "engine-devel" ,
> "VDSM Project Development"
>
> Sent: Wednesday, December 5, 2012 8:37:23 AM
> Subject: Re: [vdsm] VDSM tasks, the future
>
>
> On 12/05/2012 12:20 AM, Saggi Mizrahi wrote:
>
>
> As the only subsystem to use asynchronous tasks until now is the
> storage subsystem I suggest going over how
> I suggest tackling task creation, task stop, task remove and task
> recovery.
> Other subsystem can create similar mechanisms depending on their
> needs.
>
> There is no way of avoiding it, different types of tasks need
> different ways of tracking\recovering from them.
> network should always auto-recover because it can't get a "please
> fix" command if the network is down.
> Storage on the other hand should never start operations on it's own
> because it might take up valuable resources from the host.
> Tasks that need to be tracked on a single host, 2 hosts, or the
> entire cluster need to have their own APIs.
> VM configuration never persist across reboots, networking sometimes
> persists and storage always persists.
> This means that recovery procedures (from the managers point of view)
> need to be vastly different.
> Add policy, resource allocation, and error flows you see that VDSM
> doesn't have nearly as much information to deal with the tasks.
>
> - Original Message -
>
> From: "Adam Litke" To: "Saggi Mizrahi"
> Cc: "VDSM Project Development"
> , "engine-devel"
> , "Ayal
> Baron" , "Barak Azulay" ,
> "Shireesh Anjal" Sent: Tuesday, December 4, 2012
> 3:50:28 PM
> Subject: Re: VDSM tasks, the future
>
> On Tue, Dec 04, 2012 at 10:35:01AM -0500, Saggi Mizrahi wrote:
>
> Because I started hinting about how VDSM tasks are going to look
> going forward
> I thought it's better I'll just write everything in an email so we
> can talk
> about it in context. This is not set in stone and I'm still
> debating things
> myself but it's very close to being done. Don't debate them yourself,
> debate them here! Even better, propose
> your idea in
> schema form to show how a command might work exactly. I don't like
> throwing ideas in the air It can be much easier to understand the
> flow of a task in vdsm and outside vdsm by a small schema, mainly
> for the each task's states.
> To define the flow of a task you can separate between type of tasks
> (network, storage, vms, or else), we should have task's states that
> clarify if the task can be recovered or not, can be canceled or not
> and inc..
>
> Canceling\Aborting\Reverting states should be more clarified and not
> every state can lead to all types of states.
> I tries to figure how task flow works today in vdsm, and this is what
> I've got - http://wiki.ovirt.org/Vdsm_tasks
>
>
>
>
>
>
> - Everything is asynchronous. The nature of message based
> communication is
> that you can't have synchronous operations. This is not really
> debatable
> because it's just how TCP\AMQP\ works. Can you show how a
> traditionally synchronous command might work?
> Let's take
> Host.getVmList as an example. The same as it works today, it's all a
> matter of how you wrap the transport layer.
> You will send a json-rpc request and wait for a response with the
> same id.
>
> As for the bindings, there are a lot of way we can tackle that.
> Always wait for the response and simulate synchronous behavior.
> Make every method return an object to track the task.
> task = host.getVmList()
> if not task.wait(1):
> task.cancel()
> else:
> res = task.result() It looks like traditional timeout.. why not
> to split blocking actions and non-blocking actions, non-blocking
> action will supply callback function to return to if the task
> fails or success. for example:
>
> createAsyncTask(host.getVmList, params, timeout=30,
> callbackGetVmList)
>
> Instead of using the dispatcher? Do you want to keep the dispatcher
> concept?
>
>
>
> Have it both ways (it's auto generated anyway) and have
> list = host.getVmList()
> task = host.getVmList_async()
>
> Have a high level and low level interfaces.
> host = host()
> host.connect("tcp://host:3233")
> req = host.sendRequest("123213", "getVmList", [])
> if not req.wait(1):
>
>
> shost = SynchHost(host)
> shost.getVmList() # Actually wraps a request object
> ahost = AsyncHost(host)
> task = getVmList() # Actually wraps a request object
>
>
>
> - Task IDs will be decided by the caller. This is how json-rpc
> works and also
> makes sense because no the engine can track the task without
> needing to have a
> stage where we give it the task ID back. IDs are reusable as long
> as no one
> else is using them at the time so they can be used for
> synchronizing
> operations between clients (making sure a command is only executed
> once on a
> specif
Re: [vdsm] moving the collection of statistics to external process
On Wed, Dec 05, 2012 at 04:23:16PM +0200, ybronhei wrote: > As part of an issue that if you push start for 200vms in the same > time it takes hours because undefined issue, we thought about moving > the collection of statistics outside vdsm. Thanks for bringing up this issue. I think this could be a good idea on its own merits (better modularity, etc). > It can help because the stat collection is an internal threads of > vdsm that can spend not a bit of a time, I'm not sure if it would > help with the issue of starting many vms simultaneously, but it > might improve vdsm response. In general, threads should be really cheap to create so I expect there is another cause for the performance bottleneck. That being said, I think we should still look at this feature. > Currently we start thread for each vm and then collecting stats on > them in constant intervals, and it must effect vdsm if we have 200 > thread like this that can take some time. for example if we have > connection errors to storage and we can't receive its response, all > the 200 threads can get stuck and lock other threads (gil issue). > > I wanted to know what do you think about it and if you have better > solution to avoid initiate so many threads? And if splitting vdsm is > a good idea here? > In first look, my opinion is that it can help and would be nice to > have vmStatisticService that runs and writes to separate log the vms > status. Vdsm recently started requiring the MOM package. MOM also performs some host and guest statistics collection as part of the policy framework. I think it would be a really good idea to consolidate all stats collection into MOM. Then, all stats become usable within the policy and by vdsm for its own internal purposes. Today, MOM has one stats collection thread per VM and one thread for the host stats. It has an API for gathering the most recently collected stats which vdsm can use. > The problem with this solution is that if those interval functions > needs to communicate with internal parts of vdsm to set values or > start internal processes when something has changed, it depends on > the stat function.. and I'm not sure that stat function should > control internal flows. > Today to recognize connectivity error we count on this method, but > we can add polling mechanics for those issues (which can raise same > problems we are trying to deal with..) I agree. Any cases where the stats collection threads are triggering internal vdsm logic need to be cleaned up. -- Adam Litke IBM Linux Technology Center ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] Host bios information
On Wed, Dec 05, 2012 at 11:05:21AM +0200, ybronhei wrote: > Today in the Api we display general information about the host that > vdsm export by getCapabilities Api. > > We decided to add bios information as part of the information that > is displayed in UI under host's general sub-tab. > > To summaries the feature - We'll modify General tab to Software > Information and add another tab for Hardware Information which will > include all the bios data that we'll decide to gather from the host > and display. > > Following this feature page: > http://www.ovirt.org/Features/Design/HostBiosInfo for more details. > All the parameters that can be displayed are mentioned in the wiki. > > I would greatly appreciate your comments and questions. Seems good to me but I would like to throw out one suggestion. getVdsCapabilities is already a huge command that does a lot of time consuming things. As part of the vdsm API refactoring, we are going to start favoring small and concise APIs over "bag" APIs. Perhaps we should just add a new verb: Host.getVdsBiosInfo() that returns only this information. -- Adam Litke IBM Linux Technology Center ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] link state semantics
On Wed, Dec 05, 2012 at 04:25:48AM -0500, Antoni Segura Puimedon wrote:
>
>
> - Original Message -
> > From: "Igor Lvovsky"
> > To: "Antoni Segura Puimedon"
> > Cc: "Alona Kaplan" , vdsm-devel@lists.fedorahosted.org
> > Sent: Wednesday, December 5, 2012 10:17:50 AM
> > Subject: Re: [vdsm] link state semantics
> >
> >
> >
> > - Original Message -
> > > From: "Antoni Segura Puimedon"
> > > To: vdsm-devel@lists.fedorahosted.org
> > > Cc: "Alona Kaplan"
> > > Sent: Tuesday, December 4, 2012 7:32:34 PM
> > > Subject: [vdsm] link state semantics
> > >
> > > Hi list!
> > >
> > > We are working on the new 3.2 feature for adding support for
> > > updating
> > > VM
> > > devices, more specifically at the moment network devices.
> > >
> > > There is one point of the design which is not yet consensual and
> > > we'd
> > > need to agree on a proper and clean design that would satisfy us
> > > all:
> > >
> > > My current proposal, as reflected by patch:
> > >http://gerrit.ovirt.org/#/c/9560/5/vdsm_api/vdsmapi-schema.json
> > > and its parent is to have a linkActive boolean that is true for
> > > link
> > > status 'up' and false for link status 'down'.
> > >
> > > We want to support a none (dummy) network that is used to
> > > dissociate
> > > vnics
> > > from any real network. The semantics, as you can see in the patch
> > > are
> > > that
> > > unless you specify a network, updateDevice will place the interface
> > > on that
> > > network. However, Adam Litke argues that not specifying a network
> > > should
> > > keep the vnic on the network it currently is, as network is an
> > > optional
> > > parameter and 'linkActive' is also optional and has this "preserve
> > > current
> > > state" semantics.
> > >
> > > I can certainly see the merit of what Adam proposes, and the
> > > implementation
> > > would be that linkActive becomes an enum like so:
> > >
> > > {'enum': 'linkState'/* or linkActive */ , 'data': ['up', 'down',
> > > 'disconnected']}
> > >
> >
> > If you are going for this use 'linkState'
> >
> > > With this change, network would only be changed if one different
> > > than
> > > the current
> > > one is specified and the vnic would be taken to the dummy bridge
> > > when
> > > the linkState
> > > would be set to 'disconnected'.
> >
> > In general +1 for new one, with a little doubt.
> > It looks a bit inconsistent that we leave the network as is if it
> > omitted from input,
> > but if linkState is 'disconnected' we will move it to dummy bridge.
> > But I can live with it.
>
> Yes, the 'disconnected' overrules the network and that, as you point
> out, can be a source of confusion. I propose to add a warning to the
> return dictionary that tells the user that setting disconnected overrules
> any network setting.
>
> >
> > >
> > > There is also an objection, raised by Adam about the semantics of
> > > portMirroring.
> > > The current behavior from my patch is:
> > >
> > > portMirroring is None or is not set -> No action taken.
> > > portMirroring = [] -> No action taken.
> > > portMirroring = [a,b,z] -> Set port mirroring for nets a,b and z to
> > > the specified vnic.
> > >
> > > His proposal is:
> > > portMirroring is None or is not set -> No action taken.
> > > portMirroring = [] -> Unset port mirroring to the vnic that is
> > > currently set.
> > > portMirroring = [a,b,z] -> Set port mirroring for nets a,b and z to
> > > the specified vnic.
> > >
> >
> > +1 for Adam's approach, just don't forget to unset portMirroring from
> > all nets setted before
> > if they not in new portMirroring = [a,b,z]
>
> So you're saying:
>
> portMirroring is None or is not set -> No action taken.
> portMirroring = [] -> Unset port mirroring to the vnic that is
> currently set.
> portMirroring = [a,b,z] -> Set port mirroring for nets a,b and z to
>the specified vnic AND unset any other mirroring.
>
> I'm fine with it, I think it is even more complete and correct.
Yes, +1.
> >
> > > I would really welcome comments on this to have finally an
> > > agreement
> > > to the api for this
> > > feature.
> > >
> > > Best,
> > >
> > > Toni
> > > ___
> > > vdsm-devel mailing list
> > > vdsm-devel@lists.fedorahosted.org
> > > https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
> > >
> >
> ___
> vdsm-devel mailing list
> vdsm-devel@lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
--
Adam Litke
IBM Linux Technology Center
___
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
[vdsm] moving the collection of statistics to external process
As part of an issue that if you push start for 200vms in the same time it takes hours because undefined issue, we thought about moving the collection of statistics outside vdsm. It can help because the stat collection is an internal threads of vdsm that can spend not a bit of a time, I'm not sure if it would help with the issue of starting many vms simultaneously, but it might improve vdsm response. Currently we start thread for each vm and then collecting stats on them in constant intervals, and it must effect vdsm if we have 200 thread like this that can take some time. for example if we have connection errors to storage and we can't receive its response, all the 200 threads can get stuck and lock other threads (gil issue). I wanted to know what do you think about it and if you have better solution to avoid initiate so many threads? And if splitting vdsm is a good idea here? In first look, my opinion is that it can help and would be nice to have vmStatisticService that runs and writes to separate log the vms status. The problem with this solution is that if those interval functions needs to communicate with internal parts of vdsm to set values or start internal processes when something has changed, it depends on the stat function.. and I'm not sure that stat function should control internal flows. Today to recognize connectivity error we count on this method, but we can add polling mechanics for those issues (which can raise same problems we are trying to deal with..) I would like to here your ideas and comments.. thanks -- Yaniv Bronhaim. RedHat, Israel 09-7692289 054-7744187 ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] Fedora, udev and nic renaming
On Tue, Dec 04, 2012 at 05:25:48AM -0500, Alon Bar-Lev wrote: > > Thanks for this verbose description. > > I don't think using libguestfs is the solution for this. Yeah, it seems like a hack that would be quite hard to maintain for all supported guest operating systems. > > Fixing qemu to accept BIOS interface name at -net parameter is preferable. I > don't think we should expose the interface a PCI device as it will have some > drawbacks, but attempt to use the onboard convention. I don't see a real use case for setting the bios name explicitly. After all, libvirt/vdsm/Engine is going to to allocate them according to their relative order. I'd be content with qemu providing a sane, reproducible, biosdevname for each nic. Michael, would it be difficult to have? > > Alon > > - Original Message - > > From: "Antoni Segura Puimedon" > > To: vdsm-devel@lists.fedorahosted.org > > Sent: Tuesday, December 4, 2012 11:08:31 AM > > Subject: [vdsm] Fedora, udev and nic renaming > > > > Hi, > > > > We are currently working on stabilizing the networking part of vdsm > > in Fedora > > 18 and, to achieve that purpose, we decided to test in in both > > physical hosts > > and, for extra convenience and better support, also in VMs. > > > > Due to the move of Fedora 17 and 18 to systemd and newer udev > > versions, we > > encountered some issues that should be noted and worked on to provide > > our users > > with a hassle-free experience. > > > > First of all, let me state what happens (in renaming) in RHEL-6.x > > when a new > > ethernet device is handled by udev: > > a) One or more udev rules match the characteristics of the interface: > > The last > > matching rule is applied. > > b) No rule is matching: /lib/udev/write-net-rules writes a permanent > > rule using the MAC address of the interface in a udev rules file, so > > the > > interface name will be permanent and in the ethX namespace. > > > > In Fedora 17 (but even more so in F18), with the move to a newer > > version of > > udev and, specially, with the change from sysV init to systemd, the > > mechanism > > changed. Since systemd is making the boot happen in a parallelized > > way, some > > changes had to be enforced in udev to keep the renaming working: > > > > - To avoid naming collisions, it was decided to use Dell's > > biosdevname software > > to retrieve a device name for the network interfaces. Typically emX > > for > > onboard nics and pXpY for pci connected nics. > > - For devices which biosdevname could not provide any information, it > > was > > agreed to assign them a name in the ethX space in a first-come, > > first-served > > fashion. > > - Optionally, one could define the interace MAC addr in an ifcfg file > > and /lib/udev/rename-device would look into the ifcfg file and > > assign > > the device name there set (I have not yet succeeded in that part, I > > have to > > investigate more, I guess). > > > > As you can see, biosdevname, never reports names in the eth space to > > avoid > > collision with a potential parallel discovery of an interface not > > recognizable > > by it, to which the kernel could have assigned already a bios > > reported name. > > > > For physical machines this approach works fine. However, for Virtual > > machines > > with more than one nic, the automatic process described above > > presents some > > issues. Biosdevname, due to the different ways the virtualization > > hypervisors > > report the vnics, dropped support for VMs in 0.3.7 (F18 uses 0.4.1-2) > > and > > decided that on VMs, it would just return "4" to indicate to udev to > > use > > kernel first-come, first-served for those interfaces (ethX > > namespace). Is this the case for all nic models (e100, rtl) or only to virtio? > > > > The issue with using first-come first-served, is that due to the > > highly > > parallelized boot there is now, it is very common to encounter that > > the names > > of your devices (as identified by MAC address) suffer a permutation > > upon each > > reboot. Here you can see an example: > > > > NOTE: The libvirt dump of the VM reports the same PCI address for > > each > > interface across reboots. > > > > Boot 0 (Nov 13th 14:59) > > eth0: flags=4163 mtu 1500 > > ether 52:54:00:54:85:57 txqueuelen 1000 (Ethernet) > > eth1: flags=4163 mtu 1500 > > ether 52:54:00:77:45:6b txqueuelen 1000 (Ethernet) > > eth2: flags=4163 mtu 1500 > > ether 52:54:00:ca:41:c7 txqueuelen 1000 (Ethernet) > > eth3: flags=4163 mtu 1500 > > ether 52:54:00:f5:3d:c8 txqueuelen 1000 (Ethernet) > > eth4: flags=4163 mtu 1500 > > ether 52:54:00:5e:10:76 txqueuelen 1000 (Ethernet) > > eth5: flags=4163 mtu 1500 > > ether 52:54:00:95:00:93 txqueuelen 1000 (Ethernet) > > > > Boot 1 (Nov 13th 15:01) > > eth0: flags=4163 mtu 1500 > > ether 52:54:00:ca:41:c7 txqueuelen 1000 (Ethernet) > > eth1: flags=4163 mtu 1500 >
Re: [vdsm] VDSM tasks, the future
On 12/05/2012 12:20 AM, Saggi Mizrahi wrote:
As the only subsystem to use asynchronous tasks until now is the storage
subsystem I suggest going over how
I suggest tackling task creation, task stop, task remove and task recovery.
Other subsystem can create similar mechanisms depending on their needs.
There is no way of avoiding it, different types of tasks need different ways of
tracking\recovering from them.
network should always auto-recover because it can't get a "please fix" command
if the network is down.
Storage on the other hand should never start operations on it's own because it
might take up valuable resources from the host.
Tasks that need to be tracked on a single host, 2 hosts, or the entire cluster
need to have their own APIs.
VM configuration never persist across reboots, networking sometimes persists
and storage always persists.
This means that recovery procedures (from the managers point of view) need to
be vastly different.
Add policy, resource allocation, and error flows you see that VDSM doesn't have
nearly as much information to deal with the tasks.
- Original Message -
From: "Adam Litke"
To: "Saggi Mizrahi"
Cc: "VDSM Project Development" , "engine-devel"
, "Ayal
Baron" , "Barak Azulay" , "Shireesh Anjal"
Sent: Tuesday, December 4, 2012 3:50:28 PM
Subject: Re: VDSM tasks, the future
On Tue, Dec 04, 2012 at 10:35:01AM -0500, Saggi Mizrahi wrote:
Because I started hinting about how VDSM tasks are going to look
going forward
I thought it's better I'll just write everything in an email so we
can talk
about it in context. This is not set in stone and I'm still
debating things
myself but it's very close to being done.
Don't debate them yourself, debate them here! Even better, propose
your idea in
schema form to show how a command might work exactly.
I don't like throwing ideas in the air
It can be much easier to understand the flow of a task in vdsm and
outside vdsm by a small schema, mainly for the each task's states.
To define the flow of a task you can separate between type of tasks
(network, storage, vms, or else), we should have task's states that
clarify if the task can be recovered or not, can be canceled or not and
inc..
Canceling\Aborting\Reverting states should be more clarified and not
every state can lead to all types of states.
I tries to figure how task flow works today in vdsm, and this is what
I've got - http://wiki.ovirt.org/Vdsm_tasks
- Everything is asynchronous. The nature of message based
communication is
that you can't have synchronous operations. This is not really
debatable
because it's just how TCP\AMQP\ works.
Can you show how a traditionally synchronous command might work?
Let's take
Host.getVmList as an example.
The same as it works today, it's all a matter of how you wrap the transport
layer.
You will send a json-rpc request and wait for a response with the same id.
As for the bindings, there are a lot of way we can tackle that.
Always wait for the response and simulate synchronous behavior.
Make every method return an object to track the task.
task = host.getVmList()
if not task.wait(1):
task.cancel()
else:
res = task.result()
It looks like traditional timeout.. why not to split blocking actions
and non-blocking actions, non-blocking action will supply callback
function to return to if the task fails or success. for example:
createAsyncTask(host.getVmList, params, timeout=30, callbackGetVmList)
Instead of using the dispatcher? Do you want to keep the dispatcher concept?
Have it both ways (it's auto generated anyway) and have
list = host.getVmList()
task = host.getVmList_async()
Have a high level and low level interfaces.
host = host()
host.connect("tcp://host:3233")
req = host.sendRequest("123213", "getVmList", [])
if not req.wait(1):
shost = SynchHost(host)
shost.getVmList() # Actually wraps a request object
ahost = AsyncHost(host)
task = getVmList() # Actually wraps a request object
- Task IDs will be decided by the caller. This is how json-rpc
works and also
makes sense because no the engine can track the task without
needing to have a
stage where we give it the task ID back. IDs are reusable as long
as no one
else is using them at the time so they can be used for
synchronizing
operations between clients (making sure a command is only executed
once on a
specific host without locking).
- Tasks are transient If VDSM restarts it forgets all the task
information.
There are 2 ways to have persistent tasks: 1. The task creates an
object that
you can continue work on in VDSM. The new storage does that by the
fact that
copyImage() returns one the target volume has been created but
before the data
has been fully copied. From that moment on the stat of the copy
can be
queried from any host using getImageStatus() and the specific copy
operation
can be queried with getTaskStatus() on the host performing it.
After VDSM
crashes, depending on policy, either VDSM will create a new task to
con
Re: [vdsm] link state semantics
- Original Message -
> From: "Dan Kenigsberg"
> To: "Livnat Peer"
> Cc: "Adam Litke" , "Alona Kaplan" ,
> vdsm-devel@lists.fedorahosted.org, "Antoni
> Segura Puimedon"
> Sent: Wednesday, December 5, 2012 2:06:18 PM
> Subject: Re: [vdsm] link state semantics
>
> On Wed, Dec 05, 2012 at 02:40:44PM +0200, Livnat Peer wrote:
> > On 05/12/12 14:21, Dan Kenigsberg wrote:
> > > On Tue, Dec 04, 2012 at 03:10:00PM -0600, Adam Litke wrote:
> > >> On Tue, Dec 04, 2012 at 12:32:34PM -0500, Antoni Segura Puimedon
> > >> wrote:
> > >>> Hi list!
> > >>>
> > >>> We are working on the new 3.2 feature for adding support for
> > >>> updating VM
> > >>> devices, more specifically at the moment network devices.
> > >>>
> > >>> There is one point of the design which is not yet consensual
> > >>> and we'd
> > >>> need to agree on a proper and clean design that would satisfy
> > >>> us all:
> > >>>
> > >>> My current proposal, as reflected by patch:
> > >>>http://gerrit.ovirt.org/#/c/9560/5/vdsm_api/vdsmapi-schema.json
> > >>> and its parent is to have a linkActive boolean that is true for
> > >>> link
> > >>> status 'up' and false for link status 'down'.
> > >>>
> > >>> We want to support a none (dummy) network that is used to
> > >>> dissociate vnics
> > >>> from any real network. The semantics, as you can see in the
> > >>> patch are that
> > >>> unless you specify a network, updateDevice will place the
> > >>> interface on that
> > >>> network. However, Adam Litke argues that not specifying a
> > >>> network should
> > >>> keep the vnic on the network it currently is, as network is an
> > >>> optional
> > >>> parameter and 'linkActive' is also optional and has this
> > >>> "preserve current
> > >>> state" semantics.
> > >>>
> > >>> I can certainly see the merit of what Adam proposes, and the
> > >>> implementation
> > >>> would be that linkActive becomes an enum like so:
> > >>>
> > >>> {'enum': 'linkState'/* or linkActive */ , 'data': ['up',
> > >>> 'down', 'disconnected']}
> > >>>
> > >>> With this change, network would only be changed if one
> > >>> different than the current
> > >>> one is specified and the vnic would be taken to the dummy
> > >>> bridge when the linkState
> > >>> would be set to 'disconnected'.
> > >>>
> > >>> There is also an objection, raised by Adam about the semantics
> > >>> of portMirroring.
> > >>> The current behavior from my patch is:
> > >>>
> > >>> portMirroring is None or is not set -> No action taken.
> > >>> portMirroring = [] -> No action taken.
> > >>> portMirroring = [a,b,z] -> Set port mirroring for nets a,b and
> > >>> z to the specified vnic.
> > >>>
> > >>> His proposal is:
> > >>> portMirroring is None or is not set -> No action taken.
> > >>> portMirroring = [] -> Unset port mirroring to the vnic that is
> > >>> currently set.
> > >>> portMirroring = [a,b,z] -> Set port mirroring for nets a,b and
> > >>> z to the specified vnic.
> > >>>
> > >>> I would really welcome comments on this to have finally an
> > >>> agreement to the api for this
> > >>> feature.
> > >
> > > ack for portMirroring semantics. [] must mean "no networks are
> > > mirrored
> > > to this nic".
> > >
> >
> > +1, It makes sense.
> >
> > > I am less sure about allowing a "No action taken" semantics, as
> > > it
> > > add the current state to the API and complicates it. I'd also
> > > like to
> > > keep the updateDevice API as similar as possible to vmCreate one.
> > >
> > > However, we already have defaults in vmCreate (for pci address
> > > allocation, portmirroring off) so I suppose I can join Adam here.
> > >
> > > But this does not mean we should allow a default everywhere. I
> > > find it
> > > unintuitive to have a linkState=disconnected, as setting this
> > > attribute
> > > should clear the network attribute - they become non-orthogonal.
> > > So in
> > > my opinion, a missing network should mean "nic is connected to no
> > > network" rather than "keep current connection".
> >
> > I find the 'disconnect' state a bit problematic, a 'test' I do to
> > see if
> > things make sense is a comparison to the 'physical' world.
> > In the physical world a link can have up or down, any other state
> > that
> > we add is less intuitive and IMO should be avoided.
> > The 'problematic' status we are trying to express in the API is a
> > network card that has no wire connected to it, how about using an
> > empty
> > network name to express that no network is connected to this card?
> >
> > Then we can keep the semantics of not sending a network-name means
> > no
> > change in the network.
>
> Usually I dislike attaching special semantics to the empty string,
> but
> it sounds like a reasonable way out this time.
>
> +1 to network='' meaning "connect this nic to nothing".
I agree as well. AFAICT, I think you bought us a way out.
>
> >
> > And I also agree with danken that we should keep the API
> > consistent,
> > createVM hotplug and updateDevice should behave similarly.
Indeed! I'm going
Re: [vdsm] link state semantics
On Wed, Dec 05, 2012 at 02:40:44PM +0200, Livnat Peer wrote:
> On 05/12/12 14:21, Dan Kenigsberg wrote:
> > On Tue, Dec 04, 2012 at 03:10:00PM -0600, Adam Litke wrote:
> >> On Tue, Dec 04, 2012 at 12:32:34PM -0500, Antoni Segura Puimedon wrote:
> >>> Hi list!
> >>>
> >>> We are working on the new 3.2 feature for adding support for updating VM
> >>> devices, more specifically at the moment network devices.
> >>>
> >>> There is one point of the design which is not yet consensual and we'd
> >>> need to agree on a proper and clean design that would satisfy us all:
> >>>
> >>> My current proposal, as reflected by patch:
> >>>http://gerrit.ovirt.org/#/c/9560/5/vdsm_api/vdsmapi-schema.json
> >>> and its parent is to have a linkActive boolean that is true for link
> >>> status 'up' and false for link status 'down'.
> >>>
> >>> We want to support a none (dummy) network that is used to dissociate vnics
> >>> from any real network. The semantics, as you can see in the patch are that
> >>> unless you specify a network, updateDevice will place the interface on
> >>> that
> >>> network. However, Adam Litke argues that not specifying a network should
> >>> keep the vnic on the network it currently is, as network is an optional
> >>> parameter and 'linkActive' is also optional and has this "preserve current
> >>> state" semantics.
> >>>
> >>> I can certainly see the merit of what Adam proposes, and the
> >>> implementation
> >>> would be that linkActive becomes an enum like so:
> >>>
> >>> {'enum': 'linkState'/* or linkActive */ , 'data': ['up', 'down',
> >>> 'disconnected']}
> >>>
> >>> With this change, network would only be changed if one different than the
> >>> current
> >>> one is specified and the vnic would be taken to the dummy bridge when the
> >>> linkState
> >>> would be set to 'disconnected'.
> >>>
> >>> There is also an objection, raised by Adam about the semantics of
> >>> portMirroring.
> >>> The current behavior from my patch is:
> >>>
> >>> portMirroring is None or is not set -> No action taken.
> >>> portMirroring = [] -> No action taken.
> >>> portMirroring = [a,b,z] -> Set port mirroring for nets a,b and z to the
> >>> specified vnic.
> >>>
> >>> His proposal is:
> >>> portMirroring is None or is not set -> No action taken.
> >>> portMirroring = [] -> Unset port mirroring to the vnic that is currently
> >>> set.
> >>> portMirroring = [a,b,z] -> Set port mirroring for nets a,b and z to the
> >>> specified vnic.
> >>>
> >>> I would really welcome comments on this to have finally an agreement to
> >>> the api for this
> >>> feature.
> >
> > ack for portMirroring semantics. [] must mean "no networks are mirrored
> > to this nic".
> >
>
> +1, It makes sense.
>
> > I am less sure about allowing a "No action taken" semantics, as it
> > add the current state to the API and complicates it. I'd also like to
> > keep the updateDevice API as similar as possible to vmCreate one.
> >
> > However, we already have defaults in vmCreate (for pci address
> > allocation, portmirroring off) so I suppose I can join Adam here.
> >
> > But this does not mean we should allow a default everywhere. I find it
> > unintuitive to have a linkState=disconnected, as setting this attribute
> > should clear the network attribute - they become non-orthogonal. So in
> > my opinion, a missing network should mean "nic is connected to no
> > network" rather than "keep current connection".
>
> I find the 'disconnect' state a bit problematic, a 'test' I do to see if
> things make sense is a comparison to the 'physical' world.
> In the physical world a link can have up or down, any other state that
> we add is less intuitive and IMO should be avoided.
> The 'problematic' status we are trying to express in the API is a
> network card that has no wire connected to it, how about using an empty
> network name to express that no network is connected to this card?
>
> Then we can keep the semantics of not sending a network-name means no
> change in the network.
Usually I dislike attaching special semantics to the empty string, but
it sounds like a reasonable way out this time.
+1 to network='' meaning "connect this nic to nothing".
>
> And I also agree with danken that we should keep the API consistent,
> createVM hotplug and updateDevice should behave similarly.
>
> Livnat
>
> >
> > Dan.
> > ___
> > vdsm-devel mailing list
> > vdsm-devel@lists.fedorahosted.org
> > https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
> >
>
___
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] link state semantics
On 05/12/12 14:21, Dan Kenigsberg wrote:
> On Tue, Dec 04, 2012 at 03:10:00PM -0600, Adam Litke wrote:
>> On Tue, Dec 04, 2012 at 12:32:34PM -0500, Antoni Segura Puimedon wrote:
>>> Hi list!
>>>
>>> We are working on the new 3.2 feature for adding support for updating VM
>>> devices, more specifically at the moment network devices.
>>>
>>> There is one point of the design which is not yet consensual and we'd
>>> need to agree on a proper and clean design that would satisfy us all:
>>>
>>> My current proposal, as reflected by patch:
>>>http://gerrit.ovirt.org/#/c/9560/5/vdsm_api/vdsmapi-schema.json
>>> and its parent is to have a linkActive boolean that is true for link
>>> status 'up' and false for link status 'down'.
>>>
>>> We want to support a none (dummy) network that is used to dissociate vnics
>>> from any real network. The semantics, as you can see in the patch are that
>>> unless you specify a network, updateDevice will place the interface on that
>>> network. However, Adam Litke argues that not specifying a network should
>>> keep the vnic on the network it currently is, as network is an optional
>>> parameter and 'linkActive' is also optional and has this "preserve current
>>> state" semantics.
>>>
>>> I can certainly see the merit of what Adam proposes, and the implementation
>>> would be that linkActive becomes an enum like so:
>>>
>>> {'enum': 'linkState'/* or linkActive */ , 'data': ['up', 'down',
>>> 'disconnected']}
>>>
>>> With this change, network would only be changed if one different than the
>>> current
>>> one is specified and the vnic would be taken to the dummy bridge when the
>>> linkState
>>> would be set to 'disconnected'.
>>>
>>> There is also an objection, raised by Adam about the semantics of
>>> portMirroring.
>>> The current behavior from my patch is:
>>>
>>> portMirroring is None or is not set -> No action taken.
>>> portMirroring = [] -> No action taken.
>>> portMirroring = [a,b,z] -> Set port mirroring for nets a,b and z to the
>>> specified vnic.
>>>
>>> His proposal is:
>>> portMirroring is None or is not set -> No action taken.
>>> portMirroring = [] -> Unset port mirroring to the vnic that is currently
>>> set.
>>> portMirroring = [a,b,z] -> Set port mirroring for nets a,b and z to the
>>> specified vnic.
>>>
>>> I would really welcome comments on this to have finally an agreement to the
>>> api for this
>>> feature.
>
> ack for portMirroring semantics. [] must mean "no networks are mirrored
> to this nic".
>
+1, It makes sense.
> I am less sure about allowing a "No action taken" semantics, as it
> add the current state to the API and complicates it. I'd also like to
> keep the updateDevice API as similar as possible to vmCreate one.
>
> However, we already have defaults in vmCreate (for pci address
> allocation, portmirroring off) so I suppose I can join Adam here.
>
> But this does not mean we should allow a default everywhere. I find it
> unintuitive to have a linkState=disconnected, as setting this attribute
> should clear the network attribute - they become non-orthogonal. So in
> my opinion, a missing network should mean "nic is connected to no
> network" rather than "keep current connection".
I find the 'disconnect' state a bit problematic, a 'test' I do to see if
things make sense is a comparison to the 'physical' world.
In the physical world a link can have up or down, any other state that
we add is less intuitive and IMO should be avoided.
The 'problematic' status we are trying to express in the API is a
network card that has no wire connected to it, how about using an empty
network name to express that no network is connected to this card?
Then we can keep the semantics of not sending a network-name means no
change in the network.
And I also agree with danken that we should keep the API consistent,
createVM hotplug and updateDevice should behave similarly.
Livnat
>
> Dan.
> ___
> vdsm-devel mailing list
> vdsm-devel@lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
>
___
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] link state semantics
On Wed, Dec 05, 2012 at 02:21:16PM +0200, Dan Kenigsberg wrote:
> On Tue, Dec 04, 2012 at 03:10:00PM -0600, Adam Litke wrote:
> > On Tue, Dec 04, 2012 at 12:32:34PM -0500, Antoni Segura Puimedon wrote:
> > > Hi list!
> > >
> > > We are working on the new 3.2 feature for adding support for updating VM
> > > devices, more specifically at the moment network devices.
> > >
> > > There is one point of the design which is not yet consensual and we'd
> > > need to agree on a proper and clean design that would satisfy us all:
> > >
> > > My current proposal, as reflected by patch:
> > >http://gerrit.ovirt.org/#/c/9560/5/vdsm_api/vdsmapi-schema.json
> > > and its parent is to have a linkActive boolean that is true for link
> > > status 'up' and false for link status 'down'.
> > >
> > > We want to support a none (dummy) network that is used to dissociate vnics
> > > from any real network. The semantics, as you can see in the patch are that
> > > unless you specify a network, updateDevice will place the interface on
> > > that
> > > network. However, Adam Litke argues that not specifying a network should
> > > keep the vnic on the network it currently is, as network is an optional
> > > parameter and 'linkActive' is also optional and has this "preserve current
> > > state" semantics.
> > >
> > > I can certainly see the merit of what Adam proposes, and the
> > > implementation
> > > would be that linkActive becomes an enum like so:
> > >
> > > {'enum': 'linkState'/* or linkActive */ , 'data': ['up', 'down',
> > > 'disconnected']}
> > >
> > > With this change, network would only be changed if one different than the
> > > current
> > > one is specified and the vnic would be taken to the dummy bridge when the
> > > linkState
> > > would be set to 'disconnected'.
> > >
> > > There is also an objection, raised by Adam about the semantics of
> > > portMirroring.
> > > The current behavior from my patch is:
> > >
> > > portMirroring is None or is not set -> No action taken.
> > > portMirroring = [] -> No action taken.
> > > portMirroring = [a,b,z] -> Set port mirroring for nets a,b and z to the
> > > specified vnic.
> > >
> > > His proposal is:
> > > portMirroring is None or is not set -> No action taken.
> > > portMirroring = [] -> Unset port mirroring to the vnic that is currently
> > > set.
> > > portMirroring = [a,b,z] -> Set port mirroring for nets a,b and z to the
> > > specified vnic.
> > >
> > > I would really welcome comments on this to have finally an agreement to
> > > the api for this
> > > feature.
>
> ack for portMirroring semantics. [] must mean "no networks are mirrored
> to this nic".
>
> I am less sure about allowing a "No action taken" semantics, as it
> add the current state to the API and complicates it. I'd also like to
> keep the updateDevice API as similar as possible to vmCreate one.
>
> However, we already have defaults in vmCreate (for pci address
> allocation, portmirroring off) so I suppose I can join Adam here.
>
> But this does not mean we should allow a default everywhere. I find it
> unintuitive to have a linkState=disconnected, as setting this attribute
> should clear the network attribute - they become non-orthogonal. So in
> my opinion, a missing network should mean "nic is connected to no
> network" rather than "keep current connection".
Hmm, a split second after sending this, I've realized that my suggestion
has a similar non-orthogonality problem: when you remove the network
attribute, you implictly change the linkState to "down".
So both options are bad :-(
Still I feel that linkState is a "lesser" attribute, relative to
network, and it would be better to have network imply linkState and not
vice versa.
Dan.
___
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] link state semantics
On Tue, Dec 04, 2012 at 03:10:00PM -0600, Adam Litke wrote:
> On Tue, Dec 04, 2012 at 12:32:34PM -0500, Antoni Segura Puimedon wrote:
> > Hi list!
> >
> > We are working on the new 3.2 feature for adding support for updating VM
> > devices, more specifically at the moment network devices.
> >
> > There is one point of the design which is not yet consensual and we'd
> > need to agree on a proper and clean design that would satisfy us all:
> >
> > My current proposal, as reflected by patch:
> >http://gerrit.ovirt.org/#/c/9560/5/vdsm_api/vdsmapi-schema.json
> > and its parent is to have a linkActive boolean that is true for link
> > status 'up' and false for link status 'down'.
> >
> > We want to support a none (dummy) network that is used to dissociate vnics
> > from any real network. The semantics, as you can see in the patch are that
> > unless you specify a network, updateDevice will place the interface on that
> > network. However, Adam Litke argues that not specifying a network should
> > keep the vnic on the network it currently is, as network is an optional
> > parameter and 'linkActive' is also optional and has this "preserve current
> > state" semantics.
> >
> > I can certainly see the merit of what Adam proposes, and the implementation
> > would be that linkActive becomes an enum like so:
> >
> > {'enum': 'linkState'/* or linkActive */ , 'data': ['up', 'down',
> > 'disconnected']}
> >
> > With this change, network would only be changed if one different than the
> > current
> > one is specified and the vnic would be taken to the dummy bridge when the
> > linkState
> > would be set to 'disconnected'.
> >
> > There is also an objection, raised by Adam about the semantics of
> > portMirroring.
> > The current behavior from my patch is:
> >
> > portMirroring is None or is not set -> No action taken.
> > portMirroring = [] -> No action taken.
> > portMirroring = [a,b,z] -> Set port mirroring for nets a,b and z to the
> > specified vnic.
> >
> > His proposal is:
> > portMirroring is None or is not set -> No action taken.
> > portMirroring = [] -> Unset port mirroring to the vnic that is currently
> > set.
> > portMirroring = [a,b,z] -> Set port mirroring for nets a,b and z to the
> > specified vnic.
> >
> > I would really welcome comments on this to have finally an agreement to the
> > api for this
> > feature.
ack for portMirroring semantics. [] must mean "no networks are mirrored
to this nic".
I am less sure about allowing a "No action taken" semantics, as it
add the current state to the API and complicates it. I'd also like to
keep the updateDevice API as similar as possible to vmCreate one.
However, we already have defaults in vmCreate (for pci address
allocation, portmirroring off) so I suppose I can join Adam here.
But this does not mean we should allow a default everywhere. I find it
unintuitive to have a linkState=disconnected, as setting this attribute
should clear the network attribute - they become non-orthogonal. So in
my opinion, a missing network should mean "nic is connected to no
network" rather than "keep current connection".
Dan.
___
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] link state semantics
- Original Message -
> From: "Igor Lvovsky"
> To: "Antoni Segura Puimedon"
> Cc: "Alona Kaplan" , vdsm-devel@lists.fedorahosted.org
> Sent: Wednesday, December 5, 2012 10:17:50 AM
> Subject: Re: [vdsm] link state semantics
>
>
>
> - Original Message -
> > From: "Antoni Segura Puimedon"
> > To: vdsm-devel@lists.fedorahosted.org
> > Cc: "Alona Kaplan"
> > Sent: Tuesday, December 4, 2012 7:32:34 PM
> > Subject: [vdsm] link state semantics
> >
> > Hi list!
> >
> > We are working on the new 3.2 feature for adding support for
> > updating
> > VM
> > devices, more specifically at the moment network devices.
> >
> > There is one point of the design which is not yet consensual and
> > we'd
> > need to agree on a proper and clean design that would satisfy us
> > all:
> >
> > My current proposal, as reflected by patch:
> >http://gerrit.ovirt.org/#/c/9560/5/vdsm_api/vdsmapi-schema.json
> > and its parent is to have a linkActive boolean that is true for
> > link
> > status 'up' and false for link status 'down'.
> >
> > We want to support a none (dummy) network that is used to
> > dissociate
> > vnics
> > from any real network. The semantics, as you can see in the patch
> > are
> > that
> > unless you specify a network, updateDevice will place the interface
> > on that
> > network. However, Adam Litke argues that not specifying a network
> > should
> > keep the vnic on the network it currently is, as network is an
> > optional
> > parameter and 'linkActive' is also optional and has this "preserve
> > current
> > state" semantics.
> >
> > I can certainly see the merit of what Adam proposes, and the
> > implementation
> > would be that linkActive becomes an enum like so:
> >
> > {'enum': 'linkState'/* or linkActive */ , 'data': ['up', 'down',
> > 'disconnected']}
> >
>
> If you are going for this use 'linkState'
>
> > With this change, network would only be changed if one different
> > than
> > the current
> > one is specified and the vnic would be taken to the dummy bridge
> > when
> > the linkState
> > would be set to 'disconnected'.
>
> In general +1 for new one, with a little doubt.
> It looks a bit inconsistent that we leave the network as is if it
> omitted from input,
> but if linkState is 'disconnected' we will move it to dummy bridge.
> But I can live with it.
Yes, the 'disconnected' overrules the network and that, as you point
out, can be a source of confusion. I propose to add a warning to the
return dictionary that tells the user that setting disconnected overrules
any network setting.
>
> >
> > There is also an objection, raised by Adam about the semantics of
> > portMirroring.
> > The current behavior from my patch is:
> >
> > portMirroring is None or is not set -> No action taken.
> > portMirroring = [] -> No action taken.
> > portMirroring = [a,b,z] -> Set port mirroring for nets a,b and z to
> > the specified vnic.
> >
> > His proposal is:
> > portMirroring is None or is not set -> No action taken.
> > portMirroring = [] -> Unset port mirroring to the vnic that is
> > currently set.
> > portMirroring = [a,b,z] -> Set port mirroring for nets a,b and z to
> > the specified vnic.
> >
>
> +1 for Adam's approach, just don't forget to unset portMirroring from
> all nets setted before
> if they not in new portMirroring = [a,b,z]
So you're saying:
portMirroring is None or is not set -> No action taken.
portMirroring = [] -> Unset port mirroring to the vnic that is
currently set.
portMirroring = [a,b,z] -> Set port mirroring for nets a,b and z to
the specified vnic AND unset any other mirroring.
I'm fine with it, I think it is even more complete and correct.
>
> > I would really welcome comments on this to have finally an
> > agreement
> > to the api for this
> > feature.
> >
> > Best,
> >
> > Toni
> > ___
> > vdsm-devel mailing list
> > vdsm-devel@lists.fedorahosted.org
> > https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
> >
>
___
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] link state semantics
- Original Message -
> From: "Antoni Segura Puimedon"
> To: vdsm-devel@lists.fedorahosted.org
> Cc: "Alona Kaplan"
> Sent: Tuesday, December 4, 2012 7:32:34 PM
> Subject: [vdsm] link state semantics
>
> Hi list!
>
> We are working on the new 3.2 feature for adding support for updating
> VM
> devices, more specifically at the moment network devices.
>
> There is one point of the design which is not yet consensual and we'd
> need to agree on a proper and clean design that would satisfy us all:
>
> My current proposal, as reflected by patch:
>http://gerrit.ovirt.org/#/c/9560/5/vdsm_api/vdsmapi-schema.json
> and its parent is to have a linkActive boolean that is true for link
> status 'up' and false for link status 'down'.
>
> We want to support a none (dummy) network that is used to dissociate
> vnics
> from any real network. The semantics, as you can see in the patch are
> that
> unless you specify a network, updateDevice will place the interface
> on that
> network. However, Adam Litke argues that not specifying a network
> should
> keep the vnic on the network it currently is, as network is an
> optional
> parameter and 'linkActive' is also optional and has this "preserve
> current
> state" semantics.
>
> I can certainly see the merit of what Adam proposes, and the
> implementation
> would be that linkActive becomes an enum like so:
>
> {'enum': 'linkState'/* or linkActive */ , 'data': ['up', 'down',
> 'disconnected']}
>
If you are going for this use 'linkState'
> With this change, network would only be changed if one different than
> the current
> one is specified and the vnic would be taken to the dummy bridge when
> the linkState
> would be set to 'disconnected'.
In general +1 for new one, with a little doubt.
It looks a bit inconsistent that we leave the network as is if it omitted from
input,
but if linkState is 'disconnected' we will move it to dummy bridge.
But I can live with it.
>
> There is also an objection, raised by Adam about the semantics of
> portMirroring.
> The current behavior from my patch is:
>
> portMirroring is None or is not set -> No action taken.
> portMirroring = [] -> No action taken.
> portMirroring = [a,b,z] -> Set port mirroring for nets a,b and z to
> the specified vnic.
>
> His proposal is:
> portMirroring is None or is not set -> No action taken.
> portMirroring = [] -> Unset port mirroring to the vnic that is
> currently set.
> portMirroring = [a,b,z] -> Set port mirroring for nets a,b and z to
> the specified vnic.
>
+1 for Adam's approach, just don't forget to unset portMirroring from all nets
setted before
if they not in new portMirroring = [a,b,z]
> I would really welcome comments on this to have finally an agreement
> to the api for this
> feature.
>
> Best,
>
> Toni
> ___
> vdsm-devel mailing list
> vdsm-devel@lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
>
___
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
[vdsm] Host bios information
Today in the Api we display general information about the host that vdsm export by getCapabilities Api. We decided to add bios information as part of the information that is displayed in UI under host's general sub-tab. To summaries the feature - We'll modify General tab to Software Information and add another tab for Hardware Information which will include all the bios data that we'll decide to gather from the host and display. Following this feature page: http://www.ovirt.org/Features/Design/HostBiosInfo for more details. All the parameters that can be displayed are mentioned in the wiki. I would greatly appreciate your comments and questions. Thanks. -- Yaniv Bronhaim. RedHat, Israel 09-7692289 054-7744187 ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
