<div dir="ltr">IMHO I think it's a great way to fix the URI problem.<div>+1<div><br></div><div>Belmiro</div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jan 8, 2016 at 3:23 PM, Sylvain Bauza <span dir="ltr"><<a href="mailto:sbauza@redhat.com" target="_blank">sbauza@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><br>
<br>
Le 08/01/2016 15:10, Andrew Laski a écrit :<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 01/08/16 at 12:43pm, John Garbutt wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 7 January 2016 at 19:59, Matt Riedemann <<a href="mailto:mriedem@linux.vnet.ibm.com" target="_blank">mriedem@linux.vnet.ibm.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
There is a cells v2 change up for review [1] which creates the flavor tables<br>
in the API DB.<br>
<br>
I noted that those table definitions include the soft-delete columns<br>
(deleted and deleted_at), which at the YVR summit and in other threads [2]<br>
we've said we're not doing anymore for new tables.<br>
<br>
The point raised to keep them soft-deletable is that the flavor API allows<br>
showing soft-deleted flavors if you know the id [3]. And you can get the<br>
flavor id for an instance (we always store the flavor info that was used to<br>
boot the instance).<br>
<br>
The question is, can we break that wrinkle in the API by not allow<br>
soft-deleting the flavor in the API DB?<br>
</blockquote>
<br>
On balance, I think this is OK.<br>
</blockquote>
<br>
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.<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Note that in the normal nova DB, if the admin archives/purges the<br>
instance_types table, the wrinkle is already broken because the soft-deleted<br>
flavor is now hard-deleted, but that's maybe not a great justification for<br>
consciously removing this support in the API DB.<br>
</blockquote>
<br>
This is what won me over. All be it, reluctantly.<br>
</blockquote>
<br>
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.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
If we made the flavor soft-deletable in the API DB, one issue is we don't<br>
have an in-tree entrypoint for cleaning this up (there are no archive/purge<br>
CLIs for the API DB). We could always add that, but it's not there right<br>
now.<br>
<br>
Another thing that came up in the cells meeting this week is that if we<br>
didn't make the flavor soft-deletable, we could still show the flavor<br>
information for a given instance via the server GET API. However, that would<br>
be a microversion change to show the full flavor information for the server<br>
rather than just the flavor id.<br>
</blockquote>
<br>
This is really only possible because we now store flavor info inside<br>
every instance object.<br>
I think before that, deleting the flavor would make some instance<br>
operations fail.<br>
</blockquote>
<br>
Because we now store flavor info with each instance it opens up the following possibility:<br>
<br>
Currently the flavor portion of an instance show request looks like "flavor": {"id": "8", "links": [{"href": "<a href="https://example.com/flavors/8" rel="noreferrer" target="_blank">https://example.com/flavors/8</a>", "rel": "bookmark"}]}<br>
<br>
If that were instead changed to return "<a href="https://example.com/servers/" rel="noreferrer" target="_blank">https://example.com/servers/</a><uuid>/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.<br>
<br>
So for an instance booted with flavor 8 <a href="https://example.com/flavors/8" rel="noreferrer" target="_blank">https://example.com/flavors/8</a> would be equivalent to <a href="https://example.com/servers/" rel="noreferrer" target="_blank">https://example.com/servers/</a><uuid>/flavor except that the latter would be available even if flavor 8 were deleted.<br>
<br>
Does that seem like an acceptable path for users?<br>
<br>
</blockquote>
<br></div></div>
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.<br>
<br>
+1000 to that.<span class="HOEnZb"><font color="#888888"><br>
<br>
-Sylvain</font></span><span class="im HOEnZb"><br>
<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Thoughts? I'm cross-posting this to -dev and the -operators list to see what<br>
kind of user impact there would be if we didn't soft-delete flavors in the<br>
API DB (so you couldn't look up deleted flavors in the API).<br>
</blockquote>
<br>
In balance, I think we should not allow soft_delete of flavors in the API DB.<br>
<br>
In a related note, and I thinking about a backlog spec looking at a<br>
flavor lifecycle. Thinking about early release, to production, then<br>
phasing out of flavors. I don't think soft delete is needed for that.<br>
<br>
Thanks,<br>
johnthetubaguy<br>
<br>
__________________________________________________________________________ <br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote>
<br>
__________________________________________________________________________ <br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote>
<br>
<br></span><div class="HOEnZb"><div class="h5">
_______________________________________________<br>
OpenStack-operators mailing list<br>
<a href="mailto:OpenStack-operators@lists.openstack.org" target="_blank">OpenStack-operators@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
</div></div></blockquote></div><br></div>