Open Stack

++ As I was not sure how to word it without sounding too opinionated
without appropriate technical jargon. When most folks hear "mostly the
same" regarding a critical component, and sometimes not so critical ones,
that raises all kinds of red flags. I could not think from purely code
aspect of what that means but from operations it means potentially it could
affect the bottom line and well, that affects everyone generally :)

On Tue, Jul 11, 2017 at 6:45 AM, Davanum Srinivas <davanum at gmail.com> wrote:

> On Tue, Jul 11, 2017 at 7:33 AM, Chris Dent <cdent+os at anticdent.org>
> wrote:
> > On Tue, 11 Jul 2017, Mikhail Fedosin wrote:
> >
> >> For example, deactivating an image in Glance looks like *POST*
> >> /v2/images/{image_id}/actions/deactivate with empty body.
> >> At one time, Chris Dent advised us to avoid such decisions, and simply
> >> change the status of the artifact to 'deactivated' using *PATCH*, which
> we
> >> did.
> >
> >
> > Indeed I did. The point of that was to avoid "actions" style URLs on
> > resources that already have that information in their
> > representations so that the interface is more RESTful and doesn't
> > have a profusion of verby URLs. The other option is to PUT a full
> > representation with the status changed.
> >
> > But that's not the point here. The issue is that in order for Glare
> > to provide a seamless compatibility layer with Glance it needs to be
> > able to present a facade which is _identical_ to Glance. Not mostly
> > the same but with improvement, but identical with all the same
> > warts.
>
> Big +1 to "Not mostly the same but with improvement, but identical
> with all the same warts.". Anything else is a deal breaker IMHO.
>
> Thanks,
> Dims
>
> >
> > This provides a critical part in a smooth migration plan. As people
> > become aware of glare being there, they can start taking advantage
> > of the new features in their new code or code that they are ready to
> > update, without having to update old stuff.
> >
> > If Glare has fairly good separation between the code that handles
> > URLs and processes bodies (in and out) and the code that does stuff
> > with those bodies[1], it ought to be somewhat straightforward to
> > create such a facade.
> >
> > [1] Not gonna use model, view, controller here; those terms have
> > never been accurate for web-based APIs.
> >
> >
> >
> > --
> > Chris Dent                  ┬──┬◡ﾉ(° -°ﾉ)       https://anticdent.org/
> > freenode: cdent                                         tw: @anticdent
> >
> > ____________________________________________________________
> ______________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:
> unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
>
>
> --
> Davanum Srinivas :: https://twitter.com/dims
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
-- 
Kind regards,

Melvin Hillsman
mrhillsman at gmail.com
mobile: (832) 264-2646

Learner | Ideation | Belief | Responsibility | Command
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170711/51c0fc59/attachment.html>