Fuel for OpenStack

Fail 15 nodes installation _rsync error

Asked by yoonjaeyol

I try to install to my server 15 node with Fuel 5.0.

I was successfully install to server 10 node.

But increase 15 node, It is fail following error

ID: 213 - Reason: Fail to upload folder using command rsync -c -r --delete rsync://10.20.0.2:/puppet/modules/ /etc/puppet/modules/.
                       Exit code: 12, stderr: rsync: read error: Connection reset by peer (104)
rsync error: error in rsync protocol data stream (code 12) at io.c(764) [Receiver=3.0.9]

ID: 211 - Reason: Fail to upload folder using command rsync -c -r --delete rsync://10.20.0.2:/puppet/modules/ /etc/puppet/modules/.
                       Exit code: 12, stderr: rsync: read error: Connection reset by peer (104)
rsync error: error in rsync protocol data stream (code 12) at io.c(764) [Receiver=3.0.9]

ID: 204 - Reason: Fail to upload folder using command rsync -c -r --delete rsync://10.20.0.2:/puppet/modules/ /etc/puppet/modules/.
                       Exit code: 12, stderr: rsync: read error: Connection reset by peer (104)
rsync error: error in rsync protocol data stream (code 12) at io.c(764) [Receiver=3.0.9]

ID: 199 - Reason: Fail to upload folder using command rsync -c -r --delete rsync://10.20.0.2:/puppet/modules/ /etc/puppet/modules/.
                       Exit code: 12, stderr: rsync: read error: Connection reset by peer (104)
rsync error: error in rsync protocol data stream (code 12) at io.c(764) [Receiver=3.0.9]

ID: 212 - Reason: Fail to upload folder using command rsync -c -r --delete rsync://10.20.0.2:/puppet/modules/ /etc/puppet/modules/.
                       Exit code: 12, stderr: rsync: read error: Connection reset by peer (104)
rsync error: error in rsync protocol data stream (code 12) at io.c(764) [Receiver=3.0.9]

please check the log

Question information

Language:
English Edit question
Status:
Solved
For:
Fuel for OpenStack Edit question
Assignee:
No assignee Edit question
Solved by:
yoonjaeyol
Solved:
Last query:
Last reply:
Revision history for this message
Evgeny Kozhemyakin (ekozhemyakin) said : 		#1

Hi,
your issue seems similar the one from https://bugs.launchpad.net/fuel/+bug/1330495.
Plase look into it.
The temporary workaround is running rsync in standalone mode (instead of xinetd).

Revision history for this message
yoonjaeyol (yoonjaeyol) said : 		#2

I have one more question.

How to configure standalone instead of xinetd.

There is some different configure than normal Linux system.

Please give me some idea.

thank you Evgeny Kozhemyakin

Revision history for this message
Evgeny Kozhemyakin (ekozhemyakin) said : 		#3

In fuel 5.0 rsync is running in lxc container.

Find it by running "docker ps | grep rsync".
Edit /var/lib/docker/devicemapper/mnt/<...long long container id...>/rootfs/etc/xinetd.d/rsync
     and set "disable=yes".
Inter into the container with "dockerctl shell rsync".
Kill with -1 the parrent xinetd process.
Run "/usr/bin/rsync --daemon --config=/etc/rsyncd.conf"

PS:
This issue has been fixed for fuel v5.0.1 (I hope).
See https://bugs.launchpad.net/fuel/+bug/1322577.
So you can also try the patch from there or test new 5.0.1 iso.

Revision history for this message
Joshua Dotson (tns9) said : 		#4

This must be a bug. I've been trying to hammer this out all day with my install. It happens when I use neutron and murano, but not when I'm using nova-network. :( It really makes no sense.

Revision history for this message
Joshua Dotson (tns9) said : 		#5

@ekozhemyakin: Your temporary fix works, but it is not present in 5.0.1. I built my ISO on July 8th. Please provide a long term fix, asap.

Revision history for this message
yoonjaeyol (yoonjaeyol) said : 		#6

My problem is solved.

Thank you for your comment Evgeny Kozhemyakin

Revision history for this message
Evgeny Kozhemyakin (ekozhemyakin) said : 		#7

yoonjaeyol: np, you're welcome.

Joshua Dotson: it's not exactly the same fix in 5.0.1, just retry mechanism for rsync has been added.
Do you still meet this sort of problems in 5.0.1?

Revision history for this message
Joshua Dotson (tns9) said : 		#8

@ekozhemyakin: The retries do not seem to help on 5.0.1. I believe this is due to the parallel nature of the retries which create a denial of service on xinetd.

Revision history for this message
Evgeny Kozhemyakin (ekozhemyakin) said : 		#9

Yes, possibly it is the access restriction mechanism of xinetd.
I think we should ping the developers in #1322577.