++ 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 <dava...@gmail.com> wrote:
> On Tue, Jul 11, 2017 at 7:33 AM, Chris Dent <cdent...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
--
--
Kind regards,
Melvin Hillsman
mrhills...@gmail.com
mobile: (832) 264-2646
Learner | Ideation | Belief | Responsibility | Command
__________________________________________________________________________
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
