Re: [VOTE] CHANGELOG.md file (second try)

[Dave Neuman]

Hey Rawlin,
I think Steve was starting to work on one, so we will see what he says.
If he doesn't have one started, I think you can go ahead and create one.

Thanks,
Dave

On Wed, Feb 7, 2018 at 4:04 PM, Rawlin Peters 
wrote:

> Hey all,
>
> So it appears this vote passed in favor of adding a CHANGELOG.md file
> without having a changelog label in GitHub. Is anyone currently
> working on one?
>
> With the 2.2 release planned for 2/12/18, I'd like to at least put in
> some upgrade release notes about Per-Delivery-Service Routing Names.
> If no one has a CHANGELOG.md in progress, I'll take the liberty to
> start one and add those release notes in there (using
> https://github.com/influxdata/influxdb/blob/master/CHANGELOG.md as an
> example template).
>
> -Rawlin
>
> On Wed, Jan 10, 2018 at 10:35 AM, Chris Lemmons 
> wrote:
> > [X] +1 to adding a changelog.MD file
> > [] -1 to adding a changelog.MD file
> >
> > That said, I'm only in favour of it if we're fastidious about
> > requiring changelog updates on every single PR. A PR should either
> > provide a reasonable changelog entry, or, in the body of the PR,
> > justify it's absence. A simple "This bugfix does not require a
> > changelog entry." is sufficient for trivial bugfixes. That's plenty
> > for a reviewer to quickly either agree or decide to request (or
> > provide) an entry.
> >
> > If we add the changelog file, we need to update the contributing file
> > to include the new guidelines.
> >
> > On Wed, Jan 10, 2018 at 9:14 AM, Jeremy Mitchell 
> wrote:
> >> Yes, I was about to mention milestones. Why not leverage Github
> milestones
> >> on issues/PRs? We talked about using milestones at the last TC summit to
> >> determine the scope of a release. Now is our chance to do that.
> >>
> >> Milestones can be applied to issues or PRs. I tend to create issues for
> >> everything I do, so I would put the milestone on the issue but others
> can
> >> simply put a milestone on their PR (if there is no related issue).
> Either
> >> way, it tags the items we want included in the changelog. And then the
> RM
> >> can build the changelog from the milestones. Easy peasy.
> >>
> >> Jeremy
> >>
> >>
> >>
> >>
> >>
> >>
> >> On Tue, Jan 9, 2018 at 4:56 PM, Leif Hedstrom  wrote:
> >>
> >>>
> >>>
> >>> > On Jan 9, 2018, at 10:22 AM, Dave Neuman  wrote:
> >>> >
> >>> > Looks like this thread died over the holidays.  Let me try to bring
> it
> >>> back
> >>> > up before we cut a 2.2 branch.
> >>> > Can you please respond with *just* the following:
> >>> >
> >>> > [X] +1 to adding a changelog.MD file
> >>> > [] -1 to adding a changelog.MD file
> >>> >
> >>> > [] +1 to adding a changelog label in github
> >>> > [X] -1 to adding a changelog label in github
> >>> >
> >>>
> >>>
> >>> To add to the previous thread / thoughts. I feel reasonably strongly
> that
> >>> having a changelog label in Github is not useful. In the ATS
> community, we
> >>> can *barely* get people to set the Milestone properly, and I feel that
> the
> >>> Milestone is a much more important thing to keep accurate than anything
> >>> else. And, to be normalized, you don’t want to duplicate this info :-).
> >>>
> >>> So, what we do is have the RM be like a hawk over the Milestones, and
> then
> >>> run Phil’s fancy pants script to generate the ChangeLog from the
> Milestones
> >>> on all PRs closed.
> >>>
> >>> Cheers,
> >>>
> >>> — leif
> >>>
> >>> > Thanks,
> >>> > Dave
> >>> >
> >>> > On Fri, Dec 15, 2017 at 9:14 AM, Dewayne Richardson <
> dewr...@gmail.com>
> >>> > wrote:
> >>> >
> >>> >> +1 on the CHANGELOG.md as well, but I like having the changelog
> label
> >>> >> because it helps streamline it's creation.  I also think the labels
> are
> >>> >> valuable because they help summarize the parts of the repo that
> changed
> >>> and
> >>> >> keeps the concept closer to the repository (where the real change
> is).
> >>> >>
> >>> >> -Dew
> >>> >>
> >>> >> On Thu, Dec 14, 2017 at 3:01 PM, Robert Butts <
> robert.o.bu...@gmail.com
> >>> >
> >>> >> wrote:
> >>> >>
> >>> >>> +1. To clarify, I'm +1 on having the "changelog" label, to help
> whoever
> >>> >>> manually goes thru and builds the CHANGELOG.md.
> >>> >>>
> >>> >>> But I agree with @neuman I don't think we can automate this.
> Titles are
> >>> >> too
> >>> >>> short, some changes need longer explanations and some don't, only a
> >>> human
> >>> >>> can figure out how important something is to users; a high
> priority bug
> >>> >> fix
> >>> >>> could still be low-impact, or vica-versa. Much as I dislike manual
> >>> >> things,
> >>> >>> this really needs human judgement. And we absolutely need a good
> >>> >> Changelog
> >>> >>> with each Release.
> >>> >>>
> >>> >>> On Thu, Dec 14, 2017 at 2:36 PM, Dave Neuman 
> >>> wrote:
> >>> >>>
> >>>  Thanks for putting that together Dewayne. I was just starting to
> do
> >>> >> that
> 

