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

2018-02-27 Thread Dan Kirkwood 
+1

On Tue, Feb 27, 2018 at 2:50 PM, Jeremy Mitchell 
wrote:

> I like that format. Bullets seems nice and simple with external links where
> more info is required.
>
> I would be in favor of a PR to add these sections so it's easy for the next
> person to add a bullet to the relevant section.
>
> On Tue, Feb 27, 2018 at 2:15 PM, Rawlin Peters 
> wrote:
>
> > Hey folks,
> >
> > So I used the influxdb changelog as an example format, but @dew has
> > shown me this popular project for changelog convention:
> > http://keepachangelog.com/en/1.0.0/. For example see the project
> > changelog: https://github.com/olivierlacan/keep-a-changelog/
> > blob/master/CHANGELOG.md.
> >
> > Since we now have a changelog, it would be best to have a standard,
> > agreed-upon format for it so that we can keep it consistent for every
> > release.
> >
> > Basically it means every release has its own section (with an
> > "unreleased" section at the top), and everything will be
> > bullet-pointed underneath one of these sections for every release:
> > - "Added" for new features.
> > - "Changed" for changes in existing functionality.
> > - "Deprecated" for soon-to-be removed features.
> > - "Removed" for now removed features.
> > - "Fixed" for any bug fixes.
> > - "Security" in case of vulnerabilities.
> >
> > For example with my per-DS routing name upgrade notes currently in the
> > changelog, I would add that to the "Added" section and link to the
> > upgrade notes in our docs.
> >
> >  What do you all think? All in favor of accepting this keepachangelog
> > format?
> >
> > - Rawlin
> >
> >
> >
> > On Thu, Feb 8, 2018 at 2:29 PM, Rawlin Peters 
> > wrote:
> > > I went ahead and created one:
> > > https://github.com/apache/incubator-trafficcontrol/pull/1865. Please
> > > review and merge if you are okay with the current format. I'm not sure
> > > if we want to go back and add a list of all the new features in 2.2 or
> > > not, but please add to the CHANGELOG.md file if you have any pending
> > > release notes like 2.2 upgrade gotchas you'd like to get in.
> > >
> > > Thanks,
> > > Rawlin
> > >
> > > On Wed, Feb 7, 2018 at 4:07 PM, Dave Neuman  wrote:
> > >> 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 <
> rawlin.pet...@gmail.com>
> > >> 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 <
> > mitchell...@gmail.com>
> > >>> 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

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

2018-02-27 Thread Chris Lemmons 
The keepachangelog folks seem to have done a great job describing a
way that works. I'm +1 on re-using their work. :)

On Tue, Feb 27, 2018 at 8:27 PM, Dave Neuman  wrote:
> +1
>
> On Tue, Feb 27, 2018 at 14:50 Jeremy Mitchell  wrote:
>
>> I like that format. Bullets seems nice and simple with external links where
>> more info is required.
>>
>> I would be in favor of a PR to add these sections so it's easy for the next
>> person to add a bullet to the relevant section.
>>
>> On Tue, Feb 27, 2018 at 2:15 PM, Rawlin Peters 
>> wrote:
>>
>> > Hey folks,
>> >
>> > So I used the influxdb changelog as an example format, but @dew has
>> > shown me this popular project for changelog convention:
>> > http://keepachangelog.com/en/1.0.0/. For example see the project
>> > changelog: https://github.com/olivierlacan/keep-a-changelog/
>> > blob/master/CHANGELOG.md.
>> >
>> > Since we now have a changelog, it would be best to have a standard,
>> > agreed-upon format for it so that we can keep it consistent for every
>> > release.
>> >
>> > Basically it means every release has its own section (with an
>> > "unreleased" section at the top), and everything will be
>> > bullet-pointed underneath one of these sections for every release:
>> > - "Added" for new features.
>> > - "Changed" for changes in existing functionality.
>> > - "Deprecated" for soon-to-be removed features.
>> > - "Removed" for now removed features.
>> > - "Fixed" for any bug fixes.
>> > - "Security" in case of vulnerabilities.
>> >
>> > For example with my per-DS routing name upgrade notes currently in the
>> > changelog, I would add that to the "Added" section and link to the
>> > upgrade notes in our docs.
>> >
>> >  What do you all think? All in favor of accepting this keepachangelog
>> > format?
>> >
>> > - Rawlin
>> >
>> >
>> >
>> > On Thu, Feb 8, 2018 at 2:29 PM, Rawlin Peters 
>> > wrote:
>> > > I went ahead and created one:
>> > > https://github.com/apache/incubator-trafficcontrol/pull/1865. Please
>> > > review and merge if you are okay with the current format. I'm not sure
>> > > if we want to go back and add a list of all the new features in 2.2 or
>> > > not, but please add to the CHANGELOG.md file if you have any pending
>> > > release notes like 2.2 upgrade gotchas you'd like to get in.
>> > >
>> > > Thanks,
>> > > Rawlin
>> > >
>> > > On Wed, Feb 7, 2018 at 4:07 PM, Dave Neuman  wrote:
>> > >> 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 <
>> rawlin.pet...@gmail.com>
>> > >> 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 <
>> > mitchell...@gmail.com>
>> > >>> 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

