Hi, I think that while there are benefits to moving away from the host object, we have a de-facto API based on it. A way to change without breaking user's template would be to use a "proxy" object that maintains the same endpoints and allows adding functionality or handling changes in the underlying objects without breaking the way users use them. So the templates will still have a "@host" object with the same methods as before, except it will in fact be proxy object and not an active record. For example, we could have a nice error message if the actual host is nil. We could also leverage method_missing to easily handle passing anything not defined in the api to the host (possibly only if safe mode is off), so that any users relying on active record methods etc. won't have breakage.
Tomer On Mon, Jan 16, 2017 at 2:49 PM, Stephen Benjamin <stben...@redhat.com> wrote: > On Mon, Jan 16, 2017 at 3:24 AM, Ondrej Prazak <opra...@redhat.com> wrote: > > > > +1 for keeping the macros. IMHO, just because we did something a certain > way for a long time should not prevent us from changing it if there are > reasons for a change. This is also not the first change in core that > affected plugin(s) in a negative way and I doubt it will be the last. > Breaking plugin tests is unpleasant, but it is still a second best scenario. > > > The plugin test failure is relatively minor, the main objection here > is the number of users who rely on this interface now need to change. > After raising this issue we got some PR's that help the migrations > which is nice, but there's > organizations who have less sophisticated technical users who learned > basic ERB who have to re-learn this, not to mention that git repos of > users using foreman_templates now have to update, and we now have lots > of incorrect info out there on the internet and internal intranets > that need to be updated. We're making our users do a lot of work for > not a lot of good. > > The change was not needed, and it was merged while a significant > number of developers were away for the holidays. I think it should be > changed to restore the @host interface, or reverted. I know there are > some benefits to stop using the Host::Managed object, but we could've > implemented @host as an instance of some proxy class without breakage > for users. > > FWIW, this change, if we actually followed semver, should require a > bump to 2.0 once the deprecated methods are removed. > > - Stephen > > -- > You received this message because you are subscribed to the Google Groups > "foreman-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to foreman-dev+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- Have a nice day, Tomer Brisker Red Hat Engineering -- You received this message because you are subscribed to the Google Groups "foreman-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to foreman-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
