new actions: quarkus:deploy and quarkus:run

[William Burke]

TLDR;  I want to create a new RunMojo and DeployMojo (and gradle equivalent) that delegate to quarkus extension.  I also want bootstrapping a @QuarkusIntegrationTest to also delegate to a quarkus extension.  I saw how "deploy" was added recently.  I'd like to change how its implemented.

I want to replace the azure-functions-maven-plugin.  To do this I need my Quarkus extension to be able to package the quarkus + azure functions project in a special format (easily done and implemented already).  I also need to be able to *run* locally which requires a special azure functions local environment.  I also need to be able to *deploy* to Azure.  Finally, in addition to replacing  the azure-functions-maven-plugin base functionality, I'd also like to be able to *run* an azure function within a @QuarkusIntegrationTest.

FYI, this will also be applicable to AWS Lambda and probably Google Functions too.

For *running* the azure function, I want to create a new RunMojo in quarkus so that you can do:

$ mvn quarkus:run

Why do I want a special *run*? and not just expand *quarkus:dev*? I don't think I'm going to be able to provide continuous testing or dev mode when running in azure functions environment (similarly with aws lambda, etc).

To implement this, quarkus:run would delegate to a quarkus extension by performing a custom build via CuratedApplication (similar to how dev services are launched).  

For *deploying* the azure function, it would work the same as run. Create a DeployMojo that uses a custom build with CuratedApplication to delegate to quarkus extension.

For @QuarkusIntegrationTest, quarkus would just try to use the CuratedApplication to run the app.  If there are no results from that, default to the current way to launch quarkus in an integration test.

Thoughts?

--

Bill Burke

Red Hat

[Daniel Oh]

This is really good stuff that makes the azure function deployment easier for devs. I was wondering if you have the plan to apply for Quarkus CLI as well.

--
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%3DjTWaw4FxDU5oTMWjzuOZaTtEZcfGkvNReMB_Ponw1-ahg%40mail.gmail.com.

--

Daniel oh

Senior PRINCIPAL TECHNICAL MARKETING MANAGER

Red Hat Inc

d...@redhat.com    M: +1-(617)717.8732     @danieloh30

[William Burke]

On Thu, Mar 2, 2023 at 10:20 AM Daniel Oh <d...@redhat.com> wrote:

This is really good stuff that makes the azure function deployment easier for devs. I was wondering if you have the plan to apply for Quarkus CLI as well.

cli deploy already exists and delegates to maven/gradle DeployMojo already.  I would create a similar CLI action for run.

[Loïc MATHIEU]

This would be interesting for all applications. 

For normal apps building the jar and  launching the right Java command would be great. 

As we have a special jar in a special folder this will make it easier, specially for newcomers. 

Running locally on prod mode is something useful so making it easy would be great.

--

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%3DjS9E%2BKbUWaP-Z_4yMCnaPpH4e9Web_Qov_breaocr1WzA%40mail.gmail.com.

[Alexey Loubyansky]

There is https://github.com/quarkusio/quarkus/issues/9315 currently assigned to me but mainly because there was a contributor I couldn't assign it to who wanted to work on it, who later unfortunately moved on to do other things. Feel free to take it, Bill.

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CAJLxjVG%2Bq5ydyUKDovzwSx%3DySv35HcFaAz_4xgvvZ3AWwhh45g%40mail.gmail.com.

[Ioannis Canellos]

Currently, the DeployMojo and DeployTask do not do anything special. They mostly trigger a quarkus build and configure extensions and properties so that are needed for the build.

We could align how deployment works between the kubernetes family of extensions and lambda, so that these tools cover lambda too.

--

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%3DjTWaw4FxDU5oTMWjzuOZaTtEZcfGkvNReMB_Ponw1-ahg%40mail.gmail.com.

--

Ioannis Canellos

[Daniel Oh]

Cool!

[William Burke]

Kube, lambda, azure functions, and probably google CF too all need a custom deploy.

[Ioannis Canellos]

We can have the custom deployment behavior implement it as part of the extensions and have the existing build tools trigger it.

Would you like to schedule a meeting or something to talk about it?

--

