| *** naohirot has joined #openstack-ironic | 00:01 | |
| *** Marga_ has quit IRC | 00:02 | |
| *** ijw has quit IRC | 00:03 | |
| *** yuanying has quit IRC | 00:04 | |
| *** yuanying has joined #openstack-ironic | 00:09 | |
| *** r-daneel has quit IRC | 00:24 | |
| *** saripurigopi has joined #openstack-ironic | 00:28 | |
| egon | l | 00:34 |
|---|---|---|
| *** saripurigopi has quit IRC | 00:36 | |
| *** saripurigopi has joined #openstack-ironic | 00:39 | |
| *** rloo has quit IRC | 00:43 | |
| *** kkoski has joined #openstack-ironic | 00:46 | |
| *** Marga_ has joined #openstack-ironic | 00:47 | |
| *** yuanying_ has joined #openstack-ironic | 00:50 | |
| *** Marga_ has quit IRC | 00:52 | |
| *** yuanying has quit IRC | 00:53 | |
| *** Marga_ has joined #openstack-ironic | 00:53 | |
| *** thrash is now known as thrash|g0ne | 00:54 | |
| *** Marga_ has quit IRC | 01:03 | |
| *** achanda has quit IRC | 01:10 | |
| mgagne | is there a way to tell a driver to always include some values in the extra or driver_info field? | 01:18 |
| mgagne | looking at the vendor interface now, thanks! | 01:21 |
| *** chenglch has joined #openstack-ironic | 01:24 | |
| *** Sukhdev has quit IRC | 01:34 | |
| *** jxiaobin has joined #openstack-ironic | 01:36 | |
| *** saripurigopi has quit IRC | 01:49 | |
| *** kkoski has quit IRC | 01:57 | |
| *** kkoski has joined #openstack-ironic | 01:58 | |
| *** kkoski has quit IRC | 02:09 | |
| *** achanda has joined #openstack-ironic | 02:10 | |
| *** achanda has quit IRC | 02:17 | |
| *** harlowja is now known as harlowja_away | 02:17 | |
| *** kkoski has joined #openstack-ironic | 02:33 | |
| *** davideagnello has quit IRC | 02:42 | |
| *** ramineni has joined #openstack-ironic | 02:43 | |
| *** kkoski has quit IRC | 03:03 | |
| *** achanda has joined #openstack-ironic | 03:13 | |
| *** Sukhdev has joined #openstack-ironic | 03:17 | |
| *** achanda has quit IRC | 03:17 | |
| *** Nisha has joined #openstack-ironic | 03:37 | |
| *** tiagogomes has quit IRC | 03:37 | |
| *** tiagogomes has joined #openstack-ironic | 03:37 | |
| *** achanda has joined #openstack-ironic | 03:49 | |
| *** saripurigopi has joined #openstack-ironic | 03:54 | |
| openstackgerrit | Shivanand Tendulker proposed openstack/ironic: grub2 bootloader support for uefi boot mode https://review.openstack.org/166192 | 03:57 |
| openstackgerrit | Shivanand Tendulker proposed openstack/ironic: Secure boot support for pxe_ilo driver https://review.openstack.org/154808 | 03:58 |
| *** krtaylor has quit IRC | 04:07 | |
| *** krtaylor has joined #openstack-ironic | 04:10 | |
| *** davideagnello has joined #openstack-ironic | 04:30 | |
| *** davideagnello has quit IRC | 04:35 | |
| openstackgerrit | Michael Davies proposed openstack/python-ironicclient: Cache negotiated api microversion for this server https://review.openstack.org/173674 | 04:49 |
| *** achanda has quit IRC | 04:50 | |
| *** achanda has joined #openstack-ironic | 04:50 | |
| *** yog has joined #openstack-ironic | 05:11 | |
| *** yog is now known as Guest36614 | 05:11 | |
| *** Sukhdev has quit IRC | 05:17 | |
| saripurigopi | How to check whether BP is implemented or not, I'm looking at https://review.openstack.org/#/c/135899/ RAID interface | 05:28 |
| ramineni | saripurigopi: you can check the bp status - https://blueprints.launchpad.net/ironic/+spec/ironic-generic-raid-interface | 05:29 |
| ramineni | saripurigopi: Its in code review stage | 05:30 |
| saripurigopi | ramineni: got it, thank you. can I submit bp which is dependent on this implementation? | 05:31 |
| ramineni | saripurigopi: yes, you can do that | 05:31 |
| saripurigopi | ramineni: cool, thank you. | 05:32 |
| ramineni | saripurigopi: you need a spec for it though, which states its depending on the generic implementation | 05:32 |
| saripurigopi | ramineni: okay. | 05:34 |
| saripurigopi | Is there interface to auto discover nodes based on some qualification? | 05:36 |
| *** ukalifon has joined #openstack-ironic | 05:59 | |
| *** Haomeng|2 has joined #openstack-ironic | 06:01 | |
| *** Haomeng has quit IRC | 06:04 | |
| openstackgerrit | jxiaobin proposed openstack/ironic-specs: Mount config drive as loop device to supply data to cloud-init https://review.openstack.org/173142 | 06:08 |
| *** alex_xu has quit IRC | 06:18 | |
| *** jcoufal has joined #openstack-ironic | 06:29 | |
| *** alex_xu has joined #openstack-ironic | 06:30 | |
| *** mgoddard has quit IRC | 06:40 | |
| *** mgoddard has joined #openstack-ironic | 06:41 | |
| *** achanda has quit IRC | 06:48 | |
| *** dtantsur|afk is now known as dtantsur | 07:06 | |
| dtantsur | Morning! | 07:06 |
| Haomeng|2 | good morning dtantsur! | 07:07 |
| dtantsur | o/ | 07:08 |
| pshige | dtantsur: morning | 07:08 |
| *** rwsu has quit IRC | 07:09 | |
| mrda | hi dtantsur, Haomeng|2, pshige | 07:11 |
| pshige | haomeng|2, mrda: morning | 07:14 |
| *** a1exhughe5 has joined #openstack-ironic | 07:21 | |
| Nisha | dtantsur, morning | 07:21 |
| pshige | Nisha: morning :) | 07:22 |
| Nisha | pshige, morning :) | 07:22 |
| *** jistr has joined #openstack-ironic | 07:24 | |
| Haomeng|2 | mrda, pshige, morning:) | 07:28 |
| *** ifarkas has joined #openstack-ironic | 07:32 | |
| *** chlong has quit IRC | 07:35 | |
| openstackgerrit | Michael Davies proposed openstack/python-ironicclient: Cache negotiated api microversion for this server https://review.openstack.org/173674 | 07:37 |
| *** rameshg87 has joined #openstack-ironic | 07:42 | |
| rameshg87 | good afternoon ironic | 07:42 |
| *** bkero has joined #openstack-ironic | 07:58 | |
| *** rameshg87 is now known as rameshg87-lunch | 08:05 | |
| *** pas-ha has joined #openstack-ironic | 08:06 | |
| *** viktors has joined #openstack-ironic | 08:08 | |
| *** davideagnello has joined #openstack-ironic | 08:08 | |
| *** romcheg has joined #openstack-ironic | 08:13 | |
| *** davideagnello has quit IRC | 08:13 | |
| *** Nisha has quit IRC | 08:14 | |
| *** Nisha has joined #openstack-ironic | 08:14 | |
| *** lucasagomes has joined #openstack-ironic | 08:17 | |
| *** ndipanov has joined #openstack-ironic | 08:27 | |
| *** rameshg87-lunch is now known as rameshg87 | 08:33 | |
| *** dtantsur is now known as dtantsur|brb | 08:37 | |
| openstackgerrit | Haomeng,Wang proposed openstack/ironic: supports alembic migration for db2 https://review.openstack.org/173721 | 08:38 |
| *** Nisha has quit IRC | 08:47 | |
| openstackgerrit | Lucas Alvares Gomes proposed openstack/ironic-specs: New stateless iPXE driver https://review.openstack.org/130812 | 08:47 |
| *** a1exhughe5 has quit IRC | 08:48 | |
| *** a1exhughe5 has joined #openstack-ironic | 08:49 | |
| *** rameshg87 has quit IRC | 08:49 | |
| *** pelix has joined #openstack-ironic | 08:50 | |
| *** rameshg87 has joined #openstack-ironic | 08:50 | |
| openstackgerrit | Merged openstack/ironic-specs: Add pxe_ucs driver spec for liberty https://review.openstack.org/173271 | 08:51 |
| openstackgerrit | IWAMOTO Toshihiro proposed openstack/ironic-specs: Collect IPA logs https://review.openstack.org/168799 | 08:54 |
| *** krtaylor has quit IRC | 08:57 | |
| rameshg87 | lucasagomes: hello | 08:58 |
| lucasagomes | rameshg87, hi there | 08:58 |
| rameshg87 | lucasagomes: the specs https://review.openstack.org/#/c/130812/ and https://review.openstack.org/#/c/134865/ ideally are suited as a new implementation of boot interface | 08:59 |
| rameshg87 | lucasagomes: we have the boot interface thing as one of priority items for kilo | 09:00 |
| lucasagomes | virtual media deploy? | 09:00 |
| rameshg87 | lucasagomes: yeah | 09:00 |
| lucasagomes | right yeah, but didn't finish that :-( | 09:00 |
| rameshg87 | lucasagomes: i meant boot interface thing as one of priority items for liberty | 09:00 |
| rameshg87 | sorry | 09:01 |
| rameshg87 | lucasagomes: i hope ipxe also fits in better as a new boot interface implementation | 09:01 |
| lucasagomes | rameshg87, yeah it would :-) | 09:01 |
| rameshg87 | lucasagomes: but i am not sure how it can be prioritized | 09:02 |
| lucasagomes | I think we do have it as a priority as per devananda email for PTL | 09:02 |
| rameshg87 | yeah | 09:02 |
| lucasagomes | he mentions that | 09:02 |
| rameshg87 | lucasagomes: so does it make sense for https://review.openstack.org/#/c/130812/ and https://review.openstack.org/#/c/134865/ to be proposed as a new boot interface instead ? | 09:02 |
| lucasagomes | depending on the new boot interface? | 09:02 |
| openstackgerrit | Naohiro Tamura proposed openstack/ironic: Add iRMC Virtual Media Deploy module for iRMC Driver https://review.openstack.org/151958 | 09:02 |
| lucasagomes | or as it? | 09:02 |
| lucasagomes | cause they r different work | 09:03 |
| rameshg87 | yeah i meant depending on new boot interface | 09:03 |
| lucasagomes | do we have a spec for the new boot interface? | 09:03 |
| rameshg87 | lucasagomes: https://review.openstack.org/#/c/168698/ | 09:03 |
| lucasagomes | or we are just doing it? cause to be honest iPXE doesn't depend on that... I just need a driver vendor passthru endpoint | 09:03 |
| lucasagomes | cool | 09:04 |
| lucasagomes | we can align things for sure | 09:04 |
| rameshg87 | lucasagomes: yeah | 09:04 |
| *** krtaylor has joined #openstack-ironic | 09:04 | |
| rameshg87 | lucasagomes: i had some rough POCs as well | 09:04 |
| lucasagomes | cool | 09:04 |
| rameshg87 | lucasagomes: see references | 09:04 |
| lucasagomes | will take a look | 09:04 |
| rameshg87 | lucasagomes: it's not exactly according to spec | 09:04 |
| rameshg87 | lucasagomes: but working ones | 09:04 |
| rameshg87 | okay, let me know what you think after having a look :) | 09:05 |
| *** Marga_ has joined #openstack-ironic | 09:06 | |
| *** athomas has quit IRC | 09:07 | |
| *** athomas has joined #openstack-ironic | 09:08 | |
| lucasagomes | rameshg87, will do, I'm finishing reviewing another patch | 09:10 |
| rameshg87 | lucasagomes: sure..thanks | 09:13 |
| *** pas-ha has quit IRC | 09:18 | |
| *** pas-ha has joined #openstack-ironic | 09:21 | |
| *** derekh has joined #openstack-ironic | 09:25 | |
| *** Marga_ has quit IRC | 09:28 | |
| *** Marga_ has joined #openstack-ironic | 09:29 | |
| *** ukalifon has quit IRC | 09:45 | |
| *** jamielennox is now known as jamielennox|away | 09:52 | |
| *** ukalifon has joined #openstack-ironic | 09:58 | |
| *** naohirot has quit IRC | 10:00 | |
| *** chenglch has quit IRC | 10:03 | |
| *** dtantsur|brb is now known as dtantsur | 10:10 | |
| *** ukalifon has quit IRC | 10:17 | |
| *** ukalifon has joined #openstack-ironic | 10:18 | |
| *** achanda has joined #openstack-ironic | 10:22 | |
| *** ukalifon has quit IRC | 10:26 | |
| *** ukalifon has joined #openstack-ironic | 10:26 | |
| *** jcoufal has quit IRC | 10:27 | |
| *** achanda has quit IRC | 10:27 | |
| *** jcoufal has joined #openstack-ironic | 10:27 | |
| rameshg87 | folks, anyone face the below issue ? | 10:30 |
| rameshg87 | i run stack.sh with enabling ironic and virt driver as ironic | 10:30 |
| rameshg87 | the nova-compute ironic virt driver gets started first (n-cpu) and then tries to contact the ironic-api service and retries 60 times | 10:31 |
| rameshg87 | ir-api and ir-cond doesn't come up by that time and n-cpu dies | 10:31 |
| vdrok | rameshg87, yup, had this issue | 10:32 |
| vdrok | rameshg87, morning | 10:32 |
| rameshg87 | later on after starting ir-api and ir-cond, ironic waits for the nova-hypervisor stats to appear | 10:32 |
| rameshg87 | vdrok: morning :) | 10:32 |
| rameshg87 | and fails | 10:32 |
| rameshg87 | vdrok: did you increase the retry count ? | 10:32 |
| vdrok | rameshg87, this one helps | 10:32 |
| vdrok | rameshg87, https://review.openstack.org/#/c/171406/ | 10:32 |
| rameshg87 | vdrok: oh okay | 10:32 |
| vdrok | rameshg87, well you could increase retry count but it doesn't seem right :0 | 10:33 |
| rameshg87 | vdrok: but this issue may come up at some point of time later on due to some other reason | 10:33 |
| rameshg87 | vdrok: i think we should restart n-cpu if it's not running after enrolling the nodes | 10:33 |
| rameshg87 | vdrok: wdyt ? | 10:33 |
| * rameshg87 fetches the devstack patch | 10:33 | |
| vdrok | rameshg87, in this case restarting n-cpu makes sense, but not sure that we should do that in general | 10:35 |
| rameshg87 | vdrok: yeah, may be when we see nova-compute is not running ? | 10:36 |
| lucasagomes | rameshg87, there's this here as well https://review.openstack.org/#/c/171313/ | 10:36 |
| lucasagomes | perhaps we should bump that default in the Ironic driver | 10:36 |
| rameshg87 | oh :) | 10:37 |
| * rameshg87 realises everyone has faced this issue before | 10:37 | |
| rameshg87 | so really there are multiple ways to solve this | 10:38 |
| rameshg87 | i just tried adding stop_nova_compute and start_nova_compute before we wait for hypervisor stats, but doesn't work straight away | 10:38 |
| rameshg87 | stop_*() fails stack.sh if it is not running | 10:39 |
| rameshg87 | let me try this ... | 10:39 |
| vdrok | rameshg87, lucasagomes, in this case when n-cert is disabled difference between failing n-cpu and starting ir-cond may be long (like 5 min) | 10:39 |
| vdrok | so I think increasing retries is not good for this case, seems that there is some other slowdown | 10:40 |
| rameshg87 | vdrok: yeah i felt same .. | 10:40 |
| lucasagomes | yeah, do we need to stop n-cpu if Ironic is not present? | 10:42 |
| lucasagomes | or should we just skip it, leave it dorment | 10:42 |
| lucasagomes | dormant* | 10:42 |
| rameshg87 | lucasagomes: yeah check if any process nova-compute is running, and then start it if it's not running | 10:43 |
| vdrok | ooh, and then there is this one https://review.openstack.org/#/c/173493/2 | 10:44 |
| vdrok | lots of ways to fix it :) | 10:44 |
| rameshg87 | yeah :) | 10:44 |
| rameshg87 | and then there is this: https://review.openstack.org/#/c/156887/7/lib/ironic (684-687) | 10:45 |
| rameshg87 | i am just testing it out | 10:45 |
| *** zhenguo has quit IRC | 10:48 | |
| rameshg87 | lucasagomes: just replied to your comment on https://review.openstack.org/#/c/168698/2/specs/liberty/new-boot-interface.rst | 10:50 |
| lucasagomes | rameshg87, we are not booting the same ramdisk always, specially for rescue | 10:51 |
| lucasagomes | rameshg87, for the rescue ramdisk we may not include any of the deploy bits | 10:52 |
| lucasagomes | in fact, I think that the RAX guys doesn't even use IPA for rescue | 10:52 |
| lucasagomes | it's yet another ramdisk | 10:52 |
| lucasagomes | jroll, JayF ^ | 10:52 |
| lucasagomes | rameshg87, https://github.com/rackerlabs/onmetal-rescue-agent/ | 10:52 |
| rameshg87 | lucasagomes: oh okay | 10:55 |
| lucasagomes | rameshg87, one could use the same ramdisk for everything, just by setting the same glance id for everything and all | 10:56 |
| lucasagomes | but it's important to have the flexibility of booting different stuff for different propouses | 10:56 |
| rameshg87 | lucasagomes: so what about deploy and cleaning ? | 10:57 |
| rameshg87 | lucasagomes: should we have this there too ? | 10:57 |
| lucasagomes | rescue mainly since the ramdisk should include a bunch of tools for troubeshooting that is not needed otherwise | 10:57 |
| lucasagomes | rameshg87, cleaning ? hmm I think it should. For cleaning right now we just boot the same ramdisk right? | 10:58 |
| *** ramineni has quit IRC | 10:58 | |
| rameshg87 | lucasagomes: yes | 10:58 |
| lucasagomes | perhaps for this first implementation we should just call the deploy methods in cleaning? | 10:59 |
| rameshg87 | lucasagomes: but i felt we might end up overloading the boot interface | 11:00 |
| rameshg87 | lucasagomes: i just thought of classifying it like this - either bare metal is always booted to something that ironic will use it for some operator | 11:00 |
| rameshg87 | or operations | 11:01 |
| rameshg87 | OR bare metal is booted to the deployed image for the user to use it | 11:01 |
| rameshg87 | always assumption seemed wrong - more flexibility is required there | 11:01 |
| lucasagomes | yeah it keeps things simple indeed | 11:01 |
| lucasagomes | yeah it will require more flexibility... hmm /me thinks | 11:02 |
| *** Marga_ has quit IRC | 11:02 | |
| lucasagomes | rameshg87, how it will works in code... the deploy interface will be in control over the boot interface right? | 11:05 |
| rameshg87 | lucasagomes: but if it still wanted deploy/cleaning to be different from rescue it can be possible, right ? | 11:05 |
| rameshg87 | lucasagomes: yes | 11:05 |
| lucasagomes | rameshg87, yeah I think it should... but let's think | 11:05 |
| lucasagomes | maybe we just need a generic method | 11:05 |
| lucasagomes | as you did in that spec | 11:05 |
| rameshg87 | lucasagomes: like this it will look: https://review.openstack.org/#/c/166513/4/ironic/drivers/modules/iscsi_deploy.py | 11:06 |
| lucasagomes | but the deploy interface must be aware about what is the boot interface | 11:06 |
| rameshg87 | it's not according to the spec | 11:06 |
| lucasagomes | rameshg87, will take a look | 11:06 |
| lucasagomes | I will need to step out a bit and grab something to eat quickly | 11:06 |
| rameshg87 | oh okay :) | 11:06 |
| rameshg87 | np, see you later, i should be around | 11:07 |
| rameshg87 | i am just removing "boot" from it | 11:07 |
| * lucasagomes is in the office today, will skip thursday | 11:07 | |
| lucasagomes | ack | 11:07 |
| openstackgerrit | Ramakrishnan G proposed openstack/ironic-specs: Add new boot interface in Ironic https://review.openstack.org/168698 | 11:09 |
| *** thrash|g0ne is now known as thrash | 11:12 | |
| *** yuanying_ has quit IRC | 11:21 | |
| *** rameshg87 is now known as rameshg87-away | 11:23 | |
| *** saripurigopi has quit IRC | 11:39 | |
| *** saripurigopi has joined #openstack-ironic | 11:46 | |
| *** davideagnello has joined #openstack-ironic | 11:46 | |
| *** davideagnello has quit IRC | 11:50 | |
| *** Haomeng has joined #openstack-ironic | 11:58 | |
| pshige | Is specs core meeting here in three hours? | 11:59 |
| dtantsur | specs core meeting? Oo | 12:00 |
| *** Haomeng|2 has quit IRC | 12:00 | |
| *** rameshg87-away has quit IRC | 12:01 | |
| pshige | https://wiki.openstack.org/wiki/Meetings/Ironic | 12:01 |
| pshige | the end of announcement | 12:01 |
| pshige | in Agenda for next meeting | 12:02 |
| dtantsur | communication rocks! | 12:02 |
| dtantsur | someone should be told about mailing list >_< | 12:02 |
| dtantsur | pshige, thanks! | 12:02 |
| pshige | dtantsur: thank you! | 12:03 |
| lucasagomes | dtantsur, it will collide with our meeting at 15UTC | 12:03 |
| dtantsur | yep | 12:03 |
| lucasagomes | I said that yesterday, so it's ok if we delay a bit | 12:04 |
| dtantsur | let's make sure that next time we have a ML announcement | 12:04 |
| *** arif-ali has quit IRC | 12:05 | |
| *** trown|outttypeww is now known as trown | 12:06 | |
| *** dprince has joined #openstack-ironic | 12:08 | |
| *** arif-ali has joined #openstack-ironic | 12:12 | |
| *** zhenguo has joined #openstack-ironic | 12:29 | |
| lucasagomes | dtantsur, +1 totally | 12:32 |
| lucasagomes | even because one of the IRC meetings happens at 3 am here :-) | 12:33 |
| *** saripurigopi has quit IRC | 12:35 | |
| openstackgerrit | Lucas Alvares Gomes proposed openstack/ironic: Troubleshoot: Do not power off node if deployment fail https://review.openstack.org/172932 | 12:36 |
| pshige | 3 am in Dublin! in 13 hours ... | 12:46 |
| openstackgerrit | Dmitry Tantsur proposed stackforge/ironic-discoverd: Bump version to 1.2.0 https://review.openstack.org/173807 | 12:53 |
| *** rloo has joined #openstack-ironic | 12:57 | |
| openstackgerrit | Zhenguo Niu proposed openstack/ironic: Add attempt of max retries to power state sync logs https://review.openstack.org/167122 | 13:00 |
| lucasagomes | pshige, :-D | 13:04 |
| lucasagomes | yeah... we are UTC +1 now | 13:04 |
| * lucasagomes likes Ireland's TZ | 13:04 | |
| * pshige likes Japan Standard Time (2218 JST now) | 13:18 | |
| * dtantsur likes Friday evening whatever time | 13:23 | |
| *** david-lyle has quit IRC | 13:24 | |
| pshige | dtantsur, :-D | 13:24 |
| NobodyCam | good morning says the man waiting on koffi | 13:28 |
| *** r-daneel has joined #openstack-ironic | 13:31 | |
| dtantsur | NobodyCam, morning | 13:33 |
| NobodyCam | morning dtantsur :) | 13:33 |
| pshige | NobodyCam: morning :) | 13:33 |
| NobodyCam | morning pshige :) | 13:34 |
| dtantsur | folks, I'd like to seriously discuss retrying HTTP 409 in our client. Getting all kind of http://paste.openstack.org/show/203982/ makes writing automation insane... | 13:34 |
| *** MattMan has quit IRC | 13:34 | |
| jlvillal | Good morning, dtantsur NobodyCam lucasagomes pshige and the rest of Ironic | 13:34 |
| dtantsur | jlvillal, morning | 13:35 |
| NobodyCam | mrorning jlvillal | 13:35 |
| NobodyCam | dtantsur: don't we already re-try most things in te client? | 13:35 |
| dtantsur | NobodyCam, looks like no | 13:35 |
| jlvillal | dtantsur, Makes sense to me to retry, if the 409 is a temporary state. | 13:35 |
| pshige | jlvillal: morning | 13:36 |
| NobodyCam | dtantsur: ya, I think that makes sense. ocf I will note that I have yet to ingest any coffee | 13:37 |
| * dtantsur does not risk opening IRC without the first cup | 13:39 | |
| *** Guest36614 has quit IRC | 13:41 | |
| *** mariojv has joined #openstack-ironic | 13:41 | |
| openstackgerrit | Merged stackforge/ironic-discoverd: Bump version to 1.2.0 https://review.openstack.org/173807 | 13:41 |
| *** MattMan has joined #openstack-ironic | 13:42 | |
| NobodyCam | hehehee | 13:44 |
| *** saripurigopi has joined #openstack-ironic | 13:44 | |
| lucasagomes | jlvillal, NobodyCam morning | 13:45 |
| NobodyCam | morning lucasagomes | 13:46 |
| NobodyCam | :) | 13:46 |
| *** mtanino has joined #openstack-ironic | 13:48 | |
| rloo | hi everyone | 13:49 |
| NobodyCam | good morning rloo :) | 13:49 |
| jlvillal | good morning rloo and again to lucasagomes :) | 13:50 |
| lucasagomes | rloo, morning | 13:50 |
| pshige | rloo: morning :) | 13:50 |
| rloo | morning NobodyCam, jlvillal. Hi lucasagomes, dtantsur, pshige. | 13:50 |
| dtantsur | rloo, morning | 13:50 |
| rloo | dtantsur: when does the client get a 409? | 13:50 |
| * jlvillal is looking forward to meeting the IRC people in person at the summit | 13:51 | |
| rloo | dtantsur: I don't see why we can't add some environment/option to the client, to retry? | 13:51 |
| dtantsur | rloo, I think we should | 13:51 |
| dtantsur | rloo, we get it on node-set-provision-state | 13:51 |
| dtantsur | nowadays you have to call this much more often :) | 13:51 |
| *** romcheg has quit IRC | 13:53 | |
| rloo | dtantsur: I guess it depends on how configurable it should be. retry only on 409, retry only on 409+node-set-provision-state, ... | 13:53 |
| dtantsur | rloo, I think it should be retry or don't retry, with retry being the default | 13:54 |
| rloo | dtantsur: i was wondering if the API folks have an opinion on that. Not that I've paid any attention to what they're doing. | 13:54 |
| dtantsur | rloo, we can default to "rety" for CLI and default to "as before" for API | 13:55 |
| rloo | dtantsur: maybe they only deal with api, not CLI. | 13:55 |
| rloo | dtantsur: oh, you want in both cli and api. | 13:55 |
| rloo | dtantsur: me thinks this may require a spec | 13:56 |
| dtantsur | rloo, hmm, are we talking about ironicclient API? I'm talking about it | 13:56 |
| *** kkoski has joined #openstack-ironic | 13:56 | |
| pshige | jlvilla: I will attend the summit ! | 13:56 |
| NobodyCam | pshige: awesome!!! | 13:57 |
| rloo | dtantsur: oh. the library. I was thinking of the actual http request. | 13:57 |
| dtantsur | maybe, but that's not my concern right now | 13:57 |
| rloo | did you see this patch for the client: https://review.openstack.org/#/c/173852/ | 13:58 |
| rloo | so we're going to have a kilo branch for the client, but we'll continue using the package versioning we've been using? | 13:59 |
| rloo | with the specs being moved from kilo to kilo-archive to liberty, how do people who know git, get the history of those files? eg https://github.com/openstack/ironic-specs/blob/master/specs/liberty/cisco-ucs-pxe-driver.rst? | 14:03 |
| jlvillal | pshige, Great! :) | 14:05 |
| openstackgerrit | Ruby Loo proposed openstack/ironic-specs: Remove placeholder for Liberty directory https://review.openstack.org/173893 | 14:06 |
| rloo | pshige, jlvillal: will be great to meet you face to face :-) | 14:07 |
| openstackgerrit | Ruby Loo proposed openstack/ironic-specs: Remove placeholder in Liberty directory https://review.openstack.org/173893 | 14:08 |
| NobodyCam | how log is "tox --e py27 -- test_pxe taking for folks? I'm getting Ran 87 tests in 151.053s | 14:08 |
| NobodyCam | but I think it ia ia test I added | 14:08 |
| NobodyCam | :-p but I think it is a test I added even | 14:09 |
| * NobodyCam goews back to coffee | 14:09 | |
| NobodyCam | :-p | 14:09 |
| rloo | NobodyCam: 1.708s for me | 14:10 |
| jlvillal | rloo, I don't understand your question about git and kilo, kilo-archive, and liberty | 14:10 |
| NobodyCam | yep its me :-p | 14:10 |
| rloo | jlvillal: git is funny, if you rename files. | 14:10 |
| rloo | jlvillal: if you look at that file I linked, what's the history of it? | 14:10 |
| jlvillal | rloo, One moment | 14:10 |
| *** zz_jgrimm is now known as jgrimm | 14:11 | |
| rloo | jlvillal: that file got moved from 'kilo' directory to 'kilo-archive' directory to 'liberty' directory | 14:11 |
| jlvillal | If I do this: git log --follow specs/liberty/cisco-ucs-pxe-driver.rst | 14:11 |
| jlvillal | I can see the rename | 14:11 |
| jlvillal | rloo, Without --follow I don't see the rename | 14:11 |
| rloo | jlvillal: I usually look at the history of a file, to get the patch/commit for changes to it | 14:11 |
| jlvillal | rloo, So you can see the history, but you have to use --follow | 14:12 |
| rloo | jlvillal: thx, I'll try it | 14:13 |
| jlvillal | rloo, You're welcome | 14:13 |
| *** saripurigopi has quit IRC | 14:14 | |
| *** saripurigopi has joined #openstack-ironic | 14:17 | |
| BadCub | Morning folks | 14:18 |
| dtantsur | BadCub, morning | 14:18 |
| NobodyCam | morning BadCub :) | 14:19 |
| rloo | jlvillal: do you really like how it looks? https://review.openstack.org/#/c/173427/ | 14:19 |
| *** achanda has joined #openstack-ironic | 14:20 | |
| pshige | BadCub: morning :) | 14:21 |
| rloo | hiya BadCub | 14:23 |
| pshige | I sat in the back row at the previous design summit, so I didn't chat with almost anyone here, except devananda. | 14:24 |
| *** achanda has quit IRC | 14:24 | |
| * dtantsur reapplied for visa yesterday and keeps fingers crossed | 14:25 | |
| lucasagomes | pshige, oh... let's talk more on the next summit then! | 14:26 |
| * BadCub returns with more coffee | 14:26 | |
| lucasagomes | BadCub, good morning :-) | 14:26 |
| BadCub | morning rloo, dtantsur NobodyCam pshige :) | 14:27 |
| BadCub | mornin lucasagomes | 14:27 |
| BadCub | :) | 14:27 |
| *** Marga_ has joined #openstack-ironic | 14:28 | |
| pshige | lucasagomes: yes, I'll be happy with that! | 14:31 |
| jlvillal | rloo, I like the new look | 14:31 |
| jlvillal | Because it helps differentiate the conditional from the action lines | 14:31 |
| jlvillal | dtantsur, you had to re-apply. Sorry if they denied first time :( | 14:32 |
| rloo | jlvillal: I agree with that, but I don't like it because the conditional stuff isn't aligned. I don't see why we need to enforce that look but if others want it, democracy rules. Or 2 dictators rule anyway ;) | 14:32 |
| jlvillal | rloo, But if the conditonal stuff is aligned then the action lines blend into the conditional. | 14:34 |
| *** achanda has joined #openstack-ironic | 14:34 | |
| rloo | jlvillal: it doesn't blend for me but i'm used to it. clearly, others think the way you do, otherwise that Ewhatever rule wouldn't exist. | 14:35 |
| jlvillal | rloo, So then you have to hunt around to find the colon to figure out where the conditional ends. | 14:35 |
| * jlvillal is upset that the Windows update has broken his laptop's video camera :( | 14:35 | |
| dtantsur | lucasagomes, do we really need a spec to: 1. bring https://github.com/openstack/nova/blob/master/nova/virt/ironic/client_wrapper.py#L104 to ironicclient; 2. use it when issuing shell commands? | 14:38 |
| lucasagomes | dtantsur, well maybe not a spec... unless we want to get some comments about the idea first | 14:38 |
| lucasagomes | it doesn't seem contradictory... so maybe just put a patch up for it? | 14:39 |
| jroll | morning $too_many_people_to_name :) | 14:41 |
| pshige | jroll: morning :) | 14:42 |
| jroll | BadCub: what time is this specs thing? | 14:42 |
| BadCub | jroll: 8 I beleive | 14:43 |
| pshige | In 16 mins | 14:43 |
| jroll | ok, I have another meeting then but I should be able to overlap some if it's just on irc | 14:43 |
| NobodyCam | morning jroll | 14:44 |
| *** achanda has quit IRC | 14:45 | |
| BadCub | I put a few topics on the pad for folks to ponder on too. https://etherpad.openstack.org/p/IronicSpecProcess | 14:49 |
| *** igordcard has quit IRC | 14:49 | |
| openstackgerrit | Nisha Agarwal proposed openstack/ironic: Update ilo drivers documentation for inspection https://review.openstack.org/170065 | 14:49 |
| BadCub | Some ideas that might make things less hectic | 14:50 |
| *** igordcard has joined #openstack-ironic | 14:50 | |
| BadCub | brb | 14:51 |
| *** smoriya has joined #openstack-ironic | 14:54 | |
| pshige | smoriya: good evening! | 14:55 |
| dtantsur | jroll, morning | 14:55 |
| smoriya | pshige: good evening :) | 14:55 |
| jroll | heya dtantsur :) | 14:56 |
| * BadCub returns | 14:59 | |
| * NobodyCam is here too | 15:00 | |
| *** rwsu has joined #openstack-ironic | 15:00 | |
| *** smoriya has quit IRC | 15:05 | |
| *** smoriya has joined #openstack-ironic | 15:06 | |
| NobodyCam | I'm adding my thoughts to the spec etherpad | 15:06 |
| BadCub | NobodyCam: cool, thank you :) | 15:07 |
| openstackgerrit | Zhenguo Niu proposed openstack/ironic: Cleanup some code in pxe.prepare https://review.openstack.org/173925 | 15:07 |
| jlvillal | Was there a meeting somewhere that started 9 minutes ago? I thought it was going to be here. | 15:09 |
| NobodyCam | jlvillal: I'm meeting | 15:09 |
| NobodyCam | lol I'm working on the etherpad | 15:10 |
| jlvillal | NobodyCam, Okay. I thought there was a discussion about specs going on. | 15:10 |
| *** ijw has joined #openstack-ironic | 15:10 | |
| pshige | comment authers cannot be seen on etherpad? | 15:10 |
| NobodyCam | I assume that will come as folks come up with idea's and questions | 15:10 |
| NobodyCam | pshige: I'm just adding my thoughts | 15:11 |
| NobodyCam | please add any ideas you have | 15:11 |
| pshige | I've already added my thoughs. | 15:12 |
| NobodyCam | pshige: on https://etherpad.openstack.org/p/IronicSpecProcess ??? | 15:12 |
| pshige | oh | 15:13 |
| pshige | I've added another etherpad .. > https://etherpad.openstack.org/p/liberty-ironic-design-summit-ideas | 15:14 |
| lucasagomes | r we having a hangout or something for the spec review stuff? | 15:14 |
| NobodyCam | lucasagomes: I think at this point we are putting down the ideas | 15:15 |
| lucasagomes | ok | 15:15 |
| NobodyCam | on how to review | 15:15 |
| NobodyCam | :-P | 15:15 |
| NobodyCam | we can start a hangout | 15:15 |
| BadCub | I am good with hangout | 15:16 |
| dtantsur | -0 for hangout, it's pretty exhausting... | 15:17 |
| *** athomas has quit IRC | 15:19 | |
| *** athomas has joined #openstack-ironic | 15:21 | |
| openstackgerrit | Nisha Agarwal proposed openstack/ironic: Update ilo drivers documentation for inspection https://review.openstack.org/170065 | 15:21 |
| *** jmanko has joined #openstack-ironic | 15:24 | |
| devananda | morning, all | 15:24 |
| BadCub | morning devananda | 15:24 |
| dtantsur | devananda, morning, you're a bit late for the party :D | 15:24 |
| pshige | devananda: morning :) | 15:24 |
| devananda | indeed. unexpected travel required pre-coffee this morning. | 15:24 |
| devananda | anyone care to dial me in? :) | 15:25 |
| BadCub | devananda: everyone is jotting down ideas on the questions/ideas I put on the pad for discussion right now | 15:25 |
| BadCub | devananda: https://etherpad.openstack.org/p/IronicSpecProcess | 15:25 |
| devananda | k k | 15:25 |
| *** jcoufal_ has joined #openstack-ironic | 15:26 | |
| *** jmank has quit IRC | 15:27 | |
| *** jrist has quit IRC | 15:27 | |
| *** jerryz has quit IRC | 15:28 | |
| lucasagomes | the specs priority there looks confusing | 15:28 |
| dtantsur | yeah | 15:28 |
| lucasagomes | ubber important == high prio | 15:28 |
| dtantsur | BadCub, what's the difference between High and Uber? | 15:28 |
| dtantsur | and why aren't they ordered? | 15:28 |
| lucasagomes | we like to and need = Med | 15:28 |
| lucasagomes | can we keep high/med/low only | 15:29 |
| lucasagomes | ? | 15:29 |
| lucasagomes | devananda, morning | 15:29 |
| BadCub | The specs listed under HIGH are already in LP as HIGH. I have not moved them up on the pad yet | 15:29 |
| dtantsur | will anyone cry if I delete 1st 3 sections? | 15:29 |
| NobodyCam | oh morning devananda :) | 15:29 |
| *** jcoufal has quit IRC | 15:29 | |
| dtantsur | BadCub, hmm, if you have some logic there, please go on then :) | 15:29 |
| *** Marga_ has quit IRC | 15:30 | |
| BadCub | dtantsur: all of the specs listed under High/Med/Low were all specs that were approved in K and carried over | 15:30 |
| BadCub | They have not yet been tagged for L | 15:30 |
| *** Marga_ has joined #openstack-ironic | 15:30 | |
| BadCub | I listed them, so we could look at them and move them up into the appropriate L category | 15:30 |
| dtantsur | BadCub, UCS already approved for L | 15:30 |
| dtantsur | ah, I see | 15:30 |
| dtantsur | so, there can be duplicate | 15:31 |
| BadCub | dtantsur: yes, a couple BPs were tagged for L already | 15:31 |
| BadCub | dtantsur: actually we should be pulling the BPs from the existing list and placing them in the priority grouping for L instead of duplicating on the pad | 15:35 |
| BadCub | they should move from carried over/backlog up | 15:35 |
| *** jrist has joined #openstack-ironic | 15:38 | |
| *** Sukhdev has joined #openstack-ironic | 15:38 | |
| devananda | it sounds like we need to track who on the core team has taken responsibility for tracking which features | 15:40 |
| devananda | ie, who the sponsors are for each large change | 15:40 |
| devananda | which is something we haven't done before | 15:40 |
| lucasagomes | yeah, I particularly like the sponsors idea | 15:40 |
| BadCub | devananda: I think this sharing of ideas will help us pull a lot of good ideas forward and help the whole group :) | 15:41 |
| lucasagomes | but we should be serious about it, if you sponsor something you gotta review it quick and consistently | 15:41 |
| lucasagomes | maybe even help with code when it's just nits and typos | 15:41 |
| BadCub | lucasagomes: ++ | 15:41 |
| devananda | lucasagomes: ++ | 15:41 |
| dtantsur | we kind of had it, e.g. I sponsored inspection :) | 15:42 |
| devananda | dtantsur: and your collaboration on the out-of-band work was very helpful | 15:42 |
| *** dlpartain has joined #openstack-ironic | 15:42 | |
| dtantsur | :) | 15:43 |
| lucasagomes | +1 but we should make it official and documented for this cycle if that's the path we are going to | 15:43 |
| devananda | we need that sort of cross-pollination // collaboration... this doesn't work very well if the sponsor is on the same team as the patch author | 15:43 |
| pshige | lucasagomes: ++ | 15:43 |
| NobodyCam | if go to a sponsor based system can any one sponsor any spec.. but that I mean something like can I sponsor a IPA or discoverD spec? | 15:43 |
| jlvillal | NobodyCam, I would vote for this spec: https://review.openstack.org/133902 Maybe for specs we like and need?? | 15:43 |
| * BadCub looks | 15:43 | |
| lucasagomes | NobodyCam, sure, if you have the technical capacity to judge the work why not | 15:43 |
| devananda | NobodyCam: a) only core reviewers could sponsor things, b) I'd propose that members of the same team don't sponsor (or aren't the only sponsor) of some work | 15:44 |
| NobodyCam | lucasagomes: I am not core on discoverD | 15:44 |
| lucasagomes | you don't need to be expert and know all about that project, but you should be happy with the idea and have technical capacity to review and test it | 15:44 |
| lucasagomes | NobodyCam, right, so yeah that wouldn't allow you to sponsor things in discoverd | 15:44 |
| lucasagomes | but yes for IPA and Ironic | 15:44 |
| lucasagomes | (if IPA needs spec) | 15:45 |
| NobodyCam | jlvillal: :) | 15:45 |
| dtantsur | NobodyCam, I would say you can, if you want to invest some time in it | 15:45 |
| rloo | what's the rationale for having a sponsor (vs no sponsor)? | 15:45 |
| dtantsur | rloo, to have a person ~responsible for landing the feature, so that it's not forgotten | 15:46 |
| rloo | I mean, are you talking about enforcing that all specs have a sponsor? | 15:46 |
| dtantsur | enforcing... hmmm.... | 15:46 |
| dtantsur | initially we were talking about exceptions | 15:46 |
| dtantsur | now we're talking about major undertakings | 15:46 |
| jlvillal | I do worry about this process making it harder for people to contribute. Especially for people who don't have any core reviewers in their company. | 15:46 |
| rloo | I don't mind if people volunteer to sponsor/shepherd (sp) but I wasn't sure if you were talking about 'must have'... | 15:47 |
| jlvillal | +1 | 15:47 |
| dtantsur | chances are high we won't need specs for e.g. implementing some interface for a driver | 15:47 |
| *** dlpartain has left #openstack-ironic | 15:47 | |
| rloo | to be honest, that would be similar to someone or someones helping out to get a patch merged. | 15:47 |
| * lucasagomes thought about sponsors for exception | 15:47 | |
| BadCub | I think the sponsoring specs idea is derived from "How do we make exepections for specs outside the approval window/timeframe or after cutoff" | 15:47 |
| lucasagomes | but maybe not... yeah it's a risky thing | 15:47 |
| * jlvillal Had thought sponsors was for all specs. If only for exceptions, that is more amenable. | 15:48 | |
| rloo | oh, if you mean for after the proposal deadline, then yes, I agree that it makes sense for some core (or two) to say they think it is worthwhile/can be done/will review | 15:48 |
| BadCub | jlvillal: rloo yes, it is for specs after deadline | 15:48 |
| devananda | +1 for exceptions // after the deadline // for very large things // and from other companies | 15:49 |
| jlvillal | BadCub, That sounds reasonable and a good idea. Because it is an exception. | 15:49 |
| BadCub | jlvillal: ++ | 15:49 |
| pshige | sponsors for essential or high specs are needed, I think. | 15:49 |
| jlvillal | devananda, Is that an 'and' statement? Or an 'or' statement? | 15:49 |
| jroll | devananda: it's unclear to me why "from other companies" matters so much for a "sponsor", as long as reviews still come in from other companies | 15:50 |
| * jlvillal thinks it is an 'and' statement | 15:50 | |
| lucasagomes | jroll, it looks bad to have people from the same company being the only ones reviewing some certain change | 15:51 |
| lucasagomes | I would say, that we could have people from the same company reviewing it, no problem | 15:51 |
| lucasagomes | but someone from another company should also review it prior to approval | 15:51 |
| devananda | ^ exactly | 15:51 |
| BadCub | lucasagomes: I agree ^ | 15:52 |
| devananda | and if the only person who has committed to reviewing a feature is on the same team as (or in fact *IS*) the author | 15:52 |
| devananda | then it is less likely, by the mere fact that someone else has already promised to do the work, that other people will do the work too | 15:52 |
| jroll | lucasagomes: devananda: if "the only person" is the only one reviewing, it isn't going to land | 15:52 |
| rloo | does nova ask for 1 or 2 core sponsors for feature exceptions? | 15:52 |
| devananda | rloo: 3 | 15:53 |
| rloo | whoa! | 15:53 |
| devananda | because of the frequency with which reviewers dont have enough time to actually review things | 15:53 |
| jroll | lucasagomes: devananda: I'm not saying that anything should land with only people from the same company reviewing, I'm specifically asking about this 'sponsor' thing | 15:53 |
| pshige | 3! | 15:53 |
| rloo | I think if we have 2, with at least one not being the author/same group/company, we're ok. | 15:53 |
| lucasagomes | jroll, if only people from the same company are willing to sponsors a patch for an exception, the exception won't be given to that spec | 15:53 |
| devananda | and the criticality of getting really fast turn around during the exception process | 15:53 |
| jroll | which I tend to not love anyway, we should all be sponsors for thigns we FFE | 15:53 |
| dtantsur | +1 for "2, with at least one not being the author/same group/company" | 15:54 |
| lucasagomes | I think 2 cores is enough | 15:54 |
| jroll | if we're going to grant an FFE, it should be something critical to the project that everyone agrees we need | 15:54 |
| lucasagomes | dtantsur, +1 | 15:54 |
| devananda | I'm not a fan of the word "sponsor" here, tbh | 15:54 |
| lucasagomes | backer?! | 15:54 |
| BadCub | supporter? | 15:54 |
| *** viktors is now known as viktors|afk | 15:54 | |
| pshige | BadCub: +1 | 15:55 |
| * jroll wonders if we could just do shorter release cycles and not FF long enough to need FFEs... | 15:55 | |
| devananda | jroll: ++ | 15:55 |
| BadCub | ++^ | 15:55 |
| jroll | so like | 15:55 |
| lucasagomes | is it up to us? | 15:55 |
| devananda | that would appear to solve much of these problems | 15:55 |
| devananda | *many | 15:55 |
| lucasagomes | I'm +1 with the idea, but being part of openstack means following the rules of openstack | 15:56 |
| jroll | why don't we talk about that instead of more and more processes around specs and FF | 15:56 |
| * dtantsur does 3 months cycles for discoverd and likes it | 15:56 | |
| lucasagomes | unless we go to the TC and try to change it :-D | 15:56 |
| lucasagomes | jroll, totally +1 | 15:56 |
| BadCub | what I observed in K was y'all reviewing like mad and getting uber hectic. Makes me sad to see folks stress and crunch so hard | 15:56 |
| jroll | lucasagomes: with the whole big tent thing we have the freedom to do different cadences | 15:57 |
| lucasagomes | devananda, does the big tent thing helps with it ^? | 15:57 |
| lucasagomes | jroll, oh ok I didn;t know that | 15:57 |
| rloo | i thought the meeting today was to go over the submitted specs, not to discuss process :-) | 15:57 |
| jroll | rloo: I thought so too :/ | 15:57 |
| lucasagomes | spec jam! | 15:57 |
| devananda | lucasagomes: yes, we can self-select a different cadence | 15:57 |
| lucasagomes | I like talking about the process as early as possible | 15:57 |
| NobodyCam | oh I though it was process based that may be /me who derailed it then | 15:57 |
| NobodyCam | :( | 15:58 |
| devananda | lucasagomes: if we all feel that more frequent releases would be better, I will work with ttx to set that up | 15:58 |
| lucasagomes | devananda, cool. Is it something we are looking at then? Release more release often? | 15:58 |
| lucasagomes | gotcha | 15:58 |
| devananda | I will still want us to do a release coordinated with the same timing as the rest of openstack | 15:58 |
| devananda | but we could do more frequent as well (ie, every 3 months) | 15:58 |
| rloo | personally, i'm not convinced that more frequent releases will help, but I don't mind watching/participating in the experiment :) | 15:58 |
| devananda | and follow our own freeze schedule, etc | 15:58 |
| BadCub | devananda: agreed there | 15:58 |
| * lucasagomes wonders how the stable branches etc will work with it | 15:59 | |
| jroll | rloo: it will enable us to do shorter (or no) freezes, and I think if the freeze is short enough we can stop doing FFEs, which we've been talking about all morning | 15:59 |
| lucasagomes | perhaps it should be another discussion | 15:59 |
| devananda | rloo: where I think it may help us is in lessenning the perceived impact of bumping a proposal | 15:59 |
| devananda | rloo: right now, not accepting something for K means that company has to wait 6 months | 15:59 |
| devananda | or s/that company/anyone who wants that feature/ | 16:00 |
| openstackgerrit | Nisha Agarwal proposed openstack/ironic: Update ilo drivers documentation for inspection https://review.openstack.org/170065 | 16:00 |
| rloo | devananda: so the problem is perhaps, not having a feature freeze deadline. | 16:00 |
| devananda | I will say, the counterpoint is that operators and distributors *actually* *really* want a six-month release that they can count on to be stable | 16:01 |
| *** Marga_ has quit IRC | 16:01 | |
| *** a1exhughe5 has quit IRC | 16:01 | |
| lucasagomes | perhaps we all should read http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/ar01s04.html | 16:01 |
| rloo | devananda: is the bottleneck getting specs approved? we had specs in kilo that didn't get implemented. | 16:01 |
| lucasagomes | and discuss it | 16:01 |
| * lucasagomes is particulary fond of it | 16:01 | |
| devananda | us simply doing shorter "sprints" with less freeze at the end doesn't change whether or not our downstream consumers want a realease every 6 mo | 16:01 |
| BadCub | rloo: I think we had too many approved for K | 16:02 |
| devananda | rloo: I think we spent about half the cycle on on specs and the second half on code | 16:02 |
| rloo | what would 'release early' mean for us though? there are already X-1, X-2, X-3?, X-rc1... | 16:02 |
| jroll | devananda: how sure are you that operators want a 6 month release (specifically, the 6 number)? I tend to see many operators running icehouse, still | 16:02 |
| jroll | lucasagomes: +10000000 | 16:02 |
| rloo | devananda: so the problem is that we shouldn't spend half the cycle on specs. | 16:02 |
| jlvillal | jroll, The comic company here in Portland is still running Grizzly :) | 16:02 |
| devananda | rloo: right | 16:02 |
| jlvillal | Dark Horse Comics I think | 16:03 |
| jroll | jlvillal: exactly. | 16:03 |
| devananda | jroll: operators want stable releases. distributors like us to produce code that they can package with their 6-month-timed releases. | 16:03 |
| *** derekh has quit IRC | 16:03 | |
| jroll | I haven't heard of very many people even running juno things yet | 16:03 |
| rloo | devananda: so releasing often, eg 2 months?, we'd have a feature freeze after 1 month in? | 16:03 |
| *** jistr has quit IRC | 16:03 | |
| devananda | jroll: openstack's cadence essentially comes from distros | 16:03 |
| jroll | /rage | 16:03 |
| rloo | BadCub: if we had too many approved for Kilo, how is more frequent releases going to help? | 16:04 |
| * lucasagomes admires rolling release distros | 16:04 | |
| BadCub | devananda: what is your opinion on the cut-off time frame for Specs? A month before end-of-cycle? Two months? More? | 16:04 |
| *** jistr has joined #openstack-ironic | 16:04 | |
| rloo | If we look back at Kilo, we didn't even finish implementing the state machine, we introduced microversions and didn't finish that, cleaning isn't finished. how are more frequent releases going to help? I think it'll be worse. | 16:05 |
| devananda | BadCub: X-2 at the latest, which is 6 weeks before feature freeze | 16:05 |
| devananda | rloo: making releases more frequent doesn't mean we finish big features faster | 16:06 |
| jroll | rloo: because we won't spend the first 2-3 months on specs instead of code, look at this graph: http://stackalytics.com/?module=ironic&metric=commits | 16:06 |
| BadCub | rloo: I think that initially, it could be, however if we set reasonable cut-off timeframes, and cap the amount of specs we can "reasonably" accomodate. The process would actually smooth out | 16:06 |
| rloo | so the problem is 'don't spend the first 2-3 months on specs only' | 16:06 |
| jroll | I mean, that's one problem | 16:07 |
| rloo | we now have a few specs that should only take 1-2 days to approve since they're being rolled from kilo, so that should help. | 16:07 |
| jroll | everybody slams a million features home at the end of a cycle because it means waiting 6 months if they don't | 16:07 |
| jroll | if a cycle bump only means your feature gets out a month later, that's much more palatable | 16:07 |
| BadCub | we have a bunch of specs that are already approved but not tagged to L yet. | 16:08 |
| *** dttocs has joined #openstack-ironic | 16:08 | |
| rloo | jroll: my concern is that. well, are we OK releasing if a feature isn't complete. and if so, how 'not complete' can it be? | 16:08 |
| BadCub | devananda: Maybe we set the cut-off at 8 weeks and allow for a 2 week "safety gap" ? | 16:09 |
| jroll | rloo: we can always feature flag it or whatever, just disable the API endpoint or whatever makes that feature happen until it's ready | 16:09 |
| rloo | jroll: small features that are self-contained are fine. but i worry about a partial implementation of a big feature that gets into a release. | 16:09 |
| jroll | rloo: have the patch chain not enable using the feature at all until the last patch in the chain | 16:09 |
| *** rameshg87 has joined #openstack-ironic | 16:09 | |
| *** jistr has quit IRC | 16:09 | |
| lucasagomes | I think that depends on the feature | 16:09 |
| lucasagomes | sometimes only parts of it is already usable | 16:10 |
| *** athomas has quit IRC | 16:10 | |
| rloo | jroll: it is easy to say, harder to monitor/do. i think. frankly, i worry about the overhead. but again, if people want to try it... | 16:10 |
| dtantsur | our patches should be self-contained IMO | 16:10 |
| jroll | personally, I think release cycles at all are insanity, they incentivize being able to land unstable code, break compatibility, etc. but I'm willing to play ball. | 16:10 |
| jroll | lucasagomes: sure, of course :) | 16:10 |
| dtantsur | so that every commit makes sense on its own | 16:10 |
| devananda | another good visualization of this tail-loading: https://github.com/openstack/ironic/graphs/contributors?from=2014-11-01&to=2015-04-15&type=c | 16:10 |
| NobodyCam | jroll: JoshNang: as a question: based on things found with the cleaning stuff do you forsee changes to the implement-zapping-states spec? | 16:10 |
| jroll | dtantsur: +++ | 16:10 |
| devananda | 16:07:33 < jroll> everybody slams a million features home at the end of a cycle because it means waiting 6 months if they don't | 16:10 |
| devananda | THAT ^ | 16:11 |
| jroll | NobodyCam: probably, I have no idea right now | 16:11 |
| JoshNang | NobodyCam: i'll look again, but nothing comes to mind. other than getting a list of zap/clean steps is challenging because you may not have the agent booted. | 16:11 |
| lucasagomes | one thing... are we take any decisions today ? Or it's more a brain storm? Can someone summarize the ideas and put it in a ML? | 16:12 |
| devananda | BadCub: while that sounds good, I think it will result in a similar situation -- we'll be pressured to heavily review specs early in each cycle | 16:12 |
| *** tiagogomes has left #openstack-ironic | 16:12 | |
| rloo | I think 6 months isn't too long to wait. but i suspect that the problem is that it isn't 'at most' 6 months. if you have an idea it could take 12 months. or longer. | 16:12 |
| * BadCub cleans up the list of Specs | 16:12 | |
| devananda | BadCub: which will result in less code being reviewed early in the cycle, and more code review / code landing at the end of the cycle | 16:12 |
| rameshg87 | rloo: hello | 16:13 |
| rloo | hi rameshg87 | 16:13 |
| rameshg87 | rloo: regarding using driver_internal_info https://review.openstack.org/#/c/173214/1/specs/liberty/ironic-generic-raid-interface.rst | 16:13 |
| BadCub | devananda: if we plan on doing our own release cycle, how about we have a spec approval window in each internal cycle? | 16:13 |
| *** tiagogomes has joined #openstack-ironic | 16:13 | |
| jroll | rloo: when you have customers that want a feature before they give you money, 6 months is a *really long time* | 16:13 |
| lucasagomes | BadCub, +1 I think that's the idea | 16:14 |
| rameshg87 | rloo: one reason i prefer driver_internal_info over any other field is it is read-only and best place to put validated information | 16:14 |
| jroll | rloo: and really, in the long run, we're building this so we can make money (whether externally or saving money by some internal metric), right? | 16:14 |
| devananda | jroll: customers that want a feature downstream should not wait for that feature to be landed upstream | 16:14 |
| rloo | honestly. i think if people want to do releases more frequently, then I suggest they propose something. we should use this time (or some time, whatever) to review specs to unblock folks. | 16:14 |
| NobodyCam | is there a official spec for the boot interface stuff? | 16:14 |
| * rameshg87 waits till rloo is out of other conversation | 16:14 | |
| BadCub | so we need to determine what our "internal release cycle" is, and maybe block out a couple days or a week at the beginning of that cycle to do spec approval.. | 16:15 |
| devananda | I'm fine tabling the release cadence and spec process discussions if folks want to actually go review specs | 16:15 |
| *** jistr has joined #openstack-ironic | 16:15 | |
| jroll | devananda: that's only true because of this issue. | 16:15 |
| devananda | but it is something we need to discuss, and soon | 16:15 |
| rloo | rameshg87: but driver_internal_info is for internal use by the driver. if the user specifies the raid config -- that should be read-only? read-only to whom? | 16:15 |
| jroll | devananda: if I could wait a month for a feature to upstream before shipping it, I would consider it | 16:15 |
| lucasagomes | devananda, right, is the ML a good place to discuss it? | 16:15 |
| devananda | we have a few weeks (until vancouver) to decide on the cadence we use for Liberty | 16:16 |
| rameshg87 | rloo: a read-only place seemed a better place to put validated information. | 16:16 |
| devananda | jroll: the nature of upstream is you can't ever promise a customer what will land there. you know that ... | 16:16 |
| rloo | devananda: and/or is that something to discuss at the summit? | 16:16 |
| rameshg87 | rloo: i can wait till other conversation is complete. np | 16:16 |
| devananda | rloo: summit is fine to finalize it, but we should all be as close as possible to the same page by then | 16:16 |
| * rameshg87 reads scrollback | 16:16 | |
| devananda | rloo: by the end of the summit, we have to declare the schedule we'll follow | 16:17 |
| rloo | rameshg87: not sure i understand. if the user provides information to/about the node, shouldn't it be placed in one of the usual places? driver_info, instance_info, properties, capabilities, i've lost track of them all. | 16:17 |
| rloo | devananda: got it, and yes, that makes sense. start the discussion now! | 16:17 |
| *** jistr has quit IRC | 16:17 | |
| jroll | devananda: sure. but clearly people are shipping upstream (or else they wouldn't worry about landing things RIGHT NOW BEFORE THE CYCLE ENDS) | 16:18 |
| devananda | lucasagomes: ML is possible, but too low bandwidth. I think the discussion we just had was helpful | 16:18 |
| BadCub | devananda: I can pull all the ideas from the pad and consolidate them into an informal game-plan concept and throw it up for folks to look at too | 16:18 |
| lucasagomes | devananda, yup yeah it was helpful to brainstorm the ideas | 16:18 |
| dtantsur | ++ | 16:18 |
| lucasagomes | the ML is good to document it as such | 16:18 |
| * devananda throws wet cats at jroll | 16:18 | |
| jroll | :D | 16:18 |
| devananda | BadCub: ++ | 16:18 |
| BadCub | lol | 16:18 |
| rloo | BadCub: my suggestion is for the folks that want frequent releases, to put more details into how it will work. | 16:18 |
| rameshg87 | rloo: yes, driver_info, instance_info, etc, but if the user/an external entity(like nova) is going to update the information through node-update. | 16:18 |
| lucasagomes | BadCub, that would be awesome | 16:19 |
| rameshg87 | rloo: but in case of raid, both GET and PUT are through it's own APIs | 16:19 |
| jroll | devananda: to be fair, you probably know users better than I do, so take my statements with many grains of salt :) | 16:19 |
| devananda | jroll: you mind working with badcub and myself to draft exactly what a more frequent release cadence would look like? | 16:19 |
| dtantsur | rloo, 1 mon spec proposals, 1 mon spec implementation, 1 mon FF and bug fixing | 16:19 |
| dtantsur | :) | 16:19 |
| rameshg87 | rloo: i mean information is read/written using it's own APIs | 16:19 |
| BadCub | rloo: I agree. We do need more details there. I will leave the pad for folks to add more comments for the next day and then throw together the concept. | 16:19 |
| rloo | rameshg87: but that's the point, there's an API. which means that it is user/external info. that's not what driver_internal_info is meant for. | 16:19 |
| BadCub | that sound good for everyone? | 16:19 |
| jroll | devananda: push a tag at 0000 UTC daily ;D | 16:20 |
| devananda | jroll, BadCub: I think if the 3 of us can iron out a proposal in, say, the next 10 days, that should give others time to consider it thoroughly before the summit | 16:20 |
| jroll | devananda: for real though, yes, willing to help | 16:20 |
| devananda | jroll: thanks | 16:20 |
| BadCub | devananda: jroll I think that would be awesomeness | 16:20 |
| rameshg87 | rloo: but where else would you suggest ? driver_info ? | 16:21 |
| devananda | rameshg87: RAID layout should be instance_info | 16:21 |
| BadCub | I will star compiling the pad details on the other topics tomorrow :) | 16:21 |
| *** athomas has joined #openstack-ironic | 16:21 | |
| BadCub | s/star/start | 16:21 |
| rameshg87 | devananda: but it's not related to instance. | 16:21 |
| *** jmankov has joined #openstack-ironic | 16:21 | |
| rloo | rameshg87: like devananda says. Or a new field. | 16:21 |
| devananda | rameshg87: then it should be node.properties | 16:22 |
| rameshg87 | devananda: it's done during zapping in which instance might not be there | 16:22 |
| devananda | either this is static with respect to Nova, and nova merely schedules instances onto nodes that match the type of RAID that instance wants -- in which case it is node.properties | 16:22 |
| devananda | or this is dynamic and determined by the desired instance, ie it comes from the nova Flavor, and nova has to pass that info on node.instance_info | 16:23 |
| *** absubram has joined #openstack-ironic | 16:23 | |
| rameshg87 | devananda: yeah, in the spec the schedulable properties (like local_gb, raid_level) are updated in properties | 16:23 |
| devananda | the problem is that some people are going to want (A) and some will want (B) and we already know this | 16:23 |
| BadCub | devananda: I will also move all the backlog specs to a new pad for the Specs Cores to gander at and see if we are on track for gettng them into L | 16:23 |
| BadCub | brb | 16:23 |
| NobodyCam | brb... | 16:23 |
| dtantsur | folks, I'm going for now, see you tomorrow | 16:23 |
| *** dtantsur is now known as dtantsur|afk | 16:23 | |
| lucasagomes | dtantsur, have a good night | 16:23 |
| rloo | night dtantsur|afk | 16:23 |
| devananda | BadCub: thanks. and yea, the "review kilo leftovers" discussion is clearly separate from "talk about liberty process" | 16:24 |
| rameshg87 | devananda: yeah B is not being targetted now | 16:24 |
| pshige | dtantsur: have a good night | 16:24 |
| jroll | devananda: in the second case, why wouldn't flavor match to properties? | 16:24 |
| rameshg87 | devananda: it's only A that is mentioned in that spec | 16:24 |
| *** jrist has quit IRC | 16:24 | |
| lucasagomes | devananda, rloo rameshg87... so this is something that 1) users do a PUT request 2) Ironic validates information and put it in the driver_internal_info if valid 3) zapping consumes the the tihngs in driver_internal_info and build the raid 4) set the raid information in properites so that nova is aware of it... If that correct? | 16:24 |
| lucasagomes | Is that correct?* | 16:25 |
| rameshg87 | yes, that's what is there in spec right now | 16:25 |
| lucasagomes | I think I'm good with it | 16:25 |
| *** smoriya has quit IRC | 16:25 | |
| *** jmanko has quit IRC | 16:25 | |
| lucasagomes | the key thing here is that, there's a validation prior to setting it to driver_internal_info... which is read-only | 16:25 |
| rameshg87 | yeah, that's what i was coming to | 16:26 |
| lucasagomes | where other fields the user can go there and tweak it, and it won't trigger any validation | 16:26 |
| *** saripurigopi has quit IRC | 16:26 | |
| rameshg87 | someone could even update properties with node-update itself and modify the validated info | 16:26 |
| rloo | i'm not sure i agree with that, although i sort of see what you mean. | 16:26 |
| lucasagomes | rameshg87, yup | 16:26 |
| rloo | the thing is, the user is specifying information. | 16:26 |
| rloo | they shouldn't have to look at driver_internal_info to see what that info was. | 16:27 |
| lucasagomes | rloo, user gives data, which is turned into information I believe... Users can say build a raid level BLAH | 16:27 |
| lucasagomes | but the information saved will contian things like size that is possible for that node etc | 16:27 |
| rameshg87 | rloo: the user needn't check driver_internal_info. there is an API for it, right ? | 16:27 |
| rloo | lucasagomes: where/how does the user get access to their BLAH? | 16:27 |
| lucasagomes | rloo, it's the supported raid level | 16:28 |
| lucasagomes | and ironic will validate whether the node contains enough disks to support that level etc | 16:28 |
| lucasagomes | ther'es a mininum of disks required for different raid levels | 16:28 |
| lucasagomes | and that should be validated | 16:28 |
| rloo | lucasagomes: is the supported raid level saved anywhere? | 16:28 |
| rloo | lucasagomes: maybe i misinterpreted the spec. | 16:29 |
| lucasagomes | http://en.wikipedia.org/wiki/Standard_RAID_levels | 16:29 |
| rameshg87 | lucasagomes: "node contains enough disks to support that level" is an optional thing for driver | 16:29 |
| rloo | lucasagomes: here's the API: PUT /nodes/<uuid>/raid/configuration | 16:30 |
| rameshg87 | lucasagomes: inband can't do it :( | 16:30 |
| lucasagomes | rameshg87, right yeah fair | 16:30 |
| rloo | lucasagomes, rameshg87: is that specifying the configuration? is 'configuration' hardcoded, or is that to be replaced with the user's configuration? | 16:30 |
| lucasagomes | rloo, I'm not sure, I think the information is not changed but introspected | 16:31 |
| jroll | I have a higher level question: does nova have any sort of concept of raid? it doesn't need one because there's no real disks, right? | 16:32 |
| rameshg87 | rloo: i didn't get your question. we pass on the input directly to the driver handling it after applying some ironic *defaults* | 16:32 |
| jroll | ok yeah, no references to the word 'raid' in their codebase, ignore me :) | 16:32 |
| rameshg87 | jroll: not there unfortunately | 16:32 |
| rloo | rameshg87: what is the input? I mean, is the request literally 'PUT /nodes/<uuid>/raid/configuration' where only the uuid is replaced with a real uuid? | 16:33 |
| lucasagomes | jroll, yeah ... but it's ok. Cause zapping happens prior to available | 16:33 |
| lucasagomes | so nova will only see a device already created | 16:33 |
| jroll | right | 16:33 |
| jroll | so when we say 'user' we mean the ironic user, to be clear | 16:33 |
| rloo | rameshg87: there's a body to that PUT, right? | 16:33 |
| rameshg87 | rloo: yeah | 16:33 |
| lucasagomes | jroll, yup operator | 16:33 |
| rameshg87 | rloo: the body itself is the json data | 16:33 |
| rameshg87 | the raid configuration | 16:33 |
| rloo | rameshg87: right, that's what i thought. and you and lucasagomes are saying that this json data will be verified and placed in driver_internal_info, and I disagree with that cuz this is user information. | 16:34 |
| devananda | BadCub: hope you dont mind me rearranging the spec list a bit :) | 16:34 |
| BadCub | devananda: not at all! | 16:34 |
| rloo | rameshg87: we're opening the door now, for all other kinds of information that the user might specify, being put in driver_internal_info. | 16:35 |
| rameshg87 | rloo: yeah, the data sent along with this PUT API will be validated and placed in driver_internal_info | 16:35 |
| rameshg87 | rloo: one second getting an example | 16:35 |
| rloo | rameshg87: and the reason we have driver_internal_info, is cuz someone else wanted to store internal info in driver_info. | 16:35 |
| rameshg87 | to make sure we are first in same page | 16:35 |
| rameshg87 | rloo: http://paste.openstack.org/show/171957/ | 16:36 |
| lucasagomes | cool, yeah it says current and pending | 16:37 |
| lucasagomes | which gives an overview about the state of the raid | 16:37 |
| lucasagomes | and this is internal info | 16:37 |
| * devananda wonders why driver_internal_info is exposed in the API at all | 16:37 | |
| lucasagomes | devananda, +1 | 16:37 |
| rameshg87 | yeah, and current state of raid *is* not the exact input from user | 16:37 |
| lucasagomes | yeah I wonder that too | 16:37 |
| lucasagomes | devananda, perhaps for troubleshooting... but idk either | 16:38 |
| jroll | driver_internal_info is useful to operators | 16:38 |
| jroll | for example agent_url | 16:38 |
| rameshg87 | lucasagomes: yeah it helps | 16:38 |
| rloo | devananda: I wondered about that too, but I think someone said it was to help with debugging. or maybe that's what i thought it woudl be useful for. | 16:38 |
| rameshg87 | jroll: exactly :) | 16:38 |
| jroll | we inspect things from there in our dashboard | 16:38 |
| rameshg87 | it has been useful to me | 16:38 |
| lucasagomes | jroll, good point | 16:38 |
| rameshg87 | to find agent_url and then ssh to it when there is some issue | 16:38 |
| *** EmilienM is now known as EmilienM|afk | 16:38 | |
| jroll | tl;dr I use it in my environments and will yell at anyone who takes it away :D | 16:39 |
| lucasagomes | jroll, we won't or we would break our current api | 16:39 |
| lucasagomes | so ur safe | 16:39 |
| lucasagomes | no more api breakages please | 16:39 |
| jroll | heh | 16:39 |
| rloo | lucasagomes: I dunno. we could deprecate it, give jroll 6 months (ok 12 months) to replace it ;) | 16:40 |
| lucasagomes | rloo, heh -2 | 16:40 |
| lucasagomes | :P | 16:40 |
| jroll | rloo: I only need a day, I'll revert the patch downstream :) | 16:40 |
| lucasagomes | it's only shown with /detail right? | 16:40 |
| lucasagomes | so it's grand | 16:40 |
| *** jrist has joined #openstack-ironic | 16:40 | |
| rameshg87 | lol | 16:40 |
| rameshg87 | rloo: so coming back .. yes initially the user-input is saved exactly as it is | 16:41 |
| lucasagomes | anyhoo... I'm +1 for driver_internal_info on raid | 16:41 |
| lucasagomes | I think that's the right place for it | 16:41 |
| jroll | lucasagomes: yeah, just node-show or node-list --detail | 16:41 |
| lucasagomes | cool | 16:42 |
| rloo | rameshg87: are you saving the user's config json data anywhere? | 16:42 |
| *** Marga_ has joined #openstack-ironic | 16:42 | |
| rameshg87 | rloo: that's in driver_internal_info too | 16:42 |
| * NobodyCam begains to wounder if we'll end up wanting a port_internal_info and node_internal_info as well as driver | 16:42 | |
| NobodyCam | brb .. bbt | 16:42 |
| rloo | rameshg87: if I look in driver_internal_info, will I see the user's config data? | 16:42 |
| rameshg87 | rloo: yes | 16:42 |
| lucasagomes | NobodyCam, hope not :D | 16:42 |
| rloo | rameshg87: I disagree with that | 16:43 |
| rameshg87 | rloo: it will show up as 'target_raid_configuration' | 16:43 |
| *** yog has joined #openstack-ironic | 16:43 | |
| rameshg87 | rloo: that's what the driver hopes to apply when zapping is invoked next time | 16:43 |
| *** yog is now known as Guest16106 | 16:43 | |
| rloo | rameshg87: the PUT operation just puts that info, no operation is done? | 16:43 |
| lucasagomes | validation | 16:44 |
| rameshg87 | rloo: no operation is done. | 16:44 |
| rameshg87 | rloo: just validation | 16:44 |
| rameshg87 | yeah | 16:44 |
| lucasagomes | for drac we can validate important things out-of-band | 16:44 |
| lucasagomes | as mentioned, number of disks for the raid level is available and so on | 16:44 |
| lucasagomes | that's neat | 16:44 |
| rameshg87 | and returns 202 accepted | 16:44 |
| rloo | rameshg87: it seems to me that you should add a new target_raid_configuration or something like that. | 16:44 |
| rameshg87 | rloo: add a new "target_raid_configuration" field ? | 16:45 |
| *** jrist has quit IRC | 16:45 | |
| rloo | rameshg87: yeah, why not? | 16:45 |
| rloo | rameshg87: we have a target_provision_state and target_power_state. why should this be hidden in driver_internal_info? | 16:46 |
| rameshg87 | rloo: but all nodes might not be interested in raid no ? raid is just for nodes that support it and drivers managing the nodes that support it | 16:46 |
| rameshg87 | rloo: in majority of cases, this field might be lying around not used :) | 16:47 |
| rloo | rameshg87: are all nodes interested in inspecting and cleaning? we have clean_step and inspection* fields | 16:47 |
| rloo | rameshg87: and what about console_enabled? | 16:47 |
| rameshg87 | hmm .. interesting | 16:47 |
| rloo | rameshg87: I'd prefer if it went in instance_info or properties but you had reasons for not. | 16:48 |
| rloo | rameshg87: or extra. i don't know if i ever figured out what that was for. | 16:48 |
| rameshg87 | rloo: what was your main point against driver_internal_info ? | 16:48 |
| devananda | target_raid_level is not a bad idea | 16:49 |
| rloo | rameshg87: it is internal to the driver. that's why it is called driver_INTERNAL_info. | 16:49 |
| devananda | if that's unused on nodes that don't support raid, tha'ts fine | 16:49 |
| devananda | i generally agree with rloo's concern about abusing driver_internal_info here | 16:49 |
| devananda | it's not something the user should have to care about | 16:49 |
| lucasagomes | yeah the target_raid_config seems okish | 16:50 |
| lucasagomes | devananda, but the user don't | 16:50 |
| lucasagomes | I mean he should not be looking at that field | 16:50 |
| lucasagomes | theere's an api endpoint which he can GET | 16:50 |
| devananda | if I'm PUT'ing data to Ironic to change some properties of a node, that request shouldn't in any way require me to look at *internal* info | 16:50 |
| devananda | so perhaps I "PUT {new raid info} /v1/nodes/NNNN/states/raid" | 16:51 |
| devananda | I should darn well be able to "GET /v1/nodes/NNNN/states/raid" and see the state after it was applied | 16:51 |
| lucasagomes | devananda, that's exactly what it is | 16:51 |
| lucasagomes | GET/PUT v1/nodes/<uuid>/raid/configuration | 16:51 |
| *** ifarkas has quit IRC | 16:51 | |
| devananda | if I have to go look at driver_internal_info to see whether ironic succeeded or failed in applying those raid settings, we've made a terrible API | 16:51 |
| rameshg87 | devananda: it's completely through API in it's current proposal | 16:52 |
| devananda | on the other hand, if some driver wants to maintain some internal cache about the hardware's capabilities (like this node can support RAID 0/1/10 and that hardware supports 0/1/10/5/50) | 16:52 |
| devananda | then that's just fine | 16:52 |
| devananda | driver_internal_info IS the right place to cache that sort of thing | 16:52 |
| lucasagomes | devananda, http://paste.openstack.org/show/171957/ | 16:52 |
| lucasagomes | yes, exactly | 16:52 |
| rameshg87 | devananda: you can tell the configuration, know whether it's applied or not AND get the configuration after applying it - all through API | 16:53 |
| rameshg87 | devananda: rloo: it doesn't change anything much - but i was just skeptical in adding a new field altogether | 16:53 |
| rameshg87 | when every possible operation was exposed through an API | 16:54 |
| rameshg87 | and when i could use something that is existing | 16:54 |
| devananda | lucasagomes: at initial reading, that paste looks sane | 16:54 |
| rameshg87 | and implementation OR the user didn't bother much where the information was stored | 16:54 |
| lucasagomes | devananda, yup, yeah that's what the spec proposes | 16:54 |
| lucasagomes | devananda, that's why I think that driver_internal_info is the right place. I'ts just caching the pending configuration set by the user | 16:55 |
| lucasagomes | it doesn't require user to look into it or anything like that | 16:55 |
| devananda | lucasagomes: the API should also expose a sample of the raid-config object, as well as a description of it | 16:55 |
| devananda | lucasagomes: not just a list of the logical_disk_properties | 16:55 |
| devananda | it looks like you're on the path to doing that, but there's more than just this paste | 16:55 |
| devananda | lucasagomes: hm, no. caching the pending configuration should not be done in driver_internal_info | 16:56 |
| devananda | for one, that creates two API endpoints to get the same info | 16:56 |
| *** jrist has joined #openstack-ironic | 16:58 | |
| lucasagomes | devananda, a sample? yeah that would be useful... but then we have also docs with samples etc | 16:58 |
| lucasagomes | devananda, right... that's the problem with the driver_internal_info being externally exposed I suppose | 16:59 |
| lucasagomes | I mean, the information has been validated by the driver and now is pending | 16:59 |
| lucasagomes | driver needs to cache it somewhere, I don't see option if not driver_internal_info | 16:59 |
| lucasagomes | by putting it on other fields means that users can partial update the data, without revalidating, which is not nice | 17:00 |
| lucasagomes | it's the same for set_boot_device | 17:01 |
| lucasagomes | when you set it to persistent, some BMCs saves that internally so you can retrieve | 17:01 |
| rameshg87 | unless we put it on a new field which they cannot touch with any other API | 17:02 |
| lucasagomes | some drivers saves it to driver_internal_info because the BMC cannot save it | 17:02 |
| lucasagomes | you can look the option on both, whether get-set-boot-device or looking at internal info | 17:02 |
| lucasagomes | the info will be there | 17:02 |
| rloo | lucasagomes: the set_boot_device bothers me too. | 17:02 |
| lucasagomes | right, but here's the thing... if we have something that is not nice, is that internal information is being exposed right? | 17:03 |
| lucasagomes | not that we are saving things that, which are internal for the driver | 17:03 |
| lucasagomes | things there* | 17:03 |
| rloo | lucasagomes: that was meant for saving things that are internal (for the driver or instance or whatever) | 17:04 |
| lucasagomes | rloo, and a already validated information is something internal no? | 17:04 |
| lucasagomes | I mean we have introspected into this information | 17:04 |
| lucasagomes | it's not just raw input | 17:04 |
| rloo | lucasagomes: so I am fine if you want to save validated info in driver_internal_info. I'm not fine with not saving the user's data in a field that the user can find/makes sense to them. | 17:05 |
| rameshg87 | rloo: but validated info == info-that-user-input | 17:05 |
| rloo | lucasagomes: so if you want some user-field like target_raid to hae the config, and you want driver_internal_info to have a validated config,then whatever. | 17:06 |
| lucasagomes | I'm not against the target_raid_config tho | 17:07 |
| rloo | rameshg87: look. why do we even have target_power_state? we could have just provided APIs for that. I could say the same for most of the other things we have. console_enabled. Why not store whether it is enabled or disabled in driver_internal_info? | 17:07 |
| rloo | rameshg87: I don't even know why we have inspection* fields. we could have put them in driver_internal_info too. | 17:07 |
| * rloo thinks we should deprecate all the fields and just keep driver_internal_info. | 17:08 | |
| NobodyCam | rloo: ieek | 17:08 |
| *** pas-ha has quit IRC | 17:09 | |
| rloo | look, it clearly isn't clear. And maybe if I actually read rameshg87 and grok'd it, I'd think differently. Although I don't think so. rameshg87 just needs two cores to +2/+A. This is just my opinion, although it seems like devananda also agrees. with part of it anyway ;) | 17:09 |
| rloo | rameshg87: I mean 'read the spec in detail' | 17:10 |
| lucasagomes | yeah, we have many incosistences specially the diff endpoints retunring the same information | 17:10 |
| lucasagomes | GET v1/nodes/<uuid> | 17:10 |
| lucasagomes | GET v1/nodes/<uuid>/states | 17:10 |
| lucasagomes | will return same info | 17:11 |
| rloo | note that we validate that the power state (and or provision state) is a valid state. So by your example, we should just put the target*states in driver_internal_info. | 17:11 |
| lucasagomes | I'm not against the target_raid_config to keep the consistency with the other states we have | 17:11 |
| lucasagomes | rloo, the thing is that target_ states are indexable | 17:11 |
| lucasagomes | if one, want target_raid_config to be indexable | 17:12 |
| lucasagomes | so that they can filter the API by it | 17:12 |
| lucasagomes | so yes, we should have a target_ state | 17:12 |
| lucasagomes | I can filter all nodes that are powered on, or transitioning to it | 17:12 |
| lucasagomes | is it useful for raid config? I'm not sure maybe... | 17:13 |
| lucasagomes | if so we can make it an indexable field | 17:13 |
| rloo | lucasagomes: is that the only reason we added target_*_state? so that we could filter on that? | 17:13 |
| lucasagomes | rloo, to be very honest, when we started the ironic api nobody had any experience with REST APIs | 17:13 |
| lucasagomes | so it's natural that we have our incosistencies | 17:13 |
| rloo | lucasagomes: totally agree. i just don't see why we'd want to add a new inconsistency. | 17:14 |
| lucasagomes | rloo, one of the reason to have it to be indexable, yes so we can filter on it | 17:14 |
| * rameshg87 can't think of any use case of indexing a json data | 17:14 | |
| rameshg87 | and it's not guaranteed that indexing will work | 17:15 |
| *** ndipanov has quit IRC | 17:15 | |
| lucasagomes | yup | 17:15 |
| rameshg87 | unless database is that intelligent :) | 17:15 |
| rloo | in this case, it seems like the only useful thing might be to see IF target_raid* is not None | 17:15 |
| lucasagomes | yup that's valid | 17:16 |
| rloo | but I don't think of target* stuff being there just for filtering. we have filtering for maintenance and instance too. I see them there so that the user can get some info as to the state/etc of the node. | 17:16 |
| rameshg87 | yeah | 17:16 |
| lucasagomes | or if we have a raid already set (which is the non target field) | 17:16 |
| rloo | which is why i'd prefer that this config was in properties or extras or instance_info and not a separate field, but I'm happy with anything that isn't *internal* | 17:17 |
| lucasagomes | yup yeah all the fielters that we can filter on should be indexable basically | 17:17 |
| rloo | rameshg87, lucasagomes: gonna get lunch. i think i've given you enough of my opinions on this :-) | 17:18 |
| *** athomas has quit IRC | 17:18 | |
| lucasagomes | rloo, fair | 17:18 |
| lucasagomes | and I will go home too | 17:18 |
| * lucasagomes came to the office | 17:18 | |
| lucasagomes | rloo, enjoy lunch! | 17:18 |
| rameshg87 | and i will goto sleep too | 17:18 |
| NobodyCam | night lucasagomes and rameshg87 :) | 17:18 |
| lucasagomes | NobodyCam, have a good night | 17:19 |
| rameshg87 | have a good day NobodyCam, rloo | 17:19 |
| rameshg87 | goodnight lucasagomes | 17:19 |
| lucasagomes | good night/day everyone! | 17:19 |
| NobodyCam | thank you both great conversations!!! | 17:19 |
| rameshg87 | bye everyone | 17:19 |
| lucasagomes | rameshg87, night | 17:19 |
| *** rameshg87 has quit IRC | 17:19 | |
| *** lucasagomes has quit IRC | 17:20 | |
| *** ijw has quit IRC | 17:25 | |
| *** ijw has joined #openstack-ironic | 17:26 | |
| *** ijw has quit IRC | 17:27 | |
| *** ijw has joined #openstack-ironic | 17:28 | |
| *** davideagnello has joined #openstack-ironic | 17:28 | |
| *** trown is now known as trown|lunch | 17:29 | |
| *** achanda has joined #openstack-ironic | 17:35 | |
| *** harlowja_away is now known as harlowja | 17:36 | |
| jxiaobin | Hi @JoshNang | 17:37 |
| JoshNang | jxiaobin: hi! | 17:38 |
| jxiaobin | I have a question on the cleaning | 17:38 |
| JoshNang | ask away! | 17:38 |
| *** Sukhdev has quit IRC | 17:38 | |
| jxiaobin | do we need to configure "cleaning_network_uuid" in order to make cleaning work? | 17:39 |
| jxiaobin | does that mean cleaning can only happen in a particular network? | 17:40 |
| JoshNang | using the default neutron provider, yes | 17:41 |
| * JoshNang needs to add to the deploy docs | 17:41 | |
| JoshNang | basically, we have to be able to boot a ramdisk, the ramdisks require a network config to be able to boot | 17:41 |
| jxiaobin | hmm, for us, we will have a bunch of networks, and a server can only live in one network | 17:43 |
| jxiaobin | so a single "cleaning_network_uuid" will not work out for us | 17:43 |
| JoshNang | so the way we have it deployed in production is a separate vlan set aside for just cleaning | 17:44 |
| jxiaobin | I think Ironic shall support cleaning in the same network as well | 17:45 |
| JoshNang | i think that should be possible | 17:46 |
| JoshNang | (not today, but in the future) | 17:46 |
| jxiaobin | The idea is Ironic reuse the provisioning network for cleaning | 17:46 |
| JoshNang | right. we'll have to modify a few things internally to hold onto that information. currently, the node has no idea what network it was on by the time it hits cleaning | 17:47 |
| JoshNang | you should file a bug | 17:47 |
| JoshNang | so we don't lose track of it | 17:47 |
| jxiaobin | sure, thanks a lot! | 17:47 |
| JoshNang | np! | 17:48 |
| *** Marga_ has quit IRC | 17:49 | |
| *** Marga_ has joined #openstack-ironic | 17:49 | |
| jroll | jxiaobin: ironic does support cleaning in the same network, you just have to tell it which network that is :) | 17:52 |
| jxiaobin | jroll: but that need enhancement, right? is the feature available now? | 17:54 |
| jroll | jxiaobin: yes, whatever network nova is using to boot a server, use the same network for cleaning_network_uuid | 17:54 |
| jxiaobin | jroll: maybe I missed something, but in code, ironic will only use the "cleaning_network_uuid" from configuration file. | 17:56 |
| jroll | jxiaobin: right, there is a manual step of configuring that | 17:57 |
| jroll | jxiaobin: you say you have one network that baremetal nodes are booted on, right? | 17:57 |
| jxiaobin | jroll: yes | 17:57 |
| jroll | ok, what's the ID for that network? | 17:57 |
| *** andreykurilin has joined #openstack-ironic | 17:58 | |
| jxiaobin | UUID? let's assume "123456" :) | 17:58 |
| *** openstackstatus has quit IRC | 17:58 | |
| jroll | sure | 17:58 |
| *** trown|lunch is now known as trown | 17:58 | |
| jroll | so set cleaning_network_uuid=123456 | 17:59 |
| jroll | it's an unfortunate manual step, but it works, it can be the same network | 17:59 |
| *** openstackstatus has joined #openstack-ironic | 17:59 | |
| *** ChanServ sets mode: +v openstackstatus | 17:59 | |
| jxiaobin | but this is a global configuration, right? in my poc env, I have 3 networks | 18:00 |
| jxiaobin | I'll have to change the configuration, and reload the value, then delete the node | 18:00 |
| jroll | ah, I see | 18:01 |
| jroll | it's per-conductor, but yes essentially global | 18:01 |
| jxiaobin | yeah :-) | 18:02 |
| jxiaobin | basically our management want to adopt Ironic as our baremetal solution | 18:02 |
| -openstackstatus- NOTICE: Gerrit has stopped emitting events so Zuul is not alerted to changes. We will restart Gerrit shortly to correct the problem. | 18:03 | |
| *** ChanServ changes topic to "Gerrit has stopped emitting events so Zuul is not alerted to changes. We will restart Gerrit shortly to correct the problem." | 18:03 | |
| jxiaobin | currently we're running our home-made system, which already manages like ~35000 physical servers | 18:03 |
| *** ijw has quit IRC | 18:03 | |
| jroll | nice | 18:03 |
| *** ijw has joined #openstack-ironic | 18:03 | |
| jxiaobin | it's essentially a private cloud, so we do not care too much about multi tenancy, isolation | 18:04 |
| jroll | so better networking things in general is something we're going to be hitting hard soon | 18:04 |
| jroll | but it isn't great right now | 18:04 |
| *** ijw has quit IRC | 18:04 | |
| *** ijw has joined #openstack-ironic | 18:05 | |
| jxiaobin | we actually don't need fancy networking features, we're quite traditional | 18:05 |
| *** htrmeira has joined #openstack-ironic | 18:05 | |
| jxiaobin | all our servers are on the same vlan | 18:06 |
| jxiaobin | thanks jroll for the information though :) | 18:06 |
| jroll | you're welcome :) | 18:07 |
| BadCub | We just lost the entire electrical box on the house | 18:11 |
| BadCub | devananda: ^^^^ | 18:12 |
| jroll | "lost" :P | 18:12 |
| BadCub | Tree cutters crashed a tree into house | 18:13 |
| jroll | daaaang | 18:13 |
| BadCub | Ripped the entire electric box off the wall | 18:13 |
| *** Marga_ has quit IRC | 18:15 | |
| *** EmilienM|afk is now known as EmilienM | 18:22 | |
| BadCub | Electricians and power company called :( | 18:23 |
| *** ChanServ changes topic to "Bare Metal Provisioning | Status: http://bit.ly/ironic-whiteboard | Docs: http://docs.openstack.org/developer/ironic/ | Bugs: https://bugs.launchpad.net/ironic" | 18:25 | |
| -openstackstatus- NOTICE: Gerrit has been restarted. New patches, approvals, and rechecks between 17:30 and 18:20 UTC may have been missed by Zuul and will need rechecks or new approvals added. | 18:25 | |
| htrmeira | Hey guys, did anyone install ironic in a production environment and made it work? | 18:28 |
| *** sambetts has quit IRC | 18:29 | |
| *** sambetts has joined #openstack-ironic | 18:32 | |
| jroll | htrmeira: yes, I'm from rackspace where we run it in production on our public cloud | 18:33 |
| *** andreykurilin has quit IRC | 18:36 | |
| *** andreykurilin has joined #openstack-ironic | 18:40 | |
| htrmeira | :jroll, I'm having a realy weird problem in my deploy. Nova does not recognize any ironic bm node. Have you seen something like this? | 18:40 |
| jroll | htrmeira: can you be more specific? | 18:41 |
| jroll | htrmeira: also, what version of nova and ironic are you running? is there a specific guide or distribution you used to install this? | 18:41 |
| htrmeira | I have followed this guide: http://docs.openstack.org/developer/ironic/deploy/install-guide.html | 18:43 |
| htrmeira | My ironic version (.deb versions): http://pastebin.com/RuNaNUGu | 18:43 |
| htrmeira | the whole openstack installation is Kilo (up to date). | 18:43 |
| htrmeira | :jroll the problem is, when I create a bm node using ironic create-node, I can see the entry on ironic database table. But, I can not see the entry on nova database table (compute_nodes). | 18:45 |
| *** jcoufal_ has quit IRC | 18:45 | |
| * jroll looks | 18:45 | |
| htrmeira | jroll, and because of this, nova hypervisor-list does not show any ironic bm node. | 18:45 |
| *** dttocs has quit IRC | 18:46 | |
| jroll | first thing I would check is these configs: | 18:46 |
| jroll | http://docs.openstack.org/developer/ironic/deploy/install-guide.html#configure-compute-service-to-use-the-bare-metal-service | 18:46 |
| *** Marga_ has joined #openstack-ironic | 18:46 | |
| htrmeira | I have checked, It seems to be ok. would you like to see the nova.conf? | 18:49 |
| jroll | mmm | 18:49 |
| jroll | I guess at this point I would want to see nova-compute logs | 18:49 |
| jroll | make sure it's connecting to ironic ok etc | 18:49 |
| jroll | also "ironic node-list" | 18:49 |
| htrmeira | sure. Just a sec. | 18:50 |
| *** Marga_ has quit IRC | 18:51 | |
| *** andreykurilin has quit IRC | 18:52 | |
| *** ijw has quit IRC | 18:57 | |
| *** Haomeng has quit IRC | 19:06 | |
| *** Haomeng has joined #openstack-ironic | 19:06 | |
| *** ijw has joined #openstack-ironic | 19:08 | |
| *** ijw has quit IRC | 19:13 | |
| htrmeira | jroll: sorry the delay, we are having some problems with our network. I will have to seek your help latter, if possible. =/ | 19:19 |
| jroll | htrmeira: I'm always here, as are some of my other team members :) | 19:19 |
| htrmeira | jroll: Thank you very much. =) | 19:20 |
| jroll | not a problem! | 19:20 |
| *** ijw has joined #openstack-ironic | 19:28 | |
| *** ukalifon has quit IRC | 19:30 | |
| *** david-lyle has joined #openstack-ironic | 19:30 | |
| *** ijw_ has joined #openstack-ironic | 19:30 | |
| *** ijw has quit IRC | 19:32 | |
| *** ijw has joined #openstack-ironic | 19:33 | |
| *** htrmeira has left #openstack-ironic | 19:36 | |
| *** ijw_ has quit IRC | 19:36 | |
| *** ijw has quit IRC | 19:39 | |
| *** dttocs has joined #openstack-ironic | 19:46 | |
| *** alex_xu has quit IRC | 19:48 | |
| *** alex_xu has joined #openstack-ironic | 19:49 | |
| *** dttocs has quit IRC | 19:50 | |
| *** ijw has joined #openstack-ironic | 19:50 | |
| openstackgerrit | Shilla Saebi proposed openstack/ironic: changes to upgrade-guide.rst https://review.openstack.org/174065 | 19:56 |
| *** Marga_ has joined #openstack-ironic | 20:02 | |
| *** dttocs has joined #openstack-ironic | 20:17 | |
| *** dttocs has quit IRC | 20:21 | |
| *** kkoski has quit IRC | 21:01 | |
| *** Marga_ has quit IRC | 21:05 | |
| *** dttocs has joined #openstack-ironic | 21:06 | |
| *** absubram has quit IRC | 21:10 | |
| *** Marga_ has joined #openstack-ironic | 21:10 | |
| *** dprince has quit IRC | 21:12 | |
| *** Sukhdev has joined #openstack-ironic | 21:13 | |
| *** Marga_ has quit IRC | 21:19 | |
| *** Marga_ has joined #openstack-ironic | 21:19 | |
| *** andreykurilin has joined #openstack-ironic | 21:25 | |
| *** achanda has quit IRC | 21:34 | |
| *** achanda has joined #openstack-ironic | 21:37 | |
| openstackgerrit | John L. Villalovos proposed openstack/ironic: ironic/tests/drivers/amt: Add autospec=True to mocks https://review.openstack.org/174113 | 21:37 |
| *** achanda has quit IRC | 21:37 | |
| *** achanda has joined #openstack-ironic | 21:38 | |
| TheJulia | Anyone seen issues cleaning a node with IPA? From the conductor log http://paste.openstack.org/show/uZ9wd5p7auUGn5MNl7gD/ | 21:38 |
| jroll | aw hell | 21:40 |
| jroll | TheJulia: we hit that but I thought it was a downstream shim we added | 21:41 |
| jroll | JoshNang: ^ :( | 21:41 |
| jroll | I'll put a patch up | 21:41 |
| jroll | but we'll need to backport it | 21:41 |
| TheJulia | jroll: :( | 21:41 |
| TheJulia | c'est la vie | 21:42 |
| *** trown is now known as trown|outttypeww | 21:42 | |
| JoshNang | :( yeah i thought that was downstream too | 21:42 |
| jroll | TheJulia: mind filing a bug in the meantime? | 21:43 |
| jroll | idk why I thought this was in our hack, wow | 21:43 |
| openstackgerrit | Jim Rollenhagen proposed openstack/ironic: Fix heartbeat when clean step in progress https://review.openstack.org/174115 | 21:43 |
| jroll | that should do it | 21:43 |
| TheJulia | jroll: sure | 21:45 |
| TheJulia | jroll: will in 2-3 minutes | 21:45 |
| jroll | yeah, no rush :) | 21:45 |
| jroll | actually, I'll just get it, no worries | 21:45 |
| *** jamielennox|away is now known as jamielennox | 21:46 | |
| *** andreykurilin has quit IRC | 21:46 | |
| openstackgerrit | Jim Rollenhagen proposed openstack/ironic: Fix heartbeat when clean step in progress https://review.openstack.org/174115 | 21:50 |
| jroll | ^ with a bug # | 21:50 |
| jroll | devananda: we're going to want to backport that to the RC, however that works (just push to stable/kilo?) | 21:50 |
| devananda | jroll: cheers. tag the bug with "kilo-rc-potential" pls | 21:55 |
| jroll | yep | 21:55 |
| devananda | jroll: https://wiki.openstack.org/wiki/StableBranch#Processes | 21:56 |
| jroll | done | 21:56 |
| jroll | aha, awesome, ty | 21:56 |
| jroll | well | 21:56 |
| devananda | note that the fix has to land on master first | 21:56 |
| jroll | my problem is I don't see stable/kilo branch, though maybe I'm doing something wrong here | 21:56 |
| devananda | jroll: proposed/kilo | 21:56 |
| jroll | aha | 21:57 |
| jroll | ty | 21:57 |
| devananda | np! | 21:57 |
| devananda | the permissions are the same -- only stable maintenance team & release mgmt team can approve them | 21:57 |
| devananda | and th eprocess is the same as documented up there ^ | 21:57 |
| jroll | yep | 21:57 |
| openstackgerrit | Jim Rollenhagen proposed openstack/ironic: Fix heartbeat when clean step in progress https://review.openstack.org/174115 | 21:58 |
| jroll | oh damn, I overwrote that | 21:58 |
| devananda | heh | 21:58 |
| jroll | and still didn't end up on proposed/kilo | 21:58 |
| devananda | gotta jump on a call, back in a while | 21:59 |
| TheJulia | jroll: cool, thank you, my lag just got REALLY bad... like... maybe time to get new internet connection bad | 21:59 |
| jroll | The branch 'proposed/kilo' does not exist on the given remote | 21:59 |
| jroll | 'gerrit'. If these changes are intended to start a new branch, re-run | 22:00 |
| jroll | with the '-R' option enabled. | 22:00 |
| jroll | hrmmmmmmm | 22:00 |
| jroll | TheJulia: :( no problem | 22:00 |
| TheJulia | It is just a s ign I need to call it an evening | 22:00 |
| mrda | Morning Ironic | 22:03 |
| mrda | (Sorry TheJulia, it's just morning, at least here :) | 22:03 |
| jroll | heya mrda :) | 22:04 |
| mrda | o/ | 22:05 |
| jroll | THERE we go | 22:08 |
| jroll | thanks for the announce openstackgerrit | 22:08 |
| jroll | devananda: backport is https://review.openstack.org/174122 | 22:09 |
| *** ijw has quit IRC | 22:18 | |
| *** ijw has joined #openstack-ironic | 22:20 | |
| *** ijw has quit IRC | 22:30 | |
| jxiaobin | shall we document "scheduler_use_baremetal_filters" of nova.conf in install-guide.rst? | 22:43 |
| jxiaobin | my understanding is if this option is not set, the scheduler will not go through the baremetal filters, am I right? | 22:44 |
| jroll | do we not document that? | 22:44 |
| jroll | because we should | 22:44 |
| jxiaobin | I didn't find that | 22:44 |
| jroll | :( | 22:45 |
| jxiaobin | I greped all the doc under deploy folder, none | 22:45 |
| jroll | can you send a patch or file a bug? :) | 22:46 |
| jxiaobin | sure | 22:46 |
| jxiaobin | for months, I've been running VM filters, until today I'm trying to fix this, and found the option in code :D | 22:47 |
| jroll | heh | 22:48 |
| jroll | I've been trained to always go to the code :) | 22:48 |
| *** achanda has quit IRC | 22:48 | |
| *** kbs1 has quit IRC | 22:49 | |
| *** Marga_ has quit IRC | 22:51 | |
| openstackgerrit | jxiaobin proposed openstack/ironic: document "scheduler_use_baremetal_filters" option in nova.conf https://review.openstack.org/174141 | 22:51 |
| jroll | jxiaobin: left a quick review :) | 22:53 |
| *** achanda has joined #openstack-ironic | 22:58 | |
| openstackgerrit | jxiaobin proposed openstack/ironic: document "scheduler_use_baremetal_filters" option in nova.conf https://review.openstack.org/174141 | 22:58 |
| jxiaobin | jroll: got it and updated :) | 22:59 |
| *** kbs has joined #openstack-ironic | 22:59 | |
| jroll | thanks :) | 22:59 |
| jroll | jxiaobin: could you add a new line before the new stuff? | 23:00 |
| *** yuanying has joined #openstack-ironic | 23:01 | |
| jxiaobin | jroll: ok | 23:01 |
| openstackgerrit | jxiaobin proposed openstack/ironic: document "scheduler_use_baremetal_filters" option in nova.conf https://review.openstack.org/174141 | 23:02 |
| openstackgerrit | John L. Villalovos proposed openstack/ironic: ironic/tests/drivers/drac: Add spec= & autospec=True https://review.openstack.org/174145 | 23:03 |
| *** Marga_ has joined #openstack-ironic | 23:03 | |
| *** yuanying has quit IRC | 23:03 | |
| jroll | thank you jxiaobin, +2 :) | 23:03 |
| *** yuanying has joined #openstack-ironic | 23:04 | |
| jxiaobin | thanks jroll! | 23:04 |
| *** Isotopp has quit IRC | 23:06 | |
| *** chlong has joined #openstack-ironic | 23:11 | |
| *** Sukhdev has quit IRC | 23:12 | |
| *** Marga_ has quit IRC | 23:13 | |
| *** Isotopp has joined #openstack-ironic | 23:15 | |
| *** Isotopp has quit IRC | 23:15 | |
| *** Isotopp has joined #openstack-ironic | 23:15 | |
| *** kbs has quit IRC | 23:22 | |
| *** Marga_ has joined #openstack-ironic | 23:23 | |
| *** dttocs_ has joined #openstack-ironic | 23:31 | |
| *** moshaile__ has joined #openstack-ironic | 23:33 | |
| *** tteggel_ has joined #openstack-ironic | 23:34 | |
| *** Shrews_ has joined #openstack-ironic | 23:35 | |
| *** HenryG_ has joined #openstack-ironic | 23:35 | |
| *** Haomeng|2 has joined #openstack-ironic | 23:36 | |
| *** Shrews has quit IRC | 23:36 | |
| *** Shrews_ is now known as Shrews | 23:36 | |
| *** mdbooth has quit IRC | 23:38 | |
| *** moshaile_ has quit IRC | 23:38 | |
| *** dttocs has quit IRC | 23:38 | |
| *** HenryG has quit IRC | 23:38 | |
| *** bigjools has quit IRC | 23:38 | |
| *** bigjools_ has joined #openstack-ironic | 23:38 | |
| *** Haomeng has quit IRC | 23:38 | |
| *** mdbooth_ has joined #openstack-ironic | 23:38 | |
| *** mdbooth_ is now known as mdbooth | 23:38 | |
| *** tteggel has quit IRC | 23:39 | |
| *** bigjools_ is now known as bigjools | 23:39 | |
| *** bigjools has quit IRC | 23:40 | |
| *** bigjools has joined #openstack-ironic | 23:40 | |
| *** Marga_ has quit IRC | 23:54 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!