Re: [Engine-devel] minutes for sync up on Open Attestation integration with oVirt in 4/9

From: "Itamar Heim" <iheim(a)redhat.com&gt; To: "Oved Ourfalli" <ovedo(a)redhat.com&gt; Cc: engine-devel(a)ovirt.org Sent: Monday, April 15, 2013 9:49:12 AM Subject: Re: [Engine-devel] minutes for sync up on Open Attestation integration with oVirt in 4/9 On 04/15/2013 09:20 AM, Oved Ourfalli wrote: > > > ----- Original Message ----- >> From: "Wei D Chen" <wei.d.chen(a)intel.com&gt; >> To: "Doron Fediuck" <dfediuck(a)redhat.com&gt;, "Ofri Masad" >> <omasad(a)redhat.com&gt; >> Cc: engine-devel(a)ovirt.org >> Sent: Monday, April 15, 2013 8:54:18 AM >> Subject: Re: [Engine-devel] minutes for sync up on Open Attestation >> integration with oVirt in 4/9 >> >> Hi Doron and Ofri, >> >> Thanks for your reply, here is some other question. >> >> ii. When adding a host into the trusted cluster, the host will be >> attested via OAT service, only trusted hosted can be added. >> >> Would you also kindly tell me if there is any mandatory logic check >> when adding a host into a cluster, so we can also put attestation >> logic with these mandatory check together? Some example or code location is better. >> Thanks a lot. >> > > I think there are two approaches, depending on the use case. > #1: > If the host trusted property is static, then you can narrow the > tests to two locations: > * AddVdsCommand - (Vds = Host) - This command is triggered when a > new host is added to the system. You can use the canDoAction method > (which we have on all commands, and it determines whether an action > can be run or not), and there, if cluster requires trusted hosts > only, you can test whether this host is trusted or not. > * ChangeVdsClusterCommand - this command is used when you change the > cluster of a host. So, if the target cluster requires tursted hosts, > you can do a similar test in its canDoAction method. > > #2: > If the host trusted property can change, then I'd suggest using the > NonOperational property of a host. > We have a class called VdsUpdateRunTimeInfo that does periodic tests > of hosts, deciding what's their status, according to specific flags. > The code there is quite complex, and would require refactoring at > some point, but in the meantime you can use the MonitoringStrategy > interface that is being used there, and implement a new monitoring > strategy for Open Attestation. > > There, in the processHardwareCapabilities, you can test that the > host is trusted. > > When creating the strategy, using the MonitoringStrategyFactory, > you'll need to create the appropriate strategy. > Currently we support either virt strategy or gluster strategy or > both. In your case you would need virt+attestation / > gluster+attestation / > virt+gluster+attestation, according to the services deployed on the > cluster. I'd go with the 2nd approach. i.e., not block the host from being added, only from being used, based on monitoring / non-op status

