| *** naohirot has joined #openstack-ironic | 00:02 | |
| *** jcoufal has quit IRC | 00:02 | |
| *** smoriya has joined #openstack-ironic | 00:07 | |
| *** mjturek1 has quit IRC | 00:22 | |
| *** romcheg has quit IRC | 00:27 | |
| *** romcheg has joined #openstack-ironic | 00:29 | |
| *** jcoufal_ has quit IRC | 00:31 | |
| *** pegmatite has joined #openstack-ironic | 00:32 | |
| *** pegmatite has left #openstack-ironic | 00:34 | |
| naohirot | good morning ironic | 00:38 |
|---|---|---|
| NobodyCam | morning naohirot | 00:38 |
| mrda | hi naohirot (& NobodyCam) | 00:38 |
| naohirot | hi good evening NobodyCam :) | 00:38 |
| NobodyCam | oh hey howdy mrda | 00:39 |
| NobodyCam | :) | 00:39 |
| NobodyCam | how was the flight? | 00:39 |
| naohirot | good morning mrda :) | 00:39 |
| mrda | NobodyCam: Don't ask :) | 00:39 |
| mrda | Good to be home though | 00:39 |
| NobodyCam | :( | 00:39 |
| NobodyCam | yes!!! | 00:39 |
| mrda | Are you back home too NobodyCam, or are you still on the road? | 00:40 |
| NobodyCam | got back in lastnight at like 10:00 pm | 00:40 |
| mrda | oh wow | 00:41 |
| NobodyCam | :) | 00:41 |
| naohirot | NobodyCam: don't you live in bay area ? | 00:41 |
| NobodyCam | nope plam springs | 00:42 |
| NobodyCam | palm evem lol | 00:42 |
| naohirot | NobodyCam: I see, you are in the same city as | 00:44 |
| naohirot | NobodyCam: Ironicer I couldn't recall his name | 00:45 |
| jroll | BadCub maybe? :P | 00:45 |
| jroll | morning naohirot :) | 00:45 |
| naohirot | jroll: Yes, jroll | 00:45 |
| naohirot | jroll: good evening:) | 00:45 |
| naohirot | naohirot: I used to live in san jose :) | 00:46 |
| NobodyCam | :) | 00:47 |
| NobodyCam | they need to fix our official city webcam... it never a good shot .. lol .. ( http://www.ci.palm-springs.ca.us/index.aspx?page=100 ) | 00:48 |
| naohirot | NobodyCam: I really missed bay area. | 00:48 |
| NobodyCam | I thought LA was high density but it nothing like SF was this last week. | 00:50 |
| naohirot | NobodyCam: Is it sun set, right now? | 00:50 |
| NobodyCam | in about 45 minutes | 00:51 |
| NobodyCam | thats just that cam | 00:52 |
| NobodyCam | pics are always blue and out of focus | 00:52 |
| naohirot | NobodyCam: Yeah, it is still very bright | 00:53 |
| NobodyCam | :) | 00:53 |
| naohirot | NobodyCam: really spring is coming to palm Spring :) | 00:54 |
| openstackgerrit | Jarrod Johnson proposed stackforge/pyghmi: Fix needless retries due to misdirected packets https://review.openstack.org/156424 | 00:54 |
| NobodyCam | lol did you do the tram cam ... they've still got snow up there :) | 00:55 |
| naohirot | NobodyCam: No, I didn't, I wanted to visit, Is it a steam locomotion right? | 00:56 |
| naohirot | NobodyCam: s/locomotion/locomotive/ | 00:57 |
| openstackgerrit | Jarrod Johnson proposed stackforge/pyghmi: Fix needless retries due to misdirected packets https://review.openstack.org/156424 | 00:59 |
| NobodyCam | its a aerial tram : http://www.pstramway.com/history.html | 01:00 |
| naohirot | NobodyCam: I seems I mixed up Palm Spring and Colorado spring :) | 01:00 |
| NobodyCam | lol or like Durango to Silverton narrow gauge rail :) !!!! +1 to that | 01:01 |
| NobodyCam | http://www.carolglazerphotography.com/whats-new-2010b/bin/images/large/Durango_and_Silverton_Narrow_Gauge_Railroad_Train_1.jpg | 01:02 |
| jroll | colorado springs > palm springs | 01:02 |
| * jroll ducks | 01:02 | |
| openstackgerrit | Merged stackforge/pyghmi: Fix needless retries due to misdirected packets https://review.openstack.org/156424 | 01:03 |
| NobodyCam | :) | 01:04 |
| NobodyCam | you say Train.. I say Tram ... lol | 01:04 |
| naohirot | NobodyCam: Chino Canyon seems a part of Sierra Nevada, nice mountain area like Rocky Mountains :) | 01:05 |
| NobodyCam | :) its really nice. thou can be strange when its 100+ at street level and the top is still covered in snow | 01:07 |
| openstackgerrit | Shiina, Hironori proposed openstack/ironic: Fix typos in documentation: Capabilities https://review.openstack.org/156425 | 01:08 |
| *** romcheg has quit IRC | 01:11 | |
| naohirot | NobodyCam: when I visited Sequoia N.P. and Kings Canyon N.P., there were a lot of snow. | 01:12 |
| NobodyCam | :) | 01:13 |
| naohirot | NobodyCam: but I haven't visited Joshua Tree N.P. :) | 01:13 |
| * NobodyCam thinks snow is best viewed from a post card | 01:13 | |
| naohirot | NobodyCam: Yeah, I think so. :) | 01:15 |
| *** PaulCzar has joined #openstack-ironic | 01:20 | |
| NobodyCam | :) | 01:29 |
| *** zhenzanz has joined #openstack-ironic | 01:31 | |
| *** zhenzanz has quit IRC | 01:58 | |
| *** jjohnson2 has quit IRC | 01:59 | |
| openstackgerrit | Josh Gachnang proposed openstack/ironic: Implement Cleaning States https://review.openstack.org/153444 | 02:05 |
| naohirot | NobodyCam: jroll: I'm testing irmc driver with a bare metal which has 6 NICs, and I have a problem. | 02:09 |
| naohirot | NobodyCam: jroll: I can deploy user image by nova boot, but the bare metal doesn't respond to ping. | 02:11 |
| naohirot | NobodyCam: jroll: I'm wondering IP address is not assigned to the correct NIC. | 02:12 |
| naohirot | NobodyCam: jroll: Is Ironic support this http://docs.openstack.org/admin-guide-cloud/content/admin-password-injection.html ? | 02:12 |
| naohirot | NobodyCam: jroll: If I had root password of the instance, I can check the NICs. | 02:13 |
| naohirot | NobodyCam: jroll: the instance of the bare metal booted from pxe/tftp (pxe_irmc driver), so the network settings should be ok between conductor and the bare metal | 02:18 |
| naohirot | NobodyCam: jroll: But booted instance doesn't respond to ssh as well as ping | 02:19 |
| naohirot | NobodyCam: jroll: But I can access to "login prompt" of the instance thought iRMC virtual video console. | 02:21 |
| naohirot | s/thought/through/ | 02:21 |
| *** ramineni has joined #openstack-ironic | 02:40 | |
| *** lynxman has quit IRC | 02:57 | |
| *** lynxman has joined #openstack-ironic | 02:58 | |
| *** lynxman has joined #openstack-ironic | 02:58 | |
| *** yog__ has quit IRC | 03:04 | |
| jroll | naohirot: strange, I assume you're right about the IP being assigned to the wrong nic | 03:46 |
| *** achanda has joined #openstack-ironic | 03:56 | |
| *** Marga_ has quit IRC | 04:12 | |
| NobodyCam | JoshNang: I chatted with deva and jroll was correct with his comment about cleaned state | 04:14 |
| *** stendulker has joined #openstack-ironic | 04:14 | |
| jroll | do I win a prize | 04:14 |
| jroll | NobodyCam: is that the only new agenda item? | 04:15 |
| JoshNang | NobodyCam: as in, no deleted/cleaning states? | 04:15 |
| NobodyCam | jroll: I got noticeof change yesterday: https://wiki.openstack.org/w/index.php?title=Meetings/Ironic&diff=next&oldid=73308 | 04:16 |
| NobodyCam | as in current rev is correct | 04:16 |
| jroll | hmm | 04:17 |
| jroll | JoshNang: no *ed states | 04:17 |
| jroll | NobodyCam: I know some of these are old... | 04:17 |
| openstackgerrit | Yuiko Takada proposed stackforge/ironic-discoverd: Support i18n https://review.openstack.org/156104 | 04:17 |
| JoshNang | alright! | 04:17 |
| jroll | (rameshg87) Whether RAID configuration should have a separate RAIDInterface or should use ManagementInterface (https://review.openstack.org/#/c/135899/) Landed! (this topic is needed only if there are objections, or comments) | 04:17 |
| jroll | is old | 04:18 |
| jroll | (mjturek) Agenda item for the next IRC meeting (the one after 02/03) - Discuss the completeness of the installation guide, specifically in regards to neutron setup. | 04:18 |
| jroll | may be old? | 04:18 |
| *** yuikotakada has joined #openstack-ironic | 04:18 | |
| jroll | there's a dupe in there too about secure boot mode | 04:18 |
| jroll | screw it, we can roll through them and see what happens | 04:19 |
| *** Nisha has joined #openstack-ironic | 04:19 | |
| NobodyCam | I removed my item | 04:19 |
| NobodyCam | ya rameshg87's item can be removed it was added on 2/9 and mjturek's was added 2/2 | 04:23 |
| NobodyCam | so both of those are old | 04:23 |
| NobodyCam | ok that should be up to date now | 04:29 |
| NobodyCam | :) | 04:29 |
| *** coolsvap_ is now known as coolsvap | 04:31 | |
| *** Marga_ has joined #openstack-ironic | 04:36 | |
| *** jerryz has joined #openstack-ironic | 04:37 | |
| jroll | NobodyCam: thanks for removing those, I think the first and last items are the same but I guess we can wait and find out :) | 04:41 |
| *** rameshg87 has joined #openstack-ironic | 04:45 | |
| *** Nisha has quit IRC | 04:45 | |
| *** yog_ has joined #openstack-ironic | 04:47 | |
| *** deva__ has joined #openstack-ironic | 04:47 | |
| *** pensu has joined #openstack-ironic | 04:47 | |
| NobodyCam | added by different people :-p | 04:48 |
| ramineni | NobodyCam, jroll : they are different , proposed by https://review.openstack.org/#/c/129529/ and https://review.openstack.org/#/c/135845/ | 04:48 |
| naohirot | jroll: Hi | 04:49 |
| ramineni | NobodyCam, jroll : Two seperate management interfaces for both .. as both are different | 04:49 |
| naohirot | jroll: do you know if Ironic support password injection? http://docs.openstack.org/admin-guide-cloud/content/admin-password-injection.html | 04:49 |
| NobodyCam | oh I have a +2 on 135845 | 04:52 |
| deva__ | naohirot: no, we do not | 04:53 |
| jroll | ramineni: ok, thanks | 04:53 |
| NobodyCam | hey hey mr deva__ hope you are feeling better | 04:53 |
| jroll | naohirot: we should/do however support using configdrive to set an admin password | 04:54 |
| naohirot | deva__: thanks | 04:54 |
| *** deva__ has quit IRC | 04:54 | |
| rameshg87 | naohirot, since ironic supports configdrive, you can inject passwords with that | 04:54 |
| jroll | configdrive with cloud-init, that is | 04:54 |
| *** devanand_ has joined #openstack-ironic | 04:54 | |
| rameshg87 | naohirot, if you are using only ironic, use nocloud cloud-init datasource | 04:54 |
| NobodyCam | thats not really injection thou :-p | 04:54 |
| jroll | devanand_: don't come around here and get us sick :( | 04:54 |
| jroll | NobodyCam: right :P | 04:54 |
| jroll | theoretically you could run a rootkit, I mean, nova-agent :P | 04:54 |
| devanand_ | NobodyCam: hi! Had some food. Still out of it and not fully here | 04:54 |
| *** Marga_ has quit IRC | 04:55 | |
| * rameshg87 wonders how many devananda's are around :) | 04:55 | |
| *** Marga_ has joined #openstack-ironic | 04:55 | |
| NobodyCam | jroll: offered to run the meeting tonight (morning for some) | 04:55 |
| naohirot | rameshg87: I'm using an environment using devstack | 04:55 |
| devanand_ | Just two | 04:55 |
| jroll | uh oh | 04:55 |
| NobodyCam | lol | 04:56 |
| jroll | am I being thrown into this now? | 04:56 |
| * jroll puts down his beer | 04:56 | |
| naohirot | rameshg87: I'm using an environment created by devstack | 04:56 |
| rameshg87 | naohirot, yes you can use there too | 04:56 |
| NobodyCam | lol | 04:56 |
| naohirot | rameshg87: can I ask details after the meeting? | 04:56 |
| rameshg87 | naohirot, sure | 04:56 |
| naohirot | rameshg87: thanks! | 04:57 |
| naohirot | naohirot: I move to meeting3 | 04:57 |
| jroll | naohirot: afaik just add "--configdrive true" to your "nova boot" command and you will get a password | 04:57 |
| devanand_ | I'll lurk during the meeting, but if one ofvyou can run it that'd be rally helpful | 04:57 |
| jroll | naohirot: I think this is likely an environmental thing that can otherwise be fixed, though. maybe even an image thing | 04:57 |
| jroll | devanand_: yeah, we got this | 04:57 |
| devanand_ | Cheers | 04:57 |
| naohirot | jroll: Yeah, I need to check network environment too. | 04:58 |
| *** rameshg87_ has joined #openstack-ironic | 04:58 | |
| *** rameshg87_ has quit IRC | 04:58 | |
| *** Nisha has joined #openstack-ironic | 05:00 | |
| *** yog_ has quit IRC | 05:00 | |
| *** hshiina has joined #openstack-ironic | 05:02 | |
| *** coolsvap is now known as coolsvap_ | 05:02 | |
| *** pensu has quit IRC | 05:05 | |
| *** coolsvap_ is now known as coolsvap | 05:09 | |
| *** BadCub01_ has joined #openstack-ironic | 05:10 | |
| BadCub01_ | I did what? | 05:10 |
| mrda | Welcome to the cool kids club, BadCub01_ | 05:11 |
| BadCub01_ | Thanks! | 05:11 |
| mrda | it's now official in the meeting minutes :) | 05:11 |
| BadCub01_ | very cool :-) | 05:12 |
| *** BadCub01_ has quit IRC | 05:16 | |
| *** devlaps has quit IRC | 05:16 | |
| *** BadCub01_ has joined #openstack-ironic | 05:16 | |
| *** BadCub01_ has left #openstack-ironic | 05:17 | |
| *** BadCub01_ has joined #openstack-ironic | 05:20 | |
| openstackgerrit | Yuiko Takada proposed stackforge/ironic-discoverd: Support i18n part2 https://review.openstack.org/156115 | 05:21 |
| *** pradipta has joined #openstack-ironic | 05:22 | |
| *** faizan_ has joined #openstack-ironic | 05:26 | |
| *** jrist is now known as jrist-afk | 05:26 | |
| *** pensu has joined #openstack-ironic | 05:30 | |
| *** achanda has quit IRC | 05:43 | |
| *** achanda has joined #openstack-ironic | 05:46 | |
| *** pcaruana has quit IRC | 05:47 | |
| *** killer_prince is now known as lazy_prince | 05:48 | |
| *** davideagnello has quit IRC | 05:53 | |
| *** coolsvap is now known as coolsvap_ | 05:53 | |
| *** coolsvap_ is now known as coolsvap | 06:00 | |
| jroll | I see no reason why oslo-incubator would be an advantage | 06:00 |
| jroll | I guess is my main point | 06:01 |
| jroll | it has clear disadvantages | 06:01 |
| devanand_ | It's light weight | 06:01 |
| jroll | pip install is not? | 06:01 |
| devanand_ | Let's each consuming project choose when to pull changes in | 06:01 |
| *** wanyen has joined #openstack-ironic | 06:01 | |
| jroll | idk what you mean by lightweight | 06:01 |
| jroll | ... if openstack pinned dependencies in a remotely sane way, we could do that with any library | 06:02 |
| devanand_ | And doesn't require versioning, api backwards compatibility, etc | 06:02 |
| devanand_ | Right. But we don't. And were can't. | 06:02 |
| jroll | I explicitly want api compat | 06:02 |
| jroll | because we depend on that api | 06:02 |
| devanand_ | Pip is incapable of sanely pinning dependencies | 06:02 |
| jroll | for installing the world in one environment, yes | 06:02 |
| devanand_ | Oh. Containers | 06:03 |
| jroll | or virtualenvs | 06:03 |
| devanand_ | Right | 06:03 |
| jroll | something the rest of the python community has done for years | 06:03 |
| jroll | people do downstream | 06:03 |
| jroll | etc | 06:03 |
| devanand_ | Fair | 06:03 |
| jroll | idk, I've stated my opinion, I'm only going to get more upset about this | 06:03 |
| * jroll waits for someone to ask for a spec on this | 06:04 | |
| *** jcoufal has joined #openstack-ironic | 06:05 | |
| devanand_ | That's fine - new library it is then | 06:05 |
| faizan_ | jroll: can you please let me know what is the process for hosting this library? | 06:06 |
| jroll | there is a process, I don't know much about it, infra team would know more | 06:07 |
| jroll | faizan_: let me grab a link, we did the same recently with the ipa builder | 06:07 |
| jroll | faizan_: https://review.openstack.org/#/c/155868/ | 06:07 |
| NobodyCam | devanand_: I am going to add "devanand_ > That's fine - new library it is then" to the agenda so folks can see that | 06:08 |
| NobodyCam | ? | 06:08 |
| devanand_ | NobodyCam: I'll just comment on the review when it is posted | 06:09 |
| *** Marga_ has quit IRC | 06:09 | |
| NobodyCam | ack :) | 06:09 |
| Nisha | devanand_, link https://review.openstack.org/147857 for Add states for inspection, | 06:09 |
| jroll | oh right, I meant to ask about that | 06:10 |
| jroll | devanand_: you said earlier to burn all of the *ED states? | 06:10 |
| Nisha | it needs your review as there had been different views on it | 06:10 |
| *** faizan_ has quit IRC | 06:10 | |
| Nisha | jroll, :) | 06:10 |
| devanand_ | jroll: defer, not burn ... | 06:10 |
| jroll | right | 06:10 |
| devanand_ | So far no one seems to need them | 06:11 |
| Nisha | devanand_, what does no-op state do | 06:11 |
| devanand_ | But in theory they will be needed in the future | 06:11 |
| Nisha | means we transition from INSPECTING-> MANAGEABLE? | 06:11 |
| Nisha | or INSPECTING->INSPECTED and then INSPECTED-> MANAGEABLE | 06:11 |
| *** viktors has quit IRC | 06:12 | |
| devanand_ | I'll take a look | 06:13 |
| Nisha | devanand_, so i should go with below transitions ? i.e. INSPECTING->INSPECTED and then INSPECTED-> MANAGEABLE | 06:13 |
| Nisha | devanand_, thanks | 06:13 |
| devanand_ | Then I need to go back to bed. Still sick... | 06:13 |
| Nisha | devanand_, ok. | 06:14 |
| BadCub01_ | get some rest devanand_ | 06:14 |
| jroll | night deva | 06:14 |
| Nisha | good night devanand_ | 06:14 |
| Nisha | jroll, i had a question on api versioning thing. | 06:15 |
| NobodyCam | night devanand_ | 06:15 |
| jroll | Nisha: sure, but I need to go to bed soon too | 06:15 |
| jroll | past 10pm here | 06:15 |
| Nisha | jroll, :) | 06:15 |
| Nisha | in ironic/api/controllers/v1/node.py, we have a function as check_allow_management_verbs() | 06:16 |
| Nisha | that has a check for "pecan.request.version.minor < 4" | 06:16 |
| Nisha | how do get the version greater than 3? | 06:16 |
| openstackgerrit | OpenStack Proposal Bot proposed openstack/ironic: Imported Translations from Transifex https://review.openstack.org/155970 | 06:16 |
| jroll | Nisha: there's a header you can pass, X-OpenStack-Ironic-Version or something | 06:17 |
| Nisha | actually from cli this doesnt get parsed thru | 06:17 |
| jroll | Nisha: people are working on it for the cli https://review.openstack.org/#/c/155624/ | 06:17 |
| jroll | until then use curl I guess | 06:17 |
| * BadCub01_ is heading to bed. See everyone tomorrow! | 06:18 | |
| Nisha | ohk :) | 06:18 |
| Nisha | jroll, thanks | 06:18 |
| jroll | np | 06:18 |
| *** BadCub01_ has quit IRC | 06:18 | |
| Nisha | good night jroll | 06:19 |
| jroll | night | 06:19 |
| Nisha | its morniing here :) | 06:19 |
| devanand_ | Nisha: this isn't necessary | 06:19 |
| devanand_ | machine.add_transition(INSPECTING, INSPECTED, 'inspect') | 06:19 |
| Nisha | devanand_, so you means we transit from INSPECTIG-> MANAGEABLE? | 06:20 |
| devanand_ | See line 1777 of https://review.openstack.org/#/c/149823/16/ironic/conductor/manager.py,cm | 06:20 |
| devanand_ | How there are two state transitions there | 06:20 |
| Nisha | devanand_, yes | 06:20 |
| devanand_ | Oh. So that's the no-op | 06:21 |
| Nisha | so i was actually updatin the last_inspected field during first transition | 06:21 |
| devanand_ | Yup. And I'd there was a call back, the first one would call it | 06:21 |
| devanand_ | But these are still both driven by the same event | 06:22 |
| devanand_ | The driver returning INSPECTED | 06:22 |
| Nisha | devanand_, do u mean same verb? | 06:22 |
| Nisha | driver returns just the state, it is not set by driver in this case | 06:23 |
| devanand_ | Right. I'd actually like to replace this sort of flow, where a driver returns a state | 06:23 |
| devanand_ | I did that for all the other states already | 06:23 |
| Nisha | it is set when driver returns to conductor and calls event('inspect') where it updates the state and last_inspected field | 06:24 |
| Nisha | devanand_, ok | 06:24 |
| devanand_ | And stated using event based call backs | 06:24 |
| *** yog__ has joined #openstack-ironic | 06:24 | |
| devanand_ | Nisha: I should review this when in more awake | 06:25 |
| Nisha | devanand_, yes, | 06:25 |
| devanand_ | It looks good, I think | 06:25 |
| Nisha | look at patch set 15 | 06:25 |
| Nisha | also | 06:25 |
| Nisha | of generic inspection | 06:25 |
| Nisha | in that driver doesnt return anything to conductor | 06:25 |
| Nisha | devanand_, actually only this is mainly holding inspection code | 06:26 |
| Nisha | :) | 06:26 |
| devanand_ | But not now. Right now, I need to rest. Will look tomorrow | 06:27 |
| Nisha | devanand_, yes | 06:27 |
| Nisha | agree | 06:28 |
| Nisha | :).... | 06:28 |
| devanand_ | Good night :) | 06:28 |
| Nisha | good night devanand_ | 06:28 |
| *** devanand_ has quit IRC | 06:28 | |
| naohirot | devanand_: jroll: good night | 06:28 |
| naohirot | rameshg87: do you have time? | 06:29 |
| naohirot | rameshg87: I'm reading http://docs.openstack.org/user-guide/content/enable_config_drive.html | 06:29 |
| Nisha | naohirot, rameshg87 is in meeting in office | 06:30 |
| Nisha | he will ping u once back | 06:31 |
| naohirot | Nisha: Hi, okay thinks | 06:31 |
| naohirot | Nisha: s/thinks/thanks/ | 06:31 |
| Nisha | naohirot, :) | 06:31 |
| naohirot | Nisha: :) | 06:31 |
| *** jerryz has quit IRC | 06:59 | |
| *** yuriyz has quit IRC | 07:07 | |
| openstackgerrit | Yuiko Takada proposed stackforge/ironic-discoverd: Support i18n part2 https://review.openstack.org/156115 | 07:14 |
| *** dlpartain has joined #openstack-ironic | 07:15 | |
| *** dlpartain has left #openstack-ironic | 07:15 | |
| *** ukalifon1 has joined #openstack-ironic | 07:17 | |
| *** yog__ has quit IRC | 07:24 | |
| *** yog__ has joined #openstack-ironic | 07:24 | |
| *** gridinv has joined #openstack-ironic | 07:29 | |
| *** hshiina has quit IRC | 07:33 | |
| *** gridinv has quit IRC | 07:43 | |
| *** achanda has quit IRC | 07:47 | |
| *** mkerrin has joined #openstack-ironic | 07:54 | |
| *** achanda has joined #openstack-ironic | 07:54 | |
| *** Nisha has quit IRC | 08:03 | |
| *** andreykurilin_ has joined #openstack-ironic | 08:05 | |
| *** chlong has quit IRC | 08:11 | |
| *** ifarkas has joined #openstack-ironic | 08:11 | |
| *** gridinv has joined #openstack-ironic | 08:20 | |
| *** achanda has quit IRC | 08:20 | |
| *** dtantsur|afk is now known as dtantsur | 08:23 | |
| *** achanda has joined #openstack-ironic | 08:24 | |
| *** achanda has quit IRC | 08:30 | |
| *** achanda has joined #openstack-ironic | 08:37 | |
| *** wanyen has quit IRC | 08:41 | |
| openstackgerrit | Anusha Ramineni proposed stackforge/proliantutils: Update ris module to be consistent with operations https://review.openstack.org/156506 | 08:42 |
| *** Nisha has joined #openstack-ironic | 08:43 | |
| *** achanda has quit IRC | 08:47 | |
| *** bauwser is now known as bauzas | 08:47 | |
| *** pensu has quit IRC | 08:50 | |
| *** yuriyz has joined #openstack-ironic | 08:50 | |
| *** jistr has joined #openstack-ironic | 08:51 | |
| *** viktors has joined #openstack-ironic | 08:52 | |
| *** yuikotakada has quit IRC | 08:53 | |
| *** mkerrin has quit IRC | 08:53 | |
| *** yuriyz has quit IRC | 08:55 | |
| *** jerryz has joined #openstack-ironic | 08:57 | |
| openstackgerrit | Ryan Moore proposed openstack/ironic: Don't write PXE config file during takeover https://review.openstack.org/156250 | 08:58 |
| *** pas-ha has joined #openstack-ironic | 08:59 | |
| *** yuriyz has joined #openstack-ironic | 09:07 | |
| *** lucasagomes has joined #openstack-ironic | 09:09 | |
| openstackgerrit | Merged stackforge/ironic-discoverd: Support i18n https://review.openstack.org/156104 | 09:16 |
| openstackgerrit | Merged stackforge/ironic-discoverd: Functional test for setting IPMI credentials https://review.openstack.org/142823 | 09:17 |
| *** pensu has joined #openstack-ironic | 09:19 | |
| openstackgerrit | Merged stackforge/ironic-discoverd: Don't wait for too long for IPMI credentials update https://review.openstack.org/156144 | 09:20 |
| openstackgerrit | Dmitry Tantsur proposed stackforge/ironic-discoverd: Fix i18n import https://review.openstack.org/156513 | 09:20 |
| openstackgerrit | Merged stackforge/ironic-discoverd: Also set IPMI address if it's not set already https://review.openstack.org/156156 | 09:21 |
| openstackgerrit | Ryan Moore proposed openstack/ironic: Don't write PXE config file during takeover https://review.openstack.org/156250 | 09:23 |
| *** romcheg has joined #openstack-ironic | 09:28 | |
| *** romcheg has quit IRC | 09:29 | |
| openstackgerrit | Merged stackforge/ironic-discoverd: Fix i18n import https://review.openstack.org/156513 | 09:30 |
| openstackgerrit | Dmitry Tantsur proposed stackforge/ironic-discoverd: Support i18n part2 https://review.openstack.org/156115 | 09:32 |
| *** athomas has joined #openstack-ironic | 09:32 | |
| *** Nisha has quit IRC | 09:35 | |
| *** vdrok_afk is now known as vdrok | 09:36 | |
| rameshg87 | naohirot, hi | 09:41 |
| naohirot | rameshg87: hi | 09:41 |
| rameshg87 | naohirot, do you any questions still left for me ? :) | 09:42 |
| naohirot | rameshg87: I roughly understood what is configdrive, I think. | 09:42 |
| rameshg87 | naohirot, okay :) | 09:42 |
| rameshg87 | naohirot, do you test with nova or ironic alone ? | 09:42 |
| naohirot | rameshg87: then how do I know what kind of metadata alow me to login with plain password? | 09:42 |
| rameshg87 | naohirot, i am not sure about nova config drives | 09:43 |
| naohirot | rameshg87: no, I'm using all of services. | 09:43 |
| rameshg87 | naohirot, but config drive can have user scripts which can have cloud-config | 09:43 |
| naohirot | rameshg87: nova, keystone, neutron, etc | 09:43 |
| rameshg87 | naohirot, i use only ironic most of the time (i mean i test my deployments triggering them through ironic command-line) | 09:44 |
| rameshg87 | naohirot, i use nocloud data source | 09:44 |
| naohirot | rameshg87: what is cloud-config? | 09:44 |
| *** romcheg has joined #openstack-ironic | 09:45 | |
| rameshg87 | naohirot, https://help.ubuntu.com/community/UEC/Images#Ubuntu_Cloud_Guest_images_on_12.04_LTS_.28Precise.29_and_beyond_using_NoCloud | 09:45 |
| rameshg87 | naohirot, i use this | 09:45 |
| rameshg87 | naohirot, just generate the configdrive using cloud-localds | 09:46 |
| rameshg87 | naohirot, gzip it and base64 encode it | 09:46 |
| rameshg87 | naohirot, provide it in instance_info['configdrive'] | 09:46 |
| rameshg87 | naohirot, as i said i always trigger deployments from ironic (not from nova) | 09:47 |
| rameshg87 | naohirot, from nova --configdrive should be a better alternative (as jroll said) | 09:47 |
| naohirot | rameshg87: I'm okay to use nova --configdrive, but I haven't understood what kind of data I should pass. | 09:49 |
| naohirot | rameshg87: my understanding of configdrive is a way to pass some data to instance, right? | 09:50 |
| rameshg87 | naohirot, http://docs.openstack.org/user-guide/content/inserting_userdata.html | 09:50 |
| rameshg87 | naohirot, you can use --user-data | 09:50 |
| naohirot | rameshg87: my question is that passing what kind of data allow me to login ubuntu with plain password | 09:51 |
| rameshg87 | naohirot, somethign like this: http://paste.openstack.org/show/175893/ | 09:52 |
| rameshg87 | naohirot, you can pass this as --user-data | 09:52 |
| rameshg87 | naohirot, it will allow you to login with 'passw0rd' on cloud images running cloud-init | 09:52 |
| naohirot | rameshg87: Okay, it seems everything is described in https://help.ubuntu.com/community/UEC/Images#Ubuntu_Cloud_Guest_images_on_12.04_LTS_.28Precise.29_and_beyond_using_NoCloud | 09:55 |
| naohirot | rameshg87: I'll take a look, thanks! | 09:55 |
| naohirot | rameshg87: my network will be disconnected at 19:00 Oclock here. | 09:56 |
| naohirot | rameshg87: I'll ask you if I further question | 09:57 |
| rameshg87 | naohirot, sure ... | 09:58 |
| rameshg87 | lucasagomes, hi | 10:00 |
| *** arif-ali has joined #openstack-ironic | 10:00 | |
| *** jerryz has quit IRC | 10:03 | |
| viktors | dtantsur: hi! | 10:07 |
| dtantsur | o/ | 10:08 |
| lucasagomes | rameshg87, pong | 10:09 |
| lucasagomes | rameshg87, just reviewed the raid spec | 10:10 |
| viktors | dtantsur: I have a question as for py3 testing in Ironic - should we use py33 or py34 for it? | 10:10 |
| viktors | I see py34 only in openstack-infra/project-config | 10:10 |
| dtantsur | viktors, IIRC infra switched to py34 | 10:10 |
| *** pelix has joined #openstack-ironic | 10:10 | |
| viktors | yes, so should we use py34 only for Ironic? | 10:11 |
| rameshg87 | lucasagomes, oh thanks .. :) | 10:11 |
| rameshg87 | lucasagomes, actually i pinged for a different reason .. :) | 10:12 |
| lucasagomes | rameshg87, sure | 10:12 |
| rameshg87 | lucasagomes, the localboot changes, it's hard to figure out if bootloader got successfully installed or not | 10:12 |
| rameshg87 | lucasagomes, ironic already sets the node to active state, and doesn't know if it failed | 10:12 |
| rameshg87 | lucasagomes, am i correct ? | 10:12 |
| rameshg87 | lucasagomes, have some thoughts ? | 10:13 |
| rameshg87 | lucasagomes, i think ramdisk should inform back ironic after a successfuly bootloader installation (it's easy to figure out if it happened successfully or not) | 10:13 |
| lucasagomes | rameshg87, yes :( that's why I want IPA to be the default ramdisk so I can have better control over it | 10:13 |
| lucasagomes | I can pool the status and check whether it really succeed | 10:13 |
| rameshg87 | lucasagomes, oh so it's in plan ? | 10:13 |
| lucasagomes | now, on the previous ramdisk... we could have a new endpoint | 10:14 |
| rameshg87 | lucasagomes, yeah i felt so .. | 10:14 |
| lucasagomes | to basically say like /deploy_is_done | 10:14 |
| rameshg87 | lucasagomes, how about a vendor passthru for just communicating this | 10:14 |
| lucasagomes | which would give Ironic the control over the node again and it can reboot from there | 10:14 |
| lucasagomes | rameshg87, yeah it could be too | 10:14 |
| rameshg87 | lucasagomes, and then ironic go and turn the node to active | 10:14 |
| lucasagomes | rameshg87, yeah | 10:14 |
| lucasagomes | that also works | 10:14 |
| rameshg87 | lucasagomes, shall i just file a bug for development on pxe ramdisk ? | 10:15 |
| lucasagomes | rameshg87, please do | 10:15 |
| rameshg87 | lucasagomes, i think i can pursue this after i am done with localboot changes for iscsi_ilo drive | 10:15 |
| rameshg87 | *driver | 10:15 |
| lucasagomes | it shouldn't be hard to fix, using /continue_deploy and /deploy_is_done should do the work | 10:15 |
| rameshg87 | yeah | 10:15 |
| lucasagomes | rameshg87, cool | 10:15 |
| lucasagomes | thanks for that | 10:15 |
| rameshg87 | thanks :) | 10:15 |
| viktors | dtantsur: so I suppose to add env for py33 and py34. Should I add them both to default test envlist? | 10:16 |
| rameshg87 | lucasagomes, one more question | 10:16 |
| lucasagomes | sure | 10:16 |
| dtantsur | viktors, honestly I don't know... this should be discussed more widely | 10:16 |
| rameshg87 | lucasagomes, is there some way i can get grub installed on dib ramdisk when it is built | 10:16 |
| rameshg87 | lucasagomes, now i just mounted qemu image and install grub-pc on it | 10:17 |
| *** stendulker has quit IRC | 10:17 | |
| viktors | dtantsur: ok, thanks anyway | 10:17 |
| rameshg87 | lucasagomes, i assume it's still not supported in grub | 10:17 |
| rameshg87 | i mean in dib | 10:17 |
| * viktors went fix tests for py34 | 10:17 | |
| lucasagomes | rameshg87, it seems possible yes /me thinking | 10:17 |
| lucasagomes | I think you could pass some param to install grub in a given directory which is a os fs | 10:18 |
| lucasagomes | alternatively it's also possible to use extlinux | 10:18 |
| lucasagomes | which is wayeasier to work with | 10:18 |
| lucasagomes | just need to copy the boot loader code to the MBR to the begin of the disk | 10:18 |
| viktors | by the way, is there anybody familiar with Infra project-config ? | 10:18 |
| lucasagomes | and generate the config file for the partiton (you already have the root UUID and all) | 10:19 |
| rameshg87 | lucasagomes, i meant fs image with grub installed | 10:19 |
| dtantsur | viktors, #openstack-infra? :) I did some hacking for stackforge/ironic-discoverd, but I'm not a guru | 10:19 |
| rameshg87 | lucasagomes, if i do "disk-image-create ubuntu baremetal", the cloud image that is created doesn't have grub installed | 10:20 |
| rameshg87 | lucasagomes, so the ramdisk is not able to find /usr/sbin/grub-install on the install image | 10:20 |
| viktors | dtantsur: can you please check, that I don't break anything by this one - https://review.openstack.org/#/c/156530 ? | 10:20 |
| lucasagomes | rameshg87, ohh... hmmm it should be like installing any other package in the image right? | 10:21 |
| * lucasagomes thinks | 10:21 | |
| dtantsur | viktors, lgtm | 10:21 |
| viktors | dtantsur: thanks | 10:21 |
| rameshg87 | lucasagomes, yes, for ubuntu it's grub-pc | 10:21 |
| rameshg87 | lucasagomes, i just mounted the image using qemu-nbd, chrooted to it and installed using apt-get | 10:22 |
| rameshg87 | lucasagomes, i think dib should do this | 10:22 |
| lucasagomes | rameshg87, yeah it should | 10:22 |
| rameshg87 | lucasagomes, btw did you test with fedora cloud image ? does it have grub in it ? | 10:22 |
| lucasagomes | rameshg87, I will check with some rh people, because we do have a element that install grub afaik | 10:23 |
| lucasagomes | rameshg87, yeah, but I did the same as you. And then some people that works on tripleo created the proper element | 10:23 |
| lucasagomes | for the image we use | 10:23 |
| lucasagomes | and that installs grub and all | 10:23 |
| lucasagomes | afaict | 10:23 |
| rameshg87 | lucasagomes, okay | 10:24 |
| lucasagomes | rameshg87, if you just add a script to the install.d that install grub2 does it work? | 10:25 |
| rameshg87 | lucasagomes, yes i think it should | 10:26 |
| rameshg87 | lucasagomes, may be as part of ubuntu element itself ? | 10:26 |
| rameshg87 | lucasagomes, https://github.com/openstack/diskimage-builder/tree/master/elements/ubuntu ? | 10:27 |
| lucasagomes | yeah or a diff element, not sure they want to include grub in all images | 10:27 |
| *** Nisha has joined #openstack-ironic | 10:30 | |
| *** leopoldj has joined #openstack-ironic | 10:32 | |
| *** athomas has quit IRC | 10:35 | |
| *** PaulCzar has quit IRC | 10:37 | |
| openstackgerrit | Vladyslav Drok proposed openstack/ironic: Support for non-Glance image references https://review.openstack.org/136741 | 10:38 |
| *** leopoldj has quit IRC | 10:38 | |
| *** athomas has joined #openstack-ironic | 10:39 | |
| rameshg87 | lucasagomes, did you test your change on 64-bit hardware ? baremetal or vm ? | 10:53 |
| rameshg87 | lucasagomes, i see bootloader being installed when ramdisk calls /usr/sbin/grub-install | 10:53 |
| lucasagomes | rameshg87, the DIB change? | 10:53 |
| lucasagomes | I tested on VM only, dtantsur did you test on baremetal? | 10:53 |
| rameshg87 | lucasagomes, when i do hexdump on first sector i can see grub bootlodare there | 10:53 |
| rameshg87 | lucasagomes, but bare metal is not booting from disk :( | 10:54 |
| lucasagomes | rameshg87, hmmmm, I can def take a look at the ramdisk | 10:54 |
| dtantsur | lucasagomes, what exactly? | 10:54 |
| lucasagomes | rameshg87, what is the error | 10:54 |
| lucasagomes | dtantsur, local boot | 10:54 |
| * dtantsur is sick and barely catches up | 10:54 | |
| rameshg87 | lucasagomes, no error | 10:54 |
| rameshg87 | lucasagomes, grub installed successfully | 10:55 |
| dtantsur | lucasagomes, IIRC I did | 10:55 |
| rameshg87 | lucasagomes, hexdump shows grub is installed | 10:55 |
| lucasagomes | rameshg87, it tries to boot and fail? or just say can't boot from device | 10:55 |
| lucasagomes | dtantsur, right thanks | 10:55 |
| rameshg87 | lucasagomes, i dropped to a shell just before rebooting | 10:55 |
| rameshg87 | lucasagomes, i can see grub in first sectore | 10:55 |
| rameshg87 | lucasagomes, it says invalid disk | 10:55 |
| rameshg87 | lucasagomes, when bios tries to boot from it | 10:55 |
| openstackgerrit | Merged openstack/ironic: Fix file permissions in project https://review.openstack.org/156305 | 10:57 |
| openstackgerrit | Merged openstack/ironic: Fix file permissions in project https://review.openstack.org/156305 | 10:57 |
| *** foexle has joined #openstack-ironic | 10:57 | |
| lucasagomes | rameshg87, I see hmm | 10:58 |
| * lucasagomes thinking now | 10:58 | |
| lucasagomes | rameshg87, you end up in the grub shell right? can you try to boot from there? | 10:59 |
| lucasagomes | http://www.chrissearle.org/2008/08/13/Booting_from_grub_shell/ | 10:59 |
| rameshg87 | lucasagomes, no i don't end up in grub-shell | 10:59 |
| rameshg87 | lucasagomes, after installing grub, baremetal reboots | 10:59 |
| rameshg87 | lucasagomes, and when bios attempts to boot from disk, it says can't boot from disk | 11:00 |
| *** jcoufal_ has joined #openstack-ironic | 11:00 | |
| rameshg87 | lucasagomes, wondering if something to do with 32 bit vs 64 bit | 11:00 |
| rameshg87 | lucasagomes, but 32-bit grub should work on 64-bit machine | 11:00 |
| lucasagomes | rameshg87, I see, indeed | 11:00 |
| lucasagomes | yeah the grub install my look at the host image which it's booted and install the bootloader according to it | 11:01 |
| *** jcoufal has quit IRC | 11:03 | |
| *** ramineni has quit IRC | 11:04 | |
| *** lxsli has joined #openstack-ironic | 11:09 | |
| *** lxsli has left #openstack-ironic | 11:09 | |
| rameshg87 | lucasagomes, got the issue | 11:31 |
| rameshg87 | lucasagomes, we have to mark the partition as active | 11:31 |
| lucasagomes | rameshg87, oh | 11:31 |
| rameshg87 | lucasagomes, don't know but seems like some bios has this issue | 11:31 |
| lucasagomes | is it something we can do via ironic interface? | 11:32 |
| lucasagomes | perhaps as part of the set_boot_device thing? | 11:32 |
| rameshg87 | lucasagomes, won't boot unless some partition is marked as active in the partition table | 11:32 |
| rameshg87 | lucasagomes, we have to do it in partition table | 11:32 |
| rameshg87 | lucasagomes, may be parted can do it i guess | 11:32 |
| lucasagomes | rameshg87, +1 indeed, true... | 11:33 |
| lucasagomes | as part of parted we should indicate it indeed | 11:33 |
| rameshg87 | lucasagomes, for now from the installed image, i just went into fdisk and did 'a' on root partition | 11:34 |
| rameshg87 | lucasagomes, that marked partition as active | 11:34 |
| rameshg87 | lucasagomes, and then it started booting | 11:34 |
| rameshg87 | lucasagomes, http://www.gnu.org/software/parted/manual/parted.html | 11:34 |
| lucasagomes | def add_partition(self, size, part_type='primary', fs_type='', | 11:34 |
| lucasagomes | bootable=False): | 11:34 |
| lucasagomes | we can pass it in Ironic already | 11:34 |
| rameshg87 | lucasagomes, oh | 11:34 |
| lucasagomes | but I think I'm not passing it when formating the disk | 11:35 |
| lucasagomes | we may have everything we need tho, we know it's local boot so we should add the root partition as bootable | 11:35 |
| lucasagomes | rameshg87, I will put a patch up for that soonish if u want | 11:35 |
| lucasagomes | or if u want to go ahead and do it no problem too | 11:35 |
| rameshg87 | lucasagomes, i am leaving for home right now, i will be back in a few hours | 11:36 |
| rameshg87 | lucasagomes, if you are not doing that by that time, i will pick it up | 11:36 |
| lucasagomes | rameshg87, right, I'm just finishing adding some tests to IPA | 11:36 |
| rameshg87 | lucasagomes, okay | 11:36 |
| lucasagomes | if I finish soon I do it, otherwise u can pick it | 11:36 |
| lucasagomes | yeah | 11:36 |
| lucasagomes | thanks rameshg87 ! | 11:36 |
| rameshg87 | thanks :) | 11:36 |
| rameshg87 | bye | 11:36 |
| *** rameshg87 has quit IRC | 11:36 | |
| *** smoriya has quit IRC | 11:43 | |
| openstackgerrit | Pavlo Shchelokovskyy proposed openstack/ironic: Remove docs in proprietary formats https://review.openstack.org/156554 | 11:46 |
| *** andreykurilin_ has quit IRC | 11:57 | |
| *** andreykurilin__ has joined #openstack-ironic | 11:57 | |
| openstackgerrit | Lucas Alvares Gomes proposed openstack/ironic-python-agent: Add iscsi extension https://review.openstack.org/155727 | 11:59 |
| openstackgerrit | Sirushti Murugesan proposed openstack/ironic: Adds support for deploying whole disk images https://review.openstack.org/150142 | 12:04 |
| openstackgerrit | Dmitry Tantsur proposed openstack/ironic: WIP: add module for in-band inspection using ironic-discoverd https://review.openstack.org/156562 | 12:09 |
| *** BertieFulton has joined #openstack-ironic | 12:10 | |
| openstackgerrit | Lucas Alvares Gomes proposed openstack/ironic: Vendorpassthru doesn't get correct 'self' https://review.openstack.org/156244 | 12:22 |
| lucasagomes | added tests to ^ | 12:22 |
| *** dprince has joined #openstack-ironic | 12:25 | |
| *** lucasagomes is now known as lucas-hungry | 12:28 | |
| openstackgerrit | Yuiko Takada proposed stackforge/ironic-discoverd: Support i18n part3 https://review.openstack.org/156119 | 12:38 |
| *** antonym has quit IRC | 12:43 | |
| *** pradipta has quit IRC | 12:49 | |
| *** jjohnson2 has joined #openstack-ironic | 12:49 | |
| openstackgerrit | Naohiro Tamura proposed openstack/ironic: Fix ml2_conf.ini settings https://review.openstack.org/156092 | 12:54 |
| *** antonym has joined #openstack-ironic | 12:58 | |
| *** yuikotkada has joined #openstack-ironic | 13:00 | |
| *** pas-ha has quit IRC | 13:00 | |
| *** Nisha has quit IRC | 13:00 | |
| *** athomas has quit IRC | 13:01 | |
| *** pas-ha has joined #openstack-ironic | 13:01 | |
| openstackgerrit | Yuiko Takada proposed stackforge/ironic-discoverd: Support i18n part3 https://review.openstack.org/156119 | 13:01 |
| openstackgerrit | Naohiro Tamura proposed openstack/ironic: Add iRMC Management module for iRMC Driver https://review.openstack.org/146803 | 13:01 |
| *** athomas has joined #openstack-ironic | 13:06 | |
| *** rameshg87 has joined #openstack-ironic | 13:13 | |
| rameshg87 | is there some issue with sshing to review.openstack.org ? | 13:15 |
| rameshg87 | i can access review.openstack.org through web, but not able to raise review | 13:15 |
| *** martini has joined #openstack-ironic | 13:17 | |
| gilliard | rameshg87: I've just been able to pull a patch over ssh. It did take a minute or so though... | 13:18 |
| rameshg87 | gilliard, thanks .. will wait for a few mins and see | 13:19 |
| *** athomas has quit IRC | 13:22 | |
| *** Marga_ has joined #openstack-ironic | 13:22 | |
| *** pas-ha has quit IRC | 13:27 | |
| *** athomas has joined #openstack-ironic | 13:28 | |
| *** pensu has quit IRC | 13:28 | |
| openstackgerrit | Ramakrishnan G proposed openstack/ironic: Add driver interface for RAID configuration https://review.openstack.org/155230 | 13:28 |
| gilliard | rameshg87: you got it, then? | 13:29 |
| rameshg87 | gilliard, yeah just got it back working :) | 13:29 |
| openstackgerrit | Naohiro Tamura proposed openstack/ironic: Add iRMC Virtual Media Deploy module for iRMC Driver https://review.openstack.org/151958 | 13:29 |
| *** lucas-hungry is now known as lucasagomes | 13:29 | |
| *** pas-ha has joined #openstack-ironic | 13:42 | |
| openstackgerrit | Lucas Alvares Gomes proposed openstack/ironic: Add AgentVendorPasshtru for the PXE driver https://review.openstack.org/155728 | 13:43 |
| *** yog__ has quit IRC | 13:43 | |
| *** Marga_ has quit IRC | 13:44 | |
| *** pensu has joined #openstack-ironic | 13:45 | |
| openstackgerrit | Ramakrishnan G proposed openstack/ironic: Root partition should be marked as bootable https://review.openstack.org/156587 | 13:46 |
| *** Nisha has joined #openstack-ironic | 13:47 | |
| *** HenryG has quit IRC | 13:49 | |
| *** HenryG has joined #openstack-ironic | 13:52 | |
| *** rloo has joined #openstack-ironic | 13:53 | |
| rameshg87 | lucasagomes, hi | 13:56 |
| lucasagomes | rameshg87, hi there | 13:56 |
| *** dprince has quit IRC | 13:56 | |
| rameshg87 | lucasagomes, https://review.openstack.org/#/c/156244/2/ironic/tests/drivers/test_base.py | 13:56 |
| lucasagomes | rameshg87, yeah, making sure the references are different | 13:57 |
| rameshg87 | lucasagomes, i am still wondering instantiating twice is the real culprit of the problem | 13:57 |
| lucasagomes | rameshg87, why? | 13:57 |
| lucasagomes | (if you remove ur change on base.py, you'll see those tests failing) | 13:57 |
| rameshg87 | lucasagomes, i agree tests will fail | 13:58 |
| rameshg87 | lucasagomes, but is that the real problem ? | 13:58 |
| lucasagomes | rameshg87, with the inheritance you mean? | 13:58 |
| lucasagomes | the problem was that we were passing the same dictionary reference across all instances | 13:58 |
| rameshg87 | lucasagomes, yeah | 13:58 |
| lucasagomes | inherited or not, so all the references would be pointing to 'func' of the last instantiate object | 13:59 |
| rameshg87 | lucasagomes, but the actual problem was that 'func' in all those instances were wrong, right ? | 13:59 |
| lucasagomes | that's the problem I see, not sure if there's more hidden stuff there | 13:59 |
| lucasagomes | rameshg87, they all were pointing to the last instantiate object func | 13:59 |
| rameshg87 | lucasagomes, but if i look at code | 14:00 |
| lucasagomes | because that's the last modification to the dictionary (which was being referencied across all instances) | 14:00 |
| rameshg87 | lucasagomes, we create a new instance everytime here: https://github.com/openstack/ironic/blob/master/ironic/drivers/base.py#L446 | 14:00 |
| rameshg87 | lucasagomes, right ? | 14:00 |
| *** stendulker has joined #openstack-ironic | 14:00 | |
| lucasagomes | rameshg87, yes | 14:01 |
| lucasagomes | but the decorators add _vendor_routes and _driver_routes | 14:01 |
| lucasagomes | in the class, before instantialization | 14:01 |
| lucasagomes | so it's the same for all instances | 14:01 |
| *** stendulker_ has joined #openstack-ironic | 14:02 | |
| *** trown|outttypeww is now known as trown | 14:02 | |
| *** Guest90435 has joined #openstack-ironic | 14:02 | |
| rameshg87 | lucasagomes, but each instance had it's own vendor route, right ? | 14:02 |
| *** Guest90435 is now known as annegentle | 14:02 | |
| rameshg87 | lucasagomes, and we did inspect each instance to get the methods: https://github.com/openstack/ironic/blob/master/ironic/drivers/base.py#L451 | 14:03 |
| rameshg87 | lucasagomes, i mean we inspected the actual child classes | 14:03 |
| lucasagomes | rameshg87, yeah, the _vendor_routes are pretty much the same across all isntances... but on __new__ we make each instance to have it's own vendor_routes (no _ prefixed) pointing to the functions in that instance | 14:04 |
| *** stendulker has quit IRC | 14:05 | |
| lucasagomes | rameshg87, I'm happy to add more tests re inheritance too | 14:05 |
| rameshg87 | lucasagomes, but where is _vendor_routes ? :) | 14:05 |
| rameshg87 | i am not able to find them .. | 14:05 |
| lucasagomes | rameshg87, https://github.com/openstack/ironic/blob/master/ironic/drivers/base.py#L404 | 14:06 |
| lucasagomes | _vendor_metadata sorry | 14:06 |
| lucasagomes | it's added as a attribute to the function definition in the class | 14:06 |
| rameshg87 | lucasagomes, but func is a bound method, right ? | 14:07 |
| lucasagomes | rameshg87, yes, and you can add attributes to it | 14:07 |
| *** mjturek1 has joined #openstack-ironic | 14:07 | |
| lucasagomes | In [1]: def func(): | 14:07 |
| lucasagomes | ...: pass | 14:07 |
| lucasagomes | ...: | 14:07 |
| lucasagomes | In [2]: func._test = "aaaaaaaa" | 14:07 |
| lucasagomes | In [3]: func._test | 14:07 |
| rameshg87 | lucasagomes, so since func is a bound method, wouldn't it be different for each instances ? | 14:07 |
| lucasagomes | Out[3]: 'aaaaaaaa' | 14:07 |
| lucasagomes | rameshg87, we add it in the decorator, so it's before instantiation | 14:08 |
| rameshg87 | lucasagomes, hmm .. i will do one thing, i really haven't seen _passthru in detail | 14:08 |
| rameshg87 | lucasagomes, i will check this in more detail and will ping you again | 14:09 |
| lucasagomes | rameshg87, yup check it out, it's a bit blackmigicish | 14:09 |
| rameshg87 | lucasagomes, yeah it really is :) | 14:09 |
| lucasagomes | heh | 14:09 |
| lucasagomes | but decorators are like that | 14:09 |
| lucasagomes | same for metaclasses | 14:09 |
| lucasagomes | rameshg87, IPA does something similar AFAIR | 14:09 |
| rameshg87 | lucasagomes, okay | 14:09 |
| rameshg87 | lucasagomes, the problem is i still don't have a full understanding of where the problem that i am solving is created | 14:10 |
| lucasagomes | rameshg87, https://github.com/openstack/ironic-python-agent/blob/master/ironic_python_agent/extensions/base.py#L272 | 14:10 |
| rameshg87 | lucasagomes, i kind of know the problem, know the solution which works, but don't know where it is getting created :) | 14:10 |
| rameshg87 | lucasagomes, i think i will need to learn this more | 14:10 |
| lucasagomes | adding attributes to functions as part of the decorator | 14:10 |
| lucasagomes | it's a normal thing actually, tho it's not striagh forward | 14:11 |
| lucasagomes | rameshg87, the problem is being created at the instantiation time | 14:11 |
| rameshg87 | okay .. | 14:11 |
| lucasagomes | say, you instantiate a class once | 14:11 |
| lucasagomes | one of the methods is decorated with our @passhtru decorator | 14:11 |
| lucasagomes | so it will get the _vendor_metadata that was added by the decorator to the method decorated with @passthru | 14:12 |
| lucasagomes | then as we didn't do a copy() of it, it will add a key 'func' pointing to the reference of the method decorated from the instance object | 14:12 |
| lucasagomes | because we can't call Class.method() if it's not a staticmethod | 14:12 |
| lucasagomes | needs to come from an instance | 14:13 |
| lucasagomes | then... we instantiate it again | 14:13 |
| lucasagomes | same thing, but on the second instance we are changing 'func' to point to the method of the new instance | 14:13 |
| lucasagomes | remmeber it wasn't copy()'ed | 14:13 |
| lucasagomes | so it will also change the metadata from the instance 1 | 14:13 |
| lucasagomes | because that metadata was the same dictionary | 14:14 |
| lucasagomes | rameshg87, gotcha? | 14:14 |
| rameshg87 | lucasagomes, yeah .. | 14:14 |
| rameshg87 | lucasagomes, i understood the explanation .. | 14:14 |
| rameshg87 | lucasagomes, i will try to add the inheritance test case later .. | 14:14 |
| lucasagomes | rameshg87, ack | 14:14 |
| rameshg87 | lucasagomes, might come back again with more questions if i stumble upon something there | 14:15 |
| rameshg87 | :) | 14:15 |
| lucasagomes | rameshg87, cool np | 14:15 |
| rameshg87 | lucasagomes, btw https://review.openstack.org/#/c/156587/ | 14:15 |
| lucasagomes | maybe there's a better way to create those maps too, this way seems blackmagic as I said | 14:15 |
| rameshg87 | lucasagomes, the bootable partition issue | 14:15 |
| rameshg87 | :) | 14:15 |
| *** Marga_ has joined #openstack-ironic | 14:15 | |
| lucasagomes | rameshg87, cool, thanks! | 14:16 |
| *** rameshg87 is now known as rameshg87-brb | 14:19 | |
| stendulker_ | lucasgomes: Hi | 14:20 |
| *** Marga_ has quit IRC | 14:20 | |
| stendulker_ | lucasgomes: This is regarding code review - Ilo drivers sets capabilities:boot_mode in node https://review.openstack.org/#/c/155731/ | 14:20 |
| lucasagomes | stendulker_, hi there, thanks I will take a look | 14:21 |
| stendulker_ | lucasgomes: You had few questions on implementation, have answered tham in the review. | 14:22 |
| stendulker_ | lucasgomes: Thank you | 14:22 |
| lucasagomes | thanks u for the reply | 14:23 |
| openstackgerrit | Victor Sergeyev proposed openstack/ironic: Run tests in py34 environment https://review.openstack.org/156192 | 14:23 |
| openstackgerrit | Victor Sergeyev proposed openstack/ironic: Use mock from standard library in py3x env https://review.openstack.org/156600 | 14:23 |
| openstackgerrit | Yuiko Takada proposed stackforge/ironic-discoverd: Support i18n part3 https://review.openstack.org/156119 | 14:24 |
| *** yuikotkada has quit IRC | 14:24 | |
| *** stendulker has joined #openstack-ironic | 14:26 | |
| *** stendulker_ has quit IRC | 14:28 | |
| *** yog__ has joined #openstack-ironic | 14:30 | |
| *** derekh has quit IRC | 14:33 | |
| *** derekh has joined #openstack-ironic | 14:35 | |
| *** zz_jgrimm is now known as jgrimm | 14:40 | |
| gilliard | lucasagomes: I tried to review your nova patch and now I'm watching baha men!!?! | 14:47 |
| lucasagomes | gilliard, what is that? hah | 14:47 |
| lucasagomes | which patch? | 14:48 |
| gilliard | https://review.openstack.org/#/c/145302/4/nova/tests/unit/virt/ironic/test_driver.py | 14:48 |
| lucasagomes | LOL | 14:48 |
| lucasagomes | ohhhhhh hah | 14:48 |
| lucasagomes | gilliard, that's a super funny patch to review man :P | 14:48 |
| gilliard | srsly though. Many of the changes in the test don't seem to be related to the change in the driver. | 14:50 |
| lucasagomes | gilliard, :/ yeah, I just fixed some stuff to use the alreayd created node object | 14:51 |
| lucasagomes | instead of creating it all the time | 14:51 |
| lucasagomes | I could remove it tho, but doesn't really affect anything | 14:52 |
| lucasagomes | gilliard, as a background, that bit was part of the previous patch that merged with the base config driver | 14:52 |
| lucasagomes | so I split that up, the changes came from that so I just left as is | 14:52 |
| gilliard | Right - I thought it would be something like that. | 14:52 |
| gilliard | And the changes all look fine, of course :) | 14:53 |
| *** yog__ has quit IRC | 14:55 | |
| lucasagomes | gilliard, cool :) | 14:55 |
| gilliard | +1. If it still doesn't merge, you will get a lot more core-reviewer-eyeballs if it links to a bug somehow. | 14:55 |
| gilliard | But 9 +1s and a +2 should be.... | 14:55 |
| *** lazy_prince is now known as killer_prince | 14:56 | |
| openstackgerrit | Ramakrishnan G proposed openstack/ironic: Add localboot support for iscsi_ilo driver https://review.openstack.org/156608 | 14:58 |
| lucasagomes | gilliard, I see, yeah I posted in the -nova channel to get some more [core] eyeballs into it | 14:59 |
| lucasagomes | thanks for the tips | 14:59 |
| *** naohirot has quit IRC | 15:04 | |
| *** BadCub_ has joined #openstack-ironic | 15:05 | |
| BadCub_ | Morning Ironic | 15:05 |
| NobodyCam | good morning Ironicers :) | 15:06 |
| NobodyCam | morning BadCub_ , lucasagomes , gilliard :) | 15:06 |
| lucasagomes | NobodyCam, morning | 15:06 |
| jroll | morning BadCub_ NobodyCam lucasagomes gilliard and everyone else :D | 15:06 |
| lucasagomes | jroll, morning | 15:07 |
| NobodyCam | morning jroll :) | 15:07 |
| *** ndipanov has quit IRC | 15:07 | |
| NobodyCam | :) | 15:08 |
| *** absubram has joined #openstack-ironic | 15:09 | |
| *** pas-ha has quit IRC | 15:10 | |
| *** ndipanov has joined #openstack-ironic | 15:10 | |
| *** yog__ has joined #openstack-ironic | 15:13 | |
| *** Marga_ has joined #openstack-ironic | 15:16 | |
| *** Marga_ has quit IRC | 15:21 | |
| *** pas-ha has joined #openstack-ironic | 15:21 | |
| openstackgerrit | Victor Sergeyev proposed openstack/ironic: Use oslo_utils replace oslo.utils https://review.openstack.org/149450 | 15:25 |
| viktors | jiangfei: around? | 15:26 |
| lucasagomes | jroll, wondering where I should add the installation of bootloader on IPA, in a extension or as part of the hardware manager thing | 15:31 |
| lucasagomes | will do on extension as first stab | 15:31 |
| * lucasagomes jumps on a call | 15:32 | |
| *** achanda has joined #openstack-ironic | 15:32 | |
| jroll | lucasagomes: with an extension, it has to be called by ironic, dunno if that's desired | 15:33 |
| jroll | I would add it as part of the image writing | 15:33 |
| jroll | if image is partition and localboot, write bootloader | 15:33 |
| *** BertieFulton has quit IRC | 15:35 | |
| *** dlpartain has joined #openstack-ironic | 15:39 | |
| *** dlpartain has left #openstack-ironic | 15:39 | |
| *** Marga_ has joined #openstack-ironic | 15:39 | |
| *** Marga_ has quit IRC | 15:40 | |
| *** Marga_ has joined #openstack-ironic | 15:41 | |
| *** achanda has quit IRC | 15:41 | |
| *** pas-ha has quit IRC | 15:46 | |
| *** anderbubble has joined #openstack-ironic | 15:52 | |
| *** Marga_ has quit IRC | 15:53 | |
| *** r-daneel has joined #openstack-ironic | 15:54 | |
| lucasagomes | jroll, right, I will have to add as a separated call, due the iscsi one. Because for that methodology, ironic is the one partitioning and writting the image | 15:55 |
| jroll | ah, right | 15:56 |
| lucasagomes | but yeah, as an extension it looks good | 15:56 |
| lucasagomes | and it's good to be separated as well, makes things more atomic-ish | 15:56 |
| jroll | yeah, indeed | 15:56 |
| jroll | "ish" | 15:56 |
| lucasagomes | heh | 15:57 |
| *** stendulker_ has joined #openstack-ironic | 15:59 | |
| jlvillal | Morning all! | 16:01 |
| *** stendulker has quit IRC | 16:02 | |
| NobodyCam | morning jlvillal :) | 16:03 |
| *** Sam______ has joined #openstack-ironic | 16:04 | |
| *** achanda has joined #openstack-ironic | 16:05 | |
| *** pensu has left #openstack-ironic | 16:05 | |
| openstackgerrit | Jarrod Johnson proposed stackforge/pyghmi: Move packet queue into IO thread https://review.openstack.org/156639 | 16:06 |
| *** achanda has quit IRC | 16:06 | |
| openstackgerrit | Ramakrishnan G proposed openstack/ironic: Add localboot support for iscsi_ilo driver https://review.openstack.org/156608 | 16:08 |
| rameshg87-brb | jroll, can you please have a look at inband raid configuration spec: https://review.openstack.org/#/c/147803/ | 16:11 |
| rameshg87-brb | jroll, two +2s and waiting for feedback from a rackspace guy :) | 16:11 |
| openstackgerrit | Ramakrishnan G proposed openstack/ironic: Add driver interface for RAID configuration https://review.openstack.org/155230 | 16:13 |
| *** Sam______ has quit IRC | 16:13 | |
| *** rameshg87-brb has quit IRC | 16:14 | |
| * jroll looks | 16:16 | |
| openstackgerrit | Merged stackforge/pyghmi: Move packet queue into IO thread https://review.openstack.org/156639 | 16:17 |
| *** Nisha_away has joined #openstack-ironic | 16:20 | |
| *** Nisha has quit IRC | 16:21 | |
| jroll | JayF: you should also look at | 16:25 |
| jroll | ... | 16:25 |
| jroll | https://review.openstack.org/#/c/147803/ | 16:26 |
| jroll | that | 16:26 |
| lucasagomes | jlvillal, morning :) | 16:28 |
| jlvillal | NobodyCam: lucasagomes: Thanks | 16:28 |
| NobodyCam | :) | 16:29 |
| jroll | morning jlvillal :) | 16:31 |
| *** jrist-afk is now known as jrist | 16:31 | |
| jlvillal | jroll: Morning | 16:31 |
| * jlvillal trying to get back into work mode after three day weekend... | 16:32 | |
| lucasagomes | jlvillal, btw, I left some comments on the stable state patch | 16:34 |
| jlvillal | lucasagomes: Thanks. I'll go look! | 16:34 |
| *** andreykurilin__ has quit IRC | 16:34 | |
| lucasagomes | jlvillal, more about the reason about it, code-wise it looks good. please take a look when you have some time | 16:34 |
| lucasagomes | sure | 16:34 |
| lucasagomes | np | 16:34 |
| *** andreykurilin_ has joined #openstack-ironic | 16:34 | |
| jlvillal | lucasagomes: I will reply. But basically we had initial patches where target was not going to a stable/passive state. So trying to help people to not make errors. | 16:37 |
| *** derekh has quit IRC | 16:37 | |
| openstackgerrit | Merged openstack/ironic-specs: In-band RAID configuration using agent ramdisk https://review.openstack.org/147803 | 16:38 |
| lucasagomes | jlvillal, right, to avoid programmatic errors then | 16:38 |
| *** derekh has joined #openstack-ironic | 16:38 | |
| jlvillal | lucasagomes: Yes | 16:38 |
| *** gridinv has quit IRC | 16:39 | |
| jlvillal | lucasagomes: Though I'll admit I like the term 'stable' more than 'passive' | 16:40 |
| * dtantsur too | 16:40 | |
| lucasagomes | jlvillal, yeah me too | 16:40 |
| dtantsur | maybe we should change the spec? | 16:40 |
| jlvillal | dtantsur: I would like that, if it is allowed | 16:41 |
| lucasagomes | re terminology wise I was just a bit concern with getting different from the spec, but grand | 16:41 |
| lucasagomes | jlvillal, thanks for the replies anyway | 16:41 |
| lucasagomes | I will change my vote on that | 16:41 |
| jlvillal | lucasagomes: Okay to leave it as 'stable' then? | 16:41 |
| dtantsur | jlvillal, you can propose a patch to ironic-specs clarifying the wording. Would be very nice | 16:42 |
| lucasagomes | jlvillal, I would prefer + if people agree in updating the spec for that would be nice too | 16:42 |
| dtantsur | +1 for stable | 16:42 |
| jlvillal | dtantsur: Okay. I will do a patch for the spec | 16:42 |
| NobodyCam | mornign dtantsur :) | 16:43 |
| dtantsur | NobodyCam, oh morning :) sorry for not noticing you (and maybe someone else). I'm sick for the 3rd day already... | 16:43 |
| dtantsur | .. and for that reason I'll be calling it a day, I guess | 16:44 |
| NobodyCam | dtantsur: :( ugg being sick sucks | 16:44 |
| dtantsur | yeah | 16:44 |
| NobodyCam | have a good rest dtantsur | 16:44 |
| dtantsur | thanks | 16:44 |
| dtantsur | g'night | 16:44 |
| *** dtantsur is now known as dtantsur|afk | 16:44 | |
| NobodyCam | lucasagomes: looking at your comment on https://review.openstack.org/#/c/155460/4/ironic/drivers/modules/pxe.py | 16:44 |
| openstackgerrit | Victor Sergeyev proposed openstack/ironic: Use oslo_utils replace oslo.utils https://review.openstack.org/149450 | 16:45 |
| NobodyCam | would : LOG.warn("root_uuid key not found. Unable to verify PXE config" | 16:45 |
| lucasagomes | NobodyCam, hi there | 16:45 |
| NobodyCam | " for node %(node)s", {"node": task.node.uuid}) | 16:45 |
| NobodyCam | be what your looking for there? | 16:45 |
| openstackgerrit | John L. Villalovos proposed openstack/ironic-specs: Use the term 'stable' state instead of 'passive' https://review.openstack.org/156655 | 16:45 |
| dtantsur|afk | that ^^^ was fast Oo | 16:45 |
| dtantsur|afk | ok, gone for real now :) | 16:45 |
| NobodyCam | hehehe | 16:45 |
| jlvillal | dtantsur|afk: ;) | 16:45 |
| lucasagomes | NobodyCam, yeah, also, if that KeyError appears we are skipping the else: | 16:46 |
| lucasagomes | so the switch one be changed | 16:46 |
| *** ndipanov has quit IRC | 16:46 | |
| lucasagomes | NobodyCam, /me thinking | 16:47 |
| *** devanand_ has joined #openstack-ironic | 16:48 | |
| lucasagomes | NobodyCam, something like "The UUID for the root partition can't be found, unable to switch the pxe config from deployment mode to service mode for node %s" | 16:49 |
| *** andreykurilin_ has quit IRC | 16:49 | |
| lucasagomes | NobodyCam, makes sense? | 16:49 |
| *** andreykurilin_ has joined #openstack-ironic | 16:49 | |
| *** Marga_ has joined #openstack-ironic | 16:49 | |
| lucasagomes | NobodyCam, or "... skipping trying to switch ..." | 16:50 |
| *** stendulker_ has quit IRC | 16:50 | |
| *** viktors is now known as viktors|afk | 16:51 | |
| *** coolsvap is now known as coolsvap_ | 16:51 | |
| *** rwsu has joined #openstack-ironic | 16:52 | |
| NobodyCam | lucasagomes: ya | 16:53 |
| lucasagomes | NobodyCam, cool, there's some comments on the tests as well | 16:58 |
| lucasagomes | like verifying that the root_uuid is written to the driver_internal_info as well | 16:58 |
| *** ndipanov has joined #openstack-ironic | 16:59 | |
| *** Guest31726 is now known as dank_ | 17:01 | |
| NobodyCam | lucasagomes: ack attempting to see if test will run in my local env :/ | 17:02 |
| *** mmorais_ has quit IRC | 17:02 | |
| lucasagomes | NobodyCam, ack, should be fine :) | 17:02 |
| lucasagomes | it's unittests | 17:02 |
| *** mmorais has joined #openstack-ironic | 17:04 | |
| NobodyCam | lol pbr start hating my mac for some reason | 17:04 |
| NobodyCam | :( | 17:04 |
| NobodyCam | didn't we land a patch to the client for --configdrive? | 17:04 |
| jroll | --config-drive | 17:05 |
| martini | JayF, you around? Figured out what I was doing wrong on the dib build, and also thinking of a different way to disentangle | 17:05 |
| JayF | I'm here, what's up? | 17:05 |
| lucasagomes | NobodyCam, oh, yeah idk about mac :( | 17:06 |
| lucasagomes | NobodyCam, we did yes | 17:06 |
| *** jcoufal_ has quit IRC | 17:06 | |
| NobodyCam | yep found it :) | 17:06 |
| NobodyCam | yep pbr hates me: ImportError: No module named pbr.version | 17:07 |
| martini | Instead of pulling the entire 'element' out of diskimage-builder and making a separate repo for it, we could move the code that actually gets executed into a python module and have the diskiamge-builder simply call the script that that provides | 17:07 |
| lucasagomes | NobodyCam, :( any bugs filled for that? | 17:07 |
| lucasagomes | martini, is it about using diskimage-builder with IPA or something? | 17:08 |
| NobodyCam | lucasagomes: I think so... just have to break out my brick :) | 17:08 |
| martini | That way https://github.com/openstack/diskimage-builder/blob/master/elements/deploy-ironic/init.d/80-deploy-ironic becomes a simple call out to a python script. Which incidentally would make it easy to add the same agent to any other ramdisk | 17:09 |
| martini | Well, splitting the actual deployment code from the image. diskimage-builder is good for building the image and pulling in dependencies, but the network reachable agent that gets installed doesn't necessarily have to be part of the diskimage-builder piece | 17:10 |
| *** ukalifon1 has quit IRC | 17:11 | |
| martini | Unless there a limiting factor that requires the diskimage-builder component to be an inline shell script? | 17:12 |
| JayF | lucasagomes: we talked at the SF mid-cycle about breaking up the bits Ironic uses for ramdisks; for existing pxe/dib ramdisk making sure Ironic devs can hack on it without being gated by cores from another project (DIB) and for IPA/CoreOS ramdisk, we're splitting the builder out from the agent itself so other things (perhaps discoverd) can use it | 17:13 |
| JayF | martini: I don't know, really, but just splitting out the actual ramdisk code seems like a godo start | 17:14 |
| lucasagomes | JayF, I see so having a diff repo for the ramdisk image building, where the DIB element, or coreos stuff used to biuld the images will leave? | 17:16 |
| lucasagomes | sounds resonable | 17:16 |
| jroll | I'd rather just nuke DIB stuff, personally | 17:17 |
| JayF | lucasagomes: exactly; see my email to the list about 'coreos-image-builder' | 17:17 |
| lucasagomes | JayF, will take a look | 17:18 |
| lucasagomes | jroll, +0 coreos doesn't seem to do an excellent job on building ramdisk images either | 17:18 |
| lucasagomes | tho better than DIB I assume | 17:19 |
| jroll | lucasagomes: I think that's a tooling failure rather than a coreos failure | 17:19 |
| lucasagomes | jroll, fair enough yeah | 17:20 |
| *** jistr has quit IRC | 17:24 | |
| openstackgerrit | Lucas Alvares Gomes proposed openstack/ironic: Address final comments of a4cf7149fb https://review.openstack.org/156671 | 17:26 |
| *** eghobo has joined #openstack-ironic | 17:28 | |
| martini | I see there's a pypi module for ironic-discoverd. I'm thinking a new module, let's call it ironic-deploy for the sake of discussion, to wrap the active code that lives in dib into a true module. Assuming we go that route: how do we create a new repo for it, and how does code from that repo get uploaded to pypi? | 17:28 |
| martini | (getting ahead of myself anyway; I can mock it up without those details sorted out) | 17:28 |
| JayF | I'd call it something like ironic-pxe-deploy or ironic-iscsi-deploy since it's explicitly for the pxe driver | 17:33 |
| *** anderbubble has quit IRC | 17:42 | |
| devananda | JayF: i'm missing something - what's specific to the iscsi/pxe deploy? | 17:45 |
| JayF | devananda: martini is looking at splitting out the code that runs in pxe ramdisk from DIB; that code is only used for iscsi/pxe deploy | 17:47 |
| devananda | JayF: oh. urgh. right. that's going in a separate place from the coreos image building bits ... | 17:49 |
| devananda | somehow this feels unnecessarily complicated | 17:49 |
| devananda | but it's probably not | 17:49 |
| martini | ironic-iscsi-deploy makes sense to me for the code that's currently in DIB. It's independent of whether it was booted via PXE or virtual media though | 17:49 |
| devananda | martini: right. and some of it should be independent of whether it is built with DIB or coreos | 17:50 |
| devananda | martini: though it sounds like we're not going that far with the separation? | 17:50 |
| martini | The idea is to turn this bit of shell script - https://github.com/openstack/diskimage-builder/blob/master/elements/deploy-ironic/init.d/80-deploy-ironic - which is inlined into /init in the dib process, into a python script which will then be called by that inline process | 17:50 |
| lucasagomes | martini, I have an extension to IPA that does the iscsi bit | 17:51 |
| lucasagomes | in python | 17:51 |
| lucasagomes | https://review.openstack.org/#/c/155727/ | 17:51 |
| lucasagomes | devananda, morning | 17:51 |
| lucasagomes | devananda, also, wanted to talk to you re IPA as default ramdisk | 17:51 |
| lucasagomes | devananda, I got it working, we may need to start looking it in gate perhaps? | 17:52 |
| lucasagomes | idk what's the plan is, how we are deprecating the old ramdisk etc | 17:52 |
| martini | Would that extension require installing the rest of IPA as well? If it doesn't add too many pip/binary dependencies, its not really an issue, just asking | 17:53 |
| devananda | lucasagomes: if we can get that running in the gate, and if it doesn't require bumping the VM RAM requirement, then I would imagine we can swap it in ironic's pxe_ssh gate job quite soon | 17:53 |
| devananda | lucasagomes: I'll be talking with tripleo folks this week in seattle about a lot of things, this among them | 17:53 |
| lucasagomes | martini, well yes? it's an extension for IPA so it requires the rest of IPA in order to it to work | 17:54 |
| lucasagomes | but can be refactored, idk if I got ur idea completely about splitting all the bits tho | 17:54 |
| lucasagomes | devananda, if the image is built with the coreos and not DIB yes, it doesn't require RAM bumping | 17:54 |
| lucasagomes | we already use coreos to build the image for the agent in devstack so it seems fine | 17:55 |
| devananda | lucasagomes: let's test it -- should be easy to do. | 17:55 |
| jroll | lucasagomes: right now ipa requires 1gb of ram in the gate, dib/iscsi requires 512mb | 17:55 |
| JayF | jroll: but IPA has to load the image into ramdisk before writing | 17:55 |
| devananda | lucasagomes: we don't build the coreos image in the devstack-tempest-dsvm-ironic ... it is downloaded | 17:55 |
| lucasagomes | jroll, oh, right ok didn't know that | 17:55 |
| JayF | jroll: iscsi+IPA means the image is done locally | 17:55 |
| JayF | jroll: so it's def. worth a shot imo | 17:56 |
| devananda | so we need to change words a bit | 17:56 |
| lucasagomes | JayF, yeah, I will try to run with 512 MB | 17:56 |
| jroll | I'm not saying it's not doable | 17:56 |
| lucasagomes | see what's up | 17:56 |
| jroll | but it won't boot on 512mb iirc | 17:56 |
| devananda | IPA can now do both an agent-fetch-from-glance deploy and an iscsi-deploy | 17:56 |
| devananda | the theory we discussed last week is that, using iscsi, the IPA ramdisk will *not* require more than 512MB | 17:56 |
| devananda | because in that case, it won't need a tmpfs to cache the image | 17:57 |
| devananda | we THINK tht's why it is taking 2x the RAM right now ... | 17:57 |
| devananda | so | 17:57 |
| lucasagomes | yeah i will give it go locally | 17:57 |
| jroll | I thought it didn't boot on 512mb, but ok | 17:57 |
| jroll | worth a try | 17:57 |
| devananda | I would think you can test this i the gate with a simple patch to devstack-gate | 17:57 |
| lucasagomes | devananda, right, we need to get things merged first | 17:58 |
| lucasagomes | both in IPA and Ironic | 17:58 |
| devananda | lucasagomes: oh ok | 17:58 |
| lucasagomes | I think both patches are fine, already. For now I created a new driver iscsi_ssh | 17:58 |
| lucasagomes | that uses pxe and IPA | 17:58 |
| lucasagomes | note that only the vendor interface is different then the pxe_ssh | 17:58 |
| jroll | I mean, you would need a patch to devstack, too, to download the image etc | 17:58 |
| jroll | or at least add iscsi_ssh to the decision whether to download/use ipa ramdisk | 17:59 |
| lucasagomes | I made it use the same pxe config file for both etc, to facilitaty backwards compat | 17:59 |
| devananda | lucasagomes: so what I think our goal there should be: get the pxe_ssh driver working with the IPA ramdisk that is produced by IPA's post-merge job | 17:59 |
| devananda | and test that with a patch to devstack that changes the default (pxe_ssh) job from using dib to downloading that image -- but doesn't change anything else | 17:59 |
| lucasagomes | jroll, sure yeah | 17:59 |
| devananda | lucasagomes: why would you need a different driver? | 18:00 |
| lucasagomes | devananda, we don't, I just did to keep things separately, peaple used to use pxe_ssh may want to use it with the DIB ramdisk | 18:00 |
| lucasagomes | I theorically could make the same vendor interface work for both ramdisks tho | 18:01 |
| lucasagomes | I can try that | 18:01 |
| devananda | lucasagomes: if we're going to change the default, we need to provide a migration path, which means compatibility, which means the new default must work with the old ramdisk | 18:01 |
| *** anderbubble has joined #openstack-ironic | 18:01 | |
| devananda | so that folks who are in production right now with the dib-built ramdisk can continue using that with the new driver | 18:01 |
| lucasagomes | devananda, right, ack I will try to get the same vendor interface we have now in PXE to work with both ramdisks | 18:01 |
| lucasagomes | that would facilitate a bunch | 18:01 |
| lucasagomes | devananda, gotcha! | 18:02 |
| *** derekh has quit IRC | 18:02 | |
| lucasagomes | for ref: https://review.openstack.org/#/c/155728/7/ironic/drivers/modules/pxe.py | 18:02 |
| lucasagomes | devananda, jroll JayF thanks for the inputs! | 18:03 |
| jroll | np :) | 18:04 |
| *** davideagnello has joined #openstack-ironic | 18:09 | |
| *** harlowja_away is now known as harlowja_ | 18:10 | |
| lucasagomes | JoshNang, hey, if you think it's odd the 'provide' we may want to update the spec to reflect that | 18:11 |
| JoshNang | lucasagomes: i mean, it makes more sense in the user facing api | 18:11 |
| lucasagomes | JoshNang, right | 18:11 |
| JoshNang | lucasagomes: so reflecting it in the state machine is fine with me | 18:12 |
| lucasagomes | gotcha | 18:12 |
| JoshNang | it'll looks odd in states.py, but reasonable everywhere else | 18:12 |
| JoshNang | *look | 18:12 |
| lucasagomes | yeah, I don't have a strong opnion on that, I understand 'provide' means go from manageable to available | 18:12 |
| lucasagomes | and it will pass cleaning if enabled | 18:12 |
| lucasagomes | so it sort of makes sense to me | 18:13 |
| lucasagomes | JoshNang, yeah | 18:13 |
| JoshNang | right. this works for me, and prevents me from having to bump the api microversion, so ++ heh | 18:13 |
| lucasagomes | JoshNang, cool thanks | 18:13 |
| JoshNang | np! thanks for the review | 18:13 |
| lucasagomes | I will +2 after the changes then | 18:13 |
| lucasagomes | rest lgtm | 18:13 |
| openstackgerrit | Jarrod Johnson proposed stackforge/pyghmi: Fix exceptions on sdr read https://review.openstack.org/156695 | 18:13 |
| lucasagomes | devananda, adam_g btw, I also was thinking about microversioning and backports | 18:14 |
| lucasagomes | how would that work | 18:14 |
| *** andreykurilin_ has quit IRC | 18:14 | |
| lucasagomes | if for e.g we have to backport something that adds version 1.5 but not 1.3 or 1.4 | 18:14 |
| lucasagomes | devananda, adam_g food for though | 18:14 |
| *** andreykurilin_ has joined #openstack-ironic | 18:14 | |
| adam_g | lucasagomes, i dont think bumping API versions with new things is a suitable backport? | 18:14 |
| lucasagomes | adam_g, right, yeah well sounds resonable | 18:15 |
| adam_g | lucasagomes, do you have an example of something that would get backported with a bump there? | 18:15 |
| lucasagomes | adam_g, not really, it was just really thinking about stuff | 18:15 |
| *** jxiaobin has joined #openstack-ironic | 18:15 | |
| lucasagomes | adam_g, and was wondering about how that would work | 18:15 |
| adam_g | lucasagomes, ah. yeah, i cant really think of anything there. sorta similar, for things like non-alembic DB migrations, we would leave a gap between, say, last migration # for kilo and first of L. 34-last_kilo_migration.py ... 44-first_l_migration.py, to allow space for fixes | 18:17 |
| * jlvillal likes the price for the OpenStack summit with his discount code :) | 18:18 | |
| *** achanda has joined #openstack-ironic | 18:18 | |
| devananda | lucasagomes: short version - anything that changes the API should NOT be back ported | 18:19 |
| *** korekhov has joined #openstack-ironic | 18:19 | |
| lucasagomes | adam_g, yeah | 18:19 |
| lucasagomes | devananda, +1, yeah adam pointed out that and it clicked in my head | 18:20 |
| lucasagomes | I was just worrying whether we have thought about it or not | 18:20 |
| lucasagomes | so brought that up | 18:20 |
| devananda | lucasagomes: have you read teh backport guidelines? | 18:20 |
| lucasagomes | devananda, not that I remember | 18:20 |
| devananda | lucasagomes: https://wiki.openstack.org/wiki/StableBranch#Stable_branch_policy | 18:21 |
| devananda | Some types of changes are completely forbidden: | 18:21 |
| devananda | Changes to the external HTTP APIs | 18:21 |
| devananda | Changes to .. internal AMQP API | 18:21 |
| devananda | DB schema changes | 18:21 |
| devananda | Incompatible config file changes | 18:21 |
| lucasagomes | a-ha alright awesome | 18:21 |
| adam_g | devananda, this reminds me, if you get a sec can you create a 2014.2.1 milestone on https://launchpad.net/ironic ? i will tag and upload what we have in stable/juno as 2014.2.1? | 18:22 |
| devananda | adam_g: hm, lemme try | 18:22 |
| lucasagomes | devananda, jroll: "Entering emergency mode. Exit the shell to continue." 512MB ram doesn't work with IPA | 18:22 |
| adam_g | i should have access to do everything else | 18:22 |
| jroll | lucasagomes: ya | 18:23 |
| * jroll has a good memory for once | 18:23 | |
| lucasagomes | that said, in our dev guidelines we change it to 1GB | 18:23 |
| lucasagomes | http://docs.openstack.org/developer/ironic/dev/dev-quickstart.html#deploying-ironic-with-devstack | 18:23 |
| lucasagomes | not sure how that plays on gate tho | 18:23 |
| jroll | lucasagomes: right, and it will be fine for tempest but not for tempest parallel | 18:23 |
| devananda | lucasagomes: yea, in the gate we need it to be smaller for the tempest parallel job to run | 18:24 |
| * adam_g wonders about the future of that job | 18:24 | |
| lucasagomes | devananda, jroll I see | 18:24 |
| lucasagomes | well hmmm | 18:24 |
| lucasagomes | is it "check-tempest-dsvm-ironic-parallel-nv" ? cause it's non-voting and failing right now in our gate | 18:25 |
| devananda | adam_g: heh... you tell me - is that job, or any job that runs the compute tests against nova+ironic in parallel, worth having? | 18:25 |
| lucasagomes | adam_g, that worth fixing? | 18:25 |
| adam_g | lucasagomes, i have a patch up to fix it. a new test merged to tempest that fails in that run... because we aren't running it anywhere outside our gate, we dont catch those things | 18:25 |
| lucasagomes | I see | 18:26 |
| devananda | adam_g: "a new test" related to ironic? | 18:26 |
| adam_g | devananda, running tests in parallel is worht having, and doing it with tenant isolation is too.. but running a whole bunch of tests that aren't really relevant to our interests seems not important. and it souonds like the attitude about testing is migrating away from 'test everythign' to 'test what you need to test' | 18:26 |
| adam_g | devananda, | 18:27 |
| adam_g | https://review.openstack.org/#/c/156415/ | 18:27 |
| devananda | adam_g: ++ to everything you just said | 18:27 |
| devananda | so yea, this is an example of "we should only be running the tests we want" -- and the job is failing because it's trying to run all the tests | 18:28 |
| lucasagomes | fair enuff | 18:28 |
| adam_g | yeah | 18:29 |
| devananda | adam_g: re: 2014.2.1 release - i found the right page. first time I've done this ... and I see that nova has a 2014.2.2 already | 18:29 |
| jroll | https://gigaom.com/2015/02/17/openstack-comes-up-huge-for-walmart/ <- ironic shoutout | 18:29 |
| devananda | adam_g: we didn't do a 2014.2.1 back in december. is that ok? our 2014.2.1 will be out of sync with everyone else's | 18:29 |
| adam_g | devananda, yeah, there have been 2 official point releases so far for the integrated juno stuff | 18:29 |
| adam_g | devananda, non-integrated stuff is free to follow their own schedule. ill ping ttx just to double check that, but ive seen other projects cut their own point releases | 18:30 |
| devananda | ack | 18:30 |
| lucasagomes | jroll, awesome! will read | 18:30 |
| jroll | :) | 18:30 |
| lucasagomes | we should have a "success stories" in our wiki | 18:31 |
| lucasagomes | for people using Ironic | 18:31 |
| jroll | well, they aren't using it yet :P | 18:31 |
| lucasagomes | yeah, well but you guys are | 18:31 |
| *** harshs has joined #openstack-ironic | 18:31 | |
| jroll | success story: OS_AUTH_URL=...rackspace.com... nova boot --flavor onmetal-compute1 | 18:31 |
| devananda | lucasagomes: the challenge with corporate success stories is you need the corporation to authorize it | 18:32 |
| devananda | lucasagomes: we are not allowed to just add taht to our wiki | 18:33 |
| lucasagomes | devananda, oh, right | 18:33 |
| *** romcheg has quit IRC | 18:33 | |
| jroll | yay legal departments | 18:33 |
| lucasagomes | heh | 18:33 |
| lucasagomes | ok folks, I will call it a day. It's a bit late here | 18:34 |
| lucasagomes | thanks for the chat/suggestions! | 18:34 |
| jroll | night lucasagomes :) | 18:34 |
| lucasagomes | good night everyone | 18:34 |
| *** lucasagomes is now known as lucas-dinner | 18:34 | |
| jlvillal | lucasagomes: Good night | 18:34 |
| BadCub_ | gnite lucas-dinner | 18:34 |
| openstackgerrit | Merged stackforge/pyghmi: Fix exceptions on sdr read https://review.openstack.org/156695 | 18:34 |
| adam_g | NobodyCam, any idea how this might be happening? https://bugs.launchpad.net/tempest/+bug/1422832 | 18:35 |
| openstack | Launchpad bug 1422832 in tempest "tempest.api.compute.admin.test_baremetal_nodes API validation inaccurate" [Undecided,New] | 18:35 |
| *** spandhe has joined #openstack-ironic | 18:40 | |
| *** devlaps has joined #openstack-ironic | 18:40 | |
| devananda | adam_g: https://launchpad.net/ironic/+milestone/2014.2.1 | 18:41 |
| adam_g | devananda, great thanks. waiting to hear from ttx before i push tags | 18:41 |
| openstackgerrit | Jarrod Johnson proposed stackforge/pyghmi: Add missing generic discrete codes https://review.openstack.org/156704 | 18:42 |
| devananda | adam_g: I'm a bit confused by the new tests for Nova os-baremetal-nodes - somehow I had it in my brain that Nova wanted to deprecate/remove those after Kilo | 18:43 |
| adam_g | devananda, im not sure either. i went offline for a week and came back and they are running and failing | 18:44 |
| adam_g | one of the failures is valid as its relevant to the juno migration and is a bug in grenade | 18:44 |
| adam_g | the other failure (which is only hitting me locally) is that bug | 18:45 |
| *** athomas has quit IRC | 18:45 | |
| *** devlaps has quit IRC | 18:49 | |
| *** zer0c00l has quit IRC | 18:54 | |
| NobodyCam | oh adam_g sorry was looking at another window and didn't see your ping | 18:55 |
| openstackgerrit | Merged stackforge/pyghmi: Add missing generic discrete codes https://review.openstack.org/156704 | 18:58 |
| NobodyCam | devananda: I was under the same impression as you with reguard to Nova wanting to deprecate/remove those | 18:58 |
| adam_g | NobodyCam, no worries. i think ive got it. | 18:58 |
| NobodyCam | :) | 18:58 |
| *** ifarkas has quit IRC | 18:59 | |
| *** zer0c00l has joined #openstack-ironic | 19:00 | |
| *** athomas has joined #openstack-ironic | 19:06 | |
| Nisha_away | devananda, request to look at inspection patches | 19:06 |
| Nisha_away | NobodyCam, ^^^ | 19:06 |
| Nisha_away | jroll ^^^ | 19:06 |
| openstackgerrit | Jarrod Johnson proposed stackforge/pyghmi: Reduce severity of a non-redundant state https://review.openstack.org/156712 | 19:07 |
| openstackgerrit | Chris Krelle proposed openstack/ironic: Add logging when no reservation are cleared on startup. https://review.openstack.org/156713 | 19:10 |
| jroll | O.o | 19:12 |
| jroll | NobodyCam: ... | 19:13 |
| devananda | adam_g: checked with nova - they do not plan to remove os-baremetal-nodes ext | 19:13 |
| NobodyCam | :) | 19:13 |
| jroll | devananda: wat | 19:13 |
| *** pelix has quit IRC | 19:14 | |
| devananda | NobodyCam: ^ does not make sense to me. "not clearing reservations" is perfectly normal expected behavior | 19:14 |
| jroll | I'm thinking on -2'ing that | 19:14 |
| NobodyCam | :) | 19:14 |
| jroll | commit message also is bonkers | 19:15 |
| openstackgerrit | Merged stackforge/pyghmi: Reduce severity of a non-redundant state https://review.openstack.org/156712 | 19:15 |
| Nisha_away | devananda, regarding nova ffe | 19:16 |
| devananda | jroll: yea | 19:16 |
| jroll | I left a -1 to be nice | 19:17 |
| Nisha_away | how do we want to put the value in the instance_info | 19:17 |
| Nisha_away | devananda, do we want to have operators also populated in the instance_info and do the required actions in ironic? | 19:18 |
| Nisha_away | NobodyCam, jroll ^^^ | 19:19 |
| devananda | Nisha_away: huh? | 19:19 |
| jroll | Nisha_away: I don't think I understand the question | 19:19 |
| *** Nisha_away is now known as Nisha | 19:20 | |
| *** openstackgerrit has quit IRC | 19:20 | |
| devananda | Nisha_away: when using nova with ironic, only nova should be updating instance_info | 19:20 |
| devananda | but I also do not understand the qeustion | 19:20 |
| *** openstackgerrit has joined #openstack-ironic | 19:20 | |
| Nisha | devananda, jroll this is in regards to this comment | 19:20 |
| Nisha | Aren't you just throwing away all the operators? Is the point of all this code just to filter out the operators if they're not <all-in> or <or> ? | 19:20 |
| Nisha | actually i drop the operator and copy the value in instance_info | 19:21 |
| Nisha | thats where my question is now | 19:21 |
| jroll | oh, those kind of operators | 19:21 |
| Nisha | yes | 19:21 |
| devananda | Nisha: why are you dropping the operators? | 19:21 |
| Nisha | devananda, else ironic will need to drop the operator, correct? | 19:22 |
| devananda | Nisha: why? | 19:22 |
| Nisha | example | 19:22 |
| jroll | aren't the operators meant to be used, not just dropped? | 19:22 |
| Nisha | say flavor has 'capabilities:BootMode':'<in> uefi' | 19:23 |
| *** wanyen has joined #openstack-ironic | 19:23 | |
| wanyen | hi Jroll, | 19:23 |
| Nisha | so right now i copy the value uefi only in instance_info | 19:23 |
| Nisha | instead of <in> uefi | 19:23 |
| jroll | wanyen: hi | 19:23 |
| wanyen | I like to discuss secure_boot | 19:24 |
| Nisha | if we have BootMode = '<in> uefi' means we will have to evaluate that in ironic | 19:24 |
| wanyen | Secure_boot is not a boot mode , it is a UEFI boot option | 19:24 |
| Nisha | if we have BootMode = '<in> uefi' in instance_info means we will have to evaluate that in ironic | 19:24 |
| jroll | wanyen: I understand. I've stated my opinion on the review. you should do the same | 19:25 |
| wanyen | secure boot can be used with UEFI or other uefi options, e.g., UEFI HTTP boot or UEFI iscsi boot | 19:25 |
| Nisha | basically it means may be we will have to do what nova scheduler and nova extra_specs_op.py is doing | 19:25 |
| Nisha | devananda, ^^^ | 19:26 |
| wanyen | jroll, yes. I entered a comment as well. | 19:26 |
| jroll | wanyen: I tend to think we shouldn't have a separate management interface method for every boolean variable about boot mode | 19:26 |
| jroll | wanyen: ok, then I will reply when I have time | 19:26 |
| jroll | [/b 2 | 19:26 |
| jroll | oops | 19:26 |
| wanyen | jroll, tx | 19:26 |
| Nisha | jroll, ^^^ | 19:26 |
| jroll | Nisha: link to review? | 19:27 |
| Nisha | #link https://review.openstack.org/#/c/141012/25/nova/virt/ironic/patcher.py | 19:27 |
| devananda | Nisha: what happens when there are multiple capabilities with different operators? | 19:28 |
| Nisha | the code will create a dictionary with all the capabilities and their values but will drop the operator | 19:29 |
| jroll | Nisha: it looks like you should talk to dansmith about this... also, I tend to agree that we should fail if we hit an unsupported operator | 19:29 |
| Nisha | for unsupported operator i have already failed. He has given comment on nested capability key. this i wll address | 19:30 |
| Nisha | but the comment above which we are discussing is something depends on how ironic wants information in instance_info | 19:30 |
| devananda | Nisha: stripping the operators seems like a really bad thing | 19:31 |
| jroll | Nisha: I just see a log.warning if there's an unsupported operator | 19:31 |
| jroll | devananda++ | 19:31 |
| devananda | Nisha: operators are such things as ">" and "<" and "==" and "!=" | 19:32 |
| Nisha | then actually i can just copy the exact value in instance_info and then ironic will strip off the operator as per desired action? | 19:32 |
| devananda | Nisha: how is throwing that information away before passing it to Ironic helpful? | 19:32 |
| devananda | Nisha: wat? why would Ironic strip that off too? | 19:32 |
| devananda | I'm missing something | 19:32 |
| devananda | why are the operators not important to you? | 19:32 |
| devananda | if this only supports very simple "capability:foo": | 19:33 |
| devananda | if this only supports very simple "capability:foo":"bar" style, then we should error on having ANY operator | 19:33 |
| devananda | because stripping the operator, when the flavor says something like "capability:foo":"!= bar" is going to be, well, wrong | 19:34 |
| Nisha | devananda, yes | 19:35 |
| devananda | Nisha: so, what am I missing? why are you stripping operators off AT ALL ? | 19:35 |
| Nisha | i was initially just supporting for <in> operator which we can use for multiple values in the capabilitis values at ironic node | 19:36 |
| Nisha | devananda, ok so i will pass on the information as it is to ironic | 19:37 |
| Nisha | that makes the code easy | 19:37 |
| Nisha | devananda, as of now i dont plan to support nested key...is that fine? | 19:38 |
| devananda | Nisha: declaring what operators or structure is supported seems OK to me -- but it should error (not fail silently) in that case | 19:40 |
| *** lucas-dinner is now known as lucasagomes | 19:40 | |
| devananda | Nisha: also, <in> doesn't make sense to me | 19:40 |
| Nisha | devananda, why <in> is a supported operator | 19:41 |
| devananda | Nisha: if I say "capabilities:boot_mode" : "<in> bios, uefi, vmedia, unicorns" -- then what is Ironic actually supposed to do with this list? | 19:41 |
| devananda | Nisha: it seems like you want to use only the "==" operator | 19:41 |
| Nisha | devananda, no above is wrong | 19:41 |
| devananda | oh? | 19:41 |
| Nisha | it will be 'capabilities:boot_mode' : '<in> uefi' at flavor | 19:42 |
| Nisha | at ironic it will be a list like capabilities = 'boot_mode:bios uefi vmedia' | 19:42 |
| Nisha | in this case the node gets selected | 19:43 |
| Nisha | with <in> operator | 19:43 |
| devananda | Nisha: what prevents Nova from having 'capabilities:boot_mode' : '<in> uefi, bios' ? | 19:44 |
| devananda | it is, after all, the "in" operator -- it can take a list | 19:44 |
| Nisha | now when we copy the flavor value '<in> uefi' to the instance_info | 19:44 |
| devananda | and a deployer will undoubtedly customize their flavors | 19:44 |
| Nisha | for the above example the operator is <all-in> | 19:44 |
| Nisha | now when we copy the flavor value '<in> uefi' to the instance_info, ironic has to see what operator is being passed by operator and take action based on that | 19:45 |
| Nisha | so for <in> operator we basically just need the value 'uefi' fo rthe driver to take any action | 19:46 |
| Nisha | for <all-in> operator even i am not sure how ironic shall behave. May be ironic can say for certain capabilities that the oerator is not supported. | 19:47 |
| wanyen | Ironic does not have a use case for all-in yet, so not supported sounds reasonable | 19:50 |
| wanyen | devananda, Nisah initially proposed to use 'capability:boot_mode':'uefi' but it got shutdown by Nova becasue they believe <in> operator can fulfill what she proposed. | 19:53 |
| rloo | wanyen, Nisha, devananda: if this capabilities mechanism from nova is meant to be generic and used for any capabilities in ironic, how do we know which operators are/are not of interest? doesn't it depend on the actual capability? | 19:53 |
| Nisha | rloo, +1 | 19:53 |
| wanyen | rloo: yes | 19:53 |
| rloo | Nisha: so I am now thinking that the nova.ironic driver should just pass the value down to ironic, and the appropriate ironic driver should interpret the value | 19:54 |
| Nisha | rloo, ok | 19:54 |
| rloo | Nisha, wanyen: does that make sense? Don't just say ok to get the patch approved ;) | 19:55 |
| *** devanand_ has quit IRC | 19:55 | |
| Nisha | rloo, it makes sense...but then we will need to handle nested keys also in this | 19:55 |
| rloo | Nisha: yes, ironic will need to handle it. | 19:56 |
| Nisha | as of now it looks tricky to handle nested keys | 19:56 |
| wanyen | rloo, it's the matter whether we take incremental approach or not. | 19:57 |
| jroll | because how dare we use dictionaries to define capabilities :| | 19:57 |
| wanyen | if we have a use case now then we should implement everything | 19:57 |
| rloo | wanyen: it seems to me that it is easier/faster to iterate on code in ironic, than in nova... | 19:57 |
| jroll | ++ | 19:57 |
| rloo | wanyen: you cannot implement 'everything' in nova because we don't know what 'everything' is. | 19:57 |
| *** lucasagomes is now known as lucas-dinner | 19:58 | |
| rloo | wanyen: implementing a particular usecase means that it most likely may not be general enough for other use cases. | 19:58 |
| Nisha | rloo, jroll in my opinion we cant have nested capabilities from ironic | 19:58 |
| jroll | Nisha: why | 19:59 |
| jroll | I don't pretend to understand what nested capabilities are, but I'm curious what would hold us back | 19:59 |
| Nisha | #link https://github.com/openstack/nova/blob/master/nova/virt/ironic/driver.py#L235-243 | 20:00 |
| *** nosleep77 has joined #openstack-ironic | 20:00 | |
| NobodyCam | brb ... quick run to starbucks :) | 20:01 |
| Nisha | ironic virt driver considers the string 'key1:val1,key2:val2,key3:val3..' as the valid capability | 20:01 |
| mrda | Morning | 20:01 |
| Nisha | it doesnt takes it as a dictionary which is allowed by other drivers in nova | 20:02 |
| jroll | huh, weird | 20:02 |
| jroll | mrda: morning :) | 20:02 |
| jroll | I think I'm done caring about this capabilities thing | 20:02 |
| jroll | but I don't thinki we should drop operators | 20:02 |
| *** romcheg has joined #openstack-ironic | 20:03 | |
| *** Marga_ has quit IRC | 20:03 | |
| Nisha | jroll, thats fine but about nested keys we should error out? | 20:03 |
| mrda | jroll: \o | 20:03 |
| jroll | Nisha: I guess? idk | 20:03 |
| jroll | Nisha: we support dictionaries now | 20:03 |
| jroll | but backwards compat | 20:03 |
| jroll | maybe we should just do all of this next cycle? | 20:04 |
| Nisha | at flavor side, u can have capability built as 'capabilities:opt1:b:aa': '2' | 20:04 |
| jroll | since we're 3 days from getting this patch frozen anyway and I don't want to rush bad code in | 20:04 |
| jroll | after kilo is released we can start using dictionaries for capabilities | 20:04 |
| Nisha | jroll, fine then also backward compatibility will be a quest | 20:05 |
| jroll | Nisha: what do you mean? | 20:06 |
| jroll | we'll have to handle backwards compat in ironic, but not in nova, if we bump this to L | 20:06 |
| Nisha | ya | 20:06 |
| wanyen | jroll, what to bump to L? | 20:07 |
| jroll | wanyen: this capabilities work. I'm not saying we should, just wondering out loud | 20:07 |
| wanyen | jroll,we need capability to pass to ironic to support secure boot, local boot for partiontion image and trusted boot | 20:08 |
| jroll | Nisha: although thinking more... not sure why we can't do nested capabilities | 20:08 |
| jroll | json.dumps is a thing | 20:08 |
| jroll | wanyen: I understand why we need it | 20:08 |
| * devananda reads backscroll, then goes off to re-read the nova spec | 20:08 | |
| wanyen | jroll, so I think we can take incremental approach to support these features | 20:09 |
| Nisha | jroll, how do u defined the capability at ironic node for node to get selected by nova scheduler | 20:09 |
| * devananda notes the ratio of approved:completed specs in Nova ... http://specs.openstack.org/openstack/nova-specs/specs/kilo/index.html | 20:09 | |
| jroll | wanyen: I agree, it's possible, I'm wondering if it's worth the effort | 20:09 |
| jroll | devananda: I think that's not up to date :P | 20:09 |
| Nisha | jroll, however as of now we cant define nested capability keys in ironic , so its worth to error out in nova virt driver in case of nested key.... | 20:11 |
| wanyen | jroll, ironic takes incremental approach for other features as well. I see 'todo' quite often | 20:11 |
| jroll | Nisha: ok, after reading the spec... why aren't we just doing something like node.instance_info['capabilities'] = flavor.extra['capabilities'] | 20:12 |
| jroll | Nisha: and let ironic handle everything | 20:12 |
| jroll | Nisha: ironic doesn't need to support every possible option nova passes, but I tend to think we should just pass it along directly | 20:13 |
| jroll | Nisha: this is what the spec says as well, as far as I can tell | 20:13 |
| devananda | jroll: that's my understanding after reviewing the spec again, too | 20:13 |
| Nisha | yes, but at that time we didnt know the operators case :( | 20:14 |
| openstackgerrit | OpenStack Proposal Bot proposed openstack/python-ironicclient: Updated from global requirements https://review.openstack.org/155583 | 20:14 |
| Nisha | we always thought it is exact match :( | 20:14 |
| jroll | Nisha: so pass the operators along too, and let ironic handle it? | 20:14 |
| Nisha | jroll, ++ | 20:14 |
| jroll | alternatively lay that out in the spec, because it's clearly contentious | 20:14 |
| devananda | Nisha: but nova reviewers did when they approved the spec | 20:15 |
| devananda | Nisha: if that's not what you expected, the spec should have been revisited | 20:15 |
| Nisha | devananda, :( | 20:15 |
| devananda | Nisha: proposing to use a feature, then actually only use a subset of that feature without documenting that you're only supporting a small subset of it .... | 20:16 |
| devananda | Nisha: I'm sorry, but that looks fairly poor and last-minute right now :( | 20:16 |
| wanyen | Nisah, as Jroll, suggested pass all capability info to ironic and ironic can error out the unspported operator or nested cap | 20:16 |
| Nisha | since ironic itself is inot capable to have nested capabilities keys, is it ok to error out in ironic virt driver in that case? anyway the code will not hit till ironic supports nested capability key | 20:17 |
| Nisha | wanyen yes | 20:17 |
| Nisha | devananda, is above fine? | 20:17 |
| devananda | jroll: as far as ironic handling the entire range of nova's capabilities -- at what point do you see Ironic type checking this data? | 20:18 |
| jroll | devananda: I haven't thought that far ahead yet | 20:18 |
| devananda | jroll: usually we type check input at the API layer. this sounds like it is driver-specific. which is, IMO, bad form | 20:18 |
| devananda | jroll: :( | 20:18 |
| jroll | mmm. | 20:18 |
| jroll | yeah | 20:18 |
| devananda | jroll: even if we exclude the possibliity of nested caps, we're still left with two problems | 20:18 |
| Nisha | devananda, which two? | 20:19 |
| jroll | devananda: I don't really see a good solution to that, though. which is lame. | 20:19 |
| devananda | - operators (==, !=, <, >, ...), requested capabilities (on node.instance_info) and actual capabilities (on node.properties) that need to be evaluated at some layer | 20:19 |
| *** athomas has quit IRC | 20:20 | |
| Nisha | yes true | 20:20 |
| devananda | - the failure mode where a deploy is requested and the driver can not enforce the requested capabilities, even if they matched the operator check above | 20:20 |
| devananda | the latter one we already have to deal with (though I'm not sure how you were planning to, Nisha) | 20:20 |
| devananda | the former one is entirely new | 20:21 |
| Nisha | devananda, i didnt get latter one...why driver will not be able to enforce it , if the ndoe is selected? | 20:21 |
| openstackgerrit | Josh Gachnang proposed openstack/ironic: Implement Cleaning States https://review.openstack.org/153444 | 20:22 |
| devananda | the whole point of driver capabilities was to allow drivers to expose different sets of capabilities that they support | 20:22 |
| devananda | and allow the scheduler to find nodes appropriately | 20:22 |
| devananda | that's /separate/ from this, right? except if we're passing the whole flavor extra specs down to Ironic, is it? | 20:23 |
| * devananda might be confused | 20:23 | |
| Nisha | the node got selected because capabilities matched. but yes if two or more capabilities are given and node is selected then one has to take prefernece if they change/deal with the same hardware property | 20:23 |
| Nisha | yes | 20:24 |
| Nisha | thats seperate | 20:24 |
| jroll | how are driver capabilities exposed to nova? | 20:24 |
| Nisha | right now its only enabling nova to select the node | 20:24 |
| wanyen | Nisah, isn't flavor telling ironic why the node get selected? | 20:24 |
| jroll | or are they not, and thus we cannot schedule against them | 20:24 |
| devananda | Nisha: scheduler matching uses the operators, though. so Ironic has to evaluate those in the same way ... | 20:24 |
| devananda | jroll: node.properties.capabilities | 20:25 |
| openstackgerrit | Josh Gachnang proposed openstack/ironic: Implement Cleaning States https://review.openstack.org/153444 | 20:25 |
| jroll | devananda: that seems like node capabilities, are driver capabilities added to that? | 20:25 |
| devananda | jroll: that field is interpolated by nova.virt.ironic.driver | 20:25 |
| Nisha | jroll, through inspection some capabilities gets populated which can be used for scheduling | 20:26 |
| devananda | eh... right, driver capabilities. I used the wrong word earlier -- I don't think we've implemented that | 20:26 |
| devananda | I meant node capabilities | 20:26 |
| jroll | ok. | 20:26 |
| wanyen | deva, nova supposed to match flavor with node capabilitites and it should take operator as part of the matching. right? | 20:26 |
| Nisha | devananda, yes ironic will have to evaluate | 20:26 |
| devananda | wanyen: right. taht's all part of the nova scheduler | 20:26 |
| devananda | Nisha: this is what confused me so much about dropping the operators. you *cant* do that | 20:27 |
| devananda | beacuse Nova already used those to determine which node to select | 20:27 |
| wanyen | deva, what will ironic driver need to evaluate oeprator? | 20:27 |
| * NobodyCam is back | 20:27 | |
| Nisha | devananda, now i am confused :( | 20:27 |
| devananda | removing the operators before passing it to Ironic could result in a node that doesn't meet the requirements | 20:27 |
| Nisha | devananda, yes | 20:27 |
| devananda | ok, example | 20:27 |
| Nisha | ++ | 20:27 |
| jroll | devananda: by the time it gets to ironic, we've got it narrowed down to one node | 20:28 |
| * jroll is trying to think of an example that wouldn't work | 20:28 | |
| Nisha | jroll, yes | 20:28 |
| Nisha | instance_info applies to one node | 20:28 |
| Nisha | so when nova has populated that means now ironic has to take further action | 20:28 |
| openstackgerrit | John L. Villalovos proposed openstack/ironic-specs: Use the term 'stable state' instead of 'passive state' https://review.openstack.org/156655 | 20:28 |
| wanyen | by the time it gets to ironic, nova has choosen a node | 20:29 |
| jroll | Nisha: what would be put into instance_info if the capability for the flavor is "<in> bios,uefi" | 20:29 |
| Nisha | jroll, the above example is wrong | 20:29 |
| Nisha | for <in> operator you can have a single value | 20:29 |
| Nisha | that said it will be | 20:29 |
| jroll | oh, I see | 20:29 |
| jroll | and the node exposes bios,uefi | 20:29 |
| Nisha | '<in> bios' | 20:29 |
| jroll | and for <in> bios it could pick that node | 20:30 |
| Nisha | yes | 20:30 |
| jroll | right, ok | 20:30 |
| Nisha | jroll, yes | 20:30 |
| devananda | node.properties.capabilities == {'boot_mode': 'uefi', 'turbo': 'on', 'storage_type': 'hdd'} && nova flavor.extra_specs ['capabilities:turbo': '<in> on,off', 'capabilities:boot_mode': 'uefi', 'capabilities:storage_type': '!= ssd'} | 20:30 |
| wanyen | based on instance instance_info, said bios, the ironic driver will deploy bios | 20:30 |
| devananda | that will match in the nova scheduler | 20:30 |
| devananda | but if you strip off the operators <in> and != | 20:30 |
| devananda | it will not match in Ironic | 20:30 |
| devananda | it will fail both on turbo setting and storage_type | 20:31 |
| Nisha | devananda, yes totally agreed not to strip operators | 20:31 |
| wanyen | deva, ironic driver will just see that boot_mode=uefi in instance info and perform uefi mode | 20:31 |
| Nisha | devananda, above example is from some testcase? | 20:32 |
| jroll | I just keep getting more confused about this | 20:32 |
| devananda | wanyen: no, it wont | 20:32 |
| * jroll reads nova docs | 20:32 | |
| devananda | Nisha: I made up the example just now | 20:32 |
| Nisha | devananda, :) | 20:32 |
| devananda | wanyen: nova isn't setting node.instance_info['boot_mode': 'uefi'] | 20:32 |
| devananda | wanyen: *isn't just setting ... | 20:33 |
| Nisha | wanyen with this discussion instance_info will have 'boot_mode': '<in> uefi' | 20:33 |
| devananda | it would also be setting the other two | 20:33 |
| Nisha | devananda, yes | 20:33 |
| jroll | extra_specs is completely unstructured eh | 20:33 |
| devananda | and ironic will need to interpolate "turbo: <in> on,off" and "storage_type: != ssd" as well | 20:33 |
| Nisha | jroll, yeah | 20:33 |
| devananda | which is not something we currently do, nor have a spec for | 20:33 |
| devananda | jroll: yes | 20:34 |
| devananda | jroll: well no | 20:34 |
| devananda | jroll: it has some very loose structure defined | 20:34 |
| Nisha | devananda, "turbo : <all-in> on,off" | 20:34 |
| wanyen | deav, ironic needs toact on all capabilitites specified but Nova did the node selection. right? | 20:34 |
| jroll | devananda: I'm just going source-diving | 20:34 |
| Nisha | yes | 20:35 |
| Nisha | :) | 20:35 |
| devananda | wanyen: that is my understanding, yes | 20:35 |
| jroll | '=': lambda x, y: float(x) >= float(y), | 20:35 |
| jroll | that's fun | 20:35 |
| devananda | either we pass the entire field down from nova -- and then interpolate it in Ironic | 20:35 |
| Nisha | devananda, ++ | 20:35 |
| wanyen | deva, as long as driver know how to hander its supprted capability, what wouldbe the problem? | 20:35 |
| devananda | or we clearly declare, in the nova driver, what is (and is not) allowed -- and then pass only that down | 20:36 |
| *** achanda has quit IRC | 20:36 | |
| devananda | wanyen: the problem is validation. this should not be implemented uniquely within each driver in Ironic | 20:36 |
| devananda | wanyen: non-discoverable variations in behavior between drivers is bad for operators | 20:37 |
| Nisha | devananda, with second option the deploy will fail saying unspported flavor value used? | 20:37 |
| devananda | wanyen: if we can validate the request before actually trying to do a deploy -- that's great. | 20:37 |
| Nisha | devananda, but the node is specific to a driver | 20:38 |
| Nisha | how it can be outside driver | 20:38 |
| devananda | Nisha: sure. and even some nodes managed by the same driver will have different capabilities | 20:38 |
| Nisha | devananda, yes true | 20:38 |
| jroll | deploy validation is syncronous, yes? and reaches into the driver? | 20:38 |
| devananda | Nisha: but the interface for determining whether the requested capabilities are valid for that node should be common across drivers | 20:38 |
| jroll | imbw | 20:39 |
| devananda | jroll: it calls node.driver.deploy.validate() synchronously - yes | 20:39 |
| wanyen | deva, It can be done via common lib | 20:39 |
| Nisha | devananda, that sounds like doing outside the driver layer when it has to be common across all drivers | 20:40 |
| *** andreykurilin_ has quit IRC | 20:40 | |
| jroll | devananda: yeah, so I think we can handle validation there, seems fine | 20:40 |
| devananda | jroll: I may have worded that poorly. this is something JayF and I have talked about several times. | 20:40 |
| Nisha | devananda, am not so sure how it should be handles | 20:40 |
| *** andreykurilin_ has joined #openstack-ironic | 20:40 | |
| devananda | I would like capabilities to be abstracted in some way and NOT left solely up to the driver | 20:40 |
| jroll | devananda: yeah, agree there | 20:41 |
| devananda | an off the cuff and silly example of what I *dont* want: ilo driver to use "boot_mode: uefi" and the drac driver to use "boot-mode: Uefi" | 20:41 |
| Nisha | devananda, that means we should have a seperate end point for capabilities | 20:41 |
| jroll | for the purposes of the nova driver change, I think we can all agree that the virt driver should pass along all extra specs with operators attached and we can deal with ironic when we get there | 20:42 |
| wanyen | deva, each driver may support differnt capabiltites. We can have common library to parse capabilities | 20:42 |
| devananda | jroll: yes. except one more thing -- I want validation of the passed parameters to happen at the API layer, not in the conductor | 20:42 |
| jroll | devananda: sure, that's tangential to this change | 20:43 |
| jroll | devananda: we have an extra month to think about ironic compared to this nova stuff | 20:43 |
| jroll | not tangential, but you get what I mean | 20:43 |
| devananda | jroll: not really. people are going to start using this -- and passing arbitrary, vendor-specific things through this mechanism, with no validation | 20:43 |
| devananda | jroll: it will "just work" with their downstream changes, but not be portable, and we'll be guaranteed to break it soon | 20:43 |
| devananda | and then folks will complain that we aren't offering backwards-compat | 20:44 |
| jroll | devananda: we can't reasonably support downstream changes, if it breaks it's their fault | 20:44 |
| devananda | that is the problemw ith landing changes like this in Nova | 20:44 |
| jroll | devananda: there's no code in ironic to handle this stuff right now | 20:44 |
| jroll | devananda: if we cared about downstream changes I would throw a fit about using CLEANING over DECOMMISSIONING | 20:44 |
| devananda | jroll: again, poor choice of words. by downstream changes I mean their local use of flavor extra specs | 20:45 |
| devananda | which is a completely permissible operator change | 20:45 |
| jroll | devananda: in out of tree drivers or? | 20:45 |
| devananda | jroll: nah. doesn't need to be in a driver. just set in node.properties['capabilities'] | 20:45 |
| devananda | actually | 20:45 |
| devananda | yes | 20:46 |
| devananda | the UEFI stuff | 20:46 |
| jroll | devananda: blah | 20:46 |
| jroll | devananda: maybe before this lands we ninja in a change that does the validation | 20:46 |
| jroll | starting with if node.instance_info.get('capabilities'): raise... | 20:46 |
| jroll | since we don't support any yet afaik | 20:46 |
| Nisha | jroll, but local boot uses it | 20:47 |
| jroll | actually, we might support uefi or localboot today, validate those, drop anything else | 20:47 |
| jroll | right | 20:47 |
| Nisha | which got merged last week | 20:47 |
| jroll | so we allow localboot | 20:47 |
| jroll | nothing else | 20:47 |
| jroll | when something lands to support uefi, we do it | 20:47 |
| Nisha | and secureboot also uses | 20:47 |
| wanyen | jroll, why limited tolocal boot? | 20:48 |
| jroll | do you not understand my point | 20:48 |
| *** Marga_ has joined #openstack-ironic | 20:48 | |
| jroll | validate what we have today | 20:48 |
| jroll | block everything else | 20:48 |
| jroll | add as needed | 20:48 |
| jroll | it's likely not the best way to deal with this but it is better than allow everything | 20:48 |
| wanyen | jroll, ok. We should allow secure boot and trusted boot then | 20:48 |
| Nisha | boot modes? | 20:49 |
| wanyen | nisah, that's uefi stugg | 20:49 |
| wanyen | s/stugg/stuff | 20:49 |
| Nisha | wanyen, so its ok to block at validate layer? | 20:49 |
| jroll | I only see localboot using capabilities afaict | 20:50 |
| Nisha | yes, and secure boot code in review also uses it | 20:50 |
| jroll | right, and that code can also patch the validation to add secure boot | 20:50 |
| wanyen | jroll, uefi, secureboot and trusted boot also need to use capability | 20:50 |
| jroll | wanyen: they can add it. | 20:51 |
| jroll | I'm not going to provide backwards compat for a feature in review | 20:51 |
| *** jgrimm is now known as zz_jgrimm | 20:51 | |
| Nisha | jroll, fine. so do we agree that ironic virt driver will not handle nested capability keys as of now? | 20:52 |
| jroll | I have no idea what nested capability keys are, so I don't know. | 20:52 |
| jroll | I don't see support for it in the scheduler filter | 20:52 |
| jroll | afaict | 20:52 |
| jroll | https://github.com/openstack/nova/blob/master/nova/scheduler/filters/extra_specs_ops.py | 20:53 |
| Nisha | nested capability at node should look like | 20:53 |
| Nisha | {'stats': {'opt1': {'a': 1, 'b': {'aa': 2}}, 'opt2': 2}} | 20:53 |
| Nisha | at flavor it can be like this | 20:53 |
| Nisha | 'opt1:a': '1', 'capabilities:opt1:b:aa': '2', | 20:53 |
| Nisha | 'trust:trusted_host': 'true' | 20:53 |
| jroll | Nisha: is that something nova supports today? | 20:53 |
| Nisha | jroll its supported | 20:53 |
| Nisha | yes | 20:53 |
| jroll | and if so, how does it schedule on them | 20:53 |
| Nisha | i copied above from a test case in "nova/tests/unit/scheduler/filters/test_compute_capabilities_filters.py" | 20:54 |
| jroll | ok | 20:54 |
| Nisha | the node selection is done compute_capabilities filter | 20:54 |
| wanyen | nisha, I think it's reasonable to error out with not supported for now snce ironic does not have a use case yet | 20:55 |
| Nisha | wanyen, ++ | 20:55 |
| wanyen | it seems complicated and we don't want to rush it in | 20:55 |
| Nisha | wanyen, plus ironic doesnt has such nested capabilities supported right now | 20:56 |
| Nisha | ironic virt driver computes the capability as a string before passing it to nova for scheduler to consume it | 20:57 |
| wanyen | deva and jroll, is it ok not to support nested cap in K | 20:57 |
| openstackgerrit | Jim Rollenhagen proposed openstack/ironic: WIP: POC to validate capabilities https://review.openstack.org/156768 | 20:57 |
| jroll | devananda: here's what I had in mind for doing this, if we land it before nova then things should work out | 20:58 |
| jroll | wanyen: it's likely fine, we can talk about it later | 20:58 |
| *** zz_jgrimm is now known as jgrimm | 20:58 | |
| wanyen | jroll, tx. we need to merge nova code by Feb. 20 midnight UTC that's why we like to get agreement | 20:59 |
| jroll | wanyen: right. | 20:59 |
| jroll | Nisha: wanyen: we can pass along the nested stuff to ironic and decide from there | 20:59 |
| Nisha | jroll, i a not sure how to deal with nested stuff in nova right now | 21:00 |
| Nisha | jroll, i am not sure how to deal with nested stuff in nova right now | 21:00 |
| devananda | wanyen: I agree that we should error, in the nova.virt.ironic driver, on any nested capabilities passed in. For now. | 21:00 |
| Nisha | devananda, thanks | 21:01 |
| wanyen | deva, ty | 21:01 |
| jroll | Nisha: maybe pass it along in the same format | 21:01 |
| jroll | oh, or that | 21:01 |
| devananda | BadCub_: if you're around, please jump in to #openstack-meeting for the cross project meeting | 21:01 |
| devananda | BadCub_: probably nothing to do but watch and learn today | 21:02 |
| jroll | oh, I've been meaning to lurk there | 21:02 |
| devananda | jroll: yes. something like that, but ofc a little cleaner :) | 21:02 |
| Nisha | jroll, yes that can be done that said the instance_info will have 'key1:subkey' : '<op> value' | 21:03 |
| jroll | devananda: sure, just throwing it up | 21:03 |
| devananda | jroll: we should maybe define the acceptable caps ironic/common/capabilities.py ... or something | 21:03 |
| jroll | right | 21:03 |
| devananda | jroll: but the idea, yes | 21:03 |
| jroll | idk, do you want me to pursue it? | 21:03 |
| jroll | would be nice to have before nova change merges | 21:03 |
| wanyen | jroll, if we error out nested cap in ironic virt driver, why to pass it to ironic? | 21:07 |
| jlvillal | rloo: I added the original author of the spec to https://review.openstack.org/#/c/156655/ and hopefully I answered your questions. | 21:08 |
| jroll | wanyen: I'm saying do one or the other, not both | 21:08 |
| wanyen | jroll, I see. I think we will error it out in ironic virt driver. | 21:10 |
| jroll | that's fine | 21:11 |
| jroll | I think we could avoid it an error on the ironic side, but I guess it doesn't matter | 21:11 |
| jroll | devananda: do you want me to continue pursuing that validation patch? | 21:11 |
| rloo | jlvillal: thx. the reason for leaving 'passive' in the spec is because it had been there before, and it shows better (to me) the diff between active states and 'stable' states. | 21:11 |
| devananda | jroll: please | 21:11 |
| *** achanda has joined #openstack-ironic | 21:11 | |
| *** achanda has quit IRC | 21:11 | |
| jroll | devananda: ok, I kind of wonder about out-of-tree drivers, but they can patch capabilities.py downstream | 21:12 |
| devananda | wanyen: we should error on nested caps in the nova.virt.ironic driver, yes. but the work jroll just proposed further establishes a set of supported capabilities, and enforces them in ironic's API service | 21:12 |
| *** achanda has joined #openstack-ironic | 21:12 | |
| devananda | jroll: the /right/ approach is for us to somehow expose that set via the REST API ... but | 21:12 |
| devananda | but that's not designed yet | 21:12 |
| jroll | me thinks everyone should read this, or at least the cores https://review.openstack.org/#/c/150653/ | 21:12 |
| wanyen | deva, that's fine. | 21:13 |
| jroll | devananda: right, agree, also do you want api bump for this? that would allow setting anything you want depending on api version so I'm thinking not | 21:13 |
| devananda | yes | 21:13 |
| devananda | i mean | 21:13 |
| devananda | "yes everyone should read that" :) | 21:13 |
| Shrews | jroll: yes. read it. loved it. | 21:14 |
| jroll | heh | 21:14 |
| jroll | ikr | 21:14 |
| jroll | now I just need 30 hour days | 21:14 |
| jlvillal | rloo: Okay, I will put passive in there. | 21:15 |
| jlvillal | :) | 21:15 |
| rloo | thx jlvillal | 21:16 |
| jlvillal | rloo: Are you okay with "stable (aka passive)" ? | 21:17 |
| wanyen | deva, just need a clrification, ironic can limit what capabilities that requires action from ironic driver but user should be able to define other capabilities that only used for scheduling purpose, e.g., finding a machine with specified server model, nic capacities, etc... right? | 21:17 |
| jroll | wanyen: hrm, that's a good point | 21:17 |
| rloo | jlvillal: yeah, although 'aka' -> 'or' is ok with you? Not sure if people know what 'aka' means. | 21:17 |
| jroll | blah | 21:18 |
| jroll | devananda: wrt wanyen's point, my thing won't work :| | 21:18 |
| jlvillal | rloo: I like 'aka' better (Also Known As). But I can do 'or' :) | 21:18 |
| jroll | unless we have an api to get valid capabilities to be passed to ironic... that could get fragile | 21:18 |
| jroll | jlvillal: gotta think about non-native english speakers | 21:19 |
| rloo | jlvillal: hmm, maybe we don't want aka then, if you really want to call them 'stable'. I'm not sure I like 'stable', but I don't want to spend too much time thinking of something better. | 21:19 |
| jlvillal | rloo: jroll: I'll go with 'or' | 21:19 |
| devananda | wanyen: urgh... | 21:22 |
| devananda | wanyen: how does the nova.virt.ironic driver know which capabilities to pass down to Ironic? | 21:22 |
| devananda | wanyen: or if it passes them all, how does Ironic know which ones to assert on the node? | 21:22 |
| *** LiveOne_ has joined #openstack-ironic | 21:22 | |
| openstackgerrit | John L. Villalovos proposed openstack/ironic-specs: Use the term 'stable state' instead of 'passive state' https://review.openstack.org/156655 | 21:23 |
| wanyen | deva, I think it will depends on driver. driver know whick one needs toact on vs. not | 21:23 |
| devananda | if Nova psses 10 capabilities down to Ironic, silently ignoring 9 of them, and only using the "boot_mode" capability, would be undiscoverable and unacceptable behavior | 21:23 |
| devananda | wanyen: driver can not just choose to ignore a bunch of things taht were requested by the user (ie, by nova) | 21:24 |
| *** Marga_ has quit IRC | 21:24 | |
| devananda | urgh, well, except that actually, today, if I pass inkey:value pairs, they are just ignored .... | 21:25 |
| *** Marga_ has joined #openstack-ironic | 21:25 | |
| wanyen | deva, driver is not ignoring them bu t it know which one requires action. | 21:25 |
| *** Marga_ has quit IRC | 21:25 | |
| devananda | wanyen: as a user, how would I know which ones the driver acted on, and which it did not? | 21:25 |
| *** Marga_ has joined #openstack-ironic | 21:25 | |
| wanyen | deva, user does not need to know. | 21:25 |
| devananda | wanyen: !?!? | 21:25 |
| wanyen | deva, as long as node is selected and the action is taken for the capabilities that requie work in driver, that should be fine. right? | 21:26 |
| *** LiveOne_ has left #openstack-ironic | 21:26 | |
| devananda | wanyen: "and the action is taken" -- how does the user know if the action they requested WAS taken? | 21:27 |
| devananda | wanyen: what if the user asks for turbo mode, and the driver doesn't support it -- in your proposal, it would silently ignore that requset | 21:27 |
| wanyen | deva, it will be whether the deploy is successful they way they expect. | 21:27 |
| devananda | wanyen: as a user, that is never what I want | 21:27 |
| devananda | wanyen: so the user has to log into the machine and manually check if all the things they requested were done? .... | 21:28 |
| wanyen | deva, if driver does not support turbo mode, it should returns a not supoorted error | 21:28 |
| devananda | wanyen: I agree - it should error. | 21:28 |
| devananda | wanyen: except that's not what you said a minute ago | 21:29 |
| wanyen | deva, I meant if the flavor is only for scheduling purpose such as specific server model, then driver will have no op but for unsupported caps, it should error out. | 21:30 |
| devananda | jroll: if ironic were to expose valid_capabilities.keys() in some way, so nova only passed those caps (and then used all others only for scheduling purposes) | 21:32 |
| jroll | 21:18:54 jroll | unless we have an api to get valid capabilities to be passed to ironic... that could get fragile | 21:32 |
| jroll | :) | 21:32 |
| devananda | ... | 21:32 |
| devananda | right | 21:32 |
| jroll | so we do need an api for this | 21:33 |
| devananda | ok. i feel like I understand this now. sorry if I'm a bit slower than others today | 21:33 |
| jroll | so who wants to write the spec for this api endpoint? | 21:36 |
| Nisha | devananda, I plan to not error out for nested capabilities.... | 21:36 |
| devananda | jroll: going that route is a much larger change in the nova virt driver, and i'm fairly sure would not make it in this cycle | 21:36 |
| jroll | devananda: yeah, agree | 21:37 |
| devananda | jroll: so, is there a middle ground we can do now, to get enough support for UEFI in, without making upgrades broken in the future? | 21:37 |
| devananda | remember, what ever we land in nova now, we'll need Ironic's API to continue to support for 12 months | 21:38 |
| jroll | devananda: right, I'm scared | 21:38 |
| devananda | :( | 21:38 |
| JayF | To ask a blunt question: HP seems to care a lot about this; why not downstream it for K then upstream for L? | 21:39 |
| JayF | like we did for a lot of the early agent features | 21:39 |
| devananda | wanyen: ^ ? | 21:39 |
| JayF | I know it's not perfect, but it's better than rushing to form an API contract we might regret | 21:39 |
| JayF | and us running some of the stuff downstream led to a better version upstream | 21:40 |
| wanyen | we would really like to be able to support secuer boot, local boot options for K | 21:40 |
| jroll | but does it need to be *upstream* in K? | 21:43 |
| jroll | (not voicing an opinion here, just asking) | 21:43 |
| jroll | wanyen: ^ | 21:43 |
| NobodyCam | brb | 21:44 |
| wanyen | jroll, upstream in K is much preferable. | 21:44 |
| * mrda is always wary on prematurely agreeing on a public API | 21:44 | |
| JayF | mrda: that's mainly where I'm coming from. I feel like if there was 2 hours of IRC discussion about it, there should be something more permanent (like ML or spec) to nail it down | 21:45 |
| JayF | and/or improve the existing spec so folks know *exactly* what's being implemented | 21:45 |
| jroll | wanyen: of course, I also tend to think this isn't near ready | 21:47 |
| mrda | JayF: I've just been burned too many times when afterwards I realise I haven't considered everything | 21:47 |
| wanyen | jroll, so with your API idea, can it be checked at ironic rather than at ironic virt dirver? | 21:47 |
| jroll | wanyen: no, at ironic we're validating which capabilities drivers can handle, but nova is passing all of them | 21:48 |
| wanyen | jroll, can conductor check? | 21:49 |
| rloo | fwiw, lucas-dinner has some feature/change that needs capabilities passed from nova too | 21:49 |
| jroll | wanyen: that... doesn't help? | 21:49 |
| jroll | rloo: yeah, localboot | 21:49 |
| Nisha | jroll, so whats the consclusion | 21:50 |
| jroll | wanyen: we want to validate at the API layer that ironic can handle all capabilities passed to it. so nova needs to know what to pass to it. | 21:50 |
| jroll | Nisha: there is no conclusion (yet) | 21:50 |
| Nisha | i am confused what to pursue for nova patch | 21:50 |
| Nisha | :( | 21:50 |
| Nisha | i have done the changes to pass entire capabilities to instance_info (even nestedkey) | 21:51 |
| Nisha | befre posting the patch wanted an opinion | 21:51 |
| rloo | jroll: w/o the API part, seems like the only thing we can do in the next few days is to 'hardcode' in the ironic.driver, the actual capabilities that ironic will handle in the near future. that still doesn't handle how the user knows they didn't get turbo whatever, unless we also error from the nova.ironic.driver if other capabilities are specified. | 21:52 |
| wanyen | nisha, we were discussing how to differentiate cap for scheduling only and cap that requires action from driver | 21:52 |
| jroll | rloo: that isn't the worst idea | 21:53 |
| Nisha | wanyen, i read it but if it requires changes more than what is there in nova spec, then the changes will not go in K | 21:53 |
| wanyen | nisha, there is not way to differntiate them. right? | 21:53 |
| jroll | Nisha: go ahead and push that patch, we can go from there | 21:53 |
| wanyen | s/not/no | 21:54 |
| Nisha | wanyen, No as of now ao differentiation. but may be that can be done as part of inspection | 21:54 |
| Nisha | wanyen, No as of now no differentiation. but may be that can be done as part of inspection | 21:54 |
| Nisha | jroll, ok thanks | 21:54 |
| *** eghobo has quit IRC | 21:54 | |
| wanyen | nisha, how can inspection handle that? | 21:55 |
| NobodyCam | woo hoo /me was able to get unit test kinda working again on his mac | 21:56 |
| Nisha | may be while updating capabilities to node.properties some hook could be added...not sure though...but then it will again per capability which may differ driver to driver | 21:56 |
| wanyen | nisha, yes. I think it's driver specific as well. | 21:57 |
| jroll | NobodyCam: day well spent :P | 21:57 |
| NobodyCam | uggh | 21:58 |
| Nisha | wanyen, jroll rloo devananda so as of now i post the patch with passing capabilities as it is to ironic even the nested keys as it is | 21:58 |
| jroll | Nisha: cool, thanks for that | 21:59 |
| wanyen | nisha, why you decided not to error out nested cap? | 21:59 |
| wanyen | nisah, I meant error out at ironic virt driver | 22:00 |
| Nisha | wanyen, just because its possible to code that way. In any case as of now ironic itself is not capable to have nested capabilities, so instance_info will never have such a key till ironic supports it | 22:01 |
| jlvillal | jroll: I think you did the 'oslo.config' to 'oslo_config' renaming | 22:02 |
| jroll | jlvillal: possibly | 22:02 |
| Nisha | only thing is when we dont block at nova layer , we have a way open for future to handle it within ironic whenever ironic starts supporting nested capabilities | 22:02 |
| jroll | jlvillal: that was beyond yesterday so I don't remember | 22:02 |
| jroll | Nisha: ++ | 22:02 |
| jlvillal | I noticed :) | 22:02 |
| jlvillal | s/I noticed :)/:)/ | 22:03 |
| jroll | jlvillal: had a question about it or? | 22:03 |
| jlvillal | jroll: I noticed: ironic/drivers/modules/virtualbox.py | 22:03 |
| *** Hefeweizen has quit IRC | 22:03 | |
| jroll | :P | 22:03 |
| jroll | oh, did that bring in another oslo.config | 22:03 |
| jlvillal | Should that file also be done? I was reviewing a different patch | 22:03 |
| wanyen | nisha, ++ | 22:03 |
| Nisha | jroll, wanyen thanks | 22:04 |
| jlvillal | jroll: I can do a patch for it, if it is appropriate | 22:04 |
| jroll | jlvillal: yep, it should be, probably missed inr eview | 22:04 |
| jroll | jlvillal: there's a few in there now | 22:04 |
| jlvillal | jroll: Should some remain as 'oslo.config'? | 22:04 |
| jlvillal | I did a 'git grep' and noticed a few | 22:04 |
| jlvillal | I wasn't sure if intentional or not. | 22:05 |
| jroll | jlvillal: just openstack/common/ stuff | 22:05 |
| jlvillal | openstack/common should remain 'oslo.config'? | 22:05 |
| jroll | yep | 22:05 |
| jlvillal | Everything else should be 'oslo_config | 22:05 |
| jlvillal | Everything else should be 'oslo_config' | 22:05 |
| jlvillal | Okay. Thanks! | 22:05 |
| jroll | yep! | 22:05 |
| jroll | np :) | 22:05 |
| openstackgerrit | John L. Villalovos proposed openstack/ironic: Add concept of stable states to the state machine https://review.openstack.org/155529 | 22:08 |
| openstackgerrit | John L. Villalovos proposed openstack/ironic: Move oslo.config references to oslo_config https://review.openstack.org/156797 | 22:08 |
| devananda | JayF: suggestion: make https://launchpad.net/coreos-image-builder run by the same team as IPA | 22:08 |
| devananda | JayF: oh -- https://launchpad.net/ironic-python-agent never mind | 22:08 |
| JayF | :) | 22:08 |
| devananda | JayF: so that should exist, right? | 22:09 |
| JayF | If you think we should give IPA it's own place, we can | 22:09 |
| JayF | when we originally made ipa | 22:09 |
| JayF | we said ironic would handle bugs | 22:09 |
| devananda | yea, i remember | 22:09 |
| JayF | so no lp | 22:09 |
| devananda | but IPA has artefacts which are separate from Ironic's releases | 22:09 |
| devananda | JayF: where did we end up on the "should IPA have versioned releases" discussion? | 22:10 |
| *** Hefeweizen has joined #openstack-ironic | 22:10 | |
| openstackgerrit | John L. Villalovos proposed openstack/ironic: Move oslo.config references to oslo_config https://review.openstack.org/156797 | 22:10 |
| *** achanda has quit IRC | 22:10 | |
| JayF | devananda: everytime I've been in one of those, the answer has been to punt on the question | 22:11 |
| JayF | I think it's a /very/ good candidate for a design session at Vancouver, honestly | 22:11 |
| JayF | assuming j* will all be able to go :P | 22:11 |
| devananda | JayF: IIRC, we said IPA wouldn't have versioned releases because it would produce artefacts, and the whole thing was one unified non-versioned thing | 22:11 |
| devananda | except two things have changed | 22:11 |
| devananda | a) coreos-image-builder is now separate from IPA's repo | 22:11 |
| devananda | b) zigo pointed out in grenoble that he wants to package IPA so folks can install it. he had a good reason why, which I've now forgotten | 22:12 |
| devananda | I think (b) was so folks could build their own images with it, but use debian packages to get those tools (rather than git clone) | 22:12 |
| NobodyCam | humm we dont test iscsi_deploy continue_deploy in test_iscsi_deploy | 22:13 |
| jlvillal | jroll: You are a hard man to add as a review :( | 22:13 |
| zigo | devananda: Correct. *everything* should be in Debian, otherwise, that's non-free ! :) | 22:13 |
| jlvillal | s/review/reviewer/ | 22:13 |
| devananda | JayF: ^ | 22:13 |
| JayF | zigo: I'm really curious what you'd do with an ironic-python-agent debian package, or what use case you see it being useful for | 22:13 |
| JayF | zigo: I also don't buy into the notion if debian doesn't package it, it's not free :P | 22:14 |
| Nisha | devananda, review for https://review.openstack.org/147857 (states for inspection) | 22:14 |
| jroll | jlvillal: my gerrit id is busted :/ | 22:14 |
| devananda | JayF: hm. perhaps only coreos-image-builder needs to have releases / have a debian package then | 22:14 |
| zigo | JayF: Ok, let me rephrase then. Nothing in Debian should be, IMO, relying on any external source. | 22:14 |
| openstackgerrit | Ruby Loo proposed openstack/ironic: Removed unused image file https://review.openstack.org/156800 | 22:14 |
| zigo | JayF: Everything should be self-contained in the distribution. | 22:14 |
| jlvillal | jroll: :( | 22:14 |
| * jroll looks | 22:15 | |
| zigo | JayF: If you rely on some external blobs which you can't rebuild yourself, that's IMO a very crappy situation where you have no control over things. | 22:15 |
| jroll | zigo: would you package the ironic ramdisk built by DIB? | 22:15 |
| jroll | slash do you package it? | 22:15 |
| zigo | jroll: I have packaged DIB ... | 22:15 |
| devananda | jroll: yes, debian does package it (it == all the bits to build that ramdisk) | 22:15 |
| *** korekhov has quit IRC | 22:16 | |
| zigo | jroll: I very much would like to have scripts in Debian so that it's possible to use DIB to create the ramdisk. | 22:16 |
| *** korekhov has joined #openstack-ironic | 22:16 | |
| JayF | zigo: I think what devananda said fits in this case then; coreos-image-builder should have releases | 22:16 |
| JayF | zigo: and that would build IPA ramdisks on demand | 22:16 |
| devananda | JayF: it goes a step further | 22:16 |
| zigo | Great ! :) | 22:16 |
| JayF | zigo: the tight coupling between IPA and the build system is something I'm working to change right now | 22:16 |
| zigo | Just tag a release, and ping me, and I'll package and upload in Debian. | 22:17 |
| devananda | JayF: c-i-b needs to have a release, yes, but when it builds the ramdisk, it shouldn't be pulling IPA from git | 22:17 |
| JayF | devananda: this is aside from whether or not IPA should have releases, I went from "very no" to "on the fence" about releasing | 22:17 |
| JayF | devananda: I think I'd be OK with IPA doing client-style releases, as long as we aren't on the 6 month deathmarch release :P | 22:17 |
| JayF | jroll: ^ have any opinion? | 22:17 |
| devananda | JayF: I'm glad you agree that c-i-b should have releases. and yea, both of them should be on the client model (tag when ever you want) | 22:18 |
| jroll | idk, I guess I don't care | 22:18 |
| jroll | no feature freeze pls | 22:18 |
| JayF | devananda: and when I say 'releases', I'm explicitly leaving the artifact (pip package? tarball?) up in the air | 22:18 |
| JayF | For now I have to get CIB merged at all, hehe | 22:18 |
| devananda | coreos-image-builder tags should get published on pip. it's a utility. | 22:18 |
| zigo | JayF: FYI, I had the same issue with Sahara. It uses an image which contains Hadoop, which can't be built in Debian: we don't have an Hadoop package in Debian, plus it needs a very specific DIB version. I very much would like to fix the situation, but there's not much I can do if upstream don't do things correctly (ie: if Sahara doesn't use DIB correcly, of if DIB changes too fast... I'm not sure who's at fault here...). | 22:18 |
| zigo | So, let's not have the same kind of bad issue with Ironic. ! :) | 22:19 |
| JayF | devananda: ++ I was talking about IPA when saying that | 22:19 |
| zigo | Couldn't we use openstack-debian-images to build the image? | 22:19 |
| zigo | Or embedded Debian ? :) | 22:19 |
| devananda | ironic-python-agent is a client. if I can run it in a container inside a ramdisk, why couldn't I pip install and run it locally? (ignoring the fact that it would hose my machine if I did) | 22:19 |
| JayF | zigo: part of why we're splitting builder from contents is because we want other folks to be able to build IPA in other ways, if they see fit | 22:19 |
| zigo | http://www.emdebian.org/ | 22:19 |
| JayF | zigo: You're welcome to contribute new build methods if you'd like :). I would not use such of a thing and don't have an interest in building it | 22:20 |
| zigo | "As of July 2014, updates to the Emdebian distributions ceased. There will be no further updates and no further stable releases. " <--- crap !!! :( | 22:20 |
| zigo | I didn't know about this. | 22:20 |
| JayF | devananda: To add to your argument, ironic-python-agent --standalone is a thing now | 22:20 |
| JayF | devananda: for local testing without an Ironic installation | 22:20 |
| devananda | JayF: fantastic! | 22:20 |
| * jroll imagines a ramdisk that boots up and pip installs ipa | 22:20 | |
| devananda | JayF: so yes, that definitely should have tagged versions, be on pip, and so on | 22:20 |
| JayF | devananda: (skips lookup and heartbeat, but still takes commands via REST api) | 22:20 |
| *** anderbubble has quit IRC | 22:21 | |
| JayF | devananda: /me outsources to BadCub_ | 22:21 |
| devananda | JayF: along with nice big warnings about what it does | 22:21 |
| devananda | JayF: ++ | 22:21 |
| JayF | he'll be our new secret agent man | 22:21 |
| zigo | Probably it should be possible to tweak openstack-debian-images to make a much much smaller image, but it will never be as small as coreos, for sure! | 22:21 |
| zigo | jroll: Please go to hell with your pip install ... :) | 22:22 |
| jroll | ... | 22:22 |
| jroll | a smiley face doesn't make that any less abrasive | 22:22 |
| *** jjohnson2 has quit IRC | 22:22 | |
| zigo | jroll: How about you rewrite everything in PHP, and use pear install? Or CPAN in Perl? | 22:22 |
| devananda | zigo: so as JayF said, the coreos image building scripts are being separated from the actual agent that we use in the ramdisk, to enable others to build ramdisks in different ways that embed the same agent | 22:23 |
| devananda | zigo: .... really? | 22:23 |
| jroll | right. | 22:23 |
| zigo | jroll: Sorry, it's just that my hair stands up each time I see someone talking about pip install. | 22:23 |
| zigo | jroll: I'm convince that one of the reason TrippleO is still what it is right now (eg: failing every odd days), is because it uses that. | 22:24 |
| jroll | zigo: and that makes it ok to be rude to someone that you're asking to do a thing for you? | 22:24 |
| zigo | jroll: I didn't want to appear as rude, sorry. | 22:24 |
| devananda | zigo: maybe you meant that to be humorous, but it did not parse that way to me (or, it seems, to others) | 22:26 |
| devananda | we try to be tolerant of as many different ways to do things as there are thigns to do | 22:26 |
| devananda | (and, fwiw, I used to install almost everyhing from CPAN ... and it worked far better than PIP) | 22:27 |
| zigo | Yeah, I had a big smile on my face when I wrote it, and I really didn't mean to hurt anyone. | 22:27 |
| *** achanda has joined #openstack-ironic | 22:29 | |
| jroll | jlvillal: +2 btw | 22:30 |
| jlvillal | jroll: Thanks :) | 22:30 |
| jroll | np | 22:31 |
| *** Marga_ has quit IRC | 22:32 | |
| *** Marga_ has joined #openstack-ironic | 22:32 | |
| *** anderbubble has joined #openstack-ironic | 22:35 | |
| openstackgerrit | Merged openstack/ironic: Remove docs in proprietary formats https://review.openstack.org/156554 | 22:43 |
| *** Marga_ has quit IRC | 22:44 | |
| *** sdake_ws has quit IRC | 22:44 | |
| *** Marga_ has joined #openstack-ironic | 22:44 | |
| *** andreykurilin_ has quit IRC | 22:45 | |
| *** lucas-dinner has quit IRC | 22:52 | |
| victor_lowther | So, after getting overly annoyed at devstack and not quite as peeved at dockstack, I wrote a thing: https://github.com/VictorLowther/dockonic | 22:55 |
| victor_lowther | Possibly the world's stupidest way to run Ironic in a Docker container. | 22:56 |
| jroll | victor_lowther: heh, neat | 22:57 |
| *** foexle has quit IRC | 22:58 | |
| jroll | I wrote this yesterday https://gist.github.com/jimrollenhagen/ac768558233e0e37415f | 22:58 |
| *** Marga_ has quit IRC | 23:05 | |
| *** Marga_ has joined #openstack-ironic | 23:06 | |
| *** chlong has joined #openstack-ironic | 23:08 | |
| * devananda notes that the non-glance image ref patch is > 1K LOC | 23:10 | |
| NobodyCam | devananda: quick question. on lines 515 & 516 of https://review.openstack.org/#/c/155460/4/ironic/drivers/modules/pxe.py is there a reason you used task.node instead of just node.? | 23:13 |
| devananda | NobodyCam: just habit, I guess | 23:14 |
| NobodyCam | :) | 23:14 |
| Nisha | devananda, NobodyCam reviews on inspection patches | 23:21 |
| *** yuanying has joined #openstack-ironic | 23:23 | |
| openstackgerrit | Chris Krelle proposed openstack/ironic: Correctly rebuild the PXE file during takeover of ACTIVE nodes https://review.openstack.org/155460 | 23:24 |
| NobodyCam | devananda: please take a look at the dance I had to do to get the test to pass on https://review.openstack.org/#/c/155460/5/ironic/drivers/modules/pxe.py lines 519-522 | 23:25 |
| jroll | NobodyCam: yeah, I hate that about our objects | 23:26 |
| jroll | but never found time to care enough to fix it :/ | 23:26 |
| NobodyCam | ok so hit that too.. :) | 23:26 |
| *** wanyen has quit IRC | 23:27 | |
| jroll | yeah, I think it's setattr() insanity breaking it | 23:29 |
| NobodyCam | :) we prob should file a bug for it :-p | 23:29 |
| *** anderbubble has quit IRC | 23:30 | |
| openstackgerrit | Chris Krelle proposed openstack/ironic: Correctly rebuild the PXE file during takeover of ACTIVE nodes https://review.openstack.org/155460 | 23:38 |
| NobodyCam | had white space :-p | 23:38 |
| openstackgerrit | Shiina, Hironori proposed openstack/ironic: Fix typos in documentation: Capabilities https://review.openstack.org/156425 | 23:42 |
| NobodyCam | JoshNang: you happen to see 153444 is "Patch in Merge Conflict" ? | 23:45 |
| JoshNang | NobodyCam: blah yeah, i'm not sure why it didn't ask me to rebase when i submitted :/ | 23:48 |
| JoshNang | i figured i'd take care of it when i push the dependent patch (when i finish writing the tests) | 23:48 |
| NobodyCam | sweet :) | 23:53 |
| NobodyCam | was one of the reviews in a open tab | 23:53 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!