Re: [VOTE] CHANGELOG.md file (second try)

[Rawlin Peters]

Hey all,

So it appears this vote passed in favor of adding a CHANGELOG.md file
without having a changelog label in GitHub. Is anyone currently
working on one?

With the 2.2 release planned for 2/12/18, I'd like to at least put in
some upgrade release notes about Per-Delivery-Service Routing Names.
If no one has a CHANGELOG.md in progress, I'll take the liberty to
start one and add those release notes in there (using
https://github.com/influxdata/influxdb/blob/master/CHANGELOG.md as an
example template).

-Rawlin

On Wed, Jan 10, 2018 at 10:35 AM, Chris Lemmons  wrote:
> [X] +1 to adding a changelog.MD file
> [] -1 to adding a changelog.MD file
>
> That said, I'm only in favour of it if we're fastidious about
> requiring changelog updates on every single PR. A PR should either
> provide a reasonable changelog entry, or, in the body of the PR,
> justify it's absence. A simple "This bugfix does not require a
> changelog entry." is sufficient for trivial bugfixes. That's plenty
> for a reviewer to quickly either agree or decide to request (or
> provide) an entry.
>
> If we add the changelog file, we need to update the contributing file
> to include the new guidelines.
>
> On Wed, Jan 10, 2018 at 9:14 AM, Jeremy Mitchell  
> wrote:
>> Yes, I was about to mention milestones. Why not leverage Github milestones
>> on issues/PRs? We talked about using milestones at the last TC summit to
>> determine the scope of a release. Now is our chance to do that.
>>
>> Milestones can be applied to issues or PRs. I tend to create issues for
>> everything I do, so I would put the milestone on the issue but others can
>> simply put a milestone on their PR (if there is no related issue). Either
>> way, it tags the items we want included in the changelog. And then the RM
>> can build the changelog from the milestones. Easy peasy.
>>
>> Jeremy
>>
>>
>>
>>
>>
>>
>> On Tue, Jan 9, 2018 at 4:56 PM, Leif Hedstrom  wrote:
>>
>>>
>>>
>>> > On Jan 9, 2018, at 10:22 AM, Dave Neuman  wrote:
>>> >
>>> > Looks like this thread died over the holidays.  Let me try to bring it
>>> back
>>> > up before we cut a 2.2 branch.
>>> > Can you please respond with *just* the following:
>>> >
>>> > [X] +1 to adding a changelog.MD file
>>> > [] -1 to adding a changelog.MD file
>>> >
>>> > [] +1 to adding a changelog label in github
>>> > [X] -1 to adding a changelog label in github
>>> >
>>>
>>>
>>> To add to the previous thread / thoughts. I feel reasonably strongly that
>>> having a changelog label in Github is not useful. In the ATS community, we
>>> can *barely* get people to set the Milestone properly, and I feel that the
>>> Milestone is a much more important thing to keep accurate than anything
>>> else. And, to be normalized, you don’t want to duplicate this info :-).
>>>
>>> So, what we do is have the RM be like a hawk over the Milestones, and then
>>> run Phil’s fancy pants script to generate the ChangeLog from the Milestones
>>> on all PRs closed.
>>>
>>> Cheers,
>>>
>>> — leif
>>>
>>> > Thanks,
>>> > Dave
>>> >
>>> > On Fri, Dec 15, 2017 at 9:14 AM, Dewayne Richardson 
>>> > wrote:
>>> >
>>> >> +1 on the CHANGELOG.md as well, but I like having the changelog label
>>> >> because it helps streamline it's creation.  I also think the labels are
>>> >> valuable because they help summarize the parts of the repo that changed
>>> and
>>> >> keeps the concept closer to the repository (where the real change is).
>>> >>
>>> >> -Dew
>>> >>
>>> >> On Thu, Dec 14, 2017 at 3:01 PM, Robert Butts >> >
>>> >> wrote:
>>> >>
>>> >>> +1. To clarify, I'm +1 on having the "changelog" label, to help whoever
>>> >>> manually goes thru and builds the CHANGELOG.md.
>>> >>>
>>> >>> But I agree with @neuman I don't think we can automate this. Titles are
>>> >> too
>>> >>> short, some changes need longer explanations and some don't, only a
>>> human
>>> >>> can figure out how important something is to users; a high priority bug
>>> >> fix
>>> >>> could still be low-impact, or vica-versa. Much as I dislike manual
>>> >> things,
>>> >>> this really needs human judgement. And we absolutely need a good
>>> >> Changelog
>>> >>> with each Release.
>>> >>>
>>> >>> On Thu, Dec 14, 2017 at 2:36 PM, Dave Neuman 
>>> wrote:
>>> >>>
>>>  Thanks for putting that together Dewayne. I was just starting to do
>>> >> that
>>>  myself when I saw it was already done.
>>>  As a developer this is fine, I can see a list of PRs and click on each
>>> >>> one
>>>  to see the whole conversation.  I can comb through them and get a
>>> >> general
>>>  sense for what changed.
>>> 
>>>  However, as an operator and user of Traffic Control (which I mostly am
>>>  these days) I am -1 for the following reasons:
>>>  1) only committers can assign labels to issues and pull requests.
>>> This
>>>  means that the committers need 