Ioannis Canellos

[Max Rydahl Andersen]

> We can have the custom deployment behavior implement it as part of the
> extensions and have the existing build tools trigger it.
> Would you like to schedule a meeting or something to talk about it?

yeah; lets explore options here.

Also we have the plugin and side-loading mechanisms so they do not need to
be as hardly coupled to the extensions anymore.

/max

>>>> <https://groups.google.com/d/msgid/quarkus-dev/CAL%3DE%3DjTWaw4FxDU5oTMWjzuOZaTtEZcfGkvNReMB_Ponw1-ahg%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>>> .
>>>>
>>>
>>>
>>> --
>>> *Ioannis Canellos <http://iocanel.com> *

>>>
>>>
>>>
>>
>> --
>> Bill Burke
>> Red Hat
>>
>
>
> --

> *Ioannis Canellos <http://iocanel.com> *

>
> --
> 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/CADHGh9Uyo8zWwxywKXqMsgevj3vdS1M3eJAG9KLuOZCfyhtBqg%40mail.gmail.com.

[William Burke]

On Thu, Mar 2, 2023 at 3:15 PM Max Rydahl Andersen <mand...@redhat.com> wrote:

> We can have the custom deployment behavior implement it as part of the
> extensions and have the existing build tools trigger it.
> Would you like to schedule a meeting or something to talk about it?

yeah; lets explore options here.

Also we have the plugin and side-loading mechanisms so they do not need to
be as hardly coupled to the extensions anymore.

You mean the CLI has a plugin and side-loading mechanism?   That's not a great approach IMO, especially if i can get right-click IDE integration tests working.

[Stuart Douglas]

We have talked about quarkus:run before: https://groups.google.com/g/quarkus-dev/c/TfaVQH-eXmg/m/Rx2H3kW3AAAJ

At the time I was suggesting we should do it so you could also run a prod application with dev services locally.

Stuart

--

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%3DjTWaw4FxDU5oTMWjzuOZaTtEZcfGkvNReMB_Ponw1-ahg%40mail.gmail.com.

[Max Rydahl Andersen]

Hi Bill,

Adding back quarkus-dev as I accidentally missed to cc it on my reply.

I was more referring to the deploy part for the usage of cli that
currently can add additional extensions if need be (used in the new quarkus
deploy pr)

How's it work? From what's currently committed, it looks like deploy just
pulls together a ton of system properties and such to wrap a $mvn
quarkus:deploy. Are you just adding/pulling in additional extensions to
the maven quarkus:deploy action? I guess you need that because kube deploy
is different from Openshift, vanilla Kube, and Minishift? Azure/Lambda
doesn't have that problem.

Correct - my thinking was that if we could make azure/lambda work similar (via the quarkus:deploy mvn/gradle)
then we wouldn't have to have different ways to trigger the azure function/lambda deploys.

For run - I’m trying to get my head around what that run does. Is it
deploying and then running or simulating a run locally ?

Re-read the OP. For AzureF and Lambda, *run* would spin up the locally
installed Azure/Lambda environment to execute the app. FYI: Lambda can
run in *dev* mode using a mock dev service I wrote, but for JVM deployments
dev mode is not equivalent to actual lambda production.

okey - now I grok it.

I've always been proponents of a quarkus:run option; the easier it is to run the better.

Main objection always been that some tend do use such "run"'s to measure performance -
but we should just make it print out "This is a best effort Run - do not use for performance measurements or click-bait articles" or similar :)

--
Max Andersen

--
Bill Burke
Red Hat

[William Burke]

On Mon, Mar 6, 2023 at 3:19 AM Max Rydahl Andersen <mand...@redhat.com> wrote:

Hi Bill,

Adding back quarkus-dev as I accidentally missed to cc it on my reply.

I was more referring to the deploy part for the usage of cli that
currently can add additional extensions if need be (used in the new quarkus
deploy pr)

How's it work? From what's currently committed, it looks like deploy just
pulls together a ton of system properties and such to wrap a $mvn
quarkus:deploy. Are you just adding/pulling in additional extensions to
the maven quarkus:deploy action? I guess you need that because kube deploy
is different from Openshift, vanilla Kube, and Minishift? Azure/Lambda
doesn't have that problem.

