I've been thinking a bit more about how TripleO updates are developing
specifically with regards to compute nodes. What is commonly called the "update
story" I think.
As I understand it we expect people to actually have to reboot a compute node
in the cluster in order to deploy an update. This
Clint wrote:
> I would call your e-mail a documentation/roadmap bug. This plan may
> have been recorded somewhere, but for me it has just always been in my
> head as the end goal (thanks to Robert Collins for drilling the hole
> and pouring it in there btw ;).
I found the following links helpful i
Excerpts from Dan Prince's message of 2014-01-22 09:17:24 -0800:
> I've been thinking a bit more about how TripleO updates are developing
> specifically with regards to compute nodes. What is commonly called the
> "update story" I think.
>
> As I understand it we expect people to actually have to
- Original Message -
> From: "Clint Byrum"
> To: "openstack-dev"
> Sent: Wednesday, January 22, 2014 12:45:45 PM
> Subject: Re: [openstack-dev] [TripleO] our update story: can people live
> with it?
>
> Excerpts from Dan Prince's
] [TripleO] our update story: can people live
with it?
- Original Message -
> From: "Clint Byrum"
> To: "openstack-dev"
> Sent: Wednesday, January 22, 2014 12:45:45 PM
> Subject: Re: [openstack-dev] [TripleO] our update story: can people live
On 01/22/2014 12:17 PM, Dan Prince wrote:
> I've been thinking a bit more about how TripleO updates are developing
> specifically with regards to compute nodes. What is commonly called the
> "update story" I think.
>
> As I understand it we expect people to actually have to reboot a compute node
Excerpts from Dan Prince's message of 2014-01-22 10:15:20 -0800:
>
> - Original Message -
> > From: "Clint Byrum"
> > To: "openstack-dev"
> > Sent: Wednesday, January 22, 2014 12:45:45 PM
> > Subject: Re: [openstack-dev] [Tri
On Wed, 2014-01-22 at 13:15 -0500, Dan Prince wrote:
>
> - Original Message -
> > From: "Clint Byrum"
> > To: "openstack-dev"
> > Sent: Wednesday, January 22, 2014 12:45:45 PM
> > Subject: Re: [openstack-dev] [TripleO] our update story:
15 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [TripleO] our update story: can people live
> with it?
>
> - Original Message -
> > From: "Clint Byrum"
> > To: "openstack-dev&
day, January 22, 2014 12:45:45 PM
> > > Subject: Re: [openstack-dev] [TripleO] our update story: can people live
> > > with it?
> > >
> > > Given the scenario above, that would be a further optimization. I don't
> > > think it makes sense
boot method too.
Thanks,
Kevin
From: Clint Byrum [cl...@fewbar.com]
Sent: Wednesday, January 22, 2014 10:55 AM
To: openstack-dev
Subject: Re: [openstack-dev] [TripleO] our update story: can people live
with it?
Agreed, it is tricky if we try to on
On Jan 22, 2014, at 1:53 PM, Jay Pipes wrote:
> On Wed, 2014-01-22 at 13:15 -0500, Dan Prince wrote:
>>
>> - Original Message -
>>> From: "Clint Byrum"
>>> To: "openstack-dev"
>>> Sent: Wednesday, January 22, 2014 12:45:45
Excerpts from Fox, Kevin M's message of 2014-01-22 12:19:56 -0800:
> I think most of the time taken to reboot is spent in bringing down/up the
> services though, so I'm not sure what it really buys you if you do it all. It
> may let you skip the crazy long bootup time on "enterprise" hardware, bu
Byrum"
> > > > To: "openstack-dev"
> > > > Sent: Wednesday, January 22, 2014 12:45:45 PM
> > > > Subject: Re: [openstack-dev] [TripleO] our update story: can people
> > > > livewith it?
> > > >
> > > > Given the
> >>> To: "openstack-dev"
> >>> Sent: Wednesday, January 22, 2014 12:45:45 PM
> >>> Subject: Re: [openstack-dev] [TripleO] our update story: can people live
> >>> with it?
> >>>
> >>> Excerpts from Dan Prince
_
From: Clint Byrum [cl...@fewbar.com]
Sent: Wednesday, January 22, 2014 12:36 PM
To: openstack-dev
Subject: Re: [openstack-dev] [TripleO] our update story: can people live
with it?
Excerpts from Fox, Kevin M's message of 2014-01-22 12:19:56 -0800:
> I think most of the
Hi
On 22 January 2014 21:33, Fox, Kevin M wrote:
> I think we're pretty far off in a tangent though. My main point was, if
> you can't selectively restart services as needed, I'm not sure how useful
> patching the image really is over a full reboot. It should take on the same
> order of magnitud
On 22/01/14 20:54, Clint Byrum wrote:
>
>I don't understand the aversion to using existing, well-known tools to handle
this?
>
These tools are of course available to users and nobody is stopping them
from using them. We are optimizing for not needing them. They are there
and we're not going to
Hi
Not a tarball. The node would notice from Heat metadata that it should update
to a new image and would fetch that image and sync the contents to its /. This
would leave it bit for bit identical to a fresh deployment of the new image, at
least on disk. The running state would differ and that
Excerpts from Angus Thomas's message of 2014-01-23 04:57:20 -0800:
> On 22/01/14 20:54, Clint Byrum wrote:
> >> >
> >> >I don't understand the aversion to using existing, well-known tools to
> >> >handle this?
> >> >
> > These tools are of course available to users and nobody is stopping them
> >
)
Subject: Re: [openstack-dev] [TripleO] our update story: can people live
with it?
Hi
Not a tarball. The node would notice from Heat metadata that it should update
to a new image and would fetch that image and sync the contents to its /. This
would leave it bit for bit identical to a
penStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [TripleO] our update story: can people live
> with it?
>
> Hi
>
> Not a tarball. The node would notice from Heat metadata that it should update
> to a new image and would fetch
On 23 January 2014 07:55, Clint Byrum wrote:
> Agreed, it is tricky if we try to only restart what we've changed.
man checkrestart
> OR, just restart everything. We can make endpoints HA and use rolling
> updates to avoid spurious faults.
+1 for simple.
> There are complex ways to handle thing
On 23 January 2014 09:19, Fox, Kevin M wrote:
> I think most of the time taken to reboot is spent in bringing down/up the
> services though, so I'm not sure what it really buys you if you do it all. It
> may let you skip the crazy long bootup time on "enterprise" hardware, but
> that could be w
d be done with python virtualenvs instead...
>
> Kevin
>
> From: Chris Jones [c...@tenshu.net]
> Sent: Thursday, January 23, 2014 7:17 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [TripleO] our update story: can people li
On 23 January 2014 09:27, Keith Basil wrote:
>>> 3) Deploy specific application level updates via packages or tarballs.
>>> (only selected applications/packages get deployed)
>>
>> ++. FWIW, #3 happens a heck of a lot more often than #1 or #2 in CD
>> environments, so this level of optimization
> >
> > Cool. I like this a good bit better as it avoids the reboot. Still, this is
> > a rather
> large amount of data to copy around if I'm only changing a single file in
> Nova.
> >
>
> I think in most cases transfer cost is worth it to know you're deploying what
> you tested. Also it is pret
> On 01/22/2014 12:17 PM, Dan Prince wrote:
> > I've been thinking a bit more about how TripleO updates are developing
> specifically with regards to compute nodes. What is commonly called the
> "update story" I think.
> >
> > As I understand it we expect people to actually have to reboot a compute
Excerpts from Day, Phil's message of 2014-01-24 04:39:10 -0800:
> > On 01/22/2014 12:17 PM, Dan Prince wrote:
> > > I've been thinking a bit more about how TripleO updates are developing
> > specifically with regards to compute nodes. What is commonly called the
> > "update story" I think.
> > >
>
Excerpts from Day, Phil's message of 2014-01-24 04:24:11 -0800:
> > >
> > > Cool. I like this a good bit better as it avoids the reboot. Still, this
> > > is a rather
> > large amount of data to copy around if I'm only changing a single file in
> > Nova.
> > >
> >
> > I think in most cases trans
30 matches
Mail list logo
