Agreeing with everything else already said, it would be cool to filter
the change log using a time/date range to see all changes in a certain
timeframe. For instance, the CDN broke at 1pm, and I want to see all
the changes a few hours prior.

-Rawlin

On Fri, Mar 23, 2018 at 11:03 AM, Jeremy Mitchell <mitchell...@gmail.com> wrote:
> Yes, I was just thinking about filtering of the change log as well. For
> example, change logs probably need to be filtered by tenancy and/or
> role/capability.
>
> Example, as a user, i'm not interested in delivery service changes outside
> my tenancy nor should i see them at all. Nor should I see certain types of
> changes. I.e. server changes.
>
> So I think the change log endpoints are going to need to be enhanced to
> support this more advanced filtering.
>
> Jeremy
>
> On Fri, Mar 23, 2018 at 10:50 AM, Chris Lemmons <alfic...@gmail.com> wrote:
>
>> And while I think a robust and detailed changelog is a first step,
>> some finer filtering mechanisms on the other end may be valuable as
>> well. For example, it might be useful at some point in the future to
>> have the default view of the changelog elide the DSR changes (which
>> could be viewed easily by adjusting the filter). Just spitballing, of
>> course, but the principle of "have as much data as is reasonable and
>> provide powerful tools to manipulate it" goes a long way.
>>
>> On Fri, Mar 23, 2018 at 10:11 AM, Jeremy Mitchell <mitchell...@gmail.com>
>> wrote:
>> > Can't argue with that. Our change log needs to be more robust imo. Like
>> you
>> > said, what exactly changed on server with id=42?
>> >
>> > On Fri, Mar 23, 2018 at 9:08 AM, Chris Lemmons <alfic...@gmail.com>
>> wrote:
>> >
>> >> The changelog exists to answer the question, "Who made things this way
>> >> and when?"
>> >>
>> >> I think we do need changelog entries on everything change that changes
>> >> things, but those comments aren't useful unless they tell us what
>> >> changed and what the old and new values are. So, I'm not in favour of
>> >> filling the changelog with a whole bunch of:
>> >>
>> >> myusername - Updated server ['Foo'] with id: 42
>> >>
>> >> But I'd be quite interested in this:
>> >>
>> >> myusername - Updated server ['Foo'] with id 42: Changed 'origin' from
>> >> 'http://foo.example.com' to 'http://bar.example.com'.
>> >>
>> >> I think that moves it from being spammy to being useful. Might take a
>> >> bit of thought to make sure we don't create epic changelog messages
>> >> when someone creates a whole new object or changes a large number of
>> >> things, but overall I think it would be very useful.
>> >>
>> >> WRT the DSRs, I think that considering them to be Change Logs
>> >> themselves might work at some point, but it's not quite there yet. I
>> >> would include the changes to DSRs.
>> >>
>> >> On Wed, Mar 21, 2018 at 10:46 AM, Dewayne Richardson <
>> dewr...@apache.org>
>> >> wrote:
>> >> > IMO, I don't think it's necessary to pollute the Change Log with
>> Delivery
>> >> > Service Requests (DSRs) comments.  I think DSRs are turning out to be
>> the
>> >> > Change Log for Delivery Services and comments on those are Change Log
>> >> noise.
>> >> >
>> >> > -Dew
>> >> >
>> >> > On Wed, Mar 21, 2018 at 10:24 AM, Jeremy Mitchell <
>> >> mitchell...@apache.org>
>> >> > wrote:
>> >> >
>> >> >> Currently, every POST (create), PUT (update) or DELETE (delete) TO
>> API
>> >> >> endpoint (or most of them) create a change log entry.
>> >> >>
>> >> >> For example when i PUT /api/cachegroups/4 it creates this CL entry:
>> >> >>
>> >> >> myusername - Updated Cachegroup named 'Foo' with id: 57
>> >> >>
>> >> >> Question: In the golang rewrite of the TO API should EVERY POST, PUT
>> >> >> and DELETE trigger a change log entry? Or should it be optional and
>> >> >> determine by the developer?
>> >> >>
>> >> >> I ask because I'm adding endpoints for create, update and delete of
>> >> >> delivery service request comments and it feels like too much to
>> create a
>> >> >> change log entry for that. I'd hate to pollute the change log for
>> minor
>> >> >> stuff.
>> >> >>
>> >> >> To me, it seems like it should be optional and determined by the API
>> >> >> developer.
>> >> >>
>> >> >> Jeremy
>> >> >>
>> >>
>>

Reply via email to