NobodyCam | g'night jroll | 00:00 |
---|---|---|
NobodyCam | :) | 00:00 |
NobodyCam | non-worky: this kinda thing just upsets me :( http://www.bbc.com/news/world-us-canada-33695872 | 00:02 |
openstackgerrit | Josh Gachnang proposed openstack/ironic-python-agent: Add node param to base erase_block_device https://review.openstack.org/206766 | 00:02 |
JoshNang | ^ related to the hardware manager API breakage | 00:03 |
*** davideagnello has quit IRC | 00:05 | |
NobodyCam | JoshNang: voted ahead of test so I hope it passes :-p | 00:05 |
JoshNang | NobodyCam: :P thanks | 00:06 |
*** ijw has quit IRC | 00:12 | |
*** achanda has quit IRC | 00:15 | |
*** david-lyle has quit IRC | 00:24 | |
*** puranamr has joined #openstack-ironic | 00:31 | |
*** mtanino has quit IRC | 00:34 | |
*** naohirot has joined #openstack-ironic | 00:37 | |
*** puranamr has quit IRC | 00:43 | |
*** zhenguo has joined #openstack-ironic | 00:57 | |
*** meghal has quit IRC | 01:14 | |
*** r-daneel has quit IRC | 01:19 | |
*** rloo has quit IRC | 01:24 | |
openstackgerrit | Tan Lin proposed openstack/ironic: Migrate IronicObjectSerializer to subclass from oslo https://review.openstack.org/201038 | 01:26 |
*** chenglch has joined #openstack-ironic | 01:27 | |
*** Pradip has quit IRC | 01:31 | |
*** pal has joined #openstack-ironic | 02:02 | |
*** david-lyle has joined #openstack-ironic | 02:19 | |
*** david-lyle has quit IRC | 02:23 | |
openstackgerrit | Merged openstack/ironic-python-agent: Add node param to base erase_block_device https://review.openstack.org/206766 | 02:28 |
*** Qiming has joined #openstack-ironic | 02:28 | |
*** pal has quit IRC | 02:35 | |
*** achanda has joined #openstack-ironic | 02:37 | |
*** boris-42 has quit IRC | 02:40 | |
*** hakimo has joined #openstack-ironic | 02:51 | |
*** ukalifon has joined #openstack-ironic | 02:52 | |
*** hakimo_ has quit IRC | 02:53 | |
*** bizarrochristy has joined #openstack-ironic | 02:55 | |
*** bizarrochristy has quit IRC | 02:58 | |
*** bizarrochristy has joined #openstack-ironic | 02:58 | |
*** bizarrochristy has quit IRC | 03:12 | |
openstackgerrit | Shivanand Tendulker proposed openstack/ironic: grub2 bootloader support for uefi boot mode https://review.openstack.org/166192 | 03:18 |
*** ukalifon has quit IRC | 03:21 | |
*** coolsvap|away is now known as coolsvap | 03:26 | |
*** ramineni has joined #openstack-ironic | 03:28 | |
*** david-lyle has joined #openstack-ironic | 03:34 | |
*** pal has joined #openstack-ironic | 03:40 | |
*** sinval_ has quit IRC | 03:45 | |
openstackgerrit | OpenStack Proposal Bot proposed openstack/ironic: Updated from global requirements https://review.openstack.org/206815 | 03:46 |
openstackgerrit | OpenStack Proposal Bot proposed openstack/ironic-lib: Updated from global requirements https://review.openstack.org/206816 | 03:46 |
openstackgerrit | OpenStack Proposal Bot proposed openstack/ironic-python-agent: Updated from global requirements https://review.openstack.org/206817 | 03:46 |
*** ishant has joined #openstack-ironic | 03:48 | |
*** achanda has quit IRC | 03:55 | |
*** amotoki has joined #openstack-ironic | 03:56 | |
*** vishwanathj has joined #openstack-ironic | 04:10 | |
*** rameshg87 has joined #openstack-ironic | 04:32 | |
*** chenke has quit IRC | 04:33 | |
*** chenke has joined #openstack-ironic | 04:33 | |
*** puranamr has joined #openstack-ironic | 04:38 | |
*** davideagnello has joined #openstack-ironic | 04:51 | |
*** ukalifon has joined #openstack-ironic | 05:02 | |
*** ukalifon has quit IRC | 05:04 | |
*** ramineni1 has joined #openstack-ironic | 05:07 | |
*** ramineni has quit IRC | 05:09 | |
*** davideagnello has quit IRC | 05:12 | |
*** achanda has joined #openstack-ironic | 05:26 | |
rameshg87 | ramineni1: hi | 05:42 |
ramineni1 | rameshg87, hi , morning :) | 05:43 |
*** saripurigopi has joined #openstack-ironic | 05:43 | |
ramineni1 | rameshg87, have just seen your comment | 05:46 |
ramineni1 | rameshg87, but the endpoint is already there, we are just adding a pointer to it | 05:46 |
saripurigopi | morning Ironic | 05:46 |
*** puranamr has quit IRC | 05:51 | |
rameshg87 | ramineni1: yeah, but sometimes adding a new attribute requires micro-version bump-up too | 05:55 |
rameshg87 | ramineni1: just like https://review.openstack.org/#/c/193439/ , which starts accepting a node attribute as input | 05:55 |
rameshg87 | ramineni1: but I too don't know. in my opinion it's not required. it's a general rule followed now, that every change (breaking or non-breaking) in the api requires a micro version change. | 05:56 |
rameshg87 | ramineni1: wdyt ? | 05:56 |
ramineni1 | rameshg87, just wondering , this is not a new functionality as such like the ablove review, so not sure, if its actually required | 05:59 |
ramineni1 | rameshg87, may be we can wait for one more opinion on this :) | 05:59 |
rameshg87 | ramineni1: yeah | 06:00 |
rameshg87 | ramineni1: let's wait .. | 06:00 |
ramineni1 | rameshg87, :) | 06:00 |
SpamapS | TheJulia: sh: 1: debootstrap: not found ... | 06:06 |
SpamapS | cinerama: ^ | 06:06 |
SpamapS | Need to add that to the env setup. | 06:07 |
openstackgerrit | Ramakrishnan G proposed openstack/ironic: Add RAIDInterface for RAID configuration https://review.openstack.org/196003 | 06:11 |
*** chenke has quit IRC | 06:15 | |
openstackgerrit | Ramakrishnan G proposed openstack/ironic: Add RPCAPIs for RAID configuration https://review.openstack.org/196006 | 06:25 |
*** Nisha has joined #openstack-ironic | 06:27 | |
*** zhenguo has quit IRC | 06:32 | |
*** Marga_ has quit IRC | 06:36 | |
*** zhenguo has joined #openstack-ironic | 06:40 | |
*** Marga_ has joined #openstack-ironic | 06:40 | |
openstackgerrit | OpenStack Proposal Bot proposed openstack/ironic: Imported Translations from Transifex https://review.openstack.org/206903 | 06:40 |
openstackgerrit | Ramakrishnan G proposed openstack/ironic: Add APIs for RAID configuration https://review.openstack.org/196007 | 06:43 |
openstackgerrit | Gopi Krishna S proposed openstack/ironic: UCS: node-get-boot-device is failing for Cisco servers https://review.openstack.org/206528 | 06:49 |
*** Haomeng has joined #openstack-ironic | 06:51 | |
*** Haomeng|2 has quit IRC | 06:54 | |
*** achanda has quit IRC | 06:54 | |
*** karimb has joined #openstack-ironic | 06:57 | |
*** athomas has joined #openstack-ironic | 06:57 | |
*** achanda has joined #openstack-ironic | 06:57 | |
*** uggla_ has joined #openstack-ironic | 07:00 | |
*** davideagnello has joined #openstack-ironic | 07:13 | |
*** uggla_ has quit IRC | 07:14 | |
*** adam_g has quit IRC | 07:14 | |
*** davideagnello has quit IRC | 07:17 | |
*** karimb has quit IRC | 07:22 | |
*** karimb has joined #openstack-ironic | 07:23 | |
*** achanda has quit IRC | 07:27 | |
*** romainh has joined #openstack-ironic | 07:36 | |
*** dtantsur|afk is now known as dtantsur | 07:37 | |
dtantsur | Morning Ironic | 07:37 |
Nisha | dtantsur, o/ | 07:42 |
mrda | Morning dtantsur | 07:44 |
Nisha | dtantsur, i was trying inspector ramdisk manually. it reports disk size 1 less than the actual | 07:45 |
Nisha | dtantsur, i used the returned value as the root device hint and the deploy failed | 07:46 |
Nisha | dtantsur, i read the comments as " | 07:46 |
Nisha | # NOTE(dtantsur): -1 is required to give Ironic some spacing for partitioning and may be removed later | 07:46 |
Nisha | " | 07:46 |
Nisha | dtantsur, i think this is misleading from inspection results | 07:47 |
*** yog__ has joined #openstack-ironic | 07:47 | |
dtantsur | Nisha, if you don't do it, deploy will fail | 07:51 |
dtantsur | so yeah, it's not good, but without it we'll need to do this -1 manually | 07:51 |
Nisha | deploy in which scenario | 07:51 |
dtantsur | Nisha, any | 07:51 |
dtantsur | well, at least iscsi | 07:52 |
dtantsur | last time I checked our partitioner failed when local_gb was strictly equal to the disk size | 07:52 |
* dtantsur should probably mention it in some "known issues" section... | 07:52 | |
Nisha | i used the size returned by inspector ramdisk as root device hint, and deploy failed | 07:52 |
Nisha | but when i used exact integer size i.e. floating value dropped off, it works fine | 07:53 |
dtantsur | as root device hints - yes, probably. I'm not sure what to do about it... | 07:53 |
Nisha | dtantsur, means? the returned value would/could be used as root device hint | 07:54 |
dtantsur | yep, but you have to +1gib until we know how to solve problem with partitioner | 07:55 |
Nisha | hmmm | 07:55 |
*** ukalifon1 has joined #openstack-ironic | 07:55 | |
dtantsur | Nisha, for your reference: https://github.com/openstack-dev/devstack/blob/master/tools/ironic/scripts/create-node#L15-L17 | 07:56 |
dtantsur | we do it in devstack as well... | 07:56 |
*** pal has quit IRC | 07:59 | |
*** yog__ has quit IRC | 07:59 | |
*** natorious is now known as zz_natorious | 07:59 | |
Nisha | dtantsur, got it | 08:02 |
Nisha | i had set the local_gb to some arbitrary value for solving one issue, so was not using actual disk size in local_gb | 08:02 |
Nisha | but in ilo drivers we dont do this ...and using the inspection result works.... | 08:04 |
Nisha | am just wondering if its specific to some drivers...or applies to all | 08:05 |
Nisha | need to recheck | 08:05 |
*** jistr has joined #openstack-ironic | 08:08 | |
*** ndipanov has quit IRC | 08:14 | |
*** ndipanov has joined #openstack-ironic | 08:14 | |
openstackgerrit | Ramakrishnan G proposed openstack/ironic: Add support for inband raid configuration agent ramdisk https://review.openstack.org/198238 | 08:16 |
openstackgerrit | Ramakrishnan G proposed openstack/ironic: Refactor agent driver with pxe boot interface https://review.openstack.org/166521 | 08:16 |
rameshg87 | dtantsur: hi | 08:16 |
*** yog__ has joined #openstack-ironic | 08:16 | |
rameshg87 | dtantsur: https://review.openstack.org/#/c/206487/1/specs/liberty/ironic-ml2-integration.rst L87, I didn't get the comment #2 | 08:17 |
*** lucasagomes has joined #openstack-ironic | 08:17 | |
*** karimb has quit IRC | 08:17 | |
dtantsur | rameshg87, 1. "out of band BMC" seems self-repeating, 2. virtual media boot is not a netboot IMO | 08:18 |
*** ifarkas has joined #openstack-ironic | 08:18 | |
rameshg87 | dtantsur: I got the first one. | 08:19 |
rameshg87 | dtantsur: but virtual media is a sort of "netboot", right ? | 08:19 |
dtantsur | hmmm, no? | 08:19 |
rameshg87 | dtantsur: we make the machine boot from an external source in your network | 08:19 |
dtantsur | does it use PXE? | 08:19 |
rameshg87 | dtantsur: ah, pxe == netboot, seems too much restrictive to me | 08:20 |
rameshg87 | dtantsur: it's our term | 08:20 |
rameshg87 | dtantsur: but still in virtual media we boot the machine from an external source in the network | 08:20 |
dtantsur | I mean, yeah, in some sense it is netboot, but for many people netboot is related to the machine fetching something from network on start up, not out-of-band | 08:20 |
rameshg87 | dtantsur: eh "fetching something from network on start up" is applicable and true here as well | 08:21 |
dtantsur | rameshg87, so it would be cool if you avoid calling it netboot, just stating that it's still possible to use virtual media boot with some drivers | 08:21 |
dtantsur | I just don't want people to read it as "some drivers allow PXE to work" :) | 08:21 |
rameshg87 | dtantsur: okay, got it. but in general, all over ironic, notion of "netboot" applies to pxe and virtual media booting | 08:22 |
rameshg87 | dtantsur: for example if someone requests "netboot" as "true" in flavor in nova, you get a node that boots from virtual media | 08:22 |
dtantsur | interesting. then fine, you can call it "netboot", but it's worth adding something like "because virtual media boot does not need an instance to access conductor on boot" | 08:24 |
dtantsur | or something | 08:24 |
rameshg87 | dtantsur: ack, thanks | 08:30 |
rameshg87 | will add it | 08:30 |
*** ramineni1 has quit IRC | 08:32 | |
lucasagomes | rameshg87, hi there | 08:33 |
rameshg87 | lucasagomes: hi | 08:34 |
lucasagomes | rameshg87, re lazy delete instance | 08:34 |
lucasagomes | rameshg87, what you suggest to remove the periodic task? | 08:34 |
openstackgerrit | Ramakrishnan G proposed openstack/ironic-specs: Update neutron integration spec https://review.openstack.org/206487 | 08:34 |
lucasagomes | without having a racy code | 08:34 |
*** romcheg has joined #openstack-ironic | 08:34 | |
rameshg87 | lucasagomes: I don't know if what I proposed was a good one | 08:35 |
rameshg87 | lucasagomes: if we are a non-stable state, someone is actually holding a lock on the system | 08:35 |
lucasagomes | rameshg87, oh at the process_event()? | 08:35 |
lucasagomes | but that's racy | 08:35 |
lucasagomes | because between the check of the flag | 08:36 |
lucasagomes | and the actual change of state there's a window there | 08:36 |
rameshg87 | hmm..yeah | 08:36 |
rameshg87 | but first in any case, if we are having a new field in the db, we will need to update it without a lock | 08:37 |
rameshg87 | but advantage with periodic task is if it missed first time, it can do it second time, right ? | 08:37 |
*** ukalifon1 has quit IRC | 08:37 | |
lucasagomes | exactly | 08:37 |
lucasagomes | we guarantee that it's going to be deleted eventually | 08:37 |
lucasagomes | and we won't end up with a orhpan node that was suppose to be deleted but wasn't because the code is racy | 08:38 |
*** ramineni1 has joined #openstack-ironic | 08:38 | |
rameshg87 | lucasagomes: ack, I agree. I will just rethink, please ignore my comment till then | 08:39 |
lucasagomes | rameshg87, it's ok... let's think | 08:39 |
lucasagomes | rameshg87, I think it would be useful to have a generic thing | 08:39 |
lucasagomes | but there are some differences | 08:39 |
rameshg87 | lucasagomes: yeah, I thought we might have something similar for other things as well | 08:39 |
rameshg87 | lucasagomes: when we have interactive clients (other than nova), talking to ironic | 08:40 |
rameshg87 | lucasagomes: particularly when we have stuffs like ui coming up | 08:40 |
*** e0ne has joined #openstack-ironic | 08:40 | |
rameshg87 | the same thing might be applicable to all other *ING states as well | 08:40 |
lucasagomes | rameshg87, right | 08:41 |
lucasagomes | I replied to the comment | 08:41 |
lucasagomes | rameshg87, as you suggest we may want to call that field somewhat more generic, what about "abort_operation"? | 08:41 |
lucasagomes | but even then there're some differneces, a node in DEPLOY* are expect to transition to AVAILABLE after abort | 08:42 |
lucasagomes | states like CLEANING they need to stay at CLEANFAIL and not restart cleaning again | 08:42 |
*** athomas has quit IRC | 08:42 | |
lucasagomes | there are different behaviors when aborting states | 08:43 |
*** e0ne has quit IRC | 08:43 | |
lucasagomes | that's why I decided to minimize the scope for that spec and fix the interaction with nova firtst | 08:43 |
lucasagomes | first* | 08:43 |
lucasagomes | also other states will need a new API verb for it, "deleted" can't be used for cleaning, inspecting or zapping because deleting an isntance at those states makes no sense | 08:44 |
lucasagomes | it's expected to the instance to be deleted already | 08:44 |
rameshg87 | lucasagomes: yeah, but making it even abort_operation is tougher there, right ? | 08:46 |
rameshg87 | lucasagomes: because the periodic task (or whatever) which checks this flag has to decide what to do with the node | 08:46 |
rameshg87 | lucasagomes: if node in states.X, do A; if node in states.Y do B; etc, right ? | 08:47 |
rameshg87 | lucasagomes: yeah, avoiding race condition seems tougher without a periodic task :( | 08:48 |
lucasagomes | rameshg87, exactly | 08:48 |
lucasagomes | it's hard that's why I limited the scope | 08:48 |
lucasagomes | currently the nova interaction is biting me. We use heat that talks to nova that talks to Ironic | 08:49 |
lucasagomes | when the heat stack fails it tries to delete the instances in nova to rollback | 08:49 |
lucasagomes | which makes nova calls Ironic when nodes are still being deployed | 08:49 |
lucasagomes | and things goes mad there | 08:49 |
lucasagomes | so I limited the scope of that patch to fix it | 08:49 |
lucasagomes | rameshg87, I believe the generic 'abort' will be something else, as I mentioned it needs more than that. A new API call etc | 08:50 |
lucasagomes | so it may have it's own mechanism | 08:50 |
rameshg87 | lucasagomes: okay | 08:52 |
* rameshg87 needs to look at abort spec | 08:52 | |
lucasagomes | rameshg87, right so should I rename the field to abort_operation? and then in another spec we can reuse it for other tasks? | 08:53 |
lucasagomes | I think it's ok | 08:53 |
rameshg87 | lucasagomes: but abort_operation turns out to be "delete" for DEPLOYING and "abort" for other *ING, right ? | 08:55 |
lucasagomes | rameshg87, yeah that's what sucks :-( | 08:55 |
lucasagomes | ok let's keep delete_instance cause it's specific | 08:55 |
*** pelix has joined #openstack-ironic | 08:55 | |
rameshg87 | lucasagomes: yeah, even I don't have a better opinion on that. let's keep it delete_instance until we all agree we have something better. | 08:55 |
lucasagomes | rameshg87, ++ | 08:56 |
lucasagomes | fair enuff... rameshg87 thanks for the discussion! | 08:56 |
rameshg87 | lucasagomes: thanks :) | 08:56 |
*** pal has joined #openstack-ironic | 08:57 | |
*** coolsvap is now known as coolsvap|away | 09:04 | |
*** amotoki has quit IRC | 09:05 | |
*** dtantsur is now known as dtantsur|brb | 09:12 | |
*** coolsvap|away is now known as coolsvap | 09:12 | |
*** ftersin has joined #openstack-ironic | 09:14 | |
*** athomas has joined #openstack-ironic | 09:16 | |
openstackgerrit | Shivanand Tendulker proposed openstack/ironic: Secure boot support for pxe_ilo driver https://review.openstack.org/154808 | 09:18 |
*** ftersin has left #openstack-ironic | 09:22 | |
*** alexpilotti has joined #openstack-ironic | 09:25 | |
*** romcheg has quit IRC | 09:27 | |
-openstackstatus- NOTICE: Currently our CI system is broken, jobs are not getting processed at all. | 09:28 | |
*** ChanServ changes topic to "Currently our CI system is broken, jobs are not getting processed at all." | 09:28 | |
*** MattMan has quit IRC | 09:31 | |
*** romcheg has joined #openstack-ironic | 09:31 | |
*** MattMan has joined #openstack-ironic | 09:32 | |
*** romainh has left #openstack-ironic | 09:37 | |
*** yuikotakada has joined #openstack-ironic | 09:38 | |
*** romainh has joined #openstack-ironic | 09:39 | |
openstackgerrit | Naohiro Tamura proposed openstack/ironic: Add hardware inspection module for iRMC driver https://review.openstack.org/196480 | 09:42 |
*** chenglch has quit IRC | 09:43 | |
*** mdbooth has quit IRC | 09:46 | |
*** mdbooth has joined #openstack-ironic | 09:47 | |
*** alex_xu has quit IRC | 09:48 | |
*** alex_xu has joined #openstack-ironic | 09:49 | |
*** coolsvap is now known as coolsvap|away | 09:50 | |
ramineni1 | dtantsur|brb, lucasagomes , any comments on this https://review.openstack.org/#/c/203921/ | 09:53 |
ramineni1 | dtantsur|brb, lucasagomes , do we need a micro version bump on this? | 09:53 |
lucasagomes | rameshg87, hi there... we according to what we are following right now yes | 09:55 |
lucasagomes | everytime we change the syntax of the API (adding new thing, removing etc...) we should bump the version | 09:55 |
*** naohirot has quit IRC | 09:56 | |
*** Qiming has quit IRC | 09:56 | |
*** e0ne has joined #openstack-ironic | 09:57 | |
*** coolsvap|away is now known as coolsvap | 09:58 | |
rameshg87 | lucasagomes: yeah, that's what I thought | 09:59 |
rameshg87 | lucasagomes: so I think in ramineni1's case we should do it | 10:00 |
lucasagomes | rameshg87, but I don't get much that change, why it's adding it only to properties? | 10:00 |
lucasagomes | I mean other controllers like Node has plenty of endpoints like that | 10:00 |
*** ifarkas has quit IRC | 10:00 | |
*** thiagop has quit IRC | 10:00 | |
*** mjturek1 has quit IRC | 10:00 | |
*** yuriyz has quit IRC | 10:00 | |
*** mitz has quit IRC | 10:00 | |
*** yuanying has quit IRC | 10:00 | |
*** dguerri` has quit IRC | 10:00 | |
*** mitz has joined #openstack-ironic | 10:00 | |
*** yuriyz has joined #openstack-ironic | 10:00 | |
*** thiagop has joined #openstack-ironic | 10:00 | |
*** ifarkas has joined #openstack-ironic | 10:01 | |
*** yuanying has joined #openstack-ironic | 10:01 | |
*** dguerri` has joined #openstack-ironic | 10:01 | |
*** dguerri` is now known as dguerri | 10:01 | |
*** dguerri has joined #openstack-ironic | 10:01 | |
rameshg87 | lucasagomes: hmm..that's true | 10:01 |
*** mjturek1 has joined #openstack-ironic | 10:01 | |
lucasagomes | nodes/<uuid>/states, nodes/<uuid>/validate | 10:01 |
lucasagomes | and more nested ones | 10:01 |
lucasagomes | like nodes/<uuid>/states/power | 10:01 |
lucasagomes | etc... | 10:01 |
rameshg87 | lucasagomes: but is there some recommendation on what all to provide links ? | 10:02 |
*** e0ne_ has joined #openstack-ironic | 10:02 | |
rameshg87 | lucasagomes: I understand we gave for ports as it's another type of resources that a node composes | 10:02 |
lucasagomes | yeah we link the resource itself and the subresources | 10:02 |
lucasagomes | the endpoints are documented | 10:03 |
lucasagomes | we should have a schema on the API etc | 10:04 |
*** pelix1 has joined #openstack-ironic | 10:04 | |
*** pelix has quit IRC | 10:04 | |
*** pelix1 is now known as pelix | 10:04 | |
rameshg87 | lucasagomes: I don't have an idea someone will be using these links, when they can basically code it to find it | 10:04 |
*** pelix has quit IRC | 10:04 | |
*** pelix has joined #openstack-ironic | 10:04 | |
rameshg87 | lucasagomes: links like /v1/drivers/foo/properties | 10:04 |
rameshg87 | when someone knows it is documented in the API, they will make 2 REST calls to first GET on /v1/drivers/foo and then find link and then go there | 10:05 |
*** e0ne has quit IRC | 10:05 | |
*** athomas has quit IRC | 10:05 | |
*** e0ne_ is now known as e0ne | 10:06 | |
*** athomas has joined #openstack-ironic | 10:06 | |
rameshg87 | lucasagomes: but for nested endpoints, links can be further provided within, right ? | 10:07 |
rameshg87 | lucasagomes: you might wanna take a look at this too - https://review.openstack.org/#/c/205895/ | 10:07 |
lucasagomes | rameshg87, yeah I think what we want to make it all discoverable programatically like that is having a json schema | 10:07 |
lucasagomes | not exposes links | 10:07 |
*** Nisha has quit IRC | 10:08 | |
*** Pradeep has joined #openstack-ironic | 10:12 | |
*** Pradeep has quit IRC | 10:12 | |
*** PradeepV has joined #openstack-ironic | 10:12 | |
*** zhenguo has quit IRC | 10:13 | |
PradeepV | Hi All, | 10:14 |
PradeepV | my ironic node provision state is in cleaning state and i am not able to delete it, getting error as "InvalidState: Can not delete node "b56c24cd-f19c-4da2-a123-b6b0b52162f3" while it is in provision state "cleaning"." | 10:14 |
PradeepV | how to delete the ironic node | 10:15 |
rcarrillocruz | PradeepV: you will have to change its state on the mysql DB | 10:16 |
rcarrillocruz | to available | 10:16 |
rcarrillocruz | prior to being able to delete | 10:16 |
rcarrillocruz | run something like: | 10:16 |
lucasagomes | PradeepV, yeah currently nodes can get stuck on those transitioning states, which is pretty bad | 10:16 |
lucasagomes | we are trying to sort it out by introducing things like CLEANWAIT (already merged) | 10:16 |
rcarrillocruz | sudo mysql ironic -e "update nodes set provision_state='available' where uuid='your_server_uuid'" | 10:17 |
rcarrillocruz | then you'll be able to do ironic node-delete uuid | 10:17 |
lucasagomes | but yeah right now you will need to clean the db unfortunately | 10:17 |
*** degorenko has quit IRC | 10:17 | |
PradeepV | Thank you Carrill it worked... | 10:19 |
PradeepV | lucasagomes..why is it getting stuck in that state | 10:20 |
*** romainh has quit IRC | 10:20 | |
lucasagomes | PradeepV, because the conductor doesn't know how to resume if something fails | 10:20 |
lucasagomes | and we don't offer any API so you can get out of that state | 10:21 |
lucasagomes | like aborting that operation for e.g | 10:21 |
PradeepV | ok lucasagomes, thank you | 10:21 |
*** dtantsur|brb is now known as dtantsur | 10:30 | |
dtantsur | oh, gate is broken again.... | 10:36 |
sambetts | dtantsur: yup | 10:36 |
sambetts | dtantsur: its not doing very well at the moment at being stable | 10:36 |
dtantsur | sigh... I guess openstack upstream has grown too large | 10:37 |
lucasagomes | dtantsur, https://github.com/openstack/ironic/blob/master/ironic/conductor/manager.py#L804-L817 | 10:39 |
lucasagomes | dtantsur, unless one changes the database it won't be possible to the instance_info to not be cleaned there | 10:39 |
dtantsur | lucasagomes, ok, nevermind me then. I'll review properly a bit later. | 10:40 |
lucasagomes | ack | 10:40 |
dtantsur | tbh I spent so much time thinking about versioning, so I can hardly think about anything | 10:40 |
lucasagomes | heh fair enuff | 10:40 |
dtantsur | and now this enroll discussion... I regret I even bothered with this enroll change | 10:41 |
lucasagomes | dtantsur, well do not. Cause I think we agreed the problem is not the enroll | 10:42 |
lucasagomes | but how we version stuff | 10:42 |
lucasagomes | enroll just made it more apparently because now we have to deal with it | 10:42 |
dtantsur | I'm not sure deva agrees with it | 10:42 |
lucasagomes | enroll is part of the spec as the entry point for the state machine since it started | 10:43 |
lucasagomes | and was approved like that | 10:43 |
*** Qiming has joined #openstack-ironic | 10:43 | |
dtantsur | yep. several times. | 10:43 |
dtantsur | and we really need it. *at least* because we need verification step. | 10:43 |
sambetts | and I want to use Enroll too | 10:44 |
*** Qiming has left #openstack-ironic | 10:44 | |
sambetts | the think I've noticed is all these discussions revolve around existing users, and seem to ignore that new users just want the full feature set as it is without having to "opt-in" | 10:45 |
dtantsur | these discussions didn't get users involved at all :-/ | 10:46 |
dtantsur | we just *assume* we know what users want | 10:46 |
sambetts | ironic is a weird one anyway because the users of ironic aren't the same as the users in the OpenStack sense | 10:47 |
dtantsur | (I don't state that our assumption is wrong obviously, just pointing out) | 10:47 |
sambetts | :-P yes | 10:47 |
*** thrash|g0ne is now known as thrash | 10:48 | |
sambetts | imo (ignore the standalone case) users talk to ironic through something like nova, and ops talk directly to ironic | 10:48 |
dtantsur | for example about versioning: I didn't receive an answer to my question "how should inspector deal with ironic API versioning" | 10:48 |
dtantsur | I'm an API user, and I still don't know | 10:48 |
dtantsur | or rather I don't understand. all cases look pretty bad to me. | 10:49 |
dtantsur | with enroll it's a bit easier: I don't want give another opportunity to mess enrolling a node, some people do it often enough | 10:49 |
sambetts | yeah :/ while I was reading the thread this morning, I relised how much I hate calling the client the client | 10:49 |
dtantsur | ok, I'm repeating myself :) | 10:50 |
sambetts | I don't think we should think of it as a client, but as a python API hook and as an api command line interface (which is what CLI means...) which means the version your using should be dictated by the server your talking to | 10:52 |
dtantsur | sambetts, I think you should add your opinion to the ML thread, so that it's not get lost here | 10:52 |
sambetts | I wanted to bounce it off you first ;) | 10:53 |
dtantsur | well, I kind of agree that our stuff should be a thin layer on the way to the server | 10:53 |
*** coolsvap is now known as coolsvap|away | 10:55 | |
lucasagomes | dtantsur, perhaps inspector should use a specific version of the API? and require it? | 10:57 |
lucasagomes | or support X versions of the API | 10:57 |
dtantsur | lucasagomes, we don't have notion of supporting "X versions" | 10:58 |
lucasagomes | X = in the plural I mean | 10:58 |
dtantsur | we can request one version, and fail if it's not available | 10:58 |
lucasagomes | dtantsur, yeah say, right now to inspect a node you need the version 1.10 of the API | 10:58 |
lucasagomes | so all calls that inspector does to Ironic should use that version | 10:58 |
dtantsur | yeah, maybe... | 10:59 |
lucasagomes | dtantsur, right that's like inspector being the client of our API | 10:59 |
lucasagomes | it's the same as we say "client should mandatory indicate the version" | 10:59 |
lucasagomes | inspection could have a set of supported versions that it has been tested with | 10:59 |
dtantsur | lucasagomes, but when Juno was supported by discoverd, it was a bit bigger problem | 10:59 |
lucasagomes | and user can chose between those | 10:59 |
lucasagomes | dtantsur, right yeah because there was no versioning at that time | 11:00 |
dtantsur | I can't have a set of supported versions. the only version supported is version I gate tests against | 11:00 |
lucasagomes | dtantsur, fair enuff... Inspector can require a specific version of the API to work with | 11:01 |
lucasagomes | or at least a fallback to the very minimal version | 11:01 |
lucasagomes | 1.1 | 11:01 |
lucasagomes | that was is good because you make inspector to always work independent of how the Ironic API grows | 11:01 |
lucasagomes | idk it seems analogous to say, this software requires lib version X... you can say inspector requires Ironic API version X too | 11:02 |
lucasagomes | (just an idea) | 11:02 |
dtantsur | if I hardcode 1.2 (we need to know about AVAILABLE), then I afraid it will break sambetts' plugin that requires ENROLL | 11:04 |
dtantsur | (not sure if this plugin already exists) | 11:04 |
sambetts | dtantsur: not yet, but its on my to do list | 11:04 |
dtantsur | I see | 11:04 |
dtantsur | lucasagomes, btw we don't hide current node state even if it's not supported by the API, do we? | 11:05 |
* dtantsur writes docs on API versioning | 11:06 | |
lucasagomes | dtantsur, yeah as requiremets grow you can require new versions of the API or disable that feature when the API is not newer enough | 11:06 |
lucasagomes | dtantsur, I think it gets translated yes | 11:06 |
dtantsur | lucasagomes, all states? like MANAGEABLE, INSPECTING, etc? | 11:07 |
lucasagomes | at least AVAILABLE -> NOSTATE | 11:07 |
*** Haomeng|2 has joined #openstack-ironic | 11:07 | |
dtantsur | I hope it's the only one actually | 11:07 |
lucasagomes | oh yeah I think that's the only one | 11:07 |
*** athomas has quit IRC | 11:08 | |
lucasagomes | yeah I'm not advocating on feature hiding here... but just that you can get some stability by making inspector to explicitly support a version (or some versions) of the Ironic API | 11:08 |
lucasagomes | at least for the basic functionality | 11:09 |
dtantsur | yeah, I think so | 11:09 |
*** Haomeng has quit IRC | 11:10 | |
lucasagomes | that would also allow you to have a clear path for upgrades... 1. upgrade ironic 2. upgrade inspector | 11:10 |
lucasagomes | at all times | 11:10 |
lucasagomes | with the guaarantee that an older version of inspector will continue to work while ironic is being updated across the cluster | 11:11 |
lucasagomes | (and mixed versions of Ironic may be present at one time) | 11:11 |
lucasagomes | anyway... food for thought | 11:12 |
*** romainh has joined #openstack-ironic | 11:14 | |
PradeepV | I am able to boot up an instance using pxe boot, but the ssame setup is failing when booting an instance using agent driver , getting error as "2015-07-29 16:12:36.310 ^[[01;31mERROR nova.openstack.common.loopingcall [^[[00;36m-^[[01;31m] ^[[01;35m^[[01;31min fixed duration looping call" | 11:17 |
* rameshg87 goes home | 11:18 | |
*** rameshg87 has quit IRC | 11:18 | |
*** e0ne has quit IRC | 11:25 | |
TheJulia | SpamapS: Wow you were up late... | 11:25 |
TheJulia | Good morning everyone | 11:26 |
*** romcheg has quit IRC | 11:28 | |
dtantsur | TheJulia, morning | 11:29 |
sambetts | morning TheJulia | 11:31 |
lucasagomes | TheJulia, good morning | 11:32 |
*** ramineni1 has quit IRC | 11:32 | |
lucasagomes | PradeepV, the message is not very helpful | 11:32 |
lucasagomes | I will grab a quick sandwich and I can try helping out once I'm back | 11:33 |
*** lucasagomes is now known as lucas-hungry | 11:33 | |
*** e0ne has joined #openstack-ironic | 11:35 | |
openstackgerrit | Dmitry Tantsur proposed openstack/ironic: Document API versioning https://review.openstack.org/206999 | 11:36 |
dtantsur | lucas-hungry, jroll, devananda and others: please review ^^ I tried to capture the current state of things | 11:37 |
PradeepV | I will lucasagomes, | 11:37 |
*** pal has quit IRC | 11:37 | |
TheJulia | PradeepV: Realistically we would need logs and insight into the different node configurations that is present with each driver loaded | 11:38 |
* TheJulia sips more coffee | 11:38 | |
*** saripurigopi has quit IRC | 11:38 | |
sambetts | TheJulia: I'm just going through it with him on IM, its weird as hell :-P | 11:41 |
*** Haomeng has joined #openstack-ironic | 11:42 | |
TheJulia | sambetts: Joy :) | 11:42 |
*** Haomeng|2 has quit IRC | 11:45 | |
* sambetts thinks coffee might be a good idea | 11:49 | |
*** coolsvap|away is now known as coolsvap | 11:51 | |
TheJulia | Yes, coffee is a very good idea | 11:52 |
*** athomas has joined #openstack-ironic | 11:56 | |
*** e0ne has quit IRC | 11:59 | |
*** pal has joined #openstack-ironic | 12:03 | |
*** ukalifon has joined #openstack-ironic | 12:06 | |
openstackgerrit | Sinval Vieira Mendes Neto proposed openstack/ironic: Add more info level log to deploy_utils.work_on_disk() method https://review.openstack.org/205387 | 12:07 |
*** pal has quit IRC | 12:07 | |
dtantsur | lucas-hungry, one thing that prevents me from requiring ironic API version 1.2 (or many other) is that it is not (and was not ever) gate tested | 12:08 |
*** sinval_ has joined #openstack-ironic | 12:09 | |
*** jjohnson2 has joined #openstack-ironic | 12:17 | |
*** coolsvap is now known as coolsvap|away | 12:17 | |
*** romcheg has joined #openstack-ironic | 12:19 | |
openstackgerrit | Dmitry Tantsur proposed openstack/ironic-inspector: Require ironic API version 1.6 https://review.openstack.org/207018 | 12:24 |
dtantsur | lucas-hungry, also ^^ | 12:24 |
*** e0ne has joined #openstack-ironic | 12:25 | |
*** vikas has joined #openstack-ironic | 12:30 | |
*** mjturek1 has quit IRC | 12:31 | |
NobodyCam | good morning Ironicers, from the man making kofi | 12:33 |
*** ishant has quit IRC | 12:36 | |
sambetts | o/ NobodyCam | 12:37 |
*** kkoski has joined #openstack-ironic | 12:38 | |
*** lucas-hungry is now known as lucasagomes | 12:38 | |
lucasagomes | dtantsur, cool! Yeah, tempest have no notion of microversioning AFAICT right now | 12:39 |
lucasagomes | that should change | 12:39 |
dtantsur | lucasagomes, https://review.openstack.org/#/c/166386 :) | 12:39 |
lucasagomes | NobodyCam, morning | 12:39 |
dtantsur | NobodyCam, morning! | 12:39 |
lucasagomes | yup! o/ | 12:40 |
vikas | Hi Guys..I have installed all-in-one ironic enabled devstack .When I am trying to launch a image on virtual baremetal node,I can see on vnccosole that rernel and ramdisk images are downloaded successfully but it doesnt go further after that and server state on dashboard get stuck at "spawning".Please suggest me something where could be the problem and how can i debug this? | 12:40 |
vikas | Help please | 12:40 |
NobodyCam | mornig lucasagomes dtantsur TheJulia sambetts | 12:41 |
lucasagomes | vikas, the console is redirected to a file at /opt/stack/ironic-bm-logs/baremetalbrbm_0_console.log | 12:41 |
lucasagomes | you can do a tail -f there and see it booting | 12:42 |
lucasagomes | or see a more specific error | 12:42 |
NobodyCam | vikas: what state is the node in "wait for call back"? | 12:42 |
* NobodyCam gets coffee | 12:43 | |
vikas | yes in ir-cond logs , after a long time it changes state from "wait-for-call-back" to "fail" | 12:43 |
vikas | using vnc console i can see node fetching images from tftp server | 12:43 |
lucasagomes | vikas, yeah check the file where the console is being redirect to see what's going on there | 12:44 |
vikas | after fetching ramdisk it says "ready" | 12:44 |
vikas | and thats it | 12:44 |
vikas | ok.. | 12:44 |
vikas | will get back | 12:45 |
lucasagomes | or you can disbale the redirection by removing the "console=ttyS0" kernel option from the "pxe_append_params" configuration option at /etc/ironic/ironic.conf | 12:45 |
lucasagomes | then restart the conductor | 12:45 |
lucasagomes | and restart the deployment | 12:45 |
vikas | ok.. will try this also | 12:45 |
vikas | Thanks.. :) | 12:46 |
lucasagomes | cool | 12:46 |
openstackgerrit | Dmitry Tantsur proposed openstack/ironic: Only take exclusive lock in sync_power_state if node is updated https://review.openstack.org/202562 | 12:46 |
*** mjturek1 has joined #openstack-ironic | 12:46 | |
lucasagomes | folks if you guys have a time https://review.openstack.org/#/c/205142/ (deprecate bash ramdisk) | 12:46 |
*** afaranha has quit IRC | 12:47 | |
*** coolsvap|away is now known as coolsvap | 12:48 | |
*** 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" | 12:50 | |
-openstackstatus- NOTICE: zuul's disks were at capacity. Space has been freed up and jobs are being re-queued. | 12:50 | |
*** pal has joined #openstack-ironic | 12:54 | |
openstackgerrit | Lucas Alvares Gomes proposed openstack/ironic-specs: Lazy delete instances https://review.openstack.org/204162 | 12:55 |
NobodyCam | lucasagomes: do you know if the DIB IPA element still requires over three gig of ram? | 12:55 |
lucasagomes | folks if you guys have a time ^ as well | 12:55 |
lucasagomes | NobodyCam, hi there, hmm I don't know the current state of it exactly | 12:55 |
lucasagomes | trown, ^ you have been testing it right? | 12:56 |
NobodyCam | my fear (maybe unfounded) is that we may lose support for unber powered test nodes.. ie if they only have 1 gig of ram | 12:57 |
lucasagomes | NobodyCam, the coreos version of IPA works with 1GB ram | 12:57 |
lucasagomes | that's what we use in gate to test | 12:57 |
dtantsur | ++ | 12:57 |
NobodyCam | ++ | 12:58 |
sambetts | Sigh... outlook and openstack mailers don't play nice together... its butchered my reply to the versioning thread... | 12:58 |
TheJulia | lucasagomes: coreos deploying via iscsi? or downloading the image | 12:59 |
TheJulia | ? | 12:59 |
lucasagomes | sambetts, heh do not use outlook :-) (jk, you can use whatever u want) | 12:59 |
lucasagomes | TheJulia, both | 12:59 |
lucasagomes | TheJulia, IPA (the service) supports both | 12:59 |
sambetts | lucasagomes: its only my work mail that goes through it ;) | 12:59 |
lucasagomes | and both are tested on gate | 12:59 |
dtantsur | well, image download has its restrictions | 12:59 |
lucasagomes | TheJulia, gate-tempest-dsvm-ironic-pxe_ipa - Tests IPA with ISCSI | 13:00 |
*** vikas_ has joined #openstack-ironic | 13:00 | |
lucasagomes | TheJulia, gate-tempest-dsvm-ironic-agent_ssh - Tests IPA with agent | 13:00 |
lucasagomes | I know the names are horrible... | 13:00 |
trown | NobodyCam: lucasagomes, checking how much memory my test VMs have | 13:00 |
dtantsur | our usual default is 4GiB IIRC | 13:01 |
trown | well they have 4GB each, since I have been testing in the context of tripleo | 13:01 |
TheJulia | I know, thats what I thought, that it had to be iscsi since downloading a 300mb image requires tons of ram to get pushed out to disk | 13:01 |
lucasagomes | vikas, so if you tftp is running on a different server | 13:02 |
lucasagomes | vikas, you have to configure the "tftp_server" configuration option at /etc/ironic/ironic.conf to point to it | 13:02 |
vikas_ | my tftp server is 10.0.0.4 | 13:02 |
vikas_ | yes its this ip only | 13:02 |
vikas_ | 10.0.0.4 in ironic.conf | 13:03 |
lucasagomes | there are two options related to tftp in Ironic "tftp_server" and "tftp_root" | 13:03 |
vikas_ | and bm node downloading pxelinux.0 from 10.0.0.4 on;y | 13:03 |
lucasagomes | the root is the root directory of the tftp, this should be accesible to the ironic-conductor | 13:03 |
lucasagomes | vikas, oh right so the tftp doesn't seem to be a problem here | 13:04 |
lucasagomes | vikas, I see "curl: (7) Failed to connect to 127.0.0.1 port 6385: Connection refused" | 13:04 |
lucasagomes | this seems to be the agent trying to access the Ironic API | 13:04 |
vikas_ | ok | 13:04 |
lucasagomes | can you check if you have any firewall rules blocking a tcp connection to the port 6385 ? | 13:04 |
lucasagomes | TheJulia, yeah the agent_ssh uses the cirros image | 13:05 |
lucasagomes | which is ~30MB I think | 13:05 |
vikas_ | but how can this bm node which is a vm reach 127.0.0.1 of underlying host | 13:05 |
lucasagomes | so it's grand... TheJulia but in the future IPA should stream the image and not 1. download then 2.write to the disk | 13:06 |
vikas_ | my internal network is 50.0.0.0/24 | 13:06 |
lucasagomes | vikas, it should be fine, your testing with nested VMs? | 13:06 |
lucasagomes | the VM being deployed is running at the same server as the Ironic services, right? | 13:07 |
TheJulia | lucasagomes: agreed, a lthough I suspect that is going to require some fun support to be added :) | 13:07 |
vikas_ | not nested VMs | 13:07 |
lucasagomes | TheJulia, yeah... well... we can pipe stuff | 13:07 |
vikas_ | only bm node is vm | 13:07 |
lucasagomes | there's also some conversion that should happen on the fly there as well | 13:07 |
lucasagomes | vikas, oh ok... I though you said "all-in-one"... So the services are in one VM and the Baremetal node is in another right? | 13:08 |
lucasagomes | and you have a bridge network between both VMs? | 13:08 |
vikas_ | yes through neutron router | 13:08 |
vikas_ | and services are in physical ubuntu machgine | 13:09 |
TheJulia | lucasagomes: Yes, I'm not sure qemu-img will support piped input though, but its been a while since I dug through the code | 13:09 |
* TheJulia needs more coffee | 13:09 | |
NobodyCam | so does /me | 13:09 |
lucasagomes | vikas, right, can you boot something on the machine u want to deploy and see if that can reach the Ironic API/ | 13:09 |
lucasagomes | ?* | 13:09 |
lucasagomes | I think there's something going on there | 13:10 |
*** rloo has joined #openstack-ironic | 13:10 | |
vikas_ | ironic api is running on 10.0.04 (same as tftp server,on physical ubuntu) | 13:10 |
vikas_ | from where i can change this 127.0.0.1 to 10.0.0.4 | 13:11 |
vikas_ | so that this curl command will not fail | 13:11 |
vikas_ | bm_node can reach services through neutron router only in my setup | 13:12 |
vikas_ | bm_node is in 50. network and services on 10. | 13:12 |
*** coolsvap is now known as coolsvap|away | 13:14 | |
*** degorenko has joined #openstack-ironic | 13:14 | |
lucasagomes | vikas, /etc/ironic/ironic.conf under [api] you have an option called "host_ip" | 13:16 |
lucasagomes | you can change it there | 13:16 |
vikas_ | cool | 13:17 |
openstackgerrit | Dmitry Tantsur proposed openstack/ironic-inspector: Use retries provided by ironicclient instead of ad-hoc ones https://review.openstack.org/207037 | 13:19 |
dtantsur | we should do this ^^^ with nova too, but we need https://review.openstack.org/#/c/206041/ | 13:24 |
-openstackstatus- NOTICE: zuul jobs after about 07:00 UTC may need a 'recheck' to enter the queue. Look if your change is in http://status.openstack.org/zuul/ and recheck if not. | 13:26 | |
*** caiobo has joined #openstack-ironic | 13:27 | |
*** albertoffb has joined #openstack-ironic | 13:27 | |
openstackgerrit | Merged openstack/ironic-lib: Updated from global requirements https://review.openstack.org/206816 | 13:28 |
*** [1]cdearborn has joined #openstack-ironic | 13:29 | |
lucasagomes | TheJulia, you guys run ironic-api under apache wsgi right? | 13:34 |
jroll | morning lucasagomes dtantsur TheJulia vikas_ sambetts and trown :) | 13:35 |
lucasagomes | jroll, hey | 13:35 |
trown | morning jroll | 13:35 |
dtantsur | jroll, o/ | 13:35 |
NobodyCam | mornign jroll | 13:35 |
jroll | dtantsur: re versioning with inspector... why not let the user set the version? (and plugins like sam's can require 1.11 or whatever) | 13:35 |
jroll | oh and NobodyCam! | 13:35 |
jroll | morning :) | 13:35 |
lucasagomes | jroll, I know you need coffee still, but if you have a time mind taking a peek at https://review.openstack.org/#/c/204162/ ? | 13:35 |
NobodyCam | :-p | 13:36 |
jroll | lucasagomes: dmitry wrote version docs, he gets first dibs on review :P | 13:36 |
dtantsur | +1 :) | 13:36 |
jroll | I'll try to get to that today though | 13:36 |
dtantsur | jroll, I think as we define it, API version is something defined by the client code, not by its user. I can't be sure my code will work with API v1.0 just because a user sets it | 13:38 |
jroll | dtantsur: I mean, in theory you could test all versions :) | 13:39 |
jroll | dtantsur: more realistically, you can say "1.2 is tested and fully supported, use others at your own risk" or whatever | 13:39 |
dtantsur | well, all past versions :) I can't test future versions (I wish I could) | 13:39 |
jroll | heh | 13:39 |
*** vikas has quit IRC | 13:40 | |
lucasagomes | jroll, heh fair enuff | 13:41 |
*** romainh has left #openstack-ironic | 13:44 | |
*** PradeepV has quit IRC | 13:45 | |
TheJulia | lucasagomes: no, we run standalone without apache | 13:45 |
lucasagomes | TheJulia, I see | 13:47 |
jroll | dtantsur: I has comments for you | 13:48 |
jroll | lucasagomes: so are you trying to figure out how to run it in apache? | 13:48 |
lucasagomes | jroll, yes, I believe it's just copying the etc/apache2/ironic under the apache vhost folder | 13:48 |
lucasagomes | enable the site and restart apache ? | 13:49 |
lucasagomes | jroll, something I'm missing? | 13:49 |
*** kkoski has quit IRC | 13:49 | |
jroll | lucasagomes: seems like it should mostly work, assuming ironic is at /opt/stack/ironic :) | 13:49 |
jroll | and apache user/group may need to change | 13:49 |
lucasagomes | jroll, oh ++ | 13:50 |
jroll | but yeah, seems sane otherwise... I think yuriyz may also have experience with this if you get stuck | 13:50 |
lucasagomes | we should dociment it | 13:50 |
lucasagomes | document* | 13:50 |
jroll | yeah, totally | 13:50 |
lucasagomes | I will try to do it and document as we go | 13:50 |
jroll | I've been meaning to set it up forever and haven't gotten to it | 13:50 |
rloo | hi everyone, dtantsur, jroll, TheJulia, lucasagomes | 13:50 |
lucasagomes | rloo, hello good morning | 13:50 |
NobodyCam | mornign rloo :) | 13:50 |
jroll | morning rloo :) | 13:50 |
lucasagomes | jroll, cool I will try it here, if I get it working I will document it upstream | 13:51 |
jroll | rloo: this seems relevant to your interests https://review.openstack.org/#/c/206999/ | 13:51 |
jroll | nice, thanks lucasagomes | 13:51 |
rloo | lucasagomes: quick question, wrt that new CLEANWAIT state. i am looking at https://review.openstack.org/#/c/204995/4/nova/virt/ironic/driver.py. | 13:51 |
lucasagomes | rloo, shoot! | 13:51 |
rloo | lucasagomes: in _wait_for_provision_state(), don't we want to check for CLEANWAIT too? | 13:51 |
rloo | morning NobodyCam! | 13:51 |
lucasagomes | rloo, yeah now that it exists in the Ironic we should indeed | 13:52 |
rloo | lucasagomes: the quesition has nothing to do with that particular patch, just the code i saw while reviewing it :) | 13:52 |
lucasagomes | rloo, tho i wanna get rid of this loop with the lazy instnace | 13:52 |
jroll | dtantsur: so on https://review.openstack.org/#/c/206752/ the tl;dr is with that option enabled, nova will do `select * from instances where host='ironic-compute-host'`, which is insane when you can have thousands of instances on one compute host :) | 13:52 |
TheJulia | goodmorning rloo | 13:52 |
lucasagomes | rloo, yeah we could submit a patch to include the CLEANWAIT there ++ | 13:52 |
rloo | lucasagomes: but it'll break now won't it? | 13:52 |
jroll | dtantsur: and I think it actually does it n/10 times, where n is number of ironic nodes | 13:53 |
rloo | lucasagomes: well, not break, just take longer | 13:53 |
lucasagomes | rloo, yeah right now it will just take longer cause CLEANWAIT doesn't make ironic break the loop | 13:53 |
jroll | dtantsur: https://github.com/openstack/nova/blob/master/nova/scheduler/host_manager.py#L388-418 | 13:53 |
rloo | lucasagomes: whereas before, it was CLEANING so it would have exit'd the loop faster. when do you think you might get the lazy instance delete implemented? the spec hasn't been approved yet... | 13:54 |
*** albertoffb has quit IRC | 13:55 | |
lucasagomes | rloo, yeah :-( we could just submit a small patch for now adding CLEANWAIT there | 13:56 |
lucasagomes | so we break the loop faster | 13:56 |
lucasagomes | rloo, I already have the code for the lazy stuff almost ready... need the spec tho | 13:57 |
rloo | lucasagomes: ok. would you like me to do it? | 13:57 |
lucasagomes | rloo, if you have it handy there | 13:57 |
rloo | lucasagomes: no, nothing handy :) | 13:58 |
lucasagomes | lol | 13:58 |
lucasagomes | rloo, I added to my todo, if I see nothing is submitted I will do today later on | 13:58 |
rloo | lucasagomes: ok sounds good. | 13:58 |
dtantsur | jroll, oh I see | 14:01 |
dtantsur | rloo, morning! | 14:01 |
jroll | dtantsur: it OOM'd our nova-scheduler running by itself on a 4gb machine :) | 14:01 |
dtantsur | wow | 14:01 |
jroll | and ate enough cpu that rabbit handshakes couldn't even get packets out | 14:02 |
jroll | quite amazing | 14:02 |
NobodyCam | oh wow | 14:02 |
NobodyCam | time.sleep(0) | 14:03 |
lucasagomes | yuriyz, around? | 14:04 |
yuriyz | hi lucasagomes | 14:04 |
lucasagomes | yuriyz, I'm trying to configure the ironic-api with apache wsgi, you've done it right? | 14:05 |
yuriyz | yes | 14:05 |
lucasagomes | yuriyz, so here's what I did... I copied etc/ironic/ironic to /etc/apache2/sites-enabled/ironic.conf | 14:05 |
lucasagomes | I edit it changed the user and group from "stack" to "ironic" | 14:05 |
lucasagomes | enabled the site and reloaded apache | 14:05 |
NobodyCam | TheJulia: did cinerama put up a patch to address "sh: 1: debootstrap: not found" | 14:05 |
*** EmilienM has quit IRC | 14:05 | |
lucasagomes | then I started ironic-api | 14:05 |
lucasagomes | yuriyz, but when I check the ironic_access.log it's empty | 14:06 |
lucasagomes | yuriyz, am I missing something? | 14:06 |
yuriyz | do you edit path to api? | 14:06 |
yuriyz | default is /opt/stack/ironic/ironic/api/app.wsgi | 14:07 |
TheJulia | NobodyCam: I thought she was going to, but I don't see anything | 14:07 |
lucasagomes | yuriyz, yeah that file exists (I'm testing with devstack) | 14:07 |
lucasagomes | stack@virtual-machine:~/devstack$ ls -la /opt/stack/ironic/ironic/api/app.wsgi | 14:08 |
lucasagomes | -rw-r--r-- 1 stack stack 858 Jul 21 13:59 /opt/stack/ironic/ironic/api/app.wsgi | 14:08 |
TheJulia | NobodyCam: /win 43 | 14:09 |
TheJulia | doh | 14:09 |
yuriyz | please look at /var/log/apache2/ironic_error.log | 14:09 |
*** EmilienM has joined #openstack-ironic | 14:09 | |
jroll | NobodyCam: time.sleep(0) is an eventlet-ism to yield to other threads and not hog the cpu, we have some in ironic too | 14:10 |
NobodyCam | jroll: ya, I saw the comment ... was just thinking that (1) may have prevented the hammering of your system :-p | 14:11 |
yuriyz | "native" ironic-api process should be stopped before apache restarts | 14:11 |
lucasagomes | yuriyz, oh right I see some errors there | 14:12 |
lucasagomes | yuriyz, gotcha | 14:12 |
lucasagomes | lemme try it a bit more thanks for the tip | 14:12 |
jroll | NobodyCam: nope, it locked up on the first iteration of the loop :) | 14:13 |
lucasagomes | yuriyz, worked! Gotta fix the wsgi mode upstream | 14:13 |
lucasagomes | it's important oslo worngly | 14:13 |
* lucasagomes makes a patch | 14:13 | |
openstackgerrit | Naohiro Tamura proposed openstack/ironic: Add raises docstring tag into object.Ports methods https://review.openstack.org/207064 | 14:15 |
NobodyCam | lol: this is kinda Ironic: http://www.pme-legend.com/campaigns/bare-metal-jeans | 14:16 |
openstackgerrit | Lucas Alvares Gomes proposed openstack/ironic: Fix apache wsgi import https://review.openstack.org/207068 | 14:21 |
lucasagomes | yuriyz, ^ | 14:21 |
jroll | nice catch | 14:22 |
lucasagomes | jroll, I will document it now | 14:23 |
*** absubram has joined #openstack-ironic | 14:25 | |
rloo | lucasagomes: i +1'd but have some comments for https://review.openstack.org/#/c/204995/. not sure how nova folks vote | 14:25 |
*** mtanino has joined #openstack-ironic | 14:25 | |
*** r-daneel has joined #openstack-ironic | 14:26 | |
dtantsur | NobodyCam, lol | 14:27 |
NobodyCam | :-p | 14:27 |
lucasagomes | rloo, thanks! | 14:28 |
lucasagomes | NobodyCam, looks like a normal jeans | 14:28 |
NobodyCam | yep.. just the name :-p | 14:28 |
*** kkoski has joined #openstack-ironic | 14:28 | |
lucasagomes | they should add some metal to it | 14:29 |
*** uggla__ has joined #openstack-ironic | 14:29 | |
NobodyCam | or a pixie logo :-p | 14:29 |
lucasagomes | heh ++ | 14:29 |
lucasagomes | on the butt | 14:29 |
NobodyCam | LOL | 14:30 |
*** uggla__ has quit IRC | 14:30 | |
*** uggla___ has joined #openstack-ironic | 14:30 | |
*** sinval_ has quit IRC | 14:33 | |
jroll | lucasagomes: I also left a comment there, idk if worth a -1 but I did it anyway | 14:34 |
jroll | (nova patch) | 14:34 |
NobodyCam | I hit it late lastnight... should I retest.. I have not yet done that | 14:35 |
NobodyCam | ww | 14:35 |
lucasagomes | jroll, thanks will fix! left a comment as well | 14:36 |
rloo | jroll: now I feel like I was being too nice. I had the same thought as you, but the other tests (wrt the destroy) use the FAKE_CLIENT node thingy so I figured lucasagomes was being consistent with that. | 14:36 |
lucasagomes | I can test _unprovision() directly instead of going through destroy() wdyt? | 14:36 |
rloo | lucasagomes: yes, testing _unprovision() would be better. | 14:36 |
lucasagomes | rloo, yeah I copied it over and then modified it | 14:36 |
lucasagomes | c&p lazyness :-( sorry | 14:37 |
lucasagomes | will do | 14:37 |
jroll | yeah +1 | 14:37 |
*** coolsvap|away is now known as coolsvap | 14:37 | |
rloo | lucasagomes: the only problem with testing _unprovision() is that then I'd wonder about testing all of it :-( | 14:37 |
jroll | (I now see why you did that, thuogh) | 14:37 |
lucasagomes | rloo, yeah, well I add the rest of the tests if needed | 14:37 |
lucasagomes | the nova driver needs some love | 14:38 |
rloo | lucasagomes: I'm fine with whatever you do I think, given that it needs more love anyway :) | 14:38 |
lucasagomes | (-: | 14:38 |
lucasagomes | I will add the tests for _unprovision() | 14:38 |
rloo | lucasagomes: eg if you add _unprovision() tests, my guess is that some of the existing tests might need to be changed to directly test _unprovision() | 14:39 |
lucasagomes | hmm | 14:40 |
lucasagomes | I will take a look after documenting the wsgi thing | 14:40 |
*** pal has quit IRC | 14:45 | |
*** pal has joined #openstack-ironic | 14:46 | |
thiagop | good morning Ironicers | 14:49 |
*** athomas has quit IRC | 14:49 | |
NobodyCam | good mornign thiagop | 14:50 |
*** pal has quit IRC | 14:50 | |
*** athomas has joined #openstack-ironic | 14:55 | |
thiagop | Hey NobodyCam | 14:55 |
*** absubram has quit IRC | 14:55 | |
NobodyCam | :) | 14:56 |
* NobodyCam joins a call :-) | 14:58 | |
*** absubram has joined #openstack-ironic | 14:59 | |
*** caiobo has quit IRC | 15:00 | |
*** jistr has quit IRC | 15:00 | |
*** yuikotak_ has joined #openstack-ironic | 15:01 | |
*** e0ne has quit IRC | 15:02 | |
*** mestery has joined #openstack-ironic | 15:02 | |
*** jistr has joined #openstack-ironic | 15:02 | |
*** yuikotakada has quit IRC | 15:03 | |
*** e0ne has joined #openstack-ironic | 15:04 | |
rloo | hey dtantsur, I think 'their' use of 'service' is in reference to this other file (in this patch: https://review.openstack.org/#/c/201670/) | 15:06 |
dtantsur | rloo, ah I see. so subproject are just not considered, nice... | 15:07 |
rloo | dtantsur: but yeah, a project could provide more than one "service". they don't address the individual components. | 15:07 |
rloo | dtantsur: i find it ironic that in their reference/projects.yaml file, the project names have the first letter uppercased, even though they want them lowercased :) | 15:07 |
dtantsur | lol | 15:08 |
rloo | dtantsur: i added a comment; will see if anyone bites | 15:08 |
*** [1]cdearborn has quit IRC | 15:09 | |
*** cdearborn has joined #openstack-ironic | 15:09 | |
*** cdearborn has quit IRC | 15:10 | |
*** cdearborn has joined #openstack-ironic | 15:11 | |
*** davideagnello has joined #openstack-ironic | 15:16 | |
openstackgerrit | Lucas Alvares Gomes proposed openstack/ironic: Document configuring ironic-api behind mod_wsgi https://review.openstack.org/207091 | 15:20 |
*** davideagnello has quit IRC | 15:20 | |
*** vikas_ has quit IRC | 15:25 | |
*** ijw has joined #openstack-ironic | 15:29 | |
*** alexpilotti has quit IRC | 15:34 | |
*** gabriel-bezerra has quit IRC | 15:39 | |
*** vishwanathj has quit IRC | 15:41 | |
*** Sukhdev_ has joined #openstack-ironic | 15:47 | |
*** romcheg has quit IRC | 15:48 | |
*** ijw has quit IRC | 15:50 | |
*** trown is now known as trown|lunch | 15:50 | |
*** ifarkas has quit IRC | 15:50 | |
openstackgerrit | Stephanie Miller proposed openstack/bifrost: Correct reference to deploy_image variable in install playbook https://review.openstack.org/206745 | 15:52 |
*** karimb has joined #openstack-ironic | 15:54 | |
TheJulia | cinerama: danke | 15:54 |
*** uggla___ has quit IRC | 15:57 | |
*** uggla___ has joined #openstack-ironic | 15:58 | |
*** uggla___ has quit IRC | 15:59 | |
*** gabriel-bezerra has joined #openstack-ironic | 16:01 | |
*** lucasagomes is now known as lucas-afk | 16:03 | |
openstackgerrit | Dmitry Tantsur proposed openstack/ironic-python-agent: [WIP] Add support for inspection using ironic-inspector https://review.openstack.org/205587 | 16:04 |
dtantsur | see you tomorrow! | 16:04 |
*** dtantsur is now known as dtantsur|afk | 16:04 | |
NobodyCam | night dtantsur|afk | 16:06 |
NobodyCam | anyone have a free cycle to look at a vagrant file patch: https://review.openstack.org/#/c/191110 </ShameLessPlug> | 16:07 |
*** jistr has quit IRC | 16:08 | |
*** romcheg has joined #openstack-ironic | 16:11 | |
*** meghal has joined #openstack-ironic | 16:11 | |
*** romcheg has quit IRC | 16:12 | |
*** coolsvap is now known as coolsvap|away | 16:12 | |
*** puranamr has joined #openstack-ironic | 16:13 | |
*** romcheg has joined #openstack-ironic | 16:14 | |
*** [1]cdearborn has joined #openstack-ironic | 16:15 | |
*** david-lyle has quit IRC | 16:18 | |
*** lsmola has quit IRC | 16:20 | |
cinerama | feels good when you go to look at a patch someone wants a review on and you already reviewed :) | 16:21 |
openstackgerrit | Merged openstack/bifrost: Remove un-necessary role https://review.openstack.org/206667 | 16:21 |
NobodyCam | :) | 16:22 |
*** Marga_ has quit IRC | 16:26 | |
*** Marga_ has joined #openstack-ironic | 16:28 | |
*** cdearborn has quit IRC | 16:30 | |
meghal | hello all…I was going through the following raid spec- http://specs.openstack.org/openstack/ironic-specs/specs/liberty/ironic-generic-raid-interface.html which says that a raid interface is being added for operators to specify a raid config while enrolling hardware, which can be used for zapping or cleaning | 16:33 |
meghal | so, I was wondering if there are any plans to allow end user to customize raid config ? | 16:33 |
meghal | while booting an instance ? | 16:33 |
*** coolsvap|away is now known as coolsvap | 16:39 | |
*** david-lyle has joined #openstack-ironic | 16:42 | |
devananda | meghal: generally no. changing the physical characteristics of the hardware is not logically part of the deploy process, but a precondition to it, so it is done while the node is in the MANAGEABLE state | 16:45 |
*** ukalifon has quit IRC | 16:45 | |
*** alexpilotti has joined #openstack-ironic | 16:47 | |
*** Marga_ has quit IRC | 16:47 | |
sambetts | devananda: I still think that should be selectable by flavor :/ | 16:47 |
sambetts | but thats likely something for the future | 16:48 |
meghal | devananda: thanks for your reply. So, what if there is a ironic node with hw raid configured and has multiple disks, how will a user be able to specify if he wants raid0 or raid10 ? | 16:48 |
devananda | sambetts: the point is for it to be selectable by flavor :) | 16:49 |
*** zz_natorious is now known as natorious | 16:49 | |
devananda | sambetts: iow, if I have a pool of servers and I know some users will want raid5 and some will want raid10, I create two flavors, and prepare some servers in each way, then the scheduler matches flavor <-> raid topology | 16:50 |
devananda | in that way, the user isn't waiting for the raid to be built after they ask Nova for an instance | 16:50 |
sambetts | devananda: in my use case 1 node would be able to support both raids | 16:50 |
meghal | sambetts: devananda - so ironic node has raid capabilities and there will be a flavor which exposes those capabilities, so user will know that he is booting a raid node, but I still believe that user will want to configure raid setup | 16:50 |
devananda | cause, well, building raids isn't necessarily fast .... | 16:50 |
meghal | because if we preconfigure raid, aren't we restricting hw capability to allow customization of raid config | 16:51 |
jroll | sambetts: devananda: I think just-in-time raid config is something we should do eventually, but baby steps and all | 16:51 |
devananda | meghal: "user" is a cloud consumer in this case, not a traditional sysadmin | 16:51 |
sambetts | jroll: Yes baby steps :D | 16:51 |
devananda | meghal: yes | 16:51 |
devananda | jroll: yeh ... I know that some hardware will support things like that, but in that case, it can be automated | 16:52 |
jroll | devananda: automated? | 16:52 |
meghal | devananda: right…user is cloud admin who configures ironic node with specific raid, but why should we restrict node with hw raid to specific configuration, when we can add support to ipa to customize it based on end user input | 16:53 |
devananda | though I think the interface for specifying raid config right now is complex enough that we'll need automation around it anyway | 16:53 |
meghal | devananda: is it because we want predictable reimaging time ? | 16:53 |
devananda | meghal: that's part of it | 16:53 |
jroll | meghal: I think we'll get to that point someday (I certianly want to), but one thing at a time... | 16:53 |
devananda | meghal: when the cloud user is the same as the cloud operator, then yea, some things are different. but in that case, the "user" can still do this | 16:54 |
meghal | jroll: sure…I do not have a question about timing, I was just wondering if that is the direction ironic is thinking | 16:54 |
devananda | they just need to perform the RAID config through the manageable state | 16:54 |
devananda | meghal: primary reason is to support the case where the cloud user != cloud operator | 16:55 |
jroll | meghal: cool, yes, that's something I (we?) want to do | 16:55 |
meghal | devananda: now I am confused…I see cloud operator as an admin managing ironic cluster…and cloud user as an end user using nova to boot ironic nodes | 16:56 |
devananda | jroll: how long does it take your hardware to convert a 12 disk RAID10 into a RAID5? | 16:56 |
devananda | meghal: exactly | 16:56 |
devananda | meghal: inthat case, does the user who issues "nova boot" want to wait a very long time for RAID to be rebuilt? | 16:56 |
devananda | meghal: also, how do they specify ** to Nova ** the RAID config they want? | 16:56 |
devananda | they pick a pre-existing flavor | 16:57 |
meghal | devananda: sure in certain cases, he would want to…because he has set that expectation by specifying a particular raid config | 16:57 |
devananda | which "he" ? | 16:57 |
meghal | devananda: yes specifying raid config to nova is the tricky question | 16:57 |
meghal | devananda: I meant cloud user | 16:57 |
*** coolsvap is now known as coolsvap|away | 16:58 | |
devananda | meghal: so, it's not a tricky question. it is done by selecting a flavor that the cloud operator has already created | 16:58 |
jroll | devananda: I'm not trying to pretend it's possible on all hardware, it's just something I want to be able to do (and maybe some nova users are ok with waiting) | 16:58 |
*** coolsvap|away is now known as coolsvap | 16:58 | |
jroll | devananda: remember mdraid etc is a thing | 16:58 |
devananda | Nova's API doesn't support anything beyond that | 16:58 |
sambetts | I see there being 4/5 near indentical flavors with the only difference being the type of raid | 16:58 |
devananda | jroll: ..... | 16:58 |
meghal | devananda: at Yahoo we have been playing around with this question as well, for certain disk customization which can happen after OS comes up, we can use chef | 16:58 |
jroll | devananda: yes? | 16:59 |
devananda | jroll: software raid? | 16:59 |
*** kkoski has quit IRC | 16:59 | |
jroll | devananda: yes? | 16:59 |
meghal | devananda: but for certain customizations which ipa or any OS installer needs to do, either nova needs to support it, or we piggy back on cloud-init user data or so | 16:59 |
devananda | <sigh> | 16:59 |
meghal | devananda: we have not been able to decide though…this was just a thought | 16:59 |
devananda | meghal: can you give some specific examples? | 17:00 |
meghal | but there should be some support from nova api | 17:00 |
*** davideagnello has joined #openstack-ironic | 17:00 | |
jroll | devananda: people do use software raid, believe it or not | 17:00 |
meghal | devananda: lets say user specifies user-data which is cloud-init and specify a raid config in yaml format | 17:00 |
meghal | devananda: ironic driver receives the user data in instance info | 17:00 |
devananda | jroll: sure. it exists. but i dont think ironic needs to solve for every situation | 17:01 |
meghal | devananda: ironic conductor parses the user data and provides input to IPA which can take appropriate action | 17:01 |
devananda | meghal: I mean, can you give an example of the requirement? not the flow you think will meet it | 17:01 |
*** pal has joined #openstack-ironic | 17:02 | |
jroll | devananda: I mean, if I want a compute with the boot disk on software raid, I shouldn't be able to use ironic to do that? that's... sad at best | 17:02 |
devananda | sambetts: in theory, yea, i could see there being a lot of "hardware-X-config-A", "hardware-X-config-B", and so on | 17:02 |
*** kkoski has joined #openstack-ironic | 17:02 | |
meghal | devananda: so we have lot of hardware with hw raid and cloud users while booting instances like to specify raid0 or raid10 and expect the hw to come up with that configuration | 17:02 |
meghal | devananda: that is the use case | 17:02 |
devananda | meghal: ok. could you create two pools of hardware, some preconfigured with raid0 and some preconfigured with raid10? | 17:03 |
*** e0ne has quit IRC | 17:03 | |
devananda | to note - the "available storage" of each of those pools will also be different | 17:04 |
Madasi | seems like a workable intermediate solution, but has lots if inefficiencies long term at scale | 17:04 |
meghal | devananda: then we will be restricting usage of that pool when cloud users needing raid support are not booting instances | 17:04 |
devananda | even if they have the same # of HDD | 17:04 |
sambetts | devananda: I don't see a problem with that sort of flavor list, the problem with having pools of preconfigured hardware is that what happens if you run out of one type | 17:04 |
*** kkoski has quit IRC | 17:04 | |
jroll | yeah, I think JIT hw raid config should be an acceptable thing, if a deployer chooses to make their user wait hours to get a server | 17:04 |
Madasi | you'd end up with a crazy backend system that looks at usage, reconfigures raid, and moves nodes from one pool to another | 17:05 |
Madasi | seems like a better solution in raid configuration on demand as an end goal | 17:05 |
devananda | Madasi: except that by not predefining the set of allowable configurations (and this applies to more than just RAID), we push the complexity out through the API and on to users | 17:05 |
devananda | imagine as a user the interface here | 17:06 |
jroll | wait | 17:06 |
Madasi | it's predifined to a set of allowed options | 17:06 |
jroll | there's a couple of things here | 17:06 |
jroll | 1) raid-x flavors with preconfigured raid | 17:06 |
*** Pradip has joined #openstack-ironic | 17:06 | |
jroll | 2) raid-x flavors with JIT raid | 17:07 |
jroll | 3) --i-want-raid-x in nova api | 17:07 |
jroll | 3 is horrible | 17:07 |
Madasi | ^ | 17:07 |
jroll | let's never do that | 17:07 |
Madasi | I was thinking of #2 | 17:07 |
sambetts | I'm after 2 | 17:07 |
jroll | 2 is great but slow | 17:07 |
devananda | nova boot --image ... --flavor baremetal --hwspec "{'raid': { ... lots of details ...}, 'network': { ... more details about bonding ... }, 'firmware': { ... specific firmware versions ... }, and so on}" | 17:07 |
jroll | 1 is bad but fast | 17:07 |
meghal | jroll: why is it horrible ? because of longer time ? | 17:07 |
meghal | and user interface ? | 17:07 |
Madasi | jroll: is it really that slow to configure striping across a bunch of completely empty disks? | 17:07 |
Madasi | been a long time since I setup hardware raid, so honest question here | 17:08 |
jroll | I think we can combine 1 and 2 to have raid-x flavors that prefer preconfigured raid, and do it JIT if it isn't there | 17:08 |
devananda | jroll: 1 is what I think gives the best user eperience. 2 is acceptable as well, but it's clearly a trade off. 3 is terrible IMO | 17:08 |
*** Marga_ has joined #openstack-ironic | 17:08 | |
jroll | Madasi: I honestly don't have enough experience to say, I'm trusting others here | 17:08 |
*** natorious is now known as zz_natorious | 17:08 | |
jroll | devananda: yeah, I like 2 with "if something is preconfigured use that" | 17:08 |
meghal | jroll: by JIT do you mean sw raid ? | 17:09 |
jroll | devananda: and operators that want the best user experience will preconfigure things | 17:09 |
jroll | meghal: I mean raid configured Just In Time (at deploy time) | 17:09 |
devananda | jroll: so remember the discussion we had on Friday in Paris? | 17:09 |
Madasi | I thought wiping the disks was a significant portion of raid setup time, but maybe it is actually laying down the striping and other setup tasks | 17:09 |
jroll | devananda: that was 9 months ago, no | 17:10 |
devananda | Madasi: i believe it varies significantly by hardware | 17:10 |
jroll | devananda: you mean the whole zapping thing? | 17:10 |
Madasi | noly user experience difference between #1 and #2 should be boot time, right? | 17:10 |
devananda | jroll: for the sake of a better UX, I believe we agreed that all the potentially-slow, potentially-destructive, probably-change-the-hardware-properties steps should get lumped together | 17:10 |
meghal | jroll: so by (2) you mean raid config is specified in flavor extra spec and hw is configured at deploy time. Yes, that is def better than restricting a hw pool | 17:10 |
devananda | and put behind the management API | 17:10 |
devananda | the thing about changing RAID config -- it actually changes the node.properties | 17:11 |
*** mjturek1 has quit IRC | 17:11 | |
devananda | so doing that in a deploy will mess with quota usages in Nova too | 17:11 |
devananda | becaues it changes the total amount of disk consumed | 17:11 |
jroll | devananda: here's my take on this: clearly (1) is the best option here. the question is what to do in the "nothing is preconfigured" case. our options are a) just fail. the user has to ask support what happened. support has to go to ops and ask them to configure a thing. hopefully the user gets it before someone else does. b) configure raid on the fly, user still has to wait but doesn't need to | 17:11 |
jroll | contact support. | 17:11 |
devananda | just one example -- perhaps not the best one, because who really sets a quota around disk usage? | 17:11 |
devananda | (oh, wait, folks do bill on that) | 17:12 |
devananda | jroll: "nothing is preconfigured" should be "cloud operator starts preconfiguring things" | 17:12 |
Madasi | devananda: that is a valid point, different raid configs are different flavor definitions in nova. One more example of where nova's model of reality doesn't map properly for us | 17:13 |
openstackgerrit | Julia Kreger proposed openstack/bifrost: Cleanup use of extra_dib_elements https://review.openstack.org/206664 | 17:13 |
devananda | to be clear -- I think it would be quite nice for some use cases to do JIT HW RAID configuration | 17:13 |
jroll | devananda: I mean... hopefully. if they're around. and notified. and not busy with something else. etc. etc. | 17:13 |
devananda | but I think it significantly complicates /other/ interactions between Ironic and OpenStack that are, well, not great | 17:13 |
jroll | devananda: which is going to end with software being written to watch pools of hw and different raid configs and preconfigure int he background and so on | 17:13 |
devananda | Madasi: exactly | 17:13 |
devananda | jroll: yep. and I fully expect that to be written | 17:14 |
jroll | devananda: that's... meh. hopefully whoever writes it is a fan of contributing to open source | 17:14 |
*** alexpilotti has quit IRC | 17:14 | |
Madasi | devananda: question though. customer builds raid 10, so you are billing them for half the potential capacity of the disk space on the box. Do you have them locked out of the raid config, or can the change that to raid 5 or even raid 0 and get extra space for the price of an os reinstall by hand? | 17:15 |
sambetts | For my use case, I know this doesn't fit a lot of other peoples, but we have a data center full of identical hardware, all specs out far beyond what most users might want, I actually want fuzzy fitting of flavors e.g. scedule a flavor onto a node that provides more than the flavor's asking for but limit it using the OOB management | 17:15 |
devananda | sambetts: oh, interesting | 17:16 |
Madasi | seems to me like we advertise to nova total potential capacity and don't worry about how it's actually being used | 17:16 |
sambetts | that goes for disk, RAM, CPU etc etc etc, we can limit all those things in management and only give the user what they've asked for | 17:16 |
devananda | Madasi: fair point. and that's possible, too | 17:16 |
jroll | right, billing for ram/disk usage doesn't make sense for ironic. bill on instances. | 17:16 |
devananda | right | 17:17 |
devananda | just poiting out how all this breaks Nova's models | 17:17 |
sambetts | don't most people bill based on flavor? | 17:17 |
meghal | Madasi jroll - yes bill on instances seems right way to go…that's why we also want quota per flavor in nova | 17:17 |
devananda | anyway, i need to run. E_TOOMANYMEETINGS | 17:17 |
sambetts | devananda: have fun :-P | 17:17 |
devananda | thanks :p | 17:17 |
meghal | and quota per flavor could directly track instances | 17:18 |
meghal | thanks devananda for your inputs | 17:18 |
sambetts | yeah this conversation is really interesting | 17:18 |
*** karimb has quit IRC | 17:19 | |
Madasi | sambetts: i would expect so, devananda's point earlier was that from nova's point of view JIT ram config changes a node from one type to another since it tracks nodes by ram/disk capacity | 17:19 |
Madasi | billing wouldn't care since it is by flavor/instance | 17:20 |
Madasi | but nova would | 17:20 |
meghal | we have this use case here - we order multiple type of hardware and expose it via flavors to cloud users, also hw is installed in specific location in datacenter, and users do want a particular hw in particular location, so we end up assigning quota per flavor and az and any quota assignment that goes beyond params like cores,ram,disk etc needs to be tracked by instances | 17:21 |
meghal | also, cloud users want to configure raid config while booting instances | 17:22 |
meghal | because in ironic entire hw comes as a whole and not like vms where it can be split up | 17:22 |
sambetts | meghal: is the type of RAID config you want, more than just picking a type of RAID ? | 17:22 |
meghal | sambetts: it also relates to customizing disk config, mirroring root partition on RAID | 17:23 |
*** alexpilotti has joined #openstack-ironic | 17:23 | |
meghal | for certain disk config which does not involve raid and can be done after OS comes up, we are asking users to do it via chef, and that we will provide with fixed size root partition | 17:24 |
sambetts | meghal: thats software RAID yes? | 17:24 |
meghal | but for sw raid as well,root partition also needs to be mirrored as users want to take that advantage | 17:25 |
meghal | and so it needs to be done by some OS installer - IPA | 17:25 |
sambetts | my use case is for out of band hardware RAID setup specficly | 17:25 |
meghal | I believe there needs to be an interface which provides input params for setting up RAID, does disk config and is directly understood by IPA to take appropriate action | 17:26 |
meghal | now whether we do it via flavor or end-user api | 17:27 |
sambetts | couldn't you bake the software RAID into the image? | 17:27 |
sambetts | then its just done based on image selection | 17:27 |
*** achanda has joined #openstack-ironic | 17:27 | |
meghal | thats a great suggestion, I will ask the OS guy in our team | 17:27 |
Madasi | wouldn't you need an image per raid config per flavor then? | 17:28 |
Madasi | that's a lot of images | 17:28 |
Madasi | assuming drive differences between your flavors | 17:29 |
*** mjturek1 has joined #openstack-ironic | 17:29 | |
meghal | Madasi: yes…thats true…we would need different configs per different flavors and hence different images | 17:29 |
meghal | argh | 17:29 |
meghal | yes that will be lot of images | 17:29 |
sambetts | I guess it depends on if the software your using to RAID can adapt to different amounts of disk | 17:29 |
sambetts | e.g. done by percentage or something :/ I don't know, I've not played with much sw RAID past like LVM stuff | 17:30 |
Madasi | sambetts: to achieve that i think you'd need to lay down raid at a certain size, then figure out a way to have something like cloud-init trigger a resize of the raid to include any extra space | 17:31 |
Madasi | not sure if that is possible with raid in the same way it is with partitions, but if so it could work with multiple disk sizes | 17:31 |
meghal | once we push it to cloud-init, root partition is already created | 17:31 |
*** Marga_ has quit IRC | 17:32 | |
sambetts | meghal: it might be created but if its a logical volume its easily changed | 17:32 |
*** Marga_ has joined #openstack-ironic | 17:32 | |
sambetts | although it'll be mounted... shoot... | 17:32 |
Madasi | just use zfs :P | 17:32 |
sambetts | or btfs ;) | 17:33 |
meghal | sambetts: yeah…so pushing it to image level will also not help | 17:33 |
meghal | action needs to happen at IPA level | 17:33 |
sambetts | my issue with software level RAID is that it feels like its user level task to complete not a deploy one | 17:35 |
sambetts | e.g. a user could change it after the fact inside his instance but with OOB RAID they can't | 17:35 |
sambetts | how would nova/ironic deal with a user rearraging something inside the instance? questions like that come up | 17:36 |
meghal | thats where cleaning comes in…right ? | 17:36 |
sambetts | meghal: I mean while the instance is running | 17:36 |
meghal | sambetts: while an instance is running why would nova/ironic have to deal with what user does inside the instance ? | 17:37 |
sambetts | it shouldn't, and for the same reason I don't think it should be setting anything up inside the instance either | 17:38 |
meghal | sambetts: question is if user wants things to be configured in a certain way, he can only provide input to the cloud | 17:39 |
meghal | and cloud needs to take action accordingly…user has no other option | 17:39 |
sambetts | meghal: he can create his own image and upload it? | 17:39 |
Madasi | that's a lot trickier with ironic than it is with nova, due to hardware drivers and the like | 17:40 |
meghal | sambetts: as Madasi brought up, it will also have to be tied with the flavor | 17:40 |
sambetts | if the user is making it themselves, then you don't need so many precreated images, the user knows the flavor he/she targeting it for | 17:40 |
*** pelix has quit IRC | 17:41 | |
*** kkoski has joined #openstack-ironic | 17:42 | |
meghal | sambetts: could work….but there are other questions as well…whether we want users to upload images because of security concerns | 17:42 |
*** r-daneel has quit IRC | 17:44 | |
openstackgerrit | Merged openstack/ironic: Fix apache wsgi import https://review.openstack.org/207068 | 17:45 |
*** Sukhdev_ has quit IRC | 17:47 | |
sambetts | meghal: thats a good question, what if you provided an image builder that accepted the RAID information and could pre-configure it? and had some kind of checksum that made sure it came from your builder? tbh I don't see a problem with having many prebuilt images, depends how many differnt flavors you have I guess, but you could tag the image with the flavor ID to make it easily searchable | 17:47 |
sambetts | remembering that the kernal and initrd would be the same for most of them so you wouldn't need duplicates of those uploaded | 17:49 |
lucas-afk | rloo, replied to https://review.openstack.org/#/c/205033/ , lemme know if that's fine | 17:51 |
*** Marga_ has quit IRC | 17:51 | |
*** Marga_ has joined #openstack-ironic | 17:52 | |
*** puranamr has quit IRC | 17:52 | |
rloo | lucas-afk: yeah, i think that's fine. i haven't thought the stuff through. just that i thought there was some code you added wrt cleaning/cleanwait to be backwards compatible with cleaning, so i figured there might be some timing thing wrt upgrading ironic while a node was being cleaned. | 17:54 |
*** puranamr has joined #openstack-ironic | 17:54 | |
lucas-afk | rloo, yeah, I know, it's pretty tricky the whole state of things right now | 17:55 |
lucas-afk | :-( | 17:55 |
*** lucas-afk is now known as lucasagomes | 17:55 | |
rloo | lucasagomes: I'm fine approving it then unless you want to update the docstrings. | 17:55 |
lucasagomes | rloo, I will update the docstrings... but no worries it depends on the patch on nova first | 17:56 |
rloo | lucasagomes: oh right. | 17:56 |
lucasagomes | without been merged on nova this won't merge (Depends-On the commit message) | 17:56 |
lucasagomes | so we have time | 17:56 |
lucasagomes | rloo, I'm adding the tests for the _unprovision right now | 17:56 |
rloo | thx lucasagomes | 17:56 |
*** e0ne has joined #openstack-ironic | 17:56 | |
lucasagomes | rloo, thanks you for the review | 17:56 |
*** [1]cdearborn has quit IRC | 17:56 | |
*** trown|lunch is now known as trown | 17:56 | |
rloo | lucasagomes: yw | 17:56 |
*** cdearborn has joined #openstack-ironic | 17:57 | |
rloo | lucasagomes: sorry, i had another question in that patch. | 18:02 |
lucasagomes | rloo, cool will take a look soonish | 18:02 |
meghal | sambetts: sorry…was afk…yes verifying checksum is a good idea…let me talk to the OS expert in my team and see how can this be possible and whether we can push this configuration to image level or whether it needs to be done at IPA level | 18:05 |
rloo | lucasagomes: no hurries. (just couldn't change my vote yet.) | 18:05 |
*** e0ne has quit IRC | 18:06 | |
*** adam_g has joined #openstack-ironic | 18:07 | |
*** adam_g has quit IRC | 18:07 | |
*** adam_g has joined #openstack-ironic | 18:07 | |
*** e0ne has joined #openstack-ironic | 18:09 | |
*** sinval_ has joined #openstack-ironic | 18:12 | |
*** [1]cdearborn has joined #openstack-ironic | 18:17 | |
*** coolsvap is now known as coolsvap|brb | 18:18 | |
meghal | have one more question on availability zones, right now availability zone in nova is tracked by nova-compute hosts rather than hypervisor | 18:19 |
meghal | so ironic nodes exposed as hypervisors under one nova-compute cannot be exposed to users as avail. zones | 18:20 |
meghal | have we tried to talk to nova team about the same ? | 18:20 |
meghal | or is anybody using a different solution ? | 18:20 |
*** zer0c00l has quit IRC | 18:26 | |
*** pal has quit IRC | 18:26 | |
lucasagomes | rloo, jroll https://review.openstack.org/204995 added the missing unittests, I think it's good now | 18:27 |
lucasagomes | and folks I will call t a day, it's late here | 18:27 |
lucasagomes | I will catch up with the rest tomorrow! Have a great night everyone | 18:27 |
rloo | thx lucasagomes! | 18:28 |
lucasagomes | rloo, see you have a nice afternoon. I will take a look at the instance_uuid patch tomorrow morning | 18:28 |
*** lucasagomes is now known as lucas-dinner | 18:28 | |
sambetts | I'm off too, man its been a long day :-P G,night all o/ | 18:29 |
*** zer0c00l has joined #openstack-ironic | 18:31 | |
*** openstackgerrit has quit IRC | 18:31 | |
*** cdearborn has quit IRC | 18:31 | |
*** openstackgerrit has joined #openstack-ironic | 18:32 | |
meghal | thanks sambetts for your inputes | 18:40 |
meghal | inputs* | 18:40 |
NobodyCam | night sambetts | 18:42 |
NobodyCam | night lucas-dinner | 18:42 |
*** vishwanathj has joined #openstack-ironic | 18:42 | |
*** vishwanathj has quit IRC | 18:46 | |
openstackgerrit | Tom Cocozzello proposed openstack/bifrost: Activate pep8 check that _ is imported https://review.openstack.org/207173 | 18:53 |
*** kkoski has quit IRC | 18:55 | |
*** kkoski has joined #openstack-ironic | 18:55 | |
*** Sukhdev_ has joined #openstack-ironic | 18:55 | |
*** zer0c00l has quit IRC | 18:56 | |
*** kkoski_ has joined #openstack-ironic | 18:57 | |
*** pal has joined #openstack-ironic | 18:57 | |
*** kkoski has quit IRC | 18:58 | |
openstackgerrit | Julia Kreger proposed openstack/bifrost: Make simple-init element perform source-based install https://review.openstack.org/207177 | 19:04 |
openstackgerrit | Julia Kreger proposed openstack/bifrost: Change default OS and support dib_packages https://review.openstack.org/207178 | 19:04 |
TheJulia | rcarrillocruz: You'll be interested in the above revision | 19:04 |
*** krtaylor has quit IRC | 19:04 | |
*** sinval_ has quit IRC | 19:06 | |
openstackgerrit | Julia Kreger proposed openstack/bifrost: Move set +e to ensure VM creation causes failure https://review.openstack.org/207182 | 19:10 |
*** coolsvap|brb is now known as coolsvap|away | 19:10 | |
openstackgerrit | Julia Kreger proposed openstack/bifrost: WIP: Test script to drive image testing https://review.openstack.org/207184 | 19:12 |
*** zer0c00l has joined #openstack-ironic | 19:15 | |
*** meghal has quit IRC | 19:16 | |
*** kkoski_ has quit IRC | 19:16 | |
*** kkoski has joined #openstack-ironic | 19:16 | |
*** krtaylor has joined #openstack-ironic | 19:17 | |
openstackgerrit | Thiago Paiva Brito proposed openstack/ironic: OneView Driver for Ironic https://review.openstack.org/191822 | 19:26 |
*** davideagnello has quit IRC | 19:27 | |
*** ionutbalutoiu has joined #openstack-ironic | 19:28 | |
alexpilotti | jroll: me and ionutbalutoiu are playing around with Windows images on Ironic | 19:29 |
jroll | alexpilotti: cool! | 19:30 |
alexpilotti | with GPT, after a reboot PXE boot chain complains that we have not MBR :-) | 19:30 |
alexpilotti | so one option is to build images with MBR partitioning, we’re trying this now | 19:31 |
jroll | heh | 19:31 |
jroll | you can do UEFI too | 19:31 |
alexpilotti | the other is that by using UEFI, we cannot use whole disk images | 19:31 |
jroll | oh. | 19:31 |
*** jjohnson2 has quit IRC | 19:31 | |
TheJulia | I thought > windows8 required gpt | 19:31 |
alexpilotti | here you go :-) | 19:31 |
alexpilotti | I basically have two questions | 19:32 |
alexpilotti | 1) can we do UEFI with whole disk images | 19:32 |
alexpilotti | 2) can we get GPT to work :-) | 19:32 |
TheJulia | what drier? | 19:33 |
TheJulia | driver | 19:33 |
jroll | so | 19:33 |
* TheJulia knows what jroll is going to say :) | 19:33 | |
alexpilotti | currently we used PXE, planning to go iPXE | 19:33 |
jroll | this should work with agent + whole disk images | 19:33 |
jroll | and probably whole disk images in general | 19:33 |
jroll | or maybe not, I think pxe driver chain loads pxe to disk or something ridiculous | 19:34 |
alexpilotti | jroll: yep, that’s how it works | 19:34 |
*** vishwanathj has joined #openstack-ironic | 19:35 | |
TheJulia | jroll: I agree, although the agent is going to need to learn to repair gpt tables after the image has been written out | 19:35 |
NobodyCam | you could deploy a non gpt whole-disk image then run gdisk to upgrade: One of the best features of gdisk (and sgdisk and cgdisk too) is its ability to convert MBR and BSD disklabels to GPT without data loss. | 19:36 |
alexpilotti | was wondering if we can set the target server to boot from local disk and having IPMI to ask to boot from PXE | 19:36 |
jroll | TheJulia: yeah, and also how to do configdrive on gpt | 19:36 |
TheJulia | jroll: yup | 19:36 |
TheJulia | (this is one of those things floating around in the back of her brain at the moment) | 19:36 |
jroll | alexpilotti: I have no clue why the pxe driver does a pxe chainload thing instead of setting boot from disk, but I assume there was a reason for it... | 19:37 |
NobodyCam | so tentent instances can not boot with out a control plane | 19:37 |
alexpilotti | NobodyCam TheJulia: nice idea! this is something requiring changes in the agent or there’s a way to instruct it to do so? | 19:37 |
TheJulia | it would require changes in the agent | 19:38 |
alexpilotti | and the node definition should have a property stating the partitioning model I guess | 19:38 |
TheJulia | it would be easy for the agent to look back at the disk and identify if its mbr or gpt, and act accordingly | 19:39 |
TheJulia | well, relatively easy | 19:39 |
alexpilotti | TheJulia: but this assumes that we have a mandatory partitioning model? | 19:40 |
jroll | NobodyCam: that sounds like a bug, not a feature | 19:40 |
TheJulia | alexpilotti: your image should have it's basic partitioning in it | 19:40 |
TheJulia | alexpilotti: Think about it as we're putting a small image on a larger disk :) | 19:40 |
NobodyCam | :/ | 19:41 |
TheJulia | jroll: Some people I've spoken to actually prefer it that way | 19:41 |
TheJulia | something about having central control over kernels and ramdisks | 19:42 |
jroll | TheJulia: yeah, they're insane :) | 19:42 |
jroll | well, that's a non-argument with whole disk images | 19:42 |
TheJulia | yup | 19:42 |
jroll | so I don't get it at all | 19:42 |
TheJulia | well, agree that its a non-argument, I didn't administer sanity tests at all | 19:42 |
alexpilotti | TheJulia: sure, was just about the necessity of a GPT to MBR on the fly conversion, as at that point we can just convert it before storeing it in Glance | 19:43 |
alexpilotti | to recap, you guys say that we can do whole disk + UEFI? | 19:44 |
jroll | I have no clue about UEFI | 19:44 |
TheJulia | alexpilotti: I say give it a shot, and we classify any issues you encounter trying to use a whole disk image as bugs | 19:45 |
jroll | +1 | 19:46 |
*** pal has quit IRC | 19:46 | |
*** achanda has quit IRC | 19:46 | |
TheJulia | Personally, I've not tried it and cannot say it will work, your bound to encounter an issue or two, but that is why we're here :) | 19:46 |
*** krtaylor has quit IRC | 19:46 | |
NobodyCam | ++ | 19:46 |
*** athomas has quit IRC | 19:47 | |
alexpilotti | TheJulia: thanks, we tried with the PXE and it failed, trying again to see what exact errors we got | 19:47 |
alexpilotti | TheJulia jroll: unrelated, following up to a coversation a few weeks ago: we’re adding ironic configdrive support in Cloudbase-Init this week | 19:48 |
NobodyCam | alexpilotti: I can say that the iLo driver do support UEFI | 19:48 |
*** HenryG has quit IRC | 19:49 | |
*** pal has joined #openstack-ironic | 19:49 | |
alexpilotti | on VMs configdrives are disks, in Ironic partitions, so we just have to look for those as well | 19:49 |
*** jjohnson2 has joined #openstack-ironic | 19:49 | |
TheJulia | alexpilotti: awesome! | 19:49 |
jroll | alexpilotti: woot | 19:49 |
*** e0ne has quit IRC | 19:51 | |
*** HenryG has joined #openstack-ironic | 19:52 | |
*** meghal has joined #openstack-ironic | 19:55 | |
*** e0ne has joined #openstack-ironic | 19:55 | |
*** vishwanathj has quit IRC | 19:57 | |
*** krtaylor has joined #openstack-ironic | 19:59 | |
*** meghal has quit IRC | 19:59 | |
*** meghal has joined #openstack-ironic | 20:00 | |
*** meghal has quit IRC | 20:01 | |
*** meghal has joined #openstack-ironic | 20:01 | |
alexpilotti | so, looks like by setting the BIOS to boot from disk as first option and PXE as second we are good, still testing | 20:02 |
*** puranamr has quit IRC | 20:02 | |
*** e0ne has quit IRC | 20:03 | |
*** puranamr has joined #openstack-ironic | 20:03 | |
*** kkoski has quit IRC | 20:06 | |
*** kkoski has joined #openstack-ironic | 20:07 | |
TheJulia | Well, ultimately you would still want to do whole disk images via the agent :) | 20:07 |
*** vishwanathj has joined #openstack-ironic | 20:10 | |
*** e0ne has joined #openstack-ironic | 20:11 | |
*** kkoski has quit IRC | 20:11 | |
*** meghal has quit IRC | 20:16 | |
*** openstackgerrit has quit IRC | 20:16 | |
*** meghal has joined #openstack-ironic | 20:16 | |
NobodyCam | w00t: https://review.openstack.org/#/c/198771 approved | 20:17 |
*** openstackgerrit has joined #openstack-ironic | 20:17 | |
*** jaypipes has joined #openstack-ironic | 20:18 | |
jaypipes | dtantsur|afk: so, does ironic-inspector publish a RESTful API? if it does, then sure, of course it should have a service type and appear in the Keystone service catalog. If it doesn't there's no need to have one. | 20:18 |
NobodyCam | hey jaypipes welocme to Ironic-landa | 20:19 |
NobodyCam | welcome even | 20:19 |
jaypipes | NobodyCam: holla. | 20:19 |
jroll | ohai | 20:20 |
*** vishwanathj has quit IRC | 20:20 | |
openstackgerrit | Stephanie Miller proposed openstack/bifrost: Clarify variable names & cleanup docs https://review.openstack.org/207206 | 20:23 |
*** achanda has joined #openstack-ironic | 20:25 | |
*** meghal has quit IRC | 20:27 | |
*** achanda has quit IRC | 20:34 | |
*** achanda has joined #openstack-ironic | 20:35 | |
*** jjohnson2 has quit IRC | 20:35 | |
*** jjohnson2 has joined #openstack-ironic | 20:36 | |
*** achanda has quit IRC | 20:41 | |
*** davideagnello has joined #openstack-ironic | 20:41 | |
openstackgerrit | OpenStack Proposal Bot proposed openstack/ironic: Updated from global requirements https://review.openstack.org/206815 | 20:42 |
*** puranamr has quit IRC | 20:48 | |
*** puranamr has joined #openstack-ironic | 20:53 | |
*** pal has quit IRC | 20:54 | |
*** Sukhdev_ has quit IRC | 20:55 | |
*** meghal has joined #openstack-ironic | 20:58 | |
*** meghal has quit IRC | 20:58 | |
*** trown is now known as trown|outttypeww | 21:03 | |
*** sinval_ has joined #openstack-ironic | 21:03 | |
*** absubram has quit IRC | 21:04 | |
*** kkoski has joined #openstack-ironic | 21:11 | |
*** ekarlso has quit IRC | 21:16 | |
*** meghal has joined #openstack-ironic | 21:18 | |
*** kkoski has quit IRC | 21:20 | |
*** kkoski has joined #openstack-ironic | 21:20 | |
*** jjohnson2 has quit IRC | 21:20 | |
*** sinval_ has quit IRC | 21:23 | |
*** e0ne has quit IRC | 21:24 | |
*** kkoski has quit IRC | 21:25 | |
*** achanda has joined #openstack-ironic | 21:34 | |
*** kkoski has joined #openstack-ironic | 21:35 | |
*** achanda has quit IRC | 21:39 | |
*** ekarlso has joined #openstack-ironic | 21:44 | |
*** thiagop has quit IRC | 21:58 | |
*** Haomeng|2 has joined #openstack-ironic | 22:00 | |
*** meghal has quit IRC | 22:00 | |
*** meghal has joined #openstack-ironic | 22:01 | |
*** avladu has joined #openstack-ironic | 22:01 | |
*** meghal has quit IRC | 22:01 | |
*** meghal has joined #openstack-ironic | 22:02 | |
*** Haomeng has quit IRC | 22:02 | |
*** meghal has quit IRC | 22:04 | |
rloo | hey lucas-dinner, I ended up submitting a nova patch for CLEANWAIT: https://review.openstack.org/#/c/207236/ | 22:07 |
*** romcheg has quit IRC | 22:09 | |
*** ionutbalutoiu has quit IRC | 22:09 | |
*** achanda has joined #openstack-ironic | 22:11 | |
*** [1]cdearborn has quit IRC | 22:14 | |
*** lucas-dinner has quit IRC | 22:15 | |
*** Sukhdev_ has joined #openstack-ironic | 22:19 | |
*** mjturek1 has quit IRC | 22:23 | |
*** zz_natorious is now known as natorious | 22:29 | |
*** natorious has quit IRC | 22:34 | |
*** natorious has joined #openstack-ironic | 22:34 | |
*** jaypipes has quit IRC | 22:43 | |
*** sinval_ has joined #openstack-ironic | 22:46 | |
*** Haomeng has joined #openstack-ironic | 22:46 | |
*** Haomeng|2 has quit IRC | 22:49 | |
*** sinval has quit IRC | 22:50 | |
*** vishwanathj has joined #openstack-ironic | 22:53 | |
*** penick has joined #openstack-ironic | 22:56 | |
*** alexpilotti has quit IRC | 23:05 | |
*** avladu has quit IRC | 23:06 | |
*** sinval_ has quit IRC | 23:13 | |
*** puranamr has quit IRC | 23:18 | |
*** vishwanathj has quit IRC | 23:20 | |
*** Vikas has joined #openstack-ironic | 23:22 | |
Vikas | Hi folks, I am trying to boot an instance using pxe.ramdisk and kernel images are being deployed successfully , but at kernel initialization time its getting stuck.In console logs I can see that tgtd daemon is failing. | 23:27 |
Vikas | start iSCSI target on /dev/vda^M waiting for tgtd socket...not found^M Jul 29 23:17:17 (none) daemon.info tgtd: semkey 0x610230d1^M Jul 29 23:17:18 (none) daemon.warn tgtd: tgtd daemon started, pid:217^M Jul 29 23:17:18 (none) daemon.warn tgtd: tgtd logger started, pid:219 debug:0^M waiting for tgtd socket...found^M Jul 29 23:17:19 (none) daemon.err tgtd: iser_ib_init(3351) Failed to initialize RDMA; load kernel modules?^ | 23:28 |
Vikas | Can anybody give me some pointers please? | 23:28 |
*** zhenguo has joined #openstack-ironic | 23:31 | |
*** meghal has joined #openstack-ironic | 23:34 | |
*** jamielennox is now known as jamielennox|away | 23:39 | |
*** penick has quit IRC | 23:39 | |
*** Vikas_ has joined #openstack-ironic | 23:58 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!