since ignition can constantly retry though (after reboots), I guess it depends on how long the apps running are it are allowed to not have the node available.
On Friday, June 9, 2017 at 12:23:36 PM UTC-7, Charles Allen wrote: > > Thank you, Alex! > > It is worth noting that AWS's S3 has 99.9% monthly uptime SLAs as of the > time of this writing (as per https://aws.amazon.com/s3/sla/ ). > For 5 minutes to be enough for ignition to expect recovery, that means the > underlying service should have 99.99% monthly uptime SLA. > > So it is not immediately clear that pulling from S3 is a suitable target > for ignition as it is currently configured. > > Thoughts? > > On Thursday, June 8, 2017 at 2:19:15 PM UTC-7, Alex Crawford wrote: >> >> On 06/07, Charles Allen wrote: >> > Is the retry behavior of ignition fetches documented anywhere? >> >> It is not, but it really should be. Ignition will retry fetches until >> they succeed (there are other mechanisms in the OS which will cut the >> entire boot process short though). Fetches are considered complete if >> they return HTTP codes less than 500. So, for example, if you fetch a >> config which results in a 404, Ignition will immediately fail. If it >> returns a 500, Ignition will keep trying. >> >> > I would be very concerned if a simple 5XX response from an S3 endpoint >> > could prevent an instance from booting without warning. >> >> Agreed. On top of the above behavior, if Ignition fails to complete and >> it gets stuck in the initramfs, the machine will begin a five-minute >> countdown. If there is no user input within that time, the machine will >> reboot and start the whole process again. The effect is that your >> machine will continually attempt to boot and run Ignition until it is >> sucessful. >> >> -Alex >> >