Correct - my thinking was that if we could make azure/lambda work similar (via the quarkus:deploy mvn/gradle)
then we wouldn't have to have different ways to trigger the azure function/lambda deploys.

Ok, I looked at the code, IMO, I would have implemented it differently and kept the maven plugin more generic.  Right now, everything is all hardcoded within quarkus-maven-plugin.  I don't want to be adding knowledge of azure and lambda and every other single deployment environment too.  IMO, the maven plugin should be executing deploy similarly to how @QuarkusIntegrationTest launches Dev Services: nice and generically.

Furthermore, I really hope that what's implemented in CLI as regards to Kube is temporary and evolves to be completely generic as well.  It's also all hardcoded with knowledge of specific deployment environments (all the kube flavors).

 

For run - I’m trying to get my head around what that run does. Is it
deploying and then running or simulating a run locally ?

Re-read the OP. For AzureF and Lambda, *run* would spin up the locally
installed Azure/Lambda environment to execute the app. FYI: Lambda can
run in *dev* mode using a mock dev service I wrote, but for JVM deployments
dev mode is not equivalent to actual lambda production.

okey - now I grok it.

I've always been proponents of a quarkus:run option; the easier it is to run the better.

Main objection always been that some tend do use such "run"'s to measure performance -
but we should just make it print out "This is a best effort Run - do not use for performance measurements or click-bait articles" or similar :)

Or you could just not have a plain Java "run" .  java -jar ./target/runner.jar is pretty easy to type.   A pure Java run could just output to console

"You don't need maven to run a regular quarkus application.  Just execute the following from the command line:

$ java -jar ./target/myapp-runner.jar

"

[Erin Schnabel]

On Mon, Mar 6, 2023 at 11:54 AM William Burke <bbu...@redhat.com> wrote:

On Mon, Mar 6, 2023 at 3:19 AM Max Rydahl Andersen <mand...@redhat.com> wrote:

Hi Bill,

Adding back quarkus-dev as I accidentally missed to cc it on my reply.

I was more referring to the deploy part for the usage of cli that
currently can add additional extensions if need be (used in the new quarkus
deploy pr)

How's it work? From what's currently committed, it looks like deploy just
pulls together a ton of system properties and such to wrap a $mvn
quarkus:deploy. Are you just adding/pulling in additional extensions to
the maven quarkus:deploy action? I guess you need that because kube deploy
is different from Openshift, vanilla Kube, and Minishift? Azure/Lambda
doesn't have that problem.

Correct - my thinking was that if we could make azure/lambda work similar (via the quarkus:deploy mvn/gradle)
then we wouldn't have to have different ways to trigger the azure function/lambda deploys.

Ok, I looked at the code, IMO, I would have implemented it differently and kept the maven plugin more generic.  Right now, everything is all hardcoded within quarkus-maven-plugin.  I don't want to be adding knowledge of azure and lambda and every other single deployment environment too.  IMO, the maven plugin should be executing deploy similarly to how @QuarkusIntegrationTest launches Dev Services: nice and generically.

Furthermore, I really hope that what's implemented in CLI as regards to Kube is temporary and evolves to be completely generic as well.  It's also all hardcoded with knowledge of specific deployment environments (all the kube flavors).

I'm with you, Bill. I am not a huge fan of all of the hard-coding in the CLI either. It's fragile.

My understanding is that this was point-in-time to have something, and that it would evolve. Adding the additional use-case provides incentive to take the next step. ;)

[Max Rydahl Andersen]

>>
>>> Hi Bill,
>>>
>>> Adding back quarkus-dev as I accidentally missed to cc it on my reply.
>>>
>>> I was more referring to the deploy part for the usage of cli that
>>> currently can add additional extensions if need be (used in the new
>>> quarkus
>>> deploy pr)
>>>
>>> How's it work? From what's currently committed, it looks like deploy just
>>> pulls together a ton of system properties and such to wrap a $mvn
>>> quarkus:deploy. Are you just adding/pulling in additional extensions to
>>> the maven quarkus:deploy action? I guess you need that because kube
>>> deploy
>>> is different from Openshift, vanilla Kube, and Minishift? Azure/Lambda
>>> doesn't have that problem.
>>>
>>> Correct - my thinking was that if we could make azure/lambda work similar
>>> (via the quarkus:deploy mvn/gradle)
>>> then we wouldn't have to have different ways to trigger the azure
>>> function/lambda deploys.
>>>

