[Libvirt-cim] [PATCH 1 of 2] Add calls into VSMigrationService to utilize new MigrationIndication provider
Jay Gagnon
grendel at linux.vnet.ibm.com
Mon Feb 4 15:37:45 UTC 2008
Dan Smith wrote:
> However, as Jay points out, I think that the indication should be
> typed per-platform as usual. So, should we type the job to match,
> since we'll need to persist the information for typing the indication
> as well?
>
>
I'm no Heidi, but it seems like we should be prefixing this. We prefix
every other class we create, and if somebody doesn't want to deal with
the Xen/KVM distinction they are welcome to subscribe to/filter
on/whatever they want the CIM super class and get both, right?
As to where the prefix comes from, I think Kaitlin was on to something
with the ref that comes in from migrate_do, although I think it can be
even easier than she said. We don't actually need to attach the prefix
to the migration_job structure; we're already attaching the classname,
so all we need is a call to class_prefix_name and we've got a prefix.
>
> JG> @@ -297,12 +319,50 @@ static void migrate_job_set_state(struct
> JG> CMSetProperty(inst, "Status",
> JG> (CMPIValue *)status, CMPI_chars);
>
> JG> + CU_DEBUG("Creating indication.");
> JG> + /* Prefix needs to be dynamic */
> JG> + ind = get_typed_instance(_BROKER,
> JG> + "Xen",
> JG> + "ComputerSystemMigrationIndication",
> JG> + job->ref_ns);
> JG> + /* Prefix needs to be dynamic */
> JG> + if (ind == NULL) {
> JG> + CU_DEBUG("Failed to create ind, type '%s:%s_%s'",
> JG> + job->ref_ns,
> JG> + "Xen",
> JG> + "ComputerSystemMigrationIndication");
> JG> + }
> JG> +
> JG> + /* Need to copy job inst before attaching as PreviousInstance because
> JG> + otherwise the changes we are about to make to job inst are made
> JG> + to PreviousInstance as well. */
> JG> + s = cu_dup_instance(_BROKER, inst, &prev_inst);
>
> I didn't quite understand from the other patch, but I don't think this
> is what you want to do. You create an instance with a set of
> properties set (like CCN) with the get_typed_instance() call, but then
> just overwrite the ObjectPath of it here.
>
> I think the semantics of the cu_dup_instance() call should be that it
> creates you a new instance. Something like this maybe:
>
> new_inst = cu_dup_instance(_BROKER, src_inst, &s);
>
As was already brought to light by my first run at cu_dup_instance, I
get easily turned around when I start working with actual instances and
such, so I'd like to make sure I follow this. Let's say I fix up
cu_dup_instance so that it creates a new instance using the existing
instances ObjectPath, then copies all the properties correctly. Then I
wouldn't have to call get_typed_instance in the first place, because
everything that it does is already taken care of, right?
> JG> + if (s.rc != CMPI_RC_OK || prev_inst == NULL) {
> JG> + CU_DEBUG("dup_instance failed (%i:%s)", s.rc, s.msg);
> JG> + return;
> JG> + }
> JG> +
> JG> + CU_DEBUG("Setting PreviousInstance");
> JG> + CMSetProperty(ind, "PreviousInstance",
> JG> + (CMPIValue *)&prev_inst, CMPI_instance);
> JG> +
> JG> CU_DEBUG("Modifying job %s (%i:%s)", job->uuid, state, status);
>
> JG> s = CBModifyInstance(_BROKER, job->context, op, inst, NULL);
> JG> if (s.rc != CMPI_RC_OK)
> JG> CU_DEBUG("Failed to update job instance: %s",
> JG> CMGetCharPtr(s.msg));
> JG> +
> JG> + CU_DEBUG("Setting SourceInstance");
> JG> + CMSetProperty(ind, "SourceInstance",
> JG> + (CMPIValue *)&inst, CMPI_instance);
> JG> +
> JG> + rc = raise_indication(job->context,
> JG> + "ComputerSystemMigrationIndication",
> JG> + job->ref_ns,
> JG> + ind);
> JG> + if (!rc)
> JG> + CU_DEBUG("Failed to raise indication");
> JG> }
>
> These changes make the migrate_job_set_state() function quite a bit
> longer. Can we break out these out into a separate function? If it
> just returns an indication instance, then maybe something like this
> could work:
>
> ind = prepare_indication(job_inst);
>
> /* Existing job_inst update code */
>
> raise_indication(ind, job_inst);
>
> The prepare call would dup the old instance and create the indication
> instance, and the raise call would add the updated version and do the
> actual raise. What do you think?
>
Sure that's fine. I didn't think too much about code structure when I
was in "wait is that gonna work?" mode; should have cleaned up a little
more before I sent it out.
--
-Jay
More information about the Libvirt-cim
mailing list