[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Continuous Deployment




On 1/15/13 2:33 PM, Brian DeCamp wrote:
Thanks again. This is all giving me a warmer feeling. You can imagine the s-storm created when a consultant waltzes in to a public company to tell them to throw away much of what they've done in the past and use OpenShift instead. Oh and by the way, I've never really used this before. They are giving it careful consideration though. I just hope I'm doing the right thing.

Re: HornetQ and SwitchYard. They recently punted on RabbitMQ and decided ActiveMQ was what they would support. I'd rather avoid those waters. It sounds like I have to add a hefty chunk to the project plan for an ActiveMQ cartridge, and I have no idea how to size that. SwitchYard looks promising, but I don't think they need a Rete implementation or BPM for now. Although, I chose Camel in part because it is used by both Mule and SwitchYard in case we need to go that route in the future. I'll be keeping a close eye on it.
HornetQ is what we're directly supporting now as part of JBoss AS/EAP. That said an ActiveMQ cartridge and support within AS/EAP is definitely on the roadmap especially in light of the FuseSource acquisition last Fall. Sounds like SwitchYard might be overkill at this point, but I recommend looking at it if you are running your apps on JBoss. You can enable or disable only the components you want including camel, bpel, bpm, rules, etc.

I would love to have a quick call to discuss.
If you can suggest a few dates/times I'll set it up.

Brian
Skype: brian.decamp
Phone: 303-619-4482


On Jan 15, 2013, at 9:50 AM, William DeCoste <wdecoste redhat com> wrote:

Hi Brian,

We currently support HornetQ as part of AS7 for JMS. Also, you can embed the SwitchYard gear into an existing AS/EAP application to enable SwitchYard which includes Camel, Drools, etc. In the hosted environment, you may run into port binding and routing issues if you are trying to do inter-gear communication over another mechanism such as ActiveMQ. ActiveMQ would have to use the ports that are allowed for the gear type. For a local Origin/OSE environment you'd have the flexibility to create your own ActiveMQ, Camel, etc. cartridges and control the ports and routing via the cart implementation.

Please let me know how I can assist. If you'd like to set up a quick call to discuss please let me know.

Thanks -Bill

On 1/15/13 7:18 AM, Brian DeCamp wrote:
Thanks for all the thoughtful responses. We actually have two different scenarios where we want to manage a rolling deployment. One scenario is when we are rolling out a new Tomcat controller for REST services. It sounds like we would have to implement a mod_proxy cartridge to do that. The second scenario is when we are rolling out a new version of a backend service. The services tier is a message-based SOA. We plan to implement the message bus using Apache Camel over ActiveMQ. The services themselves will be simple JMS applications running on a stripped down AS7. The Camel Dynamic Router will run in an ActiveMQ cluster and manage the routing of the messages to services on the backend. I had hoped I could run all of it in OpenShift, although I'm not yet sure what kind of cartridges I'd have to create to do that.

On Jan 14, 2013, at 6:03 PM, dev-request lists openshift redhat com wrote:

Just floating ideas, but there's nothing fundamental that would prevent someone putting together a mod_cluster cartridge that supplanted haproxy, except that there is some broker work required to allow the config (although direct descriptor creation is still allowed, I thought)?

I ask because integrated ecosystem scaling might very well offer features haproxy can't - so in a happy ecosystem mod cluster might coexist with haproxy.  I guess you could also deploy a server cart that contains just mod cluster as well, as long as it could execute scale up events.

On Jan 14, 2013, at 7:02 PM, Mike McGrath <mmcgrath redhat com> wrote:

On Mon, 14 Jan 2013, Clayton Coleman wrote:

What are the technical challenges to adding mod_cluster support to Openshift?
Just that it only works with jboss, there's always been a plan in place to
do connection bleeding but it's not really come up until now.  I think
Matt's been a big proponent since the start.

In theory we can do this with haproxy but we've not spent any time doing
so yet.

   -Mike

On Jan 14, 2013, at 6:45 PM, William DeCoste <wdecoste redhat com> wrote:

     mod_cluster used with the JBoss AS/EAP domain model provides exactly this capability but neither is available in OpenShift yet although they are on the roadmap.

     On 1/14/13 3:36 PM, Clayton Coleman wrote:
     And as a side note rams email the other day floated a very similar concept (a balancer that can bleed between two apps).

Being able to gracefully restart very large apps is desirable - if you can tolerate both being up at the same time then having a new copy of your app, and an old copy of you app (both scaled)
that is load balanced by your own balancer.  You can then control the scale up down in a scripted fashion.

On Jan 14, 2013, at 6:21 PM, William DeCoste <wdecoste redhat com> wrote:

     Hi Brian,

     What mechanism would you use to control the bleed from the old to the new application? This component would most likely be out of the scope of OpenShift. You would be able to
     deploy both versions of the application in OpenShift side by side.

     What type of cartridge is the application? Would you be using OpenShift's Jenkins cartridge to manage the builds and deployments or an external Jenkins?

     Thanks -Bill


     On 1/14/13 12:57 PM, Brian DeCamp wrote:
     Hi,
I originally posted this on the community forum, but Nam suggested I post it on the dev mailing list.

I'd like to use OpenShift Origins or Enterprise to manage a Continuous Deployment pipeline for a large (30MM+ user) application. Our  SOA will also A/B test every release as it
goes out, automatically failing a release that does not meet certain thresholds for KPIs. To do this, I need to control the deployment of the new build into production. When a
build successfully passes all our tests in Jenkins, I'd like to install the new build into production without removing the old build. Then I'll slowly bleed traffic over to the
new version while monitoring our KPIs. If all goes well, all traffic will eventually use the new version and I can remove the old version. If not, I'll redirect all the traffic
back to the old version and remove the new build. Traffic routing will be through HA Proxy for web applications, and through a custom message broker for backend services.

Is it possible to do this all with the deployment hooks? If not, is there someplace in the Origins code I can look to scope out the amount of work involved to meet these
requirements?

Brian



_______________________________________________
dev mailing list
dev lists openshift redhat com
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev


--
Bill DeCoste
Principal Software Engineer, Red Hat
978-204-0920
wdecoste redhat com

     _______________________________________________
     dev mailing list
     dev lists openshift redhat com
     http://lists.openshift.redhat.com/openshiftmm/listinfo/dev


--
Bill DeCoste
Principal Software Engineer, Red Hat
978-204-0920
wdecoste redhat com



------------------------------

Message: 2
Date: Mon, 14 Jan 2013 18:17:48 -0600 (CST)
From: Mike McGrath <mmcgrath redhat com>
To: Clayton Coleman <ccoleman redhat com>
Cc: "dev lists openshift redhat com" <dev lists openshift redhat com>
Subject: Re: Continuous Deployment
Message-ID: <alpine LFD 2 03 1301141816270 2603 redhat com>
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Mon, 14 Jan 2013, Clayton Coleman wrote:

Just floating ideas, but there's nothing fundamental that would prevent someone putting together a mod_cluster cartridge that supplanted haproxy, except that there is some broker work required to allow the config (although direct descriptor creation is still allowed, I thought)?

I ask because integrated ecosystem scaling might very well offer features haproxy can't - so in a happy ecosystem mod cluster might coexist with haproxy.  I guess you could also deploy a server cart that contains just mod cluster as well, as long as it could execute scale up events.

Correct, this goes back to that balance between a consistent experience
between cartridges and what the users expect.  mod_cluster may very well
be a better experience for the jboss users.

	-Mike

On Jan 14, 2013, at 7:02 PM, Mike McGrath <mmcgrath redhat com> wrote:

On Mon, 14 Jan 2013, Clayton Coleman wrote:

What are the technical challenges to adding mod_cluster support to Openshift?
Just that it only works with jboss, there's always been a plan in place to
do connection bleeding but it's not really come up until now.  I think
Matt's been a big proponent since the start.

In theory we can do this with haproxy but we've not spent any time doing
so yet.

   -Mike

On Jan 14, 2013, at 6:45 PM, William DeCoste <wdecoste redhat com> wrote:

     mod_cluster used with the JBoss AS/EAP domain model provides exactly this capability but neither is available in OpenShift yet although they are on the roadmap.

     On 1/14/13 3:36 PM, Clayton Coleman wrote:
     And as a side note rams email the other day floated a very similar concept (a balancer that can bleed between two apps).

Being able to gracefully restart very large apps is desirable - if you can tolerate both being up at the same time then having a new copy of your app, and an old copy of you app (both scaled)
that is load balanced by your own balancer.  You can then control the scale up down in a scripted fashion.

On Jan 14, 2013, at 6:21 PM, William DeCoste <wdecoste redhat com> wrote:

     Hi Brian,

     What mechanism would you use to control the bleed from the old to the new application? This component would most likely be out of the scope of OpenShift. You would be able to
     deploy both versions of the application in OpenShift side by side.

     What type of cartridge is the application? Would you be using OpenShift's Jenkins cartridge to manage the builds and deployments or an external Jenkins?

     Thanks -Bill


     On 1/14/13 12:57 PM, Brian DeCamp wrote:
     Hi,
I originally posted this on the community forum, but Nam suggested I post it on the dev mailing list.

I'd like to use OpenShift Origins or Enterprise to manage a Continuous Deployment pipeline for a large (30MM+ user) application. Our  SOA will also A/B test every release as it
goes out, automatically failing a release that does not meet certain thresholds for KPIs. To do this, I need to control the deployment of the new build into production. When a
build successfully passes all our tests in Jenkins, I'd like to install the new build into production without removing the old build. Then I'll slowly bleed traffic over to the
new version while monitoring our KPIs. If all goes well, all traffic will eventually use the new version and I can remove the old version. If not, I'll redirect all the traffic
back to the old version and remove the new build. Traffic routing will be through HA Proxy for web applications, and through a custom message broker for backend services.

Is it possible to do this all with the deployment hooks? If not, is there someplace in the Origins code I can look to scope out the amount of work involved to meet these
requirements?

Brian



_______________________________________________
dev mailing list
dev lists openshift redhat com
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev


--
Bill DeCoste
Principal Software Engineer, Red Hat
978-204-0920
wdecoste redhat com

     _______________________________________________
     dev mailing list
     dev lists openshift redhat com
     http://lists.openshift.redhat.com/openshiftmm/listinfo/dev


--
Bill DeCoste
Principal Software Engineer, Red Hat
978-204-0920
wdecoste redhat com



------------------------------

Message: 3
Date: Mon, 14 Jan 2013 19:54:32 -0500 (EST)
From: Clayton Coleman <ccoleman redhat com>
To: Mike McGrath <mmcgrath redhat com>
Cc: "dev lists openshift redhat com" <dev lists openshift redhat com>
Subject: Re: Continuous Deployment
Message-ID: <20DBE284-9F2A-4A7A-8A4F-93E178D8CB26 redhat com>
Content-Type: text/plain;	charset=us-ascii

On Jan 14, 2013, at 7:17 PM, Mike McGrath <mmcgrath redhat com> wrote:

On Mon, 14 Jan 2013, Clayton Coleman wrote:

Just floating ideas, but there's nothing fundamental that would prevent someone putting together a mod_cluster cartridge that supplanted haproxy, except that there is some broker work required to allow the config (although direct descriptor creation is still allowed, I thought)?

I ask because integrated ecosystem scaling might very well offer features haproxy can't - so in a happy ecosystem mod cluster might coexist with haproxy.  I guess you could also deploy a server cart that contains just mod cluster as well, as long as it could execute scale up events.
Correct, this goes back to that balance between a consistent experience
between cartridges and what the users expect.  mod_cluster may very well
be a better experience for the jboss users.
Is the hardest part of creating a custom cart for something like this telling Openshift to route the node proxy traffic to the cart as the primary?  I know the new broker code looks for git host, but is it truly flexible enough that I could write a cart today that when installed would get traffic?

Maybe that's partly a question for Dan or Krishna and the new model refactor.

   -Mike

On Jan 14, 2013, at 7:02 PM, Mike McGrath <mmcgrath redhat com> wrote:

On Mon, 14 Jan 2013, Clayton Coleman wrote:

What are the technical challenges to adding mod_cluster support to Openshift?
Just that it only works with jboss, there's always been a plan in place to
do connection bleeding but it's not really come up until now.  I think
Matt's been a big proponent since the start.

In theory we can do this with haproxy but we've not spent any time doing
so yet.

  -Mike

On Jan 14, 2013, at 6:45 PM, William DeCoste <wdecoste redhat com> wrote:

    mod_cluster used with the JBoss AS/EAP domain model provides exactly this capability but neither is available in OpenShift yet although they are on the roadmap.

    On 1/14/13 3:36 PM, Clayton Coleman wrote:
    And as a side note rams email the other day floated a very similar concept (a balancer that can bleed between two apps).

Being able to gracefully restart very large apps is desirable - if you can tolerate both being up at the same time then having a new copy of your app, and an old copy of you app (both scaled)
that is load balanced by your own balancer.  You can then control the scale up down in a scripted fashion.

On Jan 14, 2013, at 6:21 PM, William DeCoste <wdecoste redhat com> wrote:

    Hi Brian,

    What mechanism would you use to control the bleed from the old to the new application? This component would most likely be out of the scope of OpenShift. You would be able to
    deploy both versions of the application in OpenShift side by side.

    What type of cartridge is the application? Would you be using OpenShift's Jenkins cartridge to manage the builds and deployments or an external Jenkins?

    Thanks -Bill


    On 1/14/13 12:57 PM, Brian DeCamp wrote:
    Hi,
I originally posted this on the community forum, but Nam suggested I post it on the dev mailing list.

I'd like to use OpenShift Origins or Enterprise to manage a Continuous Deployment pipeline for a large (30MM+ user) application. Our  SOA will also A/B test every release as it
goes out, automatically failing a release that does not meet certain thresholds for KPIs. To do this, I need to control the deployment of the new build into production. When a
build successfully passes all our tests in Jenkins, I'd like to install the new build into production without removing the old build. Then I'll slowly bleed traffic over to the
new version while monitoring our KPIs. If all goes well, all traffic will eventually use the new version and I can remove the old version. If not, I'll redirect all the traffic
back to the old version and remove the new build. Traffic routing will be through HA Proxy for web applications, and through a custom message broker for backend services.

Is it possible to do this all with the deployment hooks? If not, is there someplace in the Origins code I can look to scope out the amount of work involved to meet these
requirements?

Brian



_______________________________________________
dev mailing list
dev lists openshift redhat com
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev


--
Bill DeCoste
Principal Software Engineer, Red Hat
978-204-0920
wdecoste redhat com

    _______________________________________________
    dev mailing list
    dev lists openshift redhat com
    http://lists.openshift.redhat.com/openshiftmm/listinfo/dev


--
Bill DeCoste
Principal Software Engineer, Red Hat
978-204-0920
wdecoste redhat com

------------------------------

Message: 4
Date: Mon, 14 Jan 2013 19:03:06 -0600 (CST)
From: Mike McGrath <mmcgrath redhat com>
To: Clayton Coleman <ccoleman redhat com>
Cc: "dev lists openshift redhat com" <dev lists openshift redhat com>
Subject: Re: Continuous Deployment
Message-ID: <alpine LFD 2 03 1301141901480 2603 redhat com>
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Mon, 14 Jan 2013, Clayton Coleman wrote:

On Jan 14, 2013, at 7:17 PM, Mike McGrath <mmcgrath redhat com> wrote:

On Mon, 14 Jan 2013, Clayton Coleman wrote:

Just floating ideas, but there's nothing fundamental that would prevent someone putting together a mod_cluster cartridge that supplanted haproxy, except that there is some broker work required to allow the config (although direct descriptor creation is still allowed, I thought)?

I ask because integrated ecosystem scaling might very well offer features haproxy can't - so in a happy ecosystem mod cluster might coexist with haproxy.  I guess you could also deploy a server cart that contains just mod cluster as well, as long as it could execute scale up events.
Correct, this goes back to that balance between a consistent experience
between cartridges and what the users expect.  mod_cluster may very well
be a better experience for the jboss users.
Is the hardest part of creating a custom cart for something like this telling Openshift to route the node proxy traffic to the cart as the primary?  I know the new broker code looks for git host, but is it truly flexible enough that I could write a cart today that when installed would get traffic?

Maybe that's partly a question for Dan or Krishna and the new model refactor.

If it speaks http, yeah.  It's pretty 'simple/dumb' in that way.  We've
sort of gone the "configure things to work most of the time" but now that
we're there we'll start getting more requests like this for better polish
(like bleeding of connections, not using sticky sessions, etc)

	-Mike

   -Mike

On Jan 14, 2013, at 7:02 PM, Mike McGrath <mmcgrath redhat com> wrote:

On Mon, 14 Jan 2013, Clayton Coleman wrote:

What are the technical challenges to adding mod_cluster support to Openshift?
Just that it only works with jboss, there's always been a plan in place to
do connection bleeding but it's not really come up until now.  I think
Matt's been a big proponent since the start.

In theory we can do this with haproxy but we've not spent any time doing
so yet.

  -Mike

On Jan 14, 2013, at 6:45 PM, William DeCoste <wdecoste redhat com> wrote:

    mod_cluster used with the JBoss AS/EAP domain model provides exactly this capability but neither is available in OpenShift yet although they are on the roadmap.

    On 1/14/13 3:36 PM, Clayton Coleman wrote:
    And as a side note rams email the other day floated a very similar concept (a balancer that can bleed between two apps).

Being able to gracefully restart very large apps is desirable - if you can tolerate both being up at the same time then having a new copy of your app, and an old copy of you app (both scaled)
that is load balanced by your own balancer.  You can then control the scale up down in a scripted fashion.

On Jan 14, 2013, at 6:21 PM, William DeCoste <wdecoste redhat com> wrote:

    Hi Brian,

    What mechanism would you use to control the bleed from the old to the new application? This component would most likely be out of the scope of OpenShift. You would be able to
    deploy both versions of the application in OpenShift side by side.

    What type of cartridge is the application? Would you be using OpenShift's Jenkins cartridge to manage the builds and deployments or an external Jenkins?

    Thanks -Bill


    On 1/14/13 12:57 PM, Brian DeCamp wrote:
    Hi,
I originally posted this on the community forum, but Nam suggested I post it on the dev mailing list.

I'd like to use OpenShift Origins or Enterprise to manage a Continuous Deployment pipeline for a large (30MM+ user) application. Our  SOA will also A/B test every release as it
goes out, automatically failing a release that does not meet certain thresholds for KPIs. To do this, I need to control the deployment of the new build into production. When a
build successfully passes all our tests in Jenkins, I'd like to install the new build into production without removing the old build. Then I'll slowly bleed traffic over to the
new version while monitoring our KPIs. If all goes well, all traffic will eventually use the new version and I can remove the old version. If not, I'll redirect all the traffic
back to the old version and remove the new build. Traffic routing will be through HA Proxy for web applications, and through a custom message broker for backend services.

Is it possible to do this all with the deployment hooks? If not, is there someplace in the Origins code I can look to scope out the amount of work involved to meet these
requirements?

Brian



_______________________________________________
dev mailing list
dev lists openshift redhat com
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev


--
Bill DeCoste
Principal Software Engineer, Red Hat
978-204-0920
wdecoste redhat com

    _______________________________________________
    dev mailing list
    dev lists openshift redhat com
    http://lists.openshift.redhat.com/openshiftmm/listinfo/dev


--
Bill DeCoste
Principal Software Engineer, Red Hat
978-204-0920
wdecoste redhat com

------------------------------

_______________________________________________
dev mailing list
dev lists openshift redhat com
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev


End of dev Digest, Vol 10, Issue 21
***********************************
_______________________________________________
dev mailing list
dev lists openshift redhat com
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
--
Bill DeCoste
Principal Software Engineer, Red Hat
978-204-0920
wdecoste redhat com

_______________________________________________
dev mailing list
dev lists openshift redhat com
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev

_______________________________________________
dev mailing list
dev lists openshift redhat com
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev

--
Bill DeCoste
Principal Software Engineer, Red Hat
978-204-0920
wdecoste redhat com


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]