>> Ok, I looked at the code, IMO, I would have implemented it differently and
>> kept the maven plugin more generic. Right now, everything is all hardcoded
>> within quarkus-maven-plugin. I don't want to be adding knowledge of azure
>> and lambda and every other single deployment environment too.

Yes - this is what we've known for a while. Why I was curious to be better grok early
on what lambda/functions would need. Earlier it just seemed so very specific making
it tricky to unify with some help.

>> IMO, the
>> maven plugin should be executing deploy similarly to how
>> @QuarkusIntegrationTest launches Dev Services: nice and generically.
>>
>> Furthermore, I really hope that what's implemented in CLI as regards to
>> Kube is temporary and evolves to be completely generic as well. It's also
>> all hardcoded with knowledge of specific deployment environments (all the
>> kube flavors).

Plugin is driven by which extensions are active; the cli can't fully have that "Freedom"
as intended to work without users doing extra setups - or are you thinking about something else?

But yes; the whole point have been to get something going and then iterate when we get
more custom cases.

>>
>
> I'm with you, Bill. I am not a huge fan of all of the hard-coding in the
> CLI either. It's fragile.
>
> My understanding is that this was point-in-time to have something, and that
> it would evolve. Adding the additional use-case provides incentive to take
> the next step. ;)

/max

[William Burke]

FYI:

Here's the quarkus:run implementation I'm working on for Azure Functions.  It works with integration tests too and is all generic using CurratedApplication custom build to generically discover run capabilities.

https://github.com/quarkusio/quarkus/pull/31780

[Ioannis Canellos]

On Sat, Mar 11, 2023 at 1:56 AM William Burke <bbu...@redhat.com> wrote:

https://github.com/quarkusio/quarkus/pull/31780

Took a glimpse at the pull request and I think I like this approach more. The main benefit that I see is that through the handler it's easier to pass information back to the dev tools and therefore to the user.

This is something that the deploy mojo and tasks don't do well, as they are customizing the options passed to a regular build.

I'll see what it takes in order to adopt this approach for the deploy stuff too.

Now regarding the CLI I think that one needs concrete commands per platform, so that users can take advantage of the options and completion. Without them, why even bother to have cli commands and not just stay to maven mojos and gradle tasks? This is were CLI plugins come into the picture. As we can't have a sub command for every deployment target under the sun, we start with something like (say kubernetes & openshift) and we use plugins based on the extensions the user has selected etc.

--

Ioannis Canellos

[Max Rydahl Andersen]

https://github.com/quarkusio/quarkus/pull/31780

Thanks Bill - added a few comments on first impression looks good. wanna try play more with it.

Took a glimpse at the pull request and I think I like this approach more.
The main benefit that I see is that through the handler it's easier to pass
information back to the dev tools and therefore to the user.
This is something that the deploy mojo and tasks don't do well, as they are
customizing the options passed to a regular build.
I'll see what it takes in order to adopt this approach for the deploy stuff
too.

+1, CuratedApplication approach feels like a generalisation we should be able to use.

Now regarding the CLI I think that one needs concrete commands per
platform, so that users can take advantage of the options and completion.
Without them, why even bother to have cli commands and not just stay to
maven mojos and gradle tasks? This is were CLI plugins come into the
picture. As we can't have a sub command for every deployment target under
the sun, we start with something like (say kubernetes & openshift) and we
use plugins based on the extensions the user has selected etc.

I think those two approaches can still be used together.

But yes, yes we should try out and see if things falls apart in places
where it ends up being too messy.

/max

[William Burke]

TBH, I'm very ambivalent to the CLI and not sure I'd actually use it in development.  

