Bug 1018973

Summary:

Changes to the libvirt network type do not save

Product:

Red Hat Satellite

Reporter:

Sam Kottler <skottler>

Component:

Provisioning

Assignee:

Lukas Zapletal <lzap>

Status:

CLOSED CURRENTRELEASE

QA Contact:

Sachin Ghai <sghai>

Severity:

medium

Docs Contact:

Priority:

unspecified

Version:

6.0.2

CC:

bkearney, dcleal, lzap, ohadlevy, sghai

Target Milestone:

Unspecified

Keywords:

Triaged

Target Release:

Unused

Hardware:

Unspecified

OS:

Unspecified

Whiteboard:

Fixed In Version:

Doc Type:

Bug Fix

Doc Text:

Story Points:

---

Clone Of:

Environment:

Last Closed:

2014-07-02 14:05:29 UTC

Type:

Bug

Regression:

---

Mount Type:

---

Documentation:

---

CRM:

Verified Versions:

Category:

---

oVirt Team:

---

RHEL 7.3 requirements from Atomic Host:

Cloudforms Team:

---

Target Upstream Version:

Embargoed:

Attachments:

Description	Flags
greyout form on editing an existing host	none

Description Sam Kottler 2013-10-14 20:03:16 UTC

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 Program Management 2013-10-15 01:33:05 UTC

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 06:00:25 UTC

does it mean we incorrectly save the vm or just display it incorrectly?

Comment 4 Dominic Cleal 2013-10-15 08:51:01 UTC

Editing a VM, or creating a new one?

Comment 5 Lukas Zapletal 2013-10-16 11:21:09 UTC

Finally looking into this, my dev setup was broken due to other small bugs (fixed now).

Comment 6 Sam Kottler 2013-10-16 12:14:57 UTC

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 12:22:00 UTC

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 12:33:00 UTC

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 14:52:10 UTC

I just reproduced on a new host entry, I never powered the host up. Digging into.

Comment 10 Lukas Zapletal 2013-10-17 09:47:00 UTC

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 10:30:36 UTC

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 11:56:28 UTC

I have implemented greying upstream: http://projects.theforeman.org/issues/3338

Comment 13 Dominic Cleal 2013-10-17 12:01:50 UTC

(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 14:56:47 UTC

Oh sorry missed that. Closing #3286, thanks.

Comment 15 Lukas Zapletal 2013-10-21 13:34:20 UTC

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 14:58:58 UTC

Fixed in f9a773198bb569d67b1fff0a90f4412276d33122.

Comment 19 Sachin Ghai 2014-05-27 06:24:22 UTC

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 06:26:01 UTC

Created attachment 899391 [details]
greyout form on editing an existing host

Comment 21 Lukas Zapletal 2014-05-28 09:15:09 UTC

Yes this is correct behavior right now, unfortunately any better solution is too much work.

Comment 22 Sachin Ghai 2014-05-28 09:17:18 UTC

As per comment 19 and 21.. moving this bz to verified.

Comment 23 Lukas Zapletal 2014-05-30 06:38:13 UTC

That's the only way we can do with the current fog library. I can confirm.

Comment 24 Bryan Kearney 2014-06-03 14:44:13 UTC

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 14:05:29 UTC

This was delivered with 6.0.3, which is the Satellite 6 Beta.