Re: Github PR/Issues Format Templates

2018-02-27 Thread Chris Lemmons 
If there's a relevant GitHub issue, that should be noted in the
check-in comment, I think. Same for "what does it do?" I don't usually
want to spell out steps for someone to verify my stuff because those
are the steps that I took to verify it. The PR is so you can see the
things I didn't see. And the commit list will make the presence of
tests, documentation, and a changelog entry really obvious.

Taking yours and reformatting a bit, what if we did something like this?

...

*Describe your PR:* _(copy/paste from changeset comments is encouraged!)_



*Quick Checklist:*

- [ ] Each commit message tells you everything you need to know about
the change. (Squashing can help with this.)
- [ ] If applicable, the commit message mentions the appropriate issue number.
- [ ] This PR does *not* fix a serious security flaw. (Read more:
www.apache.org/security )
- [ ] Automatic code formatters (like gofmt) have been run.

*Tests:*

- [ ] Are not necessary.
- [ ] Would be helpful, but aren't in this PR.
- [ ] Are present, but incomplete.
- [ ] Are included.

*Doc updates:*

- [ ] Are not necessary.
- [ ] Would be helpful, but aren't in this PR.
- [ ] Are present, but incomplete.
- [ ] Are included.

*If there's no update to CHANGELOG.md, why not?*

*Does this break backward compatibility?*

*Is there anyone specific that ought to take a look at this?*

...

We want to be friendly to committers, while still getting good
information for checking PRs. I could be easily convinced that the
"Tests" or "Doc updates" sections in there are too long, but I think
it should be clear that a potential committer can offer up some code
without hitting 100% on tests, docs, and such.

On Tue, Feb 27, 2018 at 1:24 PM, Jeremy Mitchell  wrote:
> How about something like this for a PR template?
>
>  What does this PR do? Is there a relevant Github issue?
>
>
>  What is the best way to verify this PR?
>
>
>  Does your PR include any of the following?
>
> - [ ] Tests
> - [ ] Documentation
> - [ ] CHANGELOG.md entry
>
> On Tue, Feb 27, 2018 at 10:46 AM, Jeremy Mitchell 
> wrote:
>
>> With an issue and/or pr template, we will have 6/6 items checked:
>>
>> https://github.com/apache/incubator-trafficcontrol/community
>>
>> I actually think PR templates would be quite helpful. As a
>> committer/merger, it would be nice to know what problem the PR is solving
>> and how to verify the functionality. A PR template could also help
>> contributors ensure that their PRs are complete. I.e. does this PR includes
>> tests, documentation, etc.
>>
>> I'll take a stab at a couple of templates and run them by the group.
>>
>> Jeremy
>>
>> On Wed, Jan 31, 2018 at 1:10 PM, Chris Lemmons  wrote:
>>
>>> I'm +1 on Issue Templates, for sure. I don't know that PR templates
>>> are quite as critical, but it might be nice to have a reminder in
>>> there about verifying that the changelog is updated if necessary and
>>> documentation for new features is present. If the PR Template
>>> overwrites the default comment that you get from the commit body, it
>>> might be more annoying than valuable, though.
>>>
>>> I'm also +1 on hiding these particular files in a .github directory.
>>> Unlike CONTRIBUTING and README, they don't provide all that much
>>> benefit for a new person looking for stuff to read.
>>>
>>> On Wed, Jan 31, 2018 at 12:17 PM, Durfey, Ryan 
>>> wrote:
>>> > Always +1 on standardization and consistency
>>> >
>>> > I still want to circle back and setup project/kanbans for organizing
>>> tickets in Github.
>>> >
>>> > Ryan DurfeyM | 303-524-5099
>>> > CDN Support (24x7): 866-405-2993 or cdn_supp...@comcast.com>> cdn_supp...@comcast.com>
>>> >
>>> > From: Dewayne Richardson 
>>> > Reply-To: "dev@trafficcontrol.incubator.apache.org" <
>>> dev@trafficcontrol.incubator.apache.org>
>>> > Date: Wednesday, January 31, 2018 at 11:15 AM
>>> > To: "dev@trafficcontrol.incubator.apache.org" <
>>> dev@trafficcontrol.incubator.apache.org>
>>> > Subject: Github PR/Issues Format Templates
>>> >
>>> > I was working through the go-swagger repo and found a bug.  I submitted
>>> a
>>> > new issue and found this interesting approach I think the TC github
>>> should
>>> > adopt, "Issue and PR Templates".  I think the main value here is
>>> > consistency in our PRs/Issues and user friendly prompts to say "these
>>> are
>>> > the data points we need to help you solve your issue".
>>> >
>>> > Working example:
>>> > https://github.com/go-swagger/go-swagger/issues/new
>>> >
>>> > Github Doc on how to implement templates:
>>> > https://github.com/blog/2111-issue-and-pull-request-templates
>>> >
>>> > If we think it's a good idea, then I'll respond with some examples for
>>> > Issues and PR's that we can discuss.
>>> >
>>> > -Dew
>>> >
>>>
>>
>>

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

