How is metaparticle expected to interact with CI/CD?

[brendandburns]

An important (and open) question.

Proposals wanted!

[stealthybox]

Maybe executing the binary with a detach flag could be good?
Return code would naturally reflect whether the application is running properly in the provider.

The provider (k8s/swarm/aci) could decide whether cleanup is necessary for resources in the failure case, or this could be exposed as a flag.

Just brainstorming.

[brendandburns]

Yeah, I think that's a great idea!

I might use an environment variable instead of a flag, since flags would require munging the command line. Want to send a PR?

Thanks!

[ahaeber]

Looking at the Java implementation, it seems like Metaparticle is bootstrapped by invoking the Containerize method. And that method checks whether it should execute the method itself, or build & deploy. I would prefer to not having to invoke that method in my code. It makes the code harder to understand and debug.

Why not make an annotation processor for this instead? It mainly needs to look at the annotations anyways. That gets the bootstrapping out of the application code, but you still have the annotations present in the code with container and runtime config.

[brendandburns]

Do you have pointers for how to do this? I looked into it when I started to design, and it honestly looked super complicated to implement and I didn't have the cycles to figure out how to do it. If you have the knowledge necessary to do it, or have pointers to a good tutorial/library that I could lean on, I definitely agree that it is a better design. Thanks!

…

--brendan

________________________________________ From: Andreas Häber <notifications@github.com> Sent: Thursday, January 11, 2018 1:38 PM To: metaparticle-io/package Cc: Brendan Burns; Author Subject: Re: [metaparticle-io/package] How is metaparticle expected to interact with CI/CD? (#49) Looking at the Java implementation, it seems like Metaparticle is bootstrapped by invoking the Containerize method. And that method checks whether it should execute the method itself, or build & deploy. I would prefer to not having to invoke that method in my code. It makes the code harder to understand and debug. Why not make an annotation processor for this instead? It mainly needs to look at the annotations anyways. That gets the bootstrapping out of the application code, but you still have the annotations present in the code with container and runtime config. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmetaparticle-io%2Fpackage%2Fissues%2F49%23issuecomment-357069322&data=02%7C01%7Cbburns%40microsoft.com%7Ce8922a01dda34df603fd08d5593b96bf%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636513034827229204&sdata=xHSzXDl1w62UMzU7Q8RZtab9ydAlNN9yh9zEy7GcnnM%3D&reserved=0>, or mute the thread<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAFfDgr4I3Tgd5P62EiCXTRCojZYPxE6Eks5tJn84gaJpZM4RGdvp&data=02%7C01%7Cbburns%40microsoft.com%7Ce8922a01dda34df603fd08d5593b96bf%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636513034827229204&sdata=99GdneChbClu4ZpkVtA5Pl1ouWIxD3F4cHANRQTkk3U%3D&reserved=0>.

[ahaeber]

Glad you like the approach. Fortunately there are some helpful tools to make it easier, like Google's auto-service. See http://www.baeldung.com/java-annotation-processing-builder for a tutorial that also links to docs for auto-service. I can try to make a Metaparticle annotation processor too, but not sure how much time I'll have available for that right now.

[ahaeber]

@brendandburns started on the annotation processor in the commit above. Got the annotation processor plumbing added including a unit test, but does not work yet.

[srini85]

@stealthybox, @brendandburns

Maybe executing the binary with a detach flag could be good?
Return code would naturally reflect whether the application is running properly in the provider.

Would it need to run in detached more or not run at all? CI pipeline may just finish after building and publishing the image right?

[srini85]

@brendandburns - had an attempt at using environment variable for the dotnet version.

See Pull request
#71

[ahaeber]

@brendandburns After trying out a few options with the Java Annotation Processor I found that it is the wrong place to containerize applications. We're inspecting classes (bits and pieces of the application) so we don't have the full picture here. Maybe package-annotations could be better, like:
package-info.java:

@Runtime(...)
@Package(...)
package io.metaparticle.example.chatserver

However, we don't know anything about its dependencies here. And I think it will be too cumbersome to add that.

I looked a little at the new jlink-facility in Java 9, so we're at the module level. However we still don't have the complete application available to containerize here. Also found that Oracle already considered using using jlink to create Docker containers but found that it didn't give any real benefits (https://bugs.openjdk.java.net/browse/JDK-8190739).

[wagoodman]

Just summarizing the above highlighted needed features: For CI/CD I'll need individual independent operations for at least:

• building a docker image
• pushing a docker image
• deploying a docker container + detaching

I vote we try a simpler approach first, then go from there. Anyone have any functional reasons why we shouldn't do this with just environment variables? Say:

• if METAPARTICLE_CI_BUILD == true then ONLY build
• if METAPARTICLE_CI_PUSH == true then ONLY push the image
• if METAPARTICLE_CI_DEPLOY == true then ONLY deploy and don't follow logs (however, the return code should reflect the final deployment status... which implies it should wait for a steady state after all probes have completed successfully).