rework of deploy?

55 views
Skip to first unread message

William Burke

unread,
Mar 27, 2023, 1:14:42 PM3/27/23
to Quarkus Development mailing list
I'd like to rework quarks:deploy to be similar to what I did for quarkus:run in my dev branch [1] as I am implementing my own deploy for Azure Functions (and later AWS lambda).


From CLI, it looks like the kubernates flavors never run together: i.e. you wouldn't deploy them at the same time.

So I'd like to do the following:
* Have a "quarkus.deploy.target" like I do for quarkus run.  If there are more than one deployment steps, then the appdev must choose one. (CLI does this).  I will refactor a bunch of code here to clean up the kubernates flavor deploy steps.
* Why does quarkus:deploy run in package phase?  I would imagine you'd want it to be separate and not have to rebuild before deploy, i.e. if you are changing deployment config and don't want to have to rebuild.

--
Bill Burke
Red Hat

Ioannis Canellos

unread,
Mar 28, 2023, 2:01:53 AM3/28/23
to bbu...@redhat.com, Quarkus Development mailing list
On Mon, Mar 27, 2023 at 5:14 PM William Burke <bbu...@redhat.com> wrote:
I'd like to rework quarks:deploy to be similar to what I did for quarkus:run in my dev branch [1] as I am implementing my own deploy for Azure Functions (and later AWS lambda).


We definitely need to align them. I started playing a little bit borrowing the idea of `performCustomBuild` from your pull request: https://github.com/quarkusio/quarkus/pull/31874. At some point I hit some gradle related classloading issues that I didn't have the time to fix.

From CLI, it looks like the kubernates flavors never run together: i.e. you wouldn't deploy them at the same time.
Correct. 

So I'd like to do the following:
* Have a "quarkus.deploy.target" like I do for quarkus run.  If there are more than one deployment steps, then the appdev must choose one. (CLI does this).  I will refactor a bunch of code here to clean up the kubernates flavor deploy steps. 
Yeah, there can only be a single deployment target at a time. AFAIR, The target is either determined by the available extensions, or explicitly by the user. If there are multiple extensions present the user needs to choose one. If there are no extensions, the tooling adds them as forced dependencies.
* Why does quarkus:deploy run in package phase?  I would imagine you'd want it to be separate and not have to rebuild before deploy, i.e. if you are changing deployment config and don't want to have to rebuild.
Mostly, because originally (before adding dev tools support) we didn't have any other way of triggering deployment.


--
Bill Burke
Red Hat

--
You received this message because you are subscribed to the Google Groups "Quarkus Development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to quarkus-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CAL%3DE%3DjRpyN5q_XTmDJH2fKu8n6sPWyU%2BT4OdGkqM_xQnvMW4Aw%40mail.gmail.com.


--

William Burke

unread,
Mar 29, 2023, 12:17:22 PM3/29/23
to Ioannis Canellos, Quarkus Development mailing list
This seems to be the entry point for all kube deploy actions


It also seems that deploy is hard wired into builds (and kubernetes is the only extension that takes advantage of this)


Makes me think I can't unwind this stuff and separate deploy from package as it may break backward compatibility for those that have explicitly wired in kubernetes.  

Stuart Douglas

unread,
Mar 29, 2023, 7:18:26 PM3/29/23
to bbu...@redhat.com, Ioannis Canellos, Quarkus Development mailing list
On Thu, 30 Mar 2023 at 03:17, William Burke <bbu...@redhat.com> wrote:
This seems to be the entry point for all kube deploy actions


It also seems that deploy is hard wired into builds (and kubernetes is the only extension that takes advantage of this)


Makes me think I can't unwind this stuff and separate deploy from package as it may break backward compatibility for those that have explicitly wired in kubernetes.  

I think it should still be possible, but at the moment it is a big limitation that deploy is tied to the build.

If you want to separate it out we will probably need to create some kind of deployment manifest that is generated by the build, that contains all the information needed for a standalone deployment step.

Stuart

 

William Burke

unread,
Mar 30, 2023, 9:28:00 AM3/30/23
to Stuart Douglas, Ioannis Canellos, Quarkus Development mailing list
On Wed, Mar 29, 2023 at 7:18 PM Stuart Douglas <sdou...@redhat.com> wrote:


On Thu, 30 Mar 2023 at 03:17, William Burke <bbu...@redhat.com> wrote:
This seems to be the entry point for all kube deploy actions


It also seems that deploy is hard wired into builds (and kubernetes is the only extension that takes advantage of this)


Makes me think I can't unwind this stuff and separate deploy from package as it may break backward compatibility for those that have explicitly wired in kubernetes.  

I think it should still be possible, but at the moment it is a big limitation that deploy is tied to the build.

