Bug 1263602
Summary: | [RFE] Ability to set different mount options for hosted_engine nfs storage than the default | ||
---|---|---|---|
Product: | Red Hat Enterprise Virtualization Manager | Reporter: | Alexandros Gkesos <agkesos> |
Component: | RFEs | Assignee: | Simone Tiraboschi <stirabos> |
Status: | CLOSED ERRATA | QA Contact: | Nikolai Sednev <nsednev> |
Severity: | medium | Docs Contact: | |
Priority: | high | ||
Version: | 3.5.4 | CC: | achareka, apinnick, lsurette, mavital, nsoffer, ppostler, pstehlik, rbalakri, sasundar, sbonazzo, srevivo, stirabos, tnisan, trichard, ykaul, ylavi |
Target Milestone: | ovirt-4.2.1 | Keywords: | FutureFeature, Triaged |
Target Release: | --- | Flags: | lsvaty:
testing_plan_complete-
|
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Enhancement | |
Doc Text: |
Additional mount options for the self-hosted engine storage domain, such as NFS mount, are available in the Manager.
|
Story Points: | --- |
Clone Of: | Environment: | ||
Last Closed: | 2018-05-15 17:36:24 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | Integration | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | 1359265 | ||
Bug Blocks: |
Description
Alexandros Gkesos
2015-09-16 09:38:43 UTC
Simone, please create an upstream bug blocking this one for 4.1. Now in /etc/ovirt-hosted-engine/hosted-engine.conf we already have a mnt_options= line for this kind of options. It's already possible to pass a value for it via answerfile. We just have to let the user optionally customize that value from the text UI; the question is if we want also to parse/validate that options somehow. (In reply to Simone Tiraboschi from comment #8) > Now in /etc/ovirt-hosted-engine/hosted-engine.conf we already have a > mnt_options= line for this kind of options. > It's already possible to pass a value for it via answerfile. > We just have to let the user optionally customize that value from the text > UI; the question is if we want also to parse/validate that options somehow. How does that work with the shared conf and adding hosts via UI\API? Is this shared? Can you set it via UI? (In reply to Yaniv Dary from comment #9) > How does that work with the shared conf and adding hosts via UI\API? > Is this shared? Can you set it via UI? It should be part of the auto-import procedure: the auto-import procedure will import the hosted-engine storage domain with its mount options and it should also pass that value to host-deploy to write it in hosted-engine.conf on each host. Probably we miss the last step to close the gap. Roy? (In reply to Simone Tiraboschi from comment #10) > (In reply to Yaniv Dary from comment #9) > > How does that work with the shared conf and adding hosts via UI\API? > > Is this shared? Can you set it via UI? > > It should be part of the auto-import procedure: the auto-import procedure > will import the hosted-engine storage domain with its mount options and it > should also pass that value to host-deploy to write it in hosted-engine.conf > on each host. > > Probably we miss the last step to close the gap. Roy? The engine will pass whatever there in the hosted-engine.conf. So if that would be updated then for the HE hosts, we are covered. The problem is with non HE hosts which are connected from the backend to that storage domain, does it matter there even though those host will never read/write to that domain because the hosted engine vm will not run there? (and in 4.1 we will prevent creating other disks there) (In reply to Roy Golan from comment #11) > (In reply to Simone Tiraboschi from comment #10) > > (In reply to Yaniv Dary from comment #9) > > > How does that work with the shared conf and adding hosts via UI\API? > > > Is this shared? Can you set it via UI? > > > > It should be part of the auto-import procedure: the auto-import procedure > > will import the hosted-engine storage domain with its mount options and it > > should also pass that value to host-deploy to write it in hosted-engine.conf > > on each host. > > > > Probably we miss the last step to close the gap. Roy? > > The engine will pass whatever there in the hosted-engine.conf. > > So if that would be updated then for the HE hosts, we are covered. Yes, it's mnt_options under hosted-engine.conf But I see a possible race conditions here: if I correctly understood what you are saying, we are not fetching the mount options when we are importing the hosted-engine storage domain into the engine; the trick is just that ovirt-ha-agent will connect the storage domain before the engine, and so the engine connection (without the mnt_options) will be not effective since the hosted-engine storage domain is already connected. This will work for sure for the first host and for additional hosts deployed via CLI. I'm not really sure we will not have race conditions when we deploy an host from the engine since in this case the engine and ovirt-ha-agent are running independently and only the first one will mount. See: https://bugzilla.redhat.com/show_bug.cgi?id=1349532#c18 Then there is another possible issue: setting an host into maintenance mode from the engine will also disconnect the hosted-engine storage domain; the agent will try to consume it every 35 second and if not available it will reconnect. If the user exits maintenance mode before that, the engine could reconnect before the agent loosing mnt_options. see https://bugzilla.redhat.com/show_bug.cgi?id=1353608#c5 > The problem is with non HE hosts which are connected from the backend to > that storage domain, does it matter there even though those host will never > read/write to that domain because the hosted engine vm will not run there? > (and in 4.1 we will prevent creating other disks there) In general I think that correctly importing it with the right mnt_options will be a safer design. The auto-import doesn't have the mnt options in the context and we can't pull the hosted-engine.conf disk at that point. We need vdsm to expose those mount options it possible and that would be the best. Using the hosted-engine.conf should be used by the ha-agent. Allon, exposing mount options on getStorageDomainInfo is on your plan? if not can we consider it for hosted engine? (In reply to Roy Golan from comment #14) > The auto-import doesn't have the mnt options in the context and we can't > pull the hosted-engine.conf disk at that point. We need vdsm to expose those > mount options it possible and that would be the best. Using the > hosted-engine.conf should be used by the ha-agent. > > Allon, exposing mount options on getStorageDomainInfo is on your plan? if > not can we consider it for hosted engine? My instinctive answer would be to say no, as domains are logical entities and the mount options are StorageConnection details. BUT... I see it does return the remove path for some reason, so it makes me rethink things. Nir - your two cents? (In reply to Allon Mureinik from comment #15) > (In reply to Roy Golan from comment #14) > > The auto-import doesn't have the mnt options in the context and we can't > > pull the hosted-engine.conf disk at that point. We need vdsm to expose those > > mount options it possible and that would be the best. Using the > > hosted-engine.conf should be used by the ha-agent. > > > > Allon, exposing mount options on getStorageDomainInfo is on your plan? if > > not can we consider it for hosted engine? > > My instinctive answer would be to say no, as domains are logical entities > and the mount options are StorageConnection details. > BUT... I see it does return the remove path for some reason, so it makes me > rethink things. > > Nir - your two cents? I don't see a reason to hide the mount options, and it can be useful also for DR. The information is available in /proc/mounts and can be easily exposed in vdsm apis as file storage domain specific info. Should I open a bug against VDSM for that? (In reply to Roy Golan from comment #17) > Should I open a bug against VDSM for that? Seems like a good idea for tracking this. (In reply to Roy Golan from comment #17) > Should I open a bug against VDSM for that? Yes please. Roy, please open it and reference it here. Simone, may you kindly provide more info regarding reproduction steps, what was the solution exactly (to get additional nfs opions within the otopi during deployment, or to fetch these using /etc/ovirt-hosted-engine/hosted-engine.conf)? Is there any documentation covering this new capability? You have to see a question like this: 'If needed, specify additional mount options for the connection to the hosted-engine storage domain' and you can enter additional mount options there. The options added by the user should be saved under mnt_options field in /etc/ovirt-hosted-engine/hosted-engine.conf on the host itself and also on additional hosts. The engine should care them as well importing the hosted-engine storage domain (you could see them trying editing the storage domain) and they should be effective on all the hosts of the storage pool (check the result of mount command on all the hosts). Mount options should also be tried checking the NFS mount at customization stage. If the mount fails hosted-engine-setup should report and ask again. So please try also negative flow with dumb options. (In reply to Alexandros Gkesos from comment #0) > 8. Does the customer have any specific timeline dependencies and which > release would they like to target > > - RHEL6 + RHEL7 This bug is targeted to 4.2 which covers only RHEL 7. (In reply to Simone Tiraboschi from comment #24) > You have to see a question like this: 'If needed, specify additional mount > options for the connection to the hosted-engine storage domain' > and you can enter additional mount options there. > > The options added by the user should be saved under mnt_options field in > /etc/ovirt-hosted-engine/hosted-engine.conf on the host itself and also on > additional hosts. > > The engine should care them as well importing the hosted-engine storage > domain (you could see them trying editing the storage domain) and they > should be effective on all the hosts of the storage pool (check the result > of mount command on all the hosts). > > Mount options should also be tried checking the NFS mount at customization > stage. > If the mount fails hosted-engine-setup should report and ask again. > So please try also negative flow with dumb options. During latest deployment Today, I didn't seen expected message, e.g. "If needed, specify additional mount options for the connection to the hosted-engine storage domain". Tested on these components: ovirt-hosted-engine-setup-2.2.0-0.0.master.20171110120732.git35143a6.el7.centos.noarch See deployment flow here: http://pastebin.test.redhat.com/531649 Moving back to assigned. (In reply to Nikolai Sednev from comment #26) > Moving back to assigned. Yes, sorry, fault of mine: https://github.com/oVirt/ovirt-hosted-engine-setup/blob/master/src/plugins/gr-he-setup/storage/nfs.py#L55 We blocked it on hosted-engine-setup side till https://bugzilla.redhat.com/show_bug.cgi?id=1359265 get correctly fixed on engine-side I understand from Yaniv lavi that POSIX domain can be used for setting custom properties here. (In reply to Sandro Bonazzola from comment #28) > I understand from Yaniv lavi that POSIX domain can be used for setting > custom properties here. Both NFS and POSIX support custom mount options from engine/vdsm side. If there's something missing on HE setup's side, we should fix it. In any event, we should not use POSIX type for NFS domains (even though it should work) - there are several optimizations and special treatments for NFS The documentation text flag should only be set after 'doc text' field is provided. Please provide the documentation text and set the flag to '?' again. During latest deployment Today, I didn't seen expected message, e.g. "If needed, specify additional mount options for the connection to the hosted-engine storage domain". Tested on these components: ovirt-hosted-engine-setup-2.2.0-0.0.master.20171127213100.git92f0f9a.el7.centos.noarch ovirt-hosted-engine-ha-2.2.0-0.0.master.20171122155227.20171122155225.gitbc3ec09.el7.centos.noarch See deployment flow here: http://pastebin.test.redhat.com/536131 Moving back to assigned. We have two distinct flows here: a. in the old hosted-engine flow, ovirt-hosted-engine-setup directly creates the storage domain trough vdsm. We are not asking about custom mount_options there since vdsm will not report them back to the engine and so they will be absolutely ignored by the engine at auto import time. See: https://bugzilla.redhat.com/1359265 b. in the new ansible based flow (Node 0) instead, ovirt-hosted-engine-setup will create the NFS storage domain trough the engine running on the local VM and so all the custom mount options will be in the DB by design. In this case ovirt-hosted-engine-setup is asking about custom mount option since we know that they reach the engine. Fixed on node zero Moving to verified forth to https://bugzilla.redhat.com/show_bug.cgi?id=1359265#c25. Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHEA-2018:1488 BZ<2>Jira Resync |