Skip to content
This repository has been archived by the owner on Jul 23, 2019. It is now read-only.

Enable platform dependent bootstrap ignition files #102

Merged
merged 1 commit into from
Jun 14, 2019

Conversation

hardys
Copy link

@hardys hardys commented Jun 11, 2019

Some of the additions made should only be enabled for the
baremetal platform, so move these to data/data/bootstrap/baremetal
and adjust the code to conditionally read this depending on the
platform name.

Closes: #62
Related: #64

@hardys
Copy link
Author

hardys commented Jun 11, 2019

Only lightly tested so far, but lets ensure it passes CI, feedback welcome on the approach - I discussed it with @staebler and it sounds like it may be a reasonable approach to enable platform specific additions.

Copy link
Contributor

@staebler staebler left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The approach taken elsewhere is to place files that should be used on all platform in a _base folder. For example, bootkube.service would move to data/data/bootstrap/_base/systemd/units/bootkube.service.

Also, there is no baremetal platform type in the installer. Bare metal installations use the none platform. But note that not all none-platform installations are bare-metal installations.

pkg/asset/ignition/bootstrap/bootstrap.go Outdated Show resolved Hide resolved
pkg/asset/ignition/bootstrap/bootstrap.go Outdated Show resolved Hide resolved
pkg/asset/ignition/bootstrap/bootstrap.go Outdated Show resolved Hide resolved
@stbenjam
Copy link
Member

stbenjam commented Jun 11, 2019

@staebler There is a baremetal platform in our fork (it's why it exists), it will be contributed back to openshift/installer soon. This fork implements baremetal IPI.

@stbenjam
Copy link
Member

@hardys I think the approach is good. The only concern I have is that looking at the implementation of addStorageFiles, I don't think it would be possible for a platform to override a base configuration file. If for example, we wanted a custom motd, I believe the same file would end up in the ignition twice - not sure how ignition handles it, but ideally we'd create a unique set of files to deploy, with the platform-specific ones taking precedence

@staebler
Copy link
Contributor

@staebler There is a baremetal platform in our fork (it's why it exists), it will be contributed back to openshift/installer soon. This fork implements baremetal IPI.

Ah, I didn't even notice that this wasn't https://github.com/openshift/installer.

@derekhiggins
Copy link
Collaborator

Build SUCCESS, see build http://10.8.144.11:8080/job/dev-tools/731/

@hardys
Copy link
Author

hardys commented Jun 12, 2019

The approach taken elsewhere is to place files that should be used on all platform in a _base folder. For example, bootkube.service would move to data/data/bootstrap/_base/systemd/units/bootkube.service

Thanks for the feedback - for this fork I wanted to avoid causing us more rebase pain, so decided not to move the files, but it sounds like I should create another PR to openshift/installer which aligns with that convention, then we can rebase and drop this patch when it hopefully lands :)

As mentioned this fork implements a new baremetal platform, and this is part of our cleanup to enable proposing the additions to enable baremetal IPI without impact to other platforms.

Some of the additions made should only be enabled for the
baremetal platform, so move these to data/data/bootstrap/baremetal
and adjust the code to conditionally read this depending on the
platform name.

Closes: openshift-metal3#62
Related: openshift-metal3#64
@hardys hardys force-pushed the baremetal_bootstrap branch from eec38a3 to 6aba139 Compare June 12, 2019 10:50
@hardys
Copy link
Author

hardys commented Jun 12, 2019

@hardys I think the approach is good. The only concern I have is that looking at the implementation of addStorageFiles, I don't think it would be possible for a platform to override a base configuration file. If for example, we wanted a custom motd, I believe the same file would end up in the ignition twice - not sure how ignition handles it, but ideally we'd create a unique set of files to deploy, with the platform-specific ones taking precedence

This is a good point, I need to do some testing but AFAICS recent ignition versions do validation so probably duplicate files will break, so we'll need to handle it in the installer.

I'll look into that, but I think the other issues raised by @staebler are now fixed.

@derekhiggins
Copy link
Collaborator

Build ABORTED, see build http://10.8.144.11:8080/job/dev-tools/737/

@derekhiggins
Copy link
Collaborator

Build FAILURE, see build http://10.8.144.11:8080/job/dev-tools/738/

@derekhiggins
Copy link
Collaborator

Build SUCCESS, see build http://10.8.144.11:8080/job/dev-tools/739/

@hardys
Copy link
Author

hardys commented Jun 12, 2019

@stbenjam I took a look at how we can handle colliding files/units, and I think we'll need to add some logic to track the append index for each filename, then insert instead of append when we find a colliding name.

Since that's logically separate from this change, and we don't yet have any colliding files, perhaps that can be a followup if/when needed?

@stbenjam
Copy link
Member

stbenjam commented Jun 12, 2019

Sure, sounds good to me.

I also agree with deferring the move to _base - it'd be very painful to rebase if any of those files change.

@hardys
Copy link
Author

hardys commented Jun 13, 2019

@celebdor, @yboaron @cybertron can you check you're happy with this as it touches the keepalived and coredns integration, also please can you confirm if this will close both #62 and #64 ?

If you're happy then I think we're probably good to merge this.

Copy link
Contributor

@cybertron cybertron left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like this does wrap up the installer parts of those changes. The behavior here mirrors what happens in MCO for platform-specific files, so lgtm.

"systemd-journal-gatewayd.socket": {},
"approve-csr.service": {},
// baremetal platform services
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Long term our plan is to move away from using systemd services on the bootstrap node too, but in the meantime this looks good.

@stbenjam stbenjam merged commit 27dc191 into openshift-metal3:master Jun 14, 2019
hardys pushed a commit to hardys/kni-installer that referenced this pull request Jun 19, 2019
…etal

These were missed in openshift-metal3#102
and were added as part of the baremetal integration.
hardys pushed a commit to hardys/kni-installer that referenced this pull request Jun 19, 2019
These were missed in openshift-metal3#102
and were added as part of the baremetal integration.
stbenjam pushed a commit that referenced this pull request Jun 21, 2019

Verified

This commit was signed with the committer’s verified signature.
stbenjam Stephen Benjamin
These were missed in #102
and were added as part of the baremetal integration.
stbenjam pushed a commit to stbenjam/kni-installer that referenced this pull request Jun 21, 2019

Verified

This commit was signed with the committer’s verified signature.
stbenjam Stephen Benjamin
These were missed in openshift-metal3#102
and were added as part of the baremetal integration.
stbenjam pushed a commit to stbenjam/kni-installer that referenced this pull request Jul 1, 2019

Verified

This commit was signed with the committer’s verified signature.
stbenjam Stephen Benjamin
These were missed in openshift-metal3#102
and were added as part of the baremetal integration.
stbenjam pushed a commit to stbenjam/kni-installer that referenced this pull request Jul 3, 2019

Verified

This commit was signed with the committer’s verified signature.
stbenjam Stephen Benjamin
These were missed in openshift-metal3#102
and were added as part of the baremetal integration.
markmc pushed a commit to markmc/kni-installer that referenced this pull request Jul 8, 2019
These were missed in openshift-metal3#102
and were added as part of the baremetal integration.
markmc pushed a commit that referenced this pull request Jul 8, 2019
These were missed in #102
and were added as part of the baremetal integration.
hardys pushed a commit to hardys/kni-installer that referenced this pull request Jul 12, 2019
These were missed in openshift-metal3#102
and were added as part of the baremetal integration.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Complete addition of coredns-mdns integration to installer
5 participants