| *** naohirot has joined #openstack-ironic | 00:00 | |
| naohirot | good morning ironic! | 00:00 |
|---|---|---|
| NobodyCam | morning marios | 00:00 |
| NobodyCam | gah | 00:00 |
| NobodyCam | morning naohirot | 00:01 |
| naohirot | NobodyCam: Hi, thank you for the approval :-) | 00:01 |
| NobodyCam | huh | 00:01 |
| NobodyCam | :-p | 00:01 |
| NobodyCam | thank you | 00:02 |
| naohirot | NobodyCam: so is it okay to change the status to "approval" and the delivery to "started" ? | 00:03 |
| *** clif has joined #openstack-ironic | 00:03 | |
| *** clif is now known as clif_h | 00:03 | |
| naohirot | NobodyCam: I'm asking about https://blueprints.launchpad.net/ironic | 00:03 |
| JayF | naohirot: that's something devananda has to do once he sees the spec is approved | 00:04 |
| NobodyCam | he has a tool for that | 00:04 |
| NobodyCam | at least I think he does | 00:04 |
| jroll | yeah, spec2bp.py or something | 00:04 |
| jroll | ttx wrote it | 00:05 |
| naohirot | JayF: good evening | 00:05 |
| *** dlaube has quit IRC | 00:05 | |
| NobodyCam | he may have a set time to run that.. I'm not sure | 00:05 |
| naohirot | JayF: NobodyCam: Okay I understood, thanks. | 00:05 |
| NobodyCam | devananda: around still? | 00:05 |
| jroll | I mean, blueprint status isn't actually that important, as a developer | 00:06 |
| naohirot | jroll: Hi | 00:06 |
| jroll | it only really matters to release folks | 00:06 |
| jroll | hiya naohirot :) | 00:06 |
| NobodyCam | ya naohirot feel free to start | 00:06 |
| JayF | hey guys, so clif_h is a new developer working with us on Rackspace OnMetal and as such will be working as well on Ironic :) everyone treat him nicely | 00:07 |
| naohirot | NobodyCam: yes, I'll ask a lot of question maybe once I started cording :-) | 00:07 |
| JayF | and NobodyCam this means no more [^j|J*] | 00:07 |
| jroll | lolol | 00:07 |
| jroll | and by "nicely", we mean throw a few low-hanging busses at him :) | 00:08 |
| * naohirot started meeting | 00:08 | |
| clif_h | low-hanging fruit you mean | 00:08 |
| jroll | busses, too | 00:09 |
| JayF | beep beep | 00:09 |
| jroll | http://31.media.tumblr.com/tumblr_lz1lwc25ox1rnua94o1_500.gif | 00:09 |
| jroll | and, just realized I forgot to take care of my latest bus yesterday :| | 00:10 |
| JayF | we'll have to find a bigger, scarier bus to throw you under as punishment | 00:10 |
| NobodyCam | lol | 00:10 |
| jroll | nooooooooo | 00:10 |
| NobodyCam | Hi ya clif_h | 00:10 |
| clif_h | NobodyCam: hello | 00:11 |
| NobodyCam | JayF: clif_h: https://bugs.launchpad.net/ironic/+bugs?field.tag=low-hanging-fruit | 00:12 |
| rloo | jroll: maybe clif_h can fix that set-maintenance-mode-off-via-node-update-should-reset-maintenance-reason | 00:19 |
| jroll | ok, weekly status report finally sent | 00:21 |
| jroll | rloo: sureynot | 00:21 |
| rloo | clif_h: if you have any questions, just ask jroll ;) | 00:21 |
| * jroll runs | 00:21 | |
| NobodyCam | night jroll | 00:22 |
| jroll | lol | 00:22 |
| jroll | I'm not leaving | 00:22 |
| jroll | just running away from ruby | 00:22 |
| *** ryanpetrello has quit IRC | 00:22 | |
| *** yuanying has quit IRC | 00:23 | |
| NobodyCam | lol | 00:23 |
| *** yuanying has joined #openstack-ironic | 00:23 | |
| devananda | NobodyCam: pong | 00:24 |
| *** yuanying has quit IRC | 00:24 | |
| *** yuanying has joined #openstack-ironic | 00:27 | |
| *** smoriya has joined #openstack-ironic | 00:27 | |
| NobodyCam | devananda: ping | 00:28 |
| devananda | pong | 00:28 |
| NobodyCam | lol | 00:28 |
| jroll | -.- | 00:29 |
| jroll | devananda: the ping earlier I believe was asking about updating blueprint statuses | 00:29 |
| NobodyCam | oh | 00:29 |
| devananda | oh | 00:29 |
| NobodyCam | that | 00:29 |
| jroll | lol, I should have kept my mouth shut and watched this keep going back and forth | 00:30 |
| NobodyCam | jroll: https://www.youtube.com/watch?v=IhJQp-q1Y1s | 00:31 |
| *** ryanpetrello has joined #openstack-ironic | 00:31 | |
| jroll | hahaha | 00:31 |
| NobodyCam | devananda: I was just checking if there was a set time you ran the blueprint update script | 00:32 |
| devananda | nope | 00:32 |
| devananda | just when ever I'm reminded to | 00:32 |
| NobodyCam | ack :) | 00:33 |
| NobodyCam | naohirot: ^^^^ | 00:33 |
| NobodyCam | lol | 00:33 |
| devananda | naohirot: please update the delivery status as you go. I will not necessarily know when the work is completed | 00:33 |
| naohirot | NobodyCam: yes | 00:33 |
| naohirot | devananda: good evening | 00:33 |
| devananda | naohirot: since kilo-1 is on Dec 18, I targeted irmc power driver to the next milestone, kilo-2 | 00:35 |
| naohirot | devananda: Okay, I'll update the delivery status, thanks | 00:35 |
| devananda | naohirot: if you think the code will be ready this week, let me know and I can re-target to kilo01 | 00:35 |
| naohirot | devananda: I'll work toward kilo-2 since I haven't stated coding :-) | 00:36 |
| devananda | sounds good | 00:37 |
| naohirot | devananda: thanks | 00:38 |
| *** Masahiro has joined #openstack-ironic | 00:46 | |
| *** Masahiro has quit IRC | 00:50 | |
| *** ryanpetrello has quit IRC | 00:52 | |
| *** spandhe has quit IRC | 01:02 | |
| *** kurtrao has joined #openstack-ironic | 01:07 | |
| *** Masahiro has joined #openstack-ironic | 01:08 | |
| *** yuanying has quit IRC | 01:08 | |
| *** yuanying has joined #openstack-ironic | 01:09 | |
| *** yuanying has quit IRC | 01:15 | |
| *** yuanying has joined #openstack-ironic | 01:16 | |
| *** yuanying has quit IRC | 01:17 | |
| *** yuanying has joined #openstack-ironic | 01:19 | |
| *** rloo has quit IRC | 01:22 | |
| lintan | Haomeng:Hi | 01:25 |
| *** chenglch has joined #openstack-ironic | 01:31 | |
| *** yuanying has quit IRC | 01:33 | |
| *** ryanpetrello has joined #openstack-ironic | 01:34 | |
| *** yuanying has joined #openstack-ironic | 01:38 | |
| *** yuanying has quit IRC | 01:40 | |
| *** killer_prince is now known as lazy_prince | 01:40 | |
| *** ryanpetrello has quit IRC | 01:48 | |
| *** yuanying has joined #openstack-ironic | 01:50 | |
| Haomeng | lintan: good morning:) | 01:51 |
| *** hemna__ has quit IRC | 01:53 | |
| *** nosnos has joined #openstack-ironic | 01:56 | |
| *** r-daneel has quit IRC | 02:03 | |
| *** Marga_ has quit IRC | 02:11 | |
| *** Masahiro has quit IRC | 02:18 | |
| *** Masahiro has joined #openstack-ironic | 02:21 | |
| *** hemna__ has joined #openstack-ironic | 02:22 | |
| *** marcoemorais has quit IRC | 02:24 | |
| *** ryanpetrello has joined #openstack-ironic | 02:26 | |
| openstackgerrit | Arun S A G proposed openstack/python-ironicclient: Add option to specify node uuid in node-create subcommand https://review.openstack.org/132137 | 02:30 |
| *** ryanpetrello has quit IRC | 02:31 | |
| *** rushiagr_away is now known as rushiagr | 02:42 | |
| *** Masahiro has quit IRC | 02:52 | |
| *** Masahiro has joined #openstack-ironic | 02:53 | |
| *** hemna__ has quit IRC | 02:55 | |
| *** Masahiro has quit IRC | 02:59 | |
| *** ryanpetrello has joined #openstack-ironic | 03:02 | |
| *** ryanpetrello has quit IRC | 03:12 | |
| *** Masahiro has joined #openstack-ironic | 03:22 | |
| *** ramineni has joined #openstack-ironic | 03:22 | |
| *** rushiagr is now known as rushiagr_away | 03:27 | |
| *** naohirot has quit IRC | 03:27 | |
| *** ryanpetrello has joined #openstack-ironic | 03:31 | |
| *** enterprisedc has quit IRC | 03:33 | |
| *** enterprisedc has joined #openstack-ironic | 03:33 | |
| *** nosnos has quit IRC | 03:39 | |
| *** Nisha has joined #openstack-ironic | 03:40 | |
| *** achanda has joined #openstack-ironic | 03:44 | |
| *** harlowja_ is now known as harlowja_away | 03:47 | |
| *** Haomeng|2 has joined #openstack-ironic | 03:48 | |
| *** Haomeng has quit IRC | 03:48 | |
| *** rushiagr_away is now known as rushiagr | 03:53 | |
| openstackgerrit | Nisha Agarwal proposed openstack/ironic-specs: uefi support for agent-ilo driver https://review.openstack.org/137024 | 04:02 |
| *** naohirot has joined #openstack-ironic | 04:04 | |
| *** pensu has joined #openstack-ironic | 04:05 | |
| *** yuanying_ has joined #openstack-ironic | 04:14 | |
| *** pensu has quit IRC | 04:17 | |
| *** yuanying has quit IRC | 04:17 | |
| *** nosnos has joined #openstack-ironic | 04:19 | |
| *** chenglch|2 has joined #openstack-ironic | 04:20 | |
| *** chenglch has quit IRC | 04:23 | |
| *** rameshg87 has joined #openstack-ironic | 04:23 | |
| openstackgerrit | Shivanand Tendulker proposed openstack/ironic-specs: Ironic Management Interfaces to support UEFI Secure Boot https://review.openstack.org/135845 | 04:27 |
| *** lazy_prince is now known as killer_prince | 04:39 | |
| openstackgerrit | Nisha Agarwal proposed openstack/ironic-specs: Discover node properties using new CLI node-introspect https://review.openstack.org/100951 | 04:41 |
| *** achanda has quit IRC | 04:43 | |
| openstackgerrit | Nisha Agarwal proposed openstack/ironic-specs: Discover node properties for iLO drivers https://review.openstack.org/103007 | 04:43 |
| *** achanda has joined #openstack-ironic | 04:43 | |
| *** achanda has quit IRC | 04:46 | |
| *** achanda_ has joined #openstack-ironic | 04:46 | |
| *** ryanpetrello has quit IRC | 04:47 | |
| zer0c00l | Haomeng|2: Hi, i see your comments on the test case https://review.openstack.org/132137 | 05:04 |
| *** Kamilion has quit IRC | 05:04 | |
| Haomeng|2 | zer0c00l: hi, let me check again | 05:04 |
| zer0c00l | i guess you want me to write testcase for an invalid uuid | 05:04 |
| zer0c00l | or may be am i asking the wrong person? :) | 05:05 |
| Haomeng|2 | zer0c00l: yes, it is better that we have more cases to cover the new option | 05:05 |
| Haomeng|2 | zer0c00l: such as we input a invalid format uuid, what is the expect result | 05:06 |
| Haomeng|2 | zer0c00l: and for the result verification, that is option I think, depends on you:) | 05:06 |
| *** pensu has joined #openstack-ironic | 05:06 | |
| *** Marga_ has joined #openstack-ironic | 05:07 | |
| zer0c00l | Also what is the second test case? | 05:07 |
| zer0c00l | i don't understand the point number 2 | 05:08 |
| Haomeng|2 | zer0c00l: 2nd one is - can we verify the result to see if the created node uuid is the same with the input arguments - if this is diffcult to test, we can ignore this comments | 05:08 |
| Haomeng|2 | zer0c00l: so you can go ahead to add the 1st case | 05:09 |
| *** killer_prince is now known as lazy_prince | 05:09 | |
| zer0c00l | How do i test the firstcase. The code doesn't validate the uuid | 05:10 |
| zer0c00l | may be i need to add that validation stuff? | 05:10 |
| Haomeng|2 | zer0c00l: let me check the api | 05:10 |
| zer0c00l | Basically anyone can send anything in --uuid | 05:10 |
| Haomeng|2 | zer0c00l: ok, if our api does not support the uuid validation, that should not be your coverige | 05:12 |
| zer0c00l | i am checking the ironic API | 05:12 |
| Haomeng|2 | zer0c00l: and another point, can we add test case to create node with existing uuid? | 05:12 |
| Haomeng|2 | zer0c00l: me too | 05:12 |
| Haomeng|2 | zer0c00l: we have such code to vaoid uuid to get an instance - https://github.com/openstack/ironic/blob/b2121442204f5148c96a2016dc9f2721b48c1fcc/ironic/db/sqlalchemy/api.py#L290 | 05:14 |
| *** alexiz has quit IRC | 05:15 | |
| Haomeng|2 | zer0c00l: but for node_create call, looks like we have no such validation - https://github.com/openstack/ironic/blob/b2121442204f5148c96a2016dc9f2721b48c1fcc/ironic/db/sqlalchemy/api.py#L253 | 05:15 |
| Haomeng|2 | zer0c00l: so can we add the validation for input uuid, how do you think? | 05:16 |
| zer0c00l | yes we can do that | 05:17 |
| zer0c00l | is there a way to validate uuid? | 05:17 |
| zer0c00l | on the client side? | 05:17 |
| zer0c00l | uuid.UUID | 05:22 |
| zer0c00l | is_uuid_like | 05:22 |
| *** achanda_ has quit IRC | 05:23 | |
| zer0c00l | from ironic/openstack/common/uuidutils.py | 05:23 |
| *** lazy_prince is now known as killer_prince | 05:29 | |
| *** Marga_ has quit IRC | 05:31 | |
| *** Marga_ has joined #openstack-ironic | 05:31 | |
| *** pcrews has quit IRC | 05:37 | |
| *** pcrews has joined #openstack-ironic | 05:45 | |
| *** achanda has joined #openstack-ironic | 05:51 | |
| Haomeng|2 | zer0c00l: let me check client code | 05:52 |
| *** Masahiro has quit IRC | 05:52 | |
| Haomeng|2 | zer0c00l: yes | 05:53 |
| *** Masahiro has joined #openstack-ironic | 05:53 | |
| mrda | thanks zer0c00l - I didn't know about that func | 05:53 |
| Haomeng|2 | zer0c00l: it is better that we valid the uuid format in api side | 05:54 |
| *** killer_prince is now known as lazy_prince | 05:55 | |
| Haomeng|2 | zer0c00l: so, client will not have such logic, all the logic in api side | 05:55 |
| *** achanda has quit IRC | 05:55 | |
| Haomeng|2 | zer0c00l: and for api change, maybe we need another patch | 05:55 |
| zer0c00l | ok | 05:57 |
| openstackgerrit | Naohiro Tamura proposed openstack/python-ironicclient: Removed "py26" from tox.ini in python-ironicclient https://review.openstack.org/138634 | 05:57 |
| Haomeng|2 | zer0c00l: so dont worry, that is just my comments:) | 05:57 |
| Haomeng|2 | zer0c00l: and you can wait more comments, and commit new patch to cover more comments | 05:57 |
| *** Marga_ has quit IRC | 06:02 | |
| zer0c00l | sure | 06:03 |
| Haomeng|2 | zer0c00l: and another option is that we just verify uuid format from client side, for example - https://github.com/openstack/python-ironicclient/blob/0a6ec955c096fa19371b08f47716bb494a78ac5c/ironicclient/openstack/common/cliutils.py#L253 | 06:03 |
| *** Kamilion has joined #openstack-ironic | 06:05 | |
| *** ParsectiX has quit IRC | 06:08 | |
| *** Marga_ has joined #openstack-ironic | 06:08 | |
| *** Masahiro has quit IRC | 06:09 | |
| *** Masahiro has joined #openstack-ironic | 06:10 | |
| *** Nisha has quit IRC | 06:14 | |
| *** k4n0 has joined #openstack-ironic | 06:20 | |
| *** Marga_ has quit IRC | 06:31 | |
| *** nosnos has quit IRC | 06:38 | |
| *** mrda is now known as mrda-away | 06:40 | |
| *** nosnos has joined #openstack-ironic | 06:40 | |
| *** pcrews has quit IRC | 06:42 | |
| *** pcrews has joined #openstack-ironic | 06:43 | |
| openstackgerrit | jiangfei proposed openstack/ironic-python-agent: add deprecated_name to the config variables https://review.openstack.org/131632 | 06:57 |
| *** Nisha has joined #openstack-ironic | 07:10 | |
| *** yuriyz has quit IRC | 07:16 | |
| *** yuriyz has joined #openstack-ironic | 07:16 | |
| *** pcrews has quit IRC | 07:20 | |
| openstackgerrit | Tan Lin proposed openstack/ironic: Add AMT support with Ironic https://review.openstack.org/135184 | 07:25 |
| *** Masahiro has quit IRC | 07:27 | |
| *** Masahiro has joined #openstack-ironic | 07:31 | |
| openstackgerrit | Tan Lin proposed openstack/ironic: Add AMT support with Ironic https://review.openstack.org/135184 | 07:45 |
| *** jerryz has joined #openstack-ironic | 07:49 | |
| *** openstackgerrit has quit IRC | 07:50 | |
| *** openstackgerrit has joined #openstack-ironic | 07:50 | |
| *** Masahiro has quit IRC | 07:59 | |
| *** Masahiro has joined #openstack-ironic | 08:02 | |
| *** Nisha has quit IRC | 08:10 | |
| *** smoriya has quit IRC | 08:33 | |
| *** jcoufal has joined #openstack-ironic | 08:38 | |
| *** Nisha has joined #openstack-ironic | 08:53 | |
| *** tatyana has joined #openstack-ironic | 09:01 | |
| *** andreykurilin_ has joined #openstack-ironic | 09:06 | |
| *** romcheg has joined #openstack-ironic | 09:28 | |
| *** lucasagomes has joined #openstack-ironic | 09:29 | |
| *** dlpartain has joined #openstack-ironic | 09:30 | |
| *** ndipanov_gone has quit IRC | 09:32 | |
| *** jcoufal has quit IRC | 09:40 | |
| lucasagomes | jroll, devananda sorry catching up with (some of) the backlog from yesterday now | 09:48 |
| *** ndipanov has joined #openstack-ironic | 09:48 | |
| lucasagomes | jroll, I think that a machine that doesn't conform failing at deploy time is not the worst scenario case, it's the best scenario. If something changes - due memory/disk hot spare, or even BIOS tweaks like disabling CPU-cores - while it's sitting on AVAILABLE for a X number of time (could be months) and the machine gets deployed successfully, that's the worst case scenario | 09:49 |
| lucasagomes | jroll, because now ur client asked for X,Y,Z and you gave him X,Y,A and that is hard to debug, you're basically giving someone a different thing than he asked and/or is paying for | 09:50 |
| *** athomas has joined #openstack-ironic | 09:54 | |
| *** lazy_prince has quit IRC | 09:57 | |
| *** enterprisedc has quit IRC | 10:07 | |
| *** enterprisedc has joined #openstack-ironic | 10:07 | |
| rameshg87 | lucasagomes, hi | 10:10 |
| lucasagomes | rameshg87, hi | 10:10 |
| rameshg87 | lucasagomes, i have a question - do we ask operator to enroll all the nics of a bare metal into ironic ? | 10:11 |
| *** killer_prince has joined #openstack-ironic | 10:11 | |
| *** killer_prince is now known as lazy_prince | 10:11 | |
| lucasagomes | rameshg87, usually yes, because ironic will create a PXE config for all them. Unless you have control about which one exactly will boot so it won't fail with a "Couldn't find a valid PXE config"-thing | 10:12 |
| lucasagomes | rameshg87, dtantsur|afk have seem a problem with multiple nics tho | 10:12 |
| *** alexpilotti has joined #openstack-ironic | 10:12 | |
| rameshg87 | lucasagomes, if i have 4 nics on my bare metal and i enroll all of them | 10:13 |
| rameshg87 | lucasagomes, and from nova i request connectivity to 2 networks | 10:13 |
| *** andreykurilin_ has quit IRC | 10:14 | |
| rameshg87 | lucasagomes, oh okay | 10:14 |
| rameshg87 | lucasagomes, i see there is a check | 10:14 |
| lucasagomes | right :) | 10:15 |
| rameshg87 | lucasagomes, so if there are 4 nics and i select connectivity to 4 networks in nova | 10:16 |
| rameshg87 | lucasagomes, then selects 4 ports of ironic, creates neutron ports in 4 networks. it can't be 4 flat networks right ? | 10:17 |
| Nisha | rameshg87, the NICs must be pxe enabled for ironic to choose it for deploy | 10:18 |
| lucasagomes | rameshg87, not complete sure. Is this part of the virtual media without DHCPing spec work? | 10:19 |
| Nisha | by default only only one NIC is pxe enabled | 10:19 |
| rameshg87 | lucasagomes, yes. | 10:19 |
| rameshg87 | Nisha, yes, but i was just wondering how the mapping would work. | 10:19 |
| Nisha | rameshg87, all are connected to public network? | 10:20 |
| Nisha | or all connected to private network | 10:20 |
| Nisha | ? | 10:20 |
| Nisha | or its mix? | 10:20 |
| rameshg87 | lucasagomes, Nisha, if i have NIC1, NIC2, NIC3, NIC4 physically connected to flat networks NET1, NET2, NET3, NET4 respectively, then it wouldn't work right ? | 10:21 |
| *** sambetts has joined #openstack-ironic | 10:21 | |
| Nisha | rameshg87, are all NICs connected to same kind of network?\ | 10:22 |
| Nisha | i.e. public or private? | 10:22 |
| rameshg87 | lucasagomes, Nisha, so i guess it would be managed by neutron to provide connectivity for the respective NICs | 10:22 |
| rameshg87 | Nisha, they are 4 separate networks | 10:22 |
| rameshg87 | lucasagomes, my question was if i have 4 ports enrolled into Ironic | 10:22 |
| rameshg87 | lucasagomes, and i use virtual media driver | 10:23 |
| *** naohirot has quit IRC | 10:25 | |
| rameshg87 | lucasagomes, i have it like this | 10:26 |
| rameshg87 | lucasagomes, https://github.com/openstack/ironic/blob/master/ironic/drivers/modules/ilo/deploy.py#L158-L167 | 10:26 |
| lucasagomes | rameshg87, right, only one port will have a VIF? | 10:27 |
| * lucasagomes checks | 10:27 | |
| *** pelix has joined #openstack-ironic | 10:27 | |
| lucasagomes | I don't have an answer, I gotta investigate a bit | 10:27 |
| rameshg87 | lucasagomes, yeah but we have VIF for all the ports in Ironic | 10:27 |
| *** chenglch|2 has quit IRC | 10:27 | |
| lucasagomes | oh | 10:28 |
| rameshg87 | lucasagomes, i smell something wrong here. | 10:28 |
| lucasagomes | +1 | 10:28 |
| rameshg87 | lucasagomes, i think we should pass the IP details of all the ports to the booted ramdisk and then let it assign the IP to all the interfaces | 10:28 |
| rameshg87 | lucasagomes, just like a config drive will do | 10:28 |
| lucasagomes | https://github.com/openstack/nova/blob/master/nova/virt/ironic/driver.py#L898-L905 | 10:29 |
| lucasagomes | yeah seems all ports will have a vif indeed | 10:29 |
| *** Masahiro has quit IRC | 10:29 | |
| rameshg87 | lucasagomes, yes. so all the ports will have a IP assigned in neutron | 10:29 |
| rameshg87 | lucasagomes, so if we are going to avoid dhcp and statically assign IPs, we should rather pass network details for all the MAC addresses to the ramdisk | 10:30 |
| rameshg87 | lucasagomes, so that it has connectivity to all the networks - one of them might be the actual provisioning network | 10:30 |
| lucasagomes | yeah :/ | 10:32 |
| *** Nisha has quit IRC | 10:32 | |
| lucasagomes | idk how the ip= BOOTIF thing will work for that | 10:32 |
| lucasagomes | does you can specify which mac each address will go to? | 10:33 |
| rameshg87 | lucasagomes, yeah it might be problem, because there are multiple details to pass on | 10:33 |
| rameshg87 | lucasagomes, let me just think over | 10:34 |
| rameshg87 | lucasagomes, the problem was that we have only 1 network connected in our bare metals that we use for testing :) | 10:34 |
| rameshg87 | lucasagomes, will keep the dhcp spec on hold for now until i figure out this | 10:35 |
| *** jistr has joined #openstack-ironic | 10:37 | |
| lucasagomes | ack | 10:37 |
| lucasagomes | thanks for looking into it | 10:37 |
| *** jistr is now known as jistr|trng | 10:38 | |
| *** athomas has quit IRC | 10:41 | |
| *** jcoufal has joined #openstack-ironic | 10:42 | |
| *** kurtrao has quit IRC | 10:46 | |
| *** derekh has joined #openstack-ironic | 10:50 | |
| *** ramineni has quit IRC | 10:50 | |
| *** rameshg87 has quit IRC | 10:59 | |
| *** athomas has joined #openstack-ironic | 11:06 | |
| *** Marga_ has joined #openstack-ironic | 11:20 | |
| *** k4n0 has quit IRC | 11:23 | |
| *** Masahiro has joined #openstack-ironic | 11:30 | |
| *** Masahiro has quit IRC | 11:34 | |
| *** pensu has quit IRC | 11:41 | |
| *** kurtrao has joined #openstack-ironic | 11:43 | |
| kurtrao | I've met this problem in creating disk image using disk-image-builder. It reports: /hooks/root.d/99-shared_apt_cache: line 12: DISTRO_NAME: unbound variable | 11:45 |
| kurtrao | can anyone please help? | 11:45 |
| kurtrao | i was following the install-guide.html from openstack official site | 11:46 |
| *** Haomeng has joined #openstack-ironic | 11:47 | |
| *** Haomeng|2 has quit IRC | 11:47 | |
| lucasagomes | kurtrao, hi there, diskimage-builder is a tool from TripleO | 11:50 |
| lucasagomes | kurtrao, I think that people on #tripleo can help you better with it | 11:50 |
| kurtrao | ok. thanks a lot~ Will it possiblly be a problem of the document? I've seen some bugs before like mis-use of "service" and "services" as tenant name. So, just to confirm. That's ok. I'll check with #tripleo | 11:51 |
| *** tatyana has left #openstack-ironic | 11:52 | |
| *** dlpartain has quit IRC | 11:59 | |
| *** romcheg has quit IRC | 12:05 | |
| *** romcheg has joined #openstack-ironic | 12:12 | |
| *** pensu has joined #openstack-ironic | 12:16 | |
| *** jistr|trng has quit IRC | 12:28 | |
| *** jistr has joined #openstack-ironic | 12:34 | |
| *** jistr is now known as jistr|trng | 12:35 | |
| *** Marga_ has quit IRC | 12:41 | |
| *** lucasagomes is now known as lucas-hungry | 12:41 | |
| *** rameshg87 has joined #openstack-ironic | 12:53 | |
| *** MattMan has joined #openstack-ironic | 12:57 | |
| *** pensu has quit IRC | 12:59 | |
| *** tatyana has joined #openstack-ironic | 13:01 | |
| *** naohirot has joined #openstack-ironic | 13:02 | |
| *** ryanpetrello has joined #openstack-ironic | 13:07 | |
| *** Masahiro has joined #openstack-ironic | 13:08 | |
| *** dprince has joined #openstack-ironic | 13:09 | |
| *** rushiagr is now known as rushiagr_away | 13:10 | |
| *** Masahiro has quit IRC | 13:13 | |
| *** rameshg87 has quit IRC | 13:20 | |
| *** ryanpetrello has quit IRC | 13:37 | |
| *** jjohnson2 has joined #openstack-ironic | 13:38 | |
| *** ryanpetrello has joined #openstack-ironic | 13:46 | |
| *** lucas-hungry is now known as lucasagomes | 13:49 | |
| *** ryanpetrello has quit IRC | 13:50 | |
| *** jcoufal has quit IRC | 13:55 | |
| *** jcoufal has joined #openstack-ironic | 13:56 | |
| openstackgerrit | Lucas Alvares Gomes proposed openstack/ironic-specs: Root device hints https://review.openstack.org/138729 | 14:01 |
| *** dlaube has joined #openstack-ironic | 14:01 | |
| openstackgerrit | Lucas Alvares Gomes proposed openstack/ironic-specs: Root device hints https://review.openstack.org/138729 | 14:02 |
| *** dlaube has quit IRC | 14:03 | |
| *** rushiagr_away is now known as rushiagr | 14:05 | |
| *** rloo has joined #openstack-ironic | 14:08 | |
| *** mjturek has joined #openstack-ironic | 14:08 | |
| *** lazy_prince is now known as killer_prince | 14:10 | |
| victor_lowther | Good morning party people. | 14:10 |
| *** dlaube has joined #openstack-ironic | 14:19 | |
| *** erwan_taf has joined #openstack-ironic | 14:21 | |
| lucasagomes | victor_lowther, yo morning | 14:26 |
| erwan_taf | heya world | 14:26 |
| lucasagomes | erwan_taf, howdy | 14:26 |
| erwan_taf | hey lucasagomes | 14:28 |
| *** dlaube has quit IRC | 14:28 | |
| * rloo is too busy partying to say good morning to victor_lowther. What, is it morning already? :-) | 14:28 | |
| *** nosnos has quit IRC | 14:28 | |
| victor_lowther | well, it is in Texas. | 14:28 |
| lucasagomes | rloo, morning :) | 14:29 |
| * victor_lowther runs off for coffee, email, and spec reviews | 14:29 | |
| rloo | afternoon lucasagomes! | 14:29 |
| *** dlaube has joined #openstack-ironic | 14:33 | |
| *** rameshg87 has joined #openstack-ironic | 14:35 | |
| *** rameshg87 has quit IRC | 14:36 | |
| *** rameshg87 has joined #openstack-ironic | 14:37 | |
| *** jogo has joined #openstack-ironic | 14:40 | |
| jogo | https://bugs.launchpad.net/nova/+bug/1379373 | 14:41 |
| jogo | wondering if nova still needs nova/api/openstack/compute/contrib/baremetal_nodes.py | 14:41 |
| rloo | jogo: ohhh. that was there to help 'migrate' BM users to ironic. but BM was deleted from nova. so do we still want to support those BM APIs... | 14:43 |
| rloo | jogo: I think we need to discuss with devananda and/or is there a policy wrt how long to support something before it is deprecated? | 14:47 |
| jogo | rloo: right, but kilo nova doesn't support nova-baremetal | 14:49 |
| jogo | rloo: yeah not sure what the right policy answer is here | 14:49 |
| rameshg87 | NobodyCam, hi | 14:50 |
| rloo | jogo: I know. So I'm fine if we don't support/proxy the nova BM apis too. But... user experience blah blah... There are only two: baremetal-node-list and baremetal-node-show. | 14:50 |
| rloo | jogo: and I think we only proxy'd them cuz someone (outside of ironic) asked for it. maybe as part of graduation... | 14:51 |
| jogo | rloo: yeah, I am interested in hearing what devananda has to say | 14:52 |
| rloo | jogo: me too ;) | 14:52 |
| *** Masahiro has joined #openstack-ironic | 14:57 | |
| *** krtaylor has quit IRC | 14:57 | |
| *** pcrews has joined #openstack-ironic | 14:57 | |
| dlaube | g'morning guys | 15:02 |
| *** Masahiro has quit IRC | 15:02 | |
| dlaube | anyone know how ironic or nova sets up the magic IP "169.254.169.254" for the metadata service? | 15:05 |
| dlaube | is there a request that get sent to neutron in order to create some routes or something? | 15:06 |
| PaulCzar | hey folks, i'm way further along with the pxe_ssh driver | 15:17 |
| PaulCzar | am getting errors regarding setting ports to DHCP | 15:17 |
| PaulCzar | https://gist.github.com/paulczar/10f421479ac264368f7c | 15:17 |
| PaulCzar | the interesting error is at the bottom | 15:17 |
| *** r-daneel has joined #openstack-ironic | 15:21 | |
| *** jerryz has quit IRC | 15:21 | |
| *** Nisha has joined #openstack-ironic | 15:24 | |
| NobodyCam | morning Ironic.. says the man running late :-p | 15:25 |
| NobodyCam | hi rameshg87 :) | 15:26 |
| *** rameshg87 has quit IRC | 15:28 | |
| NobodyCam | PaulCzar: neutron run and running? | 15:29 |
| *** killer_prince has quit IRC | 15:29 | |
| jroll | huh | 15:35 |
| jroll | /var/log/nova/nova-compute.log:2014-12-03 15:07:09.135 8182 DEBUG nova.virt.ironic.driver [-] unplug: instance_uuid=25cb63eb-4b08-4925-b0ea-e810c2e2849e vif=[VIF({'profile': {}, 'ovs_interfaceid': None, 'network': Network({'bridge': u'brq38e82ca6-74', 'subnets': [Subnet({'ips': [FixedIP({'meta': {}, 'version': 4, 'type': 'fixed', 'floating_ips': [], 'address': u'172.16.255.6'})], 'version': 4, | 15:35 |
| jroll | 'meta': {'dhcp_server': u'172.16.255.3'}, 'dns': [], 'routes': [], 'cidr': u'172.16.255.0/24', 'gateway': IP({'meta': {}, 'version': 4, 'type': 'gateway', 'address': u'172.16.255.1'})})], 'meta': {'injected': False, 'tenant_id': u'78246742e14049fc81be918cba080e87', 'should_create_bridge': True}, 'id': u'38e82ca6-7475-4022-a824-85bf1faa89d8', 'label': u'internal'}), 'devname': u'tap5b4f39c1-95', | 15:35 |
| jroll | 'vnic_type': u'normal', 'qbh_params': None, 'meta': {}, 'details': {u'port_filter': True}, 'address': u'08:00:27:a0:3a:50', 'active': False, 'type': u'bridge', 'id': u'5b4f39c1-955a-45d5-b861-02f192898eea', 'qbg_params': None})] _unplug_vifs /usr/local/lib/python2.7/dist-packages/nova/virt/ironic/driver.py:934 | 15:35 |
| jroll | whoa, my bad | 15:35 |
| jroll | didn't realize that was so long | 15:35 |
| NobodyCam | wow its eraly for that | 15:35 |
| NobodyCam | lol | 15:35 |
| jroll | lol | 15:35 |
| jroll | I call that making an entrance | 15:35 |
| NobodyCam | morning jroll | 15:35 |
| jroll | morning :) | 15:36 |
| dlaube | g'morning | 15:36 |
| jroll | PaulCzar: so it looks like nova deleted the port from neutron just before ironic tried to use it | 15:36 |
| NobodyCam | morning dlaube | 15:36 |
| jroll | err, actually, unplugged it from ironic | 15:37 |
| jroll | strange | 15:37 |
| Shrews | :) | 15:37 |
| NobodyCam | morning Shrews | 15:37 |
| Shrews | morning NobodyCam | 15:38 |
| *** krtaylor has joined #openstack-ironic | 15:38 | |
| jroll | hey Shrews and dlaube | 15:39 |
| Shrews | hiya jrollyroll | 15:39 |
| jroll | dlaube: btw, there's fancy network things going on there, someone had figured it out but I forget who (sorry, I don't use metadata service, unfortunately) | 15:39 |
| *** zz_jgrimm is now known as jgrimm | 15:39 | |
| lucasagomes | NobodyCam, jroll Shrews dlaube morning | 15:40 |
| NobodyCam | morning lucasagomes :) | 15:40 |
| jroll | \o lucasagomes | 15:40 |
| Shrews | hi lucasagomes | 15:40 |
| dlaube | jroll: ahh ok… darn | 15:40 |
| lucasagomes | jroll, re boot() vs deploy() interface :( I don't think I will have much time to work on that | 15:42 |
| PaulCzar | jroll: that's what I'm thinking ... I can't see why though | 15:42 |
| lucasagomes | I've been assigned to some other priorities | 15:42 |
| *** jmank has joined #openstack-ironic | 15:43 | |
| jroll | lucasagomes: priorities are hard :( | 15:43 |
| lucasagomes | aye | 15:43 |
| jroll | lucasagomes: it might take me a little bit of time, but maybe I could take that on and trade you the iscsi driver configdrive stuff? :) | 15:43 |
| lucasagomes | jroll, that sounds good to me | 15:43 |
| lucasagomes | cause that is one of my priorities :) | 15:44 |
| jroll | PaulCzar: right, either that or maybe the port wasn't successfully created, take a look at neutron logs? | 15:44 |
| jroll | exactly :) | 15:44 |
| jroll | and it sounds painful :P | 15:44 |
| lucasagomes | does it? :( | 15:44 |
| PaulCzar | jroll: nova's error for the instance shows : no valid host, 3 attempts made | 15:44 |
| lucasagomes | you mean creating the partition and dealing with the rebuild stuff? I probably will need to pick urs and devananda brains a bit to catch up with u guys about the problems | 15:45 |
| jroll | lucasagomes: yeah, mostly just that I'm scared of that partitioning code :P | 15:45 |
| lucasagomes | cool, fair trade :) | 15:46 |
| jroll | PaulCzar: right, it will try to reschedule to another node if the deploy fails | 15:46 |
| NobodyCam | PaulCzar: three attempts are you running the RetryFilter ? | 15:46 |
| jroll | (I'm also scared of refactoring our interfaces) :P | 15:46 |
| NobodyCam | jroll: is that a new default | 15:46 |
| NobodyCam | I don't recall it being like that | 15:47 |
| lucasagomes | heh yeah, the main problem with boot() and deploy() is actually to abstract, in a generic way, means for the deploy() interface to pass information for the boot interface | 15:47 |
| jroll | NobodyCam: dunno, I think it's been that way for a while | 15:47 |
| lucasagomes | things like the ipa url that is part of the pxe template | 15:47 |
| NobodyCam | :-p | 15:47 |
| lucasagomes | or the iscsi_iqn | 15:47 |
| lucasagomes | once that's kinda sorted I believe it will be easier | 15:47 |
| PaulCzar | jroll: Bound port: fbcef375-dd45-47ea-b279-04f5bc18be9b, host: allinone, vnic_type: normal, profile: , driver: linuxbridge, vif_type: bridge, v | 15:48 |
| PaulCzar | if_details: {"port_filter": true} | 15:48 |
| jroll | hrm | 15:48 |
| jroll | lucasagomes: yeah, I'm thinking just... driver.deploy.get_deploy_config(), we'll need to normalize some things etc | 15:49 |
| lucasagomes | yeah, something like that | 15:49 |
| lucasagomes | we use Jinja2 templates for the configs so it may be a question of adding a deploy_information field | 15:50 |
| *** sambetts has quit IRC | 15:50 | |
| lucasagomes | wihch defaults to "" (empty string) | 15:50 |
| jroll | right | 15:50 |
| jroll | OTOH | 15:50 |
| jroll | IPA will ignore iscsi_iqn, iscsi ramdisk will ignore ipa-api-url | 15:51 |
| jroll | maybe just pass everything :P | 15:51 |
| lucasagomes | heh, one thing is | 15:51 |
| lucasagomes | the deploy() interface will probably have control over the boot() interface | 15:51 |
| PaulCzar | jroll: neutron logs .. just grepping for the port ID - http://pastebin.com/KUDgRLcg | 15:51 |
| lucasagomes | so you can give it the right parameters depending on the deploy() but generic enough on the boot() | 15:51 |
| PaulCzar | so it looks like it does a lookup for the port and can't see it for some reason so just goes ahead and deletes it | 15:52 |
| jroll | PaulCzar: yeah... also I see PUT /v2.0/ports/fbcef375-dd45-47ea-b279-04f5bc18be9b.json HTTP/1.1" 404 | 15:53 |
| jroll | *before* it's deleted | 15:53 |
| lucasagomes | [off-topic] if anyone has some time, please take a look at https://review.openstack.org/#/c/138729/ | 15:54 |
| openstackgerrit | Lucas Alvares Gomes proposed openstack/ironic-specs: Root device hints https://review.openstack.org/138729 | 15:54 |
| PaulCzar | jroll: hmmm, is it an auth/tenant thing ? I think I'm running nova as the admin user / admin tenant ... just remember ironic has a user hard coded into ironic.conf | 15:59 |
| PaulCzar | so maybe the port is getting created for admin, and then ironic can't see it | 15:59 |
| jroll | PaulCzar: ooo, maybe, though ironic's user should be an admin, no? | 15:59 |
| openstackgerrit | Merged openstack/ironic: Add documentation for SeaMicro driver https://review.openstack.org/136324 | 16:01 |
| *** naohirot has quit IRC | 16:01 | |
| PaulCzar | jroll: yeah, I set the ironic policy to allow the ironic service user to work | 16:01 |
| PaulCzar | but I'm switching the ironic.conf user to the same user as me | 16:01 |
| PaulCzar | see if that works | 16:01 |
| jroll | PaulCzar: hrm, to the same user as the user doing nova boot? | 16:05 |
| jroll | seems wrong | 16:05 |
| jroll | ironic's user needs to, at a minimum, be able to validate tokens with keystone | 16:05 |
| *** dlpartain has joined #openstack-ironic | 16:06 | |
| NobodyCam | lucasagomes: why model? | 16:08 |
| PaulCzar | jroll: just trying to think why ironic can't see the neutron port ... thought it might be because it's not in the same user or at least tenant as the user calling neutron | 16:08 |
| PaulCzar | (grasping at straws ) | 16:08 |
| lucasagomes | NobodyCam, that's the field I was wondering whether I should include or not heh but as it was part of the info I can find on sysfs I thought why not | 16:09 |
| openstackgerrit | Jim Rollenhagen proposed openstack/ironic-python-agent: Use _ instead of - for config options https://review.openstack.org/131632 | 16:09 |
| jroll | JayF: ^ that lgtm | 16:09 |
| lucasagomes | NobodyCam, tho I think I should remove it | 16:09 |
| jroll | PaulCzar: could be, yeah, I don't know much about neutron :/ | 16:09 |
| lucasagomes | NobodyCam, it's not like it's a unique identifier or something | 16:10 |
| jroll | lucasagomes: it could be unique | 16:10 |
| *** dlaube has quit IRC | 16:10 | |
| NobodyCam | yea, I'll add a comment | 16:10 |
| jroll | say I have two disks, one is model cheapo-ssd and one is giant-hdd | 16:10 |
| lucasagomes | jroll, :D yeah if you have only one of the disks on that model | 16:10 |
| jroll | right | 16:10 |
| NobodyCam | jroll: in /SOME/ cases | 16:10 |
| jroll | right | 16:10 |
| jroll | so it can be useful | 16:10 |
| lucasagomes | jroll, right, yeah | 16:10 |
| lucasagomes | I don't think it's totally invalid | 16:10 |
| jroll | instead of looking up serial numbers for each node | 16:10 |
| jroll | I can just spam every node with a model name | 16:11 |
| lucasagomes | hmm it does makes sense yea | 16:11 |
| NobodyCam | I'll add a comment please feel free to disagree | 16:11 |
| jroll | lucasagomes: I wonder if size would be another reasonable thing there | 16:11 |
| jroll | if you know your root disk is 32gb, tell it to look for the 32gb disk | 16:12 |
| lucasagomes | jroll, I was thinking about it, but I was trying to make it shorted | 16:12 |
| jroll | I would use that | 16:12 |
| lucasagomes | because I know u guys use on IPA | 16:12 |
| rloo | lucasagomes: just reading your comments wrt the state machine. there was some discussion in IRC about it yesterday that might help. | 16:12 |
| lucasagomes | jroll, for size we could add some operators | 16:12 |
| lucasagomes | like greater than etc | 16:12 |
| lucasagomes | rloo, right, I tried to catch up with some of the IRC conversation | 16:13 |
| jroll | lucasagomes: yeah, for this spec I would just do "exact" size | 16:13 |
| rloo | lucasagomes: wrt zap/clean. We wanted to distinguish them, so eg clean might be a subset of zap. You might want to do some things only once after enrolling the node, but other things (whatever-in-clean) always after deleting. | 16:13 |
| lucasagomes | rloo, but it's difficult if we don't summirize the decisions in gerrit | 16:13 |
| lucasagomes | jroll, right, mind adding a ocmment for it? I would glad add that | 16:13 |
| jroll | sure thing | 16:13 |
| rloo | lucasagomes: yup. i was thinking about that. (summarizing decisions etc). it is easy to forget to do that. | 16:14 |
| lucasagomes | rloo, right I mean, many things can be a subset of zapping idk why cleaning tasks are one exception | 16:14 |
| lucasagomes | rloo, because, the RAID example idk if it fits on CLEANING | 16:15 |
| lucasagomes | unless we say that cleaning is also building RAID | 16:15 |
| rloo | lucasagomes: i think to identify things that one ALWAYS wants to do after deleting, vs things that most likely only want to do once after enrolling. | 16:15 |
| rloo | lucasagomes: so maybe 'clean' is the wrong verb. | 16:16 |
| lucasagomes | right | 16:16 |
| rloo | lucasagomes: what happened to 'decommission'? | 16:16 |
| lucasagomes | yeah could be naming problem | 16:16 |
| jroll | decommission has too many meanings | 16:16 |
| rloo | lucasagomes: how about 'zappy' instead of 'clean' :-) | 16:16 |
| lucasagomes | I would think that normalising | 16:16 |
| lucasagomes | cause cleaning is called before the node is provisioned as well | 16:17 |
| jroll | eh? | 16:17 |
| jroll | isn't it just after delete? | 16:17 |
| jroll | and when triggered by operator | 16:17 |
| * lucasagomes rechecks the state machine | 16:17 | |
| lucasagomes | jroll, nop, it goes from MANAGED to CLEANING and the AVAILABLE | 16:17 |
| rloo | lucasagomes: so if you want to clean before the first time a node is provisioned, you add that/those tasks to the zap | 16:18 |
| lucasagomes | which is good, it makes sense | 16:18 |
| lucasagomes | we don't know if the machine is being recycled or not | 16:18 |
| *** romcheg has quit IRC | 16:18 | |
| jroll | lucasagomes: but from available, it only goes to managed and cleaning if the operator requests | 16:18 |
| jroll | but yeah, when you first bring it in it should be cleaned | 16:18 |
| *** Marga_ has joined #openstack-ironic | 16:19 | |
| jroll | sorry, I thought "before the node is provisioned" meant every time the node is provisioned :P | 16:19 |
| lucasagomes | rloo, but that's the thing. Imagine someone managing many nodes in Ironc with different drivers | 16:19 |
| lucasagomes | rloo, one driver ZAPPING only build arrays, the other it also cleans | 16:19 |
| lucasagomes | so he is used to put the node back in MANAGED and call ZAPPING | 16:19 |
| lucasagomes | one will complete erease all the data and the other not | 16:19 |
| lucasagomes | it's hard to manage | 16:19 |
| lucasagomes | jroll, oh no, like before it gets into the main loop :) as a first step (which makes sense) | 16:20 |
| jroll | lucasagomes: commented on the disk thing | 16:20 |
| jroll | yeah, ok :) | 16:20 |
| rloo | lucasagomes: I'm not sure I understand. Is your example after a deletion, or only after enrolling, or both? | 16:20 |
| lucasagomes | jroll, ta much | 16:20 |
| jroll | lucasagomes: to be clear, when we talked about separating CLEAN and ZAP, there will be actions that happen in both | 16:21 |
| jroll | like erase disks will happen in both | 16:21 |
| lucasagomes | rloo, after enrolling | 16:21 |
| rloo | maybe 'clean' -> 'mini-zap' | 16:21 |
| lucasagomes | jroll, right yeah | 16:22 |
| lucasagomes | jroll, the example I was using is that, before ereasing the disks, one may want to break the RAID | 16:22 |
| rloo | lucasagomes: after enrolling only? So driver1 only wants to ZAP, not CLEAN, and driver2 ZAP and CLEAN? | 16:22 |
| lucasagomes | and clean individual disks to not have to deal with the RAID abstraction | 16:22 |
| lucasagomes | and be confident that individual disks are ereased | 16:22 |
| jroll | right, hmm | 16:23 |
| lucasagomes | but then if the ZAPPING doesnt happen after clean, we can't rebuild the raid (unless clean does it) | 16:23 |
| rloo | lucasagomes: so driver1 codes the 'clean' so that it doesn't clean if it came from 'managed' state, and driver2 is happy as-is. | 16:23 |
| jroll | lucasagomes: well | 16:23 |
| lucasagomes | rloo, after entolling is not a one-way pass | 16:23 |
| jroll | for a raid | 16:23 |
| lucasagomes | rloo, you can put it back to MANAGED | 16:23 |
| lucasagomes | and call zap again | 16:23 |
| jroll | the individual disks will still show as sda/sdb/etc, won't they? | 16:23 |
| jroll | at least for software raid, idk about hw raid | 16:24 |
| openstackgerrit | Sirushti Murugesan proposed openstack/ironic-specs: Whole Disk Image Support https://review.openstack.org/97150 | 16:24 |
| lucasagomes | jroll, in raid I believe it's shown as a individual device | 16:24 |
| rloo | lucasagomes: sorry, when I said 'after enrolling' (and not after deleting), I meant it as a one-way/one-time. Exceptions are with avail->manage. | 16:24 |
| lucasagomes | erwan_taf does it to clean his disks | 16:24 |
| jroll | lucasagomes: software raid will have /dev/sda, /dev/sdb, and the raid is at /dev/md0 | 16:24 |
| jroll | for example | 16:24 |
| lucasagomes | jroll, right, I can take a look at it see if we could clean individual devices without touching RAID | 16:26 |
| jroll | lucasagomes: cool, hardware raid is the only one I'm worried about | 16:26 |
| lucasagomes | yup | 16:27 |
| * lucasagomes investigate | 16:27 | |
| jroll | thanks | 16:28 |
| *** dlpartain has quit IRC | 16:28 | |
| erwan_taf | back | 16:30 |
| erwan_taf | If you want to clean disks for security issues, you have to delete all your raid arrays, create JBOD-like config and clean each individual disk by itself | 16:31 |
| *** dlaube has joined #openstack-ironic | 16:31 | |
| erwan_taf | this is the way to insure all your disks doesn't have any user data on it | 16:31 |
| erwan_taf | I mean, physical disks | 16:32 |
| erwan_taf | i.e a 6 physical disk setup will be turn in 6 individual raid volume of 1 disk | 16:33 |
| victor_lowther | erwan_taf: Several RAID controllers I work with do not allow direct access to disks | 16:33 |
| erwan_taf | then I can address the cleaning of every single phys disk | 16:33 |
| jroll | erwan_taf: for software raid, hardware raid, or both? | 16:33 |
| erwan_taf | victor_lowther: by creating a raid 0 of 1 disk you can | 16:33 |
| victor_lowther | so you cannot clean the ehtire physical disk no matter what you do | 16:33 |
| victor_lowther | without attaching it to something else | 16:33 |
| erwan_taf | jroll: software is easy to handle, just process all the /dev/sd* something | 16:33 |
| victor_lowther | no | 16:33 |
| jroll | erwan_taf: right, thought so | 16:34 |
| victor_lowther | a single-disk RAID 0 still has the raid metadata + other controller specific stuff that you cannot touch from userspace. | 16:34 |
| erwan_taf | on the hardware raid, I do use inbound cleaning | 16:34 |
| erwan_taf | victor_lowther: sure but we are considering the addressable space | 16:34 |
| erwan_taf | this is where the data we are interested in is located isn't it ? | 16:35 |
| victor_lowther | thren in that case you don't have to disassemble the raid to clean it. | 16:35 |
| erwan_taf | then I do clean the raid I created | 16:35 |
| victor_lowther | just spam it with zeros | 16:35 |
| erwan_taf | I don't know the server, and I don't what was the usage of that server before | 16:35 |
| erwan_taf | maybe yes a raid array exists but some uses other disks to another usage | 16:35 |
| jroll | if you overwrite every existing block device with zeroes, I would think that would be enough | 16:36 |
| erwan_taf | as I can't predict what disks were used before, considering cleaning everything and gain access to every phys disk is the sole way I know to insure all disks are cleaned | 16:36 |
| jroll | but this is not my expertise | 16:36 |
| erwan_taf | jrist: depends on your expections of cleaning | 16:36 |
| erwan_taf | jroll: sorry ^ | 16:36 |
| jroll | my expectations are that the second tenant cannot access the first tenant's data | 16:37 |
| erwan_taf | If you expect Dod 5220-22.M, that's a little bit more complicated ;) | 16:37 |
| jrist | :) | 16:37 |
| victor_lowther | or only byt RAID controllers that allow for secure erase commands to be passed through. :) | 16:37 |
| victor_lowther | Good luck with that. | 16:37 |
| erwan_taf | I'm usually don't expect raid controllers to be cooperative | 16:37 |
| jroll | jrist: I'm going to buy you a beer one day for all these false highlights | 16:37 |
| jroll | :) | 16:38 |
| erwan_taf | that makes me much more resilient to various setups | 16:38 |
| jrist | jrist: sounds good | 16:38 |
| jrist | but I'm allergic to beer and that will kill me | 16:38 |
| erwan_taf | \o/ | 16:38 |
| jrist | ;( | 16:38 |
| lucasagomes | jrist, ouch :( | 16:38 |
| erwan_taf | jrist did highliht himself to answer jroll | 16:38 |
| jroll | that was the best false highlight | 16:38 |
| erwan_taf | jrist: that's sad man | 16:38 |
| jrist | lol | 16:38 |
| jrist | I know erwan_taf . I know | 16:39 |
| jroll | jrist: the drink of your choice, then :P allergic to beer or gluten or? | 16:39 |
| jrist | didn't used to be allergic | 16:39 |
| jrist | dunno. went to an allergist for it even | 16:39 |
| jrist | he had no clue, lol | 16:39 |
| jroll | I guess gluten probably doesn't kill people | 16:39 |
| jroll | wow, weird | 16:39 |
| victor_lowther | I am also of the opinion that if your CLEANING is smart enough to tear down your RAID arrays for cleaning to your desired level of paranoia, making it smart enough to rebuild what it tore down is not too much to ask. | 16:39 |
| NobodyCam | oh man :( | 16:39 |
| erwan_taf | so the definition of how deep should be the cleaning is variable | 16:39 |
| lucasagomes | it's actually hard to read a conversation between jrist and jroll :D | 16:39 |
| jrist | lucasagomes: wow, I'm surprised you didn't say jrist and jrist | 16:39 |
| jroll | lmao | 16:40 |
| jrist | :) | 16:40 |
| victor_lowther | heh | 16:40 |
| lucasagomes | lol | 16:40 |
| erwan_taf | I suggest that clean explodes raids, clean disks if required, and let the raid unconfigured | 16:40 |
| erwan_taf | -ETOOMANY_JR | 16:40 |
| jrist | erwan_taf: :) | 16:40 |
| JayF | jroll: gluten isn't an "allergy" technically... it's an intolerance. IDK what the difference is but I used to :P | 16:40 |
| victor_lowther | that is silly if the default expectation is that a cleaned system is ready to be reassined the same sort of role it had. | 16:41 |
| victor_lowther | er, reassigned | 16:41 |
| erwan_taf | from my opinion, a clean system is a system ready to be configured to become something | 16:41 |
| erwan_taf | clean does clean | 16:41 |
| erwan_taf | prepare does prepare and expect it to be clean | 16:42 |
| victor_lowther | hm | 16:42 |
| victor_lowther | I have different expectations, then | 16:42 |
| jroll | yeah, clean should not build a raid imo | 16:42 |
| lucasagomes | I agree with that level of abstraction | 16:42 |
| victor_lowther | to me, a clean system has been sanitized | 16:42 |
| victor_lowther | configuration and role assignment happens elsewhere. | 16:42 |
| erwan_taf | does cleaning your car make it ready to travel ? | 16:43 |
| erwan_taf | that semantically wrong at my taste | 16:43 |
| victor_lowther | no, it gets rid of the dirt and bugs | 16:43 |
| victor_lowther | it doesn't change the design or config | 16:43 |
| jroll | victor_lowther: ++ I think y'all are on the same page | 16:43 |
| erwan_taf | so I missed where the raid level should be defined | 16:44 |
| victor_lowther | ZAP | 16:44 |
| victor_lowther | or defined in MANAGE and initially instantiated in ZAP | 16:44 |
| jroll | um | 16:44 |
| jroll | I'm not so sure about that | 16:45 |
| victor_lowther | scrubbed in CLEAN | 16:45 |
| jroll | at the summit, we talked about potentially doing long-running tasks in ZAP | 16:45 |
| jroll | short-running tasks can be done at deploy time | 16:45 |
| victor_lowther | yes | 16:45 |
| jroll | how long does configuring a hardware raid take? | 16:45 |
| JayF | hours | 16:45 |
| jroll | blah | 16:45 |
| JayF | if you're doing a full init | 16:45 |
| erwan_taf | does ZAP knows what the host will be used for and decide which raid level/disks to use ? | 16:45 |
| victor_lowther | which is why systems available to be deployted are in AVAILABLE, not MANAGED | 16:45 |
| jroll | erwan_taf: no, that's why zap can't do that IMO | 16:45 |
| jroll | or | 16:46 |
| jroll | idk | 16:46 |
| lucasagomes | hmm | 16:46 |
| *** Masahiro has joined #openstack-ironic | 16:46 | |
| jroll | maybe it can | 16:46 |
| victor_lowther | and CLEAN happens between MANAGED/DELETE and AVAILABLE | 16:46 |
| JayF | jroll: ZAP is operator initiated, and it does whatever the operator tells it to | 16:47 |
| JayF | jroll: so an operator could say "ZAP this node to RAID 10" and it would do it | 16:47 |
| jroll | ok, yeah, the machine in the spec looks fine to me | 16:47 |
| jroll | right | 16:47 |
| jroll | had to re-read | 16:47 |
| JayF | coolio | 16:47 |
| erwan_taf | that's still why I still consider that Zap is doing too much things. Deleting Raid Arrays & taking care of user data is one thing, preparing the server for a particular role is another | 16:47 |
| jroll | when you unprovision a node, it cleans up after previous tenant | 16:47 |
| erwan_taf | clean vs prepare | 16:47 |
| jroll | when you want to configure raid or whatever the heck, you do a zap | 16:48 |
| jroll | erwan_taf: we have split this between clean and zap already | 16:48 |
| jroll | zap ~= prepare | 16:48 |
| erwan_taf | but at this stage we don't know what this node will be used for | 16:48 |
| erwan_taf | which could define a particular hw config | 16:48 |
| jroll | huh? | 16:48 |
| *** Marga_ has quit IRC | 16:49 | |
| PaulCzar | jroll: I can run neutron port-update from the ironic user ... so it's not a permissions problem | 16:49 |
| victor_lowther | We decide what the node will be used for in MANAGED | 16:49 |
| jroll | the operator requests ironic to do a particular zap | 16:49 |
| victor_lowther | and set node.properties accordingly | 16:49 |
| erwan_taf | ok | 16:49 |
| jroll | right | 16:49 |
| victor_lowther | before making it AVAILABLE | 16:49 |
| jroll | and the flavor matches capabilities in node.properties | 16:49 |
| jroll | e.g. "raid10" | 16:49 |
| JayF | erwan_taf: the idea of ZAP doesn't make as much sense until it's combined with hardware capabilities (there's a backlog spec up) which allows you to schedule based on a server having given capabilities (like, say, having a RAID configured) | 16:49 |
| *** dlpartain has joined #openstack-ironic | 16:49 | |
| *** Masahiro has quit IRC | 16:50 | |
| erwan_taf | so clean should be done before zap | 16:51 |
| victor_lowther | no | 16:51 |
| jroll | yes. | 16:51 |
| erwan_taf | if zap does create the raid | 16:51 |
| jroll | and it is. | 16:51 |
| victor_lowther | because zap can change what the hardware looks like | 16:51 |
| erwan_taf | it have to be cleaned first | 16:51 |
| jroll | clean is done when the node is unprovisioned, or when the node is unrolled | 16:51 |
| victor_lowther | and clean should not. | 16:51 |
| jroll | enrolled | 16:51 |
| jroll | to get to MANAGED, you have to do CLEAN | 16:51 |
| jroll | to get to ZAP, you have to be in MANAGED | 16:51 |
| victor_lowther | no | 16:51 |
| jroll | yes | 16:51 |
| victor_lowther | to get to AVAILABLE, you have to CLEAN. | 16:51 |
| jroll | per the current spec | 16:51 |
| JayF | AVAILABLE -> MANAGED is a transition | 16:51 |
| jroll | sure | 16:51 |
| JayF | MANAGED -> [CLEAN] -> AVAILABLE is the path out of managed | 16:52 |
| JayF | that's what deva's diagram yesterday indicated | 16:52 |
| jroll | CLEAN -> AVAILABLE -> MANAGED | 16:52 |
| jroll | you can't get to managed without a clean | 16:52 |
| victor_lowther | jroll: you arereading hte graph wrong | 16:53 |
| jroll | er, I guess you can | 16:53 |
| *** dlpartain has quit IRC | 16:53 | |
| jroll | wth | 16:53 |
| *** ryanpetrello has joined #openstack-ironic | 16:53 | |
| *** achanda has joined #openstack-ironic | 16:54 | |
| rloo | jroll is right. If you went through the DELET* state, to get to MANAGED, you have to DELET* -> CLEAN* -> AVAILABLE -> (make request) -> MANAGED | 16:55 |
| jroll | rloo: right, but I was wrong about initial enrollment | 16:56 |
| *** yuriyz has quit IRC | 16:57 | |
| *** yuriyz has joined #openstack-ironic | 16:57 | |
| rloo | jroll: okay ;) | 16:59 |
| *** deva__ has joined #openstack-ironic | 17:01 | |
| *** achanda has quit IRC | 17:02 | |
| *** viktors|afk is now known as viktors | 17:03 | |
| NobodyCam | humm if a available is put back in to manage it has to go thru clean again to become available again | 17:03 |
| JayF | Yes :) That's by design | 17:04 |
| devananda | mornin, all | 17:04 |
| NobodyCam | morning devananda :) | 17:04 |
| JayF | because who knows what the oper did to the machine while it was in MANAGE, and it has to be re-normalized (I like that term) before going back into the pool | 17:05 |
| JayF | or else you risk provisioning an instance to a machine that's slightly different than all the rest | 17:05 |
| jroll | heya devananda | 17:05 |
| jroll | so I think this solves the whole issue with raid stuff | 17:06 |
| jroll | it goes DELETING -> CLEAN -> AVAILABLE -> MANAGED -> ZAP (build raid) -> MANAGED -> CLEAN -> AVAILABLE | 17:06 |
| jroll | erwan_taf: lucasagomes: ^ this should do what you need, yes? assuming CLEAN knows how to tear down a raid? | 17:06 |
| lucasagomes | jroll, hmm kinda, but there's a race there between AVAILABLE and MANAGED no? | 17:07 |
| jroll | mmm. | 17:07 |
| lucasagomes | node becomes AVAILABLE, then have to be manually moved to MANAGED | 17:07 |
| *** subscope has quit IRC | 17:08 | |
| jroll | lucasagomes: assuming there's a flavor that can schedule to that node when it doesn't have a raid, yeah, there's a race | 17:08 |
| devananda | jroll: the problem there is, if the node is AVAILABLE, it might be scheduled by Nova at that point | 17:08 |
| victor_lowther | jroll: seriously, what is wrong with making CLEANING be responsible for recreating whatever raid config it tore down? | 17:08 |
| jroll | devananda: right | 17:08 |
| victor_lowther | if it even needs to do so? | 17:08 |
| jroll | victor_lowther: I'm not sure that it fits, maybe it does | 17:08 |
| devananda | jroll: if you need to do a destructive task between DELETING and DEPLOYING, it has to happen before AVAILABLE, if you want to guarantee that it happens at all | 17:08 |
| lucasagomes | yeah | 17:09 |
| devananda | victor_lowther: ++ | 17:09 |
| lucasagomes | as rloo pointed it may be a language problem, maybe cleaning is not the best term for it | 17:09 |
| lucasagomes | cause cleaning building RAID, sure it can, but sounds a bit out of place | 17:10 |
| *** romcheg has joined #openstack-ironic | 17:10 | |
| jroll | well | 17:10 |
| *** achanda has joined #openstack-ironic | 17:10 | |
| jroll | I'm fine with cleaning building exactly the raid it tore down | 17:10 |
| erwan_taf | we are not facing technical issues but semantic ones | 17:10 |
| JayF | jroll: thats what I had in mind | 17:10 |
| erwan_taf | in a state machine having a single verb per action is nice to ease the communication | 17:11 |
| erwan_taf | we are hidding states under a single name | 17:11 |
| erwan_taf | cleaning is not creating | 17:11 |
| erwan_taf | that's where the confusion comes from | 17:11 |
| *** jistr|trng has quit IRC | 17:11 | |
| erwan_taf | cleaning should clean | 17:11 |
| devananda | can we not argue about languages in such a multi-cultural, multi-national environment? | 17:12 |
| devananda | I'm giong to rename them states AAA, BBB, CCC, DDD | 17:12 |
| jroll | the problem is that we can't feasibly encode every potential cleaning or zapping task in this state machine | 17:12 |
| lucasagomes | devananda, heh, well default is english :D | 17:12 |
| devananda | and then start adding one character from every language I know | 17:12 |
| victor_lowther | if the system config does not change from the POV of hte rest of hte graph, then who cares? | 17:12 |
| devananda | some kanji, sanskrit, and greek for good measure | 17:12 |
| *** marcoemorais has joined #openstack-ironic | 17:13 | |
| victor_lowther | Interesting Game of Life patterns. | 17:13 |
| devananda | because UTF8 is cool | 17:13 |
| devananda | brb, gotta walk into the office | 17:13 |
| victor_lowther | I want the glider gun state. | 17:13 |
| lucasagomes | "There are only two hard problems in Computer Science: cache invalidation and naming things" | 17:13 |
| JayF | µå˜å©´∂ -> [笴å˜] -> å√刬å∫¬´ | 17:13 |
| NobodyCam | JayF: huh | 17:14 |
| JayF | NobodyCam: alternate state names with utf8 | 17:15 |
| rloo | so if we rename 'CLEAN' to 'QQQ' and 'ZAP' to 'PPP' does it help? | 17:15 |
| *** marcoemorais1 has joined #openstack-ironic | 17:15 | |
| rloo | (we can figure out the actual names or vote on it or something later) | 17:15 |
| erwan_taf | devananda: I'm sorry to disagree. we are already exchanging with english words/verbs. If we do hide various action under a single umbrella that creates confusion and useless debates because everyone understand that word differently | 17:15 |
| *** marcoemorais1 has quit IRC | 17:16 | |
| NobodyCam | state 1; state 2 state 3.... | 17:16 |
| victor_lowther | or since people are getting hung up on the word state, taskbucket 1, taskbucket2, etc. | 17:16 |
| erwan_taf | I mean we are defining server's states which does exists, so it shouldbe verbs | 17:16 |
| erwan_taf | or adverbs | 17:17 |
| romcheg | Let's use universal musical notation: sad sound for DELETING, etc.. | 17:17 |
| jroll | I mean | 17:17 |
| jroll | the words don't matter | 17:17 |
| *** marcoemorais1 has joined #openstack-ironic | 17:17 | |
| jroll | the spec has a description of every state that is defined | 17:17 |
| jroll | we should use those definitions, not the words themselves | 17:17 |
| rloo | erwan_taf: can you propose something that works with AAA, BBB, CCC states or whatever. we can deal with the actual names later. | 17:17 |
| *** marcoemorais has quit IRC | 17:17 | |
| rloo | ++ jroll | 17:17 |
| jroll | in the state diagram, the words are only a reference to those definitions | 17:18 |
| erwan_taf | if that doesn't shock anyone that a state named "clean" is made for creating something .... | 17:20 |
| * erwan_taf read : "CLEANING be responsible for recreating whatever raid config" | 17:20 | |
| erwan_taf | that hurts my logical brain ... sorry for that | 17:20 |
| victor_lowther | offtopic: compliance training that I cannot fast-forward through audio | 17:20 |
| erwan_taf | If I the sole one, I step down on that topic | 17:20 |
| jroll | erwan_taf: where do you see that? | 17:20 |
| erwan_taf | <victor_lowther> jroll: seriously, what is wrong with making CLEANING be responsible for recreating whatever raid config it tore down? | 17:21 |
| victor_lowther | it is not as if I have not been taking this course every year for the last 17 years. :/ | 17:21 |
| rloo | erwan_taf: please humour us, try to be constructive. Replace 'CLEAN*' with whatever for now. If you could/did, would it work? | 17:21 |
| jroll | erwan_taf: so, here's a thing | 17:21 |
| jroll | erwan_taf: clean should clean the raid volume, agree? | 17:21 |
| *** ParsectiX has joined #openstack-ironic | 17:22 | |
| jroll | erwan_taf: a raid volume is cleaned by disassembling the raid, scrubbing each disk, and reassembling the raid, agree? | 17:22 |
| erwan_taf | rloo: I'm just trying to say that sometimes if a state is hidding serveral differents tasks it just means that we need to split this state in two states | 17:22 |
| rloo | erwan_taf: so what two states would you suggest? | 17:22 |
| rloo | erwan_taf: clean & prepare? | 17:22 |
| Nisha | devananda, victor_lowther : [off_topic here] i have a question regarding states. Why DISCOVERYFAIL/INTROSPECTIONFAIL/INSPECTIONFAIL not a valid state? | 17:22 |
| victor_lowther | erwan_taf: not if the end states from the POV of the graph are the same. | 17:23 |
| rloo | Nisha: I think it is INSPECTFAIL, and it is a valid state | 17:23 |
| victor_lowther | Nisha: they are, why would you think otherwise? | 17:23 |
| * lucasagomes feels we are being sucked into the FSM thing again | 17:23 | |
| jroll | we have a dirty raid volume, we want a clean raid volume, this means we need to re-assemble the raid when it's done cleaning | 17:23 |
| Nisha | rloo, the states spec doesnt mention about the state | 17:23 |
| Nisha | victor_lowther, ^^^ | 17:23 |
| rloo | Nisha: it is mentioned. Maybe we need to clarify it. | 17:24 |
| jroll | Nisha: comment that on the spec, please | 17:24 |
| erwan_taf | rloo: yes something lke clean/erase/wipe versus build/create/ | 17:24 |
| victor_lowther | https://www.irccloud.com/pastebin/uPnYSYQy | 17:24 |
| rloo | Nisha: see line 119 | 17:24 |
| lucasagomes | jroll, victor_lowther maybe having CLEAN -> PREPARE -> AVAILABLE? | 17:24 |
| devananda | back | 17:24 |
| NobodyCam | wb devananda | 17:25 |
| lucasagomes | where prepare could also prepare the machine like preboot | 17:25 |
| jroll | lucasagomes: but, what is PREPARE? put the server back how it was? sounds like CLEAN | 17:25 |
| lucasagomes | devananda, wb | 17:25 |
| victor_lowther | lines 13 - 15 in that paste. | 17:25 |
| rloo | Nisha: ...a -ED suffix, and the fail state has a -FAIL suffix | 17:25 |
| *** ndipanov is now known as ndipanov_gone | 17:25 | |
| Nisha | rloo, ohk. thanks | 17:26 |
| rloo | Nisha: if you can think of a better way to word it or if an example would help, please comment in the spec. | 17:27 |
| jroll | can I point out here that this whole "rebuild a raid" thing is only one use case? and that I think it fits into the current proposal, I think we would be safe moving forward with what we have, and if it causes problems later we can fix it. | 17:28 |
| jroll | also, documentation is a thing | 17:28 |
| lucasagomes | jroll, right, the preboot thing I think is also valid | 17:28 |
| Nisha | rloo, ok :) | 17:28 |
| jroll | if we make it clear that any existing raids are rebuilt in CLEAN, that's fine | 17:28 |
| lucasagomes | jroll, cause you are powering on the node right? and leave it like that | 17:28 |
| jroll | lucasagomes: I disagree that we need a preboot state, just power on at the transition to available or whatever, and use node.properties to signal to nova that it's prebooted | 17:29 |
| lucasagomes | and you prebooted node are different than non prebooted mode, so it changes the states (and scheduler is aware) | 17:29 |
| jroll | have the scheduler prefer nodes with node.properties['prebooted'] == True | 17:29 |
| erwan_taf | jroll: sorry for being the grumpfy guy. It clean needs to rebuild something it means for me it's not the proper time to do it :/ | 17:29 |
| erwan_taf | jroll: would you build a house, dismantle it to clean it and rebuild it then ? | 17:30 |
| *** jcoufal has quit IRC | 17:30 | |
| erwan_taf | s/It clean/If clean/ | 17:30 |
| rloo | was lucasagomes the only one that asked for a PREBOOT state? I see that state from the summit whiteboard | 17:30 |
| jroll | erwan_taf: if I was told by someone smarter than me that this is the proper way to clean a house, yes. | 17:30 |
| lucasagomes | rloo, nop, I think J's had the use case for that | 17:30 |
| lucasagomes | the way I understood it was like a optimization prior to amke the node AVAILABLE | 17:31 |
| JayF | erwan_taf: if you want to make sure that nobody hid any landmines in the floor; yep | 17:31 |
| JayF | lol | 17:31 |
| jroll | rloo: lucasagomes: we have a use case for prebooting things, not for a state though | 17:31 |
| victor_lowther | erwan_taf: Wouldn;t do it to a house, definitly would to a server. :) | 17:31 |
| lucasagomes | which could be powering on the node | 17:31 |
| lucasagomes | or perhaps even pre-imaging it | 17:31 |
| victor_lowther | and I would have canned air and a dust mask ready. | 17:31 |
| victor_lowther | maybe even new thermal paste | 17:31 |
| erwan_taf | still thinking than clean should clean the raid at some point and destroy everthung needed and then build something that we be used finally | 17:32 |
| erwan_taf | create-raid / delete / create again could change Ids eetc.. | 17:32 |
| *** ryanpetrello has quit IRC | 17:32 | |
| victor_lowther | and after doing that, the server would be left in the same configuration as it was in before cleaning, minus the unneeded cruft that had built up. | 17:32 |
| *** Marga_ has joined #openstack-ironic | 17:32 | |
| jroll | erwan_taf: in general, what we want to do is go from dirty raid volume to clean raid volume | 17:32 |
| jroll | erwan_taf: you told me the only way to do this is to tear down the raid, clean each disk, and build it again | 17:33 |
| rloo | so erwan_taf suggested two states instead of the one CLEAN*: clean/erase/wipe versus build/create/ | 17:33 |
| erwan_taf | I mean | 17:33 |
| jroll | erwan_taf: so yes, I think that should all be done in the CLEAN phase | 17:33 |
| rloo | and lucasagomes suggested CLEAN and PREPARE | 17:33 |
| jroll | this isn't preparing | 17:33 |
| jroll | this is cleaning | 17:33 |
| devananda | erwan_taf: this really feels like a linguistic argument, and not constructive. can you make your point without relying on the word "CLEAN"? | 17:33 |
| erwan_taf | to clean a server, we need to dismantle its raid and clean every single disk, yes | 17:33 |
| rloo | what's the issue with adding a 2nd state that can be a noop for those that don't want it? | 17:33 |
| rloo | and/or what's the issue with adding a 2nd state later when there is a usecase for it? | 17:33 |
| erwan_taf | then the server is clean and not configured | 17:33 |
| devananda | rloo: unnesseray complexity | 17:33 |
| victor_lowther | because so far it is jsut for this one special case. | 17:34 |
| erwan_taf | it's then time to prepare it by setting the raid | 17:34 |
| rloo | so we need a word that means 'clean up and get ready/prep' | 17:34 |
| *** viktors is now known as viktors|afk | 17:35 | |
| jroll | victor_lowther++ | 17:35 |
| rloo | "recuperate" or "take a holiday" I think. | 17:35 |
| victor_lowther | and I htink CLEAN is a good enough one-word summary. | 17:35 |
| openstackgerrit | Merged openstack/python-ironicclient: Add option to specify node uuid in node-create subcommand https://review.openstack.org/132137 | 17:35 |
| jroll | erwan_taf: think about it as cleaning the server. one step of that is to clean the raid. when you clean a raid volume, you shold come out the other end with a raid volume. | 17:35 |
| jroll | this is all semantics | 17:35 |
| jroll | all english | 17:36 |
| jroll | and I think we're all wasting time here | 17:36 |
| devananda | i am not going to engage in a serious discussion about whether or not the word CLEAN is the optimal word. it's good enough. | 17:36 |
| jroll | while half the specs up for review wait for us to finish | 17:36 |
| rloo | CLEANUP? | 17:36 |
| devananda | we already perform many sub-actions within each state transitiona | 17:36 |
| erwan_taf | jroll: no I mean if you mean to clean the server it means more than clean the actual raid | 17:36 |
| devananda | an arbument based on breaking every single micro task into its own state is a meritless strawman | 17:37 |
| erwan_taf | jroll: it does mean cleaning _all_ the disks, even the ones that are not part of that particular raid | 17:37 |
| victor_lowther | CLEAN can be -ING and -ED ed, and CLEANUP is just awkward there. | 17:37 |
| erwan_taf | jroll: we are supposed to clean the server not only the raid volume | 17:37 |
| devananda | can we please get back to the business of making software? | 17:37 |
| jroll | erwan_taf: of course, the raid is one step | 17:37 |
| jroll | I'm done | 17:37 |
| * erwan_taf feel sorry not being able to express itself clear enough to get understood | 17:37 | |
| jroll | I'm +1 on the proposed state machine | 17:37 |
| jroll | and I've reflected that in the review | 17:38 |
| erwan_taf | and being received as trying to get thing being explicit | 17:38 |
| jroll | I think we should all get to the point where we are +1 on the proposed state machien | 17:38 |
| erwan_taf | I'm seen as being grumpfy for being grumpfy | 17:38 |
| jroll | and then we can move on to the actual import parts, like how the hell do we do this in an upgradeable fashion | 17:38 |
| lucasagomes | jroll, yeah sounds better indeed | 17:38 |
| devananda | jroll: speaking of that, i have somethuing ... | 17:38 |
| devananda | jroll: https://github.com/devananda/ironic/tree/FSM | 17:39 |
| lucasagomes | erwan_taf, no worries :) I mean everyone is trying to help | 17:39 |
| devananda | started poking at it last night to see if i could model our current states in an FSM | 17:39 |
| erwan_taf | devananda: I though you didn't wanted a FSM... | 17:40 |
| devananda | starting from where we are, going straight to new states AND a new modelling layer will be a breaking upgrade path, IMO | 17:40 |
| jroll | devananda: neat | 17:40 |
| jroll | agree | 17:40 |
| devananda | erwan_taf: i never said that | 17:40 |
| erwan_taf | devananda: if you want to see if that is FSM compatible the answer is no. If you want a FSM which is ___nice___ that's requires some rules that are not applied here ... | 17:42 |
| erwan_taf | devananda: having a FSM compatible thing was the starting point with lucasagomes and that got rejected | 17:42 |
| devananda | erwan_taf: unless i did. in which case, i was being sarcastic, or i changed my mind. all of these are possible. but if you read victor_lowther 's spec for a state machine, and followed the discussion we had been having over the last month at all, you'd know that we've been working on a state machine this whole time | 17:42 |
| devananda | erwan_taf: also, there are multiple types of FSM. what we have in production today IS an FSM | 17:42 |
| erwan_taf | but all the arguments we pushed for a FSM got rejected | 17:43 |
| devananda | but not explicitly modelled as such | 17:43 |
| devananda | no | 17:43 |
| devananda | seriously. i'm sorry you dont understand why this was met with the response it was | 17:43 |
| devananda | it's not because it is an FSM. we were working on one too. it's the way you presented it, in throwing out all the work we were already doing | 17:43 |
| devananda | and ihnsisting that our aproach is not really a FSM | 17:44 |
| erwan_taf | i agree we were wrong on the process to present that | 17:44 |
| lucasagomes | devananda, that wasn't the intention | 17:44 |
| erwan_taf | having the requirement to get a FSM is the best argument ever to get a state machine that works perfectly well and simplify the core of ironic | 17:45 |
| erwan_taf | it would be so brilliant to get ironic propusled by a FSM | 17:45 |
| devananda | oh no... FSMs are not simple. this massively complicates things | 17:45 |
| devananda | i've resisted a FORMAL state machine for the last three years because of this | 17:46 |
| devananda | anyway, i'm taking a break again and going to work on this. sorry if i seem rude, but having this discussion again isn't helpful for the channel | 17:46 |
| jroll | on that note, can everybody please go post their comments on the spec? | 17:46 |
| *** tatyana has quit IRC | 17:47 | |
| victor_lowther | formal state machines are great when they can perfectly model every aspect of a system. That is decidedly not the case when we have to do nasty things like deal with hardware. | 17:47 |
| victor_lowther | yes, give me all your comments. | 17:47 |
| *** pensu has joined #openstack-ironic | 17:47 | |
| victor_lowther | while I ditch this ridiculous complinace training and get lunch | 17:47 |
| lucasagomes | victor_lowther, g'luck :) | 17:48 |
| * lucasagomes have to do it as well | 17:48 | |
| jroll | erwan_taf, lucasagomes, rloo, post comments on the spec please, we don't make any progress if you don't | 17:48 |
| lucasagomes | jroll, will do | 17:48 |
| *** romcheg1 has joined #openstack-ironic | 17:49 | |
| *** romcheg has quit IRC | 17:49 | |
| erwan_taf | devananda, victor_lowther : can I take as a will/goal to get a FSM like state machine ? | 17:51 |
| erwan_taf | I mean for my comments | 17:51 |
| jroll | erwan_taf: you should comment with your beliefs IMO | 17:52 |
| jroll | erwan_taf: I'd also love to be educated why this state machine is not finite | 17:52 |
| erwan_taf | done | 17:54 |
| erwan_taf | stupid question, how ever did implement an FSM ? | 17:55 |
| jroll | can you rephrase that? | 17:56 |
| rloo | erwan_taf: it would be helpful to add a comment there, explaining WHY it couldn't be implemented in an FSM. I don't think a goal was to have that, but it would be useful to know, for the future. | 17:56 |
| rloo | erwan_taf: what's a "stupid question"? | 17:56 |
| erwan_taf | I mean I feel like hurted by what I read about this state machine, but wonder how many ever experienced FSM before that | 17:57 |
| erwan_taf | I mean having a state that have 3 inputs ... | 17:57 |
| *** killer_prince has joined #openstack-ironic | 17:58 | |
| *** killer_prince is now known as lazy_prince | 17:58 | |
| erwan_taf | the same state can be achieved is hidding in fact different sub states | 17:58 |
| erwan_taf | -can be achieved | 17:58 |
| jroll | I have implemented plenty of finite state machines back in university, maybe since then but I don't remember | 17:58 |
| jroll | perhaps what we do cannot be modeled by a perfect FSM | 17:59 |
| jroll | the inspect and zap tasks are optional, manual, tasks | 17:59 |
| erwan_taf | so a managed server could be or not zapped right ? | 17:59 |
| jroll | correct | 18:00 |
| *** derekh has quit IRC | 18:00 | |
| erwan_taf | our proposal with lucasagomes was to get zap as mandatory step but _doing nothing_ by default | 18:00 |
| erwan_taf | so we have a state representing what is a "zapped" server which is zapped or not | 18:01 |
| jroll | the thing is, you can't predict when a node needs to be zapped | 18:01 |
| erwan_taf | depends on the implmeentation of that driver | 18:01 |
| jroll | in my use case, a node needs to be zapped when my vendor ships me new firmware | 18:01 |
| erwan_taf | sure that's implementation | 18:01 |
| erwan_taf | in that example we have: managed -> zapping -> zapped | 18:02 |
| jroll | in a way; in your proposal, when is a node zapped? | 18:02 |
| erwan_taf | when you need to prepare it | 18:02 |
| jroll | which is when? | 18:02 |
| lucasagomes | jroll, we called "normalising "for the BIOS/firmware update, "preparing" for raid stuff, "cleaning" for cleaning | 18:03 |
| jroll | lucasagomes: sure. when does normalizing happen? | 18:03 |
| lucasagomes | jroll, will get the diagram for u | 18:03 |
| lucasagomes | 1 sec | 18:03 |
| erwan_taf | jroll: what I mean, is when a server reach a particular state, you should be in position to say what was done before | 18:03 |
| lucasagomes | it was after managed btw | 18:03 |
| erwan_taf | in that case, you can't as managed represents too many options/cases/states | 18:04 |
| lucasagomes | jroll, https://docs.google.com/drawings/d/1Pxy2lr270yAlP78P7knhYhmBbanKWFf2EfcwVrduOtA/edit?usp=sharing | 18:04 |
| jroll | lucasagomes: so how do I go from available to available with a firmware update in between? | 18:04 |
| * jroll looks | 18:04 | |
| lucasagomes | jroll, this was part of the document we were writing | 18:04 |
| jroll | or in this case, ready to ready | 18:04 |
| *** harlowja_away is now known as harlowja_ | 18:04 | |
| lucasagomes | you could always go back to manageable | 18:04 |
| lucasagomes | and restart the main loop | 18:05 |
| jroll | ok, but then we have the same problem | 18:05 |
| lucasagomes | so you can get u zapped | 18:05 |
| jroll | to entry points to that state | 18:05 |
| erwan_taf | no state is self looping here | 18:06 |
| erwan_taf | jroll: another way to say that | 18:06 |
| erwan_taf | jroll: in this example, a clean server, is a server that passed all the steps before | 18:06 |
| erwan_taf | jroll: without any exception | 18:07 |
| erwan_taf | jroll: even if some are empty body | 18:07 |
| erwan_taf | jroll: so you can trust the state to define a particular "time" in the life cycle | 18:07 |
| erwan_taf | jroll: which such loops on MANAGED that becomes unpredictable | 18:07 |
| *** andreykurilin_ has joined #openstack-ironic | 18:07 | |
| jroll | hmm | 18:08 |
| lucasagomes | yeah states becomes self explanatory | 18:08 |
| lucasagomes | just by reading the previous states | 18:08 |
| erwan_taf | jroll: you cannot know if the server is zapped or not and even worst .... is it a server that should have been zapped but not zapped | 18:08 |
| erwan_taf | it's only MANAGED | 18:08 |
| lucasagomes | what does READY means? it means the machine is CLEAN, CONSISTENT, NORMALIZED etc... | 18:08 |
| lucasagomes | it's important because FSM has no "memory" | 18:09 |
| lucasagomes | it's limited by it's states | 18:09 |
| erwan_taf | btw, not trying to propose that version but illustrate the issues on the current one | 18:09 |
| lucasagomes | so each state is very clear about what is the state of the server when how it got there | 18:09 |
| jroll | ZAP is not a state that needs to be done every cycle | 18:09 |
| jroll | that's the thing | 18:09 |
| jroll | the whole point of splitting zap/clean | 18:09 |
| erwan_taf | this is the perfect thing | 18:09 |
| lucasagomes | jroll, when we did it we based on the decommisioning | 18:10 |
| lucasagomes | which was done every cycle | 18:10 |
| jroll | zapping is something that an external system (human/robot/something else) triggers in extraordinary circumstances | 18:10 |
| jroll | (as we've defined it recently, that is) | 18:10 |
| lucasagomes | jroll, right, it's cool to move some of it out of the main loop | 18:13 |
| lucasagomes | but you gotta guarantee that once "zapped" the machine will reenter the main loop | 18:13 |
| lucasagomes | and do the required steps to become READY | 18:13 |
| lucasagomes | but always trhought a single path | 18:13 |
| erwan_taf | +1 | 18:17 |
| *** rushiagr is now known as rushiagr_away | 18:17 | |
| rloo | lucasagomes: where/what is the 'introspect' state, in the FSM? | 18:19 |
| rloo | err, s/introspect/inspect/ | 18:20 |
| *** achanda has quit IRC | 18:20 | |
| *** MattMan has quit IRC | 18:20 | |
| jroll | there's another problem I have, you can't inspect every time a node is cycled | 18:20 |
| jroll | by our definition of inspect | 18:20 |
| lucasagomes | rloo, we did it as part of becoming "defined" | 18:21 |
| erwan_taf | jroll: if you have a strong expection of the state of this hw, I do suggest inspecting before actually using it | 18:21 |
| lucasagomes | rloo, and conformity check should check if the machine is confirming | 18:21 |
| *** achanda has joined #openstack-ironic | 18:21 | |
| rloo | lucasagomes: at what point do you know you can talk to the node with the supplied credentials? | 18:21 |
| lucasagomes | rloo, because if you do like some firwamre update you can introduce new features | 18:22 |
| lucasagomes | or bios flashing etc | 18:22 |
| lucasagomes | you can disable/enable CPU cores for example via BIOS | 18:22 |
| erwan_taf | jroll: on my daily work, I can prevent a node to be used if the NICs are not well connected to the good switches or if the system is already too hot | 18:22 |
| jroll | erwan_taf: we've defined inspecting as, "find out what this hardware is and update the database". we can't do that every cycle, say ram fails, suddenly you're running on different hardware without knowing it | 18:22 |
| erwan_taf | jroll: that's a very late decision to take | 18:22 |
| jroll | what | 18:22 |
| lucasagomes | rloo, once it's manageable | 18:22 |
| jroll | we do this in production during "decommissioning" (which has become cleaning/zapping | 18:23 |
| rloo | lucasagomes: can we always inspect before we know if we can talk to the node? | 18:23 |
| lucasagomes | rloo, the "validating manageability" action will test if you have the right credentials etc | 18:23 |
| rloo | lucasagomes: I'm just wondering why we put inspecting after managed in the proposed | 18:23 |
| jroll | erwan_taf: our discovery stuff won't tell you it isn't connected or too hot, it will just update ironic's database to say what it is and isn't connected to | 18:23 |
| erwan_taf | jroll: you have two different time: 1 for checking the unlikely to be changed values, 1 for checking the likely to be changed values | 18:23 |
| jroll | no | 18:24 |
| jroll | no | 18:24 |
| jroll | no | 18:24 |
| jroll | values should never change | 18:24 |
| jroll | without me knowing | 18:24 |
| erwan_taf | *ahah* | 18:24 |
| rloo | lucasagomes: but you said inspecting happened as part of becoming defined, and that happens before validating. | 18:24 |
| erwan_taf | sorry, but they will | 18:24 |
| jroll | what | 18:24 |
| erwan_taf | disk is broken ? | 18:24 |
| erwan_taf | system too hot ? | 18:24 |
| jroll | yeah, that will change | 18:24 |
| jroll | I don't want my database to change to reflect this | 18:24 |
| erwan_taf | nic not well connectd ? | 18:24 |
| erwan_taf | broken DIMM ? | 18:24 |
| jroll | I want that node to be failed | 18:24 |
| erwan_taf | yes but you have to check its conformoty to a model | 18:25 |
| jroll | our "inspect" work explicitly only does the former | 18:25 |
| erwan_taf | yes I know | 18:25 |
| erwan_taf | would be nice at some point being able to cope with more precise cases | 18:25 |
| lucasagomes | rloo, right, I believe that's the 2 "discovery" thing | 18:25 |
| erwan_taf | deploying on a {almost}broken node isn't a good idea | 18:25 |
| jroll | no shit | 18:25 |
| erwan_taf | but that's a different topic | 18:25 |
| lucasagomes | that's why we have that "introspection/inspect" in the proposed, it's not actually discovering a new node | 18:26 |
| lucasagomes | where CREATED is like discovering | 18:26 |
| rloo | lucasagomes: you lost me. what '2 "discovery" thing'? | 18:26 |
| lucasagomes | discover nodes vs discovering node properties | 18:26 |
| jroll | the difference is | 18:26 |
| jroll | inspection is manual in the current proposal | 18:26 |
| lucasagomes | the later we changed to "introspecting" to avoid confusing | 18:27 |
| lucasagomes | confusion* | 18:27 |
| rloo | so lucasagomes, in the FSM (== the FSM, and proposed==our-not-FSM-being-proposed) | 18:28 |
| rloo | lucasagomes: are you saying that inspecting happens in the 'Filing Cred...' action? | 18:28 |
| aweeks | just going to leave this here https://i.imgur.com/mgnDvDz.jpg | 18:28 |
| lucasagomes | jroll, I think that the problem happens if the node doesn't fail to deploy | 18:28 |
| lucasagomes | then the deploy successed but you gave you client something different than he asked for or is paying for | 18:29 |
| lucasagomes | because you haven't checked before the machine is exactly what it says it's before giving the node to him | 18:29 |
| *** athomas has quit IRC | 18:29 | |
| jroll | lucasagomes: there's room for validating hardware every cycle, we need it, I agree | 18:29 |
| lucasagomes | client asks for X,Y,A but gets X,Y,Z | 18:29 |
| lucasagomes | that's hard to debug | 18:29 |
| lucasagomes | if it fails on deploy time that's the best it can happen | 18:30 |
| JayF | That type of verification is something I could see being done in a CLEAN state even though | 18:30 |
| lucasagomes | rloo, yes | 18:30 |
| JayF | in fact we do some of it today in our downstream decomissioning | 18:30 |
| lucasagomes | JayF, machine can sits on AVAIALBLE for 1 month | 18:30 |
| lucasagomes | something can happen there | 18:30 |
| lucasagomes | after that you have no validation | 18:30 |
| rloo | lucasagomes: what if the inspecting can't inspect cuz it can't talk to the node? | 18:31 |
| JayF | lucasagomes: that's a reasonable point; but I don't want to pay that inspection time on every deploy tbh | 18:31 |
| lucasagomes | rloo, maintenance with reason | 18:31 |
| lucasagomes | someone has to look at the machine and figure that it;s inacessible | 18:31 |
| lucasagomes | retry | 18:31 |
| lucasagomes | it's a retryable state | 18:31 |
| lucasagomes | retry after fixing* | 18:31 |
| jroll | so | 18:31 |
| lucasagomes | JayF, it's cool, I mean you can make that non-op | 18:32 |
| jroll | we validate hardware today at deprovision time | 18:32 |
| jroll | not at provision time | 18:32 |
| lucasagomes | JayF, that's why it's seaprated actions with diff names | 18:32 |
| jroll | and problems have been minimal | 18:32 |
| rloo | lucasagomes: so then, in the proposed diagram (note, I'm not calling it a FSM;)), do you think we should move INSPECT* to ENROLL -> INSPECT* -> VALIDAT* ? | 18:32 |
| lucasagomes | you don't have to implement if ur not using | 18:32 |
| jroll | I think we've had like... maybe 5 deploys of a not-quite-working node | 18:32 |
| jroll | *maybe* | 18:32 |
| JayF | out of 1000+ instance deploys on average per day | 18:32 |
| lucasagomes | jroll, JayF I understand ur use case | 18:33 |
| NobodyCam | brb | 18:33 |
| jroll | lucasagomes: I mean, I understand why it would be good | 18:33 |
| lucasagomes | and in any way that diagram says you _have_ to implement that | 18:33 |
| jroll | I'm just saying in the real world, it's rare | 18:33 |
| lucasagomes | what it does say is that, for those who wants it (and I think it's valid) | 18:33 |
| lucasagomes | it can be done | 18:33 |
| lucasagomes | it can cope with both use cases | 18:33 |
| lucasagomes | jroll, right, rare but can happen | 18:34 |
| lucasagomes | for 1000+ ok yeah 5 times | 18:34 |
| lucasagomes | but once you get bigger and bigger it can get worse and worse | 18:34 |
| jroll | nonono | 18:34 |
| jroll | 1000+ per day | 18:34 |
| jroll | since june | 18:34 |
| jroll | and maybe 5 total since june | 18:34 |
| *** Masahiro has joined #openstack-ironic | 18:35 | |
| *** pelix has quit IRC | 18:35 | |
| lucasagomes | right, but if you could capture that 5 cases before hand wouldn't that be helpful? | 18:35 |
| lucasagomes | I think that we have been talking about not trusting hardware | 18:35 |
| lucasagomes | not trusting BMCs all the time | 18:35 |
| lucasagomes | that's what that actions is for | 18:35 |
| lucasagomes | if u want to guarantee, you can | 18:35 |
| lucasagomes | 5 of ur machines became non-conformant, few cases or not, it's a valid state where all servers potentially can end up in | 18:36 |
| * jroll thinks | 18:36 | |
| jroll | if validating hardware is part of the deploy task | 18:37 |
| jroll | shouldn't that just be done in the deploying state? | 18:37 |
| *** ParsectiX has quit IRC | 18:38 | |
| lucasagomes | it could, I could fit actions inside other actions. But again, a deploy failure is different than a conformity check | 18:38 |
| lucasagomes | a conformity check is not a failure | 18:38 |
| lucasagomes | it's a check that takes ur server to a state which says it's not conformant | 18:38 |
| *** Masahiro has quit IRC | 18:40 | |
| lucasagomes | because that's actually the state of the machine, "look I'm not what you're telling me I am" | 18:40 |
| lucasagomes | so please take a look at me :) | 18:40 |
| jroll | dunno, I tend to think it's a failure | 18:40 |
| jroll | DEPLOYFAIL, maintenance=true, maintenance_reason='RAM did not match what's in the db" | 18:41 |
| JoshNang | lucasagomes: it could go to a state other than deployfail | 18:41 |
| JoshNang | or that^ | 18:41 |
| jroll | idk | 18:41 |
| lucasagomes | JoshNang, that's why we have that action YES or NO cause it has multipaths | 18:41 |
| lucasagomes | if when DEPLOY fails you can move to 2 diff states | 18:42 |
| lucasagomes | depending on what is happening internally in deploy you have no predicability | 18:42 |
| jroll | I have some thoughts that people probably won't love | 18:42 |
| jroll | 1) why did we decide to rewrite the entire state machine in the first place? | 18:43 |
| jroll | 2) is it possible (and/or detrimental to the project) to punt on this for now? | 18:43 |
| lucasagomes | 1) I think we need it, we have the decom use case for it | 18:44 |
| lucasagomes | that by itself is a valid reason | 18:44 |
| lucasagomes | 2) idk | 18:44 |
| jroll | we need to add to it | 18:44 |
| jroll | does not mean we need to rewrite the whole thing | 18:45 |
| lucasagomes | yes | 18:45 |
| lucasagomes | but the way we have states now it's hard | 18:45 |
| jroll | right | 18:45 |
| jroll | ok | 18:45 |
| lucasagomes | cause it's too feel doing too many thing | 18:45 |
| lucasagomes | with well defined states, if you need to add a state in between later is easy | 18:45 |
| jroll | just curious, I couldn't remember why we started this in the first place | 18:45 |
| jroll | I think the summit thing went from "what does our state machine actually look like" to "fuck this thing, let's fix it" | 18:46 |
| lucasagomes | cause you know exactly what to expect when the server gets there | 18:46 |
| lucasagomes | without multipaths | 18:46 |
| lucasagomes | jroll, yeah I think so too | 18:46 |
| lucasagomes | we started drawing on that whiteboard and started thinking about a better model | 18:46 |
| lucasagomes | which was good :) | 18:46 |
| jroll | and now we're going to spend half the cycle fixing it | 18:47 |
| lucasagomes | yeah | 18:47 |
| lucasagomes | we will have to do it at one point IMO | 18:48 |
| devananda | jroll: thank you | 18:48 |
| devananda | so, we don't need to rewrite the whole thing. and we cant without breaking compat | 18:48 |
| jroll | devananda: for what, I've said a lot | 18:48 |
| devananda | 18:43:10 < jroll> 1) why did we decide to rewrite the entire state machine in the first place? | 18:49 |
| devananda | that | 18:49 |
| jroll | ah | 18:49 |
| devananda | we needed to see how certain new states fit within the existing thing | 18:49 |
| devananda | and without making it overly complex to reason about | 18:49 |
| devananda | statements such as "we can not have multiple paths leading to a single state" and "every state/action can only do one thing" -- I have no idea where these notions came from | 18:50 |
| devananda | I don't believe either of them are part of the current code, nor possible without rewriting the entire project, nor are they an integral part of our project's mission | 18:51 |
| devananda | whcih is, to manage and provision hardware in a cloud-like way (paraphrasing here) | 18:51 |
| *** achanda has quit IRC | 18:51 | |
| devananda | we have existing users. actually, a lot of them | 18:51 |
| devananda | supporting an upgrade path for them is mroe important to me than an idealized version of what a state machine should look like | 18:52 |
| *** achanda has joined #openstack-ironic | 18:52 | |
| *** achanda has quit IRC | 18:52 | |
| *** achanda has joined #openstack-ironic | 18:52 | |
| jroll | ++ | 18:52 |
| *** arif-ali has quit IRC | 18:54 | |
| devananda | lucasagomes: where did the idea that we shouldn't have multiple paths come from? I don't get it | 18:54 |
| lucasagomes | devananda, we were trying to make the states to be predicable | 18:55 |
| devananda | lucasagomes: why is that important? | 18:55 |
| devananda | i mean, why is "no multipath" relevant to "be predictable" | 18:55 |
| lucasagomes | so you know exactly what the steps the node have passed trhough before become what it says it's (the state) | 18:55 |
| jroll | lucasagomes: I'd like to point out that you can get that info from the logs | 18:56 |
| devananda | a finite state machine has, for any given state, a set of acceptable inputs, whcih determine the next state that it transitions to | 18:56 |
| lucasagomes | cause if you come from multiple places | 18:56 |
| lucasagomes | and state machines have no "memory" | 18:56 |
| devananda | lucasagomes: why is THAT important? | 18:56 |
| lucasagomes | you can't define from where you came from if there are multi paths | 18:56 |
| jroll | but ironic has a database, and a log file | 18:56 |
| jroll | the code may not know where it came from | 18:56 |
| jroll | but that's irrelevant | 18:56 |
| *** arif-ali has joined #openstack-ironic | 18:56 | |
| lucasagomes | devananda, it's good practice, I mean, we were trying to come up with something simple | 18:56 |
| jroll | the code doesn't need to know that | 18:57 |
| lucasagomes | something people can look at and see | 18:57 |
| lucasagomes | what my server is, and what it did to become it | 18:57 |
| lucasagomes | by simplying looking at the diagram | 18:57 |
| lucasagomes | I get it's not what we are aiming for now | 18:57 |
| jroll | why do you need to know that unless you're debugging | 18:57 |
| lucasagomes | but I don't know why so much bashing, or why we are causing frustatrion | 18:57 |
| lucasagomes | simply because we spent some time and effort to present something nice to the project | 18:58 |
| jroll | I agree this has been rough, and probably too much rage | 18:58 |
| jroll | which comes from everyone working on this for weeks and not making progress | 18:58 |
| jroll | it's not directed towards y'all specifically | 18:58 |
| lucasagomes | in any time I wanted to hurt the project, or delay the current proposal | 18:58 |
| lucasagomes | jroll, yeah I understand | 18:59 |
| lucasagomes | and I have a thick skin too :) so no problem | 18:59 |
| jroll | ha | 18:59 |
| jroll | I hope most people can make it to the midcycle, everyone deserves much beer | 18:59 |
| lucasagomes | +1 :D | 18:59 |
| jroll | I'll cover drinks for the whole week for anyone that +2's that spec right now :P | 19:00 |
| rloo | anyone that +2's that spec should get their core status removed ... don't listen to jroll ;) | 19:00 |
| jroll | I'll still buy drinks if the spec makes it through that way :P | 19:01 |
| NobodyCam | we are doing what we think is best for the project, I have not felt otherwise throught this whole discussion. | 19:01 |
| rloo | so are we moving forward... ?? lucasagomes? were your comments in the spec addressed? | 19:02 |
| lucasagomes | rloo, yeah, just adding a comment about "what nova expects" | 19:03 |
| jroll | what does nova have to do with this? | 19:03 |
| lucasagomes | notihng | 19:03 |
| lucasagomes | just answering victor_lowther comment | 19:03 |
| *** deva__ has quit IRC | 19:03 | |
| lucasagomes | cause he said nova expects ACTIVE and DELETED state from Ironic | 19:03 |
| rloo | jroll: I think that is in reference to the name of the 'ACTIVE' state | 19:03 |
| erwan_taf | devananda: in such particular case, on such a simple use case, having 3 outputs on a state where 2 of them loops on the same states means the state is pretty not well defined | 19:03 |
| lucasagomes | which is not true | 19:03 |
| jroll | oh, right | 19:04 |
| jroll | yeah, nova code can be changed | 19:04 |
| lucasagomes | yeah | 19:05 |
| *** andreykurilin__ has joined #openstack-ironic | 19:09 | |
| *** andreykurilin_ has quit IRC | 19:09 | |
| rloo | so lucasagomes, wrt the spec, are you 'ok' with the state machine as proposed? no preboot, with CLEAN* states, ACTIVE/DELETED? | 19:14 |
| rloo | lucasagomes: I know you didn't -1, but wanted to check ;) | 19:15 |
| lucasagomes | rloo, oh I'm ok with it yeah | 19:15 |
| lucasagomes | will vote | 19:15 |
| rloo | thx | 19:15 |
| lucasagomes | there's some undefined things in the spec, I think Nisha pointed to one state which is not being described | 19:15 |
| jroll | \o/ | 19:16 |
| lucasagomes | but I'm overall ok with that yes | 19:16 |
| rloo | so everyone, how do we move the spec along? we need to flesh out the rest of it :-( | 19:16 |
| jroll | lucasagomes: nah, it was a *FAIL state, which is implicitly defined somewhere | 19:16 |
| jroll | unless Nisha pointed out something else | 19:16 |
| * lucasagomes will recheck her comment and vote | 19:16 | |
| rloo | lucasagomes: Nisha's question has been answered. All the *FAIL were described together, not individually except for zapfail. | 19:17 |
| *** krtaylor has quit IRC | 19:17 | |
| lucasagomes | voted | 19:19 |
| lucasagomes | +1;ed | 19:19 |
| lucasagomes | 'ed* | 19:19 |
| *** spandhe has joined #openstack-ironic | 19:20 | |
| lucasagomes | aight folks, with that | 19:22 |
| lucasagomes | I will go get something to eat :) | 19:22 |
| lucasagomes | have a good night everyone! I ttyl | 19:22 |
| jroll | night lucas :) | 19:22 |
| Shrews | lucasagomes: weren't we supposed to have a name for our mascot today? | 19:22 |
| * Shrews been battling a messed up ubuntu upgrade and may have missed in scrollback | 19:23 | |
| NobodyCam | have a good night lucasagomes | 19:23 |
| lucasagomes | Shrews,holy molly yes | 19:23 |
| lucasagomes | I will close the voting! | 19:23 |
| NobodyCam | oh on the name | 19:24 |
| lucasagomes | NobodyCam, congrats! Pixie Boots | 19:24 |
| rloo | night lucasagomes. thx for staying later ;) | 19:24 |
| lucasagomes | is the name :D | 19:24 |
| NobodyCam | oh wow :) | 19:24 |
| lucasagomes | Pixie Boots is the name of our new mascot! I will send the email later on | 19:24 |
| rloo | goodbye ironica | 19:24 |
| lucasagomes | pool is closed! | 19:24 |
| lucasagomes | Shrews, ta much for the reminder! | 19:24 |
| jroll | \o/ | 19:24 |
| NobodyCam | now is Pixie Boots a boy or girl? | 19:25 |
| JayF | Why do you need to assign gender to an animation :) | 19:25 |
| Shrews | NobodyCam: a perfectly ambiguous name :) | 19:25 |
| NobodyCam | :) | 19:25 |
| PaulCzar | ironic-conductor doesn't print out its config options when it starts in debug mode | 19:25 |
| Shrews | though i will miss the opportunity to design a Ironic Maiden t-shirt | 19:25 |
| PaulCzar | I have tftp_server = 172.16.255.100 set it ironic.conf | 19:26 |
| PaulCzar | but it sets the dhcp_option to 10.0.2.2 on the neutron port | 19:26 |
| lucasagomes | NobodyCam, it can be any :D | 19:26 |
| lucasagomes | or both at the same time | 19:26 |
| NobodyCam | i like it | 19:27 |
| *** spandhe has quit IRC | 19:27 | |
| lucasagomes | email sent :D | 19:27 |
| lucasagomes | food time :) thanks for everyone that voted! | 19:27 |
| * rloo thinks we should vote on the gender of pixie boot ;) | 19:27 | |
| jroll | PaulCzar: wtf | 19:28 |
| * lucasagomes should draw a pair of boots | 19:28 | |
| PaulCzar | fek .. it's not under the [pxe] section | 19:28 |
| NobodyCam | lucasagomes: ++ | 19:28 |
| jroll | oh, ha, I do that all the time | 19:28 |
| PaulCzar | but still, conductor should print out the config options set | 19:28 |
| lucasagomes | o/ night everyone | 19:28 |
| *** lucasagomes is now known as lucas-dinner | 19:29 | |
| jroll | PaulCzar: I thought it did :| | 19:29 |
| JayF | PaulCzar: that'd be a good bug to file --> make sure to tag it low-hanging-fruit | 19:29 |
| *** krtaylor has joined #openstack-ironic | 19:30 | |
| *** spandhe has joined #openstack-ironic | 19:39 | |
| *** pensu has quit IRC | 19:40 | |
| *** achanda has quit IRC | 19:41 | |
| *** achanda has joined #openstack-ironic | 19:42 | |
| NobodyCam | why is so hard to motivate one's self when its grey and raining out side :-p | 19:45 |
| openstackgerrit | Merged openstack/ironic-python-agent: Use _ instead of - for config options https://review.openstack.org/131632 | 19:46 |
| *** achanda has quit IRC | 19:46 | |
| PaulCzar | it seems I need to run the tftpd server in the network namespace that belongs to the neutron dhcp agent ? | 20:02 |
| *** dprince has quit IRC | 20:04 | |
| NobodyCam | PaulCzar: namespace or subnet? | 20:05 |
| PaulCzar | namespace | 20:08 |
| PaulCzar | running it in the dhcp namespace my node connects and manages to get pxelinux.0 | 20:11 |
| PaulCzar | but then it fails: unable to location configuration file | 20:12 |
| PaulCzar | locate even | 20:12 |
| NobodyCam | PaulCzar: do you have a map file in the tftp dir | 20:13 |
| PaulCzar | hmmm no ? | 20:14 |
| PaulCzar | does ironic create that ? | 20:14 |
| NobodyCam | no we don't I thought we landed a patch that added that to the doc's but I'm not seeing it | 20:16 |
| PaulCzar | that'd do it | 20:16 |
| NobodyCam | PaulCzar: https://github.com/openstack/tripleo-image-elements/blob/master/elements/ironic-conductor/install.d/69-ironic-tftp-support#L42-L43 | 20:17 |
| victor_lowther | yay, more comments on the spec! | 20:20 |
| NobodyCam | rloo: (or anyone) am I nuts did we not add a patch to the docs about the tftp map file? | 20:21 |
| jroll | I swear it was there | 20:21 |
| *** ChuckC has quit IRC | 20:21 | |
| * NobodyCam thinks a dependent service quick config ref page may be a good thing | 20:22 | |
| rloo | i thought there was something... looking... | 20:22 |
| PaulCzar | NobodyCam: I run it with the map file and now it can't find pxelinux.0 | 20:23 |
| *** Masahiro has joined #openstack-ironic | 20:23 | |
| *** Nisha has quit IRC | 20:24 | |
| NobodyCam | oh joy | 20:24 |
| NobodyCam | anything in the log about where it's looking | 20:24 |
| *** dprince has joined #openstack-ironic | 20:24 | |
| rloo | sorry NobodyCam; I don't see anything about a map file :-( | 20:27 |
| *** Masahiro has quit IRC | 20:28 | |
| NobodyCam | ya | 20:30 |
| NobodyCam | oh well I guess I'm just going crazy :-p | 20:31 |
| PaulCzar | NobodyCam: okay ... if I run it without --secure ( because security is for chumps ) and the mapfile it works | 20:33 |
| PaulCzar | something to do with absolute symlinks | 20:33 |
| PaulCzar | so it boots up to a initramfs) prompt | 20:36 |
| PaulCzar | so that's closer | 20:36 |
| NobodyCam | PaulCzar: are you running selunix or apparmor or other such | 20:36 |
| PaulCzar | on the host ? | 20:37 |
| NobodyCam | tftp host | 20:37 |
| PaulCzar | its a fairly standard ubuntu so I think its got apparmor | 20:38 |
| NobodyCam | oh brb ... fresh coffee is ready | 20:38 |
| *** mrda-away is now known as mrda | 20:38 | |
| mrda | Morning Ironic | 20:38 |
| NobodyCam | PaulCzar: ack was just thinking of what would block access to files | 20:38 |
| NobodyCam | morning mrda | 20:39 |
| PaulCzar | NobodyCam: its a tftp thing | 20:39 |
| PaulCzar | when in secure mode it doesn't allow following symlinks outside of the /tftpdirectory ... apparently absolute symlinks makes it think they're outside | 20:40 |
| PaulCzar | Ironically ( NOOO ) I found info on it here - https://bugs.launchpad.net/ironic/+bug/1280267 | 20:42 |
| NobodyCam | PaulCzar: yep | 20:45 |
| *** penick has joined #openstack-ironic | 20:52 | |
| *** igordcard has joined #openstack-ironic | 21:11 | |
| *** Marga_ has quit IRC | 21:11 | |
| *** arif-ali has quit IRC | 21:11 | |
| *** Marga_ has joined #openstack-ironic | 21:12 | |
| openstackgerrit | Chris Krelle proposed openstack/ironic: Add info on creating a tftp map file https://review.openstack.org/138864 | 21:12 |
| *** arif-ali has joined #openstack-ironic | 21:13 | |
| *** igordcard has quit IRC | 21:14 | |
| *** Marga_ has quit IRC | 21:17 | |
| *** ryanpetrello has joined #openstack-ironic | 21:18 | |
| *** Marga_ has joined #openstack-ironic | 21:18 | |
| *** ChuckC has joined #openstack-ironic | 21:18 | |
| jroll | devananda: NobodyCam: found a super interesting thing :)/b 80 | 21:24 |
| jroll | gahhhhhhh | 21:24 |
| NobodyCam | bingo | 21:24 |
| jroll | anyway | 21:24 |
| jroll | https://github.com/openstack/nova/blob/master/nova/scheduler/filter_scheduler.py#L265-273 | 21:24 |
| NobodyCam | its a fun game but I tend to like video games better | 21:24 |
| jroll | default is 1. | 21:24 |
| jroll | those are ordered in the same order they come back from ironic | 21:25 |
| jroll | which tends to be the same | 21:25 |
| jroll | so you're picking the first available, every time | 21:25 |
| jroll | if your servers have shorter cycle times, some will be used much more often than others | 21:25 |
| NobodyCam | ahh the old add a new node to casdranda and watch it fall over issue | 21:26 |
| NobodyCam | :-p | 21:26 |
| jroll | lol | 21:26 |
| jroll | basically | 21:26 |
| JayF | NobodyCam: you know they fixed that with vnodes in cass =>2 | 21:27 |
| NobodyCam | :) | 21:27 |
| openstackgerrit | OpenStack Proposal Bot proposed openstack/ironic-python-agent: Updated from global requirements https://review.openstack.org/135964 | 21:36 |
| jroll | ^ funny how it produces a new patchset even when it doesn't change anything, all 4 patchsets there are the same | 21:39 |
| * devananda steps away for a while | 21:39 | |
| *** alexpilotti has quit IRC | 21:40 | |
| rloo | ouch, forgot to ask devananda. NobodyCam, wrt that nova bug https://bugs.launchpad.net/nova/+bug/1379373 | 21:41 |
| rloo | NobodyCam: any idea whether/how long we want to support/proxy nova BM API? | 21:42 |
| JayF | jroll: ^ if you wanna land those reqs, I just +2'd it | 21:42 |
| jroll | JayF: waiting for tests, yo | 21:43 |
| *** Marga_ has quit IRC | 21:43 | |
| JayF | jroll: nothing changed since patch set 3 ? | 21:43 |
| jroll | JayF: yeah, still | 21:43 |
| jroll | idk, you're the one that taught me to wait :P | 21:43 |
| *** Marga_ has joined #openstack-ironic | 21:43 | |
| jroll | +A | 21:43 |
| *** Marga_ has quit IRC | 21:44 | |
| *** Marga_ has joined #openstack-ironic | 21:44 | |
| *** jgrimm is now known as zz_jgrimm | 21:46 | |
| NobodyCam | rloo: I'm not sure | 21:48 |
| NobodyCam | but I have a question posted on that bug | 21:48 |
| rloo | NobodyCam: ok. I didn't actually look in detail at that bug, but it seems like if/how we address it might have to do with what support if any, we provide. | 21:48 |
| *** Marga_ has quit IRC | 21:48 | |
| *** Marga__ has joined #openstack-ironic | 21:48 | |
| *** dprince has quit IRC | 21:49 | |
| *** Marga__ has quit IRC | 21:50 | |
| NobodyCam | rloo: I believe that error came from a mis config, user still has baremetal driver.. but i'm not 100% sure | 21:50 |
| rloo | NobodyCam: so eg, if you take master/nova, there is no BM code there. So should a 'nova baremetal-show-whatever' proxy to ironic if ironic is running? Or should it just return an error. | 21:50 |
| NobodyCam | but ya | 21:50 |
| *** Marga_ has joined #openstack-ironic | 21:50 | |
| NobodyCam | rloo: thats really a question for nova | 21:50 |
| NobodyCam | they were conserned about backwards compablity issues | 21:51 |
| *** Marga_ has quit IRC | 21:52 | |
| jroll | I think what they're concerned about | 21:52 |
| jroll | is what happens when someone runs a baremetal client command | 21:52 |
| *** Marga_ has joined #openstack-ironic | 21:52 | |
| jroll | against nova that doesn't have that | 21:52 |
| jroll | that being baremetal | 21:52 |
| jroll | because people may upgrade clients without upgrading nova | 21:53 |
| NobodyCam | ya | 21:53 |
| rloo | NobodyCam: did you see jogo's comment in the bug (and in IRC earlier today) about whether we still need nova/api/openstack/compute/contrib/baremetal_nodes.py? | 21:53 |
| *** andreykurilin_ has joined #openstack-ironic | 21:53 | |
| rloo | NobodyCam: without that extension, there is no proxying. | 21:53 |
| *** andreykurilin__ has quit IRC | 21:53 | |
| NobodyCam | yea | 21:53 |
| NobodyCam | Thats the file we hacked in the proxying support into | 21:54 |
| rloo | so if he's good with deleting it and another nova core is good with it, i'm fine with it too. but... i'm not sure what the 'right' thing might be. | 21:54 |
| rloo | I think since BM code is gone, it makes sense to get rid of the proxying too. | 21:55 |
| NobodyCam | I would point every thing at https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/contrib/baremetal_nodes.py#L95 | 21:56 |
| NobodyCam | fo a cycle | 21:56 |
| *** penick has quit IRC | 21:57 | |
| rloo | NobodyCam: ooo, that's a good idea (if we agree we don't want to proxy) | 21:57 |
| NobodyCam | but thats really up to the nova folk | 21:57 |
| rloo | NobodyCam: ok, jogo wanted to know what devananda thought, but I forgot to ask him. He'll be back though;) | 21:58 |
| *** Marga_ has quit IRC | 22:02 | |
| *** Marga_ has joined #openstack-ironic | 22:02 | |
| jjohnson2 | Well, I got it to the point of sending a bad RAKP2 packet | 22:03 |
| openstackgerrit | Jarrod Johnson proposed stackforge/pyghmi: Implement server side IPMI protocol (WIP) https://review.openstack.org/138109 | 22:03 |
| jjohnson2 | and now it is time to vacation for a while.. | 22:03 |
| NobodyCam | jjohnson2: :) so we'll see you next year? | 22:04 |
| jjohnson2 | January 5th is my return date | 22:04 |
| NobodyCam | have a great time away | 22:04 |
| jjohnson2 | between vacation and comp time, I have a good time to spend | 22:04 |
| NobodyCam | :) | 22:04 |
| jjohnson2 | NobodyCam, but after fixing rakp2, then all that's needed is one more function before easy street | 22:05 |
| jjohnson2 | oh I'm dumb... | 22:05 |
| NobodyCam | :) jjohnson2 thank you so much for this | 22:05 |
| *** Marga_ has quit IRC | 22:06 | |
| jjohnson2 | rakp2 is fine | 22:06 |
| jjohnson2 | I was actually using the wrong password... | 22:06 |
| jjohnson2 | so it legitimately bounced me | 22:06 |
| *** Marga_ has joined #openstack-ironic | 22:06 | |
| *** penick has joined #openstack-ironic | 22:06 | |
| NobodyCam | d'oh | 22:06 |
| jjohnson2 | myserver = sin.IpmiServer({'USERID': 'password'}) | 22:06 |
| jjohnson2 | import pyghmi.ipmi.private.serversession as sin | 22:07 |
| jjohnson2 | import pyghmi.ipmi.private.session as sess | 22:07 |
| jjohnson2 | then loop on sess.Session.wait_for_rsp(30) | 22:07 |
| jjohnson2 | has been my test harness | 22:07 |
| jjohnson2 | but oh well, rakp3 handling is next | 22:07 |
| jjohnson2 | but my implementation is good enough for an attacker to offline attack the user password, so it's well on its way to a proper ipmi implementation | 22:08 |
| NobodyCam | jjohnson2: are you adding cypher zero support :-p | 22:08 |
| jjohnson2 | nope | 22:08 |
| NobodyCam | j/k | 22:08 |
| jjohnson2 | cipher 0 does not work | 22:08 |
| jjohnson2 | null usernames, also don't work | 22:08 |
| jjohnson2 | you shall have a username, it shall be ipmi 2, and screw cipher suite 0 | 22:09 |
| jjohnson2 | support for cipher suites 2 and whatever the sha256 numbers would come after first pass | 22:09 |
| NobodyCam | ++ :) | 22:09 |
| jjohnson2 | pretty easy to add, but ipmitool doesn't use those by default and neither does pyghmi | 22:09 |
| jjohnson2 | # ipmitool -I lanplus -U USERID -P password -L Administrator+ -H 127.0.0.1 | 22:10 |
| jjohnson2 | > Error: no response from RAKP 3 message | 22:10 |
| jjohnson2 | that's where the virtual bmc gets to so far | 22:10 |
| NobodyCam | thats a lot more then my initial attempt got | 22:10 |
| jjohnson2 | hmm, and needs adminstrator+, I might be acting like an old intel bmc | 22:10 |
| jjohnson2 | all fun for the new yew | 22:10 |
| jjohnson2 | year | 22:10 |
| NobodyCam | :) | 22:11 |
| jjohnson2 | wasn't as bad once I actually started working on it | 22:11 |
| *** Marga_ has quit IRC | 22:12 | |
| *** Masahiro has joined #openstack-ironic | 22:12 | |
| NobodyCam | jjohnson2: this will advance our testing big time. | 22:12 |
| *** Marga_ has joined #openstack-ironic | 22:12 | |
| NobodyCam | so many many thank you's from me | 22:13 |
| jjohnson2 | well, hopefully you remain patient | 22:13 |
| jjohnson2 | and I'll party down for a few weeks | 22:13 |
| NobodyCam | :) | 22:13 |
| NobodyCam | have a great time jjohnson2 :) | 22:14 |
| * NobodyCam will brb | 22:14 | |
| *** Marga_ has quit IRC | 22:15 | |
| *** Marga_ has joined #openstack-ironic | 22:15 | |
| *** Marga_ has quit IRC | 22:16 | |
| *** Marga_ has joined #openstack-ironic | 22:16 | |
| rloo | jjohnson2: are you actually leaving your house? | 22:16 |
| *** Masahiro has quit IRC | 22:17 | |
| jjohnson2 | rloo, I'll be going all the way to half way across the state, big travel in my terms | 22:17 |
| rloo | WOW! good for you jjohnson2! | 22:17 |
| openstackgerrit | Merged openstack/ironic-python-agent: Updated from global requirements https://review.openstack.org/135964 | 22:17 |
| *** jjohnson2 has quit IRC | 22:23 | |
| *** Marga_ has quit IRC | 22:27 | |
| *** Marga_ has joined #openstack-ironic | 22:27 | |
| *** penick has quit IRC | 22:35 | |
| *** penick has joined #openstack-ironic | 22:36 | |
| *** penick has quit IRC | 22:36 | |
| *** penick has joined #openstack-ironic | 22:38 | |
| *** davideagnello has quit IRC | 22:41 | |
| *** davideagnello has joined #openstack-ironic | 22:43 | |
| *** krtaylor has quit IRC | 22:52 | |
| *** Marga_ has quit IRC | 22:52 | |
| *** Marga_ has joined #openstack-ironic | 22:53 | |
| *** mjturek has quit IRC | 23:04 | |
| *** krtaylor has joined #openstack-ironic | 23:04 | |
| *** penick has quit IRC | 23:06 | |
| *** pcrews has quit IRC | 23:13 | |
| *** erwan_taf has quit IRC | 23:16 | |
| *** romcheg1 has quit IRC | 23:19 | |
| *** jjohnson2 has joined #openstack-ironic | 23:20 | |
| *** naohirot has joined #openstack-ironic | 23:23 | |
| *** igordcard has joined #openstack-ironic | 23:24 | |
| *** ryanpetrello has quit IRC | 23:24 | |
| Haomeng | morning Ironic:) | 23:26 |
| NobodyCam | morning Haomeng :) | 23:27 |
| Haomeng | NobodyCam: :) | 23:27 |
| NobodyCam | :) | 23:28 |
| *** penick has joined #openstack-ironic | 23:31 | |
| NobodyCam | w00 h00 actually was able to help someone in the internal ironic channel :) | 23:33 |
| JayF | why do you have an internal ironic channel :( | 23:33 |
| NobodyCam | :-p no-one is ever in it ... | 23:34 |
| * jroll looks at his internal ironic channel | 23:34 | |
| NobodyCam | lol | 23:34 |
| JayF | jroll: I don't see any ironic channel, just a place where dentists hang out to talk about teeth <.< >.> | 23:34 |
| jroll | to be fair, we push people this way if it's not an internal question :P | 23:34 |
| jroll | lol | 23:34 |
| NobodyCam | JayF: internal support of corp folks | 23:34 |
| *** jjohnson2 has quit IRC | 23:35 | |
| NobodyCam | many dont have outside IRc access | 23:35 |
| jroll | ah yeah | 23:35 |
| JayF | I'm mainly just poking fun :) We do redirect non-internal questions to here, even if we end up answering them | 23:37 |
| NobodyCam | :) I do try but for many its a real pain to access freenode | 23:39 |
| NobodyCam | so we have a "hipChat" channel | 23:39 |
| jroll | port 443 ftw | 23:40 |
| jroll | hipchat isn't too bad really | 23:40 |
| NobodyCam | i (actually) like the client | 23:40 |
| NobodyCam | support last line editing with s/a/b/ | 23:40 |
| *** ryanpetrello has joined #openstack-ironic | 23:51 | |
| naohirot | good morning ironic | 23:53 |
| mrda | morning naohirot | 23:53 |
| NobodyCam | morning naohirot | 23:53 |
| naohirot | Haomeng: goodmorning | 23:53 |
| mrda | morning Haomeng | 23:53 |
| NobodyCam | PaulCzar: got it all working? | 23:53 |
| Haomeng | naohirot: Good Morning, naohirot:) | 23:53 |
| Haomeng | mrda: Good morning, mrda:) | 23:53 |
| naohirot | mrda: NobodyCam: good evening | 23:54 |
| naohirot | mrda: are you in US right? | 23:54 |
| mrda | naohirot: No, Australia | 23:54 |
| naohirot | mrda: Oh really, same time zone! | 23:55 |
| mrda | naohirot: very close :) | 23:55 |
| *** cohn has joined #openstack-ironic | 23:55 | |
| naohirot | mrda: Year, almost same :-) | 23:55 |
| naohirot | jroll: JayF: good evening | 23:56 |
| jroll | hi there naohirot | 23:56 |
| naohirot | s/Year/Yeah/ :) | 23:56 |
| spandhe | anybody here tried ipxe yet? | 23:56 |
| NobodyCam | hi spandhe, I believe several folks have used it | 23:57 |
| JayF | hiya | 23:58 |
| spandhe | NobodyCam: awesome! :) I am trying to understand the ipxe config template format.. | 23:58 |
| spandhe | any idea why every option has boot in the end? | 23:58 |
| NobodyCam | so it boots | 23:59 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!
