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

From: "Doron Fediuck" <dfediuck(a)redhat.com&gt; To: "Itamar Heim" <iheim(a)redhat.com&gt; Cc: "Oved Ourfalli" <ovedo(a)redhat.com&gt;, engine-devel(a)ovirt.org Sent: Monday, April 15, 2013 10:05:57 AM Subject: Re: [Engine-devel] minutes for sync up on Open Attestation integration with oVirt in 4/9 ----- Original Message ----- > 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 > > virt+gluster+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 > +1. It means that the admin can add the host, but the host will not be operational until we get a positive indication from the attestation service.

> > > > > > > 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 > >>> /engin 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 > >>> /ovirt > >>> /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 > _______________________________________________ Engine-devel mailing list Engine-devel(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel