Re: [openstack-dev] [Openstack-operators] [nova][cells] Should flavors in the API DB for cells v2 be soft-deletable?
On 7 January 2016 at 19:59, Matt Riedemann wrote: > There is a cells v2 change up for review [1] which creates the flavor tables > in the API DB. > > I noted that those table definitions include the soft-delete columns > (deleted and deleted_at), which at the YVR summit and in other threads [2] > we've said we're not doing anymore for new tables. > > The point raised to keep them soft-deletable is that the flavor API allows > showing soft-deleted flavors if you know the id [3]. And you can get the > flavor id for an instance (we always store the flavor info that was used to > boot the instance). > > The question is, can we break that wrinkle in the API by not allow > soft-deleting the flavor in the API DB? On balance, I think this is OK. > Note that in the normal nova DB, if the admin archives/purges the > instance_types table, the wrinkle is already broken because the soft-deleted > flavor is now hard-deleted, but that's maybe not a great justification for > consciously removing this support in the API DB. This is what won me over. All be it, reluctantly. > If we made the flavor soft-deletable in the API DB, one issue is we don't > have an in-tree entrypoint for cleaning this up (there are no archive/purge > CLIs for the API DB). We could always add that, but it's not there right > now. > > Another thing that came up in the cells meeting this week is that if we > didn't make the flavor soft-deletable, we could still show the flavor > information for a given instance via the server GET API. However, that would > be a microversion change to show the full flavor information for the server > rather than just the flavor id. This is really only possible because we now store flavor info inside every instance object. I think before that, deleting the flavor would make some instance operations fail. > Thoughts? I'm cross-posting this to -dev and the -operators list to see what > kind of user impact there would be if we didn't soft-delete flavors in the > API DB (so you couldn't look up deleted flavors in the API). In balance, I think we should not allow soft_delete of flavors in the API DB. In a related note, and I thinking about a backlog spec looking at a flavor lifecycle. Thinking about early release, to production, then phasing out of flavors. I don't think soft delete is needed for that. Thanks, johnthetubaguy __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Openstack-operators] [nova][cells] Should flavors in the API DB for cells v2 be soft-deletable?
On 01/08/16 at 12:43pm, John Garbutt wrote:
On 7 January 2016 at 19:59, Matt Riedemann wrote:
There is a cells v2 change up for review [1] which creates the flavor tables
in the API DB.
I noted that those table definitions include the soft-delete columns
(deleted and deleted_at), which at the YVR summit and in other threads [2]
we've said we're not doing anymore for new tables.
The point raised to keep them soft-deletable is that the flavor API allows
showing soft-deleted flavors if you know the id [3]. And you can get the
flavor id for an instance (we always store the flavor info that was used to
boot the instance).
The question is, can we break that wrinkle in the API by not allow
soft-deleting the flavor in the API DB?
On balance, I think this is OK.
There's an alternate approach to this that we can take which I'll
outline below. But it should meet the needs of anyone currently looking
up deleted flavors.
Note that in the normal nova DB, if the admin archives/purges the
instance_types table, the wrinkle is already broken because the soft-deleted
flavor is now hard-deleted, but that's maybe not a great justification for
consciously removing this support in the API DB.
This is what won me over. All be it, reluctantly.
I think this is good justification for removing the ability because
currently it is essentially undefined behavior. Requesting a deleted
flavor may or may not work and either response is correct.
If we made the flavor soft-deletable in the API DB, one issue is we don't
have an in-tree entrypoint for cleaning this up (there are no archive/purge
CLIs for the API DB). We could always add that, but it's not there right
now.
Another thing that came up in the cells meeting this week is that if we
didn't make the flavor soft-deletable, we could still show the flavor
information for a given instance via the server GET API. However, that would
be a microversion change to show the full flavor information for the server
rather than just the flavor id.
This is really only possible because we now store flavor info inside
every instance object.
I think before that, deleting the flavor would make some instance
operations fail.
Because we now store flavor info with each instance it opens up the
following possibility:
Currently the flavor portion of an instance show request looks like
"flavor": {"id": "8", "links": [{"href":
"https://example.com/flavors/8";, "rel": "bookmark"}]}
If that were instead changed to return
"https://example.com/servers//flavor" as the link and we exposed the
flavor information stored with the instance on that endpoint then we no
longer need to expose deleted flavors.
So for an instance booted with flavor 8 https://example.com/flavors/8
would be equivalent to https://example.com/servers//flavor except
that the latter would be available even if flavor 8 were deleted.
Does that seem like an acceptable path for users?
Thoughts? I'm cross-posting this to -dev and the -operators list to see what
kind of user impact there would be if we didn't soft-delete flavors in the
API DB (so you couldn't look up deleted flavors in the API).
In balance, I think we should not allow soft_delete of flavors in the API DB.
In a related note, and I thinking about a backlog spec looking at a
flavor lifecycle. Thinking about early release, to production, then
phasing out of flavors. I don't think soft delete is needed for that.
Thanks,
johnthetubaguy
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Openstack-operators] [nova][cells] Should flavors in the API DB for cells v2 be soft-deletable?
Le 08/01/2016 15:10, Andrew Laski a écrit :
On 01/08/16 at 12:43pm, John Garbutt wrote:
On 7 January 2016 at 19:59, Matt Riedemann
wrote:
There is a cells v2 change up for review [1] which creates the
flavor tables
in the API DB.
I noted that those table definitions include the soft-delete columns
(deleted and deleted_at), which at the YVR summit and in other
threads [2]
we've said we're not doing anymore for new tables.
The point raised to keep them soft-deletable is that the flavor API
allows
showing soft-deleted flavors if you know the id [3]. And you can get
the
flavor id for an instance (we always store the flavor info that was
used to
boot the instance).
The question is, can we break that wrinkle in the API by not allow
soft-deleting the flavor in the API DB?
On balance, I think this is OK.
There's an alternate approach to this that we can take which I'll
outline below. But it should meet the needs of anyone currently
looking up deleted flavors.
Note that in the normal nova DB, if the admin archives/purges the
instance_types table, the wrinkle is already broken because the
soft-deleted
flavor is now hard-deleted, but that's maybe not a great
justification for
consciously removing this support in the API DB.
This is what won me over. All be it, reluctantly.
I think this is good justification for removing the ability because
currently it is essentially undefined behavior. Requesting a deleted
flavor may or may not work and either response is correct.
If we made the flavor soft-deletable in the API DB, one issue is we
don't
have an in-tree entrypoint for cleaning this up (there are no
archive/purge
CLIs for the API DB). We could always add that, but it's not there
right
now.
Another thing that came up in the cells meeting this week is that if we
didn't make the flavor soft-deletable, we could still show the flavor
information for a given instance via the server GET API. However,
that would
be a microversion change to show the full flavor information for the
server
rather than just the flavor id.
This is really only possible because we now store flavor info inside
every instance object.
I think before that, deleting the flavor would make some instance
operations fail.
Because we now store flavor info with each instance it opens up the
following possibility:
Currently the flavor portion of an instance show request looks like
"flavor": {"id": "8", "links": [{"href":
"https://example.com/flavors/8";, "rel": "bookmark"}]}
If that were instead changed to return
"https://example.com/servers//flavor" as the link and we exposed
the flavor information stored with the instance on that endpoint then
we no longer need to expose deleted flavors.
So for an instance booted with flavor 8 https://example.com/flavors/8
would be equivalent to https://example.com/servers//flavor
except that the latter would be available even if flavor 8 were deleted.
Does that seem like an acceptable path for users?
Yes, that's something we discussed on IRC yesterday which I think would
be very good. It means a microversion but it means that operators would
be very happy because if a flavor is removed, the flavor URI would still
be working.
+1000 to that.
-Sylvain
Thoughts? I'm cross-posting this to -dev and the -operators list to
see what
kind of user impact there would be if we didn't soft-delete flavors
in the
API DB (so you couldn't look up deleted flavors in the API).
In balance, I think we should not allow soft_delete of flavors in the
API DB.
In a related note, and I thinking about a backlog spec looking at a
flavor lifecycle. Thinking about early release, to production, then
phasing out of flavors. I don't think soft delete is needed for that.
Thanks,
johnthetubaguy
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Openstack-operators] [nova][cells] Should flavors in the API DB for cells v2 be soft-deletable?
IMHO I think it's a great way to fix the URI problem.
+1
Belmiro
On Fri, Jan 8, 2016 at 3:23 PM, Sylvain Bauza wrote:
>
>
> Le 08/01/2016 15:10, Andrew Laski a écrit :
>
>> On 01/08/16 at 12:43pm, John Garbutt wrote:
>>
>>> On 7 January 2016 at 19:59, Matt Riedemann
>>> wrote:
>>>
There is a cells v2 change up for review [1] which creates the flavor
tables
in the API DB.
I noted that those table definitions include the soft-delete columns
(deleted and deleted_at), which at the YVR summit and in other threads
[2]
we've said we're not doing anymore for new tables.
The point raised to keep them soft-deletable is that the flavor API
allows
showing soft-deleted flavors if you know the id [3]. And you can get the
flavor id for an instance (we always store the flavor info that was
used to
boot the instance).
The question is, can we break that wrinkle in the API by not allow
soft-deleting the flavor in the API DB?
>>>
>>> On balance, I think this is OK.
>>>
>>
>> There's an alternate approach to this that we can take which I'll outline
>> below. But it should meet the needs of anyone currently looking up deleted
>> flavors.
>>
>>
>>
>>> Note that in the normal nova DB, if the admin archives/purges the
instance_types table, the wrinkle is already broken because the
soft-deleted
flavor is now hard-deleted, but that's maybe not a great justification
for
consciously removing this support in the API DB.
>>>
>>> This is what won me over. All be it, reluctantly.
>>>
>>
>> I think this is good justification for removing the ability because
>> currently it is essentially undefined behavior. Requesting a deleted flavor
>> may or may not work and either response is correct.
>>
>>
>>> If we made the flavor soft-deletable in the API DB, one issue is we don't
have an in-tree entrypoint for cleaning this up (there are no
archive/purge
CLIs for the API DB). We could always add that, but it's not there right
now.
Another thing that came up in the cells meeting this week is that if we
didn't make the flavor soft-deletable, we could still show the flavor
information for a given instance via the server GET API. However, that
would
be a microversion change to show the full flavor information for the
server
rather than just the flavor id.
>>>
>>> This is really only possible because we now store flavor info inside
>>> every instance object.
>>> I think before that, deleting the flavor would make some instance
>>> operations fail.
>>>
>>
>> Because we now store flavor info with each instance it opens up the
>> following possibility:
>>
>> Currently the flavor portion of an instance show request looks like
>> "flavor": {"id": "8", "links": [{"href": "https://example.com/flavors/8";,
>> "rel": "bookmark"}]}
>>
>> If that were instead changed to return
>> "https://example.com/servers//flavor"
>> as the link and we exposed the flavor information stored with the instance
>> on that endpoint then we no longer need to expose deleted flavors.
>>
>> So for an instance booted with flavor 8 https://example.com/flavors/8
>> would be equivalent to https://example.com/servers//flavor except
>> that the latter would be available even if flavor 8 were deleted.
>>
>> Does that seem like an acceptable path for users?
>>
>>
> Yes, that's something we discussed on IRC yesterday which I think would be
> very good. It means a microversion but it means that operators would be
> very happy because if a flavor is removed, the flavor URI would still be
> working.
>
> +1000 to that.
>
> -Sylvain
>
>
>
>
>>> Thoughts? I'm cross-posting this to -dev and the -operators list to see
what
kind of user impact there would be if we didn't soft-delete flavors in
the
API DB (so you couldn't look up deleted flavors in the API).
>>>
>>> In balance, I think we should not allow soft_delete of flavors in the
>>> API DB.
>>>
>>> In a related note, and I thinking about a backlog spec looking at a
>>> flavor lifecycle. Thinking about early release, to production, then
>>> phasing out of flavors. I don't think soft delete is needed for that.
>>>
>>> Thanks,
>>> johnthetubaguy
>>>
>>> __
>>>
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>> __
>>
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> ___
> OpenStack-operators mailing list
> o
Re: [openstack-dev] [Openstack-operators] [nova][cells] Should flavors in the API DB for cells v2 be soft-deletable?
On 01/08/2016 09:10 AM, Andrew Laski wrote:
> On 01/08/16 at 12:43pm, John Garbutt wrote:
>> On 7 January 2016 at 19:59, Matt Riedemann
>> wrote:
>>> There is a cells v2 change up for review [1] which creates the flavor
>>> tables
>>> in the API DB.
>>>
>>> I noted that those table definitions include the soft-delete columns
>>> (deleted and deleted_at), which at the YVR summit and in other
>>> threads [2]
>>> we've said we're not doing anymore for new tables.
>>>
>>> The point raised to keep them soft-deletable is that the flavor API
>>> allows
>>> showing soft-deleted flavors if you know the id [3]. And you can get the
>>> flavor id for an instance (we always store the flavor info that was
>>> used to
>>> boot the instance).
>>>
>>> The question is, can we break that wrinkle in the API by not allow
>>> soft-deleting the flavor in the API DB?
>>
>> On balance, I think this is OK.
>
> There's an alternate approach to this that we can take which I'll
> outline below. But it should meet the needs of anyone currently looking
> up deleted flavors.
>
>
>>
>>> Note that in the normal nova DB, if the admin archives/purges the
>>> instance_types table, the wrinkle is already broken because the
>>> soft-deleted
>>> flavor is now hard-deleted, but that's maybe not a great
>>> justification for
>>> consciously removing this support in the API DB.
>>
>> This is what won me over. All be it, reluctantly.
>
> I think this is good justification for removing the ability because
> currently it is essentially undefined behavior. Requesting a deleted
> flavor may or may not work and either response is correct.
I agree. Our old contract was essentially:
* you can have access to deleted flavors if you know the id, until such
time that you can't because it was actually purged.
Making the 'until such time' go to 0 seems fine.
>>> If we made the flavor soft-deletable in the API DB, one issue is we
>>> don't
>>> have an in-tree entrypoint for cleaning this up (there are no
>>> archive/purge
>>> CLIs for the API DB). We could always add that, but it's not there right
>>> now.
>>>
>>> Another thing that came up in the cells meeting this week is that if we
>>> didn't make the flavor soft-deletable, we could still show the flavor
>>> information for a given instance via the server GET API. However,
>>> that would
>>> be a microversion change to show the full flavor information for the
>>> server
>>> rather than just the flavor id.
>>
>> This is really only possible because we now store flavor info inside
>> every instance object.
>> I think before that, deleting the flavor would make some instance
>> operations fail.
>
> Because we now store flavor info with each instance it opens up the
> following possibility:
>
> Currently the flavor portion of an instance show request looks like
> "flavor": {"id": "8", "links": [{"href":
> "https://example.com/flavors/8";, "rel": "bookmark"}]}
>
> If that were instead changed to return
> "https://example.com/servers//flavor" as the link and we exposed
> the flavor information stored with the instance on that endpoint then we
> no longer need to expose deleted flavors.
>
> So for an instance booted with flavor 8 https://example.com/flavors/8
> would be equivalent to https://example.com/servers//flavor except
> that the latter would be available even if flavor 8 were deleted.
>
> Does that seem like an acceptable path for users?
I've proposed https://review.openstack.org/#/c/265282/ as the spec for
this change. Once you stare at the attributes in flavors, a bunch of
them really aren't needed once it becomes a sub resource.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
