Bug 1018973 - Changes to the libvirt network type do not save
Changes to the libvirt network type do not save
Status: CLOSED CURRENTRELEASE
Product: Red Hat Satellite 6
Classification: Red Hat
Component: Provisioning (Show other bugs)
6.0.2
Unspecified Unspecified
unspecified Severity medium (vote)
: Unspecified
: --
Assigned To: Lukas Zapletal
Sachin Ghai
: Triaged
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-10-14 16:03 EDT by Sam Kottler
Modified: 2014-07-02 10:05 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-07-02 10:05:29 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
greyout form on editing an existing host (29.99 KB, image/png)
2014-05-27 02:26 EDT, Sachin Ghai
no flags Details

  None (edit)
Description Sam Kottler 2013-10-14 16:03:16 EDT
Description of problem:
Changing network type and then saving the form will not work. For example, if I change the network to be NAT'ed and save the form, it will still show as bridged the next time I load the edit page.
Comment 1 RHEL Product and Program Management 2013-10-14 21:33:05 EDT
Since this issue was entered in Red Hat Bugzilla, the release flag has been
set to ? to ensure that it is properly evaluated for this release.
Comment 3 Ohad Levy 2013-10-15 02:00:25 EDT
does it mean we incorrectly save the vm or just display it incorrectly?
Comment 4 Dominic Cleal 2013-10-15 04:51:01 EDT
Editing a VM, or creating a new one?
Comment 5 Lukas Zapletal 2013-10-16 07:21:09 EDT
Finally looking into this, my dev setup was broken due to other small bugs (fixed now).
Comment 6 Sam Kottler 2013-10-16 08:14:57 EDT
This occurs when editing a VM or creating a new one. It looks like the first network type gets chosen when saving and then you can't edit. On the installation I'm looking at the issue is not only aesthetic - the change actually doesn't get saved with libvirt.
Comment 7 Dominic Cleal 2013-10-16 08:22:00 EDT
Yeah, not being able to edit VM properties is quite common for Foreman CRs.  Ideally we can fix the retrieval, but if we can't edit reliably then the dropdown could be locked (like Martin did the other day for VMware).
Comment 8 Sam Kottler 2013-10-16 08:33:00 EDT
This occurs on a local libvirt connection, too. The installation consistently doesn't save the changes so I doubt it's just a connectivity problem over the wire.
Comment 9 Lukas Zapletal 2013-10-16 10:52:10 EDT
I just reproduced on a new host entry, I never powered the host up. Digging into.
Comment 10 Lukas Zapletal 2013-10-17 05:47:00 EDT
Okay, libvirtd should support editing (since virt-manager can apparently edit stuff), but fog library, which is used by Foreman, does not. We can do the upstream work to support it, but I don't believe we will manage to get the fog patch for MDP2.

For this reason I also recommend to implement "UI greying" for those compute resources who does not support editing. That is: all except ovirt right now.
Comment 11 Lukas Zapletal 2013-10-17 06:30:36 EDT
Speaking about new VM libvirt, I am not able to reproduce. I can select and create all combinations of bridge and nat, it just save for me. Can you retest and before that restart libvirtd? Haven't you been editing networks previously via virsh or virt-manager there?
Comment 12 Lukas Zapletal 2013-10-17 07:56:28 EDT
I have implemented greying upstream: http://projects.theforeman.org/issues/3338
Comment 13 Dominic Cleal 2013-10-17 08:01:50 EDT
(In reply to Lukas Zapletal from comment #12)
> I have implemented greying upstream:
> http://projects.theforeman.org/issues/3338

There's already a redmine ticket associated with this BZ, close one as a dupe?
Comment 14 Lukas Zapletal 2013-10-17 10:56:47 EDT
Oh sorry missed that. Closing #3286, thanks.
Comment 15 Lukas Zapletal 2013-10-21 09:34:20 EDT
Just to make sure, Sam, I was unable to reproduce when I was creating NEW host. I checked with Todd and he confirmed me it was happening only for existing hosts. So once the upstream is closed we can close this one.
Comment 17 Dominic Cleal 2014-01-27 09:58:58 EST
Fixed in f9a773198bb569d67b1fff0a90f4412276d33122.
Comment 19 Sachin Ghai 2014-05-27 02:24:22 EDT
Verified with sat6 beta snap6..(Satellite-6.0.3-RHEL-6-20140523.0).

I'm not sure the exact steps to verify this bz, but from the description of the bug it seems that on saving form, the selected 'network' type'  was not retained.

So to reproduce this, I created a new host and I got two network types:
1. Pysical(Bridge)
2. Virtual(NAT)

I selected the Virtual(NAT) and on saving form the selected network type i.e. Virtual(NAT) retained.

Later, when I edited the existing host, the form was grayed out and I couldn't change any thing. As per changes in comment12, it seems its working as expected.

@Lukas: Please confirm if I correctly verified this bz.
Comment 20 Sachin Ghai 2014-05-27 02:26:01 EDT
Created attachment 899391 [details]
greyout form on editing an existing host
Comment 21 Lukas Zapletal 2014-05-28 05:15:09 EDT
Yes this is correct behavior right now, unfortunately any better solution is too much work.
Comment 22 Sachin Ghai 2014-05-28 05:17:18 EDT
As per comment 19 and 21.. moving this bz to verified.
Comment 23 Lukas Zapletal 2014-05-30 02:38:13 EDT
That's the only way we can do with the current fog library. I can confirm.
Comment 24 Bryan Kearney 2014-06-03 10:44:13 EDT
Upstream bug http://projects.theforeman.org/issues/3286 is rejected, and this is verified. I am removing the url.
Comment 26 Bryan Kearney 2014-07-02 10:05:29 EDT
This was delivered with 6.0.3, which is the Satellite 6 Beta.

Note You need to log in before you can comment on or make changes to this bug.