Mount iscsiadm and configuration in kubelet container

[cehoffman]

In order to use iscsi volumes, the kubelet container needs access to iscsiadm and configuration.

This solution is referenced in coreos/coreos-kubernetes#481. There also appears to be a bug with stable at least. The documentation states that /etc/iscsi/initiatorname.iscsi is automatically created and filled with a unique name, but this is not my experience. For these changes to be useful, that file needs to be created with a unique name. I am doing that as part of the ignition configuration now, but did not include it here incase it should be fixed in an upstream dependency of Tectonic.

[coreosbot]

Can one of the admins verify this patch?

[coreosbot]

Can one of the admins verify this patch?

[coreosbot]

Can one of the admins verify this patch?

[coreosbot]

Can one of the admins verify this patch?

[coreosbot]

Can one of the admins verify this patch?

[redbaron]

/etc/iscsi/initiatorname.iscsi is autogenerated with a value derived from machine-id by a iscsid-initiatorname.service, which is itself started by iscsid.service.

[cehoffman]

@redbaron correct, I found this out once I enabled iscsid. I had forgotten to update this. The initiatorname isn't any issue like I had originally thought.

[redbaron]

I used changes from this PR to sucessfully mount iscsi volumes, don't why it is still not merged

[sym3tri]

@crawford @aaronlevy any opposition to this change?

[crawford]

@sym3tri seems fine.

[aaronlevy]

I'm not super exited about a binary from host being used in the kubelet container (my comment is pretty dated at this point - but is it safe enough to assume libc on host == libc in hyperkube container?)

Is there a reason the binary can't be shipped as part of hyperkube (rather than relying on a copy mounted from host?)

Should we maybe consider documenting using a systemd drop-in to add extra flags to the args passed to kubelet-wrapper?

[cehoffman]

@aaronlevy I think documenting a the drop-in would be nice. There are a few other reasons one might one to extend the rkt args for kubelet. For example, I do it to mount a preloaded docker auth file for access to a private container registry.

[sym3tri]

Thanks for this contribution, but we're not adding any new features to this repo at this time. We're converging Tectonic with a future release of Open Shift. We'll keep this request in mind as we integrate the products.

See our blog post for more info: https://coreos.com/blog/coreos-tech-to-combine-with-red-hat-openshift