-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
add server version to ark version
output
#1116
Conversation
This lgtm. |
pkg/apis/ark/v1/status_request.go
Outdated
// by the StatusRequestController. | ||
ProcessedTimestamp metav1.Time `json:"processedTimestamp"` | ||
|
||
// ServerVersion is the version of the Ark binary that the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
// ServerVersion is the version of the Ark binary that the | |
// ServerVersion is the Ark server version. |
Would appreciate another look at this when folks have a chance now that I've implemented the server-side logic. I did a couple of things differently than our existing patterns and would like input on whether they're good changes:
Still need to do the client-side updates to |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Took a quick look. 👍
fa40cc1
to
8dacd0e
Compare
Added client code. The output currently looks something like:
|
Should we add a |
I included one :) |
My bad!
…On Thu, Dec 6, 2018 at 5:27 PM Steve Kriss ***@***.***> wrote:
I included one :)
—
You are receiving this because you are on a team that was mentioned.
Reply to this email directly, view it on GitHub
<#1116 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAABYiO_4c2wXSq4Fkmu4pJeBt7sHxQQks5u2ZnJgaJpZM4ZDKth>
.
|
ark version
outputark version
output
rebased |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good 👍
pkg/apis/ark/v1/status_request.go
Outdated
|
||
// StatusRequest is a request to access current status information about | ||
// the Ark server. | ||
type StatusRequest struct { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it worth calling this ServerStatusRequest?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🤷♂️ I think I'm fine either way - strong feelings? Anyone else?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like being more specific as opposed to less
pkg/apis/ark/v1/status_request.go
Outdated
Phase StatusRequestPhase `json:"phase"` | ||
|
||
// ProcessedTimestamp is when the StatusRequest was processed | ||
// by the StatusRequestController. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would omit the controller detail - that's not something an end user would want or need to know about.
pkg/builder/status_request.go
Outdated
limitations under the License. | ||
*/ | ||
|
||
package builder |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you anticipate we'll add more builders over time? If so, maybe this organization would make more sense?
pkg/builders/
statusrequest
someothertype
and then in each package, we'd have a plain Builder
type along with NewBuilder
, e.g.
package statusrequest
type Builder struct {}
func NewBuilder() *Builder {}
We could even align on a common function name to spit out the underlying object - perhaps Build()
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Or if we're afraid that pkg/builders/backup
would conflict with var backup *v1.Backup
, we could suffix all builder packages with builder
- pkg/builders/backupbuilder
and then instead of saying backupbuilder.NewBuilder()
it would just be backupbuilder.New()
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I do expect we'd add more, yes; over time, I'd like this to replace the existing test obj helpers and be a little more succinct and standardized.
What's the motivation for having a subpackage per type? I'm not sure on that aspect yet.
+1 for renaming to Build()
to get the obj
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was hoping to eliminate the duplication of "builder(s)" in builders.NewStatusRequestBuilder
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
maybe it should just go into pkg/statusrequest
, as a type Builder struct
and NewBuilder()
constructor? And over time as we relocate controller logic into separate packages, each of those can define their own?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That seems reasonable. Although we'll have problems with single-word types, such as backup
and restore
(trying to use as both a variable name and package name).
pkg/cmd/version/version.go
Outdated
) | ||
|
||
func NewCommand() *cobra.Command { | ||
func NewCommand(f client.Factory) *cobra.Command { | ||
timeout := time.Minute |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would default this to 3 to 5 seconds
pkg/cmd/version/version.go
Outdated
fmt.Printf("Version: %s\n", buildinfo.Version) | ||
fmt.Printf("Git commit: %s\n", buildinfo.FormattedGitSHA()) | ||
Run: func(c *cobra.Command, args []string) { | ||
fmt.Println("Client:") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I know we haven't done this much (if any) to date, but is this worth splitting out into its own function so we can unit test it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, refactored & added a unit test for what I think is the important part. PTAL.
} | ||
defer client.StatusRequests(namespace).Delete(created.Name, nil) | ||
|
||
listOptions := metav1.ListOptions{ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We have this same logic in downloadrequest.Stream()
. It might be nice in the future to extract this to a helper, with a custom handler function to call in the watch.Modified
case.
pkg/statusrequest/process.go
Outdated
arkv1client "github.com/heptio/ark/pkg/generated/clientset/versioned/typed/ark/v1" | ||
) | ||
|
||
const ttl = time.Hour |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
1 minute is probably sufficient, especially if we change the default client-side timeout to 3 or 5 seconds.
} | ||
|
||
for _, req := range items { | ||
if req.Status.Phase == arkv1api.StatusRequestPhaseProcessed { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it worth readding everything, not just processed ones?
addressed most of the comments in new commits - still thinking about unit testing of the CLI run func |
Could you include a changelog entry? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Lgtm 👍
@ncdc could you take another look here? your comments should all be addressed. will squash before merge. |
@skriss did another pass. |
Changes made. Anything else? Will do some retesting this aft as well. |
LGTM
|
tests LGTM. |
Signed-off-by: Steve Kriss <[email protected]>
squished. |
Signed-off-by: Steve Kriss [email protected]
Fixes #770
Would appreciate a quick review on the CRD definition before I proceed with the rest of the PR.
cc @heptio/ark-team