20:01:31 #startmeeting tc 20:01:32 Meeting started Tue Sep 9 20:01:31 2014 UTC and is due to finish in 60 minutes. The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:01:33 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:01:36 The meeting name has been set to 'tc' 20:01:41 Our agenda for today: 20:01:46 #link https://wiki.openstack.org/wiki/Governance/TechnicalCommittee 20:01:57 #topic Graduation review: Zaqar (ex-Marconi) (final decision?) 20:02:01 o/ 20:02:08 So this is the continuation of last week's meeting 20:02:13 I believe sdague planned to be here, but i may have made him a bit late by chatting earlier 20:02:14 o/ 20:02:17 We have a review up for it now: 20:02:23 #link https://review.openstack.org/118592 20:02:30 there was also a thread on the ML @ 20:02:36 #link http://lists.openstack.org/pipermail/openstack-dev/2014-September/044845.html 20:02:50 * mordred may have sent an email to that thread 1 hour ago 20:02:55 A few things are pretty clear now: 20:02:59 this is more a simple queue/messaging service than a full-featured queue provisioning service 20:03:01 * mordred apologizes for being late to the game 20:03:10 So more MagnetoDB than Trove 20:03:23 And it's also clear that we need to have a clear discussion (probably after the TC membership refresh) on layers, and that Zaqar would belong to an outer layer (with Trove and Sahara, for example) 20:03:40 I do not concede that point in this context 20:03:42 But any new structure we decide early in Kilo would reasonably start to kick in for the L release 20:03:56 So the remaining question seems to be -- should we accept another integrated project in Kilo, /before/ we change the structure for L and beyond 20:04:25 mordred: I haven't read your latest post, though 20:04:27 I would like to say that I'm a little sad that the discussion devolved into yet another meta discussion around project structure and taxonomy 20:04:30 so my summary may be partial 20:04:33 while I love discussing that 20:04:36 * dhellmann pauses to read mordred's email 20:04:54 I think it's a real disservice to zaqar to try to have a meta discussion instead of having the actual discussion 20:04:59 mordred: FWIW, thanks for bringing the discussion back to the project 20:05:47 o/ 20:05:51 I would much rather say yes or no to zaqar for reasons having to do with actual fitness than to say "sorry, we're going to discsuss how we discuss things more" 20:05:57 but that may just be me 20:06:02 ttx: i have strong opinions on the small-tent-big-ecosystem discussion and would like us to prioritize addressing that in paris 20:06:16 devananda: yes. I think we shoudl have that discussion for sure 20:06:24 I'm feeling like zaqar should be given a "blinders on" assessment -- laser focus on the project itself with the governance we have now 20:06:51 darn, lost kgriffs 20:06:54 should not all projects get that treatment 20:07:06 NobodyCam: at this point in this time yes 20:07:36 annegentle_: ++ 20:07:36 o/ 20:07:41 ok, caught up with mordred's email. So you're saying it still invents more than it should 20:07:47 +1 annegentle_ 20:07:50 * annegentle_ goes to read as well 20:07:55 whatever the "should" definition is 20:07:59 annegentle_: so I'm not sure how to do that actually, it seems really weird to define what is OpenStack as a whole by looking at it through a soda straw. Which seems odd to me. 20:08:04 ttx: potentially. I would like to know what it's actually aspring to be 20:08:06 mordred: i agree that feels unfair to zaqar. otoh, I don't agree that setting aside the big picture is helpful for us 20:08:28 mordred: it feels unfair because the timing of the two discussions is unfortunate, not because anyone is trying to be unfair 20:08:56 OK, so we agree that we say yes or no, not based on timing and potential future governance change, but on what we have now 20:09:16 Agreed 20:09:21 mordred: Zaqar aims to be a multi-tenant cloud messaging service. That's the shortest thing I can come up with 20:09:27 ttx: +1 20:09:37 ttx: also, are we deciding based on the integration checklist (maturity of QA, docs, community, etc) or based on technical merit of the project itself? 20:09:49 devananda: both? 20:09:51 devananda: both, right? 20:09:57 mordred: to that we can add more use-cases, features or whatever 20:10:00 the checklist is the minimum requirements that are consensual 20:10:03 devananda: both, has to be on technical merit plus the checklist 20:10:03 but that's the short description of it 20:10:11 k, good 20:10:17 flaper87: can you speak to which of the straw-man comparisons I made it wants to be more like? or is that an invalid premise? 20:10:19 technicla merit is, as we'll see when it comes to vote, much less consensual 20:10:34 ttx: indeed 20:10:43 mordred: as one of the biggest cloud users, is it just that you don't have a use case? or that as a cloud consumer you'd prefer another technical solution? 20:11:13 flaper87: fwiw, I maintain my objection to the store-and-retrieve model, and to fetch-by-id. neither of these fall within the domain of queueing 20:11:29 [ timeboxing this to 30min, if it takes more, it's back next week ] 20:11:30 flaper87: aiui, you're planning to remove those in the /v2/ API maybe? 20:11:34 mordred: probably SMTP/IMAP ? I really had quite a hard time parsing them all so I may probably be saying something wrong. 20:11:43 devananda: that's the plan, yest (fetch-by-id) 20:11:53 store-and-retrieve will remain 20:11:56 devananda: this is why I'm poking - if they are not a queue, then this whole thing is quite a bit different 20:12:10 mordred: right. it's not a queue as far as I can tell, and never was 20:12:19 devananda: why isn't in a queue? 20:12:22 devananda: it sounds like what they actually are is a message service that's easier in comparison to model by thinking of email 20:12:24 mordred: but the discussion of the v2 API is at least going towards beign a queue 20:12:36 by removing the random access 20:12:42 flaper87: random access is not a queue 20:12:53 devananda: ok, take that off. Why is it not a queue? 20:13:48 flaper87: in your data store internally, are messages identified by a sequential value, or a random number / UUID ? 20:14:01 mordred: so to summarize your objection, you think zaqar is reinventing something that doesn't need to be reinvented? 20:14:14 devananda: both, how is that relevant? 20:14:23 flaper87: random access is nto a queue 20:14:24 mordred: or just that you would like the use case precised? 20:14:33 ttx: potentially, yes. but I still think we're all at a lack of fundamental clarity on what it wants to be, which makes judging whether it's reinventing a wheel harder 20:14:51 flaper87: how your data model represents the data that zaqar is handling informs the type of service that I think it is 20:14:53 ttx: depending on what it wants to be, I may think that it's reinventing a wheel and will never be successful no matter what they do 20:15:04 mordred, in last meeting and in the mailing list we mentioned that Zaqar aims to provide a service similar to SQS 20:15:04 ttx: other things they are trying to be are thigns they could be very successful at 20:15:07 mordred: hmm, ok 20:15:12 devananda: I completely disagre with that 20:15:17 if zaqar's data structure is designed for random read/write access, it's not a queue 20:15:25 vkmc: please humor me and assume I know nothing about Amazon's product line 20:15:30 devananda: it's not designed for random access 20:15:36 random access just happened to be there 20:15:46 huh 20:17:13 ttx: basically, there are people who I respect who like what zaqar is trying to do, which makes me think I misunderstand the intent and therefore am judging by invalid criteria 20:17:14 mordred, sure thing, there are several differences with other queing systems but maybe the most important (I don't want to expand on this since we don't have much time) is that we are providing persistent storage and high availability 20:17:34 maybe the thing that's wrong is the mission statement, maybe that should be "message delivery API and service" instead of "message queueing API and service"? 20:17:43 dhellman_: ++ 20:17:45 dhellmann: ++ 20:17:56 it seems like that more clearly describes what zaqar (wow, hard to type) is trying to be 20:18:06 +1 dhellman_ 20:18:30 s/dhellman_/dhellmann 20:18:31 flaper87, do you agree with that? 20:18:32 I think "queueing" is a bit of an abuse in terms, mostly driven because SQS has Q in it 20:18:48 dhellmann: +1 20:18:56 we actually took queuing out of the deffinition 20:18:57 right 20:19:02 cool 20:19:03 that's something that confused people last time 20:19:12 ok, it's still there in reference/programs.yaml 20:19:16 The wiki says: "Zaqar is a multi-tenant cloud messaging service for web developers" 20:19:21 dhellmann: that's our bad, then. 20:19:35 yeah, not a big deal, I think we can change both things at once 20:19:36 mordred: if we start with "message delivery API and service", would that hit your NIH detector? 20:19:52 flaper87: that resolves my objection to it not being a queue. but then ^ 20:19:54 i.e. do you think it should be built on top of IMAP/POP servers ? 20:19:55 ok. so, then in that case, it does seem to be closer in design to jabber or email than to rabbit, yeah? 20:20:20 it never intended to be close to rabbit, FWIW. 20:20:24 we still have all of the questions about whether they should have just used an imap server or whatever, but I think it eliminates the tendency to map it to oslo.messaging 20:20:33 The AMQP experiment was just that, an experiment to rely on an existing queuing technology 20:20:44 dhellmann: ++ 20:20:46 but taht went wrong and we shared our findings 20:21:05 in that case, can someone explain, briefly, why it is that doing message delivery is something that cannot be done within the context of technologies we already use for other projects in openstack? 20:21:25 mordred: because it's for apps built on the cloud not the cloud itself 20:21:38 and I harp on that mainly because my understanding of the need for a new tech stack was that the characteristics that were trying to be achieved were clsoer in model to rabbit 20:21:40 and so they could theoretically build a postfix/dovecot driver, but I don't think we would want to say they should *only* have that, wouild we? 20:21:57 dhellmann: right. or an exim/cyrus driver 20:21:58 it's the desire for a web api for this sort of thing, right? 20:22:03 mordred: pick your flavor 20:22:11 or a mysql driver that's completely scalable 20:22:25 mordred: anything actually 20:22:28 this sort of thing stored in RDBMS is a long understood and long solved problem is what I'm getting at 20:22:35 It's possible to build storage driver for whatever people want but we also have to consider performance and what not 20:22:39 dhellmann: it's not so much a question of dictating what they implement, as it is of deciding if what they've implemented is something essential/core to OpenStack 20:23:00 flaper87: scaling out RDBMS (eg, mysql) is a really well understood problem space 20:23:05 mordred: what are you getting it ? That NoSQL shouldn't be necessary ? 20:23:08 yes 20:23:09 flaper87: saying that you can't use an RDBMS because it doesn't scale is .... interesting 20:23:10 funny, because the feedback they got last cycle was that an RDBMS was completely inappropriate for this sort of thing -- was that because we didn't understand what "this sort of thing" was? 20:23:17 gettig at* 20:23:20 wendar: sure 20:23:24 devananda: I wasn't talking about RDBMS 20:23:26 dhellmann: yes 20:23:27 I was talking about IMAP 20:23:35 or smtp 20:23:37 or whatever 20:23:48 dhellmann: yes. an RDBMS is inappropriate for a queue. it's fine for storing messages. 20:24:05 flaper87: oh. you're saying email is not performant or webscale? 20:24:10 flaper87: i'm confused 20:24:30 flaper87: I thought last cycle ya'll turned away from the sqla driver because of performance reasons 20:24:39 devananda: I never said it is *not* performant, I said that those things have to be taken under consideration 20:24:48 mordred: because then we are back to the SQLA driver... it exists after all. Not sure that condems Zaqar architecture 20:25:26 wendar: re: "is essential to OpenStack" is the scope / small-tent-big-ecosystem discussion. I think we're trynig to avoid that right now 20:25:29 flaper87: what "features" or aspects of the current API would you expect to have to drop to make the SQL driver perform well for the remaining "message delivery" use cases? 20:25:45 would my smartphone send my smartring an email to remind me I didn't close my smartgaragedoor? 20:25:58 annegentle_: why not? 20:26:29 no spoilers for the apple release, please, I haven't watched yet 20:26:30 annegentle_: if every smartdevice had a smartemailaddress, what's the problem with scaling that? 20:26:48 devananda: because my garage door doesn't have an email server? 20:26:50 OK.. I think we can't close this one today.... the new questions raised by mordred were raised too late to be addressed on the ML before this meeting 20:26:50 annegentle_: I'm hard pressed to think of any other messaging service that is as well understood, widely deployed, or handles as much traffic today 20:26:50 devananda: yes, without defining what "essential" means it's fuzzy, but the call is still "should Zaqar be integrated?" for some values of "integrated" 20:26:58 * NobodyCam is now lost as nothing in email guarantees order of delivery 20:27:03 so I think we need another round of ML discussion 20:27:05 dhellmann: we're likely going to drop support for random-access but other than that, I don't think we should be dropping anything. 20:27:31 sending questions one hour before meeting feels like a trap to me 20:27:40 flaper87: and do you think that an SQL driver could be built to meet those use cases and perform well at the same time? 20:27:44 ttx: sorry - wasn't intentional 20:27:59 yeah, I think it's clear we need to carry this over another week 20:28:01 flaper87: it sounds like you are moving towards being more queue-like 20:28:08 dhellmann: the sql driver exists already, we marked it as deprecated because of the concerns raised last time. 20:28:10 mordred: just saying we just can't close that one, we need solidly-built arguments and rebuttals 20:28:21 can it be improved? It certainly can 20:28:21 and IRC is not the best medium for that, especially in 10 min utes time 20:28:33 so I'd like to defer this to next week and address ironic now 20:28:40 unless someone disagrees 20:28:41 flaper87: right, and it sounds like maybe those concerns are being retracted with new understanding so I'm curious about whether that driver could be re-instated 20:28:47 and thinks we can resolve that one in-meeting 20:29:14 flaper87: right. what dhellman said - I think we've been judging zaqar against the wrong criteria 20:29:32 and I think it's worth stewing on in a new light for a little bit to see if that makes people more happier 20:29:39 to be fair it was always presented like a queue 20:29:42 * jaypipes reads back.. 20:30:11 ok, let's move to next topic and push discussion to ML and final decision to next week meeting 20:30:11 ttx: that's my recollection as well. this is the first time I recall hearing that it's not a queue 20:30:16 ttx: in fairness there was also low attendance last week with it being a short / holiday week in the us 20:30:17 dhellmann: it could, yes. 20:30:29 flaper87: ok, that's a good data point 20:30:32 sdague: that doesn't prevent posting the questions last week. 20:30:42 yes I think we all saw queue for a while 20:30:50 FWIW, we started talking about it as a messaging service since right after the failed graduation meeting 20:30:58 and that's how we've been presenting it ever since 20:31:00 flaper87: fair enough 20:31:17 flaper87: that may be true - but somehow that did not sink in with most of us - no idea why 20:31:33 flaper87: let's give you some time to rebut these new arguments and be back next week -- does that work for you ? 20:31:35 henrynash, ping 20:31:42 mordred: even Rackspace named the productization queues iirc 20:31:59 ttx: I guess :) 20:32:01 annegentle_: that's correct :/ 20:32:04 #topic Graduation review: Ironic (part 1) 20:32:13 devananda: ok, switch hats 20:32:21 devananda: put on the funny one 20:32:30 devananda: so, what about ironic 20:32:31 * devananda switches hats 20:32:41 ttx: what about it? :) 20:32:51 I've prepared some comments on the graduation requriements doc 20:33:03 in case those are useful as a starting point for any qyestions folks have 20:33:06 #link https://etherpad.openstack.org/p/IronicGraduationDiscussion 20:34:28 can you provide an upgrade path update? 20:34:34 whatever the plan / status is there 20:34:42 not clear in the doc 20:34:54 russellb: there are links and description at the end of the doc 20:34:57 russellb: second bullet point has more detail 20:35:14 russellb: tldr; grenade test for a sideways upgrade within Juno exists 20:35:24 russellb: and passes (as of yesterday) but hasn't been landed yet 20:35:52 The upgrade spec didn't make it, which means we'll need to revisit in Kilo 20:36:04 russellb: however, the nova spec for deprecation of baremetal wasn't approved. I don't know how taht plays into Nova's plans for upgrade, etc 20:36:15 hmm, would that be a graduation blocker? 20:36:33 I am unsure 20:36:41 mikal: I don't see a technical problem leaving both drivers in tree in Juno, but I have no direct control on what Nova does there 20:36:44 i think it is based on our documented expectations 20:36:46 The driver only landed a couple of days ago, that had been the focus until now 20:36:47 as much as i hate that 20:36:54 wondering if we can mitigate it somehow 20:37:13 I think we could say there is a risk we'll never get to upgrade without an incentive 20:37:17 if there is a sideways upgrade in place, is that something that can be documented too? 20:37:20 is there a commitment from the nova team to work on that with the ironic team early in kilo? 20:37:23 russellb: if the presense of the baremetal driver in tree is a blcoker, I think this is a case where our expectations are only being tested against Ironic (yet again) and may be inappropriate 20:37:44 dhellmann: as much as the nova team is a coherant entity, yes 20:37:45 devananda: which case was that expectation ignored? 20:38:05 dhellmann: the people who walked the ironic driver through would walk the upgrade code through as well 20:38:05 russellb: the deprecation plan spec was proposed to nova at the same time as the driver spec, but not reviewed/approved 20:38:15 mikal: ok, well I ask because our rules give nova essentially a "veto" over adding ironic until that migration path is "approved" and that always makes me a little nervous 20:38:21 russellb: meanwhile we have written alle the code for both things in parallel, as was communicated to us at the midcycle 20:38:23 mikal: ok, that's good 20:38:35 https://review.openstack.org/#/c/95025/13/specs/juno/deprecate-baremetal-driver.rst 20:38:38 devananda: if it's important to you to be able to point fingers, we can say it's nova's fault, i don't care 20:38:40 deprecation plan spec 20:38:50 devananda: packages are only available in Ubuntu 14.04 for installing ironic? What's the RHEL story/plan? 20:38:57 *shrug* 20:39:03 Landing the driver was a lot of work, we did that first 20:39:03 russellb: sorry - i don't mean to point at nova here. I mean to point at the adherence to a process which hasn't been tested before now 20:39:17 mikal: makes sense 20:39:23 So... 20:39:34 devananda: where's the _migration_ plan? 20:39:38 russellb: landing specs and code takes time, and I know a lot of folks in Nova have been working hard to help us land the driver 20:39:41 What happens if we graduate ironic and never get around to fixing upgrades? 20:39:49 jeblair: in that spec 20:39:54 mikal: right, the "neutron" problem 20:39:59 mikal: "fixing upgrades" ? 20:40:03 which is explicitly what we put these rules in place to avoid 20:40:14 devananda: fixing / finishing / implementing. Whatever. 20:40:14 we've already got an upgrade path in place, and grenade tests for it are proposed 20:40:24 devananda: i'm looking for discussion of the fact that the upgrade is a sideways upgrade within a release 20:40:33 i can't find the documentation for that 20:40:48 i wonder if in the next week, that could be documented? 20:40:51 the only things left are, IIUC: land the grenade tests (and maybe some bits in devstack/tempest to facilityate them) and then do the steps in Nova to delete the baremetal code 20:41:00 if there's a migration path well documented, i think i would be happy 20:41:09 devananda: there's no migration code to land in nova? 20:41:19 devananda: there's the API proxy, right? 20:41:26 grenade sideways migration test, +A'd today: https://review.openstack.org/#/c/111859/ 20:41:48 adam_g: do you know where that's documented? 20:41:49 mikal: the upgrade code was landed in ironic tree... considered a pull up upgrade from ironic, not a push upgrade from nova 20:42:02 ah 20:42:10 sdague: sure, but at the least we need an API proxy in nova, yes? 20:42:12 jeblair: I believe the "upgrade" path from icehouse baremetal to juno ironic is: upgrade icehouse baremetal to juno baremetal, then do sideways upgrade from juno baremetal to juno ironic (is that what you were looking for?) 20:42:23 jroll: yeah, i'm looking for the document that says that :) 20:42:30 jeblair: ++ 20:42:32 yeah, how would a deployer know that? 20:42:33 IIRC we originally said we'd do a FFE for that, but it wasn't proposed and we "spent" our ironic FFE budget on the driver instead 20:42:35 mikal: the proxy API actually got -1'd by dprince in the spec 20:42:54 so it looks like there's 2 key issues here 20:43:04 1) get the migration path documented now that it works 20:43:26 2) nova and ironic teams need to talk and decide if there's really any code left to land in nova 20:43:34 (one of the things we are explicitly supposed to approve, according to our own policies, is the migration plan; so i mean it would be good to know what it is :) 20:43:35 and if we're actually blocked on deprecation anymore 20:43:35 russellb: yeh, I agree #1 needs to be in english somewhere, right now it's all in code 20:43:43 jeblair: +1 20:43:56 So, re-reading the spec review... 20:44:06 Dan Prince doesn't like having the API proxy, but his argument is weak 20:44:10 "Its a waste of time" 20:44:16 But its not, its already written 20:44:26 the proxy is already written? 20:44:32 https://review.openstack.org/#/c/116316 20:44:37 We keep falling into this hole where we try to assert that a given type of user can't possibly exist, without any evidence 20:44:44 russellb: this is my understanding 20:44:48 ah, sure enough 20:45:01 if that's all that's blocking this, i'd rather just review it 20:45:16 NobodyCam: that should probably be proposed to nova, not ironic at this point :) 20:45:22 https://review.openstack.org/#/c/116316 is in the ironic tree, shouldn't that go to nova? 20:45:24 i mean, i get the argument that it doesn't matter as much since it's an admin API, too though 20:45:25 Look, if the TC asked Nova to add a FFE for the API proxy, I'd be fine with that 20:45:32 I had stoped work on it 20:45:40 and I would have a hard time to complain about it 20:45:45 so moved 20:45:55 ++ 20:45:56 Nova FF seems to be going fine at the moment, its not like we're in a big panic or anything 20:45:58 mikal: i think we (nova) need to go off and decide how much we care, and provide an answer to the TC on that 20:46:01 +1 20:46:06 i actually don't care much, since it's an admin API 20:46:09 i'm just meh on that detail 20:46:11 just to make sure I understand -- the baremetal driver and ironic driver would coexist in Nova ? 20:46:19 russellb: ++ 20:46:19 ttx: they do currently 20:46:28 ttx: you maen in the Juno release? 20:46:33 also, is this migration the only thing holding off ironic graduation? 20:46:36 devananda: yes 20:46:36 for the juno release only if we graduated 20:46:37 ttx: the deprecation plan is to do that for some period (at least one release) and then kill baremetal with fire 20:46:44 ttx: aiui, they have to, since there is a requirement for a deprecation cycle on the baremetal driver 20:46:57 ttx: and baremetal driver could be deleted when Kilo opens 20:46:58 mikal:, devananda ok, got it 20:47:10 i propose 1) ironic go document this migration plan, and 2) we confirm in nova team if we're willing to deprecate baremetal without the APi proxy 20:47:12 why does this all remind me of the conversation about nova-network... 20:47:19 and that would unblock this completely AFAICT 20:47:27 russellb: I would be happy to deal with the nova bit of that 20:47:30 devananda: can 1 and 2 be done within a week? 20:47:31 mikal: yay 20:47:32 does the proxy code need to be perposed to nova? (so lost track) 20:47:34 russellb: presumably via an email thread 20:47:35 so are there any other things besides the migration plan blocking graduation at this point? 20:47:35 mikal: hopefully just a -dev thread 20:47:39 jiinx 20:47:41 s/so/sorry/ 20:47:45 NobodyCam: please propose the proxy code 20:47:47 russellb: heh 20:47:58 russellb: ++ 20:48:05 I'm going to be honest here 20:48:05 you do recognize that 2/3rds of ask.openstack.org questions are unanswered, is that a doc deficiency or lack of packages or something else? 20:48:08 because it exists 20:48:09 ack will pick that code back up 20:48:10 devananda: the horizon work didn't land this cycle? 20:48:12 devananda: personally I'm good. Last cycle we deferred on the catch-22 with nova driver 20:48:13 I'm looking at the support/docs aspect 20:48:20 The reason the proxy is the least best thought through part of the plan is that we realized we might need to do it very late 20:48:24 (At about j-2) 20:48:27 dhellmann: horizon won't land code from non-integrated projects 20:48:32 dhellmann: it's supposed to land on first integrated cycle 20:48:37 jroll: ok 20:48:42 dhellmann: correct. horizon didn't accept the work, and we didn't have folks working on it until after the midcycle either 20:48:58 annegentle_: who is it that looks at ask.openstack.org things? is that a thing project teams are expected to pay attention to? 20:49:03 i'd love it if we can find a way for horizon to be able to accept incubated code 20:49:06 annegentle_: (asking, I have no idea) 20:49:10 jeblair: separate discussion 20:49:11 jeblair: ++ 20:49:15 mikal: you know, we could even consider a backport to juno if we changed our minds later and thought it was important later on if it's an independent API extension ... 20:49:17 but yes, separate discussion 20:49:19 devananda: horizon might be another bottleneck in kilo, have you talked to them about prioritizing the work? 20:49:20 mordred: there is a clause in the graduation req's stating that incubating projects are supposed to answer things on ask.oo.org ... 20:49:24 mordred: yes 20:49:30 devananda: oh, wow. crazy 20:49:32 ok 20:49:38 mordred: it's a way to measure the projects' support of users 20:49:50 russellb: true dat 20:49:51 JoshNang: you're working with the horizon team on that, IIRC. any sense of whether they'll prioritize reviewign it in Kilo? 20:49:54 oh - users are suposed to use ask.o.o? crazy ... 20:50:02 aweeks: ^ might know about horizon as well 20:50:03 ... 20:50:10 mordred: it's one of a few support channels we tell people about 20:50:16 devananda: sounds like horizon is excited about it 20:50:17 jeblair: apparently we should be asking more nova questions on ask.o.o ... 20:50:19 JayF: you called? 20:50:21 devananda: are russell's 1 and 2 points solvable in less than a week? 20:50:35 i didn't have any other concerns other than the migration stuff we've discussed 20:50:37 ttx: point 2 is 20:50:40 yay ironic 20:50:51 ttx: point one was "document the sideways migration plan" -- we can definitely solve that 20:50:54 devananda: unfortuantely i didn't ask if they'd prioritize 20:50:59 ttx: i think point two was up to Nova, though? 20:51:00 other TC members: any other objection ? 20:51:08 devananda: yes, mikal answered to that one 20:51:11 did annegentle_ get an answer? 20:51:11 k 20:51:12 20:48 < annegentle_> you do recognize that 2/3rds of ask.openstack.org questions are unanswered, is that a doc deficiency or lack of packages or something else? 20:51:14 devananda: it is an action for us, but it blocks you 20:51:29 mikal: ack 20:51:32 ok, so it looks like we may have a winner here next week 20:51:41 jeblair: annegentle_: is taht a general statement, or a reflection on ironic specifically? 20:51:44 ttx: I'm happy with their progress. I'm a little worried about the dependencies on those other teams, but I think that's under control now. 20:51:44 I think we should take a week to sort out these little details and then pull the trigger 20:51:48 devananda: please post a governance change to upgrade status as well, so that we can formally vote 20:51:55 ttx: ack 20:52:02 mikal: yep, part 2 next week to check on this stuff 20:52:04 last comments? 20:52:05 annegentle_: i read that as 2/3 of ironic questions? 20:52:05 but seems doable 20:52:07 also what's the RHEL plan? 20:52:17 jeblair: 7 answered of 18 20:52:23 annegentle_: RHEL packaging is up to RH, not us, afaik 20:52:24 jeblair: with the ironic tag 20:52:25 annegentle_: what RHEL plan? 20:52:37 annegentle_: but fwiw, I don't have insight into that yet 20:52:39 devananda: ok, yes, just wondering if you know if they're awaiting integration 20:52:46 don't know 20:52:50 * russellb can speak to it if he knew the question 20:52:53 don't care :) 20:52:55 heh 20:52:59 is it up to individual projects to deal with packaging for the distros? 20:53:00 yeah seems irrelevant 20:53:03 dhellman_: no 20:53:04 your install docs are covered for Ubuntu 20:53:05 it's interesting, but i don't think it's relevant to the discussion 20:53:06 dhellmann: not afaik 20:53:12 so it's probably fine but does affect the install guide 20:53:13 yep irrelevant 20:53:16 which people ask about 20:53:29