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

Do not retrieve users in each goal state #1935

Merged
merged 6 commits into from
Jul 9, 2020

Conversation

narrieta
Copy link
Member

@narrieta narrieta commented Jul 6, 2020

The remote access handler retrieves the list of users on the VM when the goal state doesn't include any jit users (this is done to remove the jit accounts).

Retrieving the users can be extremely slow in some environments and currently it is done an each goal state.

I introduced a flag so that now we retrieve the users only on the first goal state after service start or when the agent has actually created jit accounts.

@@ -1,53 +0,0 @@
# Copyright Microsoft Corporation
Copy link
Member Author

Choose a reason for hiding this comment

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

this mock is specialized for the remote access tests so i moved it there

@codecov
Copy link

codecov bot commented Jul 6, 2020

Codecov Report

Merging #1935 into develop will decrease coverage by 0.02%.
The diff coverage is 83.87%.

Impacted file tree graph

@@             Coverage Diff             @@
##           develop    #1935      +/-   ##
===========================================
- Coverage    69.59%   69.56%   -0.03%     
===========================================
  Files           85       85              
  Lines        11918    11907      -11     
  Branches      1670     1673       +3     
===========================================
- Hits          8294     8283      -11     
+ Misses        3253     3252       -1     
- Partials       371      372       +1     
Impacted Files Coverage Δ
azurelinuxagent/common/exception.py 98.83% <ø> (-0.04%) ⬇️
azurelinuxagent/ga/remoteaccess.py 88.00% <83.87%> (-0.89%) ⬇️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 4785b6b...c2d0b26. Read the comment docs.

for data in TestRemoteAccessHandler.eventing_data:
del data

# add_user tests
@patch('azurelinuxagent.common.logger.Logger.info', side_effect=log_info)
Copy link
Member Author

Choose a reason for hiding this comment

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

No point in testing the log statements, removed these checks from the tests

except RemoteAccessError as rae:
self.err_message = self.err_message + "Error removing user {0}. Exception: {1}"\
.format(user, ustr(rae))
self._remove_user(user)
Copy link
Contributor

Choose a reason for hiding this comment

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

Don't we want to keep the log when we are removing the user?

Copy link
Contributor

Choose a reason for hiding this comment

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

You are logging it when removing below on L122.

Copy link
Member Author

Choose a reason for hiding this comment

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

_remove_user does the logging; 122 is a left-over, will remove it

raise Exception("test exception for bad username")
if username in self.all_users:
raise Exception("test exception, user already exists")
self.all_users[username] = (username, None, None, None, comment, None, None, expiration)
Copy link
Contributor

Choose a reason for hiding this comment

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

Would a named tuple be better here (line 41)? I'm having trouble understanding what all the "None"s are.

Copy link
Member Author

Choose a reason for hiding this comment

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

yes, probably. the existing tests need many improvements. i did several improvements as part of this pr and i may do more if i touch this code in the future.

Copy link
Member Author

Choose a reason for hiding this comment

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

(btw i moved this mock from the common utils directory to this specific test, since its functionality is limited to the remote access tests)

tstuser = "foobar"
expiration_date = datetime.utcnow() + timedelta(days=1)
pwd = tstpassword
rah._add_user(tstuser, pwd, expiration_date)
Copy link
Contributor

Choose a reason for hiding this comment

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

Probably (definitely) out of the scope of this PR, but this should ideally call "run()" instead of a private method (lines 97, 114, 126, etc...). Is it worth capturing this as a future task, or should we just make the changes if these tests break?

Copy link
Member Author

Choose a reason for hiding this comment

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

Yes, most of those tests need rewriting and unfortunately that is very common across most of the code base so opening tasks could be unmanageable. I tend to do improvements as I touch related code, many times I span the improvements over several iterations of the code.

Copy link
Member Author

Choose a reason for hiding this comment

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

Of course, if a test breaks while changing the prod code we need to address that immediately. When that happens to you, try to evaluate whether the broken test adds any value, on several occasions I've found fixing broken tests is not worth the effort (they may be redundant, test private implementation, etc)

larohra
larohra previously approved these changes Jul 8, 2020
Copy link
Contributor

@larohra larohra left a comment

Choose a reason for hiding this comment

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

LGTM

Copy link
Contributor

@larohra larohra left a comment

Choose a reason for hiding this comment

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

LGTM

@narrieta narrieta merged commit f8d8376 into Azure:develop Jul 9, 2020
@narrieta narrieta deleted the remote-access branch July 9, 2020 16:55
@narrieta narrieta mentioned this pull request Aug 4, 2020
6 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants