Bottles Feature

[Dru Sellers]

Greetings All,

Now with the latest 2.2.1 almost wrapped up, I am going to start working on the bottles feature you may have heard me talking about. If you haven't here's the gist of it.

Think Jars for .Net, but not quite because we got ta do it different. :) Imagine you have a 'bottle' (this doesn't matter but lets think about it as a zipped directory, it could just as easily be a standard directory or an assembly with embedded content). When topshelf detects a new bottle it will load the content and start running it right from there (in the beginning this might mean unzipping it and then moving the content into the shelving area where the service will be automatically started and hosted). Bottles will have additional capabilities other than just 'packaging all the content into a zip', including access to install actions (so you can add tables and so forth) and then we can activate your service (installers would only run once, activators would run whenever the app is 'started')

This concept is going to be baked into FubuMVC as well as topshelf and masstransit. It is my hope that this concept will help make using the Topshelf.Host.exe even easier to use.

If you have any thoughts feel free to respond now. :)

-d

[Keith Elder]

One thing that needs to be thought of early on is monitoring of these services. No matter how we packaged it, if a systems engineer cannot monitor a given service using SCOM or some other means then for my use cases Topshelf doesn't buy me much. 

--
Keith Elder
Deep Fried Bytes  (A Boy Howdy Production)
Microsoft MVP
INETA Mentor - AL, LA, MS
Mobile: 601.467.9744
Blog: http://keithelder.net
Podcast: http://deepfriedbytes.com
Twitter: http://twitter.com/keithelder

[Dru Sellers]

Pls start a monitoring thread. Do you have any thoughts around bottles?

-d

[Keith Elder]

Sure. Let's start with *why*? What's the *end goal* of bottles?  Why would someone care? What does it buy them over what they are doing today?

[Travis Smith]

The why is deployment story mostly. If I can bundle my code and deploy
it, including pre/post install actions, as a single zip file it's much
easier. When you're deploying to 12 boxes with 18 services each, a
deployment story like that looks much nicer :)

--
-Travis

[Peter Ritchie]

I aggree with Keith here.

 

There's so many other things that are hindering TopShelf use in enterprise-class environments and there's already deployment technologies and strategies that I can (and must) use at the moment.

 

Having said that, and moving foward with Bottles; it's important not to introduce another packaging and deployment scheme.  I've got lots of ways to package and deploy files and content right now, I don't need another subset that I need to learn and use /just/ to package and deploy the files that a topshelf service uses.  i.e. my systems comprise much more than just services--and their specific dependencies--and my deployment strategy must include all those other things as well.  If there's another deployment technology that used just for deploying the parts that a TopShelf service is going to use or need, I'm not likely to use it at all.

 

Cheers -- Peter

--
"Refactoring with Microsoft Visual Studio 2010": http://lynk.at/c13trs
http://PeterRitchie.com/blog/
http://twitter.com/PeterRitchie
http://facebook.com/Peter.Ritchie/
http://www.linkedin.com/in/PeterARitchie
Skype:Peter.a.Ritchie

[Travis Smith]

On Fri, Apr 8, 2011 at 10:44 AM, Peter Ritchie <pe...@peterritchie.com> wrote:
> There's so many other things that are hindering TopShelf use in
> enterprise-class environments

Can you comment on that more, even if it's just to me directly? I know
of a significiant number of organization using Topshelf at the
enterprise level currently. Perhaps the shelving componets aren't up
to the level needed for some organizations to feel comfortable about
it but the core service hosting has been used for some time. I've
never gotten the feeling that there was a major blocking issue for
adoption.

--
-Travis

[Vladimir Okhotnikov]

Hi

sorry to jump in, but that sounds pretty much like what the guys at
www.openwrap.org are doing (with the exception that they also do
dependency and version control, as a package management solution). I
remember Seb describing their deployment, based on dynamic updating
packages from system repo, unwrapping their contents and dynamic loading
of assemblies from there. Perhaps you would like to consider integrating
with that approach, to avoid reimplementing versioning and dependency
concerns? I would surely like OW-compatible solution for topshelf
deployment...

Regards,
Vladimir Okhotnikov

[Travis Smith]

This is pretty specific to hosting services inside Topshelf (or other
app hosts, ala Fubu). It's not about dependancy management and other
stuff that OpenWrap takes care of. It's about giving up on the pain of
using remote WMI calls to manage services (which is pretty poor). It's
about letting Topshelf manage the service's lifecycle. The end game is
more of Topshelf as an Application Server in the .NET world; however,
that's a ways down the road.

-Travis

--
-Travis

