[openstack-dev] [security] [salt] Removal of Security and OpenStackSalt project teams from the Big Tent
Charles Neill
charles.neill at RACKSPACE.COM
Wed Sep 21 17:10:38 UTC 2016
Agreed entirely with Travis's points. I think it was a given to anyone within the OSSP that Rob would be our PTL going forward. I recognize that the community needs feedback to make these decisions, but I am in our IRC channel 5 days a week, at least 8 hours a day, and I have never seen any attempt to reach out to us in that medium. I wouldn't call it babysitting to make some reasonable attempt to meet us where we are instead of moralizing on the mailing list when we don't respond to OTHER postings on the same mailing list.
I believe kicking OSSP out of the big tent will have these results:
* The 5 individuals we have working full-time on Syntribos (http://stackalytics.com/?module=syntribos / https://github.com/openstack/syntribos) as part of OSIC may not be able to continue our arrangement if this project is not in the big tent. I can't speak for OSIC leadership on this point, but it is certainly a risk
* The OSSP has been losing members recently for various reasons not related to OpenStack politics. Removing us from the big tent will only accelerate this
* Projects like Bandit, Syntribos, and Anchor will atrophy without dedicated developer attention, representing a HUGE waste of developer resources and potential positive operator impact
* It will take longer to wrap up OSSA/OSSN/Threat Analysis for OpenStack projects if only the 4 members of the VMT are involved/invested
* I want to be clear: the VMT does very important work, and they are incredibly responsive for such a small team. Nonetheless, the numbers don't lie. We have more people working on one tool (Syntribos) than the entire group responsible for vulnerability management throughout all of OpenStack. Thankfully, we don't ONLY work on Syntribos - we attended the midcycle where we helped on OSSNs and the threat analysis for Barbican.
I would understand this reaction if we were a completely barren group that hadn't made any contributions to OpenStack in months, but to the contrary, we have been very active on a number of projects. In fact, my team (Syntribos) is testing OpenStack projects for security vulnerabilities at this very moment, and we have reported several recently.
I think this speaks just as much to a disconnect by the OpenStack community from our project, and I would turn your accusation of inactivity back on you. If you're completely unaware of the work we're doing, and unwilling to join our very active IRC channel to get in touch with us, is it not a bit hypocritical to accuse us of negligence for not consuming the entire firehose of the OpenStack Dev list?
Sincerely,
Charles Neill
From: Travis Mcpeak <tmcpeak at us.ibm.com<mailto:tmcpeak at us.ibm.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Date: Wednesday, September 21, 2016 at 11:23
To: "openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Subject: Re: [openstack-dev] [security] [salt] Removal of Security and OpenStackSalt project teams from the Big Tent
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.
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<mailto:openstack-dev-request at lists.openstack.org>
To: openstack-dev at lists.openstack.org<mailto: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<mailto: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<mailto:openstack-dev-request at lists.openstack.org>
You can reach the person managing the list at
openstack-dev-owner at lists.openstack.org<mailto: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<mailto:michal.dulko at intel.com>>
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev at lists.openstack.org<mailto: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<mailto: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> <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> <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<mailto: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<mailto:jun.zhongjun2 at gmail.com>>
To: openstack-dev <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Subject: [openstack-dev] [manila] Enable IPv6 in Manila Ocata
Message-ID:
<CAAz2tN-hrs_3d0HvavVvU2epHS4CCH1pko88FX1EGgUh8H9DfQ at mail.gmail.com<mailto: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<mailto:ifat.afek at nokia.com>>
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Subject: [openstack-dev] [vitrage] Barcelona design sessions
Message-ID: <CAD9E9DC-E55D-4BCC-BC8E-1CACDFFA7E09 at alcatel-lucent.com<mailto: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<mailto:louise.m.daly at intel.com>>
To: "openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>"
<openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Subject: [openstack-dev] [Kuryr] Kuryr IPVlan Code PoC
Message-ID:
<D2C06722FF4FE54C88729FC07A5DCD91B43469 at IRSMSX101.ger.corp.intel.com<mailto: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<mailto:rsblendido at suse.com>>
To: openstack-dev at lists.openstack.org<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto:skramaja at redhat.com>>
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev at lists.openstack.org<mailto: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<mailto: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<mailto: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<mailto:gfidente at redhat.com>>
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>, Emilien Macchi
<emacchi at redhat.com<mailto: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<mailto: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<mailto:thierry at openstack.org>>
To: OpenStack Development Mailing List
<openstack-dev at lists.openstack.org<mailto: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<mailto: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<mailto:thingee at gmail.com>>
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev at lists.openstack.org<mailto: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<mailto: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<mailto:thierry at openstack.org>>
To: openstack-dev at lists.openstack.org<mailto: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<mailto: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<mailto:amrith at tesora.com>>
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Subject: [openstack-dev] [ptl] code churn and questionable changes
Message-ID:
<CO2PR17MB0011672EBE3DD1B02AFF35ECA0F60 at CO2PR17MB0011.namprd17.prod.outlook.com<mailto: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>
------------------------------
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
End of OpenStack-dev Digest, Vol 53, Issue 51
*********************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160921/22651b5b/attachment-0001.html>
More information about the OpenStack-dev
mailing list