| *** anderbubble has quit IRC | 00:00 | |
| *** anderbubble has joined #openstack-ironic | 00:00 | |
| *** ryanpetrello has quit IRC | 00:13 | |
| *** ParsectiX has joined #openstack-ironic | 00:21 | |
| *** ParsectiX has quit IRC | 00:26 | |
| *** smoriya has joined #openstack-ironic | 00:32 | |
| *** alexpilotti has quit IRC | 00:33 | |
| *** Marga_ has joined #openstack-ironic | 00:33 | |
| *** Masahiro has joined #openstack-ironic | 00:33 | |
| *** Marga_ has quit IRC | 00:34 | |
| *** Masahiro has quit IRC | 00:38 | |
| *** zhenzanz has joined #openstack-ironic | 00:39 | |
| *** Marga_ has joined #openstack-ironic | 00:41 | |
| *** romcheg has quit IRC | 00:48 | |
| *** anderbubble has quit IRC | 00:58 | |
| *** Marga_ has quit IRC | 00:58 | |
| *** Marga_ has joined #openstack-ironic | 00:59 | |
| *** yongli has joined #openstack-ironic | 01:12 | |
| *** Guest41771 has joined #openstack-ironic | 01:14 | |
| *** Guest41771 is now known as annegentle | 01:15 | |
| *** yongli has quit IRC | 01:24 | |
| *** yongli has joined #openstack-ironic | 01:26 | |
| *** pcrews has joined #openstack-ironic | 01:36 | |
| *** nosnos has joined #openstack-ironic | 01:44 | |
| *** anderbubble has joined #openstack-ironic | 01:47 | |
| *** pcrews has quit IRC | 01:47 | |
| *** Marga_ has quit IRC | 01:56 | |
| *** yongli is now known as help | 02:03 | |
| *** help is now known as Guest40937 | 02:04 | |
| *** Guest40937 is now known as heyongli | 02:04 | |
| *** ParsectiX has joined #openstack-ironic | 02:10 | |
| *** chenglch has joined #openstack-ironic | 02:11 | |
| NobodyCam | morning mrda Haomeng|2 naohirot :) | 02:12 |
|---|---|---|
| Haomeng|2 | NobodyCam: morning | 02:12 |
| NobodyCam | :-p | 02:12 |
| naohirot | NobodyCam: good morning! | 02:12 |
| NobodyCam | :) | 02:13 |
| naohirot | NobodyCam: good evening :-) | 02:13 |
| NobodyCam | hehehe | 02:13 |
| NobodyCam | all ready for the new meeting time :) | 02:14 |
| *** Marga_ has joined #openstack-ironic | 02:14 | |
| *** ParsectiX has quit IRC | 02:14 | |
| naohirot | NobodyCam: Yes, I'm ready too. | 02:15 |
| *** ryanpetrello has joined #openstack-ironic | 02:17 | |
| naohirot | NobodyCam: Unfortunately I cannot attend the first Asian/Australia friendly meeting next week :< | 02:18 |
| *** Masahiro has joined #openstack-ironic | 02:22 | |
| mrda | NobodyCam: I didn't see the announcement. /me checks the wiki | 02:25 |
| mrda | Ahh, I give my apologies for this week's meeting. 5:30am is doable, 3:30am (the new non-Asia TZ) is not :) | 02:26 |
| *** Masahiro has quit IRC | 02:26 | |
| *** arif-ali has joined #openstack-ironic | 02:29 | |
| NobodyCam | mrda: but then next week should be much better | 02:31 |
| *** chenglch has quit IRC | 02:42 | |
| *** chenglch has joined #openstack-ironic | 02:47 | |
| mrda | NobodyCam: yes, I think it's 7:30pm at night | 02:48 |
| *** achanda has joined #openstack-ironic | 02:56 | |
| *** rushiagr_away is now known as rushiagr | 03:15 | |
| *** rushiagr is now known as rushiagr_away | 03:21 | |
| *** rushiagr_away is now known as rushiagr | 03:25 | |
| *** naohirot has quit IRC | 03:28 | |
| *** Masahiro has joined #openstack-ironic | 03:38 | |
| *** achanda has quit IRC | 03:39 | |
| *** achanda has joined #openstack-ironic | 03:39 | |
| *** achanda has quit IRC | 03:40 | |
| *** achanda has joined #openstack-ironic | 03:40 | |
| *** Masahiro has quit IRC | 03:43 | |
| *** achanda has quit IRC | 03:44 | |
| *** nosnos has quit IRC | 03:52 | |
| *** ParsectiX has joined #openstack-ironic | 03:59 | |
| *** naohirot has joined #openstack-ironic | 04:01 | |
| *** pensu has joined #openstack-ironic | 04:03 | |
| *** ParsectiX has quit IRC | 04:04 | |
| *** pensu has quit IRC | 04:11 | |
| *** Marga_ has quit IRC | 04:17 | |
| *** Masahiro has joined #openstack-ironic | 04:22 | |
| *** achanda has joined #openstack-ironic | 04:23 | |
| *** lazy_prince has quit IRC | 04:25 | |
| *** Marga_ has joined #openstack-ironic | 04:25 | |
| *** killer_prince has joined #openstack-ironic | 04:27 | |
| *** killer_prince is now known as lazy_prince | 04:27 | |
| *** ramineni has joined #openstack-ironic | 04:28 | |
| *** ryanpetrello has quit IRC | 04:28 | |
| *** heyongli has quit IRC | 04:36 | |
| *** heyongli has joined #openstack-ironic | 04:37 | |
| *** Marga__ has joined #openstack-ironic | 04:40 | |
| *** Marga_ has quit IRC | 04:44 | |
| *** nosnos has joined #openstack-ironic | 04:44 | |
| *** pradipta_away is now known as pradipta | 04:46 | |
| *** subscope has joined #openstack-ironic | 04:47 | |
| *** rushiagr is now known as rushiagr_away | 04:55 | |
| *** lazy_prince has quit IRC | 04:55 | |
| *** Masahiro has quit IRC | 04:57 | |
| *** killer_prince has joined #openstack-ironic | 04:57 | |
| *** killer_prince is now known as lazy_prince | 04:57 | |
| openstackgerrit | Naohiro Tamura proposed openstack/ironic-specs: iRMC Virtual Media Deploy Driver for Ironic https://review.openstack.org/134865 | 04:57 |
| *** ParsectiX has joined #openstack-ironic | 05:00 | |
| *** achanda has quit IRC | 05:00 | |
| *** Masahiro has joined #openstack-ironic | 05:02 | |
| *** yuanying_ has joined #openstack-ironic | 05:03 | |
| *** ParsectiX has quit IRC | 05:04 | |
| *** yuanying has quit IRC | 05:06 | |
| *** heyongli has quit IRC | 05:09 | |
| *** heyongli has joined #openstack-ironic | 05:10 | |
| *** vinbs has joined #openstack-ironic | 05:18 | |
| *** pensu has joined #openstack-ironic | 05:28 | |
| *** rushiagr_away is now known as rushiagr | 05:40 | |
| openstackgerrit | Naohiro Tamura proposed openstack/ironic-specs: iRMC Management Driver for Ironic https://review.openstack.org/136020 | 05:45 |
| openstackgerrit | Naohiro Tamura proposed openstack/ironic-specs: iRMC Power Driver for Ironic https://review.openstack.org/134487 | 05:49 |
| *** nosnos has quit IRC | 05:58 | |
| *** heyongli has quit IRC | 05:58 | |
| *** nosnos has joined #openstack-ironic | 05:58 | |
| *** ParsectiX has joined #openstack-ironic | 06:00 | |
| *** ParsectiX has quit IRC | 06:01 | |
| *** chenglch|2 has joined #openstack-ironic | 06:01 | |
| openstackgerrit | Michael Davies proposed openstack/ironic-specs: Proposal to add logical names to Ironic nodes https://review.openstack.org/134439 | 06:03 |
| *** chenglch has quit IRC | 06:04 | |
| *** heyongli has joined #openstack-ironic | 06:19 | |
| *** lazy_prince has quit IRC | 06:20 | |
| *** yonglihe has joined #openstack-ironic | 06:21 | |
| *** yonglihe has quit IRC | 06:21 | |
| *** dlpartain has joined #openstack-ironic | 06:21 | |
| *** rushiagr is now known as rushiagr_away | 06:25 | |
| *** nosnos_ has joined #openstack-ironic | 06:29 | |
| *** nosnos has quit IRC | 06:29 | |
| *** achanda has joined #openstack-ironic | 06:35 | |
| *** subscope has quit IRC | 06:47 | |
| *** dlpartain has quit IRC | 06:48 | |
| *** Marga__ has quit IRC | 06:53 | |
| *** rushiagr_away is now known as rushiagr | 06:54 | |
| *** chenglch|2 has quit IRC | 06:57 | |
| *** heyongli has quit IRC | 06:59 | |
| *** achanda has quit IRC | 06:59 | |
| *** achanda has joined #openstack-ironic | 07:00 | |
| *** chenglch has joined #openstack-ironic | 07:04 | |
| *** achanda has quit IRC | 07:05 | |
| *** Masahiro has quit IRC | 07:06 | |
| *** Masahiro has joined #openstack-ironic | 07:10 | |
| *** rameshg87 has joined #openstack-ironic | 07:14 | |
| *** Nisha has joined #openstack-ironic | 07:23 | |
| *** jcoufal has joined #openstack-ironic | 07:24 | |
| *** k4n0 has joined #openstack-ironic | 07:24 | |
| rameshg87 | naohirot, hi | 07:27 |
| naohirot | rameshg87: Hi | 07:27 |
| rameshg87 | naohirot, i have proposed to refactor the current virtual media driver to abstract out the virtual-media-implementation | 07:29 |
| rameshg87 | naohirot, i need it for adding support for testing virtual-media with vms | 07:29 |
| rameshg87 | naohirot, https://review.openstack.org/#/c/137933/ | 07:29 |
| rameshg87 | naohirot, i think your driver for iRMC can also make use of the virtual media driver once it is abstracted out | 07:29 |
| * naohirot reading the spec | 07:29 | |
| * naohirot read through once | 07:34 | |
| naohirot | rameshg87: Is it solely for testing purpose? | 07:35 |
| rameshg87 | naohirot, i would like to refactor it out because i want to add virtual media support in vms | 07:35 |
| rameshg87 | naohirot, if i refactor virtual-media-implementation out of the virtual-media driver, then i think it can be used by you also | 07:36 |
| rameshg87 | naohirot, main difference of iLO vs iRMC it attaches as virtual media - iLO needs http whereas iRMC needs nfs | 07:37 |
| rameshg87 | naohirot, if we abstract how to connect a file as virtual media OR how to connect a glance image as virtual media, then the rest is common | 07:37 |
| naohirot | rameshg87: Yes, I understood your intention of refactoring, but my question is "is it for facilitating the virtual media testing?" | 07:38 |
| rameshg87 | naohirot, yes | 07:38 |
| rameshg87 | naohirot, that's my intention :) | 07:38 |
| naohirot | rameshg87: Okay, I understood the purpose too. | 07:40 |
| naohirot | rameshg87: "if we abstract how to connect a file as virtual media OR how to connect a glance image as virtual media", in this sentence | 07:42 |
| naohirot | rameshg87: I can imagine "how to connect a file as virtual media" | 07:42 |
| *** killer_prince has joined #openstack-ironic | 07:42 | |
| *** killer_prince has quit IRC | 07:42 | |
| naohirot | rameshg87: but I cannot imagine "how to connect a glance image as virtual media", is it possible? | 07:43 |
| *** lazy_prince has joined #openstack-ironic | 07:43 | |
| *** lazy_prince has quit IRC | 07:43 | |
| naohirot | rameshg87: because iRMC cannot deal with HTTP | 07:43 |
| *** lazy_prince has joined #openstack-ironic | 07:44 | |
| rameshg87 | naohirot, yeah, that's my point with virtual media as well | 07:44 |
| rameshg87 | naohirot, even kvm virtual machine cannot connect glance image as virtual media | 07:45 |
| rameshg87 | naohirot, kvm virtual machine can attach only a local file on the host as virtual media | 07:45 |
| naohirot | rameshg87: Aha, the abstracted layer converts "mount request" to either HTTP for iLO or NFS for iRMC? | 07:45 |
| rameshg87 | naohirot, yes | 07:45 |
| rameshg87 | naohirot, so it's upto respective drivers to implement this portion | 07:46 |
| rameshg87 | naohirot, you may implement to download the glance image to conductor and expose to the nodes over nfs | 07:47 |
| naohirot | rameshg87: Okay, that's nice :) | 07:47 |
| rameshg87 | naohirot, even for virtual machines i might need to do the same thing | 07:47 |
| rameshg87 | naohirot, i am planning to propose a single shared filesystem across all conductor and all virtual machine hosts | 07:47 |
| rameshg87 | naohirot, let's call it <SHARED> | 07:48 |
| naohirot | rameshg87: how do you make KVM mount iLO virtual media? | 07:48 |
| rameshg87 | naohirot, each conductor can have a directory inside <SHARED> | 07:48 |
| rameshg87 | naohirot, if a conductor wants to expose a glance image as virtual media | 07:48 |
| rameshg87 | naohirot, it will download the image and put it inside <SHARED>/<CONDUCTOR-NAME>/<NODE-UUID>/image | 07:49 |
| rameshg87 | naohirot, the same will be accessible on the kvm host as well | 07:49 |
| rameshg87 | naohirot, since nfs support soft-links, we can create an ImageCache within <SHARED>/<CONDUCTOR-NAME>/ which will enable to share images for several vms managed by a single conductor | 07:50 |
| naohirot | rameshg87: I see, coping glance image into the <SHARED> enable for KVM to mount? | 07:51 |
| *** pradipta is now known as pradipta_away | 07:51 | |
| rameshg87 | naohirot, yeah because <SHARED> is visible in kvm host as well | 07:51 |
| naohirot | rameshg87: what kind of protocol does KVM use to mount the image in <SHARED>? | 07:52 |
| naohirot | rameshg87: Aha, KVM host mount the <SHARE> as a local file system via NFS, but not KVM guest. | 07:54 |
| *** andreykurilin_ has joined #openstack-ironic | 07:55 | |
| rameshg87 | naohirot, yes | 07:55 |
| rameshg87 | naohirot, anything inside <SHARED> will be seen as a local file | 07:55 |
| rameshg87 | naohirot, so we can attach anything inside <SHARED> as virtual media to kvm guests | 07:56 |
| naohirot | rameshg87: that's good, I like the idea <SHARED> :-) | 07:57 |
| rameshg87 | naohirot, :) | 07:57 |
| *** yuriyz has quit IRC | 07:58 | |
| rameshg87 | naohirot, if you are interested, you can try to use the same refactored-driver as well :) | 07:59 |
| naohirot | rameshg87: Yes, of course. I haven't started coding my part yet. | 08:00 |
| rameshg87 | naohirot, okay. | 08:01 |
| naohirot | rameshg87: I have no problem to follow the abstracted virtual media I/F. | 08:01 |
| rameshg87 | naohirot, i will just wait for everyone to put their thoughts on my spec | 08:01 |
| rameshg87 | naohirot, if it goes through, you can propose a spec dependent on mine and we can achieve this | 08:02 |
| *** Nisha has quit IRC | 08:02 | |
| naohirot | rameshg87: Okay. | 08:02 |
| naohirot | rameshg87: I think it is easier for deployer to understand if there is the <SHARED> concept. | 08:04 |
| rameshg87 | naohirot, yes | 08:04 |
| *** yuriyz has joined #openstack-ironic | 08:04 | |
| rameshg87 | naohirot, and if each conductor has a directory inside <SHARED>, i don't think there will be issues with locking across multiple conductors | 08:05 |
| naohirot | rameshg87: so are you going to mention this in Monday IRC meeting? | 08:05 |
| rameshg87 | naohirot, yeah i can do | 08:06 |
| naohirot | rameshg87: Okay | 08:06 |
| *** Masahiro has quit IRC | 08:06 | |
| rameshg87 | naohirot, but i just posted the spec yesterday. i would like to give some time, so that everyone takes a look at short spec | 08:06 |
| *** ramineni1 has joined #openstack-ironic | 08:06 | |
| rameshg87 | naohirot, brb | 08:07 |
| *** rameshg87 is now known as rameshg87-lunch | 08:07 | |
| *** ramineni has quit IRC | 08:08 | |
| naohirot | rameshg87: Yes, just mentioning that new spec has been posted is enough | 08:08 |
| *** Masahiro has joined #openstack-ironic | 08:12 | |
| *** Nisha has joined #openstack-ironic | 08:14 | |
| *** rameshg87-lunch is now known as rameshg87 | 08:16 | |
| *** mrda is now known as mrda-away | 08:16 | |
| *** anderbubble has quit IRC | 08:22 | |
| *** andreykurilin_ has quit IRC | 08:37 | |
| *** ekarlso- has quit IRC | 08:52 | |
| *** ndipanov has joined #openstack-ironic | 08:55 | |
| *** jistr has joined #openstack-ironic | 09:00 | |
| *** zhenzanz has quit IRC | 09:02 | |
| *** romcheg has joined #openstack-ironic | 09:07 | |
| *** Dafna has joined #openstack-ironic | 09:07 | |
| *** lucasagomes has joined #openstack-ironic | 09:08 | |
| *** ekarlso- has joined #openstack-ironic | 09:09 | |
| *** derekh has joined #openstack-ironic | 09:19 | |
| rameshg87 | lucasagomes, hi | 09:21 |
| *** MattMan has joined #openstack-ironic | 09:27 | |
| *** nosnos_ has quit IRC | 09:31 | |
| *** nosnos has joined #openstack-ironic | 09:31 | |
| *** dtantsur|afk is now known as dtantsur | 09:32 | |
| dtantsur | Morning Ironic, happy 1st winter day :) | 09:33 |
| *** athomas has joined #openstack-ironic | 09:40 | |
| *** stendulker has joined #openstack-ironic | 09:45 | |
| lucasagomes | rameshg87, hi there | 09:45 |
| lucasagomes | dtantsur, morning :) | 09:45 |
| * lucasagomes will escape winter soon | 09:45 | |
| dtantsur | lucasagomes, o/ how was your trip back? | 09:45 |
| lucasagomes | dtantsur, was good :) no surprises | 09:46 |
| dtantsur | heh I like the christmas market part of the winder :) | 09:46 |
| lucasagomes | dtantsur, yours? | 09:46 |
| lucasagomes | oh yeah! that xmas market in paris was great actually | 09:46 |
| dtantsur | lucasagomes, pretty good, with the exception of a crazy man who simulated heart problems to get out of the bus on the intermediate station | 09:46 |
| lucasagomes | hah damn | 09:47 |
| dtantsur | lucasagomes, one in Brno is much better, I promise :) | 09:47 |
| dtantsur | you have to come here next winter | 09:47 |
| lucasagomes | oh really? nice! | 09:47 |
| stendulker | dtantsur: Hi | 09:47 |
| lucasagomes | indeed! | 09:47 |
| dtantsur | stendulker, o/ | 09:47 |
| lucasagomes | they have a xmas market here but it's pretty small | 09:48 |
| stendulker | dtantsur: Have addressed all your comments for spec review of secure boot feature in iLO https://review.openstack.org/#/c/135228 | 09:48 |
| dtantsur | oh cool | 09:48 |
| stendulker | dtantsur: have raised separate spec for management interfaces for secure boot https://review.openstack.org/#/c/135845 | 09:48 |
| dtantsur | lemme find some time, I just returned from the business trip and have an extreme amount of things to do :) | 09:48 |
| dtantsur | ok I'll have a look later | 09:49 |
| stendulker | dtantsur : ok | 09:49 |
| *** igordcard has joined #openstack-ironic | 09:49 | |
| stendulker | dtantsur: thank you. | 09:49 |
| *** openstackgerrit has quit IRC | 09:50 | |
| stendulker | lucagomes: Hi | 09:50 |
| *** openstackgerrit has joined #openstack-ironic | 09:50 | |
| stendulker | lucasgomes: Have added you as a reviewer for spec - Ironic Management Interfaces to support UEFI Secure Boot https://review.openstack.org/#/c/135845 . | 09:51 |
| *** nosnos has quit IRC | 09:52 | |
| stendulker | lucasgomes: Devananda wanted this spec to be reviewed by developers that support other hardware vendor | 09:52 |
| *** Masahiro has quit IRC | 09:52 | |
| *** sambetts has joined #openstack-ironic | 09:55 | |
| openstackgerrit | Merged openstack/ironic: Add decorator that requires a lock for Drac management driver https://review.openstack.org/137713 | 09:56 |
| *** nosnos has joined #openstack-ironic | 09:58 | |
| *** Masahiro has joined #openstack-ironic | 10:04 | |
| *** naohirot has quit IRC | 10:08 | |
| dtantsur | lucasagomes, I just realized Imre is on PTO this week. May I use you for discoverd reviews? | 10:11 |
| lucasagomes | dtantsur, ok yeah | 10:13 |
| dtantsur | thanks :) I don't want to get back to self-approving... | 10:13 |
| *** Nisha has quit IRC | 10:14 | |
| *** yuanying has joined #openstack-ironic | 10:14 | |
| lucasagomes | heh I can figure :) no problem add me and I will review it | 10:15 |
| *** yuanying_ has quit IRC | 10:17 | |
| *** pelix has joined #openstack-ironic | 10:18 | |
| openstackgerrit | Tan Lin proposed openstack/ironic: Fixed typo in Drac management driver test https://review.openstack.org/138028 | 10:20 |
| *** yuanying has quit IRC | 10:26 | |
| dtantsur | lucasagomes, please start with https://review.openstack.org/#/c/137649/ once you have time, you already saw it | 10:26 |
| * lucasagomes clicks | 10:27 | |
| * dtantsur breakfast time | 10:27 | |
| *** yuanying has joined #openstack-ironic | 10:27 | |
| *** jerryz has joined #openstack-ironic | 10:32 | |
| rameshg87 | lucasagomes, hi | 10:32 |
| rameshg87 | lucasagomes, i didn't get your comment on https://review.openstack.org/#/c/137567/ | 10:33 |
| rameshg87 | lucasagomes, "One thing that may need to happen to this work is to make the "ipappend 3" line from the pxe templates, but I believe it will be included when the full spec is posted." | 10:33 |
| lucasagomes | rameshg87, hi there | 10:33 |
| lucasagomes | lemme re-read | 10:33 |
| rameshg87 | lucasagomes, did you mean to put "ipappend 3" should be put in all our pxe templates ? | 10:33 |
| lucasagomes | oh make that line optional | 10:33 |
| lucasagomes | if you add "ipappend 3" it will automatically add the ip= BOOTIF= | 10:34 |
| lucasagomes | to the kernel cmdline | 10:34 |
| rameshg87 | lucasagomes, yeah, but i still didn't get it :) | 10:34 |
| lucasagomes | in ur spec, ur proposing adding it via Ironic directly right? (ask neutron for the ip and add it as part of the deploy) | 10:34 |
| rameshg87 | lucasagomes, yes | 10:35 |
| rameshg87 | lucasagomes, but only for virtual media driver | 10:35 |
| lucasagomes | so idk if u add it directly + leave the ipappend 3 there, it will add those line twice | 10:35 |
| lucasagomes | oh | 10:35 |
| lucasagomes | indeed! | 10:35 |
| lucasagomes | forgot the virtual media | 10:35 |
| lucasagomes | x.x | 10:35 |
| rameshg87 | lucasagomes, :) | 10:36 |
| lucasagomes | rameshg87, right yeah makes no sense for virtual media | 10:36 |
| rameshg87 | lucasagomes, so i don't have any change for any of pxe drivers in mind | 10:36 |
| *** vdrok_ has joined #openstack-ironic | 10:36 | |
| lucasagomes | rameshg87, right, it's grand | 10:36 |
| rameshg87 | lucasagomes, the change is only for virtual media where you send the ip details via the config file | 10:36 |
| lucasagomes | yeah, I missed that part | 10:37 |
| rameshg87 | lucasagomes, similar to what config-drive might do | 10:37 |
| rameshg87 | lucasagomes, okay | 10:37 |
| lucasagomes | sorry for that | 10:37 |
| rameshg87 | lucasagomes, i will post full spec | 10:37 |
| lucasagomes | +1 :) | 10:37 |
| rameshg87 | lucasagomes, thanks :) | 10:37 |
| lucasagomes | yw | 10:37 |
| *** alexpilotti has joined #openstack-ironic | 10:43 | |
| * pensu finally deployed a baremetal node using Ironic. Feeling happy! | 10:53 | |
| ramineni1 | dmitry, lucasagomes : could you review https://review.openstack.org/#/c/129529/ also , if you have some time | 10:55 |
| ramineni1 | dtantsur, lucasagomes: could you review https://review.openstack.org/#/c/129529/ also , if you have some time | 10:56 |
| lucasagomes | ack | 10:56 |
| dtantsur | yeah | 10:56 |
| *** smoriya has quit IRC | 11:01 | |
| ramineni1 | lucasagomes, dtantsur: thanks :) | 11:04 |
| *** Masahiro has quit IRC | 11:04 | |
| *** ramineni1 has quit IRC | 11:05 | |
| *** dlpartain has joined #openstack-ironic | 11:05 | |
| *** Ariz has joined #openstack-ironic | 11:06 | |
| dtantsur | pensu, congrats! | 11:06 |
| dtantsur | lucasagomes, hmm, good point about updating ports... I don't know how to implement it for now... | 11:06 |
| *** Ariz has quit IRC | 11:07 | |
| dtantsur | (chassis is out of consideration for now, because discoverd does not touch them) | 11:07 |
| lucasagomes | dtantsur, yeah, I'm fine with the current code, but was wondering whether we want to think a bit in have it more generic for other resources | 11:07 |
| *** rameshg87 has quit IRC | 11:07 | |
| lucasagomes | in case we need it later and still have to be backward compat | 11:07 |
| *** Ariz has joined #openstack-ironic | 11:08 | |
| lucasagomes | perhaps returning a json patch for each resource | 11:08 |
| lucasagomes | like a named tuple | 11:08 |
| lucasagomes | (node, port) | 11:08 |
| *** Masahiro has joined #openstack-ironic | 11:08 | |
| * lucasagomes not sure either | 11:08 | |
| dtantsur | lucasagomes, that is, a patch for each port as well? maybe... | 11:08 |
| lucasagomes | or even passing the instance of the ironic client to the plugins | 11:08 |
| lucasagomes | so they can pretty much do what needs to be done | 11:08 |
| lucasagomes | dtantsur, yeah :/ | 11:09 |
| dtantsur | lucasagomes, I wanted to avoid too many calls to Ironic update API. Plugins could already call get_ironic() and do whatever they want with the client | 11:09 |
| dtantsur | (or is it get_client?) | 11:09 |
| lucasagomes | heh get_client may be a better name | 11:09 |
| dtantsur | lucasagomes, so for a node it makes sense to collect all patches and then issue them at once. for port I'm not calling update right now though | 11:10 |
| lucasagomes | yeah | 11:10 |
| lucasagomes | I was even considering plugins is generic enough, all that logic of updating the properties in the node and creating ports | 11:10 |
| lucasagomes | could live in a plugin | 11:10 |
| lucasagomes | but maybe I'm going too far :D | 11:11 |
| lucasagomes | I'm good as-is on that patch anyway, added the suggestion just in case | 11:11 |
| dtantsur | lucasagomes, with updating node - why not? :) creating a port is not an idempotent operation though | 11:11 |
| dtantsur | lucasagomes, I'd prefer to make it as good as it's possible right now | 11:12 |
| lucasagomes | aight | 11:12 |
| lucasagomes | u want me to approve ? (to avoid the self-approving thing) | 11:12 |
| *** subscope has joined #openstack-ironic | 11:12 | |
| dtantsur | lucasagomes, not now | 11:14 |
| dtantsur | lucasagomes, what about new suggestion here: https://blueprints.launchpad.net/ironic-discoverd/+spec/plugin-architecture ? | 11:14 |
| * lucasagomes reads | 11:14 | |
| pensu | dtantsur: thanks! :) | 11:14 |
| lucasagomes | dtantsur, right, as u pass the node objects, you may want to pass the port objects as well to the post_discover | 11:15 |
| lucasagomes | but for that, you may need to create the ports before | 11:15 |
| dtantsur | oh right, forgot | 11:15 |
| dtantsur | yes, we can rearrange | 11:15 |
| lucasagomes | and then pass it to that function | 11:15 |
| lucasagomes | right | 11:15 |
| lucasagomes | it sounds better, more flexible at least | 11:15 |
| lucasagomes | as part of the discover, people may want to classify each port | 11:16 |
| dtantsur | lucasagomes, updated | 11:16 |
| dtantsur | how does it look now? | 11:16 |
| lucasagomes | "used for deployement", "used for production" | 11:16 |
| * lucasagomes refreshs | 11:16 | |
| *** dlpartain has quit IRC | 11:16 | |
| lucasagomes | sounds good :) | 11:17 |
| lucasagomes | just being picky, I would rename node_info to "discovered_data" or something like that | 11:17 |
| stendulker | 1lucasgomes: thank you. Had to go away for a meeting. | 11:17 |
| dtantsur | lucasagomes, thanks, will update. | 11:17 |
| dtantsur | (that's why we need reviews :) | 11:17 |
| lucasagomes | dtantsur, heh ack | 11:17 |
| stendulker | lucasgomes: thank you. Had to go away for a meeting. | 11:17 |
| lucasagomes | stendulker, :) thanks for what? | 11:17 |
| stendulker | lucasgomes: For accepting spec review related to secure boot | 11:18 |
| lucasagomes | ah | 11:19 |
| * lucasagomes have to review that too | 11:19 | |
| stendulker | lucasgomes: Or i interpreted someone lesle's message as acceptance for my review :) | 11:20 |
| dtantsur | lucasagomes, when you have more time, please have a look at https://review.openstack.org/#/c/137418/ and the remaining chain | 11:20 |
| stendulker | lucasgomes : Can you please review this spec: - Ironic Management Interfaces to support UEFI Secure Boot https://review.openstack.org/#/c/135845 | 11:21 |
| lucasagomes | right, I need first to get my head around what was decided last week, I only reviewed stuff today | 11:21 |
| *** Masahiro has quit IRC | 11:21 | |
| *** jcoufal has quit IRC | 11:22 | |
| stendulker | ;lucagomes: Have added you as reviewer based on Devanand's comment of having it reviewed from the devlopers that work on diffrent ardware vendor to see thes proposed management APIs would be useful in different hardware vendors. | 11:22 |
| lucasagomes | stendulker, sure, thanks! | 11:23 |
| stendulker | thank you lucagomes :) | 11:23 |
| *** stendulker has quit IRC | 11:24 | |
| *** vinbs has quit IRC | 11:32 | |
| *** foexle has joined #openstack-ironic | 11:36 | |
| dtantsur | lucasagomes, updated https://review.openstack.org/#/c/137649 | 11:47 |
| dtantsur | patch to display new revisions of discoverd here hasn't merged yet :( | 11:47 |
| lucasagomes | dtantsur, ack, I will take a look a later on, finishing expensing things and looking at things we decide last week | 11:48 |
| lucasagomes | the disk stuff | 11:48 |
| lucasagomes | I probably will add it to the meeting today | 11:49 |
| dtantsur | of course, take your time :) | 11:49 |
| lucasagomes | cheers | 11:49 |
| dtantsur | oh it's probably late to add things to the meeting | 11:49 |
| dtantsur | and btw I like your idea about making the default discovery logic a plugin, will implement :) | 11:50 |
| lucasagomes | :D | 11:51 |
| lucasagomes | yeah, cause u never know, ppl may want to use it for diff proposes so making it flexible sounds good to me :) | 11:51 |
| *** jerryz has quit IRC | 11:56 | |
| *** nosnos has quit IRC | 12:09 | |
| *** naohirot has joined #openstack-ironic | 12:10 | |
| *** lucasagomes is now known as lucas-hungry | 12:11 | |
| *** nosnos has joined #openstack-ironic | 12:11 | |
| dtantsur | lucas-hungry, seen the meeting agenda? We're going to talk about state machine, you may want to jump in with the updates suggestion | 12:16 |
| *** foexle has quit IRC | 12:16 | |
| *** Masahiro has joined #openstack-ironic | 12:22 | |
| *** bradjones has quit IRC | 12:26 | |
| *** Masahiro has quit IRC | 12:26 | |
| *** bradjones has joined #openstack-ironic | 12:27 | |
| *** nosnos has quit IRC | 12:29 | |
| *** rameshg87 has joined #openstack-ironic | 12:32 | |
| *** LuisArizmendi has joined #openstack-ironic | 12:33 | |
| *** rameshg87 has quit IRC | 12:33 | |
| *** Ariz has quit IRC | 12:37 | |
| *** nosnos has joined #openstack-ironic | 12:37 | |
| *** ryanpetrello has joined #openstack-ironic | 12:40 | |
| *** nosnos has quit IRC | 12:45 | |
| *** igordcard has quit IRC | 12:50 | |
| *** pensu has quit IRC | 12:52 | |
| *** dtantsur is now known as dtantsur|brb | 12:55 | |
| lucas-hungry | dtantsur|brb, yup | 13:01 |
| lucas-hungry | dtantsur|brb, we need to finish the document first, but I can throw in the inital ideas | 13:01 |
| *** lucas-hungry is now known as lucasagomes | 13:01 | |
| *** enterprisedc has joined #openstack-ironic | 13:03 | |
| *** erwan_taf has joined #openstack-ironic | 13:03 | |
| erwan_taf | heya world | 13:06 |
| lucasagomes | yo :) | 13:06 |
| erwan_taf | hey lucasagomes | 13:06 |
| lucasagomes | erwan_taf, you may wanna join the meeting today (17 UTC) | 13:06 |
| *** Haomeng has joined #openstack-ironic | 13:07 | |
| *** Haomeng|2 has quit IRC | 13:07 | |
| *** dprince has joined #openstack-ironic | 13:12 | |
| *** krtaylor has quit IRC | 13:23 | |
| *** krtaylor has joined #openstack-ironic | 13:38 | |
| *** sambetts has quit IRC | 13:41 | |
| *** sambetts has joined #openstack-ironic | 13:42 | |
| *** chenglch has quit IRC | 13:56 | |
| *** LuisArizmendi has quit IRC | 13:57 | |
| *** jjohnson2 has joined #openstack-ironic | 13:57 | |
| *** dtantsur|brb is now known as dtantsur | 14:00 | |
| dtantsur | erwan_taf, o/ | 14:00 |
| erwan_taf | dtantsur: _o/ | 14:00 |
| *** mjturek has joined #openstack-ironic | 14:01 | |
| *** rloo has joined #openstack-ironic | 14:09 | |
| *** Masahiro has joined #openstack-ironic | 14:10 | |
| *** dlaube has joined #openstack-ironic | 14:10 | |
| *** dlaube1 has joined #openstack-ironic | 14:11 | |
| *** dlaube has quit IRC | 14:11 | |
| *** Masahiro has quit IRC | 14:15 | |
| erwan_taf | lucasagomes: I'll be sadly very few avail. this week, I'll try my best being on the meeting | 14:21 |
| *** igordcard has joined #openstack-ironic | 14:22 | |
| erwan_taf | lucasagomes: can you have a look for adding the create state in the state machine ? | 14:22 |
| lucasagomes | erwan_taf, oh no problem | 14:23 |
| erwan_taf | thx lucasagomes | 14:25 |
| *** sambetts has quit IRC | 14:25 | |
| openstackgerrit | Jim Mankovich proposed openstack/ironic-specs: Remove Sensor RecordID from IPMI Sensor ID https://review.openstack.org/130070 | 14:28 |
| *** sambetts has joined #openstack-ironic | 14:28 | |
| *** sambetts has quit IRC | 14:31 | |
| *** Jatin360 has joined #openstack-ironic | 14:33 | |
| *** alexpilotti has quit IRC | 14:53 | |
| NobodyCam | good morning ironic says the man just waking up | 14:56 |
| dtantsur | NobodyCam, morning | 14:58 |
| *** dlaube1 has quit IRC | 14:59 | |
| NobodyCam | morning dtantsur | 15:00 |
| lucasagomes | NobodyCam, yo morning | 15:00 |
| NobodyCam | morning lucasagomes | 15:00 |
| *** alexm__ has quit IRC | 15:01 | |
| *** ryanpetrello has quit IRC | 15:02 | |
| NobodyCam | lucasagomes: you pullremoved your topic from the agenda? | 15:03 |
| *** dlaube has joined #openstack-ironic | 15:04 | |
| lucasagomes | NobodyCam, hey, it was from last week no? | 15:04 |
| lucasagomes | (tho I coulnd't participate last week) | 15:04 |
| NobodyCam | ya we had it there for you :) | 15:04 |
| NobodyCam | its all good! | 15:04 |
| * lucasagomes will read all the logs | 15:05 | |
| *** smoriya has joined #openstack-ironic | 15:05 | |
| NobodyCam | :) | 15:05 |
| jroll | morning NobodyCam lucasagomes dtantsur and everyone else :) | 15:10 |
| lucasagomes | jroll, yo, hey lemme ask u something quick | 15:10 |
| * jroll listens | 15:10 | |
| lucasagomes | jroll, r u working ont he configdrive for other drivers other than IPA too? | 15:10 |
| * lucasagomes needs it for pxe_ipmitool | 15:11 | |
| jroll | lucasagomes: I was planning on it, yeah | 15:11 |
| lucasagomes | jroll, ah great :) | 15:11 |
| jroll | deva and I talked about partition images a bit | 15:11 |
| jroll | tl;dr deciding where/how to put it there is hard | 15:11 |
| jroll | because rebuild | 15:11 |
| jroll | build without configdrive, rebuild with configdrive will be a problem | 15:11 |
| lucasagomes | oh right (1 sec in a call) | 15:11 |
| jroll | so we talked about always laying it down | 15:12 |
| jroll | sometimes empty | 15:12 |
| jroll | sure, no worries | 15:12 |
| * jroll reading scrollback from a million channels | 15:12 | |
| *** viktors has joined #openstack-ironic | 15:12 | |
| *** ChuckC has quit IRC | 15:14 | |
| *** ChuckC has joined #openstack-ironic | 15:14 | |
| *** ryanpetrello has joined #openstack-ironic | 15:15 | |
| *** k4n0 has quit IRC | 15:16 | |
| *** dlpartain has joined #openstack-ironic | 15:17 | |
| *** Jatin360 has quit IRC | 15:17 | |
| NobodyCam | morning jroll | 15:18 |
| jroll | \o | 15:18 |
| *** alexpilotti has joined #openstack-ironic | 15:19 | |
| vdrok_ | hi everyone! | 15:20 |
| openstackgerrit | Ramakrishnan G proposed openstack/ironic-specs: Add support for VirtualBox WebService. https://review.openstack.org/137926 | 15:20 |
| *** ChuckC has quit IRC | 15:20 | |
| *** naohirot has quit IRC | 15:22 | |
| *** vdrok has quit IRC | 15:22 | |
| jroll | hiya vdrok_ :) | 15:23 |
| *** vdrok_ is now known as vdrok | 15:23 | |
| vdrok | hi jroll ! :) | 15:23 |
| NobodyCam | morning vdrok | 15:24 |
| vdrok | morning NobodyCam | 15:24 |
| *** alexpilotti has quit IRC | 15:25 | |
| *** alexpilotti has joined #openstack-ironic | 15:26 | |
| NobodyCam | :) brb | 15:29 |
| openstackgerrit | Ramakrishnan G proposed openstack/ironic-specs: iLO virtual media drivers to deploy without DHCP https://review.openstack.org/137567 | 15:30 |
| *** lazy_prince is now known as killer_prince | 15:34 | |
| dtantsur | jroll, vdrok, hi! | 15:35 |
| lucasagomes | jroll, back... so how it works for nova? | 15:35 |
| jroll | heya dtantsur :) | 15:35 |
| vdrok | evening dtantsur ! | 15:35 |
| lucasagomes | vdrok, morning | 15:35 |
| vdrok | hi lucasagomes | 15:36 |
| lucasagomes | jroll, in nova you can rebuild and ask for a config drive? maybe we can add it as a limitation of Ironic | 15:36 |
| jroll | lucasagomes: nova builds the configdrive ISO, uploads it to swift, ironic will pull it down | 15:36 |
| jroll | lucasagomes: probably? | 15:36 |
| lucasagomes | jroll, how we identify the configdrive partition in ironic? does it have a particular label? | 15:36 |
| jroll | lucasagomes: afaik, in virt world, it's just mounted to the guest as another block device, through the hypervisor (this may be a wild guess) :) | 15:36 |
| jroll | lucasagomes: yep, config-2 | 15:36 |
| lucasagomes | if so, as part of the rebuild we can look at that label and try to find it | 15:36 |
| lucasagomes | if not we build the config partition | 15:36 |
| lucasagomes | we can make sure that it's always the last partition for e.g | 15:37 |
| jroll | lucasagomes: right, but you don't want to touch the partition table on a rebuild right? | 15:37 |
| *** dlpartain has quit IRC | 15:37 | |
| lucasagomes | jroll, I believe we do it, but we just regenrate it at the exactly same offsets | 15:37 |
| jroll | someone smarter than me (JayF or devananda) told me that it might break bootloaders if it's the last partition or something | 15:37 |
| jroll | dunno if I'm remembering correctly | 15:37 |
| lucasagomes | hmm | 15:38 |
| lucasagomes | right, yeah we can dig into it | 15:38 |
| openstackgerrit | Ramakrishnan G proposed openstack/ironic-specs: Add support for VirtualBox WebService. https://review.openstack.org/137926 | 15:38 |
| lucasagomes | jroll, NobodyCam another thing https://bugs.launchpad.net/ironic/+bug/1397988 | 15:38 |
| lucasagomes | does it makes sense to you guys? being able to select the root device to put the image on? for servers with multiple disks (non-RAID) | 15:39 |
| lucasagomes | or even RAID but not across all the disks | 15:39 |
| jroll | I mean | 15:39 |
| * lucasagomes needs it | 15:39 | |
| jroll | in a way, yes | 15:39 |
| jroll | I don't think the user should be able to choose | 15:39 |
| lucasagomes | not the user | 15:39 |
| jroll | but maybe node.properties can point to it | 15:39 |
| lucasagomes | but the operator | 15:39 |
| jroll | or something | 15:39 |
| lucasagomes | yeah, it's not something the user will request as part of the nova boot or anything | 15:40 |
| dtantsur | well, there should be at least some way to specify a disk | 15:40 |
| jroll | ok yeah | 15:40 |
| *** dlaube has quit IRC | 15:40 | |
| jroll | dtantsur: by the user? | 15:40 |
| lucasagomes | but operators may need a interface to say, that disk is the root device for the image installation | 15:40 |
| lucasagomes | jroll, ack | 15:40 |
| jroll | ++ | 15:40 |
| *** dlaube has joined #openstack-ironic | 15:40 | |
| jroll | totally agree there | 15:41 |
| dtantsur | ^^^ ++ | 15:41 |
| jroll | left a comment on that bug that the operator should specify it | 15:41 |
| *** killer_prince is now known as lazy_prince | 15:42 | |
| lucasagomes | cool I put a update there | 15:42 |
| lucasagomes | jroll, ta much! | 15:42 |
| jroll | :) | 15:42 |
| openstackgerrit | Merged openstack/ironic: Ilo tests refactoring https://review.openstack.org/137775 | 15:43 |
| *** pcrews has joined #openstack-ironic | 15:44 | |
| *** lazy_prince is now known as killer_prince | 15:46 | |
| *** smoriya has quit IRC | 15:46 | |
| *** ndipanov has quit IRC | 15:50 | |
| NobodyCam | lucasagomes: where you looking in to a ipmi to system command deamon thingy? | 15:51 |
| lucasagomes | NobodyCam, I had no time to actually do anything else with it :( | 15:52 |
| lucasagomes | NobodyCam, I will try to find the code I had (which is messy) | 15:52 |
| lucasagomes | and give ya | 15:52 |
| NobodyCam | happy to take a look and see whats I can do to help :) | 15:53 |
| lucasagomes | yeah that's actually a fun thing to do :D | 15:54 |
| lucasagomes | tho I haven't looked into using anything from pyghmi | 15:54 |
| lucasagomes | it may worth to check and see if something can be used from it | 15:54 |
| *** ndipanov has joined #openstack-ironic | 15:57 | |
| NobodyCam | jjohnson2: was looking into such things but I think he's being pulled in several directions at the same time :-p | 15:58 |
| jjohnson2 | NobodyCam, hello | 15:58 |
| jjohnson2 | mentioning my name is like the batsignal, except someone far less cooler comes along | 15:59 |
| *** Masahiro has joined #openstack-ironic | 15:59 | |
| jroll | lol | 16:01 |
| NobodyCam | lol | 16:02 |
| NobodyCam | Hey jjohnson2 have you had a chance to look at the ipmi to command thingy | 16:02 |
| openstackgerrit | Jarrod Johnson proposed stackforge/pyghmi: Implement server side IPMI protocol (WIP) https://review.openstack.org/138109 | 16:03 |
| jjohnson2 | not really | 16:03 |
| jjohnson2 | though I enjoyed timing that | 16:03 |
| NobodyCam | lol | 16:03 |
| NobodyCam | lucasagomes: ^^^^ | 16:04 |
| *** Masahiro has quit IRC | 16:04 | |
| dtantsur | lucasagomes, a friendly reminder to reduce number of outstanding discoverd patches :) pleeeeeease | 16:04 |
| lucasagomes | NobodyCam, hah lol | 16:04 |
| lucasagomes | dtantsur, looking now :0 | 16:04 |
| lucasagomes | :* | 16:04 |
| lucasagomes | :)* | 16:04 |
| lucasagomes | damn >.< | 16:04 |
| NobodyCam | lol | 16:04 |
| lucasagomes | typing is hard | 16:04 |
| dtantsur | smiling is hard :) | 16:05 |
| NobodyCam | it monday after a holiday | 16:05 |
| NobodyCam | it's even | 16:05 |
| dtantsur | it's monday. period | 16:05 |
| dtantsur | (actually a monday after a week-long business trip) | 16:05 |
| NobodyCam | oh fresh coffee is ready .. brb | 16:07 |
| *** Nisha has joined #openstack-ironic | 16:10 | |
| NobodyCam | ahh second cup! | 16:12 |
| jroll | \o/ | 16:12 |
| *** yuanying_ has joined #openstack-ironic | 16:14 | |
| NobodyCam | hehe | 16:16 |
| *** yuanying has quit IRC | 16:16 | |
| NobodyCam | oh lucasagomes any ews on the name? | 16:19 |
| *** anderbubble has joined #openstack-ironic | 16:19 | |
| NobodyCam | *news | 16:19 |
| lucasagomes | NobodyCam, ohhhh will send the email :D | 16:20 |
| lucasagomes | thanks for the reminder | 16:20 |
| NobodyCam | :p | 16:20 |
| lucasagomes | I will pick the 5 ones most voted | 16:20 |
| lucasagomes | and put in a pool :) | 16:20 |
| lucasagomes | there's a pool system on g+ should I just use that? Or u guys know any other good one? | 16:20 |
| NobodyCam | there is a list on the whilteboard | 16:20 |
| lucasagomes | vote on the whiteboard? | 16:21 |
| lucasagomes | ah awesome! | 16:22 |
| lucasagomes | idk who did it but looks pretty good haha | 16:22 |
| NobodyCam | no no I put a count of votes on the white board | 16:22 |
| lucasagomes | NobodyCam, ah ta much! | 16:22 |
| NobodyCam | for quick off the cuff votes I like http://doodle.com/ | 16:22 |
| * lucasagomes clicks | 16:23 | |
| NobodyCam | but I think that just scheduling stuff | 16:23 |
| lucasagomes | so we actually have 6 names as finalists | 16:23 |
| lucasagomes | cause the 4 last ones have 2 votes each | 16:23 |
| lucasagomes | I think it's grand we can decide on those 6 them :) | 16:24 |
| lucasagomes | then* | 16:24 |
| devananda | morning, all | 16:27 |
| jroll | hiya devananda | 16:27 |
| openstackgerrit | Yuriy Zveryanskyy proposed openstack/ironic-specs: Add a new driver for Fuel Agent https://review.openstack.org/138115 | 16:27 |
| devananda | doodle ++ | 16:28 |
| lucasagomes | devananda, morning | 16:28 |
| * lucasagomes is creating a doodle acc | 16:28 | |
| *** naohirot has joined #openstack-ironic | 16:28 | |
| openstackgerrit | Oleksii Chuprykov proposed openstack/ironic-python-agent: Use oslo.utils and oslo.concurrency https://review.openstack.org/138116 | 16:28 |
| devananda | mmm, early monday morning conference calls ... | 16:28 |
| * devananda multitasks | 16:29 | |
| jroll | sigh, why can't we improve IPA instead of using fuel-agent | 16:29 |
| jroll | yuriyz: ^ | 16:30 |
| NobodyCam | morning devananda : are you going to make the new meeting time? | 16:30 |
| devananda | yes | 16:30 |
| *** ChuckC has joined #openstack-ironic | 16:30 | |
| NobodyCam | :) | 16:30 |
| dtantsur | one more ramdisk, dear god Oo | 16:31 |
| dtantsur | devananda, o/ | 16:31 |
| yuriyz | jroll, i think fuel-agent will be an alternative | 16:31 |
| PaulCzar | blerg, seeing some weird ssh_agent stuff . on a new install I get 'SSH connect failed: not a valid EC private key file' | 16:31 |
| NobodyCam | are the status updates all up to date? | 16:32 |
| PaulCzar | I can ssh -i /opt/stack/ironic/key user@host from the ironic user | 16:32 |
| devananda | yuriyz: what is the benefit to fuel over ipa ? | 16:32 |
| jroll | yuriyz: as I understand it, fuel-agent is basically IPA plus advanced partitioning? | 16:32 |
| jroll | yuriyz: we *want* IPA to do partitioning etc | 16:32 |
| NobodyCam | PaulCzar: what are you sshing to? | 16:32 |
| yuriyz | jroll, devananda, please read a spec | 16:32 |
| jroll | yuriyz: I did read the spec, it sounds like this is needed because IPA doesn't do partitions and RAID | 16:33 |
| PaulCzar | NobodyCam: running in virtualbox, sshing back to my mac so it can use the virtualbox commands to spin up the ironic node | 16:33 |
| *** stendulker has joined #openstack-ironic | 16:33 | |
| jroll | PaulCzar: are you sure driver_info has the correct path to the key? the key doesn't have a passphrase, right? | 16:33 |
| PaulCzar | correct | 16:34 |
| NobodyCam | and the key is in your authorized_keys files | 16:34 |
| NobodyCam | file* | 16:34 |
| PaulCzar | yeah as I said I can run ssh as the ironic user and it connects fine using the key | 16:34 |
| yuriyz | jroll, yes but there is already a working production-ready solution with fuel-agent | 16:35 |
| PaulCzar | the error suggests its a problem with reading the key itself | 16:35 |
| NobodyCam | file perms? | 16:35 |
| jroll | PaulCzar: permissions? | 16:35 |
| jroll | yeah | 16:35 |
| jroll | yuriyz: hmm, I don't like it, I guess I will see what others think | 16:36 |
| lucasagomes | NobodyCam, seems like I've to invite people to participate with doodle :/ | 16:37 |
| * lucasagomes wants something public | 16:37 | |
| yuriyz | jroll, I think should be an alternative for people (not only IPA) | 16:37 |
| lucasagomes | oh no.... it seems fine | 16:37 |
| yuriyz | and Fuel Agent driver wil | 16:38 |
| NobodyCam | lucasagomes: :( | 16:40 |
| lucasagomes | NobodyCam, it works :) I was confused by the interface | 16:40 |
| yuriyz | and Fuel Agent driver will not change any interface, external or internal | 16:40 |
| PaulCzar | jroll: NobodyCam nope .. doesn't seem to be perms | 16:41 |
| PaulCzar | https://gist.github.com/paulczar/4c640100b303b445a54e | 16:41 |
| *** ryanpetrello_ has joined #openstack-ironic | 16:41 | |
| NobodyCam | humm | 16:42 |
| NobodyCam | what user is the conductor running as? | 16:43 |
| *** ryanpetrello has quit IRC | 16:43 | |
| *** ryanpetrello_ is now known as ryanpetrello | 16:43 | |
| openstackgerrit | Victor Lowther proposed openstack/ironic-specs: New Ironic provisioner state machine. https://review.openstack.org/133828 | 16:43 |
| *** achanda has joined #openstack-ironic | 16:43 | |
| lucasagomes | all http://doodle.com/9h4ncgx4etkyfgdw | 16:44 |
| lucasagomes | :D please vote and help us pick the best name | 16:44 |
| yuriyz | we have two IPMI drivers (ipminative and ipmitool), and new agent is not bad idea I think | 16:44 |
| * lucasagomes sent to the mailist too | 16:44 | |
| erwan_taf | thx lucasagomes | 16:47 |
| erwan_taf | lucasagomes: your drawing is really fun | 16:47 |
| lucasagomes | erwan_taf, hah thanks? | 16:47 |
| PaulCzar | NobodyCam: conductor and api are both running as the ironic user | 16:50 |
| PaulCzar | just added comment to the gist ... I can use paramiko to connect fine ... which is I believe used by the ssh_agent | 16:51 |
| dtantsur | lucasagomes, "Please add your launchpad ID on the Name Field." <-- already failed this one :) | 16:51 |
| lucasagomes | dtantsur, it's all good :D | 16:51 |
| jroll | PaulCzar: no paramiko, it just shells out | 16:51 |
| *** ifarkas has joined #openstack-ironic | 16:53 | |
| dtantsur | good topic for the next meeting: whether we need moar vm drivers, like: https://review.openstack.org/#/c/137926 | 16:54 |
| PaulCzar | jroll: sure about that? https://github.com/openstack/ironic/blob/master/ironic/common/utils.py#L105-L134 | 16:54 |
| NobodyCam | what meeting room are we in? | 16:55 |
| lucasagomes | dtantsur, +1 | 16:55 |
| lucasagomes | NobodyCam, -3 | 16:55 |
| jroll | "Some developers are forced to run Windows on their office laptop." omg I'm so sorry | 16:55 |
| lucasagomes | lol | 16:55 |
| dtantsur | jroll, ++ | 16:55 |
| jroll | PaulCzar: oops :) | 16:55 |
| devananda | "VirtualBox comes with a very friendly WebService to manage the VMs remotely" <-- ick | 16:55 |
| devananda | jroll: lolol | 16:55 |
| dtantsur | we need more SOAP in Ironic :) | 16:56 |
| jroll | so | 16:56 |
| jroll | I tend to think those folks should just do nested virt for testing | 16:56 |
| jroll | though I see the value in not doing that | 16:56 |
| dtantsur | I've heard ideas about using IPMI proxy and dropping vm drivers | 16:57 |
| dtantsur | if we do so, this effort will be in vain | 16:57 |
| NobodyCam | we should add that to the meeting wiki page | 16:57 |
| Shrews | NobodyCam: #openstack-meeting-3, yes? | 16:57 |
| devananda | dtantsur: I believe, jang has been the one talking about that - do you know if he's made any progress? | 16:57 |
| dtantsur | NobodyCam, for the next meeting, right? | 16:57 |
| dtantsur | no idea :( | 16:58 |
| NobodyCam | dtantsur: jjohnson2 just put up a wip for that... so we're getting closer | 16:58 |
| jroll | dtantsur: the code would be valuable, still, the proxy could also do this SOAP thing | 16:58 |
| lucasagomes | Shrews, yes -3 | 16:58 |
| dtantsur | hm right | 16:58 |
| *** stendulker has quit IRC | 16:58 | |
| NobodyCam | are both the meetings in -3 | 16:58 |
| devananda | REMINDER -- New Meeting time is in one (1) minute in #openstack-meeting-3 | 16:58 |
| jjohnson2 | NobodyCam, yeah, it's interesting, to do it right I might have to delve into ctypes... or just accept that people shouldn't make ipmi servers in a position for ambiguous routing... | 16:58 |
| PaulCzar | jroll: it would be great if there was some better docs on setting up ironic hosts with virsh. the scripts in devstack are hard to follow for a non-devstack ironic | 16:59 |
| devananda | NobodyCam: yes - our meetings are now always in #openstack-meeting-3 | 16:59 |
| NobodyCam | I will up date the meeting wiki | 16:59 |
| NobodyCam | after this meeting | 16:59 |
| devananda | NobodyCam: I did last week | 16:59 |
| jroll | PaulCzar: indeed | 16:59 |
| jroll | jjohnson2: you might look at cffi | 16:59 |
| NobodyCam | devananda: I dont see the meeting room listed | 17:00 |
| *** Masahiro has joined #openstack-ironic | 17:00 | |
| devananda | NobodyCam: you're interested in bare metal deployments within OpenStack, please join our weekly discussion about the Ironic project! Meetings are held in the #openstack-meeting-3 room on irc.freenode.net, and are chaired by Devananda or Chris Krelle (NobodyCam). | 17:00 |
| NobodyCam | lol oh the RED text | 17:00 |
| NobodyCam | lol | 17:00 |
| *** zz_jgrimm is now known as jgrimm | 17:00 | |
| NobodyCam | :( | 17:00 |
| devananda | NobodyCam: feel free to make it more prominent :) | 17:01 |
| *** stend has joined #openstack-ironic | 17:01 | |
| jroll | lucasagomes: I put my irc nick on the poll, oops | 17:01 |
| lucasagomes | jroll, it's all good :) | 17:02 |
| lucasagomes | no worries | 17:02 |
| *** zyluo_ has joined #openstack-ironic | 17:02 | |
| *** romcheg has quit IRC | 17:04 | |
| *** Masahiro has quit IRC | 17:05 | |
| *** Marga_ has joined #openstack-ironic | 17:06 | |
| *** viktors is now known as viktors|afk | 17:07 | |
| *** ndipanov has quit IRC | 17:08 | |
| devananda | GheRivero: around? | 17:10 |
| GheRivero | devananda: pong | 17:10 |
| devananda | meeting reminder :) | 17:11 |
| devananda | GheRivero: i was about to ask you a question bout oslo, but didn't see you in the meeting room | 17:11 |
| *** anderbubble has quit IRC | 17:12 | |
| GheRivero | I was in another call today. but ask me here anyway | 17:12 |
| *** foexle has joined #openstack-ironic | 17:12 | |
| devananda | GheRivero: ah, np | 17:12 |
| *** zyluo_ has left #openstack-ironic | 17:14 | |
| *** Marga_ has quit IRC | 17:14 | |
| *** Marga_ has joined #openstack-ironic | 17:15 | |
| *** ndipanov has joined #openstack-ironic | 17:22 | |
| *** derekh has quit IRC | 17:22 | |
| *** LuisArizmendi has joined #openstack-ironic | 17:22 | |
| *** jgrimm is now known as zz_jgrimm | 17:23 | |
| *** LuisArizmendi has quit IRC | 17:27 | |
| *** marcoemorais has joined #openstack-ironic | 17:28 | |
| *** athomas has quit IRC | 17:34 | |
| *** anderbubble has joined #openstack-ironic | 17:35 | |
| *** ifarkas has quit IRC | 17:36 | |
| dlaube | hey guys | 17:38 |
| *** jistr has quit IRC | 17:38 | |
| dlaube | anyone know how —user-data actually makes it to the node when you supply this option at nova boot? | 17:38 |
| *** sambetts has joined #openstack-ironic | 17:39 | |
| jroll | dlaube: through nova metadata magic | 17:40 |
| dlaube | so —user-data data (probably cloud-init formatted text file) gets passed by nova to the metadata service for the instance/node, at provision time? | 17:42 |
| *** romcheg has joined #openstack-ironic | 17:44 | |
| jroll | I believe so, I'm not entirely sure | 17:44 |
| dlaube | ok, thanks jroll | 17:49 |
| jroll | np | 17:49 |
| *** harlowja_away is now known as harlowja_ | 17:49 | |
| *** anderbubble_ has joined #openstack-ironic | 17:59 | |
| *** anderbubble has quit IRC | 17:59 | |
| *** anderbubble has joined #openstack-ironic | 17:59 | |
| *** Nisha has quit IRC | 18:00 | |
| NobodyCam | good meeting all | 18:00 |
| lucasagomes | yup | 18:00 |
| victor_lowther | ya | 18:01 |
| lucasagomes | so, I don't know but it sounds wrong, conceptually wrong if we treat everything as a state | 18:01 |
| *** marcoemorais has quit IRC | 18:01 | |
| victor_lowther | Even finagled an unfiltered connection from one of the labs. :) | 18:01 |
| devananda | good meeting, and probably good we saved teh biggest topic for last | 18:01 |
| rloo | +1. Now how do we speed up/resolve the state machine stuff? One issue at a time? | 18:01 |
| devananda | at least we got through everything else :) | 18:01 |
| dtantsur | lucasagomes, maybe you should show your suggested state machine? | 18:01 |
| lucasagomes | dtantsur, it's WIP :) | 18:02 |
| dtantsur | we at least have to clarify what goes first: discovery or zapping | 18:02 |
| victor_lowther | That would be a big help. | 18:02 |
| *** marcoemorais has joined #openstack-ironic | 18:02 | |
| *** stend has quit IRC | 18:02 | |
| victor_lowther | zapping, IMO. | 18:02 |
| dtantsur | looks like that | 18:02 |
| JoshNang | dtantsur: what's the argument for zapping going before discovery? | 18:02 |
| lucasagomes | erwan_taf, is working on that too | 18:02 |
| erwan_taf | I do | 18:02 |
| victor_lowther | because it can change what the OS will see w.r.t hardware | 18:02 |
| erwan_taf | zapping sounds weird for me | 18:02 |
| dtantsur | JoshNang, updating firmware can change how resources are represented | 18:02 |
| dtantsur | e.g. creating RAID may change represented hard driver size | 18:02 |
| JoshNang | ok makes sense | 18:03 |
| lucasagomes | yup updating firmware can introduce new features that needs to be discovered | 18:03 |
| victor_lowther | and RAID, and changing memory settings, and partitioning nics., and... | 18:03 |
| erwan_taf | zapping is like "I don't know how to describe a clean state machine so I let the option of having a fuzz place to do anything even if it's not consistent with the rest" | 18:03 |
| victor_lowther | no | 18:03 |
| jroll | dtantsur: how do you zap a machine if you don't know anything about it? | 18:03 |
| JoshNang | erwan_taf: it was originally decommissioning, but that has other, confusing meanings | 18:04 |
| victor_lowther | we know enough about it to get into ot. | 18:04 |
| * erwan_taf is finishing a proposal of a state machine | 18:04 | |
| jroll | victor_lowther: sure, but e.g. how do you know which firmware should be there | 18:04 |
| dtantsur | jroll, kind of chicken-and-egg, yeah. that's why erwan_taf and lucasagomes kind of changed the whole sequence IIRC | 18:05 |
| *** Nisha has joined #openstack-ironic | 18:05 | |
| erwan_taf | jroll: because our proposal integrates a time where you have a conformity chck | 18:05 |
| erwan_taf | check | 18:05 |
| JayF | We aren't talking about in the DELETED->ZAPPING->AVAILABLE transition putting DISCOVERING in there, right? | 18:05 |
| JayF | only if a "zap" was initiated by API call to change configuration of node, right? | 18:05 |
| dtantsur | Nisha, we're trying to figure out whether zapping or discovery should go first | 18:05 |
| victor_lowther | the problem with discovery is that it seemed to focus exclusively on stuff Nova directly cares about | 18:05 |
| dtantsur | you may be interested | 18:05 |
| erwan_taf | give me a couple of minutes and I'll share a first draft of it | 18:05 |
| lucasagomes | jroll, I think that's why the ZAPPING may need to be broken in other states, cause then we can do firmware/update before and other stuff after | 18:05 |
| jroll | JayF: talking about doing zapping before/after discovery, when discovery is initiated | 18:05 |
| Nisha | Yes i am reading up whatever is available | 18:06 |
| victor_lowther | "discovery" should happen whenever the drivers bound to a node are told to | 18:06 |
| JayF | you can't zap before discovery | 18:06 |
| JayF | because you have to know what hardware exists to "zap", right? | 18:06 |
| victor_lowther | from that sperspective, it shoudl ne be a discrete thing in the state machine | 18:06 |
| victor_lowther | er, should not be. | 18:06 |
| devananda | JayF: "discovery" == introspection | 18:06 |
| devananda | dtantsur: I wonder how much confusion continues around that ^ | 18:07 |
| JayF | devananda: are we talking about the "put creds and a driver in and let it go" introspection | 18:07 |
| JayF | devananda: or "how much ram/disks do we have" | 18:07 |
| dtantsur | devananda :( | 18:07 |
| JayF | because honestly if it's get creds and figure stuff out, the difference is academic imo | 18:07 |
| jroll | JayF: wait, those are not the same? | 18:07 |
| dtantsur | I'm partly to blame for carrying on the concept | 18:07 |
| dtantsur | JayF, these are the same right now IMO | 18:08 |
| devananda | lucasagomes: are you / erwan_taf proposing taht "discovery" be a required step every time a node is transitioned towards being AVAILABLE? IOW, that it happens both the first time a node is enrolled, and every time an instance is deleted? | 18:08 |
| JayF | jroll: I think part of where my questions are coming from is that either decom will have to rely on "introspected" data or will have to do some of its own | 18:08 |
| jroll | right | 18:09 |
| Nisha | devananda, why when the instanceis seleted | 18:09 |
| Nisha | s/seleted/deleted | 18:09 |
| JayF | jroll: generally speaking, I think it's just that discovery and decom are awkward to fit into a state model togehter, and why it worries me if we're talking about what devananda just spelled out | 18:09 |
| lucasagomes | devananda, yes, but the thing is that it's optional | 18:09 |
| devananda | Nisha: I'm asking lucas taht question | 18:09 |
| devananda | lucasagomes: optional how? | 18:09 |
| lucasagomes | devananda, once a node is deleted for e.g, we have to rediscover because something may be broken | 18:09 |
| lucasagomes | like a disk failed | 18:09 |
| jroll | yeah, agree, this is hard | 18:09 |
| lucasagomes | so it will fail conformit check later | 18:09 |
| lucasagomes | devananda, optional like, if not implemented it's non-op | 18:10 |
| jroll | lucasagomes: but you want that to fail | 18:10 |
| victor_lowther | Any problems with dripping DISCOVERY as a distinct state from the state machine | 18:10 |
| devananda | lucasagomes: to use your distinction of states and actions, "introspect" is a discrete action, not inherently related to anything else | 18:10 |
| jroll | not discover the change | 18:10 |
| *** lifeless has quit IRC | 18:10 | |
| jroll | and end up passing conformity checks with a missing disk | 18:10 |
| victor_lowther | and just letting instrospection do it on demand? | 18:10 |
| devananda | lucasagomes: I do not want to require rediscovery / repeated-introspection after every instance deletion. | 18:10 |
| JayF | lucasagomes: I disagree a lot with that idea, zapping should catch those situations and toss the box into zapfail | 18:11 |
| devananda | that's just wasted time and cycles | 18:11 |
| victor_lowther | and ZAPPING can demand it before and after the tasks do their thing? | 18:11 |
| erwan_taf | devananda: at some point, yes you have to discover your capability kind of often if you want to be sure being accurate | 18:11 |
| JayF | lucasagomes: if zapping finds failed hardware, it should kick the node into zapping failed with the reason why | 18:11 |
| victor_lowther | JayF: +1 | 18:11 |
| devananda | JayF: ++ | 18:11 |
| Nisha | Jayf ++ | 18:11 |
| NobodyCam | JayF: + | 18:12 |
| devananda | introspection should happen on enrollment AND when there is an expected change AND when a problem is encountered | 18:12 |
| JoshNang | JayF: ++ | 18:12 |
| JayF | fwiw that's how it works in my production today | 18:12 |
| jroll | JayF: ++ /me gets on the bandwagon | 18:12 |
| JayF | except we don't call it zapping | 18:12 |
| jroll | erwan_taf: I never want to discover unintentional changes | 18:12 |
| devananda | it doesn't need to happen every time I deploy an instance | 18:12 |
| devananda | (or every time I delete one) | 18:12 |
| erwan_taf | this is because you don't consider facts that could change over time | 18:12 |
| *** Marga_ has quit IRC | 18:12 | |
| victor_lowther | devananda: sounds like an argument for dropping it from the state machine. | 18:12 |
| NobodyCam | devananda: AND when a problem is encountered? | 18:12 |
| lucasagomes | it's the same as "zapping should catch those situations" the difference is that everything is included in zapping | 18:12 |
| erwan_taf | the more hw properties you add, the more this is required | 18:12 |
| lucasagomes | discover/consistency/bios update/ etc... | 18:13 |
| erwan_taf | in my case, I can detect where the server is connected or the healthyness of a disk | 18:13 |
| Nisha | lucasagomes why zapping will do discovery | 18:13 |
| erwan_taf | that is likely to change | 18:13 |
| jroll | discovery should be a manual operation IMO | 18:13 |
| NobodyCam | devananda: your not saying that a node going into zapfailed should be introspected? | 18:13 |
| devananda | NobodyCam: like DEPLOYFAIL. I might want to re-discovery the node after it fails a deploy to see what's different about it | 18:13 |
| devananda | but that's something I expect the operator (or something outside of IronicConductor) to choose to do | 18:13 |
| *** igordcard has quit IRC | 18:13 | |
| lucasagomes | wait folks | 18:14 |
| devananda | not something we impute on all failed nodes | 18:14 |
| lucasagomes | let us present the state machine first | 18:14 |
| NobodyCam | where would that data be presented... I wouldn't want change node.properties | 18:14 |
| lucasagomes | we a document describing it | 18:14 |
| devananda | jroll: ++ discovery is manually-initiated | 18:14 |
| *** spandhe has joined #openstack-ironic | 18:15 | |
| lucasagomes | otherwise we will be discussing something without seems the full picture | 18:15 |
| lucasagomes | seeing* | 18:15 |
| *** igordcard has joined #openstack-ironic | 18:15 | |
| Nisha | NobodyCam, the discovery might be needed after zapping, i.e. say after raid configuration but it shudnt be part of zapping | 18:15 |
| dtantsur | victor_lowther, hope you're not talking about dropping the DISCOVERING state itself? /me is context-switching right now, sorry... | 18:15 |
| victor_lowther | Since the actions DISCOVERING take will need to happen elsewhere as well, yes I am. | 18:16 |
| victor_lowther | unless there is a compelling reason ti keep it around. | 18:17 |
| *** achanda has quit IRC | 18:18 | |
| dtantsur | victor_lowther, because it _is_ a state? | 18:19 |
| Nisha | victor_lowther, i think i am out-ofcontext here. Why DISCOVERING state is not required now? Are you proposing to change DISCOVERING state to ZAPPING or something else? | 18:19 |
| jroll | this is going so far downhill | 18:19 |
| devananda | let's be clear about an aspect of DISCOVERING -- during this transition, and only this transtion, the properties of the node may be changed. | 18:19 |
| dtantsur | victor_lowther, also how are you going to indicate success/failure of discovery other than by state transition | 18:19 |
| devananda | jroll: yes it is | 18:19 |
| dtantsur | devananda, right | 18:20 |
| devananda | dtantsur: -> DISCOVERYFAIL | 18:20 |
| victor_lowther | If that is the only place they can change, then DISCOVERING must be after ZAPPING | 18:20 |
| JayF | DISCOVERING is a state only entered to by user API call action; agreed? | 18:20 |
| jroll | can you do discovery without zapping? | 18:21 |
| dtantsur | devananda, we first had ENROLL -> DISCOVERING -> {INIT, DISCOVERYFAIL}. do you see any problems with it? | 18:21 |
| *** pelix has quit IRC | 18:21 | |
| devananda | this also requires that, if I don't want my node's properties to change automatically, then my nodes can not automatically go into the DISCOVERING state | 18:21 |
| sambetts | IMO I thought the discovering state was before INIT | 18:21 |
| dtantsur | JayF, ++ | 18:21 |
| JayF | If that's true; then "location" in the state diagram doesn't matter. What matters is what states are allowed to go into "DISCOVERING" and what states you're allowed to exit "DISCOVERING" into | 18:21 |
| devananda | but they must go through ZAPPING when an isntance is deleted | 18:21 |
| devananda | do you see the problem? | 18:21 |
| jroll | right, discovery and zapping are two completely different paths | 18:21 |
| victor_lowther | then we need something besides node.properties to hold potentially dynamic node properties | 18:21 |
| devananda | jroll: exactly | 18:21 |
| jroll | if the operator chooses, the operator may do both in sequence | 18:22 |
| jroll | but they are two separate things | 18:22 |
| jroll | we should never have DISCOVERY -> ZAPPING or ZAPPING -> DISCOVERY | 18:22 |
| Nisha | jroll ^^^ why? | 18:22 |
| JoshNang | victor_lowther: like what dynamic properties? | 18:22 |
| jroll | Nisha: why should we? | 18:23 |
| victor_lowther | JayF: if location in the state machine does not matter, then DISCOVERING should not be in the state machine | 18:23 |
| JoshNang | it seems like most of those can and should be covered by capabilities | 18:23 |
| jroll | Nisha: I don't see any valid reason to automatically do both when one is requested | 18:23 |
| dtantsur | victor_lowther, I don't see why, sorry | 18:23 |
| jroll | Nisha: if I want to zap a node, why would it go through discovery? | 18:23 |
| devananda | dtantsur: yes, I see a problem. I may want ENROLL -> INIT | 18:23 |
| JayF | victor_lowther: IDK about that from a technical standpoint; but I stand by my assertion that entry and exit points are the only thing that matters. At that point drag the box in visio wherever someone wants it to go :P | 18:23 |
| victor_lowther | JoshNang: Anything that can change as a result of ZAPPING | 18:23 |
| devananda | dtantsur: DISCOVERY is never mandatory | 18:23 |
| devananda | s/is never/can not be/ | 18:23 |
| *** lifeless has joined #openstack-ironic | 18:23 | |
| dtantsur | devananda, is it a reason for dropping DISCOVERING state completely? (that's what I'm talking about) | 18:24 |
| *** r-daneel has joined #openstack-ironic | 18:24 | |
| devananda | dtantsur: no -- it is a valid state. but it is one which must be explicitly requested | 18:24 |
| jroll | I don't understand why hardware properties would change as a result of zapping (in terms of schedulable properties) | 18:24 |
| *** romcheg1 has joined #openstack-ironic | 18:24 | |
| Nisha | jroll, ok | 18:24 |
| JayF | victor_lowther: devananda: Question -> how do we want to handle zapping behaviors (not in the delete case; in the called-from-api gimme-a-raid standpoint) that might need something in capabilities or properties changed? | 18:24 |
| victor_lowther | JayF: We should just node that node property discovery can happen on-demand | 18:24 |
| dtantsur | devananda, aha good. victor_lowther is saying we don't need it at all. | 18:24 |
| jroll | dtantsur: devananda: I think you mean ENROLL -> {INIT, DISCOVERING -> {INIT, DISCOVERYFAIL}} | 18:24 |
| victor_lowther | therefore it is not a deterministic part of the state machine. | 18:24 |
| devananda | Ironic should not automatically-and-by-design-always change the properties of the nodes it manages. It MAY do this, if configured thus. It MAY NOT do this, if configured thus. | 18:25 |
| JayF | victor_lowther: devananda: Because in the case of "make me a RAID 0" or something like that, your root_gb will change | 18:25 |
| jroll | dtantsur: devananda: is what we agreed on | 18:25 |
| devananda | we can't build a state machien whcih REQUIRES discovery | 18:25 |
| NobodyCam | jroll: how do we know what disks to wipe if we have not discovered them? | 18:25 |
| erwan_taf | please let us a chance to present our state machine properly | 18:25 |
| devananda | jroll: yes. ENROLL -> [INIT | DISCOVERING -> [INIT | DISCOVERYFAIL] ] | 18:25 |
| jroll | NobodyCam: wipe them all! | 18:25 |
| JayF | NobodyCam: that's what I said about how decom is going to need to do some introspection | 18:25 |
| *** romcheg has quit IRC | 18:25 | |
| erwan_taf | we know we are changing some stuff but it does support what you speak about | 18:25 |
| JayF | NobodyCam: we already have hardware managers which find hardware to clean up | 18:25 |
| jroll | NobodyCam: zapping will need to find the disks, yes, but discovery is about changing node.properties | 18:26 |
| victor_lowther | NobodyCam: Make sure any tasks that run in ZAPPING get their info straight from the relavent drivers, not node.properties | 18:26 |
| erwan_taf | optional steps etc... while keeping sanity for a state machine aka step->transition->step | 18:26 |
| JayF | NobodyCam: we'd keep that model I'd think, even if it dupes a little stuff from discovery, it's all using standard OS interfaces to get the info so it's not that duplicated | 18:26 |
| jroll | erwan_taf: then present it, we need to finish this | 18:26 |
| JayF | victor_lowther: ++ | 18:26 |
| victor_lowther | NobodyCam: which is really the only sane wayt to do it. | 18:26 |
| erwan_taf | jroll: we need a little time to finish it | 18:26 |
| JayF | victor_lowther: NobodyCam: that's how it behaves now and should behave; if any refernce to node properties happen, it should be to validate the machine still matches them and ZAPFAIL if it doesn't | 18:26 |
| jroll | erwan_taf: (not trying to be mean, just frustrated at the moment, sorry) | 18:26 |
| devananda | erwan_taf: we're already almost a month after the summit, and we can't continue delaying other work on the state machine much longer | 18:27 |
| *** marcoemorais has quit IRC | 18:27 | |
| jroll | erwan_taf, lucasagomes: how close is your proposal, can we see an early version or at least something which outlines the main idea? | 18:27 |
| *** marcoemorais has joined #openstack-ironic | 18:27 | |
| *** romcheg has joined #openstack-ironic | 18:27 | |
| erwan_taf | jroll: state machine is 99% | 18:27 |
| jroll | erwan_taf: then propose it now, please? | 18:28 |
| erwan_taf | definition of it aka a kind of document that explains it properly is 50% | 18:28 |
| devananda | erwan_taf: so I'm interested to see your proposal, but also frustrated that it sounds like you have a brand new competing proposal to the one we've all been thinking about for the last month | 18:28 |
| erwan_taf | I can finish it in the day | 18:28 |
| erwan_taf | devananda: it isn't that different | 18:28 |
| devananda | erwan_taf: and didn't share, or even mention it sooner | 18:28 |
| devananda | erwan_taf: oh. then why not share it as comments on the existing proposal? | 18:28 |
| victor_lowther | erwan_taf: can you diff it against https://review.openstack.org/#/c/133828/? | 18:28 |
| devananda | erwan_taf: or as a diff file? | 18:28 |
| victor_lowther | or add comments like devananda said | 18:29 |
| erwan_taf | would be complicated :/ | 18:29 |
| erwan_taf | this proposal is mixing states and transitions | 18:29 |
| devananda | erwan_taf: I feel like asking us to hold off on discussing this whiel we wait for you is not really constructive | 18:29 |
| victor_lowther | More complicated than two competing propsals? | 18:29 |
| jroll | erwan_taf: do you have it on a whiteboard or something? take a picture? | 18:29 |
| *** romcheg1 has quit IRC | 18:29 | |
| erwan_taf | it have multipathing which is weird for a state machine | 18:29 |
| victor_lowther | erwan_taf: Have you read the current proposal | 18:29 |
| victor_lowther | ? | 18:29 |
| victor_lowther | So do we. :) | 18:30 |
| erwan_taf | for sure I did with lucasagomes | 18:30 |
| erwan_taf | and that's were our proposal started from | 18:30 |
| lucasagomes | we started thinking about other use cases that erwan_taf currently have | 18:30 |
| erwan_taf | and sorry not having shared about it before, it was just a couple of days before :/ | 18:30 |
| lucasagomes | and wouldn't fit on that proposal | 18:30 |
| erwan_taf | and also thinking about making this state machine being able to be propulsed by a state machine framework | 18:31 |
| erwan_taf | a state machine shall be state->action->state | 18:31 |
| * victor_lowther sighs | 18:31 | |
| erwan_taf | if multiple actions or multiple states exists in a row, that's not a state machine | 18:31 |
| jroll | lucasagomes: what use cases? | 18:32 |
| erwan_taf | ok | 18:32 |
| erwan_taf | let's share now then | 18:32 |
| jroll | yes please | 18:32 |
| *** Marga_ has joined #openstack-ironic | 18:32 | |
| erwan_taf | that's not completed as I wanted it to be | 18:33 |
| erwan_taf | sorry about the format, it was for developping it faster & cleaner : | 18:33 |
| erwan_taf | https://docs.google.com/drawings/d/1Pxy2lr270yAlP78P7knhYhmBbanKWFf2EfcwVrduOtA/edit?usp=sharing | 18:33 |
| NobodyCam | erwan_taf: ya even a unpolished look would help | 18:33 |
| erwan_taf | and this is the start of the explanations : https://docs.google.com/a/enovance.com/document/d/1RfstwW1cdI8RcB51fdYNSN9dfvZJ1U2b-oJNPikvlno/edit?usp=sharing | 18:34 |
| erwan_taf | more explanations are required on "what" a particular action is supposed to do | 18:34 |
| erwan_taf | I'll do it live here | 18:34 |
| * lucasagomes clicks | 18:34 | |
| erwan_taf | the main idea is being able to put _1 action_ per transition | 18:35 |
| JoshNang | erwan_taf: can you change the sharing on the explanation? | 18:35 |
| jroll | so this assumes e.g. "provisioning" is not a state | 18:35 |
| jroll | when it really is a state | 18:35 |
| victor_lowther | so you have approximately the same state machine with different names for the states | 18:35 |
| lucasagomes | jroll, the current state of the machine | 18:35 |
| lucasagomes | jroll, when you look at | 18:35 |
| *** sambetts has quit IRC | 18:35 | |
| lucasagomes | provisioned being the target state | 18:36 |
| dtantsur | erwan_taf, can't access the explanation as well | 18:36 |
| lucasagomes | and undeployed being the current one | 18:36 |
| lucasagomes | you always know what is the action being taken | 18:36 |
| lucasagomes | in this case provisioning | 18:36 |
| victor_lowther | and a couple of extra transition paths back through normalizing where the curent one drops to error states | 18:36 |
| jroll | mmm, I see | 18:36 |
| lucasagomes | also the machine is self explanatory, once the node is at READY for example, by reading the previous states | 18:36 |
| lucasagomes | you know exactly what READY means | 18:36 |
| *** rushiagr is now known as rushiagr_away | 18:37 | |
| *** davideagnello has joined #openstack-ironic | 18:37 | |
| dtantsur | lucasagomes, erwan_taf, I don't remember exactly: where is discovery there? | 18:37 |
| lucasagomes | it means the machine is CLEAN it's CONSISTENT it has been NORMALIZED etc... | 18:37 |
| erwan_taf | https://docs.google.com/a/enovance.com/document/d/1RfstwW1cdI8RcB51fdYNSN9dfvZJ1U2b-oJNPikvlno/edit?usp=sharing | 18:37 |
| erwan_taf | should be better | 18:37 |
| jroll | dtantsur: normalizing | 18:37 |
| *** MattMan has left #openstack-ironic | 18:37 | |
| lucasagomes | dtantsur, that's the 1% missing | 18:37 |
| jroll | oh, maybe I'm wrong | 18:37 |
| jroll | erwan_taf: I still can't see that link | 18:37 |
| lucasagomes | dtantsur, you mean like discovered after created right? | 18:37 |
| devananda | erwan_taf: still can't access either | 18:37 |
| dtantsur | lucasagomes, yep | 18:37 |
| erwan_taf | uh. | 18:38 |
| lucasagomes | devananda, lemme see | 18:38 |
| lucasagomes | devananda, https://docs.google.com/drawings/d/1Pxy2lr270yAlP78P7knhYhmBbanKWFf2EfcwVrduOtA/edit?usp=sharing | 18:38 |
| devananda | why are READY, UNDEPLOYED marked as unrepeatable states? | 18:38 |
| erwan_taf | let me put it to the etherpad | 18:38 |
| devananda | lucasagomes: got that. not the explanation | 18:38 |
| lucasagomes | devananda, because if it fails on that particular node, nova wiht the retry field | 18:39 |
| *** foexle has quit IRC | 18:39 | |
| lucasagomes | can try to put the instance in another node | 18:39 |
| lucasagomes | so we can't repeat that in the node that just failed | 18:39 |
| erwan_taf | https://etherpad.openstack.org/p/Ironic_SM_Explained | 18:39 |
| lucasagomes | to not end up with the same instance being deployed more than once | 18:39 |
| erwan_taf | will make it better | 18:39 |
| *** BertieFulton has joined #openstack-ironic | 18:39 | |
| *** vdrok has quit IRC | 18:39 | |
| devananda | lucasagomes: at what point in this state machine a) is the node exposed to Nova, b) is the interaction between Nova and Ironic represented? | 18:40 |
| lucasagomes | devananda, READY is exposed to nova | 18:40 |
| lucasagomes | and only READY | 18:40 |
| *** romcheg has quit IRC | 18:40 | |
| devananda | lucasagomes: so why is that non-repeatable? | 18:40 |
| erwan_taf | please note this state machine is not representing _faults_ | 18:40 |
| erwan_taf | only valid paths | 18:40 |
| victor_lowther | OK | 18:41 |
| erwan_taf | I'm pretty sure we are all trying to do the same | 18:41 |
| lucasagomes | devananda, cause if it fails in the deployment, we can't just retry it, we should clean that up first, check consistency and then it will be READY again | 18:41 |
| victor_lowther | why provisioned after READY? | 18:41 |
| erwan_taf | we just made the exercise of having well defined verbs & actions to get a single action per transition | 18:41 |
| lucasagomes | devananda, if we have DEPOYFAIL right now we can't retry either right? | 18:41 |
| lucasagomes | we delete it and then try again | 18:42 |
| *** ndipanov is now known as ndipanov_gone | 18:42 | |
| lucasagomes | victor_lowther, READY == available | 18:42 |
| JayF | lucasagomes: with decom, you can go DEPLOYFAIL->ZAPPING or ZAPFAIL->ZAPPING | 18:42 |
| lucasagomes | provisioned == deployed | 18:42 |
| erwan_taf | the consistency checking is one of the addition of my experience : we shall not try deploying a server which is not consistent with what you expect it to be | 18:42 |
| JayF | lucasagomes: at least downstream that's how we have it implemented | 18:42 |
| JayF | lucasagomes: so if you fix whatever crappy thing broke your deploy, you can kick it back through decom and into available | 18:42 |
| devananda | erwan_taf, lucasagomes: ok. so what is the benefit of this proposal over the one that we've all already spent a month thinking about? | 18:43 |
| lucasagomes | JayF, yeah, that's kinda same, but the ZAPPING now are more than one state | 18:43 |
| lucasagomes | well defined states | 18:43 |
| erwan_taf | and note also some transitions are _optional_ | 18:43 |
| erwan_taf | I mean no code | 18:43 |
| lucasagomes | JayF, the problem with the ZAPPING is that it has no real meaning, it can be anything, each driver kinda ends up implementing it's own state machine | 18:43 |
| *** naohirot has quit IRC | 18:44 | |
| devananda | lucasagomes: you said earlier something to the effect of, knowing what state a machine was in /before/ teh current state. I don't see how this proposal is any better -- there are still multiple paths | 18:44 |
| lucasagomes | devananda, where? | 18:44 |
| devananda | lucasagomes: to get to manageable and normalized | 18:44 |
| devananda | 2 paths to manageable | 18:44 |
| devananda | 3 paths to normalized | 18:44 |
| erwan_taf | devananda: first I doesn't mix states & transition, then it does put a good semantic and avoid "all-in-one" task, It insure that it can be propulsed by a state machine framework, it does include additional steps to improve the consistency of the deployed server | 18:44 |
| lucasagomes | devananda, managable is the main loop | 18:45 |
| lucasagomes | once it gets to the main loop it never goes back to defined | 18:45 |
| JayF | lucasagomes: for a given machine though; it should be stable when run over and over again (when I say "ZAPPING" in this case; I mean running the on-delete zapping steps) | 18:45 |
| devananda | lucasagomes: what happens if someone changes teh IPMI credentials ? | 18:45 |
| erwan_taf | devananda: only 2 paths at a maximum : "yes / no" the current proposal have more than 2 | 18:45 |
| devananda | it's no longer manageable | 18:45 |
| devananda | erwan_taf: three paths lead to the action of Normalizing | 18:46 |
| JayF | ^ It's really confusing that decom got abstracted out into something that can do many different things :( | 18:46 |
| lucasagomes | devananda, it fails conformity check | 18:46 |
| jroll | I have to go afk for a while, bbl | 18:46 |
| lucasagomes | and operator now have to take a look at what happened | 18:46 |
| erwan_taf | devananda: at the input, not at output | 18:46 |
| lucasagomes | devananda, that's why we have the CONSISTENT, once it's READY we know that the machine is consistent | 18:47 |
| erwan_taf | devananda: INIT could exit to DISCOVERING/ZAPPING/AVAILABLE | 18:47 |
| victor_lowther | and it has those paths because people asked for them | 18:47 |
| erwan_taf | AVAILABLE exists to PREBOOTING/DEPLOYING/INIT | 18:47 |
| victor_lowther | ditto | 18:47 |
| erwan_taf | this was our starting point | 18:48 |
| devananda | erwan_taf: if I removed the shapes around each word, I would have almost the same diagram | 18:48 |
| *** linggao has joined #openstack-ironic | 18:48 | |
| devananda | erwan_taf: you say this doesn't mix states and actions, but I don't agree | 18:48 |
| *** Masahiro has joined #openstack-ironic | 18:49 | |
| devananda | when Ironic is in the process of copying bytes onto the disk | 18:49 |
| devananda | is that machine Ready? Undeployed? Provisioned? | 18:49 |
| lucasagomes | JayF, for a given driver right? more than 1 driver can control a machine and that would change the meaning of ZAPPING | 18:49 |
| lucasagomes | JayF, plus it's a proposal :) it's something we thought that would be nice to get u guys to see and comment etc | 18:49 |
| victor_lowther | lucasagomes: it changes the exact steps performed in ZAPPING | 18:49 |
| *** cohn has joined #openstack-ironic | 18:49 | |
| victor_lowther | not the meaning of ZAPPING | 18:49 |
| erwan_taf | victor_lowther: it just split in explicits steps | 18:50 |
| JayF | lucasagomes: My main thing is having "ZAPPING" be one set of semi-standard things (yes, per-driver, but I'd expect most drivers to implement the same generic sets of things) | 18:50 |
| lucasagomes | devananda, the current state is UNDEPLOYED and target state PROVISIONED | 18:50 |
| devananda | that logical resource is in a state of transition -- which IS a state | 18:50 |
| lucasagomes | READY is just like "hey nova I'm available to be picked" | 18:50 |
| JayF | lucasagomes: vs if it's initiated via the API by an operator, zapping can be an arbitrary set of things (like configuring a raid) | 18:50 |
| JayF | lucasagomes: which just makes it incredibly confusing to talk about, because almost always one use case or the other gets forgottten | 18:50 |
| devananda | lucasagomes: how is that significantly different from "current state is PROVISIONING and target state is PROVISIONED" ? | 18:50 |
| lucasagomes | JayF, "but I'd expect most drivers to implement the same generic sets of things" that's what we are trying to abstract | 18:50 |
| JayF | lucasagomes: I don't want that abstracted | 18:51 |
| lucasagomes | and making some of the operations optional | 18:51 |
| JayF | lucasagomes: I want to be able to do very specific things to specific hardware | 18:51 |
| victor_lowther | and the menaing of ZAPPING is "Here is where we perform things that take a long time and are going to nuke your data" | 18:51 |
| erwan_taf | JayF: so am I, but we have a dedicate time to do it | 18:51 |
| erwan_taf | I mean it have to be explicit when a particular action shall be done | 18:52 |
| JayF | lucasagomes: but the "decom" steps we'll have in Ironic/IPA "stock" during ZAPPING will all be basic; like secure erasure or the like. More advanced/dangerous things should have to be explicitly enabled. | 18:52 |
| victor_lowther | up to and including what configuration you think the node has. | 18:52 |
| erwan_taf | that proposal first check if the hw is consistent or not, if so, we clean it & prepare it | 18:53 |
| JayF | lucasagomes: at least that's how I modeled it in my head -- it's difficult/impossible, even across similar ("this is all DRAC 5") hardware, to be confident advanced things can be done repeatedly without issue | 18:53 |
| * devananda goes back to "is this better, or just different" | 18:53 | |
| lucasagomes | devananda, both tells you the same | 18:53 |
| devananda | 18:44:55 < erwan_taf> devananda: first I doesn't mix states & transition, then it does put a good semantic and avoid "all-in-one" task, It insure that it can be propulsed by a state machine framework, it does include additional steps to improve the consistency of the deployed server | 18:53 |
| victor_lowther | JayF: indeed | 18:53 |
| victor_lowther | Experience has shown that hardware is alot tricker to manage than vms are | 18:53 |
| devananda | erwan_taf: it still mixes states and transitions exactly as much as the original proposal | 18:53 |
| *** Masahiro has quit IRC | 18:53 | |
| erwan_taf | JayF: creating raid is in "Preparing" action | 18:53 |
| erwan_taf | devananda: where ? | 18:54 |
| devananda | erwan_taf: yes, it deconstructs the ZAPPING state more | 18:54 |
| devananda | erwan_taf: I disagree with the impication that the current proposal can not be propelled by a FSM framework | 18:54 |
| erwan_taf | s/deconstructs/define|precise/ | 18:54 |
| devananda | erwan_taf: your fourth point was merely restating the second | 18:54 |
| JayF | erwan_taf: I'm talking solely about the state diagram presented at the summit; I'm not sure it's fruitful to change direction this late in the process and my attention reflects that :/ | 18:55 |
| devananda | so -- is there a benefit to defining/deconstructing the ZAPPING phase into more phases? | 18:55 |
| JayF | devananda: I think it makes it a hell of a lot more clear to operators | 18:55 |
| lucasagomes | telling you the real state of the machine? | 18:55 |
| lucasagomes | when a operator see ZAPPING | 18:55 |
| lucasagomes | it means different things for different drivers | 18:55 |
| JayF | devananda: because I run this stuff, and am on the core team of ironic-specs, and it's still hard to remember/differenciate. I don't want to have to explain the semantic difference between "automatic" zapping and user-initiated zapping to my ops team | 18:55 |
| erwan_taf | a state machine means having one action to change from a state to another. Zapping does virtually anything which could be done in an explicit step | 18:55 |
| devananda | JayF: are you in favor of splitting ZAPPING into more than one state (such as normalizing, cleaning, consistency-checking) ? | 18:55 |
| lucasagomes | that said, it doesn't have a real meaning | 18:55 |
| JayF | devananda: Not in that sense, no | 18:56 |
| JayF | devananda: but in the general sense of I'd rather it not be lumped into a "general hardware reconfiguration" bucket like it is now | 18:56 |
| erwan_taf | if you want being able to define when you have to do something and check the potential impacts with the others actions then yes, you have to split everything in 1 state/transition | 18:56 |
| JayF | normalizing/cleaning would be a fine name for it, but I just don't want decom to spam multiple states | 18:56 |
| devananda | "do the special things to get back to INIT" | 18:56 |
| JayF | I just see, "I'm doing a long-running RAID setup because you told me to" as an inherently different state then "I'm performing required security tasks before this node is available again" | 18:57 |
| devananda | I think we have ZAPPING as a wide open, undefined space today precisey because it isn't clear what falls into that bucket - -and different driverse / operators / deployments will want different things | 18:57 |
| victor_lowther | then the ironic state machine should have a spot for "insert driver and/or user specific states here" | 18:57 |
| erwan_taf | a state machine should be in posiiton to read like "My server is currently doing _that" | 18:57 |
| erwan_taf | which is impossible in the current proposal | 18:57 |
| devananda | erwan_taf: that is not a fair statement | 18:58 |
| victor_lowther | erwan_taf: it is not pissible in your proposals either | 18:58 |
| NobodyCam | spliting may not be such a bad thing, I can see folks wanting a burn-in state, as example | 18:58 |
| NobodyCam | spliting it now may make that easier when the time comes | 18:58 |
| erwan_taf | that state machine offer you an important value : it is propusled by a FSM and its only up to people coding some functions but not the logic | 18:58 |
| lucasagomes | victor_lowther, no? | 18:58 |
| erwan_taf | victor_lowther: it is | 18:58 |
| erwan_taf | victor_lowther: every single state is a adverb | 18:58 |
| erwan_taf | My server is provisonned ... | 18:59 |
| erwan_taf | at some point we'll need to provide _states_ to any UI | 18:59 |
| victor_lowther | unless you make discrete states for every action that could happen in the process of ZAPPING, it is not. | 18:59 |
| erwan_taf | victor_lowther: all the possible of Zapping should be exposed to find any interactions with other tasks/states | 18:59 |
| JayF | I wonder if some of this would be more clear if we had two state fields, like nova, a "state" and a "task_state" | 19:00 |
| erwan_taf | if you need something, we also need it | 19:00 |
| devananda | erwan_taf: whoa. nope! | 19:00 |
| erwan_taf | so it have to be exposed explicately as its a state to do something | 19:00 |
| JayF | erwan_taf: such specificity is not always possible when you might be working with hardware nobody else has that has capabilities nobody else has | 19:00 |
| *** davideagnello has quit IRC | 19:00 | |
| victor_lowther | and depenging on what drivers expose and what site policy says should happen, that set isnot knowable in advance | 19:00 |
| devananda | erwan_taf: right now, there are A LOT of things which zapping could do -- and we had better not start talking about all of them | 19:00 |
| JayF | erwan_taf: like I made a fancy machine with a jLo in it that has a single call for zapping on delete: "reset to factory". That can't be modeled in the state machine today because it doens't exist today | 19:00 |
| devananda | because then we'll get nothing done this cycle | 19:00 |
| devananda | seriously folks | 19:01 |
| devananda | seriously | 19:01 |
| lucasagomes | :/ | 19:01 |
| devananda | we need to make some progress here | 19:01 |
| lucasagomes | would be better to have a middle ground here | 19:01 |
| erwan_taf | JayF: REset to factory ? good example | 19:01 |
| lucasagomes | kinda like we do for vendor stuff? | 19:01 |
| devananda | ZAPPING as an open bucket for (insert special something here) | 19:01 |
| lucasagomes | as we notice that zapping is doing same thing we can promote it to states? | 19:01 |
| JayF | erwan_taf: no, it's a crappy example because it doesn't exist today; but might in the future, so we can't model it yet :) | 19:01 |
| devananda | or like I said a bit ago | 19:01 |
| devananda | 18:56:52 <@devananda> "do the special things to get back to INIT" | 19:01 |
| devananda | that IS going to be different per driver | 19:01 |
| devananda | and per deployment | 19:01 |
| *** davideagnello has joined #openstack-ironic | 19:01 | |
| erwan_taf | devananda: if you don't spend time on defining what are the possible states of a server, you'll end with crazy paths and looks of undefined states | 19:02 |
| devananda | because right now, we're encouraging operators to customize their deploy ramdisks | 19:02 |
| devananda | -- and their undeploy ramdisks | 19:02 |
| erwan_taf | devananda: people will do anything anywhere... | 19:02 |
| devananda | (which are probabaly thes ame thing) | 19:02 |
| JayF | devananda: that's true; but the fact we're mixing-in the API-driven hardware actions to that state is what is confusing to me | 19:02 |
| devananda | erwan_taf: sweeping generalizations aren't helpful here | 19:02 |
| JayF | devananda: i.e. for hardware capabilities, in the design summit, we said we would allow a node to be kicked back into ZAPPING via API with instructions to, for instance, setup RAID across it's disks | 19:02 |
| devananda | JayF: I recall, perhaps incorrectly, that that would be out of band | 19:03 |
| JayF | devananda: that sort of stuff happening in the same state as the "automatic security cleanup" is confusing to me, regardless of if what happens in the "automatic cleanup" can vary by hardware/driver | 19:03 |
| erwan_taf | JayF: I can tell this state machine would handle that | 19:03 |
| devananda | by which I mean, not managed by Ironic | 19:03 |
| erwan_taf | JayF: (reset to default) | 19:03 |
| JayF | devananda: that was /not/ the impression I got at all in the design summit | 19:03 |
| erwan_taf | I'm pretty sure the list of possible actions to a server is a finite list | 19:03 |
| devananda | JayF: wait flag | 19:04 |
| JayF | devananda: either way; what you describe is still the same: two different types of actions reflected in teh same state | 19:04 |
| *** marcoemorais has quit IRC | 19:04 | |
| devananda | JayF: but you are correct in that | 19:04 |
| GheRivero | agh! I miss the change in the meeting time! | 19:04 |
| *** marcoemorais has joined #openstack-ironic | 19:04 | |
| Nisha | is hardware capability proposed to be under Zapping? | 19:04 |
| devananda | GheRivero: that's why I pinged you earlier | 19:04 |
| dtantsur | Nisha, the last suggestion was: discovering capabilities - part of discovery, asserting capabilities (e.g. making RAID) - part of zapping | 19:05 |
| victor_lowther | argh, cafe closes in 30 mins | 19:05 |
| GheRivero | stupid me! I was leaving oslo meeting by them. I though you refer to that one | 19:05 |
| victor_lowther | gotta get lunch | 19:05 |
| erwan_taf | having an FSM compatible SM would allow having a very simple core (the FSM) and let drivers only taking care of transitions | 19:05 |
| Nisha | dtantsur, ok thanks | 19:05 |
| devananda | victor_lowther: mmm, food | 19:05 |
| lucasagomes | Nisha, no, I remember we said that zapping can look at capabilties and do something with it | 19:05 |
| lucasagomes | but capabilites aren't defined as part of zapping | 19:05 |
| erwan_taf | the current proposal requires a lot of conditional coding and everytime someone will ask for soemthing, that will create exceptions | 19:06 |
| lucasagomes | (but it's kinda off topic) | 19:06 |
| Nisha | lucasagomes, m getting confused.... :( | 19:06 |
| erwan_taf | making the coding work much more difficult for new comers :" I have to consider all this cases" | 19:06 |
| NobodyCam | lucasagomes: ya lets not go down that road atm | 19:06 |
| Nisha | NobodyCam, ok | 19:07 |
| *** Ariz has joined #openstack-ironic | 19:07 | |
| *** davideagnello has quit IRC | 19:07 | |
| erwan_taf | spliting have the benefit of being semantically easy to understand, reduce the amount of code in each transition and insure that all people expectations are takien in account at some point which is then exportable to a UI as the list of actions is defined | 19:07 |
| *** davideagnello has joined #openstack-ironic | 19:08 | |
| NobodyCam | just to put it out there we can always come back and define more states if we find our perposed model is failing in real work usage | 19:08 |
| erwan_taf | having states that offers multiple outputs is complicated to debug/code | 19:08 |
| *** Ariz has quit IRC | 19:08 | |
| erwan_taf | NobodyCam: by adding a 4th output ? | 19:08 |
| erwan_taf | NobodyCam: I mean, the state machine is overcomplicated for a finite list of states | 19:08 |
| *** Ariz has joined #openstack-ironic | 19:08 | |
| *** Ariz has quit IRC | 19:09 | |
| erwan_taf | I mean we all need the same tasks ... | 19:09 |
| *** Ariz has joined #openstack-ironic | 19:09 | |
| NobodyCam | erwan_taf: I was reffering to the broad nature of zapping | 19:09 |
| devananda | erwan_taf: your statements disparaging the current proposal do not match my understandings of it. I don't want to sit here and argue | 19:09 |
| erwan_taf | if we can agree on having a single action per transition, it means we don't want to achieve a perfectly defined finite list of actions/states | 19:09 |
| *** Ariz is now known as LuisArizmendi | 19:10 | |
| erwan_taf | devananda: I hope you don't receive my proposal as aggressive | 19:11 |
| *** LuisArizmendi has quit IRC | 19:12 | |
| erwan_taf | devananda: I'm just trying to expose a different vision, meaning that if you need a state machine it have to follow a list of rules (which are not mine) to get something consistent | 19:12 |
| devananda | JayF: fwiw, I agree with your point that "two different types of actions [namely, automatic cleanup and operator-initated reconfiguragion] reflected in teh same state" is confusing // bad | 19:12 |
| *** Ariz has joined #openstack-ironic | 19:12 | |
| lucasagomes | yeah folks it's just a proposal | 19:13 |
| erwan_taf | devananda: we _just_ insured that 1 single task was done per action | 19:13 |
| erwan_taf | devananda: and that naturally led to this diagram | 19:13 |
| erwan_taf | devananda: you can try doing the exercise | 19:14 |
| devananda | "single task" | 19:14 |
| *** Ariz is now known as LuisArizmendi | 19:14 | |
| devananda | waht does this mean? | 19:14 |
| erwan_taf | Zapping is doing several things | 19:14 |
| erwan_taf | upgrading a firmware is a task | 19:14 |
| devananda | erwan_taf: yes, but that's not the only thing you changed | 19:14 |
| erwan_taf | cleaning disk is a task | 19:14 |
| erwan_taf | configuring a raid is a task | 19:14 |
| *** cohn has left #openstack-ironic | 19:15 | |
| devananda | how far down that rabbit hole do you wish to go? | 19:15 |
| erwan_taf | I can tell you we started from the existing proposal | 19:15 |
| devananda | downloading image from glance -- task | 19:15 |
| devananda | copying image to disk -- a task | 19:15 |
| *** Ariz has joined #openstack-ironic | 19:15 | |
| devananda | configuring Neutron -- a task | 19:15 |
| devananda | .... | 19:15 |
| *** LuisArizmendi has quit IRC | 19:15 | |
| *** Ariz has quit IRC | 19:15 | |
| erwan_taf | then I asked lucasagomes to explain what each task did and we did the split by semantic & searched for links | 19:15 |
| erwan_taf | devananda: we did it per server state | 19:15 |
| erwan_taf | what are the possible state of a server | 19:16 |
| lucasagomes | it's a broader task, I think you can think about "a task" as a zap_step | 19:16 |
| erwan_taf | everything single state is read like "server is currently in that state" | 19:16 |
| erwan_taf | I mean if we need (and we all need) to update firmwares, then it should be told explically | 19:17 |
| erwan_taf | to find all the possible deps with other tasks | 19:18 |
| JayF | devananda: I'll make sure that comment makes it onto the spec then | 19:18 |
| JayF | devananda: not sure the irc conversation is continuing to be fruitful :( | 19:18 |
| erwan_taf | if you need to redefine raids, then you have to split into a task to cleanup stuf, and a task to create it | 19:18 |
| JayF | Sounds like we'd be spending all day defining state machines and never writing the software to do real work :P | 19:19 |
| devananda | erwan_taf: having a separate task (and thereby a separate state) for every single operation that I might conceivable apply to hardware is not tenable | 19:19 |
| erwan_taf | but the list is here | 19:19 |
| devananda | erwan_taf: firstly, there are far too many things an operator may want to do to simple / standard hardware | 19:19 |
| erwan_taf | I'm pretty sure that this proposal fits any kind of change | 19:19 |
| erwan_taf | (hw change) | 19:19 |
| devananda | erwan_taf: second, there are types of hardware which support totally unique things | 19:19 |
| JayF | erwan_taf: do you have all our custom, downstream steps modeled? | 19:19 |
| devananda | erwan_taf: that just violated your own logic | 19:20 |
| JayF | erwan_taf: like my update_firmware_lsi_nytro task in decom, is that on your list? | 19:20 |
| devananda | erwan_taf: if any kind of change fits in one step, how is taht any different? | 19:20 |
| erwan_taf | JayF: it's a way to implement the cleaning transition for a particular driver ? | 19:20 |
| lucasagomes | JayF, the way we thought that firmware/bios updates goes into normalising | 19:20 |
| * devananda is sad now | 19:20 | |
| JayF | lucasagomes: are you talking about the state machine erwan_taf proposed? | 19:21 |
| lucasagomes | JayF, yup | 19:21 |
| * JayF is not in favor of throwing out half a day at the summit and all the reviews since then for a last-minute incoming idea | 19:21 | |
| JayF | sorry lucas + erwan :( | 19:21 |
| lucasagomes | JayF, it's just a proposal :) | 19:21 |
| erwan_taf | I am also, we had bad timing, didn't being able to get a clean description of this proposal leading to prelimnary delivey (but late) and lead to flameware | 19:22 |
| lucasagomes | JayF, plus, very few things are solved within a summit design session | 19:22 |
| lucasagomes | it's good to exercise, like try to fit the tasks you have on zapping on that state machine | 19:22 |
| JayF | lucasagomes: right now, nothing for k-1 is really solved because it's all backed up on the statemachine stuff | 19:22 |
| *** luisjariz has joined #openstack-ironic | 19:22 | |
| lucasagomes | see if it does cover ur use case | 19:22 |
| NobodyCam | just to remind folks of the orginal state-blueprint: https://blueprints.launchpad.net/ironic/+spec/state-machine | 19:22 |
| JayF | which is more where my annoyance comes from :( | 19:22 |
| lucasagomes | JayF, I'm all about making it land asap | 19:22 |
| NobodyCam | note the comment :Ironic will not attempt to handle multi-state transitions | 19:22 |
| *** andreykurilin_ has joined #openstack-ironic | 19:23 | |
| erwan_taf | JayF: being able to use an existing FSM framework would make the code easier to write & faster integration | 19:23 |
| *** penick has joined #openstack-ironic | 19:23 | |
| erwan_taf | that will end in a custom dev. for a common task | 19:23 |
| lucasagomes | JayF, and the same way we spent 3 hours on the previous state machine we could spend more few hours to think/re-think it | 19:23 |
| lucasagomes | see if it fits, if not we move on | 19:23 |
| lucasagomes | JayF, devananda I can even see ZAPPING being a middle grond here, like we have for vendor_passthru | 19:24 |
| lucasagomes | devananda, JayF once we start identifying the zap_steps that all drivers have been implementing | 19:24 |
| lucasagomes | we could promote then to a proper state | 19:24 |
| erwan_taf | said differently, if you would have to do a FSM for a Robot, you would have made it using an FSM. we are doing automation, I don't make the difference. Having automation that doesn't match a FSM sounds difficult for me | 19:24 |
| JayF | I completely disagree | 19:24 |
| JayF | you can never know what all the steps are | 19:24 |
| lucasagomes | JayF, some I believe you can | 19:24 |
| JayF | because hardware companies are moving as fast as if not faster than us | 19:24 |
| devananda | lucasagomes: this is not "just a proposal" -- I feel (and see, from the comments of others) that the way it was presented came across as destructive to the work many people have spent the last month on | 19:25 |
| JayF | I believe you can try; and get some that fit and some that don't but you'll never get rid of the sepcial case | 19:25 |
| lucasagomes | JayF, I believe you always want to earease the data from previous tenant right? isn't that a CLEAN state? | 19:25 |
| JayF | maybe it's not | 19:25 |
| JayF | maybe I have a diskless machine | 19:25 |
| JayF | or maybe my machine has more than disks that need to be cleaned | 19:25 |
| erwan_taf | devananda: not destructing. please. rephrasing more likely | 19:25 |
| lucasagomes | JayF, fine, states can be non-op | 19:25 |
| *** anderbubble has quit IRC | 19:25 | |
| JayF | I'm saying that the states should reflect general things Ironic does | 19:25 |
| JayF | not the hardware beneath | 19:26 |
| devananda | erwan_taf: there are far too many permutations of hardware out there for us, here, now, to define all states which they can be in | 19:26 |
| JayF | because once you expose it up that far, you break the abstraction and will make it harder to implement "funky" hardware in the future | 19:26 |
| *** anderbubble has joined #openstack-ironic | 19:26 | |
| erwan_taf | we are not speaking about a possible implementation of a particular case | 19:26 |
| devananda | also, I'll revive the coment NobodyCam made a minute ago | 19:26 |
| lucasagomes | devananda, right, def not intentional. The idea was to present something different | 19:26 |
| devananda | "Ironic will not attempt to handle multi-state transitions at this time. Such efforts should be pushed higher up the stack, eg. to Nova or Heat" | 19:26 |
| devananda | that is from my original BP about implementing a FSM for Ironic | 19:26 |
| lucasagomes | with a more clear defined tasks that needs to be accomplished to deploy a node | 19:26 |
| erwan_taf | we are trying to define what are the possible states of a server, it is then up to driver to implement the proper action | 19:26 |
| devananda | Registered by Devananda van der Veen on 2013-05-28 | 19:27 |
| lucasagomes | JayF, right, but that's the middle ground I'm saying | 19:27 |
| JayF | I don't think that's a middle ground at all | 19:27 |
| devananda | lucasagomes: understood - I didn't think either of you meant to derail things, but that is the effect proposing an _alternate_ has, rather than propsing a _change_ to the current proposal | 19:27 |
| lucasagomes | JayF, cause for the tasks tahta can't be predicted ZAPPING would still be there | 19:27 |
| *** andreykurilin_ has quit IRC | 19:28 | |
| lucasagomes | devananda, right, we haven't put a spec or anything. That's why we are first presenting it here on IRC to get this feedback | 19:28 |
| *** andreykurilin_ has joined #openstack-ironic | 19:29 | |
| JayF | I think that's actually worse, lucas :( | 19:29 |
| JayF | because most people spent the time in IRC trying to grok the new thing rather than discussing what already existed | 19:29 |
| JayF | at least something in Gerrit, people can do homework and read up rather than it requiring full attention | 19:29 |
| lucasagomes | JayF, hmm :/ | 19:30 |
| devananda | it's not jsut a matter of time, but effort and momentum | 19:30 |
| devananda | it feels derailing to have a new proposal come out of left field when we already have MANY specs which depend on this proposal | 19:30 |
| devananda | even entertaining a completely different state machine (as opposed to a change to the current one) means many people | 19:31 |
| PaulCzar | am I reading this correct ( https://github.com/openstack/ironic/blob/9cee24e257031c74afcbc9e37c0b705240e9b399/ironic/common/keystone.py#L41-L44 ) that auth_url needs to be set, rather than constructable from auth_host, auth_port, etc ? | 19:31 |
| devananda | who are not cores, but were in the meeting this morning, are now thinking about all the work they have to go re-do | 19:31 |
| PaulCzar | auth_uri even | 19:31 |
| erwan_taf | devananda: sometimes thinking out of the box is valuable | 19:32 |
| devananda | erwan_taf: I didn't say it wasn't | 19:32 |
| erwan_taf | devananda: we tried seriously improving the existing but the final result was not a single patch but a strong change | 19:32 |
| *** Marga_ has quit IRC | 19:33 | |
| erwan_taf | devananda: I do understand if you refuse that big change | 19:33 |
| *** Marga_ has joined #openstack-ironic | 19:33 | |
| *** davideagnello has quit IRC | 19:33 | |
| erwan_taf | devananda: we really started for the existing, and try to solve some issues like getting 1 change per action and adding the conformity checking | 19:33 |
| *** luisjariz has quit IRC | 19:33 | |
| devananda | erwan_taf: I'm not saying the idea is bad. I haven't had nearly enough time to form an opinion like that | 19:33 |
| lucasagomes | devananda, right, I understand the urgency of the spec and all. But like people know that it's a spec and it's being discussed | 19:33 |
| devananda | erwan_taf: but I feel the timing and delivery of this idea was not constructive | 19:34 |
| lucasagomes | and it can change | 19:34 |
| erwan_taf | devananda: which is alsmot the sole change but just looks like very differnent because of that storng "step>action>step" requirement of a DSM | 19:34 |
| erwan_taf | FSM | 19:34 |
| devananda | IIUC, all you really did, besides changing words and adopting FSM notation, is dissect the ZAPPING stage into several stages | 19:34 |
| erwan_taf | devananda: we strongly hope that being FSM compliant would ease the implemention & support of drivers | 19:35 |
| *** davideagnello has joined #openstack-ironic | 19:35 | |
| *** igordcard has quit IRC | 19:35 | |
| *** davideagnello has quit IRC | 19:35 | |
| devananda | erwan_taf: except we already have many drivers | 19:35 |
| *** davideagnello has joined #openstack-ironic | 19:35 | |
| devananda | erwan_taf: who is going to refactor those so that they comply with your proposal? | 19:35 |
| devananda | how long wil lthat take? | 19:35 |
| devananda | (also, we haven't looked at that in depth yet for the current proposal -- but it should be less, because it is building on top of what we already have) | 19:36 |
| erwan_taf | at least we are speaking about a spec that already change that isn't it ? | 19:36 |
| devananda | not throwing it all out | 19:36 |
| erwan_taf | a change is a change | 19:36 |
| devananda | no | 19:36 |
| erwan_taf | we are convering exactly the existing scheme | 19:36 |
| *** dprince has quit IRC | 19:36 | |
| erwan_taf | the optional zapping is just split in functions: you don't need one ? don't implement it, that's "no-op" by default | 19:37 |
| devananda | erwan_taf: your sweeping generalizations aren't helpful, especially when it seems to me like you lack context in this project to know that, for instance, not all changes are equal. a change which affects existing users by breakign compatibility is not equivalent to a change which does not do that | 19:37 |
| devananda | I'm going to step away now and get some brunch | 19:38 |
| NobodyCam | ummm food | 19:38 |
| erwan_taf | that doesn't mean trying to share my experience and getting at some point an explicit list of actions to make a new server being deployed isn't useful for the project | 19:38 |
| erwan_taf | I do understand we are late, but I don't get how a discussion on a spec cannot lead to some different set of changes just because it's a little bit different | 19:39 |
| erwan_taf | sorry if this idea isn't popular, but it's up to the project to offer clean/explicit entry point for actions | 19:41 |
| NobodyCam | erwan_taf: but is an explicit list of actions required i'm of the though that state machine != workflow | 19:42 |
| erwan_taf | letting stuff like zapping is just giving an entry point for everything that doesn't fit elsewhere | 19:42 |
| NobodyCam | erwan_taf: but is that something we can address next cycle if we find that it is causing confusion | 19:43 |
| erwan_taf | if you do consider reworking the state machine, I hope it's not for breaking everything in 6 months :( | 19:44 |
| erwan_taf | I mean that's a serious change, I do agree on that | 19:44 |
| *** marcoemorais has quit IRC | 19:46 | |
| erwan_taf | that's why we tried, but sounds like we failed, at doing the work now to provide a view of an FSM compatible state machine | 19:46 |
| erwan_taf | which is easier to implement | 19:46 |
| *** marcoemorais has joined #openstack-ironic | 19:46 | |
| lucasagomes | aight, proposals are like that. So we can try to get the things we have thought of | 19:47 |
| lucasagomes | look at the current proposal, see some that we can fit there and move on with that | 19:47 |
| lucasagomes | I also don't want to delay yet more this work, it's fundamental to get it done soon | 19:48 |
| *** marcoemorais has quit IRC | 19:48 | |
| *** marcoemorais has joined #openstack-ironic | 19:48 | |
| *** marcoemorais has quit IRC | 19:49 | |
| *** ChuckC has quit IRC | 19:49 | |
| NobodyCam | lucasagomes: correct me where I am wrong but I see your concern being that the current model will make troubleshooting more difficult be cause the last state /may/ be unknowen? | 19:49 |
| lucasagomes | NobodyCam, as well. Also, it's not a FSM | 19:50 |
| erwan_taf | NobodyCam: If you are in DEPLOYED | 19:50 |
| *** marcoemorais has joined #openstack-ironic | 19:50 | |
| *** dtantsur is now known as dtantsur|afk | 19:51 | |
| erwan_taf | NobodyCam: what was the path you took to get there ? | 19:51 |
| erwan_taf | NobodyCam: -ETOOMANYPATH | 19:51 |
| devananda | why does that matter? | 19:51 |
| victor_lowther | erwan_taf: so we jsut save the state transition history for the nodes in the database somewhere. | 19:51 |
| erwan_taf | because when you debug some code, it's nice to know what were the previous steps and what they did | 19:51 |
| victor_lowther | Problem Solved. | 19:51 |
| dtantsur|afk | before I go: did anyone (meaning probably devananda) send our status report to the ML? | 19:52 |
| rloo | dtantsur|afk: I think jroll volunteered to do that after every meeting | 19:52 |
| *** dprince has joined #openstack-ironic | 19:52 | |
| erwan_taf | victor_lowther: a FSM would have provide that feature naturally | 19:52 |
| NobodyCam | erwan_taf: there is a log. I would look there first for most troubleshoot | 19:52 |
| devananda | dtantsur|afk: I did not. I believe jroll has volunteered to do that | 19:52 |
| dtantsur|afk | aha, now we know whom to blame :D | 19:52 |
| erwan_taf | NobodyCam: in an FSM, the path is explicit | 19:52 |
| devananda | erwan_taf: "easy to debug" is not necessarily a reason to do something | 19:52 |
| lucasagomes | victor_lowther, the thing is, once you have a FSM on that model, you can have a engine driving it | 19:53 |
| erwan_taf | devananda: read "predictable" then | 19:53 |
| devananda | erwan_taf: so again I ask, why is single-prior-state necessarily better or a more accurate representation of reality? | 19:53 |
| lucasagomes | victor_lowther, so drivers only implement those "actions" and the engine drives the states | 19:53 |
| lucasagomes | victor_lowther, right now, we have drivers setting states for the nodes like node.provision_state = ACTIVE, so there's no engine driving it | 19:53 |
| lucasagomes | which is what makes coding with a well defined FSM simpler | 19:54 |
| devananda | in my reality, paths converge and diverge. a state machine which can't handle that is not complete. | 19:54 |
| NobodyCam | but then we have a different FSM for each driver | 19:54 |
| erwan_taf | devananda: if some used the "state machine" title isn't for nothing. Ironic really need a state machine which implies some rules : http://en.wikipedia.org/wiki/Finite-state_machine | 19:54 |
| victor_lowther | if I am troubleshooting failure mode, I care about what is in the logs, and I do not care about the details of the state machine until I have to. | 19:54 |
| erwan_taf | devananda: if you don't play that game, you'll have a perfectly custom solution that could have been part of a generic FSM approach | 19:54 |
| devananda | error states are also a state, which we have all conveniently left out -- because they are non-linear | 19:54 |
| erwan_taf | devananda: FSM gives you tooling to solve the implemntation | 19:55 |
| victor_lowther | also, we do not have a FSM by design | 19:55 |
| erwan_taf | devananda: FSM is predictable | 19:55 |
| *** ChuckC has joined #openstack-ironic | 19:55 | |
| victor_lowther | becasue we do not know all the possible states in advance | 19:55 |
| devananda | erwan_taf: hardware is not necessarily predictable | 19:55 |
| erwan_taf | but the expected path to get a server to be installed is | 19:55 |
| erwan_taf | I'm pretty sure we are not speaking about the same stuff | 19:56 |
| victor_lowther | erwan_taf: not past a certian level of detail it is not. | 19:56 |
| erwan_taf | I'm not speaking of a physical state of a server | 19:56 |
| erwan_taf | but a expected and generic state to achieve a goal | 19:56 |
| victor_lowther | or if it is , it is only in the sense that any program implements a FSM. | 19:56 |
| erwan_taf | installing a server doesn't have 100 steps | 19:56 |
| erwan_taf | it doesn't have 100 of exceptions | 19:57 |
| erwan_taf | we all do the same tasks | 19:57 |
| devananda | erwan_taf: no we don't | 19:57 |
| victor_lowther | erwan_taf: I am just going to assume you have never worked in tech support. | 19:57 |
| erwan_taf | using different tools but the life cycle is pretty clear | 19:57 |
| erwan_taf | victor_lowther: thanks | 19:57 |
| devananda | erwan_taf: that assumption right there may be the root of the miscommunication here | 19:57 |
| erwan_taf | why ? | 19:58 |
| devananda | erwan_taf: many current and potential users of Ironic have vastly different steps they take -- while at the 10,000ft view they look similar | 19:58 |
| devananda | the actual steps that each driver takes may be COMPLETELY different | 19:58 |
| devananda | and an oeprator may need to customize that even further locally in ways the upstream community does not (or can not) know about | 19:59 |
| NobodyCam | oh thats a very good point devananda ^^^ | 19:59 |
| *** marcoemorais has quit IRC | 19:59 | |
| *** marcoemorais1 has joined #openstack-ironic | 19:59 | |
| devananda | so in general, sure, enroll -> expose to scheduling -> place workload -> remove workload -> repeat -- in general, that's the FLOW | 19:59 |
| erwan_taf | devananda: I'm not speaking on the implementation on how to do a particular task | 20:00 |
| devananda | the actual states in there, and wjhat each state means locally, and what action(s) get from STATE M to STATE N, may be quite different | 20:00 |
| devananda | erwan_taf: no, you're speaking towhat states and what actions Ironic models | 20:00 |
| devananda | but you have said that there is a finite set of states and tasks, and we should model all of them | 20:01 |
| erwan_taf | which is the entry point to perform particular actions based on implemtnations | 20:01 |
| devananda | and I disagree | 20:01 |
| devananda | we should model *enough* of them | 20:01 |
| devananda | not *all* of them | 20:01 |
| *** marcoemorais1 has quit IRC | 20:01 | |
| erwan_taf | devananda: got your point | 20:01 |
| devananda | :) | 20:01 |
| erwan_taf | I'm really interested to get a task I cannot map here | 20:01 |
| *** marcoemorais has joined #openstack-ironic | 20:01 | |
| erwan_taf | maybe the one that will make me realize that I'm totally wrong | 20:02 |
| erwan_taf | victor_lowther: any example ? | 20:02 |
| * lucasagomes brb for few minutes | 20:02 | |
| devananda | erwan_taf: http://en.wikipedia.org/wiki/Hewlett-Packard#THE-MACHINE | 20:03 |
| devananda | erwan_taf: I'm not suggesting that's using Ironic, but what if it was? can we, today, predict what states that will have? | 20:05 |
| erwan_taf | victor_lowther: and just to present myself, you surely use some of my code everyday you boot | 20:05 |
| erwan_taf | devananda: at a very high level, I'm pretty sure yes. Updating it if possible, cleaning it, prepare it, deploy and restart the same task | 20:06 |
| devananda | erwan_taf: there are tasks which are not part of that | 20:06 |
| erwan_taf | sure so, that's an empty body | 20:06 |
| erwan_taf | a not required step is a nop | 20:07 |
| erwan_taf | return; | 20:07 |
| erwan_taf | machine then transitent from several steps in a row | 20:07 |
| erwan_taf | disruptcy will occur | 20:07 |
| erwan_taf | but up as I know, the logical steps to achieve a deployement are almost the same | 20:08 |
| erwan_taf | but sounds like we disagree on that | 20:08 |
| victor_lowther | This is no longer a productive conversation | 20:09 |
| *** davideagnello has quit IRC | 20:11 | |
| *** Marga_ has quit IRC | 20:13 | |
| *** anderbubble has quit IRC | 20:13 | |
| *** Marga_ has joined #openstack-ironic | 20:13 | |
| *** mrda-away is now known as mrda | 20:15 | |
| mrda | Morning Ironic | 20:15 |
| * erwan_taf throw flowers on the chan and clean the place for new discussions | 20:15 | |
| *** davideagnello has joined #openstack-ironic | 20:21 | |
| *** Nisha has quit IRC | 20:24 | |
| *** marcoemorais has quit IRC | 20:25 | |
| *** dprince has quit IRC | 20:30 | |
| * erwan_taf is switching on making some proposal to the actual proposal | 20:30 | |
| rloo | if we don't call it a 'state machine' or a 'finite state machine', will that make the new states & transitions more acceptable? | 20:32 |
| erwan_taf | that really describe a state machine so that's not a mater of naming here | 20:36 |
| NobodyCam | morning mrda :) | 20:36 |
| *** Masahiro has joined #openstack-ironic | 20:37 | |
| * lucasagomes is back | 20:38 | |
| mrda | hey NobodyCam | 20:38 |
| lucasagomes | morning mrda | 20:40 |
| NobodyCam | wb lucasagomes :) | 20:40 |
| lucasagomes | NobodyCam, hey ya | 20:41 |
| lucasagomes | devananda, JayF jroll NobodyCam right so anyway, thanks for listening to the proposal thing | 20:41 |
| lucasagomes | I think we can move forward with the current one, I will continue to review that spec | 20:41 |
| *** Masahiro has quit IRC | 20:42 | |
| openstackgerrit | Ruby Loo proposed openstack/ironic-specs: Don't deprecate maint mode updates via node-update https://review.openstack.org/138178 | 20:42 |
| lucasagomes | rloo, in a sense, I think it would | 20:44 |
| lucasagomes | but it's fine, I don't have a better name for it as well | 20:45 |
| devananda | lucasagomes: a brief example of my frustration around the timing of this -- I would much rather we all have spent that time/energy discussing some of the unanswered questions in this spec | 20:46 |
| devananda | lucasagomes: such as how to handle backwards-compat at the REST and driver api levels | 20:46 |
| devananda | lucasagomes: or the "wait flag" and error states, both of which are still unexplored | 20:46 |
| devananda | or not explored well enough | 20:46 |
| devananda | instead, I feel very frustrated | 20:46 |
| rloo | lucasagomes: I like the idea of it being a FSM (or state machine), but I don't know enough to know whether what is proposed is strictly that, and I don't know if that is really a goal here | 20:48 |
| erwan_taf | I wonder how to express the fact this proposal is lacking of steps that would be useful to insure conformity of servers | 20:48 |
| lucasagomes | devananda, right, it's not all waste of time tho. I can say that I've learned a couple of things working on that proposal. Like having a FSM that conforms to a model | 20:48 |
| lucasagomes | playing with the abstraction | 20:48 |
| lucasagomes | rloo, yeah | 20:49 |
| mrda | hey lucasagomes | 20:50 |
| devananda | lucasagomes: surely we all learned something from this conversation. but did it get Ironic closer to our goals for Kilo, or further? | 20:50 |
| devananda | not really asking that, btw. I know what it feels like to me | 20:50 |
| lucasagomes | devananda, right, I could argue it does. If didn't have this conversation I would have a lot of "what-if" in my head | 20:51 |
| lucasagomes | I have a cleaner go now | 20:51 |
| devananda | lucasagomes: that's good :) | 20:52 |
| *** yjiang5_ has joined #openstack-ironic | 20:52 | |
| lucasagomes | yeah, and I wouldn't be here until very late w/o dinner or anything if I didn't care enough | 20:53 |
| lucasagomes | so we should move on :) | 20:53 |
| lucasagomes | and I will get some dinner | 20:53 |
| devananda | food is good too :) | 20:53 |
| lucasagomes | +1 have a good night everyone | 20:53 |
| lucasagomes | see ya tomorrow | 20:53 |
| rloo | nght lucasagomes! | 20:53 |
| *** marcoemorais has joined #openstack-ironic | 20:54 | |
| *** lucasagomes is now known as lucas-dinner | 20:54 | |
| erwan_taf | see ya lucas-dinner | 20:55 |
| *** spandhe has quit IRC | 20:58 | |
| NobodyCam | night lucas-dinner | 20:58 |
| *** anderbubble has joined #openstack-ironic | 20:58 | |
| openstackgerrit | Jarrod Johnson proposed stackforge/pyghmi: Implement server side IPMI protocol (WIP) https://review.openstack.org/138109 | 21:04 |
| *** Marga_ has quit IRC | 21:06 | |
| *** Marga_ has joined #openstack-ironic | 21:06 | |
| NobodyCam | jjohnson2: awesome to those patches :) | 21:08 |
| *** spandhe has joined #openstack-ironic | 21:08 | |
| jjohnson2 | NobodyCam, a fun project between conference calls | 21:08 |
| NobodyCam | :) | 21:08 |
| jjohnson2 | and analyzing things like voltage regulation circuit variations | 21:09 |
| jjohnson2 | I just shuddered at the thought of a single process trying to talk ipmi to itself... | 21:14 |
| *** andreykurilin_ has quit IRC | 21:16 | |
| *** andreykurilin__ has joined #openstack-ironic | 21:16 | |
| jjohnson2 | heh, reading a comment of mine "# unrecognized data, assume evil" calls to mind the star trek tng data and lore | 21:17 |
| NobodyCam | lol | 21:17 |
| *** igordcard has joined #openstack-ironic | 21:17 | |
| erwan_taf | see ya guys | 21:18 |
| NobodyCam | bbc just played many of the tng's over the holiday | 21:18 |
| jjohnson2 | I got til thursday before I vacation for the year, will see if I managed to squeeze a testable thing in | 21:18 |
| NobodyCam | have a good night erwan_taf | 21:18 |
| NobodyCam | jjohnson2: :) | 21:18 |
| *** alexiz has joined #openstack-ironic | 21:20 | |
| *** rloo_ has joined #openstack-ironic | 21:21 | |
| *** PaulCzar_ has joined #openstack-ironic | 21:22 | |
| *** ChuckC_ has joined #openstack-ironic | 21:22 | |
| *** erwan_taf has quit IRC | 21:23 | |
| *** tchaypo_ has joined #openstack-ironic | 21:23 | |
| *** Marga_ has quit IRC | 21:25 | |
| *** Marga_ has joined #openstack-ironic | 21:25 | |
| openstackgerrit | Victor Lowther proposed openstack/ironic-specs: New Ironic provisioner state machine. https://review.openstack.org/133828 | 21:26 |
| *** spandhe has quit IRC | 21:27 | |
| *** BertieFulton has quit IRC | 21:31 | |
| *** linggao has quit IRC | 21:33 | |
| *** igordcard has quit IRC | 21:35 | |
| *** ChuckC has quit IRC | 21:35 | |
| *** rloo has quit IRC | 21:35 | |
| *** shakayumi has quit IRC | 21:35 | |
| *** tchaypo has quit IRC | 21:35 | |
| *** russellb has quit IRC | 21:35 | |
| *** PaulCzar has quit IRC | 21:35 | |
| jjohnson2 | I'm not going to support ipmi origin and destination in the same python process for now... that's just too perverse... | 21:35 |
| *** tchaypo_ is now known as tchaypo | 21:36 | |
| *** PaulCzar_ is now known as PaulCzar | 21:37 | |
| openstackgerrit | Victor Lowther proposed openstack/ironic-specs: New Ironic provisioner state machine. https://review.openstack.org/133828 | 21:39 |
| NobodyCam | victor_lowther: is zapping the only state a node in INIT cat transation to? | 21:40 |
| victor_lowther | That seems to be the way some want to simplify the state transitions. I am okay with it because the zapping spec has a mechanism that can turn ZAPPING into a nop. | 21:42 |
| NobodyCam | ack | 21:44 |
| devananda | victor_lowther: you did the same thing I was about to -- add () to the ascii art. nice | 21:47 |
| devananda | victor_lowther: wdyt of s/INIT/MANAGED/ ? | 21:49 |
| victor_lowther | As long as the semantics stay the same, I don't really care beyond noting that INIT is shorter. :) | 21:50 |
| devananda | yes, same semantics. but represented more clearly in that a node which is [ENROLLED] must be validated before it can reach [MANAGED] | 21:51 |
| devananda | which I'd represent with a (VALIDATING) state | 21:51 |
| devananda | just filling in part of the dia, based on the words you've written, and that seems to be clearer | 21:51 |
| devananda | also, MANAGED isn't longer than other words we already have for state names | 21:52 |
| devananda | :) | 21:52 |
| devananda | victor_lowther: oh, and wouldn't it be ENROLLED, not [ENROLLED] ? | 21:53 |
| victor_lowther | so split what happens in ENROLL into 3 states, then. | 21:53 |
| NobodyCam | sorry I lost a bunch of my thoughts this morning: for the deleted state should we follow the same path as INIT and only allow nodes to transition to zapping | 21:54 |
| victor_lowther | ENROLL -> [VALIDATING] -> (ENROLLED) -> MANAGED | 21:54 |
| victor_lowther | and probably rename ENROLLFAIL to VALIDATEFAIL while I am at it. | 21:55 |
| devananda | victor_lowther: you've described the automatic flow today, something like [ENROLLED] -> [ENROLLFAIL] -> [ENROLLED] -> INIT | 21:55 |
| devananda | er, I mean [ENROLLED] -> (ENROLLFAIL) -> [ENROLLED] -> INIT | 21:55 |
| victor_lowther | well, except for the ENROLLFAIL bit. :) | 21:56 |
| victor_lowther | dtantsur|afk wants ENROLL -> [VALIDATING] to be a manual step | 21:56 |
| *** andreykurilin__ has quit IRC | 21:56 | |
| devananda | the "try to validate any time driver_info is changed" bit is where I forsee some difficulty | 21:57 |
| victor_lowther | but his comments got lost due to typo fixes. :) | 21:57 |
| devananda | yea, that's not surprising | 21:57 |
| devananda | I would prefer that as well, at least today | 21:57 |
| *** andreykurilin has joined #openstack-ironic | 21:57 | |
| victor_lowther | so do I, but that seemed to be what people wanted. | 21:57 |
| victor_lowther | Having it be manual would be simpler. | 21:57 |
| devananda | i mean, i would prefer not-auto-validate | 21:58 |
| devananda | cool. we agree :) | 21:58 |
| *** spandhe has joined #openstack-ironic | 21:58 | |
| * jroll finally finishes reading scrollback | 21:58 | |
| victor_lowther | NobodyCam: that is what the current rev of the spec does. | 21:58 |
| devananda | victor_lowther: or have VALIDATING kick back to ENROLLED with a last_error | 21:59 |
| victor_lowther | kick back to ENROLL, you mean? | 21:59 |
| devananda | sure | 21:59 |
| NobodyCam | victor_lowther: Nodes in DELETED can transition back to AVAILABLE or can have tasks enqueued on them and then transition to ZAPPING | 22:01 |
| openstackgerrit | Jarrod Johnson proposed stackforge/pyghmi: Implement server side IPMI protocol (WIP) https://review.openstack.org/138109 | 22:01 |
| victor_lowther | crap, I thought I deleted that verbiage. | 22:01 |
| victor_lowther | comment in spec pld? | 22:01 |
| NobodyCam | will do | 22:02 |
| jjohnson2 | NobodyCam, well, that's it for today, I wired to the vague area that would ultimately handle sessionless messages and will spawn a server mode session | 22:03 |
| jjohnson2 | next up, handle get channel auth cap, and rmcp+ session negotiation (defer 1.5 IPMI til... when someone cares...) | 22:03 |
| victor_lowther | jjohnson2: never. | 22:04 |
| jjohnson2 | victor_lowther, that would be my guess. Why anyone would need a new 1.5 ipmi *target* is currently beyond me, so I'm inclined to leave 1.5 support to be client-only | 22:05 |
| lucas-dinner | victor_lowther, looks nicer with the zapping pass there (which can be non-op) | 22:05 |
| lucas-dinner | victor_lowther, devananda what about the rescue state, it's a bit unclear to me yet | 22:05 |
| NobodyCam | jjohnson2: awesome thank you :) | 22:06 |
| devananda | I'm going to side track for a second, because two things have been niggling the back of my mind today (and for a while now) | 22:06 |
| devananda | and then I'm going to go shopping for dinner | 22:06 |
| lucas-dinner | cause ACTIVE means tenant is on that node, so operators would ask for rescue right? | 22:06 |
| devananda | from a linguistic POV, we have two categories of state names: verbs, which are either present or past tense, indicating an ongoing or completed action upon the physical server; adverbs, which indicate the status of the logical resource | 22:06 |
| jjohnson2 | NobodyCam, it may be a christmas miracle | 22:06 |
| devananda | lucas-dinner: user can ask for rescue via Nova | 22:06 |
| lucas-dinner | devananda, a-ha! | 22:06 |
| lucas-dinner | right | 22:06 |
| jjohnson2 | devananda, oh, like if I'm on a boat at sea, and it starts sinking? | 22:07 |
| jjohnson2 | nova is more capable than I would have ever imagined | 22:07 |
| devananda | jjohnson2: lol | 22:08 |
| jjohnson2 | well, guess you can *ask* anyone/anything for rescue | 22:08 |
| jjohnson2 | it won't necessarily meaningfully respond, but at least you asked... | 22:08 |
| jjohnson2 | well, that's it for a day, I'm too punchy | 22:08 |
| NobodyCam | have a good night jjohnson2 :) | 22:09 |
| devananda | the actual physical hardware is quite possibly in exactly the same "state" | 22:10 |
| devananda | whether Ironic indicates ENROLL, INIT, or AVAILABLE | 22:10 |
| devananda | these are differences in the logical resource, not physical | 22:10 |
| victor_lowther | Pretty much | 22:10 |
| devananda | i have no idea yet if this is a helpful distinction to anyone else | 22:10 |
| devananda | but our state names don't make this clear | 22:11 |
| *** andreykurilin has quit IRC | 22:11 | |
| victor_lowther | I don't really see why they should | 22:11 |
| *** andreykurilin has joined #openstack-ironic | 22:12 | |
| victor_lowther | I mean yes, if the server comes preconfigured from the factory for its role (which I would expect if you are ordering hundreds at a time), then all our ZAPPING and DEPLOYING isn't changing the way the underlying hardware is configured | 22:13 |
| NobodyCam | never trust what the box says! | 22:13 |
| victor_lowther | but we need to funnel the nodes into the states they want regardless of whether the underlying hardware config will change. | 22:14 |
| victor_lowther | because realistically having every server in your order come in the exact config you want without problems is a pipe dream. | 22:15 |
| *** jjohnson2 has quit IRC | 22:15 | |
| victor_lowther | you will have things jostled in transit, flaky batteries, dead hard drives, bad firmware, etc. etc. etc. | 22:16 |
| victor_lowther | and if you don't walk through all the config steps, you will regret it later. | 22:16 |
| NobodyCam | ++ or you ordered your hardware from eMachines | 22:17 |
| devananda | victor_lowther: hmm. I didn't mean to imply anything i nregards to changing the order of state transitions | 22:18 |
| victor_lowther | or you ordered your hardware, got it, ran out of funcing, and put the project on hold until next year's budget | 22:18 |
| victor_lowther | and all your raid batteries died in the process. | 22:18 |
| * victor_lowther has personally replaced hundreds of parts for that exact reason | 22:19 | |
| NobodyCam | :) ++ | 22:19 |
| NobodyCam | I had this rack of Cobalt Raq's | 22:20 |
| NobodyCam | batteries and fans needed replacing all the time | 22:20 |
| victor_lowther | devananda: then I don't see what you are getting at | 22:20 |
| victor_lowther | NobodyCam: There is a company I have not heard of in awhile. | 22:21 |
| NobodyCam | :) | 22:21 |
| NobodyCam | had lots of them (in the before times) | 22:21 |
| devananda | victor_lowther: possibly nothing :) | 22:21 |
| *** Marga_ has quit IRC | 22:22 | |
| *** Marga_ has joined #openstack-ironic | 22:22 | |
| devananda | victor_lowther: just that we're indicating changes in the status of a logical resource using the same semantics, but different lingustics, as with changes in a physical resource | 22:23 |
| victor_lowther | and at the least the underlying hardware has increased entropy locally, and so it not in the exact same state. :) | 22:23 |
| devananda | also, I offer this dia of our current state machine for reference, from memory (so it might be incorrect) -- http://paste.openstack.org/raw/HUZHE3VJySpDEyj7g5hT/ | 22:24 |
| devananda | seeing that helps me start thinking about how to migrate forward with some modicum of upgrade path | 22:25 |
| victor_lowther | yeah | 22:25 |
| devananda | like, we're missing [REBUILD] | 22:25 |
| NobodyCam | yep we have rescue now | 22:25 |
| victor_lowther | What did REBUILD do? | 22:26 |
| *** Masahiro has joined #openstack-ironic | 22:26 | |
| jroll | sigh, rebuild | 22:26 |
| jroll | is that a state? | 22:26 |
| NobodyCam | redeploys with fs changes | 22:26 |
| jroll | I thought it was just DEPLOYING | 22:26 |
| NobodyCam | with *OUT* | 22:26 |
| NobodyCam | yes: https://github.com/openstack/ironic/blob/master/ironic/common/states.py#L87 | 22:27 |
| devananda | jroll: https://github.com/openstack/ironic/blob/master/ironic/api/controllers/v1/node.py#L345 | 22:27 |
| jroll | blah | 22:27 |
| jroll | I guess that's good, I just didn't realize it | 22:28 |
| devananda | it is a request'able provision_state | 22:28 |
| *** penick has quit IRC | 22:28 | |
| jroll | right | 22:28 |
| victor_lowther | it seems quite nova specific. | 22:29 |
| devananda | it's like reset-from-scratch | 22:29 |
| *** igordcard has joined #openstack-ironic | 22:29 | |
| devananda | it's like reset-from-scratch-but-keep-my-IP-and-host | 22:29 |
| jroll | it's "lay down a new OS" | 22:30 |
| jroll | (imo) | 22:30 |
| devananda | yup | 22:30 |
| jroll | "and maybe keep some data around" | 22:30 |
| devananda | the maybe keep data is the silly part, IMO. that can be done in other ways | 22:30 |
| jroll | victor_lowther: tripleo uses this to upgrade software, they build a new image and use --preserve-ephemeral | 22:30 |
| devananda | what's more broadly useful is "keep my IP and host" | 22:30 |
| jroll | sure | 22:30 |
| devananda | whereas nova delete + nova boot does not guarantee anything about IP or host | 22:31 |
| *** Masahiro has quit IRC | 22:31 | |
| jroll | right, ofc | 22:31 |
| victor_lowther | yeah, to me that sounds like a transition from ACTIVE to DEPLOYING | 22:32 |
| devananda | victor_lowther: basically, yes | 22:32 |
| devananda | the representation of a node which is being rebuilt is | 22:32 |
| devananda | current_state: rebuild, target_state: deploydone | 22:33 |
| devananda | (/me double checks that) | 22:33 |
| devananda | nope, i'm wrong | 22:34 |
| devananda | current_state: deploying, target_state: deploydone | 22:34 |
| devananda | the 'rebuild' state only exists as a REST verb. that's rather inconsistent, but oh well. | 22:34 |
| NobodyCam | sounds like a bug :-p | 22:35 |
| *** penick has joined #openstack-ironic | 22:35 | |
| devananda | PUT /nodes/<uuid>/states/provision {target: "rebuild"} | 22:35 |
| *** ryanpetrello has quit IRC | 22:36 | |
| *** ryanpetrello has joined #openstack-ironic | 22:36 | |
| *** Marga_ has quit IRC | 22:39 | |
| *** Marga_ has joined #openstack-ironic | 22:39 | |
| *** ryanpetrello has quit IRC | 22:42 | |
| * lucas-dinner added some comments to the spec | 22:42 | |
| NobodyCam | devananda: cli appers to support rebuild | 22:43 |
| victor_lowther | devananda: Could you add your enroll change comments to the spec? I am about to go rescue my wife from my kids. Or vice versa. | 22:43 |
| *** andreykurilin has quit IRC | 22:43 | |
| *** andreykurilin has joined #openstack-ironic | 22:44 | |
| devananda | victor_lowther: ack | 22:45 |
| devananda | victor_lowther: also cleaned up my ascii art a bit, will link in my comments | 22:45 |
| lucas-dinner | brb | 22:46 |
| devananda | http://paste.openstack.org/raw/YzaNhr2mE2QONzcgk6Gz/ | 22:49 |
| NobodyCam | very nice! | 22:49 |
| NobodyCam | the "//" helps :) | 22:51 |
| *** ryanpetrello has joined #openstack-ironic | 22:57 | |
| devananda | victor_lowther: I am going to take a quick stab at redrawing your state diagram. hope you don't mind | 23:00 |
| victor_lowther | Go for it dude. | 23:01 |
| victor_lowther | I will be back later tonight. | 23:01 |
| *** ryanpetrello_ has joined #openstack-ironic | 23:02 | |
| *** ryanpetrello has quit IRC | 23:04 | |
| *** yjiang5_ is now known as yjiang5 | 23:04 | |
| *** ryanpetrello_ is now known as ryanpetrello | 23:04 | |
| *** Marga_ has quit IRC | 23:10 | |
| *** Marga_ has joined #openstack-ironic | 23:10 | |
| *** arif-ali has quit IRC | 23:12 | |
| *** Marga_ has quit IRC | 23:15 | |
| *** Marga_ has joined #openstack-ironic | 23:15 | |
| *** Marga_ has quit IRC | 23:16 | |
| *** Marga_ has joined #openstack-ironic | 23:17 | |
| *** arif-ali has joined #openstack-ironic | 23:19 | |
| NobodyCam | brb | 23:19 |
| *** arif-ali has quit IRC | 23:26 | |
| *** andreykurilin has quit IRC | 23:26 | |
| *** andreykurilin has joined #openstack-ironic | 23:27 | |
| *** andreykurilin_ has joined #openstack-ironic | 23:28 | |
| dlaube | hmm.. I keep getting "Could not download image with id 1edccf41-f244-4304-ab65-66d28d5a86a7." a few minutes after I run a nova boot | 23:29 |
| dlaube | I can see the image with that id when I glance image-list | 23:29 |
| dlaube | verified that both the user image and the kernel and initrd images are there and have public=true set | 23:30 |
| NobodyCam | dlaube: are you using IPA? | 23:31 |
| *** anderbubble has quit IRC | 23:31 | |
| *** andreykurilin has quit IRC | 23:32 | |
| *** Marga_ has quit IRC | 23:32 | |
| dlaube | NobodyCam: using driver | agent_ssh | 23:32 |
| dlaube | on devstack | 23:32 |
| *** Marga_ has joined #openstack-ironic | 23:32 | |
| NobodyCam | any thing more in the conductor log | 23:33 |
| jroll | aha | 23:33 |
| jroll | dlaube: check out conductor logs, may have more info | 23:34 |
| jroll | dlaube: also, you need whole disk image | 23:34 |
| NobodyCam | I bet swift temp url? | 23:34 |
| jroll | yeah | 23:34 |
| NobodyCam | oh good point jroll | 23:34 |
| *** arif-ali has joined #openstack-ironic | 23:34 | |
| dlaube | ironic cond log shows: | 23:34 |
| dlaube | 2014-12-01 18:01:57.970 ERROR ironic.drivers.modules.agent [-] node 1d0203c6-151c-4113-bb31-738b336a07e4 command status errored: {u'message': u'Error downloading image.', u'code': 500, u'type': u'ImageDownloadError', u'details': u'Could not download image with id 1edccf41-f244-4304-ab65-66d28d5a86a7.'} | 23:34 |
| jroll | blah | 23:34 |
| jroll | that would be actually downloading | 23:34 |
| dlaube | how would I know if its a swift temp url issue? | 23:35 |
| jroll | probably bad swift temp url would be my guess | 23:35 |
| jroll | so ironic should have logged the url at some point | 23:35 |
| jroll | the swift url, that is | 23:35 |
| dlaube | should I grep ironic cond log for the glance image id? | 23:35 |
| jroll | are you using the localrc that's provided in our dev docs | 23:35 |
| jroll | sure, that would work | 23:35 |
| dlaube | localrc / openrc | 23:35 |
| dlaube | yes | 23:35 |
| jroll | ok | 23:35 |
| jroll | the other thing you could do is, remove devstack/files/ir-*, clone ironic-python-agent, apply this patch, and set IRONIC_BUILD_RAMDISK=True | 23:36 |
| jroll | https://review.openstack.org/#/c/134813/ | 23:36 |
| jroll | that will send IPA logs to console | 23:37 |
| jroll | there may be an easier way, hang on | 23:37 |
| jroll | oh wait, it should log to console already | 23:37 |
| jroll | dlaube: look at the console logs (/opt/stack/ironic-bm<tab>/something, sorry that isn't more helpful | 23:38 |
| dlaube | cool, ty | 23:39 |
| dlaube | checking now jroll | 23:39 |
| dlaube | hmm | 23:43 |
| dlaube | ive got 6 nodes on there | 23:43 |
| dlaube | checking each one | 23:43 |
| dlaube | most seem to trail off to a login prompt | 23:43 |
| jroll | how recent is your devstack, btw? | 23:44 |
| * NobodyCam wounders if lines like "Up to 50% off. Work can wait. These deals won't." will get ad folks in trouble ashe deletes another cyber monday spam mail | 23:47 | |
| *** andreykurilin_ has quit IRC | 23:49 | |
| *** ChuckC_ has quit IRC | 23:53 | |
| Kamilion | NobodyCam: ugh, I'm getting text messages from my Uncarrier, t-mobile, begging me to switch to a contract plan I don't qualify for. ._. | 23:54 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!