Dusty Mabe

Another thing we could do to mitigate risk is to move the old kernel/initrd to a different filesystem (tmpfs or any kind of tmp) rather than deleting it. Upon failure...

> Unless we can run on an offline backup. @dustymabe Is that possible? should be - we can probably just mount up one of the snapshots somewhere

> Is it ./images/pxeboot/vmlinuz i believe so. at least that is what the [treeinfo](https://kojipkgs.fedoraproject.org/compose/branched/Fedora-26-20170521.n.0/compose/Everything/aarch64/os/.treeinfo) is telling us to use: ``` [images-aarch64] boot.iso = images/boot.iso efiboot.img = images/efiboot.img initrd = images/pxeboot/initrd.img...

can we move forward with getting this into fedora/centos proper channels?

in the mean time, let's bump the copr to have the latest released version

I did see that in the reference and I tried using it but I couldn't get it to work. Can you work through an example with me? - I have...

> that is possible but only with internal openshift registry. That means you have to push your image to openshift images stream. It is not possible to do it with...

another check could be to make sure the secret data doesn't have any newlines in it since those aren't allowed: see https://kubernetes.io/docs/concepts/configuration/secret/

yeah mainly all we can do is do checks that guarantee it isn't a valid base64 secret string: - no newlines - does it have any non [base64 characters](https://en.wikipedia.org/wiki/Base64#Base64_table)? -...

> for examples, abcd1234, it's not encoded and it will pass all checks right. in other words, we can't warn the user in all cases, but we certainly can warn...