| *** dsneddon has joined #heat | 00:03 | |
| *** sdake has quit IRC | 00:07 | |
| *** dims has joined #heat | 00:12 | |
| *** steveg_afk has joined #heat | 00:16 | |
| *** blomquisg has joined #heat | 00:18 | |
| *** boris-42 has joined #heat | 00:30 | |
| *** steveg_afk has quit IRC | 00:32 | |
| *** pm90_ has quit IRC | 00:44 | |
| *** sthillma has quit IRC | 00:53 | |
| *** randallburt has quit IRC | 01:09 | |
| *** Drago has joined #heat | 01:11 | |
| openstackgerrit | Angus Salkeld proposed openstack/heat: Convergence: Correct the class name EngineListener https://review.openstack.org/196531 | 01:12 |
|---|---|---|
| *** Drago has quit IRC | 01:13 | |
| *** Drago has joined #heat | 01:13 | |
| openstackgerrit | Angus Salkeld proposed openstack/heat: Convergence: Fix stack status_reason https://review.openstack.org/196533 | 01:16 |
| *** Qiming has joined #heat | 01:29 | |
| *** Qiming_ has joined #heat | 01:30 | |
| *** Qiming has quit IRC | 01:34 | |
| openstackgerrit | Rico Lin proposed openstack/heat: support list resources with details https://review.openstack.org/196571 | 01:35 |
| *** Qiming_ is now known as Qiming | 01:35 | |
| *** tobe has joined #heat | 01:38 | |
| *** LiJiansheng has joined #heat | 01:39 | |
| *** tobe has quit IRC | 01:39 | |
| *** Marga_ has joined #heat | 01:45 | |
| *** steveg_afk has joined #heat | 01:48 | |
| *** Marga_ has quit IRC | 01:48 | |
| *** Marga_ has joined #heat | 01:49 | |
| *** erkules has quit IRC | 01:52 | |
| *** erkules_ has joined #heat | 01:52 | |
| *** elynn has joined #heat | 01:58 | |
| *** Yanyanhu has joined #heat | 01:59 | |
| *** EricGonczer_ has joined #heat | 01:59 | |
| *** Slower has quit IRC | 01:59 | |
| *** elynn has quit IRC | 02:06 | |
| *** elynn has joined #heat | 02:08 | |
| *** chlong_ has joined #heat | 02:08 | |
| *** chlong__ has joined #heat | 02:10 | |
| elynn | morning all :) | 02:10 |
| *** chlong_ has quit IRC | 02:13 | |
| *** ananta_ has joined #heat | 02:14 | |
| ananta_ | good morning | 02:15 |
| *** tobe has joined #heat | 02:16 | |
| asalkeld | o/ | 02:21 |
| *** ananta_ has quit IRC | 02:26 | |
| openstackgerrit | Rico Lin proposed openstack/heat: support list resources with details https://review.openstack.org/196571 | 02:27 |
| *** EricGonczer_ has quit IRC | 02:27 | |
| *** chlong_ has joined #heat | 02:28 | |
| openstackgerrit | Rico Lin proposed openstack/heat: support list resources with details https://review.openstack.org/196571 | 02:30 |
| *** steveg_afk has quit IRC | 02:30 | |
| *** chlong__ has quit IRC | 02:31 | |
| *** chlong has joined #heat | 02:31 | |
| *** chlong_ has quit IRC | 02:34 | |
| *** mwheckmann has joined #heat | 02:37 | |
| *** elynn_ has joined #heat | 02:37 | |
| *** elynn has quit IRC | 02:37 | |
| *** mwheckmann has quit IRC | 02:46 | |
| *** fbo_ has quit IRC | 02:48 | |
| openstackgerrit | Merged openstack/heat: Fix config generator for oslo.service https://review.openstack.org/196367 | 02:48 |
| *** ananta_ has joined #heat | 02:50 | |
| *** kebray has joined #heat | 02:51 | |
| ananta_ | asalkeld: there are few patches required for convergence rollback to work properly | 02:51 |
| *** fbo has joined #heat | 02:51 | |
| asalkeld | ok | 02:51 |
| asalkeld | which reviews? | 02:51 |
| ananta_ | https://review.openstack.org/#/c/196619/ and https://review.openstack.org/#/c/196536/ | 02:52 |
| asalkeld | ananta_: i think i am heading to the conclusion that the convergence-unit-test-framework thing is starting to be a very high priority | 02:52 |
| asalkeld | it's just not easy to test otherwise | 02:53 |
| ananta_ | asalkeld: yes and Ishant Tyagi have started on it :) | 02:54 |
| asalkeld | ananta_: i don't see any logical change here https://review.openstack.org/#/c/196619/1/heat/engine/stack.py | 02:54 |
| asalkeld | (is it just the test cases?) | 02:54 |
| ananta_ | asalkeld: no, the break in the elif is removed...and it is very important | 02:55 |
| ananta_ | the search still needs to continue to see if there is any resoruce with current template ID, it shouldn't stop there | 02:55 |
| asalkeld | ok, spotted that change now | 02:56 |
| *** yuanying has quit IRC | 02:56 | |
| ananta_ | asalkeld: difficult to spot the change as it got moved out...in line comparison would have helped | 02:57 |
| ananta_ | asalkeld: may be i should put a comment there :) | 02:57 |
| ananta_ | asalkeld: before https://review.openstack.org/#/c/196536/, the args supplied to heat were not passed to updated stack... and update-rollback was failing | 02:59 |
| ananta_ | sirushti: o/ | 03:00 |
| asalkeld | yeah, i nearly made a bug for that | 03:00 |
| asalkeld | it's still a bit messy, but will do for now | 03:00 |
| ananta_ | asalkeld: sure, let me know if it can be refactored in some way | 03:00 |
| asalkeld | i wonder if we really need to create a stack object and instead just pass the common_params in | 03:00 |
| asalkeld | let's get it working, then stand back and see how we can make it better | 03:01 |
| ananta_ | asalkeld: true... we don't need to pass the whole stack...but it was there for me to pass :) and aligned with old logic | 03:01 |
| ananta_ | asalkeld: sure | 03:01 |
| asalkeld | both +2'd | 03:01 |
| ananta_ | asalkeld: thank you! | 03:02 |
| asalkeld | i have 2 you can have a look at: https://review.openstack.org/#/c/196531/ https://review.openstack.org/#/c/196531/ | 03:02 |
| openstackgerrit | Merged openstack/python-heatclient: Fix argument order for assertEqual https://review.openstack.org/195718 | 03:02 |
| ramishra | morning all | 03:02 |
| asalkeld | https://review.openstack.org/#/c/196533/ | 03:02 |
| asalkeld | hi ramishra | 03:02 |
| ramishra | hi asalkeld | 03:03 |
| ananta_ | asalkeld: sure | 03:03 |
| *** kevinbenton has joined #heat | 03:08 | |
| *** gberginc has joined #heat | 03:09 | |
| ananta_ | asalkeld: reviewed | 03:10 |
| asalkeld | ta | 03:10 |
| *** MasterPiece has quit IRC | 03:13 | |
| *** pm90_ has joined #heat | 03:21 | |
| *** Drago has quit IRC | 03:32 | |
| sirushti | morning all | 03:45 |
| sirushti | ananta_, hi, what's up? | 03:45 |
| *** dims has quit IRC | 03:48 | |
| *** Slower has joined #heat | 03:52 | |
| *** kebray has quit IRC | 03:56 | |
| *** Slower has quit IRC | 04:00 | |
| *** coolsvap|away is now known as coolsvap | 04:08 | |
| *** sdake has joined #heat | 04:09 | |
| *** sdake_ has joined #heat | 04:10 | |
| ananta_ | sirushti: you may want to review https://review.openstack.org/#/c/196536/ and https://review.openstack.org/#/c/196619/ | 04:10 |
| sirushti | ananta_, sure | 04:11 |
| sirushti | ananta_, can we put those two in the DNM chain just to be sure so that we don't regress on any of the existing functional tests? | 04:12 |
| *** KanagarajM has joined #heat | 04:12 | |
| ananta_ | sirushti: sure | 04:12 |
| sirushti | ananta_, thanks | 04:12 |
| KanagarajM | good morning all | 04:12 |
| *** david-lyle has quit IRC | 04:13 | |
| *** achanda has joined #heat | 04:13 | |
| *** sdake has quit IRC | 04:13 | |
| *** david-lyle has joined #heat | 04:14 | |
| *** vasanth has joined #heat | 04:18 | |
| *** pm90_ has quit IRC | 04:22 | |
| sirushti | stevebaker, Hi, around? re: grenade testing | 04:25 |
| stevebaker | sirushti: hi | 04:25 |
| *** sdake has joined #heat | 04:25 | |
| sirushti | stevebaker, Hi, so do you want the whole of heat_integrationtests to run during the verify phase? | 04:25 |
| sirushti | stevebaker, I was hoping we run only a few smoke tests | 04:25 |
| sirushti | like what tempest does | 04:26 |
| sirushti | FWIW, I've also drafted a spec about the kind of upgrade tests we could write -> https://review.openstack.org/#/c/190641/2/specs/liberty/upgrade-tests.rst | 04:26 |
| stevebaker | sirushti: only running smoke tests sounds reasonable, but we need some mechanism for specifying which tests are smoke | 04:27 |
| sirushti | stevebaker, I'm thinking we need to move to something like tempest-lib | 04:27 |
| stevebaker | yes, that was always the plan, when it was ready to be consumed | 04:28 |
| *** gberginc has quit IRC | 04:28 | |
| *** sdake_ has quit IRC | 04:29 | |
| *** vasanth has quit IRC | 04:29 | |
| *** achanda has quit IRC | 04:30 | |
| sirushti | ok, I think it's being used now for python-.*client functional tests | 04:30 |
| *** pm90_ has joined #heat | 04:31 | |
| stevebaker | ok, that is a good start | 04:31 |
| *** tobe has quit IRC | 04:31 | |
| sirushti | ok, I'll take a better look at it, thanks | 04:32 |
| *** tobe has joined #heat | 04:32 | |
| sirushti | stevebaker, also, when you find time, could you please take a look at the direction of that upgrade-testing spec^ and let me know if that's okay | 04:34 |
| stevebaker | sure, I'll take a look | 04:35 |
| sirushti | thanks | 04:35 |
| *** ananta_ has quit IRC | 04:52 | |
| *** sdake_ has joined #heat | 04:59 | |
| *** sdake has quit IRC | 05:03 | |
| *** LiJiansheng has quit IRC | 05:11 | |
| *** vijayagurug has joined #heat | 05:19 | |
| *** LiJiansheng has joined #heat | 05:24 | |
| *** nihilifer has joined #heat | 05:25 | |
| *** rakesh_hs has joined #heat | 05:28 | |
| *** ifarkas has joined #heat | 05:31 | |
| openstackgerrit | Thomas Herve proposed openstack/heat: Add a new crypt method using cryptography https://review.openstack.org/195018 | 05:39 |
| *** ishant has joined #heat | 05:42 | |
| *** Marga_ has quit IRC | 05:43 | |
| *** ishant|2 has joined #heat | 05:46 | |
| *** achanda has joined #heat | 05:48 | |
| *** ishant has quit IRC | 05:49 | |
| *** tshtilma has joined #heat | 05:52 | |
| *** gberginc has joined #heat | 05:53 | |
| openstackgerrit | Pratik Mallya proposed openstack/heat: Add properties_data encryption to heat-manage https://review.openstack.org/195325 | 06:02 |
| *** achanda has quit IRC | 06:04 | |
| openstackgerrit | Pratik Mallya proposed openstack/heat: Fix heat-manage bug encrypting encrypted data https://review.openstack.org/195639 | 06:04 |
| openstackgerrit | Rabi Mishra proposed openstack/heat: Fix valdaition error for parameter group https://review.openstack.org/196956 | 06:08 |
| openstackgerrit | Rabi Mishra proposed openstack/heat: Fix validation error for parameter group https://review.openstack.org/196956 | 06:09 |
| *** pm90_ has quit IRC | 06:11 | |
| *** pm90_ has joined #heat | 06:11 | |
| *** erkules_ is now known as erkules | 06:12 | |
| *** erkules has joined #heat | 06:12 | |
| *** tlashchova_ has joined #heat | 06:16 | |
| openstackgerrit | Pratik Mallya proposed openstack/heat: Add properties_data encryption to heat-manage https://review.openstack.org/195325 | 06:17 |
| openstackgerrit | Pratik Mallya proposed openstack/heat: Fix heat-manage bug encrypting encrypted data https://review.openstack.org/195639 | 06:18 |
| *** Marga_ has joined #heat | 06:26 | |
| *** achanda has joined #heat | 06:26 | |
| *** sdake_ has quit IRC | 06:29 | |
| *** lsmola has joined #heat | 06:33 | |
| openstackgerrit | Thomas Herve proposed openstack/heat: Support snapshot deletion policy in Server https://review.openstack.org/185582 | 06:33 |
| *** tspatzier has joined #heat | 06:38 | |
| *** pm90_ has quit IRC | 06:38 | |
| *** nkhare has joined #heat | 06:40 | |
| *** pm90_ has joined #heat | 06:46 | |
| therve | ramishra, Around? Got a question on https://review.openstack.org/#/c/194052/ | 06:49 |
| ramishra | therve: hi.. sure | 06:49 |
| therve | ramishra, Do you know what's the deal with _resource_names being used outside of ResourceGroup? | 06:50 |
| therve | Oh | 06:52 |
| therve | SoftwareDeploymentGroup is a ResourceGroup | 06:52 |
| therve | Urggg | 06:53 |
| ramishra | therve: yeah | 06:53 |
| therve | ramishra, Thanks | 06:53 |
| ramishra | SDG has some way of handling it;) | 06:53 |
| therve | I also discovered group removal policies... Good lord | 06:54 |
| openstackgerrit | Kanagaraj Manickam proposed openstack/heat: Adds designate.domain constraint https://review.openstack.org/192569 | 06:54 |
| openstackgerrit | Kanagaraj Manickam proposed openstack/heat: Designate Domain resource https://review.openstack.org/193897 | 06:54 |
| openstackgerrit | Kanagaraj Manickam proposed openstack/heat: Designate Record resource https://review.openstack.org/193898 | 06:54 |
| ramishra | I think I'll refactor SDG later | 06:54 |
| *** pm90_ has quit IRC | 06:56 | |
| *** boris-42 has quit IRC | 07:02 | |
| *** achanda has quit IRC | 07:03 | |
| *** hdd has quit IRC | 07:11 | |
| *** pm90_ has joined #heat | 07:14 | |
| *** pm90__ has joined #heat | 07:18 | |
| *** pm90_ has quit IRC | 07:21 | |
| *** dkusidlo has joined #heat | 07:22 | |
| *** LimorStotland has joined #heat | 07:24 | |
| *** dkusidlo has quit IRC | 07:33 | |
| *** e0ne has joined #heat | 07:33 | |
| *** chlong has quit IRC | 07:35 | |
| *** e0ne has quit IRC | 07:37 | |
| openstackgerrit | Pratik Mallya proposed openstack/heat: Add properties_data encryption to heat-manage https://review.openstack.org/195325 | 07:40 |
| *** jistr has joined #heat | 07:43 | |
| *** BManojlovic has joined #heat | 07:43 | |
| *** jtomasek has joined #heat | 07:46 | |
| openstackgerrit | Pratik Mallya proposed openstack/heat: Fix heat-manage bug encrypting encrypted data https://review.openstack.org/195639 | 07:48 |
| *** LiJiansheng has quit IRC | 07:50 | |
| *** pm90__ has quit IRC | 07:53 | |
| *** pm90_ has joined #heat | 07:54 | |
| *** sdake_ has joined #heat | 07:55 | |
| *** shardy_ has joined #heat | 07:58 | |
| *** shardy has quit IRC | 07:59 | |
| *** LiJiansheng has joined #heat | 08:01 | |
| *** sergmelikyan has joined #heat | 08:02 | |
| *** jistr has quit IRC | 08:03 | |
| *** shardy_ has quit IRC | 08:03 | |
| *** shardy has joined #heat | 08:04 | |
| *** jistr has joined #heat | 08:10 | |
| *** sergmelikyan has quit IRC | 08:14 | |
| *** sergmelikyan has joined #heat | 08:15 | |
| *** tobe has quit IRC | 08:17 | |
| *** LiJiansheng has quit IRC | 08:19 | |
| *** LiJiansheng has joined #heat | 08:21 | |
| *** derekh has joined #heat | 08:22 | |
| *** sergmelikyan has quit IRC | 08:25 | |
| *** sergmelikyan has joined #heat | 08:26 | |
| *** LiJiansheng has quit IRC | 08:26 | |
| derekh | I'm wondering if I should do a heat temp revert in tripleo CI until this lands https://review.openstack.org/#/c/196717/1 | 08:26 |
| derekh | Any ETA on when this might land ? | 08:27 |
| pm90_ | +1 for that patch, it is breaking our templates :( | 08:28 |
| pm90_ | I mean, without it our templates are breaking | 08:29 |
| *** yassine_ has joined #heat | 08:34 | |
| *** sergmelikyan has quit IRC | 08:37 | |
| *** alex_xu_ is now known as alex_xu | 08:38 | |
| *** LiJiansheng has joined #heat | 08:39 | |
| *** pm90_ has quit IRC | 08:41 | |
| *** sdake_ has quit IRC | 08:45 | |
| -openstackstatus- NOTICE: OpenStack CI is down due to hard drive failures | 08:46 | |
| *** ChanServ changes topic to "OpenStack CI is down due to hard drive failures" | 08:46 | |
| *** mwheckmann has joined #heat | 08:50 | |
| *** pas-ha has joined #heat | 08:51 | |
| pas-ha | morning all | 08:51 |
| openstackgerrit | Angus Salkeld proposed openstack/heat: wip: yaql function https://review.openstack.org/196984 | 08:56 |
| *** sergmelikyan has joined #heat | 09:00 | |
| *** e0ne has joined #heat | 09:02 | |
| *** yuanying has joined #heat | 09:05 | |
| *** yuanying has quit IRC | 09:10 | |
| *** yuanying has joined #heat | 09:11 | |
| *** e0ne is now known as e0ne_ | 09:15 | |
| openstackgerrit | Steven Hardy proposed openstack/heat-specs: Add HOT resource_type_mapping annotation https://review.openstack.org/196656 | 09:22 |
| shardy | therve, tspatzier: ^^ I reworked the spec to move to a HOT annotation as discussed yesterday | 09:23 |
| shardy | the one thing we lose is the ability to do any grouping or compound constraint, but that's probably OK | 09:24 |
| tspatzier | hi shardy, cool, I'll have a look after lunch | 09:24 |
| shardy | tspatzier: great, thanks! :) | 09:24 |
| tspatzier | shardy: the compound constraint was a nice thing. I'll think about it - maybe we can find some clever combination? Or is it really two separate ideas? | 09:26 |
| *** e0ne_ has quit IRC | 09:26 | |
| shardy | tspatzier: I'm not sure, I couldn't see a way to keep it but will think about it more, any ideas on that much appreciated! :) | 09:26 |
| shardy | derekh: I just approved it, I missed that we only just landed the change because it's not a revert | 09:29 |
| derekh | shardy: ack, thanks | 09:29 |
| *** e0ne has joined #heat | 09:29 | |
| openstackgerrit | Steven Hardy proposed openstack/heat: Add str_split function to HOT 2015-10-15 https://review.openstack.org/195629 | 09:31 |
| *** tlashchova_ has quit IRC | 09:38 | |
| *** ochuprykov has joined #heat | 09:43 | |
| *** ananta_ has joined #heat | 09:49 | |
| *** LimorStotland has quit IRC | 09:49 | |
| *** LiJiansheng has quit IRC | 09:59 | |
| *** sergmelikyan has quit IRC | 10:10 | |
| *** LiJiansheng has joined #heat | 10:11 | |
| *** sergmelikyan has joined #heat | 10:11 | |
| *** coolsvap is now known as coolsvap|away | 10:14 | |
| *** Yanyanhu has quit IRC | 10:15 | |
| *** Qiming has quit IRC | 10:15 | |
| *** sergmelikyan has quit IRC | 10:17 | |
| *** elynn_ has quit IRC | 10:23 | |
| *** e0ne is now known as e0ne_ | 10:23 | |
| *** ananta_ has quit IRC | 10:23 | |
| *** e0ne_ is now known as e0ne | 10:25 | |
| *** LimorStotland has joined #heat | 10:27 | |
| *** sergmelikyan has joined #heat | 10:37 | |
| *** cmyster has joined #heat | 10:37 | |
| *** shardy_ has joined #heat | 10:43 | |
| *** shardy has quit IRC | 10:45 | |
| *** Drago1 has joined #heat | 10:45 | |
| *** Drago1 has quit IRC | 10:45 | |
| *** Drago1 has joined #heat | 10:46 | |
| *** sergmelikyan has quit IRC | 10:47 | |
| *** shardy_ has quit IRC | 10:48 | |
| *** yuanying has quit IRC | 10:49 | |
| *** shardy has joined #heat | 10:49 | |
| *** chlong has joined #heat | 10:50 | |
| *** LiJiansheng has quit IRC | 10:51 | |
| ramishra | ochuprykov: hi | 10:57 |
| ochuprykov | ramishra: hi | 10:58 |
| ramishra | ochuprykov: can you pl validate if all the corner cases that you can think of with RG rolling_update is taken care of now? | 10:59 |
| ochuprykov | ramishara: taking into account that capacity = count + blacklist? | 11:00 |
| ramishra | yes | 11:00 |
| ochuprykov | seems that it is correct | 11:01 |
| ramishra | if you can put all the corner cases in the comment, I'll add them to the unit tests | 11:02 |
| ochuprykov | ok, i will write some corner cases in comments | 11:02 |
| ramishra | ochuprykov: thanks | 11:03 |
| openstackgerrit | Kanagaraj Manickam proposed openstack/heat: Designate Domain resource https://review.openstack.org/193897 | 11:05 |
| openstackgerrit | Kanagaraj Manickam proposed openstack/heat: Designate Record resource https://review.openstack.org/193898 | 11:05 |
| *** dims has joined #heat | 11:07 | |
| *** EricGonczer_ has joined #heat | 11:10 | |
| *** LiJiansheng has joined #heat | 11:11 | |
| *** ishant|2 has quit IRC | 11:13 | |
| *** sergmelikyan has joined #heat | 11:14 | |
| *** Qiming has joined #heat | 11:15 | |
| ramishra | shardy: hi! | 11:18 |
| shardy | ramishra: Hi! | 11:18 |
| *** dkusidlo has joined #heat | 11:19 | |
| *** asalkeld has quit IRC | 11:20 | |
| ramishra | shardy: I've responded to your blacklist query for https://review.openstack.org/#/c/194052/, we do a final update as we leverage the blacklisted items during update to manage the min_in_service | 11:20 |
| shardy | ramishra: does it make sense to consider a blacklisted item as one of those in service? | 11:22 |
| ramishra | shardy: during the update yes, why not | 11:22 |
| shardy | ramishra: well the use-case for the blacklist is removing nodes which are either broken or are being removed from service | 11:23 |
| *** EricGonczer_ has quit IRC | 11:23 | |
| shardy | maybe it's fine, it just seems a bit odd to consider those nodes as "in service" | 11:23 |
| *** sparr has quit IRC | 11:23 | |
| shardy | not a blocker, just an observation :) | 11:24 |
| ramishra | shardy: we plan to blacklist them after the update, that's why I've considered them, I agree it's debatable. | 11:24 |
| shardy | ramishra: Ok, np, in practice I doubt operators will drop nodes and trigger a rolling update in the same operation anyway | 11:25 |
| shardy | unless they're crazy and/or very brave ;D | 11:25 |
| ramishra | yeah, I agree. but if we agree that dropping blacklist is the first thing and then we do any rolling update, we can do that. but we would have same number of updates(additional one in the beginning) | 11:26 |
| ramishra | the replace function is getting complicated with blacklist, final size etc. | 11:28 |
| shardy | maybe dropping them first would be slightly more logical, as by definition stuff in the blacklist is excluded from the group, and any operations on the group | 11:29 |
| *** KanagarajM has quit IRC | 11:29 | |
| shardy | would that help simplify things slightly, if we drop removed nodes, adjust the counts, then start the rolling update? | 11:29 |
| ramishra | yeah. sure. I'll try that | 11:30 |
| shardy | ramishra: I'm thinking it'd be good if _replace didn't need to know anything about the blacklist, other than perhaps some class variables reflecting the current count | 11:30 |
| ramishra | if we remove blacklist in the beginning it would be ok. else, we may end up updating the blacklisted nodes, which we don't want | 11:31 |
| shardy | relatedly, should we resize before trying the rolling update? | 11:32 |
| shardy | e.g if there's a blacklist, and/or an increase in count, we should probably handle that (to have the correct number of in-service nodes at the start of the rolling update), then do any replacement of existing nodes? | 11:34 |
| *** EricGonczer_ has joined #heat | 11:34 | |
| ramishra | what about blacklist? Also we add items to maintain min_in_service, so resize afterwards makes sense to me. | 11:34 |
| ochuprykov | i'm +1 to resize after | 11:34 |
| ochuprykov | in this case we needn't to create new instances only for managing min_in_service | 11:36 |
| *** radez is now known as radez_g0n3 | 11:36 | |
| *** sparr has joined #heat | 11:38 | |
| *** EricGonczer_ has quit IRC | 11:39 | |
| shardy | ramishra: resize uses _resource_names so it should respect the blacklist | 11:39 |
| shardy | I'm just thinking that if you increase count at the same time as modifying the resource definition, you probably want more capacity | 11:39 |
| shardy | so it's quite likely that reducing the capacity by the batch count for a long time is not what you wanted | 11:40 |
| shardy | If you add any new nodes (and remove any blacklisted ones), then you can process the rolling update without the temporary reduction in capacity, e.g less nodes than was even specified before the update | 11:41 |
| shardy | Again, this may well be a corner case not worth focussing too much on, just trying to think what an operator would want/expect | 11:41 |
| *** steveg_afk has joined #heat | 11:44 | |
| ramishra | yeah.. I know _replace function is complex now. But it takes care of most corner cases with minimum number of updates.. at least I believe so;) | 11:44 |
| ramishra | probably most of the cases may not happen in real-life. ex. modify resource def and reduce the count with a min_in_service same as count etc | 11:46 |
| *** liusheng has quit IRC | 11:48 | |
| *** tochi has quit IRC | 11:49 | |
| shardy | ramishra: Yeah, you may be right, I'm just trying to figure out the order of least operator astonishment | 11:50 |
| shardy | e.g if I increase count from 50 to 100, while also updating resource_def with a batch count of 10 | 11:50 |
| shardy | would you expect to have a net number of nodes of 40 or 90 during the rolling update? | 11:50 |
| shardy | I think I would expect 90 | 11:51 |
| shardy | Anyway, no big deal, just throwing the idea out there for consideration :) | 11:52 |
| *** EricGonczer_ has joined #heat | 11:53 | |
| ramishra | rolling update would do 40 and the 50 by resize, yeah I got your point. assumption is update is only for existing resources;) | 11:53 |
| *** EricGonc_ has joined #heat | 11:57 | |
| *** jruano has joined #heat | 11:57 | |
| *** radez_g0n3 is now known as radez | 11:58 | |
| *** EricGonczer_ has quit IRC | 11:58 | |
| *** jistr is now known as jistr|class | 11:59 | |
| *** EricGonczer_ has joined #heat | 12:00 | |
| *** EricGonc_ has quit IRC | 12:01 | |
| openstackgerrit | Steven Hardy proposed openstack/heat-specs: Add HOT resource_type_mapping annotation https://review.openstack.org/196656 | 12:02 |
| Qiming | dpm | 12:02 |
| Qiming | don't get the idea why we do resource definition update and group resize together | 12:02 |
| *** sergmelikyan has quit IRC | 12:04 | |
| *** jistr|class is now known as jistr | 12:07 | |
| *** lkarm has joined #heat | 12:08 | |
| *** dkusidlo has quit IRC | 12:18 | |
| *** ochuprykov has quit IRC | 12:19 | |
| *** Marga_ has quit IRC | 12:21 | |
| *** Marga_ has joined #heat | 12:21 | |
| *** nkhare has quit IRC | 12:25 | |
| *** pm90_ has joined #heat | 12:31 | |
| *** pm90_ has quit IRC | 12:33 | |
| *** pm90_ has joined #heat | 12:33 | |
| pm90_ | what does it mean when jenkins marks a build as unstable? | 12:35 |
| kairat_kushaev | pm90_: static.openstack.org has harddisk failure | 12:36 |
| kairat_kushaev | pm90_: So right now gates are broken | 12:36 |
| *** dkusidlo has joined #heat | 12:38 | |
| *** sergmelikyan has joined #heat | 12:39 | |
| *** shardy has quit IRC | 12:43 | |
| *** shardy has joined #heat | 12:43 | |
| *** EricGonczer_ has quit IRC | 12:45 | |
| *** mwheckmann has quit IRC | 12:47 | |
| pm90_ | kairat_kushaev: ah, thanks for the info! | 12:52 |
| *** rpothier has joined #heat | 12:58 | |
| *** bdossant has joined #heat | 12:58 | |
| *** ananta_ has joined #heat | 13:00 | |
| ananta_ | Could some one please review these convergence patches: https://review.openstack.org/#/c/196619/ and https://review.openstack.org/#/c/196536/ | 13:01 |
| ananta_ | and also https://review.openstack.org/#/c/195387/ | 13:01 |
| *** sergmelikyan has quit IRC | 13:02 | |
| *** KanagarajM has joined #heat | 13:02 | |
| *** sergmelikyan has joined #heat | 13:03 | |
| *** ananta_ has quit IRC | 13:03 | |
| *** sergmelikyan has quit IRC | 13:08 | |
| *** sergmelikyan has joined #heat | 13:14 | |
| *** jonesbr has joined #heat | 13:14 | |
| *** sergmelikyan has quit IRC | 13:14 | |
| *** sergmelikyan has joined #heat | 13:20 | |
| *** nihilifer has quit IRC | 13:21 | |
| *** EricGonczer_ has joined #heat | 13:21 | |
| *** jaime49 has joined #heat | 13:22 | |
| *** EricGonc_ has joined #heat | 13:22 | |
| *** EricGonczer_ has quit IRC | 13:25 | |
| *** e0ne is now known as e0ne_ | 13:29 | |
| *** gberginc has quit IRC | 13:31 | |
| *** boris-42 has joined #heat | 13:31 | |
| *** dkusidlo has quit IRC | 13:31 | |
| *** cody-somerville has joined #heat | 13:32 | |
| *** cody-somerville has quit IRC | 13:32 | |
| *** cody-somerville has joined #heat | 13:32 | |
| *** htruta has joined #heat | 13:35 | |
| openstackgerrit | Sirushti Murugesan proposed openstack/heat-specs: Add a spec for in tree upgrade tests https://review.openstack.org/190641 | 13:36 |
| *** e0ne_ has quit IRC | 13:39 | |
| *** jaime49 has quit IRC | 13:41 | |
| *** jaime49 has joined #heat | 13:41 | |
| *** LiJiansheng has quit IRC | 13:42 | |
| *** dkusidlo has joined #heat | 13:43 | |
| *** KanagarajM has quit IRC | 13:46 | |
| *** e0ne has joined #heat | 13:46 | |
| *** ochuprykov has joined #heat | 13:46 | |
| *** jaime49 has quit IRC | 13:47 | |
| tspatzier | shardy: I looked at your latest spec. Looks good to me! | 13:50 |
| tspatzier | on the compound constraints, I really don't have a good idea right now. | 13:50 |
| tspatzier | The only thing that comes to mind is some kind of namespacing like in the XML world. I.e. template in namespace 1 only works with templates in the same namespace. | 13:51 |
| tspatzier | Otherwise, if we would put explicit template names or IDs in a template ('works_with: [template1.yaml, template2.yaml] it would not be self-contained any more. | 13:52 |
| tspatzier | ... but something like this is really a second step that we could do at some point in the future. | 13:53 |
| therve | tspatzier, Not sure why you say that the proposal make the registry obsolete | 13:55 |
| therve | tspatzier, Surely that's only the case if you only have one provider for the resource | 13:55 |
| *** dyasny has joined #heat | 13:55 | |
| therve | Whereas the point is to have several? | 13:55 |
| *** LiJiansheng has joined #heat | 13:56 | |
| tspatzier | therve: I thought if you have nested templates files all annotated with the new mapping, it is not necessary any more to declare this explicitly in the environment. It can all be discovered from a common directory or something. | 13:56 |
| tspatzier | or environment could overrule/restrict the discovered mapping? | 13:57 |
| therve | tspatzier, Ah, you meant for the user-one, gotcha | 13:57 |
| tspatzier | How both play together is actually an interesting question. | 13:57 |
| therve | I was thinking for the server side one | 13:57 |
| *** bdossant_ has joined #heat | 13:58 | |
| therve | As a first step I would keep things explicit | 13:58 |
| tspatzier | therve: also for server side, a provide could decide to put a couple of possible provider templates in a certain dir and not declare a resource_registry | 13:58 |
| *** bdossant has quit IRC | 13:59 | |
| *** sergmelikyan has quit IRC | 13:59 | |
| tspatzier | agreed. I guess once the new feature is there, we will get to some kind of best practises when to use which mechanism | 13:59 |
| *** sergmelikyan has joined #heat | 13:59 | |
| *** jecarey has joined #heat | 14:00 | |
| shardy | tspatzier: thanks for the feedback, agree we can leave the compound constraints thing until later | 14:00 |
| *** dims has quit IRC | 14:01 | |
| shardy | the point is to allow multiple implementations of the same resource type though, that's the main point of this change wrt TripleO requirements | 14:01 |
| shardy | e.g to make the different implementations more easily discoverable | 14:01 |
| *** dims has joined #heat | 14:01 | |
| *** wmlynch has joined #heat | 14:02 | |
| shardy | So IMO we do still need the resource_registry to define which implementation is actually selected | 14:02 |
| *** LiJiansheng has quit IRC | 14:03 | |
| therve | Right, we could potentially make the registry optional | 14:04 |
| *** pas-ha has quit IRC | 14:04 | |
| shardy | Well I think possibly a heatclient feature to create the registry automatically if exactly one impelementation is discovered could be nice | 14:04 |
| therve | +1 | 14:05 |
| shardy | Or I suppose heat could resolve it, but heatclient still needs to know which files to include in the request | 14:05 |
| shardy | e.g it's already created the resource_registry mapping by that point anyway | 14:05 |
| therve | shardy, About the resource_type_mapping section, and hoping to not derail the conversation | 14:05 |
| therve | shardy, Would it be generic enough to be what has been called "template metadata" in some past discussions? | 14:06 |
| shardy | Hmmm | 14:07 |
| shardy | I suppose, but I hadn't really envisaged any freeform usage, only things related to mapping the template to a resource type | 14:07 |
| *** dkusidlo has quit IRC | 14:07 | |
| openstackgerrit | Tetiana Lashchova proposed openstack/python-heatclient: Add support for template-function-list command https://review.openstack.org/195070 | 14:08 |
| openstackgerrit | Tetiana Lashchova proposed openstack/python-heatclient: Add support for template-version-list command https://review.openstack.org/192696 | 14:08 |
| shardy | e.g it's only a map because we might want to add some of the other tosca stuff like capabilities later | 14:08 |
| therve | I'm sure we can ask Randall what he thinks :) | 14:08 |
| shardy | I suppose folks could (ab)use the resource_type list and put whatever they want in there though ;) | 14:08 |
| therve | Yeah, let's hope not | 14:09 |
| therve | I guess you don't provide any storage/query guarantee in this spec, was just wondering | 14:10 |
| shardy | Yeah, I don't see how we can validate the resource_type list to enforce *only* types from the environment, it's going to be if <env type> in <resource type list> | 14:12 |
| shardy | but I'd prefer not to document it as anything-goes-here, or make any promises about validation in future :) | 14:12 |
| *** dkusidlo has joined #heat | 14:12 | |
| therve | Sure, but we could call it metadata without any guarantee for now, and see if people are interested on building stuff around it | 14:14 |
| *** bdossant_ has quit IRC | 14:14 | |
| therve | If we call it resource_type_mapping we're kind of stuck with that name for a while | 14:15 |
| *** jruano has quit IRC | 14:15 | |
| Qiming | shardy, why don't we persist this mapping into heat db? | 14:18 |
| *** pas-ha has joined #heat | 14:18 | |
| shardy | Qiming: because the point is better composability before the stack is persisted by heat | 14:20 |
| shardy | e.g to enable clients to make better decisions about which resource_registry mappings are valid, and to allow heat to validate that | 14:20 |
| Qiming | validation is always needed | 14:21 |
| shardy | therve: I'm -1 on the generic metadata idea, I'd prefer to this section to be limited to composability related stuff, e.g aligning somewhat with tosca | 14:22 |
| therve | Mokay | 14:23 |
| therve | I'm not super excited about the proliferation of keywords | 14:23 |
| *** shardy_ has joined #heat | 14:24 | |
| openstackgerrit | Rico Lin proposed openstack/heat: support list resources with details https://review.openstack.org/196571 | 14:24 |
| openstackgerrit | Rakesh H S proposed openstack/heat: Consolidates cinder unit tests https://review.openstack.org/196510 | 14:24 |
| openstackgerrit | Rakesh H S proposed openstack/heat: Resource plugin for cinder volume encryption https://review.openstack.org/195103 | 14:24 |
| *** shardy has quit IRC | 14:24 | |
| *** wmlynch has quit IRC | 14:27 | |
| *** shardy_ has quit IRC | 14:29 | |
| *** shardy has joined #heat | 14:30 | |
| *** lapalm has joined #heat | 14:32 | |
| *** wmlynch has joined #heat | 14:32 | |
| *** ochuprykov has quit IRC | 14:32 | |
| *** FL1SK has quit IRC | 14:35 | |
| *** hdd has joined #heat | 14:36 | |
| *** kebray has joined #heat | 14:37 | |
| *** vijayagurug has left #heat | 14:37 | |
| *** pm90_ has quit IRC | 14:43 | |
| *** kebray has quit IRC | 14:44 | |
| shardy | Anyone know where the hot guide has moved (again) to? | 14:44 |
| *** dkusidlo has quit IRC | 14:45 | |
| shardy | the one covering composition and software config in detail | 14:45 |
| shardy | http://docs.openstack.org/user-guide/hot.html just links to the template guide | 14:45 |
| *** lkarm has left #heat | 14:46 | |
| *** sergmelikyan has quit IRC | 14:47 | |
| *** pm90_ has joined #heat | 14:48 | |
| *** dsneddon has quit IRC | 14:48 | |
| *** sergmelikyan has joined #heat | 14:49 | |
| *** sergmelikyan has quit IRC | 14:49 | |
| *** dsneddon has joined #heat | 14:51 | |
| *** ChanServ changes topic to "support @ https://ask.openstack.org | developer wiki @ https://wiki.openstack.org/wiki/Heat | development @ https://launchpad.net/heat | logged @ http://eavesdrop.openstack.org/irclogs/%23heat/" | 14:51 | |
| -openstackstatus- NOTICE: The log volume was repaired and brought back online at 14:00 UTC. Log links today from before that time may be missing, and changes should be rechecked if fresh job logs are desired for them. | 14:51 | |
| *** dkusidlo has joined #heat | 14:53 | |
| *** e0ne is now known as e0ne_ | 14:55 | |
| *** EricGonc_ has quit IRC | 14:55 | |
| *** shardy has quit IRC | 14:56 | |
| *** shardy has joined #heat | 14:56 | |
| *** jaypipes has quit IRC | 14:58 | |
| *** e0ne_ is now known as e0ne | 14:58 | |
| *** sergmelikyan has joined #heat | 14:58 | |
| *** e0ne is now known as e0ne_ | 14:59 | |
| *** e0ne_ is now known as e0ne | 14:59 | |
| *** pm90_ is now known as pratikmallya | 14:59 | |
| *** pas-ha has quit IRC | 15:01 | |
| *** sergmelikyan has quit IRC | 15:06 | |
| *** shardy has quit IRC | 15:12 | |
| *** pas-ha has joined #heat | 15:13 | |
| *** dkusidlo has quit IRC | 15:14 | |
| *** jruano has joined #heat | 15:16 | |
| *** Qiming has quit IRC | 15:17 | |
| *** shardy has joined #heat | 15:18 | |
| *** BManojlovic has quit IRC | 15:18 | |
| *** mikeit has joined #heat | 15:20 | |
| *** cmyster_ has joined #heat | 15:22 | |
| *** cmyster has quit IRC | 15:26 | |
| *** Slower has joined #heat | 15:36 | |
| openstackgerrit | Pratik Mallya proposed openstack/heat: Add properties_data encryption to heat-manage https://review.openstack.org/195325 | 15:38 |
| *** sabeen1 has quit IRC | 15:38 | |
| openstackgerrit | Pratik Mallya proposed openstack/heat: Fix heat-manage bug encrypting encrypted data https://review.openstack.org/195639 | 15:43 |
| tspatzier | shardy: I was distracted for a while and just scanned the history. So you say the resource_registry will still be the definitive source for which provider template is used. And the resource_type_mapping section is just for doing some initial discovery to see what options exist? Right? | 15:43 |
| tspatzier | So what would be the overall flow: user discovery based on annotation. Then defines the resource registry with the selected provider templates? | 15:44 |
| tspatzier | Really just a question. Because we definitely need a place where the final mapping is defined. Otherwise, if we discover multiple options for a resource type, who would decide on the one to choose, right? | 15:45 |
| *** Drago1 has quit IRC | 15:47 | |
| *** kencjohnston has joined #heat | 15:49 | |
| *** Marga_ has quit IRC | 15:53 | |
| *** sdake has joined #heat | 15:54 | |
| *** mrutkows has joined #heat | 15:54 | |
| *** achanda has joined #heat | 15:56 | |
| *** sdake_ has joined #heat | 15:56 | |
| jdandrea | Has anyone been in touch with chamberk or barnold in relation to stack-lifecycle-scheduler-hint lately? I've been trying to reach either/or regarding stack resource IDs (vs. Nova/Cinder/etc. IDs) to no avail. | 15:59 |
| *** tspatzier has quit IRC | 16:00 | |
| *** achanda has quit IRC | 16:00 | |
| *** sdake has quit IRC | 16:00 | |
| *** jistr has quit IRC | 16:01 | |
| *** tlashchova_ has joined #heat | 16:01 | |
| *** sergmelikyan has joined #heat | 16:01 | |
| *** vijayagurug has joined #heat | 16:02 | |
| jdandrea | ... though I did confirm that those IDs *are* obtainable during the lifecycle plugin do_pre_op phase (per a brief chat with either sbaker or zaneb in Vancouver, I forget now, as a result of starting to implement convergence). | 16:03 |
| *** spzala has joined #heat | 16:04 | |
| *** Drago has joined #heat | 16:05 | |
| *** shardy has quit IRC | 16:06 | |
| *** shardy has joined #heat | 16:07 | |
| *** rakesh_hs has quit IRC | 16:13 | |
| *** Drago has quit IRC | 16:13 | |
| *** Drago has joined #heat | 16:14 | |
| *** pas-ha has quit IRC | 16:16 | |
| *** shardy_ has joined #heat | 16:17 | |
| *** shardy has quit IRC | 16:18 | |
| *** pas-ha has joined #heat | 16:18 | |
| *** beekneemech is now known as bnemec | 16:19 | |
| *** sergmelikyan has quit IRC | 16:21 | |
| *** EricGonczer_ has joined #heat | 16:23 | |
| *** shardy_ has quit IRC | 16:23 | |
| *** e0ne is now known as e0ne_ | 16:23 | |
| *** shardy has joined #heat | 16:24 | |
| *** heatuser has joined #heat | 16:25 | |
| *** tlashchova_ has quit IRC | 16:25 | |
| heatuser | Does heat support vertical scaling ? | 16:25 |
| *** jaypipes has joined #heat | 16:26 | |
| *** sergmelikyan has joined #heat | 16:28 | |
| *** dontalton has joined #heat | 16:29 | |
| heatuser | Does heat support vertical scaling ? | 16:31 |
| *** e0ne_ has quit IRC | 16:34 | |
| *** achanda has joined #heat | 16:35 | |
| *** e0ne has joined #heat | 16:36 | |
| *** FL1SK has joined #heat | 16:36 | |
| pas-ha | heatuser, what do you mean by vertical? you can resize VMs via stack-update, but currently heat is too optimistic in that regard | 16:37 |
| pas-ha | that is usual workflow is that after VM resize user should manually go into this VM, check that everything is working as it should and that finally confirm the resize with Nova | 16:38 |
| heatuser | pas-ha: how do you do a stack-update ? | 16:38 |
| pas-ha | heat instead always automatically confirms the resize when VM goes to VERIFY_RESIZE state | 16:38 |
| pas-ha | change the template part describing the flavor of the server and issue a usual stack update | 16:39 |
| heatuser | what is a usual stack update ? | 16:39 |
| pas-ha | heat http://docs.openstack.org/developer/python-heatclient/man/heat.html | 16:40 |
| pas-ha | via command line interface or API of python-heatclient | 16:41 |
| *** tshtilma has quit IRC | 16:42 | |
| heatuser | can I change the flavor inside the template itself ? | 16:43 |
| heatuser | like, I want to have a trigger that changes the flavor | 16:43 |
| heatuser | pas-ha | 16:44 |
| pas-ha | for that you would probably need to use a service like Mistral, heat templates are not imperative | 16:44 |
| pas-ha | couple a Mistral workflow with Ceilometer alarm and make it update the stack with template containing fatter flavor | 16:45 |
| jdandrea | heatuser: | 16:46 |
| *** yassine_ has quit IRC | 16:47 | |
| jdandrea | heatuser: The OS::Nova::Server resource type has a "flavor" property. According to the docs it can be updated without replacement. http://docs.openstack.org/hot-reference/content/OS__Nova__Server.html | 16:47 |
| pas-ha | in anyway, that's actually not the best application design - resizing Nova server is disturbing the app that is inside, you can definitely count on your app outages | 16:48 |
| jdandrea | pas-ha: Good/tangential point to be aware of, yep. | 16:48 |
| jdandrea | As for the question itself though, it does appear possible. | 16:48 |
| heatuser | so, resizing a nova server is not recommended ? | 16:49 |
| jdandrea | As for triggers, yeah, Mistral/Ceilometer. | 16:49 |
| *** mwheckmann has joined #heat | 16:49 | |
| pas-ha | you must understand what you are doing and how it will affect the workload | 16:49 |
| heatuser | once you set it to one particular flavor, it's bad to change it to another ? | 16:49 |
| pas-ha | again, it depends on what are you using this VM for / what application is running on that VM | 16:50 |
| *** openstackgerrit has quit IRC | 16:50 | |
| pas-ha | and how much you are bound to uptime of your application | 16:50 |
| heatuser | assume, I'm running the worst possible thing | 16:51 |
| *** openstackgerrit has joined #heat | 16:51 | |
| pas-ha | you might loose some intermittent data probably - during resize AFAIK Nova brings up a new VM with new flavor, and then kills the old one after resize is confirmed | 16:52 |
| pas-ha | it probably tries to keep all the partitions like ephemeral though, not sure | 16:53 |
| *** kencjohnston has quit IRC | 16:53 | |
| pas-ha | also, if you've done any manual changes inside the VM before resize - they all would be gone, you'd have to repeat them inside the resized one | 16:54 |
| * pas-ha not even sure if the original user data would be executed on the resized VM | 16:54 | |
| heatuser | pass-ha: so it doesn't actually resize the current vm, it creates the new vm with new flavor and copies everything from the previous vm ? | 16:54 |
| heatuser | pass-ha: might not even copy everything; might lose data ? | 16:55 |
| jdandrea | heatuser: Some supplementary info, as you mentioned vertical scaling earlier: http://docs.openstack.org/openstack-ops/content/scaling.html | 16:56 |
| pas-ha | AFAIK something like that, but probably depends on what exactly flavor parameters are changing (CPU no, RAM, sizes of partitions) and how much the actual compute backend supports live changes to them | 16:56 |
| pas-ha | e.g. AFAIR vmware (some older versions ?) had some problems with increasing some values online without restarting the VM | 16:57 |
| pas-ha | jdandrea, that link is for scaling your deployment AFAIU, not the app | 16:58 |
| jdandrea | Using nova directly, there is "nova resize" and "nova snapshot" (followed by "nova boot"). They are more heavyweight (especially if stuff ends up being copied between compute/controller nodes). | 16:58 |
| *** lapalm has quit IRC | 16:59 | |
| heatuser | pas-ha: I want to be able to change both CPU and RAM on the fly | 16:59 |
| jdandrea | pas-ha: *nods* but the note at the top mentions scaling and I thought that was worth pointing out (vertical in a traditional sense vs horizontal with clouds) | 16:59 |
| *** derekh has quit IRC | 16:59 | |
| *** lapalm has joined #heat | 16:59 | |
| pas-ha | heatuser, you can ask nova team what limitations are there | 17:00 |
| pas-ha | nova resize is what probably should be used here (snapshot/boot is more destructive for the app inside the VM) | 17:01 |
| jdandrea | Doc page for resize: http://docs.openstack.org/user-guide/cli_change_the_size_of_your_server.html - and note that the resized server may end up on a different compute node! (Not sure if that matters.) I second pas-ha, be aware that there is interruption and assess what that will mean for the server/app. | 17:03 |
| heatuser | can I issue a nova resize command within a hot template itself ? | 17:03 |
| *** lapalm has quit IRC | 17:03 | |
| jdandrea | heatuser: HOT is declarative, so the idea is you modify the template and issue a stack-update. Heat then orchestrates the changes by communicating with Nova, Cinder, et. al as needed. (I wonder if Heat effectively makes a resize request under the hood? Haven't checked the source for that.) | 17:04 |
| *** e0ne has quit IRC | 17:05 | |
| jdandrea | So in the template you are saying "This is how I want reality to be." So long as the template is copacetic, Heat then conducts the various services to make whatever changes are needed, and in a sensible order if there's more than one change. | 17:06 |
| jdandrea | In a sense, then, you're not having to remember "Which command do I use to do X in service Y again?" (Though it probably doesn't hurt to understand/appreciate what happens behind the scenes in various cases.) | 17:07 |
| *** randallburt has joined #heat | 17:07 | |
| pas-ha | jdandrea, yes, heat makes resize request | 17:07 |
| jdandrea | :D | 17:08 |
| *** sabeen has joined #heat | 17:08 | |
| pas-ha | and then blindly confirms it as I pointed | 17:08 |
| jdandrea | *chuckle* yup | 17:08 |
| heatuser | can OS::Ceilometer::Alarm trigger a nova sesize request ? | 17:08 |
| pas-ha | not in heat, as I sad you would have to use another service to do an automated stack update for you, like Mistral | 17:09 |
| *** sergmelikyan has quit IRC | 17:09 | |
| jdandrea | A ceilometer alarm issues a trigger (or logs in a file), but Heat is meant to orchestrate nouns, not verbs, as it were. :) | 17:09 |
| jdandrea | This would be a verb, hence Mistral, yup. | 17:10 |
| *** sergmelikyan has joined #heat | 17:10 | |
| * jdandrea looks away from the present Autoscaling and the deprecated HA Restarter resource (I know, I know, those are verb-y). | 17:11 | |
| *** sabeen has quit IRC | 17:12 | |
| heatuser | ohh, another thing | 17:13 |
| *** sabeen1 has joined #heat | 17:14 | |
| heatuser | in OS::Heat::AutoScalingGroup, can I pass a reference to a nova server from a parent template to a nested/child template ? | 17:15 |
| heatuser | jdandrea or pas-ha | 17:16 |
| *** sdake has joined #heat | 17:17 | |
| shardy | heatuser: yes, the native ASG resource can scale out stacks (not only nova servers), so you can define a template containing a nova server resource, which then passes the server ID into a child template (so you'd scale out the unit of two templates) | 17:18 |
| shardy | https://github.com/openstack/heat-templates/blob/master/hot/asg_of_stacks.yaml#L51 | 17:18 |
| heatuser | shardy: my goal to scale a OS::Heat::SoftwareDeployment | 17:19 |
| shardy | heatuser: that is certainly possible, although I'm intrigued by the use-case | 17:20 |
| *** mikeit has quit IRC | 17:21 | |
| *** sdake_ has quit IRC | 17:21 | |
| heatuser | shardy:so, do I need to redefine everything from this SoftwareDeployment in the child template, or I can just pass the ids in to the child template from the parent template ? | 17:21 |
| shardy | heatuser: if you create the server outside the group, then pass the ID in and scale out config/deployment resources, you'd just be reapplying an increasingly duplicated configuration multiple times, no? | 17:22 |
| shardy | heatuser: you can just pass in the IDs, if you don't want to scale out the other resources | 17:22 |
| *** metral is now known as metral_zzz | 17:23 | |
| *** sabeen1 has quit IRC | 17:23 | |
| heatuser | shardy: I want to scale config and server from SoftwareDeployment | 17:23 |
| heatuser | shardy: but not depends_on | 17:24 |
| *** sabeen has joined #heat | 17:24 | |
| heatuser | shardy: so, do I need to redefine config, server, depends_on in a child template ? | 17:25 |
| *** htruta_ has joined #heat | 17:25 | |
| heatuser | shardy: or can I just pass the IDs from the parent template ? or maybe, I can define the software deployment under resource in ASG ? | 17:26 |
| shardy | heatuser: sorry, you've lost me tbh - you just put whatever resources you want to scale out inside the child template, then have AutoScalingGroup scale it out | 17:26 |
| shardy | http://hardysteven.blogspot.co.uk/2015/05/heat-softwareconfig-resources.html | 17:26 |
| shardy | that may provide some context around applying multiple config/deployment resources to a single server | 17:26 |
| shardy | Scaling just a SoftwareDeployment makes no sense AFAICT, because inside an ASG every resource will be identical | 17:27 |
| shardy | but if you want to do it, yes it's technically possible and you can just pass in the IDs | 17:27 |
| heatuser | shardy: I'm trying to implement horizontal scaling | 17:28 |
| heatuser | shardy: and when I'm scaling up/down, I want to include all the configs with each vm that I scale up/down | 17:28 |
| heatuser | shardy: that is what I'm trying to do | 17:29 |
| *** tshtilma has joined #heat | 17:30 | |
| *** sergmelikyan has quit IRC | 17:31 | |
| *** mwheckmann has quit IRC | 17:33 | |
| *** dyasny has quit IRC | 17:33 | |
| *** metral_zzz is now known as metral | 17:37 | |
| *** dyasny has joined #heat | 17:37 | |
| *** achanda_ has joined #heat | 17:38 | |
| *** spzala has quit IRC | 17:40 | |
| *** achanda has quit IRC | 17:40 | |
| *** achanda has joined #heat | 17:42 | |
| *** jecarey has quit IRC | 17:43 | |
| *** achanda_ has quit IRC | 17:44 | |
| *** pas-ha has quit IRC | 17:46 | |
| *** sdake_ has joined #heat | 17:47 | |
| *** lsmola has quit IRC | 17:49 | |
| *** sdake has quit IRC | 17:50 | |
| *** sdake_ is now known as sdake | 17:50 | |
| openstackgerrit | Steven Hardy proposed openstack/heat-specs: Add nested-validation spec https://review.openstack.org/197199 | 17:51 |
| *** jecarey has joined #heat | 17:56 | |
| *** vijayagurug has left #heat | 17:56 | |
| *** chlong has quit IRC | 17:56 | |
| *** e0ne has joined #heat | 17:58 | |
| *** lapalm has joined #heat | 18:00 | |
| *** lapalm has quit IRC | 18:04 | |
| *** e0ne is now known as e0ne_ | 18:04 | |
| *** sthillma has joined #heat | 18:05 | |
| *** e0ne_ is now known as e0ne | 18:07 | |
| *** spzala has joined #heat | 18:11 | |
| *** tspatzier has joined #heat | 18:11 | |
| *** sthillma has quit IRC | 18:14 | |
| openstackgerrit | Julio Ruano proposed openstack/heat: WIP: Add Service to Magnum resources https://review.openstack.org/197207 | 18:14 |
| *** sthillma has joined #heat | 18:15 | |
| *** tellesnobrega_ has joined #heat | 18:15 | |
| *** e0ne is now known as e0ne_ | 18:18 | |
| *** randallburt has quit IRC | 18:18 | |
| *** tellesnobrega_ has quit IRC | 18:20 | |
| *** achanda has quit IRC | 18:21 | |
| *** heatuser has quit IRC | 18:22 | |
| *** e0ne_ is now known as e0ne | 18:23 | |
| *** htruta_ has quit IRC | 18:26 | |
| *** shardy has quit IRC | 18:27 | |
| *** shardy has joined #heat | 18:27 | |
| *** gberginc has joined #heat | 18:27 | |
| *** jruano_ has joined #heat | 18:31 | |
| *** jruano has quit IRC | 18:32 | |
| openstackgerrit | Miguel Grinberg proposed openstack/heat: Prepare SignalResponder class for more signal types https://review.openstack.org/197220 | 18:37 |
| *** multi_io has quit IRC | 18:37 | |
| *** multi_io has joined #heat | 18:43 | |
| *** sdake has quit IRC | 18:46 | |
| *** sdake has joined #heat | 18:47 | |
| *** randallburt has joined #heat | 18:48 | |
| *** cmyster_ has quit IRC | 18:55 | |
| *** lapalm has joined #heat | 19:06 | |
| *** lapalm has quit IRC | 19:06 | |
| *** lapalm has joined #heat | 19:06 | |
| *** dsneddon has quit IRC | 19:09 | |
| *** achanda has joined #heat | 19:10 | |
| *** lapalm has quit IRC | 19:11 | |
| *** shardy has quit IRC | 19:13 | |
| *** e0ne is now known as e0ne_ | 19:14 | |
| *** blomquisg has quit IRC | 19:14 | |
| *** blomquisg has joined #heat | 19:15 | |
| *** e0ne_ is now known as e0ne | 19:15 | |
| *** dsneddon has joined #heat | 19:18 | |
| *** tlashchova_ has joined #heat | 19:22 | |
| *** tspatzier has quit IRC | 19:24 | |
| *** Marga_ has joined #heat | 19:26 | |
| *** randallburt has quit IRC | 19:30 | |
| *** Marga_ has quit IRC | 19:32 | |
| *** Marga_ has joined #heat | 19:32 | |
| *** Marga_ has quit IRC | 19:36 | |
| *** Marga__ has joined #heat | 19:36 | |
| *** Marga__ has quit IRC | 19:53 | |
| *** achanda has quit IRC | 19:54 | |
| *** achanda has joined #heat | 19:55 | |
| openstackgerrit | OpenStack Proposal Bot proposed openstack/heat: Updated from global requirements https://review.openstack.org/195108 | 19:56 |
| *** achanda has quit IRC | 19:59 | |
| *** jaime49 has joined #heat | 20:01 | |
| openstackgerrit | OpenStack Proposal Bot proposed openstack/python-heatclient: Updated from global requirements https://review.openstack.org/197275 | 20:02 |
| *** jruano_ has quit IRC | 20:04 | |
| *** jruano has joined #heat | 20:05 | |
| openstackgerrit | Merged openstack/heat: Coverage: Full coverage for engine function methods https://review.openstack.org/196453 | 20:06 |
| *** tshtilma has quit IRC | 20:07 | |
| *** lapalm has joined #heat | 20:07 | |
| *** gokrokve has joined #heat | 20:10 | |
| *** lapalm has quit IRC | 20:12 | |
| *** sergmelikyan has joined #heat | 20:13 | |
| *** mrutkows has quit IRC | 20:15 | |
| *** sergmelikyan has quit IRC | 20:17 | |
| *** sergmelikyan has joined #heat | 20:18 | |
| *** serg_melikyan has joined #heat | 20:24 | |
| *** sergmelikyan has quit IRC | 20:25 | |
| *** lapalm has joined #heat | 20:28 | |
| *** lapalm has quit IRC | 20:30 | |
| *** lapalm has joined #heat | 20:30 | |
| *** tlashchova_ has quit IRC | 20:30 | |
| *** serg_melikyan has quit IRC | 20:32 | |
| *** sergmelikyan has joined #heat | 20:34 | |
| *** lapalm_ has joined #heat | 20:34 | |
| *** lapalm has quit IRC | 20:34 | |
| *** e0ne has quit IRC | 20:35 | |
| *** jtomasek has quit IRC | 20:37 | |
| *** gberginc has quit IRC | 20:38 | |
| *** EricGonczer_ has quit IRC | 20:39 | |
| *** randallburt has joined #heat | 20:43 | |
| *** lapalm_ has quit IRC | 20:46 | |
| *** radez is now known as radez_g0n3 | 20:58 | |
| *** vahidh has quit IRC | 21:09 | |
| *** pratikma_ has joined #heat | 21:13 | |
| *** pratikmallya has quit IRC | 21:13 | |
| *** rpothier has quit IRC | 21:14 | |
| *** sergmelikyan has quit IRC | 21:17 | |
| *** vahidh has joined #heat | 21:21 | |
| *** daneyon has joined #heat | 21:27 | |
| *** dyasny has quit IRC | 21:42 | |
| *** jonesbr has left #heat | 21:44 | |
| *** kairat_kushaev has quit IRC | 21:47 | |
| *** skraynev has quit IRC | 21:49 | |
| *** Raj1 has joined #heat | 21:54 | |
| *** jecarey has quit IRC | 21:57 | |
| *** jruano has quit IRC | 21:59 | |
| *** spzala has quit IRC | 22:04 | |
| *** kebray has joined #heat | 22:04 | |
| *** randallburt has quit IRC | 22:04 | |
| *** hdd has quit IRC | 22:06 | |
| *** gokrokve has quit IRC | 22:07 | |
| *** jaime49 has quit IRC | 22:09 | |
| *** dims_ has joined #heat | 22:19 | |
| *** sergmelikyan has joined #heat | 22:19 | |
| *** Raj1 has quit IRC | 22:19 | |
| *** dims has quit IRC | 22:22 | |
| *** gokrokve has joined #heat | 22:22 | |
| *** pleia2 has quit IRC | 22:23 | |
| *** Hazelesque has quit IRC | 22:23 | |
| *** Hazelesque_ has joined #heat | 22:23 | |
| *** pleia2 has joined #heat | 22:25 | |
| *** kebray has quit IRC | 22:35 | |
| openstackgerrit | Merged openstack/heat: Remove default of port_security_enabled https://review.openstack.org/196717 | 22:35 |
| *** dontalton has quit IRC | 22:37 | |
| openstackgerrit | OpenStack Proposal Bot proposed openstack/heat: Updated from global requirements https://review.openstack.org/195108 | 22:38 |
| *** asalkeld has joined #heat | 22:38 | |
| *** gokrokve has quit IRC | 22:44 | |
| openstackgerrit | OpenStack Proposal Bot proposed openstack/python-heatclient: Updated from global requirements https://review.openstack.org/197275 | 22:45 |
| *** jruano has joined #heat | 22:45 | |
| *** randallburt has joined #heat | 22:47 | |
| *** sabeen has quit IRC | 22:48 | |
| *** daneyon has quit IRC | 22:52 | |
| *** sergmelikyan has quit IRC | 22:52 | |
| *** jruano has quit IRC | 22:57 | |
| *** dims_ has quit IRC | 23:01 | |
| *** randallburt has quit IRC | 23:09 | |
| asalkeld | stevebaker: yaql poc -> https://review.openstack.org/#/c/196984/1 | 23:13 |
| stevebaker | asalkeld: now that you've done it, what do you think of the idea? | 23:13 |
| asalkeld | documenting the yaql will be an issue | 23:15 |
| asalkeld | one option is to have it as an option at the end of get_attr | 23:16 |
| stevebaker | yaql really needs some auto-generated reference cods | 23:16 |
| stevebaker | docs | 23:16 |
| asalkeld | so either {get_attr: [normal, stuff, extra]} OR {get_attr: [normal, stuff, "yaql expression"]} | 23:17 |
| asalkeld | yaql is really good at selecting items out of json | 23:17 |
| asalkeld | i'll leave it out there for a bit, and see what people think | 23:18 |
| stevebaker | ok | 23:19 |
| kfox1111 | whats the status of conditionals in heat? going to be able to do it in liberty? | 23:19 |
| stevebaker | asalkeld: evil idea: implement yaql extensions which evaluate heat intrinsic functions inside yaql | 23:20 |
| * kfox1111 reads up a few lines | 23:20 | |
| kfox1111 | nice. :) | 23:20 |
| asalkeld | kfox1111: what do you really want? | 23:22 |
| stevebaker | kfox1111: tripleo has come up with an approach using environment resource types so you can choose a stack resource which might create resources, or nothing. https://github.com/openstack/tripleo-heat-templates/blob/master/network/ports/noop.yaml https://github.com/openstack/tripleo-heat-templates/blob/master/network/ports/vip.yaml | 23:23 |
| asalkeld | conditional resources/variables? | 23:23 |
| kfox1111 | heh. what I want... The ability to write one template that takes in paramaters for configuration rather then needing to fork the template and make specific versions. | 23:23 |
| asalkeld | kfox1111: ok, so be a bit more explicit | 23:24 |
| asalkeld | turn on/off resources | 23:24 |
| asalkeld | or change values? | 23:24 |
| kfox1111 | like, one template that works with nova-network and neutron based on paramaters. | 23:24 |
| asalkeld | so resources | 23:24 |
| kfox1111 | or the ability to pass an optional floating ip and have it used if passed. | 23:24 |
| kfox1111 | or, here's a wrinkle. | 23:24 |
| kfox1111 | neutron port allows specifying security groups. | 23:25 |
| asalkeld | stevebaker: we could totally change to yaql IF we didn't have implicit dependancies | 23:25 |
| kfox1111 | specifying a security group of ["default"] is different then not specifying anything. | 23:25 |
| kfox1111 | some way of optionally dropping out a paramater to a resource entirely. | 23:25 |
| stevebaker | asalkeld: the yaql would need to do its own dependency evaluation, which could be the hard part | 23:26 |
| kfox1111 | or lastly, some way to make paramaters required or optional depending on another paramater. | 23:26 |
| asalkeld | kfox1111: keep it coming, i'll see if i can implement any of those with yaql | 23:26 |
| asalkeld | stevebaker: nope, i don't think it can | 23:26 |
| asalkeld | so we could force people to put depends_on in their resources | 23:27 |
| asalkeld | but that is pain for users | 23:27 |
| kfox1111 | Id rather have to specify dependencies manually if it ment I can do conditionals. | 23:27 |
| kfox1111 | maintaining seperate templates is painful. :/ | 23:28 |
| stevebaker | kfox1111: we feel your pain, its just that nobody has stepped up to implement it yet | 23:30 |
| kfox1111 | it would be nice to have a conditional that allows easily switching one software deployment for another depending on what type of image it is (ubuntu, centos, etc) | 23:30 |
| asalkeld | kfox1111: is almost seems like it would be better to have the logic in the environment | 23:32 |
| stevebaker | the yaql function might be a suitable way to build the conditional expression, just need to figure out how to do the conditional parts (maybe the yaql function could gain a if/elif/else arguments) | 23:32 |
| kfox1111 | one of the advantages of params, is its a nice contract between user and tempate writer. | 23:34 |
| kfox1111 | horizon gives you a nice way for users to answer a few questions (paramaters) and out pops a working system. | 23:34 |
| kfox1111 | environments are not so easy to craft. | 23:34 |
| stevebaker | yes, environments are powerful and complicated | 23:35 |
| kfox1111 | for the app catalog use case, I'd really like to not ever have to exaplain to a user how to use an environment. :/ | 23:35 |
| kfox1111 | at least by default. if conditionals are supported, there could be a form paramater that says "pull config from environment" or something. | 23:36 |
| asalkeld | na | 23:37 |
| kfox1111 | stevebaker: https://www.youtube.com/watch?v=N3onNfjf4uY | 23:37 |
| asalkeld | brb, breakfast | 23:37 |
| stevebaker | conditional templates would mean the end of our static dependency representation, which I think we could only consider once convergence is in | 23:37 |
| kfox1111 | gota prototype going where you can browse the app catalog, then start up a heat template right from the ui. | 23:37 |
| kfox1111 | so the user's work flow is basically, pick a web app, hit launch, fill out a form for config, and get a working app. :) | 23:38 |
| stevebaker | kfox1111: nice | 23:38 |
| *** Qiming has joined #heat | 23:39 | |
| kfox1111 | but getting users to contribute truely generic templates to the catalog's going to be hard if they end up being very specific like most end up being without conditionals. :/ | 23:39 |
| stevebaker | kfox1111: selecting one or more environment files could work in that flow too though | 23:39 |
| kfox1111 | hmm... so pre can some environment files and make those available as options too? | 23:40 |
| *** tochi has joined #heat | 23:40 | |
| stevebaker | kfox1111: yes, the app catalog metadata should describe environment files too, and how they can be combined | 23:41 |
| kfox1111 | hmm.... | 23:42 |
| kfox1111 | there only is ever one root environment file though? | 23:42 |
| kfox1111 | (the horzion ui seems to imply that) | 23:42 |
| stevebaker | kfox1111: horizon is lagging the cli/api. Multiple environments are overlayed on each other in order. | 23:43 |
| kfox1111 | so you could have a list of possible environemnts, and only some are valid with each other? hmm... | 23:44 |
| stevebaker | kfox1111: tripleo/tuskar are dealing with the exact same issue (introspecting templates and building a ui). You should read the thread [openstack-dev] [TripleO][Heat] Tuskar v. Heat responsibilities | 23:44 |
| stevebaker | kfox1111: shardy has already started with some proposals | 23:44 |
| stevebaker | like nested validation | 23:44 |
| kfox1111 | well, for the plugin, all we are doing is calling into the existing heat wizard, prepopulating the heat_url. we could prepopulate the env_url pretty easily, but it would be hard to populate multiple if the ui doesn't support it. | 23:44 |
| kfox1111 | I've been skimming that thread, but not digging in closely. I guess I'll go back and have a closer look. | 23:45 |
| stevebaker | yes, horizon will need an enhancement. You could still do most things with a single environment though | 23:45 |
| kfox1111 | I guess the other option is I can pass a bunch of include's if thats possible through. | 23:45 |
| *** dims has joined #heat | 23:45 | |
| *** dims has quit IRC | 23:46 | |
| kfox1111 | it still feels kind of odd to have the environment and user form split though. | 23:46 |
| kfox1111 | you ask the user to customize the template set, then ask them a bunch of other questions. it would be nice to be able to do it all at once. | 23:47 |
| kfox1111 | but, it does have the interesting ramification that the app catalog running on the local cloud knows if, say, neutron is supported, | 23:47 |
| kfox1111 | and can selectively add a neutron environment file to the app so that the user doesn't have to know the details. | 23:47 |
| kfox1111 | at the summit, env include was talked about. is that going through in liberty? | 23:49 |
| stevebaker | yes, which a bp like this could help with https://review.openstack.org/#/c/196656/3/specs/liberty/resource-type-mapping.rst,cm | 23:49 |
| stevebaker | I'm not aware of an env include spec yet | 23:50 |
| *** jruano has joined #heat | 23:50 | |
| kfox1111 | looking at the bp. | 23:51 |
| kfox1111 | bummer. cause if it was supported, I could just build up a new env file dynamically which was just a bunch of includes, and then pass the whole thing as an env text blob to the horizon dialog. | 23:52 |
| stevebaker | kfox1111: my mindset is that heat templates describe a very broad architecture of the cloud app, and environments state the specific implementations | 23:53 |
| stevebaker | kfox1111: I'd like to implement it, but there is not much left after PTL and tripleo duties | 23:55 |
| kfox1111 | yeah. in my mindset, a heat template is the instructions for deploying a web scale application. the user only cares about answering a few questions to get a working thing. env's take coder knowhow, and therefore tend to break that. :/ | 23:55 |
| asalkeld | lol interface matching | 23:55 |
| kfox1111 | so in your mindset mixed with mine, the template writer should be providing the env's? | 23:56 |
| kfox1111 | and the paramaters are the final config? | 23:57 |
| *** htruta_ has joined #heat | 23:57 | |
| asalkeld | kfox1111: parameters are a part of the environment | 23:58 |
| asalkeld | literally | 23:58 |
| asalkeld | environment = parameters + resource_registry | 23:58 |
| kfox1111 | but not exposed via form in horizon or the heat cli. | 23:58 |
| kfox1111 | which is a thing that non computer scientists can understand. | 23:59 |
| kfox1111 | yaml, not so much. | 23:59 |
| stevebaker | kfox1111: yes, the template writer also writes one or more environments. | 23:59 |
| kfox1111 | interesting. so under that model, it does make sense to put them in the catalog along with the template it self. | 23:59 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!