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 >> >> >> >> >> >>
