> From: Crag Wolfe [mailto:cwo...@redhat.com]
>
> On 10/20/2016 09:30 PM, Rabi Mishra wrote:
> > Thanks Crag on starting the thread. Few comments inline.
> >
...
> >
> > For RPC changes, we don't have a great solution right now (looking
> > specifically at heat/engine/service.py). If we ad
> From: Gyorgy Szombathelyi
>
> Unknown column 'user.name' in 'field list'
>
> in some operation when the DB is already upgraded to Mitaka, but some
> keystone instances in a HA setup are still Liberty.
Currently we don't support rolling upgrades in keystone. To do an upgrade, you
need to upgra
> From: Morgan Fainberg [mailto:morgan.fainb...@gmail.com]
>>
>> Keystone stable working with master db seems like an interesting bit, are
>> there already tests for that?
>
>Not yet. Right now there is only a unit test, checking obvious
>incompatibilities.
>
> As an FYI, this test was reverted
> From: Sean Dague [mailto:s...@dague.net]
>
> On 02/05/2016 04:44 AM, Grasza, Grzegorz wrote:
> >
> >> From: Sean Dague [mailto:s...@dague.net]
> >>
> >> On 02/04/2016 10:25 AM, Grasza, Grzegorz wrote:
> >>>
> >>> Keystone is
> -Original Message-
> From: Sean Dague [mailto:s...@dague.net]
>
> On 02/04/2016 10:25 AM, Grasza, Grzegorz wrote:
> >
> > Keystone is just one service, but we want to run a test, in which it
> > is setup in HA – two services running at different versions,
Hi Sean,
we are looking into testing online schema migrations in keystone.
The idea is to run grenade with multinode support, but it would be something
different than the current implementation.
Currently, the two nodes which are started run with different roles, one is a
controller the other i
Hi,
I wrote up a POC implementing an example online schema migration in one release
cycle:
https://review.openstack.org/269693
This bases on the Online Schema Migration blueprint [1] and adds a
configuration option to denote which columns are being used at a given time.
The upgrade scenario for
Hi,
I noticed that right now, when we make changes (adding/removing fields) in
https://github.com/openstack/magnum/tree/master/magnum/objects , we don't
change object versions.
The idea of objects is that each change in their fields should be versioned,
documentation about the change should al
> -Original Message-
> From: Zane Bitter [mailto:zbit...@redhat.com]
> Sent: Thursday, 6 August, 2015 2:57
> To: OpenStack Development Mailing List
> Subject: [openstack-dev] [Heat] RPC API versioning
>
> We've been talking about this since before summit without much consensus.
> I think
> >>
> >> On Mon, Jun 22, 2015 at 5:40 AM, Jastrzebski, Michal
> >> wrote:
> >> > Hello,
> >> >
> >> > I wanted to start discussion about versioned objects backporting
> >> > for conductor-less projects.
> >> > In Vancouver we discussed compatibility mode, which works like that:
> >> >
Dan's blog
10 matches
Mail list logo
