- additional unit tests for networking migration
- some additional protobuf helpers
- fixes for app/container conversion
Details
- Reviewers
aquamatthias timcharper jenkins • jasongilanfarr - Commits
- rMARATHON2d31b4f83926: unit tests (and fixes) for networking migration
rMARATHON8f435300e719: unit tests (and fixes) for networking migration
rMARATHON11537361898d: unit tests (and fixes) for networking migration
rMARATHON2646e7643e5f: unit tests (and fixes) for networking migration
rMARATHON2b81cb4bfecd: unit tests (and fixes) for networking migration
rMARATHON1b0cd4c2f6cb: unit tests (and fixes) for networking migration
rMARATHON6d83c343b2f7: unit tests (and fixes) for networking migration - JIRA Issues
- JIRA MARATHON-7032 Unit testing needed for app migration added for D201 network overhaul
sbt test
Diff Detail
- Repository
- rMARATHON marathon
- Lint
Automatic diff as part of commit; lint not applicable. - Unit
Automatic diff as part of commit; unit tests not applicable.
Not sure what Jenkins is complaining about. But I've got more changes coming anyway...
Build has FAILED
Link to build: https://jenkins.mesosphere.com/service/jenkins/job/public-test-marathon-phabricator/1969/
See console output for more information: https://jenkins.mesosphere.com/service/jenkins/job/public-test-marathon-phabricator/1969/console
Build is green https://jenkins.mesosphere.com/service/jenkins/job/public-test-marathon-phabricator/1974/ for more details.
I imported a state that is runnable with 1.4, applied your patch to master and started this version.
The migration failed with:
Caused by: mesosphere.marathon.ValidationFailedException: Validation failed: Failure(Set(GroupViolation(Set(MON_GROUP, framework-id, SERVERPORT, FORWARDHOST, MON_APP, id, MON_CONTACT, SERVICENAME, MON_PIPE_ID, dns-proxy-pool, FORWARDPORT, EXTADDR, transparent, EXTNETNAME, ETCDENDPOINT, IO, ext-dns-server, LISTENPORT),contains elements, which are not valid.,Some(env),Set(GroupViolation(ext-dns-server,not valid,Some((15)),Set(RuleViolation(ext-dns-server,must contain only alphanumeric chars or underscore, and must not begin with a number,Some(value)))), GroupViolation(dns-proxy-pool,not valid,Some((12)),Set(RuleViolation(dns-proxy-pool,must contain only alphanumeric chars or underscore, and must not begin with a number,Some(value)))), GroupViolation(framework-id,not valid,Some((6)),Set(RuleViolation(framework-id,must contain only alphanumeric chars or underscore, and must not begin with a number,Some(value))))))))
You can do the same by
- downloading/extracting: https://drive.google.com/a/mesosphere.io/file/d/0B4MZvhoJUyX6NTR4MzRMc2pmc0U/view?usp=sharing
- import into zk: docker run -it -v /path/to/backup:/root/universe mesosphere/dcos-debug java -jar /root/guano/target/guano-0.1a.jar -s yourzk:2181 -r /universe -i /root/universe/
- run your migration
src/main/scala/mesosphere/marathon/raml/AppConversion.scala | ||
---|---|---|
351 | If this is specific to proto handling, should this code be part of AppDefinition.fromProto? | |
src/main/scala/mesosphere/marathon/raml/ContainerConversion.scala | ||
199 | The idea with obsolete was: it is only used in Migration code. Why do we need this here? |
src/main/scala/mesosphere/marathon/raml/AppConversion.scala | ||
---|---|---|
351 | no because AppDefinition.fromProto converts from protobuf-to-model. This code converts from protobuf-to-RAML -- different semantics. | |
src/main/scala/mesosphere/marathon/raml/ContainerConversion.scala | ||
199 | because the migration code leverages protobuf-to-RAML conversions for the migration. I added the conversion funcs to our existing xxxConversion classes. |
looks like the app has environment variable names that contain hyphens. how did we ever get here?
D201 introduced stronger environment variable name validation. model validation is pretty lax for envvar names: https://github.com/mesosphere/marathon/blob/releases/1.4/src/main/scala/mesosphere/marathon/state/EnvVarValue.scala#L56
[info] Caused by: mesosphere.marathon.ValidationFailedException: Validation failed: Failure(Set(RuleViolation(List(hostname, CLUSTER),Missing value,Some(constraints)))) [info] at mesosphere.marathon.api.v2.Validation$class.validateOrThrow(Validation.scala:23) [info] at mesosphere.marathon.api.v2.Validation$.validateOrThrow(Validation.scala:304) [info] at mesosphere.marathon.api.v2.AppsResource$$anonfun$appNormalization$1.apply(AppsResource.scala:409) [info] at mesosphere.marathon.api.v2.AppsResource$$anonfun$appNormalization$1.apply(AppsResource.scala:406) [info] at mesosphere.marathon.Normalization$$anon$1.normalized(Normalization.scala:15) [info] at mesosphere.marathon.Normalization$Normalized$.normalize$extension(Normalization.scala:11) [info] at mesosphere.marathon.storage.migration.MigrationTo1_5$$anonfun$migrateServiceFlow$1.apply(MigrationTo1_5.scala:113) [info] at mesosphere.marathon.storage.migration.MigrationTo1_5$$anonfun$migrateServiceFlow$1.apply(MigrationTo1_5.scala:110)
- rMARATHON0a64b1f84c14 sanity check: precise unit tests for envvar conversion, relocate envvar proto-to-RAML conversion
- rMARATHON08a79d58d722 app envvar names should not use strict name validation to avoid API compat breakage
- rebase to master
@aquamatthias your concerns have been addressed. migration of the exported ZK blob now completes successfully
Build is green https://jenkins.mesosphere.com/service/jenkins/job/public-test-marathon-phabricator/2007/ for more details.
src/main/scala/mesosphere/marathon/raml/AppConversion.scala | ||
---|---|---|
351 | there's no need. the state model doesn't define ports (definitions or mappings) wrapped in Option. RAML does, and that's where the complication comes in | |
src/main/scala/mesosphere/marathon/storage/migration/MigrationTo1_5.scala | ||
50 | validation is baked into the AppsResource normalizer; no additional steps needed here |
I applied the migration to the production zk state. The migration now runs successfully - great!
Have you added a test case for all scenarios that failed before?
So we can make sure, we do not run again into this situation?
During the migration, laxer validations are applied.
This leads to a situation, where no change can be applied after the migration, since the validation on the root group fails with:
{ "details": [ { "errors": [ "Missing value" ], "path": "/groups(0)/groups(2)/apps(37)/constraints" }, { "errors": [ "Missing value" ], "path": "/groups(0)/groups(2)/apps(4)/constraints" }, { "errors": [ "Missing value" ], "path": "/groups(0)/groups(2)/apps(36)/constraints" }, { "errors": [ "Missing value" ], "path": "/groups(0)/groups(2)/apps(0)/constraints" } ], "message": "Object is not valid" }
src/main/scala/mesosphere/marathon/api/v2/validation/EnvVarValidation.scala | ||
---|---|---|
23 | This turns env var name validation off for apps. "env": { "&&$G$ ^^^ kjshg dfg dfjkhgdfk g! doo": "marathon" } which should not have been accepted, but passes validation. | |
src/main/scala/mesosphere/marathon/raml/ContainerConversion.scala | ||
199 | Any suggestion to separate the migration path from the standard code path? | |
src/main/scala/mesosphere/marathon/storage/migration/MigrationTo1_5.scala | ||
85 | Please add a short explanation, why current root must be last. |
suspect that constraint validation is failing because the recent constraint "fixes" that landed on master should have removed the largely redundant (but incorrect) validation func in AppDefinition. will create a separate diff for that and rebase this once that lands.
src/main/scala/mesosphere/marathon/api/v2/validation/EnvVarValidation.scala | ||
---|---|---|
23 | ||
src/main/scala/mesosphere/marathon/raml/ContainerConversion.scala | ||
199 | I thought it would be pretty consistent to keep all the RAML conversion code in the same package. I could see, perhaps, segregating the protobuf-to-RAML code into separate conversion classes .. but then I think that complicates maintenance efforts - from a maintenance perspective I'd rather have everything in the same file. do you have any suggestions? we name proto fields OBSOLETE when they've been deprecated and no longer used for new items written to storage. according to that rule, I've named the fields appropriately |
Build is green https://jenkins.mesosphere.com/service/jenkins/job/public-test-marathon-phabricator/2017/ for more details.
Build has FAILED
Link to build: https://jenkins.mesosphere.com/service/jenkins/job/public-test-marathon-phabricator/2018/
See console output for more information: https://jenkins.mesosphere.com/service/jenkins/job/public-test-marathon-phabricator/2018/console
Build has FAILED
Link to build: https://jenkins.mesosphere.com/service/jenkins/job/public-test-marathon-phabricator/2019/
See console output for more information: https://jenkins.mesosphere.com/service/jenkins/job/public-test-marathon-phabricator/2019/console
Build is green https://jenkins.mesosphere.com/service/jenkins/job/public-test-marathon-phabricator/2020/ for more details.
Thanks!
src/test/scala/mesosphere/mesos/protos/ImplicitsSpec.scala | ||
---|---|---|
6 | Nit: please use double package notation. You should not need this import then. |
src/test/scala/mesosphere/mesos/protos/ImplicitsSpec.scala | ||
---|---|---|
6 | double package only applies for mesosphere.marathon packages |
This turns env var name validation off for apps.
I tried to add an env var like this:
which should not have been accepted, but passes validation.