| *** tango|2 has quit IRC | 00:04 | |
| *** sarob has quit IRC | 00:04 | |
| *** ccrouch has quit IRC | 00:05 | |
| *** dims has joined #heat | 00:10 | |
| *** Qiming has joined #heat | 00:13 | |
| *** dims has quit IRC | 00:14 | |
| *** dims has joined #heat | 00:14 | |
| *** ccrouch has joined #heat | 00:16 | |
| *** sjmc7 has quit IRC | 00:20 | |
| *** Qiming has quit IRC | 00:22 | |
| *** randallburt has quit IRC | 00:29 | |
| *** sdake_ has joined #heat | 00:33 | |
| *** randallburt has joined #heat | 00:36 | |
| miguelgrinberg | asalkeld: do you have a minute to chat about https://review.openstack.org/#/c/127699/? | 00:39 |
|---|---|---|
| *** alexpilotti has quit IRC | 00:40 | |
| asalkeld | ok | 00:44 |
| asalkeld | just looking | 00:44 |
| *** cody-somerville has quit IRC | 00:44 | |
| miguelgrinberg | I think your suggested solution does not work | 00:44 |
| *** shakayumi has quit IRC | 00:45 | |
| miguelgrinberg | and for context, what we want to do here is to set endpoint_type to internalURL for all clients as a default. We found that the only way right now is to set every client separately, the defaults in [clients] are not used | 00:45 |
| miguelgrinberg | because each [client_xxx] section has its own default set to externalURL | 00:46 |
| asalkeld | ok, so what you need to know is "is the value set - non-default" not as i was reading "is there a config value of this attribute name | 00:47 |
| miguelgrinberg | correct | 00:47 |
| asalkeld | does oslo.conf not give us a mechanism to say "is this the default"? | 00:47 |
| miguelgrinberg | and I achieved that by removing the defaults in the client specific sections | 00:47 |
| miguelgrinberg | maybe I need to check again, didn't find how to do that | 00:48 |
| asalkeld | https://github.com/openstack/oslo.config/blob/master/oslo/config/cfg.py | 00:48 |
| asalkeld | just looking now | 00:48 |
| miguelgrinberg | but in any case, what would be the point in having a default in [client_xxx] if it will never be used? | 00:48 |
| asalkeld | i guess that's a fair point | 00:50 |
| asalkeld | can't we set the default to the value of the [clients] section? | 00:51 |
| asalkeld | miguelgrinberg, see https://github.com/openstack/oslo.config/blob/master/oslo/config/cfg.py#L231 | 00:52 |
| miguelgrinberg | Maybe, but based on the brief debugging session I did I think at the time the defaults are set the config file hasn't been read yet. | 00:52 |
| *** Drago has quit IRC | 00:52 | |
| asalkeld | you can use $another-value | 00:52 |
| asalkeld | so that the use of the config variable will be like any other cofig | 00:53 |
| miguelgrinberg | okay, that might work | 00:53 |
| asalkeld | it makes it easier to use | 00:53 |
| miguelgrinberg | let me give that a try, if that works I'll resubmit with that. Thanks! | 00:53 |
| asalkeld | np | 00:53 |
| *** spzala has joined #heat | 00:55 | |
| asalkeld | miguelgrinberg, :-( | 00:57 |
| asalkeld | https://github.com/openstack/oslo.config/blob/master/oslo/config/cfg.py#L241-L244 | 00:57 |
| asalkeld | don't think that will work | 00:57 |
| miguelgrinberg | oh crap | 00:57 |
| asalkeld | totally | 00:58 |
| asalkeld | was a nice idea tho' | 00:58 |
| miguelgrinberg | yeah, would have been really nice | 00:58 |
| miguelgrinberg | very explicit | 00:59 |
| asalkeld | would be worth adding that to oslo.config so we can using it later | 00:59 |
| *** ramishra has joined #heat | 01:00 | |
| miguelgrinberg | I'll play with oslo.config a bit and see what can be done | 01:01 |
| asalkeld | cool, we can merge what you have tho' and clean up later | 01:02 |
| miguelgrinberg | asalkeld: that would be awesome, we would really like to have this fix by Juno. | 01:02 |
| asalkeld | ok +2'd | 01:06 |
| miguelgrinberg | thank you | 01:07 |
| *** apporc has joined #heat | 01:12 | |
| *** zhiwei has joined #heat | 01:13 | |
| *** sdake_ has quit IRC | 01:13 | |
| *** Qiming has joined #heat | 01:14 | |
| *** ramishra has quit IRC | 01:14 | |
| *** ramishra has joined #heat | 01:16 | |
| *** Yanyanhu has joined #heat | 01:20 | |
| ramishra | stevebaker: Hi | 01:22 |
| *** achanda has joined #heat | 01:24 | |
| *** EricGonczer_ has joined #heat | 01:24 | |
| *** rwsu has quit IRC | 01:30 | |
| *** Yanyanhu has quit IRC | 01:32 | |
| *** achanda__ has quit IRC | 01:32 | |
| *** EricGonczer_ has quit IRC | 01:32 | |
| *** gooblja_ has joined #heat | 01:32 | |
| *** EricGonczer_ has joined #heat | 01:32 | |
| *** ipolyzos_ has joined #heat | 01:32 | |
| *** erkules_ has joined #heat | 01:32 | |
| *** achanda_ has joined #heat | 01:32 | |
| *** zhiyan|afk has joined #heat | 01:32 | |
| *** Adri2000_ has joined #heat | 01:32 | |
| *** sileht_ has joined #heat | 01:32 | |
| *** stevebak` has joined #heat | 01:32 | |
| *** erkules has quit IRC | 01:32 | |
| *** rwsu has joined #heat | 01:33 | |
| *** ipolyzos has quit IRC | 01:33 | |
| *** gooblja has quit IRC | 01:33 | |
| *** zhiyan has quit IRC | 01:33 | |
| *** rushiagr_away has quit IRC | 01:33 | |
| *** stevebaker has quit IRC | 01:33 | |
| *** Adri2000 has quit IRC | 01:33 | |
| *** otoolee has quit IRC | 01:33 | |
| *** sileht has quit IRC | 01:33 | |
| *** john-n-seattle has quit IRC | 01:33 | |
| *** gooblja_ is now known as gooblja | 01:33 | |
| *** LiJiansheng has joined #heat | 01:33 | |
| *** achanda has quit IRC | 01:33 | |
| *** john-n-seattle has joined #heat | 01:34 | |
| *** achanda_ has quit IRC | 01:34 | |
| *** ramishra has quit IRC | 01:34 | |
| *** Yanyanhu has joined #heat | 01:34 | |
| *** dims has quit IRC | 01:34 | |
| *** zhiyan|afk is now known as zhiyan | 01:34 | |
| *** EricGonczer_ has quit IRC | 01:34 | |
| *** dims has joined #heat | 01:35 | |
| *** rushiagr_away has joined #heat | 01:35 | |
| *** achanda has joined #heat | 01:35 | |
| *** openstack has joined #heat | 01:43 | |
| Qiming | stevebak`, there? | 01:52 |
| *** anteaya has joined #heat | 01:52 | |
| *** openstackgerrit has joined #heat | 01:52 | |
| asalkeld | Qiming, might be lunch in NZ | 01:52 |
| Qiming | aha, 4 hours diff from Beijing | 01:52 |
| *** LiJiansheng has quit IRC | 01:52 | |
| *** nosnos has joined #heat | 01:52 | |
| *** spzala has quit IRC | 01:52 | |
| *** rushiagr_away has joined #heat | 01:52 | |
| *** otoolee has joined #heat | 01:53 | |
| *** randallburt has quit IRC | 01:56 | |
| *** shakamunyi has joined #heat | 01:58 | |
| *** sdake_ has joined #heat | 02:00 | |
| *** LiJiansheng has joined #heat | 02:02 | |
| *** tonisbones has joined #heat | 02:05 | |
| *** tonisbones has quit IRC | 02:09 | |
| *** sdake has quit IRC | 02:10 | |
| *** larsks|alt is now known as larsks | 02:12 | |
| *** harlowja is now known as harlowja_away | 02:21 | |
| *** shakayumi has joined #heat | 02:24 | |
| *** shakamunyi has quit IRC | 02:27 | |
| openstackgerrit | liusheng proposed a change to openstack/heat: Log translation hint for Heat.contrib https://review.openstack.org/109484 | 02:27 |
| *** Yanyanhu has quit IRC | 02:28 | |
| *** Yanyanhu has joined #heat | 02:28 | |
| openstackgerrit | A change was merged to openstack/heat: Add tox genconfig target https://review.openstack.org/128441 | 02:30 |
| openstackgerrit | A change was merged to openstack/heat: Remove unused oslo lockutils module https://review.openstack.org/128267 | 02:31 |
| *** shardy has quit IRC | 02:32 | |
| *** dims has joined #heat | 02:36 | |
| *** sdake_ has quit IRC | 02:37 | |
| *** dims has quit IRC | 02:40 | |
| *** sdake_ has joined #heat | 02:43 | |
| openstackgerrit | A change was merged to openstack/heat: Clarify snapshot deletion methods https://review.openstack.org/117473 | 02:44 |
| openstackgerrit | A change was merged to openstack/heat: Make Rackspace Cloud DNS TTL constraints match API https://review.openstack.org/128061 | 02:44 |
| openstackgerrit | A change was merged to openstack/heat: Adding tests for sahara client exeptions https://review.openstack.org/127927 | 02:44 |
| asalkeld | phew reached my review limit | 02:56 |
| zhiwei | Hi, asalkeld. I saw some log message use dict(key=val) and others {'key': 'val'}. Which is preferred? | 02:56 |
| asalkeld | zhiwei, I am not sure it's import to me | 02:56 |
| asalkeld | what ever makes sense to the person writing it? | 02:57 |
| zhiwei | but one of my forks want me to change dict() to {} | 02:57 |
| zhiwei | and I don't want to change this. | 02:57 |
| asalkeld | one of your "forks"? | 02:57 |
| asalkeld | rebases? | 02:57 |
| zhiwei | sorry. | 02:58 |
| asalkeld | zhiwei, what do you mean by "one of my forks" | 02:58 |
| zhiwei | my work mates. | 02:58 |
| asalkeld | i see | 02:58 |
| asalkeld | tell him/her "get over it" | 02:58 |
| asalkeld | ;) | 02:58 |
| zhiwei | but he did not listen to me. | 02:59 |
| asalkeld | more important stuff to worry about IMHO | 02:59 |
| asalkeld | zhiwei, what's the review? | 02:59 |
| asalkeld | i normally write code that looks like the code around it, so it fits in | 03:00 |
| asalkeld | just try match what's around what you are doing | 03:00 |
| asalkeld | so when you are reading the code it looks consistent | 03:01 |
| asalkeld | zhiwei, does that ^ seem reasonable to you? | 03:01 |
| zhiwei | yes, I think it's ok for us. | 03:01 |
| zhiwei | I changed `i = i + 1` to `i += 1` before, but I don't want to change this again. | 03:02 |
| asalkeld | yeah, i think it's important as a reviewer to "pick your battles" | 03:03 |
| asalkeld | and not get too picky | 03:03 |
| *** stevebak` is now known as stevebaker | 03:03 | |
| * asalkeld is trotting off to have lunch - brb | 03:04 | |
| zhiwei | asalkeld: :) | 03:10 |
| *** achanda has quit IRC | 03:14 | |
| *** achanda_ has joined #heat | 03:17 | |
| *** radez is now known as radez_g0n3 | 03:26 | |
| *** ramishra has joined #heat | 03:32 | |
| *** ramishra has quit IRC | 03:35 | |
| *** ramishra has joined #heat | 03:35 | |
| openstackgerrit | A change was merged to openstack/heat: Log translation hint for Heat.engine (part2) https://review.openstack.org/123387 | 03:36 |
| openstackgerrit | A change was merged to openstack/heat: Log translation hint for Heat.engine (part3) https://review.openstack.org/123388 | 03:37 |
| *** Goneri has quit IRC | 03:49 | |
| *** ramishra has quit IRC | 03:49 | |
| *** nosnos has quit IRC | 03:50 | |
| tiantian | asalkeld: around? | 03:50 |
| asalkeld | hi, yip | 03:50 |
| *** nosnos has joined #heat | 03:51 | |
| tiantian | https://bugs.launchpad.net/heat/+bug/1381298 please have a look | 03:51 |
| uvirtbot | Launchpad bug 1381298 in heat "Autoscaling failed due to the roles" [Undecided,New] | 03:51 |
| *** achampion has quit IRC | 03:51 | |
| asalkeld | okie dokie | 03:51 |
| *** achampion has joined #heat | 03:52 | |
| asalkeld | tiantian, can I defer to shardy for that one? | 03:52 |
| asalkeld | but sounds about right | 03:53 |
| asalkeld | reminds me a little of another bug tho' | 03:53 |
| tiantian | And I will commit a patch for it, but I'm not sure it's right way | 03:53 |
| *** wpf has quit IRC | 03:54 | |
| tiantian | I found when create a trust context, only give the "heat_stack_owner" role, I think should inherit the roles | 03:55 |
| *** nosnos has quit IRC | 03:55 | |
| openstackgerrit | huangtianhua proposed a change to openstack/heat: Inherit roles for create_trust_context() https://review.openstack.org/128509 | 04:01 |
| asalkeld | tiantian, https://bugs.launchpad.net/heat/+bug/1376562 | 04:02 |
| uvirtbot | Launchpad bug 1376562 in heat "Can't delegate optional roles" [High,Triaged] | 04:02 |
| *** swygue has joined #heat | 04:04 | |
| asalkeld | tiantian, would you be fixing both at the same time/ | 04:06 |
| *** renlt has joined #heat | 04:07 | |
| tiantian | asalkeld: https://review.openstack.org/128509 is't ok handle in this way? | 04:07 |
| asalkeld | tiantian, that looks good to me | 04:08 |
| asalkeld | this seems to be shardy's suggestion in bug 1376562 | 04:09 |
| uvirtbot | Launchpad bug 1376562 in heat "Can't delegate optional roles" [High,Triaged] https://launchpad.net/bugs/1376562 | 04:09 |
| asalkeld | his "option 1" | 04:09 |
| tiantian | yeah, I see it:) | 04:10 |
| asalkeld | tiantian, i think reference that bug in you patch too | 04:10 |
| asalkeld | so steven picks up on it | 04:10 |
| tiantian | I will add shardy to review my patch, and let's see what he suggest | 04:11 |
| asalkeld | tiantian, a test would be good too | 04:11 |
| tiantian | tks,will add the test:) | 04:12 |
| openstackgerrit | huangtianhua proposed a change to openstack/heat: Inherit roles for create_trust_context() https://review.openstack.org/128509 | 04:15 |
| *** ramishra has joined #heat | 04:20 | |
| *** dims has joined #heat | 04:25 | |
| *** ramishra has quit IRC | 04:26 | |
| *** achampion has quit IRC | 04:28 | |
| *** achampion has joined #heat | 04:29 | |
| *** dims has quit IRC | 04:29 | |
| *** nosnos has joined #heat | 04:30 | |
| *** andreaf has joined #heat | 04:30 | |
| *** ramishra has joined #heat | 04:32 | |
| *** wpf has joined #heat | 04:47 | |
| *** sanjayu has joined #heat | 04:47 | |
| *** achanda_ has quit IRC | 04:49 | |
| *** achanda_ has joined #heat | 04:52 | |
| *** rushiagr_away is now known as rushiagr | 04:59 | |
| *** sdake_ has quit IRC | 05:02 | |
| *** arunrajan has joined #heat | 05:03 | |
| *** Yanyan has joined #heat | 05:11 | |
| *** rushiagr is now known as rushiagr_away | 05:11 | |
| *** jyoti-ranjan has joined #heat | 05:14 | |
| openstackgerrit | Mike Spreitzer proposed a change to openstack/heat: Implement AZ spanning for AWS ASGs https://review.openstack.org/116139 | 05:14 |
| *** saju_m has joined #heat | 05:14 | |
| *** lazy_prince has quit IRC | 05:15 | |
| *** Yanyanhu has quit IRC | 05:15 | |
| openstackgerrit | Mike Spreitzer proposed a change to openstack/heat: Implement AZ spanning for AWS ASGs https://review.openstack.org/116139 | 05:16 |
| *** rakesh_hs has joined #heat | 05:19 | |
| *** harlowja_at_home has joined #heat | 05:20 | |
| openstackgerrit | Mike Spreitzer proposed a change to openstack/heat: Implement AZ spanning for AWS ASGs https://review.openstack.org/116139 | 05:23 |
| openstackgerrit | Ethan Lynn proposed a change to openstack/heat: Add unicode support for resource name https://review.openstack.org/128157 | 05:30 |
| *** elynn has joined #heat | 05:31 | |
| *** Qiming_ has joined #heat | 05:31 | |
| *** rushiagr_away is now known as rushiagr | 05:32 | |
| *** Qiming_ has quit IRC | 05:33 | |
| *** Qiming_ has joined #heat | 05:34 | |
| *** Qiming has quit IRC | 05:34 | |
| *** harlowja_at_home has quit IRC | 05:38 | |
| *** Qiming_ has quit IRC | 05:38 | |
| *** sileht_ is now known as sileht | 05:38 | |
| *** sileht has joined #heat | 05:40 | |
| *** jprovazn has joined #heat | 05:42 | |
| openstackgerrit | Adrian Vladu proposed a change to openstack/heat-templates: Added Puppet Agent HOT https://review.openstack.org/128561 | 05:42 |
| *** ifarkas has joined #heat | 05:43 | |
| *** achanda has joined #heat | 05:45 | |
| openstackgerrit | Adrian Vladu proposed a change to openstack/heat-templates: Added Puppet Agent HOT https://review.openstack.org/128561 | 05:46 |
| *** nkhare has joined #heat | 05:48 | |
| *** ckmvishnu has joined #heat | 05:48 | |
| *** achanda_ has quit IRC | 05:49 | |
| *** kopparam has joined #heat | 05:49 | |
| *** unmeshg has joined #heat | 05:53 | |
| *** Goneri has joined #heat | 05:53 | |
| *** killer_prince has joined #heat | 05:56 | |
| *** killer_prince is now known as lazy_prince | 05:57 | |
| *** cmyster has joined #heat | 06:00 | |
| *** cmyster has quit IRC | 06:00 | |
| *** cmyster has joined #heat | 06:00 | |
| openstackgerrit | OpenStack Proposal Bot proposed a change to openstack/heat: Imported Translations from Transifex https://review.openstack.org/128188 | 06:03 |
| *** saju_m has quit IRC | 06:05 | |
| *** zigo has joined #heat | 06:08 | |
| *** julienvey has joined #heat | 06:08 | |
| *** metral has quit IRC | 06:09 | |
| *** ramishra has quit IRC | 06:09 | |
| *** metral has joined #heat | 06:09 | |
| *** dims has joined #heat | 06:13 | |
| openstackgerrit | A change was merged to openstack/heat: Log translation hint for Heat.engine (part1) https://review.openstack.org/109512 | 06:16 |
| *** dims has quit IRC | 06:18 | |
| *** arunrajan has left #heat | 06:21 | |
| skraynev | good morning | 06:22 |
| skraynev | hi aslkeld | 06:22 |
| skraynev | s/aslkeld/asalkeld | 06:23 |
| asalkeld | hi skraynev | 06:25 |
| *** erkules_ is now known as erkules | 06:27 | |
| *** ananta has joined #heat | 06:34 | |
| *** asalkeld has quit IRC | 06:35 | |
| *** d0m0reg00dthing has joined #heat | 06:39 | |
| *** d0m0reg00dthing has quit IRC | 06:40 | |
| *** tomek_adamczewsk has joined #heat | 06:44 | |
| *** tspatzier has joined #heat | 06:45 | |
| *** achanda has quit IRC | 06:45 | |
| *** swygue has quit IRC | 06:46 | |
| *** saju_m has joined #heat | 06:47 | |
| *** andreaf has quit IRC | 06:50 | |
| *** asalkeld has joined #heat | 06:52 | |
| *** Adri2000_ is now known as Adri2000 | 06:54 | |
| *** jcoufal has joined #heat | 06:55 | |
| cmyster | morning | 06:57 |
| *** robklg has joined #heat | 06:57 | |
| skraynev | hi cmyster | 06:57 |
| *** jstrachan has joined #heat | 07:00 | |
| *** Guest86578 is now known as d0ugal | 07:04 | |
| *** d0ugal has quit IRC | 07:05 | |
| *** d0ugal has joined #heat | 07:05 | |
| *** ccrouch has quit IRC | 07:08 | |
| *** andersonvom has joined #heat | 07:08 | |
| *** ccrouch has joined #heat | 07:09 | |
| *** pas-ha has joined #heat | 07:11 | |
| pas-ha | morning all :) | 07:11 |
| *** tspatzier__ has joined #heat | 07:12 | |
| asalkeld | hi pas-ha | 07:12 |
| *** sabeen1 has joined #heat | 07:15 | |
| *** tspatzier has quit IRC | 07:15 | |
| *** sabeen3 has quit IRC | 07:16 | |
| *** pasquier-s has joined #heat | 07:24 | |
| cmyster | hi | 07:24 |
| skraynev | hey pas-ha | 07:25 |
| *** shardy has joined #heat | 07:25 | |
| *** Yanyan has quit IRC | 07:30 | |
| *** mcwoods has joined #heat | 07:36 | |
| gooblja | Is somebody familiar with oslo messaging? I am truing to get heat notifications similar as it is done in ceilometer. I have qpid queue. and I am truing it with the code http://paste.openstack.org/show/121183/ but i get error : oslo.config.cfg.DuplicateOptError: duplicate option: rpc_backend :) maybe somebody has a clue? | 07:40 |
| *** Yanyanhu has joined #heat | 07:42 | |
| gooblja | error is shown when function get_transport is called :( | 07:44 |
| asalkeld | gooblja, remove the config option | 07:46 |
| asalkeld | and just hardcode (for now) the exchange | 07:47 |
| *** achanda has joined #heat | 07:57 | |
| *** liusheng has joined #heat | 07:58 | |
| *** tomek_adamczewsk has quit IRC | 07:59 | |
| *** tomek_adamczewsk has joined #heat | 08:00 | |
| *** jistr has joined #heat | 08:02 | |
| *** achanda has quit IRC | 08:02 | |
| *** tomek_adamczewsk has quit IRC | 08:02 | |
| *** tomek_adamczewsk has joined #heat | 08:03 | |
| *** derekh has joined #heat | 08:06 | |
| *** ishant has joined #heat | 08:10 | |
| *** alexpilotti has joined #heat | 08:11 | |
| *** jamiehannaford has joined #heat | 08:12 | |
| openstackgerrit | Tetiana Lashchova proposed a change to openstack/heat: Create security group rules in loose loop https://review.openstack.org/128234 | 08:15 |
| *** tomek_adamczewsk has quit IRC | 08:20 | |
| *** stannie has joined #heat | 08:30 | |
| *** kopparam has quit IRC | 08:30 | |
| *** rwsu has quit IRC | 08:31 | |
| *** kopparam has joined #heat | 08:31 | |
| shardy | tiantian: hey, do you have a moment to discuss https://review.openstack.org/#/c/128509/2? | 08:35 |
| shardy | It looks basically good, but I'd like to figure out a way to make it solve bug #1376562 | 08:36 |
| uvirtbot | Launchpad bug 1376562 in heat "Can't delegate optional roles" [High,Triaged] https://launchpad.net/bugs/1376562 | 08:36 |
| openstackgerrit | A change was merged to openstack/heat: Log translation hint for Heat.contrib https://review.openstack.org/109484 | 08:40 |
| *** fayablazer has joined #heat | 08:44 | |
| *** my_openstack_use has joined #heat | 08:49 | |
| shadower | shardy: thanks for the resourcegroup patches, I'll have a look at them later today | 08:53 |
| shardy | shadower: np, please let me know if they do what you need :) | 08:54 |
| shardy | I'll push another revision shortly with the interface tweaks requested by stevebaker | 08:54 |
| *** julienvey has quit IRC | 08:54 | |
| shadower | shardy: yep, will do. SpamapS will have a thing or two to say, too, I'm sure | 08:54 |
| shardy | shadower: Yeah he left a positive comment on the review, which seems a good start :) | 08:55 |
| *** rwsu has joined #heat | 08:56 | |
| shadower | oh cool | 08:56 |
| *** julienvey has joined #heat | 08:56 | |
| *** mkerrin has quit IRC | 08:56 | |
| shadower | shardy: there's no chance the patches will get into Juno Heat though, is there? | 08:56 |
| *** Putns has joined #heat | 08:56 | |
| *** lazy_prince is now known as killer_prince | 08:57 | |
| *** tomek_adamczewsk has joined #heat | 08:58 | |
| *** killer_prince has quit IRC | 09:00 | |
| openstackgerrit | Hang Liu proposed a change to openstack/heat: Change ThreadGroupManager.remove_event() to be compatible with greenthread callback https://review.openstack.org/128580 | 09:00 |
| *** lazy_prince has joined #heat | 09:00 | |
| *** sorantis has joined #heat | 09:02 | |
| *** jstrachan has quit IRC | 09:05 | |
| *** sergmelikyan has joined #heat | 09:05 | |
| shardy | shadower: unfortunately no, it's too late for Juno | 09:05 |
| shadower | oh well | 09:05 |
| *** nikunj2512 has joined #heat | 09:07 | |
| *** tomek_adamczewsk has quit IRC | 09:10 | |
| *** tomek_adamczewsk has joined #heat | 09:11 | |
| *** rushiagr is now known as rushiagr_away | 09:19 | |
| *** mkerrin has joined #heat | 09:20 | |
| *** jyoti-ranjan has quit IRC | 09:24 | |
| *** sorantis has quit IRC | 09:26 | |
| *** mkerrin has quit IRC | 09:26 | |
| *** lsmola has quit IRC | 09:26 | |
| *** jcoufal has quit IRC | 09:29 | |
| *** jcoufal has joined #heat | 09:29 | |
| openstackgerrit | Ishant Tyagi proposed a change to openstack/heat: Add DB model for resource graph and also persist the graph. https://review.openstack.org/128590 | 09:31 |
| *** renlt has quit IRC | 09:34 | |
| *** judf has quit IRC | 09:35 | |
| *** rushiagr_away is now known as rushiagr | 09:36 | |
| *** jyoti-ranjan has joined #heat | 09:37 | |
| *** lazy_prince is now known as killer_prince | 09:37 | |
| *** killer_prince is now known as lazy_prince | 09:40 | |
| cmyster | shardy: hey, is there a list of TBD tests like we have (had) for Tempest but for heat acceptance ? | 09:42 |
| *** lsmola has joined #heat | 09:42 | |
| shardy | cmyster: "heat acceptance"? | 09:46 |
| shardy | hey, btw :) | 09:46 |
| *** andreaf has joined #heat | 09:46 | |
| shardy | tbh I've lost interest in tempest recently since it became clear it's an unbelieveably unproductive time-sink | 09:47 |
| *** vijayagurug has joined #heat | 09:48 | |
| *** lazy_prince is now known as killer_prince | 09:49 | |
| cmyster | shardy: we talked about it some time ago, writing heat acceptence tests inside heat | 09:49 |
| shardy | cmyster: Do you mean the functional tests? | 09:50 |
| shardy | The idea, IIRC was to require (or strongly encourage) new features to have an associated functional test | 09:50 |
| cmyster | yes, | 09:50 |
| cmyster | a group of them | 09:50 |
| shardy | that should be possible for kilo, thanks to the work stevebaker has been doing moving things from tempest to the heat tree | 09:51 |
| shardy | cmyster: so the answer is not yet then, but we can recategorize all the tempest stuff in the heat launchpad to be tagged "functional test" or something | 09:51 |
| cmyster | each new feature will have a set of tests that we can call acceptance tests for feature X and then when its passing validation we can say its accepted as a new feature bluh bluh bluh | 09:52 |
| shardy | I think we need to get the functional test job voting first, then push on getting new tests written | 09:52 |
| cmyster | where's the job ? | 09:52 |
| shardy | cmyster: I've not used quite that terminology before, but basically yes, that sounds like what we'd like to happen | 09:52 |
| *** andreaf has quit IRC | 09:53 | |
| cmyster | shardy: its QA term' | 09:53 |
| shardy | Originally the plan was to require tempest patches to be posted for features but for obvious reasons, that's not worked out | 09:53 |
| * cmyster nods | 09:53 | |
| *** alexheneveld has joined #heat | 09:56 | |
| *** mkerrin has joined #heat | 10:00 | |
| *** jstrachan has joined #heat | 10:02 | |
| *** amakarov_away is now known as amakarov | 10:02 | |
| openstackgerrit | Visnusaran Murugan proposed a change to openstack/heat: Validation to avoid duplicate stack names per tenant https://review.openstack.org/123397 | 10:02 |
| *** cdent has joined #heat | 10:04 | |
| *** saju_m has quit IRC | 10:08 | |
| *** andreaf has joined #heat | 10:09 | |
| *** andreaf has quit IRC | 10:09 | |
| *** andreaf has joined #heat | 10:10 | |
| *** elynn has quit IRC | 10:13 | |
| *** Yanyanhu has quit IRC | 10:13 | |
| *** killer_prince is now known as lazy_prince | 10:16 | |
| *** dims has joined #heat | 10:18 | |
| *** jstrachan has quit IRC | 10:21 | |
| *** jstrachan has joined #heat | 10:22 | |
| *** ramishra has joined #heat | 10:29 | |
| *** kopparam has quit IRC | 10:42 | |
| ramishra | shardy: Hello, would like your feedback for https://review.openstack.org/#/c/128182/ | 10:42 |
| *** kopparam has joined #heat | 10:43 | |
| ramishra | shardy: please review it when you have time | 10:44 |
| *** ckmvishnu has quit IRC | 10:44 | |
| *** andreaf has quit IRC | 10:47 | |
| *** kopparam has quit IRC | 10:47 | |
| *** andreaf has joined #heat | 10:47 | |
| *** swygue has joined #heat | 10:51 | |
| *** saju_m has joined #heat | 10:52 | |
| *** saju_m has quit IRC | 10:54 | |
| *** saju_m has joined #heat | 10:54 | |
| *** mkollaro has joined #heat | 10:54 | |
| *** nkhare_ has joined #heat | 10:55 | |
| *** saju_m has quit IRC | 10:55 | |
| *** saju_m has joined #heat | 10:56 | |
| *** saju_m has quit IRC | 10:57 | |
| *** saju_m has joined #heat | 10:57 | |
| *** nkhare has quit IRC | 10:58 | |
| shardy | ramishra: Hi! sure, will do | 10:58 |
| *** andreaf has quit IRC | 11:00 | |
| openstackgerrit | unmesh-gurjar proposed a change to openstack/heat: Database models and apis for convergence https://review.openstack.org/109012 | 11:09 |
| *** jprovazn has quit IRC | 11:09 | |
| *** nikunj2512 has quit IRC | 11:10 | |
| *** kopparam has joined #heat | 11:11 | |
| *** ckmvishnu has joined #heat | 11:13 | |
| *** zhiwei has quit IRC | 11:16 | |
| *** ramishra has quit IRC | 11:24 | |
| *** ramishra has joined #heat | 11:25 | |
| *** ramishra has quit IRC | 11:26 | |
| *** ramishra has joined #heat | 11:26 | |
| openstackgerrit | unmesh-gurjar proposed a change to openstack/heat: Added observed properties to resource show output https://review.openstack.org/112838 | 11:27 |
| *** apporc has quit IRC | 11:31 | |
| *** my_openstack_use has quit IRC | 11:32 | |
| asalkeld | unmeshg, we should probably have somewhere people can give feedback on that design | 11:33 |
| asalkeld | maybe an etherpad? | 11:33 |
| asalkeld | on the wiki | 11:33 |
| asalkeld | doh, it's right there | 11:34 |
| *** radez_g0n3 is now known as radez | 11:37 | |
| *** ramishra has quit IRC | 11:38 | |
| unmeshg | @asalkeld: yeah...its in the wiki | 11:41 |
| asalkeld | yes, thanks busy there now | 11:41 |
| *** nikunj2512 has joined #heat | 11:41 | |
| *** pasquier-s has quit IRC | 11:42 | |
| *** swygue has quit IRC | 11:43 | |
| *** ramishra has joined #heat | 11:47 | |
| *** andersonvom has quit IRC | 11:50 | |
| *** Qiming has joined #heat | 11:51 | |
| *** cmyster has quit IRC | 11:52 | |
| *** andersonvom has joined #heat | 11:53 | |
| *** andersonvom has joined #heat | 11:54 | |
| *** nkhare_ has quit IRC | 11:55 | |
| *** lazy_prince is now known as killer_prince | 11:55 | |
| *** ananta has quit IRC | 11:55 | |
| *** mspreitz has joined #heat | 11:55 | |
| *** unmeshg has left #heat | 11:56 | |
| *** inc0 has joined #heat | 11:57 | |
| *** rpothier has joined #heat | 11:57 | |
| inc0 | hello | 11:57 |
| asalkeld | hi | 11:57 |
| *** ananta has joined #heat | 11:58 | |
| *** rakesh_hs has quit IRC | 11:58 | |
| *** unmeshg_ has joined #heat | 11:58 | |
| *** rakesh_hs has joined #heat | 11:59 | |
| *** tspatzier__ is now known as tspatzier | 11:59 | |
| inc0 | https://www.mail-archive.com/openstack-dev@lists.openstack.org/msg37483.html I've proposed this to be part of convergence, any thoughts guys? | 12:00 |
| *** ramishra has quit IRC | 12:00 | |
| *** killer_prince is now known as lazy_prince | 12:00 | |
| *** ananta has quit IRC | 12:01 | |
| *** jdandrea has quit IRC | 12:09 | |
| *** jdandrea has joined #heat | 12:09 | |
| *** EricGonczer_ has joined #heat | 12:10 | |
| *** lazy_prince is now known as killer_prince | 12:10 | |
| *** ananta has joined #heat | 12:11 | |
| *** dims has quit IRC | 12:11 | |
| *** dims has joined #heat | 12:12 | |
| *** EricGonczer_ has quit IRC | 12:14 | |
| *** dims_ has joined #heat | 12:14 | |
| *** alexheneveld has quit IRC | 12:15 | |
| *** dims has quit IRC | 12:16 | |
| *** aweiteka has joined #heat | 12:16 | |
| *** killer_prince is now known as lazy_prince | 12:23 | |
| *** bdossant has joined #heat | 12:24 | |
| *** lazy_prince is now known as killer_prince | 12:26 | |
| *** jdob has joined #heat | 12:27 | |
| *** alexheneveld has joined #heat | 12:28 | |
| *** pasquier-s has joined #heat | 12:34 | |
| *** ishant2 has joined #heat | 12:37 | |
| *** ramishra has joined #heat | 12:38 | |
| *** kopparam has quit IRC | 12:40 | |
| *** kopparam has joined #heat | 12:41 | |
| *** spzala has joined #heat | 12:41 | |
| therve | inc0, Why you don't want it to happen? | 12:44 |
| therve | (sarcarsm) | 12:45 |
| *** kopparam has quit IRC | 12:45 | |
| inc0 | therve, explain please? I'm code developer, I'm oblivious to such basic communication issues | 12:46 |
| *** spzala has quit IRC | 12:49 | |
| *** andreaf has joined #heat | 12:52 | |
| *** sanjayu has quit IRC | 12:53 | |
| *** simonc has joined #heat | 12:59 | |
| *** andreaf has quit IRC | 13:00 | |
| mspreitz | ananta: are you here? | 13:00 |
| ananta | mspreitz...yeah... | 13:00 |
| ananta | sorry i lost some context | 13:01 |
| asalkeld | g'night it is 11pm here | 13:01 |
| mspreitz | I want to ask about the future of OS::Heat::HARestarter | 13:01 |
| *** asalkeld has quit IRC | 13:01 | |
| Qiming | asalkeld, bye | 13:01 |
| mspreitz | Do you agree that when the time comes... | 13:01 |
| skraynev | asalkeld: g' night | 13:02 |
| inc0 | mspreitz, one thing, how do you want to autoheal instance that is supposed to be failed? | 13:02 |
| mspreitz | we can replace the implementation of HARestarter? | 13:02 |
| Qiming | mspreitz, many ways, in addition to delete + create | 13:02 |
| mspreitz | inc0: note that the pattern I have been following is health maint. on a user-chosen assembly, not necessarily a single resrouce | 13:02 |
| *** andreaf has joined #heat | 13:03 | |
| *** ckmvishnu has left #heat | 13:03 | |
| mspreitz | ananta: my concern is that some people have said that HARestarter is inconsistent with convergence | 13:03 |
| mspreitz | ananta: but we need to give users at least a transition period of 1 release | 13:03 |
| ananta | mspreitz: i need to look at HARestarter | 13:04 |
| mspreitz | ananta: or no need to transition, if we can change the implementation behind the resource names that they write in their templates | 13:04 |
| ananta | BTW, how is it related to convergence? | 13:04 |
| ryansb | mspreitz: I feel like changing behavior of HARestarter wouldn't be great (ambiguity, since users don't necessarily know what Heat version their provider runs) I'd much rather have a new resource & deprecate HARestarter | 13:04 |
| ryansb | instead of having users think it does X where it actually does Y in their version. | 13:04 |
| mspreitz | Look at the Heat chat two weeks ago, and at the patch for deprecating HARestarter... | 13:04 |
| mspreitz | you will see remarks, and who made them, about HARestarter being inconsistent with convergence | 13:05 |
| ananta | ok | 13:05 |
| zaneb | spoiler: it was me | 13:05 |
| mspreitz | ryansb: exactly. My whole concern here is treating users right | 13:05 |
| mspreitz | zane: do you think now that we could simply change the implemenation behind the buggy name? | 13:05 |
| mspreitz | and, separately, fix the name bug | 13:06 |
| mspreitz | (fixing the name bug can obviously be done with a proper transition period) | 13:06 |
| ryansb | That seems like it'd be more confusing for users than introducing a new resource & deprecating HARestarter | 13:07 |
| zaneb | so... it'll be the same except for the name and the implementation? | 13:07 |
| *** swygue has joined #heat | 13:07 | |
| *** tonisbones has joined #heat | 13:07 | |
| mspreitz | ryansb: when I speak of changing the implementation, I mean to NOT change the net result, only how it is accomplished. To users it would be a non-change. | 13:08 |
| mspreitz | zaneb: the name change would be a separate change, done in a way that does NOT introduce confusion. | 13:09 |
| ryansb | ah, I see what you're saying. I thought you meant change as in "fix bugs & work a bit differently to make more sense" not just "fix bugs w/ no user facing change" | 13:09 |
| mspreitz | zaneb: can we leave the name change out of it for now, and focus on the harder problem first? | 13:09 |
| zaneb | the implementation isn't the problem though. *everything* is the problem. it's completely broken by design | 13:09 |
| mspreitz | zaneb: I recall you saying things like that before. Which is why I am dubious with what asalkeld said at the end of today's meeting. | 13:10 |
| mspreitz | namely, that we could just change the implementation without users noticing | 13:10 |
| *** rpothier has quit IRC | 13:11 | |
| mspreitz | anant: ^^^ is what I want your opinion on | 13:11 |
| mspreitz | ananta: I mean | 13:11 |
| mspreitz | ananta: are you still here? | 13:11 |
| ananta | yup | 13:12 |
| inc0 | allright...and why can't we make convergence work in exactly the same way? (we get alarm->contionous observer gets alarm->contious observer restarts an instance) | 13:12 |
| *** ramishra has quit IRC | 13:12 | |
| ananta | i was reading about HARestarter =) ... sorry my limited understanding is not helping me | 13:12 |
| mspreitz | If you want to reconvene on this topic later, I am OK with that | 13:13 |
| ananta | the way I see is that the HARestarter is another resource type...so it should be handled differently in convergence | 13:13 |
| inc0 | ananta, that would produce us exponential number of resources. HARestartedInstance, HARestartedNetwork .... | 13:14 |
| inc0 | I'll add EvacuatedOnSharedStorageInstance ;) | 13:14 |
| inc0 | couldn't we add for example something like handle_autoheal and that method itself will be plugin based? | 13:16 |
| mspreitz | I did not understand the thinking behind either ananta or inc0 remarks | 13:16 |
| *** saju_m has quit IRC | 13:16 | |
| unmeshg_ | does it sound correct that convergence should not observe resources which are in HARestarter ? | 13:16 |
| mspreitz | ananta: did you make a typo? I do not understand what you tried to say | 13:16 |
| mspreitz | unmeshg_: I an concerned about mission creep for convergence | 13:17 |
| inc0 | unmeshg_, my understanding is that it will be actually ceilometer which will observe resoruce | 13:17 |
| Qiming | IIUC, the problem lies in this line self.stack.restart_resource(victim.name), while 'restart' means different things for different resource types. | 13:17 |
| mspreitz | unmeshg_: I think convergence should keep thinks like the heat template says. Making sure that those things are really working is a higher level issue. | 13:17 |
| mspreitz | s/thinks/things | 13:17 |
| mspreitz | Qiming: there is certainly a name bug here... | 13:18 |
| Qiming | maybe we can have resource.handle_restart() default to delete followed by create, but each subclass can have its own implementation | 13:18 |
| mspreitz | Qiming: I propose to discuss that separately. For now can we pretend that the name is "delete-and-recreate-thing-and-all-its-dependents" ? | 13:18 |
| Qiming | I don't see a conflict with convergence work there, iiuc | 13:18 |
| inc0 | mspreitz, question is, is instance, which works in incorrect way, actually working? or its state is "failed" and then convergence should do its magic? | 13:19 |
| ananta | mspreitz: yup... the properties of resources as they are seen in the template | 13:19 |
| *** EricGonczer_ has joined #heat | 13:19 | |
| mspreitz | inc0: what ananta said | 13:19 |
| unmeshg_ | IMO, handle_recreate would be more appropriate than handle_restart | 13:19 |
| mspreitz | inc0: I do not think we should get convergence into the business of evaluating more than what is said in the template | 13:20 |
| ananta | mspreitz: I agree | 13:20 |
| Qiming | unmeshg_, +1, since all resources are 'created' rather than 'started' | 13:20 |
| mspreitz | Qiming, unmeshg_: YES, YESS, YESSS the name is a bug! Can we please discuss that separately? | 13:20 |
| *** Drago has joined #heat | 13:20 | |
| ananta | i think HARestarter would be a special case to be handled | 13:21 |
| mspreitz | I mean, we can fix the name bug easily and orthogonally. Let us not confuse the hard work by thinking about the name bug | 13:21 |
| zaneb | I'm fine with special cases. Not fine with designing all of convergence around one special case that will go away a release later. | 13:22 |
| unmeshg_ | @ananta: I agree | 13:22 |
| ananta | zaneb: I agree | 13:22 |
| unmeshg_ | @zaneb: eventually if we remove HARestarter, Convergence should start observing those resources as well | 13:22 |
| unmeshg_ | am I missing something ? | 13:23 |
| *** andersonvom has quit IRC | 13:23 | |
| mspreitz | unmeshg_: convergence will certainly obsserve resources, but in a shallow way | 13:23 |
| ananta | the HARestarter interferes with what convergence does..but it can be handled as a special case...i am sure there could more cases like that | 13:23 |
| zaneb | I don't think convergence should not observe those resources | 13:23 |
| zaneb | the tricky part is that HARestart performs weird operation on its containing stack | 13:23 |
| zaneb | which no other resource does, and which no resource should ever do | 13:24 |
| *** che-arne has joined #heat | 13:24 | |
| mspreitz | I think convergence should not attemt to evaluate health in as high level a way as an OS::Neutron::HealthMonitor specifies | 13:24 |
| inc0 | mspreitz, you think heat should do it at all? | 13:24 |
| *** alexpilotti has quit IRC | 13:24 | |
| Qiming | if we fix the HARestarter implementation, could we treat it as a extremely light-weight convergence engine? | 13:25 |
| mspreitz | And, as was noted in the meeting today and now here, the unit for recovery might not be an individual resource. The high level health needs to be on a user-chosen assembly of resources | 13:25 |
| *** ggiamarchi has joined #heat | 13:25 | |
| mspreitz | inc0: those words could be interpreted in a few ways... | 13:25 |
| jdandrea | unmeshg_: +1 | 13:26 |
| inc0 | mspreitz, what I mean, what will actually tell HARestarter to do HARestart? | 13:26 |
| *** andreaf has quit IRC | 13:26 | |
| inc0 | what will monitor health? Will that be heat? neutron lbaas? | 13:26 |
| inc0 | ceilometer? | 13:26 |
| mspreitz | inc0: it should be possible to get the job done through heat, but the user has to bring some intelligence to the party, through the temnplate | 13:26 |
| inc0 | mspreitz, thing is, health monitoring is a horribly complicated thing if we want to this properly (vide nova servicegroup, still has lots of issues) | 13:27 |
| mspreitz | If you look at the pattern I showed in my addition of optional health to ASG you see what I mean | 13:27 |
| mspreitz | inc0: I am not proposing to solve world peace here... | 13:27 |
| *** andreaf has joined #heat | 13:28 | |
| mspreitz | inc0: if we add the ability to maintain health as determined by LBaaS, that is a big step up from where we are today. And... | 13:28 |
| mspreitz | .. if we also expose a hook that can be used by some more sophisticated system, then we have a properly open design | 13:28 |
| mspreitz | .. that could support a user doing as sophisticated health maint. as she likes | 13:28 |
| inc0 | why not *just* expose hook (RPC and convergence_continous_observer?) to mark resources as failed? | 13:29 |
| mspreitz | inc0: the unit of failure/recovery might not be a single resource. Example: a volume | 13:29 |
| mspreitz | (zaneb: prepare, this is going in your direction) | 13:30 |
| inc0 | yes, thats other topic I'd love to mention, later -> configurable autohealing | 13:30 |
| mspreitz | inc0: OK, here comes a simplification I will defend:... | 13:30 |
| mspreitz | health maint. can and should be formulated as: test, and if it fails delete and re-create, a user-chosen assembly of resources | 13:31 |
| mspreitz | This is a pattern the world understands and uses. | 13:31 |
| inc0 | what I'm really concerned is "test" part and "delete and re-create" | 13:32 |
| mspreitz | zaneb: is that the pattern you say is broken by design? | 13:32 |
| openstackgerrit | Vijayaguru Guruchave proposed a change to openstack/python-heatclient: Pass auth_url if os_no_client_auth specified. https://review.openstack.org/127987 | 13:32 |
| zaneb | mspreitz: not sure. maybe | 13:32 |
| mspreitz | inc0: so if we expose a hook that can be used to effect the delete and re-create then the test part is extensible (which is goodness) | 13:33 |
| mspreitz | inc0: as for the delete and re-create, that is something heat knows how to do | 13:33 |
| *** jyoti-ranjan has quit IRC | 13:33 | |
| mspreitz | zaneb: can you elaborate? | 13:33 |
| *** EricGonczer_ has quit IRC | 13:33 | |
| inc0 | mspreitz, sure, but in my opinion that too is oversimplification, not all resources can be deleted and re-created | 13:33 |
| inc0 | vide volume | 13:34 |
| mspreitz | inc0: I keep saying, do not think this has to be about an individual resource | 13:34 |
| inc0 | but again, thats something we can tackle by introducing more or less plugin-based actions | 13:34 |
| zaneb | http://git.openstack.org/cgit/openstack/heat/tree/heat/engine/resources/instance.py#n63 <- this part right here is what's broken by design | 13:34 |
| mspreitz | I keep saying, the unit of health is a user-chosen assembly | 13:34 |
| zaneb | http://git.openstack.org/cgit/openstack/heat/tree/heat/engine/resources/instance.py#n103 <- also this part | 13:34 |
| mspreitz | zaneb: your concern with L63 is that one resource has an unholy relationship with a peer. That is not the only way to get the pattern I want. | 13:36 |
| Qiming | zaneb, +1 | 13:36 |
| inc0 | zaneb, why exactly "find resource" is wrong? I mean, if convergence contionus observer gets notification from nova that instance xxx has got ERROR status, shouldn't it do exactly the same? | 13:36 |
| inc0 | second thing, again, configurable, plugin based handle_autoheal will do the job | 13:36 |
| mspreitz | zaneb: about L103 --- do you think it is reasonable for a Heat API to have an operation that takes a (stack ID, resource name) and does this: delete that resource, and re-create it according to the existing template? | 13:37 |
| zaneb | inc0: resources that go digging around in the stack are evil | 13:37 |
| *** nikunj2512 has quit IRC | 13:38 | |
| mspreitz | zaneb: ... and propagate any consequent changes in the attributes | 13:39 |
| *** nikunj2512 has joined #heat | 13:39 | |
| zaneb | like an update with force-replace? | 13:40 |
| *** zz_gondoi is now known as gondoi | 13:41 | |
| *** charlesr has joined #heat | 13:41 | |
| Qiming | mspreitz, can you explain the word 'assembly'? sorry I haven't read your patch #127884, maybe I have missed something? | 13:41 |
| *** andreaf has quit IRC | 13:42 | |
| openstackgerrit | Andrea Rosa proposed a change to openstack/heat: Add validation constraints on config inputs https://review.openstack.org/105496 | 13:44 |
| *** jasond has joined #heat | 13:44 | |
| mspreitz | zaneb: yes, like an update with force-replace. Except that the caller does not provide a resource snippt, he just says "delete and re-create, you already know what I want for the create part" | 13:44 |
| mspreitz | Qiming: for "assembly" you can read "stack", that is not very different from what I mean | 13:45 |
| zaneb | mspreitz: yeah, hopefully we will soon have an update PATCH api where you don't have to supply the template again | 13:45 |
| mspreitz | Qiming: I said assembly because it does not logically have to exactly be a stack, the user requirement is only that it is a user-specified set of things (with relationships) | 13:46 |
| *** ananta has left #heat | 13:46 | |
| zaneb | I could see something where we adding a parameter listing resources we want to force to be replaced | 13:46 |
| Qiming | mspreitz, I see | 13:46 |
| *** unmeshg_ has quit IRC | 13:47 | |
| *** andreaf has joined #heat | 13:48 | |
| *** rakesh_hs has quit IRC | 13:48 | |
| *** rushiagr is now known as rushiagr_away | 13:48 | |
| mspreitz | zaneb: so you would be comfortable with a resource type that takes a template as a parameter, instantiates that template as a nested stack, monitors health info about that nested stack from LBaaS, and does a delete and re-create when LBaaS says the nested stack is unhealthy | 13:48 |
| mspreitz | zaneb: have I got that right? | 13:48 |
| mspreitz | (I really should have said the parameter is a snippet, as in OS::Heat::ASG, not just a template) | 13:50 |
| *** jmckind has joined #heat | 13:51 | |
| *** jmckind has quit IRC | 13:51 | |
| *** jmckind has joined #heat | 13:51 | |
| *** jmckind has joined #heat | 13:52 | |
| *** ishant has quit IRC | 13:52 | |
| *** jmckind has quit IRC | 13:52 | |
| *** ishant2 has quit IRC | 13:52 | |
| * mspreitz has another question, but will wait until zaneb answers the outstanding one | 13:53 | |
| *** jmckind has joined #heat | 13:53 | |
| inc0 | ok, so again, how convergence with exposed hook and configurable autoheal action doesn't solve this issue? | 13:53 |
| inc0 | (basic configuration is destroy-recreate, but I will argue that it can't be hardcoded for same reason why "restart resource" broke HARestarter) | 13:54 |
| mspreitz | inc0: your parenthetic remark looks like a digression, but I have to follow it first.. | 13:55 |
| mspreitz | inc0: what is your view of why "restart resource" broke HARestarter? | 13:55 |
| inc0 | because not every resource should be restarted | 13:55 |
| inc0 | if you have instance on host which blew up, restarting it won't really do anything | 13:56 |
| *** tango|2 has joined #heat | 13:56 | |
| mspreitz | inc0: remember that "restart" is a name bug. What HARestarter actually does is delete and re-create. Supposing Nova notices that the host is gone, the re-create will put the new server on a working host | 13:57 |
| inc0 | mspreitz, or delete whole volume with database because volume controller has lost a ping for few seconds | 13:58 |
| mspreitz | AFK | 13:58 |
| inc0 | my point is, there is no "one size fits all" approach to autohealing | 13:58 |
| inc0 | which means, that should be configurable | 13:58 |
| inc0 | per resource instance really in my opinion (not per resource type) | 13:59 |
| *** sdake_ has joined #heat | 13:59 | |
| *** kopparam has joined #heat | 13:59 | |
| inc0 | evacuation is form of autohealing, recreating is another form | 13:59 |
| inc0 | vm with DB could be evacuated and vm with frontend could be recreated | 14:00 |
| *** andreaf has quit IRC | 14:00 | |
| zaneb | mspreitz: I'd be more comfortable with that than I am with HARestarter | 14:01 |
| inc0 | zaneb, and how about my idea? | 14:01 |
| *** ramishra has joined #heat | 14:02 | |
| * mspreitz is back from AFK | 14:02 | |
| zaneb | inc0: convergence is a longer term thing. that's the whole reason for this discussion | 14:02 |
| *** EricGonczer_ has joined #heat | 14:02 | |
| mspreitz | inc0: storage volume or DB can not be healed on its own. You can only heal a larger unit that includes the storage. | 14:03 |
| mspreitz | inc0: OTOH, in some cases you can restore health with a less drastic action. E.g., for a VM a true restart might suffice in some cases. | 14:03 |
| inc0 | mspreitz, my point...configurable | 14:04 |
| inc0 | client should decide what is best way to restore health of resource | 14:04 |
| *** vijendar has quit IRC | 14:04 | |
| mspreitz | inc0: my point is that I just talked about two separate issues: scope and how to recover. And for the latter, I am dubious about anything less drastic than delete and re-create | 14:04 |
| *** aweiteka has quit IRC | 14:05 | |
| *** kopparam_ has joined #heat | 14:05 | |
| inc0 | I'm dubious about anything hardcoded | 14:05 |
| inc0 | thats my point | 14:05 |
| mspreitz | Reality is like this: in some cases a true restart of a VM is enough, but neither Heat nor LBaaS will be smart enough to know that. Better to always delete and re-create | 14:05 |
| *** alexheneveld has quit IRC | 14:05 | |
| *** aweiteka has joined #heat | 14:06 | |
| inc0 | mspreitz, not if you can't afford losing ephemeral disk | 14:06 |
| inc0 | evacuate is good approach then | 14:06 |
| mspreitz | inc0: if you can not afford to lose an ephemeral disk then you have a big problem no matter what we do! | 14:06 |
| inc0 | mspreitz, in reality, this is often a case | 14:06 |
| mspreitz | I assume the user builds a reliable distributed system | 14:06 |
| *** ramishra has quit IRC | 14:06 | |
| inc0 | mspreitz, not always they don't | 14:07 |
| openstackgerrit | Steven Hardy proposed a change to openstack/heat: ResourceGroup update refactor https://review.openstack.org/128364 | 14:07 |
| openstackgerrit | Steven Hardy proposed a change to openstack/heat: ResourceGroup add "force_remove" property https://review.openstack.org/128365 | 14:07 |
| Qiming | a (accidentally) stopped server can be started; an deleted server can be recreated; a crashed server can be rebooted/rebuilt; a server previously running on a failed host can be evacuated... heat just needs to call the existing Nova API based on the server's status. It is not always about delete-recreate. | 14:08 |
| inc0 | but still, I feel that we agree in general but we argue on something that is actually an implementational detail | 14:08 |
| *** kopparam has quit IRC | 14:08 | |
| mspreitz | inc0: in the real world there is always the possibility of a disk crash. I think what you mean is that while the user can cope, it may be expensive and he would prefer not to pay the price if he does not have to. | 14:08 |
| mspreitz | Qiming: inc0: I agree that if we want to try to get the cheaper recoveries when possible we have to have some choice. | 14:09 |
| inc0 | mspreitz, is convergence (whenever it happens) we expose hook for LBaaS to use (or anything else), and if somethings hits this hook, convergence contionus observes marks resource as failed and rebuilds it (however it can) | 14:10 |
| mspreitz | Qiming: inc0: I have been focused on the most expensive one because we have trouble with something that simple | 14:10 |
| inc0 | will that fit your case? | 14:10 |
| mspreitz | inc0: OK, now it is time for me to get back to the conversation with zaneb... | 14:11 |
| mspreitz | zaneb: would you be OK with a service that, for whatever reason, calls the operation on a (stack ID, resource name) that deletes and re-creates that resource? | 14:11 |
| Qiming | mspreitz, imho, LBaaS based failure detection is only one possibility, but I don't like the approach to hardcode it in the resource type implementation | 14:11 |
| mspreitz | Qiming: I agree. That is why I ask for an exposed ability to delete and re-create whenever something else desires it | 14:12 |
| *** shakayumi has quit IRC | 14:12 | |
| *** vijayagurug has left #heat | 14:13 | |
| zaneb | mspreitz: as long as it follows the usual stack update workflow, and just does a no-questions-asked UpdateReplace on the specified resource | 14:13 |
| mspreitz | zaneb: I am not sure I understand your limitations there. Can you elaborate? | 14:14 |
| inc0 | anyway, I got to go, see you all | 14:14 |
| mspreitz | inc0: thanks | 14:15 |
| *** sdake has joined #heat | 14:15 | |
| *** sdake has quit IRC | 14:15 | |
| *** sdake has joined #heat | 14:15 | |
| inc0 | mspreitz, will you be in Paris?> | 14:15 |
| mspreitz | inc0: unfortunately, no. I hope my colleague Bill Arnold will be there | 14:15 |
| *** rpothier has joined #heat | 14:15 | |
| inc0 | I think there is design session for HARestarter in agenda | 14:16 |
| zaneb | mspreitz: just go in and replace one resource isn't enough, you have to respect the entire dependency graph, which means the mechanism needs to be a stack update | 14:16 |
| mspreitz | inc0: I wish I could go, but I have been told I can not | 14:16 |
| mspreitz | zaneb: OK, that makes sense to me. | 14:16 |
| mspreitz | zaneb: in fact, I think we should even respect hierarchy | 14:16 |
| mspreitz | zaneb: i.e., if updating a nested stack, and its outputs change, there is an update being done on the parent stack too | 14:17 |
| *** nkhare_ has joined #heat | 14:17 | |
| mspreitz | zaneb: but the interface is simple - just point and shoot at a single resource | 14:18 |
| mspreitz | (which might be a stack itself) | 14:18 |
| zaneb | mspreitz: yeah, agree, I'm hoping that's something convergence will be able to do for us. I think it's unrealistic for now :/ | 14:18 |
| inc0 | zaneb, because of human resources? | 14:18 |
| *** charlesr has quit IRC | 14:19 | |
| zaneb | no | 14:20 |
| inc0 | whats blocking us then? | 14:20 |
| *** ramishra has joined #heat | 14:20 | |
| gooblja | Hello everybody :) Have question about heat.conf... what parameters have to be set to enable notifications on qpid mq... it seems that by default it dosen't sends notifications... :( | 14:21 |
| *** aweiteka has quit IRC | 14:21 | |
| therve | gondoi, notification_driver=messaging in the configuration file should do it | 14:22 |
| therve | If the rest is configured properly | 14:22 |
| shardy | therve: hey, did you see my question about the oslo liason the other day? | 14:23 |
| mspreitz | zaneb: I think you just said that HARestarter would be fine if it were a service instead of a resource type | 14:23 |
| therve | shardy, No sorry | 14:23 |
| *** alexpilotti has joined #heat | 14:23 | |
| zaneb | mspreitz: I think I did | 14:23 |
| shardy | We were looking for a volunteer last week so I said I'd do it for kilo, wanted to check that was cool with you, e.g that you weren't keen to do it | 14:24 |
| shardy | (you're welcome to if you do :) | 14:24 |
| therve | shardy, Awesome thanks | 14:24 |
| mspreitz | zaneb: and, being a service, there should be a resource type for it, right? | 14:24 |
| zaneb | mspreitz: sure | 14:24 |
| zaneb | in fact, I think that's exactly the problem with HARestarter | 14:24 |
| shardy | therve: Ok, cool, just wanted to check given that you did it for Juno | 14:25 |
| mspreitz | zaneb: so you think we could fix HARestarter without requiring any changes in user templates? | 14:25 |
| zaneb | it's a resource that is a place to hang some code in Heat, instead of a representation of some other thing that has it's own API and UUID | 14:25 |
| therve | shardy, Yeah I hope I did an okay job up until recently :) | 14:25 |
| *** ramishra has quit IRC | 14:25 | |
| zaneb | that's what I've been consistently trying to get rid of since at least Havana | 14:25 |
| *** cody-somerville has joined #heat | 14:26 | |
| shardy | therve: Yes absolutely! I just figured it was about time for me to volunteer for something and you weren't around at the meeting ;) | 14:26 |
| mspreitz | zaneb: OK, I understand better what you have been trying to say | 14:26 |
| *** cody-somerville has quit IRC | 14:26 | |
| *** cody-somerville has joined #heat | 14:26 | |
| *** charlesr has joined #heat | 14:27 | |
| jdandrea | zaneb: let Heat "orchestrate" and let other services "perform," is that the gist? (I've been trying to drive that point home in meetings here as well ... *notes stack-digging resources are evil*) | 14:27 |
| *** Qiming has quit IRC | 14:27 | |
| zaneb | jdandrea: ++ | 14:28 |
| * mspreitz wonders if confusion between objects and operations is the problem here | 14:29 | |
| jdandrea | zaneb: There has been confusion on my end (about orchestrate vs perform). I resorted to an composer/conductor/orchestra metaphor. | 14:29 |
| jdandrea | mspreitz: I think you may be on to something. | 14:29 |
| *** Qiming has joined #heat | 14:29 | |
| zaneb | mspreitz: yep, I think that's part of it too | 14:29 |
| mspreitz | zaneb: let us consider an HARestarter service. What does it do? When I invoke its operation, it does nothing more or less than invoke the Heat operation that we discussed earlier | 14:29 |
| *** alexpilotti has quit IRC | 14:29 | |
| jdandrea | s/to an/to a | 14:30 |
| zaneb | mspreitz: but it does it on a stack that you have passed in a reference to. it follows that the HARestarter resource itself cannot be in the same stack | 14:30 |
| mspreitz | zaneb: ah, right, today's HARestarter offers a subset of the functionality of our hypothetical service | 14:31 |
| mspreitz | zaneb: but I do not see subsetting as evil, just immaturity | 14:32 |
| *** pas-ha has quit IRC | 14:32 | |
| mspreitz | Aha! Here it is... | 14:32 |
| *** kopparam_ has quit IRC | 14:33 | |
| zaneb | today's HARestarter offers a broken version of the functionality of our hypothetical service, while ignoring the central organising principle of Heat, which is the dependency graph | 14:33 |
| mspreitz | If only Ceilometer could let me write a general Heat API invocation as an alarm action, we would all be happy | 14:33 |
| * shardy wonders how we got from health-aware ASG's to an HARestarter *service* | 14:33 | |
| shardy | it's like one of those bad zombie movies | 14:33 |
| mspreitz | shardy: it is because we want to open up to more general detection | 14:33 |
| mspreitz | shardy: so we need an exposed "recover" operation | 14:34 |
| gooblja | therve so i added notification_driver=messaging, but i don't see notification messages... to gather them I use this script http://paste.openstack.org/show/121266/ with this script ia can gather nova notifications if I change exchange to nova but with heat it looks empty | 14:35 |
| *** aweiteka has joined #heat | 14:35 | |
| mspreitz | If we agree that Heat could have a proper delete-and-recreate-this-resource operation, and a Ceilometer alarm or a general thing could invoke it, we would be done, right? | 14:35 |
| *** kopparam has joined #heat | 14:35 | |
| zaneb | shardy: rofl | 14:35 |
| therve | gondoi, I would expect you to subscribe to a notification queue | 14:36 |
| therve | gooblja sorry | 14:36 |
| therve | gooblja, Maybe you configured nova differently? | 14:36 |
| gondoi | :D | 14:36 |
| inc0 | check if there is anything consuming notifications...that might be an issue too | 14:37 |
| mspreitz | inc0: does my outline make sense to you? (Again, focusing for now only on the nost drastic recovery) | 14:37 |
| inc0 | mspreitz, yes, but I think we shouldn't do another service...let's push convergence to that point asap | 14:38 |
| mspreitz | inc0: I did not say anything about another service | 14:38 |
| mspreitz | inc0: oh wait | 14:38 |
| mspreitz | inc0: for detection by LBaaS we do not need another service. We just need a proper delete-and-recreate in the Heat API and Ceilometer to be able to invoke it | 14:39 |
| *** kopparam has quit IRC | 14:39 | |
| mspreitz | inc0: for general detection you need some way to get that "general" part in there, that is where the possibility of another service arises | 14:39 |
| *** nkhare_ has quit IRC | 14:39 | |
| therve | mspreitz, That API could be the signal API, no? | 14:39 |
| therve | Don't know if we want something more dedicated than that | 14:40 |
| shardy | mspreitz: I maintain the quickest way to achieve that is simply to use an autoscaling group (potentially configured with size one), combined with some additional data which allows specification of what unhealthy members should be removed from the group | 14:40 |
| *** kopparam has joined #heat | 14:40 | |
| mspreitz | therve: I think there shoud be a proper Heat API for this. There could also be a signal based way to do it. | 14:40 |
| therve | mspreitz, Well signal is a proper Heat API :) | 14:40 |
| inc0 | shardy, doesn't that be convergence? | 14:41 |
| mspreitz | therve: I am not so sure of that. signal requires synthetic users | 14:41 |
| therve | If it still does it's a bug | 14:41 |
| mspreitz | shardy: so delete-and-recreate becomes workflow {set scaling group size to 0; set scaling group size to 1}, right? | 14:42 |
| shardy | inc0: I'm just saying that rather than overloading every problem around signal driven recovery, we could consider how to do it right now | 14:42 |
| *** jergerber has joined #heat | 14:43 | |
| gooblja | therve yeap http://paste.openstack.org/show/121268/ very interesting for nova there is no notification_driver defined. I also tried to add rpc_backend = qpid but then my dashboard could not get stack_list and no notifications apeared :( | 14:43 |
| zaneb | shardy: I think that's more or less what I suggested on mspreitz's spec review | 14:43 |
| shardy | mspreitz: No, you'd leave the size at 1, but either do a stack update with a hint saying which unhealthing thing gets removed, or that hint is contained (or obtainable via subsequent introspection) in the alarm signal | 14:44 |
| shardy | mspreitz: https://review.openstack.org/#/c/128365/ | 14:44 |
| shardy | that is a first step towards that for ResourceGroup | 14:44 |
| *** cdent has quit IRC | 14:45 | |
| therve | gooblja, What's the version of Heat you're using? | 14:45 |
| shardy | zaneb: Ok, cool, I feel like I've been constantly saying it since this whole HARestarter thing kicked off | 14:45 |
| *** kopparam has quit IRC | 14:45 | |
| gooblja | therve :) how to check it? | 14:45 |
| *** cdent has joined #heat | 14:45 | |
| mspreitz | shardy: update w hint vs signal seem different enough I am going to have to discuss them separately | 14:45 |
| therve | gooblja, Depends on how you installed it | 14:46 |
| shardy | mspreitz: the internal mechanism is the same | 14:46 |
| mspreitz | shardy: my concern is for the user... | 14:46 |
| shardy | autoscaling *is* a stack update, in response to the signal | 14:46 |
| *** jasond has quit IRC | 14:46 | |
| mspreitz | shardy: I want a user to be able to write a template that creates a system that maintains its own health | 14:47 |
| gooblja | therve there was manual installation another man did it :) i don't realy know how :( | 14:47 |
| *** tango has joined #heat | 14:47 | |
| mspreitz | shardy: if there were a way to have a template speak of that "update w hint", and prescribe that it happens when a certain condition is met, that would be an OK outline | 14:47 |
| *** tango|2 has quit IRC | 14:48 | |
| shardy | mspreitz: well that's what I'm proposing, you define an update policy which determines what happens | 14:48 |
| *** funzo_ is now known as funzo | 14:48 | |
| mspreitz | shardy: can you elaborate? On what thing is there an update policy? Does that update policy speak of the reaction or the condition or both? If not both, how is it connected to the other? | 14:49 |
| shardy | mspreitz: If you look in the resource group patch, you'll see there's a "remove_policies" | 14:51 |
| shardy | that is something which could equally be applied to AutoScalinggGroup, either directly via a template update and similar new property, or similar logic triggered via the signal and data gleaned from ceilometer | 14:52 |
| shardy | (both, probably) | 14:52 |
| mspreitz | shardy: OK. How does a user write a template that causes such an update when LBaaS detects ill health? | 14:53 |
| gooblja | therve I found version I have heat 0.2.9 | 14:53 |
| mspreitz | you may s/LBaaS detects ill health/a Ceilometer alarm fires/ | 14:54 |
| therve | gooblja, That's the client version | 14:54 |
| shardy | mspreitz: you need the ill health to trigger a ceilometer alarm, which then enables us to detect (either via the alarm signal payload or by querying ceilometer) | 14:54 |
| shardy | that some thing in the group needs to be added to the blacklist | 14:54 |
| mspreitz | shardy: Ceilometer alarm payload is not controllable by user. | 14:55 |
| mspreitz | shardy: if not in ceilometer alarm payload, what would do the right Ceilometer query? | 14:55 |
| shardy | mspreitz: probably the template author would define a query in the remove_hints map, which would enable heat to query things which match the criteria of ill health | 14:56 |
| mspreitz | shardy: oh, wait, I am off by one level... | 14:57 |
| mspreitz | shardy: we are talking about a general way to maintain the health of one thing... | 14:58 |
| mspreitz | shardy: so there may not be a need for a parameter flowing from Ceilometer to Heat, the thing is implicit | 14:58 |
| *** achanda has joined #heat | 14:59 | |
| mspreitz | shardy: or, maybe I was wrong about the "we" | 14:59 |
| *** randallburt has joined #heat | 14:59 | |
| inc0 | ok, not I really gtg, cya, mspreitz we'll talk later | 15:00 |
| *** randallburt has quit IRC | 15:00 | |
| inc0 | now** | 15:00 |
| *** randallburt has joined #heat | 15:00 | |
| mspreitz | shardy: so I think I could maintain the health of one thing like this: create a ResourceGroup of count=1, resource=(the one thing), remove_policy=[0], and let it have a webhook that does an update; (redefine remove_policy so that it is ignored at create time) | 15:01 |
| mspreitz | (I think that redefintion gives a better definition anyway) | 15:01 |
| gooblja | therve hmmm... can I somehow check heat version via command line.. i have openstack on Centos 7... and i suppose it was instaled by yum install | 15:02 |
| mspreitz | shardy: do you agree? | 15:02 |
| shardy | mspreitz: s/ResourceGroup/AutoScalingGroup | 15:03 |
| mspreitz | why that substitution? | 15:03 |
| mspreitz | shardy: IIRC, in ASG, an "update policy" that specifies a change of 0 takes an early out | 15:04 |
| *** inc0 has quit IRC | 15:05 | |
| mspreitz | shardy: AutoScalingGroup.adjust takes an early out if the change is no change | 15:06 |
| *** thedodd has joined #heat | 15:06 | |
| *** ramishra has joined #heat | 15:07 | |
| skraynev | g'night all | 15:07 |
| mspreitz | skraynev: g'night | 15:07 |
| shardy | mspreitz: ResourceGroup is a static template driven thing, what you want is signal driven group adjustments, which is ASG combined with ScalingPolicy | 15:07 |
| *** achanda has quit IRC | 15:07 | |
| shardy | Maybe the remove_hint becomes a property of ScalingPolicy, which then derives the unhealthy victims and passes the data to the ASG on adjustment | 15:09 |
| mspreitz | shardy: that sound a little better... | 15:11 |
| mspreitz | shardy: actually it is more than enough if I am trying to maintain the health of one thing (i.e., ASG with size fixed at 1) | 15:12 |
| mspreitz | shardy: when the size is fixed at 1, we need no parameter to specify which member to delete | 15:12 |
| mspreitz | shardy: if we go up a level and try to have a scaling group that maintains the health of all its members, we still have trouble identifying the member | 15:13 |
| mspreitz | shardy: so, are you talking about how to maintain the health of one thing, or of all the members of a scaling group? | 15:13 |
| mspreitz | (of general size) | 15:14 |
| shardy | mspreitz: I'm saying they can be the same | 15:14 |
| mspreitz | shardy: so I will continue on the general size discussion... | 15:14 |
| mspreitz | shardy: since a Ceilometer alarm is a concrete thing, not a pattern, there has to be an alarm per member of the scaling group, right? | 15:15 |
| *** alexpilotti has joined #heat | 15:15 | |
| *** rushiagr_away is now known as rushiagr | 15:16 | |
| *** robklg has quit IRC | 15:16 | |
| shardy | mspreitz: I have to go to a meeting now, but no, IMO you'd have one alarm | 15:16 |
| mspreitz | shardy: then I am really puzzled. Can you send or post a complete outline when you get a chance? | 15:17 |
| shardy | mspreitz: sure, I will try to do that | 15:18 |
| mspreitz | shardy: Thaniks! | 15:18 |
| mspreitz | Thanks | 15:18 |
| therve | mspreitz, You can make a query after the alarm to know the specifics | 15:18 |
| therve | IIUC | 15:18 |
| shardy | therve: +1 | 15:18 |
| mspreitz | therve: "I" can not act; the user has to write a template | 15:18 |
| therve | mspreitz, Right, that's what Steven said, you would specify that query | 15:19 |
| mspreitz | the user has to write a template that causes some particular thing to take action at the right time | 15:19 |
| mspreitz | therve: what agent can a template author cause to issue the right query? | 15:19 |
| therve | Sorry I don't understand | 15:20 |
| mspreitz | where in the template does the query appear? | 15:20 |
| jdandrea | Is there a link to the list of environment variables I can get at during cloud-init (e.g., the resource ID for the server being instantiated)? | 15:20 |
| therve | In the resource that get signaled by the alarm | 15:21 |
| *** aweiteka has quit IRC | 15:21 | |
| mspreitz | therve: Since Ceilometer does not allow user control over the HTTP request body in an alarm action, there has to be a distinct alarm per thing-whose-health-is-being-maintained, right? | 15:22 |
| mspreitz | therve: or are you proposing one query about the health of all the members of the group? | 15:23 |
| therve | mspreitz, Not if you query ceilometer after the alarm to get the proper information | 15:23 |
| therve | But we're going in circle here | 15:23 |
| mspreitz | therve: I maybe just realized why we are going in a circle | 15:24 |
| Qiming | jdandrea, /var/lib/cloud/data/instance-id ? | 15:24 |
| therve | No I mean we don't manage to understand each other :) | 15:24 |
| jdandrea | Qiming: thank you! | 15:24 |
| mspreitz | therve: you are proposing that when a signal is received, the receiver queries about the health of all the members of the group; is that it? | 15:24 |
| mspreitz | therve: yes, I understood what you meant by circle | 15:24 |
| therve | mspreitz, Well not the health of all the members, but the id of the members with bad health | 15:25 |
| mspreitz | therve: we may have misunderstood each other because I was not even thinking of the possibility you are trying to suggest | 15:25 |
| mspreitz | therve: I need a clarification in your answer.... | 15:26 |
| mspreitz | therve: this query you are speaking of, does the query (not its result) identify the mebers with bad health, or is it a query like "return me the list of members with bad health" ? | 15:26 |
| *** nosnos has quit IRC | 15:27 | |
| therve | mspreitz, The latter | 15:27 |
| mspreitz | therve: Ah, that is why I did not understand you. | 15:27 |
| *** ramishra has quit IRC | 15:27 | |
| mspreitz | therve: the cost of answering that query grows in proportion to the list of the group, right? | 15:28 |
| mspreitz | s/list/size | 15:28 |
| mspreitz | therve: the cost of answering that query grows in proportion to the size of the group, right? | 15:28 |
| therve | mspreitz, Hopefully not. | 15:28 |
| mspreitz | therve: how could it not? Oh wait, I just realized something else. This query is not an operation in today's Ceilometer API, right? | 15:29 |
| therve | I think it is | 15:29 |
| mspreitz | therve: can you outline how the signal handler could use today's Ceilometer API to make the query you have in mind? | 15:30 |
| Qiming | g'night | 15:30 |
| mspreitz | Qiming: g'night | 15:30 |
| therve | mspreitz, No | 15:30 |
| *** kebray has joined #heat | 15:31 | |
| *** kebray has quit IRC | 15:31 | |
| *** fayablazer has quit IRC | 15:32 | |
| mspreitz | therve: I can not see how the Ceilometer query API could be used to do such a query | 15:33 |
| therve | Maybe it's not possible then | 15:33 |
| mspreitz | therve: I think it is impossible. So that is why I conclude there has to be an alarm per group member. | 15:34 |
| mspreitz | that is among the reasons | 15:34 |
| *** aweiteka has joined #heat | 15:34 | |
| *** Qiming has quit IRC | 15:35 | |
| mspreitz | the other is that there is no way for a ceilometer client to make any part of the HTTP request in an alarm action variable; it alarm action has to be a literal. And it can not have a user-specified request body nor headers | 15:35 |
| mspreitz | therve: how could a ceilomter client specify an alarm action that identifies the right group member for a given alarm? | 15:36 |
| mspreitz | therve: by index is bad, the index of a member changes over the lifetime of a group | 15:37 |
| mspreitz | therve: the resource name or ID of the member would work | 15:37 |
| mspreitz | ... if that name or ID were something that the user could write at the relevant position in a template | 15:37 |
| *** inc0 has joined #heat | 15:38 | |
| mspreitz | therve: but I do not see how a user can write the "resource" property of an OS::Heat::AutoScalingGroup to make it create an alarm with an action that contains the name or ID of the group member | 15:39 |
| *** serg_melikyan has joined #heat | 15:40 | |
| inc0 | hehe you're still discussing?;) | 15:40 |
| mspreitz | inc0: yes | 15:40 |
| mspreitz | therve: I take that back, there is one thing I can think of... | 15:40 |
| mspreitz | therve: the member has to be a stack, and the template that specifies that stack can include a reference to the stack's ID | 15:41 |
| mspreitz | therve: however, the stack's ID is not the same as the ID of the Resource that is the group member | 15:41 |
| mspreitz | therve: so there is still a gap | 15:41 |
| mspreitz | therve: in a future with convergence, it would suffice to delete the stack | 15:42 |
| mspreitz | --- the stack that backs the group member | 15:42 |
| mspreitz | therve: but not today | 15:42 |
| mspreitz | therve: so I do not see a way today to use shardy's remove_policies on a group with more than one member | 15:45 |
| *** packet has joined #heat | 15:46 | |
| mspreitz | therve: are you still there? | 15:47 |
| *** JayJ has joined #heat | 15:47 | |
| therve | mspreitz, ceilometer resource-list should be able to return the member with bad health | 15:48 |
| *** viktors is now known as viktors|afk | 15:51 | |
| *** andrearosa has quit IRC | 15:52 | |
| *** otoolee has quit IRC | 15:53 | |
| mspreitz | therve: you mean like this: `ceilometer resource-list -q "counter_name=network.services.lb.member"` ? | 15:53 |
| therve | Well with the counter value | 15:56 |
| therve | Sorry got to go | 15:56 |
| * jdandrea is still stuck trying to figure out if there's an environment variable specifying the resource ID during cloud-id. | 15:57 | |
| *** sabeen2 has joined #heat | 15:57 | |
| * jdandrea ... and is going to brute force it (for now). | 15:58 | |
| mspreitz | jdandrea: you know about GETting http://169.245.169.254/ from inside the VM, right? | 15:58 |
| jdandrea | mspreitz: I do, but I don't use it. Perhaps I should. :) | 15:58 |
| jdandrea | "The magic IP." | 15:58 |
| *** sabeen1 has quit IRC | 15:59 | |
| mspreitz | jdandrea: try it. It returns an index to the head of a branch of magic files | 15:59 |
| * jdandrea waves a wand | 15:59 | |
| jdandrea | Ok. | 15:59 |
| mspreitz | jdandrea: but rember that what you find is specific to the VM from which you are exploring | 15:59 |
| mspreitz | jdandrea: and it only works in VMs for which that is the relevant mechanism; for others it is a special mounted filesystem | 15:59 |
| jdandrea | mspreitz: That's what I want. I think that, for SoftwareConfig cases, there *are* env vars. Just not sure if that's true for standard issue cloud-init. | 16:00 |
| mspreitz | jdandra: at various times in the past I have found documentation for cloud-init... | 16:00 |
| *** tspatzier has quit IRC | 16:00 | |
| mspreitz | jdandrea: but I think that, in practice, what you actually get is somewhat vedor specific | 16:01 |
| mspreitz | jandra: and I do not remember what, if anything, that doc said about envars | 16:01 |
| mspreitz | right now I am hunting doc on Ceilometer query syntax. Trying to figure out how to compare with number 0 instead of string 0 | 16:02 |
| jdandrea | mspreitz: Hmm, good question. | 16:02 |
| jdandrea | type='string? http://docs.openstack.org/developer/ceilometer/webapi/v2.html#Query | 16:03 |
| jdandrea | (maybe that's the default, and it can be changed to int) | 16:04 |
| *** andrearosa has joined #heat | 16:04 | |
| shardy | jdandrea: I think http://169.254.169.254/latest/meta-data/instance-id gives you what you want | 16:04 |
| mspreitz | jdandrea: I mean in the CLI, not the API | 16:04 |
| shardy | heat doesn't pass the resource_id in the cloud-init data so I don't think there's any magic variable you can reference | 16:05 |
| *** aweiteka has quit IRC | 16:05 | |
| jdandrea | shardy: *nods* ... I was grabbing that from /var/lib/cloud/data/instance-id previously. | 16:05 |
| jdandrea | shardy: oic, and I suspect I can't pass that resource id in either (picture a cat chasing its tail). | 16:05 |
| shardy | jdandrea: Ah, so cloud-init does get that data then | 16:05 |
| jdandrea | shardy: *nods* I wasn't sure if there was some *other* set of data though, with the resource id. | 16:06 |
| mspreitz | shardy: does Heat pass its resource ID for a Compute instance to Nova at all? | 16:06 |
| shardy | jdandrea: yeah, exactly | 16:06 |
| shardy | mspreitz: no, it can't | 16:06 |
| mspreitz | shardy: why can't it? | 16:06 |
| shardy | the resource_id comes from nova | 16:06 |
| mspreitz | shardy: I thought Heat has its own ID for each Resource | 16:07 |
| jdandrea | shardy: I ask because I'm creating a ceilometer sample from the VM (a heartbeat of sorts), and one of the fields required by a sample is "resource_id. | 16:07 |
| shardy | mspreitz: no, the ID comes from each underlying service in nearly all cases | 16:07 |
| jdandrea | shardy: Maybe it can be anything. I just imagine it should be somewhat unique (apart from the metadata with the stack ID, which I *can* pass in). | 16:08 |
| jdandrea | shardy: So until that underlying service gives Heat an ID, you can't possibly know what it will be. | 16:08 |
| jdandrea | Makes sense. | 16:08 |
| *** spzala has joined #heat | 16:09 | |
| openstackgerrit | Steven Hardy proposed a change to openstack/heat: Remove oslo request_id module https://review.openstack.org/128268 | 16:10 |
| openstackgerrit | Steven Hardy proposed a change to openstack/heat: Remove oslo middleware.base module https://review.openstack.org/128269 | 16:10 |
| openstackgerrit | Steven Hardy proposed a change to openstack/heat: Remove oslo sslutils https://review.openstack.org/128270 | 16:10 |
| jdandrea | shardy: I wonder if I can pass in the resource name/path though? *thinking aloud here* | 16:10 |
| jdandrea | Ehhh, maybe not the path. | 16:11 |
| jdandrea | nm | 16:11 |
| *** __TheDodd__ has joined #heat | 16:11 | |
| *** thedodd has quit IRC | 16:12 | |
| *** jistr has quit IRC | 16:14 | |
| *** otoolee has joined #heat | 16:15 | |
| *** aweiteka has joined #heat | 16:18 | |
| *** bdossant has quit IRC | 16:27 | |
| *** pasquier-s has quit IRC | 16:31 | |
| *** inc0 has quit IRC | 16:33 | |
| *** tomek_adamczewsk has quit IRC | 16:35 | |
| *** kebray has joined #heat | 16:37 | |
| jdandrea | In a ResourceGroup, IIUC, resource names are appended wth numbers in sequence (server-1, server-2, etc.) so that the names are unique. Is there a way for me to use that number elsewhere within that resource's properties? (Trying to create a scheduler hint unique to that particular resource.) | 16:44 |
| shardy | jdandrea: maybe you could scale out nested stacks and reference the OS::stack_name intrinsic function in the hint? | 16:49 |
| jdandrea | shardy: Welllll ... that's certainly one way to do it. Not preferable, but yeah. | 16:50 |
| * jdandrea is hung up on things being neat and tidy, imagines stacks lying around like pizza boxes after a party. :-P | 16:51 | |
| jdandrea | It works in a pinch, mhm. | 16:51 |
| *** derekh has quit IRC | 16:52 | |
| *** alexheneveld has joined #heat | 16:56 | |
| zaneb | jdandrea: doesn't the %index% replacement (in Juno) work for that? | 17:01 |
| jdandrea | zaneb: *That's* what it was! (I think.) I was trying to locate it in the docs. | 17:01 |
| jdandrea | zaneb: So if I use %index% in one of my properties, I can get at that value for a given resource instantiaion (crossing fingers). | 17:02 |
| zaneb | I think that's how it works | 17:02 |
| jdandrea | zaneb: tyvm :) | 17:03 |
| * jdandrea is giving it a try | 17:03 | |
| *** julienvey has quit IRC | 17:09 | |
| *** julienvey has joined #heat | 17:10 | |
| mspreitz | zaneb: oh, that %index% thing would be handy. Is it documented anywhere? | 17:10 |
| zaneb | afaik | 17:11 |
| *** jstrachan has quit IRC | 17:12 | |
| mspreitz | zaneb: jdandrea: found doc at http://docs.openstack.org/developer/heat/template_guide/openstack.html#OS::Heat::ResourceGroup | 17:13 |
| mspreitz | right where I would look first! | 17:13 |
| *** jprovazn has joined #heat | 17:14 | |
| *** julienvey has quit IRC | 17:14 | |
| *** aweiteka has quit IRC | 17:14 | |
| *** harlowja_away is now known as harlowja | 17:15 | |
| jdandrea | mspreitz: I *was* looking at that. Chalk it up to developer myopia. *head/desk* | 17:16 |
| jdandrea | Staring me in the face. ty | 17:17 |
| *** vijayaguru has joined #heat | 17:17 | |
| mspreitz | jdandrea: BTW, this solves a problem were talking about earlier - how can a template author write a resource_def (a ResourceGroup property) that refers to the particular member when instantiated | 17:18 |
| *** randallburt has quit IRC | 17:18 | |
| jdandrea | mspreitz: Indeed. | 17:18 |
| zaneb | I don't know why it says there that it only works in the name. it's definitely applied to all properties. if somebody wants to submit a patch... | 17:18 |
| *** vijendar has joined #heat | 17:18 | |
| jdandrea | " Can be used, *for example*, to customize the name ..." - that's ok, no? | 17:19 |
| *** tango has quit IRC | 17:23 | |
| *** amakarov is now known as amakarov_away | 17:23 | |
| *** rushiagr is now known as rushiagr_away | 17:25 | |
| *** aweiteka has joined #heat | 17:26 | |
| jdandrea | $1M question coming up here: Does %index% (and INDEX_VAR and _handle_repl_val()) work for properties of any scaling resource? *checks the code* D'oh! Nope. Hmm. Maybe if I scale a resource group of size 1 ... ;) | 17:27 |
| jdandrea | (Oh, the index_var would have to be per plugin anyway. Understandable.) | 17:27 |
| mspreitz | jdandrea: right. That's why I am surprised shardy is talking about dealing directly with a group of general size | 17:28 |
| mspreitz | If the group size is fixed at 1, you don't need no stinkin' variable to tell you what the index is! | 17:28 |
| mspreitz | jdandera: well, actually, there are lots of reasons I am surprised | 17:29 |
| *** andersonvom has joined #heat | 17:29 | |
| jdandrea | mspreitz: I want to understand and appreciate all the angles around that, for certain. I'll get there. :) | 17:30 |
| shardy | http://blog.russellbryant.net/2014/10/15/openstack-instance-ha-proposal/ | 17:30 |
| shardy | Oh inc0 has gone | 17:30 |
| jdandrea | shardy: Ooh, ty | 17:30 |
| * jdandrea goes off to read again | 17:30 | |
| shardy | interesting reading for those wanting automated evacuate | 17:31 |
| *** vijendar has quit IRC | 17:31 | |
| *** Drago has quit IRC | 17:31 | |
| *** vijendar has joined #heat | 17:31 | |
| openstackgerrit | Steven Hardy proposed a change to openstack/heat: ResourceGroup update refactor https://review.openstack.org/128364 | 17:38 |
| openstackgerrit | Steven Hardy proposed a change to openstack/heat: ResourceGroup add "force_remove" property https://review.openstack.org/128365 | 17:38 |
| openstackgerrit | Steven Hardy proposed a change to openstack/heat: ResourceGroup add remove_policies property https://review.openstack.org/128365 | 17:40 |
| openstackgerrit | Vijayaguru Guruchave proposed a change to openstack/python-heatclient: Pass auth_url if os_no_client_auth specified https://review.openstack.org/127987 | 17:41 |
| mspreitz | shardy: thanks for the pointer. Now I wonder how it is related to our earlier discussion of health maintenace that is not limited to infrastructure (i.e., hypervisor) failure. | 17:47 |
| *** achanda has joined #heat | 17:49 | |
| *** tspatzier has joined #heat | 17:51 | |
| *** Drago has joined #heat | 17:52 | |
| mspreitz | jdandrea: shardy: BTW, if you have the scrollback in #openstack-ceilometer, you see that ceilometer query abilities are surprisingly limited | 17:53 |
| mspreitz | at least for `ceilometer resource-list` | 17:53 |
| jdandrea | I can see it, yep. Will read, tx. | 17:53 |
| mspreitz | `ceilometer sample-list` is, hopefully, another story | 17:54 |
| *** randallburt has joined #heat | 17:56 | |
| *** Drago1 has joined #heat | 17:58 | |
| *** tspatzier has quit IRC | 17:58 | |
| mspreitz | shardy: does your blog post about automated evacuate have implications for the sort of health maintenance I have been discussing? | 17:59 |
| *** tango has joined #heat | 18:01 | |
| *** jamiehannaford has quit IRC | 18:01 | |
| *** vijendar has quit IRC | 18:03 | |
| *** spzala has quit IRC | 18:04 | |
| *** kopparam has joined #heat | 18:05 | |
| mspreitz | shardy: sorry, s/your/Russell's/ | 18:05 |
| *** charlesr has quit IRC | 18:06 | |
| *** __TheDodd__ has quit IRC | 18:07 | |
| *** thedodd has joined #heat | 18:09 | |
| *** vijayaguru has left #heat | 18:09 | |
| *** Drago1 has quit IRC | 18:11 | |
| *** Drago1 has joined #heat | 18:12 | |
| openstackgerrit | Zane Bitter proposed a change to openstack/heat: Unit tests: remove dead code from Neutron Autoscaling test https://review.openstack.org/128728 | 18:15 |
| openstackgerrit | Zane Bitter proposed a change to openstack/heat: Ensure all Neutron LoadBalancer members are deleted https://review.openstack.org/128729 | 18:15 |
| *** achanda has quit IRC | 18:16 | |
| shardy | mspreitz: possibly, it's certainly related to the use-case I've been discussing with inc0 | 18:17 |
| shardy | it only really solves the case where you want to restart a VM because a nova host went down though | 18:18 |
| shardy | so not the general purpose solution you seem to be seeking | 18:18 |
| *** jergerber has quit IRC | 18:18 | |
| mspreitz | shardy: right. I want different detection, different fencing, different recovery | 18:19 |
| *** mkollaro has quit IRC | 18:20 | |
| *** achanda has joined #heat | 18:20 | |
| *** charlesr has joined #heat | 18:21 | |
| *** thedodd has quit IRC | 18:23 | |
| mspreitz | shardy: your remarks earlier in this chat today are about different fencing and recovery than Russell's blog post | 18:29 |
| *** tomek_adamczewsk has joined #heat | 18:30 | |
| *** nikunj2512 has quit IRC | 18:31 | |
| *** spzala has joined #heat | 18:32 | |
| *** otoolee has quit IRC | 18:41 | |
| *** mspreitz has quit IRC | 18:42 | |
| *** thedodd has joined #heat | 18:47 | |
| *** spzala has quit IRC | 18:50 | |
| *** Drago1 has quit IRC | 18:50 | |
| *** tomek_adamczewsk has quit IRC | 18:53 | |
| *** kbyrne has quit IRC | 18:53 | |
| *** tomek_adamczewsk has joined #heat | 18:53 | |
| *** achampio1 has joined #heat | 18:55 | |
| *** packet has quit IRC | 18:55 | |
| *** cody-somerville has quit IRC | 18:55 | |
| *** jpeeler has quit IRC | 18:56 | |
| *** dteselkin has quit IRC | 18:56 | |
| *** packet has joined #heat | 18:57 | |
| *** gilliard has quit IRC | 18:57 | |
| *** kopparam has quit IRC | 18:57 | |
| *** achampion has quit IRC | 18:57 | |
| *** skraynev has quit IRC | 18:57 | |
| *** gilliard has joined #heat | 18:58 | |
| *** charlesr has quit IRC | 18:59 | |
| *** mspreitz has joined #heat | 19:01 | |
| *** vijendar has joined #heat | 19:02 | |
| *** kopparam has joined #heat | 19:02 | |
| *** Drago1 has joined #heat | 19:02 | |
| mspreitz | shardy: Sorry, I was not multi-tasking enough, I just noticed and read your comment on https://review.openstack.org/#/c/124656/ | 19:02 |
| *** tomek_ad1 has joined #heat | 19:02 | |
| *** tomek_adamczewsk has quit IRC | 19:03 | |
| mspreitz | I made the comments about HARestarter because (a) it is the primary motivation, (b) that motivation lends a sense of urgency, and (c) as an urgent diversion from a train-wreck there is less need to do something hugely general (which is a direction some reviewers wanted to go) | 19:04 |
| mspreitz | shardy: I will admit a second motivation, which is I think what is now proposed is much nicer to users than asking them to code up a bunch of mechanism afresh each time they want health maintenance | 19:05 |
| *** tomek_adamczewsk has joined #heat | 19:05 | |
| mspreitz | shardy: are you saying you would prefer to review primarily on the basis of that second motivation? | 19:05 |
| *** dteselkin has joined #heat | 19:05 | |
| *** kbyrne has joined #heat | 19:06 | |
| *** Drago1 has quit IRC | 19:07 | |
| *** tomek_ad1 has quit IRC | 19:07 | |
| *** achanda has quit IRC | 19:07 | |
| *** Drago1 has joined #heat | 19:08 | |
| *** randallburt has quit IRC | 19:08 | |
| *** jpeeler has joined #heat | 19:09 | |
| *** skraynev has joined #heat | 19:11 | |
| *** charlesr has joined #heat | 19:12 | |
| *** adrienverge has joined #heat | 19:12 | |
| *** kopparam has quit IRC | 19:14 | |
| adrienverge | Hi all | 19:16 |
| adrienverge | The cinder scheduler hints patch would appreciate reviews :) | 19:16 |
| adrienverge | https://review.openstack.org/#/c/126298/ | 19:16 |
| *** kebray has quit IRC | 19:20 | |
| *** achanda has joined #heat | 19:25 | |
| *** otoolee has joined #heat | 19:28 | |
| *** Drago1 has quit IRC | 19:28 | |
| *** cdent has quit IRC | 19:28 | |
| *** Drago1 has joined #heat | 19:28 | |
| *** Drago1 has quit IRC | 19:29 | |
| *** EricGonczer_ has quit IRC | 19:29 | |
| *** adrienverge has quit IRC | 19:31 | |
| *** Drago1 has joined #heat | 19:31 | |
| *** Drago1 has quit IRC | 19:35 | |
| *** Drago1 has joined #heat | 19:35 | |
| *** cdent has joined #heat | 19:48 | |
| *** EricGonczer_ has joined #heat | 19:49 | |
| *** kebray has joined #heat | 19:49 | |
| *** EricGonczer_ has quit IRC | 19:51 | |
| *** Drago1 has quit IRC | 19:52 | |
| *** cdent has quit IRC | 19:53 | |
| *** Drago1 has joined #heat | 19:53 | |
| *** charlesr has quit IRC | 19:55 | |
| *** ifarkas has quit IRC | 19:57 | |
| *** tonisbones has quit IRC | 19:58 | |
| *** vijendar has quit IRC | 19:59 | |
| *** vijendar has joined #heat | 20:06 | |
| *** EricGonczer_ has joined #heat | 20:12 | |
| *** jprovazn has quit IRC | 20:19 | |
| *** spzala has joined #heat | 20:21 | |
| *** vijendar has quit IRC | 20:25 | |
| *** vijendar has joined #heat | 20:25 | |
| *** EricGonczer_ has quit IRC | 20:30 | |
| *** achanda has quit IRC | 20:31 | |
| *** otoolee has quit IRC | 20:31 | |
| *** crose has joined #heat | 20:33 | |
| *** dteselkin has quit IRC | 20:36 | |
| openstackgerrit | Mike Spreitzer proposed a change to openstack/heat-specs: Adding Optional Health to OS::Heat::AutoScalingGroup https://review.openstack.org/124656 | 20:37 |
| *** EricGonczer_ has joined #heat | 20:38 | |
| *** dteselkin has joined #heat | 20:38 | |
| *** otoolee has joined #heat | 20:47 | |
| *** Drago1 has quit IRC | 20:48 | |
| *** sarob has joined #heat | 20:49 | |
| *** achanda has joined #heat | 20:49 | |
| *** EricGonczer_ has quit IRC | 20:49 | |
| *** Drago has quit IRC | 20:52 | |
| *** jdob has quit IRC | 20:55 | |
| *** julienvey has joined #heat | 21:03 | |
| *** fayablazer has joined #heat | 21:05 | |
| *** swygue has quit IRC | 21:07 | |
| *** dims_ has quit IRC | 21:14 | |
| *** dims_ has joined #heat | 21:15 | |
| *** rpothier has quit IRC | 21:20 | |
| *** JayJ has quit IRC | 21:20 | |
| *** JayJ has joined #heat | 21:20 | |
| *** andersonvom has quit IRC | 21:21 | |
| *** mspreitz has quit IRC | 21:23 | |
| *** arunrajan has joined #heat | 21:23 | |
| arunrajan | brint: Saw your response to https://jira.rax.io/browse/HEAT-761 We were in a team meeting and looking for that one but couldn't find it. Do you happen to have that Jira number handy? | 21:24 |
| *** radez is now known as radez_g0n3 | 21:25 | |
| stevebaker | morning | 21:27 |
| *** __TheDodd__ has joined #heat | 21:28 | |
| *** thedodd has quit IRC | 21:29 | |
| shardy | stevebaker: hey, it's getting late so it's probably just me, but if you can spell out what you want for remove_policies that would be awesome & I'll revisit it in the morning | 21:30 |
| shardy | I thought I'd addressed your comments but evidently Im missing some context from the plugpoint thing | 21:31 |
| stevebaker | shardy: I did in the initial comment, just a list of maps instead of a top-level map | 21:31 |
| stevebaker | shardy: dialing in? | 21:32 |
| shardy | stevebaker: Ok cool, maybe I misinterpreted, somewhat sleep-deprived atm ;) | 21:32 |
| stevebaker | shardy: I can't imagine why | 21:33 |
| *** EricGonczer_ has joined #heat | 21:35 | |
| *** jmckind has quit IRC | 21:37 | |
| *** blomquisg has quit IRC | 21:39 | |
| *** miguelgrinberg has quit IRC | 21:39 | |
| *** aweiteka has quit IRC | 21:40 | |
| *** fayablazer has quit IRC | 21:41 | |
| *** gondoi is now known as zz_gondoi | 21:41 | |
| *** tomek_adamczewsk has quit IRC | 21:41 | |
| *** tomek_adamczewsk has joined #heat | 21:42 | |
| *** EricGonczer_ has quit IRC | 21:45 | |
| *** arunrajan has left #heat | 21:45 | |
| *** miguelgrinberg_ has joined #heat | 21:46 | |
| *** crose has quit IRC | 21:48 | |
| *** JayJ has quit IRC | 21:48 | |
| *** alexheneveld has quit IRC | 21:54 | |
| *** kebray has quit IRC | 21:57 | |
| *** packet has quit IRC | 21:58 | |
| *** miguelgrinberg_ has quit IRC | 22:00 | |
| *** sabeen1 has joined #heat | 22:01 | |
| *** julienvey has quit IRC | 22:01 | |
| *** julienvey has joined #heat | 22:02 | |
| *** sabeen2 has quit IRC | 22:04 | |
| *** alexheneveld has joined #heat | 22:05 | |
| *** andersonvom has joined #heat | 22:06 | |
| *** miguelgrinberg_ has joined #heat | 22:06 | |
| *** julienvey has quit IRC | 22:07 | |
| *** sarob has quit IRC | 22:08 | |
| *** andersonvom has quit IRC | 22:10 | |
| *** asalkeld has joined #heat | 22:12 | |
| asalkeld | morning | 22:12 |
| *** jcoufal has quit IRC | 22:13 | |
| *** miguelgrinberg_ has quit IRC | 22:13 | |
| *** miguelgrinberg_ has joined #heat | 22:26 | |
| *** Drago has joined #heat | 22:29 | |
| *** miguelgrinberg_ has quit IRC | 22:30 | |
| *** julienvey has joined #heat | 22:32 | |
| *** vdreamarkitex has joined #heat | 22:32 | |
| *** alexpilotti has quit IRC | 22:32 | |
| *** __TheDodd__ has quit IRC | 22:33 | |
| *** julienvey has quit IRC | 22:36 | |
| *** achanda has quit IRC | 22:40 | |
| *** achanda has joined #heat | 22:44 | |
| *** sarob has joined #heat | 22:53 | |
| *** asalkeld has quit IRC | 22:56 | |
| *** Drago has quit IRC | 23:06 | |
| *** cody-somerville has joined #heat | 23:07 | |
| *** asalkeld has joined #heat | 23:13 | |
| *** cody-somerville has quit IRC | 23:18 | |
| *** sarob has quit IRC | 23:21 | |
| *** sarob has joined #heat | 23:22 | |
| *** sarob has quit IRC | 23:22 | |
| *** sarob has joined #heat | 23:23 | |
| *** che-arne has quit IRC | 23:23 | |
| *** sarob has quit IRC | 23:23 | |
| *** sarob has joined #heat | 23:24 | |
| *** sarob has quit IRC | 23:24 | |
| *** sarob has joined #heat | 23:24 | |
| *** che-arne has joined #heat | 23:24 | |
| *** sarob has quit IRC | 23:25 | |
| *** sarob has joined #heat | 23:25 | |
| *** sarob has quit IRC | 23:26 | |
| *** cody-somerville has joined #heat | 23:26 | |
| *** andersonvom has joined #heat | 23:31 | |
| openstackgerrit | OpenStack Proposal Bot proposed a change to openstack/heat: Updated from global requirements https://review.openstack.org/128038 | 23:41 |
| *** aweiteka has joined #heat | 23:47 | |
| *** lifeless has quit IRC | 23:52 | |
| *** lifeless has joined #heat | 23:53 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!