19:01:01 #startmeeting ironic 19:01:02 Meeting started Mon Apr 28 19:01:01 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:03 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 19:01:05 The meeting name has been set to 'ironic' 19:01:13 as usual, the agenda is at 19:01:15 #link https://wiki.openstack.org/wiki/Meetings/Ironic 19:01:28 #topic announcements 19:01:37 o/ 19:01:43 here 19:01:47 first off, this is actually supposed to be the official openstack vacation week 19:02:05 o/ 19:02:08 o/ 19:02:11 o/ 19:02:13 oh 19:02:15 most project's cancelled their meetings - thanks all for sticking around anyway (or not, if you're not here) 19:02:17 well, i'm OUTTA HERE then 19:02:21 please take the rest of the week off :) 19:02:23 hehe 19:02:29 hi 19:02:38 I will be offline thurs-sun 19:02:53 i'm working, i have changes to put up 19:02:57 also: the summit is just two weeks away,a nd most projects have already published their session schedules 19:03:06 i'm about done with taht task_manager refactor for multiple-nodes -> single-node 19:03:14 comstud: awesome! 19:03:14 comstud, w00t! 19:03:26 only tests to fix 19:03:47 if anyone sees a session conflict, please let me know 19:04:01 looks good so far devananda! 19:04:07 #link http://junodesignsummit.sched.org/ 19:04:52 #topic sub-team reports 19:05:03 adam_g: hi! 19:05:08 hey! 19:05:13 adam_g: looks like the ironic-virtual test has been mostly passing! 19:05:16 awesome job on that! 19:05:37 yeah, finally! check-tempest-dsvm-virtual-ironic. will propose to make it voting next week if it proves stable 19:05:49 woot! 19:05:50 if you see it failing in the meantime, please investigate or ping me 19:06:03 adam_g: are you tracking the job's failures somewhere? 19:06:06 adam_g, good stuff, will do 19:06:32 devananda, im not, i plan to get some script together to do that. 19:06:40 adam_g, great! I think I've seen some strange failure, but can't find while Gerrit is down 19:06:41 since we'll be running it across many projects 19:07:27 adam_g: logstash might be an easy place to start 19:08:04 dtantsur: did I see you comment earlier that ironic is passing on F20 now? 19:08:05 devananda, ah, yeah. good call 19:08:29 devananda, yes! At least tempest/scenario/test_baremetal_basic_ops.py 19:08:37 (I am not sure what to try next) 19:09:14 I also created a new etherpad for tracking Fedora: https://etherpad.openstack.org/p/IronicTestingOnFedora 19:09:42 dtantsur: what's the status of getting F20 tested upstream? 19:09:55 dtantsur, beside the API tests, there isn't much else ironic specific in tempest. if we can get the agent deployable with devstack we can look at extending the current basic_ops to cover the agent as well 19:10:03 As you see there, 2 patches are still required for devstack 19:10:12 dtantsur: it'd be great to get a non-voting job going 19:10:20 adam_g: we're working on that right now :) 19:10:33 adam_g: what do you think of folks extending the ironic tempest suite? 19:10:44 Also, while a lot of work was done with supporting SELinux enforcing and proper firewall, it's less tested, I think 19:11:09 adam_g: eg, to start validating more interestign functions (partitioning, ephemeral, etc) and integration (neutron floating-ips, for example) 19:11:22 devananda, +1 19:11:39 i think that'd be a ironic_advanced_ops test? 19:11:50 but we should brainstorm about what specifically we want to test 19:11:58 and what we actually can test 19:12:11 https://etherpad.openstack.org/p/IronicCI would be a good place for that 19:13:59 adam_g: mind starting that discussion on the list? 19:14:12 devananda, sure! 19:14:22 thanks! 19:14:35 jroll: hi! any updaets on the agent? 19:14:42 hi! 19:14:55 so, we've been continuing work on the main patch for the driver 19:15:06 JoshNang is working on a devstack setup 19:15:30 and enabling us to test in parallel with the pxe driver, do tempest CI, etc 19:15:41 awesome 19:15:53 i'm also adding neutron support from the patch that factors it out of pxe 19:15:54 I think that's mostly it 19:15:56 jroll, how is that going? i remember reading reports last week of chairs being thrown and desks being flipped 19:16:04 https://review.openstack.org/#/c/90233/ <-- factoring 19:16:06 heh 19:16:18 only 2 injuries sustained 19:16:26 jroll: JayF: what about approving this bp https://blueprints.launchpad.net/ironic/+spec/ironic-python-agent-partition? are there any objections? 19:16:47 let me look, I haven't seen an update since my last comment 19:17:09 ah, I'll leave that tab open for a review after meetinglunch is over 19:17:10 JayF: ok, thanks 19:17:29 vkozhukalov: also, devananda needs to approve that, I don't believe we have access to do so 19:18:00 devananda: could you please take a look too? 19:18:03 yes. let me look it over after the meeting. I see a lot more detail than when I last looked 19:18:09 jroll: JayF the same question about https://blueprints.launchpad.net/ironic/+spec/ipa-discovery-ext 19:18:31 I'll look at that as well after meetinglunch 19:18:48 agordeev2: right. I think JoshNang pinged you about it, but our pluggable hardware manager thing should cover most of that functionality 19:18:50 JayF: jroll TY 19:18:54 as an aside, I want to point folks at the monday morning talk on IPA 19:18:57 #link http://openstacksummitmay2014atlanta.sched.org/event/754c3678d31f9f74e020b9a1e6f4dece 19:19:07 agordeev2: I can leave more detailed notes on the etherpad, though 19:19:08 (should have pasted taht in announcements...) 19:20:15 #topic vendor passthru 19:20:31 not much to say on taht topic -- it landed last week 19:20:46 \o/ 19:20:50 :) 19:21:05 #topic allow CLI to trigger a deploy 19:21:08 hm, hm, OS weeks start on Thursdays... technically vacation week isn't until this Thursday 19:21:18 slackers 19:21:51 comstud: ahh... well. my vacation starts on thursday too, though somehow I missed that openstack defines a week as starting on thursday 19:21:56 I think the last time we talked about it we decided that the trigger wouldn't exist in the CLI only lib 19:22:01 https://wiki.openstack.org/wiki/Icehouse_Release_Schedule 19:22:08 (sorry to sidebar current topic.. plz continue :) 19:22:41 comstud: i would point ot that the summit does not start on may 15th 19:22:46 yeah 19:22:57 well, this is open to interpretation I guess.. so this week and next week are vacation weeks 19:22:58 fine by me 19:23:00 comstud: those dates are based on when releases are tagged, not the actual "week" 19:23:01 :) 19:23:26 ok 19:23:39 lucasagomes: right. i still feel that we shouldn't enable the CLI to start/stop deploys 19:23:57 yeah 19:23:59 i'm not sure who added that to the agenda -- perhaps they're here and can explain the motivation? 19:24:05 anyone thinks it's a good idea to have a way to trigger the deploy directly from the CLI? (w/o proxying through nova) 19:24:24 I added after commenting on a patch 19:24:30 that is proposing it to be added to the cli 19:24:33 oh 19:24:39 who proposed that change? 19:24:57 #link https://review.openstack.org/#/c/89301/ 19:25:04 Yuiko Takada is his name 19:25:08 idk the IRC name tho 19:25:33 gotcha 19:26:15 #action devananda to follow up on https://review.openstack.org/#/c/89301/ and clarify that the CLI should not have set-provision-state 19:26:34 i'm going to skip the partition-api topic because we alraedy covered that 19:26:37 and i need to review the BP 19:26:53 #topic oslo sync status 19:27:02 that's me 19:27:12 GheRivero: o/ 19:27:24 I did some cleaning on the oslo dependencies https://review.openstack.org/#/c/90670/ 19:27:58 regarding oslo.test.... we are not using it at all, althoug it was on the list of the dependencies. Removed ^^ 19:28:23 and oslo.db should be on the way now that gerrit is updated 19:28:42 so if there is no week off, should start landing before the summit 19:28:42 we landed lucas' oslo.messaging patch last week too 19:28:53 I saw. Thanks lucasagomes 19:29:00 GheRivero, :) np 19:29:41 no more big change in the short term 19:30:24 great 19:30:57 I'd like to take a few minutes for console support 19:31:02 #topic console support 19:31:26 #link https://review.openstack.org/#/c/64100/ 19:31:40 mostly because this is a very long-lived patch, which is also a really useful feature 19:31:52 #topic console support 19:32:00 Also a graduation requirement, no? 19:32:06 matty_dubs: yep 19:32:09 I tested this with HP server, works OK 19:32:54 devananda, I am working on it per your comment 19:32:58 yuriyz: awesome. looks like matty_dubs also tested it -- thanks guys! 19:33:37 anyone have questions / concerns about it prior to landing, once the remaining few nits are addressed? 19:34:31 k, well, pls comment on the review if you do -- i just wanted to draw attention to it :) 19:34:39 #topic open discussion 19:35:34 hi 19:35:36 denanada, after it gets landed, I'd like to add the console support for ipminative + shellinabox 19:35:41 I'd like to talk a bit about neutron integration 19:36:11 and ipminative + confluent. 19:36:22 devananda: do we need more cores? i've had a patch up since 4/2 :) 19:36:24 linggao, ipmnative is not stable yet 19:36:32 linggao: cool, i think ipminative+shellinabox is great as a separate patch 19:36:49 comstud: yea -- three of our cores are less active than I'd like right now. 19:36:51 devananda yes. 19:37:02 comstud: I will be reviewing reviewer stats later this week 19:37:09 ok cools 19:37:16 yuriyz: "not stable" -- please clarify 19:37:20 yuriyz, ipminative needs more testing. 19:37:34 morgabra: sure! what's on your mind 19:37:50 devananda: AFAIR there were problems with permissions 19:37:51 Neutron question #1: Is there functionality that ironic will need from neutron that currently doesn't exist? 19:38:00 ipmnative fail in my tests after 5-7 power operations 19:38:10 linggao: what is confluent in this context? I know of the company by that name, not a terminal service ... 19:38:45 morgabra: ooh. a few things come to mind. it'd be great to have some discussions at the summit, too 19:38:50 morgabra: pluggable dhcp back-ends 19:39:02 +1 19:39:16 i believe we'd have an interest there:) 19:39:17 morgabra: actually let me prefase all this with "i'm not a neutron dev, so maybe this stuff already exists" :) 19:39:28 morgabra: I'm looking for some improved Neutron port integration, currently in thinking level. See https://blueprints.launchpad.net/ironic/+spec/access-port-discovery 19:39:31 devananda confluent is a server wrote by jbjohnso that does the communication through http. 19:39:36 morgabra: hw switch config for lockign down traffic on ports 19:39:45 morgabra: port discovery 19:40:11 there's also that race condition on the port update 19:40:17 linggao: devananda: so, I ask because as part of discovery I've already made a plugin that looks very similar to that blueprint 19:40:27 devananda, I'll ask jbjohnso to talk to you about it. 19:40:30 https://github.com/rackerlabs/ironic-neutron-plugin 19:40:37 linggao: I was going through the ssh driver, and realized we could possibly implement serial support there at some point, too -- after 64100 merges, of course 19:40:46 obviously this isn't suitable to use, but I think I've learned enough to ask the right questions 19:40:59 gmatefi: we were just poking at lldp things in the agent this morning 19:41:02 fwiw 19:41:02 matty_dubs, yes. 19:41:44 so getting port discovery into ironic would require a patch to neutron with this extension no? 19:41:52 morgabra: can you clarifythe opening statement from the readme: "neutron plugin that is suitable for managing an ironic deployment" 19:42:07 morgabra: by "managing" do yuou just mean enrolling hardware with ironic? 19:42:23 devananda: I can explain my specific use case 19:42:41 morgabra: please do :) 19:43:08 linggao: thanks. we also need to talk about test requirements for pyghmi at some point 19:43:10 in that we have a cab of hardware that is plugged into some number of ToRs (switches) 19:43:34 devananda, sure 19:43:42 we wanted to be able to configure the physical switchports to allow access to a particular vlan 19:43:51 devananda: morgabra is part of our team, btw, if that clarifies anything :) 19:43:58 of which there didn't seem to be any mechanism build into neutron to do so 19:44:14 jroll: thanks. that helps 19:44:31 which obviously requires mapping chassis (hosts?) to said switchports 19:44:52 and I apologize my thoughts aren't well formed 19:45:05 what I am looking for is to signal binding:vnic_type = VNIC_DIRECT to Neutron for a NIC id 19:45:30 and then support Neutron ML2 plugin to resolve NIC ID directly for TOR port if direct NIC is requested 19:45:55 the access port discovery BP could be a tool to support the DB build-up 19:46:06 morgabra: i think you mean "mapping node and its ports to said switch's ports" 19:46:41 there is support in tripleo today for the undercloud instances to get VLAN tag data via heat / cloud-init 19:46:56 devananda: correct 19:47:01 obviously this is soft -- and only suitable for trusted tenant, which the undercloud is 19:47:24 for multitenancy, yea, we need ToRs to do the VLAN tagging, not the host 19:48:02 I wouldn't neccessarily assert that sending tagged vlans down to an untrusted tenant is a bad idea 19:48:04 also in some cases for trusted ones, to protect from unwanted / DoS traffic 19:49:05 JayF: sending tagged vlan membership to an untrusted tenant may be fine -- but the ToR still needs to not trust the traffic coming from that node after it boots into the user's instance 19:49:16 anyway ,the integration point here is not just neutron<->ironic 19:49:19 it also involves Nova 19:49:32 since that is "coordinating" placing a tenant / instance onto the node 19:50:08 right 19:50:09 Nova gathers the node's metadata, including its NIC MAC addresses, and passes that to Neutron 19:50:23 the only interaction from ironic -> neutron today is setting the DHCP BOOT options 19:50:25 JayF: in some cases, sending tagged traffic is a must-have. I.e. in contrast to virtual cases, where (theoretically) multiple vNICs could be cretated, here we are limited by the physical NIC and VLAN support might be needed 19:50:55 I would also like to see port-mac filtering in ToRs 19:50:58 to prevent spoofing 19:51:11 and other bad-tenant-behaviors 19:51:20 gmatefi: I completely agree. For instance, if you want the user to have both an 'internal' and 'public' network available in a situation with only one physical (or logical, in the case of teaming/bonding) interface. 19:51:43 devananda: where does nova hit neutron today? I don't see it in our virt driver 19:51:53 and offhand, the only neutron-to-ironic information flow that I see is for discovery 19:51:59 jroll: it's not in the virt driver, it's in compute.manager 19:52:03 ah 19:52:03 devananda: as long as ironic needs a dedicated VLAN for agent operation, some interaction might be needed 19:52:09 jroll: happens before .spawn() is called IIRC 19:52:22 gmatefi: ahhh. you're right. 19:52:55 gmatefi: well. we need at least a "default VLAN" where the agent(s) and ironic-conductor and glance can talk to eachother 19:53:05 devananda: right. we're trying to figure out where these integration points should happen 19:53:25 like, morgabra's thing tells neutron to link a port to a vlan or whatever 19:53:27 or unlink 19:53:35 gmatefi: if that is untagged, then it should be fairly simple: when deleting an instance, remove that port's VLAN tag 19:53:40 where should that call happen? nova side or ironic side? 19:53:43 nova 19:53:49 well 19:53:55 heh 19:54:20 i should refresh my memory of compute.manager before answering that so hastily 19:54:48 all the deploy/agent operations are kinda outside of nova's usual view of the world 19:55:05 so the only kicker is the host <-> switch port discovery and/or mapping 19:55:13 there's a neutron blueprint for it 19:55:36 but should we use that extension in ironic? 19:55:39 discovery to me means: new hw is racked and cabled, and something enrolls it with ironic 19:55:40 or make that part pluggable? 19:56:02 devananda: we were thinking of using LLDP on the agent 19:56:07 devananda: yes, I am also looking for some "default VLAN" or similar concept for ironic ports, needs to be aligned somehow with neutron model 19:56:40 morgabra: i assume you mean on the neutron agent 19:56:42 (not IPA) 19:56:57 no, in IPA 19:56:57 devananda: there is no neutron agent right? 19:57:02 in this case? 19:57:27 hmm 19:57:34 Basically we have to know what physical port on the switch the node IPA is running on is plugged into 19:57:45 and there's no way to make that connected except LLDP or external metadata 19:57:47 have the agent (which would boot because the hardware MAC is unknown) use LLDP to determine whcih switch port it's cabled to 19:57:56 exactly 19:57:57 right 19:58:10 where would the node port <-> switch port assoc be stored? 19:58:14 neutron or ironic? 19:58:32 ironic 19:58:33 devananda: well, that's part of what I'm trying to figure out. It has to be in neutron 19:58:38 right 19:58:43 in my view, it needs to be supplied to Neutron plugin in some way 19:58:46 hm... 19:58:51 neutron switchport -> MAC 19:59:08 and MAC -> ironic port -> ironic node 19:59:25 mac is already forwarded by nova to neutron on port create 19:59:26 ironic doesn' thave a concept of switchport. and neutron doesn't have a concept of physical node 19:59:30 MAC is the common ground 19:59:40 I don't like codifying mac at the common ground 19:59:46 so, if Neutron can resolve mac->switch port, then the concept works 19:59:47 because it can change over the life of a node 19:59:55 if a NIC is replaced, as the obvious case 20:00:05 JayF: so can the swichport a MAC is pluggd in to 20:00:26 actually, not the mac is the critical, but to forward a unique NIC identifier 20:00:38 time's up -- 20:00:49 python-agent does not have any authorization for commands, is this good? 20:00:54 let's continue in channel - -this is pretty interesting :) 20:00:57 let's take this to #openstack-ironic 20:01:06 thanks everyone! see you in two weeks! 20:01:08 #endmeeting