Skip to content

Conversation

@runcom
Copy link
Member

@runcom runcom commented Mar 26, 2019

  • we're still waiting on a tag to fix Gopkg.toml to use a tag (News 2.0.0 coreos/ignition#773)
  • I still have to polish functions and address some todos but want to see if logic is right first

Signed-off-by: Antonio Murdaca [email protected]

@openshift-ci-robot openshift-ci-robot added the size/XXL Denotes a PR that changes 1000+ lines, ignoring generated files. label Mar 26, 2019
@openshift-ci-robot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: runcom
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approver: crawford

If they are not already assigned, you can assign the PR to them by writing /assign @crawford in a comment when ready.

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@runcom
Copy link
Member Author

runcom commented Mar 26, 2019

/hold

This is not going to pass until MCO/RHCOS are done with the move as well

@wking @abhinavdahiya @crawford @ashcrow @cgwalters @jlebon @ajeddeloh ptal

@openshift-ci-robot openshift-ci-robot added the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Mar 26, 2019
@wking
Copy link
Member

wking commented Mar 26, 2019

Can you split the vendor bump out into a separate commit (like this), so we can more easily review the changes you made without having the changes dep made mixed in?

@runcom
Copy link
Member Author

runcom commented Mar 26, 2019

Can you split the vendor bump out into a separate commit (like this), so we can more easily review the changes you made without having the changes dep made mixed in?

done

Copy link
Member

Choose a reason for hiding this comment

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

Instead of setting up ign and then, in the append case, immediately clobbering it, I'd rather have:

var ign whateverTypeThisShouldBe
if appendToFile {
  ign = ignition.FileAppendFromBytes(strings.TrimSuffix(base, ".template"), "root", mode, data)
} else {
  ign = ignition.FileFromBytes(strings.TrimSuffix(base, ".template"), "root", mode, data)
}

Or we should update FileFromBytes to support an append parameter, or an options struct parameter, or some such...

Copy link
Member Author

Choose a reason for hiding this comment

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

yeah, I've already accounted for that, just want to validate that the v3 way of doing append is how I did @ajeddeloh

Choose a reason for hiding this comment

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

yeah this looks good.

Choose a reason for hiding this comment

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

Actually, in the case of appending you'll want to make sure a file entry doesn't already exist at that path. In that case you'll need to add the append entry to it's append list.

Copy link
Member

Choose a reason for hiding this comment

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

Actually, in the case of appending you'll want to make sure a file entry doesn't already exist at that path.

This helper is for our internal use, so we can probably ignore that case. Will Ignition crash and burn if this happens, so we can fail out in CI if by some programmer mistake we have two entries for the same file?

Choose a reason for hiding this comment

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

Ignition will crash and burn at validation time (note: you can call the validation function ahead of time) since there will be two file entries with the same path

Copy link
Contributor

Choose a reason for hiding this comment

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

nit: no need for func.
https://play.golang.org/p/kM-DWZ9yCXN

package main

import (
	"fmt"
	"net/url"
)

func main() {
	u := (&url.URL{
		Scheme: "https",
		Host:   fmt.Sprintf("api.%s:22623", "adahiya-0.tt.testing"),
		Path:   fmt.Sprintf("/config/%s", "master"),
	}).String()
	fmt.Println(u)
}

Copy link
Member

Choose a reason for hiding this comment

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

@staebler, looks like this function approach was yours in #206. Do you remember why you took this route? It seems complicated for a string pointer, vs:

source := fmt.Sprintf("https://api.%s:22623/config/%s", installConfig.ClusterDomain(), role)

Copy link
Contributor

Choose a reason for hiding this comment

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

I don't think that was authored by me. That was authored by @crawford.

@ajeddeloh
Copy link

Would it be possible to add validation (via github.com/coreos/ignition/config/validate.ValidateWithoutSource()) to the final result in this PR. Would be a good check to ensure we're not hitting weird cases.

@wking
Copy link
Member

wking commented Mar 26, 2019

Would it be possible to add validation...

I'm comfortable with e2e suites in CI to cover installer-generated Ignition content. That leaves users who supply their own Ignition files as part of a multi-step install? I'm ok handling that in a separate PR.

Signed-off-by: Antonio Murdaca <[email protected]>
@runcom runcom force-pushed the ign-v3 branch 3 times, most recently from 0ae9143 to b5dcbf6 Compare March 28, 2019 21:17
@eparis
Copy link
Member

eparis commented Mar 29, 2019

/hold
As this PR (in conjunction with others) would break the upgrades we are promising customers after beta3 it may not merge.

@cgwalters
Copy link
Member

As this PR (in conjunction with others) would break the upgrades we are promising customers after beta3 it may not merge.

We put a good amount of work into this and think we can pull it off fairly quickly.

Signed-off-by: Antonio Murdaca <[email protected]>
@ashcrow
Copy link
Member

ashcrow commented Mar 29, 2019

As this PR (in conjunction with others) would break the upgrades we are promising customers after beta3 it may not merge.

We put a good amount of work into this and think we can pull it off fairly quickly.

Agreed.

kikisdeliveryservice added a commit to kikisdeliveryservice/machine-config-operator that referenced this pull request Mar 29, 2019
Updating MC* to use ignition v3. The following changes are included:
- ssh keys now written to /home/core/.ssh/authorized_keys.d/ignition
- code changes to use v3 and remove usage of v2.2.0
- unit and e2e test updates
- updated golden files
- remove the use of container-linux-config-transpiler in render.go and
  use v3 types instead

Requires: openshift/installer#1468
Closes: openshift#565
@wking
Copy link
Member

wking commented Apr 1, 2019

I realize this is on hold, but when we revive it we need to bump the AWS UPI template too.

@openshift-ci-robot
Copy link
Contributor

@runcom: PR needs rebase.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

@openshift-ci-robot openshift-ci-robot added the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Apr 15, 2019
@openshift-ci-robot
Copy link
Contributor

@runcom: The following tests failed, say /retest to rerun them all:

Test name Commit Details Rerun command
ci/prow/unit 7b47364 link /test unit
ci/prow/e2e-aws 7b47364 link /test e2e-aws
ci/prow/e2e-aws-upgrade 7b47364 link /test e2e-aws-upgrade

Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@abhinavdahiya
Copy link
Contributor

This looks abandoned. Please feel free to reopen if you think this is still something you would like to pursue

/close

@openshift-ci-robot
Copy link
Contributor

@abhinavdahiya: Closed this PR.

Details

In response to this:

This looks abandoned. Please feel free to reopen if you think this is still something you would like to pursue

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. size/XXL Denotes a PR that changes 1000+ lines, ignoring generated files.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

9 participants