date:20170922

PDF: 
http://www.openstack.org/blog/wp-content/uploads/2017/09/devdigest-20170922.pdf
HTML: 
https://www.openstack.org/blog/2017/09/openstack-developer-mailing-list-digest-20170922/

# OpenStack Developer Mailing List Digest September 16-22

## Summaries
* [Technical Committee Status 
update](http://lists.openstack.org/pipermail/openstack-dev/2017-September/122487.html)
* [POST 
/api-sig/news](http://lists.openstack.org/pipermail/openstack-dev/2017-September/122451.html)
* [Release 
Countdown](http://lists.openstack.org/pipermail/openstack-dev/2017-September/122527.html)

## PTG

### Survey/polls
* Should we have Upstream Institutes at the PTG? [yay or 
nay](http://lists.openstack.org/pipermail/openstack-dev/2017-September/122262.html)

### Summaries
* 
[Blazar](http://lists.openstack.org/pipermail/openstack-dev/2017-September/122414.html)
* Cross-project
* [Simplification in OpenStack 
etherpad](https://etherpad.openstack.org/p/simplifying-os)
* [Skip Level Upgrades & Fast Forward 
Upgrades](http://lists.openstack.org/pipermail/openstack-dev/2017-September/122347.html)
 and 
[thread](http://lists.openstack.org/pipermail/openstack-dev/2017-September/thread.html#122347)
* 
[Charms](http://lists.openstack.org/pipermail/openstack-dev/2017-September/122335.html)
* Cinder
* [Team 
photo](http://lists.openstack.org/pipermail/openstack-dev/2017-September/122294.html)
* 
[Cyborg](http://lists.openstack.org/pipermail/openstack-dev/2017-September/122175.html)
* [Docs and 
i18n](http://lists.openstack.org/pipermail/openstack-dev/2017-September/122404.html)
*  Glance
* Recaps:
* 
[Wednesday](http://lists.openstack.org/pipermail/openstack-dev/2017-September/122156.html)
* 
[Thursday](http://lists.openstack.org/pipermail/openstack-dev/2017-September/122195.html)
* Neutron
* 
[Videos](http://lists.openstack.org/pipermail/openstack-dev/2017-September/122131.html)
* [Team 
photo](http://lists.openstack.org/pipermail/openstack-dev/2017-September/122412.html)
* Nova
* Recaps:
* 
[Cells](http://lists.openstack.org/pipermail/openstack-dev/2017-September/122209.html)
* 
[Placement](http://lists.openstack.org/pipermail/openstack-dev/2017-September/122233.html)
* [Nova and 
Neutron](http://lists.openstack.org/pipermail/openstack-dev/2017-September/122244.html)
* [Nova and 
Cinder](http://lists.openstack.org/pipermail/openstack-dev/2017-September/122238.html)
* [Everything 
else](http://lists.openstack.org/pipermail/openstack-dev/2017-September/122258.html)
* [Team 
photo](http://lists.openstack.org/pipermail/openstack-dev/2017-September/122235.html)
* 
[Sahara](http://lists.openstack.org/pipermail/openstack-dev/2017-September/122353.html)
* 
[Tricircle](http://lists.openstack.org/pipermail/openstack-dev/2017-September/122263.html)
* Triple-O
* [Triple-O and 
Ansible](http://lists.openstack.org/pipermail/openstack-dev/2017-September/122234.html)
 and 
[thread](http://lists.openstack.org/pipermail/openstack-dev/2017-September/thread.html#122234)
* [Team 
photo](http://lists.openstack.org/pipermail/openstack-dev/2017-September/122202.html)
* 
[QA](http://lists.openstack.org/pipermail/openstack-dev/2017-September/122295.html)


### Gerrit Upgrade Update From Infra
* Gerrit emails are slow, because it’s sending one at a time
* [Upstream bug](https://bugs.chromium.org/p/gerrit/issues/detail?id=7261)
* [Patch to apply](https://review.openstack.org/#/c/505677)
* Web UI File Editor
* Behaving oddly. Might be because of API time outs. Gertty is also having 
reported problems.
* 
[Message](http://lists.openstack.org/pipermail/openstack-dev/2017-September/122410.html)


### Install Guide VS Tutorial
* Since the 
[doc-migration](http://specs.openstack.org/openstack/docs-specs/specs/pike/os-manuals-migration.html),
 people have been having questions regarding the usage of “Install Tutorial” 
and “Install Guide” in the OpenStack manuals repository and project specific 
repos.
* The documentation team agrees this should be consistent.
* Tutorial’s literal translation is “paper, book, film, or computer program 
that provide practical information about a specific subject.”
* From PTG discussions, a distinction made was installation provides one of 
many possible ways to install the components.
* Consistency is more important than bike shedding over the name.
* Industry wise, what’s the trend?
* 
[Thread](http://lists.openstack.org/pipermail/openstack-dev/2017-September/thread.html#122272)


### Garbage Patches for simple typo fixes
* [Previous thread from 2016 on 
this](http://lists.openstack.org/pipermail/openstack-dev/2016-September/104173.html)
* Various contributors are doing many patches that are typo, style changes.
* It has been expressed that this can cause CI resource starvation.
* TC created the [Top 5 help 
wanted](https://governance.openstack.org/tc/reference/top-5-help-wanted.html) 
to help contributors

Re: [openstack-dev] Garbage patches for simple typo fixes

2017-09-22 Thread Zhipeng Huang

Hi Doug,

Absolutely glad to help on this matter. We could take this offline first
via email or irc chat and then comes up with a solution for the broader
community to review

On Sat, Sep 23, 2017 at 2:47 AM, Doug Hellmann 
wrote:

> Excerpts from Davanum Srinivas (dims)'s message of 2017-09-22 13:47:06
> -0400:
> > Doug,
> > Howard (cc'ed) already did a bunch of reaching out especially on
> > wechat. We should request his help.
> >
> > Howard,
> > Can you please help with communications and follow up?
> >
> > Thanks,
> > Dims
>
> Thanks, Dims and Howard,
>
> I think the problem has reached a point where it would be a good
> idea to formalize our approach to outreach. We should track the
> patches or patch series identified as problematic, so reviewers
> know not to bother with them. We can also track who is contacting
> whom (and how) so we don't have a bunch of people replicating work
> or causing confusion for people who are trying to contribute. Having
> that information will also help us figure out when we need to
> escalate by finding the right managers to be talking to.
>
> Let's put together a small team to manage this instead of letting
> it continue to cause frustration for everyone.
>
> Doug
>
> >
> > On Fri, Sep 22, 2017 at 1:43 PM, Doug Hellmann 
> wrote:
> > > Excerpts from Matt Riedemann's message of 2017-09-22 08:26:31 -0500:
> > >> On 9/22/2017 7:10 AM, Tom Barron wrote:
> > >> > FWIW I think it is better not to attribute motivation in these
> cases.
> > >> > Perhaps the code submitter is trying to pad stats, but perhaps they
> are
> > >> > just a new contributor trying to learn the process with a "harmless"
> > >> > patch, or just a compulsive clean-upper who hasn't thought through
> the
> > >> > costs in reviewer time and CI resources.
> > >>
> > >> I agree. However, the one that set me off last night was a person from
> > >> one company who I've repeatedly -1ed the same types of patches in nova
> > >> for weeks, including on stable branches, and within 10 minutes of each
> > >> other across several repos, so it's clearly part of some daily
> routine.
> > >> That's what prompted me to send something to the mailing list.
> > >>
> > >
> > > As fungi points out, education and communication are likely to be
> > > our best solution. Maybe one approach is to identify the companies
> > > and individuals involved and find one of our community members to
> > > contact them directly via email.  We would want the person doing
> > > that to be willing to explain all of the reasons the community does
> > > not want the sort of activity we are rejecting and to provide
> > > guidance about more useful contributions (Matt's comment is a great
> > > start on both). I imagine that conversation would take a good deal
> > > of patience, especially after the second or third time, but a personal
> > > touch frequently makes all the difference in these sorts of cases.
> > >
> > > If we have someone willing to step into that sort of role, I would
> > > be happy to help craft the initial contact messages and advise as
> > > needed.
> > >
> > > Does anyone want to volunteer to work with me and actually send the
> > > emails?
> > >
> > > Doug
> > >
> > > 
> __
> > > OpenStack Development Mailing List (not for usage questions)
> > > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>



-- 
Zhipeng (Howard) Huang

Standard Engineer
IT Standard & Patent/IT Product Line
Huawei Technologies Co,. Ltd
Email: huangzhip...@huawei.com
Office: Huawei Industrial Base, Longgang, Shenzhen

(Previous)
Research Assistant
Mobile Ad-Hoc Network Lab, Calit2
University of California, Irvine
Email: zhipe...@uci.edu
Office: Calit2 Building Room 2402

OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Garbage patches for simple typo fixes

On 08:50 Sep 22, Doug Hellmann wrote:
> Excerpts from Tom Barron's message of 2017-09-22 08:10:35 -0400:
> > 
> > On 09/21/2017 10:21 PM, Matt Riedemann wrote:
> > > I just wanted to highlight to people that there seems to be a series of
> > > garbage patches in various projects [1] which are basically doing things
> > > like fixing a single typo in a code comment, or very narrowly changing
> > > http to https in links within docs.
> > > 
> > > Also +1ing ones own changes.
> > > 
> > > I've been trying to snuff these out in nova, but I see it's basically a
> > > pattern widespread across several projects.
> > > 
> > > This is the boilerplate comment I give with my -1, feel free to employ
> > > it yourself.
> > > 
> > > "Sorry but this isn't really a useful change. Fixing typos in code
> > > comments when the context is still clear doesn't really help us, and
> > > mostly seems like looking for padding stats on stackalytics. It's also a
> > > drain on our CI environment.
> > > 
> > > If you fixed all of the typos in a single module, or in user-facing
> > > documentation, or error messages, or something in the logs, or something
> > > that actually doesn't make sense in code comments, then maybe, but this
> > > isn't one of those things."
> > > 
> > > I'm not trying to be a jerk here, but this is annoying to the point I
> > > felt the need to say something publicly.
> > > 
> > > [1] https://review.openstack.org/#/q/author:%255E.*inspur.*
> > > 
> > 
> > The boilerplate is helpful but have we considered putting something
> > along these lines in official documentation so that reviewers can just
> > point to it? It should then be clear to all that negative reviews on
> > these grounds are not simply a function of the individual reviewer's
> > judgment or personality.
> 
> That's a good idea. How about adding a "Contribution Guidelines" section
> to https://docs.openstack.org/project-team-guide/open-development.html
> with this and other tips?

We can make sure this is linked somehow with the contributor portal when
applicable.

http://lists.openstack.org/pipermail/openstack-dev/2017-September/122534.html

-- 
Mike Perez


signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Garbage patches for simple typo fixes

On 15:04 Sep 22, Jeremy Stanley wrote:
> On 2017-09-22 14:50:55 + (+), Rajath Agasthya (rajagast) wrote:
> > On 9/21/17, 10:19 PM, "Jeremy Freudberg"  wrote:
> > > 3) Delay spin-up of resource-intensive/long-running CI jobs
> > > until after some initial review has been added or time has
> > > passed. Authorized contributors, not necessarily synonymous with
> > > cores, can override the delay if there's a critical patch which
> > > needs to get through the queue quickly.
> >
> > +1. This is done in Go code review process, where CI is run by an
> > explicit Run-TryBot+1 review only after a core developer
> > ascertains that the patch looks okay and most code review comments
> > are addressed. This means no CI resource usage for every change
> > and every single patchset. We could adopt a similar approach so
> > that CI resources aren’t wasted for useless patches. This doesn’t
> > take a whole lot of work for the reviewers than the current review
> > process.
> > 
> > https://github.com/golang/go/wiki/GerritAccess#trybot-access-may-start-trybots
> 
> I'm wary of potential overengineering like this, particularly
> without at least some analysis showing the percentage of CI
> resources we'll save by asking our already overworked (on most teams
> anyway) core reviewers to also take on the task of authorizing basic
> CI jobs. The more likely outcome I foresee is that, much like
> contributions going unreviewed sometimes for weeks or months, the
> change authors won't even know whether their changes are suitable
> for review for some similar period of delay.
> 
> The CI system is there to serve reviewers and contributors, not the
> other way around. The CI resource shortages we see from time to time
> should not be used as an excuse to go on witch hunts so we can find
> ways to save what probably accounts for <1% of our overall
> utilization. That's classic premature optimization. What's important
> in this situation is the time wasted by reviewers having to respond
> to or find ways to ignore these patches, so let's focus on that
> rather than getting bogged down with attractive non-problems for
> which we can more easily engineer technical solutions.

+1

Can you imagine the number of jobs that would be delayed. At least today with
things not be delayed we can see if a patch ever worked when it was rebased in
the CI comments.

-- 
Mike Perez


signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Nova][Privsep] Heads up: privsep conversion for nova-compute

2017-09-22 Thread Michael Still

Hi,

this email is a courtesy message to make sure you're all aware that at the
PTG we decided to try to convert all of nova-compute to privsep for the
Queens release. This will almost certainly have an impact on out of tree
drivers, although I am hoping the fall out is minimal.

A change like this will require a fair while to stabilize, so the plan is
to land the patches early in the Queens cycle so that we have time to find
problems and fix them. So, please ensure that your driver is being tested
by CI regularly, so that you notice any problems that we inadvertently
cause.

This conversion has already started, with a few patches already landed.
Please let me know, perhaps by replying to this email, if you find issues
caused by the conversion and I will do my best to work through them with
you.

Thanks,
Michael
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [docs][ptls][install] Install guide vs. tutorial

On 11:33 Sep 21, Alexandra Settle wrote:
> > For me, a tutorial is something that teaches. So after I've gone through a
> > tutorial I would expect to have learned how installs work and would
> > just know
> > these things (with an occasional need to reference a few points) going
> > forward.
> >
> > A guide to me is something that I know I will use whenever I need to do
> > something. So for me, having an installation guide is what I would
> > expect
> > from this as every time I need to do a package based install, I am
> > going to pull
> > up the guide to go through it.
> >
>Interesting.
> 
> So Sean has the opposite impression from Eric and I.  Yeah, that does 
> make it seem like reaching a consensus will be difficult.
> 
> At that point I think consistency becomes the most important thing.
> 
> 
> I completely agree consistency is more important, than bike shedding over the
> name :)
> To be honest, it would be easier to change everything to ‘guide’ – seeing as
> all our URLs are ‘install-guide’.
> But that’s the lazy in me speaking.
> 
> Industry wise – there does seem to be more of a trend towards ‘guide’ rather
> than ‘tutorial’. Although, that is at a cursory glance.
> 
> I am happy to investigate further, if this matter is of some contention to
> people?

This is the first time I'm hearing about "Install Tutorial". I'm also lazy, +1
with sticking to install guide.

-- 
Mike Perez


signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Garbage patches for simple typo fixes

On 21:21 Sep 21, Matt Riedemann wrote:
> I just wanted to highlight to people that there seems to be a series of
> garbage patches in various projects [1] which are basically doing things
> like fixing a single typo in a code comment, or very narrowly changing http
> to https in links within docs.
> 
> Also +1ing ones own changes.
> 
> I've been trying to snuff these out in nova, but I see it's basically a
> pattern widespread across several projects.
> 
> This is the boilerplate comment I give with my -1, feel free to employ it
> yourself.
> 
> "Sorry but this isn't really a useful change. Fixing typos in code comments
> when the context is still clear doesn't really help us, and mostly seems
> like looking for padding stats on stackalytics. It's also a drain on our CI
> environment.
> 
> If you fixed all of the typos in a single module, or in user-facing
> documentation, or error messages, or something in the logs, or something
> that actually doesn't make sense in code comments, then maybe, but this
> isn't one of those things."
> 
> I'm not trying to be a jerk here, but this is annoying to the point I felt
> the need to say something publicly.
> 
> [1] https://review.openstack.org/#/q/author:%255E.*inspur.*

I agree with the frustration here. It was mentioned earlier in the thread the
top 5 wanted [1] is a good step in the right direction. I think also the
efforts on the contributor portal [2] are going to be a helpful link to send
people when they make mistakes.

I'm sure some of the people who haven't had this communicated to them yet
aren't aware, so we should all be aware as demonstrated in Matt's boilerplate
comment to be nice when communicating.

[1] - http://governance.openstack.org/tc/reference/top-5-help-wanted.html 
[2] - 
http://lists.openstack.org/pipermail/openstack-dev/2017-September/122534.html

-- 
Mike Perez


signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Garbage patches for simple typo fixes

Excerpts from Ildiko Vancsa's message of 2017-09-22 13:20:31 -0600:
> Hi All,
> 
> Another forum we try to put emphasis on this is the Upstream Institute 
> trainings we have before the Summits and on some smaller events as well.
> 
> We usually try to spend some quality time on review best practices and on 
> metrics as well. The aim is to make people realize that if they need practice 
> with the process the project repositories are not the place for that and also 
> to let them know that we see the patterns and they get negative recognition 
> for it.
> 
> The only issue with that is I’m not sure we always have the right audience, 
> like people might not contribute after all neither they give the knowledge 
> and heads up to their colleagues in the company who do. :( Regardless of this 
> we will continue to highlight these and if you have suggestion on what else 
> we should mention or how to better articulate it we are open to ideas.
> 
> We were also thinking about collecting ideas and suggestions for people who 
> would take on mentoring in projects, like what and how to do. Do you see this 
> activity being part of that too? Could we say something like if we have a few 
> people per project who are willing to coach and mentor people we can have a 
> small set of guidelines for them on how to start the communication for these 
> cases? Or would this rather be handled centrally?
> 
> As for those who are practicing we have sandbox repositories/projects in all 
> the tools which might worth highlighting.
> 
> The new Contributor Portal can also be a good place to highlight 
> corresponding best practices and point out behaviors we disagree with.

It makes sense to repeat this information in a few places, with
references to an extensive explanation in the project team guide.
I don't think that would have helped in the current cases, but it
won't hurt in the future.

Doug

> 
> Thanks,
> Ildikó
> IRC: ildikov
> 
> > On 2017. Sep 22., at 12:47, Doug Hellmann  wrote:
> > 
> > Excerpts from Davanum Srinivas (dims)'s message of 2017-09-22 13:47:06 
> > -0400:
> >> Doug,
> >> Howard (cc'ed) already did a bunch of reaching out especially on
> >> wechat. We should request his help.
> >> 
> >> Howard,
> >> Can you please help with communications and follow up?
> >> 
> >> Thanks,
> >> Dims
> > 
> > Thanks, Dims and Howard,
> > 
> > I think the problem has reached a point where it would be a good
> > idea to formalize our approach to outreach. We should track the
> > patches or patch series identified as problematic, so reviewers
> > know not to bother with them. We can also track who is contacting
> > whom (and how) so we don't have a bunch of people replicating work
> > or causing confusion for people who are trying to contribute. Having
> > that information will also help us figure out when we need to
> > escalate by finding the right managers to be talking to.
> > 
> > Let's put together a small team to manage this instead of letting
> > it continue to cause frustration for everyone.
> > 
> > Doug
> > 
> >> 
> >> On Fri, Sep 22, 2017 at 1:43 PM, Doug Hellmann  
> >> wrote:
> >>> Excerpts from Matt Riedemann's message of 2017-09-22 08:26:31 -0500:
>  On 9/22/2017 7:10 AM, Tom Barron wrote:
> > FWIW I think it is better not to attribute motivation in these cases.
> > Perhaps the code submitter is trying to pad stats, but perhaps they are
> > just a new contributor trying to learn the process with a "harmless"
> > patch, or just a compulsive clean-upper who hasn't thought through the
> > costs in reviewer time and CI resources.
>  
>  I agree. However, the one that set me off last night was a person from
>  one company who I've repeatedly -1ed the same types of patches in nova
>  for weeks, including on stable branches, and within 10 minutes of each
>  other across several repos, so it's clearly part of some daily routine.
>  That's what prompted me to send something to the mailing list.
>  
> >>> 
> >>> As fungi points out, education and communication are likely to be
> >>> our best solution. Maybe one approach is to identify the companies
> >>> and individuals involved and find one of our community members to
> >>> contact them directly via email.  We would want the person doing
> >>> that to be willing to explain all of the reasons the community does
> >>> not want the sort of activity we are rejecting and to provide
> >>> guidance about more useful contributions (Matt's comment is a great
> >>> start on both). I imagine that conversation would take a good deal
> >>> of patience, especially after the second or third time, but a personal
> >>> touch frequently makes all the difference in these sorts of cases.
> >>> 
> >>> If we have someone willing to step into that sort of role, I would
> >>> be happy to help craft the initial contact messages and advise as
> >>> needed.
> >>> 
> >>> Does anyone want to

Re: [openstack-dev] [devstack] Why do we apt-get install NEW files/debs/general at job time ?

2017-09-22 Thread Michał Jastrzębski

On 22 September 2017 at 11:45, Clark Boylan  wrote:
> On Fri, Sep 22, 2017, at 08:58 AM, Michał Jastrzębski wrote:
>> Another, more revolutionary (for good or ill) alternative would be to
>> move gates to run Kolla instead of DevStack. We're working towards
>> registry of images, and we support most of openstack services now. If
>> we enable mixed installation (your service in devstack-ish way, others
>> via Kolla), that should lower the amount of downloads quite
>> dramatically (lots of it will be downloads from registry which will be
>> mirrored/cached in every nodepool). Then all we really need is to
>> support barebone image with docker and ansible installed and that's
>> it.
>
> Except that it very likely isn't going to use less bandwidth. We already
> mirror most of these package repos so all transfers are local to the
> nodepool cloud region. In total we seem to grab about 139MB of packages
> for a neutron dvr multinode scenario job (146676348 bytes) on Ubuntu
> Xenial. This is based off the package list compiled at
> http://paste.openstack.org/raw/621753/ then asking apt-cache for the
> package size for the latest version.
>
> Kolla images on the other hand are in the multigigabyte range
> http://tarballs.openstack.org/kolla/images/.
>
> Clark

Right, all 200+ of them, with proper registry management it's going to
be more streamlined. That will lower amount of effort to handle DIB
images tho. We are going to build them anyway, so there net bandwidth
will actually be lower... Also I don't think it's bandwidth that's
issue here as much as general package management and installation of
packages even from locally available mirror, docker would help with
that.

>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [sahara] PTL duties and Meeting on Sep 29th

2017-09-22 Thread Telles Nobrega

Exactly. Thursday the 28th. Thanks.
On Fri, 22 Sep 2017 at 17:39 Jeremy Freudberg 
wrote:

> Enjoy the time off. You've earned it.
>
> Quick note, the cancelled meeting date will actually be Thursday Sept
> *28* not 29 (which evidently coincides with Czech Statehood Day).
>
> On Fri, Sep 22, 2017 at 3:29 PM, Telles Nobrega 
> wrote:
> > Hi Saharans and interested parties,
> >
> > Next week I will be on PTO, I don't think pointing a temporary PTL is
> > necessary since we have active cores that can handle the work without a
> > problem.
> >
> > Also, since I will on PTO and Thursday is a public holiday in Tchech
> > Republic I'm canceling the meeting.
> >
> > Thanks all and see you in week.
> >
> > --
> >
> > TELLES NOBREGA
> >
> > SOFTWARE ENGINEER
> >
> > Red Hat I
> >
> > tenob...@redhat.com
> >
> > TRIED. TESTED. TRUSTED.
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-- 

TELLES NOBREGA

SOFTWARE ENGINEER

Red Hat I 

tenob...@redhat.com

TRIED. TESTED. TRUSTED. 
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [devstack] pike time growth in August

2017-09-22 Thread Clark Boylan

On Fri, Sep 22, 2017, at 01:18 PM, Attila Fazekas wrote:
> The main offenders reported by devstack does not seams to explain the
> growth visible on OpenstackHealth [1] .
> The logs also stated to disappear which does not makes easy to figure
> out.
> 
> 
> Which code/infra changes can be related ?
> 
> 
> http://status.openstack.org/openstack-health/#/test/devstack?resolutionKey=day=P6M

A big factor is likely the loss of OSIC. That cloud performed really
well and now we don't have it anymore so averages will increase.

Clark

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [sahara] PTL duties and Meeting on Sep 29th

2017-09-22 Thread Jeremy Freudberg

Enjoy the time off. You've earned it.

Quick note, the cancelled meeting date will actually be Thursday Sept
*28* not 29 (which evidently coincides with Czech Statehood Day).

On Fri, Sep 22, 2017 at 3:29 PM, Telles Nobrega  wrote:
> Hi Saharans and interested parties,
>
> Next week I will be on PTO, I don't think pointing a temporary PTL is
> necessary since we have active cores that can handle the work without a
> problem.
>
> Also, since I will on PTO and Thursday is a public holiday in Tchech
> Republic I'm canceling the meeting.
>
> Thanks all and see you in week.
>
> --
>
> TELLES NOBREGA
>
> SOFTWARE ENGINEER
>
> Red Hat I
>
> tenob...@redhat.com
>
> TRIED. TESTED. TRUSTED.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [devstack] pike time growth in August

2017-09-22 Thread Attila Fazekas

The main offenders reported by devstack does not seams to explain the
growth visible on OpenstackHealth [1] .
The logs also stated to disappear which does not makes easy to figure out.


Which code/infra changes can be related ?


http://status.openstack.org/openstack-health/#/test/devstack?resolutionKey=day=P6M
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [requirements][stable] EOL tags and upper-constraints.txt in tox.ini

2017-09-22 Thread Matthew Thode

On 17-09-22 15:07:14, Doug Hellmann wrote:
> Excerpts from Tony Breeds's message of 2017-09-21 20:20:22 -0500:
> > On Thu, Sep 21, 2017 at 12:13:23PM -0400, Doug Hellmann wrote:
> > > Excerpts from Tony Breeds's message of 2017-09-21 08:36:39 -0400:
> > > > On Wed, Sep 20, 2017 at 06:08:22PM -0400, Doug Hellmann wrote:
> > > > 
> > > > > I like the idea. I'm not sure why, if the constraints file is only 
> > > > > used
> > > > > for the dependency installation step, we still need tox_install.sh?
> > > > 
> > > > Right now that isn't true, when we get something like my idea
> > > > implemented we'd still need the tox_install.sh in projects that need
> > > > services (not published on pypi) like horizon plugins or neutron stadium
> > > > projects.   Fixing that issue is a totally different discussion, one I
> > > > started at the PTG but I need to let those conversations settle and do
> > > > research on wasy to fix that.
> > > > 
> > > > > If
> > > > > that's just to avoid updating the URL when we create branches, I can
> > > > > live with continuing to do that step if we figure out some other way 
> > > > > to
> > > > > minimize the open race window.
> > > > 
> > > > So lets check we're on the same page with the race window point.  At the
> > > > moment the process looks like:
> > > > 1. projects tag RC1 and when generate a stable/series branch.
> > > > 2. We generate a reviews that updates .gitreview
> > > > 3. We generate a reviews that updates .tox.ini
> > > > 4. time passes
> > > > 5. requirements creates a stable/series branch
> > > > 6. requirements thaws
> > > > 
> > > > Now the race is that if projects merge the patch from step 3 before step
> > > > 5 they're broken (on stable/series) because there isn't a
> > > > 'stable/series' in the requirements repo.  There are some additional 
> > > > issues
> > > > for cycle-trailing projects but nothing radically different.
> > > > 
> > > > Correct?
> > > > 
> > > > Assuming I have that right  In the new world:
> > > > 
> > > > 0. requirements publish master.txt and series.txt
> > > > 1. projects tag RC1 and when generate a stable/series branch.
> > > > 2. We generate a reviews that updates .gitreview
> > > > 3. We generate a reviews that updates .tox.ini
> > > > 4. time passes
> > > > 5. requirements creates a stable/series branch
> > > > 6. requiremenst now publish series.txt, new_series.txt and master.txt
> > > > 6. requirements thaws
> > > 
> > > Where in that sequence do we make the change so that we're not
> > > publishing to series.txt from the new stable branch in requirements and
> > > from master in requirements? Between step 4 and 5? Or is the job smart
> > > enough to not do that?
> > 
> > Right now the job is dumb, but yes we'd teach the job to detect that's
> > it's a stable branch and only publish it's series branch.  We also teach
> > the job to not publish to $series.txt if that stable branch exists.
> > 
> > So I think the publish job looks like:
> > 
> > ---
> > # preamble
> > # typed directly into email so be warned ;P
> > # We probably want to check if ZUUL_BRANCH is the correct variable to
> > # use.
> > case "$ZUUL_BRANCH" in
> > stable/*)
> > series=$(basename "$ZUUL_BRANCH")
> > git show origin/$ZUUL_BRANCH:upper-constraints.txt > 
> > publish/constraints/upper/${series}.txt
> > ;;
> > master)
> > for series in queens master ; do
> > if ! git rev-parse origin/stable/${series} ; then
> > git show origin/master:upper-constraints.txt > 
> > publish/constraints/upper/${series}.txt
> > fi
> > done
> > ;;
> > esac
> > # postample
> > ---
> > 
> > So using the queens release as an example:
> > 
> > Jan 22 - Jan 26R-5 Requirements freeze
> > NOTES: openstack/requirements (master) publishes 
> > {queens,master}.txt
> > Jan 29 - Feb 02R-4  
> > Feb 05 - Feb 09R-3RC1 target week
> > ACTIONS: Projects create stable/queens branches
> > ACTIONS: Generate .gitreview and UPPER_CONSTRAINTS 
> > changes
> > ACTIONS: Projects merge .gitreview and 
> > UPPER_CONSTRAINTS changes
> > Feb 12 - Feb 16R-2
> > ACTIONS: Projects create stable/queens branch for 
> > openstack/requirements
> > ACTIONS: Generate .gitreview and UPPER_CONSTRAINTS 
> > changes
> > ACTIONS: Projects merge .gitreview and 
> > UPPER_CONSTRAINTS changes
> > ACTIONS: Make sure master publishes {rocky,master}.txt
> >  (optionally add the S release at this point, 
> > it doesn't hurt)
> 
> We could add new "future" series names as soon as we know them, since we
> would just be publishing to a file that nothing uses.
> 
> > Feb 19 - Feb 23R-1
> > Feb 26 - Mar 02R+0Queens release
> > Mar 05 - Mar 09R+1  
> > Mar 12 - Mar 16R+2Queens cycle-trailing release deadline
> > 
> > There's a whole other side

[openstack-dev] [sahara] PTL duties and Meeting on Sep 29th

2017-09-22 Thread Telles Nobrega

Hi Saharans and interested parties,

Next week I will be on PTO, I don't think pointing a temporary PTL is
necessary since we have active cores that can handle the work without a
problem.

Also, since I will on PTO and Thursday is a public holiday in Tchech
Republic I'm canceling the meeting.

Thanks all and see you in week.

-- 

TELLES NOBREGA

SOFTWARE ENGINEER

Red Hat I 

tenob...@redhat.com

TRIED. TESTED. TRUSTED. 
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Garbage patches for simple typo fixes

2017-09-22 Thread Ildiko Vancsa

Hi All,

Another forum we try to put emphasis on this is the Upstream Institute 
trainings we have before the Summits and on some smaller events as well.

We usually try to spend some quality time on review best practices and on 
metrics as well. The aim is to make people realize that if they need practice 
with the process the project repositories are not the place for that and also 
to let them know that we see the patterns and they get negative recognition for 
it.

The only issue with that is I’m not sure we always have the right audience, 
like people might not contribute after all neither they give the knowledge and 
heads up to their colleagues in the company who do. :( Regardless of this we 
will continue to highlight these and if you have suggestion on what else we 
should mention or how to better articulate it we are open to ideas.

We were also thinking about collecting ideas and suggestions for people who 
would take on mentoring in projects, like what and how to do. Do you see this 
activity being part of that too? Could we say something like if we have a few 
people per project who are willing to coach and mentor people we can have a 
small set of guidelines for them on how to start the communication for these 
cases? Or would this rather be handled centrally?

As for those who are practicing we have sandbox repositories/projects in all 
the tools which might worth highlighting.

The new Contributor Portal can also be a good place to highlight corresponding 
best practices and point out behaviors we disagree with.

Thanks,
Ildikó
IRC: ildikov

> On 2017. Sep 22., at 12:47, Doug Hellmann  wrote:
> 
> Excerpts from Davanum Srinivas (dims)'s message of 2017-09-22 13:47:06 -0400:
>> Doug,
>> Howard (cc'ed) already did a bunch of reaching out especially on
>> wechat. We should request his help.
>> 
>> Howard,
>> Can you please help with communications and follow up?
>> 
>> Thanks,
>> Dims
> 
> Thanks, Dims and Howard,
> 
> I think the problem has reached a point where it would be a good
> idea to formalize our approach to outreach. We should track the
> patches or patch series identified as problematic, so reviewers
> know not to bother with them. We can also track who is contacting
> whom (and how) so we don't have a bunch of people replicating work
> or causing confusion for people who are trying to contribute. Having
> that information will also help us figure out when we need to
> escalate by finding the right managers to be talking to.
> 
> Let's put together a small team to manage this instead of letting
> it continue to cause frustration for everyone.
> 
> Doug
> 
>> 
>> On Fri, Sep 22, 2017 at 1:43 PM, Doug Hellmann  wrote:
>>> Excerpts from Matt Riedemann's message of 2017-09-22 08:26:31 -0500:
 On 9/22/2017 7:10 AM, Tom Barron wrote:
> FWIW I think it is better not to attribute motivation in these cases.
> Perhaps the code submitter is trying to pad stats, but perhaps they are
> just a new contributor trying to learn the process with a "harmless"
> patch, or just a compulsive clean-upper who hasn't thought through the
> costs in reviewer time and CI resources.

 I agree. However, the one that set me off last night was a person from
 one company who I've repeatedly -1ed the same types of patches in nova
 for weeks, including on stable branches, and within 10 minutes of each
 other across several repos, so it's clearly part of some daily routine.
 That's what prompted me to send something to the mailing list.

>>> 
>>> As fungi points out, education and communication are likely to be
>>> our best solution. Maybe one approach is to identify the companies
>>> and individuals involved and find one of our community members to
>>> contact them directly via email.  We would want the person doing
>>> that to be willing to explain all of the reasons the community does
>>> not want the sort of activity we are rejecting and to provide
>>> guidance about more useful contributions (Matt's comment is a great
>>> start on both). I imagine that conversation would take a good deal
>>> of patience, especially after the second or third time, but a personal
>>> touch frequently makes all the difference in these sorts of cases.
>>> 
>>> If we have someone willing to step into that sort of role, I would
>>> be happy to help craft the initial contact messages and advise as
>>> needed.
>>> 
>>> Does anyone want to volunteer to work with me and actually send the
>>> emails?
>>> 
>>> Doug
>>> 
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 
> 
> __
> OpenStack Development Mailing List (not for usage

Re: [openstack-dev] [requirements][stable] EOL tags and upper-constraints.txt in tox.ini

Excerpts from Tony Breeds's message of 2017-09-21 20:20:22 -0500:
> On Thu, Sep 21, 2017 at 12:13:23PM -0400, Doug Hellmann wrote:
> > Excerpts from Tony Breeds's message of 2017-09-21 08:36:39 -0400:
> > > On Wed, Sep 20, 2017 at 06:08:22PM -0400, Doug Hellmann wrote:
> > > 
> > > > I like the idea. I'm not sure why, if the constraints file is only used
> > > > for the dependency installation step, we still need tox_install.sh?
> > > 
> > > Right now that isn't true, when we get something like my idea
> > > implemented we'd still need the tox_install.sh in projects that need
> > > services (not published on pypi) like horizon plugins or neutron stadium
> > > projects.   Fixing that issue is a totally different discussion, one I
> > > started at the PTG but I need to let those conversations settle and do
> > > research on wasy to fix that.
> > > 
> > > > If
> > > > that's just to avoid updating the URL when we create branches, I can
> > > > live with continuing to do that step if we figure out some other way to
> > > > minimize the open race window.
> > > 
> > > So lets check we're on the same page with the race window point.  At the
> > > moment the process looks like:
> > > 1. projects tag RC1 and when generate a stable/series branch.
> > > 2. We generate a reviews that updates .gitreview
> > > 3. We generate a reviews that updates .tox.ini
> > > 4. time passes
> > > 5. requirements creates a stable/series branch
> > > 6. requirements thaws
> > > 
> > > Now the race is that if projects merge the patch from step 3 before step
> > > 5 they're broken (on stable/series) because there isn't a
> > > 'stable/series' in the requirements repo.  There are some additional 
> > > issues
> > > for cycle-trailing projects but nothing radically different.
> > > 
> > > Correct?
> > > 
> > > Assuming I have that right  In the new world:
> > > 
> > > 0. requirements publish master.txt and series.txt
> > > 1. projects tag RC1 and when generate a stable/series branch.
> > > 2. We generate a reviews that updates .gitreview
> > > 3. We generate a reviews that updates .tox.ini
> > > 4. time passes
> > > 5. requirements creates a stable/series branch
> > > 6. requiremenst now publish series.txt, new_series.txt and master.txt
> > > 6. requirements thaws
> > 
> > Where in that sequence do we make the change so that we're not
> > publishing to series.txt from the new stable branch in requirements and
> > from master in requirements? Between step 4 and 5? Or is the job smart
> > enough to not do that?
> 
> Right now the job is dumb, but yes we'd teach the job to detect that's
> it's a stable branch and only publish it's series branch.  We also teach
> the job to not publish to $series.txt if that stable branch exists.
> 
> So I think the publish job looks like:
> 
> ---
> # preamble
> # typed directly into email so be warned ;P
> # We probably want to check if ZUUL_BRANCH is the correct variable to
> # use.
> case "$ZUUL_BRANCH" in
> stable/*)
> series=$(basename "$ZUUL_BRANCH")
> git show origin/$ZUUL_BRANCH:upper-constraints.txt > 
> publish/constraints/upper/${series}.txt
> ;;
> master)
> for series in queens master ; do
> if ! git rev-parse origin/stable/${series} ; then
> git show origin/master:upper-constraints.txt > 
> publish/constraints/upper/${series}.txt
> fi
> done
> ;;
> esac
> # postample
> ---
> 
> So using the queens release as an example:
> 
> Jan 22 - Jan 26R-5 Requirements freeze
> NOTES: openstack/requirements (master) publishes 
> {queens,master}.txt
> Jan 29 - Feb 02R-4  
> Feb 05 - Feb 09R-3RC1 target week
> ACTIONS: Projects create stable/queens branches
> ACTIONS: Generate .gitreview and UPPER_CONSTRAINTS changes
> ACTIONS: Projects merge .gitreview and UPPER_CONSTRAINTS 
> changes
> Feb 12 - Feb 16R-2
> ACTIONS: Projects create stable/queens branch for 
> openstack/requirements
> ACTIONS: Generate .gitreview and UPPER_CONSTRAINTS changes
> ACTIONS: Projects merge .gitreview and UPPER_CONSTRAINTS 
> changes
> ACTIONS: Make sure master publishes {rocky,master}.txt
>  (optionally add the S release at this point, it 
> doesn't hurt)

We could add new "future" series names as soon as we know them, since we
would just be publishing to a file that nothing uses.

> Feb 19 - Feb 23R-1
> Feb 26 - Mar 02R+0Queens release
> Mar 05 - Mar 09R+1  
> Mar 12 - Mar 16R+2Queens cycle-trailing release deadline
> 
> There's a whole other side issue about how long requirements is frozen
> for.  Ignoring that do you think the above process will remove the race,
> and mean that EOL branches can possibly continue to run tests?
> 
> 
> Yours Tony.

Yes, that does look like a sound approach.

Doug

Re: [openstack-dev] Garbage patches for simple typo fixes

Excerpts from Davanum Srinivas (dims)'s message of 2017-09-22 13:47:06 -0400:
> Doug,
> Howard (cc'ed) already did a bunch of reaching out especially on
> wechat. We should request his help.
> 
> Howard,
> Can you please help with communications and follow up?
> 
> Thanks,
> Dims

Thanks, Dims and Howard,

I think the problem has reached a point where it would be a good
idea to formalize our approach to outreach. We should track the
patches or patch series identified as problematic, so reviewers
know not to bother with them. We can also track who is contacting
whom (and how) so we don't have a bunch of people replicating work
or causing confusion for people who are trying to contribute. Having
that information will also help us figure out when we need to
escalate by finding the right managers to be talking to.

Let's put together a small team to manage this instead of letting
it continue to cause frustration for everyone.

Doug

> 
> On Fri, Sep 22, 2017 at 1:43 PM, Doug Hellmann  wrote:
> > Excerpts from Matt Riedemann's message of 2017-09-22 08:26:31 -0500:
> >> On 9/22/2017 7:10 AM, Tom Barron wrote:
> >> > FWIW I think it is better not to attribute motivation in these cases.
> >> > Perhaps the code submitter is trying to pad stats, but perhaps they are
> >> > just a new contributor trying to learn the process with a "harmless"
> >> > patch, or just a compulsive clean-upper who hasn't thought through the
> >> > costs in reviewer time and CI resources.
> >>
> >> I agree. However, the one that set me off last night was a person from
> >> one company who I've repeatedly -1ed the same types of patches in nova
> >> for weeks, including on stable branches, and within 10 minutes of each
> >> other across several repos, so it's clearly part of some daily routine.
> >> That's what prompted me to send something to the mailing list.
> >>
> >
> > As fungi points out, education and communication are likely to be
> > our best solution. Maybe one approach is to identify the companies
> > and individuals involved and find one of our community members to
> > contact them directly via email.  We would want the person doing
> > that to be willing to explain all of the reasons the community does
> > not want the sort of activity we are rejecting and to provide
> > guidance about more useful contributions (Matt's comment is a great
> > start on both). I imagine that conversation would take a good deal
> > of patience, especially after the second or third time, but a personal
> > touch frequently makes all the difference in these sorts of cases.
> >
> > If we have someone willing to step into that sort of role, I would
> > be happy to help craft the initial contact messages and advise as
> > needed.
> >
> > Does anyone want to volunteer to work with me and actually send the
> > emails?
> >
> > Doug
> >
> > __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [devstack] Why do we apt-get install NEW files/debs/general at job time ?

2017-09-22 Thread Clark Boylan

On Fri, Sep 22, 2017, at 08:58 AM, Michał Jastrzębski wrote:
> Another, more revolutionary (for good or ill) alternative would be to
> move gates to run Kolla instead of DevStack. We're working towards
> registry of images, and we support most of openstack services now. If
> we enable mixed installation (your service in devstack-ish way, others
> via Kolla), that should lower the amount of downloads quite
> dramatically (lots of it will be downloads from registry which will be
> mirrored/cached in every nodepool). Then all we really need is to
> support barebone image with docker and ansible installed and that's
> it.

Except that it very likely isn't going to use less bandwidth. We already
mirror most of these package repos so all transfers are local to the
nodepool cloud region. In total we seem to grab about 139MB of packages
for a neutron dvr multinode scenario job (146676348 bytes) on Ubuntu
Xenial. This is based off the package list compiled at
http://paste.openstack.org/raw/621753/ then asking apt-cache for the
package size for the latest version.

Kolla images on the other hand are in the multigigabyte range
http://tarballs.openstack.org/kolla/images/.

Clark

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Garbage patches for simple typo fixes

2017-09-22 Thread Tom Barron



On 09/22/2017 09:26 AM, Matt Riedemann wrote:
> On 9/22/2017 7:10 AM, Tom Barron wrote:
>> FWIW I think it is better not to attribute motivation in these cases.
>> Perhaps the code submitter is trying to pad stats, but perhaps they are
>> just a new contributor trying to learn the process with a "harmless"
>> patch, or just a compulsive clean-upper who hasn't thought through the
>> costs in reviewer time and CI resources.
> 
> I agree. However, the one that set me off last night was a person from
> one company who I've repeatedly -1ed the same types of patches in nova
> for weeks, including on stable branches, and within 10 minutes of each
> other across several repos, so it's clearly part of some daily routine.
> That's what prompted me to send something to the mailing list.
> 

Yup :)

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Contributor Portal PTG Recap

# Contributor Portal Next Steps

## Landing Page Mock ups
* Current mock up:
https://drive.google.com/file/d/0BxMh9oiou2xMLVRvRWRFVklHa2c/view
* Limited click through mock up:
https://invis.io/CSDEZTBDJ#/252645774_Landing

## Todo
- [ ] thingee: A proposal for the *second level* of what the landing page
shows.
- [ ] thingee: Follow up with the Wes and Jimmy at the OpenStack Foundation
for design assistance.

## Communication To The Community
* [Initial
email](http://lists.openstack.org/pipermail/openstack-dev/2017-June/118877.html)
* [Initial full
thread](http://lists.openstack.org/pipermail/openstack-dev/2017-June/thread.html#118877)

## Highlights from PTG session
[OpenStack Etherpad](https://etherpad.openstack.org/p/contributor-portal)

### TLDR (big changes from discussion)
* Instead of all team on-boarding documentation living in a central
repository, it will still remain with the individual teams to maintain in
their own repository. General documentation (e.g. git, creating accounts,
gerrit setup, etc) will still live in this central repo. If you choose to
contribute by code for example and you pick a project, it will take you
through our general documentation, then the project’s specific documentation.
* This could lead to inconsistencies in documentation design? Confusion
for the reader being sent to different pages?

### General
* We can’t go based off services. Not everything people are contributing
to is a service, so they won't have anything corresponding in the
[service type authority
repo](http://git.openstack.org/cgit/openstack/service-types-authority/tree/service-types.yaml).
There might be a field in projects.yaml that can help with this.
* Remind Thierry on the service type authority repo for
grouping/mapping project.
* Videos were considered, but they’re hard to keep up-to-date.
Previous Documentation PTL Alexandra Settle expressed that even
screenshots can get out of date real fast.
* Generate some kind of crash-course / cheatsheet content for people
who are used to GitHub but not familiar with Gerrit. Aspiers
volunteered for this and made this first pass [ethercalc
sheet](https://ethercalc.openstack.org/github-gerrit).
* Translation team needs to be included
* Provide documentation with how to edit the landing page, since the
source is being hosted on github (there are transition discussions in
place with the infra team and Jimmy)
* Help projects with creating their own contributor guides if they
need to. Think of something like Cookie cutter for setting up the
scaffolding for a new OpenStack project, but getting projects
contributor guides going.

### Upstream Institute
Attendees of the session we’re more in favor of projects keeping
their specific documentation owned in their repositories. As learned
from the centralize documentation problem
[1](http://specs.openstack.org/openstack/docs-specs/specs/pike/os-manuals-migration.html)
[2](https://doughellmann.com/blog/2017/08/24/stop-working-so-hard-scaling-open-source-community-practices/)
[3](https://governance.openstack.org/tc/reference/top-5-help-wanted.html#documentation-owners),
this is a good move. Upstream institute would then use whatever
general documentation is provided. If people get past that, we could
even suggest on-boarding to one of the [top 5 most wanted
help](https://governance.openstack.org/tc/reference/top-5-help-wanted.html)!

### User Committee
Lauren Sell worked with Melvin and others from the user committee to get their
requirements and perspective on the project. Here's an ether pad:
https://etherpad.openstack.org/p/contributor-portal-user-section

### Mock Up Feedback
* Having the service types is great, but on the next level it would
be good to express the code name with a description of what the
project does.
* Combine in events OpenStack day, meetups, forum, ptg, etc.
(emphasize on in person thing)

### Bikeshed
* A word that combines code and documentation ("team(s)" was already
rejected)

--
Mike Perez

signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Garbage patches for simple typo fixes

2017-09-22 Thread Davanum Srinivas

Doug,
Howard (cc'ed) already did a bunch of reaching out especially on
wechat. We should request his help.

Howard,
Can you please help with communications and follow up?

Thanks,
Dims

On Fri, Sep 22, 2017 at 1:43 PM, Doug Hellmann  wrote:
> Excerpts from Matt Riedemann's message of 2017-09-22 08:26:31 -0500:
>> On 9/22/2017 7:10 AM, Tom Barron wrote:
>> > FWIW I think it is better not to attribute motivation in these cases.
>> > Perhaps the code submitter is trying to pad stats, but perhaps they are
>> > just a new contributor trying to learn the process with a "harmless"
>> > patch, or just a compulsive clean-upper who hasn't thought through the
>> > costs in reviewer time and CI resources.
>>
>> I agree. However, the one that set me off last night was a person from
>> one company who I've repeatedly -1ed the same types of patches in nova
>> for weeks, including on stable branches, and within 10 minutes of each
>> other across several repos, so it's clearly part of some daily routine.
>> That's what prompted me to send something to the mailing list.
>>
>
> As fungi points out, education and communication are likely to be
> our best solution. Maybe one approach is to identify the companies
> and individuals involved and find one of our community members to
> contact them directly via email.  We would want the person doing
> that to be willing to explain all of the reasons the community does
> not want the sort of activity we are rejecting and to provide
> guidance about more useful contributions (Matt's comment is a great
> start on both). I imagine that conversation would take a good deal
> of patience, especially after the second or third time, but a personal
> touch frequently makes all the difference in these sorts of cases.
>
> If we have someone willing to step into that sort of role, I would
> be happy to help craft the initial contact messages and advise as
> needed.
>
> Does anyone want to volunteer to work with me and actually send the
> emails?
>
> Doug
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Davanum Srinivas :: https://twitter.com/dims

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Garbage patches for simple typo fixes

Excerpts from Matt Riedemann's message of 2017-09-22 08:26:31 -0500:
> On 9/22/2017 7:10 AM, Tom Barron wrote:
> > FWIW I think it is better not to attribute motivation in these cases.
> > Perhaps the code submitter is trying to pad stats, but perhaps they are
> > just a new contributor trying to learn the process with a "harmless"
> > patch, or just a compulsive clean-upper who hasn't thought through the
> > costs in reviewer time and CI resources.
> 
> I agree. However, the one that set me off last night was a person from 
> one company who I've repeatedly -1ed the same types of patches in nova 
> for weeks, including on stable branches, and within 10 minutes of each 
> other across several repos, so it's clearly part of some daily routine. 
> That's what prompted me to send something to the mailing list.
> 

As fungi points out, education and communication are likely to be
our best solution. Maybe one approach is to identify the companies
and individuals involved and find one of our community members to
contact them directly via email.  We would want the person doing
that to be willing to explain all of the reasons the community does
not want the sort of activity we are rejecting and to provide
guidance about more useful contributions (Matt's comment is a great
start on both). I imagine that conversation would take a good deal
of patience, especially after the second or third time, but a personal
touch frequently makes all the difference in these sorts of cases.

If we have someone willing to step into that sort of role, I would
be happy to help craft the initial contact messages and advise as
needed.

Does anyone want to volunteer to work with me and actually send the
emails?

Doug

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Garbage patches for simple typo fixes

2017-09-22 Thread Jeremy Freudberg

Oops hit send to early.

1) git-review shows some community guidelines
2) auto-review of known lower-quality patches

And those do relieve some reviewer burden.

On Fri, Sep 22, 2017 at 12:43 PM, Jeremy Freudberg
 wrote:
> You're right. The amount of wasted reviewer time is far more
> drastic+problematic then the amount of "wasted" CI resources.
>
> My prior email did contain these suggestions:
>
>
> On Fri, Sep 22, 2017 at 11:04 AM, Jeremy Stanley  wrote:
>> On 2017-09-22 14:50:55 + (+), Rajath Agasthya (rajagast) wrote:
>>> On 9/21/17, 10:19 PM, "Jeremy Freudberg"  wrote:
>>> > 3) Delay spin-up of resource-intensive/long-running CI jobs
>>> > until after some initial review has been added or time has
>>> > passed. Authorized contributors, not necessarily synonymous with
>>> > cores, can override the delay if there's a critical patch which
>>> > needs to get through the queue quickly.
>>>
>>> +1. This is done in Go code review process, where CI is run by an
>>> explicit Run-TryBot+1 review only after a core developer
>>> ascertains that the patch looks okay and most code review comments
>>> are addressed. This means no CI resource usage for every change
>>> and every single patchset. We could adopt a similar approach so
>>> that CI resources aren’t wasted for useless patches. This doesn’t
>>> take a whole lot of work for the reviewers than the current review
>>> process.
>>>
>>> https://github.com/golang/go/wiki/GerritAccess#trybot-access-may-start-trybots
>>
>> I'm wary of potential overengineering like this, particularly
>> without at least some analysis showing the percentage of CI
>> resources we'll save by asking our already overworked (on most teams
>> anyway) core reviewers to also take on the task of authorizing basic
>> CI jobs. The more likely outcome I foresee is that, much like
>> contributions going unreviewed sometimes for weeks or months, the
>> change authors won't even know whether their changes are suitable
>> for review for some similar period of delay.
>>
>> The CI system is there to serve reviewers and contributors, not the
>> other way around. The CI resource shortages we see from time to time
>> should not be used as an excuse to go on witch hunts so we can find
>> ways to save what probably accounts for <1% of our overall
>> utilization. That's classic premature optimization. What's important
>> in this situation is the time wasted by reviewers having to respond
>> to or find ways to ignore these patches, so let's focus on that
>> rather than getting bogged down with attractive non-problems for
>> which we can more easily engineer technical solutions.
>> --
>> Jeremy Stanley
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Garbage patches for simple typo fixes

2017-09-22 Thread Jeremy Freudberg

You're right. The amount of wasted reviewer time is far more
drastic+problematic then the amount of "wasted" CI resources.

My prior email did contain these suggestions:


On Fri, Sep 22, 2017 at 11:04 AM, Jeremy Stanley  wrote:
> On 2017-09-22 14:50:55 + (+), Rajath Agasthya (rajagast) wrote:
>> On 9/21/17, 10:19 PM, "Jeremy Freudberg"  wrote:
>> > 3) Delay spin-up of resource-intensive/long-running CI jobs
>> > until after some initial review has been added or time has
>> > passed. Authorized contributors, not necessarily synonymous with
>> > cores, can override the delay if there's a critical patch which
>> > needs to get through the queue quickly.
>>
>> +1. This is done in Go code review process, where CI is run by an
>> explicit Run-TryBot+1 review only after a core developer
>> ascertains that the patch looks okay and most code review comments
>> are addressed. This means no CI resource usage for every change
>> and every single patchset. We could adopt a similar approach so
>> that CI resources aren’t wasted for useless patches. This doesn’t
>> take a whole lot of work for the reviewers than the current review
>> process.
>>
>> https://github.com/golang/go/wiki/GerritAccess#trybot-access-may-start-trybots
>
> I'm wary of potential overengineering like this, particularly
> without at least some analysis showing the percentage of CI
> resources we'll save by asking our already overworked (on most teams
> anyway) core reviewers to also take on the task of authorizing basic
> CI jobs. The more likely outcome I foresee is that, much like
> contributions going unreviewed sometimes for weeks or months, the
> change authors won't even know whether their changes are suitable
> for review for some similar period of delay.
>
> The CI system is there to serve reviewers and contributors, not the
> other way around. The CI resource shortages we see from time to time
> should not be used as an excuse to go on witch hunts so we can find
> ways to save what probably accounts for <1% of our overall
> utilization. That's classic premature optimization. What's important
> in this situation is the time wasted by reviewers having to respond
> to or find ways to ignore these patches, so let's focus on that
> rather than getting bogged down with attractive non-problems for
> which we can more easily engineer technical solutions.
> --
> Jeremy Stanley
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [devstack] Why do we apt-get install NEW files/debs/general at job time ?

2017-09-22 Thread Michał Jastrzębski

On 22 September 2017 at 07:31, Jeremy Stanley  wrote:
> On 2017-09-22 15:04:43 +0200 (+0200), Attila Fazekas wrote:
>> "if DevStack gets custom images prepped to make its jobs
>> run faster, won't Triple-O, Kolla, et cetera want the same and where
>> do we draw that line?). "
>>
>> IMHO we can try to have only one big image per distribution,
>> where the packages are the union of the packages requested by all team,
>> minus the packages blacklisted by any team.
> [...]
>
> Until you realize that some projects want packages from UCA, from
> RDO, from EPEL, from third-party package repositories. Version
> conflicts mean they'll still spend time uninstalling the versions
> they don't want and downloading/installing the ones they do so we
> have to optimize for one particular set and make the rest
> second-class citizens in that scenario.
>
> Also, preinstalling packages means we _don't_ test that projects
> actually properly declare their system-level dependencies any
> longer. I don't know if anyone's concerned about that currently, but
> it used to be the case that we'd regularly add/break the package
> dependency declarations in DevStack because of running on images
> where the things it expected were preinstalled.
> --
> Jeremy Stanley

Another, more revolutionary (for good or ill) alternative would be to
move gates to run Kolla instead of DevStack. We're working towards
registry of images, and we support most of openstack services now. If
we enable mixed installation (your service in devstack-ish way, others
via Kolla), that should lower the amount of downloads quite
dramatically (lots of it will be downloads from registry which will be
mirrored/cached in every nodepool). Then all we really need is to
support barebone image with docker and ansible installed and that's
it.

> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Senlin] Senlin Queens Meetup

2017-09-22 Thread Qiming Teng

I'd love to join you on Oct 14th, but I'm out of town.

- Qiming
On Tue, Sep 19, 2017 at 10:04:03PM +0800, YUAN RUIJIE wrote:
> Hi all,
> 
> We are going to have a meetup to discuss the features and some other
> details about Senlin in Oct.
> Tentatively schedule：
> Date: 15th Oct.
> Location: Beijing, CHN
> 
> 
> Please leave your comments if you have any suggestion or the have conflict
> with the date.
> 
> Sincerely,
> ruijie

> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [release] Release countdown for week R-22, September 22-29

2017-09-22 Thread Sean McGinnis


Welcome back to our regular release countdown email. Now that the PTG is over,
we will send regular weekly countdown emails.

Development Focus
-

Hopefully the PTG last week gave everyone a jump start on Queens development.
We are only four weeks out from Queens-1. Team focus should be on spec approval
and implementation for priority features.

General Information
---

All PTL's should have received an email from me with an overview of the release
plan for Queens. Please contact me via email or on IRC if you have any questions
about it or missed it.

Teams should review their release liaison information and make sure it is up to
date [1].

[1] https://wiki.openstack.org/wiki/CrossProjectLiaisons

While reviewing liaisons, this would also be a good time to make sure your
declared release model matches the project's plans for Queens (e.g. [2]). This
should be done prior to the first milestone and can be done by proposing a
change to the Queens deliverable file for the project(s) affected [3].

[2] 
https://github.com/openstack/releases/blob/e0a63f7e896abdf4d66fb3ebeaacf4e17f688c38/deliverables/queens/glance.yaml#L5
[3] http://git.openstack.org/cgit/openstack/releases/tree/deliverables/queens

Finally, time to brainstorm and propose topics for the Forum in Sydney. Details
can be found here: [4] The deadline for formal topic submission is September 29.

[4] 
http://lists.openstack.org/pipermail/openstack-dev/2017-September/121783.html

Upcoming Deadlines & Dates
--

Sydney Forum topic formal submission period: September 18-29
Queens-1 milestone: October 19 (R-19 week)
Forum at OpenStack Summit in Sydney: November 6-8
Last Newton Library releases September 25-29 (R-22)
Newton Branch EOL October 11th (R-20 week)

-- 
Sean McGinnis (smcginnis)

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Garbage patches for simple typo fixes

2017-09-22 Thread Lance Bragstad

On Sep 22, 2017 07:59, "Matt Riedemann"  wrote:

On 9/22/2017 9:50 AM, Rajath Agasthya (rajagast) wrote:

> On 9/21/17, 10:19 PM, "Jeremy Freudberg" 
> wrote:
>
> 3) Delay spin-up of resource-intensive/long-running CI jobs until after
> some
>  initial review has been added or time has passed. Authorized
>  contributors, not necessarily synonymous with cores, can override the
>  delay if there's a critical patch which needs to get through the queue
>  quickly.
>  +1. This is done in Go code review process, where CI is run by an
> explicit Run-TryBot+1
> review only after a core developer ascertains that the patch looks okay
> and most code
> review comments are addressed. This means no CI resource usage for every
> change and
> every single patchset. We could adopt a similar approach so that CI
> resources aren’t wasted
> for useless patches. This doesn’t take a whole lot of work for the
> reviewers than the current
> review process.
>
> https://github.com/golang/go/wiki/GerritAccess#trybot-access
> -may-start-trybots
>
> Thanks,
> Rajath
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
Figuring out what is useless or not is probably not worth the effort here.
We already skip long running tempest dsvm jobs in certain patches, like
with docs or unit test only changes. Updating a code comment in code isn't
going to catch that.

And it's perfectly valid to have useful single-line code changes (although
if it's a bug there should be a test too). Or multi-line changes that are
just adding comments to code.

Plus most people are probably not going to review something until CI has
voted on it anyway, at least when you have the number of open reviews that
some projects, like nova, has.


I agree. Reviewers already have a bunch of responsibilities on their plate
and this would be another one. I also imagine it would be tough to get used
to the absence of automatic testing after the default behavior for so long.

I'd personally opt to look for these types of patches instead of losing
automatic testing when patches are pushed.


So I think this is a non-starter.

-- 

Thanks,

Matt


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Garbage patches for simple typo fixes

2017-09-22 Thread Jeremy Stanley

On 2017-09-22 14:50:55 + (+), Rajath Agasthya (rajagast) wrote:
> On 9/21/17, 10:19 PM, "Jeremy Freudberg"  wrote:
> > 3) Delay spin-up of resource-intensive/long-running CI jobs
> > until after some initial review has been added or time has
> > passed. Authorized contributors, not necessarily synonymous with
> > cores, can override the delay if there's a critical patch which
> > needs to get through the queue quickly.
>
> +1. This is done in Go code review process, where CI is run by an
> explicit Run-TryBot+1 review only after a core developer
> ascertains that the patch looks okay and most code review comments
> are addressed. This means no CI resource usage for every change
> and every single patchset. We could adopt a similar approach so
> that CI resources aren’t wasted for useless patches. This doesn’t
> take a whole lot of work for the reviewers than the current review
> process.
> 
> https://github.com/golang/go/wiki/GerritAccess#trybot-access-may-start-trybots

I'm wary of potential overengineering like this, particularly
without at least some analysis showing the percentage of CI
resources we'll save by asking our already overworked (on most teams
anyway) core reviewers to also take on the task of authorizing basic
CI jobs. The more likely outcome I foresee is that, much like
contributions going unreviewed sometimes for weeks or months, the
change authors won't even know whether their changes are suitable
for review for some similar period of delay.

The CI system is there to serve reviewers and contributors, not the
other way around. The CI resource shortages we see from time to time
should not be used as an excuse to go on witch hunts so we can find
ways to save what probably accounts for <1% of our overall
utilization. That's classic premature optimization. What's important
in this situation is the time wasted by reviewers having to respond
to or find ways to ignore these patches, so let's focus on that
rather than getting bogged down with attractive non-problems for
which we can more easily engineer technical solutions.
-- 
Jeremy Stanley


signature.asc
Description: Digital signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Garbage patches for simple typo fixes


On 9/22/2017 9:24 AM, Csatari, Gergely (Nokia - HU/Budapest) wrote:

Isn't it possible to ignore these patches in stackalytics? If the motivation is 
to look better there, this would solve the problem.


That's a technical solution to a social problem. See my reply elsewhere 
in this thread. How you classify what is useful or not is extremely hard.


--

Thanks,

Matt

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Garbage patches for simple typo fixes


On 9/22/2017 9:59 AM, Matt Riedemann wrote:
Figuring out what is useless or not is probably not worth the effort 
here. We already skip long running tempest dsvm jobs in certain patches, 
like with docs or unit test only changes. Updating a code comment in 
code isn't going to catch that.


And it's perfectly valid to have useful single-line code changes 
(although if it's a bug there should be a test too). Or multi-line 
changes that are just adding comments to code.


Plus most people are probably not going to review something until CI has 
voted on it anyway, at least when you have the number of open reviews 
that some projects, like nova, has.


So I think this is a non-starter.


To summarize, this is a social issue, not a technical issue.

--

Thanks,

Matt

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Garbage patches for simple typo fixes

2017-09-22 Thread Csatari, Gergely (Nokia - HU/Budapest)


On 9/22/2017 9:50 AM, Rajath Agasthya (rajagast) wrote:

On 9/21/17, 10:19 PM, "Jeremy Freudberg"  wrote:

3) Delay spin-up of resource-intensive/long-running CI jobs until after some
 initial review has been added or time has passed. Authorized
 contributors, not necessarily synonymous with cores, can override the
 delay if there's a critical patch which needs to get through the queue
 quickly.
 
+1. This is done in Go code review process, where CI is run by an explicit Run-TryBot+1

review only after a core developer ascertains that the patch looks okay and 
most code
review comments are addressed. This means no CI resource usage for every change 
and
every single patchset. We could adopt a similar approach so that CI resources 
aren’t wasted
for useless patches. This doesn’t take a whole lot of work for the reviewers 
than the current
review process.

https://github.com/golang/go/wiki/GerritAccess#trybot-access-may-start-trybots

Thanks,
Rajath
 
   


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



Figuring out what is useless or not is probably not worth the effort 
here. We already skip long running tempest dsvm jobs in certain patches, 
like with docs or unit test only changes. Updating a code comment in 
code isn't going to catch that.


And it's perfectly valid to have useful single-line code changes 
(although if it's a bug there should be a test too). Or multi-line 
changes that are just adding comments to code.


Plus most people are probably not going to review something until CI has 
voted on it anyway, at least when you have the number of open reviews 
that some projects, like nova, has.


So I think this is a non-starter.

--

Thanks,

Matt

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Garbage patches for simple typo fixes

2017-09-22 Thread Rajath Agasthya (rajagast)

On 9/21/17, 10:19 PM, "Jeremy Freudberg"  wrote:

3) Delay spin-up of resource-intensive/long-running CI jobs until after some
initial review has been added or time has passed. Authorized
contributors, not necessarily synonymous with cores, can override the
delay if there's a critical patch which needs to get through the queue
quickly.

+1. This is done in Go code review process, where CI is run by an explicit 
Run-TryBot+1 
review only after a core developer ascertains that the patch looks okay and 
most code 
review comments are addressed. This means no CI resource usage for every change 
and
every single patchset. We could adopt a similar approach so that CI resources 
aren’t wasted
for useless patches. This doesn’t take a whole lot of work for the reviewers 
than the current
review process. 

https://github.com/golang/go/wiki/GerritAccess#trybot-access-may-start-trybots 

Thanks,
Rajath

  

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][api] POST /api-sig/news

2017-09-22 Thread Joe Topjian

On Fri, Sep 22, 2017 at 7:03 AM, Jay Pipes  wrote:

> On 09/21/2017 11:37 PM, Joe Topjian wrote:
>
>>
>> Microversions also reared their head in the form of a long
>> discussion about how SDK developers and users are consuming
>> microversions at a very granular level. This discussion opened many
>> surprised eyes as we learned how different SDK platforms deal with
>> microversions, and what exactly are the best practices. We agreed
>> that it is generally good for an SDK to shield its users from the
>> details of microversions, but to allow power users to access them if
>> they care to.
>>
>>
>> I wanted to add some notes about this.
>>
>> I wasn't able to attend the PTG but I was delighted that somehow this
>> topic came up - and it looks like it was a very in-depth conversation, too.
>> The etherpad notes look to have accurately summarized the difficulty we're
>> having with microversions in Gophercloud.
>>
>> Difficult as the problem is, we're not exactly stuck... yet, anyway. As
>> one of the maintainers of Gophercloud, one thing I wanted to mention is
>> that there shouldn't be a concern of communication problems or anything of
>> the sort (ie: why haven't these Gophercloud guys reached out??). While the
>> discussion of microversions has been going on for almost two months, we
>> only have, at best, a couple of hours a week to research solutions. If
>> either we reach a solution or unfortunately come up short, I plan to post
>> to the api-consumer list with a story of the experience, feedback, and/or a
>> call for help that we're flat out stuck. At the moment, anything more would
>> be commentating the sport of virtual whiteboarding :)
>>
>> On the topic of microversions itself, I'm finding this to be a fun
>> challenge. I like the core goals of microversions, and given that there
>> isn't precedence for this type of thing (unless I'm mistaken) makes it more
>> fun. I do hope that we can implement a solution that enables users of
>> Gophercloud to easily leverage microversions and do some really cool stuff.
>>
>
> Hi Joe!
>
> I'd be interested in helping out. Can you point me to where you're
> tracking issues related to microversion support on GH?
>

Sure: https://github.com/gophercloud/gophercloud/issues/441
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO] TripleO/Ansible PTG session

2017-09-22 Thread Jiří Stránský

On 22.9.2017 15:30, Jiri Tomasek wrote:

Will it be possible to send Zaqar messages at each deployment step to make
the deployment process more interactive?

If we go the way of allowing the wrapping playbook to execute per step,
i think we could send messages to Zaqar after each step. Mistral could
trigger the playbook with sth like `tripleo_run_steps: [1]`, then with
`tripleo_run_steps: [2]` etc. So even though the playbook would support
running all steps by default, Mistral could run it step-by-step.

(Currently we only send Zaqar messages before Heat stack and after Heat
stack, is that right? [1] Or do we send & read some messages from within
the overcloud stack deployment too?)

With logs from external playbooks (like ceph-ansible) it would be less
comfy than it is now, or would require extra effort to improve on that.
Currently AFAIK we don't send any Zaqar messages there anyway [2], but
we at least publish the logs into Mistral separately from the rest of
deployment logs. If we trigger an external playbook from Ansible, making
it a "normal citizen" of a TripleO deployment step, then the external
playbook logs would be reported along with logs of that whole deployment
step. This is IMO the main weak point of having the step loop in Ansible
(assuming its most basic form), perhaps something where we could find an
improvement, e.g. utilizing ARA as James suggested earlier in the
thread. (I don't know enough about ARA at this point to suggest a
particular way of integrating it with Mistral/UI though.)

in case of driving separate
playbooks from mistral workflow, that would be absolutely possible. As it
seems we're more keen on driving everything from wrapping ansible playbook,
is it going to be possible to send Zaqar messages from ansible playbook
directly?

I did a quick search but didn't find any existing Ansible module for
this. If we needed/wanted this for additional granularity, we might have
to implement it.

Being able to properly monitor progress of deployment is important so it
would be good to clarify how that is going to work.

-- Jirka

[1]
https://github.com/openstack/tripleo-common/blob/979dc308e51bb9b8e7b66b4258da1d67e50d9c2b/workbooks/deployment.yaml#L180
[2]
https://github.com/openstack/tripleo-common/blob/979dc308e51bb9b8e7b66b4258da1d67e50d9c2b/workbooks/ceph-ansible.yaml

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [devstack] Why do we apt-get install NEW files/debs/general at job time ?

2017-09-22 Thread Jeremy Stanley

On 2017-09-22 15:04:43 +0200 (+0200), Attila Fazekas wrote:
> "if DevStack gets custom images prepped to make its jobs
> run faster, won't Triple-O, Kolla, et cetera want the same and where
> do we draw that line?). "
> 
> IMHO we can try to have only one big image per distribution,
> where the packages are the union of the packages requested by all team,
> minus the packages blacklisted by any team.
[...]

Until you realize that some projects want packages from UCA, from
RDO, from EPEL, from third-party package repositories. Version
conflicts mean they'll still spend time uninstalling the versions
they don't want and downloading/installing the ones they do so we
have to optimize for one particular set and make the rest
second-class citizens in that scenario.

Also, preinstalling packages means we _don't_ test that projects
actually properly declare their system-level dependencies any
longer. I don't know if anyone's concerned about that currently, but
it used to be the case that we'd regularly add/break the package
dependency declarations in DevStack because of running on images
where the things it expected were preinstalled.
-- 
Jeremy Stanley


signature.asc
Description: Digital signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Garbage patches for simple typo fixes

Hi, 

Isn't it possible to ignore these patches in stackalytics? If the motivation is 
to look better there, this would solve the problem. 

Br, 
Gerg0

-Original Message-
From: Jeremy Stanley [mailto:fu...@yuggoth.org] 
Sent: Friday, September 22, 2017 4:20 PM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] Garbage patches for simple typo fixes

On 2017-09-22 08:30:21 -0400 (-0400), Amrith Kumar wrote:
[...]
> When can we take some concrete action to stop these same kinds of 
> things from coming up again and again?

Technical solutions to social problems rarely do more than increase complexity 
for everyone involved. Communication, documentation and education are likely 
our best options here, but I still question the degree to which the people 
pushing these sorts of contributions will actually get the message since it's 
obvious they aren't engaging meaningfully with the community before attempting 
to contribute.

Could demographic profiling help us figure out the primary motivation (whether 
it's testing the waters, stats padding or employers pushing their staff to 
contribute patches before they've had time to actually assimilate our community 
norms and expectations)?
--
Jeremy Stanley

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [kolla] Documentation restructure and refresh

2017-09-22 Thread Kurt Taylor

At Queens PTG in Denver, we worked on getting the documentation refreshed,
as well as incorporating the new format laid out by the documentation team.

To get this started, I have pushed a WIP ToC patch(1) that incorporates all
the points we discussed. Also, here is the start for the queens doc
restructuring etherpad(2). There are links there for all the related work
and the PTG topic discussion etherpad. I have also created a blueprint(3)
for us to track work.

Feel free to jump in on the etherpad, and please add your nic for work you
want to do. This is the place for brainstorming/discussion points before
deciding on work for the BP. I'll add an agenda topic to the weekly meeting
to make sure this work moves along.

Note: the list in the etherpad is not a complete work list, we need to
break down the ToC into chapters and get volunteers to write or
migrate/refresh that content.

Thanks in advance to anyone that wants to help.

Kurt Taylor (krtaylor)

(1) https://review.openstack.org/#/c/504801
(2) https://etherpad.openstack.org/p/kolla-queens-doc-restructure
(3) https://blueprints.launchpad.net/kolla/+spec/queens-doc-restructure
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Garbage patches for simple typo fixes

2017-09-22 Thread Jeremy Stanley

On 2017-09-22 08:30:21 -0400 (-0400), Amrith Kumar wrote:
[...]
> When can we take some concrete action to stop these same kinds of
> things from coming up again and again?

Technical solutions to social problems rarely do more than increase
complexity for everyone involved. Communication, documentation and
education are likely our best options here, but I still question the
degree to which the people pushing these sorts of contributions will
actually get the message since it's obvious they aren't engaging
meaningfully with the community before attempting to contribute.

Could demographic profiling help us figure out the primary
motivation (whether it's testing the waters, stats padding or
employers pushing their staff to contribute patches before they've
had time to actually assimilate our community norms and
expectations)?
-- 
Jeremy Stanley

signature.asc
Description: Digital signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [networking-ovn] Support for direct vnic_type

2017-09-22 Thread Moshe Levi



> -Original Message-
> From: pranab boruah [mailto:pranabjyotibor...@gmail.com]
> Sent: Friday, September 22, 2017 5:06 PM
> To: OpenStack Development Mailing List (not for usage questions)
> 
> Cc: Moshe Levi 
> Subject: [openstack-dev] [networking-ovn] Support for direct vnic_type
> 
> Thanks Moshe for the quick reply.
> 
> I can definitely use some guidance for contributing on this( a newbie here).
> Few questions:
> 1. Do you think this support could be added in queens release cycle? I think
> blueprints submission for queens is closed right?
I think it still open
> 2. For adding this support, some changes to the OVN components might be
> required too or just changes in the networking-ovn driver would be enough?
I am not sure I have not look on OVN at all. I would suggest to start with the 
networking-ovn to see if it working  
> 3. What tool do you guys use to deploy a muti-node cluster to start
> development? We used PackStack to deploy a 3-node Pike cluster with OVN,
> and it gave us enough nightmares of a lifetime.J
We use devstack. 
> 
> -Pranab
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [networking-ovn] Support for direct vnic_type

2017-09-22 Thread pranab boruah

Thanks Moshe for the quick reply.

I can definitely use some guidance for contributing on this( a newbie
here). Few questions:
1. Do you think this support could be added in queens release cycle? I
think blueprints submission for queens is closed right?
2. For adding this support, some changes to the OVN components might
be required too or just changes in the networking-ovn driver would be
enough?
3. What tool do you guys use to deploy a muti-node cluster to start
development? We used PackStack to deploy a 3-node Pike cluster with
OVN, and it gave us enough nightmares of a lifetime.J

-Pranab

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] team ptg photos

2017-09-22 Thread Furukawa, Yushiro

Thanks Kevin.  It’s so funny!!  :-)

Best regards,

Yushiro Furukawa

From: Kevin Benton [mailto:ke...@benton.pub]
Sent: Thursday, September 21, 2017 10:16 AM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [neutron] team ptg photos

https://photos.app.goo.gl/Aqa51E2aVkv5b4ah1
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [oslo][oslo.config][all] who asked me about versioning or deprecating default values for config options?

Last week at the PTG someone asked me about best practices for
changing or deprecating default values for configuration options.
Unfortunately I failed to make any notes at the time and I'm
embarrassed to say that I don't remember who it was or exactly what
the use case was. If that was you, could you let me know?  Another
potentially related case came up, and I think I have an approach
that works for both situations, but before I throw around a lot of
details I want to make sure I've thought it through.

Doug

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [os-vif] [passthrough] [VifHostDevice]

2017-09-22 Thread Moshe Levi

The ODL part is still not ready. We need to do code changes in odl to make it 
work see [1] [2]

[1] https://git.opendaylight.org/gerrit/#/c/62481/ 
[2] https://git.opendaylight.org/gerrit/#/c/60259/ 

We try to make the design as generic as possible so if you have a SR-IOV NIC 
that support switchdev 
And allow to offload rules using linux tc it should work.  

> -Original Message-
> From: pranab boruah [mailto:pranabjyotibor...@gmail.com]
> Sent: Friday, September 22, 2017 4:50 PM
> To: openstack-dev@lists.openstack.org
> Subject: [openstack-dev] [os-vif] [passthrough] [VifHostDevice]
> 
> Thanks Sean for such a descriptive answer. It definitely helped.
> 
> >the hardware offload support for melonox nics is only supported with
> >the openvswitch or odl >ml2 dirvers
> [Pranab] Okay. We have the option of using ODL as the mechanism driver
> too. I am building the cluster with ODL as the mechanism driver right now and
> would experiment with it.
> Do you think there is a design limitation in VIFHostDevice model that limits 
> us
> in using either only Mellanox or Netronome NICs? AFAIK, say I have a SRIOV
> NIC that supports OVS offload and Switchdev and we use openvswitch/odl as
> the mechanism driver, things should work as expected for this NIC too right?
> 
> __
> 
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-
> requ...@lists.openstack.org?subject:unsubscribe
> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.
> openstack.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fopenstack-
> dev=02%7C01%7Cmoshele%40mellanox.com%7C5d64f1a6da0142ffb40
> 908d501c0c634%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C63641
> 6849830686294=eU2fTih8PqnDEpmNugmDMmOB2I40znLkEpbEmfYS3
> 3Y%3D=0
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [infra][mogan] Need help for replacing the current master

Hi infra,

In order to show respect to the original authors, we would like to replace
the current mogan master [1] with a new forked repo [2] which includes the
history of files which copied from other projects.

The detailed discussion is here: http://lists.openstack.
org/pipermail/openstack-dev/2017-September/122470.html

Thank you for your time!

[1] https://github.com/openstack/mogan
[2] https://github.com/dims/mogan

-- 
Best Regards,
Zhenguo Niu
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [os-vif] [passthrough] [VifHostDevice]

2017-09-22 Thread pranab boruah

Thanks Sean for such a descriptive answer. It definitely helped.

>the hardware offload support for melonox nics is only supported with the 
>openvswitch or odl >ml2 dirvers
[Pranab] Okay. We have the option of using ODL as the mechanism driver
too. I am building the cluster with ODL as the mechanism driver right
now and would experiment with it.
Do you think there is a design limitation in VIFHostDevice model that
limits us in using either only Mellanox or Netronome NICs? AFAIK, say
I have a SRIOV NIC that supports OVS offload and Switchdev and we use
openvswitch/odl as the mechanism driver, things should work as
expected for this NIC too right?

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc][nova][mogan] How to show respect to the original authors?

Thanks Sean for the suggestion, os-brick is indeed a good example for
sharing codes. Will discuss with the team to see if it's possible to move
that code into such a library.

On Fri, Sep 22, 2017 at 9:26 PM, Sean McGinnis 
wrote:

> > >
> > > Luckily, since these things are part of the ABI of Nova, they are
> > > versioned in many cases, and in all have a well defined interfaces on
> > > one side. Seems like it should be relatively straight forward to wrap
> > > the other side of them and call it a library.
> > >
> > > 
> __
> > > OpenStack Development Mailing List (not for usage questions)
> > > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > >
> >
> > Sounds great if we can call these ABI as a library, but seems still need
> > some refactoring on Nova side to make other projects be able to leverage
> it.
> >
>
> I wouldn't drop the idea because of that. In the case of the os-brick
> library, there was common code for interacting with local storage
> management in both Cinder and Nova. We recognized this and started the
> os-brick library to move that code into one place.
>
> Cinder started using it right away, but it was at least a couple cycles
> before Nova started looking at it. I think that's perfectly fine. If
> you are able to start a library for your own use, and it has good and
> useful common functionality, then Nova can make the decision later if
> they want to take advantage of it.
>
> Sean
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Best Regards,
Zhenguo Niu
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [networking-ovn] Support for direct vnic_type

2017-09-22 Thread Moshe Levi

Hi, 

From  Mellanox perspective supporting direct port in OVN is in the plan. 
One of the reason that we did not contribute this change to OVN was because of 
that OVN support geneve tunnel and not vxlan.
(Mellanox card don't support hw-offloading of  geneve).
 If you want to contribute please go head I would happy to review the code 
changes. 

> -Original Message-
> From: pranab boruah [mailto:pranabjyotibor...@gmail.com]
> Sent: Friday, September 22, 2017 4:17 PM
> To: OpenStack Development Mailing List (not for usage questions)
> 
> Subject: [openstack-dev] [networking-ovn] Support for direct vnic_type
> 
> Hi,
> I request you to go through this thread :
> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.
> openstack.org%2Fpipermail%2Fopenstack-dev%2F2017-
> September%2F122447.html=02%7C01%7Cmoshele%40mellanox.com%
> 7C58f94f72a2b0453b525708d501bc6fc5%7Ca652971c7d2e4d9ba6a4d149256f4
> 61b%7C0%7C0%7C636416831208380962=QoirMj6E5QrBPwwxt9MR21F
> WjoW%2B1ScEacio4us8eIs%3D=0
> 
> As Sean pointed out that Direct vnic_type is not yet supported in OVN, while
> it is supported in ODL and OVS.
> I wanted to know if there is any plan to add this support in OVN too?
> Or is there is a limitation in OVN architectural design that limits the 
> support of
> Direct vinc_type?
> 
> Would be happy to contribute if required.
> 
> Thanks,
> Pranab
> 
> __
> 
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-
> requ...@lists.openstack.org?subject:unsubscribe
> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.
> openstack.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fopenstack-
> dev=02%7C01%7Cmoshele%40mellanox.com%7C58f94f72a2b0453b525
> 708d501bc6fc5%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C63641
> 6831208380962=BImVSbVcqyDh49OLzKcRWC6Kh0A%2Bgoe9uhWslRu
> uVdE%3D=0
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO] TripleO/Ansible PTG session

2017-09-22 Thread Jiri Tomasek

Will it be possible to send Zaqar messages at each deployment step to make
the deployment process more interactive? in case of driving separate
playbooks from mistral workflow, that would be absolutely possible. As it
seems we're more keen on driving everything from wrapping ansible playbook,
is it going to be possible to send Zaqar messages from ansible playbook
directly?

Being able to properly monitor progress of deployment is important so it
would be good to clarify how that is going to work.

-- Jirka

On Fri, Sep 22, 2017 at 3:17 PM, Jiří Stránský  wrote:

> On 22.9.2017 13:44, Giulio Fidente wrote:
>
>> On 09/21/2017 07:53 PM, Jiří Stránský wrote:
>>
>>> On 21.9.2017 18:04, Marios Andreou wrote:
>>>
 On Thu, Sep 21, 2017 at 3:53 PM, Jiří Stránský 
 wrote:

>>>
>> [...]
>>
>> That way we could run the whole thing end-to-end via
> ansible-playbook, or
> if needed one could execute smaller bits by themselves (steps or nested
> playbook runs) -- that capability is not baked in by default, but i
> think
> we could make it so.
>
> Also the interface for services would be clean and simple -- it's
> always
> the ansible tasks.
>
> And Mistral-less use cases become easier to handle too (= undercloud
> installation when Mistral isn't present yet, or development envs when
> you
> want to tune the playbook directly without being forced to go through
> Mistral).
>
>
 You don't *have* to go through mistral either way I mean you can always
 just run ansible-playbook directly using the generated playbooks if
 that is
 what you need for dev/debug etc.



> Logging becomes a bit more unwieldy in this scenario though, as for the
> nested ansible-playbook execution, all output would go into a task in
> the
> outer playbook, which would be harder to follow and the log of the
> outer
> playbook could be huge.
>
> So this solution is no silver bullet, but from my current point of
> view it
> seems a bit less conceptually foreign than using Mistral to provide
> step
> loop functionality to Ansible, which should be able to handle that on
> its
> own.
>
>
> just saying using mistral to invoke ansible-playbook doesn't imply
 having
 mistral do the looping/step control. I think it was already mentioned
 that
 we can/will have multiple invocations of ansible-playbook. Having the
 loop
 in the playbook then means organising our templates a certain way so
 that
 there is a _single_ parent playbook which we can parameterise to then
 run
 all or some of the steps (which as pointed above is currently the case
 for
 the upgrade and deployment steps playbooks).

>>>
>>> Yup, +1 again :) However, the 1)2)3)4) approach discussed earlier in the
>>> thread suggested to hand over the step loop control to Mistral and keep
>>> using the Mistral workflow_tasks, which would make it impossible to have
>>> a single parent playbook, if i understood correctly. So Mistral would be
>>> a requirement for running all steps via a single command (impacting UC
>>> install and developer workflow).
>>>
>>
>> yes I am not sold (yet?) on the idea of ansible driving the deployment
>> and would like to keep some abstraction before it
>>
>> the additional abstraction will make it possible for example to execute
>> tasks written as mistral actions (eg. python code) in between or during
>> any given deployment step, instead of ansible tasks only ... I guess we
>> could also write ansible actions in python but it's not trivial to ship
>> them from THT and given the project mission we have of being "openstack
>> on openstack" I'd also prefer writing a mistral action vs ansible
>>
>> similarily, the ceph-ansible workflow runs a task to build the ansible
>> inventory; if we make the "external" services integration an
>> ansible->ansible process we'll probably need to ship from THT an heat
>> query (or ansible task) to be executed by the "outer" ansible to create
>> the inventory for the inner ansible
>>
>
> Yea, allowing e2e software deployment with Ansible requires converting the
> current Mistral workflow_tasks into Ansible. In terms of services affected
> by this, there's in-tree ceph-ansible [1] and we have proposed patches for
> Kubernetes and Skydive (that's what i'm aware of).
>
>
>> I supported the introduction of mistral as an API and would prefer to
>> have there more informations there versus moving it away into YACT (yet
>> another configuration tool)
>>
>
> We could mitigate this somewhat by doing what Marios and James suggested
> -- running the global playbook one step at a time when the playbook is
> executed from Mistral. It will not give Mistral 100% of the information
> when compared with the approach you suggested, but it's a bit closer...
>
>
>> depending on mistral for the undercloud

Re: [openstack-dev] [tc][nova][mogan] How to show respect to the original authors?

2017-09-22 Thread Sean McGinnis

> >
> > Luckily, since these things are part of the ABI of Nova, they are
> > versioned in many cases, and in all have a well defined interfaces on
> > one side. Seems like it should be relatively straight forward to wrap
> > the other side of them and call it a library.
> >
> > __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> 
> Sounds great if we can call these ABI as a library, but seems still need
> some refactoring on Nova side to make other projects be able to leverage it.
> 

I wouldn't drop the idea because of that. In the case of the os-brick
library, there was common code for interacting with local storage
management in both Cinder and Nova. We recognized this and started the
os-brick library to move that code into one place.

Cinder started using it right away, but it was at least a couple cycles
before Nova started looking at it. I think that's perfectly fine. If
you are able to start a library for your own use, and it has good and
useful common functionality, then Nova can make the decision later if
they want to take advantage of it.

Sean


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Garbage patches for simple typo fixes


On 9/22/2017 7:10 AM, Tom Barron wrote:

FWIW I think it is better not to attribute motivation in these cases.
Perhaps the code submitter is trying to pad stats, but perhaps they are
just a new contributor trying to learn the process with a "harmless"
patch, or just a compulsive clean-upper who hasn't thought through the
costs in reviewer time and CI resources.


I agree. However, the one that set me off last night was a person from 
one company who I've repeatedly -1ed the same types of patches in nova 
for weeks, including on stable branches, and within 10 minutes of each 
other across several repos, so it's clearly part of some daily routine. 
That's what prompted me to send something to the mailing list.


--

Thanks,

Matt

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [networking-ovn] Support for direct vnic_type

2017-09-22 Thread pranab boruah

Hi,
I request you to go through this thread :
http://lists.openstack.org/pipermail/openstack-dev/2017-September/122447.html

As Sean pointed out that Direct vnic_type is not yet supported in OVN,
while it is supported in ODL and OVS.
I wanted to know if there is any plan to add this support in OVN too?
Or is there is a limitation in OVN architectural design that limits
the support of Direct vinc_type?

Would be happy to contribute if required.

Thanks,
Pranab

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO] TripleO/Ansible PTG session

2017-09-22 Thread Jiří Stránský


On 22.9.2017 13:44, Giulio Fidente wrote:

On 09/21/2017 07:53 PM, Jiří Stránský wrote:

On 21.9.2017 18:04, Marios Andreou wrote:

On Thu, Sep 21, 2017 at 3:53 PM, Jiří Stránský  wrote:


[...]


That way we could run the whole thing end-to-end via
ansible-playbook, or
if needed one could execute smaller bits by themselves (steps or nested
playbook runs) -- that capability is not baked in by default, but i
think
we could make it so.

Also the interface for services would be clean and simple -- it's always
the ansible tasks.

And Mistral-less use cases become easier to handle too (= undercloud
installation when Mistral isn't present yet, or development envs when
you
want to tune the playbook directly without being forced to go through
Mistral).



You don't *have* to go through mistral either way I mean you can always
just run ansible-playbook directly using the generated playbooks if
that is
what you need for dev/debug etc.




Logging becomes a bit more unwieldy in this scenario though, as for the
nested ansible-playbook execution, all output would go into a task in
the
outer playbook, which would be harder to follow and the log of the outer
playbook could be huge.

So this solution is no silver bullet, but from my current point of
view it
seems a bit less conceptually foreign than using Mistral to provide step
loop functionality to Ansible, which should be able to handle that on
its
own.



just saying using mistral to invoke ansible-playbook doesn't imply having
mistral do the looping/step control. I think it was already mentioned
that
we can/will have multiple invocations of ansible-playbook. Having the
loop
in the playbook then means organising our templates a certain way so that
there is a _single_ parent playbook which we can parameterise to then run
all or some of the steps (which as pointed above is currently the case
for
the upgrade and deployment steps playbooks).


Yup, +1 again :) However, the 1)2)3)4) approach discussed earlier in the
thread suggested to hand over the step loop control to Mistral and keep
using the Mistral workflow_tasks, which would make it impossible to have
a single parent playbook, if i understood correctly. So Mistral would be
a requirement for running all steps via a single command (impacting UC
install and developer workflow).


yes I am not sold (yet?) on the idea of ansible driving the deployment
and would like to keep some abstraction before it

the additional abstraction will make it possible for example to execute
tasks written as mistral actions (eg. python code) in between or during
any given deployment step, instead of ansible tasks only ... I guess we
could also write ansible actions in python but it's not trivial to ship
them from THT and given the project mission we have of being "openstack
on openstack" I'd also prefer writing a mistral action vs ansible

similarily, the ceph-ansible workflow runs a task to build the ansible
inventory; if we make the "external" services integration an
ansible->ansible process we'll probably need to ship from THT an heat
query (or ansible task) to be executed by the "outer" ansible to create
the inventory for the inner ansible


Yea, allowing e2e software deployment with Ansible requires converting 
the current Mistral workflow_tasks into Ansible. In terms of services 
affected by this, there's in-tree ceph-ansible [1] and we have proposed 
patches for Kubernetes and Skydive (that's what i'm aware of).




I supported the introduction of mistral as an API and would prefer to
have there more informations there versus moving it away into YACT (yet
another configuration tool)


We could mitigate this somewhat by doing what Marios and James suggested 
-- running the global playbook one step at a time when the playbook is 
executed from Mistral. It will not give Mistral 100% of the information 
when compared with the approach you suggested, but it's a bit closer...




depending on mistral for the undercloud install is also not very
different from depending on heat(-all)

I understand the ansible->ansible process addresses the "simplification"
issue we have been asked to look into; it is pretty much the only good
thing I see about it though :D


Right, it's a simpler design, which i consider important, as my hope is 
that over time it would result in some time savings, hopefully 
not just among developers, but also operators, when having to debug 
things or reason about how TripleO works.


Btw the points i didn't react to -- i mostly agree there :P. There are 
tradeoffs involved in both variants and it's not a clear-as-day choice 
for me either.


Thanks :)

Jirka

[1] 
https://github.com/openstack/tripleo-common/blob/master/workbooks/ceph-ansible.yaml


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

Re: [openstack-dev] [devstack] Why do we apt-get install NEW files/debs/general at job time ?

2017-09-22 Thread Attila Fazekas

"if DevStack gets custom images prepped to make its jobs
run faster, won't Triple-O, Kolla, et cetera want the same and where
do we draw that line?). "

IMHO we can try to have only one big image per distribution,
where the packages are the union of the packages requested by all team,
minus the packages blacklisted by any team.

You need to provide a bug link(s) (distribution/upstream bug) for
blacklisting
a package.

Very unlikely we will run out from the disk space juts because of the too
many packages,
usually if a package causes harm to anything it is a distro/upstream bug
which expected
to be solved within 1..2 cycle in the worst case scenario.

If the above thing proven to be not working, we need to draw the line based
on the
expected usage frequency.

On Wed, Sep 20, 2017 at 3:46 PM, Jeremy Stanley  wrote:

> On 2017-09-20 15:17:28 +0200 (+0200), Attila Fazekas wrote:
> [...]
> > The image building was the good old working solution and unless
> > the image build become a super expensive thing, this is still the
> > best option.
> [...]
>
> It became a super expensive thing, and that's the main reason we
> stopped doing it. Now that Nodepool has grown support for
> distributed/parallel image building and uploading, the cost model
> may have changed a bit in that regard so I agree it doesn't hurt to
> revisit that decision. Nevertheless it will take a fair amount of
> convincing that the savings balances out the costs (not just in
> resource consumption but also administrative overhead and community
> impact... if DevStack gets custom images prepped to make its jobs
> run faster, won't Triple-O, Kolla, et cetera want the same and where
> do we draw that line?).
> --
> Jeremy Stanley
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][api] POST /api-sig/news

2017-09-22 Thread Jay Pipes


On 09/21/2017 11:37 PM, Joe Topjian wrote:


Microversions also reared their head in the form of a long
discussion about how SDK developers and users are consuming
microversions at a very granular level. This discussion opened many
surprised eyes as we learned how different SDK platforms deal with
microversions, and what exactly are the best practices. We agreed
that it is generally good for an SDK to shield its users from the
details of microversions, but to allow power users to access them if
they care to.


I wanted to add some notes about this.

I wasn't able to attend the PTG but I was delighted that somehow this 
topic came up - and it looks like it was a very in-depth conversation, 
too. The etherpad notes look to have accurately summarized the 
difficulty we're having with microversions in Gophercloud.


Difficult as the problem is, we're not exactly stuck... yet, anyway. As 
one of the maintainers of Gophercloud, one thing I wanted to mention is 
that there shouldn't be a concern of communication problems or anything 
of the sort (ie: why haven't these Gophercloud guys reached out??). 
While the discussion of microversions has been going on for almost two 
months, we only have, at best, a couple of hours a week to research 
solutions. If either we reach a solution or unfortunately come up short, 
I plan to post to the api-consumer list with a story of the experience, 
feedback, and/or a call for help that we're flat out stuck. At the 
moment, anything more would be commentating the sport of virtual 
whiteboarding :)


On the topic of microversions itself, I'm finding this to be a fun 
challenge. I like the core goals of microversions, and given that there 
isn't precedence for this type of thing (unless I'm mistaken) makes it 
more fun. I do hope that we can implement a solution that enables users 
of Gophercloud to easily leverage microversions and do some really cool 
stuff.


Hi Joe!

I'd be interested in helping out. Can you point me to where you're 
tracking issues related to microversion support on GH?


Best,
-jay

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc][nova][mogan] How to show respect to the original authors?

@Dims, sure, will make a formal request, thanks!

On Fri, Sep 22, 2017 at 8:45 PM, Davanum Srinivas  wrote:

> @Zhenguo,
>
> Can you make a formal request via email? add "[infra]" and "[mogan]"
> tags so everyone in mogan is aware of this and the infra folks give
> their ok. Then we can ping infra using "infra-root" on the
> #openstack-infra channel and ask them to replace.
>
> Sounds good?
>
> Thanks,
> Dims
>
> On Fri, Sep 22, 2017 at 8:41 AM, Zhenguo Niu 
> wrote:
> > @Dims,
> >
> > Yes, I think the history is OK, do I need to ping some infra guys or if
> you
> > can help to replace the repo?
> >
> > On Fri, Sep 22, 2017 at 7:22 PM, Davanum Srinivas 
> wrote:
> >>
> >> @Zhenguo,
> >>
> >> Can you please confirm that the history looks good?
> >>
> >> Thanks,
> >> Dims
> >>
> >> On Fri, Sep 22, 2017 at 1:35 AM, Zhenguo Niu 
> >> wrote:
> >> > Thanks dims, that's cool :D
> >> >
> >> > I'll make sure there's no new patches landed to master before
> replacing
> >> > the
> >> > repo.
> >> >
> >> > On Fri, Sep 22, 2017 at 9:53 AM, Davanum Srinivas 
> >> > wrote:
> >> >>
> >> >> Zhenguo,
> >> >>
> >> >> I did some fancy surgery with both cinder and nova repos to add the
> >> >> history, please check my repo here:
> >> >> https://github.com/dims/mogan/commits/master
> >> >>
> >> >> (Needed quota.py from cinder and rest of the files from Nova)
> >> >>
> >> >> If that repo looks good, then we can request infra folks to replace
> >> >> the current master with that one.
> >> >>
> >> >> Thanks,
> >> >> Dims
> >> >>
> >> >> On Thu, Sep 21, 2017 at 9:21 PM, Zhenguo Niu 
> >> >> wrote:
> >> >> >
> >> >> >
> >> >> > On Fri, Sep 22, 2017 at 5:48 AM, Matt Riedemann <
> mriede...@gmail.com>
> >> >> > wrote:
> >> >> >>
> >> >> >> On 9/21/2017 11:55 AM, Mike Perez wrote:
> >> >> >>>
> >> >> >>> On 15:56 Sep 20, Flavio Percoco wrote:
> >> >> 
> >> >>  On 20/09/17 12:21 +, Jeremy Stanley wrote:
> >> >> >
> >> >> > On 2017-09-20 07:51:29 -0400 (-0400), Davanum Srinivas wrote:
> >> >> > [...]
> >> >> >>
> >> >> >> please indicate which file from Nova, so if anyone wanted to
> >> >> >> cross
> >> >> >> check for fixes etc can go look in Nova
> >> >> >
> >> >> > [...]
> >> >> >
> >> >> > While the opportunity has probably passed in this case, the
> ideal
> >> >> > method is to start with a Git fork of the original as your seed
> >> >> > project (perhaps with history pruned to just the files you're
> >> >> > reusing via git filter-branch or similar). This way the
> complete
> >> >> > change history of the files in question is preserved for future
> >> >> > inspection.
> >> >> 
> >> >> 
> >> >>  If it's not too late, I would definitely recommend going with a
> >> >>  fork,
> >> >>  fwiw.
> >> >> 
> >> >>  Flavio
> >> >> 
> >> >>  --
> >> >>  @flaper87
> >> >>  Flavio Percoco
> >> >> >>>
> >> >> >>>
> >> >> >>> +1 please fork instead.
> >> >> >>>
> >> >> >>>
> >> >> >>>
> >> >> >>>
> >> >> >>>
> >> >> >>>
> >> >> >>> 
> __
> >> >> >>> OpenStack Development Mailing List (not for usage questions)
> >> >> >>> Unsubscribe:
> >> >> >>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >> >> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack-dev
> >> >> >>>
> >> >> >>
> >> >> >> I'm pretty sure this ship has sailed. Mogan has been around since
> >> >> >> before
> >> >> >> the PTG in Atlanta.
> >> >> >>
> >> >> >> --
> >> >> >>
> >> >> >> Thanks,
> >> >> >>
> >> >> >> Matt
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >> 
> __
> >> >> >> OpenStack Development Mailing List (not for usage questions)
> >> >> >> Unsubscribe:
> >> >> >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >> >> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >> >> >
> >> >> >
> >> >> > Yes, we are way past that, and there are already 1000+ commits
> since
> >> >> > Mogan
> >> >> > created,
> >> >> >
> >> >> > --
> >> >> > Best Regards,
> >> >> > Zhenguo Niu
> >> >> >
> >> >> >
> >> >> >
> >> >> > 
> __
> >> >> > OpenStack Development Mailing List (not for usage questions)
> >> >> > Unsubscribe:
> >> >> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >> >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >> >> >
> >> >>
> >> >>
> >> >>
> >> >> --
> >> >> Davanum Srinivas :: https://twitter.com/dims
> >> >>
> >> >>
> >> >> 
> __
> >> >> OpenStack Development Mailing List (not for usage questions)
> >> >> Unsubscribe:
> >> >>

Re: [openstack-dev] Garbage patches for simple typo fixes

Excerpts from Tom Barron's message of 2017-09-22 08:10:35 -0400:
> 
> On 09/21/2017 10:21 PM, Matt Riedemann wrote:
> > I just wanted to highlight to people that there seems to be a series of
> > garbage patches in various projects [1] which are basically doing things
> > like fixing a single typo in a code comment, or very narrowly changing
> > http to https in links within docs.
> > 
> > Also +1ing ones own changes.
> > 
> > I've been trying to snuff these out in nova, but I see it's basically a
> > pattern widespread across several projects.
> > 
> > This is the boilerplate comment I give with my -1, feel free to employ
> > it yourself.
> > 
> > "Sorry but this isn't really a useful change. Fixing typos in code
> > comments when the context is still clear doesn't really help us, and
> > mostly seems like looking for padding stats on stackalytics. It's also a
> > drain on our CI environment.
> > 
> > If you fixed all of the typos in a single module, or in user-facing
> > documentation, or error messages, or something in the logs, or something
> > that actually doesn't make sense in code comments, then maybe, but this
> > isn't one of those things."
> > 
> > I'm not trying to be a jerk here, but this is annoying to the point I
> > felt the need to say something publicly.
> > 
> > [1] https://review.openstack.org/#/q/author:%255E.*inspur.*
> > 
> 
> The boilerplate is helpful but have we considered putting something
> along these lines in official documentation so that reviewers can just
> point to it? It should then be clear to all that negative reviews on
> these grounds are not simply a function of the individual reviewer's
> judgment or personality.

That's a good idea. How about adding a "Contribution Guidelines" section
to https://docs.openstack.org/project-team-guide/open-development.html
with this and other tips?

> FWIW I think it is better not to attribute motivation in these cases.
> Perhaps the code submitter is trying to pad stats, but perhaps they are
> just a new contributor trying to learn the process with a "harmless"
> patch, or just a compulsive clean-upper who hasn't thought through the
> costs in reviewer time and CI resources.

Good points.

Doug

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc][nova][mogan] How to show respect to the original authors?

2017-09-22 Thread Davanum Srinivas

@Zhenguo,

Can you make a formal request via email? add "[infra]" and "[mogan]"
tags so everyone in mogan is aware of this and the infra folks give
their ok. Then we can ping infra using "infra-root" on the
#openstack-infra channel and ask them to replace.

Sounds good?

Thanks,
Dims

On Fri, Sep 22, 2017 at 8:41 AM, Zhenguo Niu  wrote:
> @Dims,
>
> Yes, I think the history is OK, do I need to ping some infra guys or if you
> can help to replace the repo?
>
> On Fri, Sep 22, 2017 at 7:22 PM, Davanum Srinivas  wrote:
>>
>> @Zhenguo,
>>
>> Can you please confirm that the history looks good?
>>
>> Thanks,
>> Dims
>>
>> On Fri, Sep 22, 2017 at 1:35 AM, Zhenguo Niu 
>> wrote:
>> > Thanks dims, that's cool :D
>> >
>> > I'll make sure there's no new patches landed to master before replacing
>> > the
>> > repo.
>> >
>> > On Fri, Sep 22, 2017 at 9:53 AM, Davanum Srinivas 
>> > wrote:
>> >>
>> >> Zhenguo,
>> >>
>> >> I did some fancy surgery with both cinder and nova repos to add the
>> >> history, please check my repo here:
>> >> https://github.com/dims/mogan/commits/master
>> >>
>> >> (Needed quota.py from cinder and rest of the files from Nova)
>> >>
>> >> If that repo looks good, then we can request infra folks to replace
>> >> the current master with that one.
>> >>
>> >> Thanks,
>> >> Dims
>> >>
>> >> On Thu, Sep 21, 2017 at 9:21 PM, Zhenguo Niu 
>> >> wrote:
>> >> >
>> >> >
>> >> > On Fri, Sep 22, 2017 at 5:48 AM, Matt Riedemann 
>> >> > wrote:
>> >> >>
>> >> >> On 9/21/2017 11:55 AM, Mike Perez wrote:
>> >> >>>
>> >> >>> On 15:56 Sep 20, Flavio Percoco wrote:
>> >> 
>> >>  On 20/09/17 12:21 +, Jeremy Stanley wrote:
>> >> >
>> >> > On 2017-09-20 07:51:29 -0400 (-0400), Davanum Srinivas wrote:
>> >> > [...]
>> >> >>
>> >> >> please indicate which file from Nova, so if anyone wanted to
>> >> >> cross
>> >> >> check for fixes etc can go look in Nova
>> >> >
>> >> > [...]
>> >> >
>> >> > While the opportunity has probably passed in this case, the ideal
>> >> > method is to start with a Git fork of the original as your seed
>> >> > project (perhaps with history pruned to just the files you're
>> >> > reusing via git filter-branch or similar). This way the complete
>> >> > change history of the files in question is preserved for future
>> >> > inspection.
>> >> 
>> >> 
>> >>  If it's not too late, I would definitely recommend going with a
>> >>  fork,
>> >>  fwiw.
>> >> 
>> >>  Flavio
>> >> 
>> >>  --
>> >>  @flaper87
>> >>  Flavio Percoco
>> >> >>>
>> >> >>>
>> >> >>> +1 please fork instead.
>> >> >>>
>> >> >>>
>> >> >>>
>> >> >>>
>> >> >>>
>> >> >>>
>> >> >>> __
>> >> >>> OpenStack Development Mailing List (not for usage questions)
>> >> >>> Unsubscribe:
>> >> >>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> >> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >> >>>
>> >> >>
>> >> >> I'm pretty sure this ship has sailed. Mogan has been around since
>> >> >> before
>> >> >> the PTG in Atlanta.
>> >> >>
>> >> >> --
>> >> >>
>> >> >> Thanks,
>> >> >>
>> >> >> Matt
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >> __
>> >> >> OpenStack Development Mailing List (not for usage questions)
>> >> >> Unsubscribe:
>> >> >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> >> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >> >
>> >> >
>> >> > Yes, we are way past that, and there are already 1000+ commits since
>> >> > Mogan
>> >> > created,
>> >> >
>> >> > --
>> >> > Best Regards,
>> >> > Zhenguo Niu
>> >> >
>> >> >
>> >> >
>> >> > __
>> >> > OpenStack Development Mailing List (not for usage questions)
>> >> > Unsubscribe:
>> >> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> Davanum Srinivas :: https://twitter.com/dims
>> >>
>> >>
>> >> __
>> >> OpenStack Development Mailing List (not for usage questions)
>> >> Unsubscribe:
>> >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>> >
>> >
>> >
>> > --
>> > Best Regards,
>> > Zhenguo Niu
>> >
>> >
>> > __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe:
>> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> >

Re: [openstack-dev] [tc][nova][mogan] How to show respect to the original authors?