Re: [Engine-devel] minutes for sync up on Open Attestation integration with oVirt in 4/9
I think it's more sensible, the initial status should be the real status for this host (trusted / untrusted) only the untrusted host will be set to non-operational. we just need poll this host instead of all of the hosts in the cluster if this can be done in InitVdsOnUpCommand, and we suppose this is the first time when this host add into the cluster. Follow these steps (conclusion based on your suggestion). - The first time when one host is added into a trust cluster then poll this host, the host will be in up status if get trusted result from attestation server, or else, set this host as non-operational status. - The periodic check will poll all of the hosts only once as this will cut down a lot of time needed instead of poll each host one by one, this conclusion is based on our experiments because most of time consumed is in parallel. - When host is down for a different reason and up again, we suppose InitVdsOnUpCommand will be triggered again (right?), so we will poll this host again to get the real status(trusted / untrusted). Then mark the host as up or non-operational. As a trusted host flip to untrusted and take effective only under the condition of this host has been hacked and rebooted, so we proposal no need to add periodic check if any host's reboot will invoke InitVdsOnUpCommand and we add attestation logic in InitVdsOnUpCommand is enough. My proposal would be like this (no periodic check is needed, will simply our integration) - The first time when one host is added into a trust cluster then poll this host, the host will be in up status if get trusted result from attestation server, or else, set this host as non-operational status. - The periodic check will poll all of the hosts only once as this will cut down a lot of time needed instead of poll each host one by one, this conclusion is based on our experiments because most of time consumed is in parallel. - (up - nonoperationl / trusted - untrusted)When host is down for a different reason and up again, we suppose InitVdsOnUpCommand will be triggered again (right?) and we also suppose the host will be non-operational if host is down for some reason (right), so we will poll this host again to get the real status(trusted / untrusted) after host's rebooting. - (nonoperationl - up / untrusted - trusted) Admin will activate this host manually after admin fix the issue of this host. Attestation logic will be added into VdsManager:activate () as the clue you give me before. Any suggestion? Best Regards, Dave Chen -Original Message- From: Itamar Heim [mailto:ih...@redhat.com] Sent: Wednesday, April 17, 2013 8:31 PM To: Ofri Masad Cc: Chen, Wei D; Oved Ourfalli; engine-devel@ovirt.org Subject: Re: [Engine-devel] minutes for sync up on Open Attestation integration with oVirt in 4/9 On 04/17/2013 10:23 AM, Ofri Masad wrote: 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. so the new thread will poll all for all hosts and update the db, then during the normal monitoring detect the issue? Ofri - Original Message - From: Wei D Chen wei.d.c...@intel.com To: Omer Frenkel ofren...@redhat.com, Doron Fediuck dfedi...@redhat.com Cc: Oved Ourfalli ov...@redhat.com, engine-devel@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-boun...@ovirt.org [mailto:engine-devel-boun...@ovirt.org] On Behalf Of Omer Frenkel Sent: Monday, April 15, 2013 7:01 PM To: Doron Fediuck Cc: Oved Ourfalli; engine-devel@ovirt.org Subject: Re: [Engine-devel] minutes for sync up on Open Attestation integration with oVirt in 4/9 - Original Message - From: Doron Fediuck dfedi...@redhat.com To: Itamar Heim ih...@redhat.com Cc: Oved Ourfalli ov...@redhat.com, engine-devel@ovirt.org
Re: [Engine-devel] minutes for sync up on Open Attestation integration with oVirt in 4/9
Hi Dave, Can't a host become untrusted without being rebooted? If that is really the case, there is no need for a periodic check - the trigger for the check would be the host rebooting (which is visible to the engine). Thanks, Ofri - Original Message - From: Wei D Chen wei.d.c...@intel.com To: Itamar Heim ih...@redhat.com, Ofri Masad oma...@redhat.com Cc: Oved Ourfalli ov...@redhat.com, engine-devel@ovirt.org Sent: Thursday, April 18, 2013 9:19:03 AM Subject: RE: [Engine-devel] minutes for sync up on Open Attestation integration with oVirt in 4/9 I think it's more sensible, the initial status should be the real status for this host (trusted / untrusted) only the untrusted host will be set to non-operational. we just need poll this host instead of all of the hosts in the cluster if this can be done in InitVdsOnUpCommand, and we suppose this is the first time when this host add into the cluster. Follow these steps (conclusion based on your suggestion). - The first time when one host is added into a trust cluster then poll this host, the host will be in up status if get trusted result from attestation server, or else, set this host as non-operational status. - The periodic check will poll all of the hosts only once as this will cut down a lot of time needed instead of poll each host one by one, this conclusion is based on our experiments because most of time consumed is in parallel. - When host is down for a different reason and up again, we suppose InitVdsOnUpCommand will be triggered again (right?), so we will poll this host again to get the real status(trusted / untrusted). Then mark the host as up or non-operational. As a trusted host flip to untrusted and take effective only under the condition of this host has been hacked and rebooted, so we proposal no need to add periodic check if any host's reboot will invoke InitVdsOnUpCommand and we add attestation logic in InitVdsOnUpCommand is enough. My proposal would be like this (no periodic check is needed, will simply our integration) - The first time when one host is added into a trust cluster then poll this host, the host will be in up status if get trusted result from attestation server, or else, set this host as non-operational status. - The periodic check will poll all of the hosts only once as this will cut down a lot of time needed instead of poll each host one by one, this conclusion is based on our experiments because most of time consumed is in parallel. - (up - nonoperationl / trusted - untrusted)When host is down for a different reason and up again, we suppose InitVdsOnUpCommand will be triggered again (right?) and we also suppose the host will be non-operational if host is down for some reason (right), so we will poll this host again to get the real status(trusted / untrusted) after host's rebooting. - (nonoperationl - up / untrusted - trusted) Admin will activate this host manually after admin fix the issue of this host. Attestation logic will be added into VdsManager:activate () as the clue you give me before. Any suggestion? Best Regards, Dave Chen -Original Message- From: Itamar Heim [mailto:ih...@redhat.com] Sent: Wednesday, April 17, 2013 8:31 PM To: Ofri Masad Cc: Chen, Wei D; Oved Ourfalli; engine-devel@ovirt.org Subject: Re: [Engine-devel] minutes for sync up on Open Attestation integration with oVirt in 4/9 On 04/17/2013 10:23 AM, Ofri Masad wrote: 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. so the new thread will poll all for all hosts and update the db, then during the normal monitoring detect the issue? Ofri - Original Message - From: Wei D Chen wei.d.c...@intel.com To: Omer Frenkel ofren...@redhat.com, Doron Fediuck dfedi...@redhat.com Cc: Oved Ourfalli ov...@redhat.com, engine-devel@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
Re: [Engine-devel] minutes for sync up on Open Attestation integration with oVirt in 4/9
- Original Message - From: Ofri Masad oma...@redhat.com To: Wei D Chen wei.d.c...@intel.com Cc: Oved Ourfalli ov...@redhat.com, engine-devel@ovirt.org Sent: Thursday, April 18, 2013 9:38:26 AM Subject: Re: [Engine-devel] minutes for sync up on Open Attestation integration with oVirt in 4/9 Hi Dave, Can't a host become untrusted without being rebooted? If that is really the case, there is no need for a periodic check - the trigger for the check would be the host rebooting (which is visible to the engine). +1 Thanks, Ofri - Original Message - From: Wei D Chen wei.d.c...@intel.com To: Itamar Heim ih...@redhat.com, Ofri Masad oma...@redhat.com Cc: Oved Ourfalli ov...@redhat.com, engine-devel@ovirt.org Sent: Thursday, April 18, 2013 9:19:03 AM Subject: RE: [Engine-devel] minutes for sync up on Open Attestation integration with oVirt in 4/9 I think it's more sensible, the initial status should be the real status for this host (trusted / untrusted) only the untrusted host will be set to non-operational. we just need poll this host instead of all of the hosts in the cluster if this can be done in InitVdsOnUpCommand, and we suppose this is the first time when this host add into the cluster. Follow these steps (conclusion based on your suggestion). - The first time when one host is added into a trust cluster then poll this host, the host will be in up status if get trusted result from attestation server, or else, set this host as non-operational status. - The periodic check will poll all of the hosts only once as this will cut down a lot of time needed instead of poll each host one by one, this conclusion is based on our experiments because most of time consumed is in parallel. - When host is down for a different reason and up again, we suppose InitVdsOnUpCommand will be triggered again (right?), so we will poll this host again to get the real status(trusted / untrusted). Then mark the host as up or non-operational. right As a trusted host flip to untrusted and take effective only under the condition of this host has been hacked and rebooted, so we proposal no need to add periodic check if any host's reboot will invoke InitVdsOnUpCommand and we add attestation logic in InitVdsOnUpCommand is enough. My proposal would be like this (no periodic check is needed, will simply our integration) - The first time when one host is added into a trust cluster then poll this host, the host will be in up status if get trusted result from attestation server, or else, set this host as non-operational status. - The periodic check will poll all of the hosts only once as this will cut down a lot of time needed instead of poll each host one by one, this conclusion is based on our experiments because most of time consumed is in parallel. - (up - nonoperationl / trusted - untrusted)When host is down for a different reason and up again, we suppose InitVdsOnUpCommand will be triggered again (right?) and we also suppose the host will be non-operational if host is down for some reason (right), so we will poll this host again to get the real status(trusted / untrusted) after host's rebooting. - (nonoperationl - up / untrusted - trusted) Admin will activate this host manually after admin fix the issue of this host. Attestation logic will be added into VdsManager:activate () as the clue you give me before. Any suggestion? Best Regards, Dave Chen -Original Message- From: Itamar Heim [mailto:ih...@redhat.com] Sent: Wednesday, April 17, 2013 8:31 PM To: Ofri Masad Cc: Chen, Wei D; Oved Ourfalli; engine-devel@ovirt.org Subject: Re: [Engine-devel] minutes for sync up on Open Attestation integration with oVirt in 4/9 On 04/17/2013 10:23 AM, Ofri Masad wrote: 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. so the new thread will poll all for all hosts and update the db, then during the normal monitoring detect the issue? Ofri - Original Message - From: Wei D Chen wei.d.c...@intel.com To: Omer Frenkel ofren...@redhat.com, Doron Fediuck dfedi...@redhat.com Cc: Oved Ourfalli ov...@redhat.com, engine-devel@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
Re: [Engine-devel] minutes for sync up on Open Attestation integration with oVirt in 4/9
Yes, the host must be rebooted to take effect. Doron, what do you think? Best Regards, Dave Chen -Original Message- From: Omer Frenkel [mailto:ofren...@redhat.com] Sent: Thursday, April 18, 2013 3:20 PM To: Ofri Masad Cc: Chen, Wei D; Oved Ourfalli; engine-devel@ovirt.org Subject: Re: [Engine-devel] minutes for sync up on Open Attestation integration with oVirt in 4/9 - Original Message - From: Ofri Masad oma...@redhat.com To: Wei D Chen wei.d.c...@intel.com Cc: Oved Ourfalli ov...@redhat.com, engine-devel@ovirt.org Sent: Thursday, April 18, 2013 9:38:26 AM Subject: Re: [Engine-devel] minutes for sync up on Open Attestation integration with oVirt in 4/9 Hi Dave, Can't a host become untrusted without being rebooted? If that is really the case, there is no need for a periodic check - the trigger for the check would be the host rebooting (which is visible to the engine). +1 Thanks, Ofri - Original Message - From: Wei D Chen wei.d.c...@intel.com To: Itamar Heim ih...@redhat.com, Ofri Masad oma...@redhat.com Cc: Oved Ourfalli ov...@redhat.com, engine-devel@ovirt.org Sent: Thursday, April 18, 2013 9:19:03 AM Subject: RE: [Engine-devel] minutes for sync up on Open Attestation integration with oVirt in 4/9 I think it's more sensible, the initial status should be the real status for this host (trusted / untrusted) only the untrusted host will be set to non-operational. we just need poll this host instead of all of the hosts in the cluster if this can be done in InitVdsOnUpCommand, and we suppose this is the first time when this host add into the cluster. Follow these steps (conclusion based on your suggestion). - The first time when one host is added into a trust cluster then poll this host, the host will be in up status if get trusted result from attestation server, or else, set this host as non-operational status. - The periodic check will poll all of the hosts only once as this will cut down a lot of time needed instead of poll each host one by one, this conclusion is based on our experiments because most of time consumed is in parallel. - When host is down for a different reason and up again, we suppose InitVdsOnUpCommand will be triggered again (right?), so we will poll this host again to get the real status(trusted / untrusted). Then mark the host as up or non-operational. right As a trusted host flip to untrusted and take effective only under the condition of this host has been hacked and rebooted, so we proposal no need to add periodic check if any host's reboot will invoke InitVdsOnUpCommand and we add attestation logic in InitVdsOnUpCommand is enough. My proposal would be like this (no periodic check is needed, will simply our integration) - The first time when one host is added into a trust cluster then poll this host, the host will be in up status if get trusted result from attestation server, or else, set this host as non-operational status. - The periodic check will poll all of the hosts only once as this will cut down a lot of time needed instead of poll each host one by one, this conclusion is based on our experiments because most of time consumed is in parallel. - (up - nonoperationl / trusted - untrusted)When host is down for a different reason and up again, we suppose InitVdsOnUpCommand will be triggered again (right?) and we also suppose the host will be non-operational if host is down for some reason (right), so we will poll this host again to get the real status(trusted / untrusted) after host's rebooting. - (nonoperationl - up / untrusted - trusted) Admin will activate this host manually after admin fix the issue of this host. Attestation logic will be added into VdsManager:activate () as the clue you give me before. Any suggestion? Best Regards, Dave Chen -Original Message- From: Itamar Heim [mailto:ih...@redhat.com] Sent: Wednesday, April 17, 2013 8:31 PM To: Ofri Masad Cc: Chen, Wei D; Oved Ourfalli; engine-devel@ovirt.org Subject: Re: [Engine-devel] minutes for sync up on Open Attestation integration with oVirt in 4/9 On 04/17/2013 10:23 AM, Ofri Masad wrote: 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. so the new thread will poll all for all hosts and update the db, then during the normal monitoring detect the issue? Ofri - Original
Re: [Engine-devel] minutes for sync up on Open Attestation integration with oVirt in 4/9
Generally speaking I agree, we can drop the periodic check is this is the way we expect it to work (ie- change trust level only during reboot). The only thing I'd like to verify is what happens is we miss something. ie- let's assume the engine crashed. During the engine down time a host reboots and becomes untrusted. Now what? The same goes for network disconnect. I'd expect to run a query in such cases to make sure we do not miss a state change. - Original Message - From: Wei D Chen wei.d.c...@intel.com To: Omer Frenkel ofren...@redhat.com, Ofri Masad oma...@redhat.com, Doron Fediuck dfedi...@redhat.com Cc: Oved Ourfalli ov...@redhat.com, engine-devel@ovirt.org Sent: Thursday, April 18, 2013 10:42:10 AM Subject: Re: [Engine-devel] minutes for sync up on Open Attestation integration with oVirt in 4/9 Yes, the host must be rebooted to take effect. Doron, what do you think? Best Regards, Dave Chen -Original Message- From: Omer Frenkel [mailto:ofren...@redhat.com] Sent: Thursday, April 18, 2013 3:20 PM To: Ofri Masad Cc: Chen, Wei D; Oved Ourfalli; engine-devel@ovirt.org Subject: Re: [Engine-devel] minutes for sync up on Open Attestation integration with oVirt in 4/9 - Original Message - From: Ofri Masad oma...@redhat.com To: Wei D Chen wei.d.c...@intel.com Cc: Oved Ourfalli ov...@redhat.com, engine-devel@ovirt.org Sent: Thursday, April 18, 2013 9:38:26 AM Subject: Re: [Engine-devel] minutes for sync up on Open Attestation integration with oVirt in 4/9 Hi Dave, Can't a host become untrusted without being rebooted? If that is really the case, there is no need for a periodic check - the trigger for the check would be the host rebooting (which is visible to the engine). +1 Thanks, Ofri - Original Message - From: Wei D Chen wei.d.c...@intel.com To: Itamar Heim ih...@redhat.com, Ofri Masad oma...@redhat.com Cc: Oved Ourfalli ov...@redhat.com, engine-devel@ovirt.org Sent: Thursday, April 18, 2013 9:19:03 AM Subject: RE: [Engine-devel] minutes for sync up on Open Attestation integration with oVirt in 4/9 I think it's more sensible, the initial status should be the real status for this host (trusted / untrusted) only the untrusted host will be set to non-operational. we just need poll this host instead of all of the hosts in the cluster if this can be done in InitVdsOnUpCommand, and we suppose this is the first time when this host add into the cluster. Follow these steps (conclusion based on your suggestion). - The first time when one host is added into a trust cluster then poll this host, the host will be in up status if get trusted result from attestation server, or else, set this host as non-operational status. - The periodic check will poll all of the hosts only once as this will cut down a lot of time needed instead of poll each host one by one, this conclusion is based on our experiments because most of time consumed is in parallel. - When host is down for a different reason and up again, we suppose InitVdsOnUpCommand will be triggered again (right?), so we will poll this host again to get the real status(trusted / untrusted). Then mark the host as up or non-operational. right As a trusted host flip to untrusted and take effective only under the condition of this host has been hacked and rebooted, so we proposal no need to add periodic check if any host's reboot will invoke InitVdsOnUpCommand and we add attestation logic in InitVdsOnUpCommand is enough. My proposal would be like this (no periodic check is needed, will simply our integration) - The first time when one host is added into a trust cluster then poll this host, the host will be in up status if get trusted result from attestation server, or else, set this host as non-operational status. - The periodic check will poll all of the hosts only once as this will cut down a lot of time needed instead of poll each host one by one, this conclusion is based on our experiments because most of time consumed is in parallel. - (up - nonoperationl / trusted - untrusted)When host is down for a different reason and up again, we suppose InitVdsOnUpCommand will be triggered again (right?) and we also suppose the host will be non-operational if host is down for some reason (right), so we will poll this host again to get the real status(trusted / untrusted) after host's rebooting. - (nonoperationl - up / untrusted - trusted) Admin will activate this host manually after admin fix the issue of this host. Attestation logic will be added into VdsManager:activate () as the clue you give me before. Any suggestion? Best Regards, Dave Chen -Original Message- From: Itamar Heim [mailto:ih...@redhat.com] Sent: Wednesday, April 17, 2013 8:31
Re: [Engine-devel] minutes for sync up on Open Attestation integration with oVirt in 4/9
We run the query each time the host is moving to UP state. Which means, we query all the hosts on engine restart. if the host was unreachable or down for any reason - we will query it again before moving to UP state. Ofri - Original Message - From: Doron Fediuck dfedi...@redhat.com To: Wei D Chen wei.d.c...@intel.com Cc: Omer Frenkel ofren...@redhat.com, Ofri Masad oma...@redhat.com, Oved Ourfalli ov...@redhat.com, engine-devel@ovirt.org Sent: Thursday, April 18, 2013 11:23:47 AM Subject: Re: [Engine-devel] minutes for sync up on Open Attestation integration with oVirt in 4/9 Generally speaking I agree, we can drop the periodic check is this is the way we expect it to work (ie- change trust level only during reboot). The only thing I'd like to verify is what happens is we miss something. ie- let's assume the engine crashed. During the engine down time a host reboots and becomes untrusted. Now what? The same goes for network disconnect. I'd expect to run a query in such cases to make sure we do not miss a state change. - Original Message - From: Wei D Chen wei.d.c...@intel.com To: Omer Frenkel ofren...@redhat.com, Ofri Masad oma...@redhat.com, Doron Fediuck dfedi...@redhat.com Cc: Oved Ourfalli ov...@redhat.com, engine-devel@ovirt.org Sent: Thursday, April 18, 2013 10:42:10 AM Subject: Re: [Engine-devel] minutes for sync up on Open Attestation integration with oVirt in 4/9 Yes, the host must be rebooted to take effect. Doron, what do you think? Best Regards, Dave Chen -Original Message- From: Omer Frenkel [mailto:ofren...@redhat.com] Sent: Thursday, April 18, 2013 3:20 PM To: Ofri Masad Cc: Chen, Wei D; Oved Ourfalli; engine-devel@ovirt.org Subject: Re: [Engine-devel] minutes for sync up on Open Attestation integration with oVirt in 4/9 - Original Message - From: Ofri Masad oma...@redhat.com To: Wei D Chen wei.d.c...@intel.com Cc: Oved Ourfalli ov...@redhat.com, engine-devel@ovirt.org Sent: Thursday, April 18, 2013 9:38:26 AM Subject: Re: [Engine-devel] minutes for sync up on Open Attestation integration with oVirt in 4/9 Hi Dave, Can't a host become untrusted without being rebooted? If that is really the case, there is no need for a periodic check - the trigger for the check would be the host rebooting (which is visible to the engine). +1 Thanks, Ofri - Original Message - From: Wei D Chen wei.d.c...@intel.com To: Itamar Heim ih...@redhat.com, Ofri Masad oma...@redhat.com Cc: Oved Ourfalli ov...@redhat.com, engine-devel@ovirt.org Sent: Thursday, April 18, 2013 9:19:03 AM Subject: RE: [Engine-devel] minutes for sync up on Open Attestation integration with oVirt in 4/9 I think it's more sensible, the initial status should be the real status for this host (trusted / untrusted) only the untrusted host will be set to non-operational. we just need poll this host instead of all of the hosts in the cluster if this can be done in InitVdsOnUpCommand, and we suppose this is the first time when this host add into the cluster. Follow these steps (conclusion based on your suggestion). - The first time when one host is added into a trust cluster then poll this host, the host will be in up status if get trusted result from attestation server, or else, set this host as non-operational status. - The periodic check will poll all of the hosts only once as this will cut down a lot of time needed instead of poll each host one by one, this conclusion is based on our experiments because most of time consumed is in parallel. - When host is down for a different reason and up again, we suppose InitVdsOnUpCommand will be triggered again (right?), so we will poll this host again to get the real status(trusted / untrusted). Then mark the host as up or non-operational. right As a trusted host flip to untrusted and take effective only under the condition of this host has been hacked and rebooted, so we proposal no need to add periodic check if any host's reboot will invoke InitVdsOnUpCommand and we add attestation logic in InitVdsOnUpCommand is enough. My proposal would be like this (no periodic check is needed, will simply our integration) - The first time when one host is added into a trust cluster then poll this host, the host will be in up status if get trusted result from attestation server, or else, set this host as non-operational status. - The periodic check will poll all of the hosts only once as this will cut down a lot of time needed instead of poll each host one by one, this conclusion is based on our experiments because most of time consumed is in parallel. - (up
Re: [Engine-devel] minutes for sync up on Open Attestation integration with oVirt in 4/9
True, I just want folks to be aware of it. So this should resolve it all. Now just make sure to optimize the attestation call. - Original Message - From: Ofri Masad oma...@redhat.com To: Doron Fediuck dfedi...@redhat.com Cc: Oved Ourfalli ov...@redhat.com, engine-devel@ovirt.org Sent: Thursday, April 18, 2013 11:31:28 AM Subject: Re: [Engine-devel] minutes for sync up on Open Attestation integration with oVirt in 4/9 We run the query each time the host is moving to UP state. Which means, we query all the hosts on engine restart. if the host was unreachable or down for any reason - we will query it again before moving to UP state. Ofri - Original Message - From: Doron Fediuck dfedi...@redhat.com To: Wei D Chen wei.d.c...@intel.com Cc: Omer Frenkel ofren...@redhat.com, Ofri Masad oma...@redhat.com, Oved Ourfalli ov...@redhat.com, engine-devel@ovirt.org Sent: Thursday, April 18, 2013 11:23:47 AM Subject: Re: [Engine-devel] minutes for sync up on Open Attestation integration with oVirt in 4/9 Generally speaking I agree, we can drop the periodic check is this is the way we expect it to work (ie- change trust level only during reboot). The only thing I'd like to verify is what happens is we miss something. ie- let's assume the engine crashed. During the engine down time a host reboots and becomes untrusted. Now what? The same goes for network disconnect. I'd expect to run a query in such cases to make sure we do not miss a state change. - Original Message - From: Wei D Chen wei.d.c...@intel.com To: Omer Frenkel ofren...@redhat.com, Ofri Masad oma...@redhat.com, Doron Fediuck dfedi...@redhat.com Cc: Oved Ourfalli ov...@redhat.com, engine-devel@ovirt.org Sent: Thursday, April 18, 2013 10:42:10 AM Subject: Re: [Engine-devel] minutes for sync up on Open Attestation integration with oVirt in 4/9 Yes, the host must be rebooted to take effect. Doron, what do you think? Best Regards, Dave Chen -Original Message- From: Omer Frenkel [mailto:ofren...@redhat.com] Sent: Thursday, April 18, 2013 3:20 PM To: Ofri Masad Cc: Chen, Wei D; Oved Ourfalli; engine-devel@ovirt.org Subject: Re: [Engine-devel] minutes for sync up on Open Attestation integration with oVirt in 4/9 - Original Message - From: Ofri Masad oma...@redhat.com To: Wei D Chen wei.d.c...@intel.com Cc: Oved Ourfalli ov...@redhat.com, engine-devel@ovirt.org Sent: Thursday, April 18, 2013 9:38:26 AM Subject: Re: [Engine-devel] minutes for sync up on Open Attestation integration with oVirt in 4/9 Hi Dave, Can't a host become untrusted without being rebooted? If that is really the case, there is no need for a periodic check - the trigger for the check would be the host rebooting (which is visible to the engine). +1 Thanks, Ofri - Original Message - From: Wei D Chen wei.d.c...@intel.com To: Itamar Heim ih...@redhat.com, Ofri Masad oma...@redhat.com Cc: Oved Ourfalli ov...@redhat.com, engine-devel@ovirt.org Sent: Thursday, April 18, 2013 9:19:03 AM Subject: RE: [Engine-devel] minutes for sync up on Open Attestation integration with oVirt in 4/9 I think it's more sensible, the initial status should be the real status for this host (trusted / untrusted) only the untrusted host will be set to non-operational. we just need poll this host instead of all of the hosts in the cluster if this can be done in InitVdsOnUpCommand, and we suppose this is the first time when this host add into the cluster. Follow these steps (conclusion based on your suggestion). - The first time when one host is added into a trust cluster then poll this host, the host will be in up status if get trusted result from attestation server, or else, set this host as non-operational status. - The periodic check will poll all of the hosts only once as this will cut down a lot of time needed instead of poll each host one by one, this conclusion is based on our experiments because most of time consumed is in parallel. - When host is down for a different reason and up again, we suppose InitVdsOnUpCommand will be triggered again (right?), so we will poll this host again to get the real status(trusted / untrusted). Then mark the host as up or non-operational. right As a trusted host flip to untrusted and take effective only under the condition of this host has been hacked and rebooted, so we proposal no need to add periodic check if any host's reboot will invoke InitVdsOnUpCommand and we add attestation logic in InitVdsOnUpCommand is enough. My proposal would be like this (no periodic check is needed,
[Engine-devel] Changes in DB scripts that need your attension
Hi As part of solving https://bugzilla.redhat.com/show_bug.cgi?id=947344 I am doing the following changes: 1) Create all *.md5 files in /tmp/db 2) Create db log files by default under /var/log/ovirt-engine/db 3) Do not automatically create a *.schema file that represent the up-to-date schema (after all upgrades took place) A new utility script exportDbSchema.sh will be available for that (manual only, no auto-generation schema) In order that DB scripts in development environment will keep working, please do sudo mkdir -p /var/log/ovirt-engine/db sudo chmod 777 /var/log/ovirt-engine/db If you are getting Permission Denied errors while running the scripts it means that you didn't run the 2 commands above. If you have any comments/suggestions to this solution, please respond before this patch is merged, I will wait with this change to next SUN , APR 21 2013 Best Regards Eli ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Changes in DB scripts that need your attension
- Original Message - From: Alon Bar-Lev alo...@redhat.com To: Eli Mesika emes...@redhat.com Cc: engine-devel engine-devel@ovirt.org Sent: Thursday, April 18, 2013 12:26:44 PM Subject: Re: [Engine-devel] Changes in DB scripts that need your attension Hi, - Original Message - From: Eli Mesika emes...@redhat.com To: engine-devel engine-devel@ovirt.org Sent: Thursday, April 18, 2013 12:19:43 PM Subject: [Engine-devel] Changes in DB scripts that need your attension Hi As part of solving https://bugzilla.redhat.com/show_bug.cgi?id=947344 I am doing the following changes: 1) Create all *.md5 files in /tmp/db Please use mkstemp or equivalent to create unique temp directory. OK, will use mktemp -d for that 2) Create db log files by default under /var/log/ovirt-engine/db Please allow to override log location and/or output logs to stdout. This will make it easier to run it within installer so that the log will be available at installer log. All scripts supports the -l LOGFILE flag 3) Do not automatically create a *.schema file that represent the up-to-date schema (after all upgrades took place) A new utility script exportDbSchema.sh will be available for that (manual only, no auto-generation schema) In order that DB scripts in development environment will keep working, please do sudo mkdir -p /var/log/ovirt-engine/db sudo chmod 777 /var/log/ovirt-engine/db 777 access permission is not something that should exist in system anywhere, well apart of /tmp and /tmp is marked using 't' attribute. Regards, Alon ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Changes in DB scripts that need your attension
- Original Message - From: Eli Mesika emes...@redhat.com To: Alon Bar-Lev alo...@redhat.com Cc: engine-devel engine-devel@ovirt.org Sent: Thursday, April 18, 2013 12:44:06 PM Subject: Re: [Engine-devel] Changes in DB scripts that need your attension - Original Message - From: Alon Bar-Lev alo...@redhat.com To: Eli Mesika emes...@redhat.com Cc: engine-devel engine-devel@ovirt.org Sent: Thursday, April 18, 2013 12:26:44 PM Subject: Re: [Engine-devel] Changes in DB scripts that need your attension Hi, - Original Message - From: Eli Mesika emes...@redhat.com To: engine-devel engine-devel@ovirt.org Sent: Thursday, April 18, 2013 12:19:43 PM Subject: [Engine-devel] Changes in DB scripts that need your attension Hi As part of solving https://bugzilla.redhat.com/show_bug.cgi?id=947344 I am doing the following changes: 1) Create all *.md5 files in /tmp/db Please use mkstemp or equivalent to create unique temp directory. OK, will use mktemp -d for that 2) Create db log files by default under /var/log/ovirt-engine/db Please allow to override log location and/or output logs to stdout. This will make it easier to run it within installer so that the log will be available at installer log. All scripts supports the -l LOGFILE flag 3) Do not automatically create a *.schema file that represent the up-to-date schema (after all upgrades took place) A new utility script exportDbSchema.sh will be available for that (manual only, no auto-generation schema) In order that DB scripts in development environment will keep working, please do sudo mkdir -p /var/log/ovirt-engine/db sudo chmod 777 /var/log/ovirt-engine/db 777 access permission is not something that should exist in system anywhere, well apart of /tmp and /tmp is marked using 't' attribute. Missed that in my prev reply anyway , do whatever is needed so that the user that access the scripts in dbscripts has r/w/ permisssions on /var/log/ovirt-engine/db since this is only for development, each developer will decide how to do that Regards, Alon ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Changes in DB scripts that need your attension
- Original Message - From: Eli Mesika emes...@redhat.com To: Alon Bar-Lev alo...@redhat.com Cc: engine-devel engine-devel@ovirt.org Sent: Thursday, April 18, 2013 12:53:11 PM Subject: Re: [Engine-devel] Changes in DB scripts that need your attension - Original Message - From: Eli Mesika emes...@redhat.com To: Alon Bar-Lev alo...@redhat.com Cc: engine-devel engine-devel@ovirt.org Sent: Thursday, April 18, 2013 12:44:06 PM Subject: Re: [Engine-devel] Changes in DB scripts that need your attension - Original Message - From: Alon Bar-Lev alo...@redhat.com To: Eli Mesika emes...@redhat.com Cc: engine-devel engine-devel@ovirt.org Sent: Thursday, April 18, 2013 12:26:44 PM Subject: Re: [Engine-devel] Changes in DB scripts that need your attension Hi, - Original Message - From: Eli Mesika emes...@redhat.com To: engine-devel engine-devel@ovirt.org Sent: Thursday, April 18, 2013 12:19:43 PM Subject: [Engine-devel] Changes in DB scripts that need your attension Hi As part of solving https://bugzilla.redhat.com/show_bug.cgi?id=947344 I am doing the following changes: 1) Create all *.md5 files in /tmp/db Please use mkstemp or equivalent to create unique temp directory. OK, will use mktemp -d for that 2) Create db log files by default under /var/log/ovirt-engine/db Please allow to override log location and/or output logs to stdout. This will make it easier to run it within installer so that the log will be available at installer log. All scripts supports the -l LOGFILE flag 3) Do not automatically create a *.schema file that represent the up-to-date schema (after all upgrades took place) A new utility script exportDbSchema.sh will be available for that (manual only, no auto-generation schema) In order that DB scripts in development environment will keep working, please do sudo mkdir -p /var/log/ovirt-engine/db sudo chmod 777 /var/log/ovirt-engine/db 777 access permission is not something that should exist in system anywhere, well apart of /tmp and /tmp is marked using 't' attribute. Missed that in my prev reply anyway , do whatever is needed so that the user that access the scripts in dbscripts has r/w/ permisssions on /var/log/ovirt-engine/db since this is only for development, each developer will decide how to do that OK... I will check this with the new development environment[1] [1] https://github.com/alonbl/ovirt-engine/blob/otopi/README.developer Regards, Alon ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] [oss-security] CVE-2012-XXYY Request -- google-authenticator: Information disclosure due insecure requirement on the secrets file
FYI On 04/18/2013 01:45 PM, Jan Lieskovsky wrote: Hello Kurt, Steve, Alexander, vendors, as noted in [1]: An information disclosure file was found in the way google-authenticator, a pluggable authentication module (PAM) which allows login using one-time passcodes conforming to the open standards developed by the Initiative for Open Authentication (OATH), performed management of its secret / state file in certain configurations. Due the lack of 'user=' option the secret file was previously required to be user-readable, allowing (in certain cases) a local attacker to obtain the (pre)shared client-to-authentication-server secret, possibly leading to victim's account impersonation. A different vulnerability than CVE-2013-0258. References: [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=666129 [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=666129#10 [3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=666129#20 [4] https://bugzilla.redhat.com/show_bug.cgi?id=953505 Relevant upstream patch: [5] https://code.google.com/p/google-authenticator/source/detail?r=c3414e9857ad64e52283f3266065ef3023fc69a8 @Alexander - since I am not sure I have described the attack vector above properly, please correct me if / where required. @Kurt * the CVE-2012- identifier should be allocated to this issue, since the security implications of this problem are for the first time mentioned here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=666129#10 (2012-09-22), * from what I have looked, there doesn't seem to be: http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=authenticator a CVE identifier allocated to this issue yet (as noted above CVE-2013-0258 from that list is different issue). = could you allocate one? Thank you Regards, Jan. -- Jan iankko Lieskovsky / Red Hat Security Response Team -- Michael Pasternak RedHat, ENG-Virtualization RD ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
[Engine-devel] Location of findbugs filter.xml file
Hi all, I sent a patch upstream to add findbugs filter that will filter out bug reports that we decided that are not bugs. We have a debate on whether to have the findbugs filter definition in the root pom.xml or to put it in the jenkins jobs repo and treat it as an external tool. I would like to hear opinions about what you think should be the proper location Thanks, Yair ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Location of findbugs filter.xml file
- Original Message - From: Yair Zaslavsky yzasl...@redhat.com To: engine-devel engine-devel@ovirt.org Sent: Thursday, April 18, 2013 4:55:46 PM Subject: [Engine-devel] Location of findbugs filter.xml file Hi all, I sent a patch upstream to add findbugs filter that will filter out bug reports that we decided that are not bugs. We have a debate on whether to have the findbugs filter definition in the root pom.xml or to put it in the jenkins jobs repo and treat it as an external tool. I would like to hear opinions about what you think should be the proper location Putting it in the root pom.xml file will allow running filtered findbugs using maven, without the need to use jenkins, so I'd go with that approach. Thanks, Yair ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Location of findbugs filter.xml file
- Original Message - From: Mike Kolesnik mkole...@redhat.com To: engine-devel engine-devel@ovirt.org Cc: Oved Ourfalli ov...@redhat.com Sent: Thursday, April 18, 2013 5:10:39 PM Subject: Re: [Engine-devel] Location of findbugs filter.xml file - Original Message - - Original Message - From: Yair Zaslavsky yzasl...@redhat.com To: engine-devel engine-devel@ovirt.org Sent: Thursday, April 18, 2013 4:55:46 PM Subject: [Engine-devel] Location of findbugs filter.xml file Hi all, I sent a patch upstream to add findbugs filter that will filter out bug reports that we decided that are not bugs. We have a debate on whether to have the findbugs filter definition in the root pom.xml or to put it in the jenkins jobs repo and treat it as an external tool. I would like to hear opinions about what you think should be the proper location Putting it in the root pom.xml file will allow running filtered findbugs using maven, without the need to use jenkins, so I'd go with that approach. +1 Even better than that - each module can override the configuration with its own exceptions in its own pom file Thanks, Yair ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] spice-xpi(firefox) plugin for Windows
Nicely done and this would definitely be useful. Nothing is more nauseating then being forced to use Internet Exploder to interact with an ovirt/KVM SPICE console under windows. For the plugin deployment this is definitely a point of pain. At the moment ovirt users wishing to use the SPICE Activex plugin must use an an dated version of the SPICE client packaged with the necessary SpiceX.dll. ( http://elmarco.fedorapeople.org/spice.cab) They must also take manual steps to install and deploy the plugin on ovirt-engine server (this very painful to users). The versions of the SPICE client also made available to the community here: http://spice-space.org/download/gtk/windows/ are also a bit dated and do not include the plugin (SpiceX.dll). Perhaps a plugin deployment page linked from the main ovirt landing page would be a prudent way to deploy the plugin? In any event a working SPICE Plugin for Firefox and newer SPICE Client version under windows would be a very welcome sight indeed. I think one of the most frequently asked questions or gripes I see about ovirt is around SPICE console issues and concerns. - DHC On Wed, Apr 17, 2013 at 7:45 AM, Christophe Fergeau cferg...@redhat.comwrote: Hi everyone, Lately I've been hacking on getting the spice-xpi plugin to work on Windows. This is the Firefox plugin that is used on Linux to implement the portal SPICE console. This work has now been merged upstream ( http://cgit.freedesktop.org/spice/spice-xpi/ ), and I've pushed a scratch build using mingw available from http://koji.fedoraproject.org/koji/taskinfo?taskID=5265107 (this will go away in several days). Copying this dll + its dependencies to the C:\Program Files\Mozilla Firefox\plugins directory are enough to get a spice-xpi plugin to show up in about:plugins, and to then be able to start a SPICE client from the spice-xpi test page ( http://teuf.fedorapeople.org/plugins/test.html ). The dependencies I had to copy are: gspawn-win32-helper-console.exe gspawn-win32-helper.exe iconv.dll libffi-6.dll libgcc_s_sjlj-1.dll libgio-2.0-0.dll libglib-2.0-0.dll libgmodule-2.0-0.dll libgobject-2.0-0.dll libgthread-2.0-0.dll libintl-8.dll libstdc++-6.dll pthreadGC2.dll zlib1.dll (I picked them from the various mingw-* fedora packages). The reason for this email is that to be usable from oVirt, some portal changes are needed as it currently only tries to use the spice-xpi plugin on Linux platforms. Another fuzzy bit is how to get this plugin to the users' machines... And that's about all I had to say in that email ;) Let me know if that's useful to oVirt, how you want to integrate this, ... Cheers, Christophe ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Location of findbugs filter.xml file
On 04/18/2013 04:58 PM, Oved Ourfalli wrote: - Original Message - From: Yair Zaslavsky yzasl...@redhat.com To: engine-devel engine-devel@ovirt.org Sent: Thursday, April 18, 2013 4:55:46 PM Subject: [Engine-devel] Location of findbugs filter.xml file Hi all, I sent a patch upstream to add findbugs filter that will filter out bug reports that we decided that are not bugs. We have a debate on whether to have the findbugs filter definition in the root pom.xml or to put it in the jenkins jobs repo and treat it as an external tool. I would like to hear opinions about what you think should be the proper location Putting it in the root pom.xml file will allow running filtered findbugs using maven, without the need to use jenkins, so I'd go with that approach. +1 Thanks, Yair ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel -- Michael Pasternak RedHat, ENG-Virtualization RD ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Changes in DB scripts that need your attension
- Original Message - From: Alon Bar-Lev alo...@redhat.com To: Eli Mesika emes...@redhat.com Cc: engine-devel engine-devel@ovirt.org Sent: Thursday, April 18, 2013 12:58:26 PM Subject: Re: [Engine-devel] Changes in DB scripts that need your attension - Original Message - From: Eli Mesika emes...@redhat.com To: Alon Bar-Lev alo...@redhat.com Cc: engine-devel engine-devel@ovirt.org Sent: Thursday, April 18, 2013 12:53:11 PM Subject: Re: [Engine-devel] Changes in DB scripts that need your attension - Original Message - From: Eli Mesika emes...@redhat.com To: Alon Bar-Lev alo...@redhat.com Cc: engine-devel engine-devel@ovirt.org Sent: Thursday, April 18, 2013 12:44:06 PM Subject: Re: [Engine-devel] Changes in DB scripts that need your attension - Original Message - From: Alon Bar-Lev alo...@redhat.com To: Eli Mesika emes...@redhat.com Cc: engine-devel engine-devel@ovirt.org Sent: Thursday, April 18, 2013 12:26:44 PM Subject: Re: [Engine-devel] Changes in DB scripts that need your attension Hi, - Original Message - From: Eli Mesika emes...@redhat.com To: engine-devel engine-devel@ovirt.org Sent: Thursday, April 18, 2013 12:19:43 PM Subject: [Engine-devel] Changes in DB scripts that need your attension Hi As part of solving https://bugzilla.redhat.com/show_bug.cgi?id=947344 I am doing the following changes: 1) Create all *.md5 files in /tmp/db Please use mkstemp or equivalent to create unique temp directory. OK, will use mktemp -d for that 2) Create db log files by default under /var/log/ovirt-engine/db Please allow to override log location and/or output logs to stdout. This will make it easier to run it within installer so that the log will be available at installer log. All scripts supports the -l LOGFILE flag 3) Do not automatically create a *.schema file that represent the up-to-date schema (after all upgrades took place) A new utility script exportDbSchema.sh will be available for that (manual only, no auto-generation schema) In order that DB scripts in development environment will keep working, please do sudo mkdir -p /var/log/ovirt-engine/db sudo chmod 777 /var/log/ovirt-engine/db 777 access permission is not something that should exist in system anywhere, well apart of /tmp and /tmp is marked using 't' attribute. Missed that in my prev reply anyway , do whatever is needed so that the user that access the scripts in dbscripts has r/w/ permisssions on /var/log/ovirt-engine/db since this is only for development, each developer will decide how to do that OK... I will check this with the new development environment[1] [1] https://github.com/alonbl/ovirt-engine/blob/otopi/README.developer Hi, Where can I find the patch? I cannot see this in gerrit nor reference in bug#947344 Alon ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