* Sample code generation is a one time thing and not an everyday task.  I'd probably create samples from code.quarkus.io before I'd download the CLI to do that.

* Why do I need a wrapper for $ mvn clean install quarkus:dev?  Especially when I'm going to need to know how to configure maven and gradle anyways? Especially when I can already do whatever CLI currently does on the maven/gradle command line.

* CLI is just another unneeded download when I already probably have maven or gradle installed

That being said, a big limitation of maven (and gradle?) is that there is no way to dynamically add a Mojo.  CLI could potentially be really cool and powerful if by installing a quarkus extension, the set of CLI commands and options would automatically be extended.  Quarkus extensions developers could define dynamically added CLI commands.  Still, I'm not even sure how useful that would be if we add quarkus:run and quarkus:deploy mojos.  What else is left?  Would we want a CLI that builds, runs, deploys, *and* manages apps?  The *manages* part would be where CLI would become useful.

[Max Rydahl Andersen]

https://github.com/quarkusio/quarkus/pull/31198

Adds plug-in mechanism which Can be binaries, GAVs or jbang alias and extensions Can State they want to add. 

And noone is forcing quarkus cli on You. Thats the beauty of  what we have imo. You can choose your poison and use what works best for you. 

For me quarkus cli is nice because the syntax is much much more concise and it’s the same no matter if using mvn, gradle or jbang. 

The commands we got in queue is integrating quarkus camel, the keystone management cli, oidc configuration and I’m sure there will be more. 

--

/max

https://about.me/maxandersen

[Stuart Douglas]

On Sun, 12 Mar 2023 at 02:30, William Burke <bbu...@redhat.com> wrote:

On Sat, Mar 11, 2023 at 3:35 AM Ioannis Canellos <ioc...@gmail.com> wrote:

On Sat, Mar 11, 2023 at 1:56 AM William Burke <bbu...@redhat.com> wrote:

https://github.com/quarkusio/quarkus/pull/31780

Took a glimpse at the pull request and I think I like this approach more. The main benefit that I see is that through the handler it's easier to pass information back to the dev tools and therefore to the user.

This is something that the deploy mojo and tasks don't do well, as they are customizing the options passed to a regular build.

I'll see what it takes in order to adopt this approach for the deploy stuff too.

Now regarding the CLI I think that one needs concrete commands per platform, so that users can take advantage of the options and completion. Without them, why even bother to have cli commands and not just stay to maven mojos and gradle tasks? This is were CLI plugins come into the picture. As we can't have a sub command for every deployment target under the sun, we start with something like (say kubernetes & openshift) and we use plugins based on the extensions the user has selected etc.

TBH, I'm very ambivalent to the CLI and not sure I'd actually use it in development.  

* Sample code generation is a one time thing and not an everyday task.  I'd probably create samples from code.quarkus.io before I'd download the CLI to do that.

* Why do I need a wrapper for $ mvn clean install quarkus:dev?  Especially when I'm going to need to know how to configure maven and gradle anyways? Especially when I can already do whatever CLI currently does on the maven/gradle command line.

If you are using gradle the CLI provides a better experience. Because of the way Gradle works Quarkus cannot take over the terminal to display continuous testing messages, respond to keystrokes etc. Using the CLI works around this by having the gradle dev build produce the dev mode jar that the CLI then executes directly.

 

* CLI is just another unneeded download when I already probably have maven or gradle installed

That being said, a big limitation of maven (and gradle?) is that there is no way to dynamically add a Mojo.  CLI could potentially be really cool and powerful if by installing a quarkus extension, the set of CLI commands and options would automatically be extended.  Quarkus extensions developers could define dynamically added CLI commands.  Still, I'm not even sure how useful that would be if we add quarkus:run and quarkus:deploy mojos.  What else is left?  Would we want a CLI that builds, runs, deploys, *and* manages apps?  The *manages* part would be where CLI would become useful.

So the built in terminal can already handle that (the one you get by pressing ':' in dev mode). Any extension can contribute commands. 

Stuart

 

--
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%3DjQefYAFX43ULAStrrCxuWwEzFCo8KK4Y3n46EFN7aw1%3Dw%40mail.gmail.com.