2018-02-27 Thread Dave Neuman 
+1

On Tue, Feb 27, 2018 at 14:50 Jeremy Mitchell  wrote:

> I like that format. Bullets seems nice and simple with external links where
> more info is required.
>
> I would be in favor of a PR to add these sections so it's easy for the next
> person to add a bullet to the relevant section.
>
> On Tue, Feb 27, 2018 at 2:15 PM, Rawlin Peters 
> wrote:
>
> > Hey folks,
> >
> > So I used the influxdb changelog as an example format, but @dew has
> > shown me this popular project for changelog convention:
> > http://keepachangelog.com/en/1.0.0/. For example see the project
> > changelog: https://github.com/olivierlacan/keep-a-changelog/
> > blob/master/CHANGELOG.md.
> >
> > Since we now have a changelog, it would be best to have a standard,
> > agreed-upon format for it so that we can keep it consistent for every
> > release.
> >
> > Basically it means every release has its own section (with an
> > "unreleased" section at the top), and everything will be
> > bullet-pointed underneath one of these sections for every release:
> > - "Added" for new features.
> > - "Changed" for changes in existing functionality.
> > - "Deprecated" for soon-to-be removed features.
> > - "Removed" for now removed features.
> > - "Fixed" for any bug fixes.
> > - "Security" in case of vulnerabilities.
> >
> > For example with my per-DS routing name upgrade notes currently in the
> > changelog, I would add that to the "Added" section and link to the
> > upgrade notes in our docs.
> >
> >  What do you all think? All in favor of accepting this keepachangelog
> > format?
> >
> > - Rawlin
> >
> >
> >
> > On Thu, Feb 8, 2018 at 2:29 PM, Rawlin Peters 
> > wrote:
> > > I went ahead and created one:
> > > https://github.com/apache/incubator-trafficcontrol/pull/1865. Please
> > > review and merge if you are okay with the current format. I'm not sure
> > > if we want to go back and add a list of all the new features in 2.2 or
> > > not, but please add to the CHANGELOG.md file if you have any pending
> > > release notes like 2.2 upgrade gotchas you'd like to get in.
> > >
> > > Thanks,
> > > Rawlin
> > >
> > > On Wed, Feb 7, 2018 at 4:07 PM, Dave Neuman  wrote:
> > >> 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 <
> rawlin.pet...@gmail.com>
> > >> 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 <
> > mitchell...@gmail.com>
> > >>> 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

Re: Steering Target Geo-Ordering

2018-02-27 Thread Rawlin Peters 
Hey Eric,

In this example I'd think that all the target DSes would need to be
assigned to all 3 Cache Groups. That way the client could possibly use
any of the target DSes from the cachegroup they're routed to. But I
suppose that could change on a case-by-case basis where maybe the
target DSes are only assigned to cache groups that are close to their
origins. In that case I'd think a client in Seattle would possibly be
routed to an edge cache in Boston, which would optimize the connection
between the Boston edge cache and the Boston origin. But it might be
better to have the client connect to an edge cache in Seattle which
then retrieves the content from a Boston origin (although these are
both worst-case scenarios).

As far as the content on the origins themselves go, they'd have to be
interchangeable from the client's perspective, but I'm not sure if it
would have to be identical or not. I imagine that would really depend
on what the steering DS is providing the client.

- Rawlin

On Tue, Feb 27, 2018 at 10:37 AM, Eric Friedrich (efriedri)
 wrote:
