20:01:31 <ttx> #startmeeting tc
20:01:32 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:01:36 <openstack> The meeting name has been set to 'tc'
20:01:41 <ttx> Our agenda for today:
20:01:46 <ttx> #link https://wiki.openstack.org/wiki/Governance/TechnicalCommittee
20:01:57 <ttx> #topic Graduation review: Zaqar (ex-Marconi) (final decision?)
20:02:01 <markmcclain> o/
20:02:08 <ttx> So this is the continuation of last week's meeting
20:02:13 <devananda> I believe sdague planned to be here, but i may have made him a bit late by chatting earlier
20:02:14 <vishy> o/
20:02:17 <ttx> We have a review up for it now:
20:02:23 <ttx> #link https://review.openstack.org/118592
20:02:30 <ttx> there was also a thread on the ML @
20:02:36 <ttx> #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 <ttx> A few things are pretty clear now:
20:02:59 <ttx> 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 <ttx> So more MagnetoDB than Trove
20:03:23 <ttx> 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 <mordred> I do not concede that point in this context
20:03:42 <ttx> But any new structure we decide early in Kilo would reasonably start to kick in for the L release
20:03:56 <ttx> 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 <ttx> mordred: I haven't read your latest post, though
20:04:27 <mordred> 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 <ttx> so my summary may be partial
20:04:33 <mordred> while I love discussing that
20:04:36 * dhellmann pauses to read mordred's email
20:04:54 <mordred> 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 <flaper87> mordred: FWIW, thanks for bringing the discussion back to the project
20:05:47 <sdague> o/
20:05:51 <mordred> 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 <mordred> but that may just be me
20:06:02 <devananda> 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 <mordred> devananda: yes. I think we shoudl have that discussion for sure
20:06:24 <annegentle_> 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 <annegentle_> darn, lost kgriffs
20:06:54 <NobodyCam> should not all projects get that treatment
20:07:06 <annegentle_> NobodyCam: at this point in this time yes
20:07:36 <jeblair> annegentle_: ++
20:07:36 <zehicle_at_dell> o/
20:07:41 <ttx> ok, caught up with mordred's email. So you're saying it still invents more than it should
20:07:47 <vkmc> +1 annegentle_
20:07:50 * annegentle_ goes to read as well
20:07:55 <ttx> whatever the "should" definition is
20:07:59 <sdague> 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 <mordred> ttx: potentially. I would like to know what it's actually aspring to be
20:08:06 <devananda> 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 <devananda> mordred: it feels unfair because the timing of the two discussions is unfortunate, not because anyone is trying to be unfair
20:08:56 <ttx> 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 <mikal> Agreed
20:09:21 <flaper87> mordred: Zaqar aims to be a multi-tenant cloud messaging service. That's the shortest thing I can come up with
20:09:27 <dhellmann> ttx: +1
20:09:37 <devananda> 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 <ttx> devananda: both?
20:09:51 <dhellmann> devananda: both, right?
20:09:57 <flaper87> mordred: to that we can add more use-cases, features or whatever
20:10:00 <ttx> the checklist is the minimum requirements that are consensual
20:10:03 <annegentle_> devananda: both, has to be on technical merit plus the checklist
20:10:03 <flaper87> but that's the short description of it
20:10:11 <devananda> k, good
20:10:17 <mordred> 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 <ttx> technicla merit is, as we'll see when it comes to vote, much less consensual
20:10:34 <devananda> ttx: indeed
20:10:43 <annegentle_> 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 <devananda> 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 <ttx> [ timeboxing this to 30min, if it takes more, it's back next week ]
20:11:30 <devananda> flaper87: aiui, you're planning to remove those in the /v2/ API maybe?
20:11:34 <flaper87> 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 <flaper87> devananda: that's the plan, yest (fetch-by-id)
20:11:53 <flaper87> store-and-retrieve will remain
20:11:56 <mordred> 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 <devananda> mordred: right. it's not a queue as far as I can tell, and never was
20:12:19 <flaper87> devananda: why isn't in a queue?
20:12:22 <mordred> 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 <devananda> mordred: but the discussion of the v2 API is at least going towards beign a queue
20:12:36 <devananda> by removing the random access
20:12:42 <devananda> flaper87: random access is not a queue
20:12:53 <flaper87> devananda: ok, take that off. Why is it not a queue?
20:13:48 <devananda> flaper87: in your data store internally, are messages identified by a sequential value, or a random number / UUID ?
20:14:01 <ttx> mordred: so to summarize your objection, you think zaqar is reinventing something that doesn't need to be reinvented?
20:14:14 <flaper87> devananda: both, how is that relevant?
20:14:23 <devananda> flaper87: random access is nto a queue
20:14:24 <ttx> mordred: or just that you would like the use case precised?
20:14:33 <mordred> 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 <devananda> 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 <mordred> 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 <vkmc> mordred, in last meeting and in the mailing list we mentioned that Zaqar aims to provide a service similar to SQS
20:15:04 <mordred> ttx: other things they are trying to be are thigns they could be very successful at
20:15:07 <ttx> mordred: hmm, ok
20:15:12 <flaper87> devananda: I completely disagre with that
20:15:17 <devananda> if zaqar's data structure is designed for random read/write access, it's not a queue
20:15:25 <mordred> vkmc: please humor me and assume I know nothing about Amazon's product line
20:15:30 <flaper87> devananda: it's not designed for random access
20:15:36 <flaper87> random access just happened to be there
20:15:46 <devananda> huh
20:17:13 <mordred> 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 <vkmc> 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 <dhellmann> 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 <ttx> dhellman_: ++
20:17:45 <devananda> dhellmann: ++
20:17:56 <dhellmann> it seems like that more clearly describes what zaqar (wow, hard to type) is trying to be
20:18:06 <vkmc> +1 dhellman_
20:18:30 <vkmc> s/dhellman_/dhellmann
20:18:31 <dhellmann> flaper87, do you agree with that?
20:18:32 <ttx> I think "queueing" is a bit of an abuse in terms, mostly driven because SQS has Q in it
20:18:48 <flaper87> dhellmann: +1
20:18:56 <flaper87> we actually took queuing out of the deffinition
20:18:57 <dhellmann> right
20:19:02 <devananda> cool
20:19:03 <flaper87> that's something that confused people last time
20:19:12 <dhellmann> ok, it's still there in reference/programs.yaml
20:19:16 <flaper87> The wiki says: "Zaqar is a multi-tenant cloud messaging service for web developers"
20:19:21 <flaper87> dhellmann: that's our bad, then.
20:19:35 <dhellmann> yeah, not a big deal, I think we can change both things at once
20:19:36 <ttx> mordred: if we start with "message delivery API and service", would that hit your NIH detector?
20:19:52 <devananda> flaper87: that resolves my objection to it not being a queue. but then ^
20:19:54 <ttx> i.e. do you think it should be built on top of IMAP/POP servers ?
20:19:55 <mordred> 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 <flaper87> it never intended to be close to rabbit, FWIW.
20:20:24 <dhellmann> 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 <flaper87> The AMQP experiment was just that, an experiment to rely on an existing queuing technology
20:20:44 <mordred> dhellmann: ++
20:20:46 <flaper87> but taht went wrong and we shared our findings
20:21:05 <mordred> 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 <annegentle_> mordred: because it's for apps built on the cloud not the cloud itself
20:21:38 <mordred> 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 <dhellmann> 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 <mordred> dhellmann: right. or an exim/cyrus driver
20:21:58 <russellb> it's the desire for a web api for this sort of thing, right?
20:22:03 <dhellmann> mordred: pick your flavor
20:22:11 <mordred> or a mysql driver that's completely scalable
20:22:25 <ttx> mordred: anything actually
20:22:28 <mordred> this sort of thing stored in RDBMS is a long understood and long solved problem is what I'm getting at
20:22:35 <flaper87> It's possible to build storage driver for whatever people want but we also have to consider performance and what not
20:22:39 <wendar> 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 <devananda> flaper87: scaling out RDBMS (eg, mysql) is a really well understood problem space
20:23:05 <ttx> mordred: what are you getting it ? That NoSQL shouldn't be necessary ?
20:23:08 <mordred> yes
20:23:09 <devananda> flaper87: saying that you can't use an RDBMS because it doesn't scale is .... interesting
20:23:10 <dhellmann> 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 <ttx> gettig at*
20:23:20 <dhellmann> wendar: sure
20:23:24 <flaper87> devananda: I wasn't talking about RDBMS
20:23:26 <mordred> dhellmann: yes
20:23:27 <flaper87> I was talking about IMAP
20:23:35 <flaper87> or smtp
20:23:37 <flaper87> or whatever
20:23:48 <devananda> dhellmann: yes. an RDBMS is inappropriate for a queue. it's fine for storing messages.
20:24:05 <devananda> flaper87: oh. you're saying email is not performant or webscale?
20:24:10 <devananda> flaper87: i'm confused
20:24:30 <devananda> flaper87: I thought last cycle ya'll turned away from the sqla driver because of performance reasons
20:24:39 <flaper87> devananda: I never said it is *not* performant, I said that those things have to be taken under consideration
20:24:48 <ttx> mordred: because then we are back to the SQLA driver... it exists after all. Not sure that condems Zaqar architecture
20:25:26 <devananda> 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 <dhellmann> 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 <annegentle_> would my smartphone send my smartring an email to remind me I didn't close my smartgaragedoor?
20:25:58 <devananda> annegentle_: why not?
20:26:29 <dhellmann> no spoilers for the apple release, please, I haven't watched yet
20:26:30 <devananda> annegentle_: if every smartdevice had a smartemailaddress, what's the problem with scaling that?
20:26:48 <annegentle_> devananda: because my garage door doesn't have an email server?
20:26:50 <ttx> 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 <devananda> 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 <wendar> 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 <ttx> so I think we need another round of ML discussion
20:27:05 <flaper87> 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 <ttx> sending questions one hour before meeting feels like a trap to me
20:27:40 <dhellmann> 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 <mordred> ttx: sorry - wasn't intentional
20:27:59 <dhellmann> yeah, I think it's clear we need to carry this over another week
20:28:01 <jeblair> flaper87: it sounds like you are moving towards being more queue-like
20:28:08 <flaper87> dhellmann: the sql driver exists already, we marked it as deprecated because of the concerns raised last time.
20:28:10 <ttx> mordred: just saying we just can't close that one, we need solidly-built arguments and rebuttals
20:28:21 <flaper87> can it be improved? It certainly can
20:28:21 <ttx> and IRC is not the best medium for that, especially in 10 min utes time
20:28:33 <ttx> so I'd like to defer this to next week and address ironic now
20:28:40 <ttx> unless someone disagrees
20:28:41 <dhellmann> 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 <ttx> and thinks we can resolve that one in-meeting
20:29:14 <mordred> flaper87: right. what dhellman said - I think we've been judging zaqar against the wrong criteria
20:29:32 <mordred> 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 <ttx> to be fair it was always presented like a queue
20:29:42 * jaypipes reads back..
20:30:11 <ttx> ok, let's move to next topic and push discussion to ML and final decision to next week meeting
20:30:11 <devananda> ttx: that's my recollection as well. this is the first time I recall hearing that it's not a queue
20:30:16 <sdague> ttx: in fairness there was also low attendance last week with it being a short / holiday week in the us
20:30:17 <flaper87> dhellmann: it could, yes.
20:30:29 <dhellmann> flaper87: ok, that's a good data point
20:30:32 <ttx> sdague: that doesn't prevent posting the questions last week.
20:30:42 <annegentle_> yes I think we all saw queue for a while
20:30:50 <flaper87> FWIW, we started talking about it as a messaging service since right after the failed graduation meeting
20:30:58 <flaper87> and that's how we've been presenting it ever since
20:31:00 <annegentle_> flaper87: fair enough
20:31:17 <mordred> flaper87: that may be true - but somehow that did not sink in with most of us - no idea why
20:31:33 <ttx> 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 <samuelmz> henrynash, ping
20:31:42 <annegentle_> mordred: even Rackspace named the productization queues iirc
20:31:59 <flaper87> ttx: I guess :)
20:32:01 <jroll> annegentle_: that's correct :/
20:32:04 <ttx> #topic Graduation review: Ironic (part 1)
20:32:13 <ttx> devananda: ok, switch hats
20:32:21 <mordred> devananda: put on the funny one
20:32:30 <ttx> devananda: so, what about ironic
20:32:31 * devananda switches hats
20:32:41 <devananda> ttx: what about it? :)
20:32:51 <devananda> I've prepared some comments on the graduation requriements doc
20:33:03 <devananda> in case those are useful as a starting point for any qyestions folks have
20:33:06 <devananda> #link https://etherpad.openstack.org/p/IronicGraduationDiscussion
20:34:28 <russellb> can you provide an upgrade path update?
20:34:34 <russellb> whatever the plan / status is there
20:34:42 <russellb> not clear in the doc
20:34:54 <devananda> russellb: there are links and description at the end of the doc
20:34:57 <mikal> russellb: second bullet point has more detail
20:35:14 <devananda> russellb: tldr; grenade test for a sideways upgrade within Juno exists
20:35:24 <devananda> russellb: and passes (as of yesterday) but hasn't been landed yet
20:35:52 <mikal> The upgrade spec didn't make it, which means we'll need to revisit in Kilo
20:36:04 <devananda> 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 <russellb> hmm, would that be a graduation blocker?
20:36:33 <mikal> I am unsure
20:36:41 <devananda> 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 <russellb> i think it is based on our documented expectations
20:36:46 <mikal> The driver only landed a couple of days ago, that had been the focus until now
20:36:47 <russellb> as much as i hate that
20:36:54 <russellb> wondering if we can mitigate it somehow
20:37:13 <mikal> I think we could say there is a risk we'll never get to upgrade without an incentive
20:37:17 <russellb> if there is a sideways upgrade in place, is that something that can be documented too?
20:37:20 <dhellmann> is there a commitment from the nova team to work on that with the ironic team early in kilo?
20:37:23 <devananda> 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 <mikal> dhellmann: as much as the nova team is a coherant entity, yes
20:37:45 <russellb> devananda: which case was that expectation ignored?
20:38:05 <mikal> dhellmann: the people who walked the ironic driver through would walk the upgrade code through as well
20:38:05 <devananda> russellb: the deprecation plan spec was proposed to nova at the same time as the driver spec, but not reviewed/approved
20:38:15 <dhellmann> 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 <devananda> russellb: meanwhile we have written alle the code for both things in parallel, as was communicated to us at the midcycle
20:38:23 <dhellmann> mikal: ok, that's good
20:38:35 <jeblair> https://review.openstack.org/#/c/95025/13/specs/juno/deprecate-baremetal-driver.rst
20:38:38 <russellb> 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 <jeblair> deprecation plan spec
20:38:50 <annegentle_> devananda: packages are only available in Ubuntu 14.04 for installing ironic? What's the RHEL story/plan?
20:38:57 <mikal> *shrug*
20:39:03 <mikal> Landing the driver was a lot of work, we did that first
20:39:03 <devananda> 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 <dhellmann> mikal: makes sense
20:39:23 <mikal> So...
20:39:34 <jeblair> devananda: where's the _migration_ plan?
20:39:38 <devananda> 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 <mikal> What happens if we graduate ironic and never get around to fixing upgrades?
20:39:49 <devananda> jeblair: in that spec
20:39:54 <russellb> mikal: right, the "neutron" problem
20:39:59 <devananda> mikal: "fixing upgrades" ?
20:40:03 <russellb> which is explicitly what we put these rules in place to avoid
20:40:14 <mikal> devananda: fixing / finishing / implementing. Whatever.
20:40:14 <devananda> we've already got an upgrade path in place, and grenade tests for it are proposed
20:40:24 <jeblair> devananda: i'm looking for discussion of the fact that the upgrade is a sideways upgrade within a release
20:40:33 <jeblair> i can't find the documentation for that
20:40:48 <russellb> i wonder if in the next week, that could be documented?
20:40:51 <devananda> 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 <russellb> if there's a migration path well documented, i think i would be happy
20:41:09 <mikal> devananda: there's no migration code to land in nova?
20:41:19 <mikal> devananda: there's the API proxy, right?
20:41:26 <adam_g> grenade sideways migration test, +A'd today: https://review.openstack.org/#/c/111859/
20:41:48 <jeblair> adam_g: do you know where that's documented?
20:41:49 <sdague> 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 <russellb> ah
20:42:10 <mikal> sdague: sure, but at the least we need an API proxy in nova, yes?
20:42:12 <jroll> 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 <jeblair> jroll: yeah, i'm looking for the document that says that :)
20:42:30 <russellb> jeblair: ++
20:42:32 <dhellmann> yeah, how would a deployer know that?
20:42:33 <mikal> 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 <devananda> mikal: the proxy API actually got -1'd by dprince in the spec
20:42:54 <russellb> so it looks like there's 2 key issues here
20:43:04 <russellb> 1) get the migration path documented now that it works
20:43:26 <russellb> 2) nova and ironic teams need to talk and decide if there's really any code left to land in nova
20:43:34 <jeblair> (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 <russellb> and if we're actually blocked on deprecation anymore
20:43:35 <sdague> russellb: yeh, I agree #1 needs to be in english somewhere, right now it's all in code
20:43:43 <dhellmann> jeblair: +1
20:43:56 <mikal> So, re-reading the spec review...
20:44:06 <mikal> Dan Prince doesn't like having the API proxy, but his argument is weak
20:44:10 <mikal> "Its a waste of time"
20:44:16 <mikal> But its not, its already written
20:44:26 <russellb> the proxy is already written?
20:44:32 <NobodyCam> https://review.openstack.org/#/c/116316
20:44:37 <mikal> 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 <mikal> russellb: this is my understanding
20:44:48 <russellb> ah, sure enough
20:45:01 <russellb> if that's all that's blocking this, i'd rather just review it
20:45:16 <devananda> NobodyCam: that should probably be proposed to nova, not ironic at this point :)
20:45:22 <sdague> https://review.openstack.org/#/c/116316 is in the ironic tree, shouldn't that go to nova?
20:45:24 <russellb> i mean, i get the argument that it doesn't matter as much since it's an admin API, too though
20:45:25 <mikal> Look, if the TC asked Nova to add a FFE for the API proxy, I'd be fine with that
20:45:32 <NobodyCam> I had stoped work on it
20:45:40 <ttx> and I would have a hard time to complain about it
20:45:45 <dhellmann> so moved
20:45:55 <mordred> ++
20:45:56 <mikal> Nova FF seems to be going fine at the moment, its not like we're in a big panic or anything
20:45:58 <russellb> 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 <markmcclain> +1
20:46:06 <russellb> i actually don't care much, since it's an admin API
20:46:09 <russellb> i'm just meh on that detail
20:46:11 <ttx> just to make sure I understand -- the baremetal driver and ironic driver would coexist in Nova ?
20:46:19 <jaypipes> russellb: ++
20:46:19 <mikal> ttx: they do currently
20:46:28 <devananda> ttx: you maen in the Juno release?
20:46:33 <ttx> also, is this migration the only thing holding off ironic graduation?
20:46:36 <ttx> devananda: yes
20:46:36 <russellb> for the juno release only if we graduated
20:46:37 <mikal> ttx: the deprecation plan is to do that for some period (at least one release) and then kill baremetal with fire
20:46:44 <devananda> ttx: aiui, they have to, since there is a requirement for a deprecation cycle on the baremetal driver
20:46:57 <devananda> ttx: and baremetal driver could be deleted when Kilo opens
20:46:58 <ttx> mikal:, devananda ok, got it
20:47:10 <russellb> 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 <jaypipes> why does this all remind me of the conversation about nova-network...
20:47:19 <russellb> and that would unblock this completely AFAICT
20:47:27 <mikal> russellb: I would be happy to deal with the nova bit of that
20:47:30 <ttx> devananda: can 1 and 2 be done within a week?
20:47:31 <russellb> mikal: yay
20:47:32 <NobodyCam> does the proxy code need to be perposed to nova? (so lost track)
20:47:34 <mikal> russellb: presumably via an email thread
20:47:35 <devananda> so are there any other things besides the migration plan blocking graduation at this point?
20:47:35 <russellb> mikal: hopefully just a -dev thread
20:47:39 <russellb> jiinx
20:47:41 <NobodyCam> s/so/sorry/
20:47:45 <sdague> NobodyCam: please propose the proxy code
20:47:47 <mikal> russellb: heh
20:47:58 <jeblair> russellb: ++
20:48:05 <mikal> I'm going to be honest here
20:48:05 <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:48:08 <sdague> because it exists
20:48:09 <NobodyCam> ack will pick that code back up
20:48:10 <dhellmann> devananda: the horizon work didn't land this cycle?
20:48:12 <ttx> devananda: personally I'm good. Last cycle we deferred on the catch-22 with nova driver
20:48:13 <annegentle_> I'm looking at the support/docs aspect
20:48:20 <mikal> 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 <mikal> (At about j-2)
20:48:27 <jroll> dhellmann: horizon won't land code from non-integrated projects
20:48:32 <ttx> dhellmann: it's supposed to land on first integrated cycle
20:48:37 <dhellmann> jroll: ok
20:48:42 <devananda> 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 <mordred> 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 <jeblair> i'd love it if we can find a way for horizon to be able to accept incubated code
20:49:06 <mordred> annegentle_: (asking, I have no idea)
20:49:10 <ttx> jeblair: separate discussion
20:49:11 <mordred> jeblair: ++
20:49:15 <russellb> 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 <mordred> but yes, separate discussion
20:49:19 <dhellmann> devananda: horizon might be another bottleneck in kilo, have you talked to them about prioritizing the work?
20:49:20 <devananda> 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 <zaneb> mordred: yes
20:49:30 <mordred> devananda: oh, wow. crazy
20:49:32 <mordred> ok
20:49:38 <annegentle_> mordred: it's a way to measure the projects' support of users
20:49:50 <mikal> russellb: true dat
20:49:51 <devananda> 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 <mordred> oh - users are suposed to use ask.o.o? crazy ...
20:50:02 <JayF> aweeks: ^ might know about horizon as well
20:50:03 <ttx> ...
20:50:10 <annegentle_> mordred: it's one of a few support channels we tell people about
20:50:16 <jroll> devananda: sounds like horizon is excited about it
20:50:17 <mordred> jeblair: apparently we should be asking more nova questions on ask.o.o ...
20:50:19 <aweeks> JayF: you called?
20:50:21 <ttx> devananda: are russell's 1 and 2 points solvable in less than a week?
20:50:35 <russellb> i didn't have any other concerns other than the migration stuff we've discussed
20:50:37 <mikal> ttx: point 2 is
20:50:40 <russellb> yay ironic
20:50:51 <devananda> ttx: point one was "document the sideways migration plan" -- we can definitely solve that
20:50:54 <JoshNang> devananda: unfortuantely i didn't ask if they'd prioritize
20:50:59 <devananda> ttx: i think point two was up to Nova, though?
20:51:00 <ttx> other TC members: any other objection ?
20:51:08 <ttx> devananda: yes, mikal answered to that one
20:51:11 <jeblair> did annegentle_ get an answer?
20:51:11 <devananda> k
20:51:12 <jeblair> 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 <mikal> devananda: it is an action for us, but it blocks you
20:51:29 <devananda> mikal: ack
20:51:32 <ttx> ok, so it looks like we may have a winner here next week
20:51:41 <devananda> jeblair: annegentle_: is taht a general statement, or a reflection on ironic specifically?
20:51:44 <dhellmann> 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 <mikal> I think we should take a week to sort out these little details and then pull the trigger
20:51:48 <ttx> devananda: please post a governance change to upgrade status as well, so that we can formally vote
20:51:55 <devananda> ttx: ack
20:52:02 <russellb> mikal: yep, part 2 next week to check on this stuff
20:52:04 <ttx> last comments?
20:52:05 <jeblair> annegentle_: i read that as 2/3 of ironic questions?
20:52:05 <russellb> but seems doable
20:52:07 <annegentle_> also what's the RHEL plan?
20:52:17 <annegentle_> jeblair: 7 answered of 18
20:52:23 <devananda> annegentle_: RHEL packaging is up to RH, not us, afaik
20:52:24 <annegentle_> jeblair: with the ironic tag
20:52:25 <russellb> annegentle_: what RHEL plan?
20:52:37 <devananda> annegentle_: but fwiw, I don't have insight into that yet
20:52:39 <annegentle_> devananda: ok, yes, just wondering if you know if they're awaiting integration
20:52:46 <devananda> don't know
20:52:50 * russellb can speak to it if he knew the question
20:52:53 <ttx> don't care :)
20:52:55 <russellb> heh
20:52:59 <dhellmann> is it up to individual projects to deal with packaging for the distros?
20:53:00 <russellb> yeah seems irrelevant
20:53:03 <russellb> dhellman_: no
20:53:04 <annegentle_> your install docs are covered for Ubuntu
20:53:05 <jeblair> it's interesting, but i don't think it's relevant to the discussion
20:53:06 <devananda> dhellmann: not afaik
20:53:12 <annegentle_> so it's probably fine but does affect the install guide
20:53:13 <ttx> yep irrelevant
20:53:16 <annegentle_> which people ask about
20:53:29 <devananda> annegentle_: ah, because that's what our devs are using. we do have a few devs on fedora who are ensuring it stays supported
20:53:30 <ttx> we can't force RHEL to adopt or not adopt
20:53:32 <russellb> red hat has ironic devs, they should step up and fix it :)
20:53:39 <devananda> russellb: ++
20:53:41 <russellb> i can smack people if needed
20:53:42 <mordred> annegentle_: tell them "pip install git://git.openstack.org/openstack/ironic.git" :)
20:53:43 <sdague> agreed
20:53:46 <ttx> OK, let's move on
20:53:47 <mordred> no need for rpms at all ...
20:53:50 <annegentle_> russellb: it might be an integration wait
20:53:57 * sdague looks forward to russellb's hammer of doom
20:54:00 <ttx> I think we know the path forward on this one
20:54:08 <ttx> #topic Other governance changes
20:54:09 <mordred> ++ hammer of doom
20:54:15 <ttx> * The Oslo program is adopting pylockfile (https://review.openstack.org/117622)
20:54:22 <ttx> Discussion still on-going there. It looks like this will make it miss the deadline for Oslo library graduations
20:54:25 <dhellmann> I have prepared a collection of syllogisms on that, but I won't paste them here.
20:54:50 <ttx> dhellmann: will the delay on that one jeopardize graduation? or we don't actually care?
20:54:58 <ttx> because it deosn't graduate?
20:55:05 <dhellmann> we don't care, the work to move code around can be done in the next cycle
20:55:15 <sdague> it's currently only used in 1 nova test, so it shouldn't matter
20:55:16 <ttx> ok, so let's the discussion continue at its own pace
20:55:22 <ttx> * Add a Mission Statement for Orchestration (Heat) (https://review.openstack.org/116703)
20:55:26 <ttx> It's still being worked on apparently, so let's pass
20:55:31 <ttx> * Propose guidelines for adopting new official projects (https://review.openstack.org/116727)
20:55:38 <ttx> Still no new patchset after our first -1s, let's pass
20:55:42 <zaneb> I've been out for a week
20:55:47 <ttx> * Add Juno Nova co-authored-by authors to extra-atcs. (https://review.openstack.org/119666)
20:55:52 <zaneb> but I just added some questions on that one
20:55:58 <mikal> So... pause there
20:55:59 <ttx> So for all those extra-atcs patches we need to make sure those have signed the CLA, which makes it a bit painful to check
20:55:59 <zaneb> mainly for dhellman_
20:56:04 <mikal> It seems a few projects are interest in this
20:56:15 <mikal> If there was an automated way to check for CLAs, I'd do it for everyone
20:56:23 <ttx> fungi and reed are working on potential solutions there
20:56:23 <mikal> mordred: is there a gerrit command line which lists the members of the CLA group?
20:56:24 <annegentle_> yeah I'm checking individually
20:56:25 <jeblair> ttx: why do we need to make sure they signed the cla in order for them to vote?
20:56:29 <jaypipes> zaneb: silly Zane.. don't you know there's no allowed vacation for PTLs!? ;)
20:56:35 <eglynn> ttx: would the lack of CLA signing stop them getting voting privileges?
20:56:36 <mordred> I second jeblair's question
20:56:41 <jeblair> ttx: i think we needed to make sure they signed the cla _before merging the code_
20:56:43 <annegentle_> jeblair: huh good question
20:56:47 <ttx> jeblair: hmm
20:56:48 <eglynn> ... the code that they co-authored has already landed, surely it's too late to retrospectively require a CLA
20:56:50 <vishy> we really need to do get co-authored-by integrated with gerrit
20:56:52 <jeblair> ttx: i think we need to make sure they are individual members before they vote
20:57:07 <mikal> jeblair: agreed
20:57:07 <russellb> right, realistically we've been landing code without chceking CLA in all cases
20:57:07 <sdague> vishy: well, with our scripts at least
20:57:08 <ttx> jeblair: yes, that's for sure
20:57:08 <russellb> oops
20:57:23 <zaneb> jaypipes: yeah, catching up is hard :/
20:57:23 <eglynn> FYI the ceilo version of that nova extra-atcs patch: https://review.openstack.org/119794
20:57:30 <jaypipes> zaneb: indeed.
20:57:30 <ttx> jeblair: ok, so maybe I was off on the CLA thing there
20:57:34 <mikal> Does the vote invite generation stuff check foundation membership?
20:57:39 <annegentle_> is this status for voting and summit invites? Anything else?
20:57:41 <mikal> Is it possible for me to resign my membership?
20:57:42 <ttx> at least it doesn't affect the atc part
20:57:44 <mordred> mikal: NO
20:57:51 <mordred> mikal:  you may never leave
20:57:51 <jeblair> mikal: only indirectly
20:58:12 <ttx> annegentle_: it's for voting. Extra perks like summit invites are...extra perks
20:58:13 <mikal> I think my point being...
20:58:25 <mikal> If we care about foundation membership, it needs to be checked at the point of vote invite generation
20:58:28 <jeblair> mikal: since it only works on patches to projects that use the cla and the cla requires (incorrectly perhaps) foundation membership, there's an indirect link
20:58:41 <ttx> mikal: yes, it's just tricky to do so
20:58:42 <mikal> jeblair: unless someone can resign their membership
20:58:51 <reed> https://bugs.launchpad.net/openstack-community/+bug/1311138
20:58:53 <uvirtbot> Launchpad bug 1311138 in openstack-community "CLA cannot be re-signed or revoked" [Undecided,New]
20:58:57 <ttx> ok, let's forget my objection and move on
20:58:59 <jroll> mikal: the list of extra-atcs, did you check if those folks are already ATCs?
20:59:00 <mikal> Heh
20:59:06 <ttx> #topic Open discussion
20:59:07 <zaneb> jeblair: the CLA is explicitly designed for the case where the author is not the submitter, and hasn't signed the CLA
20:59:08 <jroll> mikal: (and does it matter)
20:59:18 <ttx> Mark Radcliffe wants to give us a phone presentation of the bylaws changes
20:59:20 <zaneb> jeblair: which makes it even more bizarre that we have it
20:59:21 <mordred> I posted 4 changes related to the PRoject Testing Interface
20:59:23 <mikal> jroll: so... that is a list of co-authors who hadn't landed a patch in the period I was checking (since 1 April)
20:59:27 <ttx> He has some availability in the Pacific time mornings of September 17th and 18th
20:59:38 <mordred> the first three should be completely rubberstampbable
20:59:42 <jroll> mikal: hadn't landed a patch at all or in nova?
20:59:44 <ttx> Proposed time would be the 18th at 8am Pacific, which means...
20:59:45 <anteaya> ttx can non tc listen in?
20:59:47 <mordred> since the first one is just importing the text into the repo
20:59:48 <mikal> jroll: in nova
20:59:54 <ttx> anteaya: I have no idea
20:59:58 <jroll> mikal: ah, ok, didn't realize it mattered :) thanks
20:59:58 <mordred> so I'd love it if people would vote on those
21:00:01 <ttx> lawyers organize the call
21:00:08 <mordred> the fourth is about teh docs tox env
21:00:14 <mikal> jroll: it gives those listed a vote in the compute PTL election, so project does matter here
21:00:19 <jroll> aha :)
21:00:24 <dhellmann> ttx: can we get the changes in writing first?
21:00:29 <mordred> the string ends here: https://review.openstack.org/#/c/119875/
21:00:34 <mikal> 8am PST is terrible for me, just sayin'
21:00:43 * jroll gets to try to vote mikal out now >:)
21:00:43 <ttx> so that would be Thtrsday at 1500 UTC
21:00:44 <anteaya> ttx I'd like to listen if I it is possible, but I accept if it isn't
21:00:55 <mikal> I'm a bit sad we moved on from extra-atcs
21:01:00 <ttx> mikal: yes, he just proposed "pacific morning"
21:01:10 <annegentle_> we still need extra-atcs I believe
21:01:13 <mikal> Do we want to do that for every integrated project?
21:01:21 <ttx> and apparently morning is 8am there
21:01:23 <russellb> mikal: if we do it, i'd really like to see it done for everything
21:01:25 <mikal> Are we will to skip the CLA check ttx wanted?
21:01:25 <sdague> mikal: it seems like it would be better to write a script, right?
21:01:30 <russellb> but that's work i'm not signing up for :)
21:01:31 <mikal> sdague: I did!
21:01:37 <mikal> sdague: I even sent you a link to it!
21:01:40 <russellb> heh
21:01:42 <dhellmann> mikal: yeah, how about if you put your script in the governance repo?
21:01:43 <ttx> mikal: yes, we said my remark was stupid and moved on
21:01:52 <sdague> mikal: so then why do we need it in the extra-atc list, and not just part of the atc generator
21:01:53 <annegentle_> the original point of having a governance document for extra atcs was for ptls to have a non-computerizedrobotic way to recognize contributors though
21:01:57 <mikal> So... if the current script is acceptable, I can move it somehwere and run it for everyone
21:02:00 <mikal> If people want me to
21:02:01 <ttx> mikal: also fungo plans to run the same for each
21:02:03 <annegentle_> so how we generated it is not the point
21:02:07 <ttx> fungi*
21:02:08 <annegentle_> in my case any way
21:02:10 <dhellmann> mikal: I would like it run for oslo
21:02:17 <ttx> we need to close the meeting
21:02:21 <russellb> bye!
21:02:23 <mikal> ttx: never!
21:02:23 <dhellmann> mikal: although I don't really expect any output
21:02:27 <annegentle_> I need to recognize some contributors
21:02:35 * ttx hovers over the big red button
21:02:37 <russellb> mikal: need to do novaclient too technically
21:02:45 <mikal> sdague: probably, but this was about making life for anteaya easier while we worked out what we're doing
21:02:46 <sdague> ok, I thought the impact was just for overall atc status
21:02:53 <mikal> russellb: fair point there
21:03:15 <ttx> mikal on extra-atcs, let's sync with fungi, he generated electorate rolls
21:03:16 <anteaya> sdague: the original point of extra-atcs was overall atc status
21:03:18 <mikal> Ok, I will take those action items and come back with a thing
21:03:25 <mikal> ttx: sure
21:03:29 <ttx> on Mark Redcliffe, i'll post to -tc
21:03:31 <ttx> #endmeeting