Re: Delivery Service Self-Service

[Jeremy Mitchell]

Thanks for all the input. Here's what I heard. For a refresher, these are
the 7 things that a "non-ops" user should be able to perform to achieve
"delivery service self-service":

1. CRUD delivery services - ✓

- non-ops users will be able to create "delivery service requests". ops
users will be able to fulfill those requests. so indirectly, non-ops users
can CRUD ds's. I will be creating documentation around this shortly.

2. Manage DS regexes - X

- this action should continue to be limited to ops users...however, maybe
we allow non-ops users to create cnames and cnames only that don't contain
regex values but conform to hostname format only. more research needed here.

3. Manage SSL keys - ✓

- non-ops users should be able to manage (add, generate) ssl keys for their
delivery services.

4. Manage URL sig keys - ✓

- non-ops users can already do this for their delivery services

5. Manage URI signing keys - X

- this action should continue to be limited to ops users as it could be
dangerous at the moment (i.e. bad neighbor behavior). need more research
here.

6. Manage steering targets - ✓

- Tenancy dictates which delivery services can be defined as a target
therefore no risk to allowing non-ops users to manage steering targets.
(they can only point a steering ds to their own ds's)

7. Invalidate DS content - ✓

- non-ops users can already do this for their delivery services

Not bad. 5 out of 7.

I will follow up later regarding "Manage DS regexes" and "Manage URI
signing keys" so we can figure out a way to provide that functionality to
non-ops users...

Thanks again,

Jeremy



On Mon, Feb 5, 2018 at 12:26 PM, Nir Sopher  wrote:

> Hi Jeremy and all,
>
> Jeremy, thanks for putting it all together!
>
> I'll be short, as I mostly agree with most of point the Jeremy's pointed
> out.
>
> Regarding the "DS regex", like Ryan IIUC, I believe, the operator needs to
> be able to configure it and control it.
> First of all as it defines a resource in the operator's domain.
> Second, the definition of the regex requires some clear methodology to
> avoid collisions, or reuse/abuse.
> Following Rawlin remark, some reasonable default should be provided, but we
> must have the ability to change it.
> Note that path regexs are important as DS identifiers, supporting the SVA
> open-caching scheme.
>
> For the last point, the DS/Server assignment, I believe it should be in the
> hands of the operator.
> In the future it can be delegated the the user, subject to capacity
> management. The user should not be familiar with the actual caches, but can
> use some filters/tagging for defining the caches to be used.
>
> Nir
>
> On Mon, Feb 5, 2018 at 8:23 PM, Rawlin Peters 
> wrote:
>
> > Replies inline
> >
> > On Fri, Feb 2, 2018 at 1:43 PM, Jeremy Mitchell 
> > wrote:
> > > 2. Manage DS regexes
> > >
> > > Here's an explanation of this:
> > > http://traffic-control-cdn.readthedocs.io/en/latest/
> > admin/traffic_ops/using.html#delivery-service-regexp
> > >
> > > Currently, this requires the Operations role and for good reason. The
> > > danger here involves the risk of a normal user entering a bad regex.
> For
> > > example, it is my understanding that the regex in position zero needs
> to
> > > always follow this format: .*\.foo\..*.
> > >
> > > Maybe with some better API validation we could let normal users manage
> DS
> > > regexesor maybe these end up going away in favor of something
> > > better/easier...not sure yet...
> >
> > I think the approach that the Traffic Portal takes today is good. Just
> > giving a DS a default HOST regex with order = 0 using the xml_id will
> > probably cover most use cases for the DS. Then for the cases where
> > someone is CNAMEing to the DS FQDN, the DS owner should be able to add
> > a max number of HOST regexes with order > 0 matching the CNAME fqdn.
> > We should probably just call those "CNAME aliases" or something and
> > just expose them as a simple hostname list in the UI rather than as
> > HOST regexes with a specific ordering. For a list of aliases, I don't
> > think the order really matters at that point as long as they're
> > greater than 0 and sequential. That operation could be safe for a
> > regular DS owner assuming we validate that the alias is a valid
> > hostname (not a regex), unique, and not in use anywhere else in that
> > CDN.
> >
> > We might want to prohibit creating multiple HOST regexes with wildcard
> > characters (i.e. non-CNAME-alias)...I'm not even sure there's a valid
> > use case for that.
> >
> > I'm not totally familiar with the usage of PATH and HEADER regexes,
> > but they both seem like they should be secondary to the primary HOST
> > regex that's created by default (e.g. the request should be matched
> > against all primary HOST regexes first before checking against the
> > other types). Right now I can create a PATH regex that essentially
> > black-holes other DSes (which ones get