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