Monday, 2014-07-21

*** chuckC has quit IRC00:14
*** zul has quit IRC00:20
*** zul has joined #openstack-ironic00:24
*** mitz has joined #openstack-ironic00:26
*** rainya has joined #openstack-ironic01:24
*** pcrews has joined #openstack-ironic01:29
*** Haomeng has quit IRC01:35
*** pcrews has quit IRC01:43
*** pcrews has joined #openstack-ironic01:51
*** rainya has quit IRC01:53
*** rainya has joined #openstack-ironic01:56
*** chuckC has joined #openstack-ironic02:00
*** pcrews has quit IRC02:28
*** chuckC has quit IRC02:42
*** ramineni has joined #openstack-ironic03:03
*** eghobo has joined #openstack-ironic03:17
*** chuckC has joined #openstack-ironic03:27
*** chuckC has quit IRC03:30
*** Nisha has joined #openstack-ironic03:56
*** Poornima|mtg has joined #openstack-ironic04:16
*** eghobo has quit IRC04:16
*** eghobo has joined #openstack-ironic04:17
*** Poornima|mtg is now known as Poornima_04:19
Nobodycam_afkmorning mrda04:30
*** Nobodycam_afk is now known as NobodyCam04:33
mrdaHey NobodyCam04:35
NobodyCam:) just checked into hotel in raleigh04:42
mrdayay! Have a great sprint NobodyCam04:47
mrdaLooking forward to seeing you and everyone else in Hillsboro next week04:47
*** chuckC has joined #openstack-ironic04:48
NishaMorning NobodyCam :)04:49
NobodyCammrda: ya; Nisha: Good morning04:50
NishaNobodyCam: :)04:51
*** rakesh_hs has joined #openstack-ironic05:05
*** eghobo has quit IRC05:13
*** rakesh_hs has quit IRC05:22
*** shausy has joined #openstack-ironic05:22
*** rakesh_hs has joined #openstack-ironic05:24
*** bvivek has joined #openstack-ironic05:35
*** rameshg87 has joined #openstack-ironic05:36
dtantsur|afkGood monday morning, Ironic :)06:02
*** dtantsur|afk is now known as dtantsur06:02
*** k4n0 has joined #openstack-ironic06:16
mrdahi dtantsur06:16
Nishahi dtantsur : please look at the https://review.openstack.org/#/c/100951/ i have addressed your comment06:21
*** pradipta_away is now known as pradipta06:28
dtantsurNisha, mrda, hi06:34
dtantsurNisha, ack, when I have some time06:34
*** pcrews has joined #openstack-ironic06:38
rameshg87dtantsur: good morning06:39
*** Haomeng has joined #openstack-ironic06:39
rameshg87dtantsur: just had a question06:39
dtantsurrameshg87, morning06:39
rameshg87dtantsur: currently we have tftp server running on each conductor node, right ?06:40
rameshg87dtantsur: i am wondering whether tftp service can be moved to neutron, something like n-tftp; it seems a network service just like neutron-dhcp06:41
*** eghobo has joined #openstack-ironic06:41
dtantsurrameshg87, not necessary on each, but likely yes06:41
dtantsurrameshg87, I doubt it. Neutron is about managing networks for instances, TFTP is about deploying instances, just what we do06:42
*** eghobo has quit IRC06:42
rameshg87dtantsur: so currently we don't need to have tftp service running on every conductor node ? can 2 conductor nodes share a tftp service ?06:42
rameshg87dtantsur: based on this code, it look like we always need a tftp service for a conductor node: https://github.com/openstack/ironic/blob/master/ironic/common/tftp.py#L45-L5106:43
dtantsurrameshg87, no, each conductor that _requires_ tftp must have it's own06:44
dtantsurrameshg87, but if conductor does not manager PXE nodes, it's not required to have TFTP server :)06:44
rameshg87dtantsur: ah okay ..06:44
*** pcrews has quit IRC06:44
rameshg87dtantsur: i have seen somewhere that the issue of pxe driver is not "truly" managing the tftp service. i.e, it doesn't know really if tftp service is running or not..06:45
dtantsurrameshg87, that's true, and that's a current design decision. We won't manage HTTP server for iPXE just as well...06:46
dtantsur(we could check that server is running, though)06:46
dtantsurshort walk, brb06:47
rameshg87dtantsur: okay..06:47
*** ifarkas has joined #openstack-ironic06:52
*** Halacs has joined #openstack-ironic07:05
*** vinbs has joined #openstack-ironic07:12
rameshg87hi dtantsur, are you back ?07:14
*** faizan has joined #openstack-ironic07:17
Halacshi, I would like to try open stack bare metal, but I have some problems so are there any other installation guide besides the following? http://docs.openstack.org/developer/ironic/deploy/install-guide.html07:21
HalacsI think I installed bare metal but I got this exception: TRACE nova.api.openstack OperationalError: (OperationalError) no such table: bm_nodes u'SELECT bm_nodes.created_at AS ...07:22
HalacsCan anybody help?07:23
*** Mikhail_D_ltp has joined #openstack-ironic07:24
*** kpavel has joined #openstack-ironic07:27
*** pradipta is now known as pradipta_away07:38
*** jistr has joined #openstack-ironic07:38
*** bvivek has quit IRC07:41
dtantsurrameshg87, I am now08:05
dtantsurHalacs, hi. First I guess you're still using Nova Baremetal instead of Ironic08:06
*** athomas has joined #openstack-ironic08:06
dtantsurHalacs, did you reconfigure Nova to use Ironic?08:06
HalacsHi dtantsur. No, I didn't. Do you have any guideline to do it?08:07
*** viktors|afk is now known as viktors08:08
*** dguerri is now known as _dguerri08:12
*** mrda is now known as mrda-away08:14
mrda-awaynight all08:14
*** _dguerri is now known as dguerri08:16
*** dguerri is now known as _dguerri08:16
*** _dguerri is now known as dguerri08:16
*** dguerri is now known as _dguerri08:16
*** _dguerri is now known as dguerri08:16
dtantsurHalacs, this step: http://docs.openstack.org/developer/ironic/deploy/install-guide.html#configure-compute-service-to-use-the-bare-metal-service08:23
*** lucasagomes has joined #openstack-ironic08:24
*** romcheg1 has joined #openstack-ironic08:29
*** romcheg1 has quit IRC08:30
*** Nisha has quit IRC08:31
*** bvivek has joined #openstack-ironic08:32
Halacsdtantsur: it should be work if I use Redhat 6.5 on all node excepts the only one which run bare metal? I have 3 nodes: controller, compute and baremetal (legacy network config)08:38
dtantsurlucasagomes, hi! Do we need a spec for our work on TripleO as well?08:38
*** shausy has quit IRC08:39
dtantsurHalacs, likely yes, provided you can install the dependencies, though I'm not 100% sure.08:39
*** shausy has joined #openstack-ironic08:41
viktorsdtantsur: hi! Could you please look at patch https://review.openstack.org/#/c/42159/ (Use oslo.db library) , when you'll have a time08:44
dtantsurviktors, sure!08:44
Halacsdtantsur: It seems to me I didn't configured nova.conf on each nodes, but only on the controller node. But now on controller, when I try to restart scheduler I got this on scheduler.log: ironic.nova.scheduler.ironic_host_manager :08:45
Halacs:08:45
Halacs:(08:45
*** Poornima_ has quit IRC08:45
dtantsurHalacs, ehhhr... could you paste the whole log somewhere?08:45
lucasagomesdtantsur, hey I don't think so, for the discovery you mean?08:46
dtantsurlucasagomes, yep. Maybe we should ask lifeless?08:46
Halacsyes, of course, just a second and I will send a pastebin link08:46
lucasagomesdtantsur, sure08:47
dtantsurlucasagomes, mind asking in #tripleo ?08:48
Halacsdtantsur: http://pastebin.com/WgY5Th0s08:49
lucasagomeslemme do it, tho it may be quite there08:49
lucasagomesthe ooo mid-cycle starts today I think08:50
dtantsurlucasagomes, oh, I forgot bout it08:50
dtantsurHalacs, 1. you have to fix Glance and QPid problems first, 2. Seems like Ironic python modules are not installed to where Nova can find them08:51
*** shausy has quit IRC08:51
lucasagomesdtantsur, yeah... well I asked anyway08:51
dtantsurFolks, especially, cores, it's the last call to review oslo.db patch https://review.openstack.org/#/c/42159/ :) It got 3x +2 and is close to being approved08:54
*** Alexei_9871 has joined #openstack-ironic08:55
*** dguerri is now known as _dguerri08:56
lucasagomesdtantsur, I will approve it, I left a comment saying that I didn't approve before because I wanted to get more reviews08:56
lucasagomesso now I think it's fine to go and approve it08:57
dtantsurheh, that's good :)08:57
lucasagomesand folks we need more reviews at the mgmt interface as well08:57
lucasagomeshttps://review.openstack.org/8609208:57
dtantsurviktors, does oslo.db has something similar to what we do in https://review.openstack.org/#/c/73121/ ? I remember asking this, but things could change08:57
dtantsurlucasagomes, did we again agree on using _LW?08:58
lucasagomesdtantsur, oh I think so, we even merged the oslo i18n patch08:59
lucasagomesI'm trying to use on my patches _LW, _LI08:59
lucasagomescause that's the new way to do it08:59
dtantsurlucasagomes, wow. Was it announced? Because I had not idea previously...08:59
lucasagomeshttps://review.openstack.org/#/c/10513209:00
lucasagomesright... hmm lemme search, I got some -1's telling me to use it09:00
lucasagomesbut lemme search for a better source09:01
dtantsurlucasagomes, one issue with mgmt patch, otherwise ok09:02
Halacsdtantsur, 1. I think glance and QPid problems is solved because I can start a standard virtual machine from web UI. 2. I check it know.09:02
lucasagomesdtantsur, ack cheers, I will fix it quickly09:02
*** _dguerri is now known as dguerri09:03
dtantsurHalacs, there should not be errors in a log; at least Ironic won't work w/o QPid. Please solve these first.09:03
*** rainya has quit IRC09:03
Halacsdtantsur, okey09:04
lucasagomesdtantsur, I will have to dig into the functions and find out what exceptions it may raise... I left Exception because the it's not obivious on the function, and the docstring doesn't help much either: ":raises: some Exception from making the password file or from executing the command"09:06
lucasagomeshah09:06
lucasagomessome Exception...09:06
lucasagomeslol09:06
viktorsdtantsur: at the moment no. But we are going to modify error wrapping in oslo.db, see spec - https://review.openstack.org/#/c/105306/09:07
dtantsurlucasagomes, well, I can try to live with `except Exception`, but I highly want the `try` block to cover only this peace09:07
lucasagomesdtantsur, yeah lemme take a look09:08
*** martyntaylor has joined #openstack-ironic09:08
*** romcheg1 has joined #openstack-ironic09:09
*** rainya has joined #openstack-ironic09:10
dtantsurviktors, interesting spec. When do you expect it to land?09:10
*** Nisha has joined #openstack-ironic09:12
*** martyntaylor has quit IRC09:13
viktorsdtantsur: Mike Bayer (zzzeek) working on this at the moment. Feel free to review his patches - https://review.openstack.org/#/q/project:openstack/oslo.db+branch:master+topic:bp/use-events-for-error-wrapping,n,z09:13
dtantsurack09:13
viktorsdtantsur: we are suppose to get these pathes merged during the week (or two)09:13
dtantsurI see09:14
*** Poornima|mtg has joined #openstack-ironic09:22
*** rainya has quit IRC09:22
*** dguerri is now known as _dguerri09:25
*** pelix has joined #openstack-ironic09:26
*** Poornima|mtg is now known as Poornima_09:26
lucasagomesdtantsur, problem with the exceptions is the mkstemp09:27
lucasagomeshttps://docs.python.org/2/library/tempfile.html#tempfile.mkstemp09:27
lucasagomesit's not even documented what it may raise09:27
dtantsurlucasagomes, I would assume it should not raise, unless something completely crazy is going on09:27
lucasagomesI can log a debug of the stdout and stderr of that command to help with the debug09:27
*** martyntaylor has joined #openstack-ironic09:28
lucasagomesdtantsur, right, so catch only the processutils.execute exceptions?09:28
romcheg1Morning guys!09:28
dtantsurlucasagomes, yes. If we encounter something new, we should give it a thought, not just try to cover everything :) and also please cover only that block with try..except..09:28
dtantsurromcheg1, morning :)09:28
*** _dguerri is now known as dguerri09:29
lucasagomesdtantsur, ack09:29
dtantsurFolks, lucasagomes, we have more-or-less prioritized specs to review: IPA https://review.openstack.org/#/c/98506/ ; discovery https://review.openstack.org/#/c/107344 :)09:31
*** athomas has quit IRC09:34
*** Nisha has quit IRC09:38
faizanHi dtantsur, lucasagomes,09:44
dtantsurfaizan, hi!09:44
faizandtantsur: lucasagomes: request you folks to review this design spec for uefi support https://review.openstack.org/#/c/99850/09:45
dtantsurfaizan and folks: please note that we do have your patches on our dashboards; unlike ironic-core team, ironic-specs-core is very limited, with only ~3 folks constantly reviewing things. We don't skip your patches because of bad will ;)09:47
dtantsurI mean, sure, once we have some time :)09:47
*** athomas has joined #openstack-ironic09:49
*** enikanorov__ has quit IRC09:52
dtantsurlucasagomes, we agreed on you chairing the meeting today, right?09:52
lucasagomesyup09:53
lucasagomeshope I remember all the commands heh09:53
dtantsurI guess there are docs somewhere :)09:56
*** dguerri is now known as _dguerri10:02
*** _dguerri is now known as dguerri10:02
faizandtantsur: thanks for having it in your pipeline. Will wait for your review comments.10:06
mrda-awaydtantsur: thanks for your review of 10731610:21
lucasagomespy26 test is broke in gate :/10:21
mrda-awaydtantsur: I have a differing view on changing host_state_cls - this is the interface into baremetal, so with ironic coming in, I was keen to maintain that interface.10:22
mrda-awaydtantsur: but if you want to discuss this more, I'm happy to ;)10:22
dtantsurmrda-away, IIRC, you're anyway introducing a new base class and will be changing bm code. So I don't think we should keep a confusing (and it's obviously confusing, if it used to require a special comment) name10:23
dtantsurlucasagomes, oh no10:23
*** romcheg1 has left #openstack-ironic10:26
*** romcheg1 has joined #openstack-ironic10:26
mrda-awaydtantsur: so this will be a little tricky - it impacts another file then - nova/tests/scheduler/test_baremetal_host_manager.py - which is not in our tree, but we're proposing to modify10:26
dtantsurmrda-away, it will impact it anyway: you're changing attribute to a function10:27
mrda-awayumm, no, because originally it has a function reference - the move to an attribute was an attempt to be tricky at maintaining the interface but cleaning it up.  Unfortunately properties can't have multiple params, so we couldn't go down that path10:28
mrda-awaysorry, originally host_state_cls was a function reference10:28
dtantsurmrda-away, yeah, sorry, I see now10:29
dtantsurso if it's for compatibility, then let's leave it10:29
dtantsur(I'd like to see it changed later in Nova tree though)10:29
*** romcheg2 has joined #openstack-ironic10:30
mrda-awayHow about I compromise - what if I propose a change in the Nova tree to change the interface, and if it lands before we do, then we'll rebase accordingly?10:30
mrda-awaydtantsur: does that sound like a good idea?10:30
dtantsurmrda-away, sounds good!10:30
mrda-awaySo, to be clear, I agree, but I really want this to land in J :)10:31
*** romcheg1 has quit IRC10:32
dtantsurmrda-away, yeah sure, me too :)10:32
*** Haomeng|2 has joined #openstack-ironic10:33
*** Haomeng has quit IRC10:35
Halacsdtantsur: now in scheduler.log, the only message is "ImportError: No module named ironic.nova.scheduler.ironic_host_manage". Can you give me, for example, a package name which I should install to RedHat6.5? python-ironicclient yum package isn't enough unfortunately10:39
dtantsurHalacs, ironicclient is required, but not enough. You have to install Ironic itself10:40
dtantsurI am not sure how it is called, probably ironic-conductor10:40
rameshg87Halacs: seems a typo ??10:40
rameshg87Halacs: did you paste the full error message ?10:41
HalacsThis is the full error msg: "2014-07-21 11:30:56.459 2231 CRITICAL nova [-] ImportError: No module named ironic.nova.scheduler.ironic_host_manager"10:41
dtantsurironic.nova.scheduler.ironic_host_manager is not in python-ironicclient package10:42
*** Poornima_ has quit IRC10:48
dtantsurlucasagomes, re my discovery spec: I realized I barely understand, on which conductors to call set_discovery_enabled? On every? What if they modify some global resource (like neutron)?10:52
lucasagomesdtantsur, yes it should go to all conductors10:52
dtantsurlucasagomes, should I put this to a spec?10:52
lucasagomesI think so10:53
dtantsurack10:53
lucasagomescrap can't find the ML about the specs deadline10:54
dtantsurlucasagomes, you can just propose and see what happens :D10:55
lucasagomesnah it's not up to me10:55
mrda-awaylucasagomes: http://openstack.10931.n7.nabble.com/Ironic-Juno-priorities-and-spec-review-timeline-td44905.html10:55
lucasagomescheers mrda-away !10:56
mrda-awayI really should be away10:56
mrda-away;P10:56
lucasagomeshehe10:57
lucasagomesta much10:58
dtantsurlucasagomes, please also have a look, if I forgot something else in my spec11:01
*** ramineni has quit IRC11:05
rameshg87dtantsur: just a question for a spec which you have reviewed, eventhough it is for ipa11:25
dtantsur?11:25
rameshg87dtantsur: for "Add deploy driver for ironic-python-agent" https://review.openstack.org/#/c/98506/711:25
rameshg87dtantsur: we don't say how the deploy agent ramdisk is booted on the bm node11:26
*** dguerri is now known as _dguerri11:26
rameshg87dtantsur: and we have another blueprint "Support long-running deploy ramdisks" https://review.openstack.org/#/c/102405/11:26
dtantsurrameshg87, I guess deploy ramdisk is booted like in PXE, though you better ask jroll11:27
rameshg87dtantsur: so does ipa will have a configuration option ?11:27
*** ifarkas has quit IRC11:27
rameshg87dtantsur: to choose whether they want long-running-ramdisks OR on-demand-booted-ramdisks ?11:27
rameshg87dtantsur: yeah, i though jroll might be a better person to ask, was just checking if you would know :-)11:28
dtantsurrameshg87, I don't quite remember, sorry. I'm not sure it's 100% decided11:28
rameshg87dtantsur: okay ..11:28
rameshg87dtantsur: is it targeted for juno ?11:28
rameshg87dtantsur: long running ramdisks ???11:28
dtantsurrameshg87, probably not, I'm not sure either11:29
rameshg87dtantsur: okay ..11:29
*** lucasagomes is now known as lucas-hungry11:33
viktorsanybody knows, what happened with py26 gate tests?11:35
HalacsI want to install a new OpenStack for Ubuntu, but which version of Ubuntu is compatible with bare metal?11:37
Halacs14.04 LTS?11:38
*** lazy_prince has quit IRC11:38
*** igordcard has joined #openstack-ironic11:40
NobodyCamgood morning Ironic11:44
Shrewsmorning NobodyCam. Welcome to NC11:45
NobodyCamthank you thank you :)11:45
NobodyCamwow its muggie out side11:45
Shrewsyup11:46
*** chuckC has quit IRC11:47
*** Haomeng has joined #openstack-ironic11:48
*** Haomeng|2 has quit IRC11:49
*** igordcard has quit IRC11:52
dtantsurNobodyCam, morning :)12:00
dtantsurHalacs, 14.04 should be ok, though Ironic has developed greatly since Icehouse release12:00
Halacsgreat, thanks.12:06
*** killer_prince has joined #openstack-ironic12:06
*** killer_prince is now known as lazy_prince12:07
*** vinbs has quit IRC12:07
*** lsmola has joined #openstack-ironic12:24
*** k4n0 has quit IRC12:28
*** lsmola has quit IRC12:34
*** jdob has joined #openstack-ironic12:36
*** derekh_ has joined #openstack-ironic12:37
*** lucas-hungry is now known as lucasagomes12:39
lucasagomesmorning NobodyCam Shrews12:39
lucasagomesif you guys have a time please take a look at https://review.openstack.org/#/c/86092/12:39
lucasagomesdtantsur, will take a look, I'll also try to see if I can workaround that problem on ks12:41
*** lazy_prince is now known as killer_prince12:42
lifelessdtantsur: hi, ask me what?12:42
lucasagomeslifeless, I think it was about the autodiscovery we are working on for Ironic... I will need to create an element for DIB for that, he was wondering whether we would need a spec for that or not12:43
lucasagomeslifeless, the element is here https://review.openstack.org/10767212:44
lifelesswe don't need a spec just because, but if its going to be contentious or tricky, we will12:44
lucasagomesyeah, I don't think we need any as well, we are not changing anything on DIB12:44
lucasagomesno special needs for that element12:44
lucasagomesbut thanks for confirming it12:45
*** lsmola has joined #openstack-ironic12:47
Shrewslucasagomes: morning! about to drive down to the tripleo meetup, but can try to look later12:49
lucasagomesShrews, oh aight, no problem! enjoy the meeting12:49
*** rameshg87 has left #openstack-ironic12:52
*** Halacs has quit IRC12:53
lucasagomesviktors, yeah it seems to be failing... weird enough some patches have passed that test. Have you tried to rebase the oslo.db patch with master recently?12:55
NobodyCammorning dtantsur12:56
*** lsmola has quit IRC12:58
NobodyCammorning lucasagomes12:58
*** lsmola has joined #openstack-ironic13:05
viktorslucasagomes: no, I haven't. I looked into the tests log, and seems to be, that rebase will not help13:05
lucasagomesyeah it's something with pip13:05
lucasagomes:(13:05
viktorsyes :(13:06
*** jcoufal has joined #openstack-ironic13:07
*** matty_dubs|gone is now known as matty_dubs13:09
*** rloo has joined #openstack-ironic13:10
*** ramineni has joined #openstack-ironic13:24
jrollgoodmorning everybody13:34
*** bvivek has quit IRC13:34
jrollI missed ramesh :(13:34
lucasagomesmorning jrist13:35
lucasagomesjroll,13:35
lucasagomesjrist, morning hah sorry man13:35
jrollheya lucas13:35
*** lsmola has quit IRC13:39
dtantsurjroll, morning13:40
jristmorning to you lucasagomes :)13:40
jristalso good morning jroll13:40
jrollmornin dtantsur, jrist13:40
* jroll makes a script to say good morning to everyone currently in channel13:40
lucasagomes:D13:40
*** dhellmann is now known as dhellmann_13:41
*** ramineni has quit IRC13:42
*** kpavel has quit IRC13:48
*** Poornima|mtg has joined #openstack-ironic13:49
*** Poornima|mtg is now known as Poornima_13:49
*** faizan has quit IRC13:53
*** martyntaylor has left #openstack-ironic13:59
jroll2014-07-21 14:00:30.478 WARNING wsme.api [-] Client-side error: Couldn't apply patch '[{'path': '/extra/vif_port_id', 'op': 'remove'}]'. Reason: 'vif_port_id'14:04
jrollanybody know what might make this happen in devstack?14:04
jrolloh that's tearing down isn't it14:05
* jroll booooooo14:05
devanandao/14:05
jrollmorning deva14:06
devanandamornin14:07
*** killer_prince has quit IRC14:08
*** Poornima_ has quit IRC14:09
*** Poornima|mtg has joined #openstack-ironic14:10
*** Poornima|mtg is now known as Poornima_14:10
dtantsurdevananda, morning14:11
lucasagomesdevananda, morning14:14
lucasagomesjroll, I think the driver capture that and just pass14:14
NobodyCamgood morning devananda14:16
jrolllucasagomes: yeah, figured that one out...14:17
jrollnow running into: 2014-07-21 14:16:48.007 WARNING nova.network.neutronv2.api [-] Neutron error: quota exceeded14:18
lucasagomes:/14:18
jrollkilling builds14:18
dtantsurlucasagomes, I'm thinking about discovery again and now I'm starting to think, that we should only route `enable_discovery` request to one of the conductors14:18
lucasagomesdtantsur, only one? why?14:18
lucasagomesdtantsur, btw, we need to know if it's enabled or not14:18
dtantsurlucasagomes, why would we want all of them? discovery does not seem to require some local environment14:19
dtantsurlucasagomes, are we really going to create PXE environment on every conductor?14:20
lucasagomesdtantsur, well I was thinking that all conductors would need to be able to answer the dhcp request14:20
dtantsurlucasagomes, you mean PXE?14:20
jrollkeep in mind the use case for this is running discovery on a ton of nodes at one time14:20
jrollI'd prefer that be able to scale :)14:20
*** jgrimm has joined #openstack-ironic14:21
devanandadtantsur: all conductors need to be able to perform discovery14:21
lucasagomesdtantsur, well PXE starts with a dhcp requests14:21
lucasagomesand as jroll pointed it needs to scale14:21
jrolllucasagomes: neutron answers the dhcp request14:21
devanandadtantsur: if we have only one conductor responsible for an entire capability, it isn't HA14:21
jrollthe conductor just does the tftp bit14:21
lucasagomesso we can't let only 1 conductor handle it all14:21
lucasagomesyeah14:21
devanandadtantsur: and we may have conductors deployed in different locations14:21
devanandaeg, different racks14:22
jrollbut yeah, that's a non-starter14:22
dtantsurdevananda, lucasagomes, makes sense14:22
* jroll waits for stack.sh14:22
lucasagomesjroll, yeah and tftp is _very_ testing with 3 machines its already pretty slow14:22
devanandaeventually we should have location-awareness (eg, for affinity-based scheduling)14:22
jrolllucasagomes++14:22
lucasagomesdevananda, jroll  https://www.youtube.com/watch?v=gZGYeo7sJhQ14:22
lucasagomesvery first stab at it on friday14:22
jrolllucasagomes: try tftp with a large image... doesn't even work14:23
lucasagomesjroll, yeah, that's why iPXE ftw!14:23
dtantsurnow a stupid question: how can I send a message to all conductors with a given driver? Should I get list of hosts from hash ring and iterate over it? Doesn't sound right :)14:23
*** datajerk has quit IRC14:23
jrolllucasagomes++++++++14:23
lucasagomesdtantsur, you have that list from the hashring14:23
jrolllucasagomes: are you using kvm in that video?14:24
lucasagomesjroll, yeah14:24
dtantsurlucasagomes, right. Is it good to put N messages to RPC, where N is number of conductors from hash ring?14:24
jrolllucasagomes: what's that gui vm manager thing? also, you running devstack locally, outside of a vm? D:14:24
lucasagomesdtantsur, you can also send a broadcast to all conductors, and they can check if they have the driver loaded14:24
lucasagomesjroll, yeah that's virt-manager, devstack is inside a vm14:25
jrollah14:25
dtantsurhmmm.... any advice on which approach is better?14:25
jrollthanks14:25
lucasagomesjroll,  https://review.openstack.org/#/c/107672/14:25
lucasagomesjroll, that's the custom ramdisk I created that interrogate the machine and register on ironic14:25
jrolllucasagomes: nice :)14:27
dtantsurstill folks, what is better: a broadcast message to all conductors or several messages only to related conductors?14:28
lucasagomesdtantsur, hmm /me thinking14:28
* dtantsur is not strong in AMQP and friends14:28
*** dhellmann_ is now known as dhellmann14:30
lucasagomesdevananda, btw, this thing about the discovery... it's per driver but drivers but there's no driver table in the db14:31
lucasagomesdevananda, I think we would need to make drivers an entity on the db as well to hold such informations14:31
* lucasagomes can't think about any other solution :/14:32
dtantsurlucasagomes, let's skip it, it won't get into Juno, I'm afraid...14:32
devanandadtantsur: each driver has (or could have) separate RPC bus14:32
*** rwsu has joined #openstack-ironic14:32
lucasagomesdtantsur, I'm trying to think in a way to avoid having it... but I didn't yet14:33
devanandadtantsur: so you should be able to do RPC broadcast to notify all conductors "driver X should start discovery with paramters Y"14:33
*** datajerk has joined #openstack-ironic14:33
devanandaand not need any db changes14:33
devanandaAPI service can already check "is driver X supported by active conductors?"14:33
devanandaso we can error out before broadcast if the driver is not loaded14:33
devanandaand if it is, jsut broadcast it, and tell user 202 ACCEPTED14:34
dtantsurdevananda, so it's similar to get_topic_for_driver, but with notifying all topics?14:34
devanandaand each conductor, upon receiving that message, checks local drivers and discards the message if that driver isn't supported14:34
devanandadtantsur: no14:35
lucasagomesdtantsur, there's a default topic on each conductor14:35
lucasagomesyou can use that topic to send it to all conductors14:35
dtantsurah, seems like I'm starting to understand14:35
dtantsurso it's essentially not passing any topic to the call, just using the default?14:35
dtantsurdevananda, re returning 202, I thought of returning error to use, if driver does not support the feature. Does it make sense to you?14:36
lucasagomesdtantsur, if no conductors on the cluster supports that driver, yes makes sense return error14:36
lucasagomesif >= 1 does, 20214:37
dtantsurlucasagomes, no, I meant if driver is not imlementing the feature14:37
devanandalucasagomes: I think dtantsur is saying, if the requested driver is active but IT doesn't support discovery14:37
devanandaso14:37
devanandadtantsur:14:37
lucasagomesah14:37
dtantsuryes14:37
devanandadtantsur: the API service should already know that14:39
devanandaah, no14:39
devanandait doesn't14:39
devanandait knows taht per-node14:39
devananda:(14:39
devanandav1/driver/XXX/validate would indicate which driver interfaces are supported14:40
devanandabut taht's per-node14:40
devanandalucasagomes: so, driver interface question14:40
dtantsuryeah, it's a bit difficult... to me this will require actually calling the RPC and checking the results14:40
devanandadtantsur: lucasagomes: where does "discovery" fit w.r.t. the DriverInterface API, as you two are proposing it?14:40
dtantsurdevananda, I expected it to be something new in the management interface14:41
devanandathe interfaces are, by definition, node-specific, with the exception of driver_vendor_passthru, which is exempt from considerations of supported, etc14:41
dtantsurif I got your question right14:41
devanandadtantsur: but the management interface is meant to address any request to a specific node14:42
dtantsurhmmmm...14:42
devanandareally all the interfaces are14:42
*** ramineni has joined #openstack-ironic14:42
devanandato add a non-node-dependent discovery function to the mgmt interface, it means adding an interface method which doesn't take a TaskManager parameter14:43
devanandato get down to the specifics14:43
dtantsuryes, that's how I saw it..14:43
lucasagomeshmm thinking...14:43
lucasagomesyeah that's correct :/14:43
devanandaand at the high level, it means calls like MagagementInterface.validate() don't apply to it14:43
dtantsurwell, yes14:44
dtantsurdevananda, do you suggest creating a new interface? or what?14:46
dtantsurall this does not look perfect to me, but nor does it look awful14:46
lucasagomesunless we use discover as a driver vendor passthru method14:47
lucasagomesfor now14:47
lucasagomesas a first stab at it14:47
devanandalucasagomes: ++14:47
dtantsurdriver vendor passthru is Yet Another exceptional method14:48
devananda*vendor_passthru is there to break such new ground until folks can agree14:48
devanandadtantsur: it is granted exceptional status intentionally14:48
devanandabecause it doesn't lock down the API14:48
lucasagomesright, yeah it can work14:48
dtantsuraren't we complicating things again?14:48
devanandait IS going to cause pain to folks14:48
devanandano matter how we address this now, I don't see any concensus14:48
jrollwait... what are we adding to the API?14:49
devanandaeither we put it in the expection and widely visible exception area as an exception to the API14:49
jrolla thing to initiate discovery or?14:49
devanandaie, vendor passthru14:49
lucasagomesjroll, yeah, active/deactive discovery14:49
devanandaor we add something to the common API that we have not come to an agreement on14:50
dtantsurdevananda, but vendor passthru now is routed to only one conductor14:50
dtantsurchosen randomly14:50
devanandaand will probably have to change, thus breaking API compatibility14:50
jrollI almost think of discovery as a provision_state... but I guess you can't do that without the node id14:50
devanandadtantsur: yes. vendor passthru is very limited14:50
devanandajroll: right14:50
jrollbut what is there to enable? just turning on pxe/tftp for unidentified nodes?14:50
devanandajroll: a node could be in provision_state "DOING_DISCOVERY_ON_THIS_THING" :)14:50
devanandajroll: running a special discovery ramdisk14:51
dtantsurI hoped we got the spec procedure to come to agreements...14:51
devanandadtantsur: I haven't looked in the last few days, but is there agreement?14:51
jrolldevananda: on identified nodes, why not just add to /nodes/uuid/states/provision14:51
dtantsurdevananda, no, nobody has looked :)14:51
devanandadtantsur: heh14:51
jrolllike set provision_state to 'discovery' and pass off to the conductor14:51
dtantsurso there's neither agreement nor disagreement :)14:51
jrolland for unidentified nodes... just look at the config option on startup14:52
dtantsurjroll, we're only discussing unregistered nodes14:52
jrollso what's wrong with looking at configs, and always having that ramdisk available?14:52
jroll(or never)14:52
devanandajroll: ++14:52
*** MattMan has joined #openstack-ironic14:52
dtantsurdevananda, it was your point, that we should have a way to enable/disable discovery w/o restarting14:52
devanandajroll: though I think the 'config' there needs to be dynamic14:53
devanandadtantsur: yes. was typing second half of my thought :)14:53
jrolldevananda: meh14:53
devanandaperhaps that is a sufficient first approximation14:53
devanandadtantsur: would that simplify the discussion enough to bring agreement?14:53
jrollwhy do we need to do that without restarting?14:53
jrolllike, rolling restarts are a thing14:54
Shrewslucasagomes: re: 86092...  test_management_interface_get_boot_device_unkown_dev .... should be "unknown"14:54
dtantsurdevananda, everything that will get to somewhat-working discovery has my agreement :D14:54
devanandajroll: example... I have a cloud. I plug in a new rack. I want to discover it. Then, I want to STOP discovery so as to prevent uninvited guests14:54
lucasagomesShrews, :( typo? I will fix that14:54
dtantsurdevananda, do we have a way for a driver to do something on start-up?14:54
jrolldevananda: I get the use case... and I get that we'd prefer it to be dynamic... but for a first version, jfdi and worry about an api endpoint for it later14:55
jrolldevananda: or like, lock the door on your DC :)14:55
* dtantsur was suggesting not doing it from the beginning >_<14:56
dtantsurI am really wondering, if our spec process is working, provided we anyway have to discuss everything on IRC...14:57
*** bvivek has joined #openstack-ironic14:57
jrollbut if we must add an endpoint... driver_vendor_passthru ftw14:57
dtantsurbrb, need some coffee14:58
Shrewslucasagomes: also, the generated docs for get_boot_device() don't look correct. http://docs-draft.openstack.org/92/86092/23/check/gate-ironic-docs/4811662/doc/build/html/api/ironic.drivers.modules.ipmitool.html#module-ironic.drivers.modules.ipmitool14:59
Shrewslucasagomes: otherwise, lgtm   :)14:59
*** malini1 has joined #openstack-ironic14:59
*** rainya has joined #openstack-ironic14:59
rloohi lucasagomes: wrt 86092 - I had a question (see my comment).14:59
lucasagomesShrews, thanks will address that15:00
*** rainya has quit IRC15:00
lucasagomesrloo, will take a look15:00
devanandajroll: yes. but jfdi in a way that doesn't break the API for the next improvement15:00
*** rainya has joined #openstack-ironic15:00
devanandadtantsur: we have conductor.manager:init_host() which could be extended to let drivers do some init too15:01
devanandadtantsur: I think that's totally reasonable but no, we don't have a separate interface for that today15:01
jrolldevananda: if we don't touch the API, I don't think it will break it :)15:01
devanandajroll: exactly :)15:01
lucasagomesrloo, right... so the idea is that if we can't get the boot device we return unknown15:01
jrolldevananda: so... make it a config option15:01
jrolldon't make it dynamic (yet)15:02
rloolucasagomes: but if we can't even do an ipmitool cmd, we raise an exception instead of returning unknown.15:02
devanandajroll: *nod*15:02
jrolldevananda: deploy new configs /b 7415:02
NobodyCamis the py26 job broken?15:02
jrollughhhhhhh15:02
* jroll needs to learn to finish thoughts15:03
*** openstackgerrit has joined #openstack-ironic15:03
lucasagomesrloo, right I can do that then15:03
devanandajroll: so that works for a DHCP-based boot mechanism15:03
dtantsurdevananda, let me ask, if the only generic thing left is adding a newly_discovered column, should I even have a spec for it? Or we just silently add it :)15:03
devanandajroll: how does config-option-driven discovery work for something like iLO-based boot mechanism?15:03
lucasagomesrloo, will change it to raise IPMIFailure on an error from ipmitool15:03
jrolldevananda: touché15:04
devanandathus the need for an API15:04
devananda:(15:04
rloolucasagomes: thx. I wasn't sure which made more sense, but yeah, raising IPMIFailure might be good.15:04
jrolldevananda: driver_vendor_passthru awayyyyyyyyyy15:04
lucasagomeshah15:04
devanandajroll: yea....15:04
lucasagomesdevananda, jroll so... config option for now?15:05
devanandalucasagomes: that seems to unblock the discussion, be generally applicable (even iLO can use a cnofig option) and then non-DHCP-based drivers will need to use driver_vendor_passthru15:05
devanandawe should check with wan-yen (or who ever was proposing iLO discovery) if that can work for them15:06
lucasagomesright, yeah... we def can improve it on K15:06
lucasagomesit's good to have something for now, baby steps15:06
devanandaNobodyCam: are you seeing all the py26 jobs failing?15:07
devanandaNobodyCam: http://logs.openstack.org/59/42159/16/check/gate-ironic-python26/890b436/console.html has some really neat errors15:07
devanandaNobodyCam: but I haven't looked at other jobs yet15:07
jrollI know this is an outstanding bug, but for this library it's so ironic15:08
jroll2014-07-21 12:05:28.266 |   http://pypi.openstack.org/simple/cryptography/ uses an insecure transport scheme (http). Consider using https if pypi.openstack.org has it available15:08
* jroll bbl15:09
dtantsurdevananda, lucasagomes, jroll, ok, config options. In my spec I document the new field and these options? or we don't even need a spec for it?15:09
*** mdorman has joined #openstack-ironic15:10
jrollnew db column, new configs, both require specs15:10
*** athomas has quit IRC15:10
NobodyCamdevananda: not all but many15:11
jrolldtantsur: I'd also mention that drivers like ilo will need to use driver vendor passthru15:11
rloodtantsur: I haven't been paying attention but it seems to me that if you've been having lots of discussions on how to do discovery and what the requirements/constraints are, it might be good to put those in a spec.15:11
NobodyCamdevananda: ya that was the one I was looking at15:11
*** athomas has joined #openstack-ironic15:12
Shrewsdevananda: NobodyCam: https://bugs.launchpad.net/openstack-ci/+bug/1344023 seems relevant15:13
lucasagomesyuriyz, what you mean by "Looks like default value for group should be '' instead of 1." ?15:15
NobodyCamShrews: yep that was the one I rechecked with and it failed again.15:15
NobodyCamwill tray again15:15
Shrews"102 fails in 24hrs"  ... geeesh15:16
yuriyzhello lucasagomes see example 2 for groups() in documentation https://docs.python.org/2/library/re.html15:17
lucasagomesyuriyz, ack lemme take a look15:17
lucasagomesthanks15:17
dtantsurrloo, I have a spec, but nobody likes reading specs :D so we discuss it here15:18
rloodtantsur: i like reading the spec before I review the code :-)15:19
dtantsurrloo, heh, it's too late for the discussion15:19
openstackgerritChris Krelle proposed a change to openstack/ironic: Add option to allow soft power off  https://review.openstack.org/10777815:19
rloodtantsur: it definitely makes sense to discuss outside the spec though. just that sometimes, I think it is worth capturing the discussion (pros/cons/why/which decision) in the spec.15:19
lucasagomesyuriyz, ah gotcha, will fix it15:20
rloodtantsur: my comment was in response to your question as to whether a spec was necessary :-)15:20
dtantsurah, I see :)15:20
lucasagomesyuriyz, I also better check if the regex object was returned15:20
yuriyzlucasagomes +115:20
dtantsurdevananda, what do you think about adding some init_discovery() method to DriverInterface, which will be called, if according to the config this driver will be used for discovery?15:21
*** rainya has quit IRC15:29
devanandaShrews: we're not based on the alpha prerelease of oslo.messaging, but yea, looks like a similar error15:31
*** rainya has joined #openstack-ironic15:32
*** Poornima_ has quit IRC15:33
devanandadtantsur: I think adding an init_discovery() method to DriverInterface which will be called during ConductorManager.init_host(), every time the service is started, for every loaded driver, if the CONF option for discovery is enabled15:34
devanandadtantsur: is a reasonable initial step15:35
*** jistr has quit IRC15:35
devanandadtantsur: but to be clear, this is not per-driver. it's global15:35
devanandaand called on every loaded driver15:35
dtantsurdevananda, why on every?15:35
dtantsurwe want only one driver to install it's environment, no?15:35
devanandahuh?15:35
devanandadtantsur: all drivers must be able to co-exist15:36
*** rameshg87 has joined #openstack-ironic15:36
devanandadtantsur: a feature which means "if you use driver X, you can't use driver Y" is a feature that I very strongly think we can't land. Perhaps I misunderstand, but why would we want only one driver to prepare for discovery?15:36
dtantsurdevananda, how will they share PXE configuration for example?15:37
dtantsurdevananda, imagine 2 drivers want their ramdisk to be "the default"15:37
devanandadtantsur: IPA and PXE driver need to be able to coexist with each other, and with iLO driver, and with DRAC driver ...15:37
dtantsurdevananda, they can be _enabled_, but how can they do discovery together?15:37
devanandadtantsur: exactly.15:38
devanandadtantsur: at the driver layer, they can both be enabled. then it's up to the DHCP service which ramdisk to reply with15:38
dtantsurdevananda, I think we misunderstand each other. It is we who dictate DHCP, which ramdisk to return. We can have PXE and IPA both enabled as drivers, but only one of them can be returned by DHCP15:39
dtantsurdevananda, so we allow only on driver to do the discovery15:39
dtantsurAm I wrong?15:39
devanandadtantsur: in the current approach, neutron controls DHCP. ironic tells neutron what ramdisk to associate to specific MAC addresses15:40
devanandadtantsur: but not the general setting15:40
devanandadtantsur: and the rackspace folks (and others) are not using neutron at all, eg with IPA15:40
dtantsurdevananda, well, ok, but how we decide, which of them to pass to neutron?15:40
devanandadtantsur: the call to neutron which we make for a specific MAC is done within the driver.deploy interface15:41
devanandadtantsur: it's totally unrelated to discovery15:41
dtantsurok, what about catch-all DHCP setting?15:41
devanandaconfiguring neutron's default "if uyou get a DHCP BOOT request from an UNKOWN MAC"15:41
devanandais not done by ironic today15:41
dtantsurI understand :) that's what I am talking about15:41
devanandaok15:42
devanandaso there's another issue here, too15:42
dtantsurdevananda, my point is: only one driver should instruct neutron:  "if you get a DHCP BOOT request from an UNKOWN MAC, give him this ramdisk", right?15:42
devanandafor a DHCP-based discovery mechanism15:42
devanandahow does neutron know which conductor's IP to point to?15:42
rlooShrews, NobodyCam: wrt py26 failure, 1344023. Should we recheck, or just wait til it is fixed? Looks like it affects all the nodes.15:42
devanandadtantsur: it's not "this ramdisk" it's "this IP"15:42
devanandaif there are 10 conductors, all could have the same ramdisk cached, but neutron must point the boot request to a specific conductor's IP15:43
devanandahow does neutron pick which one?15:43
dtantsurhmmmmm....15:43
devanandaor how does ironic decide which conductor to tell neutron?15:43
rameshg87jroll: hello15:43
devanandawhen all 10 of them are capable of handling booting the discovery ramdisk15:43
dtantsurdevananda, I assume Neutron can't round-robin then, right?15:44
*** romcheg2 has quit IRC15:44
dtantsurIf so, it looks like we have to stick with only one conductor for now...15:44
devanandadtantsur: maybe it can? or maybe it should be added there?15:44
devanandadtantsur: if ironic picks only one conductor IP for discovery here, it's not HA. what happens when taht conductor fails?15:44
devanandadtantsur: ironic will need to inform neutron that it needs to change the IP15:45
devanandadtantsur: but another ironic conductor needs to know to take that action15:45
dtantsurdevananda, well, adding HA to non-existing feature may be overcomplication. We won't be able to fix Neutron for J (provided it can't)15:45
dtantsurdevananda, btw how do we do it now for the deploy? If conductor assigned to a node fails?15:46
devanandadtantsur: adding a non-HA feature to an openstack service is bad.15:46
devanandadtantsur: so, actually. it's broken. I'd MUCH rather we fix that.15:46
dtantsurdevananda, even if it's a baby step?15:46
devanandadtantsur: there are hooks in the conductor today to handle rebalancing the hash ring15:46
*** eghobo has joined #openstack-ironic15:47
devanandadtantsur: those do the take-over for nodes which were assigned to the now-failed-conductor15:47
dtantsurdevananda, so we can also do a take-over, right?15:47
devanandadtantsur: the patch I tossed upa  while ago needed mroe work, and I've, well, been distracted15:47
devanandadtantsur: right15:47
Shrewsrloo: idk. haven't looked into it15:53
dtantsurdevananda, so, if neutron can't have several IP's for DHCP, is it ok to stick with one conductor and plan rebalancing?15:53
rlooShrews: no worries. I did a recheck cuz I saw another patch that passed that test. Will see what happens.15:53
*** eghobo has quit IRC15:54
*** shakamunyi has joined #openstack-ironic15:54
*** eghobo has joined #openstack-ironic15:55
*** rameshg87 has quit IRC15:56
devanandadtantsur: frankly, i think this needs more thought / discussion as we still haven't come to an agreement (and this discussion may be progress, but isn't enough yet) and we have many more serious needs in the next month15:57
openstackgerritLucas Alvares Gomes proposed a change to openstack/ironic: Expose {set,get}_boot_device in the API  https://review.openstack.org/9015115:57
openstackgerritLucas Alvares Gomes proposed a change to openstack/ironic: SSH virsh to use the new ManagementInterface  https://review.openstack.org/8988415:57
openstackgerritLucas Alvares Gomes proposed a change to openstack/ironic: IPMITool to use the new ManagementInterface  https://review.openstack.org/8609215:57
*** victor_lowther has joined #openstack-ironic15:57
openstackgerritLucas Alvares Gomes proposed a change to openstack/ironic: SeaMicro to use the new ManagementInterface  https://review.openstack.org/8632815:57
openstackgerritLucas Alvares Gomes proposed a change to openstack/ironic: IPMINative to use the new ManagementInterface  https://review.openstack.org/8658815:57
lucasagomesrloo, Shrews yuriyz hope I have addressed all the concerns15:57
dtantsurdevananda, well, we need the discovery quite badly, so it will anyway distract me from things...15:58
devanandadtantsur: I think a f2f discussion next week will be good15:58
devanandadtantsur: we all want the feature :)15:58
devanandadtantsur: but, for example, we actually also all need HA of conductors15:59
dtantsurdevananda, if you mean meet-up, I won't be there, but you can talk to lucasagomes15:59
* lucasagomes reads15:59
openstackgerritRuby Loo proposed a change to openstack/ironic: Use mock.assert_called_once_with()  https://review.openstack.org/10841815:59
devanandawhich is less glamorous but, IMO, more important15:59
devanandabbiab15:59
*** rameshg87 has joined #openstack-ironic16:04
*** rainya has quit IRC16:06
rameshg87dtantsur: request you to take a look at moving code to image cache to a common place https://review.openstack.org/#/c/107996/16:08
rameshg87dtantsur: the one which you had reviewed earlier. :-)16:08
lucasagomesouch we need a spec for that!?16:09
dtantsurlucasagomes, there is some interesting feature there, which deserves discussion16:10
*** rainya has joined #openstack-ironic16:10
*** Mikhail_D_ltp has quit IRC16:11
lucasagomesright16:11
*** Nisha has joined #openstack-ironic16:16
*** ramineni has quit IRC16:18
rameshg87lucasagomes: was that to me ? :-)16:19
rameshg87lucasagomes: "ouch we need a spec for that!?" ?16:19
lucasagomesrameshg87, yeah heh16:19
lucasagomesbut I haven't read it yet so16:19
rameshg87lucasagomes: okay. i didn't get it first. please have a look at it if you get time. it's simple one btw.16:19
lucasagomessure16:20
*** steveh has quit IRC16:22
rloohey, did I miss something. Which _LI/_LW/_LE/_LC do we use? https://github.com/openstack/ironic/blob/master/ironic/common/i18n.py or https://github.com/openstack/ironic/blob/master/ironic/openstack/common/gettextutils.py16:23
jrollrameshg87: hi!16:23
openstackgerritOpenStack Proposal Bot proposed a change to openstack/ironic-python-agent: Updated from global requirements  https://review.openstack.org/8872216:23
rameshg87jroll: hi16:24
rameshg87jroll: wanted some information regarding ipa.16:24
jrollask away :)16:24
openstackgerritDmitry Tantsur proposed a change to openstack/ironic-specs: Generic Hardware Discovery Bits  https://review.openstack.org/10734416:24
lucasagomesjroll, https://review.openstack.org/#/c/100735/16:24
lucasagomesjroll, can you rebase that on master16:24
lucasagomesthat's already approved but not merged because the dependency is outdated16:25
dtantsurdevananda, jroll, lucasagomes, I tried to collect more-or-less non-contradictive things in a base spec: https://review.openstack.org/107344 (this does not touch how it will work for PXE)16:25
dtantsurif it gets merged, it will be at least easier to prototype things16:25
jrolllucasagomes: on the train but will do when I land at the office16:25
rameshg87jroll: from the ipa spec it looks like it will need keystone token to make heartbeat ping, am i correct ?16:25
Shrewsrloo: umm.... hrm....16:25
lucasagomesjroll, right... you mind if I rebase that?16:25
jrolllucasagomes: doeet16:26
lucasagomesack16:26
jrollI never mind someone doing work for me16:26
*** romcheg1 has joined #openstack-ironic16:26
rlooShrews:  I say use neither, but if we're going to use, which one?16:26
Shrewsrloo: last paragraph: https://wiki.openstack.org/wiki/LoggingStandards16:27
jrollrameshg87: that's complicated.... I think the first version will, but I also think passing keystone tokens to ipa is horrible and would like to do better16:27
rameshg87jroll: the spec doesn't talk about that.16:27
jrollrameshg87: other option today is to not auth for heartbeat16:27
jrollbut that's just as bad16:27
rameshg87jroll: so in the first version, it is planned to do in the same way as pxe does now ?16:27
rlooShrews, thx (#$#$%!)16:27
rameshg87jroll: expect token-<node-uuid>  in tftp root ??16:28
jrollrameshg87: the spec says tbd because I would rather not pass keystone tokens :/ but I don't think that will land16:28
jrolland in memory on the agent16:28
Shrewsrloo: do we need to remove the common/i18n.py file and replace it with oslo.i18n?16:28
rameshg87jroll: if we don't do both, how will we do heartbeat to the api ?? :-)16:29
rlooShrews: you're asking me? :-) I think Ghe added the common/i18n.py, and that uses oslo.i18n.16:29
rameshg87jroll: heartbeat AFAIK is an important part of IPA, right ?16:29
ShrewsGheRivero: ^^^^ ?16:29
jrollrameshg87: could change api noauth whitelist to include the heartbeat url :)16:30
openstackgerritLucas Alvares Gomes proposed a change to openstack/ironic: Factor out deploy info from PXE driver  https://review.openstack.org/10073516:30
rlooShrews: I think it means that we need to change all occurrences of gettextutils blah blah, to use the common/i18n ones.16:30
JayFrameshg87: we don't want to do it the same way as pxe, because we don't want to pass around ironic admin tokens if possible :x16:30
JayFIMO noauth is better than passing around an Ironic admin token, in IPA context16:30
jrollrameshg87: in an hour or two I will have code up that does this... can we chat about it in the meeting maybe? I'd like lots of opinions on this16:30
JayFbecause you can at least secure the networks and limit it by IP :x16:30
jrollJayF: better? probably not :/ but I know what you mean :)16:31
rameshg87jroll: JayF: i was just checking regarding integration of ilo-virtual-media with IPA16:31
JayFjroll: I think it's a ton better16:31
Shrewsrloo: but i think the common directory one is likely outdated. i18n is it's own module now: https://github.com/openstack/oslo.i18n16:31
JayFrameshg87: for iLo, with an oob way to get things there, I'16:32
JayFrameshg87: I think you ahve more interesting options16:32
rameshg87JayF: yes, passing admin token is okay with iLO16:32
jrollagree16:32
rameshg87JayF: i was just trying to put up a spec for ilo-ipa integration, you guys can review it16:32
JayFI think passing around admin tokens in general is not wonderful, I wish there was a way for us to have something more limited than a full ironic admin token16:33
JayFthat could only do the things ipa needs to do16:33
openstackgerritLucas Alvares Gomes proposed a change to openstack/ironic: Rename/update common/tftp.py to common/pxe_utils.py  https://review.openstack.org/10359516:33
openstackgerritLucas Alvares Gomes proposed a change to openstack/ironic: Add iPXE Installation Guide documentation  https://review.openstack.org/10680916:33
openstackgerritLucas Alvares Gomes proposed a change to openstack/ironic: Add iPXE support for Ironic  https://review.openstack.org/9931816:33
JayFI'd just rather have the endpoints IPA hit be unauthed than giving IPA a full admin token to Ironic, if those are the choices16:33
JayFa limited access user/token is much less scary imo, but we don't have that16:33
jrollrameshg87: awesome, would love to look16:33
rameshg87JayF: okay16:34
rameshg87JayF: jroll: just wanted to check if we can factor out the boot vs "actual deploy" code  in IPA separately16:34
JayFwhat do you mean boot vs actual deploy?16:34
jrollrameshg87: yes definitely16:34
JayFOh, you mean booting it in ways other than pxe? for sure.16:34
JayFjust probably not with our current set of images16:34
rameshg87JayF: jroll: ah something like making it easy to replace  the "pxe" parts of ipa with "ilo virtual media"16:34
JayFIPA is software than runs places. Right now we only have a CoreOS ramdisk to run it in. You could almost certainly install it in something other than a ramdisk16:35
jrollJayF: in general we have been talking abour separating "how does ironic interact with a deploy ramdisk" from "how does ironic put a ramdisk on a node"16:35
JayFrameshg87: I'm assuming iLo wants a full disk image with kernel integratied?16:35
rameshg87JayF: sorry, i meant in the deploy driver in ironic16:35
jrollrameshg87: I think that division will be in the ironic driver interfaves... but yes can do16:35
rameshg87JayF: let me bring in what i am talking about16:36
rameshg87JayF: i saw your very old review that has been abandoned to see how the code will look like (eventhough it might change)16:36
rameshg87JayF: jroll: https://review.openstack.org/#/c/84795/16:36
JayFrameshg87: that is not me. that is JoshNang16:37
jrollrameshg87: see review 101020 for somewhat current code16:37
JayFalthough he sits a desk across from me :)16:37
rameshg87JayF: okay :-)16:37
rameshg87jroll: just checking ..16:37
jrollrameshg87: will be updating 101020 later today16:37
jrollrameshg87: the new review is similar to pxe driver, at least in terms of how to boot16:38
jrollso replacing will be similar16:38
rlooShrews: I guess we should find out from GheRivero. It looks to me like the common/i18n file was added 5 days ago, and it uses oslo.i18n, so I think it is needed.16:38
rlooShrews: see http://docs.openstack.org/developer/oslo.i18n/usage.html#creating-an-integration-module16:39
Shrewsrloo: ah, ok16:39
rlooShrews: and I really don't want to know any more about this ;)16:39
rameshg87jroll: JayF: in ilo virtual media, we will have an iso, instead of a kernel/ramdisk. the iso will contain the kernel and ramdisk and how to boot up the ramdisk16:39
Shrewsrloo: lol16:39
JayFrameshg87: I suspect we could easily setup a coreos image that'd be a fully contained ramdisk16:40
*** pcrews has joined #openstack-ironic16:40
rameshg87jroll: JayF: the extra parameters for deploy and the token (if required), we are planning to pass through the virtual media floppy16:40
JayFrameshg87: Does DIB produce an ISO?16:40
JayFThat should be easy to do, you'll just have to build up another image16:40
anteayaso romcheg was working on something and then went offline16:40
rameshg87JayF: we are changing DIB to produce ISO. it's a small change.16:40
rameshg87JayF: yes :-)16:40
JayFrameshg87: OK, fwiw, we don't have any DIB elements built yet16:40
jrollrameshg87: right, I understand. we're doing those options the same way as pxe16:40
anteayahe was having an issue with six versioning and using the openstackclient16:40
anteayarequirements for the openstackclient are different from what was installed for what he was running: http://git.openstack.org/cgit/openstack/python-openstackclient/tree/requirements.txt16:41
JayFrameshg87: Looking at the images, I'm 90% sure it'd be possible to do the ISO using coreos as well.16:41
rameshg87jroll: please have a look at https://review.openstack.org/#/c/107996/16:41
*** romcheg2 has joined #openstack-ironic16:41
JayFrameshg87: or like you said, support it in DIB, but we don't have the elemnts yet16:41
rameshg87jroll: i am proposing to change _cleanup_caches_if_required() to a common place. may be you might have a say on that.16:42
rameshg87jroll: i see that used in your code.16:42
*** romcheg1 has quit IRC16:43
jrollrameshg87: I like it :)16:43
jrollrameshg87: go ahead... if your code lands first, I can do the work to move it in ipa driver16:44
rameshg87JayF: jroll: just a quick look at the code. i guess it might be easy to integrate.16:44
*** martyntaylor has joined #openstack-ironic16:44
jrollrameshg87: I'll +1 or add comments on that spec shortly16:44
rameshg87JayF: jroll: i just need to setup the machine to boot up through virtual media parameters and looks like the vendor passthru will take care of all the other things :-)16:44
rameshg87jroll: thanks :-)16:45
jrollrameshg87: np :)16:45
*** lucasagomes is now known as lucas-dinner16:45
lucas-dinnerI will be back for the meeting16:45
rameshg87jroll: just one question16:47
jrollsure16:47
rameshg87jroll: in _reboot_to_instance(), i see we are setting boot from disk16:47
rameshg87jroll: so ipa supports only disk images ?16:48
rameshg87jroll: we won't use pxe to boot up an instance ?16:48
jrollrameshg87: today, yes, but it should be trivial to use pxe16:48
rameshg87jroll: okay. and this worries me :-(16:49
rameshg87jroll: sending raw bytes16:49
rameshg87jroll: task.driver.ipmi_vendor._send_raw_bytes(task, '0x00 0x08 0x03 0x08')16:50
jrollto ipmi? why? (it is a pretty standard set of bytes... not optimal but a lot of hardware doesnt boot from disk without that16:51
JoshNangi'm pretty sure phygmi also sends those bytes (but automatically)16:51
rameshg87jroll: okay. will check that part. worried because ilo will not use ipmi.16:52
jrollpyghmi does16:52
jrollrameshg87: right, that would be part of the boot code16:52
rameshg87jroll: yes..16:52
jrollrameshg87: I hate that it is there and might fix it in a better way :)16:52
rameshg87jroll: would love if you would just give some hook so that it can be replaced easily with ours16:52
jrollrameshg87: all of this sit is going to be a larger refactor in ironic itself :/16:53
rameshg87jroll: may be a method which we can inherit and change..i don't know..may be we can discuss and sort it out.. :-)16:53
jrolls/sit/stuff/?16:53
rameshg87jroll: :-)16:53
jrollrameshg87: I think ironic will end up with a bootinterface and a deployinterfave16:54
*** romcheg1 has joined #openstack-ironic16:54
jrollface16:54
rameshg87jroll: yeah16:54
jrollromcheg1: anteaya is looking for you :)16:54
rameshg87jroll: but may be only in K, we could make an early proposal for that.16:54
rameshg87jroll: when K opens.16:54
anteayaromcheg1: you disappeared16:55
rameshg87jroll: so that we can mix - different boot methods with different deploy engines16:55
*** romcheg2 has quit IRC16:55
anteayaromcheg1: so whatever you are installing is using a version of six that is too low for openstackclient16:55
anteayaromcheg1: http://git.openstack.org/cgit/openstack/python-openstackclient/tree/requirements.txt16:55
jrollrameshg87: yep, I would propose that spec in the k directory :)16:55
NobodyCamhey anteaya long time no see16:55
NobodyCamwelcome back home :)16:56
anteayaNobodyCam: how are you?16:56
anteayaNobodyCam: I'm in frankfurt16:56
anteaya:D16:56
rameshg87jroll: okay. i will wait for your next patch set.16:56
rameshg87jroll: meanwhile i will raise a spec for ilo-ipa integration.16:56
GheRiverorloo: Shrews: the i18n.py common landed last week. The only change missed is to replace all gettextutils injection, and import the _LW, _, LD from i18n.py when needed16:56
NobodyCamdoing good, I'm in Raleigh, NC16:56
ShrewsGheRivero: ah, ok. thx16:57
rlooGheRivero: is there a bug or are you going to do the missing stuff?16:57
jrollrameshg87: cool16:57
GheRiverorloo: I'm doing/will do it. But I can open a bug to keep track of it if you want16:58
anteayaNobodyCam: nice16:58
anteayaNobodyCam: how is Raleigh treating you?16:58
rlooGheRivero: it would be good to open a bug. Then I would have known that it is something to be done.16:58
rloothx GheRivero ;)16:58
NobodyCam:) its nice, We're running the TripleO mid cycle right now16:58
GheRiverorloo: Sure. My bad. Opening it now16:58
anteayaNobodyCam: ah yes, how is it going?16:59
*** bvivek has quit IRC17:00
NobodyCamanteaya: So far Well, :) but we're just getting rolling17:01
*** Mikhail_D_ltp has joined #openstack-ironic17:02
anteayaNobodyCam: :D17:03
anteayaNobodyCam: I hope you have a great time17:03
*** malini1 has quit IRC17:05
rameshg87devananda: NobodyCam: request you to take a look at revised ilo virtual media deploy spec, https://review.openstack.org/#/c/9774417:06
*** harlowja_away is now known as harlowja17:12
*** ChuckC has joined #openstack-ironic17:12
openstackgerritGhe Rivero proposed a change to openstack/ironic: Avoid calling _parse_deploy_info twice.  https://review.openstack.org/10844217:16
openstackgerritRamakrishnan G proposed a change to openstack/ironic-specs: iLO-IPA Deploy Driver  https://review.openstack.org/10844517:20
*** Alexei_9871 has left #openstack-ironic17:24
*** martyntaylor has left #openstack-ironic17:38
jrollwould it be ok for me to approve this? lucas rebased it for me, it was +A before that. https://review.openstack.org/#/c/10073517:41
jrolldevananda: ^17:41
jrollbarring jenkins ofc17:41
jroll(or you could do it :)17:41
openstackgerritJosh Gachnang proposed a change to openstack/ironic: Adding swift temp url support  https://review.openstack.org/8139117:43
*** Haomeng|2 has joined #openstack-ironic17:45
*** shakamunyi_ has joined #openstack-ironic17:46
*** athomas has quit IRC17:46
rloojroll: I was going to approve it after jenkins. did you want me to approve it now? (100735)17:46
*** Haomeng has quit IRC17:46
jrollrloo: either is fine17:47
jrolljenkins won't let it merge if it fails, so it's your call :)17:47
jrollI just want to make sure it lands :)17:47
rloojroll: I waited cuz lucas didn't approve it but why wait ;) Let's see what happens. And I would say it is OK for you to approve it ;)17:49
*** shakamunyi has quit IRC17:49
jrollha, ok. thanks! :)17:49
*** martyntaylor has joined #openstack-ironic17:51
JayFNobodyCam: if you want any tips about what to do/where to eat in Raleigh, LMK -- that's my hometown :)17:54
*** rainya has quit IRC17:56
*** martyntaylor has quit IRC17:56
*** rainya has joined #openstack-ironic17:57
NobodyCamwoo hoo17:58
*** rainya has quit IRC18:00
*** rameshg87 has quit IRC18:01
JayFNobodyCam: You gotta make sure to eat at The Pit while you're there --> http://www.thepit-raleigh.com/18:02
devanandajroll: yea. when it's clear (like this) that you're not just approving your own patch, it's fine -- but when others are available, it's better for someone else to do it18:03
jrolldevananda: thought so, thanks18:04
devanandajroll: also, py26 is failing18:04
devanandait seems like that job is failing everything18:04
*** malini1 has joined #openstack-ironic18:04
jrolloh yeah18:04
jrollAWESOME18:04
JayFgcc failed18:04
JayFwhile installing requirements18:04
jrollJayF: that's happening on most patches18:04
jrollright now18:04
JayFhooray18:05
*** martyntaylor has joined #openstack-ironic18:05
*** rainya has joined #openstack-ironic18:05
openstackgerritGhe Rivero proposed a change to openstack/ironic: Raise MissingParameterValue instead of invalid  https://review.openstack.org/10845518:07
openstackgerritGhe Rivero proposed a change to openstack/ironic: Use _check_for_missing_params when validating glance info  https://review.openstack.org/10845618:07
openstackgerritJim Rollenhagen proposed a change to openstack/ironic: Add ironic-python-agent deploy driver  https://review.openstack.org/10102018:07
*** rainya has quit IRC18:09
NobodyCamJayF: oh yummy !!!18:10
jrollwinning: https://review.openstack.org/#/c/108457/18:10
JayFNobodyCam: also look up Smokey's BBQ Shack in Morrisville, if you're driving out that far. Mmmm bbq18:11
JayFSmokey's BBQ shack is the hole-in-the-wall type place you'd only know about if a local (me) told you about :P so go there if you've got a car18:11
NobodyCamJayF: no car :-p18:12
JayFNobodyCam: aw, the Pit should be able to be gotten to easily from RH HQ though18:14
JayFNobodyCam: they're still in NCSU Centinnial Campus, right?18:14
NobodyCamwe on 100 E Davie St, Raleigh, NC18:16
JayFthe progress energy building?18:16
JayFheh18:16
JayFI think the pit might be walking distance18:16
JayFAlso I wonder where Coopers BBQ moved to, their old place was right by ther etoo18:16
NobodyCam:)18:17
openstackgerritChris Krelle proposed a change to openstack/ironic: Add option to allow soft power off  https://review.openstack.org/10777818:21
openstackgerritGhe Rivero proposed a change to openstack/ironic: Fix tear_down a node with missing info  https://review.openstack.org/10368518:26
openstackgerritGhe Rivero proposed a change to openstack/ironic: Avoid calling _parse_deploy_info twice.  https://review.openstack.org/10844218:26
*** harlowja has quit IRC18:27
*** harlowja has joined #openstack-ironic18:35
*** jgrimm has quit IRC18:38
*** lucas-dinner is now known as lucasagomes18:51
lucasagomesdevananda, NobodyCam ayou guys around?18:51
devanandalucasagomes: yah. with GheRivero and adam_g and Shrews18:52
lucasagomesdevananda, nice... just checking if you want to chair the meeting or I should do it18:53
devanandalucasagomes: go for it. I'm already multitasking too many f2f conversations18:53
lucasagomeshah ack18:53
devanandalucasagomes: and likely to pull these fine folks away from their computers in a minute to talk about ironic :)18:54
lucasagomesdevananda, +1 go for it!18:54
*** rakesh_hs has quit IRC18:55
dtantsurlucasagomes, you have a chance of leading a private party :D18:56
lucasagomesdtantsur, heh... not that private18:56
*** mrda-away is now known as mrda18:58
mrdaMorning Ironic!18:59
romcheg1Good morning mrda!19:00
lucasagomesmorning19:01
lucasagomesmeeting time19:01
jrollmrda \o19:01
*** tatyana has joined #openstack-ironic19:01
*** Nisha has quit IRC19:15
*** enikanorov_ has joined #openstack-ironic19:16
mrdarloo: the nova reviews have comments in them linking to the ironic reviews, and the child ironic reviews have links in them back to the parent nova reviews.19:17
mrdarloo: happy to explain more if necessary ;)19:17
rloomrda: no worries. I figured it out via the etherpad ;) I had wondered about those patches but didn't think they were 'important'.19:17
mrdarloo: you eyeballs would be very welcome on those reviews :)19:18
rloomrda: yup, will do now that I know :-)19:18
mrdawe do need quite turnaround on these reviews so I can get the Nova reviewers focussed19:19
rloomrda: understandable. Esp by next week...19:19
mrdathanks rloo, sorry this was explained previously19:20
mrda^^wasn't19:20
rloomrda: no worries. It might have been and I might have missed it. Or not. But now we know :-)19:20
mrdaif there's any questions on getting the nova ironic driver in, let me know because I'm now focusing on this19:22
openstackgerritNisha Agarwal proposed a change to openstack/ironic-specs: Discover node properties at node-create/node-update  https://review.openstack.org/10095119:26
*** achanda has joined #openstack-ironic19:26
*** achanda has quit IRC19:38
*** malini1 has quit IRC19:42
*** tatyana has quit IRC19:50
*** malini1 has joined #openstack-ironic19:52
*** jdob has quit IRC19:52
*** jdob has joined #openstack-ironic19:56
lucasagomesyay, alright folks it's pretty late here and I'm starving20:01
lucasagomesthanks for the meeting!20:01
lucasagomeshave a good night everyone20:01
dtantsurg'night, lucasagomes20:01
jrollnight lucas20:01
dtantsurI'm also going20:01
jrollnight dtantsur20:01
* jroll goes afk for a bit20:02
*** lucasagomes is now known as lucas-dinner20:02
*** achanda has joined #openstack-ironic20:02
*** igordcard has joined #openstack-ironic20:03
* mrda goes back to sleep20:05
*** dtantsur is now known as dtantsur|afk20:06
*** achanda has quit IRC20:07
*** Nisha has joined #openstack-ironic20:08
victor_lowtherhttps://github.com/eventlet/eventlet/issues/94 appears to still be an issue in the ironic codebase20:14
victor_lowtherat least, it seems to be screwing up my devtest runs rather alot.20:14
openstackgerritNisha Agarwal proposed a change to openstack/ironic-specs: Discover node properties for iLO driver  https://review.openstack.org/10300720:20
*** martyntaylor has left #openstack-ironic20:23
adam_gShrews,  http://paste.ubuntu.com/7832262/20:23
adam_ghttp://atdt.no-carrier.net:18080/~adam/results.html20:25
jrollvictor_lowther: yeah, we see that in jenkins too :|20:25
victor_lowtherIt is seriously harshing my devtest mellow, because nova-baremetal Just Won't Do.20:27
*** Nisha has quit IRC20:27
jrollindeed20:27
*** amitpp has joined #openstack-ironic20:29
*** amitpp has quit IRC20:29
*** romcheg1 has quit IRC20:36
*** romcheg1 has joined #openstack-ironic20:44
*** jgrimm has joined #openstack-ironic20:46
devanandamrda: ping20:57
devanandamrda: we've been chatting about the client token caching20:57
devanandamrda: and figure it'd be really good to involve you :)20:58
*** chuckC_ has joined #openstack-ironic21:08
*** matty_dubs is now known as matty_dubs|gone21:09
*** jdob has quit IRC21:13
*** romcheg1 has left #openstack-ironic21:16
*** malini1 has quit IRC21:22
*** shakamunyi_ has quit IRC21:24
mrdahey devananda21:25
mrda(sorry fell asleep)21:25
devanandamrda: hey there!21:27
mrda\o21:27
devanandamrda: so Shrews posted a comment on your patch21:27
mrdagreat21:27
mrdaI'll take a look21:28
mrdahmmm, ok21:29
devanandamrda: i think what we want is to cache and share the token among requests21:30
devanandamrda: but not use a shared TCP connection21:30
devanandamrda: and after shrews sharing his concern and me digging into it, i think the current code is going to try to share a socket among multiple greenthreads21:31
mrdayeah, just thinking through the consequences of that21:31
*** romcheg1 has joined #openstack-ironic21:32
Shrewsmrda: hope my comments made sense. let me know if not21:32
mrdaIt should be possible to just share the token, but how to differentiate the callers so the socket isn't shared...21:32
mrdaShrews: thanks for thinking through this21:33
mrdaI'll see what I can come up with to address these concerns21:33
*** chuckC_ has quit IRC21:35
NobodyCamtempest.api.compute.servers.test_attach_interfaces.AttachInterfacesTestJSON.test_create_list_show_delete_interfaces21:38
*** rameshg87 has joined #openstack-ironic21:38
openstackgerritRamakrishnan G proposed a change to openstack/python-ironicclient: Add ironic cli support for vendor-passthru  https://review.openstack.org/10129721:40
*** romcheg1 has left #openstack-ironic21:49
Shrewsdevananda: https://review.openstack.org/107710   implementation of nodelocked retry21:56
*** ChuckC has quit IRC21:58
NobodyCamhttps://github.com/openstack/tempest/blob/master/tempest/services/compute/json/interfaces_client.py#L7721:59
*** derekh_ has quit IRC22:01
*** rwsu has quit IRC22:02
mikalMorning22:08
mikaldevananda: are yuo really opposed to landing the refactor in https://review.openstack.org/#/c/107316/ in your tree, even temporarily?22:10
devanandamikal: hi! i don't see why we'd add code unrelated to ironic22:10
devanandamikal: i dont see any benefit, even in our process22:11
mikaldevananda: because you're requiring our review comments to be implemented in your tree first?22:11
devanandamikal: that should simply be a separate patch to nova22:11
mikaldevananda: but that will break your driver in your tree22:11
devanandamikal: it's a cross-project coordination22:11
devanandamikal: yep22:11
mikaldevananda: as we will require that your new driver use that new base class22:11
devanandamikal: wait. how will landing that in nova break ironic?22:12
devanandamikal: this cross tree deps stuff is painful :(22:12
mikaldevananda: your preferred process (which I have been trying to work with) is that you land the changes we ask for in your tree before proposing them in ours. We will ask you to use the base class, which you will then need to land in your tree, thus breaking your driver.22:12
mikaldevananda: the base class would only be temporary in your tree (for however long it takes to get the driver into nova)22:13
mikaldevananda: I assume the entire nova directory gets deleted from your tree once its landed in ours22:13
mikaldevananda: so I really don't see why you'd care about landing that base class22:13
devanandamikal: eh. I didn't see the relevance to having it in our tree. but I was probably in an airport when I posted that comment.22:14
devanandamikal: if it really simplifies things that much, OK22:14
mikaldevananda: we will have to keep the baremetal code around for probably another year22:14
mikaldevananda: so the base class is a win for us as its less code for us to carry around22:15
mikaldevananda: I agree its irrelevant to your tree, but so is the entire nova driver22:15
devanandamikal: right. also, remind me - why are you keeping an untested driver in tree?22:15
mikaldevananda: because it pre-exists those requirements and got a special case for the CI requirements last cycle because it was on a deprecation path22:17
mikaldevananda: basically because we're trying to not throw users under the bus22:17
mikaldevananda: and I know you like to insist there are no users, but I think that's untrue22:17
mikaldevananda: tripleo uses it for example, thus showing that it is possible to use22:17
*** Mikhail_D_ltp has quit IRC22:18
* JayF thinks a user of nova-bm would be the person driving the bus, and devananda is the person being thrown under it ;)22:19
*** jogo has joined #openstack-ironic22:19
mikalThe TC requirements for replacing and openstack component have been around for quite a while now22:19
mikalRequiring an upgrade path and staged deprecation should not be a surprise to anyone22:20
devanandamikal: dont go quoting that req to me, please ...22:20
devanandamikal: is nova maintaining the baremetal driver code? are you guys testing it in devstack-gate?22:21
devanandais anyone fixing bugs in it?22:21
jogodevananda: as for upgrade testing, I think we can use javelin22:21
devanandajogo: you can't even use grenade22:21
devanandajogo: please read my email(s) on that subject22:21
jogowe can turn off the old checks22:21
jogoand just do javelin22:21
mikaldevananda: all of that is irrelevant22:22
mikaldevananda: sure, its horrible and under tested22:22
mikaldevananda: but it still might have users22:22
mikaldevananda: we shipped it and therefore be responsible about deprecating it22:22
devanandamikal: does that responsibility mean preventing another project's progress?22:22
mikalYes, I think it does22:23
openstackgerritGhe Rivero proposed a change to openstack/ironic: Avoid calling _parse_deploy_info twice  https://review.openstack.org/10844222:23
mikalIt is the clear intent of the TC in the requirements to block graduation for projects until they have handled this deprecation case22:24
mikal* In the case that a project has intentionally duplicated functionality of22:24
mikal  another project, or portion of a project, the new project must reach a level22:24
mikal  of functionality and maturity such that we are ready to deprecate the old22:24
openstackgerritGhe Rivero proposed a change to openstack/ironic: Fix tear_down a node with missing info  https://review.openstack.org/10368522:24
mikal  code and remove it after a well defined deprecation cycle.  The deprecation22:24
mikal  plan agreed to by the PTLs of each affected project, including details for22:24
mikal  how users will be able to migrate from the old to the new, must be submitted22:24
mikal  to the TC for review as a part of the graduation review.22:24
mikali.e. ironic must convince the TC that the baremetal users have not been dead ended22:24
devanandaWow. I asked you not to quote that, and you actually pasted it22:24
devananda:(22:24
mikaldevananda: because you're not listening22:24
mikalI am trying to help you here22:24
mikalThe only code reviews I have done for the last couple of days have been in _your_tree_22:24
mikalNo one else is getting that22:25
mikalBut what I get in return is complaints about a process we've been warning you about for ages22:25
mikalYou can't pretend that requirement doesn't exist22:25
mikalIt does, and you must meet it22:25
*** jcoufal has quit IRC22:25
openstackgerritA change was merged to openstack/ironic: Use mock.assert_called_once_with()  https://review.openstack.org/10841822:27
devanandamikal: so I proposed a plan for that on May 22. It got a +2 on Jun 18, a few minor nits, and then a -2 on July 1622:27
devanandamikal: and then last week, we talked about it, which should have happened months ago22:28
devanandamikal: we have been working on and proposing code to DO the upgrade in parallel with the spec22:28
devanandamikal: but no one on Nova has looked22:28
devanandauntil now22:28
devanandajogo: i don't know what javelin is or how that helps here. please explain.22:29
devanandamikal: also, thank you for the code reviews. I am sure taht you're busier than I am, and I really do appreciate your input here.22:29
*** malini1 has joined #openstack-ironic22:30
devanandamikal: even though we've had a near vacuum for months, and then got thrown under the bus because teh upgrade spec wasn't landed in time22:30
jogodevananda: its what grenade uses to make sure resources stay around after an upgrade22:30
jogoso you create some resources on old22:30
jogoupgrade22:30
jogocheck on new cloud22:31
jogoso for ironic it would be:22:31
jogocreate resources on old nova-bm22:31
jogocheck on ironic22:31
*** jgrimm has quit IRC22:31
devanandajogo: and does that require actually BOOTING anything with nova-bm?22:32
devanandaalso - food.. I really need to eat22:32
devanandaand sleep22:32
jogodevananda: it requires nova to think something has booted22:33
jogoI dont' think it SSHs in or anything22:33
jogoif it does we can make that an option22:33
* devananda gets food22:34
mikaldevananda: so, I get that you have a plan for upgrade. That's why I am surprised when it keeps coming up. What this conversation started as was -- if you want to land our review requests in your tree first, then you will need to land some changes which are irrelevant to a strict interpretation of ironic but which make sense in the context of nova. That shouldn't be a big deal, because your copy of the code will be deleted soon.22:35
mikaldevananda: i.e. we want that refactor of the host manager class, and if that means landing a base class (and possibly the baremetal host manager) in your repo temporarily, then so be it22:36
mikalI have to go feed a baby, back in a bit22:36
openstackgerritA change was merged to openstack/ironic: Factor out deploy info from PXE driver  https://review.openstack.org/10073522:39
*** Haomeng has joined #openstack-ironic22:42
*** Haomeng|2 has quit IRC22:44
*** lucas-dinner has quit IRC22:44
*** malini1 has quit IRC22:44
mikal.22:45
*** shakamunyi_ has joined #openstack-ironic22:53
*** rainya has joined #openstack-ironic22:58
*** malini1 has joined #openstack-ironic23:07
openstackgerritA change was merged to openstack/ironic: Use oslo.db library  https://review.openstack.org/4215923:12
*** rainya has quit IRC23:18
*** mdorman has quit IRC23:23
*** shakamunyi_ has quit IRC23:33
*** chuckC has joined #openstack-ironic23:39
*** rameshg87 has left #openstack-ironic23:44
*** igordcard has quit IRC23:45
*** eghobo has quit IRC23:58

Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!