[Adam]

Now I get it "Bottles" aka "jars", I think this great!

A few features:

1) A case of bottles, so deploying multiple shelves / plugins that are dependent on each other can be packaged up into a single artifact and deployment transaction

2) Rollback: if something fails kick out everything new put it back the way it was

3) Versioning: keep a couple version around in a catalog so I can easily rollback without having to go find the previous versions

As for the stability of Topshelf, I have no issues.  I haven't used the shelving bits yet but we having been running with topshelf for well over a year and the only unstable bits are our apps.  We have 3rd party software that runs on a background thread and is notorious for throwing unhandled exceptions which unfortunately we have not found a way to wrap and catch, the service crashes probably twice a day but we never have an issue because we use the built-in windows service restart capabilities.

Keep up the nice work Dru and Chris, I am excited to see more of these core infrastructure pieces getting shared between multiple OSS projects.

Adam

[Travis Smith]

You pretty hit on target the sort of thing we'd like to be able to do.

On Fri, Apr 8, 2011 at 12:19 PM, Adam <adam....@gmail.com> wrote:
> 1) A case of bottles, so deploying multiple shelves / plugins that are
> dependent on each other can be packaged up into a single artifact and
> deployment transaction
> 2) Rollback: if something fails kick out everything new put it back the way
> it was
> 3) Versioning: keep a couple version around in a catalog so I can easily
> rollback without having to go find the previous versions

--
-Travis

[Peter Ritchie]

I have to admit, I haven't used it in a while and haven't been keeping up with recent changes.  But, the last time I looked, these were some of the issues that I remember:

 Can't use tools like SCOM to monitor a single service.

 Can't specify login (and thus impersonation) for a given service.

 

There may have been others.  Recovery options may have been one...

 

Cheers -- Peter

[Dru Sellers]

As for impersonatio , watch for process shelves. :)

-d

[Hakeem Mohammed]

@Peter Ritchie,

By impersonation, if you meant running the service as a specific user, that has been there for a while, the RunAs method in HostConfiguration. I believe it is an extension method that you can pass in your credentials to when configuring the service

[Chris Patterson]

On Fri, Apr 8, 2011 at 11:41 AM, Peter Ritchie <pe...@peterritchie.com> wrote:

 Can't use tools like SCOM to monitor a single service.

Can certainly use some help here to make that happen.

 

 Can't specify login (and thus impersonation) for a given service.

For a given service, not presently. The username/password or type (network service, etc.) can be specified on the install command-line, but it's for the entire windows service, including every service. Once we have process shelves, it will be possible to specify credentials for each shelved service, which should meet your requirements. 

 

There may have been others.  Recovery options may have been one...

When a service crashes, it will be restarted now. We need to have configurable service recovery options, but right now it's just a restart. If an unhandled exception is thrown by any service, they are all restarted since it's not really possible to figure out which one crashed (if we could we could just restart the faulted service). Again, once we have process shelves this goes away since the dead process is easy to detect and restart (just like high isolation in iis 6).

[Peter Ritchie]

...inline...

On Fri, Apr 8, 2011 at 2:09 PM, Chris Patterson <ch...@phatboyg.com> wrote:

On Fri, Apr 8, 2011 at 11:41 AM, Peter Ritchie <pe...@peterritchie.com> wrote:

 Can't use tools like SCOM to monitor a single service.

Can certainly use some help here to make that happen.

 

Not sure what could be done here.  Out of the box SCOM just does a remote connection to the service control manager on the host computer and queries the state of the service.  If that service hosted moe "services", I can't see how SCOM could support TopShelf for monitoring out of the box...  An "add-in" could  be written to do this; but there would likely be push-back from IT folks on something like that..

 

 

 Can't specify login (and thus impersonation) for a given service.

For a given service, not presently. The username/password or type (network service, etc.) can be specified on the install command-line, but it's for the entire windows service, including every service. Once we have process shelves, it will be possible to specify credentials for each shelved service, which should meet your requirements. 

 

There may have been others.  Recovery options may have been one...

When a service crashes, it will be restarted now. We need to have configurable service recovery options, but right now it's just a restart. If an unhandled exception is thrown by any service, they are all restarted since it's not really possible to figure out which one crashed (if we could we could just restart the faulted service). Again, once we have process shelves this goes away since the dead process is easy to detect and restart (just like high isolation in iis 6).

 

Of course, all the above is all disconnected from all existing configuration/deployment/monitoring of Windows Services...  You can get all that if you only host one service in TopShelf; but I think that circumvents much of the value that TopShelf is intending to provide...