> In this example, what would be the assignments of delivery services to edge 
> Cache Groups? Are all 3DS’ assigned to all 3 Cache Groups?
>
> I’ll also assume that the content on the origins, while interchangeable from 
> a clients perspective, is not identical? (i.e. might contain regionalized 
> content?)
>
> —Eric
>
>
>
>
>> On Feb 23, 2018, at 5:40 PM, Rawlin Peters  wrote:
>>
>> Hey folks,
>>
>> At Comcast we have a need to augment CLIENT_STEERING (also regular
>> STEERING while we're at it) to allow targets to be ordered/sorted
>> based upon the client's proximity to the origin of the target delivery
>> services. I'd like to get your feedback on my proposed design and
>> address any of your concerns.
>>
>> For HTTP_LIVE targets for instance, we'd like edge caches to ideally
>> retrieve/serve data from an Origin that is close to the client and
>> fall back to Origins that are farther and farther away. This allows
>> for increased redundancy while ordering optimal Origins (Delivery
>> Services) for a client to choose from.
>>
>> For example, I have 3 Origins in different locations: Seattle, Denver,
>> and Boston. I would create an HTTP_LIVE delivery service for each
>> origin and a CLIENT_STEERING delivery service with those delivery
>> services as targets. I would then like to have those targets ordered
>> based upon proximity to the client. So a client in Seattle would get
>> the list [Seattle, Denver, Boston], while a client in Boston would get
>> the list [Boston, Denver, Seattle].
>>
>> To make things more complicated, I want to add a redundant origin in
>> each location and split traffic between them (like STEERING_WEIGHT
>> today) while taking into account the geo-ordering. I also want to be
>> able to force an ordering (like STEERING_ORDER today) among co-located
>> targets.
>>
>> In order to accomplish this I propose to:
>> 1. add two new steering types: GEO_ORDER and GEO_WEIGHT (by adding a
>> target of type GEO_*, a steering DS would then enable geo-ordering)
>> 2. associate a Delivery Service Origin with a latitude/longitude,
>> thereby associating a lat/long to a GEO_* target
>>
>> Item 1 is pretty straightforward and will also play nicely with the
>> current steering types (STEERING_ORDER and STEERING_WEIGHT). I've
>> completed a POC within Traffic Router that basically provides the
>> following ordering when mixing all 4 types in a single steering
>> delivery service:
>> - Negative STEERING_ORDER targets
>> - GEO_WEIGHT and GEO_ORDER targets, grouped by proximity to the
>> client, ordered by geo-order and the consistent-hashing from the
>> weightings
>> - STEERING_WEIGHT targets (consistent-hashed)
>> - Positive STEERING_ORDER targets
>>
>> Item 2 is not as straightforward because the simple thing would be to
>> just add an Origin Lat/Long field to the Delivery Service and call it
>> a day. However I don't think we should do that, and I'll dive more
>> into that in a separate thread (coming soon).
>>
>> Does anyone have questions/concerns about adding these new GEO_ORDER
>> and GEO_STEERING target types and geo-sorting them based upon
>> proximity to the client? Are you okay with the proposed ordering when
>> all the steering types are mixed together?
>>
>> - Rawlin
>

Re: Github PR/Issues Format Templates

2018-02-27 Thread Jeremy Mitchell 
How about something like this for a PR template?

 What does this PR do? Is there a relevant Github issue?


 What is the best way to verify this PR?


 Does your PR include any of the following?

- [ ] Tests
- [ ] Documentation
- [ ] CHANGELOG.md entry

On Tue, Feb 27, 2018 at 10:46 AM, Jeremy Mitchell 
wrote:

> With an issue and/or pr template, we will have 6/6 items checked:
>
> https://github.com/apache/incubator-trafficcontrol/community
>
> I actually think PR templates would be quite helpful. As a
> committer/merger, it would be nice to know what problem the PR is solving
> and how to verify the functionality. A PR template could also help
> contributors ensure that their PRs are complete. I.e. does this PR includes
> tests, documentation, etc.
>
> I'll take a stab at a couple of templates and run them by the group.
>
> Jeremy
>
> On Wed, Jan 31, 2018 at 1:10 PM, Chris Lemmons  wrote:
>
>> I'm +1 on Issue Templates, for sure. I don't know that PR templates
>> are quite as critical, but it might be nice to have a reminder in
>> there about verifying that the changelog is updated if necessary and
>> documentation for new features is present. If the PR Template
>> overwrites the default comment that you get from the commit body, it
>> might be more annoying than valuable, though.
>>
>> I'm also +1 on hiding these particular files in a .github directory.
>> Unlike CONTRIBUTING and README, they don't provide all that much
>> benefit for a new person looking for stuff to read.
>>
>> On Wed, Jan 31, 2018 at 12:17 PM, Durfey, Ryan 
>> wrote:
>> > Always +1 on standardization and consistency
>> >
>> > I still want to circle back and setup project/kanbans for organizing
>> tickets in Github.
>> >
>> > Ryan DurfeyM | 303-524-5099
>> > CDN Support (24x7): 866-405-2993 or cdn_supp...@comcast.com> cdn_supp...@comcast.com>
>> >
>> > From: Dewayne Richardson 
>> > Reply-To: "dev@trafficcontrol.incubator.apache.org" <
>> dev@trafficcontrol.incubator.apache.org>
>> > Date: Wednesday, January 31, 2018 at 11:15 AM
>> > To: "dev@trafficcontrol.incubator.apache.org" <
>> dev@trafficcontrol.incubator.apache.org>
>> > Subject: Github PR/Issues Format Templates
>> >
>> > I was working through the go-swagger repo and found a bug.  I submitted
>> a
>> > new issue and found this interesting approach I think the TC github
>> should
>> > adopt, "Issue and PR Templates".  I think the main value here is
>> > consistency in our PRs/Issues and user friendly prompts to say "these
>> are
>> > the data points we need to help you solve your issue".
>> >
>> > Working example:
>> > https://github.com/go-swagger/go-swagger/issues/new
>> >
>> > Github Doc on how to implement templates:
>> > https://github.com/blog/2111-issue-and-pull-request-templates
>> >
>> > If we think it's a good idea, then I'll respond with some examples for
>> > Issues and PR's that we can discuss.
>> >
>> > -Dew
>> >
>>
>
>

Re: Steering Target Geo-Ordering

2018-02-27 Thread Jeremy Mitchell 
Makes perfect sense. thanks for the clarification.

On Tue, Feb 27, 2018 at 11:32 AM, Rawlin Peters 
wrote:

> Hey Jeremy,
>
> With a redundant origin in each location, there would be a total of 6
> HTTP_LIVE DSes. Then you'd create a steering DS with each of those 6
> HTTP_LIVE DSes as targets. The type of each target would either be
> GEO_ORDER or GEO_WEIGHT, depending on if we want a forced ordering or
> something like a 50/50 split, respectively.
>
> Say I have the following targets in my Steering DS:
>
> Seattle1 (S1):
> GEO_ORDER: 1
>
> Seattle2 (S2):
> GEO_ORDER: 2
>
> Denver1 (D1):
> GEO_WEIGHT: 50
>
> Denver2 (D2):
> GEO_WEIGHT: 50
>
> Boston1 (B1):
> GEO_ORDER: 1
>
> Boston2 (B2):
> GEO_ORDER: 2
>
> For a client in Seattle requesting /foo, they would get the list [S1,
> S2, D2, D1, B1, B2], where D1 and D2 are consistent hashed based upon
> the requested URL and given weight. So if they request /bar maybe D1
> and D2 are switched so they get [S1, S2, D1, D2, B1, B2].
>
> - Rawlin
>
> On Mon, Feb 26, 2018 at 8:18 PM, Jeremy Mitchell 
> wrote:
> > So, back to the Seattle, Denver, Boston example...
> >
> > To accomplish the geo ordering and redundant origin use case, you'd
> create
> > 3 HTTP_LIVE delivery services? One with an origin in seattle. One with an
> > origin in denver. One with an origin in boston. (or would you create 6
> ds's
> > so you have 2 in each location?)
> >
> > Then you'd create a steering delivery service with 3 targets (the
> HTTP_LIVE
> > ds's you just created.) Each target would have type = GEO_ORDER and
> value =
> > ?
> >
> > I'm getting confused with that above scenario. How many targets would you
> > have? What would the type of each target be and what would the value of
> > each target be?
> >
> > Jeremy
> >
> >
> > On Fri, Feb 23, 2018 at 3:40 PM, Rawlin Peters 
> > wrote:
> >
> >> Hey folks,
> >>
> >> At Comcast we have a need to augment CLIENT_STEERING (also regular
> >> STEERING while we're at it) to allow targets to be ordered/sorted
> >> based upon the client's proximity to the origin of the target delivery
> >> services. I'd like to get your feedback on my proposed design and
> >> address any of your concerns.
> >>
> >> For HTTP_LIVE targets for instance, we'd like edge caches to ideally
> >> retrieve/serve data from an Origin that is close to the client and
> >> fall back to Origins that are farther and farther away. This allows
> >> for increased redundancy while ordering optimal Origins (Delivery
> >> Services) for a client to choose from.
> >>
> >> For example, I have 3 Origins in different locations: Seattle, Denver,
> >> and Boston. I would create an HTTP_LIVE delivery service for each
> >> origin and a CLIENT_STEERING delivery service with those delivery
> >> services as targets. I would then like to have those targets ordered
> >> based upon proximity to the client. So a client in Seattle would get
> >> the list [Seattle, Denver, Boston], while a client in Boston would get
> >> the list [Boston, Denver, Seattle].
> >>
> >> To make things more complicated, I want to add a redundant origin in
> >> each location and split traffic between them (like STEERING_WEIGHT
> >> today) while taking into account the geo-ordering. I also want to be
> >> able to force an ordering (like STEERING_ORDER today) among co-located
> >> targets.
> >>
> >> In order to accomplish this I propose to:
> >> 1. add two new steering types: GEO_ORDER and GEO_WEIGHT (by adding a
> >> target of type GEO_*, a steering DS would then enable geo-ordering)
> >> 2. associate a Delivery Service Origin with a latitude/longitude,
> >> thereby associating a lat/long to a GEO_* target
> >>
> >> Item 1 is pretty straightforward and will also play nicely with the
> >> current steering types (STEERING_ORDER and STEERING_WEIGHT). I've
> >> completed a POC within Traffic Router that basically provides the
> >> following ordering when mixing all 4 types in a single steering
> >> delivery service:
> >> - Negative STEERING_ORDER targets
> >> - GEO_WEIGHT and GEO_ORDER targets, grouped by proximity to the
> >> client, ordered by geo-order and the consistent-hashing from the
> >> weightings
> >> - STEERING_WEIGHT targets (consistent-hashed)
> >> - Positive STEERING_ORDER targets
> >>
> >> Item 2 is not as straightforward because the simple thing would be to
> >> just add an Origin Lat/Long field to the Delivery Service and call it
> >> a day. However I don't think we should do that, and I'll dive more
> >> into that in a separate thread (coming soon).
> >>
> >> Does anyone have questions/concerns about adding these new GEO_ORDER
> >> and GEO_STEERING target types and geo-sorting them based upon
> >> proximity to the client? Are you okay with the proposed ordering when
> >> all the steering types are mixed together?
> >>
> >> - Rawlin
> >>
>

Re: Steering Target Geo-Ordering

2018-02-27 Thread Rawlin Peters 
Hey Jeremy,

With a redundant origin in each location, there would be a total of 6
HTTP_LIVE DSes. Then you'd create a steering DS with each of those 6
HTTP_LIVE DSes as targets. The type of each target would either be
GEO_ORDER or GEO_WEIGHT, depending on if we want a forced ordering or
something like a 50/50 split, respectively.

Say I have the following targets in my Steering DS:

Seattle1 (S1):
GEO_ORDER: 1

Seattle2 (S2):
GEO_ORDER: 2

Denver1 (D1):
GEO_WEIGHT: 50

Denver2 (D2):
GEO_WEIGHT: 50

Boston1 (B1):
GEO_ORDER: 1

Boston2 (B2):
GEO_ORDER: 2

For a client in Seattle requesting /foo, they would get the list [S1,
S2, D2, D1, B1, B2], where D1 and D2 are consistent hashed based upon
the requested URL and given weight. So if they request /bar maybe D1
and D2 are switched so they get [S1, S2, D1, D2, B1, B2].

- Rawlin

On Mon, Feb 26, 2018 at 8:18 PM, Jeremy Mitchell  wrote:
> So, back to the Seattle, Denver, Boston example...
>
> To accomplish the geo ordering and redundant origin use case, you'd create
> 3 HTTP_LIVE delivery services? One with an origin in seattle. One with an
> origin in denver. One with an origin in boston. (or would you create 6 ds's
> so you have 2 in each location?)
>
> Then you'd create a steering delivery service with 3 targets (the HTTP_LIVE
> ds's you just created.) Each target would have type = GEO_ORDER and value =
> ?
>
> I'm getting confused with that above scenario. How many targets would you
> have? What would the type of each target be and what would the value of
> each target be?
>
> Jeremy
>
>
> On Fri, Feb 23, 2018 at 3:40 PM, Rawlin Peters 
> wrote:
>
>> Hey folks,
>>
>> At Comcast we have a need to augment CLIENT_STEERING (also regular
>> STEERING while we're at it) to allow targets to be ordered/sorted
>> based upon the client's proximity to the origin of the target delivery
>> services. I'd like to get your feedback on my proposed design and
>> address any of your concerns.
>>
>> For HTTP_LIVE targets for instance, we'd like edge caches to ideally
>> retrieve/serve data from an Origin that is close to the client and
>> fall back to Origins that are farther and farther away. This allows
>> for increased redundancy while ordering optimal Origins (Delivery
>> Services) for a client to choose from.
>>
>> For example, I have 3 Origins in different locations: Seattle, Denver,
>> and Boston. I would create an HTTP_LIVE delivery service for each
>> origin and a CLIENT_STEERING delivery service with those delivery
>> services as targets. I would then like to have those targets ordered
>> based upon proximity to the client. So a client in Seattle would get
>> the list [Seattle, Denver, Boston], while a client in Boston would get
>> the list [Boston, Denver, Seattle].
>>
>> To make things more complicated, I want to add a redundant origin in
>> each location and split traffic between them (like STEERING_WEIGHT
>> today) while taking into account the geo-ordering. I also want to be
>> able to force an ordering (like STEERING_ORDER today) among co-located
>> targets.
>>
>> In order to accomplish this I propose to:
>> 1. add two new steering types: GEO_ORDER and GEO_WEIGHT (by adding a
>> target of type GEO_*, a steering DS would then enable geo-ordering)
>> 2. associate a Delivery Service Origin with a latitude/longitude,
>> thereby associating a lat/long to a GEO_* target
>>
>> Item 1 is pretty straightforward and will also play nicely with the
>> current steering types (STEERING_ORDER and STEERING_WEIGHT). I've
>> completed a POC within Traffic Router that basically provides the
>> following ordering when mixing all 4 types in a single steering
>> delivery service:
>> - Negative STEERING_ORDER targets
>> - GEO_WEIGHT and GEO_ORDER targets, grouped by proximity to the
>> client, ordered by geo-order and the consistent-hashing from the
>> weightings
>> - STEERING_WEIGHT targets (consistent-hashed)
>> - Positive STEERING_ORDER targets
>>
>> Item 2 is not as straightforward because the simple thing would be to
>> just add an Origin Lat/Long field to the Delivery Service and call it
>> a day. However I don't think we should do that, and I'll dive more
>> into that in a separate thread (coming soon).
>>
>> Does anyone have questions/concerns about adding these new GEO_ORDER
>> and GEO_STEERING target types and geo-sorting them based upon
>> proximity to the client? Are you okay with the proposed ordering when
>> all the steering types are mixed together?
>>
>> - Rawlin
>>

Re: Github PR/Issues Format Templates

2018-02-27 Thread Jeremy Mitchell 
With an issue and/or pr template, we will have 6/6 items checked:

https://github.com/apache/incubator-trafficcontrol/community

I actually think PR templates would be quite helpful. As a
committer/merger, it would be nice to know what problem the PR is solving
and how to verify the functionality. A PR template could also help
contributors ensure that their PRs are complete. I.e. does this PR includes
tests, documentation, etc.

I'll take a stab at a couple of templates and run them by the group.

Jeremy

On Wed, Jan 31, 2018 at 1:10 PM, Chris Lemmons  wrote:

> I'm +1 on Issue Templates, for sure. I don't know that PR templates
> are quite as critical, but it might be nice to have a reminder in
> there about verifying that the changelog is updated if necessary and
> documentation for new features is present. If the PR Template
> overwrites the default comment that you get from the commit body, it
> might be more annoying than valuable, though.
>
> I'm also +1 on hiding these particular files in a .github directory.
> Unlike CONTRIBUTING and README, they don't provide all that much
> benefit for a new person looking for stuff to read.
>
> On Wed, Jan 31, 2018 at 12:17 PM, Durfey, Ryan 
> wrote:
> > Always +1 on standardization and consistency
> >
> > I still want to circle back and setup project/kanbans for organizing
> tickets in Github.
> >
> > Ryan DurfeyM | 303-524-5099
> > CDN Support (24x7): 866-405-2993 or cdn_supp...@comcast.com cdn_supp...@comcast.com>
> >
> > From: Dewayne Richardson 
> > Reply-To: "dev@trafficcontrol.incubator.apache.org" <
> dev@trafficcontrol.incubator.apache.org>
> > Date: Wednesday, January 31, 2018 at 11:15 AM
> > To: "dev@trafficcontrol.incubator.apache.org" <
> dev@trafficcontrol.incubator.apache.org>
> > Subject: Github PR/Issues Format Templates
> >
> > I was working through the go-swagger repo and found a bug.  I submitted a
> > new issue and found this interesting approach I think the TC github
> should
> > adopt, "Issue and PR Templates".  I think the main value here is
> > consistency in our PRs/Issues and user friendly prompts to say "these are
> > the data points we need to help you solve your issue".
> >
> > Working example:
> > https://github.com/go-swagger/go-swagger/issues/new
> >
> > Github Doc on how to implement templates:
> > https://github.com/blog/2111-issue-and-pull-request-templates
> >
> > If we think it's a good idea, then I'll respond with some examples for
> > Issues and PR's that we can discuss.
> >
> > -Dew
> >
>

Re: Steering Target Geo-Ordering

2018-02-27 Thread Eric Friedrich (efriedri) 
In this example, what would be the assignments of delivery services to edge 
Cache Groups? Are all 3DS’ assigned to all 3 Cache Groups?

I’ll also assume that the content on the origins, while interchangeable from a 
clients perspective, is not identical? (i.e. might contain regionalized 
content?)

—Eric




> On Feb 23, 2018, at 5:40 PM, Rawlin Peters  wrote:
> 
> Hey folks,
> 
> At Comcast we have a need to augment CLIENT_STEERING (also regular
> STEERING while we're at it) to allow targets to be ordered/sorted
> based upon the client's proximity to the origin of the target delivery
> services. I'd like to get your feedback on my proposed design and
> address any of your concerns.
> 
> For HTTP_LIVE targets for instance, we'd like edge caches to ideally
> retrieve/serve data from an Origin that is close to the client and
> fall back to Origins that are farther and farther away. This allows
> for increased redundancy while ordering optimal Origins (Delivery
> Services) for a client to choose from.
> 
> For example, I have 3 Origins in different locations: Seattle, Denver,
> and Boston. I would create an HTTP_LIVE delivery service for each
> origin and a CLIENT_STEERING delivery service with those delivery
> services as targets. I would then like to have those targets ordered
> based upon proximity to the client. So a client in Seattle would get
> the list [Seattle, Denver, Boston], while a client in Boston would get
> the list [Boston, Denver, Seattle].
> 
> To make things more complicated, I want to add a redundant origin in
> each location and split traffic between them (like STEERING_WEIGHT
> today) while taking into account the geo-ordering. I also want to be
> able to force an ordering (like STEERING_ORDER today) among co-located
> targets.
> 
> In order to accomplish this I propose to:
> 1. add two new steering types: GEO_ORDER and GEO_WEIGHT (by adding a
> target of type GEO_*, a steering DS would then enable geo-ordering)
> 2. associate a Delivery Service Origin with a latitude/longitude,
> thereby associating a lat/long to a GEO_* target
> 
> Item 1 is pretty straightforward and will also play nicely with the
> current steering types (STEERING_ORDER and STEERING_WEIGHT). I've
> completed a POC within Traffic Router that basically provides the
> following ordering when mixing all 4 types in a single steering
> delivery service:
> - Negative STEERING_ORDER targets
> - GEO_WEIGHT and GEO_ORDER targets, grouped by proximity to the
> client, ordered by geo-order and the consistent-hashing from the
> weightings
> - STEERING_WEIGHT targets (consistent-hashed)
> - Positive STEERING_ORDER targets
> 
> Item 2 is not as straightforward because the simple thing would be to
> just add an Origin Lat/Long field to the Delivery Service and call it
> a day. However I don't think we should do that, and I'll dive more
> into that in a separate thread (coming soon).
> 
> Does anyone have questions/concerns about adding these new GEO_ORDER
> and GEO_STEERING target types and geo-sorting them based upon
> proximity to the client? Are you okay with the proposed ordering when
> all the steering types are mixed together?
> 
> - Rawlin

Re: Google Summer of Code 2018 Mentor Registration

2018-02-27 Thread Mark Torluemke 
+1 on the API migration suggestion.

On Mon, Feb 26, 2018 at 10:50 AM, Dave Neuman  wrote:

> I think any of the perl -> go API stuff would be great.
>
> On Mon, Feb 26, 2018 at 10:19 AM, Eric Friedrich (efriedri) <
> efrie...@cisco.com> wrote:
>
> > I agree, this would be a great way to grow the community.
> >
> > Do we have a list of marked issues in Github that would be good
> candidates?
> >
> > Or perhaps we can brainstorm some issues here on the mailer?
> >
> > —Eric
> >
> > > On Feb 24, 2018, at 5:18 PM, Phil Sorber  wrote:
> > >
> > > I think we should do this.
> > >
> > > -- Forwarded message -
> > > From: Ulrich Stärk 
> > > Date: Sat, Feb 24, 2018 at 2:19 PM
> > > Subject: Google Summer of Code 2018 Mentor Registration
> > > To: 
> > > Cc: d...@community.apache.org 
> > >
> > >
> > > Dear PMCs,
> > >
> > > I'm happy to announce that the ASF has made it onto the list of
> accepted
> > > organizations for
> > > Google Summer of Code 2018! [1,2]
> > >
> > > It is now time for mentors to sign up, so please pass this email on to
> > your
> > > community and
> > > podlings. If you aren’t already subscribed to
> > ment...@community.apache.org
> > > you should do so now else
> > > you might miss important information.
> > >
> > > Mentor signup requires two steps: mentor signup in Google's system [3]
> > and
> > > PMC acknowledgement.
> > >
> > > If you want to mentor a project in this year's SoC you will have to
> > >
> > > 1. Be an Apache committer.
> > > 2. Request an acknowledgement from the PMC for which you want to mentor
> > > projects. Use the below
> > > template and *do not forget to copy ment...@community.apache.org*. We
> > will
> > > use the email adress you
> > > indicate to send the invite to be a mentor for Apache.
> > >
> > > PMCs, read carefully please.
> > >
> > > We request that each mentor is acknowledged by a PMC member. This is to
> > > ensure the mentor is in good
> > > standing with the community. When you receive a request for
> > > acknowledgement, please ACK it and cc
> > > ment...@community.apache.org
> > >
> > > Lastly, it is not yet too late to record your ideas in Jira (see my
> > > previous emails for details).
> > > Students will now begin to explore ideas so if you haven’t already done
> > so,
> > > record your ideas
> > > immediately!
> > >
> > > Cheers,
> > >
> > > Uli
> > >
> > > mentor request email template:
> > > 
> > > to: private@.apache.org
> > > cc: ment...@community.apache.org
> > > subject: GSoC 2018 mentor request for 
> > >
> > >  PMC,
> > >
> > > please acknowledge my request to become a mentor for Google Summer of
> > Code
> > > 2018 projects for Apache
> > > .
> > >
> > > I would like to receive the mentor invite to 
> > >
> > > 
> > >
> > > 
> > >
> > > [1] https://summerofcode.withgoogle.com/organizations/
> > > [2] https://summerofcode.withgoogle.com/organizations/
> 5718432427802624/
> > > [3] https://summerofcode.withgoogle.com/
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> > > For additional commands, e-mail: dev-h...@community.apache.org
> >
> >
>