17:00:00 #startmeeting ironic 17:00:01 Meeting started Mon Aug 17 17:00:00 2015 UTC and is due to finish in 60 minutes. The chair is devananda. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:00:02 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:00:05 The meeting name has been set to 'ironic' 17:00:07 #chair NobodyCam 17:00:08 Current chairs: NobodyCam devananda 17:00:16 \o 17:00:17 morning all 17:00:19 o/ hi! 17:00:21 o/ 17:00:21 o/ 17:00:22 morning 17:00:25 o/ 17:00:28 as usual, the agenda is in the wiki 17:00:28 o/ 17:00:31 o/ 17:00:32 #link https://wiki.openstack.org/wiki/Meetings/Ironic 17:00:43 O/ 17:00:49 I'll try to keep each topic brief today so we can have plenty of time for open discussion / follow up from the midcycle 17:00:52 hi 17:00:54 o/ 17:00:57 o/ 17:01:05 o/ 17:01:08 \o 17:01:11 o/ 17:01:36 skipping announcements section since it's empty 17:01:46 :) 17:01:50 #topic subteam status reports 17:02:17 #link https://etherpad.openstack.org/p/IronicWhiteBoard 17:02:27 if you haven't already updated your subteam status, tracked at that ^ link, please do so now 17:03:01 there was a lot of work / progress on the neutron/ironic integration last week 17:03:21 many thanks to jroll, Sukhdev, and others for that 17:03:30 :) 17:03:34 it's coming along nicely 17:03:42 and thank you to all who attened the mid-cycle 17:03:45 hmm, dtantsur is on PTO. Are we in a hurry to get the ironic-lib stuff done? 17:03:57 rloo: yea, we kinda are. it's been blocking other things for a while 17:04:23 rloo: and we have a soft freeze on those files in ironic now 17:04:28 he's back wednesday 17:04:28 devananda: looks like there are two patches for ironic-lib dvsm testing. 17:04:29 also, jroll and I need to catch up with dhellmann soon to sort out releases 17:04:44 devananda: it's on my calendar to hit him up tomorrow 17:04:48 we tried last week but there's things in pip/pbr I dont understand 17:05:03 yeah, I think it's most good for a release right? 17:05:04 rloo: thanks 17:05:06 in a code POV 17:05:09 lucasagomes: yea 17:05:58 pshige_, jlvillal: any updates on docs? 17:05:58 is anyone familiar with tempest/devstack stuff, to continue Dmitry's patches? (Or we wait til Wed?) 17:06:01 lucasagomes: there's two patches right now to get dsvm running 17:06:05 and sfaizan has some patches (ready) for switching ironic to use ironic-lib when it's released 17:06:15 * lucasagomes checks the review list 17:06:28 lucasagomes: https://review.openstack.org/#/c/212491 https://review.openstack.org/#/c/212495/ 17:06:41 jroll: release ironic first, then switch to using ironic-lib, ya? 17:06:46 devananda: yes pls 17:06:47 devananda: Not from me. Was I supposed to do something on docs??? 17:06:48 jroll, thanks 17:06:59 devananda, ++ 17:07:12 rameshg87: do you have links to those patches? pls put on the etherpad 17:07:19 devananda: ack 17:07:20 * jlvillal trying to remember if he had a TODO item that he forgot about. 17:07:22 devananda: I expect by EOD tomorrow we'll be ready to release unless we see a major bug we want to fix first 17:07:38 jlvillal: oh, nope. I imagined it :) 17:07:44 * jlvillal Whew! 17:08:04 jlvillal: I thought you were going to reorganize our docs? 17:08:07 jlvillal: just kidding 17:08:12 lol 17:08:19 * jlvillal recovers from heart-attack.... :P 17:08:23 hehe 17:08:27 mrda: !! you're here :) 17:08:33 jetlag, eh? 17:08:45 devananda: I'm in SAT this week 17:08:50 ahh 17:08:55 well, welcome :) 17:09:08 anything to add to the nova/ironic section of the status report? 17:09:11 thanks - it'll be my last team meeting for a while due to TZ 17:09:36 mrda, :-( 17:09:37 devananda: Not really, we have some things to do, and jlvillal and I will update later today hopefully 17:09:49 k k 17:09:58 devananda: but I haven't had time to get anything done so far 17:10:19 mrda & jlvillal: please remind us if there are nova patches that ought to be reviewed that we want in before liberty deadline whenever that is 17:10:26 rloo: shall do 17:10:43 thx mrda 17:10:49 devananda: On Nova, we have mainly been catching back up as both mrda and I were out on vacation. There are two patches in the review queue. 17:11:03 rloo: nova is full-on feature freezed for L, bug fixes can land any time AIUI 17:11:26 But if people have patches to go into Nova, please ping mrda or jlvillal (me). So we can add them to the review queue. 17:11:40 yes please 17:11:55 We usually look for Nova bugs that are tagged as Ironic. And then look for patches off of those bugs. 17:12:15 good stuff, everyone - thanks for the updates! 17:12:27 anything else before we move on? (giving it another minute) 17:12:57 so we have OneView in the etherpad, but I don't htink the spec has been approved yet? 17:13:16 yeah not yet 17:13:23 #link https://review.openstack.org/#/c/187762/ 17:13:25 nope, not yet 17:13:25 hg87 :) 17:13:27 In fact, we're waiting for some reviews 17:13:37 any feedback is appreciated 17:13:47 * lucasagomes adds to his todo for tomorrow 17:13:49 oh -- actually, one more thing to add to the update list 17:14:12 jroll and I (and others) sat down and looked at both the approved and unapproved specs 17:14:18 compared to list of things we set out at beginning of the cycle 17:14:24 and did a major update to the priorities spreadsheet 17:14:30 #link https://docs.google.com/spreadsheets/d/1Hxyfy60hN_Fit0b-plsPzK6yW3ePQC5IfwuzJwltlbo 17:14:42 thanks devananda for the link 17:14:50 since LP doesn't give us any good way to group bp's by topic, we did that in google ... 17:14:56 oh nice one 17:15:06 * devananda waits for the mythical future when openstack will have a good tool for this 17:15:17 current priorities tab! 17:15:24 devananda: awesome (for updating priorities). Not good wrt all the stuff to do, sigh. 17:15:30 loads of changes to the driver interfaces O.O 17:16:02 rloo: it's more of a "here are all the things people seem to want to do" + "what major themes emerge" + "what's really important to everyone" 17:16:30 devananda: wrt state machine. should we add some item number about microversioning/client default versions blah blah. or did we decide how to handle enroll? 17:16:43 rloo: let's not discuss that now 17:16:46 One more thing about oneview, we're working to put a 3rd party CI to work when the code is merged, even if it runs just periodically due to hardware restrictions 17:17:06 thiagop: awesome! 17:17:08 30% done 17:17:17 ok, going to timebox this lest we run out of time for other things 17:17:20 thanks everyone for the updates! 17:17:22 thiagop, ++ awesome 17:17:26 devananda: don't want to discuss, just think it is high priority and not sure it is captured in the doc 17:17:35 thiagop: +1 on awesome :) 17:17:36 rloo: fair point 17:17:53 devananda: i don't think we can release liberty w/o resolving that 17:18:06 #topic scripts that do not fit into our current project repositories 17:18:09 NobodyCam: that's you 17:18:13 oh thats me 17:18:14 :) 17:18:37 we've have a couple of folks purpose utility type scripts, many are driver or vendor specific and 17:18:40 do not have a good location in the ironic tree. It was suggested that a solution to this would be 17:18:43 to have these scripts in their own repos, and a wiki type page could be created with links pointing 17:18:46 to these repos. I kinda like this as it allows the script creators to maintain them with out having to 17:18:49 bogged down by the entire Ironic review process, but they could still be "linked" to the ironic 17:18:52 project via the wiki page. 17:18:55 (sorry for large paste) 17:19:16 isn't that exactly the method we decided to move forward with in vancouver? 17:19:16 I like the idea of separate repo(s) outside of Ironic. 17:19:20 would like to hear what other folks think about this 17:19:38 jroll: maybe? but we haven't implemented it yet afaik, so it came back up at the midcycle 17:19:39 yeah seems fine to have a separated repo 17:19:43 I think we decided on a single utils repo in vancouver 17:19:56 I mean "many are drivers", drivers could easily live in our tree 17:20:04 devananda: what is there to implement about "make your own repo" and "put a link on our wiki page" 17:20:06 +1 for separate repos. I think in Vancouver there were 2 solutions and no decision. 17:20:07 sambetts: I recall a discussion around having a single "other utils" repo, but there are problems with that 17:20:11 If I remember correctly, the decision in vancouver was to come back to it, that there was no consensus then 17:20:15 * BadCub is again fashionably late 17:20:17 heh 17:20:21 like, who approves changes in it? what language is it in? how is it tested? 17:20:30 rloo: +1 17:20:36 would they be curated in anyway? Or just freeform? i.e. would there be an owner for each repo as to ensure some sort of consistency? 17:20:51 lucasagomes: Problem with drivers in our tree is that difficult for people to review hardware/vendor specific code 17:20:51 I'm not seeing this in the etherpad :( 17:20:51 jroll: the only thing for us to do: 1) agree on it 2) document the agreement in a wiki page 17:20:59 right 17:21:00 mrda: no curation 17:21:10 jlvillal, well we do it already right? 17:21:17 the wiki would indicate who, from that vendor (presumably) is the maintainer 17:21:17 I think we should use the neutron vendor decomp as a case study 17:21:22 s ironic--caveat-emptor as a repo name? 17:21:30 lucasagomes: Yeah, but is that a good thing or not? I'm not sure. 17:21:30 jlvillal, many of the vendor stuff can live in a separated library 17:21:32 s/s/so/ 17:21:32 in many cases not everyone will be able to test them asfolks may not have the HW to test 17:21:35 so the communit has a point of contact for issues in, essentially, third-party tools 17:21:38 like proliantutils 17:21:42 let's be clear here: this isn't driver code. this is utility scripts etc. 17:21:43 we aren't discussing the home of drivers. just other "stuff", right? 17:21:44 right? 17:21:47 much like several drivers have already created their own repos on stackforge or github 17:21:50 jroll: correct 17:21:56 Sorry, for off topic then. 17:21:58 rloo, jroll: correct 17:22:11 python enroll_hardware_from_acme_cmdb.py etc. 17:22:14 how would this work with "big tent" ie. no more stackforge 17:22:17 exactly 17:22:53 trown: so, frankly, I don't like the "no more stackforge" approach 17:22:53 as I said in vancouver, I think this should be completely outside of the ironic program, with the exception of links on our wiki. 17:23:01 jroll: +100 17:23:08 I don't care if your repo is in the openstack ecosystem or not 17:23:11 people that wants can use the 'openstack/' namespace instead of stackforge 17:23:14 make a repo. put it somewhere. 17:23:14 trown: you can have independantly released projects under the ironic statium 17:23:19 devananda: me neither...but it seems that is the direction 17:23:23 it's just not a "official" project 17:23:29 I'm good with separated repos 17:23:38 jroll: so if people put these tools in openstack/ then they will naturally propose that they be listed in openstack/governance/projects.yaml 17:23:41 +1 for separate repos and documenting on wiki 17:23:42 jroll: I'm fine with that, but is there an owner? I'm not sure it should be a free for all 17:23:44 and included in the ironic project 17:23:54 people can manage their own tools and edit the Ironic wiki to talk about it, no problem 17:23:59 jroll: +1 17:24:03 devananda: right, they should not be included in the ironic tree there. 17:24:08 jroll: right 17:24:19 So is it separate repos under openstack/ or just some repo on github.com? 17:24:25 jroll: devananda: yep that was my thinking too 17:24:26 I think everyone agrees with not in the ironic tree 17:24:44 I don't 17:24:45 mrda: I think a free for all is fine 17:24:55 ok, here's an example 17:24:57 https://github.com/rackerlabs/onmetal-scripts 17:25:03 "just some repo on github.com" is problematic as there is no access to the wealth of infra resources then 17:25:13 should that be in the ironic program? should ironic maintainers be responsible for that repo? 17:25:16 so, to have a wiki is a consensus? 17:25:26 isn't 'ironic tree' == git repo for 'ironic' code. vs 'ironic program' which includes ipa, inspector, bifrost... 17:25:31 the problem is just were to put the code? 17:25:41 example: https://review.openstack.org/#/c/158577/ 17:25:42 jroll: being under the ironic stadium doesn't mean that the ironic core team is invloved with it at all 17:25:44 thiagop: the problem is "who is responsible fo rmaintaining the code" 17:25:50 rloo: right, sorry 17:26:01 sambetts: it implies that the ironic team is responsible for it 17:26:09 * mrda just doesn't want to allow nefarious updates 17:26:12 sambetts: did we switch from umbrellas to stadiums? :) 17:26:13 sambetts: people will come to the ironic team when they have problems with it 17:26:19 How about allow both repos on github.com and under openstack/ Either is acceptable? 17:26:33 jlvillal++ (just not in the ironic program) 17:26:35 Just link to them from the wiki. 17:26:40 +++++ 17:26:41 i personally don't care where they put their stuff as long as i'm (ironic program) is not responsible for it 17:26:42 ++ 17:26:43 ++ 17:26:48 +1 17:26:49 jlvillal: that's what NobodyCam proposed at the opening of this topic :) 17:26:55 rloo: exactly 17:26:55 "if you make a repo, we'll link to it" 17:27:03 jroll: how does one create a openstack/ repo for an ironic based project that is not under the ironic program? 17:27:03 yep 17:27:12 jroll: or 'if you make a repo, you can link to it' 17:27:17 Our networking-cisco repo lives in the neutron statium but is completely independant, its only there to state its relevance to the project 17:27:17 trown: one does not 17:27:18 trown: I have no idea, they should ask infra 17:27:19 trown: ask infra 17:27:19 trown: did that this week 17:27:29 I think it's fair to have separated. Once the project is mature enough it can even be proposed to be part of the ironic umbrella 17:27:33 as others have done already 17:27:35 just don't add it to the governance stuff 17:27:36 but it needs time 17:28:05 Honestly, this may not be a project, it may just be "I have some helper scripts, the community could use them" 17:28:11 wait - thiagop - you created an openstack/* project related to ironic, but that is not intended to be part of the ironic project? 17:28:11 thiagop: oh, that's a good point. infra/tc/whatever doesn't have a problem with that? 17:28:16 thiagop: can you point me to the project-config review for that? 17:28:24 devananda: yep 17:28:55 devananda: it is openstack/python-oneviewclient 17:29:07 #link https://review.openstack.org/#/c/211301/ 17:29:10 so TheJulia brings us back to the topic at hand -- this isn't about pyhton libraries or UI frameworks or things like that -- it originally came up because the iLO team has some tooling they use, with iLO, to do mass discovery 17:29:21 trown: ^ 17:29:26 I dont know if it's even written in python 17:29:33 thiagop, thanks 17:29:38 #link https://review.openstack.org/#/c/158577 17:29:58 thiagop, gabriel-bezerra so that clearly should be part of hte ironic project in my opinion (once the spec is approved to implement that driver) 17:30:39 Which has occured again as other groups have indicated that they have something that is a helper script to do x or y specific task, but don't know what to do to help users who may find the items useful 17:30:42 devananda: I know, but once the community hasn't yet agreed on that, I proposed it that way 17:30:44 devananda: doesn't that go back to the goverances "Am I OpenStack?" thing? if it can live in openstack/* or not then 17:30:59 is an ansible module openstack? 17:31:04 and it can be a way out to the helper scripts too 17:31:07 (as an example) 17:31:11 TheJulia: it can be. see OSAD :) 17:31:15 devananda: off topic now, but it would be good to discuss which openstack/python-Xclients will fall under ironic program in the future. i'm concerned that for every vendor, we'll end up with such a client. 17:31:23 devananda: I knew you were going to respond with that :) 17:31:30 osad: \o/ 17:31:40 rloo: I was just checking projects.yaml and I agree -- it's not currently clear 17:31:51 proliantutils isn't listed there, but I think it should be 17:31:59 so getting back on topic 17:32:07 there are clearly things we don't want in the ironic umbrella 17:32:07 otoh, if OpenStack wants to rule the world, we can put all opensource code used by openstack under our tent 17:32:17 * devananda sets a timer for 5 more minutes on this topic 17:32:22 and an openstack repo can be made without putting under ironic umbrella 17:32:35 jroll: ++ 17:32:38 so I think we should advise vendors to make a repo on openstack or github, doesn't matter 17:32:43 and link to it from a wiki page 17:32:51 jroll: +1 17:33:01 jroll: +1 17:33:02 jroll: +1 17:33:06 who wants to write those docs? :) 17:33:14 (or wiki page) 17:33:15 jroll: write what docs? 17:33:21 jroll: ++, the ability to make a repo under openstack namespace but not under **any** umbrella is news to me 17:33:21 jroll: I think the way things are going, if it's in openstack/* namespace, the TC will want it to be associated with _some_ project team 17:33:24 seems fair... it's basically what was said before "create a repo and link on the wiki" "note you can create a repo under openstack/ if u wish" 17:33:29 trown: yea, news to me too 17:33:30 jroll: the wiki page part is easy. 17:33:31 rloo: the "here's what you should do for tools repos" 17:33:55 rloo: it could be a paragraph on the wiki, rather than docs or whatever 17:34:02 jroll: so two wikis: one for instructions on how, one that lists the 3rdparty/whatever stuff. 17:34:15 devananda trown I think it was after the depreciation of stackforge namespace 17:34:20 jroll: did we agree/vote on this? 17:34:22 devananda: if we have folks setup a repo, can they not "associate" to Ironic if the "thing" is meant to be used for Ironic? 17:34:22 Or one Wiki with both 17:34:23 devananda: maybe we should get that clarified, then, but today it's possible 17:34:28 jroll: (not the wiki part, the process) 17:34:39 rloo: I made a statement, I'm not seeing disagreement 17:34:43 ¯\_(ツ)_/¯ 17:34:44 I would also think many vendor type folk already a github repo like the rackerlabs one 17:34:54 BadCub: +1 17:34:59 jroll: yeah, but we're in a meeting. don't we have to vote? 17:35:08 BadCub: the question at hand is how to do that association so a) users can find it, but b) the ironic core team isn't expected to maintain vendor tools (which may not even be in python) 17:35:39 jroll: ++ to getting that clarified 17:35:43 and require spicific HW to test 17:35:47 rloo: sure, whatever, voting is fine 17:35:50 Should it be in the docs too? Or the links are only in the Wiki? 17:35:53 NobodyCam: right 17:35:54 Those are very good points to get clarified 17:36:00 * devananda doesn't feel the need to vote 17:36:06 jlvillal, I think only wiki is fine 17:36:17 +1 for wiki. 17:36:23 anyone volunteering to writing this in the wiki? 17:36:33 I will 17:36:36 * NobodyCam can take a stab at it 17:36:39 woo, thanks rameshg87 17:36:41 rameshg87: ty :) 17:36:42 or rameshg87 17:36:49 rameshg87: +1 :) 17:36:57 rameshg87: o/\o 17:37:03 :) 17:37:12 Thank you all! 17:37:13 * rameshg87 hasn't got this much cheer ever :) 17:37:23 lol 17:37:28 #action rameshg87 to wiki'fy the results of this discussion: vendors can create tool / utility repos without needing to put them under the "ironic" project umbrella, and should link from wiki page 17:37:32 thanks all! 17:37:40 thank you! 17:37:45 #topic patches adding copyright headers 17:37:51 hope this one to be fast... 17:37:59 I don't see naohiro here, so I'll proxy 17:38:04 can we just agree to email legal-discuss here 17:38:04 so we have this patch here https://review.openstack.org/212973 adding some copyright lines to their code 17:38:11 #link https://review.openstack.org/212973 17:38:31 IMHO I don't think it matters that much, but we don't have a consensus around it 17:38:34 I googled a bit, but didn't find it -- but there have been several discussions in -infra about this before 17:38:41 nobody present right now is going to have a definitive answer as to if this is ok. I'm fairly certain those headers aren't enforcable anyway. 17:38:42 lucasagomes: infra does have a policy here 17:38:51 devananda, not infra, it's legal 17:39:09 also, AFAIR some projects have decided not to have any copyright lines 17:39:12 there's a much bigger discussion around CLA / DCO / (C) headers -- some of which was wiki'd here: https://wiki.openstack.org/wiki/OpenStackAndItsCLA 17:39:23 but then that got caught up in board and TC meetings for a long time, and still isn't resolved 17:39:45 lucasagomes: it's not about legal. the CLA asserts the copyright on submission 17:39:48 at one time we were adding: # Copyright OpenStack Foundation headers 17:40:09 NobodyCam: you should never have added one of those -- sinc eyou were never, afaik, an employee of the openstaack foundation .... 17:40:14 nor should I ever have 17:40:21 devananda, right, yeah I know... but many of the code have copyright lines and we keep accepting it 17:40:28 Is the question whether we should allow those Copyright's? We already have code with them. 17:40:49 rloo: no - the question is whether we can allow them to be added after the fact 17:41:03 fujitsu submitted code w/o any (c) header, and it landed, and now they want to "correct" it 17:41:04 yeah can we add it after they are already submitted? 17:41:06 devananda: OH. that is different. No, I don't think so. 17:41:12 Some companies do demand it, rightly or wrongly, for newly created files. I think we should allow that, but not allow updates. 17:41:21 #action devananda to follow up with infra and/or legal team on this 17:41:29 is there a "chance" The foundation will require this copyright in the future, or do they even have the right to require it? 17:41:40 so as I understand it. those copyrights are meaningless. AFAIK we do it because we cargo cult the header. 17:41:51 It's all Apache licenced independent of copyright notices - but the copyright notice is a visual indication that it's not public domain code, that it is covered by an explicit licence 17:41:51 devananda++ 17:41:51 the CLA imputes it on code submission, based on the attribution of the patch author 17:41:53 jroll, ++ yeah they are meanless because we signed the CLA 17:41:54 (or is the definition of 'landed' -- when a release occurs) 17:42:07 so as far as openstack foundation legal is concerned, they aren't needed. 17:42:16 but some companies feel otherwise, thus we get them, and mostly don't care 17:42:23 rloo: no, commit accepted 17:42:36 devananda: ok, let's move on then. You've got your action item :) 17:42:40 ++ 17:42:40 anyway, time boxing at this point, but wanted everyone to be aware of the discussion and policy 17:42:48 +1, let's move on 17:42:54 #topic driver name length limit 17:43:01 another fast one 17:43:08 this one has no name on the agenda ... 17:43:10 #link https://review.openstack.org/#/c/209605/ 17:43:17 there's a patch changing the length of the name from 15 to 25 17:43:27 mine 17:43:39 but lucasagomes bringed that to us 17:43:44 is there any reason to continue to limit this artificially? if we proposed 255, what would be the objection? 17:43:51 while I think it's fine, do we have any consensus whether 25 is enough for the driver's name ? 17:43:58 imo we can make it longer and have no more problem's with it 17:43:59 25 might be too limited 17:44:05 jroll: the driver name is actually hte python entrypoint name 17:44:11 jroll: +1. I see no reason to limit it to 25 17:44:14 is there a limit on python entrypoint names? 17:44:15 +1, let's make it so we never have to deal with this again 17:44:16 broght* 17:44:22 devananda: good question, I doubt it but who knows 17:44:25 probably 79 :) 17:44:29 I think 25 is limited but equally think there should be a limit of some kind? 17:44:40 I don't care about the db field length (as long as it's < 256) 17:44:43 let's limit it to python entrypoint names then! 17:44:50 my only thought here is many folk nay not what to "node-create -d aReallyLongDriverNameGoesHere 17:44:55 * jroll googles about entrypoints 17:45:05 NobodyCam brings up a good point - usability is also a concern 17:45:11 255 might be a better choice, just so we don't have to revisit 17:45:12 this will be displayed in UI, typed on CLI, etc 17:45:12 imo reasonable value is 64 17:45:28 devananda: but the names have to be approved by the core-reviewers. 17:45:30 but I'm fine with the DB no longer imposing an arbitrarily small limit 17:45:32 yuriyz: more than in my option 17:45:45 and if someone wants to use MyReallyLongdriverNameThatNoOneWillEverType -- well, they can 17:45:51 right 17:45:57 setuptools doesn't seem to document a max length for entry points 17:45:58 Would it be sane an reasonable to set it to 100? I think it would be difficult for someone to come up with something longer, unless they are really, really creative 17:45:59 fwiw 17:46:07 ++ 17:46:08 jroll: cool 17:46:11 we could add a recommendation to use short names 17:46:12 +1 17:46:12 (assuming they can convince everyone in code review...) 17:46:18 ok 17:46:20 BadCub: 100 is even more arbitrary :) 17:46:27 alright, so everyone agrees 25 is too small? 17:46:31 lucasagomes: yes 17:46:33 +1 17:46:37 +1 17:46:37 yup 17:46:42 Yup 17:46:42 yup 17:46:43 +1 for 255 17:46:48 let's just decide on a number now before we bikeshed all over gerrit 17:46:48 I've heard two suggestions so far: 64 and 255 17:46:52