> > > Does that make sense? > Doron and Ofri, what did you have in mind for this feature? > > Regards, > Oved > >> >> Best Regards, >> Dave Chen >> >> >> -----Original Message----- >> From: Doron Fediuck [mailto:dfediuck@redhat.com] >> Sent: Wednesday, April 10, 2013 8:03 PM >> To: Ofri Masad >> Cc: Wei, Gang; Chen, Wei D; Cao, Buddy; Zhang, Lijuan >> Subject: Re: minutes for sync up on Open Attestation integration >> with oVirt in 4/9 >> >> >> >> ----- Original Message ----- >>> From: "Ofri Masad" <omasad(a)redhat.com&gt; >>> To: "Gang Wei" <gang.wei(a)intel.com&gt; >>> Cc: "Wei D Chen" <wei.d.chen(a)intel.com&gt;, "Buddy Cao" >>> <buddy.cao(a)intel.com&gt;, "Lijuan Zhang" <lijuan.zhang(a)intel.com&gt;, >>> "Doron Fediuck" <dfediuck(a)redhat.com&gt; >>> Sent: Wednesday, April 10, 2013 2:23:57 PM >>> Subject: Re: minutes for sync up on Open Attestation integration >>> with oVirt in 4/9 >>> >>> Hi, >>> >>> answers inside the mail body. >>> >>> ----- Original Message ----- >>>> From: "Doron Fediuck" <dfediuck(a)redhat.com&gt; >>>> To: "Wei D Chen" <wei.d.chen(a)intel.com&gt; >>>> Cc: "Gang Wei" <gang.wei(a)intel.com&gt;, "Buddy Cao" >>>> <buddy.cao(a)intel.com&gt;, "Lijuan Zhang" <lijuan.zhang(a)intel.com&gt;, >>>> "Ofri Masad" <omasad(a)redhat.com&gt; >>>> Sent: Wednesday, April 10, 2013 12:12:26 PM >>>> Subject: Re: minutes for sync up on Open Attestation integration >>>> with oVirt in 4/9 >>>> >>>> Hi Dave, >>>> Adding Ofri to answer your questions. >>>> >>>> ----- Original Message ----- >>>>> From: "Wei D Chen" <wei.d.chen(a)intel.com&gt; >>>>> To: "Gang Wei" <gang.wei(a)intel.com&gt;, "Doron Fediuck" >>>>> <dfediuck(a)redhat.com&gt;, >>>>> "Buddy Cao" <buddy.cao(a)intel.com&gt;, "Lijuan Zhang" >>>>> <lijuan.zhang(a)intel.com&gt; >>>>> Sent: Wednesday, April 10, 2013 6:31:05 AM >>>>> Subject: RE: minutes for sync up on Open Attestation integration >>>>> with oVirt in 4/9 >>>>> >>>>> Hi Doron, >>>>> >>>>> >>>>> iii. Then periodic trust check will be added into background process >>>>> for >>>>> all existing hosts, once becoming non-trusted, mark it as >>>>> non-operational. >>>>> >>>>> - [Dave] Would you give me some details about the “background >>>>> process” mentioned in our sync up meeting? What’s the process >>>>> and where is related code? >>>>> >>> >>> The use Quartz Job to scheduled background processes. >>> An example can be found in: >>> ovirt-engine/backend/manager/modules/bll/src/main/java/org/ovirt/engine/core/bll/Backend.java(Line: >>> 222) >>> >>> This code calls a method that is located in: >>> ovirt-engine/backend/manager/modules/bll/src/main/java/org/ovirt/e >>> ngin e/core/bll/quota/QuotaManager.java >>> (Line: 1000) >>> the @OnTimerMethodAnnotation annotation and the unique job name >>> connects the two in runtime. >>> >>> The job can query the attestation server for all the host and then >>> set untrusted hosts to Non-Operational. >>> the best way would be to call SetNonOperationalVdsCommand with a >>> new NonOperationalReason. >>> This command tries to migrate all VMs from the host and then set >>> it non operational. >>> (We need to think about non-migrational VMs - should we close >>> those VMs or keep the host running) >>> >> >> One more thing you may want to consider; If we get a positive >> response for a host which is currently non-operational, issue an >> activate command to try and make it operational again. >> Alternatively, you may decide not to handle it, assuming untrusted >> hosts can only be activated manually (see below Ofri's response on >> activating a host). >> >>>>> >>>>> iv. If admin fixed the non-operational node and try to switch it to >>>>> operational mode again, a trust check will happen to gate the >>>>> switching. >>>>> >>>>> - [Dave] If there is a button provided from UI for checking >>>>> the >>>>> logic? or we need add an extra-button for attestation check only? >>>>> >>> >>> In the UI we already have the "Activate" option. What still needs >>> to be added is the check with the attestation provider to make >>> sure that if the cluster is defined 'Trusted'. If so, only trusted >>> host will succeed in the activate command (and, of course, a >>> proper Audit Log error in case the host failed to activate due to trust issue. >>> >>> the correct place to add this check would be in: >>> ovirt-engine/backend/manager/modules/vdsbroker/src/main/java/org/o >>> virt >>> /engine/core/vdsbroker/VdsManager.java:activate() >>> this is where the re-activation process begins. >>> >>>>> >>>>> Thanks very much. >>>>> >>>>> >>>>> >>>>> Best Regards, >>>>> Dave Chen >> _______________________________________________ >> Engine-devel mailing list >> Engine-devel(a)ovirt.org >> http://lists.ovirt.org/mailman/listinfo/engine-devel >> > _______________________________________________ > Engine-devel mailing list > Engine-devel(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > _______________________________________________ Engine-devel mailing list Engine-devel(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel