| anteaya | rloo I was in a spin when I popped in before | 00:05 |
|---|---|---|
| anteaya | how are you? how was your flight home? | 00:05 |
| rloo | hi anteaya, my flight was fine. landed ok and everything :-) How about your's, i hope it wasn't delayed even more. | 00:12 |
| anteaya | no took off as expected | 00:15 |
| anteaya | fungi and beagles were on a flight that made it to Tokyo and turned around | 00:15 |
| anteaya | the water in the bathrooms wasn't working and the flight didn't have permission to land in Japan | 00:16 |
| rloo | OMG | 00:16 |
| anteaya | that is the worst flight experience I heard out of the summit | 00:16 |
| anteaya | yeah | 00:16 |
| anteaya | teh suck | 00:16 |
| rloo | anteaya: on the bright side, they're alive. That's what I tell myself when a flight is delayed or whatever. | 00:17 |
| anteaya | very true | 00:18 |
| anteaya | they are alive | 00:18 |
| anteaya | glad for that | 00:18 |
| anteaya | was very windy over Japan on our flight | 00:18 |
| openstackgerrit | A change was merged to openstack/python-ironicclient: Modifies CLI to show nodes by instance uuid https://review.openstack.org/53485 | 00:27 |
| NobodyCam | devananda: you around? | 00:29 |
| *** matsuhashi has quit IRC | 00:29 | |
| *** matsuhashi has joined #openstack-ironic | 00:30 | |
| *** matsuhashi has quit IRC | 00:34 | |
| *** lynxman has quit IRC | 00:46 | |
| *** lynxman has joined #openstack-ironic | 00:53 | |
| ctracey | anteaya: i was also on that flight | 00:53 |
| ctracey | anteaya: though, i had 3 flights in a row that were delayed for mechanical reasons | 00:54 |
| ctracey | so far been travelling 43 hours and I am not home yet ;) | 00:55 |
| rloo | ctracey: wow, good luck getting home. (I guess I had a wonderful flight and took it for granted!) | 01:02 |
| *** nosnos has joined #openstack-ironic | 01:05 | |
| *** nosnos has quit IRC | 01:05 | |
| *** nosnos has joined #openstack-ironic | 01:06 | |
| NobodyCam | woo hoo (almost) http://paste.openstack.org/show/b9OaBXAE3wTJuxJHZXLA/ | 01:06 |
| NobodyCam | devananda: ^^^^^ | 01:06 |
| *** matsuhashi has joined #openstack-ironic | 01:07 | |
| ctracey | rloo: we were actually sitting next to each other in the ironic sessions | 01:21 |
| ctracey | nice to make your acquaintance | 01:21 |
| rloo | ctracey: oh, did I speak to you? Are you the one from the Blue* company in Boston? | 01:25 |
| ctracey | rloo: yes | 01:25 |
| rloo | ha ha. that's great! nice to talk to you ctracey! | 01:26 |
| rloo | ctracey: I mentioned to lucasagomes that you were going to volunteer to do something, but he got it first -- he seemed willing for you to do it, but by then, I didn't know how to get in touch with you. So if you still want... | 01:27 |
| ctracey | rloo: i actually spoke to lucas after the sessions | 01:32 |
| ctracey | i started my new gig this week so i am getting settled here | 01:32 |
| ctracey | (and adjusting from HK time) | 01:33 |
| ctracey | by next week I should have some spare cycles | 01:33 |
| rloo | ctracey: that's great. I know "they" want more people to help out :-) | 01:33 |
| devananda | NobodyCam: yes, but there's no info there -- we need to be setting something in the node.properties dict that matches what nova wants | 02:29 |
| Haomeng | hello Ironic:) | 02:36 |
| Haomeng | good morning/afternoon/evening for every one:) | 02:36 |
| *** jbjohnso has joined #openstack-ironic | 02:37 | |
| devananda | good evening :) | 02:40 |
| Haomeng | :) | 02:41 |
| devananda | heading out for a bite to eat. bbl | 02:41 |
| Haomeng | see you devananda:) | 02:41 |
| *** jbjohnso has quit IRC | 02:59 | |
| *** michchap has quit IRC | 03:19 | |
| *** michchap has joined #openstack-ironic | 03:19 | |
| *** matsuhashi has quit IRC | 03:39 | |
| *** matsuhashi has joined #openstack-ironic | 03:40 | |
| *** matsuhashi has quit IRC | 03:44 | |
| *** michchap_ has joined #openstack-ironic | 03:53 | |
| *** michchap has quit IRC | 03:55 | |
| *** michchap has joined #openstack-ironic | 04:02 | |
| *** michchap_ has quit IRC | 04:04 | |
| *** urulama has joined #openstack-ironic | 04:12 | |
| *** matsuhashi has joined #openstack-ironic | 04:17 | |
| *** prekarat has joined #openstack-ironic | 04:19 | |
| *** jimjiang has joined #openstack-ironic | 04:21 | |
| *** rloo has quit IRC | 04:26 | |
| *** prekarat has quit IRC | 04:43 | |
| *** prekarat has joined #openstack-ironic | 04:44 | |
| devananda | lifeless: there's one decision from the ironic track that, now that my brain has recovered a bit, i'd like to chat with you about. have a few? | 04:45 |
| devananda | one in particular, that is | 04:47 |
| *** urulama has quit IRC | 04:47 | |
| NobodyCam | devananda: like this : http://paste.openstack.org/show/wi5zcSSARwPs8QQ3ZFxK/ | 04:53 |
| devananda | NobodyCam: YES!!! | 04:54 |
| devananda | :) | 04:54 |
| NobodyCam | :-p | 04:54 |
| devananda | awesome :) | 04:54 |
| devananda | is the revision up? | 04:54 |
| NobodyCam | no still a bit ruff | 04:55 |
| devananda | NobodyCam: ah, also, that should be stored in properties, not extra | 04:55 |
| NobodyCam | :) | 04:55 |
| NobodyCam | I'll clean it tomorrow | 04:56 |
| NobodyCam | clean it up | 04:56 |
| NobodyCam | that is | 04:56 |
| NobodyCam | beer is kicking in | 04:56 |
| devananda | :) | 04:56 |
| NobodyCam | :) | 04:56 |
| NobodyCam | so G'night from /me | 04:57 |
| devananda | night! | 04:57 |
| *** romcheg has joined #openstack-ironic | 04:58 | |
| *** matsuhashi has quit IRC | 05:01 | |
| *** matsuhashi has joined #openstack-ironic | 05:02 | |
| *** matsuhashi has quit IRC | 05:02 | |
| *** matsuhashi has joined #openstack-ironic | 05:07 | |
| *** urulama has joined #openstack-ironic | 05:18 | |
| *** Haomeng has quit IRC | 05:28 | |
| *** Haomeng has joined #openstack-ironic | 05:33 | |
| lifeless | devananda: sure | 05:39 |
| openstackgerrit | Jenkins proposed a change to openstack/ironic: Imported Translations from Transifex https://review.openstack.org/56325 | 06:00 |
| *** matsuhashi has quit IRC | 06:02 | |
| *** matsuhashi has joined #openstack-ironic | 06:02 | |
| devananda | lifeless: https://etherpad.openstack.org/p/IcehouseIronicFaultTolerance | 06:03 |
| devananda | lifeless: specifically, of the paths to HA that we discussed, and some of the challenges with multi-conductor-HA, the shortest route seemed to be shared file system | 06:04 |
| devananda | lifeless: does taht pose any significant problem for tripleo? | 06:04 |
| *** matsuhashi has quit IRC | 06:07 | |
| *** matsuhashi has joined #openstack-ironic | 06:07 | |
| lifeless | let me read it | 06:08 |
| lifeless | floating IP won't fly | 06:08 |
| lifeless | neutron won't let you have a floating ip on the same network you are on | 06:08 |
| lifeless | devananda: so ' auto discover failed conductors and initiate rebuild' looks best to me | 06:10 |
| *** matsuhashi has quit IRC | 06:11 | |
| *** matsuhashi has joined #openstack-ironic | 06:12 | |
| devananda | lifeless: no floating ip, but we can update the DHCP Opt on that neutron port to the same effect | 06:15 |
| lifeless | devananda: ack - I was noting for completeness (and I've commented in the spec) | 06:15 |
| devananda | just means many updates for many ports, instead of one update for the failed conductor. | 06:15 |
| devananda | yep. thanks | 06:15 |
| devananda | good to know that | 06:15 |
| lifeless | devananda: also, updates for many ports is better | 06:15 |
| lifeless | devananda: because rather than doubling one conductors load, it sheds it over N-1 other nodes. | 06:15 |
| lifeless | I will add that too | 06:16 |
| devananda | right | 06:16 |
| devananda | so, auto-discover failed conductors we can do, but initiate rebuild discussion raised one interesting point | 06:16 |
| *** matsuhashi has quit IRC | 06:16 | |
| lifeless | if someone deletes their image from glance, they get what they deserve. | 06:16 |
| devananda | we're talking about a failure situation, obviously, so we shouldn't assume that the db is necessarily representative of the node's actual state | 06:17 |
| lifeless | oh, different case :) | 06:17 |
| devananda | so rebuilding the tftp config based on the db may be unpredictable | 06:17 |
| lifeless | why shouldn't we ? | 06:17 |
| *** matsuhashi has joined #openstack-ironic | 06:17 | |
| lifeless | in what way can the db and files on disk be skewed - and it not be detected ? | 06:18 |
| devananda | picking one example and walking through it | 06:19 |
| lifeless | ok | 06:19 |
| devananda | actually, nvm | 06:20 |
| devananda | any time when the desired state of the node changes, there's a period where the node's actual state != desired state | 06:22 |
| lifeless | agreed | 06:22 |
| lifeless | the rebuild will give us desired state (or fail) | 06:22 |
| devananda | if conductor fails during one of thoe transitions, the rebuild will need to be able to restart (not resume) that transition | 06:23 |
| devananda | it's conceivable the transition could have finished autonomously after the first conductor instance died, thus the db is now out of sync. | 06:23 |
| lifeless | There are two sorts of transitions AIUI: complex workflow (deployment), simple assertions (unpack boot files on disk, make the power state be X) | 06:24 |
| *** romcheg has quit IRC | 06:24 | |
| devananda | yes, with others planned (start serial console, rebuild raid, etc) | 06:24 |
| lifeless | I think failing complex fworflow and not restarting it is fine; for assertion style things, just apply the desired state | 06:24 |
| lifeless | rebuild raid would be a separate thing? | 06:25 |
| devananda | separate? | 06:25 |
| lifeless | you're listing it as a complex workflow, but in my head it's part of 'deploy' - so I'm clearly out of date | 06:25 |
| devananda | still have a conductor. and in the PXE driver case, still have a tftp config which drives that work | 06:25 |
| devananda | it may be grouped with "deploy" but it will be implemented as a separate workflow | 06:26 |
| devananda | just like changing power state is a separate method, which is group with, and in the PXE case, also called from within, deploy | 06:27 |
| lifeless | I may be missing something but that sounds like it will incur another boot and another POST | 06:28 |
| *** matsuhashi has quit IRC | 06:30 | |
| devananda | yes | 06:30 |
| *** matsuhashi has joined #openstack-ironic | 06:30 | |
| *** matsuhashi has quit IRC | 06:30 | |
| lifeless | I thought we had a previous design where that wasn't the case? | 06:30 |
| lifeless | What invalidated it? | 06:30 |
| *** matsuhashi has joined #openstack-ironic | 06:30 | |
| lifeless | I realise we're ratholing, if you want to come back to this another time, thats fine by me. | 06:31 |
| devananda | maybe. let's see if the rathole ends in a few minutes :) | 06:32 |
| devananda | the design taht's been in my head, at least fo rthe pxe driver, involves a ramdisk with the capability to do one or more tasks | 06:33 |
| devananda | task { build raid, flash firmware, expose disks over iscsi, etc } | 06:33 |
| devananda | each task could be represented as a dib element, combinable with other hw-specific elements (eg, drivers) | 06:33 |
| devananda | in the session(s) on hw management, we discussed how to drive such a ramdisk without embedding a RESTful service in the ramdisk | 06:34 |
| lifeless | interesting. I've had a fundamentally different thing in my head. | 06:35 |
| devananda | interesting | 06:35 |
| devananda | we talked a while back about embedding an API into the ramdisk - you didnt like it, and i felt it would be too heavyweight. | 06:36 |
| lifeless | which is that we define a small language to describe the desired state and pass that to the ramdisk somehow (either as a response to a restful call it makes to the API, or as part of the initial kernel boot line - 6/1 1/2 of the other) | 06:36 |
| lifeless | and the ramdisk applies the desired state, exposes iscsi and pings for the image copy to happen | 06:36 |
| lifeless | so there's no orchestration or 'workflow' happening at all from the Ironic side, in whats in my head. | 06:37 |
| devananda | so | 06:37 |
| lifeless | For things with magic vendor interfaces they would do the same thing: apply the desired state, then do whatever they do to deploy. | 06:37 |
| lifeless | right, I don't think we need an agent in the ramdisk | 06:37 |
| devananda | what we agreed on at the summit was taht the ramdisk would make retful calls to ironic's API | 06:37 |
| devananda | no agent in ramdisk | 06:38 |
| devananda | just a loop that GETs, does something, GETs again | 06:38 |
| devananda | sounds like the same thing you're thinking of | 06:38 |
| lifeless | maybe | 06:38 |
| lifeless | I think there is quite a difference between a command-and-control interface | 06:38 |
| lifeless | and a data interface | 06:38 |
| lifeless | it *sounds* like you're talking about a command and control interface | 06:39 |
| lifeless | where Ironic is saying 'now do task X' | 06:39 |
| devananda | things with magic vendor interfaces wouldn't have this ramdisk at all | 06:40 |
| devananda | eg, iLO can do all the raid and fw stuff OOB | 06:40 |
| lifeless | sure | 06:40 |
| devananda | (so i've been told) | 06:40 |
| lifeless | so lets put them to the side | 06:40 |
| devananda | well, hang on | 06:40 |
| devananda | in your model, who is defining the desired state _script_ and passing that to the ramdisk? | 06:41 |
| lifeless | what script? | 06:41 |
| devananda | "we define a small language ..." | 06:41 |
| lifeless | language as in 'way of describing things' | 06:41 |
| lifeless | could just be a json schema | 06:41 |
| lifeless | not 'turing complete executable thing' | 06:41 |
| devananda | sure. my question remains | 06:42 |
| lifeless | e.g. - strawman - a json dict, {'disk': {...}, 'fw': {'deviceN': 'https://...'}} | 06:42 |
| lifeless | the API would be able to return that from a single GET | 06:42 |
| devananda | so that json dict would be created by the PXE driver based on various information provided to ironic, provided in an ironic-driver-agnostic way | 06:44 |
| lifeless | yes | 06:45 |
| lifeless | e.g. by the proposed use-cinder-to-define-raid-setup stuff | 06:45 |
| lifeless | or perhaps by flavor as a way to define raid setup - whatever we end up doing | 06:45 |
| devananda | ah. yea, that got massively shot down by all the cinder folks in the room | 06:45 |
| devananda | but let's not chase that rat yet | 06:45 |
| lifeless | funny, they were for it before ;) | 06:45 |
| devananda | well, the PTL thought it was good last summit, based on a 5-minute hallway chat ;) | 06:46 |
| devananda | anyhow, yes, that info is passed to ironic in some fashion | 06:46 |
| devananda | then it's passed to the driver | 06:47 |
| lifeless | ilo driver interprets it and pokes it straight into the machine | 06:47 |
| lifeless | pxe driver goes 'meh, ramdisk will do it all' | 06:47 |
| devananda | right | 06:47 |
| lifeless | awesome, we have stats | 06:48 |
| lifeless | New patch sets in the last 30 days: 1989 (66.3/day) | 06:48 |
| lifeless | nova ^ | 06:48 |
| lifeless | tripleo is | 06:48 |
| lifeless | New patch sets in the last 30 days: 416 (13.9/day) | 06:48 |
| devananda | patches or revisions? | 06:50 |
| lifeless | pushes to gerrit I believe. | 06:51 |
| devananda | so, it sounds like our ideas for the pxe ramdisk are similar. you're thinking to push a little more work into the ramdisk | 06:54 |
| devananda | and we were discussing making it a little less intelligent | 06:55 |
| devananda | IBMs proposal was that the ramdisk actually not know how to do anything besides GET, and then run what ever it got | 06:55 |
| lifeless | thats super enterprise. | 06:56 |
| lifeless | I don't like it because it makes the ramdisk harder to reason about, and incredibly hard to test. | 06:57 |
| devananda | yea. i prefer the middle road here. seems like putting all the logic in the ramdisk makes it very hw dependent | 06:57 |
| *** urulama has quit IRC | 06:57 | |
| devananda | the # of ramdisks grows exponentially as the number of different tasks * different hw platforms in a cloud | 06:57 |
| devananda | 1 ramdisk per hw platform, which can do all supported tasks, seems best | 06:59 |
| devananda | anyhow, the rathole before this one was HA :) | 06:59 |
| devananda | if, after starting up said ramdiska nd passing it some work, the conductor dies, then said ramdisk may complete step C but be unable to do D. | 07:01 |
| lifeless | so I was proposing one deploy ramdisk per hw platform; not sure how that grows badly | 07:01 |
| lifeless | right | 07:01 |
| lifeless | so the conductor failing would only impact the deploy step in my proposal | 07:01 |
| lifeless | since everything else is satisfied by the api not the confuctor | 07:02 |
| devananda | k. no, that doesn't grow badly. same as mine. the language just needs to be able to express one-or-many actions | 07:02 |
| devananda | hrm... | 07:02 |
| lifeless | and the deploy step for pxe is 'open iscsi and wait', so even that in principle could be resumed | 07:02 |
| lifeless | devananda: the one-or-many-actions thing still weirds me out: I'm talking declarative, you're talking procedural. | 07:03 |
| lifeless | devananda: it makes it hard to tell if we're agreeing or disagreeing. | 07:03 |
| devananda | i think you're seeing deply as the only means that any action occurs on a node | 07:03 |
| lifeless | (deploy resumable if the iscsi endpoint details are captured by the api as node state for the conductor to use) | 07:03 |
| devananda | and all non-deploy actions being bundled, declaratively, into the same deploy | 07:04 |
| lifeless | there are four cases I know of where we do something other than boot the users image | 07:04 |
| lifeless | - deploy | 07:04 |
| lifeless | - rescue | 07:04 |
| lifeless | - maintenance firmware or similar | 07:04 |
| lifeless | - disown | 07:04 |
| devananda | yep. you missed a few :) | 07:04 |
| devananda | - secure erase HDD | 07:04 |
| devananda | - interrogate hardware | 07:04 |
| *** romcheg has joined #openstack-ironic | 07:04 | |
| lifeless | secure erase == disown. I was being celver | 07:05 |
| devananda | ah | 07:05 |
| lifeless | clever | 07:05 |
| lifeless | - interrogate | 07:05 |
| devananda | we could implement snapshot / migrate this way, too ;) | 07:05 |
| lifeless | ok so, rescue is auser image too, so really we should not include it here | 07:05 |
| devananda | no, we should | 07:06 |
| lifeless | deploy/fw/erase/interrogate/snapshot/ | 07:06 |
| lifeless | why? | 07:06 |
| devananda | it is a change to the tftp environment | 07:06 |
| devananda | which would need to be consciously rebuilt somewhere else, if that conductor failed | 07:06 |
| devananda | *consciencously | 07:06 |
| lifeless | ok | 07:06 |
| lifeless | I'm not clear if we're talking HA or ramdisk construction at | 07:06 |
| lifeless | atm | 07:06 |
| devananda | oh | 07:06 |
| devananda | i think i have a foot in both ratholes | 07:07 |
| devananda | heh | 07:07 |
| lifeless | I could say one word from each and add confusion ? | 07:07 |
| devananda | :) | 07:08 |
| devananda | let me go back to the declarative-vs-procedural question | 07:08 |
| devananda | if we use a declarative language, who writes the interpreter that lives in a dib element? | 07:09 |
| lifeless | we do | 07:09 |
| lifeless | but more broadly the folk that are writing the pxe driver | 07:10 |
| devananda | what's the benefit to moving the procedural logic out of ironic, into bash, and using a declarative language to express it? | 07:11 |
| devananda | *out of ironic's pxe driver | 07:11 |
| devananda | it's also after 11pm and my brain may be fading | 07:13 |
| lifeless | the same benefit that using a functional programming style has: it's very easy to reason about. it forms a clear contract that is easy to implement differently (e.g. for windows or bsd), it keeps things decoupled | 07:15 |
| lifeless | and it allows hardware with different needs to not have to be modelled in the Ironic PXE driver. | 07:15 |
| lifeless | e.g. some hardware will need a reboot after fw or raid, others won't. | 07:16 |
| lifeless | also bash is a better language for expressing 'run a few scripts' than Python : it's why the shell is still shell, and not ipython | 07:16 |
| *** r-mibu has quit IRC | 07:22 | |
| lifeless | devananda: I suggest you drink up and sleep well :) | 07:32 |
| *** r-mibu has joined #openstack-ironic | 07:33 | |
| *** urulama has joined #openstack-ironic | 07:36 | |
| devananda | yep, sleep wins this round | 07:44 |
| devananda | lifeless: thanks for hashing through some of that with me :) | 07:45 |
| lifeless | anytime | 07:46 |
| *** Krast has joined #openstack-ironic | 07:58 | |
| *** ndipanov has joined #openstack-ironic | 08:01 | |
| *** ndipanov has quit IRC | 08:03 | |
| *** ndipanov has joined #openstack-ironic | 08:04 | |
| GheRivero | morning Ironic | 08:05 |
| *** matsuhashi has quit IRC | 08:30 | |
| *** matsuhashi has joined #openstack-ironic | 08:35 | |
| openstackgerrit | Haomeng,Wang proposed a change to openstack/ironic: Supporting both Python 2 and Python 3 with six https://review.openstack.org/56169 | 08:38 |
| Haomeng | morning GheRivero:) | 08:38 |
| openstackgerrit | Yuriy Zveryanskyy proposed a change to openstack/ironic: Fix node lock in PXE driver https://review.openstack.org/55565 | 08:38 |
| *** michchap is now known as 45PAALEL3 | 08:44 | |
| *** 20WAAKLSA has joined #openstack-ironic | 08:44 | |
| *** michchap has joined #openstack-ironic | 08:44 | |
| *** r-mibu_ has joined #openstack-ironic | 08:45 | |
| anteaya | ctracey: my goodness | 08:45 |
| *** ndipanov has quit IRC | 08:45 | |
| *** ndipanov has joined #openstack-ironic | 08:45 | |
| *** Krast has quit IRC | 08:45 | |
| *** r-mibu has quit IRC | 08:45 | |
| *** 45PAALEL3 has quit IRC | 08:45 | |
| *** GheRivero has quit IRC | 08:45 | |
| anteaya | ctracey: I hope you get home soon and get lots of sleep | 08:45 |
| *** Krast has joined #openstack-ironic | 08:46 | |
| *** GheRivero has joined #openstack-ironic | 08:46 | |
| *** nosnos has quit IRC | 08:46 | |
| *** jistr has joined #openstack-ironic | 08:46 | |
| *** jistr has quit IRC | 08:46 | |
| *** jistr has joined #openstack-ironic | 08:46 | |
| openstackgerrit | Yuriy Zveryanskyy proposed a change to openstack/ironic: Don't allow change reservation at create/update node https://review.openstack.org/55549 | 09:09 |
| *** lucasagomes has joined #openstack-ironic | 09:10 | |
| *** yuriyz has joined #openstack-ironic | 09:14 | |
| *** derekh has joined #openstack-ironic | 09:19 | |
| *** shausy has joined #openstack-ironic | 09:34 | |
| *** prekarat1 has joined #openstack-ironic | 10:02 | |
| *** prekarat has quit IRC | 10:04 | |
| *** Krast has quit IRC | 10:13 | |
| *** prekarat has joined #openstack-ironic | 10:20 | |
| *** matsuhashi has quit IRC | 10:20 | |
| *** matsuhashi has joined #openstack-ironic | 10:21 | |
| *** prekarat1 has quit IRC | 10:23 | |
| *** matsuhashi has quit IRC | 10:25 | |
| openstackgerrit | Lucas Alvares Gomes proposed a change to openstack/ironic: Register API options under the 'api' group https://review.openstack.org/54277 | 10:31 |
| *** 20WAAKLSA has quit IRC | 10:32 | |
| *** nosnos has joined #openstack-ironic | 10:33 | |
| openstackgerrit | Lucas Alvares Gomes proposed a change to openstack/ironic: Register API options under the 'api' group https://review.openstack.org/54277 | 10:33 |
| *** nosnos has quit IRC | 10:37 | |
| *** prekarat has quit IRC | 10:44 | |
| *** mdenny has quit IRC | 11:21 | |
| openstackgerrit | Haomeng,Wang proposed a change to openstack/ironic: Supporting both Python 2 and Python 3 with six https://review.openstack.org/56169 | 11:50 |
| *** michchap has quit IRC | 12:00 | |
| *** michchap has joined #openstack-ironic | 12:02 | |
| *** lucasagomes is now known as lucas-hungry | 12:07 | |
| *** ndipanov has quit IRC | 12:31 | |
| *** jistr has quit IRC | 12:32 | |
| *** jistr has joined #openstack-ironic | 12:37 | |
| *** michchap has quit IRC | 12:37 | |
| *** michchap has joined #openstack-ironic | 12:37 | |
| *** jistr has quit IRC | 12:37 | |
| *** jistr has joined #openstack-ironic | 12:41 | |
| *** urulama has quit IRC | 12:51 | |
| *** ndipanov has joined #openstack-ironic | 13:02 | |
| *** urulama has joined #openstack-ironic | 13:11 | |
| *** ndipanov has quit IRC | 13:29 | |
| *** prekarat has joined #openstack-ironic | 13:43 | |
| *** jdob has joined #openstack-ironic | 13:45 | |
| *** romcheg has left #openstack-ironic | 13:57 | |
| *** shausy has quit IRC | 14:00 | |
| *** jdob has quit IRC | 14:04 | |
| *** jdob has joined #openstack-ironic | 14:04 | |
| *** romcheg has joined #openstack-ironic | 14:08 | |
| *** max_lobur has quit IRC | 14:28 | |
| *** max_lobur has joined #openstack-ironic | 14:33 | |
| *** jdob has quit IRC | 14:35 | |
| *** jdob has joined #openstack-ironic | 14:35 | |
| *** jdob has quit IRC | 14:35 | |
| *** jdob has joined #openstack-ironic | 14:35 | |
| *** rloo has joined #openstack-ironic | 14:41 | |
| *** jdob has quit IRC | 14:50 | |
| *** jdob has joined #openstack-ironic | 14:51 | |
| *** jbjohnso has joined #openstack-ironic | 14:52 | |
| *** lucas-hungry is now known as lucasagomes | 14:54 | |
| *** prekarat has left #openstack-ironic | 14:55 | |
| NobodyCam | good morning Ironic | 15:08 |
| yuriyz | Morning NobodyCam | 15:12 |
| rloo | Hi NobodyCam, yuriyz, everyone else! | 15:14 |
| yuriyz | hi rloo | 15:14 |
| yuriyz | There are not many -1 on review today :) | 15:15 |
| rloo | yuriyz: that is good? | 15:16 |
| romcheg | Morning everyone | 15:16 |
| yuriyz | rloo, not very good :) | 15:16 |
| rloo | yuriyz. ha ha. I suppose I ought to do more reviews. | 15:17 |
| rloo | morning romcheg! | 15:17 |
| NobodyCam | good morning yuriyz rloo and romcheg | 15:17 |
| max_lobur | morning Ironic =) | 15:17 |
| romcheg | Managed to make devstack-gate to work for Ironic | 15:17 |
| NobodyCam | good morining max_lobur | 15:18 |
| NobodyCam | awesome | 15:18 |
| rloo | yay romcheg | 15:18 |
| romcheg | Now we have 4 patches that should be merged to enable tempest tests for Ironic | 15:18 |
| NobodyCam | romcheg: you have a list | 15:19 |
| lucasagomes | morning all :) | 15:20 |
| NobodyCam | morning lucasagomes | 15:21 |
| *** linggao has joined #openstack-ironic | 15:27 | |
| *** jistr has quit IRC | 15:32 | |
| *** ben_duyujie has joined #openstack-ironic | 15:33 | |
| openstackgerrit | Ruby Loo proposed a change to openstack/ironic: Changes power_state and adds last_error field https://review.openstack.org/54466 | 15:51 |
| NobodyCam | getting closer: http://paste.openstack.org/show/jFSXhzSuVjiKkvtS9TAb/ | 15:54 |
| NobodyCam | lucasagomes: off the top of your head do you happen to know if I can use the cli to add a fake a instance uuid | 16:03 |
| lucasagomes | NobodyCam, maybe, ironic node-update <node id> replace instance_uuid=<instance uuid> | 16:06 |
| lucasagomes | but idk, if not you can add to the db directly | 16:06 |
| *** retr0h has joined #openstack-ironic | 16:09 | |
| *** kobier has joined #openstack-ironic | 16:09 | |
| NobodyCam | :) yeo | 16:11 |
| NobodyCam | yep | 16:11 |
| NobodyCam | http://paste.openstack.org/show/g0h1vtdJ35yXYDRHyz8U/ | 16:13 |
| NobodyCam | cool :-p | 16:13 |
| *** shadower has joined #openstack-ironic | 16:14 | |
| lucasagomes | NobodyCam, :P | 16:18 |
| lucasagomes | well it kinda works haha | 16:18 |
| NobodyCam | root@undercloud-notcompute-wifscuca2int:/opt/stack/nova# ironic node-update 1abdaa2b-42ff-4583-b0c1-3415c73b2979 replace power_state=OFF | 16:18 |
| NobodyCam | Changing states is not allowed here; You must use the nodes/1abdaa2b-42ff-4583-b0c1-3415c73b2979/state interface. | 16:18 |
| NobodyCam | :-p | 16:18 |
| lucasagomes | haha | 16:18 |
| lucasagomes | loads of work to do on that part | 16:18 |
| NobodyCam | heheheh | 16:19 |
| rloo | btw, power_state is power_on or power_off I believe. OFF is not accepted (or shouldn't be) | 16:19 |
| NobodyCam | bey nova is talking to itonic | 16:19 |
| NobodyCam | ironic even | 16:19 |
| NobodyCam | yep https://github.com/openstack/ironic/blob/master/ironic/common/states.py#L62 | 16:20 |
| devananda | morning, all | 16:21 |
| NobodyCam | lol TY rloo | 16:21 |
| NobodyCam | morning devananda :) | 16:21 |
| GheRivero | morning all | 16:21 |
| rloo | morning! devananda | 16:21 |
| NobodyCam | devananda: 07:54 | NobodyCam > getting closer: http://paste.openstack.org/show/jFSXhzSuVjiKkvtS9TAb/ | 16:21 |
| NobodyCam | morning GheRivero :) | 16:21 |
| lucasagomes | morning rloo devananda | 16:22 |
| rloo | afternoon lucasagomes! | 16:22 |
| devananda | romcheg: i saw - grats on devstack-gate starting up | 16:27 |
| devananda | romcheg: also, did you see transifex now doing its thing? | 16:27 |
| *** jistr has joined #openstack-ironic | 16:29 | |
| yuriyz | morning devananda | 16:35 |
| max_lobur | hi devananda, do you have a 5 minutes? | 16:37 |
| yuriyz | devananda, what you think about private API service as option, see my comment https://blueprints.launchpad.net/ironic/+spec/vendor-lightweight-auth | 16:37 |
| romcheg | devananda: Morning | 16:41 |
| romcheg | I was just about to check Transifex :) | 16:41 |
| rloo | hi yuriyz, wrt https://review.openstack.org/#/c/54466, saw your comment. Thanks! Question though. I'm a bit concerned about modifying 'last_error' in something called .reserve_nodes(). Seems more like a side effect? but better performance would be good... | 16:43 |
| devananda | max_lobur: sure | 16:47 |
| yuriyz | rloo, I think reserve_nodes() == new exclisive action like power, deploy and let Devananda will look | 16:47 |
| max_lobur | could you please take a look at https://bugs.launchpad.net/ironic/+bug/1250575 | 16:48 |
| devananda | yuriyz: i think we should see how other services in openstack address this. i dont want to expose insecure API publicly, or require deployer to run extra services | 16:48 |
| max_lobur | what do you think | 16:48 |
| max_lobur | There is incorrect default config opt value | 16:49 |
| max_lobur | which brokes our RPC exception deserialization | 16:49 |
| max_lobur | but it's under openstack/common so we can't change it directly | 16:49 |
| rloo | ok yuriyz, will try it out ;) | 16:49 |
| devananda | max_lobur: so, ironic.conf.sample does need to be regenerated | 16:49 |
| devananda | max_lobur: is that the only issue? | 16:50 |
| max_lobur | if you're asking regarding config - yes | 16:50 |
| devananda | max_lobur: ah, i think i see | 16:51 |
| max_lobur | there is wrong default | 16:52 |
| max_lobur | and therefore wrong config | 16:52 |
| NobodyCam | bbt brb | 16:52 |
| max_lobur | wrong default leads to improper deserialization | 16:52 |
| lucasagomes | max_lobur, devananda on my patch that adds the api configuration to the api group | 16:54 |
| lucasagomes | I regenerated that file | 16:54 |
| devananda | problem is that http://git.openstack.org/cgit/openstack/ironic/tree/ironic/openstack/common/rpc/__init__.py#n59 | 16:54 |
| devananda | should read 'ironic.common.exception' | 16:54 |
| max_lobur | yes | 16:54 |
| devananda | not 'ironic.openstack.common.exception' | 16:54 |
| max_lobur | exactly | 16:54 |
| devananda | yea... | 16:54 |
| max_lobur | and It seems that nova.exception and cinder.exception can be omitted | 16:55 |
| NobodyCam | good catch max_lobur | 16:55 |
| devananda | lemme do a sync from oslo and see if that changes anything | 16:56 |
| max_lobur | https://github.com/openstack/oslo-incubator/blob/master/openstack/common/rpc/__init__.py#L58 | 16:56 |
| max_lobur | this is current oslo code | 16:56 |
| max_lobur | perfectly works for nova =) but doesn't for other project =) | 16:57 |
| devananda | heh. well, that's a bug in oslo then, ya? | 16:57 |
| max_lobur | hm | 16:57 |
| *** romcheg has quit IRC | 16:58 | |
| max_lobur | this is project specific | 16:58 |
| max_lobur | I assume it's generated when oslo is being imported to project | 16:58 |
| max_lobur | somehow | 16:58 |
| max_lobur | is that correct? | 16:58 |
| devananda | that's what i'm trying to check | 16:58 |
| devananda | it should be munged to the project's needs. bu tmaybe it's not doing that the way we expect | 16:58 |
| max_lobur | yes, exactly | 16:59 |
| yuriyz | yes, IMO this is ironic bug, oslo code: https://github.com/openstack/oslo-incubator/blob/master/openstack/common/rpc/__init__.py#L58 | 16:59 |
| max_lobur | not sure how it works, i thought there are some place holders for project-specific things | 17:01 |
| max_lobur | but there are just usual code | 17:01 |
| max_lobur | it should be complex parser to adopt those oslo files to project | 17:01 |
| devananda | i'm regenerating my oslo-incubator venv and resyncing from oslo | 17:01 |
| devananda | lesse how much changed | 17:02 |
| devananda | heh. everything :) | 17:02 |
| devananda | been a while since I did that | 17:02 |
| max_lobur | Is something broken after resync? what's the new default? | 17:05 |
| devananda | so a full resync from oslo yielded 7200 line diff | 17:06 |
| devananda | been a while, like i said | 17:06 |
| max_lobur | =) | 17:06 |
| devananda | * 7525 line | 17:06 |
| devananda | hrm. why do we haev both ironic.common.policy and ironic.openstack.common.policy, and why do we actually use both? | 17:10 |
| max_lobur | someone implemented our own layer above ironic.openstack.common.policy | 17:14 |
| max_lobur | so, did resync fixed the default rpc option? | 17:15 |
| devananda | the list is now: 59 default=['nova.exception', | 17:16 |
| devananda | 60 'cinder.exception', | 17:16 |
| devananda | 61 'exceptions', | 17:16 |
| max_lobur | yea | 17:17 |
| max_lobur | similar to original in oslo | 17:17 |
| max_lobur | so currently it does not adopted to project at all | 17:17 |
| devananda | seems so | 17:17 |
| devananda | lemme ping dhellman | 17:18 |
| max_lobur | so do you think we need to try to push fix to oslo or build or override for this? | 17:18 |
| max_lobur | *our override | 17:18 |
| max_lobur | sorry devananda, I need to go earlier, could you please comment the bug https://bugs.launchpad.net/ironic/+bug/1250575 if you find something, I will work on this tommorow | 17:23 |
| max_lobur | so currently I see the following options | 17:23 |
| max_lobur | 1. fix this in Oslo, resync, regenerate sample | 17:23 |
| max_lobur | 2. create override in our part of project, regenerate | 17:23 |
| devananda | max_lobur: will do | 17:23 |
| max_lobur | not sure about 2.. | 17:23 |
| max_lobur | tried today, it works, but new sample doesn;t reflect that | 17:23 |
| devananda | max_lobur: i was just grepping other projects. it looks like heat added their line manually to openstack/common/rpc/__init__.py | 17:23 |
| devananda | but ya, regenerating from oslo would override it | 17:24 |
| max_lobur | I mean exception begin deserialized properly with override | 17:24 |
| devananda | making work to carry it every time | 17:24 |
| max_lobur | but sample still wrong | 17:24 |
| devananda | max_lobur: i mean, we add our line(s) directly to ironic/openstack/common/rpc/__init__ | 17:24 |
| max_lobur | devananda, yea, It's probably third | 17:24 |
| devananda | then sample.conf will be correct | 17:24 |
| max_lobur | 3. change openstack/common/rpc/__init__, regenerate :) | 17:25 |
| max_lobur | but | 17:25 |
| max_lobur | will the next sync erase that? | 17:25 |
| max_lobur | and are we expecting to do further syncs? | 17:25 |
| devananda | yes, and yes | 17:26 |
| max_lobur | so 3rd is not an option | 17:26 |
| max_lobur | only 1 and 2 | 17:26 |
| devananda | that's what i meant by, "makingw ork to carry it every time" | 17:26 |
| devananda | anyhow. i'll chat with dhellman about it and see what other projects are diong | 17:27 |
| max_lobur | do you mean some checklist - what to do when syncing oslo | 17:27 |
| max_lobur | devananda, thanks | 17:27 |
| max_lobur | bye :) | 17:27 |
| openstackgerrit | Ruby Loo proposed a change to openstack/ironic: Changes power_state and adds last_error field https://review.openstack.org/54466 | 17:32 |
| devananda | rloo: does ^ fix the bug entirely, or partially? | 17:36 |
| rloo | devananda: partially, i haven't wrapped my head around provisioning yet. | 17:36 |
| rloo | devananda. well, the bug was wrt the power stuff, so that is fixed (i hope). | 17:36 |
| devananda | rloo: https://wiki.openstack.org/wiki/GitCommitMessages#Including_external_references | 17:37 |
| devananda | rloo: note closes-bug, partial-bug, related-bug | 17:37 |
| rloo | devananda: ah, didn't realize that. So, do you consider the bug is only for power-state, or does it include provisioned? | 17:39 |
| rloo | devananda: i was going to include provisioned in that too, although the code for provisioned isn't all there yet. | 17:40 |
| NobodyCam | smaller patches are better..LOL :-p | 17:40 |
| devananda | the bug seems pretty clearly about power state to me :) | 17:41 |
| rloo | devananda: ok, that's fine with me. | 17:41 |
| openstackgerrit | Ruby Loo proposed a change to openstack/ironic: Changes power_state and adds last_error field https://review.openstack.org/54466 | 17:43 |
| devananda | rloo: this change is interesting: https://review.openstack.org/#/c/54466/4..6/ironic/db/sqlalchemy/api.py | 17:43 |
| rloo | devananda: yuriy suggested that. I'm on the fence about it. | 17:43 |
| devananda | i think that's right, though i hadn't thought to put it at that low level yet | 17:43 |
| rloo | devananda: it seems too low for me, but I don't have a good picture yet of how everything works. Anyway, seems easy enough to move back up if we need to do so. | 17:44 |
| devananda | any non-shared lock is going to invoke that. | 17:44 |
| devananda | which means a lot of places in the code already | 17:44 |
| rloo | devananda: right, but only power_state uses last_error for now ;) | 17:45 |
| devananda | yes, but clearing last_error when just updating node.extra{} ? | 17:46 |
| rloo | devananda: should I wait a few more minutes in case you have other comments? Going to get my commute out of the way... | 17:46 |
| devananda | rloo: nah, i'll leave them in the review | 17:47 |
| rloo | ok thx. laytah, devananda. | 17:47 |
| rloo | devananda. and thx! | 17:47 |
| *** rloo has quit IRC | 17:48 | |
| devananda | np! | 17:48 |
| *** harlowja has joined #openstack-ironic | 17:53 | |
| *** epim has joined #openstack-ironic | 17:57 | |
| *** derekh has quit IRC | 17:59 | |
| NobodyCam | devananda: question: on line 157 of https://review.openstack.org/#/c/51328/2/nova/virt/ironic/driver.py | 18:04 |
| NobodyCam | any reason that can not be "baremetal" | 18:05 |
| *** urulama has quit IRC | 18:05 | |
| devananda | NobodyCam: because that's what the 'baremetal' driver returned,a nd this is a different driver? | 18:06 |
| *** jistr has quit IRC | 18:06 | |
| NobodyCam | devananda: but register our self with keystone as service type baremetal | 18:06 |
| NobodyCam | 'os_service_type': 'baremetal' | 18:07 |
| devananda | NobodyCam: yes. these are different things | 18:12 |
| NobodyCam | ok :) | 18:12 |
| *** blamar has joined #openstack-ironic | 18:14 | |
| devananda | NobodyCam: within nova, each hypervisor exposes a name for itself. eg, QEMU, xen, hyperv | 18:15 |
| *** urulama has joined #openstack-ironic | 18:15 | |
| NobodyCam | ya | 18:16 |
| devananda | but those hypervisors aren't registered with keystone | 18:16 |
| devananda | we just happen to be both a nova driver -and- a registered service | 18:17 |
| NobodyCam | hehehe :) got cought up with the type bit | 18:17 |
| NobodyCam | brb | 18:18 |
| NobodyCam | going to have to move sunday night | 18:26 |
| NobodyCam | for a few days | 18:26 |
| *** blamar has quit IRC | 18:26 | |
| *** blamar has joined #openstack-ironic | 18:27 | |
| *** urulama has quit IRC | 18:29 | |
| NobodyCam | devananda: one more quick question. looking at line 100 of that same driver file. is the REF to conf.baremetal just somehting not yet updated? | 18:29 |
| lucasagomes | gnight everybody! | 18:32 |
| NobodyCam | night lucasagomes :) | 18:32 |
| devananda | g'night lucasagomes | 18:32 |
| devananda | NobodyCam: yep. copy/paste error on my part | 18:32 |
| NobodyCam | :) just wanted to make sure :-P | 18:33 |
| devananda | NobodyCam: i suspect line 121 is also copy/paste error | 18:33 |
| *** lucasagomes has quit IRC | 18:33 | |
| devananda | * 122 | 18:33 |
| NobodyCam | I assume that I can assume any ref to conf.baremetal is legacy | 18:33 |
| devananda | ya | 18:34 |
| NobodyCam | hehehehe | 18:34 |
| *** urulama has joined #openstack-ironic | 18:35 | |
| * NobodyCam look for some food | 18:38 | |
| NobodyCam | *looks | 18:38 |
| *** docaedo has joined #openstack-ironic | 18:45 | |
| *** rloo has joined #openstack-ironic | 18:48 | |
| *** urulama has quit IRC | 18:49 | |
| *** rloo has quit IRC | 18:50 | |
| NobodyCam | have we talked about how and where to tag things like the deploy_kernel and ramdisk id's | 18:50 |
| *** rloo has joined #openstack-ironic | 18:50 | |
| *** urulama has joined #openstack-ironic | 18:55 | |
| *** hemna has joined #openstack-ironic | 18:59 | |
| *** urulama has quit IRC | 19:07 | |
| NobodyCam | brb | 19:11 |
| devananda | NobodyCam: no. but. I would like to keep the metadata in Nova unchanged (leave those as extra specs on the image) and have the nova-ironic driver stick them in the node.driver_info dict | 19:12 |
| *** ben_duyujie has quit IRC | 19:13 | |
| devananda | hm. we need an ironicclient method to initiate the deploy, don't we | 19:14 |
| devananda | also, folks, our gate pipeline is about to get slower: https://review.openstack.org/#/c/56439/ | 19:14 |
| devananda | with that, changes to ironic will get a full devstack test, not just our unit tests | 19:15 |
| *** urulama has joined #openstack-ironic | 19:15 | |
| *** urulama has quit IRC | 19:29 | |
| rloo | hi devananda, do/when you have a few minutes, I'd like to discuss your comments to 54466, to make sure I understand. | 19:33 |
| *** urulama has joined #openstack-ironic | 19:34 | |
| *** epim has quit IRC | 19:44 | |
| *** urulama has quit IRC | 19:45 | |
| *** urulama has joined #openstack-ironic | 19:45 | |
| devananda | rloo: hi! sure | 19:48 |
| rloo | hi devananda. so what's your rule-of-thumb for using Exception? I'd use it as much as possible cuz I'm paranoid. | 19:49 |
| rloo | vs exception.IronicException I mean. | 19:50 |
| rloo | Just wondering if you meant to change it for that one try/except, or whether I should do so elsewhere. | 19:50 |
| devananda | rloo: when we're trying to catch known error conditions and take action, use the most specific possible | 19:50 |
| devananda | rloo: when we need to enforce some action regardless of what type of failure happened, use Exception | 19:51 |
| rloo | devananda: ok, that makes sense. thx. | 19:51 |
| rloo | devananda. next question. I think you view the last_error usage for operations like power/provision changes. but not update-node? | 19:51 |
| devananda | correct | 19:51 |
| rloo | devananda. isn't it possible for update-node operation to result in an error? | 19:51 |
| devananda | that's an interesting point | 19:52 |
| rloo | devananda. the 'only' diff seems to be eg rpc call vs cast? | 19:52 |
| devananda | update-node could run into a lock (in which case it shouldn't change last-error) or it could just fail (eg, database is unreachable) in which case it should return the error (it can, it's an RPC CALL) | 19:52 |
| NobodyCam | rloo like this: http://paste.openstack.org/show/g0h1vtdJ35yXYDRHyz8U/ | 19:52 |
| rloo | NobodyCam, you're quick on the draw! | 19:53 |
| NobodyCam | lol | 19:53 |
| rloo | NobodyCam - that was an update-node request? | 19:54 |
| devananda | yes | 19:54 |
| *** urulama_ has joined #openstack-ironic | 19:54 | |
| *** urulama has quit IRC | 19:54 | |
| NobodyCam | yes | 19:54 |
| devananda | replace -> PATCH -> rpc.update_node | 19:54 |
| rloo | would the user expect to see something in last_error? I'm guessing yes? | 19:54 |
| devananda | if a deploy is in process | 19:54 |
| devananda | and the user tries to change metadata (eg, replace driver_info/foo=bar) | 19:55 |
| devananda | this will fail with an error similar to what NobodyCam pasted | 19:55 |
| devananda | but it certainly should not set last_error, since the deploy is still running | 19:55 |
| rloo | devananda: ok, I don't grok deployments yet (the states related to that). | 19:56 |
| devananda | we have two classes of failures here | 19:56 |
| devananda | failure to start doing something | 19:56 |
| devananda | failure to start doing something (both sync and async tasks) | 19:57 |
| devananda | failure to finish doing something (both sync and async tasks) | 19:57 |
| rloo | devananda: and last_error is for the latter? | 19:58 |
| devananda | actually that's 4 classes, not 2 | 19:58 |
| devananda | and I think we can only use last_error for the "fails to finish an async task" class | 19:58 |
| NobodyCam | ++ | 19:58 |
| rloo | ok. | 19:59 |
| NobodyCam | any failure on a sync tack should just report | 19:59 |
| devananda | yep | 19:59 |
| rloo | so stupid question, how does update_node errors get propagated back to api? | 20:00 |
| devananda | the exception gets passed back over the RPC channel | 20:00 |
| devananda | because it's an rpc.call | 20:00 |
| rloo | ahh, didn't know that. I need to look at that code. thx. | 20:01 |
| devananda | :) | 20:01 |
| rloo | ok, devananda, you've answered my questions. (for now). Thx! | 20:01 |
| devananda | welcome! | 20:01 |
| NobodyCam | and the only stupid question is one for which you do not seek an answer | 20:01 |
| * devananda thinks we should doc this somewhere | 20:01 | |
| devananda | rloo: mind adding a note inline about what we just discussed as the valid use for last_error? | 20:02 |
| NobodyCam | this channel is logged in eveasdrop now | 20:02 |
| rloo | devananda: sure. | 20:02 |
| devananda | thanks | 20:03 |
| rloo | NobodyCam: even though this channel is logged, I think it makes sense to doc elsewhere. Cuz I don't want to be glued to IRC ;) | 20:03 |
| NobodyCam | lol ++ | 20:03 |
| *** urulama_ has quit IRC | 20:04 | |
| *** urulama has joined #openstack-ironic | 20:04 | |
| *** epim has joined #openstack-ironic | 20:07 | |
| *** urulama has quit IRC | 20:09 | |
| NobodyCam | devananda: did I understand correctly you wish to keep the deploy kernel and ramdisk attached to the flavor? | 20:11 |
| NobodyCam | http://paste.openstack.org/show/DTHciA2saCj2tpU3kOS8/ | 20:12 |
| *** urulama has joined #openstack-ironic | 20:13 | |
| NobodyCam | I'm thinking chassis or node is the correct place for that? | 20:13 |
| NobodyCam | it really is lagacy artifacts of pxe based deploys | 20:15 |
| NobodyCam | s/it/they are/ | 20:15 |
| NobodyCam | and following that logic they should go with the driver | 20:16 |
| *** urulama_ has joined #openstack-ironic | 20:23 | |
| *** urulama has quit IRC | 20:24 | |
| *** rloo has quit IRC | 20:26 | |
| *** rloo has joined #openstack-ironic | 20:27 | |
| *** urulama_ has quit IRC | 20:33 | |
| *** urulama has joined #openstack-ironic | 20:34 | |
| *** urulama has quit IRC | 20:43 | |
| *** urulama_ has joined #openstack-ironic | 20:43 | |
| *** urulama_ has quit IRC | 20:48 | |
| *** rloo has quit IRC | 20:50 | |
| devananda | NobodyCam: so, there's a few angles on that | 20:51 |
| devananda | NobodyCam: i haven't considered all of them yet | 20:51 |
| *** rloo has joined #openstack-ironic | 20:51 | |
| NobodyCam | :-P i really think the nova flavor is the WRONG place | 20:51 |
| devananda | NobodyCam: so, the deploy k&r refer to a tool that is specific to the ironic pxe driver, the arch of the machine being targeted, and, at present, the work being done on it | 20:52 |
| *** urulama has joined #openstack-ironic | 20:53 | |
| NobodyCam | yes | 20:53 |
| devananda | NobodyCam: lifeless and I discussed some of the proposals from the summit for that hardware-mgmt-ramdisk stuff. we didnt' quite agree on whether its interface should be programatic or declarative, but we did agree taht there should be | 20:54 |
| devananda | one mgmt ramdisk per node architecture | 20:54 |
| devananda | and *not* one ramdisk per action | 20:54 |
| NobodyCam | ok should the driver have the logic to know what arch to user and there by have to know all the posiable archs | 20:55 |
| lifeless | right | 20:55 |
| lifeless | nothing we're doing is so big that we need to partition it out | 20:55 |
| devananda | that ramdisk may need to fetch other things from glance (eg, firmware images) | 20:56 |
| NobodyCam | or are we thinking tag that to something like the chassis or node that woud know its own arch | 20:56 |
| devananda | we can put an arch tag in node.properties | 20:57 |
| devananda | and the nova driver can expose that to the scheduler, which there were hooks for in the baremetal driver | 20:57 |
| devananda | eg, extra_specs:cpu_arch:x86_64 | 20:57 |
| NobodyCam | pxe deploys then will know to use the 64bit version of the deploy K&R | 20:58 |
| devananda | but the question is, where is the association of "deploy k&r" :: "node" | 20:58 |
| devananda | at the low level, it needs to be set on node.driver_info | 20:59 |
| NobodyCam | we could set a default in the chassis that could be overwriten but the node if that node needed somehting different | 20:59 |
| NobodyCam | s/but/by/ | 21:00 |
| NobodyCam | eithr that or teach pxe to know what to use / when to use it | 21:01 |
| NobodyCam | lifeless: so your thinking pxe driver should know what deploy K&R based on the nodes arch? | 21:02 |
| *** urulama_ has joined #openstack-ironic | 21:03 | |
| lifeless | btw its a public holiday for me today | 21:04 |
| lifeless | so I'm not really here | 21:04 |
| NobodyCam | ahh :) hehehe enjoy :) | 21:04 |
| *** urulama has quit IRC | 21:04 | |
| NobodyCam | devananda: I can see logic in pxe driver knowing what it need to deploy to different archs. ie i386/x64/arm/6502 | 21:06 |
| NobodyCam | would be a limited list | 21:06 |
| devananda | NobodyCam: i think the driver should know. right | 21:07 |
| NobodyCam | :) | 21:07 |
| lifeless | in nova bm we map flavor -> deploy ramdisk | 21:08 |
| lifeless | do we ever need different 'deploy' ramdisks for the same machine for different flavors? | 21:08 |
| NobodyCam | that was my question that started the topic | 21:08 |
| lifeless | If not, then it seems like we should register glance ids with ironic for this against the node's pxe driver config | 21:09 |
| lifeless | that does suggest a lot of PUTs when the ramdisk is regenerated though | 21:09 |
| NobodyCam | with each nodes, or as a "global" pxe driver option | 21:10 |
| NobodyCam | I was thinking it part of the pxe driver config just not on a per node basis | 21:11 |
| devananda | do we need to allow variation in the ramdisk within the same arch? | 21:11 |
| devananda | eg, for things like different NIC or RAID drivers | 21:11 |
| openstackgerrit | Ruby Loo proposed a change to openstack/ironic: Changes power_state and adds last_error field https://review.openstack.org/54466 | 21:11 |
| lifeless | NobodyCam: the pxe driver manages many different sorts of hardware | 21:11 |
| NobodyCam | good point | 21:12 |
| lifeless | devananda: certainly that variation will be present | 21:12 |
| NobodyCam | ya | 21:12 |
| devananda | so we need to allow more variation than just cpu arch | 21:12 |
| *** urulama_ has quit IRC | 21:12 | |
| lifeless | devananda: I would be strongly inclined to support it without forcing the union of drivers into one disk (because we may someday find that that is a fail) | 21:12 |
| devananda | exactly | 21:13 |
| *** urulama has joined #openstack-ironic | 21:13 | |
| lifeless | the simplest thing is just glance k&r pair in the driver-node-config | 21:13 |
| NobodyCam | yep | 21:13 |
| lifeless | I'm very much in favor of the simplest thing for now, to get to nova bm parity | 21:14 |
| lifeless | simplest not obviously wrong thing :) | 21:14 |
| NobodyCam | lifeless: ++ | 21:14 |
| *** urulama has quit IRC | 21:18 | |
| devananda | NobodyCam: yea. so node.driver_info gets the 5 image bits. deploy k & r, user k & r, and user image. | 21:18 |
| devananda | NobodyCam: and let's rename it while we're writing this -- what do you think of s/deploy/utility/ ? | 21:19 |
| NobodyCam | user??? that comes from nova no? | 21:19 |
| devananda | since that same ramdisk will also be used for other tasks, eg. raid, hd erase, etc, in time | 21:19 |
| devananda | NobodyCam: yes, but it has to get passed to the PXE driver some how. and it's passed at the same time as the deploy k&r, so PXE driver can build the tftp config | 21:20 |
| NobodyCam | so append user K,R,Image to driver in spawn (or there abouts) | 21:21 |
| NobodyCam | can we prefix the name like pxe_utility? | 21:21 |
| *** urulama has joined #openstack-ironic | 21:22 | |
| devananda | eh? | 21:23 |
| NobodyCam | ie we cannt pre pop the User info untill we get boot request from nova | 21:23 |
| devananda | you lost me | 21:23 |
| NobodyCam | I'm good with changing deploy to utility | 21:23 |
| NobodyCam | wanted to prefix with pxe_ but thats just me | 21:24 |
| NobodyCam | then around that | 21:24 |
| NobodyCam | i was asking about hte user K,R,Image | 21:24 |
| NobodyCam | which we dont have un we get the boot request from nova | 21:25 |
| NobodyCam | un=until | 21:25 |
| NobodyCam | utility K & R we will attach to the node befor deploy / spawn is issued | 21:27 |
| NobodyCam | so I was trying to work thru your comment devananda > NobodyCam: yea. so node.driver_info gets the 5 image bits. deploy k & r, user k & r, and user image. | 21:28 |
| devananda | ah | 21:29 |
| devananda | so yea, we'll have to set the utility k&r beforehand. then in nova.virt.ironic.driver.spawn() we'll extract the user k&r&i glance uuids and pass those to ironic | 21:30 |
| devananda | updating node.driver_info with them | 21:30 |
| devananda | NobodyCam: sound about right? | 21:30 |
| *** epim has quit IRC | 21:31 | |
| NobodyCam | will work, feels strange editing the driver_info field with deploy spicific info | 21:31 |
| *** urulama_ has joined #openstack-ironic | 21:32 | |
| NobodyCam | what about node.properties | 21:33 |
| *** urulama has quit IRC | 21:33 | |
| NobodyCam | we have provision_state | 21:33 |
| NobodyCam | maybe even add provision_image_id from which we could extract the correct K & R | 21:34 |
| NobodyCam | wounder if I could query to get that from the instance uuid | 21:35 |
| *** epim has joined #openstack-ironic | 21:35 | |
| openstackgerrit | A change was merged to openstack/ironic: Replace __metaclass__ https://review.openstack.org/54913 | 21:37 |
| devananda | NobodyCam: we probably could get that info from glance, given the nova instance uuid (we have it) | 21:41 |
| NobodyCam | ya | 21:41 |
| *** urulama_ has quit IRC | 21:42 | |
| *** urulama has joined #openstack-ironic | 21:42 | |
| *** urulama has quit IRC | 21:47 | |
| *** urulama has joined #openstack-ironic | 21:52 | |
| devananda | NobodyCam: it can also be pulled from the instance parameter of driver.spawn() | 21:54 |
| NobodyCam | :) | 21:55 |
| NobodyCam | getting there :-p | 21:55 |
| NobodyCam | hehehehe | 21:55 |
| *** urulama has quit IRC | 22:01 | |
| *** urulama has joined #openstack-ironic | 22:02 | |
| *** epim has quit IRC | 22:06 | |
| *** linggao has quit IRC | 22:08 | |
| *** urulama has quit IRC | 22:11 | |
| *** urulama has joined #openstack-ironic | 22:12 | |
| *** jbjohnso has quit IRC | 22:13 | |
| *** jdob has quit IRC | 22:19 | |
| *** urulama has quit IRC | 22:22 | |
| *** urulama_ has joined #openstack-ironic | 22:22 | |
| NobodyCam | devananda: that kinda what you had in mind? http://paste.openstack.org/show/uXklfrGonzIxgUTL3nzQ/ | 22:22 |
| *** urulama_ has quit IRC | 22:27 | |
| *** rloo has quit IRC | 22:28 | |
| *** rloo has joined #openstack-ironic | 22:28 | |
| *** urulama has joined #openstack-ironic | 22:31 | |
| * NobodyCam wanders afk ... bbiafm | 22:35 | |
| *** urulama has quit IRC | 22:41 | |
| *** urulama_ has joined #openstack-ironic | 22:41 | |
| devananda | NobodyCam: yep | 22:41 |
| devananda | rloo: patch is looking good :) | 22:42 |
| rloo | devananda: thx. Fingers crossed. ha ha. | 22:43 |
| NobodyCam | :) | 22:46 |
| *** urulama_ has quit IRC | 22:51 | |
| *** urulama has joined #openstack-ironic | 22:51 | |
| *** urulama has quit IRC | 22:56 | |
| *** urulama has joined #openstack-ironic | 23:01 | |
| *** michchap has quit IRC | 23:02 | |
| *** michchap has joined #openstack-ironic | 23:04 | |
| *** hemna is now known as hemnafk | 23:07 | |
| *** urulama_ has joined #openstack-ironic | 23:11 | |
| *** urulama has quit IRC | 23:11 | |
| *** urulama has joined #openstack-ironic | 23:21 | |
| *** urulama_ has quit IRC | 23:21 | |
| * devananda also wanders afk for a while | 23:27 | |
| NobodyCam | :) | 23:27 |
| NobodyCam | enjoy | 23:28 |
| *** urulama_ has joined #openstack-ironic | 23:31 | |
| *** urulama has quit IRC | 23:31 | |
| NobodyCam | rloo: you around? | 23:32 |
| *** urulama_ has quit IRC | 23:35 | |
| *** urulama has joined #openstack-ironic | 23:40 | |
| *** matsuhashi has joined #openstack-ironic | 23:47 | |
| *** urulama_ has joined #openstack-ironic | 23:50 | |
| *** urulama has quit IRC | 23:50 | |
| *** urulama_ has quit IRC | 23:59 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!