Thursday, 2014-08-07

*** f13o_ has quit IRC00:01
* NobodyCam loves that his irc host is set to utc time and that 5 pm pst is midnight utc00:07
*** igordcard has quit IRC00:15
devanandaright - it's after midnight somewhere. I'm going afk for a while :)00:18
NobodyCamdevananda: did you get any REST today?00:19
devanandaNobodyCam: no00:19
NobodyCam:(00:19
*** eghobo has quit IRC00:27
*** chuckC has quit IRC00:47
*** jasondotstar has quit IRC00:48
*** marzif_ has quit IRC00:55
*** jasondotstar has joined #openstack-ironic00:55
*** jasondotstar has quit IRC00:59
*** eghobo has joined #openstack-ironic01:02
*** ellenh has quit IRC01:05
Shrewsdevananda: ack01:07
*** jasondotstar has joined #openstack-ironic01:12
*** nosnos has joined #openstack-ironic01:41
*** jgrimm has joined #openstack-ironic01:43
lifelessadam_g: 103685 has conflicts with trunk01:43
*** eghobo has quit IRC01:43
*** eghobo has joined #openstack-ironic01:44
*** chenglch has joined #openstack-ironic01:45
*** eghobo has quit IRC01:46
*** chuckC has joined #openstack-ironic01:57
*** Poornima has joined #openstack-ironic02:40
*** jasondotstar has quit IRC02:42
*** eghobo has joined #openstack-ironic03:50
*** vinbs has joined #openstack-ironic03:54
*** nosnos has quit IRC03:56
*** jgrimm has quit IRC04:21
*** Poornima has quit IRC04:21
vinbsMorning Ironic! :)04:23
*** Nisha has joined #openstack-ironic04:24
*** LiveOne_ has joined #openstack-ironic04:28
*** davidlenwell_ has joined #openstack-ironic04:28
*** pcrews has quit IRC04:29
*** proffalk1n has joined #openstack-ironic04:30
*** GheRiver1 has joined #openstack-ironic04:30
*** gilliard_ has joined #openstack-ironic04:31
*** Hefeweiz1n has joined #openstack-ironic04:31
*** nosnos has joined #openstack-ironic04:34
*** MattMan2 has quit IRC04:35
*** LiveOne has quit IRC04:35
*** Hefeweizen has quit IRC04:35
*** anteaya has quit IRC04:35
*** antonym has quit IRC04:35
*** proffalken has quit IRC04:35
*** GheRivero has quit IRC04:35
*** greghaynes has quit IRC04:35
*** gilliard has quit IRC04:35
*** davidlenwell has quit IRC04:35
*** LiveOne_ is now known as LiveOne04:36
*** MattMan has joined #openstack-ironic04:42
*** antonym has joined #openstack-ironic04:43
*** greghaynes has joined #openstack-ironic04:43
*** anteaya has joined #openstack-ironic04:43
*** Poornima has joined #openstack-ironic04:51
*** ramineni has joined #openstack-ironic04:53
Haomengvinbs: morning:)04:54
*** Nisha has quit IRC04:54
*** k4n0 has joined #openstack-ironic04:56
adam_gGheRiver1, https://review.openstack.org/#/c/103685/ is this still needed? any chance of a rebase if we should still be pulling it in?05:06
adam_gromcheg, emailed you a patch to your migration script, you should also propose the flavor migration script and subscribe it to the ironic_grenade topic. gnight!05:07
*** lazy_prince has quit IRC05:19
*** rakesh_hs has joined #openstack-ironic05:20
*** k4n0 has quit IRC05:21
*** sabah has joined #openstack-ironic05:22
*** k4n0 has joined #openstack-ironic05:34
*** pradipta_away is now known as pradipta05:37
*** killer_prince has joined #openstack-ironic05:46
*** killer_prince is now known as lazy_prince05:46
*** bmahalakshmi has joined #openstack-ironic05:52
*** pcrews has joined #openstack-ironic05:58
*** GheRiver1 is now known as GheRivero06:04
*** pcrews has quit IRC06:06
*** k4n0 has quit IRC06:12
*** Mikhail_D_ltp has joined #openstack-ironic06:21
openstackgerritHaomeng,Wang proposed a change to openstack/ironic: WIP: Add send-data-to-ceilometer support for pxe_ipminative driver  https://review.openstack.org/11248606:22
openstackgerritGhe Rivero proposed a change to openstack/ironic: Raise MissingParameterValue instead of Invalid  https://review.openstack.org/10845506:24
openstackgerritGhe Rivero proposed a change to openstack/ironic: Raise MissingParameterValue when validating glance info  https://review.openstack.org/10845606:25
openstackgerritGhe Rivero proposed a change to openstack/ironic: Avoid calling _parse_deploy_info twice  https://review.openstack.org/10844206:26
*** k4n0 has joined #openstack-ironic06:28
*** Nisha has joined #openstack-ironic06:34
*** dtantsur|afk is now known as dtantsur06:38
dtantsurMorning, Ironic06:38
*** ifarkas has joined #openstack-ironic06:41
*** pradipta is now known as pradipta_away06:46
*** bvivek has joined #openstack-ironic06:46
*** eghobo has quit IRC06:46
*** nikunj2512 has joined #openstack-ironic06:56
*** rameshg87 has joined #openstack-ironic07:01
rameshg87dtantsur, hi07:01
openstackgerritRamakrishnan G proposed a change to openstack/ironic: Move code to cleanup ImageCache to a common place  https://review.openstack.org/11056007:03
openstackgerritImre Farkas proposed a change to openstack/ironic-specs: DRAC vendor passthru for RAID management  https://review.openstack.org/10798107:07
dtantsurbrb07:08
dtantsurrameshg87, hi07:08
rameshg87dtantsur, needed your initial thoughts on a change on image_cache test case07:08
rameshg87dtantsur, yesterday jroll and myself were discussing on this07:09
dtantsurrameshg87, sure, but a bit later07:09
dtantsurbreakfast time now :)07:09
rameshg87dtantsur, ah okay .. sorry go ahead :-)07:09
openstackgerritGhe Rivero proposed a change to openstack/ironic: Fix tear_down a node with missing info  https://review.openstack.org/10368507:10
*** rameshg87 has quit IRC07:10
*** rameshg87 has joined #openstack-ironic07:10
*** rakesh_hs has quit IRC07:20
*** rakesh_hs has joined #openstack-ironic07:21
*** nikunj2512 has quit IRC07:25
*** nikunj2512 has joined #openstack-ironic07:26
*** rameshg87_ has joined #openstack-ironic07:29
*** rameshg87 has quit IRC07:29
*** sabah has quit IRC07:29
*** subah has joined #openstack-ironic07:29
vinbshi dtantsur07:32
vinbs:)07:32
openstackgerritA change was merged to openstack/ironic: Sync oslo.incubator modules  https://review.openstack.org/11094107:38
*** jistr has joined #openstack-ironic07:42
*** bvivek has quit IRC07:47
*** foexle has joined #openstack-ironic07:57
*** lucasagomes has joined #openstack-ironic08:17
dtantsurvinbs, hi!08:30
dtantsurrameshg87_, I'm back, sorry for delay08:30
rameshg87_hi dtantsur08:31
rameshg87_dtantsur, yesterday myself and jroll were discussing about a test refactoring. just thought of checking with you08:32
rameshg87_dtantsur, https://github.com/openstack/ironic/blob/master/ironic/tests/drivers/test_pxe.py#L372-L49208:32
rameshg87_dtantsur, they seem to be testing the image_cache's cleanup extensively and not actually fetch_images08:33
dtantsurrameshg87_, yes, because this logic used to be somewhere there. Now it needs to be moved to test_image_cache and test you new shiny cleanup function :)08:33
rameshg87_dtantsur, so better move it to test_image_cache.py and add a small test case for fetch_images - fetch_images as such doesn't have much functionality08:34
rameshg87_dtantsur, yeah :-)08:34
dtantsurI agree08:34
rameshg87_dtantsur, just did that and put up a patch. https://review.openstack.org/#/c/110560/08:34
dtantsurack, will have a look08:35
rameshg87_dtantsur, thanks :-)08:36
*** mitz has quit IRC08:49
vinbsdtantsur, about the bug https://bugs.launchpad.net/ironic/+bug/132358908:51
dtantsursure08:51
vinbsdtantsur, how do I upload the patch? I have the instructions on an etherpad08:51
*** pelix has joined #openstack-ironic08:52
vinbsdtantsur, should I just upload the instructions in a text file?08:53
openstackgerritAndrey Kurilin proposed a change to openstack/ironic: Use timeutils from one place  https://review.openstack.org/11230308:53
dtantsurvinbs, no, I guess you should fix doc/source/deploy/install-guide.rst using your instructions, i.e. adding missing things etc08:54
*** igordcard has joined #openstack-ironic09:05
*** marzif_ has joined #openstack-ironic09:07
*** dtantsur is now known as dtantsur|lunch09:07
vinbsdtantsur, got it! thanks09:08
*** bvivek has joined #openstack-ironic09:13
openstackgerritA change was merged to openstack/ironic: Migration to oslo.utils library  https://review.openstack.org/11059609:16
*** athomas has joined #openstack-ironic09:18
*** Mikhail_D_ltp has quit IRC09:29
*** proffalk1n has quit IRC09:30
*** Mikhail_D_ltp has joined #openstack-ironic09:30
*** proffalken has joined #openstack-ironic09:32
openstackgerritAndrey Kurilin proposed a change to openstack/ironic: Use timeutils from one place  https://review.openstack.org/11230309:41
*** srinivas has joined #openstack-ironic09:57
*** Nisha has quit IRC09:58
*** sirushti has left #openstack-ironic10:02
*** nikunj2512 has quit IRC10:06
*** Nisha has joined #openstack-ironic10:07
*** nikunj2512 has joined #openstack-ironic10:09
*** sirushti has joined #openstack-ironic10:10
*** chenglch has quit IRC10:13
*** dtantsur|lunch is now known as dtantsur10:18
*** ndipanov has joined #openstack-ironic10:18
*** ndipanov has quit IRC10:18
*** Alexei_987 has joined #openstack-ironic10:33
rameshg87_dtantsur, just had a couple of questions on review of https://review.openstack.org/#/c/110560/410:34
dtantsurrameshg87_, wait a bit please, I'm on call10:35
rameshg87_dtantsur, sure ..10:35
*** srinivas has quit IRC10:36
*** subah has quit IRC10:40
openstackgerritImre Farkas proposed a change to openstack/ironic-specs: DRAC vendor passthru for RAID management  https://review.openstack.org/10798110:42
*** nikunj2512 has quit IRC10:44
*** vinbs has quit IRC10:45
*** lazy_prince has quit IRC10:45
*** killer_prince has joined #openstack-ironic10:46
*** killer_prince is now known as lazy_prince10:47
*** nikunj2512 has joined #openstack-ironic10:47
Nishalucasagomes: hi10:50
*** lazy_prince has quit IRC10:50
lucasagomesNisha, hi there10:52
Nishalucasagomes: yes i am here10:52
Nishalucasagomes: thanks for the comments10:52
Nishalucasagomes: wanted to discuss on the comments10:53
lucasagomesNisha, oh no problem... I like the concept idea of that spec, but I didn't understand much why we are using CLI commands in the spec10:53
lucasagomesso I put some comments on it10:53
Nishalucasagomes: thats where my main ques is :)10:54
Nishalucasagomes: if we dont have any changes in CLI how do we let API know about the option that discovery needs to be done10:54
lucasagomesNisha, right... I think it has to go the other way around. If we have no changes in the API how we build the CLI?10:55
lucasagomesit's fine to have changes in the CLI as part of the spec10:55
lucasagomesbut it first needs to be in the REST API, because the CLI is just a wrapper on the API10:55
lucasagomese.g the node-create command will be translated into a POST -d '{ data }' v1/nodes for the REST API10:56
Nishalucasagomes: API also has the changes and are listed in the spec. API is the way to achieve it10:56
NishaYes true10:56
lucasagomesso I think the spec should talk about the Ironic services (API/Conductor)... And it's ok to say that as part of the work the CLI will be updated10:57
Nishait speaks about that too10:57
NishaI have the prototype already working as per the spec10:58
lucasagomesNisha, yeah it's mentioned there, but as a side change. Also it says things like "This proposal makes node-create asynchronous"10:58
lucasagomesbut it doesn't say what is the return code that will be returned to be async (I'm assuming 202)10:58
lucasagomesalso how the users will track that request to know when it's finished10:59
NishaThis is because Deva has given this comment that it needs to be asynchronous10:59
lucasagomesagain node-create is the CLI command, we really should talk about POST /v1/nodes being async10:59
lucasagomesNisha, sure, yeah, if we are touching the BMC it should be async10:59
lucasagomesbecause it can take a some time to execute10:59
Nishalucasagomes: so in async how it works is, it invokes the thread which does the discovery and updates the node object.10:59
lucasagomesNisha, right, but what is returned to the user when the request is issued?11:00
lucasagomesNisha, e.g if the node creation is async11:00
lucasagomesno UUID will be returned to the client11:00
lucasagomeshow he knows which node he just created?11:00
Nishait returns the current node object without properties discovered as it does today11:00
lucasagomesah right... so the creation of the node is not async11:00
Nishain the background the node object is updated with the properties11:00
lucasagomesthe discovery of the properties is async11:01
Nishacreation of node is as it is today11:01
Nishadiscovery is async11:01
lucasagomesbut when you read "This proposal makes node-create asynchronous" you don't know that ^11:01
openstackgerritVictor Sergeyev proposed a change to openstack/ironic: Use metadata.create_all() to get database schema  https://review.openstack.org/10762911:01
lucasagomesNisha, right... I understand it better now, thanks11:01
Nishalucasagomes: so actually what all you think need to be modified in the spec?11:02
lucasagomesNisha, and what about that alternative to have 2 commands? I think that looks more sane than squeezing everything in the POST v1/nodes11:02
Nishain that approach11:02
Nishai had actually implemented that in node-create CLI itself ...ideally equivalent to have one seperate CLI for discovery11:03
lucasagomesNisha, right so for the spec we need to stop using the CLI commands as a refence11:04
lucasagomesfor e.g11:04
lucasagomeswhen you say node-create --discovery11:04
lucasagomeshow the --discovery tag will be translated to our API?11:04
Nishathe proposal is to discover properties and port create at the time of node create so manual steps can be removed11:04
lucasagomesPOST v1/nodes/?discovery=True!?11:04
NishaYes11:04
*** ramineni has quit IRC11:04
NishaI mentioned that in spec na11:04
Nishalucasagomes: see REST API impact11:05
Nishait gives that details11:06
lucasagomesNisha, right looking11:06
lucasagomesNisha, ok I just found it confused because the Proposed change actually talks about the CLI instead of the Ironic services11:07
lucasagomeswhere the changes will actually be11:07
Nishalucasagomes: is it, the spec just tells the way it needs to be invoked from a user11:08
Nishalucasagomes: IMO, the spec says about complete flow from CLI to API to conductor to driver11:08
lucasagomesNisha, right which IMO is a bit odd/wrong, cause spec is not a user manual, it should describe the changes we are making to Ironic11:09
lucasagomesNisha, but yeah I understand it better now11:10
lucasagomesthanks for that11:10
NishaOk, so you dont see any issues with the given approach11:10
lucasagomesNisha, so... about the 1 request vs 2 requests11:10
Nishalucasagomes: yes11:10
lucasagomesNisha, well... the issue I see is, the spec is confusing11:10
lucasagomesfor talking mostly about CLI instead of the API... but ok11:10
lucasagomesNisha, you think that having 1 request for the discovery is better?11:11
*** ndipanov has joined #openstack-ironic11:11
Nishalucasagomes: Yes thats where you avoid the manual step11:11
Nishacorrect?11:11
lucasagomesNisha, I don't know how I feel about having node-create to be part sync part async11:11
lucasagomesit looks pretty odd11:11
lucasagomesyou do a POST v1/nodes?discover=True11:12
lucasagomesit returns 20211:12
lucasagomesbut the node was created synchrousnly11:12
Nishaotherwise user has to again issue one CLI to do discovery and port ceration11:12
lucasagomesthat makes little sense for me11:12
*** killer_prince has joined #openstack-ironic11:12
*** killer_prince is now known as lazy_prince11:12
lucasagomesNisha, yeah I can see the optimization, but when you look at the REST API itself it looks wrong11:12
Nishaactually i just made it 202, but i didnt encounter any issue even as 20111:13
lucasagomesif it returns 202 indicating it's an async call to create the node11:13
lucasagomesbut returns the node as part of the return body11:13
Nishayes11:13
lucasagomesNisha, well the issue with 201 is that it means that the request was completed fullfiled11:13
lucasagomeswhen it's not11:13
Nishayes11:13
lucasagomesbecause there's a task running on the background11:13
Nishatrue11:13
lucasagomesso it all looks wrong to have this combination of sync + async11:13
lucasagomesfor me it's either a sync or an async request11:14
lucasagomesso breaking into 2 calls makes way more sense11:14
lucasagomeslooks better to the API11:14
Nishalucasagomes: i could have tried making it completely asynch....but then it would broken compatibility for node-create11:15
lucasagomesNisha, yeah... and would need a mechanism to track the result of that request as well11:15
lucasagomesNisha, can we break it in two commands? leave the creation as-is11:15
lucasagomesand then if you want to discovery the properties you can trigger it by a different request11:16
Nishawe can do it, i had prototyped that as well11:16
*** rameshg87_ has quit IRC11:16
lucasagomesNisha, cool, I think that's the way to go really11:16
Nishau mean a new CLI?11:16
lucasagomesNisha, have other people comments against that ^11:16
lucasagomesNisha, a new CLI? like a new command?11:17
Nishathis comment i have recvd only from you11:17
Nisha:)11:17
Nishayes11:17
Nishai think you meant that only11:17
lucasagomesNisha, ack... well on the CLI as it's a wrapper11:17
Nishaif i am wrong plz correct11:17
lucasagomesI don't see a problem in having node-create --discovery to trigger both requests11:17
NishaOk, i had done that too :)11:17
Nishai prototyped all three ways11:18
lucasagomeshah11:18
lucasagomesnice11:18
dtantsurlucasagomes, Nisha, 2 API commands, one pure sync, one pure async make a lot of sense to me, +111:18
* dtantsur was partially following11:18
lucasagomesdtantsur, :) yeah, please join the conversation11:18
NishaOk. so if user issues node-create --discover, then two URLS will be issued11:19
Nishathats fine?11:19
lucasagomesNisha, I don't see much problems on that11:19
dtantsurlucasagomes, Nisha, actually I still have a bad feeling about node-update part accepting both key=value (required) and --discover11:20
lucasagomesbecause, as said, CLI is just a wrapper11:20
Nishahmmm11:20
Nishadtantsur: :(11:20
lucasagomesdtantsur, hmm yeah... looks a bit odd indeed11:20
dtantsurlucasagomes, Nisha, I would stay with node-create --discover and a separate command node-discover for existing node11:20
lucasagomesdtantsur, do you think that, if we have a separated command in the CLI it would be better?11:20
dtantsuryep11:21
dtantsurwe still can have optional flag for -create, that makes sense to me11:21
lucasagomesso the command will discover/update the properites of the node (in case it's already there)11:21
*** Poornima has quit IRC11:21
lucasagomesdtantsur, right yeah I can see that11:21
dtantsurlucasagomes, "in case it's already there"  <-- it's always there, this command will accept UUID11:21
dtantsuror did I get you wrong?11:21
Nishadtantsur: lucasagomes ok i will propose a new CLI for node-update part11:22
lucasagomesdtantsur, I mean, if the node already has the properties filled, but OP updated the hardware (put more ram)11:22
lucasagomesand then he issued the discovery again it will just update11:22
lucasagomeswhat is already there11:22
dtantsurwell yes11:22
lucasagomesNisha, ok11:22
lucasagomesNisha, thanks11:23
Nishadtantsur: lucasagomes do you see any issues for node-create --discover?11:23
lucasagomesNisha, IMO I'm fine with that11:23
dtantsurlucasagomes, Nisha, and last idea: I suspect --create-ports should be the default for node-discover and node-create --discover. What do you think?11:23
dtantsur(then we can have --no-create-ports as a flag, if you feel like)11:23
*** nosnos has quit IRC11:23
Nishawell i can do that :)11:23
lucasagomesdtantsur, that's actually a good point11:23
lucasagomesdtantsur, I would expect my discovery to find the NICs for me as well11:23
lucasagomesby default11:23
dtantsurNisha, do you agree?11:24
Nishadtantsur: lucasagomes discovery will discover the NICs as it is part of node properties, but creation of ports shall be default is a thing whether we shud it in node-create by default or not11:25
Nishai can do that , i have no issues :)11:25
lucasagomesNisha, just one more thing about the spec... can we make the Proposed Change section to talk about the REST API instead of the CLI?11:26
lucasagomesthat really makes my brain hurt when reading that11:26
lucasagomeswe can mention the CLI changes but the main thing is the API11:26
dtantsurlucasagomes, ++11:26
lucasagomesthat's the change for Ironic, the API. The CLI is ironic but it's a diff repository of code11:27
lucasagomesit's a different project11:27
lucasagomeswe really should not use the CLI as a reference there11:27
lucasagomesmention it fine, but not as the proposed change for ironic11:27
lucasagomesand I will be back... I'm in the office I will go out buy some food, be back in few minutes11:28
*** lucasagomes is now known as lucas-brb11:28
* lucas-brb brb11:28
dtantsuroh, I'll also grab some tea11:28
Nishaok11:29
*** bvivek has quit IRC11:34
ifarkasNisha, hi, I also commented on the spec that you should state that it should only discover attributes that will be used for scheduling, and a driver can also decide to discover more properties, but only in case it will be used by driver.11:35
Nishaifarkas: do you see any more properties listed in the spec than required11:36
ifarkasNisha, there isn't any, but your spec doesn't say anything about when a driver *can* include more properties11:37
ifarkaswhich was my comment11:37
Nishaifarkas: have you seen latest patch11:38
Nishathe spec doesnt has that line at all11:38
Nishayour comment is addressed already11:38
ifarkasNisha, it's not addressed. The statement about it is missing.11:39
Nishameans?11:39
ifarkasNisha, a driver can include more properties only if it will be used by Ironic11:40
Nishayes i removed it as per your comment11:40
Nishaso the generic spec is not having that statement now, the driver specific spec can mention the reason for discovering any other property they intend to discover and where they plan to store it11:41
Nishalike for iLO discover properties spec, i discover license also11:41
Nishawhich is required by ilo deploy driver11:42
Nishaand will be stored in extras11:42
ifarkasNisha, I didn't comment on it to remove it but to specify when it is allowed11:42
Nishaifarkas: i think that responsibility shall be taken up by specific driver specs11:43
openstackgerritDmitry Tantsur proposed a change to openstack/ironic: EXPERIMENTAL Implement hardware discovery in PXE driver  https://review.openstack.org/11003111:43
openstackgerritDmitry Tantsur proposed a change to openstack/ironic: Add newly_discovered column to Node object  https://review.openstack.org/10738911:43
openstackgerritDmitry Tantsur proposed a change to openstack/ironic: EXPERIMENTAL Add Conductor.discovery_driver field  https://review.openstack.org/10930411:43
openstackgerritDmitry Tantsur proposed a change to openstack/ironic: EXPERIMENTAL Implement conductor part of hardware discovery  https://review.openstack.org/10931211:43
Nishadtantsur: lucas-brb let me know if you feel otherwise on ifarkas above ^ comment11:43
dtantsurNisha, I don't quite get the context. What line/paragraph are you arguing on?11:44
Nishadtantsur: :)11:44
ifarkasdtantsur, revision 30, line 3811:44
ifarkasdtantsur, sorry, revision 29, line 3811:45
dtantsurNisha, ifarkas, I don't think this line is critical for anything or actually means anything :) anyway, each driver is going to have it's own spec with it's own reasoning11:46
dtantsurNisha, ifarkas, and anyway JSON structure in it does not contain anything extra for now11:47
ifarkasdtantsur, Nisha, alright11:47
dtantsurand I don't even see this line in a new revision :)11:47
ifarkasdtantsur, yeah, it's missing from the new revision, that's why I thought it worth specifying when each driver can alter the list11:49
dtantsurifarkas, let's leave it for each driver's spec, we can't predict all the possibilities11:49
dtantsurimagine devananda changing our statement and turning Ironic in CMDB finally :)11:50
* dtantsur is gonna be killed this evening11:50
ifarkasdtantsur, yeah, we don't want to predict it, just state the condition that has been stated during the meeting11:50
ifarkasdtantsur, but I am fine either way11:50
Nishadtantsur: thanks11:51
Nishadtantsur: lucas-brb so i will do changes as discussed above11:52
Nishafor node-create and a new CLI11:53
Nishathanks fr the discussion dtantsur lucas-brb11:54
dtantsurnp)11:57
*** lucas-brb is now known as lucasagomes12:08
lucasagomesNisha, thank you12:08
openstackgerritRoman Prykhodchenko proposed a change to openstack/ironic: Migrate Nova BM data to Ironic  https://review.openstack.org/11240212:09
*** linggao has joined #openstack-ironic12:26
*** bvivek has joined #openstack-ironic12:29
openstackgerritRoman Prykhodchenko proposed a change to openstack/ironic: Flavor update tool for Ironic  https://review.openstack.org/11257512:36
*** foexle has quit IRC12:40
romchegMorning guys12:42
romchegI moved migration tools to Ironic source tree12:42
romchegadam_g: When you're here you can take a look at that12:42
romchegI'm going to disappear for two weeks. Maybe I'll be accessible over email12:43
romchegSo you can poke yuriyz if you need something12:43
romchegI also upgated review links in the whiteboard12:44
*** matty_dubs|gone is now known as matty_dubs12:48
*** bvivek2 has joined #openstack-ironic12:54
*** bvivek has quit IRC12:55
*** k4n0 has quit IRC12:59
*** jasondotstar has joined #openstack-ironic13:03
*** bmahalakshmi has quit IRC13:10
*** nikunj2512 has quit IRC13:11
*** ramineni has joined #openstack-ironic13:27
lucasagomesJayF, ping re ipmi13:35
*** foexle has joined #openstack-ironic13:42
*** pcrews has joined #openstack-ironic13:43
*** ifarkas has quit IRC13:45
yuriyzHi Ironic13:46
yuriyzdtantsur, I left comment on Victor's patch for you13:47
*** ifarkas has joined #openstack-ironic13:48
*** shakamunyi has joined #openstack-ironic13:50
*** ifarkas has quit IRC13:50
*** ifarkas has joined #openstack-ironic13:53
lucasagomescores https://review.openstack.org/#/c/99318/ needs another +2... please if you have a time review it13:53
lucasagomesI want to get it in so we can land the devstack patch as well and add ipxe to be tested on gate13:54
dtantsuryuriyz, morning :)13:55
dtantsurlucasagomes, I am on it, but have a question13:55
lucasagomesdtantsur, sure13:55
dtantsurlucasagomes, https://review.openstack.org/#/c/99318/17/ironic/common/pxe_utils.py looks like you're trying to supply PXE boot image for dumb firmware, not understanding iPXE, right?13:55
dtantsurI mean, even if iPXE is enabled13:55
lucasagomesdtantsur, yes13:56
lucasagomesdtantsur, if it's not an iPXE boot image13:56
lucasagomeswe send the ipxe boot image so it can chainload13:56
dtantsurlucasagomes, I can't find the place, where you save the appropriate PXE config file to TFTP root13:58
dtantsuror did I get it wrong?13:59
lucasagomesdtantsur, to generate the PXE config it uses a template13:59
lucasagomesdtantsur, for iPXE I just have another template13:59
lucasagomesso no changes to the function we have currently is needed13:59
lucasagomesdtantsur, https://review.openstack.org/#/c/99318/17/ironic/drivers/modules/ipxe_config.template that's the template for iPXE14:00
*** Nisha has quit IRC14:00
dtantsurlucasagomes, yeah, but to chainload iPXE you need pure PXE config first, no?14:00
lucasagomesdtantsur, no, this is what the PXE server does14:01
lucasagomes(dnsmasq) in case of neutron14:01
lucasagomesthat's the extra DHCP options14:01
lucasagomesdtantsur, http://ipxe.org/howto/dhcpd#ipxe-specific_options14:01
dtantsurlucasagomes, "The pxe_bootfile_name config option should point to the iPXE image (undionly.kpxe)." that's what I didn't realize :)14:02
lucasagomesoh yeah, so when enabling iPXE you also change the bootimage file config option14:02
lucasagomesand the pxe_template14:02
Haomenghi ironic14:03
dtantsurHaomeng, hi!14:03
lucasagomesthose will be documented14:03
lucasagomesHaomeng, hi there14:03
dtantsurlucasagomes, I hope it will be more clear, when docs arrive :)14:03
lucasagomesyeah, the next patch of the series are docs14:03
Haomengdtantsur: :)14:03
Haomenglucasagomes: :14:03
Haomengjust raise a question14:03
Haomengwho see such issue when deploy ironic with devstack - "error: Failed to define network from /dev/fd/63 , error: XML error: unexpected virtualport type -1''14:04
lucasagomesHaomeng, haven't see that... this happens when devstack is setting up Ironic? or another OS component?14:05
Haomenglucasagomes: yes, happens when devstack is create VMs which used by ironic14:05
Haomenglucasagomes: thank you:) let me google:)14:06
lucasagomesHaomeng, I see :( idk... virsh version maybe?14:06
Haomenglucasagomes: yes14:07
Haomenglucasagomes: good sense:)14:07
Haomenglucasagomes:  +2:)14:07
lucasagomes:)14:07
Haomengnice day:) good night:)14:08
lucasagomesHaomeng, g'night14:10
Haomenglucasagomes: :)14:10
matty_dubsjroll: JayF: Nice! (re: OnMetal pics; was on PTO yesterday)14:11
jrollmorning everybody :)14:18
jrolldtantsur: any reason you didn't approve that ipxe patch?14:19
dtantsurjroll, I realized that my understanding of iPXE is very bad :(14:22
dtantsurjroll, and good morning :)14:22
*** shakamunyi has quit IRC14:23
jrollthat's why jay and I +'d it :P14:23
jrollidk, any problem with me approving it? I think it's solid14:23
dtantsurjroll, will approve before leaving the office today (~1.5hrs), if nobody jumps in14:23
dtantsuroh you can go ahead and approve :)14:23
jrollmaybe I'll run it in devstack first14:23
lucasagomesjroll, https://review.openstack.org/#/c/9967714:25
lucasagomesjroll, you just need to set IRONIC_IPXE_ENABLED=True on ur localrc file14:25
jrolla ha14:25
jroll:)14:25
* jroll gives it a shot14:25
NobodyCammorning Ironic14:26
lucasagomesNobodyCam, morning14:26
jrollI'll review that devstack patch afterward, too14:27
jrollhiya NobodyCam14:27
lucasagomesjroll, :) thanks14:27
NobodyCammorning jroll, lucasagomes, dtantsur  and Haomeng :)14:27
*** jgrimm has joined #openstack-ironic14:28
dtantsurNobodyCam, morning :)14:28
NobodyCam:)14:29
*** Mikhail_D_ltp has quit IRC14:31
*** ifarkas has quit IRC14:34
*** rakesh_hs has quit IRC14:37
*** shakamunyi has joined #openstack-ironic14:38
openstackgerritLucas Alvares Gomes proposed a change to openstack/ironic: Remove direct calls to dbapi's get_node_by_instance  https://review.openstack.org/11259514:39
lucasagomesjroll, about IPMI, you know if FRU should return the NICs information of the node? like mac addresses and all?14:39
lucasagomesjroll, random question sorry heh14:39
jrolllucasagomes: sorry, idk about fru things14:40
lucasagomesjroll, no problem, thanks14:40
dtantsurlucasagomes, why are all these patches chained https://review.openstack.org/#/c/112595/ ? It does not look like they're interdependent14:41
lucasagomesdtantsur, they are all part of the same effort/bug14:41
openstackgerritVladyslav Drok proposed a change to openstack/ironic: Add driver name on driver load exception  https://review.openstack.org/11204914:41
lucasagomesto hide the dbapi calls underneath objects14:41
lucasagomesdtantsur, yeah it's not a linear dependency :/ but makes it easier to me to maintain them locally14:42
dtantsurlucasagomes, to me it does not justify chaining. Remember how long it took to merge management interface chain. I highly suggest making them independent (at least those who do not have +2 yet)14:42
lucasagomesdtantsur, right, ok I will break the chain14:43
dtantsurthanks14:43
openstackgerritAndrey Kurilin proposed a change to openstack/ironic: Use timeutils from one place  https://review.openstack.org/11230314:43
lucasagomesdtantsur, btw, they create() destroy() get_by_instance() dependends on https://review.openstack.org/#/c/11205614:43
dtantsurlucasagomes, ok, I really looked only at the last one14:44
dtantsurlucasagomes, I'm starting to approve those patches, that are ready14:45
lucasagomesdtantsur, np, can I break it after those first two get merged? they alreayd have a +214:45
lucasagomesdtantsur, oh ok14:45
lucasagomesdtantsur, thanks14:46
dtantsurlucasagomes, am I the only one who feels that we have to much copy-paste there?14:47
dtantsur(point for future refactoring, won't block now)14:47
lucasagomesdtantsur, for the get_ stuff?14:47
lucasagomesyeah hmm... I'm thinking of it as well, maybe I will create a helper function for that as part of the get_by_instance14:47
dtantsurlucasagomes, in patches that fix self.fields both __init__ are nearly the same14:47
lucasagomesdtantsur, ohh yeah well that's kinda true14:47
openstackgerritA change was merged to openstack/python-ironicclient: Trim trailing slash and version from endpoint  https://review.openstack.org/10771514:48
lucasagomesdtantsur, that for loop that check if the attr exists maybe could exist in the base class14:48
lucasagomesdtantsur, well I won't look at it now, I want to finish the db stuff first14:48
lucasagomesbut I will try to reduce the duplication on the db/object part14:48
dtantsurlucasagomes, yes, sure14:49
jrollhey so this patch is blocked on an ironicclient bug fix that was just approved https://review.openstack.org/#/c/105590/14:57
jrollbut I need to wait for a new client release yes?14:57
matty_dubslucasagomes: Playing with FRU on an HP blade, I can get the serial numbers of all the DIMMs, but no network information. Going to try on a Dell box too14:57
matty_dubsBah, that's even less.14:58
NobodyCambrb .... quick walkies14:58
lucasagomesmatty_dubs, oh, yeah if you use driver specific stuff you can do it14:58
lucasagomesmatty_dubs, ipmitool delloem mac list14:58
lucasagomesbut standard ipmi I don't think we can get the NIC information anywhere :(14:59
lucasagomes(only the NIC info from the BMC itself, "ipmitool lan print")14:59
dtantsurjroll, and maybe even bump version of ironicclient we depend on15:00
jrolldtantsur: I don't think that's needed because we use >=15:08
dtantsurjroll, I think we need new >=, otherwise you risk getting old ironicclient, which is broken with your code15:09
jrollI guess sure15:11
jrollI'm adding /nodes/detail to the client, think it's useful to also put in in the cli?15:12
jrolllucasagomes: ^^15:12
lucasagomesjroll, I guess so, well the CLI is just a translation of our API15:13
lucasagomesso I think it makes sense to make it available as well15:13
jrollright15:13
jrolljust that table view with all fields seems not useful :P15:13
jrollbut I'll add it, I started already15:14
lucasagomesjroll, right... well maybe if it's too messy to have in the CLI15:14
lucasagomeslike the tables etc we can skip it15:14
jrollyeah, idk15:14
jrolllucasagomes: someone might use it in a bash script :P15:14
lucasagomesheh15:15
devanandamorning, all15:15
lucasagomesdevananda, morning, feeling better?15:15
NobodyCamgood morning devananda :)15:15
devanandaI'm going to be offline again this morning - another dr appt15:15
jrollmorning devananda15:15
jroll:(15:15
NobodyCam:(15:15
lucasagomesoh15:15
lucasagomes:/15:15
devanandayea :(15:16
*** mdorman has joined #openstack-ironic15:16
* NobodyCam hopes devananda starts to feel better15:16
devanandalucasagomes: https://bugs.launchpad.net/ironic/+bug/135363115:16
* lucasagomes clicks15:17
lucasagomesdevananda, oh crap x.x15:18
devanandaI should have caught that when reviewing the initial refactoring patch. it was pointed out that adding the iLO driver can't be done today without changing patcher.py, which is silly15:18
devanandayea15:18
lucasagomesdevananda, +1 this is something that I could have helped with in the instance_info work. Like before all parameters were pxe stuff (pxe_root_gb) etc..15:18
lucasagomesyeah the instance info should really go to the base class15:18
devanandai think you did the initial work on that15:18
lucasagomesdevananda, tho we still have the deploy_k&r in the pxe15:18
devanandabut it has been refactored a few times15:18
lucasagomesbut that can be deleted in kilo15:18
lucasagomesdevananda, yeah, it was15:18
devanandait'll need to be updated here, too: https://review.openstack.org/#/c/111423/15:19
devanandaI noted it on the whiteboard15:19
lucasagomesdevananda, yeah that's the problem, how we are sync'ing that changes ?15:19
lucasagomesI mean... we want that for J or the driver is frozen?15:19
devanandawe need that now15:19
devanandabefore it lands in nova15:20
lucasagomesdevananda, right, lemme take a look at it then15:20
dtantsurdevananda, morning15:20
devananda1) propose change in ironic. 2) WIP 111423 and post link. 3) land change in ironic 4) propose new version to 11142315:20
devanandaand track all of it on the whiteboard15:20
lucasagomesdevananda, I will try to put a reference patch up today in Ironic and then we can see how we do to the nova driver15:21
lucasagomesok lemm15:21
devanandathanks much. I'll poke at it when I get back -- just leave any notes around the "Nova Driver Progress" section15:21
lucasagomesdevananda, ack15:21
* devananda heads out to dr appt15:22
lucasagomesthanks for pointing that out15:22
lucasagomescause I had forgot that part of the driver15:22
openstackgerritJim Rollenhagen proposed a change to openstack/python-ironicclient: Add /nodes/detail support  https://review.openstack.org/11261015:26
jroll^ not tested yet but should work :P15:26
*** ramineni1 has joined #openstack-ironic15:27
*** ramineni has quit IRC15:28
yuriyzdtantsur, about Victor's patch. Are you worry about models != migrations?15:28
dtantsuryuriyz, yep. previously for mysql we always got the latest state, no matter what current15:30
yuriyzdtantsur, we have test for schema comparison https://review.openstack.org/#/c/107628/15:32
dtantsuryuriyz, I'm not talking about it. Imagine user has mysql database with some intermediate version15:33
dtantsuryuriyz, before that patch, it was automagically upgraded. after it won't and user will start getting errors.15:33
openstackgerritJim Rollenhagen proposed a change to openstack/python-ironicclient: Add /nodes/detail support  https://review.openstack.org/11261015:34
*** Mikhail_D_ltp has joined #openstack-ironic15:35
openstackgerritJim Rollenhagen proposed a change to openstack/python-ironicclient: Add /nodes/detail support  https://review.openstack.org/11261015:36
lucasagomesjroll, agent uses pxe_deploy_ramdisk and pxe_deploy_kernel options in driver info right?15:37
jrolllucasagomes: it just uses deploy_ramdisk and deploy_kernel15:38
jrollI'm ok with changing that if it helps you out15:38
lucasagomesjroll, ack, cheers15:38
jrolllucasagomes: but I think the pxe driver should s/pxe_//15:38
lucasagomesjroll, nop... just because I'm taking a look at the patcher and I see there's a conditional there looking for 'agent' in the driver's name15:38
yuriyzdtantsur, this user should use 'upgrade' command, not 'create_schema'15:39
lucasagomesjroll, oh right... wait then15:39
jrolllucasagomes: right15:39
lucasagomesso you expect driver_info/deploy_kernel, driver_info/deploy_ramdisk ?15:39
jrolllucasagomes: I *think* there may be a bug there if people are using flavor to define deploy k/r15:40
lucasagomesnot pxe_deploy_kernel pxe_deploy_ramdisk15:40
jrollcorrect15:40
dtantsuryuriyz, by user you mean `test code`. yes, that's why my comment on a patch :)15:40
lucasagomesjroll, right so you expect that to be present in the driver info already and not coming from the flavor?15:40
jrolllucasagomes: https://github.com/openstack/ironic/blob/master/ironic/drivers/modules/agent.py#L8115:40
dtantsuryuriyz, https://review.openstack.org/#/c/107629/7/ironic/tests/base.py on line #91 it is create_schema15:40
jrolllucasagomes: yes, I figured anyone deploying the agent can also make that change while they are changing the driver name in the db15:40
lucasagomesjroll, alright, that's good15:41
lucasagomesbecause we want to drop the flavor extra prameters to have deploy k&r15:41
jrollindeed :)15:41
lucasagomeswe keep it now for backwards compat with icehouse15:41
lucasagomesjroll, alright thanks :)15:41
jrollnp :)15:42
*** bvivek2 has quit IRC15:44
* jroll brb15:44
yuriyzdtantsur, test code runs on test db (sqlite in memory currently) Test db is new fresh db. Old behavior is to create db from models also (line 95).15:47
*** matty_dubs is now known as matty_dubs|lunch15:47
*** eghobo has joined #openstack-ironic15:50
*** eghobo has quit IRC15:51
openstackgerritIlya Pekelny proposed a change to openstack/ironic: Test migrations with Alembic, using Oslo.db  https://review.openstack.org/11198415:51
*** eghobo has joined #openstack-ironic15:51
*** shakamunyi has quit IRC15:51
JayFlucasagomes: I didn't read /all/ of scrollback, but I know on our machines FRU data has no knowledge whatsoever of nics15:52
lucasagomesJayF, ah, right that's fine. That's all I needed to know really15:53
lucasagomesJayF, with standard ipmi we can't find any info about NICs right?15:53
JayFI don't think so, no.15:54
JayFAlthough honestly in my case I'm using PCIe NICs, so it's possible it'd be different for someone with onboard15:54
lucasagomesoh yeah15:55
lucasagomesJayF, alright, thanks15:55
jrolllucasagomes: all those fields aren't too horrible https://github.com/openstack/ironic/blob/master/ironic/drivers/modules/agent.py#L8115:55
dtantsuryuriyz, it's quite easy to use mysql for testing and IIRC that's what I'm doing now (because of broken migrations)15:56
lucasagomesjroll, hah, it's because I'm looking into the patcher.py for the driver15:56
lucasagomesjroll, and there's a conditional there checking for 'agent'15:56
*** jistr has quit IRC15:56
lucasagomesif it's part of the driver's name15:56
jrolllucasagomes: gah, that's not the link I meant to give you :|15:56
jrolllucasagomes: https://www.dropbox.com/s/n8uslc0e1jbfedp/Screenshot%202014-08-07%2008.54.07.png15:58
lucasagomesjroll, MUAHAH15:58
lucasagomesjroll, yeah looks horrible :P15:58
jrolllucasagomes: I've done way too many "select * from nodes" in mysql if I don't think it's horrible :(15:59
lucasagomesjroll, maybe leave detail out of the CLI?15:59
jrolllucasagomes: mehhhh, it doesn't look bad to awk15:59
lucasagomesjroll, folks still can do list + show15:59
jrollhmm, idk15:59
yuriyzdtantsur, mysql can be used for "opportunistic" migrations test, not related for this patch16:00
dtantsuryuriyz, mysql can be used for all unit tests, if I'm stuck with some older revision, will I now be forced to call dbsync before running tests?16:02
*** linggao has quit IRC16:02
*** vinbs has joined #openstack-ironic16:04
*** hemna has joined #openstack-ironic16:05
*** vinbs_ has joined #openstack-ironic16:06
yuriyzdtantsur, I do not try mysql for unit tests (I think some problems with hardcoded 'id' field possible), but for unit tests new fresh db created from models should be used16:07
*** vinbs has quit IRC16:09
*** vinbs_ is now known as vinbs16:09
dtantsuryuriyz, well, I can't reproduce it now, but I already got hit by it some time ago (even with sqlite). Will try to reproduce tomorrow.16:10
*** dtantsur is now known as dtantsur|afk16:10
jrollhmm, should we get this into our nova patches? https://review.openstack.org/#/c/108545/16:10
openstackgerritVladyslav Drok proposed a change to openstack/ironic: Add driver name on driver load exception  https://review.openstack.org/11204916:13
jrolldevananda: when you're back, wondering if you want me to get this review going quickly and get it into our nova patches before they land: https://review.openstack.org/#/c/108545/16:13
*** dvorak has joined #openstack-ironic16:14
*** ellenh has joined #openstack-ironic16:21
*** ramineni1 has quit IRC16:25
*** coolsvap has quit IRC16:26
*** vinbs has quit IRC16:30
*** coolsvap has joined #openstack-ironic16:31
*** gp_ has quit IRC16:33
*** marzif_ has quit IRC16:33
openstackgerritA change was merged to openstack/ironic: Fix self.fields on API Chassis object  https://review.openstack.org/11205516:35
*** rameshg87 has joined #openstack-ironic16:39
rameshg87jroll, NobodyCam, please have a look at the spec for ilo virtual media - ipa deploy spec: https://review.openstack.org/#/c/108445/16:41
JayFlooking at this and curious as to how it fits into Ironic, in terms of scope: https://review.openstack.org/#/c/107981/9/specs/juno/drac-raid-mgmt.rst,cm16:46
JayFI'm thinking it's OK because it's 1) OOB and 2) Hardware raid16:46
JayFbut curious if anyone else has any thoughts16:47
*** rameshg87 has quit IRC16:51
openstackgerritLucas Alvares Gomes proposed a change to openstack/ironic: Move the 'intance_info' fields to the GenericDriverFields  https://review.openstack.org/11262316:55
lucasagomesdevananda, https://review.openstack.org/112623 I'm currently testing it locally here... I added this link in the whiteboard in front of the link to the bug16:58
*** rakesh_hs has joined #openstack-ironic16:59
*** coolsvap has quit IRC17:04
jrolllucasagomes: hmmm, I don't seem to be able to run stack.sh with ipxe enabled :/17:04
lucasagomesjroll, why not?17:04
jrollnot sure... it installs ironicclient and then jumps straight to cleaning up17:05
lucasagomesjroll, ouch is it a fresh install?17:05
jrolllucasagomes: https://gist.github.com/jimrollenhagen/9889fffbbc29d73a0ae217:05
jrollnot a fresh install :/17:05
jrollso I wonder if that's related, but I still think there might be a bug17:06
JayF2014-08-07 17:03:15.137 | ++ sudo a2dissite ironic17:06
JayF2014-08-07 17:03:15.176 | ERROR: Site ironic does not exist!17:06
lucasagomesjroll, and it pass that ^ without the IRONIC_IPXE_ENABLED?17:06
jrollI can figure out the issue, don't worry about it... but hard to tell if this is a problem with the ironic patch or devstack patch17:06
lucasagomesyeah17:06
jrollyeah, without IRONIC_IPXE_ENABLED it's fine17:06
jrollI think it's a devstack issue17:06
lucasagomesjroll, I'm currently testing another thing here for the driver17:06
JayFoh that's part of the cleanup17:06
jrollJayF: yeah, the problem is why is it jumping to cleanup17:07
lucasagomesbut I can give it a go as soon as I finish it17:07
JayFWeird.17:07
*** coolsvap has joined #openstack-ironic17:07
lucasagomesjroll, that seems to be some apache thing17:07
jrolllucasagomes: I think the issue is that it's running cleanup17:08
* jroll looks again17:08
JayFlucasagomes: I think it's a red herring; it started cleanup really early, so it never added the site to disable it17:08
lucasagomesJayF, yeah, maybe the cleanup on the devstack patch should be more smart and check if the site is there17:08
lucasagomesbefore trying to remove it17:08
lucasagomesI can do some sanity check on that area17:08
jrollwell, that too17:08
jrollbut the question is, should cleanup be run then at all17:09
lucasagomesjroll, it probably will clean up other stuff...17:09
*** penick has joined #openstack-ironic17:09
lucasagomesbut yeah I can hmm give it a shot after finishing it17:09
jrollyeah but cleanup_ironic is being run17:09
jrollwhich is triggered by devstack "clean"17:09
* jroll digs17:10
jrollbrb17:11
lucasagomesalright I'm heading home (came to the office today)17:18
lucasagomesjroll, I will try it with a fresh install later17:18
lucasagomesdevananda, it seems to work... I'm going home now, but I will get online once I get there17:19
lucasagomesgood night everybody17:20
jrolllucasagomes: yeah no worries17:20
jrollwant me to push a new patch if I find the issue?17:20
*** lucasagomes has quit IRC17:21
*** pelix has quit IRC17:24
*** linggao has joined #openstack-ironic17:26
openstackgerritA change was merged to openstack/ironic: Fix self.fields on API Port object  https://review.openstack.org/11205617:27
devanandaback17:27
NobodyCamgood news from doc?17:37
devanandaI now have strep, they think.17:38
devanandabut hey, the pneumonia is cleared up17:38
jroll:(17:38
NobodyCamoh no :(17:38
NobodyCamstrep can be a real bugger17:39
jrollthere's a pun there17:39
*** matty_dubs|lunch is now known as matty_dubs17:40
openstackgerritDevananda van der Veen proposed a change to openstack/ironic: Move the 'instance_info' fields to GenericDriverFields  https://review.openstack.org/11262317:40
* devananda updates commit message17:40
devanandaJayF: fyi, you can update commit messages directly in gerrit17:41
devanandaclick the little pen-and-paper icon17:41
devanandafor nits, that's generally much easier than waiting for the author17:41
devanandajroll: can you take a look at ^ and give it a local test with IPA?17:42
JayFdevananda: ah, cool. Thanks17:42
jrolldevananda: at a glance, no reason that shouldn't work, but yeah give me a minute17:43
NobodyCambrb17:46
mgagneis there a way to run both nova (libvirt) and nova (ironic) in the same cell/region?17:52
devanandamgagne: ironic requires a different scheduler HostManager class17:54
*** Alexei_987 has quit IRC17:54
devanandamgagne: and afaik, most folks are leaning towards isolationg that at the cell level. that being said, I have been told that Nova can support it with host-aggregates17:54
mgagnedevananda: sure, I saw a logic to use the "right" host_state class17:54
devanandamgagne: and I think some folks from IBM talked about their work to do it at the last summit17:55
jrollmy guess is that it's not worth the trouble, but I say that as someone who already is running cells17:55
jrollso maybe running cells is more trouble than that17:55
mgagnedevananda: yes, I was more/less looking at host aggregates but the linear nature of the scheduler makes it a non-trivial task17:55
devanandatheir talk was more of a "here's all the broken stuff we ran into"17:55
devanandabu tI haven't seen any patches come from them :(17:55
*** athomas has quit IRC17:55
mgagnedevananda: but maybe I don't want my 10000 baremetal nodes polluting my nova database already used for virtual machines =)17:56
devanandamgagne: I don't follow you17:56
mgagnedevananda: isn't ironic inventory synced to nova?17:56
devanandamgagne: also - you have 10k nodes you're going to use with ironic? awesome17:57
devanandamgagne: oh gods no17:57
devanandamgagne: except sort of17:57
mgagnedevananda: I like to make it looks like I'm important =)17:57
devanandamgagne: nova views each ironic node as a distinct hypervisor17:57
mgagnedevananda: lets say it's not a small install I'm looking for17:57
mgagnedevananda: yes and although it could be possible to use the same cell to manage both libvirt and "ironic" hypervisors, it might not be a good idea for those reasons17:58
devanandaright17:58
devanandamgagne: you will get 1 record in the nova db for each ironic node.17:59
devanandafwiw, there's a known issue right now where the periodic hypervisor stats update takes O(N) time17:59
devanandasince it loops linearly through all the hypervisor hosts (essentially every single node in ironic)17:59
mgagnedevananda: right so ironic nodes are asynchronously copied to Nova18:00
devanandamgagne: not copied18:00
mgagnedevananda: inserted ?18:00
devanandasome metadata is cached18:00
devanandaironic and nova have competely separate databases18:00
mgagnedevananda: ironic nodes are asynchronously "introduced" to Nova. better? =)18:00
devanandanova stores a record for each (host, hypervisor_hostname) today -- regardless of hypervisor18:01
devanandathe difference for ironic is, instead of N compute hosts, you have 1 (or 2), but then a bagillion unique hypervisor_hostname18:01
mgagnedevananda: ok so I might also encounter performance/scalability issues in Nova when scheduling virtual machines if I have too many ironic nodes.18:01
devananda+in the same cell. yes.18:02
devanandahypothetically. since i haven't tried it18:02
mgagnedevananda: alright. I'm now more knowledgeable about the subject. all that's remaining to do is choose between an all-in-one nova or dedicated cells based on those details.18:03
jrollwell18:03
jrollmgagne: so you're thinking you would have both ironic and VM stuff in the same nova-compute?18:03
devanandaShrews: I see you've been maintaining https://review.openstack.org/#/c/94439/ -- how does that relate to all the work being tracked on https://etherpad.openstack.org/p/IronicCI ?18:03
jrollignore me, that doesn't make sense18:04
mgagnejroll: I'm looking for info about what this kind of setup would imply18:04
devanandajroll: same cell/region, i think was the question18:04
jrollright18:04
jrollI'm just trying to think about what we've seen18:04
devanandamgagne: also consider neutron18:04
jrollwe see perf issues in n-cpu18:04
mgagnedevananda: oh you18:04
jrollbut not so much in the scheduler18:04
Shrewsdevananda: it's kind of separate. i'm just having trouble getting reviews on it. only so much i can poke before i get annoying18:04
jrollbut that's separate cells18:05
devanandamgagne: :)18:05
devanandaShrews: :-/18:05
jrolljust throw neutron out the window :)18:05
* mgagne defenestrates neutron18:06
devanandalol18:06
jrollha18:06
*** lucasagomes has joined #openstack-ironic18:06
jrollmgagne: can I ask how large of a deployment y'all are planning?18:07
jrollmgagne: because, with the state of things today, I don't think I'd recommend more than 1000 ironic nodes in a single cell, without configuring very very carefully. and even then, idk.18:08
jrollhopefully that data point helps a bit :P18:09
mgagnejroll: we are still in the planning phase so we are looking for experience and info about scalability and good practices18:09
JayFWell we're the largest install of Ironic that's willing to talk about it, and jroll is right in cautioning about perf issues right now18:10
jrollmgagne: I work on rackspace's onmetal, so18:10
jrollhappy to help :)18:10
* jroll needs to blog about this more18:11
mgagneJayF: I attended most of the talks planning about scalability issues in Nova and how cells kind of fixed (in its way) those issues18:11
mgagnejroll: what the hell is rackspace?18:11
JayFmgagne: seriously?18:11
mgagnejroll: =)18:11
mgagneno18:11
JayFlol18:11
*** f13o_ has joined #openstack-ironic18:11
jrollmgagne: just another hosting provider (tm)18:12
mgagnejroll: =)18:12
*** rakesh_hs has quit IRC18:14
*** krtaylor has quit IRC18:18
JayFdevananda: would be interested in your input on https://review.openstack.org/#/c/107981/9 especially w/r/t ironic scope18:19
devanandajroll: that 1k limit seriously irks me.18:21
devanandajroll: we need to fix that18:21
devanandaironic should, by itself, scale WAY more than that18:22
JayFI think the details stuff + making the bmc power status loop parallel will go a long way... to getting us to the next bottleneck :)18:22
devanandaJayF: ooh. right. I should probably go block a bunch of specs soon. is today the deadline?18:23
devanandaor did I say it was next week?18:23
* devananda wants it to be today18:23
JayFI honestly don't remember at all18:23
jrolldevananda: this lgtm https://review.openstack.org/#/c/112623/18:23
jrolldevananda: right, what JayF said18:23
devanandaawesome, tyvm18:23
JayFdevananda: there's also a thread on ML about someone asking for an exception for a driver with an exceptionally large scope... me and dtantsur|afk basically told them no18:23
jrolldevananda: new spec deadline was july 24, spec approval deadline is like sept 318:23
jrolldevananda: according to the timeline doc18:24
jrollslash etherpad18:24
devanandajroll: er, sept 3 is when we tag J318:24
devanandathat should not be the spec approval deadline18:24
devanandait was two or three weeks ago for nova (exceptions notwithstanding)18:25
* jroll looks again18:25
devanandaJayF: right. i haven't opened email today :(18:25
jrolldevananda: that's what I got out of this, but it's not explicit https://etherpad.openstack.org/p/3sxKH2po1o18:25
JayFdevananda: it's okay, we're spreading around the work of being a bad cop ;)18:25
devanandaheh18:25
lucasagomesjroll, thanks for testing that patch with IPA18:26
jrolllucasagomes: np :)18:26
jrollwe should get it in the check jobs18:26
* jroll finds reviews and pokes people18:26
lucasagomesjroll, right, but we are not testing ipa in the gate jobs right?18:27
jrollright, not yet18:27
JayFSoon.18:27
jrollneed some merges18:27
lucasagomesI should have pinged you, when I did that change sorry18:27
JayFBasically we'll test IPA and PXE in the gate for Ironic18:27
lucasagomesyeah... we really should run that in gate18:27
lucasagomesJayF, +118:27
JayFIPA gate will test tempest w/IPA with all commonly used images (DIB+CoreOS)18:27
jrolllucasagomes: no worries :)18:27
JayFand Nova gate will test tempest w/default Ironic driver at the time18:27
devanandaJayF: you should write that plan somewhere :)18:28
lucasagomesJayF, sounds good :)18:28
JayFYou mean IRC doesn't count? :P18:28
* JayF will put it in the ipa etherpad18:28
devanandathis channel is logged.... but no18:28
jrollnoca gate?18:28
jrollnova*18:28
jrollor do you mean ironic gate?18:28
lucasagomesJayF, it's on eavesdrop right? hah jk18:28
JayFjroll: Nova gate == tempest against default Ironic driver.18:29
devanandajroll: he means nova gate. except that it's -nv today.18:29
jrollyou know what would be killer...18:29
devanandaJayF: I mean like the mailing list18:29
JayFjroll: Ironic gate == tempest against pxe and IPA ironig drivers (IPA would use DIB)18:29
jrollput eavesdrop logs in elastic search18:29
JayFdevananda: ah, I'll do that :)18:29
devanandathanks!18:29
lucasagomesand iPXE on the gate as well yay18:29
JayFjroll: IPA gate == tempest against IPA with all the commonly used images (I'd suspect an ISO would be fairly hard to test in gate)18:29
jrollJayF: you ok with using coreos version in ironic gate until we get dib working?18:29
jrollJayF: right, got it18:29
JayFjroll: I'm very OK with that personally, but if it requires more ram, that might be a question for -infra18:30
devanandaso18:30
jrollJayF: ironic was using 1024 for a while, should be fine18:30
JayFokay18:30
jrollas a temp thing18:30
devanandaas a graduation req, ironic needs to be able to run parallel tempest in the gate18:30
devanandawhich means 6 nodes18:30
jrollright ^^18:30
devanandaat 512 MB RAM each18:30
devanandaBUT18:30
devanandathat doesn't have to apply to ALL our jobs18:30
devanandajust one18:31
jrollwas just going to say that18:31
jrollbaby steps18:31
JayFcool. so DIB isn't in the critical path for IPA tempest18:31
lucasagomes+118:31
*** penick has quit IRC18:32
devanandai think we should run tempest parallel on all our drivers in our gate. but steps are better than waterfalls.18:33
devanandaalso, i'm mixing metaphors again18:33
jrollI'm going to copy these here so that y'all can take a look too :)18:33
jroll11:28:13           jroll | can I get some eyes on a couple of devstack patches? working on the road to getting the ironic agent in the gate18:33
jroll11:28:13           jroll | https://review.openstack.org/#/c/112095/18:33
jroll11:28:17           jroll | https://review.openstack.org/#/c/108457/18:33
jrolldevananda: lolmetaphors18:34
jrollbbiab18:34
lucasagomesaight, brb going to eat something18:34
devanandajroll: for the swift tempurl patch, you get notmyname to see it yet?18:34
*** lucasagomes is now known as lucas-dinner18:34
devanandalucas-dinner: g'night!18:34
lucas-dinnerdevananda, g'night! oh and thanks for updating the commit message there18:35
devanandanp18:35
devanandajroll: shouldn't there be a default avlue on this line? SWIFT_TEMPURL_KEY=${SWIFT_TEMPURL_KEY}18:38
jrolldevananda: thinking no, it ends up making a random key if one does not exist18:41
jrolldevananda: just like password things18:41
* jroll bugs notmyname18:41
devanandajroll: oh18:41
devanandareally?18:41
jrollyes?18:41
devanandahttps://review.openstack.org/#/c/112095/3/stack.sh18:41
devanandacalls read_password18:41
jrollyeah18:41
jrollthat function has a horrible name :)18:42
jrollit also sets the password randomly if the user doesn't enter one18:42
devanandaah ok18:42
*** ellenh has quit IRC18:43
*** ndipanov has quit IRC19:15
*** krtaylor has joined #openstack-ironic19:20
*** faizan has joined #openstack-ironic19:21
*** faizan has quit IRC19:30
adam_gdevananda, https://review.openstack.org/#/c/112575/ is something like this actually needed?19:32
openstackgerritA change was merged to openstack/ironic: Move the 'instance_info' fields to GenericDriverFields  https://review.openstack.org/11262319:36
*** ellenh has joined #openstack-ironic19:46
*** slagle has joined #openstack-ironic19:48
NobodyCamanyone have objection to uefi spec. I think its looking good. have one +2 so with out objection I'll land it..19:49
slaglei had a tripleo deployment go wrong, and now my ironic nodes are stuck in "power on" and "deploying"19:52
slaglei can't change the power state or provision state because they're locked19:53
slagleany way to get around this?19:53
NobodyCamslagle: I fix that with cleanup-env19:53
NobodyCam:(19:53
slaglehow does that interact with ironic?19:53
slaglecleanup-env doesn't make any ironic api calls does it?19:53
NobodyCamare you using devtest19:54
slagleyes19:54
NobodyCamno it wipes out the vm's19:54
slaglecleanup-env just deletes the baremetal vm's19:54
NobodyCamya then I rerun devtest.sh -c --trash-my-blah19:54
NobodyCamso I get a new env19:55
adam_gslagle, this is a fallback i use to complete wipe my nova/ironic state: http://paste.ubuntu.com/7982432/19:55
slagleso build a whole new seed?19:55
slaglethat's one way i guess19:55
slaglelooking for something a bit more elegant than reinstalling :)19:55
NobodyCam:-p19:55
slagleadam_g: yea, i had a similar thing for nova-bm19:56
slagleok, i can try that19:56
slagledo we think this behavior is a bug?19:56
slaglee.g. "impossible to delete or power off a node"19:56
adam_gslagle, definitely not ideal but usually unblocks me19:56
*** penick has joined #openstack-ironic19:57
adam_gslagle, oh, also make sure the associated neutron ports have been deleted before re-deploying19:57
NobodyCamno objections ... uefi spec landing... (bp name also checked, hehehehe)20:00
openstackgerritA change was merged to openstack/ironic-specs: UEFI support for Ironic deploy drivers  https://review.openstack.org/9985020:02
NobodyCambrb20:03
adam_gyuriyz, heads up. since he's gone for 2 weeks, i'm going to start pushing some changes to romcheg's review @ https://review.openstack.org/#/c/112402/20:08
aweeksI'm about to push a spec (related to https://blueprints.launchpad.net/ironic/+spec/ipa-ssl-and-client-certs) that seems unlikely to be part of juno.  No one has created the specs/kilo folder in the ironic-specs repo, is there any reason I shouldn't create it, and put my spec in there?20:18
devanandalucas-dinner: when you're around, can you explain why, in nova.virt.ironic.driver we use icli.call("node.$FUNCTION", params) rather than calling node.$FUNCTION(params) directly?20:19
aweeksdevananda: ^ I'm not sure who else I ought to ping for that20:19
devanandalucas-dinner: I reread the client libs just now and it looks like that should work...20:19
devanandaaweeks: hi! so spec proposals are going to be frozen shortly20:20
devanandaand we're not going to be reviewing specs for Kilo until closer to the summit20:20
JayFaweeks is one of the onmetal folks if you haven't met him yet :)20:20
aweeksdevananda: yeah, that's not an issue, but I figure I should put it somewhere in the meantime20:20
devanandaso feel free to propose it, but it'll just get -2'd and ignored until we open kilo discussions20:20
devanandasure20:20
devanandathat reminds me, i need to email about spec freeze. more things on my list of things that i need to do instead of getting healthy ...20:21
* devananda goes back to fixing up the nova driver patches20:21
JayFwhen is the spec freeze?20:21
devanandaand ignoring his coroporate emails20:21
JayFI can send an email about that when I send an email about the testing stuff, if you'd like?20:21
aweeksdevananda: ok, thanks20:22
*** davidlenwell_ is now known as davidlenwell20:23
devanandaJayF: based on my email "Juno priorities..." a month ago, I said we'd stop approving any more specs on Aug 1420:25
devanandaJayF: but I think we already have a lot approved and not yet implemented20:25
JayFWe certainly do, I think because since the mid-cycle we've been trying to get them through before the deadline. At least give the implementor a shot at making a code deadline for juno :)20:26
devananda++20:27
devanandaI'd like to propose that we bump the cut off to monday after the meeting20:27
devanandabut i'll propose that at the meeting20:27
*** Mikhail_D_ltp has quit IRC20:27
* devananda punts on writing an email about it now20:27
NobodyCamdevananda: are we bumping up the spec deadline, Should I not have approved the one I just did?20:27
openstackgerritAlex Weeks proposed a change to openstack/ironic-specs: Added IPA ssl/client certificate spec  https://review.openstack.org/11268220:28
devanandaNobodyCam: "to monday after the meeting"20:28
NobodyCamack.20:28
mgagnedevananda: sorry for delayed reply: we are already managing way more than 1000 nodes with our existing system (not ironic). So I guess Ironic will have to handle much more than that to be useful and not be an everyday scalability pain20:28
JayFmgagne: Please then, help us, hang out. We have similar plans at Rackspace to scale up Ironic to larger numbers than that :)20:29
devanandamgagne: do you need to use Nova with Ironic in this future world?20:29
mmitchelldevananda: yes20:30
mmitchelldevananda: (mgagne and I work at the same place ;))20:31
mgagneJayF: I'm just an operator which happens to have a strong programming background and designed a bunch of systems to automate baremetal deployment. I unfortunately didn't get assigned full time to the baremetal on openstack effort yet. I'm currently offering (moral) support to my fellow coworkers atm20:31
mgagnedevananda: mmitchell is one of the said coworkers20:31
devanandacool. well, please do hang out and help us make ironic and nova better20:32
mgagnedevananda: I want to make all openstack better =)20:32
NobodyCammgagne: this may have been asked already but what hardware are you running .. if I may ask20:32
mgagneNobodyCam: it's currently in dev phase so it's running in kvm20:33
NobodyCam:)20:33
JayFmgagne: I'm in the same boat, except lucky for me Rackspace enabled me to expand into software development and to work full-time on Ironic (well, and our product, which is built on Ironic). You can get some moral support from me in trying to get time to work on Ironic :P20:33
mgagneJayF: I'm still happy though, I operate and tweak our current openstack infrastructure which is a full time job by itself. If only I could get more than 24h per day =)20:34
mmitchellNobodyCam: plan is to re-use current already deployed inventory, so only PDU control and PXE boot control, no IPMI20:36
JayFwe should support, even with a driver like IPA20:37
JayFa blanket-chainload pxe thing20:37
JayFwhere anything that tries to pxe would get a chainload configuration back by default, unless ironic was trying to boot a deploy ramdisk20:38
devanandammitchell: single (trusted) tenant?20:38
mgagnedevananda: no, it's not for private consumption20:39
mgagneJayF: yep, it was one of the idea we had back then before Ironic exists =)20:40
mgagneJayF: always boot PXE and chainload to disk if no deployment request is set20:40
JayFmgagne: we had similar thoughts in the early days of our product planning for onmetal before we went ironic20:40
devanandaJayF: I think that's a perfectly reasonable setting to enforce20:41
JayFit would, paired with a good pdu driver, be all the pieces needed to get servers without a bmc provisioned20:42
mgagneJayF: one of our other products consists of a single tenant/virtual machine with added values and the DHCP/PXE "problem" was approached from a different angle. The idea was to give 100% of the disk to the customer for reasons still obscure as of today.20:43
JayFI'm not sure I understand.20:43
mgagneJayF: one host, one VM, one tenant20:44
mgagneJayF: so you can market it as a dedicated host with "added value"20:44
mmitchellmgagne: the initial requirement (that was dropped) was booting off that disk directly without the hypervisor20:44
devanandamgagne: all the benefits of managing VMs, none of the headache of bad neighbors20:44
mgagnemmitchell: I like to keep mystery around those details =)20:45
mgagnedevananda: yep20:45
devanandamgagne: downside is you still get the poor performance (for some workloads) of being in a VM20:45
mmitchellmgagne: no need to be secretive here ;)20:45
mgagneJayF: one guy had a great idea to avoid all-time DHCP/PXE boot which consisted of installing a second small disk with a bootloader chain loading Xen and VM20:45
mgagnedevananda: don't start me on benchmarking....20:45
mgagnedevananda: I spent months doing benchmarking and trying to explain all sort of weird behaviour especially one where the RAM disappeared and couldn't be accounted for.20:46
mmitchellthere's some ascii art of ram allocation in some xen .c file somewhere20:46
mmitchellfun times20:47
*** krtaylor has quit IRC20:47
JayFmgagne: that makes sense :)20:48
*** ellenh has left #openstack-ironic20:53
*** ellenh has joined #openstack-ironic20:53
lucas-dinnerdevananda, hey there, hmm I'm not sure... That's the ClientWrapper right? I think Shrews may be able to explain it. I'm not sure the reason why we use the icli.call("<cli command>" [,<cli args>,]) syntax20:56
lucas-dinnerdevananda, but yeah, I also think that icli.<command> looks more straight forward20:56
lucas-dinnerI mean... node.$FUNCTION20:56
Shrewslucas-dinner: there was a reason... but i'm fuzzy on it now20:57
Shrewslucas-dinner: i think it had to do with the multiple levels of api calls:  icli.node.<command>, icli.driver.<command>, etc20:57
* NobodyCam recalls that was done when we switched to the wrapper20:58
NobodyCambut I may be wrong20:58
Shrewsi missed deva's question about it though20:58
lucas-dinnerShrews, I c yeah it sounds like it could be it20:58
lucas-dinner<devananda> lucas-dinner: when you're around, can you explain why, in nova.virt.ironic.driver we use icli.call("node.$FUNCTION", params) rather than calling node.$FUNCTION(params) directly?20:59
lucas-dinner<devananda> lucas-dinner: I reread the client libs just now and it looks like that should work...20:59
devanandaShrews: I see lots of places using icli.call("node.$FUNCTION")20:59
lucas-dinnerShrews, ^20:59
devanandayea20:59
devanandathanks :)20:59
lucas-dinnerNobodyCam, yea it was, before we used the ironic client libs directly, but we had a mechanism to retry commands and it was duplicated all around the code. So the ClientWrapper was a convinent way to encapsulate that logic in one place21:00
Shrewsyeah, it was the muti-level attribute thing. if someone can come up with a way to not use the strings, i'm all for it21:00
lucas-dinner+1, I wouldn't do it now that we want the driver merged in nova21:01
lucas-dinnerbut for the future yeah, change that sytax makes sense to me21:01
devanandaif this is what we expect a user of our client libs to do, it seems like we didn't make them very user-friendly21:02
devanandaI don't think it is what we expect, though21:03
*** iron1 has joined #openstack-ironic21:03
lucas-dinnerdevananda, yeah :/ well the problem was the retry on Conflict21:03
devanandaahh21:03
lucas-dinnerunless we make the libs itself retry the requests21:03
lucas-dinnerI don't see any other way21:03
devanandaand this icli.call("string") was the work around?21:03
Shrewsyeah, that was the whole reason for the wrapper21:03
lucas-dinnerdevananda, yes21:03
devanandagotcha21:03
devanandathanks21:04
lucas-dinneryw21:04
* lucas-dinner brb21:04
*** jasondotstar has quit IRC21:04
openstackgerritEllen Hui proposed a change to openstack/ironic: Make DHCP provider pluggable  https://review.openstack.org/11235121:06
openstackgerritDevananda van der Veen proposed a change to openstack/ironic: backport reviewer comments on nova.virt.ironic.patcher  https://review.openstack.org/11269121:10
*** linggao has quit IRC21:11
openstackgerritAdam Gandelman proposed a change to openstack/ironic: Script to migrate Nova BM data to Ironic  https://review.openstack.org/11240221:12
jrolladam_g: mind looking at https://review.openstack.org/#/c/112693/ when you have a moment?21:16
adam_gjroll, sure21:17
jrollthanks21:20
*** matty_dubs is now known as matty_dubs|gone21:23
*** penick has quit IRC21:23
adam_gjroll, i assume having no postgres coverage is okay?21:24
jrolladam_g: if I'm using mysql-specific code in the ipa driver, please hurt me21:25
JayFadam_g: if ipa but not pxe broke with postgres vs mysql, that'd be a layering problem, right?21:25
jroll:)21:25
adam_gsure21:26
jrollJayF: btw, that's not the ideal config we want to get to, but it's a start21:27
*** penick has joined #openstack-ironic21:28
*** foexle has quit IRC21:28
*** ellenh has quit IRC21:41
NobodyCamhumm any one have a way to test the ipmi double bridging patch?22:03
JayFsounds like an experimental driver to me ;)22:03
NobodyCamhttps://review.openstack.org/#/c/95775 :0p22:04
JayF"anyone have a way to test $any_power_driver" == no :(22:04
NobodyCamheheehe22:04
openstackgerritJim Rollenhagen proposed a change to openstack/python-ironicclient: Add /nodes/detail support  https://review.openstack.org/11261022:04
*** ellenh has joined #openstack-ironic22:04
jrolldevananda: ^^ thanks for that review22:04
devanandaNobodyCam: jbjohnso might. or some folks at Intel.22:08
NobodyCamahh TY22:09
devanandaJayF: yes. well. no. since ya'll DO some db work in the IPA driver22:09
JayFdevananda: RFR if you have a moment, otherwise I'll happily send as-is: https://gist.github.com/jayofdoom/8578420ef4e37ea589f622:10
jrolldevananda: we call dbapi22:10
jrollso I guess if some dbapi function is broken in postgres, that only ipa uses...22:10
*** rwsu has quit IRC22:10
devanandaJayF: some of the terminology there around what gates what may be worth revising22:12
devanandaJayF: as that's not exactly how it works, and not how infra/QA folks refer to it22:12
devanandaJayF: https://etherpad.openstack.org/p/NvDZB5gox022:13
jrollah yeah... s/gate/check jobs/22:13
devanandathat's part of it :)22:13
jrollwe won't be gating on it at all to begin with22:13
*** rwsu has joined #openstack-ironic22:15
JayFis there some nutty bug in etherpad? my cursor keeps moving without me moving it22:16
JayFjroll: ^ can you update 112693 to reflect deva's suggestion in the etherpad22:17
NobodyCamJayF: do you have a bluetooth mouse?22:18
*** krtaylor has joined #openstack-ironic22:18
JayFNobodyCam: heh, no. Although I have a hilarious story about that... I work beside the office supply room and had a stored touchpad that was paired to my box and doing funky things22:19
NobodyCamlol ++++22:19
jrollJayF: done22:20
jrollNobodyCam: one time I was sitting across the room from my desk, logged into production... keyboard started going nuts so I just panicked and ctrl-d as quick as I could22:20
NobodyCamI have one case where someone had two BT keyboards and set something on one of them and was getting "aaaaaaaaa"'s across there screen22:20
jrollturned out the cleaning crew was wiping my keyboard down22:20
NobodyCamlol22:21
NobodyCamnice22:21
JayFI don't think I've ever seen jroll move so fast22:21
JayFhe jumped up like he was stung by a bee22:21
jrollyeah dude22:21
NobodyCamhehehheeh22:21
jrollit was a mysql shell22:21
jrollpanic mode22:21
NobodyCamoh ya22:21
NobodyCamdrop table *$^#$&#$^&$%*&*$%22:22
NobodyCamieek22:22
jrolllol22:22
JayFdevananda: thanks for the edits, that's a bunch better with a few changes :)22:27
devanandaJayF: think i'm done comment/editing22:27
devananda:)22:27
devanandayvw22:27
JayFdevananda: only question is22:27
openstackgerritEllen Hui proposed a change to openstack/ironic: Make DHCP provider pluggable  https://review.openstack.org/11235122:27
JayFwdym by the IPA CoreOS image build job stuff?22:27
devanandaoh22:27
JayFShould I just indicate we'd have post jobs building those?22:27
devanandaso ya'll are building a coreos image and publishing them somewhere22:27
devanandadon't you?22:27
JayFin a post job, yes22:27
devanandaright22:27
devanandaoooh so22:28
devanandawhen BUILDING that image, you run the check/gate tests WITH it22:28
devanandaso that you can't publish a broken image22:28
JayFhttps://github.com/openstack-infra/config/blob/master/modules/openstack_project/files/zuul/layout.yaml#L219422:28
JayFdevananda: I would think that if we gate IPA on the tempest tests against each image, it would mean a post job would never run against a broken image, right?22:29
devanandarun the ironic + ipa + tempest tests in the job that builds the CoreOS image22:29
devanandaright22:29
JayFHmm. So you're basically saying to replace the existing image build job with a tempest suite that /also/ creates an image22:30
JayFand we'd just have it additionally run that in post and publish the image22:30
devanandaJayF: where's the imabe build job code?22:30
devanandathis: gate-ironic-python-agent-buildimage-coreos22:30
JayFhttps://github.com/openstack/ironic-python-agent/blob/master/imagebuild/coreos/full_trusty_build.sh is the script that runs against a bare-trusty node22:30
JayFI can find the jjb piece too22:31
devanandak22:31
devanandatake a look at dib22:31
JayFhttps://github.com/openstack-infra/config/blob/master/modules/openstack_project/files/jenkins_job_builder/config/ironic-python-agent-jobs.yaml is the config bit22:31
devanandaafaik, dib is co-tested with ironic22:31
devanandaso a change in dib should, in theory, cause all of ironic's tests to run WITH that change BEFORE it passes22:32
devanandaoh22:32
devanandai see22:32
devanandaironic-in-devstack isn't consuming the final image though - it's consuming the code and building the image using dib's code22:32
JayFYeah, I was thinking we'd keep that model. Have tempest tests in check/gate for IPA that build and use the image to deploy machines22:33
JayFthen the post job would be lighter and just build and publish the image22:33
devanandayep22:33
JayFotherwise we're taking up a node for a long suite of tempest testing in post that's redundant22:33
devanandaright22:33
JayFwhereas just the imagebuild, for CoreOS, takes 2m-10m (depending on which cloud it gets provisioned to by nodepool)22:33
JayFso are you OK with that model? that was my thought when I was talking about this at the mid-cycle22:34
devananda++22:38
JayFdevananda: so are you +1 to that etherpad as it sits now then?22:38
* JayF about to timeout22:42
devanandaJayF: there's something that caught my eye22:42
devananda"fails against agent_ssh in Ironic but not against pxe_ssh in Nova"22:42
JayFI should word that better22:43
devanandaother than that, yes, LGTM22:43
JayFthe point I'm trying to make is that if pxe_ssh tests succeed when nova runs the ironic tempest suite22:43
JayFand then later the agent_ssh tempest suite fails due to that same nova change22:43
JayFthe cause would almost certainly be an /ironic/ bug, not a nova bug22:43
devanandaahhh22:44
devanandaso I missed that intent22:44
devanandaand it's a good point to make22:44
JayFSo if you missed it, and you have all the context, it's very unclear :)22:44
JayFsimilarly if IPA tests failed against CoreOS image (due to Ironic OR Nova change), but DIB image passed in Ironic/Nova tests, then it's almost certainly an *IPA* bug22:46
*** jgrimm has quit IRC22:47
devanandayep22:47
devanandamuch better22:47
JayFokay, that's awesome. going to send it22:47
JayFnice to be talking about testing the agent22:47
JayFinstead of talking about landing it22:48
devananda=)22:48
devanandaindeed it is22:48
*** penick has quit IRC22:51
*** penick has joined #openstack-ironic22:52
*** f13o_ has quit IRC22:57
*** dhellmann is now known as dhellmann_23:00
NobodyCambrb23:06
*** lucas-dinner has quit IRC23:09
devanandaJayF: still here?23:13
devanandaI finally read the drac raid spec23:13
JayFyeah, I'm here23:14
JayFjroll: everytime I review your devstack patch for ipa, I read $LINENO as $LOLNO as in, "die $LOLNO"23:15
devanandagoing to block it for several reasons23:15
JayFCool. I suspected you might which is why I linked it up to you23:16
JayF"displaying the current configuration for Dell Remote23:17
JayFAccess Controller in Ironic23:17
JayFnope because ironic is not a cmdb?23:17
devanandanope23:19
devanandathough that's almosta  good reason23:20
devanandaalso, it looks like someone already raised that concern, then later gave a +2 ?23:20
JayFYeah.23:20
JayFI have that concern a little too, but I remember we were chatting once about IPA, and you drew a line between in-band (mdadm/lvm) disk config and oob (hw raid controllers) disk config23:21
BadCubFYI @Nobodycam had to run to the vet with an emergency sample from one of the kids23:21
devanandaJayF: right - hw raid stuff is totally in scope, IMO23:21
*** penick has quit IRC23:21
devanandabut storing the inventory data ... is a fuzzy line23:21
JayFit sounded like they needed to store that data in order to implement it async23:21
devanandathis would be much more happy making if it was closer to our discussion on capabilities23:22
JayFYeah. I think we should have a spec for kilo-1 and get in in around using capabilities to manipulate firmware/settings(/raid config?)23:23
JayFthe cisco spec that asked for an exception on os-dev this morning was similarly icky23:23
JayFin that a large % of it was node auto-enrollment23:23
JayFalthough I couldn't remember if at the mid-cycle we declared that fully out of scope or /mostly/ out of scope :)23:23
*** mdorman has quit IRC23:25
devanandaI feel as though, at this point, we should just block anything having to dow ith auto enrollment or discovery23:27
devanandaand say "too contentions, lets revisit this at the summit"23:27
devanandagah. spelling.23:27
JayFI agree. I think I'm pretty firmly in the camp of no-auto-enrollment at this point. Just too complex to do well, and borderline out of scope23:28
*** penick has joined #openstack-ironic23:28
JayFalthough validating the information you create nodes with before deploying to them (anytime you deploy) should be in scope. Same reason as decom: ensure users get the same platform to deploy their workloads on every time23:28
devanandaJayF: have you seen https://review.openstack.org/#/c/101122/8/specs/juno/firmware_settings_design.rst23:43
devanandaalso, we REALLY need user docs23:45
devanandacause all of these things are more doc debt23:45
devanandaand without in-tree docs, we are marking features as implemented without any docs being written by the authors :(23:46
devanandaby we I mean me23:46
devanandaoh nvm, you commented on it alraedy23:47
*** ellenh has quit IRC23:47
JayFYeah that's specifically the spec that led to me starting the conversation about capabilities at midcycle23:48
devanandagotcha23:48
devanandahm. I read all those dates as June, not July23:48
devanandanow it makes sense23:49
JayFI feel like I'm missing a comment from that, pretty sure I responded to the last comment23:50
adam_gdevananda, so FYI the grenade work is just about done AFAICS. now just waiting on all of its dependencies to make it through the review queue23:51
devanandaawesomesauce23:52
adam_gwith his permission, ive taken over  https://review.openstack.org/#/c/112402/ while romcheg is gone23:52
adam_gdevananda, whats the story with the flavor migration scripts? why was it decided to go that route instead of just updating the flavor extra specs manually via API?23:53
devanandaadam_g: no CoAuthored line?23:53
* NobodyCam is back23:53
devanandaadam_g: not sure now? there's actually a second implementation of that floating around in gerrit, from lucas23:53
devanandaadam_g: as part of our general move away from using flavor extra specs at all in ironic23:54
devanandas/in/with/23:54
*** penick has quit IRC23:55
*** penick has joined #openstack-ironic23:55
openstackgerritAdam Gandelman proposed a change to openstack/ironic: Script to migrate Nova BM data to Ironic  https://review.openstack.org/11240223:55
adam_gdevananda, ok, well ATM i have grenade just updating them via Nova after creating and uploading the new deploy k+rd23:56
devanandaadam_g: you're just updating the flavor?23:56
devanandaadam_g: or updating all nodes driver_info?23:56
*** penick has quit IRC23:57
adam_gdevananda, ATM only the flavor23:57
devanandaah, i see23:58
devanandaso that's fair in the grenade test23:58
devanandaif we are ever goign to drop support for associating deploy k/r with flavors, we'll need to do more, but probably not related to grenade23:59
adam_gdevananda, should we be having grenade + the migration tools convert to instance_info at this point?23:59
devanandadriver_info23:59
devanandaso i'm not sure we need to23:59
adam_ghmm23:59
devanandajuno will support the backwards-compat way23:59
JayFjroll: around?23:59
devanandawe may drop that in kilo23:59
devanandabut that doesn't matter for this test23:59

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