If you want to separate it out we will probably need to create some kind of deployment manifest that is generated by the build, that contains all the information needed for a standalone deployment step.


Hmmm, why is it so much more complicated for K8s and a manifest is needed?  For azure functions, I have all the metadata needed (i.e. whether its a uber or thin jar, directory paths, etc.).  I just pull in the build step objects I need (like OutputTargetBuildItem, and config). Isn't it just a matter of unwinding the container/k8s deployments steps to not be dependent on build step objects generated only in a build?  

Ioannis Canellos

unread,
Mar 30, 2023, 2:25:00 PM3/30/23
to William Burke, Stuart Douglas, Quarkus Development mailing list
On Thu, Mar 30, 2023 at 1:27 PM William Burke <bbu...@redhat.com> wrote:
Hmmm, why is it so much more complicated for K8s and a manifest is needed?  For azure functions, I have all the metadata needed (i.e. whether its a uber or thin jar, directory paths, etc.).  I just pull in the build step objects I need (like OutputTargetBuildItem, and config). Isn't it just a matter of unwinding the container/k8s deployments steps to not be dependent on build step objects generated only in a build?  

I am not 100% sure I get what the problem is here. Can't we just perform a custom build that requests the DeploymentResultBuildItem? 


--

Stuart Douglas

unread,
Mar 30, 2023, 11:03:22 PM3/30/23
to Ioannis Canellos, William Burke, Quarkus Development mailing list
If you did that with the current code-base it would rebuild everything again. I think even if you fed in ArtifactResultBuildItem instances as inputs because it is a MultiBuildItem it may still attempt to generate the rest of them, but I am not 100% sure of that, so maybe doing a custom build where you feed in BuildItems that point to the previously created artifacts might work.

Also if there have been application changes between the build and deploy steps you might get some weirdness.

Stuart
 

Ioannis Canellos

unread,
Mar 31, 2023, 12:17:00 AM3/31/23
to Stuart Douglas, William Burke, Quarkus Development mailing list


On Fri, 31 Mar 2023, 6:03 am Stuart Douglas, <sdou...@redhat.com> wrote:

On Fri, 31 Mar 2023 at 05:25, Ioannis Canellos <ioc...@gmail.com> wrote:

On Thu, Mar 30, 2023 at 1:27 PM William Burke <bbu...@redhat.com> wrote:
Hmmm, why is it so much more complicated for K8s and a manifest is needed?  For azure functions, I have all the metadata needed (i.e. whether its a uber or thin jar, directory paths, etc.).  I just pull in the build step objects I need (like OutputTargetBuildItem, and config). Isn't it just a matter of unwinding the container/k8s deployments steps to not be dependent on build step objects generated only in a build?  

I am not 100% sure I get what the problem is here. Can't we just perform a custom build that requests the DeploymentResultBuildItem? 

If you did that with the current code-base it would rebuild everything again. I think even if you fed in ArtifactResultBuildItem instances as inputs because it is a MultiBuildItem it may still attempt to generate the rest of them, but I am not 100% sure of that, so maybe doing a custom build where you feed in BuildItems that point to the previously created artifacts might work.

Is this because container images share build item with jars?  Or is it something else I miss?

William Burke

unread,
Apr 3, 2023, 1:35:24 PM4/3/23
to Stuart Douglas, Ioannis Canellos, Quarkus Development mailing list
On Wed, Mar 29, 2023 at 7:18 PM Stuart Douglas <sdou...@redhat.com> wrote:


On Thu, 30 Mar 2023 at 03:17, William Burke <bbu...@redhat.com> wrote:
This seems to be the entry point for all kube deploy actions


It also seems that deploy is hard wired into builds (and kubernetes is the only extension that takes advantage of this)


Makes me think I can't unwind this stuff and separate deploy from package as it may break backward compatibility for those that have explicitly wired in kubernetes.  

I think it should still be possible, but at the moment it is a big limitation that deploy is tied to the build.


@Stuart Douglas, can we remove deployment from build  now that a quarkus:deploy exists?  This will break backward compatibility for kubernetes as it currently will execute on a normal build (right?) and app devs might not expect this.  My vote is to break backward compatibility.  I may be developing locally for a normal build.

William Burke

unread,
Apr 26, 2023, 4:41:39 PM4/26/23
to Stuart Douglas, Ioannis Canellos, Quarkus Development mailing list
So, I think we have to do the full quarkus augmentation along with a quarkus:deploy.

I didn't know that application.properties is processed during a normal build and copied into target/classes/application.properties.  As a result I was losing my mind as I couldn't figure out why my changes to application.properties weren't reflected in the deploy.

Maybe there is a build step that I can trigger that only rebuilds app.props, but, 
Reply all
Reply to author
Forward
0 new messages