Skip to content
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

Fix global config get for port scan. #2794

Merged
merged 6 commits into from
Oct 15, 2018

Conversation

hjoliver
Copy link
Member

@hjoliver hjoliver commented Oct 13, 2018

Fix #2795 (bug on current master, since last release).

glbl_cfg().get() isn't dict.get().

(maybe was not the best name for that function).

Also removes a cylc scan test that was not actually testing anything anymore.

@hjoliver hjoliver added the bug Something is wrong :( label Oct 13, 2018
@hjoliver hjoliver self-assigned this Oct 13, 2018
@hjoliver hjoliver added this to the next release milestone Oct 13, 2018
@matthewrmshin
Copy link
Contributor

Note I took out the default settings specially. I think it is important to respect the empty setting, e.g. in the dumper and in logical decision in some cases - where the empty list should not be treated the same way as the default list.

(I also suspect that I've done something about default evaluation in #2609.)

@matthewrmshin
Copy link
Contributor

(Or maybe not.)

@hjoliver
Copy link
Member Author

hjoliver commented Oct 14, 2018

Note we have the "--sparse" option to return explicitly set (i.e. non-default) items.

I agree that some default settings should be empty or null. But in this case, if we default to running suite daemons on localhost, is there any reason not to default to scanning localhost? If not, then having to explicitly (and correctly) default to "localhost" at every use of the config item just seems like more chances to make errors, no?

@matthewrmshin
Copy link
Contributor

(Not sure why we were both doing work on a Sunday!) The other problem is that we still need to handle the case when users put an empty value to the setting (so overriding the default). This still needs to be handled by the run time logic, so we might as well move the default to where the run time logic is.

@matthewrmshin
Copy link
Contributor

(But sorry to have broken the logic!)

@hjoliver
Copy link
Member Author

hjoliver commented Oct 15, 2018

No worries. OK, I guess you are saying we should default to "localhost" no matter what - even if the user explicit unsets the hosts list ... and that requires run time defaulting (because a built-in default gets overridden by the user setting). I guess that makes sense, reverting to run time default...

@hjoliver
Copy link
Member Author

hjoliver commented Oct 15, 2018

(mind you, shouldn't that same argument apply to the list of ports, which you still set a built-in default for?)

@hjoliver
Copy link
Member Author

(you win 👍 ... although I think we're not being consistent on this defaulting business.. Maybe #2609 helps, I'm almost on to that review again...)

@matthewrmshin
Copy link
Contributor

Yes, the port setting has the same issue - although it is less likely that users will override it with empty settings. (Another problem I have just realised - on dumping out the configuration - integer ranges get expanded to all values, so we should find a way to tuck them back into a START..END string.)

@sadielbartholomew
Copy link
Collaborator

@hjoliver can you tag me as soon as this is at a stage when there is agreement on an approach & you want me to review the implementation (possibly that is now)? It's not always obvious from the context of the comments if this is the case. Then I will review it as a priority. Thanks :)

@hjoliver
Copy link
Member Author

... - integer ranges get expanded to all values ...

Yeah, that's not nice.

@hjoliver
Copy link
Member Author

@sadielbartholomew - you can go ahead and review this if Matt is happy with the defaulting behaviour now, which I think he is. It's actually a trivial change, it'll take you about 5 mins max 😁

@matthewrmshin
Copy link
Contributor

(Running test in my local environment.)

@matthewrmshin
Copy link
Contributor

(Tests pass in my environment.)

@matthewrmshin
Copy link
Contributor

@sadielbartholomew please review 2.

@sadielbartholomew
Copy link
Collaborator

sadielbartholomew commented Oct 15, 2018

Sorry for the delay. I have just run the full test battery locally with suite servers not defined (it passed, hooray). Just need to ensure it still works with it defined, so now awaiting those test results.

Copy link
Collaborator

@sadielbartholomew sadielbartholomew left a comment

Choose a reason for hiding this comment

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

Fixes specified bug. Sensible fix & all tests pass locally with & without the 'suite servers' section.

(Codacy hanging but Matt & I agree this can be ignored as the changes are fairly trivial in code terms. Safe to merge.)

@sadielbartholomew sadielbartholomew merged commit 1e022bf into cylc:master Oct 15, 2018
@hjoliver hjoliver deleted the fix-scan-ports branch October 15, 2018 20:43
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something is wrong :(
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants