Re: [Engine-devel] Change in ovirt-engine[master]: core: enable to decrease DC compatibility...
- Original Message - > From: "Livnat Peer" > To: "Moti Asayag" > Cc: "Itamar Heim" , engine-devel@ovirt.org > Sent: Wednesday, March 12, 2014 10:33:45 PM > Subject: Re: [Engine-devel] Change in ovirt-engine[master]: core: enable to > decrease DC compatibility... > > On 03/12/2014 10:20 PM, Moti Asayag wrote: > > > > > > - Original Message - > >> From: "Livnat Peer" > >> To: "Itamar Heim" , engine-devel@ovirt.org > >> Sent: Wednesday, March 12, 2014 12:42:44 PM > >> Subject: Re: [Engine-devel] Change in ovirt-engine[master]: core: enable > >> to decrease DC compatibility... > >> > >> On 03/12/2014 11:59 AM, Itamar Heim wrote: > >>> On 03/12/2014 12:26 AM, emes...@redhat.com wrote: > Eli Mesika has submitted this change and it was merged. > > Change subject: core: enable to decrease DC compatibility... > .. > > > core: enable to decrease DC compatibility... > > enable to decrease DC compatibility version if DC has no clusters > > This patch enables to decrease the DC compatibility version if DC has no > clusters. > >>> > >>> Eli - just saw this. I'm pretty sure it would be *bad* to downgrade a DC > >>> version if it has storage domains as well. not sure if this is checked > >>> already or not. > >>> > >>> may also be an issue with some logical network features. > >>> > >> > >> Most of the network features are driven from cluster level, we enable > >> using the features on all DC level (actually >=3.1) but actually enable > >> /disable the feature when attaching the network to a cluster. > >> > >> So from network perspective I think it should be fine to downgrade the > >> DC level even if there are networks in the DC (at least now this could > >> change in future versions). > >> > > > > Actually we block adding or updating networks if the feature is not > > supported > > on the network's DC level, for example: STP, Jumbo frames and non-vm > > network. > > > > From which DC level we support STP? Jumbo frames? non-vm network? isn't > all of them supported in >=3.1 ? > Yes, mainly the problem with downgrading a DC to 3.0. > > Therefore if the management network was configured with any of those > > feature, > > there is a need to either block the action or to 'initialize' the network > > to > > the default settings (as new network being added). > > > >> In general I believe the use case for this patch is mostly for empty DCs > >> so for simplicity we should block it if there are networks or SD in the > >> DC when downgrading. > >> > >> Livnat > >> > >> > > Change-Id: I73284f641b7f80b380b39efbbd7b4566f55119b6 > Bug-Url: https://bugzilla.redhat.com/show_bug.cgi?id=1057029 > Signed-off-by: Eli Mesika > --- > M > backend/manager/modules/bll/src/main/java/org/ovirt/engine/core/bll/storage/UpdateStoragePoolCommand.java > > 1 file changed, 5 insertions(+), 2 deletions(-) > > Approvals: > Eli Mesika: Verified > Ravi Nori: Looks good to me, but someone else must approve > Yair Zaslavsky: Looks good to me, approved > > > > >>> > >> > >> ___ > >> 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] Change in ovirt-engine[master]: core: enable to decrease DC compatibility...
On 03/12/2014 10:20 PM, Moti Asayag wrote: > > > - Original Message - >> From: "Livnat Peer" >> To: "Itamar Heim" , engine-devel@ovirt.org >> Sent: Wednesday, March 12, 2014 12:42:44 PM >> Subject: Re: [Engine-devel] Change in ovirt-engine[master]: core: enable to >> decrease DC compatibility... >> >> On 03/12/2014 11:59 AM, Itamar Heim wrote: >>> On 03/12/2014 12:26 AM, emes...@redhat.com wrote: Eli Mesika has submitted this change and it was merged. Change subject: core: enable to decrease DC compatibility... .. core: enable to decrease DC compatibility... enable to decrease DC compatibility version if DC has no clusters This patch enables to decrease the DC compatibility version if DC has no clusters. >>> >>> Eli - just saw this. I'm pretty sure it would be *bad* to downgrade a DC >>> version if it has storage domains as well. not sure if this is checked >>> already or not. >>> >>> may also be an issue with some logical network features. >>> >> >> Most of the network features are driven from cluster level, we enable >> using the features on all DC level (actually >=3.1) but actually enable >> /disable the feature when attaching the network to a cluster. >> >> So from network perspective I think it should be fine to downgrade the >> DC level even if there are networks in the DC (at least now this could >> change in future versions). >> > > Actually we block adding or updating networks if the feature is not supported > on the network's DC level, for example: STP, Jumbo frames and non-vm network. > >From which DC level we support STP? Jumbo frames? non-vm network? isn't all of them supported in >=3.1 ? > Therefore if the management network was configured with any of those feature, > there is a need to either block the action or to 'initialize' the network to > the default settings (as new network being added). > >> In general I believe the use case for this patch is mostly for empty DCs >> so for simplicity we should block it if there are networks or SD in the >> DC when downgrading. >> >> Livnat >> >> Change-Id: I73284f641b7f80b380b39efbbd7b4566f55119b6 Bug-Url: https://bugzilla.redhat.com/show_bug.cgi?id=1057029 Signed-off-by: Eli Mesika --- M backend/manager/modules/bll/src/main/java/org/ovirt/engine/core/bll/storage/UpdateStoragePoolCommand.java 1 file changed, 5 insertions(+), 2 deletions(-) Approvals: Eli Mesika: Verified Ravi Nori: Looks good to me, but someone else must approve Yair Zaslavsky: Looks good to me, approved >>> >> >> ___ >> 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] Dependency checking tool
- Original Message - > From: "Rohit Agrawal" > To: engine-devel@ovirt.org > Sent: Wednesday, March 12, 2014 3:49:01 PM > Subject: [Engine-devel] Dependency checking tool > > hi, > i am now trying to make some changes in ovirt engine code for which i neede > to see the dependency. > As there are many pom.xml files. Is there any dependency tool to see all the > dependency. > If you're using eclipe - with the m2e (maven eclipse integration) plugin, you can click on the pom.xml and view the specific project dependencies and their hierarchies. Intellij should have also dependency viewer (haven't tried it though). > -- > Regards, > rohit > > ___ > 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] Change in ovirt-engine[master]: core: enable to decrease DC compatibility...
- Original Message - > From: "Livnat Peer" > To: "Itamar Heim" , engine-devel@ovirt.org > Sent: Wednesday, March 12, 2014 12:42:44 PM > Subject: Re: [Engine-devel] Change in ovirt-engine[master]: core: enable to > decrease DC compatibility... > > On 03/12/2014 11:59 AM, Itamar Heim wrote: > > On 03/12/2014 12:26 AM, emes...@redhat.com wrote: > >> Eli Mesika has submitted this change and it was merged. > >> > >> Change subject: core: enable to decrease DC compatibility... > >> .. > >> > >> > >> core: enable to decrease DC compatibility... > >> > >> enable to decrease DC compatibility version if DC has no clusters > >> > >> This patch enables to decrease the DC compatibility version if DC has no > >> clusters. > > > > Eli - just saw this. I'm pretty sure it would be *bad* to downgrade a DC > > version if it has storage domains as well. not sure if this is checked > > already or not. > > > > may also be an issue with some logical network features. > > > > Most of the network features are driven from cluster level, we enable > using the features on all DC level (actually >=3.1) but actually enable > /disable the feature when attaching the network to a cluster. > > So from network perspective I think it should be fine to downgrade the > DC level even if there are networks in the DC (at least now this could > change in future versions). > Actually we block adding or updating networks if the feature is not supported on the network's DC level, for example: STP, Jumbo frames and non-vm network. Therefore if the management network was configured with any of those feature, there is a need to either block the action or to 'initialize' the network to the default settings (as new network being added). > In general I believe the use case for this patch is mostly for empty DCs > so for simplicity we should block it if there are networks or SD in the > DC when downgrading. > > Livnat > > > >> > >> Change-Id: I73284f641b7f80b380b39efbbd7b4566f55119b6 > >> Bug-Url: https://bugzilla.redhat.com/show_bug.cgi?id=1057029 > >> Signed-off-by: Eli Mesika > >> --- > >> M > >> backend/manager/modules/bll/src/main/java/org/ovirt/engine/core/bll/storage/UpdateStoragePoolCommand.java > >> > >> 1 file changed, 5 insertions(+), 2 deletions(-) > >> > >> Approvals: > >>Eli Mesika: Verified > >>Ravi Nori: Looks good to me, but someone else must approve > >>Yair Zaslavsky: Looks good to me, approved > >> > >> > >> > > > > ___ > 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] Dependency checking tool
mvn dependency:tree Greg - Original Message - > From: "Rohit Agrawal" > To: engine-devel@ovirt.org > Sent: Wednesday, March 12, 2014 9:49:01 AM > Subject: [Engine-devel] Dependency checking tool > hi, > i am now trying to make some changes in ovirt engine code for which i neede > to see the dependency. > As there are many pom.xml files. Is there any dependency tool to see all the > dependency. > -- > Regards, > rohit > ___ > 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] Dependency checking tool
Rohit, You can run mvn dependency:tree -Dverbose To see the entire dependency tree. On Wednesday, March 12, 2014 07:19:01 PM Rohit Agrawal wrote: > hi, > i am now trying to make some changes in ovirt engine code for which i neede > to see the dependency. > As there are many pom.xml files. Is there any dependency tool to see all > the dependency. ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
[Engine-devel] Dependency checking tool
hi, i am now trying to make some changes in ovirt engine code for which i neede to see the dependency. As there are many pom.xml files. Is there any dependency tool to see all the dependency. -- Regards, rohit ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Small suggestions for engine-log-collector
On 03/12/2014 07:05 AM, Vojtech Szocs wrote: - Original Message - From: "Keith Robertson" To: "Vojtech Szocs" Cc: "engine-devel" , "Einav Cohen" , "Sandro Bonazzola" Sent: Tuesday, March 11, 2014 7:13:08 PM Subject: Re: Small suggestions for engine-log-collector - Original Message - From: "Vojtech Szocs" To: "engine-devel" Cc: "Keith Robertson" , "Einav Cohen" Sent: Tuesday, March 11, 2014 1:57:11 PM Subject: Small suggestions for engine-log-collector Hi guys, based on my testing during last week's oVirt 3.4 RC test day [1], I have a couple of small suggestions for engine-log-collector: 1, in /etc/ovirt-engine/logcollector.conf - I think there's typo: #key-file=/etc/pki/engine/keys/engine_id_rsa should be: #key-file=/etc/pki/ovirt-engine/keys/engine_id_rsa ACK http://gerrit.ovirt.org/#/c/25653/ 2, to force password-based ssh auth, one has to do this: In the normal scenario, the the ovirt user's public key should be installed into each hypervisor. Unless something has changed as a part of the hypervisor registration process this should be something that we can depend upon. My host was F19 VM added to oVirt Engine via WebAdmin GUI. I thought that host deploy script should do the public key registration, though. I'm pretty sure that public key registration used to be part of the deploy script. If this is no longer the case it is a fairly major supportability issue. Clearly, there are edge cases where you need to collect logs from a hypervisor that isn't properly registered with the RHEV-M. Was this your situation and how common do you think this scenario is? It was either a misconfiguration on my part or that I skipped some step with regard to public key registration. Understand. The reason why we bias the LC towards public key auth and fall back to PW auth is that the LC needs to make multiple calls[1] to each Hypervisor and, if you're not using public key auth it is definitely a sub-optimal usage experience. Multiply [1] times the N number of hyper-visors and the user's annoyance factor will surely reach a boiling point. ;) [1] - 1 ssh call to launch sos - 1 sftp call to get the report and remove it from /tmp engine-log-collector -k "" Yes, you are nulling out the default value which causes the LC to prompt you for a PW. Perhaps we should document this as opposed to supplying a specific option? Sandro? Well, the doc text says "If a identity file is not supplied..." which I understood as not supplying option value (i.e. "") at all, but this was just my understanding. Your understanding is correct and you forced the tool not to find the default identity file with a clever null argument. There's nothing wrong with this usage per-se and maybe we should either document it or provide an explicit option to force PW auth. because running this: engine-log-collector -k returns error message: error: -k option requires an argument however, help for -k option mentions *supplying* the argument: If a identity file is not supplied the program will prompt for a password. so either the help text should mention empty string, or -k option should allow missing argument (this was my initial understanding according to help text) Since these are just small things, I'm wondering if I should create RFE or if Keith/others can say if they are relevant. Thanks, Vojtech [1] http://etherpad.ovirt.org/p/3.4-testday-3 -- Keith Robertson Supervisor, Software Engineering Red Hat Subscription Engineering ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Change in ovirt-engine[master]: core: enable to decrease DC compatibility...
On 03/12/2014 12:47 PM, Itamar Heim wrote: > On 03/12/2014 12:42 PM, Livnat Peer wrote: >> In general I believe the use case for this patch is mostly for empty DCs >> so for simplicity we should block it if there are networks or SD in the >> DC when downgrading. > > other than ovirt/rhevm one of course. of course, the management network which is automatically created when creating the DC can be there. > ___ > 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] REST API - where did bookmarks go?
- Original Message - > From: "Juan Hernandez" > To: "Vojtech Szocs" , "engine-devel" > > Cc: "Einav Cohen" > Sent: Tuesday, March 11, 2014 7:22:35 PM > Subject: Re: REST API - where did bookmarks go? > > On 03/11/2014 07:15 PM, Vojtech Szocs wrote: > > Hi guys, > > > > as part of prototyping new JavaScript binding for oVirt REST API, > > we chose a couple of business entities (resources) to experiment > > with. > > > > I just realized that requesting /ovirt-engine/api doesn't return > > any information about bookmarks. Where did bookmarks go? Is it > > possible to manage bookmarks through REST API? > > > > Note: WebAdmin currently gets bookmarks through GWT RPC by calling > > GetAllBookmarksQuery. Bookmark seems like proper backend business > > entity (with DAO and everything) so it should be exposed also via > > REST API.. or am I missing something? > > > > Thanks, > > Vojtech > > > > The didn't go anywhere, just never existed in the API. Please open a RFE > to add them. Thanks, Juan. The RFE is here: https://bugzilla.redhat.com/1075556 > > -- > Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta > 3ºD, 28016 Madrid, Spain > Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat S.L. > ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Small suggestions for engine-log-collector
- Original Message - > From: "Keith Robertson" > To: "Vojtech Szocs" > Cc: "engine-devel" , "Einav Cohen" > , "Sandro Bonazzola" > > Sent: Tuesday, March 11, 2014 7:13:08 PM > Subject: Re: Small suggestions for engine-log-collector > > > > - Original Message - > > From: "Vojtech Szocs" > > To: "engine-devel" > > Cc: "Keith Robertson" , "Einav Cohen" > > > > Sent: Tuesday, March 11, 2014 1:57:11 PM > > Subject: Small suggestions for engine-log-collector > > > > Hi guys, > > > > based on my testing during last week's oVirt 3.4 RC test day [1], > > I have a couple of small suggestions for engine-log-collector: > > > > 1, in /etc/ovirt-engine/logcollector.conf - I think there's typo: > > > > #key-file=/etc/pki/engine/keys/engine_id_rsa > > > >should be: > > > > #key-file=/etc/pki/ovirt-engine/keys/engine_id_rsa > > > > ACK http://gerrit.ovirt.org/#/c/25653/ > > > > 2, to force password-based ssh auth, one has to do this: > > > > In the normal scenario, the the ovirt user's public key should be installed > into each hypervisor. Unless something has changed as a part of the > hypervisor registration process this should be something that we can depend > upon. My host was F19 VM added to oVirt Engine via WebAdmin GUI. I thought that host deploy script should do the public key registration, though. > > Clearly, there are edge cases where you need to collect logs from a > hypervisor that isn't properly registered with the RHEV-M. Was this your > situation and how common do you think this scenario is? It was either a misconfiguration on my part or that I skipped some step with regard to public key registration. > > > engine-log-collector -k "" > > > > Yes, you are nulling out the default value which causes the LC to prompt you > for a PW. Perhaps we should document this as opposed to supplying a > specific option? Sandro? Well, the doc text says "If a identity file is not supplied..." which I understood as not supplying option value (i.e. "") at all, but this was just my understanding. > > >because running this: > > > > engine-log-collector -k > > > >returns error message: > > > > error: -k option requires an argument > > > >however, help for -k option mentions *supplying* the argument: > > > > If a identity file is not supplied the program will prompt for a > > password. > > > >so either the help text should mention empty string, > >or -k option should allow missing argument (this was > >my initial understanding according to help text) > > > > Since these are just small things, I'm wondering if I should > > create RFE or if Keith/others can say if they are relevant. > > > > Thanks, > > Vojtech > > > > [1] http://etherpad.ovirt.org/p/3.4-testday-3 > > > ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Change in ovirt-engine[master]: core: enable to decrease DC compatibility...
On 03/12/2014 12:42 PM, Livnat Peer wrote: In general I believe the use case for this patch is mostly for empty DCs so for simplicity we should block it if there are networks or SD in the DC when downgrading. other than ovirt/rhevm one of course. ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Change in ovirt-engine[master]: core: enable to decrease DC compatibility...
On 03/12/2014 11:59 AM, Itamar Heim wrote: > On 03/12/2014 12:26 AM, emes...@redhat.com wrote: >> Eli Mesika has submitted this change and it was merged. >> >> Change subject: core: enable to decrease DC compatibility... >> .. >> >> >> core: enable to decrease DC compatibility... >> >> enable to decrease DC compatibility version if DC has no clusters >> >> This patch enables to decrease the DC compatibility version if DC has no >> clusters. > > Eli - just saw this. I'm pretty sure it would be *bad* to downgrade a DC > version if it has storage domains as well. not sure if this is checked > already or not. > > may also be an issue with some logical network features. > Most of the network features are driven from cluster level, we enable using the features on all DC level (actually >=3.1) but actually enable /disable the feature when attaching the network to a cluster. So from network perspective I think it should be fine to downgrade the DC level even if there are networks in the DC (at least now this could change in future versions). In general I believe the use case for this patch is mostly for empty DCs so for simplicity we should block it if there are networks or SD in the DC when downgrading. Livnat >> >> Change-Id: I73284f641b7f80b380b39efbbd7b4566f55119b6 >> Bug-Url: https://bugzilla.redhat.com/show_bug.cgi?id=1057029 >> Signed-off-by: Eli Mesika >> --- >> M >> backend/manager/modules/bll/src/main/java/org/ovirt/engine/core/bll/storage/UpdateStoragePoolCommand.java >> >> 1 file changed, 5 insertions(+), 2 deletions(-) >> >> Approvals: >>Eli Mesika: Verified >>Ravi Nori: Looks good to me, but someone else must approve >>Yair Zaslavsky: Looks good to me, approved >> >> >> > ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Change in ovirt-engine[master]: core: enable to decrease DC compatibility...
- Original Message - > From: "Itamar Heim" > To: engine-devel@ovirt.org > Cc: "Eli Mesika" , "Federico Simoncelli" > , "Allon Mureinik" > , "Livnat Peer" > Sent: Wednesday, March 12, 2014 11:59:16 AM > Subject: Re: Change in ovirt-engine[master]: core: enable to decrease DC > compatibility... > > On 03/12/2014 12:26 AM, emes...@redhat.com wrote: > > Eli Mesika has submitted this change and it was merged. > > > > Change subject: core: enable to decrease DC compatibility... > > .. > > > > > > core: enable to decrease DC compatibility... > > > > enable to decrease DC compatibility version if DC has no clusters > > > > This patch enables to decrease the DC compatibility version if DC has no > > clusters. > > Eli - just saw this. I'm pretty sure it would be *bad* to downgrade a DC > version if it has storage domains as well. not sure if this is checked > already or not. > > may also be an issue with some logical network features. Downgrading a DC from storage perspective is problematic (domain version, storage pool metadata removal, etc). This should be blocked. -- Federico ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Change in ovirt-engine[master]: core: enable to decrease DC compatibility...
On 03/12/2014 12:26 AM, emes...@redhat.com wrote: Eli Mesika has submitted this change and it was merged. Change subject: core: enable to decrease DC compatibility... .. core: enable to decrease DC compatibility... enable to decrease DC compatibility version if DC has no clusters This patch enables to decrease the DC compatibility version if DC has no clusters. Eli - just saw this. I'm pretty sure it would be *bad* to downgrade a DC version if it has storage domains as well. not sure if this is checked already or not. may also be an issue with some logical network features. Change-Id: I73284f641b7f80b380b39efbbd7b4566f55119b6 Bug-Url: https://bugzilla.redhat.com/show_bug.cgi?id=1057029 Signed-off-by: Eli Mesika --- M backend/manager/modules/bll/src/main/java/org/ovirt/engine/core/bll/storage/UpdateStoragePoolCommand.java 1 file changed, 5 insertions(+), 2 deletions(-) Approvals: Eli Mesika: Verified Ravi Nori: Looks good to me, but someone else must approve Yair Zaslavsky: Looks good to me, approved ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
