21:03:10 <ttx> #startmeeting project
21:03:11 <openstack> Meeting started Tue Apr  8 21:03:10 2014 UTC and is due to finish in 60 minutes.  The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:03:12 * russellb sheds a tear
21:03:13 * dhellmann sniffs
21:03:13 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:03:15 <openstack> The meeting name has been set to 'project'
21:03:18 * markwash couldn't get past the first chapter of Beloved
21:03:21 <ttx> #link http://wiki.openstack.org/Meetings/ProjectMeeting
21:03:31 <dhellmann> markwash: LOL
21:03:38 <ttx> #topic Current RC status
21:03:42 <hub_cap> markwash: i couldnt get past the title
21:03:48 <ttx> #info RC1 done, no RC2 expected at this point: Swift, Trove
21:03:57 <ttx> #info RC2 done, no RC3 expected at this point: Keystone, Cinder, Ceilometer, Horizon
21:04:04 <ttx> #info RC2 in progress: Glance, Nova, Neutron, Heat
21:04:20 <annegentle> markmc: ghosts
21:04:23 <stevebaker> \o
21:04:25 <ttx> We hope to have Nova and Neutron tomorrow, heat and Glance Thursday
21:04:39 <annegentle> er markwash :)
21:04:51 <ttx> It shall take a pretty significant regression or unforeseen fuckup to do a RC3
21:04:57 <ttx> but then, there always was
21:04:58 <annegentle> ttx: snort
21:05:36 * ttx puts $1 in the swear box
21:05:52 <ttx> Questions on the RC process ?
21:06:21 <ttx> FWIW the icehouse PTLs are not disappearing on Friday with election results
21:06:31 <russellb> go until final icehouse release yes?
21:06:33 * hub_cap suspects ttx's swear box is quite full
21:06:36 <ttx> They are the icehouse cycle PTLs, so they finish the work :P
21:06:42 <annegentle> ttx: is every project open for juno?
21:06:48 <ttx> annegentle: yes
21:07:23 <dolphm> and new PTL's effectively take over on master?
21:07:31 <dolphm> (Friday)
21:07:34 <ttx> dolphm: in theory yes
21:07:41 <dolphm> or at least, free to transition
21:07:44 <annegentle> #info Didn't really see many doc catchups in the feature freeze period
21:08:02 <annegentle> Seems like release notes are being worked
21:08:28 <hub_cap> ttx can u re-link the release notes page?
21:08:35 * hub_cap needs to get started w em
21:08:40 <ttx> #link https://wiki.openstack.org/wiki/ReleaseNotes/Icehouse
21:08:56 <markmcclain> annegentle: did you see the email I sent you?
21:09:11 <ttx> yes release notes seem to come up nicely
21:09:21 <ttx> anything else on that topic ?
21:10:02 <ttx> guess not
21:10:03 <hub_cap> thx ttx
21:10:07 <ttx> #topic Security audit of projects/releases
21:10:12 <ttx> nkinder: o/
21:10:19 <nkinder> Hi all.
21:10:27 * markwash looks nervous
21:10:36 <ttx> today of all days
21:10:41 <russellb> ttx: ha
21:10:54 <nkinder> I'm trying to get an effort going around gathering security related info for each project/release
21:10:55 <russellb> here to disclose openstackbleed?
21:11:11 <annegentle> markmcclain: sorry I need more context? I don't see one
21:11:28 <nkinder> this provides some background for later reading - http://lists.openstack.org/pipermail/openstack-dev/2014-April/032046.html
21:11:31 <ttx> #link Security audit of projects/releases
21:11:33 <ttx> arh
21:11:40 <ttx> #link http://lists.openstack.org/pipermail/openstack-dev/2014-April/032046.html
21:12:00 <nkinder> Basically, I'd like to capture commonly asked security info such as what crypto algorithms are used, what crypto implementations, and how sensitive data is handled.
21:12:11 <russellb> sounds like a good idea
21:12:19 <nkinder> Here is an example I put together for Keystone - https://wiki.openstack.org/wiki/Security/Icehouse/Keystone
21:12:30 <ttx> nkinder: so the challenge is to keep it current, I think
21:12:43 <nkinder> The idea is that each project dev team would be responsible for keeping it up to date.
21:12:51 <ttx> gathering it shall not be too hard, keeping up to date.. ;hmm
21:12:56 <nkinder> maintenance is definitely the big concern
21:12:56 <dolphm> ttx: ++ i'd love to have this in-tree, and kept up to date with the code
21:12:58 <devananda> nkinder: is there substantial interest in having this also for incubated projects (eg ironic)?
21:13:15 <nkinder> dolphm and I discussed it on the keystone meeting today, and there were some good ideas
21:13:17 <markwash> nkinder: not sure if this is actually on topic, but how can we promote better code / review practices for common security issues? I know as a reviewer I've missed some pretty obvious security problems just because I wasn't thinking like a security guy
21:13:24 <ttx> nkinder: if you have it in tree at least you can make sure one is not updated without the other
21:13:33 <ttx> could be some standard file
21:13:38 <annegentle> nkinder: so I did a brief analysis on the current ossn base, and always more than one project is affected due to the actual use cases
21:13:38 <dolphm> devananda: i think it will be expected of every project once a few have it
21:13:39 <nkinder> We're thinking keeping it in-tree would allow it to be kept up to date along with code changes
21:13:43 <hub_cap> markwash: s/like a security guy// ?
21:13:51 <dolphm> devananda: (expected by deployers, etc)
21:13:57 <russellb> markwash: if you tag a commit message with SecurityImpact, a message will go to the security list for the patch ... if you realize it has potential security impact, though
21:14:04 <devananda> dolphm: seems like a fair assumption, yea
21:14:12 <hub_cap> russellb: thx for the tip, i didnt know that
21:14:19 <markwash> hub_cap: sure
21:14:21 <annegentle> nkinder: so I'm not sure in-tree would work well from a deployer standpoint
21:14:41 <nkinder> annegentle: no, it would only work best for developers in-tree.
21:14:44 <ttx> in-tree would help, but it's no magic bullet. The issue is that oftentimes people touch things they don't know has security implications
21:14:56 <ttx> and sometimes it flies through review
21:14:57 <russellb> this sounds like docs that we should just start encouraging, and eventually expecting from every project
21:14:59 <annegentle> nkinder: right but I don't think we should serve devs easy livin' :)
21:15:05 <nkinder> It would need to be transformed and published somewhere for deployers.
21:15:18 <comstud> markwash: solution: always think like a 'security guy'
21:15:25 <ttx> years of looking at CVE patches make me a little pessimistic about human nature
21:15:27 <annegentle> nkinder: sure, but again, individual projects need to think more cross-project
21:15:32 <nkinder> ttx: that is definitely a concern as well, and diligence by core members would be needed
21:15:35 <annegentle> nkinder: and in-tree doesn't encourage that
21:15:50 <markwash> comstud: lol I suppose I'm trying?
21:15:53 <russellb> a wiki page seems like the most reasonable place to doucment this stuff ... Nova/SecurityInfo, and expect it to be updated like we have Nova/HypervisorSupportMatrix
21:15:56 <comstud> try harder!
21:15:59 <dhellmann> annegentle: +1 to thinking cross-project :-)
21:16:42 <nkinder> annegentle: agreed.  At least for the used crypto sorts of items, they are isolated to individual projects.  It's the interaction between projects around sensitive data that requires more cross-project thinking.
21:17:19 <notmyname> nkinder: indeed
21:17:21 <ttx> nkinder: I think wiki + project resposnsibility to keep up to date + external audits pointing out gaps, could work
21:17:25 <nkinder> Part of doing this at an individual project level is also to identify overlap and inconsistencies between projects, which can be used to push towards further cross-project coordination.
21:18:07 <annegentle> nkinder: yes we haven't really considered the crypto case til now but then would barbican be the responsible party (similar to keystone's commonality)? Or maybe I'm thinking wrongly?
21:18:09 <dolphm> would we want to have one page for all of Openstack then?
21:18:17 <markmcclain> ttx: was thinking that we might consider making this part of PTL duties to ensure that doc is updated for each milestone
21:18:34 <nkinder> annegentle: documenting crypto for barbican will absolutely be important (and I want to reach out to them early)
21:18:35 <dhellmann> dolphm: one page per release would make sense
21:18:49 <nkinder> markmcclain: that was my hope too
21:18:50 <ttx> markmcclain: yes, those slackers could use a bit more responsibilities :)
21:18:51 <russellb> ttx: +1
21:18:55 <dolphm> dhellmann: this *should* be mostly static
21:19:00 <russellb> to the earlier comment, not slackers comment
21:19:02 <dolphm> dhellmann: it shouldn't change dramatically per release
21:19:14 <dhellmann> dolphm: you've seen all the new projects, right? :-)
21:19:14 <dolphm> it just needs to be maintained regularly
21:19:14 <nkinder> russellb: easy for you to say, you're stepping down! :P
21:19:24 <annegentle> heh
21:19:31 <russellb> i say it with the understanding of PTL responsibilities
21:19:35 <russellb> and what i think is reasonable
21:19:41 <russellb> for Nova, it wouldn't get done alone
21:19:43 <russellb> it's "ensure it gets done"
21:19:54 <dhellmann> delegate
21:19:55 <ttx> nkinder: so i would engage with projects to encourage them to provide that info based on the model you provided, and ask them to keep current. the OSSG should run regular audits to check that the info is maintained up to date
21:20:32 <nkinder> ttx: Great, that is my plan.  I wanted to float it by the PTLs here to gauge interest first.  It seems that the interest is there, so now it's working out the details.
21:20:42 <russellb> +1!
21:20:47 <russellb> nkinder: totally see the value in this
21:20:51 <dhellmann> +1
21:20:59 <ttx> nkinder: and thx a lot for all the work you've been doing on this and the OSSNs
21:21:02 <nkinder> I'd like to start with a few projects.  Keystone is already started, so maybe 2-3 more to pilot this?
21:21:16 <annegentle> nkinder: yes thanks for the efforts!
21:21:25 <nkinder> Sure.  Happy to help!
21:21:32 <markmcclain> nkinder: I'd be happy to pilot
21:21:53 <nkinder> markmcclain: ok, great!  Any others?
21:22:13 <russellb> ask next week with new PTLs here :)
21:22:22 <ttx> yeah, should be easier
21:22:39 <nkinder> good point
21:22:55 <ttx> ok, next topic
21:22:59 <ttx> #topic Red Flags
21:23:25 <ttx> Anything that will ruin the release next week that I should know about ?
21:23:47 <russellb> if only we knew now
21:24:13 <ttx> well, last week we uncovered the DB upgrades & the translations fail
21:24:22 <ttx> So I'm going fishing again
21:24:36 * dhellmann was picturing ttx with a crystal ball
21:24:40 <russellb> i think ubuntu broke qemu
21:24:49 <russellb> but that's not really an openstack problem, exactly
21:25:09 <ttx> hmm :)
21:25:17 <russellb> ttx: the bug targeted against nova's rc2 turned out to be qemu in ubuntu
21:25:30 <ttx> russellb: will they fix it ?
21:25:39 <annegentle> ttx: do you want some packaging problems install testing uncovered?
21:25:40 <russellb> dunno, but i believe maintainer was emailed directly about it
21:26:10 <ttx> annegentle: hmm... maybe ? define packaging problems install testing
21:26:13 <annegentle> ttx: https://bugs.launchpad.net/openstack-manuals/+bug/1297140
21:26:15 <uvirtbot> Launchpad bug 1297140 in heat "Ubuntu 12.04 (LTS)  - icehouse - heat packaging issues" [Undecided,Confirmed]
21:26:30 <ttx> oh, packaging issues
21:26:33 <ttx> well, no
21:26:41 <ttx> previous job. Done with that
21:26:49 <annegentle> ttx: heh ok, that one's on its way to fixed anyway
21:27:00 <annegentle> ttx: we are uncovering config naming hiccups
21:27:01 <russellb> looks fixed already, nice ... https://bugs.launchpad.net/nova/+bug/1304107
21:27:04 <uvirtbot> Launchpad bug 1304107 in qemu "Libvirt error launching instance - Device 'virtio-net-pci' could not be initialized" [High,Fix released]
21:27:06 <annegentle> securitygroups
21:27:30 <annegentle> er security_group v. securitygroup
21:27:34 <dolphm> this might only impact keystone because we removed keystone.openstack.common.rpc after switching to oslo.notifications but we realized today that rpc_backend options otherwise lose backwards compat when migrating from havana to icehouse http://www.mail-archive.com/openstack-dev@lists.openstack.org/msg21326.html
21:28:50 <ttx> dolphm: sounds like something to document in release notes ?
21:29:05 <annegentle> and we're all bracing for the onslaught of utf-8 questions
21:29:10 <dolphm> ttx: at least for keystone, that's what i'm thinking (an uggrade note or known issue)
21:29:26 <ttx> annegentle: security_group v. securitygroup : release notes material ?
21:29:39 <dolphm> (given that we emitted notifications for the first time in havana, but didn't have any consumers)
21:29:51 <ttx> OK, all in all, we don't seem to be in too bad of a shape
21:30:09 <ttx> we shall be mostly frozen EOD Thursday
21:30:37 <ttx> and become conservative in what we consider release-critical
21:30:45 <annegentle> ttx: this bug fix helped with security_group v. securitygroup https://bugs.launchpad.net/neutron/+bug/1304105
21:30:46 <ttx> anything else on that topic ?
21:30:47 <uvirtbot> Launchpad bug 1304105 in neutron "Section name [security_group] is wrong in sample config files" [Critical,Fix released]
21:31:04 <ttx> ok, RC2 soon
21:31:25 <ttx> #topic Incubated projects
21:31:34 <SergeyLukjanov> ttx, o/
21:31:38 <ttx> devananda, SergeyLukjanov, kgriffs|afk o/
21:31:54 <annegentle> related to Incubated projects, I recommend that each write their own release notes on the wiki using Key New Features, Significant bugs fixed, Known Issues, Upgrade Notes sections
21:32:09 <devananda> ttx: o/
21:32:14 <ttx> SergeyLukjanov: https://launchpad.net/sahara/+milestone/icehouse-rc2
21:32:19 <SergeyLukjanov> ttx, sahara rc2 is planned to Thu
21:32:19 <annegentle> page pattern like: http://wiki.openstack.org/wiki/<projectname>/ReleaseNotes/Icehouse
21:32:26 <SergeyLukjanov> annegentle, will do
21:32:33 <devananda> annegentle: ack, will do this week
21:32:35 <annegentle> SergeyLukjanov: thanks
21:32:41 <annegentle> thanks devananda for asking
21:33:07 <ttx> SergeyLukjanov: I'm surprised you don't have more FixReleased in that list, since you've been backporting stuff
21:33:29 * ttx investigates
21:33:40 <SergeyLukjanov> ttx, looks like my bad
21:34:02 <SergeyLukjanov> ttx, I've moved some from fix released to fix committed due to the rc2 is not released
21:34:11 <SergeyLukjanov> ttx, is it incorrect?
21:34:16 <ttx> Hah! it is
21:34:20 <ttx> So.
21:34:28 <ttx> FixCommitted means "fixed in master"
21:34:39 <ttx> FixReleased means "fixed in milestone-proposed"
21:34:47 <ttx> taht's our only way to track that in LP
21:34:57 <dolphm> this was confusing to me too ^
21:34:59 <ttx> so here is how we play
21:35:10 <dolphm> surprising, anyway
21:35:12 <devananda> hmm, yea, that's not what i expected
21:35:23 <SergeyLukjanov> ttx, oh...,
21:35:24 <ttx> You only approve the backport to RC2 for stuff that is targeted to RC2 AND fixed in master (FixCommitted)
21:35:25 <devananda> ttx: fwiw, we have two bugs identified as backport potential
21:35:44 <ttx> that way you make sure your fix is in both branches
21:35:46 <SergeyLukjanov> ttx, so, I'm moving all of them to Fix Release :)
21:35:51 <ttx> probably
21:36:00 <SergeyLukjanov> ttx, yup, all of them merged to master first
21:36:00 <ttx> SergeyLukjanov: and always have a bug for each backport
21:36:19 <devananda> ttx: though the proposed fix for one of them is a) non-trivial plumbing change and b) only a partial backport of the much larger change proposed for juno
21:36:27 <ttx> SergeyLukjanov: LP will automatically set "FixReleased" if the bug merges to milestone-proposed
21:36:58 <ttx> SergeyLukjanov: is it clear now or do you ned more explanation ? I know it's confusing
21:37:13 <ttx> so the process is:
21:37:15 <SergeyLukjanov> ttx, ok, so, I'll update them to Fix Released and ensure that all backported changes have an issue or backing blueprint
21:37:18 <ttx> - target to RC2
21:37:23 <ttx> - get the bug fixed in master
21:37:30 <ttx> (it moves to FixCommitted)
21:37:36 <ttx> - backport it to milestone-proposed
21:37:44 <ttx> (it moves to FixReleased)
21:37:53 <SergeyLukjanov> ttx, the only unclear thing for me was "Fix Released", thanks for detailed explanation
21:38:01 <ttx> then you use the milestone page to track progress to RC
21:38:14 <ttx> SergeyLukjanov: i'll let you fix status so that it matches reality
21:38:20 <ttx> devananda: o/
21:38:54 <devananda> ttx: hi!
21:38:59 <ttx> devananda: you're in full control of what ends up in icehouse release for ironic :)
21:39:15 <ttx> whatever you feel comfortable with, you can push to release branch
21:39:29 <ttx> by design, it can't wreck the other projects since you're not integrated yet
21:39:45 <devananda> ttx: ok. i've been avoiding large changes late in the cycle, in part because there are folks tracking us
21:40:00 <devananda> ttx: and in part to get us used to the process / cadence
21:40:02 <ttx> devananda: yes, that's not really a license to kill either
21:40:07 <devananda> right :)
21:40:17 <devananda> so my question here, w.r.t. backports, is
21:40:33 <ttx> devananda: but I just don't have the bandwidth to look into the incubated changes to check their risk/benefit ratio
21:40:41 <devananda> fair enough
21:40:53 <ttx> but i can give you advice if you need it
21:40:55 <devananda> but any guidance on that is helpful :)
21:40:58 <SergeyLukjanov> ttx, statuses fixed
21:40:58 <ttx> ok
21:41:26 * ttx likes how LP redirects transparently savanna to sahara
21:41:45 <SergeyLukjanov> ttx, yup, it works smoothly
21:41:53 <SergeyLukjanov> we need such feature in storyboard too :)
21:42:04 <ttx> SergeyLukjanov: so 1302130 needs to be backported, and 1302755 1304100 first need to be fixed in master. Is that correct ?
21:42:28 <SergeyLukjanov> ttx, yup
21:42:31 <ttx> devananda: if you have a specific doubt I can help address, just point me to it
21:42:43 * devananda gets the link
21:43:28 <devananda> ttx: https://bugs.launchpad.net/ironic/+bug/1297925
21:43:29 <uvirtbot> Launchpad bug 1297925 in ironic "Disk partitioning is broken if swap >= 1024mb" [Critical,In progress]
21:43:46 <ttx> that happens. swap >= 1024mb
21:44:26 <devananda> ttx: the proposed quick-fix is to s/sfdisk/parted/
21:44:53 <devananda> but as we've been testing with one, not the other, it's hard for me to quantify the impact of that change this late
21:45:45 <ttx> devananda: ok -- so let's imagine hat was integrated
21:45:53 <ttx> +t
21:46:12 <ttx> that fix wouldn't be possible post-releasesince it fails stable patch acceptance to change behavior/deps/etc
21:46:34 <ttx> does it impact doc or is it completely under the hood ?
21:47:12 <devananda> under the hood
21:47:31 <devananda> both sfdisk and parted are present on current ubuntu dists, and afaik, same goes for RH
21:47:37 <ttx> devananda: ok... so you have two options: document the limitation in release notes, or just do all the testing you can and push the change to users asap
21:47:40 <ttx> (rc2)
21:47:58 <devananda> right -- i'd prefer option 2
21:47:59 <ttx> all depends how acceptable the "limitation" is
21:48:17 <ttx> if ironic is useless without it, well option 2 it is
21:48:49 <devananda> not useless -- but hamstrung for deploying on large bare metal systems
21:48:55 <devananda> where swap ~ RAM is expected
21:49:11 <ttx> frankly, given your state, it's a nobrainer, do it
21:49:18 <devananda> ack
21:49:20 <ttx> you want something usable and you can accept the risk
21:49:34 <devananda> great, will push it today
21:49:37 <devananda> thanks!
21:50:00 <devananda> I really appreciate the walk through the process :)
21:50:49 <ttx> devananda: not that in theory you'll need the fix to go in master first
21:51:07 <ttx> devananda: before you backport (part of) it
21:51:11 <devananda> does the backport need to be nearly the same code?
21:51:12 <devananda> right
21:51:18 <ttx> not necessarily
21:51:20 <devananda> so there's a much larger feature proposed to fix it in master
21:51:24 <devananda> and a small one as a backport
21:51:27 <ttx> it's the safeguard to make sure we don't regress from MP to master
21:51:33 <devananda> k
21:52:13 <ttx> you could push the simple patch to master and then the refactor can overwrite it
21:52:16 <SergeyLukjanov> ttx, I like this idea of safeguarding
21:52:54 <ttx> the two rules of milestone-proposed are: bug must be fixed (or not exist) in master
21:53:09 <ttx> and bug must be targeted to the relevant RC milestone
21:53:27 <SergeyLukjanov> ttx, btw, I've created m-p branches for the rest sahara repos as we agreed to release them like I do it before (with 2014.1 tag)
21:53:36 <ttx> ok
21:53:59 <ttx> devananda: want me to add the rc2 milestone for you ?
21:54:12 <devananda> ttx: I just created it, thx
21:54:39 <ttx> devananda: ok, just send me an email (or ping on IRC) when you need the tag pushed / tarball uploaded
21:55:32 <devananda> ttx: ack. thanks
21:56:04 <ttx> devananda: if the "much larger feature proposed to fix it in master" gets delayed I would advise you push a simple version of it first so that the backport can be safely pushed to mp
21:57:52 <ttx> #topic Open discussion
21:57:56 <ttx> Anything, anyone ?
21:57:58 <ttx> #endmeeting