[openstack-dev] [security] [salt] Removal of Security and OpenStackSalt project teams from the Big Tent
Doug Hellmann
doug at doughellmann.com
Wed Sep 21 18:58:20 UTC 2016
Excerpts from Chivers, Doug's message of 2016-09-21 18:20:35 +0000:
> My concern is with the original wording “The suggested way forward there would be to remove the "Security project team"”.
>
> This seems like a move to instantly reduce investment in OpenStack security, because the majority of members of the Security Project are corporately funded, which will be significantly impacted by the removal of the security project. I have no knowledge over the difference between a working group and a project, like everyone else on the project we are simply here to contribute to OpenStack security, drive innovation in security, deliver documentation like OSSNs, etc, rather than get involved in the politics of OpenStack.
I'm not sure why you consider ensuring that the team is well integrated
with the rest of the community to be "political." "Social," maybe?
> In response to the various questions of why no-one from our project noticed that we didn’t have a nomination for the PTL, we assumed that was taken care of. Realistically maybe two or three people on the security project have the availability to be PTL, one being our current PTL, for all the rest of us its simply not a concern until we need to vote.
I think that's exactly the point being made. If the team is not
actively maintaining its leadership and liaisons, so that other
teams know who the main contact points are and so the team knows
it is receiving important communication from other groups and
participating in the cycle cadence, then the group isn't really
meeting the expectations of being an official team within the
community. And if the team's members aren't interested in those
things, why continue to try to maintain the team status? The
expectations are lower for a working group, with the trade-off that
contributions do not directly confer ATC status (though working on
other projects might).
> On a personal note, reading –dev is unfortunately a lower priority than designing architectures, responding to customers and sales teams, closing tickets, writing decks and on the afternoon or so I can spend each week, working on my upstream projects (this week it was: https://review.openstack.org/#/c/357978/5 - thanks to the Barbican team for all their work). Possibly this is wrong, but I didn’t sign up as a contributor to spend all my spare time reading mailing lists.
>
> Regards
>
> Doug
>
> _________________________________
> Doug Chivers
> Chief Security Architect, Helion OpenStack
>
>
> On 21/09/2016, 18:26, "Doug Hellmann" <doug at doughellmann.com> wrote:
>
> Excerpts from Travis Mcpeak's message of 2016-09-21 16:23:55 +0000:
> > Ouch. I'd be among the first to admit I don't keep up with dev ML
> > as I should. Missing the PTL elections is certainly embarrassing
> > for us and it shouldn't be the community's job to baby-sit us and
> > make sure we're meeting our OpenStack deadlines.
> >
> > That being said, relegating us to a working group seems like a
> > knee-jerk and drastic consequence to levy against a project as
> > vibrant as ours.
>
> Why is being a working group seen as less desirable? In what way do you
> consider working groups "less"?
>
> >
> > In a previous response Rob has highlighted many of our recent
> > accomplishments, so I won't revisit that here.
> >
> > What I do want to mention is the work Rob himself has done to
> > coordinate and secure funding for our fifth consecutive mid-cycle
> > (and each prior to that). He has worked consistently to build support
> > for our initiatives, both within and outside of OpenStack.
> >
> > Since assuming the PTL role none of our active members have been
> > inclined to run against him.
> >
> > So yes, he's dropped the ball on reading the ML (I have too). If
> > allowed to keep our project status we'll ensure that these mistakes
> > don't happen in the future.
> >
> > Taking away our project status because "we act like a working group"
> > is an unfair categorization and, in my opinion, a severe reaction to a
> > relatively minor infraction.
> >
> > -Travis McPeak
> >
> >
> >
> > From: openstack-dev-request at lists.openstack.org
> > To: openstack-dev at lists.openstack.org
> > Date: 09/21/2016 05:04 AM
> > Subject: OpenStack-dev Digest, Vol 53, Issue 51
> >
> >
> >
> > Send OpenStack-dev mailing list submissions to
> > openstack-dev at lists.openstack.org
> >
> > To subscribe or unsubscribe via the World Wide Web, visit
> >
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > or, via email, send a message with subject or body 'help' to
> > openstack-dev-request at lists.openstack.org
> >
> > You can reach the person managing the list at
> > openstack-dev-owner at lists.openstack.org
> >
> > When replying, please edit your Subject line so it is more specific
> > than "Re: Contents of OpenStack-dev digest..."
> >
> >
> > Today's Topics:
> >
> > 1. Re: [cinder][sahara] LVM vs BDD drivers performance tests
> > results (Micha? Dulko)
> > 2. [manila] Enable IPv6 in Manila Ocata (jun zhong)
> > 3. [vitrage] Barcelona design sessions (Afek, Ifat (Nokia - IL))
> > 4. [Kuryr] Kuryr IPVlan Code PoC (Daly, Louise M)
> > 5. Re: [Neutron] Adding ihrachys to the neutron-drivers team
> > (Rossella Sblendido)
> > 6. Re: [tripleo] Setting kernel args to overcloud nodes
> > (Saravanan KR)
> > 7. Re: [tripleo] [puppet] Preparing TripleO agenda for Barcelona
> > - action needed (Giulio Fidente)
> > 8. [security] [salt] Removal of Security and OpenStackSalt
> > project teams from the Big Tent (Thierry Carrez)
> > 9. Re: [tc]a chance to meet all TCs for Tricircle big-tent
> > application in Barcelona summit? (Mike Perez)
> > 10. Re: [stackalytics] [deb] [packaging] OpenStack contribution
> > stats skewed by deb-* projects (Thierry Carrez)
> > 11. [ptl] code churn and questionable changes (Amrith Kumar)
> >
> >
> > ----------------------------------------------------------------------
> >
> > Message: 1
> > Date: Wed, 21 Sep 2016 09:57:43 +0200
> > From: Micha? Dulko <michal.dulko at intel.com>
> > To: "OpenStack Development Mailing List (not for usage questions)"
> > <openstack-dev at lists.openstack.org>
> > Subject: Re: [openstack-dev] [cinder][sahara] LVM vs BDD drivers
> > performance tests results
> > Message-ID: <ca9f10ad-51e4-274c-95bd-247719c89b48 at intel.com>
> > Content-Type: text/plain; charset=UTF-8
> >
> > On 09/20/2016 05:48 PM, John Griffith wrote:
> > > On Tue, Sep 20, 2016 at 9:06 AM, Duncan Thomas
> > > <duncan.thomas at gmail.com <mailto:duncan.thomas at gmail.com>> wrote:
> > >
> > > On 20 September 2016 at 16:24, Nikita Konovalov
> > > <nkonovalov at mirantis.com <mailto:nkonovalov at mirantis.com>> wrote:
> > >
> > > Hi,
> > >
> > > From Sahara (and Hadoop workload in general) use-case the
> > > reason we used BDD was a complete absence of any overhead on
> > > compute resources utilization.
> > >
> > > The results show that the LVM+Local target perform pretty
> > > close to BDD in synthetic tests. It's a good sign for LVM. It
> > > actually shows that most of the storage virtualization
> > > overhead is not caused by LVM partitions and drivers
> > > themselves but rather by the iSCSI daemons.
> > >
> > > So I would still like to have the ability to attach partitions
> > > locally bypassing the iSCSI to guarantee 2 things:
> > > * Make sure that lio processes do not compete for CPU and RAM
> > > with VMs running on the same host.
> > > * Make sure that CPU intensive VMs (or whatever else is
> > > running nearby) are not blocking the storage.
> > >
> > >
> > > So these are, unless we see the effects via benchmarks, completely
> > > meaningless requirements. Ivan's initial benchmarks suggest
> > > that LVM+LIO is pretty much close enough to BDD even with iSCSI
> > > involved. If you're aware of a case where it isn't, the first
> > > thing to do is to provide proof via a reproducible benchmark.
> > > Otherwise we are likely to proceed, as John suggests, with the
> > > assumption that local target does not provide much benefit.
> > >
> > > I've a few benchmarks myself that I suspect will find areas where
> > > getting rid of iSCSI is benefit, however if you have any then you
> > > really need to step up and provide the evidence. Relying on vague
> > > claims of overhead is now proven to not be a good idea.
> > >
> > >
> > __________________________________________________________________________
> > > OpenStack Development Mailing List (not for usage questions)
> > > Unsubscribe:
> > > OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > > <
> > http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > > <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
> > >
> > > ?Honestly we can have both, I'll work up a bp to resurrect the idea of
> > > a "smart" scheduling feature that lets you request the volume be on
> > > the same node as the compute node and use it directly, and then if
> > > it's NOT it will attach a target and use it that way (in other words
> > > you run a stripped down c-vol service on each compute node).
> >
> > Don't we have at least scheduling problem solved [1] already?
> >
> > [1]
> > https://github.com/openstack/cinder/blob/master/cinder/scheduler/filters/instance_locality_filter.py
> >
> > >
> > > Sahara keeps insisting on being a snow-flake with Cinder volumes and
> > > the block driver, it's really not necessary. I think we can
> > > compromise just a little both ways, give you standard Cinder semantics
> > > for volumes, but allow you direct acccess to them if/when requested,
> > > but have those be flexible enough that targets *can* be attached so
> > > they meet all of the required functionality and API implementations.
> > > This also means that we don't have to continue having a *special*
> > > driver in Cinder that frankly only works for one specific use case and
> > > deployment.
> > >
> > > I've pointed to this a number of times but it never seems to
> > > resonate... but I never learn so I'll try it once again [1]. Note
> > > that was before the name "brick" was hijacked and now means something
> > > completely different.
> > >
> > > [1]: https://wiki.openstack.org/wiki/CinderBrick
> > >
> > > Thanks,
> > > John?
> >
> >
> >
> >
> > ------------------------------
> >
> > Message: 2
> > Date: Wed, 21 Sep 2016 16:05:08 +0800
> > From: jun zhong <jun.zhongjun2 at gmail.com>
> > To: openstack-dev <openstack-dev at lists.openstack.org>
> > Subject: [openstack-dev] [manila] Enable IPv6 in Manila Ocata
> > Message-ID:
> > <CAAz2tN-hrs_3d0HvavVvU2epHS4CCH1pko88FX1EGgUh8H9DfQ at mail.gmail.com>
> > Content-Type: text/plain; charset="utf-8"
> >
> > Hi,
> >
> > As agreed by the manila community in IRC meeting,
> > we try to enable IPv6 in Ocata. Please check the brief spec[1] and
> > code[2]).
> >
> > The areas affected most are API (access rules) and in the drivers (access
> > rules
> > & export locations). This change intends to add the IPv6 format validation
> > for
> > ip access rule type in allow_access API, allowing manila to support IPv6
> > ACL.
> >
> > Hi all of the driver maintainers, could you test the IPv6 feature code[2]
> > to make sure whether your driver can completely support IPv6.
> > If there still have something else might not be IPv6-ready, please let me
> > known. Thanks
> > [1] https://review.openstack.org/#/c/362786/
> > [2] https://review.openstack.org/#/c/312321/
> >
> >
> > Thanks,
> > Jun
> > -------------- next part --------------
> > An HTML attachment was scrubbed...
> > URL: <
> > http://lists.openstack.org/pipermail/openstack-dev/attachments/20160921/880e28e8/attachment-0001.html
> > >
> >
> > ------------------------------
> >
> > Message: 3
> > Date: Wed, 21 Sep 2016 08:38:53 +0000
> > From: "Afek, Ifat (Nokia - IL)" <ifat.afek at nokia.com>
> > To: "OpenStack Development Mailing List (not for usage questions)"
> > <openstack-dev at lists.openstack.org>
> > Subject: [openstack-dev] [vitrage] Barcelona design sessions
> > Message-ID: <CAD9E9DC-E55D-4BCC-BC8E-1CACDFFA7E09 at alcatel-lucent.com>
> > Content-Type: text/plain; charset="utf-8"
> >
> > Hi,
> >
> > As discussed in our IRC meeting today, you are welcome to suggest topics
> > for vitrage design sessions in Barcelona:
> > https://etherpad.openstack.org/p/vitrage-barcelona-design-sessions
> >
> > Thanks,
> > Ifat.
> >
> > -------------- next part --------------
> > An HTML attachment was scrubbed...
> > URL: <
> > http://lists.openstack.org/pipermail/openstack-dev/attachments/20160921/3b999def/attachment-0001.html
> > >
> >
> > ------------------------------
> >
> > Message: 4
> > Date: Wed, 21 Sep 2016 09:53:06 +0000
> > From: "Daly, Louise M" <louise.m.daly at intel.com>
> > To: "openstack-dev at lists.openstack.org"
> > <openstack-dev at lists.openstack.org>
> > Subject: [openstack-dev] [Kuryr] Kuryr IPVlan Code PoC
> > Message-ID:
> > <D2C06722FF4FE54C88729FC07A5DCD91B43469 at IRSMSX101.ger.corp.intel.com>
> > Content-Type: text/plain; charset="us-ascii"
> >
> > Hi everyone,
> >
> > As promised here is a link to the code PoC for the Kuryr-IPVlan proposal.
> > https://github.com/lmdaly/kuryr-libnetwork
> >
> > Link to specific commit
> > https://github.com/lmdaly/kuryr-libnetwork/commit/1dc895a6d8bfaa03c0dd5cfb2d3e23e2e948a67c
> >
> > >From here you can clone the repo and install Kuryr as you normally would
> > with a few additional steps:
> >
> > 1. The IPVlan driver must be installed on the VM/Machine that the PoC will
> > be run on. Fedora-Server(not the cloud image) includes the driver by
> > default but the likes of the cloud image must be modified to include the
> > driver.
> > 2. You must install Docker experimental.
> > 3. You must use the Kuryr IPAM driver for address management.
> > 4. In order to enable the IPVlan mode you must change the ipvlan option in
> > the kuryr.conf file from false to true.
> > 5. You must also change the ifname option to match the interface of the
> > private network you wish to run the containers on. (Default is ens3)
> > 6. As listed in the limitations on the README.rst on kuryr "To create
> > Docker networks with subnets having same/overlapping cidr, it is expected
> > to pass unique pool name for each such network creation Docker command."
> > You will need to do this if you are creating a docker network with the
> > same private network on another VM.
> >
> > The IPVlan proposal was sent out to the mailing list - link for those who
> > missed it.
> > http://osdir.com/ml/openstack-dev/2016-09/msg00816.html
> >
> > Please send any feedback, issues, comments, bugs.
> >
> > Thanks,
> > Louise
> >
> >
> > --------------------------------------------------------------
> > Intel Research and Development Ireland Limited
> > Registered in Ireland
> > Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
> > Registered Number: 308263
> >
> >
> > This e-mail and any attachments may contain confidential material for the
> > sole
> > use of the intended recipient(s). Any review or distribution by others is
> > strictly prohibited. If you are not the intended recipient, please contact
> > the
> > sender and delete all copies.
> > -------------- next part --------------
> > An HTML attachment was scrubbed...
> > URL: <
> > http://lists.openstack.org/pipermail/openstack-dev/attachments/20160921/e8c695c3/attachment-0001.html
> > >
> >
> > ------------------------------
> >
> > Message: 5
> > Date: Wed, 21 Sep 2016 12:00:38 +0200
> > From: Rossella Sblendido <rsblendido at suse.com>
> > To: openstack-dev at lists.openstack.org
> > Subject: Re: [openstack-dev] [Neutron] Adding ihrachys to the
> > neutron-drivers team
> > Message-ID: <0ffde713-a31d-9362-9b0d-9d88e78528fc at suse.com>
> > Content-Type: text/plain; charset=windows-1252; format=flowed
> >
> > Congratulations Ihar! You really deserved this, I am sure you'll do great.
> >
> > Rossella
> >
> > On 09/20/2016 10:57 AM, Miguel Angel Ajo Pelayo wrote:
> > > Congratulations Ihar!, well deserved through hard work! :)
> > >
> > > On Mon, Sep 19, 2016 at 8:03 PM, Brian Haley <brian.haley at hpe.com>
> > wrote:
> > >> Congrats Ihar!
> > >>
> > >> -Brian
> > >>
> > >>
> > >> On 09/17/2016 12:40 PM, Armando M. wrote:
> > >>>
> > >>> Hi folks,
> > >>>
> > >>> I would like to propose Ihar to become a member of the Neutron drivers
> > >>> team [1].
> > >>>
> > >>> Ihar wide knowledge of the Neutron codebase, and his longstanding
> > duties
> > >>> as
> > >>> stable core, downstream package whisperer, release and oslo liaison (I
> > am
> > >>> sure I
> > >>> am forgetting some other capacity he is in) is going to put him at
> > great
> > >>> comfort
> > >>> in the newly appointed role, and help him grow and become wise even
> > >>> further.
> > >>>
> > >>> Even though we have not been meeting regularly lately we will resume
> > our
> > >>> Thursday meetings soon [2], and having Ihar onboard by then will be
> > highly
> > >>> beneficial.
> > >>>
> > >>> Please, join me in welcome Ihar to the team.
> > >>>
> > >>> Cheers,
> > >>> Armando
> > >>>
> > >>> [1]
> > >>>
> > http://docs.openstack.org/developer/neutron/policies/neutron-teams.html#drivers-team
> >
> > >>>
> > >>> <
> > http://docs.openstack.org/developer/neutron/policies/neutron-teams.html#drivers-team
> > >
> > >>> [2] https://wiki.openstack.org/wiki/Meetings/NeutronDrivers
> > >>> <https://wiki.openstack.org/wiki/Meetings/NeutronDrivers>
> > >>>
> > >>>
> > >>>
> > __________________________________________________________________________
> > >>> OpenStack Development Mailing List (not for usage questions)
> > >>> Unsubscribe:
> > OpenStack-dev-request at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > >
> > >
> >
> >
> >
> > ------------------------------
> >
> > Message: 6
> > Date: Wed, 21 Sep 2016 15:43:24 +0530
> > From: Saravanan KR <skramaja at redhat.com>
> > To: "OpenStack Development Mailing List (not for usage questions)"
> > <openstack-dev at lists.openstack.org>
> > Subject: Re: [openstack-dev] [tripleo] Setting kernel args to
> > overcloud nodes
> > Message-ID:
> > <CAPtmiAeKd0yBgkaFS5oAyzp0KqD+O0x1HweF-SucZFSUm0_NSg at mail.gmail.com>
> > Content-Type: text/plain; charset=UTF-8
> >
> > I have been working on the user-data scripts (first-boot) for updating
> > the kernel args on the overcloud node [1]. The pre-condition is that
> > the kernel args has to be applied and node has to be restarted before
> > os-net-config runs.
> >
> > I got in to problem of provisioning network not getting ip after the
> > reboot in the user-data script. While investigating, figured out that
> > network.service starts the nodes on the alpha-numeric order, on which
> > the first nic is not the one used for provisioning. network.service
> > initiates a DHCP DISCOVER on it, when it times out, network.service
> > goes to failed state and all other interfaces are DOWN state. If i
> > manually bring the interface up (via ipmi console), then all proceeds
> > fine without any issue.
> >
> > To overcome this issue, I have written a small script to find out the
> > provisioning network via metadata (metadata has the mac address of the
> > provisioning network) and make BOOTPROTO=none on all other interface's
> > ifcfg files except the provisioning network. There still an issue of
> > IP not ready at the time of querying metadata, temporarily added a
> > sleep which solves it. The user-data script [1] has all these fixes
> > and tested on an baremetal overcloud node.
> >
> > If anyone has a better way of doing it, you are more than welcome to
> > suggest.
> >
> > Regards,
> > Saravanan KR
> >
> > [1] https://gist.github.com/krsacme/1234bf024ac917c74913827298840c1c
> >
> > On Wed, Jul 27, 2016 at 6:52 PM, Saravanan KR <skramaja at redhat.com> wrote:
> > > Hello,
> > >
> > > We are working on SR-IOV & DPDK tripleo integration. In which, setting
> > > the kernel args for huge pages, iommu and cpu isolation is required.
> > > Earlier we were working on setting of kernel args via IPA [1], reasons
> > > being:
> > > 1. IPA is installing the boot loader on the overcloud node
> > > 2. Ironic knows the hardware spec, using which, we can target specific
> > > args to nodes via introspection rules
> > >
> > > As the proposal is to change the image owned file '/etc/default/grub',
> > > it has been suggested by ironic team to use the instance user data to
> > > set the kernel args [2][3], instead of IPA. In the suggested approach,
> > > we are planning to update the file /etc/default/grub, update
> > > /etc/grub2.cfg and then issue a reboot. Reboot is mandatory because,
> > > os-net-config will configure the DPDK bridges and ports by binding the
> > > DPDK driver, which requires kernel args should be set for iommu and
> > > huge pages.
> > >
> > > As discussed on the IRC tripleo meeting, we need to ensure that the
> > > user data with update of kernel args, does not overlap with any other
> > > puppet configurations. Please let us know if you have any comments on
> > > this approach.
> > >
> > > Regards,
> > > Saravanan KR
> > >
> > > [1] https://review.openstack.org/#/c/331564/
> > > [2]
> > http://docs.openstack.org/developer/ironic/deploy/install-guide.html#appending-kernel-parameters-to-boot-instances
> >
> > > [3]
> > http://docs.openstack.org/developer/tripleo-docs/advanced_deployment/extra_config.html#firstboot-extra-configuration
> >
> >
> >
> >
> > ------------------------------
> >
> > Message: 7
> > Date: Wed, 21 Sep 2016 12:49:58 +0200
> > From: Giulio Fidente <gfidente at redhat.com>
> > To: "OpenStack Development Mailing List (not for usage questions)"
> > <openstack-dev at lists.openstack.org>, Emilien Macchi
> > <emacchi at redhat.com>
> > Subject: Re: [openstack-dev] [tripleo] [puppet] Preparing TripleO
> > agenda for Barcelona - action needed
> > Message-ID: <ea008395-f1d1-47ca-f7d5-321fa9f7d9f9 at redhat.com>
> > Content-Type: text/plain; charset=windows-1252; format=flowed
> >
> > On 09/19/2016 10:49 PM, Emilien Macchi wrote:
> > > (adding puppet tag for cross project session).
> > >
> > > Let's continue to prepare TripleO sessions.
> > >
> > > https://etherpad.openstack.org/p/ocata-tripleo
> > >
> > > For reminder, we have 2 fishbowls and 4 working rooms.
> > > I looked at the topic proposals and I started to organize some sessions.
> > >
> > > Some actions from you are required:
> > > - review the session proposal
> > > - if you want to drive a session, please put your name in "Chair".
> > > - for each session we need to choose if we want it to be a work room
> > > or a fishbowl session.
> > > - 4 topics are still there, please propose a session (concatenate them
> > > if possible)
> > > - if you missed this etherpad until now, feel free to propose a
> > > session with your topic (ex: TripleO UI - roadmap, etc).
> > >
> > > At least but not least, I would propose a cross project session with
> > > Puppet OpenStack group (using a slot from their schedule) so we might
> > > have a 7th session.
> >
> > the cross project session with the puppet group is a nice idea indeed,
> > thanks Emilien
> >
> > in that context it would be nice to gather some ideas/feedback on the
> > status of openstack integration scenarios vs tripleo scenarios and see
> > if we can optimize resources and/or coverage
> > --
> > Giulio Fidente
> > GPG KEY: 08D733BA | IRC: gfidente
> >
> >
> >
> > ------------------------------
> >
> > Message: 8
> > Date: Wed, 21 Sep 2016 13:23:32 +0200
> > From: Thierry Carrez <thierry at openstack.org>
> > To: OpenStack Development Mailing List
> > <openstack-dev at lists.openstack.org>
> > Subject: [openstack-dev] [security] [salt] Removal of Security and
> > OpenStackSalt project teams from the Big Tent
> > Message-ID: <c7e735c1-bfbf-cfca-c972-b2e019840579 at openstack.org>
> > Content-Type: text/plain; charset=utf-8
> >
> > Hi everyone,
> >
> > As announced previously[1][2], there were no PTL candidates within the
> > election deadline for a number of official OpenStack project teams:
> > Astara, UX, OpenStackSalt and Security.
> >
> > In the Astara case, the current team working on it would like to abandon
> > the project (and let it be available for any new team who wishes to take
> > it away). A change should be proposed really soon now to go in that
> > direction.
> >
> > In the UX case, the current PTL (Piet Kruithof) very quickly reacted,
> > explained his error and asked to be considered for the position for
> > Ocata. The TC will officialize his nomination at the next meeting,
> > together with the newly elected PTLs.
> >
> > That leaves us with OpenStackSalt and Security, where nobody reacted to
> > the announcement that we are missing PTL candidates. That points to a
> > real disconnect between those teams and the rest of the community. Even
> > if you didn't have the election schedule in mind, it was pretty hard to
> > miss all the PTL nominations in the email last week.
> >
> > The majority of TC members present at the meeting yesterday suggested
> > that those project teams should be removed from the Big Tent, with their
> > design summit space allocation slightly reduced to match that (and make
> > room for other not-yet-official teams).
> >
> > In the case of OpenStackSalt, it's a relatively new addition, and if
> > they get their act together they could probably be re-proposed in the
> > future. In the case of Security, it points to a more significant
> > disconnect (since it's not the first time the PTL misses the nomination
> > call). We definitely still need to care about Security (and we also need
> > a home for the Vulnerability Management team), but I think the "Security
> > team" acts more like a workgroup than as an official project team, as
> > evidenced by the fact that nobody in that team reacted to the lack of
> > PTL nomination, or the announcement that the team missed the bus.
> >
> > The suggested way forward there would be to remove the "Security project
> > team", have the Vulnerability Management Team file to be its own
> > official project team (in the same vein as the stable maintenance team),
> > and have Security be just a workgroup rather than a project team.
> >
> > Thoughts, comments ?
> >
> > [1]
> > http://lists.openstack.org/pipermail/openstack-dev/2016-September/103904.html
> >
> > [2]
> > http://lists.openstack.org/pipermail/openstack-dev/2016-September/103939.html
> >
> >
> > --
> > Thierry Carrez (ttx)
> >
> >
> >
> > ------------------------------
> >
> > Message: 9
> > Date: Wed, 21 Sep 2016 04:32:57 -0700
> > From: Mike Perez <thingee at gmail.com>
> > To: "OpenStack Development Mailing List (not for usage questions)"
> > <openstack-dev at lists.openstack.org>
> > Subject: Re: [openstack-dev] [tc]a chance to meet all TCs for
> > Tricircle big-tent application in Barcelona summit?
> > Message-ID: <20160921113257.GJ31426 at gmail.com>
> > Content-Type: text/plain; charset=us-ascii
> >
> > On 00:48 Sep 21, joehuang wrote:
> > > Thank you for the message. Will the weekly IRC meeting in that week also
> > be cancelled during
> > > the summit period according to your experience?
> >
> > Likely yes.
> >
> > --
> > Mike Perez
> >
> >
> >
> > ------------------------------
> >
> > Message: 10
> > Date: Wed, 21 Sep 2016 13:37:18 +0200
> > From: Thierry Carrez <thierry at openstack.org>
> > To: openstack-dev at lists.openstack.org
> > Subject: Re: [openstack-dev] [stackalytics] [deb] [packaging]
> > OpenStack contribution stats skewed by deb-* projects
> > Message-ID: <4d62157c-fb5f-5395-3515-e7e564ff66d2 at openstack.org>
> > Content-Type: text/plain; charset=windows-1252
> >
> > Ilya Shakhat wrote:
> > > Hi,
> > >
> > > tldr; Commits stats are significantly skewed by deb-* projects
> > > (http://stackalytics.com/?metric=commits&module=packaging-deb-group)
> > >
> > > By default Stackalytics processes commits from project's master branch.
> > > For some "old core" projects there is configuration to process stable
> > > branches as well. If some commit is cherry-picked from master to stable
> > > it is counted twice in both branches / releases. The configuration for
> > > stable branch is simple - branch starting with branching point (e.g.
> > > stable/newton that starts with rc1)
> > >
> > > In deb-* projects master branch corresponds to upstream Debian
> > > community. All OpenStack-related contribution goes into debian/<release>
> > > branch. But unlike in the rest of OpenStack, git workflow differs and
> > > the branch contains merge commits from master. This makes filtering
> > > "pure" branch commits from those that came from master quite tricky (not
> > > possible to specify the branch-point). And support of this will require
> > > changes in Stackalytics code.
> > >
> > > Since currently we are at the time when people may get nervous about
> > > numbers, I'd suggest to temporary hide all commits from deb-* projects
> > > and revise stats processing in a month.
> >
> > Sounds good. Are you working on it ?
> >
> >
> > --
> > Thierry Carrez (ttx)
> >
> >
> >
> > ------------------------------
> >
> > Message: 11
> > Date: Wed, 21 Sep 2016 11:56:06 +0000
> > From: Amrith Kumar <amrith at tesora.com>
> > To: "OpenStack Development Mailing List (not for usage questions)"
> > <openstack-dev at lists.openstack.org>
> > Subject: [openstack-dev] [ptl] code churn and questionable changes
> > Message-ID:
> >
> > <CO2PR17MB0011672EBE3DD1B02AFF35ECA0F60 at CO2PR17MB0011.namprd17.prod.outlook.com>
> >
> > Content-Type: text/plain; charset="us-ascii"
> >
> > Of late I've been seeing a lot of rather questionable changes that appear
> > to be getting blasted out across multiple projects; changes that cause
> > considerable code churn, and don't (IMHO) materially improve the quality
> > of OpenStack.
> >
> > I'd love to provide a list of the changes that triggered this email but I
> > know that this will result in a rat hole where we end up discussing the
> > merits of the individual items on the list and lose sight of the bigger
> > picture. That won't help address the question I have below in any way, so
> > I'm at a disadvantage of having to describe my issue in abstract terms.
> >
> >
> >
> > Here's how I characterize these changes (changes that meet one or more of
> > these criteria):
> >
> >
> >
> > - Contains little of no information in the commit message (often just a
> > single line)
> >
> > - Makes some generic statement like "Do X not Y", "Don't use Z", "Make
> > ABC better" with no further supporting information
> >
> > - Fail (literally) every single CI job, clearly never tested by the
> > developer
> >
> > - Gets blasted across many projects, literally tens with often the same
> > kind of questionable (often wrong) change
> >
> > - Makes a stylistic python improvement that is not enforced by any
> > check (causes a cottage industry of changes making the same correction
> > every couple of months)
> >
> > - Reverses some previous python stylistic improvement with no clear
> > reason (another cottage industry)
> >
> >
> >
> > I've tried to explain it to myself as enthusiasm, and a desire to
> > contribute aggressively; I've lapsed into cynicism at times and tried to
> > explain it as gaming the numbers system, but all that is merely
> > rationalization and doesn't help.
> >
> >
> >
> > Over time, the result generally is that these developers' changes get
> > ignored. And that's not a good thing for the community as a whole. We want
> > to be a welcoming community and one which values all contributions so I'm
> > looking for some suggestions and guidance on how one can work with
> > contributors to try and improve the quality of these changes, and help the
> > contributor feel that their changes are valued by the project? Other more
> > experienced PTL's, ex-PTL's, long time open-source-community folks, I'm
> > seriously looking for suggestions and ideas.
> >
> >
> >
> > Any and all input is welcome, do other projects see this, how do you
> > handle it, is this normal, ...
> >
> >
> >
> > Thanks!
> >
> >
> >
> > -amrith
> >
> >
> >
> >
> >
> >
> >
> >
> > -------------- next part --------------
> > An HTML attachment was scrubbed...
> > URL: <
> > http://lists.openstack.org/pipermail/openstack-dev/attachments/20160921/c3bc37fe/attachment-0001.html
> > >
> >
>
More information about the OpenStack-dev
mailing list