19:01:39 #startmeeting ironic 19:01:40 Meeting started Mon Jul 7 19:01:39 2014 UTC and is due to finish in 60 minutes. The chair is devananda. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:01:42 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 19:01:44 The meeting name has been set to 'ironic' 19:01:54 hi all! as usual, the agenda can be found here 19:01:55 #link https://wiki.openstack.org/wiki/Meetings/Ironic 19:02:07 o/ 19:02:27 p/ 19:02:40 #chair NobodyCam 19:02:41 Current chairs: NobodyCam devananda 19:02:48 \q JayF 19:03:08 I dont think there are any big announcements from last week 19:03:30 and hopefully by now everyone is aware of and (if you'r going) has already made arrangements for the mid cycle 19:03:53 any questions, speak up now before we move on to release cycle progress report 19:04:34 devananda: I told that in the chat but will say it again. 19:04:36 i look forward to seeing every one htere 19:05:09 ok, moving on 19:05:10 I won't be able to be there. Last minute I realised that budget for my trip was not approved 19:05:19 romcheg: ah, bummer :( 19:05:20 :'( 19:05:26 :( 19:05:31 #topic release cycle progress 19:05:34 #link https://wiki.openstack.org/wiki/Juno_Release_Schedule 19:05:53 the J2 milestone is two weeks from now 19:06:13 it's just a milestone tag, not much to do, but ... 19:06:14 oh oh so soon. 19:06:44 there are a few specs we ought to land (and implement, since the code is nearly done too) 19:06:49 we need spec reviewa 19:06:54 reviews even 19:07:15 which specs devananda ? 19:07:22 and the meeting is the week after that, so I would really like us to have the specs in shape for J3 by the end of the midcycle (iow, by July 30) 19:07:44 rloo: I'd like to get your API work in by J2 -- think that's possible? 19:07:45 rloo: I'm basing my reviews on : https://docs.google.com/spreadsheets/d/1Hxyfy60hN_Fit0b-plsPzK6yW3ePQC5IfwuzJwltlbo/edit#gid=1357128775 19:07:48 #link https://docs.google.com/spreadsheets/d/1Hxyfy60hN_Fit0b-plsPzK6yW3ePQC5IfwuzJwltlbo/edit#gid=1357128775 19:08:09 devananda: it is possible IF the spec is approved this week and IF the code is reviewed and approved by J2 :-) 19:08:34 rloo: I've +2'd the spec and asked lucasagomes to revie it tmw 19:08:42 rloo, I will review it tomorrow morning 19:09:00 devananda: ok, code will be ready for review by wed at the latest then ;) 19:09:03 o/ 19:09:05 JoshNang: ditto for the swift tempurl spec. I've +2'd, if it's +A'd, do you think the code is ready in the next week or so? 19:09:07 I'm not really here sorry 19:09:19 haha, we have lifeless' ghost. 19:09:47 devananda: it should be 19:09:53 great, thanks 19:10:06 i should be able to get the python-swiftclient patch in this week. i'll bug them :) 19:10:16 we are going to need someone working on grenade testing 19:10:33 and folks working on deployer-focused docs 19:10:51 not immediately, but if we dont start those soon, we'll be in bad shape 19:11:01 can't we wait on the deployer-focused docs until after j3? 19:11:13 both are necessary for graduation, which will be checked soemtime between J3 (feature freeze) and release 19:11:31 rloo: we did that last cycle, and what i've noticed is that we have a lot of users right now who are grasping at straws 19:11:36 We also have people asking in IRC fairly often about developer-doc-y stuff, so it might be beneficial. 19:11:37 romcheg: did I see you working on grenade testing this morning? 19:11:39 rloo: because the deployer docs we have aren't adequate 19:11:42 aka, what devananda just said ;) 19:11:48 matty_dubs: exactly 19:11:50 NobodyCam: yes you did 19:11:51 true 19:11:59 :) 19:12:07 yeah, i agree they aren't adequate. i thought matty_dubs was going to update his blog? 19:12:13 romcheg: great TY 19:12:17 I am actually actively revising my blog post that kind of does this; I'm happy to also use that as the base for 'real' docs, and/or help with something else 19:12:31 matty_dubs: awesome. real docs would be great 19:12:31 thx for volunteering matty_dubs ! 19:12:45 Though mine's presently with devstack, which probably isn't something people would use in production 19:13:00 NobodyCam: But it would be really nice if some one came and helped me with that big piece of code w/o docs :) 19:13:03 btw, would like to add address the iPXE work here. There's the spec and patches upstream, and it's possible to test it using devstack and nested VMs like we do in gate 19:13:07 (But we can sort that out offline) 19:13:08 that's it for my progress report 19:13:43 #link https://review.openstack.org/99677 (for devstack) 19:13:47 #link https://review.openstack.org/99318 (for ironic) 19:14:04 lucasagomes: links are for? 19:14:10 NobodyCam, iPXE work 19:14:10 #info J2 is two weeks away. we'll try to land 98904 and 102914 specs and corersponding code by then (swift temp url + api for driver_info) 19:14:36 devananda: maybe agent driver too? :) 19:14:53 I've got devstack testing nearly working with it... think I'm running into code issues at this point 19:14:58 jroll: I want to look more deeply at the agent driver during the midcycle 19:15:10 alright 19:15:15 jroll: and try to land it then, which is just after j2 19:15:41 :) 19:16:06 lucasagomes: awesome, i'll take a look at the ipxe spec/code this week 19:16:13 ack :) 19:16:18 thanks 19:16:20 #info we'll also try to land the ipxe spec and code by j2 as well 19:16:44 fwiw, that was very high on our priority list at the start of Juno, and it enables several other features 19:16:47 devananda: I assume we also have to land nova=>ironic migration spec too? 19:16:48 so landing sooner is better 19:16:56 devananda: is that on the google doc spreadsheet? 19:17:01 romcheg: that's up to Nova's team. I'll continue working on that 19:17:02 ah, just one thing... after apply the patches you have to enabled iPXE on the localrc for devstack, so you need to set IRONIC_IPXE_ENABLED=True and the rest is the same, just follow our deploy guideline 19:17:20 ok, taht's all for the milestone progress 19:17:24 let's move on to subteam status 19:17:28 NobodyCam: the iPXE is #20 in google doc 19:17:39 ack 19:17:42 rloo: TY 19:18:04 #info no significant progress last week on the nova driver code. still pending a few patches and waiting for Nova team to review. 19:18:08 #topic subteam status reports 19:18:41 Shrews, adam_g: hi! can yo usummarize the tempest activity from last week? 19:18:46 we had a long and generally productive chat with -qa folks yesterday 19:18:54 Can we try to land iLo power and virtual media drivers in J2? 19:19:08 and came away with some actionable work items for the rest of the cycle that should get our CI testing better aligned with expections of the -qa team 19:19:14 summarized here https://etherpad.openstack.org/p/IronicCI 19:19:17 #link https://etherpad.openstack.org/p/IronicCI 19:20:03 and making some dents in the tempest api tests... though running into stuff where it's questionable whether the change should be in ironic's nova driver or tempest itself 19:20:15 wanyen: you had nearly 15 minutes to bring up specs to discuss. Sorry, we've moved on in the meeting to subteam reports. Feel free to bring that up in the open discussion, though. 19:20:16 not much else, Shrews and i have been chipping away at the test suite's API tests to make them runnable against ironic 19:20:40 good stuff -- thanks guys! 19:20:43 deva: okay. 19:21:10 dtantsur is on vacation this week I believe, so we're missing the bug team 19:21:22 adam_g: I noticed the thing about shrinking DIB ramdisks... how much ram are we assuming devstack gets here? 19:21:41 fairly certain agent ramdisk is even larger 19:21:53 jroll, the jenkins devstack slaves are cloud instances with 8GB 19:21:56 jroll: and IPA does things out of a ramdisk, and has to be able to hold the whole image in ram (at a minimum) 19:22:11 JayF: ehhhhh I'd like to change that 19:22:13 jroll, we're aiming to get the DIB produced pxe deploy-ironic ramdisks down to 512M per node 19:22:18 adam_g: ok 19:22:22 at minimum, AIUI, we need to be able to run 3 instances in parallel 19:22:31 and for "parallel" tempest testing, 6 instances 19:22:37 wait... I think IPA is under 512 already 19:22:40 JayF: ? ^ 19:22:44 compressed? 19:22:44 IPA is well under 512MB for download 19:22:51 but ram usage is much higher than that 19:22:56 ah, right 19:22:57 right, so deploy-ironic is < 100 compressed 19:23:05 yeah 19:23:09 JayF, oh, it downloads and convert the image in ram? 19:23:31 175M compressed for IPA 19:23:32 jroll: if RS is willing to donate larger resources to -infra for testing Ironic, that may help too 19:23:36 ok, I'll make a note and see what we can do. thanks adam_g 19:23:39 devananda: :) 19:23:40 JayF: ouch 19:23:46 lucasagomes: absolutely, we persist *nothing* to local storage (or even assume that we ahve local storage) 19:23:51 its less than I expected 19:24:45 Honestly, I think optimising for RAM in a deploy ramdisk isn't a super great use of time, so I'll ask some folks on this end about donating resources for ironic testing 19:24:55 jroll: any updates on ipa driver from last week? 19:25:22 devananda: we're working on some advanced features, as well as devstack testing 19:25:42 I think I have the required changes for devstack and running into ironic code issues at this point 19:25:47 s/ironic/agent driver/ 19:26:05 Jroll: what advanced features? 19:26:23 wanyen: decommissioning, etc 19:26:26 wanyen: for instance, the decom spec JoshNang is workign on 19:26:37 network isolation 19:26:43 jroll: sounds good. how up to date is https://etherpad.openstack.org/p/ipa-todos ? 19:26:44 tx 19:27:08 wanyen: https://review.openstack.org/#/c/102685/ 19:27:09 devananda: not terribly :) will update today 19:27:24 #link https://etherpad.openstack.org/p/ipa-todos 19:27:35 jroll: thanks! or if you have another site you are tracking IPA progress on, pls link it from the whiteboard 19:27:58 that etherpad should be fine, I just have been ignoring it 19:28:30 I'll be sure to update it today, and then before next meeting 19:28:38 #info discussion last week with openstack-qa team led to actionable work items for Ironic team to help align CI efforts. Shrews and adam_g continuing to make progress improving test coverage. 19:29:01 #info looking into lowering RAM requireemnts for deploy-ironic agent 19:29:28 jroll: is the ipa-enabling code for devstack up anywhere yet? 19:30:00 adam_g, devananda: quick question, how many nodes do you think would be good for an ironic CI environment 19:30:07 devananda: not yet, will be later today 19:30:16 jroll: want an action item? 19:30:20 fyi: 1/2 way point for the meeting...beep 19:30:34 jroll: that reallyd epends on what you want to test 19:30:35 jroll, for use with tempest? 19:31:07 devananda: https://gist.github.com/jimrollenhagen/db9230f04a817a87619a is the devstack patch 19:31:28 devananda, adam_g: if we forwarded all tempest tests to an environment with more ram... 19:31:37 #action jroll to post a review adding IPA-driver support to devstack later this week 19:31:40 how many, say, 16 or 32 gb nodes would we need 19:31:56 jroll: let's follow up on that after the meeting -- we can probably discuss it for a while 19:32:01 sounds good 19:32:11 just thinking rough numbers, but after is fine :) 19:32:13 jroll: as it depends on multiple things (mostly on what and how often you want to test) 19:32:24 right, I'm talking about zuul\ 19:32:30 with existing jobs 19:32:30 GheRiver1: hi! any updates from oslo last week? 19:32:35 but let's move on :) 19:34:14 hm... we'll come back to oslo if GheRiver1 is around 19:34:17 romcheg: hi! any updates on the nova->ironic db migration? or grenade testing? 19:34:27 There are some :) 19:34:55 So both of the tools are in the state how I think they should be so you are welcome to take a look 19:35:18 romcheg: links? 19:35:24 1se 19:35:26 sec 19:35:49 #link https://review.openstack.org/#/c/101920/ data migration tool 19:36:04 #link https://review.openstack.org/#/c/102563/ flavor update tool 19:36:26 Should I create entry points in Nova for them? 19:36:40 #info nova -> ironic database migration and flavor update tools ready for review and testing 19:36:57 romcheg: I re-submitted the spec for those this morning with the two minor fixes you pointed out 19:37:16 So after installing Nova Juno users will be able to run a command like nova-migrate-db-to-ironic --params 19:37:24 i don't expect much disagreement from Nova since the main driver spec was already approved 19:37:26 devananda: I'm reading that. 19:38:08 Large texts take more time to read them since I'm not an English speaker :) 19:38:23 romcheg: changes were very small - fix the link and s/glance/nova/ on one line 19:39:18 since GheRivero doesn't seem to be here, I'll try to give an update instead 19:39:29 Yes, that's good but I'm trying to make sure there are no other inaccuracies or ambiguous things 19:41:15 IIRC, a new version of oslo.db should be coming out soon, with fixes to the migration tests 19:41:30 but nothing specifically affecting us changed last week 19:41:52 that's it 19:42:08 #topic open discussion 19:42:39 I would like to talk about landing ilO power and virtualmedia driver in J2 19:43:09 wanyen: hi! I have +2'd the ilo power spec. once it has another +2, I'll approve it 19:43:25 i need to take another look at the virtualmediad deploy driver 19:43:44 iLo pwoer spec and ilo power driver code have been submitted for sometime. dtantsur approved the earlier versioj of the power spec 19:44:17 deva: dtantsur also approved the ilo power code. 19:44:31 wrt approving the code for these drivers. devananda: what kind of tests need to be in place if any? are they mentioned in the resp. specs? 19:45:32 rloo: they definitely need sufficient unit test coverage 19:46:04 devananda: ok, no 3rdparty CI then. 19:46:17 rloo: as far as third-party CI on real hardware, most of the driver specs I've seen have included a note asying "we can't do this right now" 19:46:28 rloo: i think the spec should include the author's expectation 19:47:00 devananda: thx. 19:47:29 how we indicate to users which drivers are tested to what degree -- I'm going to stick that on the agenda for the midcycle :) 19:48:34 deva: ilo virtual media code is ready to submit. We need approval for the spec. 19:49:08 are there any thoughts on how we can try spec dependencies? 19:49:13 wanyen: ack. I'll look at them as soon as possible 19:49:14 wanyen, I will take a look at the spec 19:49:16 NobodyCam: what do you mean? 19:49:16 s/try/track/ 19:49:17 wanyen: you can submit the code before the spec is approved :) 19:49:25 great! Thanks! 19:49:43 we have specs thats are starting to depend on each other 19:49:44 (it just won't be looked at as much) 19:49:58 NobodyCam: is there something wrong with that? 19:50:07 excuse me, can we discuss about https://review.openstack.org/#/c/104738/3/ironic/common/neutron.py ? 19:50:11 wanyen: also, i'm curious about something -- there seem to be duplicate specs from HP for advanced iLO features 19:50:23 jroll one could land before the other 19:50:37 NobodyCam: that seems natural to me. git/gerrit allow us to represent taht dependency easily enough 19:50:44 NobodyCam: I mean. use gerrit. use git. 19:50:44 jroll: yes. We are maing minor changes to address commetns. So, we will submit the code soon. 19:50:46 as example https://review.openstack.org/#/c/100951 19:51:03 NobodyCam: also don't be afraid to tell folks to make something a dependency 19:51:04 NobodyCam: if one spec depends on another, the spec could land, but the related code won't/shouldn't if it depends on the code of the dependent spec. 19:51:24 see comments on ^^^ 19:51:36 I think they are dependent 19:51:44 author seems to think noe 19:51:46 not 19:51:56 tell the author they are wrong 19:52:00 if you think they are 19:52:07 or ask for other opinions 19:52:16 work it just like code review 19:52:16 been trying 19:53:05 takadayuiko_: hi! I'm looking at taht patch - what is your question? 19:53:36 oh the config deprecation strategy... there's one for openstack? or projects do it differently? 19:53:58 there definitely is one for openstack, and we definitely should be following it 19:54:28 even though irnoic isn't integrated, we have users who are affected by us, and we need to consider upgrades and backwards-compatibility issues 19:54:32 NobodyCam: Basec on my understanding , the generic hw discovery bit does not cover user initiate discovery 19:54:39 really those are orthogonal to integration 19:54:39 devananda, thank you. I asked to lifeless and understood what is the problem, backword compatibility , right? I want to listen your ideas 19:54:44 s/basec/based 19:55:29 NobodyCam: 102565 spec has a reference at the bottom to 100951 spec. see line 29: https://review.openstack.org/#/c/102565/11/specs/juno/generic-hardware-discovery.rst 19:55:37 wanyen: it was this line that cought my eye: It will add inventory as a new field to the node object as proposed by https://review.openstack.org/#/c/102565 19:56:38 takadayuiko_: http://docs.openstack.org/developer/oslo.config/opts.html#oslo.config.cfg.DeprecatedOpt 19:57:06 NobodyCam: I think dtantsur proposed that all discovered node proerties to be stored in the inventory fields. 19:57:31 wanyen: and you're depending on that proposal 19:57:37 wanyen: yes in 102565 19:57:51 NobodyCam: we can do that. I thouhgt IPA already has that field added 19:57:58 -> 2 minute warning 19:58:02 :) 19:58:06 ty JayF 19:58:32 wanyen: IPA driver doesn't have an approved spec either, so same situation :) 19:58:51 wanyen: that said, we haven't added a new column, just using extra 19:59:27 devananda: mm, do you mean that it's better to have both url and neutron_host, neutron_port, neutron_protocol? 19:59:47 wanyen: TY 20:00:04 takadayuiko_: when removing an option, you must include a deprecation path. same for renaming as well. 20:00:19 beep times up 20:00:20 takadayuiko_: irrespective of whether i think that is a good change, it will break deployments 20:00:24 jroll> ok. we are fine to use the new inventory field. But I do have cocnerns that if the generic hw bit spec/code does not land then no oneelse can land their hew discovery cdoe? 20:00:35 to #openstack-ironic 20:00:39 thanks everyone! talk with you all again next week! 20:00:44 thanks chairs :) 20:00:46 great meeting 20:00:48 #endmeeting