[Engine-devel] minutes for sync up on Open Attestation integration with oVirt in 4/9
Chen, Wei D
wei.d.chen at intel.com
Wed Apr 17 07:44:05 UTC 2013
Thanks Ofri, whether Quartz job is configurable? If we can config interval time, it will do us a favor.
Best Regards,
Dave Chen
-----Original Message-----
From: Ofri Masad [mailto:omasad at redhat.com]
Sent: Wednesday, April 17, 2013 3:23 PM
To: Chen, Wei D
Cc: Omer Frenkel; Doron Fediuck; Oved Ourfalli; engine-devel at ovirt.org
Subject: Re: [Engine-devel] minutes for sync up on Open Attestation integration with oVirt in 4/9
Hi Dave,
The VdsUpdateRunTimeInfo runs every 3 seconds or so. so it not a good place to call the attestation host.
Instead, like we suggested earlier, create a new Quartz job (like the one I've sent you in the QuotaManager class) which run every couple of minutes and update the hosts state.
You can also add the check to InitVdsOnUpCommand, so that if a host was down for a different reason, it will be rechecked for attestation.
You can add a UI to allow manual "refresh attestation".
Ofri
----- Original Message -----
> From: "Wei D Chen" <wei.d.chen at intel.com>
> To: "Omer Frenkel" <ofrenkel at redhat.com>, "Doron Fediuck"
> <dfediuck at redhat.com>
> Cc: "Oved Ourfalli" <ovedo at redhat.com>, engine-devel at ovirt.org
> Sent: Monday, April 15, 2013 5:53:34 PM
> Subject: Re: [Engine-devel] minutes for sync up on Open Attestation
> integration with oVirt in 4/9
>
> Good approach, thanks all. How long it needs to invoke periodic check
> in the class of VdsUpdateRunTimeInfo? Whether this time configurable?
> My concern is if the initial status of each host added into trusted
> cluster is non-operational, we need wait a long time for the invoking
> of this periodic check, so a trusted host's with initial status of
> non-operational will take a long time to flip to a trusted host.
>
> As I have not seen the configuration of periodic check in
> VdsUpdateRunTimeInfo, would you give me some tips if you has some clue.
> Thanks a lot.
>
> Best Regards,
> Dave Chen
>
> -----Original Message-----
> From: engine-devel-bounces at ovirt.org
> [mailto:engine-devel-bounces at ovirt.org]
> On Behalf Of Omer Frenkel
> Sent: Monday, April 15, 2013 7:01 PM
> To: Doron Fediuck
> Cc: Oved Ourfalli; engine-devel at ovirt.org
> Subject: Re: [Engine-devel] minutes for sync up on Open Attestation
> integration with oVirt in 4/9
>
>
>
> ----- Original Message -----
> > From: "Doron Fediuck" <dfediuck at redhat.com>
> > To: "Itamar Heim" <iheim at redhat.com>
> > Cc: "Oved Ourfalli" <ovedo at redhat.com>, engine-devel at 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 at redhat.com>
> > > To: "Oved Ourfalli" <ovedo at redhat.com>
> > > Cc: engine-devel at 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 at intel.com>
> > > >> To: "Doron Fediuck" <dfediuck at redhat.com>, "Ofri Masad"
> > > >> <omasad at redhat.com>
> > > >> Cc: engine-devel at 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.
> >
> +1
> if we want to test attestation only once, every time before host moves to up.
> the right place for it, imo, is InitVdsOnUpCommand if its periodic
> also after host is up, then it should be somewhere in the monitoring
> code
>
> > >
> > > >
> > > >
> > > > 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 at 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 at redhat.com>
> > > >>> To: "Gang Wei" <gang.wei at intel.com>
> > > >>> Cc: "Wei D Chen" <wei.d.chen at intel.com>, "Buddy Cao"
> > > >>> <buddy.cao at intel.com>, "Lijuan Zhang"
> > > >>> <lijuan.zhang at intel.com>, "Doron Fediuck"
> > > >>> <dfediuck at redhat.com>
> > > >>> 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 at redhat.com>
> > > >>>> To: "Wei D Chen" <wei.d.chen at intel.com>
> > > >>>> Cc: "Gang Wei" <gang.wei at intel.com>, "Buddy Cao"
> > > >>>> <buddy.cao at intel.com>, "Lijuan Zhang"
> > > >>>> <lijuan.zhang at intel.com>, "Ofri Masad" <omasad at redhat.com>
> > > >>>> 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 at intel.com>
> > > >>>>> To: "Gang Wei" <gang.wei at intel.com>, "Doron Fediuck"
> > > >>>>> <dfediuck at redhat.com>,
> > > >>>>> "Buddy Cao" <buddy.cao at intel.com>, "Lijuan Zhang"
> > > >>>>> <lijuan.zhang at intel.com>
> > > >>>>> 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/ovi
> > > >>> rt /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/o
> > > >>> rg
> > > >>> /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 at ovirt.org
> > > >> http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > >>
> > > > _______________________________________________
> > > > Engine-devel mailing list
> > > > Engine-devel at ovirt.org
> > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > >
> > >
> > > _______________________________________________
> > > Engine-devel mailing list
> > > Engine-devel at ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > >
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> >
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>
More information about the Engine-devel
mailing list