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

Re: Changes to cartridges in master




----- Original Message -----
> +++ Clayton Coleman [03/02/14 10:46 -0500]:
> >As part of the long term move towards providing greater flexibility and
> >control of cartridges, the pull
> >https://github.com/openshift/origin-server/pull/4590 contains the initial
> >work to allow the broker to track exact versions of cartridges.  The broker
> >keeps a copy of each "version" of a cartridge it sees, and also allows an
> >administrator to disable or enable a cartridge from showing up in the list
> >of cartridges users see.  You can also import a downloadable cartridge and
> >make it visible to users, although for now it still behaves exactly like a
> >downloadable cartridge.
> >
> >## What's changed?
> >
> >Up until today, the broker would make a call to the
> >ApplicationContainerProxy to get the cartridges from a random node, and
> >then cache those in memory (or disk, or in memcached) for a period of time.
> >Now, a new collection in Mongo has been created called cartridge_types and
> >when the broker needs to lookup a cartridge's definition it checks Mongo
> >for that cartridge.  An application created with a cartridge tracks the
> >exact version that created it.  If an administrator updates that cartridge,
> >only new applications will get the new cartridge.
> >
> >Each cartridge document in mongo represents one version of a cartridge:
> >
> >    {
> >      _id: <uuid>
> >      name: "example-cartridge-0.1"
> >      manifest_text: <manifest stored as JSON>,
> >      predecessor: <id of earlier version or null>,
> >      priority: <a date>,
> >
> >      ... // extra metadata
> >    }
> >
> >An administrator starts by importing cartridges from a specific node (or any
> >node) into the broker via the new oo-admin-ctl-cartridge command:
> >
> >   oo-admin-ctl-cartridge -c import-node [--node <mcollective_identity>]
> >
> >You can specify a node to read from directly, or let OpenShift choose.  When
> >you run the first time, you should see the following:
> >
> >    $ oo-admin-ctl-cartridge -c import-node
> >    Updating 37 cartridges ...
> >    52ec19078291909962000001 # A 10gen-mms-agent-0.1
> >    52ec19078291909962000002 # A cron-1.4
> >    52ec19078291909962000003 # A diy-0.1
> >    52ec19078291909962000004 # A haproxy-1.4
> >    52ec19078291909962000005 # A jbossas-7
> >    52ec19078291909962000006 # A jbosseap-6
> >    52ec19078291909962000007 # A jbossews-1.0
> >    52ec19078291909962000008 # A jbossews-2.0
> >    52ec19078291909962000009 # A jenkins-1
> >    52ec1907829190996200000a # A jenkins-client-1
> >    52ec1907829190996200000b # A metrics-0.1
> >    ....
> >
> >The broker is informing you that it found 37 unique cartridge versions from
> >the node, and that each of them is "new" (no existing version has been
> >created).  If at this point you ran 'rhc cartridges', you would see
> >nothing.  That's because by default oo-*-cartridge won't make that an
> >imported version visible to a user.  Since the node still tracks the
> >cartridges, most of the time you'll want to use the --activate flag to
> >"activate" the cartridge.
> >
> >An activated cartridge just means that it's the official "use this version"
> >of a cartridge with that name (there can be only one).  So you could have
> >two versions of a php-5.3 cartridge that the broker knows about, but at
> >most one of them can be active.  If no version of a cartridge named
> >"foo-0.1" is active, users won't see it in the list of cartridges.
> >
> >We want to activate the new versions, but since we already have the latest
> >versions of the cartridges on the system, another 'import-node' call won't
> >do anything.  So we need to "clean" - remove unused versions of inactive
> >cartridges.
> >
> >    $ oo-admin-ctl-cartridge -c clean
> >    Deleting all unused cartridges from the broker ...
> >    52ec19078291909962000001 # 10gen-mms-agent-0.1
> >    52ec19078291909962000002 # cron-1.4
> >    52ec19078291909962000003 # diy-0.1
> >    52ec19078291909962000004 # haproxy-1.4
> >    52ec19078291909962000005 # jbossas-7
> >    ....
> >
> >Now we can pass activate to import-node and the cartridges will be "added"
> >and set to active (because we cleaned up the unused ones we just added):
> >
> >    $ oo-admin-ctl-cartridge -c import-node --activate
> >    Updating 37 cartridges ...
> >    52ec19078291909962000001 # A 10gen-mms-agent-0.1 (active)
> >    52ec19078291909962000002 # A cron-1.4 (active)
> >    52ec19078291909962000003 # A diy-0.1 (active)
> >    52ec19078291909962000004 # A haproxy-1.4 (active)
> >    52ec19078291909962000005 # A jbossas-7 (active)
> >    52ec19078291909962000006 # A jbosseap-6 (active)
> >    ....
> >
> >Run 'rhc cartridges' and these will appear instantly.
> >
> >When an application is created, OpenShift will either select the "active"
> >version of that cartridge or return an error (if you specify the exact ID
> >of a cartridge you want to use, in which case you get the cart you need).
> >The app will then track the version of the cartridge it was created with
> >until you "migrate" it.
> >
> >Migration is a very simple operation for now.  It merely updates apps
> >pointing to older cartridges to point to newer versions of cartridges.  In
> >the future it'll become much more powerful as we move into Docker and other
> >capabilities.  To migrate, run:
> >
> >    $ oo-admin-ctl-migrate -c migrate
> >    52e5c970829190e3c700000e ! -> 52ebdc958291905410000001 INCOMPLETE
> >    0 /   1 left php-5.3
> >    Migrated 0/1 cartridges
> >    Updated 0 applications
> >    Skipped 1 applications with pending jobs
> 
> Will oo-admin-upgrade still be needed or will this replace that tool?
> 
> Unless I'm reading this wrong it sounds like it could replace parts of
> it.  I definitely like the switch to focus on applications migrations
> instead of individual gears.

This does not change oo-admin-upgrade today.  Longer term, part of the goal of the docker design is to completely remove the need for oo-admin-upgrade (i.e, make all of the functionality occurring behind the scenes, happen as part of the system).  When that happens, oo-admin-ctl-cartridge -c migrate would then be responsible for handling much of that.  It might however be more targeted:

  oo-admin-ctl-cartidge -c migrate --from php-5.3 --to <uuid> 

which would schedule and manage the work of upgrading anyone on php-5.3 (whichever version they have) to a different cartridge.  This would be how you would upgrade from php-5.3 -> php-5.4.  Further out though.


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