Bug 1102876

Summary: [Rubygem-Staypuft] staypuft tftp files under /var/lib/tftpboot/boot are 0 byte image size (attach screen-shot).
Product: Red Hat OpenStack Reporter: Omri Hochman <ohochman>
Component: rubygem-staypuftAssignee: Marek Hulan <mhulan>
Status: CLOSED DUPLICATE QA Contact: Omri Hochman <ohochman>
Severity: high Docs Contact:
Priority: high    
Version: 4.0CC: acathrow, mburns, ohochman, sputhenp
Target Milestone: ---Keywords: ZStream
Target Release: 4.0   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-08-05 13:35:49 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
screen-shot none

Description Omri Hochman 2014-05-29 18:15:09 UTC 
[Rubygem-Staypuft] staypuft tftp files under /var/lib/tftpboot/boot  are 0 byte image size (attach screen-shot).

Environment  (puddle : OpenStack/Foreman/2014-05-22.2/) 
-------------------------------------------------------
ruby193-rubygem-staypuft-0.0.16-1.el6ost.noarch
foreman-installer-staypuft-0.0.13-2.el6ost.noarch
openstack-puppet-modules-2013.2-9.1.el6ost.noarch
puppet-3.3.2-2.el6.noarch
puppet-server-3.3.2-2.el6.noarch
foreman-1.6.0.9-1.el6sat.noarch


Steps:
------
(1) Install staypuft server. 
(2) Auto-discover client .
(3) Create a new deployment --> attempt to 'Deploy'.


Results:   ( See attach screen-shot) 
--------
-Client Provision get stuck --> Cannot find the tftp files under   /var/lib/tftpboot/boot

-Looking at the staypuft:/var/lib/tftpboot/boot the files are 0 byte,.
RedHat-6.5-x86_64-initrd.img    0 byte
RedHat-6.5-x86_64-vmlinuz   0 byte 



To Workaround:  (download again those files manually) 
--------------------------------------------------------
cd /var/lib/tftpboot/boot
wget
http://download.eng.bos.redhat.com/released/RHEL-6/6.5/Server/x86_64/os/images/pxeboot/initrd.img -O RedHat-6.5-x86_64-initrd.img

wget http://download.eng.bos.redhat.com/released/RHEL-6/6.5/Server/x86_64/os/images/pxeboot/vmlinuz-O RedHat-6.5-x86_64-vmlinuz
Comment 1 Omri Hochman 2014-05-29 18:15:44 UTC 
Created attachment 900479 [details]
screen-shot
Comment 2 Mike Burns 2014-05-29 18:33:58 UTC 
Marek, any ideas with this?  The 0-size files seem to show up when triggering the deployment of openstack.  It happens with both nfs:// and http://
Comment 3 Andrew Cathrow 2014-05-29 20:00:07 UTC 
Do we believe this will be relevant for OSP5?
Comment 4 Andrew Cathrow 2014-05-29 20:06:19 UTC 
Do we believe this will be relevant for OSP5?
Comment 5 Omri Hochman 2014-05-29 20:14:23 UTC 
(In reply to Andrew Cathrow from comment #3)
> Do we believe this will be relevant for OSP5?

Yes - this issue would probably effect any release.  If I understand correctly the next major version that coming is OSP5 (even before A5). so maybe it makes more sense to switch this bug to OSP5 .
Comment 6 Marek Hulan 2014-05-30 08:37:10 UTC 
Could you please attach your foreman's installation media configuration? Seems like proxy can't download these files from it.
Comment 9 Marek Hulan 2014-06-03 06:23:19 UTC 
So there are three possible ways how to cause 0 bytes files.

1) wrong subscription manager credentials
2) wrong repo url
both 1 and 2 have the same solution, you fix values in foreman UI and then just create a new host with particular OS. You can use any mac address, we just need to build new host so images are refreshed and downloaded, you can remove the host just after you create it. Also new openstack deployment should fix it automatically. So we just have to make sure that credentials and url is correct before we start.

Although I agree that we should verify wrong values beforehand, but it's not currently possible without big changes in foreman. I don't think this is high priority - since it's user's issue and he can fix it easily.

3) wrong repo url protocol

nfs:// protocol is not supported so you have to download files manually in such case, only http:// and https:// is supported, later we could add file://
Comment 10 Mike Burns 2014-08-05 13:35:49 UTC 

*** This bug has been marked as a duplicate of bug 1105594 ***