-
Notifications
You must be signed in to change notification settings - Fork 12
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
[DPE-2242] Add kafka upgrade #120
Conversation
646e793
to
f8f0fb5
Compare
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.
Code-wise looks good! Just some small points/nipticks.
I'm actually testing this right now, but we can probably merge this PR even if I did not finish to test, as it may take also part of next week
src/literals.py
Outdated
DEPENDENCIES = { | ||
"service": { | ||
"dependencies": {"zookeeper": ">3"}, | ||
"name": "kafka", | ||
"upgrade_supported": ">3", | ||
"version": "3.3", | ||
}, | ||
} |
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.
todo: I think here - to be safe - we should use a carets because we don't know what major-level version changes will do to compatibility in the future, and the specific version of ZooKeeper shipped with this Kafka version, AND the specific version of Kafka.
So that would be:
zookeeper ^3.6
(i.e support up to 4.0)version 3.3.2
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.
Ah, good catch. This was an oversight from testing probably. Thanks!
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.
Having ^3.6 means that exactly 3.6 would fail no? So upgrading back to 3.6 in case of an error would fail requirements.
Saying because I ran the unit tests with mock on zk version:
patch(
"upgrade.KafkaUpgrade.zookeeper_current_version",
new_callable=PropertyMock,
return_value="3.6",
)
# leads to the unit test failing:
ERROR upgrade:upgrade.py:86 Current ZooKeeper version 3.6 does not meet requirement ^3.6
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.
zookeeper ^3.6 (i.e support up to 4.0)
I'm not sure we should allow zookeeper to be updated to 3.8... Didn't we try this out already and failed to get it working?
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.
@zmraul That might be a bug in the requirement verification!
Gimme a moment to look at 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.
On this one
"version": "3.3"
If I have understood the code correctly, this number will go all the way down to be specified in the protocol version field of the properties file, which should only be major.minor. We should either rollback this change or change the logic in the properties such that we strip patch number in the protocol version
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.
You are right, I forgot about this. I'm not sure it is a problem for the properties. The Kafka docs don't say "use exactly major.minor
". And they don't advise against having the full version either. I'll check manually to see if there is a problem with 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.
I'm not sure I have ever come across any "major.minor.patch" specification for the protocol version. Can we check if we find any (reliable) reference about using major.minor.patch?
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.
@zmraul - That bug has been resolved and merged - canonical/data-platform-libs#86
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.
@deusebio @marcoppenheimer I think both issues have been addressed on the last commit: 4d8172b
Re-requesting review just for that one.
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.
Great stuff!
src/config.py
Outdated
major_minor = self.charm.upgrade.current_version.split(".", maxsplit=2) | ||
major_minor.pop() | ||
return ".".join(major_minor) |
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.
nitpick: Could we use indexing here?
major_minor = self.charm.upgrade.current_version.split(".")
return ".".join(major_minor[:-1])
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 believe it safer the one proposed by Raul as we should rather stick to major.minor, if we ever had a 3.2.1.1, using the other would result in a major.minor.patch version, which we don't want
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.
Then we could do major_minor[:2]
no?
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.
Indexing is not so clear directly on the string, because version might be 10.11.2
one day, so [:-1] or [:2] would not work at some point
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.
major_minor
is a list though right?
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.
Ah yes sorry. I was thinking about using indexing directly on the string.
LGTM |
In-place upgrade for Kafka. Based of ZK upgrade.
Changes from ZK upgrade
_on_upgrade_granted
function. If the requirement is not met, the unit will be set tofailed
.srvr
command on the zookeeper leader.verify_requirements
function from theupgrade
lib.Manual testing
This is the same as in zookeeper, but with the extra relation: