17:00:00 <devananda> #startmeeting ironic
17:00:01 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:05 <openstack> The meeting name has been set to 'ironic'
17:00:07 <devananda> #chair NobodyCam
17:00:08 <openstack> Current chairs: NobodyCam devananda
17:00:16 <jroll> \o
17:00:17 <thiagop> morning all
17:00:19 <betherly> o/ hi!
17:00:21 <rameshg87> o/
17:00:21 <lucasagomes> o/
17:00:22 <vdrok_> morning
17:00:25 <yuriyz> o/
17:00:28 <devananda> as usual, the agenda is in the wiki
17:00:28 <mrda> o/
17:00:31 <trown> o/
17:00:32 <devananda> #link https://wiki.openstack.org/wiki/Meetings/Ironic
17:00:43 <saripurigopi> O/
17:00:49 <devananda> 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 <rloo> hi
17:00:54 <jlvillal> o/
17:00:57 <TheJulia> o/
17:01:05 <NobodyCam> o/
17:01:08 <mariojv> \o
17:01:11 <JoshNang> o/
17:01:36 <devananda> skipping announcements section since it's empty
17:01:46 <NobodyCam> :)
17:01:50 <devananda> #topic subteam status reports
17:02:17 <devananda> #link https://etherpad.openstack.org/p/IronicWhiteBoard
17:02:27 <devananda> if you haven't already updated your subteam status, tracked at that ^ link, please do so now
17:03:01 <devananda> there was a lot of work / progress on the neutron/ironic integration last week
17:03:21 <devananda> many thanks to jroll, Sukhdev, and others for that
17:03:30 <jroll> :)
17:03:34 <jroll> it's coming along nicely
17:03:42 <NobodyCam> and thank you to all who attened the mid-cycle
17:03:45 <rloo> hmm, dtantsur is on PTO. Are we in a hurry to get the ironic-lib stuff done?
17:03:57 <devananda> rloo: yea, we kinda are. it's been blocking other things for a while
17:04:23 <rameshg87> rloo: and we have a soft freeze on those files in ironic now
17:04:28 <jroll> he's back wednesday
17:04:28 <rloo> devananda: looks like there are two patches for ironic-lib dvsm testing.
17:04:29 <devananda> also, jroll and I need to catch up with dhellmann soon to sort out releases
17:04:44 <jroll> devananda: it's on my calendar to hit him up tomorrow
17:04:48 <devananda> we tried last week but there's things in pip/pbr I dont understand
17:05:03 <lucasagomes> yeah, I think it's most good for a release right?
17:05:04 <devananda> rloo: thanks
17:05:06 <lucasagomes> in a code POV
17:05:09 <devananda> lucasagomes: yea
17:05:58 <devananda> pshige_, jlvillal: any updates on docs?
17:05:58 <rloo> is anyone familiar with tempest/devstack stuff, to continue Dmitry's patches? (Or we wait til Wed?)
17:06:01 <jroll> lucasagomes: there's two patches right now to get dsvm running
17:06:05 <rameshg87> 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 <jroll> lucasagomes: https://review.openstack.org/#/c/212491 https://review.openstack.org/#/c/212495/
17:06:41 <devananda> jroll: release ironic first, then switch to using ironic-lib, ya?
17:06:46 <jroll> devananda: yes pls
17:06:47 <jlvillal> devananda: Not from me. Was I supposed to do something on docs???
17:06:48 <lucasagomes> jroll, thanks
17:06:59 <lucasagomes> devananda, ++
17:07:12 <devananda> rameshg87: do you have links to those patches? pls put on the etherpad
17:07:19 <rameshg87> devananda: ack
17:07:20 * jlvillal trying to remember if he had a TODO item that he forgot about.
17:07:22 <jroll> 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 <devananda> jlvillal: oh, nope. I imagined it :)
17:07:44 * jlvillal Whew!
17:08:04 <rloo> jlvillal: I thought you were going to reorganize our docs?
17:08:07 <rloo> jlvillal: just kidding
17:08:12 <mrda> lol
17:08:19 * jlvillal recovers from heart-attack.... :P
17:08:23 <NobodyCam> hehe
17:08:27 <devananda> mrda: !! you're here :)
17:08:33 <devananda> jetlag, eh?
17:08:45 <mrda> devananda: I'm in SAT this week
17:08:50 <devananda> ahh
17:08:55 <devananda> well, welcome :)
17:09:08 <devananda> anything to add to the nova/ironic section of the status report?
17:09:11 <mrda> thanks - it'll be my last team meeting for a while due to TZ
17:09:36 <lucasagomes> mrda, :-(
17:09:37 <mrda> devananda: Not really, we have some things to do, and jlvillal and I will update later today hopefully
17:09:49 <devananda> k k
17:09:58 <mrda> devananda: but I haven't had time to get anything done so far
17:10:19 <rloo> 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 <mrda> rloo: shall do
17:10:43 <rloo> thx mrda
17:10:49 <jlvillal> 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 <jroll> rloo: nova is full-on feature freezed for L, bug fixes can land any time AIUI
17:11:26 <jlvillal> 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 <mrda> yes please
17:11:55 <jlvillal> We usually look for Nova bugs that are tagged as Ironic.  And then look for patches off of those bugs.
17:12:15 <devananda> good stuff, everyone - thanks for the updates!
17:12:27 <devananda> anything else before we move on? (giving it another minute)
17:12:57 <rloo> so we have OneView in the etherpad, but I don't htink the spec has been approved yet?
17:13:16 <lucasagomes> yeah not yet
17:13:23 <lucasagomes> #link https://review.openstack.org/#/c/187762/
17:13:25 <devananda> nope, not yet
17:13:25 <sambetts> hg87 :)
17:13:27 <thiagop> In fact, we're waiting for some reviews
17:13:37 <thiagop> any feedback is appreciated
17:13:47 * lucasagomes adds to his todo for tomorrow
17:13:49 <devananda> oh -- actually, one more thing to add to the update list
17:14:12 <devananda> jroll and I (and others) sat down and looked at both the approved and unapproved specs
17:14:18 <devananda> compared to list of things we set out at beginning of the cycle
17:14:24 <devananda> and did a major update to the priorities spreadsheet
17:14:30 <devananda> #link https://docs.google.com/spreadsheets/d/1Hxyfy60hN_Fit0b-plsPzK6yW3ePQC5IfwuzJwltlbo
17:14:42 <mrda> thanks devananda for the link
17:14:50 <devananda> since LP doesn't give us any good way to group bp's by topic, we did that in google ...
17:14:56 <lucasagomes> oh nice one
17:15:06 * devananda waits for the mythical future when openstack will have a good tool for this
17:15:17 <NobodyCam> current priorities tab!
17:15:24 <rloo> devananda: awesome (for updating priorities). Not good wrt all the stuff to do, sigh.
17:15:30 <lucasagomes> loads of changes to the driver interfaces O.O
17:16:02 <devananda> 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 <rloo> 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 <devananda> rloo: let's not discuss that now
17:16:46 <thiagop> 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 <NobodyCam> thiagop: awesome!
17:17:08 <thiagop> 30% done
17:17:17 <devananda> ok, going to timebox this lest we run out of time for other things
17:17:20 <devananda> thanks everyone for the updates!
17:17:22 <lucasagomes> thiagop, ++ awesome
17:17:26 <rloo> devananda: don't want to discuss, just think it is high priority and not sure it is captured in the doc
17:17:35 <jlvillal> thiagop: +1 on awesome :)
17:17:36 <devananda> rloo: fair point
17:17:53 <rloo> devananda: i don't think we can release liberty w/o resolving that
17:18:06 <devananda> #topic scripts that do not fit into our current project repositories
17:18:09 <devananda> NobodyCam: that's you
17:18:13 <NobodyCam> oh thats me
17:18:14 <NobodyCam> :)
17:18:37 <NobodyCam> we've have a couple of folks purpose utility type scripts, many are driver or vendor specific and
17:18:40 <NobodyCam> do not have a good location in the ironic tree. It was suggested that a solution to this would be
17:18:43 <NobodyCam> to have these scripts in their own repos, and a wiki type page could be created with links pointing
17:18:46 <NobodyCam> to these repos. I kinda like this as it allows the script creators to maintain them with out having to
17:18:49 <NobodyCam> bogged down by the entire Ironic review process, but they could still be "linked" to the ironic
17:18:52 <NobodyCam> project via the wiki page.
17:18:55 <NobodyCam> (sorry for large paste)
17:19:16 <jroll> isn't that exactly the method we decided to move forward with in vancouver?
17:19:16 <jlvillal> I like the idea of separate repo(s) outside of Ironic.
17:19:20 <NobodyCam> would like to hear what other folks think about this
17:19:38 <devananda> jroll: maybe? but we haven't implemented it yet afaik, so it came back up at the midcycle
17:19:39 <lucasagomes> yeah seems fine to have a separated repo
17:19:43 <sambetts> I think we decided on a single utils repo in vancouver
17:19:56 <lucasagomes> I mean "many are drivers", drivers could easily live in our tree
17:20:04 <jroll> devananda: what is there to implement about "make your own repo" and "put a link on our wiki page"
17:20:06 <rloo> +1 for separate repos. I think in Vancouver there were 2 solutions and no decision.
17:20:07 <devananda> sambetts: I recall a discussion around having a single "other utils" repo, but there are problems with that
17:20:11 <TheJulia> 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 <jroll> heh
17:20:21 <devananda> like, who approves changes in it? what language is it in? how is it tested?
17:20:30 <gabriel-bezerra> rloo: +1
17:20:36 <mrda> 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 <jlvillal> lucasagomes: Problem with drivers in our tree is that difficult for people to review hardware/vendor specific code
17:20:51 <jroll> I'm not seeing this in the etherpad :(
17:20:51 <devananda> jroll: the only thing for us to do: 1) agree on it 2) document the agreement in a wiki page
17:20:59 <jroll> right
17:21:00 <devananda> mrda: no curation
17:21:10 <lucasagomes> jlvillal, well we do it already right?
17:21:17 <devananda> the wiki would indicate who, from that vendor (presumably) is the maintainer
17:21:17 <sambetts> I think we should use the neutron vendor decomp as a case study
17:21:22 <mrda> s ironic-<vendor>-caveat-emptor as a repo name?
17:21:30 <jlvillal> lucasagomes: Yeah, but is that a good thing or not?  I'm not sure.
17:21:30 <lucasagomes> jlvillal, many of the vendor stuff can live in a separated library
17:21:32 <mrda> s/s/so/
17:21:32 <NobodyCam> in many cases not everyone will be able to test them asfolks may not have the HW to test
17:21:35 <devananda> so the communit has a point of contact for issues in, essentially, third-party tools
17:21:38 <lucasagomes> like proliantutils
17:21:42 <jroll> let's be clear here: this isn't driver code. this is utility scripts etc.
17:21:43 <rloo> we aren't discussing the home of drivers. just other "stuff", right?
17:21:44 <jroll> right?
17:21:47 <devananda> much like several drivers have already created their own repos on stackforge or github
17:21:50 <TheJulia> jroll: correct
17:21:56 <jlvillal> Sorry, for off topic then.
17:21:58 <devananda> rloo, jroll: correct
17:22:11 <jroll> python enroll_hardware_from_acme_cmdb.py etc.
17:22:14 <trown> how would this work with "big tent" ie. no more stackforge
17:22:17 <devananda> exactly
17:22:53 <devananda> trown: so, frankly, I don't like the "no more stackforge" approach
17:22:53 <jroll> 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 <devananda> jroll: +100
17:23:08 <jroll> I don't care if your repo is in the openstack ecosystem or not
17:23:11 <thiagop> people that wants can use the 'openstack/' namespace instead of stackforge
17:23:14 <jroll> make a repo. put it somewhere.
17:23:14 <sambetts> trown: you can have independantly released projects under the ironic statium
17:23:19 <trown> devananda: me neither...but it seems that is the direction
17:23:23 <thiagop> it's just not a "official" project
17:23:29 <lucasagomes> I'm good with separated repos
17:23:38 <devananda> 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 <rameshg87> +1 for separate repos and documenting on wiki
17:23:42 <mrda> 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 <devananda> and included in the ironic project
17:23:54 <lucasagomes> people can manage their own tools and edit the Ironic wiki to talk about it, no problem
17:23:59 <gabriel-bezerra> jroll: +1
17:24:03 <jroll> devananda: right, they should not be included in the ironic tree there.
17:24:08 <devananda> jroll: right
17:24:19 <jlvillal> So is it separate repos under openstack/ or just some repo on github.com?
17:24:25 <NobodyCam> jroll: devananda: yep that was my thinking too
17:24:26 <mrda> I think everyone agrees with not in the ironic tree
17:24:44 <sambetts> I don't
17:24:45 <jroll> mrda: I think a free for all is fine
17:24:55 <jroll> ok, here's an example
17:24:57 <jroll> https://github.com/rackerlabs/onmetal-scripts
17:25:03 <trown> "just some repo on github.com" is problematic as there is no access to the wealth of infra resources then
17:25:13 <jroll> should that be in the ironic program? should ironic maintainers be responsible for that repo?
17:25:16 <thiagop> so, to have a wiki is a consensus?
17:25:26 <rloo> isn't 'ironic tree' == git repo for 'ironic' code. vs 'ironic program' which includes ipa, inspector, bifrost...
17:25:31 <thiagop> the problem is just were to put the code?
17:25:41 <NobodyCam> example: https://review.openstack.org/#/c/158577/
17:25:42 <sambetts> jroll: being under the ironic stadium doesn't mean that the ironic core team is invloved with it at all
17:25:44 <devananda> thiagop: the problem is "who is responsible fo rmaintaining the code"
17:25:50 <jroll> rloo: right, sorry
17:26:01 <jroll> 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 <devananda> sambetts: did we switch from umbrellas to stadiums? :)
17:26:13 <jroll> sambetts: people will come to the ironic team when they have problems with it
17:26:19 <jlvillal> How about allow both repos on github.com and under openstack/  Either is acceptable?
17:26:33 <jroll> jlvillal++ (just not in the ironic program)
17:26:35 <jlvillal> Just link to them from the wiki.
17:26:40 <jroll> +++++
17:26:41 <rloo> 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 <NobodyCam> ++
17:26:43 <TheJulia> ++
17:26:48 <mrda> +1
17:26:49 <devananda> jlvillal: that's what NobodyCam proposed at the opening of this topic :)
17:26:55 <devananda> rloo: exactly
17:26:55 <jroll> "if you make a repo, we'll link to it"
17:27:03 <trown> jroll: how does one create a openstack/ repo for an ironic based project that is not under the ironic program?
17:27:03 <NobodyCam> yep
17:27:12 <rloo> jroll: or 'if you make a repo, you can link to it'
17:27:17 <sambetts> 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 <devananda> trown: one does not
17:27:18 <jroll> trown: I have no idea, they should ask infra
17:27:19 <mrda> trown: ask infra
17:27:19 <thiagop> trown: did that this week
17:27:29 <lucasagomes> 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 <lucasagomes> as others have done already
17:27:35 <thiagop> just don't add it to the governance stuff
17:27:36 <lucasagomes> but it needs time
17:28:05 <TheJulia> Honestly, this may not be a project, it may just be "I have some helper scripts, the community could use them"
17:28:11 <devananda> 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 <jroll> thiagop: oh, that's a good point. infra/tc/whatever doesn't have a problem with that?
17:28:16 <trown> thiagop: can you point me to the project-config review for that?
17:28:24 <thiagop> devananda: yep
17:28:55 <gabriel-bezerra> devananda: it is openstack/python-oneviewclient
17:29:07 <thiagop> #link https://review.openstack.org/#/c/211301/
17:29:10 <devananda> 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 <thiagop> trown: ^
17:29:26 <devananda> I dont know if it's even written in python
17:29:33 <trown> thiagop, thanks
17:29:38 <NobodyCam> #link https://review.openstack.org/#/c/158577
17:29:58 <devananda> 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 <TheJulia> 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 <thiagop> devananda: I know, but once the community hasn't yet agreed on that, I proposed it that way
17:30:44 <sambetts> 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 <TheJulia> is an ansible module openstack?
17:31:04 <thiagop> and it can be a way out to the helper scripts  too
17:31:07 <TheJulia> (as an example)
17:31:11 <devananda> TheJulia: it can be. see OSAD :)
17:31:15 <rloo> 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 <TheJulia> devananda: I knew you were going to respond with that :)
17:31:30 <mrda> osad: \o/
17:31:40 <devananda> rloo: I was just checking projects.yaml and I agree -- it's not currently clear
17:31:51 <devananda> proliantutils isn't listed there, but I think it should be
17:31:59 <jroll> so getting back on topic
17:32:07 <jroll> there are clearly things we don't want in the ironic umbrella
17:32:07 <rloo> 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 <jroll> and an openstack repo can be made without putting under ironic umbrella
17:32:35 <NobodyCam> jroll: ++
17:32:38 <jroll> so I think we should advise vendors to make a repo on openstack or github, doesn't matter
17:32:43 <jroll> and link to it from a wiki page
17:32:51 <thiagop> jroll: +1
17:33:01 <BadCub> jroll: +1
17:33:02 <rameshg87> jroll: +1
17:33:06 <jroll> who wants to write those docs? :)
17:33:14 <jroll> (or wiki page)
17:33:15 <rloo> jroll: write what docs?
17:33:21 <trown> jroll: ++, the ability to make a repo under openstack namespace but not under **any** umbrella is news to me
17:33:21 <devananda> 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 <lucasagomes> 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 <devananda> trown: yea, news to me too
17:33:30 <rloo> jroll: the wiki page part is easy.
17:33:31 <jroll> rloo: the "here's what you should do for tools repos"
17:33:55 <jroll> rloo: it could be a paragraph on the wiki, rather than docs or whatever
17:34:02 <rloo> jroll: so two wikis: one for instructions on how, one that lists the 3rdparty/whatever stuff.
17:34:15 <thiagop> devananda trown I think it was after the depreciation of stackforge namespace
17:34:20 <rloo> jroll: did we agree/vote on this?
17:34:22 <BadCub> 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 <jlvillal> Or one Wiki with both
17:34:23 <jroll> devananda: maybe we should get that clarified, then, but today it's possible
17:34:28 <rloo> jroll: (not the wiki part, the process)
17:34:39 <jroll> rloo: I made a statement, I'm not seeing disagreement
17:34:43 <jroll> ¯\_(ツ)_/¯
17:34:44 <NobodyCam> I would also think many vendor type folk already a github repo like the rackerlabs one
17:34:54 <sambetts> BadCub: +1
17:34:59 <rloo> jroll: yeah, but we're in a meeting. don't we have to vote?
17:35:08 <devananda> 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 <devananda> jroll: ++ to getting that clarified
17:35:43 <NobodyCam> and require spicific HW to test
17:35:47 <jroll> rloo: sure, whatever, voting is fine
17:35:50 <jlvillal> Should it be in the docs too?  Or the links are only in the Wiki?
17:35:53 <thiagop> NobodyCam: right
17:35:54 <BadCub> Those are very good points to get clarified
17:36:00 * devananda doesn't feel the need to vote
17:36:06 <lucasagomes> jlvillal, I think only wiki is fine
17:36:17 <jroll> +1 for wiki.
17:36:23 <devananda> anyone volunteering to writing this in the wiki?
17:36:33 <rameshg87> I will
17:36:36 * NobodyCam can take a stab at it
17:36:39 <jroll> woo, thanks rameshg87
17:36:41 <devananda> rameshg87: ty :)
17:36:42 <NobodyCam> or rameshg87
17:36:49 <BadCub> rameshg87: +1 :)
17:36:57 <thiagop> rameshg87: o/\o
17:37:03 <NobodyCam> :)
17:37:12 <NobodyCam> Thank you all!
17:37:13 * rameshg87 hasn't got this much cheer ever :)
17:37:23 <BadCub> lol
17:37:28 <devananda> #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 <devananda> thanks all!
17:37:40 <TheJulia> thank you!
17:37:45 <devananda> #topic patches adding copyright headers
17:37:51 <lucasagomes> hope this one to be fast...
17:37:59 <devananda> I don't see naohiro here, so I'll proxy
17:38:04 <jroll> can we just agree to email legal-discuss here
17:38:04 <lucasagomes> so we have this patch here https://review.openstack.org/212973 adding some copyright lines to their code
17:38:11 <devananda> #link https://review.openstack.org/212973
17:38:31 <lucasagomes> IMHO I don't think it matters that much, but we don't have a consensus around it
17:38:34 <devananda> I googled a bit, but didn't find it -- but there have been several discussions in -infra about this before
17:38:41 <jroll> 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 <devananda> lucasagomes: infra does have a policy here
17:38:51 <lucasagomes> devananda, not infra, it's legal
17:39:09 <lucasagomes> also, AFAIR some projects have decided not to have any copyright lines
17:39:12 <devananda> 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 <devananda> but then that got caught up in board and TC meetings for a long time, and still isn't resolved
17:39:45 <devananda> lucasagomes: it's not about legal. the CLA asserts the copyright on submission
17:39:48 <NobodyCam> at one time we were adding: # Copyright <year> OpenStack Foundation headers
17:40:09 <devananda> NobodyCam: you should never have added one of those -- sinc eyou were never, afaik, an employee of the openstaack foundation ....
17:40:14 <devananda> nor should I ever have
17:40:21 <lucasagomes> devananda, right, yeah I know... but many of the code have copyright lines and we keep accepting it
17:40:28 <rloo> Is the question whether we should allow those Copyright's? We already have code with them.
17:40:49 <devananda> rloo: no - the question is whether we can allow them to be added after the fact
17:41:03 <devananda> fujitsu submitted code w/o any (c) header, and it landed, and now they want to "correct" it
17:41:04 <lucasagomes> yeah can we add it after they are already submitted?
17:41:06 <rloo> devananda: OH. that is different. No, I don't think so.
17:41:12 <mrda> 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 <devananda> #action devananda to follow up with infra and/or legal team on this
17:41:29 <BadCub> 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 <jroll> so as I understand it. those copyrights are meaningless. AFAIK we do it because we cargo cult the header.
17:41:51 <mrda> 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 <jroll> devananda++
17:41:51 <devananda> the CLA imputes it on code submission, based on the attribution of the patch author
17:41:53 <lucasagomes> jroll, ++ yeah they are meanless because we signed the CLA
17:41:54 <rloo> (or is the definition of 'landed' -- when a release occurs)
17:42:07 <devananda> so as far as openstack foundation legal is concerned, they aren't needed.
17:42:16 <devananda> but some companies feel otherwise, thus we get them, and mostly don't care
17:42:23 <devananda> rloo: no, commit accepted
17:42:36 <rloo> devananda: ok, let's move on then. You've got your action item :)
17:42:40 <lucasagomes> ++
17:42:40 <devananda> anyway, time boxing at this point, but wanted everyone to be aware of the discussion and policy
17:42:48 <jroll> +1, let's move on
17:42:54 <devananda> #topic driver name length limit
17:43:01 <lucasagomes> another fast one
17:43:08 <devananda> this one has no name on the agenda ...
17:43:10 <devananda> #link https://review.openstack.org/#/c/209605/
17:43:17 <lucasagomes> there's a patch changing the length of the name from 15 to 25
17:43:27 <thiagop> mine
17:43:39 <thiagop> but lucasagomes bringed that to us
17:43:44 <jroll> is there any reason to continue to limit this artificially? if we proposed 255, what would be the objection?
17:43:51 <lucasagomes> while I think it's fine, do we have any consensus whether 25 is enough for the driver's name ?
17:43:58 <lucasagomes> imo we can make it longer and have no more problem's with it
17:43:59 <mrda> 25 might be too limited
17:44:05 <devananda> jroll: the driver name is actually hte python entrypoint name
17:44:11 <rloo> jroll: +1. I see no reason to limit it to 25
17:44:14 <devananda> is there a limit on python entrypoint names?
17:44:15 <jroll> +1, let's make it so we never have to deal with this again
17:44:16 <thiagop> broght*
17:44:22 <jroll> devananda: good question, I doubt it but who knows
17:44:25 <jroll> probably 79 :)
17:44:29 <betherly> I think 25 is limited but equally think there should be a limit of some kind?
17:44:40 <devananda> I don't care about the db field length (as long as it's < 256)
17:44:43 <rloo> let's limit it to python entrypoint names then!
17:44:50 <NobodyCam> 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 <devananda> NobodyCam brings up a good point - usability is also a concern
17:45:11 <mrda> 255 might be a better choice, just so we don't have to revisit
17:45:12 <devananda> this will be displayed in UI, typed on CLI, etc
17:45:12 <yuriyz> imo reasonable value is 64
17:45:28 <rloo> devananda: but the names have to be approved by the core-reviewers.
17:45:30 <devananda> but I'm fine with the DB no longer imposing an arbitrarily small limit
17:45:32 <NobodyCam> yuriyz: more than in my option
17:45:45 <devananda> and if someone wants to use MyReallyLongdriverNameThatNoOneWillEverType -- well, they can
17:45:51 <lucasagomes> right
17:45:57 <jroll> setuptools doesn't seem to document a max length for entry points
17:45:58 <BadCub> 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 <jroll> fwiw
17:46:07 <NobodyCam> ++
17:46:08 <devananda> jroll: cool
17:46:11 <thiagop> we could add a recommendation to use short names
17:46:12 <betherly> +1
17:46:12 <mrda> (assuming they can convince everyone in code review...)
17:46:18 <yuriyz> ok
17:46:20 <devananda> BadCub: 100 is even more arbitrary :)
17:46:27 <lucasagomes> alright, so everyone agrees 25 is too small?
17:46:31 <devananda> lucasagomes: yes
17:46:33 <yuriyz> +1
17:46:37 <BadCub> +1
17:46:37 <mrda> yup
17:46:42 <betherly> Yup
17:46:42 <NobodyCam> yup
17:46:43 <rameshg87> +1 for 255
17:46:48 <jroll> let's just decide on a number now before we bikeshed all over gerrit
17:46:48 <devananda> I've heard two suggestions so far: 64 and 255
17:46:52 <jroll> I like 255
17:46:54 <thiagop> lets do a vote?
17:46:54 <NobodyCam> rameshg87: ya
17:46:57 <rloo> +1 255
17:47:01 <lucasagomes> well 255 then
17:47:03 <mrda> +1 for 255
17:47:05 <lucasagomes> no hard limits
17:47:16 <thiagop> 255 it is
17:47:17 <trown> +1 for 255
17:47:20 <jlvillal> +1 for 255
17:47:20 <yuriyz> ok 255 is good
17:47:22 <devananda> that's easy
17:47:23 <jroll> we can artificially limit in code if we want to make the limit smaller for usability
17:47:24 <BadCub> +1 for 255
17:47:24 <gabriel-bezerra> as unlimited as possible
17:47:29 <rloo> unless we find out there's something else that limits it
17:47:36 <devananda> #agreed use 255 for the driver name field length in the db
17:47:37 <lucasagomes> rloo, yeah
17:47:38 <devananda> #undo
17:47:39 <openstack> Removing item from minutes: <ircmeeting.items.Agreed object at 0x9c577d0>
17:47:39 <betherly> +1 jroll
17:47:40 <jroll> woo, done
17:47:41 <jroll> NEXT
17:47:44 <lucasagomes> thiagop, thanks for the patch :-)
17:47:49 <devananda> #agreed use 255 for the driver name field length in the db, unless we find out that there is another limit (eg, python entrypoint length)
17:48:02 <devananda> #topic open discussion
17:48:07 <thiagop> lucasagomes: not at all, will to it later today
17:48:21 <lucasagomes> well I put yet another item there for the delete instances at any time in the deployment
17:48:35 <lucasagomes> devananda, while I think target_provision_state would be great, I don't see any clear way to actually implement it?
17:48:48 * BadCub wants to thank everyone for making mid-cycle so awesome.
17:49:06 <NobodyCam> ++
17:49:16 <mrda> Great job BadCub!
17:49:16 <betherly> +1
17:49:18 <lucasagomes> and syntax way, I don't think the flag is all bad. Because the node will actually transit from the target_provision_state it's currently set to transit
17:49:23 <betherly> It was awesome
17:49:31 <betherly> And thanks to everyone for making me feel welcome!
17:49:35 <lucasagomes> and then it will be deleted (and the target_* will mark it as deleted)
17:49:42 <BadCub> thnx mrda :)
17:50:00 <TheJulia> BadCub: Thank you for setting things up
17:50:04 <mrda> BadCub: and thank you for putting up with the hills
17:50:37 <BadCub> It was a pleasure! I am glad everyone had a good time. And we got to welcome betherly to the fold :)
17:50:41 <devananda> lucasagomes: the flag is easy enough to implement inside of ironic, but I have serious concerns about the usaiblity implication for clients
17:50:45 <betherly> Woohooooo
17:50:48 <jroll> lucasagomes: so I think devananda makes a good point, in that it's a third field to look at to determine the state
17:51:05 <lucasagomes> jroll, devananda right yeah I agree that target_ would be ideal
17:51:06 <devananda> lucasagomes: ie, anyone building an interface on top of ironic suddenly needs to account for a whole new field (above a certain api version)
17:51:08 <rameshg87> jroll: determine target state rather
17:51:17 <jroll> rameshg87: the overall state :)
17:51:27 <lucasagomes> just trying to figure how we can actually implement it
17:51:37 <lucasagomes> due the way our global lock current works
17:51:38 <rloo> what if we had a concept like 'queuing events'
17:51:47 <devananda> rloo: indeed .... :)
17:51:59 <lucasagomes> target_provision_state to be a queue?
17:51:59 <jroll> I brought that up before
17:52:02 <jroll> it's super complex
17:52:40 <NobodyCam> would a que'd delete work for what lucasagomes is looking to acomplish?
17:52:45 <rloo> well, i wasn't thinking of target_* being a queue. More like a separate field, with target* reflecting the current action.
17:52:51 <jroll> see top level comments for patch set 7
17:52:56 <devananda> yea, we spent a lot of time (well, at least I did) thinking about how we would do an event / queue based system intead of our current+target system
17:53:13 <rloo> cuz there are problems with queues, eg depending on what events are queued.
17:53:22 <devananda> the API changes for that would be, well, massive
17:53:30 <lucasagomes> devananda, right
17:53:34 <devananda> as it represents a complete shift in how one interacts with the service
17:53:55 <devananda> it's not something we can incrementally add
17:54:03 <rameshg87> and you never know if the queue will be executed or not
17:54:31 <NobodyCam> good poing rameshg87
17:54:36 <NobodyCam> point even
17:54:55 <devananda> rameshg87: in a properly designed event-based system, one does know if the enqueued item is acted upon or times out (because of TTLs and call-backs) ...
17:54:55 <lucasagomes> devananda, one way I was thinking is to have instance as a separated resource
17:55:03 <devananda> rameshg87: split-brain scenarios not withstanding
17:55:12 <lucasagomes> one can create an instance, and then assign it to the node (instance_uuid)
17:55:13 * mrda sounds the bell for 5 minute warning
17:55:18 <devananda> which is where one gets into RAFT or BASE systems
17:55:19 <lucasagomes> and on that instance you can mark as delete
17:55:24 <devananda> anyway ... :)
17:55:27 <NobodyCam> TY  mrda
17:55:51 <devananda> lucasagomes: "instance" as a resource in ironic?
17:56:06 <lucasagomes> devananda, yeah... (I know it's already a "thing" in nova too)
17:56:12 <devananda> cause, well, it's already a resource in Nova. perhaps we just need to change the nova.ironic.virt driver to be able to issue the deletes?
17:56:15 <devananda> heh
17:56:17 <devananda> *re-issue
17:56:23 <jroll> so devananda and I actually talked about this topic a bit at the midcycle
17:56:41 <jroll> and about possibly making the state machine transitions work differently based on (provision_state, target_provision_state)
17:57:00 <jroll> and this could make delete a valid transition for (DEPLOYING, ACTIVE)
17:57:27 <jroll> it might get weird in fsm.py, but that's probably ok
17:57:36 <lucasagomes> jroll, right, but how to make it not racy
17:57:53 <jroll> where's the race?
17:57:55 <rameshg87> jroll: and where would we record the new desired transition ?
17:58:07 <devananda> rameshg87: we'd update target_state
17:58:07 <jroll> rameshg87: it would change target to DELETED
17:58:16 <devananda> ie, (DEPLOYING, DELETED) becomes a valid state
17:58:33 <lucasagomes> hmm
17:58:42 <betherly> Before this meeting ends real quick
17:58:44 <devananda> so that when the current task finishes and calls process_event("done")
17:58:46 <betherly> Wanted to just bring up horizon UI stuff if anyone has heard further on those panels? Otherwise waiting on the UX guys and Piet to be in touch :)
17:58:53 <betherly> Will chase on it this week
17:58:59 <lucasagomes> jroll, I mean, we certainly need to acquire a exclusive lock to do that
17:59:00 <devananda> then task_manager notices that the target_state has changed -- and is now DELETED -- and fires off the next step automatically
17:59:13 <rloo> how would we update target_state if another task has lock on node?
17:59:17 <BadCub> betherly: you can follow up with me on that as well.
17:59:19 <lucasagomes> jroll, when the request comes it will already be locked by another process
17:59:34 <betherly> BadCub: thanks I'll message you :)
17:59:41 <BadCub> :)
17:59:42 <lucasagomes> so 2 process writing to the node simultaneously
17:59:49 <rameshg87> I think we should go back to channel and then discuss
17:59:53 <lucasagomes> I mean same fields
17:59:55 <jroll> lucasagomes: yeah, the locking is where it gets weird, surely it's possible to deal with it
17:59:56 <lucasagomes> yeah chanell
18:00:04 <jroll> cool
18:00:06 <lucasagomes> times' up
18:00:07 <devananda> yep. time's up
18:00:08 <jroll> thanks all
18:00:09 <devananda> thanks everyone!
18:00:12 <BadCub> thanks everyone!
18:00:13 <NobodyCam> thank you all
18:00:15 <mrda> Thanks everyone - nice to chat with you in the meeting!
18:00:16 <jlvillal> Thanks!
18:00:20 <rloo> lucasagomes: so I think we can handle this if we don't do it via periodic task. if eg a task about to finish whatever it was doing before xsitioning to a new state, checks something else...
18:00:23 <devananda> see you all at the same bat time, same bat channel next week!
18:00:28 <devananda> #endmeeting