This issue was addressed by these two pull-requests:
https://github.com/canonical/cloud-init/pull/56
https://github.com/canonical/cloud-init/pull/229

Both *didn't* landed upstream, which means this might take a little while to be updated.
I'll work on this in parallel and update this BZ as soon as I have any news.

This feature is still being worked upstream. VMWare is trying to replace OVF with a new DataSource that doesn't seem to hit this bug, called guest-info. This feature nowhere near to be upstream.

Possibly will be available on the next cloud-init release (20.4) and will be able to be backported to RHEL-8.4/cloud-init-20.3.

Lowering the Priority for now.

------- Comment From rpsene.com 2021-04-12 15:40 EDT-------
Whenever a new VM is created based on an image, or even installing a new VM with the distro image, cloud-init will generate a new instance-id for that specific VM. When you remove the Data Source and reboot, cloud-init thinks it is a new instance, regenerates a new instance-id and run again. That is when the network configuration is overwritten.

https://bugzilla.redhat.com/show_bug.cgi?id=1593010
https://bugzilla.redhat.com/show_bug.cgi?id=1750859

The workaround for this is to disable the network management after the VM is up and running:

vi /etc/cloud/cloud.cfg
add:
network:
config: disabled

We need to understand why this is happening on PowerVS (not sure if storage can be the root cause).

