Open Stack

> -----Original Message-----
> From: Russell Bryant [mailto:rbryant at redhat.com]
> Sent: 08 April 2014 13:13
> To: openstack-dev at lists.openstack.org
> Subject: Re: [openstack-dev] [nova] Server Groups are not an optional
> element, bug or feature ?
> 
> On 04/08/2014 06:29 AM, Day, Phil wrote:
> >
> >
> >> -----Original Message-----
> >> From: Russell Bryant [mailto:rbryant at redhat.com]
> >> Sent: 07 April 2014 19:12
> >> To: openstack-dev at lists.openstack.org
> >> Subject: Re: [openstack-dev] [nova] Server Groups are not an optional
> >> element, bug or feature ?
> >>
> >>
> > ...
> >
> >> I consider it a complete working feature.  It makes sense to enable
> >> the filters by default.  It's harmless when the API isn't used.  That was just
> an oversight.
> >>
> >> The list of instances in a group through the API only shows
> >> non-deleted instances.
> >
> > True, but the lack of even a soft delete on the rows in the
> instance_group_member worries me  - its not clear why that wasn't fixed
> rather than just hiding the deleted instances.    I'd of expected the full DB
> lifecycle to implemented before something was considered as a complete
> working feature.
> 
> We were thinking that there may be a use for being able to query a full list of
> instances (including the deleted ones) for a group.  The API just hasn't made
> it that far yet.  Just hiding them for now leaves room to iterate and doesn't
> prevent either option (exposing the deleted instances, or changing to auto-
> delete them from the group).
> 
Maybe it's just me, but I have a natural aversion to anything that grows forever in the database - over time and at scale this becomes a real problem.

We really need a consistent view / policy on what does and doesn't need to be possible for deleted instances - they trend of discussion seems to have been heading towards moving away from soft delete to more of a "once its gone it's gone" approach, which would get my vote.     If we need an archive service let's make that something explicit in the architecture (maybe it can be something that consumes notifications like stacktach)

Seems that at the moment service groups is heading in a new direction of its own here - not just using soft delete and read-deleted to get at old records, but actually keeping them in the DB and then hiding them in the API layer - which feels really inconsistent.