The test will trigger backup-and-restore by calling DELETE /v2/leader?backup=... and check if the
operation could run successfully e.g. backup file exists and is valid, marathon reelection was successful etc.
Related: MARATHON-7289
jeschkies | |
kensipe | |
aquamatthias | |
jenkins |
The test will trigger backup-and-restore by calling DELETE /v2/leader?backup=... and check if the
operation could run successfully e.g. backup file exists and is valid, marathon reelection was successful etc.
Related: MARATHON-7289
si
Automatic diff as part of commit; lint not applicable. |
Automatic diff as part of commit; unit tests not applicable. |
✔ Build of 3143 completed at https://jenkins.mesosphere.com/service/jenkins/job/public-marathon-phabricator-pipeline/722/
.python-version | ||
---|---|---|
1 ↗ | (On Diff #3143) | can we not fight on this ? lets consolidate on a version if you are using pyenv. I've upgraded mine. mainly because dcos-cli requires 3.5. |
tests/system/test_marathon_root.py | ||
230 | I would prefer if we add this functionality to marathon.py of the dcos-cli project. if you like... I can do it. | |
235 | totally agree on the check for task id | |
238 | I'm not understanding this.. does the backup create a tar on the marathon leader? I didn't look at the code, but this looks like a good assumption based on the code . running this command on the "master" is a bad idea and will likely result in flaky tests results (sometimes succeeding and sometimes not). Your assumption is good on a single master cluster. However on a multi-master it is flaky. You need to make sure to execute this command on the node that tar was created on. is it the previous leader? It seems likely you will need the mom_ip. I just recently added in the ability to get marathon_leader_ip. |
tests/system/test_marathon_root.py | ||
---|---|---|
204 | not an issue... but all previous approaches of creating "random" chars have been done with uuid app_id = uuid.uuid4().hex https://github.com/mesosphere/marathon/blob/master/tests/system/marathon_common_tests.py#L28 |
tests/system/test_marathon_root.py | ||
---|---|---|
201 | this test needs to skip if the marathon is less than X where X is the version that defines this behavior. |
tests/system/test_marathon_root.py | ||
---|---|---|
201 | also @masters(1) doesn't skip this test if there are more than 1 master... if fact @master(1) is pretty useless. it says there must be 1 master... which is always true if there is a working cluster. |
All critique points addressed.
tests/system/test_marathon_root.py | ||
---|---|---|
201 | That's a good catch. Thx! | |
204 | Uuids are good as app_ids but feel less useful as filenames. Actually we don't need random filename at all - it was just for testing (on the same cluster). I'll remove. | |
230 | I agree - v2/leader endpoint is not yet represented in the cli. But I don't think this is in scope of 1.10 for me. | |
238 | That's why I (incorrectly) used @masters(1) annotation. Fixed. |
this test needs to skip if the marathon is less than X where X is the version that defines this behavior.