(In reply to IBM Bug Proxy from comment #9)
> ------- Comment From rpsene.com 2021-04-12 15:40 EDT-------
> Whenever a new VM is created based on an image, or even installing a new VM
> with the distro image, cloud-init will generate a new instance-id for that
> specific VM. When you remove the Data Source and reboot, cloud-init thinks
> it is a new instance, regenerates a new instance-id and run again. That is
> when the network configuration is overwritten.
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1593010
> https://bugzilla.redhat.com/show_bug.cgi?id=1750859
> 
> The workaround for this is to disable the network management after the VM is
> up and running:
> 
> vi /etc/cloud/cloud.cfg
> add:
> network:
> config: disabled
> 
> We need to understand why this is happening on PowerVS (not sure if storage
> can be the root cause).

Hey!

Is this the same issue as the other BZ for RHEL-7.9? I'm curious to understand, are you guys running VMware nested on PowerVS? Or is it just the same behavior? If it's not related to Vmware, please file a new BZ and we can go from there - this BZ tracks a known problem existing on VMware DataSource only.

Thanks!

Hi rpsene.com,

For your question about cloud-init on PowerVS, you can get the answer from this upstream bug https://bugs.launchpad.net/cloud-init/+bug/1893770,
and a short term solution, https://bugs.launchpad.net/cloud-init/+bug/1893770/comments/24

If any more question about cloud-init on PowerVS, you can file a new bug.

Thanks

(In reply to IBM Bug Proxy from comment #9)
> ------- Comment From rpsene.com 2021-04-12 15:40 EDT-------
> Whenever a new VM is created based on an image, or even installing a new VM
> with the distro image, cloud-init will generate a new instance-id for that
> specific VM. When you remove the Data Source and reboot, cloud-init thinks
> it is a new instance, regenerates a new instance-id and run again. That is
> when the network configuration is overwritten.
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1593010
> https://bugzilla.redhat.com/show_bug.cgi?id=1750859
> 
> The workaround for this is to disable the network management after the VM is
> up and running:
> 
> vi /etc/cloud/cloud.cfg
> add:
> network:
> config: disabled
> 
> We need to understand why this is happening on PowerVS (not sure if storage
> can be the root cause).

Hi,

VMware also published a KB article to workaround this issue: https://kb.vmware.com/s/article/71264, besides the one mentioned in Comment 9 which prevents cloud-init updating network again.

As Eduardo mentioned, there were 2 pull requests tried to fix this, but none of them was accepted to cloud-init main branch. We are looking for a better solution.

Thanks,
pengpengs

(In reply to Eduardo Otubo from comment #4)
> This feature is still being worked upstream. VMWare is trying to replace OVF
> with a new DataSource that doesn't seem to hit this bug, called guest-info.
> This feature nowhere near to be upstream.
> 
> Possibly will be available on the next cloud-init release (20.4) and will be
> able to be backported to RHEL-8.4/cloud-init-20.3.
> 
> Lowering the Priority for now.

Guest-info has been renamed and upstream to cloud-init v21.3 as DatasourceVMware, it's not a replacement of OVF. It more likes a different data transfer mechanism. For guest os customization, the datasource being used is still OVF for now.

(In reply to Pengpeng Sun from comment #32)
> Guest-info has been renamed and upstream to cloud-init v21.3 as
> DatasourceVMware, it's not a replacement of OVF. It more likes a different
> data transfer mechanism. For guest os customization, the datasource being
> used is still OVF for now.

Hi Pengpeng, 

Thank you so much for the explanation. 

As we have another BZ 2026587 requested from customer to support for cloud-init datasource 'cloud-init-vmware-guestinfo', I think it is exactly the DatasourceVMware we mentioned here, right? I have some additional questions about the DatasourceVMware, could you please help to identify?

1. For the DatasourceVMware testing, no need to enable VMware Tools, using open-vm-tools is ok just like OVF, do I understand correctly?

2. Could you please provide the test steps for the DatasourceVMware testing? Is it like https://github.com/vmware-archive/cloud-init-vmware-guestinfo#walkthrough?
And what will be the datasource in /run/cloud-init/ds-identify.log(both OVF and VMware?)? 

Thanks
Huijuan

(In reply to Huijuan Zhao from comment #33)
> (In reply to Pengpeng Sun from comment #32)
> > Guest-info has been renamed and upstream to cloud-init v21.3 as
> > DatasourceVMware, it's not a replacement of OVF. It more likes a different
> > data transfer mechanism. For guest os customization, the datasource being
> > used is still OVF for now.
> 
> Hi Pengpeng, 
> 
> Thank you so much for the explanation. 
> 
> As we have another BZ 2026587 requested from customer to support for
> cloud-init datasource 'cloud-init-vmware-guestinfo', I think it is exactly
> the DatasourceVMware we mentioned here, right? I have some additional
> questions about the DatasourceVMware, could you please help to identify?
> 
> 1. For the DatasourceVMware testing, no need to enable VMware Tools, using
> open-vm-tools is ok just like OVF, do I understand correctly?
> 
> 2. Could you please provide the test steps for the DatasourceVMware testing?
> Is it like
> https://github.com/vmware-archive/cloud-init-vmware-guestinfo#walkthrough?
> And what will be the datasource in /run/cloud-init/ds-identify.log(both OVF
> and VMware?)? 
> 
> Thanks
> Huijuan

Hi Huijuan,

Yes, vmware-guestinfo (https://github.com/vmware-archive/cloud-init-vmware-guestinfo) was merged to cloud-init upstream and renamed as DatasourceVMware (https://github.com/canonical/cloud-init/blob/main/cloudinit/sources/DataSourceVMware.py) since cloud-init version 21.3

AFAIK, RHEL hasn't rebased cloud-init v21.3 yet, so that customer need go through the original setup to install the vmware-guestinfo firstly, see https://github.com/vmware-archive/cloud-init-vmware-guestinfo#installation, then configure VM to assign metadata and userdata to guestinfo, see https://github.com/vmware-archive/cloud-init-vmware-guestinfo#walkthrough

I might not get your first question correctly, the Open VM Tools (open-vm-tools) is the open source implementation of VMware Tools for Linux guest operating systems, it's available for RHEL. Yes, it's ok to user open-vm-tools for vmware-guestinfo or DatasourceVMware.

The vmware-guestinfo installation will add a configuration file that tells cloud-init what datasource to use (https://github.com/vmware-archive/cloud-init-vmware-guestinfo/blob/master/install.sh#L103) and download program used by ds-identify to determine whether or not the guestinfo datasource is useable (https://github.com/vmware-archive/cloud-init-vmware-guestinfo/blob/master/install.sh#L109)

Thanks,
Pengpeng

(In reply to Pengpeng Sun from comment #34)
> 
> Hi Huijuan,
> 
> Yes, vmware-guestinfo
> (https://github.com/vmware-archive/cloud-init-vmware-guestinfo) was merged
> to cloud-init upstream and renamed as DatasourceVMware
> (https://github.com/canonical/cloud-init/blob/main/cloudinit/sources/
> DataSourceVMware.py) since cloud-init version 21.3
> 
> AFAIK, RHEL hasn't rebased cloud-init v21.3 yet, so that customer need go
> through the original setup to install the vmware-guestinfo firstly, see
> https://github.com/vmware-archive/cloud-init-vmware-guestinfo#installation,
> then configure VM to assign metadata and userdata to guestinfo, see
> https://github.com/vmware-archive/cloud-init-vmware-guestinfo#walkthrough
> 
> I might not get your first question correctly, the Open VM Tools
> (open-vm-tools) is the open source implementation of VMware Tools for Linux
> guest operating systems, it's available for RHEL. Yes, it's ok to user
> open-vm-tools for vmware-guestinfo or DatasourceVMware.

Thank you so much for the answer, this is what I would ask. I thought we must enable VMware Tools(instead of open-vm-tools) for the DatasourceVMware, but we have to use/test open-vm-tools(which is conflict with VMware Tools), this is what I was confused at the beginning.

So after backport the DatasourceVMware(vmware-guestinfo) patch to RHEL cloud-init, we can still use the open-vm-tools for DatasourceVMware. And we can follow the https://github.com/vmware-archive/cloud-init-vmware-guestinfo#walkthrough to config the VM.

> 
> The vmware-guestinfo installation will add a configuration file that tells
> cloud-init what datasource to use
> (https://github.com/vmware-archive/cloud-init-vmware-guestinfo/blob/master/
> install.sh#L103) and download program used by ds-identify to determine
> whether or not the guestinfo datasource is useable
> (https://github.com/vmware-archive/cloud-init-vmware-guestinfo/blob/master/
> install.sh#L109)
> 
> Thanks,
> Pengpeng

Pengpeng, thank you again for the quick answers, they are really helpful.

(In reply to Huijuan Zhao from comment #35)
> So after backport the DatasourceVMware(vmware-guestinfo) patch to RHEL
> cloud-init, we can still use the open-vm-tools for DatasourceVMware. And we
> can follow the
> https://github.com/vmware-archive/cloud-init-vmware-guestinfo#walkthrough to
> config the VM.

Yes, for DatasourceVMware, you can also refer to cloud-init document at https://cloudinit.readthedocs.io/en/latest/topics/datasources/vmware.html

(In reply to Pengpeng Sun from comment #36)
> (In reply to Huijuan Zhao from comment #35)
> > So after backport the DatasourceVMware(vmware-guestinfo) patch to RHEL
> > cloud-init, we can still use the open-vm-tools for DatasourceVMware. And we
> > can follow the
> > https://github.com/vmware-archive/cloud-init-vmware-guestinfo#walkthrough to
> > config the VM.
> 
> Yes, for DatasourceVMware, you can also refer to cloud-init document at
> https://cloudinit.readthedocs.io/en/latest/topics/datasources/vmware.html

Pengpeng, ok, got it, thank you so much for the guide, I will try it as soon as possible and update in BZ 2026587.

Hi Huijuan,

Any updates on this bug, I see BZ 2026587 has been closed.

Thanks,
Pengpeng

(In reply to Pengpeng Sun from comment #42)
> Hi Huijuan,
> 
> Any updates on this bug, I see BZ 2026587 has been closed.
> 
> Thanks,
> Pengpeng

Hi Pengpeng,

The issue still exists in the latest version cloud-init-22.1
BZ 2026587 is regarding the new datasource DatasourceVMware, RHEL can support it now. But this issue only exists with OVF datasource, so it is still there.

Thanks!
Huijuan

Thanks Huijuan for the information. As Comment 9 mentioned, data source (customization configuration) provided to cloud-init only at the first boot, and then it's removed, in the following reboot, cloud-init will go through it's Datasource list and apply DatasourceNone (Set network to DHCP) at the end.

We have made a change on OVF datasource, Guest Customization transport has been moved from DatasourceOVF to DatasourceVMware. see details in https://github.com/canonical/cloud-init/pull/1573, this change is available since cloud-init v22.4.2. With this change, customer can set cloud-init Datasource list to "DatasourceVMware" only on VMware platform, then this issue won't reproduce.

Best regards,
Pengpeng

Thanks Pengpeng for the explanation and information. 

So should we consider backport the patch https://github.com/canonical/cloud-init/pull/1573 or do rebase in the next rhel cloud-init release?
Emanuele, could you please help to check comment 45 and evaluate it? Thanks!

(In reply to Pengpeng Sun from comment #45)
> We have made a change on OVF datasource, Guest Customization transport has
> been moved from DatasourceOVF to DatasourceVMware. see details in
> https://github.com/canonical/cloud-init/pull/1573, this change is available
> since cloud-init v22.4.2. With this change, customer can set cloud-init
> Datasource list to "DatasourceVMware" only on VMware platform, then this
> issue won't reproduce.

Hi Pengpeng,

I would like to confirm the change you mentioned in https://github.com/canonical/cloud-init/pull/1573.

With this change, it is backward compatibility, it still supports VM Customization Specifications on vSphere. Customers still can persist the current usage on cloud-init. Am I right?

Is there any document to notify this change in your side? 
I think we need notify this change in Red Hat DOC after backport the patch to RHEL cloud-init.

And do you have any suggestions for test cases/scenarios per the patch?

Thanks!
Huijuan

(In reply to Huijuan Zhao from comment #47)
> (In reply to Pengpeng Sun from comment #45)
> > We have made a change on OVF datasource, Guest Customization transport has
> > been moved from DatasourceOVF to DatasourceVMware. see details in
> > https://github.com/canonical/cloud-init/pull/1573, this change is available
> > since cloud-init v22.4.2. With this change, customer can set cloud-init
> > Datasource list to "DatasourceVMware" only on VMware platform, then this
> > issue won't reproduce.
> 
> Hi Pengpeng,
> 
> I would like to confirm the change you mentioned in
> https://github.com/canonical/cloud-init/pull/1573.
> 
> With this change, it is backward compatibility, it still supports VM
> Customization Specifications on vSphere. Customers still can persist the
> current usage on cloud-init. Am I right?

Yes, correct. Guest customization function and usage are consistent with this change, while DatasourceVMware but DatasourceOVF is the datasource which transports customization specification as data to cloud-init. As long as "VMware" is included in the cloud-init datasource list, Guest customization should work exactly as before.

> 
> Is there any document to notify this change in your side? 

Please check cloud-init VMware datasource doc: https://github.com/canonical/cloud-init/blob/main/doc/rtd/reference/datasources/vmware.rst#guest-os-customisation, it includes the configurations related to guest customization which is same with before.

> I think we need notify this change in Red Hat DOC after backport the patch
> to RHEL cloud-init.
> 

Yes, customer need make sure "VMware" is included in the cloud-init datasource list, while I remember on Red Hat, this is true by default.

> And do you have any suggestions for test cases/scenarios per the patch?

The current Guest Customization test cases/scenarios should pass with this change.

> 
> Thanks!
> Huijuan

Understand, thank you Pengpeng for the detail instruction :) Will check the details of cloud-init VMware datasource doc.

Hi Huijuan,

One thing I forgot to mention is that due to Guest Customization moves from DatasourceOVF to DatasourceVMware, and in DatasourceVMware, Guest customization data is loaded after guestinfo data. So there is also data loading sequence change. If customer configures more than one below data sources, the result could be different.

Before this change, with default datasource list, the data loading sequence is
1. OVF Guest customization
2. OVF guestinfo.ovfEnv
3. OVF iso
4. VMware guestinfo

After this change， with default datasource list, the data loading sequence is
1. OVF guestinfo.ovfEnv
2. OVF iso
3. VMware guestinfo
4. VMware Guest customization

I'm not sure if you have test cases related to this, if yes, please expect different result.


Thanks,
Pengpeng

(In reply to Pengpeng Sun from comment #50)
> Hi Huijuan,
> 
> One thing I forgot to mention is that due to Guest Customization moves from
> DatasourceOVF to DatasourceVMware, and in DatasourceVMware, Guest
> customization data is loaded after guestinfo data. So there is also data
> loading sequence change. If customer configures more than one below data
> sources, the result could be different.
> 
> Before this change, with default datasource list, the data loading sequence
> is
> 1. OVF Guest customization
> 2. OVF guestinfo.ovfEnv
> 3. OVF iso
> 4. VMware guestinfo
> 
> After this change， with default datasource list, the data loading sequence is
> 1. OVF guestinfo.ovfEnv
> 2. OVF iso
> 3. VMware guestinfo
> 4. VMware Guest customization
> 
> I'm not sure if you have test cases related to this, if yes, please expect
> different result.

Thank you so much Pengpeng for the reminder and explanations, we do not have such test case to cover the data loading sequence, will add test cases to cover it, thanks again!

(In reply to Emanuele Giuseppe Esposito from comment #52)
> Hi Huijuan,
> 
> I tried to backport the PR and fixed all conflicts, could you please check
> if it works?
> https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=50439045

Thanks Emanuele. 

I tested the scratch build, the default DataSource is changed to VMware from OVF, but this bug is still there: When set static IP with customize file(datasource: VMware), it changed to DHCP(datasource: none) after reboot.

# rpm -q cloud-init
cloud-init-22.1-5.el9.esposem202302011545.noarch

# cloud-id
none 
                 
# cat /run/cloud-init/cloud.cfg 
datasource_list: [ VMware, None ]

/var/log/cloud-init.log after reboot
-----------------------------------
   1180 2023-02-03 11:03:40,785 - DataSourceVMware.py[DEBUG]: Getting guestinfo value for key metadata
   1181 2023-02-03 11:03:40,785 - subp.py[DEBUG]: Running command ['/usr/bin/vmware-rpctool', 'info-get guestinfo.metadata'] with allowed return codes [0] (sh        ell=False, capture=True)
   1182 2023-02-03 11:03:40,792 - DataSourceVMware.py[DEBUG]: No value found for key metadata
   1183 2023-02-03 11:03:40,792 - DataSourceVMware.py[DEBUG]: Getting guestinfo value for key userdata
   1184 2023-02-03 11:03:40,792 - subp.py[DEBUG]: Running command ['/usr/bin/vmware-rpctool', 'info-get guestinfo.userdata'] with allowed return codes [0] (sh        ell=False, capture=True)
   1185 2023-02-03 11:03:40,795 - DataSourceVMware.py[DEBUG]: No value found for key userdata
   1186 2023-02-03 11:03:40,795 - DataSourceVMware.py[DEBUG]: Getting guestinfo value for key vendordata
   1187 2023-02-03 11:03:40,795 - subp.py[DEBUG]: Running command ['/usr/bin/vmware-rpctool', 'info-get guestinfo.vendordata'] with allowed return codes [0] (        shell=False, capture=True)
   1188 2023-02-03 11:03:40,798 - DataSourceVMware.py[DEBUG]: No value found for key vendordata
   1189 2023-02-03 11:03:40,799 - dmi.py[DEBUG]: querying dmi data /sys/class/dmi/id/product_name
   1190 2023-02-03 11:03:40,799 - guestcust_util.py[DEBUG]: Found the customization plugin at /usr/lib64/open-vm-tools/plugins/vmsvc/libdeployPkgPlugin.so
   1191 2023-02-03 11:03:40,799 - guestcust_util.py[DEBUG]: Waiting for VMware customization configuration file
   1192 2023-02-03 11:03:45,800 - guestcust_util.py[DEBUG]: Waiting for VMware customization configuration file
   1193 2023-02-03 03:03:50,401 - guestcust_util.py[DEBUG]: Waiting for VMware customization configuration file
   1194 2023-02-03 03:03:55,406 - util.py[DEBUG]: Waiting for VMware customization configuration file took -28785.394 seconds
   1195 2023-02-03 03:03:55,406 - guestcust_util.py[DEBUG]: No VMware customization configuration file found
   1196 2023-02-03 03:03:55,406 - DataSourceVMware.py[ERROR]: failed to find a valid data access method
   1197 2023-02-03 03:03:55,406 - __init__.py[DEBUG]: Datasource DataSourceVMware [seed=None] not updated for events: boot-new-instance
   1198 2023-02-03 03:03:55,406 - handlers.py[DEBUG]: finish: init-network/search-VMware: SUCCESS: no network data found from DataSourceVMware
   1199 2023-02-03 03:03:55,406 - handlers.py[DEBUG]: start: init-network/search-None: searching for network data from DataSourceNone
-----------------------------------

Will upload the log file for your reference. 


Pengpeng, could I know if this scenario(only Guest customization config static IP, no VMware guestinfo provided) test pass in your side with upstream patch? Thanks!

Hi Huijuan,

Your test got expected result, with default datasource_list, datasource_list will be [ VMware, None ] when customization happens.  Then after reboot vm, cloud-init will load DatasourceNone and update network configuration to DHCP.

(In reply to Pengpeng Sun from comment #45)
> With this change, customer can set cloud-init
> Datasource list to "DatasourceVMware" only on VMware platform, then this
> issue won't reproduce.

And this is not true, sorry for the misleading. Even with datasource_list: [ VMware ] (by creating a file /etc/cloud/cloud.cfg.d/99_vmware.cfg with content "datasource_list: [ VMware ]"), after reboot vm, vm still gets DHCP network configuration since when cloud-init fails to load network from both datasource and cloud-init configuration, it will use distro fallback network configuration which is also DHCP. See https://github.com/canonical/cloud-init/blob/main/cloudinit/stages.py#L859

The https://github.com/canonical/cloud-init/pull/1573 can NOT fix this issue, but rebasing the next cloud-init version which contains this change is recommended. 
For this issue, the VMware KB article: https://kb.vmware.com/s/article/71264 is still needed, or disable network config which is mentioned in Comment 9 can prevent cloud-init updating network again.

Thanks,
Pengpeng

Ok, got it, thank you Pengpeng for the clarification and suggestion. Red Hat also recorded this as known issue in release notes(rhel-8 and rhel-9).

Should we close this BZ as won't fix or keep it open for other solutions?

Emanuele, thank you for the backport build and resolving the conflicts, could you please help to evaluate should we keep the backport build or wait to rebase the next cloud-init version which contains this change per Pengpeng's comment 57? Thanks!

I suggest keep this open to see if a solution can be found eventually. 

The next cloud-init major release (should be 23.1) will contain PR #1573 change.

(In reply to Pengpeng Sun from comment #60)
> I suggest keep this open to see if a solution can be found eventually. 
> 
> The next cloud-init major release (should be 23.1) will contain PR #1573
> change.

Ok, got it, it makes sense. Thank you Pengpeng for the suggestion and information, will pay more attention on this patch in next rhel cloud-init rebase.

VMware bug number is 2302212

(In reply to Pengpeng Sun from comment #63)
> VMware bug number is 2302212

Correction, VMware bug number 3108507 is tracking this problem and is assigned to Pengpeng Sun.  VMware has lead creating a solution for this problem.  Adding need-info to Pengpeng to keep us up to date on progress.


VMware bug number 2302212 is split to track Red hat bugs 1664605 and 1666961.

-John

VmWare pointed us to this KB article:

https://kb.vmware.com/s/article/71264

(In reply to Pengpeng Sun from comment #60)
> I suggest keep this open to see if a solution can be found eventually. 
> 
> The next cloud-init major release (should be 23.1) will contain PR #1573
> change.

Hi Pengpeng,

We rebased to 23.1.1 in latest RHEL, but this issue is still there.
Seems there is no solution for this issue in upstream currently, should we keep this open or close as WONTFIX?

Thanks
Huijuan

(In reply to Huijuan Zhao from comment #69)
> (In reply to Pengpeng Sun from comment #60)
> > I suggest keep this open to see if a solution can be found eventually. 
> > 
> > The next cloud-init major release (should be 23.1) will contain PR #1573
> > change.
> 
> Hi Pengpeng,
> 
> We rebased to 23.1.1 in latest RHEL, but this issue is still there.
> Seems there is no solution for this issue in upstream currently, should we
> keep this open or close as WONTFIX?
> 
> Thanks
> Huijuan

Hi Huijuan,

Yes, this issue has NOT been fixed on cloud-init upstream, I'm working on it recently, will update here if any updates I have. Please keep this one open, thanks.

Best regards,
Pengpeng

(In reply to Pengpeng Sun from comment #70)
> Hi Huijuan,
> 
> Yes, this issue has NOT been fixed on cloud-init upstream, I'm working on it
> recently, will update here if any updates I have. Please keep this one open,
> thanks.
> 
> Best regards,
> Pengpeng

Ok, good to know this, thank you so much Pengpeng for the update : )

Issue migration from Bugzilla to Jira is in process at this time. This will be the last message in Jira copied from the Bugzilla bug.

This BZ has been automatically migrated to the issues.redhat.com Red Hat Issue Tracker. All future work related to this report will be managed there.

Due to differences in account names between systems, some fields were not replicated.  Be sure to add yourself to Jira issue's "Watchers" field to continue receiving updates and add others to the "Need Info From" field to continue requesting information.

To find the migrated issue, look in the "Links" section for a direct link to the new issue location. The issue key will have an icon of 2 footprints next to it, and begin with "RHEL-" followed by an integer.  You can also find this issue by visiting https://issues.redhat.com/issues/?jql= and searching the "Bugzilla Bug" field for this BZ's number, e.g. a search like:

"Bugzilla Bug" = 1234567

In the event you have trouble locating or viewing this issue, you can file an issue by sending mail to rh-issues. You can also visit https://access.redhat.com/articles/7032570 for general account information.