| *** Qiming has joined #heat | 00:01 | |
| *** gokrokve has quit IRC | 00:03 | |
| *** blomquisg has joined #heat | 00:05 | |
| *** nati_ueno has quit IRC | 00:05 | |
| *** Qiming has quit IRC | 00:14 | |
| *** gokrokve has joined #heat | 00:30 | |
| *** gokrokve has quit IRC | 00:34 | |
| *** nati_ueno has joined #heat | 00:36 | |
| *** rpothier_ has joined #heat | 00:36 | |
| *** zhiyan_ is now known as zhiyan | 00:37 | |
| *** rpothier has quit IRC | 00:40 | |
| *** nati_ueno has quit IRC | 00:40 | |
| *** rpothier_ has quit IRC | 00:45 | |
| *** rpothier__ has joined #heat | 00:45 | |
| *** randallburt has joined #heat | 00:49 | |
| *** randallburt has quit IRC | 00:50 | |
| *** randallburt has joined #heat | 00:51 | |
| *** lindsayk has quit IRC | 00:53 | |
| lifeless | randallburt: hi; SpamapS radix and I talked without you as we couldn't find you at the time. | 00:54 |
|---|---|---|
| lifeless | randallburt: I've sent mail to the list, and would be delighted to do high bandwidth chat at a mutually convenient time :) | 00:55 |
| randallburt | lifeless: no worries, I tried to ping SpamapS via hangouts on my phone at the time; I just got bogged down in other meetings. sorry about that. | 00:55 |
| lifeless | randallburt: no worries | 00:55 |
| lifeless | randallburt: hopefully the etherpad is appealing :) | 00:55 |
| randallburt | :D | 00:55 |
| randallburt | I read "appalling" at first. | 00:56 |
| openstackgerrit | Dmitry Borodaenko proposed a change to openstack/heat: Ignore nova limits set to '-1' https://review.openstack.org/89389 | 00:57 |
| *** lindsayk has joined #heat | 00:57 | |
| *** Darnoth has quit IRC | 00:58 | |
| *** zhiyan has quit IRC | 00:58 | |
| *** gokrokve has joined #heat | 00:59 | |
| openstackgerrit | Dmitry Borodaenko proposed a change to openstack/heat: Ignore nova limits set to '-1' https://review.openstack.org/89389 | 00:59 |
| *** zhiyan has joined #heat | 01:00 | |
| *** harlowja has joined #heat | 01:00 | |
| randallburt | lifeless: my fav: "- run each individual convergence step via taskflow via a distributed set of workers". Now that I know what you mean by "taskflow" I may convince kebray to let me chip in on that if I can get my Glance work sorted too. Its been a big wish of mine for a while, but no real time to devote to it. | 01:01 |
| *** annegentle has quit IRC | 01:02 | |
| *** IlyaE has joined #heat | 01:03 | |
| *** gokrokve has quit IRC | 01:04 | |
| *** nati_ueno has joined #heat | 01:10 | |
| *** IlyaE has quit IRC | 01:15 | |
| lifeless | randallburt: cool | 01:15 |
| *** TravT has quit IRC | 01:15 | |
| *** Qiming has joined #heat | 01:22 | |
| *** fandi has quit IRC | 01:27 | |
| *** nati_ueno has quit IRC | 01:28 | |
| *** masahito has joined #heat | 01:33 | |
| masahito | to disucuss BPs should I attend weekly heat meeting and propose the BPs as topic? | 01:34 |
| *** nosnos has joined #heat | 01:36 | |
| *** asalkeld has quit IRC | 01:41 | |
| openstackgerrit | OpenStack Proposal Bot proposed a change to openstack/heat: Updated from global requirements https://review.openstack.org/89232 | 01:41 |
| masahito | umm... noone is in here... | 01:46 |
| *** asalkeld has joined #heat | 01:53 | |
| sdake_ | masahito just file a blueprint | 01:56 |
| sdake_ | we dont typically discuss bluepreints in our weekly meeting unless they are highly controversial | 01:56 |
| *** gokrokve has joined #heat | 01:59 | |
| *** lindsayk has quit IRC | 02:00 | |
| *** gokrokve has quit IRC | 02:00 | |
| *** gokrokve has joined #heat | 02:01 | |
| *** jrist has quit IRC | 02:02 | |
| *** IlyaE has joined #heat | 02:04 | |
| *** gokrokve has quit IRC | 02:05 | |
| masahito | sdake_: thanks for response | 02:06 |
| *** IlyaE has quit IRC | 02:06 | |
| *** jrist has joined #heat | 02:10 | |
| masahito | I've registered 3 BPs, stack-repairing, property-check and elastic-stack. | 02:13 |
| masahito | Will these BPs be reviewed by heat review team in the futrue? | 02:15 |
| lifeless | masahito: it sounds like they will probably overlap with the fairly large refactoring we've just proposed on the list | 02:25 |
| *** nati_ueno has joined #heat | 02:26 | |
| *** alexheneveld has quit IRC | 02:33 | |
| masahito | lifeless: that's means we've already deceided to refactoring heat for Juno release, haven't we. | 02:41 |
| lifeless | masahito: decided? No. Getting substantial buy-in that its needed? yes :) | 02:42 |
| masahito | For collaboration with Mistral or implementing stack-convergence. | 02:42 |
| lifeless | mistral was discussed this morning in the weekly meeting | 02:42 |
| lifeless | stack convergence I hope will be just the way heat does things (vs a special command or something) | 02:43 |
| *** alexpilotti has quit IRC | 02:49 | |
| masahito | lifeless: Oh. I misunderstood large refactoring has been already propoesed. sorry : -) | 02:50 |
| masahito | I try to watch the weekly meeting. | 02:50 |
| masahito | Thanks a lot. | 02:54 |
| *** andersonvom has joined #heat | 02:55 | |
| *** onorua has joined #heat | 02:55 | |
| *** gokrokve has joined #heat | 02:59 | |
| sdake_ | lifeless I dont think refactor means what you think it means :) | 03:00 |
| lifeless | sdake_: incrementally improving the design via a series of correctness preserving changes? | 03:00 |
| sdake_ | Code refactoring is the process of restructuring existing computer code – changing the factoring – without changing its external behavior. Refactoring improves nonfunctional attributes of the software. Advantages include improved code readability and reduced complexity to improve source code maintainability, and create a more expressive internal architecture or object model to improve extensibility. | 03:01 |
| lifeless | sdake_: wikipedia? I think the definition in the refactoring book is closer to whats in my head. Not to worry :) | 03:02 |
| sdake_ | i think the term your looking for is ground-up rewrite :) | 03:02 |
| sdake_ | i have a hard time calculating how we could get from where we are today to how you want the code to behave in an incremental evolutionary way | 03:04 |
| sdake_ | its more like congress - throw em all out :) | 03:04 |
| lifeless | sdake_: the transition plan section has a suggestion on such a path | 03:06 |
| randallburt | sdake_: a belated lol. | 03:08 |
| sdake_ | update has been rewritten 5+ times and still isn't correct | 03:08 |
| *** harlowja is now known as harlowja_away | 03:09 | |
| sdake_ | it isn't because the architecture is unsound, its because new problems are discovered that were not understood originally | 03:09 |
| sdake_ | if the end goal is 100k resource scale, wouldn't an incremental change approach be to see if update could be made to work at that scale? | 03:10 |
| randallburt | sdake_: so the concern here is that because this proposal implies essentially zero difference between a create and an update that now both won't be correct? | 03:11 |
| * stevebaker is back | 03:11 | |
| *** IlyaE has joined #heat | 03:12 | |
| sdake_ | o/ stevebaker | 03:13 |
| lifeless | sdake_: the basic operation model falls apart when dealing with 40 node clusters | 03:16 |
| lifeless | sdake_: you are right that we can do little tweaks to change things without changing the core, but there doesn't seem like much reason to believe the current approach can cope with e.g. autoscaling a 40 node cluster (the requirement to hit STACK_READY before submitting a new update each time) | 03:16 |
| *** samstav has quit IRC | 03:17 | |
| sdake_ | when I spoke with zane about refactoring update to work he popped out a 3 month schedule | 03:19 |
| sdake_ | I wouldn't call that a little tweak ;) | 03:19 |
| asalkeld | sdake_ I think bits can be done here with no interuption | 03:19 |
| asalkeld | (the observer) | 03:20 |
| asalkeld | and probably as you go on developing it should be easy enough to move to this functionality | 03:21 |
| *** IlyaE has quit IRC | 03:22 | |
| randallburt | we may be able to even keep most of the taskrunner interface intact (for example) for minimal impact on the current resource implementations. They'd become shims for the distributed tasking perhaps, but its still incremental. | 03:23 |
| sdake_ | lifeless is the basis of the argument that one process cannot handle autoscaling in a way that meets our goals? | 03:23 |
| randallburt | sdake_: I would also add scaling to servicing large numbers of tenants all with stacks of various sizes, complexities and orchestration footprints. | 03:25 |
| lifeless | sdake_: I can't quite parse that question. Number of processes isn't a key thing here. (beyond getting to being highly available, of course) | 03:26 |
| sdake_ | randallburt you mean the work jasond wrapped up doesn't scale to your targets | 03:26 |
| *** cmyster has joined #heat | 03:27 | |
| *** cmyster has joined #heat | 03:27 | |
| randallburt | sdake_: so far, so good, but there will be a definite point where the db locking will cause problems as we have to scale up engine nodes. | 03:27 |
| cmyster | morning | 03:27 |
| sdake_ | one process is responsible for autoscaling - at some upper bound that process hits a limit | 03:27 |
| randallburt | sdake_: but as of now our traffic isn't terribly high | 03:27 |
| sdake_ | my question is - was your assertion that this upper limit is 40 vms? | 03:28 |
| sdake_ | horizontal scaling originally identified in our architecture was focused around a DHT model - not database locking | 03:29 |
| sdake_ | DHT has no scale limit | 03:29 |
| sdake_ | but that implementation, after 2 years, was never delivered because it fit into warren buffet's inbox labled "too hard" | 03:30 |
| randallburt | sdake_: plus someone probably brought up zookeeper and people lost it. | 03:30 |
| asalkeld | :-) | 03:31 |
| sdake_ | dont even get me started on zookeeper | 03:31 |
| asalkeld | well it would be good if we can just not need locking at all | 03:31 |
| sdake_ | agree the answer to that is dht as originally specified in the architecture | 03:32 |
| lifeless | so I can certainly see a DHT sitting in this model too | 03:32 |
| sdake_ | yes i read the proposal | 03:33 |
| lifeless | :) | 03:33 |
| *** arbylee has joined #heat | 03:34 | |
| sdake_ | point being dht was specified in the architecture - database locking was implemented - the correct answer to unlimited horizontal scaling is dht not database locking | 03:34 |
| lifeless | sdake_: a DHT alone doesn't get you one-and-only-one agent operating on a thing (because DHT resizing isn't atomic in most DHTs - but DHT + consensus can get you that) | 03:35 |
| lifeless | sdake_: that leaves the callgraph implementation though as a big remaining source of user visible pain | 03:35 |
| sdake_ | atomic dht membership is likely one reason why dht was never implemented as the scaleout solution | 03:37 |
| lifeless | sdake_: we're currently going through the business case process to fund this project; the exact implementation is entirely up to heat-core to dictate - what SpamapS and I are doing is trying to kick start a discussion and have a feasible design that isn't disruptive to deliver | 03:37 |
| sdake_ | if you can protect the correctness of heat, you would have my support | 03:38 |
| lifeless | sdake_: our intent is to have ~10 folk working on this (devs and test folk, not counting project mgmt folk etc) | 03:38 |
| sdake_ | I'm not convinced the correctness of heat could be protected | 03:38 |
| lifeless | so we can tackle a reasonable sized chunk of work | 03:38 |
| sdake_ | yup i heard the staffing ideas - those folks will have to come up to speed on the code base | 03:40 |
| sdake_ | i typically find someone full time takes 6-12 mos if they are highly comptent | 03:40 |
| sdake_ | (to come up to speed) | 03:41 |
| asalkeld | sdake_ just change your nick to "getoffmylawn" ;) | 03:42 |
| sdake_ | and take your damn dog with you | 03:42 |
| cmyster | teehee | 03:42 |
| asalkeld | lol | 03:42 |
| lifeless | sdake_: yeah, I know - SpamapS is likely going to regret getting his wish of more folk hacking on heat :) | 03:43 |
| lifeless | sdake_: can you articulate the correctness concerns you have? | 03:43 |
| sdake_ | if at each step along the change sets, heat continues to be deployable from trunk | 03:44 |
| lifeless | sdake_: I mean, some things like 'stack state -> _FAILED if any resource can't be provisioned' are things we *want to change*, but I presume you don't consider that an existing element of correctness | 03:44 |
| lifeless | sdake_: oh hell yes it has to be. No broken trunk ever. NONONO. | 03:44 |
| sdake_ | no that is incorrect | 03:44 |
| sdake_ | (incorrect re stack state failed) | 03:44 |
| sdake_ | just like update fails - whole stack is busted - incorrect | 03:45 |
| lifeless | sdake_: so - trunk status - we're driving this from the tripleo team and the HP cloud team - both of whom are CD focused and want a stable reliable trunk at any point in time | 03:46 |
| sdake_ | the code as is doesn't operate correctly as we would expect it to do so | 03:46 |
| *** ramishra has joined #heat | 03:46 | |
| lifeless | asalkeld: questions for you inline | 03:46 |
| sdake_ | my general take is I'd like to fix the things that are incorrect and make them behave correctly | 03:47 |
| sdake_ | but I'm just one heat core guy of many :) | 03:47 |
| sdake_ | i think changing the code to something more complex is likely to lead to less correctness | 03:48 |
| sdake_ | but just a hunch | 03:48 |
| lifeless | I certainly agree - complexity -> bugs. | 03:49 |
| lifeless | have you seen 'simple made easy' ? | 03:49 |
| sdake_ | doesn't ring a bell | 03:49 |
| asalkeld | or: complexity for dummies | 03:49 |
| lifeless | http://www.infoq.com/presentations/Simple-Made-Easy-QCon-London-2012 | 03:49 |
| lifeless | so, how would you handle allowing new stack updates to be requested before the prior one has reached STACK_READY ? | 03:50 |
| lifeless | without the key changed for that - moving from its-a-call-stack to its-a-graph-convergence-problem ? | 03:51 |
| sdake_ | 9pm at night been rolling since 6am I hope you dont expect a design to magically pop out of my head :) | 03:51 |
| lifeless | not at all | 03:51 |
| lifeless | just I don't want to fall into the trap of solving only-some-issues which can happen when we don't look at the whole thing | 03:52 |
| sdake_ | food is here - i'm off for the night | 03:52 |
| lifeless | ciao | 03:52 |
| asalkeld | lifeless, dht is a good idea imo | 03:52 |
| sdake_ | dht was the original design - never implemented | 03:52 |
| sdake_ | have to ask the question why | 03:53 |
| stevebaker | lifeless, SpamapS: hey, os-apply-config hasn' | 03:53 |
| lifeless | stevebaker: hasn't ? | 03:53 |
| *** vinsh is now known as vinsh_away | 03:53 | |
| stevebaker | t made it to pypi or tarballs.os (release 0.1.15) | 03:53 |
| sdake_ | night | 03:54 |
| cmyster | nn sdague | 03:54 |
| cmyster | NO | 03:54 |
| cmyster | that tab key I tell you... | 03:54 |
| *** nati_ueno has quit IRC | 03:55 | |
| lifeless | asalkeld: so dependencies | 03:57 |
| asalkeld | lifeless, I can see we are going to need dht | 03:57 |
| asalkeld | to prevent flap | 03:57 |
| randallburt | sdake_: re Why not DHT - no one brought it up to jasond AFAIK and he wasn't working on Heat 2 years ago ;) | 03:57 |
| asalkeld | in the case you were going through | 03:57 |
| asalkeld | # of jobs can't get out of hand | 03:58 |
| lifeless | asalkeld: so think about the events happening here | 03:59 |
| asalkeld | else delete too many, then create too many | 03:59 |
| lifeless | asalkeld: I don't think hysteresis implies a DHT | 03:59 |
| asalkeld | lifeless, no - but makes it easier to track work on a particular resource | 04:00 |
| asalkeld | hash the resource_id | 04:00 |
| asalkeld | and you can monitor what those jobs on that resource are doing | 04:00 |
| lifeless | asalkeld: thats not a DHT, but sure :) (its a hash ring) | 04:00 |
| lifeless | in fact, I don't think a DHT gets you hysteresis in and of itself | 04:01 |
| lifeless | and you'd need some gnarly green-thread-introspection stuff to prevent concurrency | 04:01 |
| asalkeld | agree | 04:02 |
| lifeless | so I'd rather not complect these things - hysteresis - things working on the scaling group should implement hysteresis and lock each other out. | 04:02 |
| asalkeld | well it should just be another nested stack | 04:03 |
| lifeless | asalkeld: as far as dependencies go, what I think you mean is | 04:03 |
| lifeless | some things need to reach when a child comes or goes | 04:03 |
| lifeless | e.g. when a launchconfig goes complete you want to start the work on the instance | 04:04 |
| asalkeld | well I was thinking of all the yields and how each big resource has potentially many stages | 04:05 |
| lifeless | asalkeld: so a nested stack thats being replicated? Sure, but the # of such stacks and the last direction of change and size of change is what you need for hysteresis | 04:05 |
| lifeless | asalkeld: so each yield point is basically going to become a separate action | 04:05 |
| asalkeld | how are the stages broken up | 04:05 |
| asalkeld | yes | 04:06 |
| asalkeld | just saying that need some tought | 04:06 |
| asalkeld | thought | 04:06 |
| asalkeld | and we need to be able to package that well | 04:06 |
| lifeless | so the question in the strawman up there is... | 04:06 |
| lifeless | what event should the next stage be reacting too - how will the diff-and-create-actions code know when to run next | 04:06 |
| asalkeld | yes, since it's internal knowledge (what stage of the resource creation is up to) | 04:07 |
| lifeless | there are I think two things that I'd like to have here - one generic graph diff that looks at desired vs actual (and neds to be scaling aware to know to use a desired template on a sub stack etc) | 04:08 |
| *** gokrokve has quit IRC | 04:08 | |
| lifeless | and secondly, resource specific knowledge that plugins supply that says 'ok, the resource I have here is incomplete or wrong in X way, so I need to do Y to adjust it' | 04:08 |
| asalkeld | could just be "in progress" (i.e. needs to be run again) | 04:09 |
| lifeless | then the generic stuff would run until the broad shape is correct and then the resource specific stuff would kick in to do the actual local work | 04:09 |
| lifeless | as an example making a server with a neutron port | 04:09 |
| lifeless | the graph diff would see server depends on port and nothing exists, so a) make port and return (make port is then the (B) resource specific bit) | 04:10 |
| lifeless | when the port comes alive the parent gets the event, which diffs again and sees the port is there but not the server, so hands off to the (B) resource specific bit for servers. | 04:10 |
| asalkeld | well we will need resources to be smarter | 04:11 |
| asalkeld | so they can figure out what needs to be done | 04:11 |
| lifeless | when the server comes alive, its parent gets a graph change event, the generic diff code would run to get local constraints, then back into the resource specific stuff for whatever resource the parent was | 04:12 |
| asalkeld | or, we go the other way an say a resource can only do one thing, and you must use nested stacks to compose | 04:12 |
| lifeless | internalwise I'd say a nested stack is what a complex resource is | 04:12 |
| lifeless | not sure that users should see that aspect of it but that seems likely to be hidable | 04:13 |
| asalkeld | it would push our nested stack capablitiy | 04:13 |
| lifeless | ok so lets be specific | 04:16 |
| lifeless | there needs to be an ability for a given resource to diff current state vs desired state | 04:16 |
| lifeless | where that resource might be a hand specified one, or a member of a scale group | 04:16 |
| lifeless | the more we generalise that the less diff code we need to write | 04:16 |
| *** harlowja_away is now known as harlowja | 04:18 | |
| asalkeld | it does just sound like a new stack | 04:18 |
| lifeless | it needs to be efficient - local and frugal on data requirements | 04:20 |
| lifeless | (no diffing all the subchildren on every run!) | 04:21 |
| lifeless | that might be a generation checking-and-signoff thing | 04:21 |
| lifeless | there are a few ways to make incremental graph diffs fast | 04:21 |
| cmyster | guys since not too many people are only and this might be important for later, can you take this to a thread of sorts ? | 04:22 |
| asalkeld | cmyster, you are welcome to interupt | 04:23 |
| asalkeld | we can put this in an etherpad at some point | 04:23 |
| cmyster | can't, got other things to worry about before my boss comes, but would love to read about it later and might comment on it | 04:24 |
| cmyster | from a QE point of view | 04:24 |
| lifeless | it is a thread :) | 04:24 |
| lifeless | theres the etherpad | 04:24 |
| lifeless | and the mailing list | 04:24 |
| lifeless | this is just a breakout session | 04:24 |
| *** randallburt has quit IRC | 04:24 | |
| cmyster | k | 04:25 |
| asalkeld | lifeless, this seems like uni (I did elec. eng process control) inputs (template), outputs (observer state), feedback (actioner/differ) | 04:28 |
| asalkeld | drive output to look like desired input | 04:29 |
| *** blomquisg has quit IRC | 04:29 | |
| *** asalkeld has quit IRC | 04:35 | |
| *** arbylee has quit IRC | 04:39 | |
| *** lipinski has quit IRC | 04:40 | |
| *** blomquisg has joined #heat | 04:42 | |
| *** asalkeld has joined #heat | 04:51 | |
| *** nati_ueno has joined #heat | 04:52 | |
| *** chandan_kumar has joined #heat | 05:00 | |
| *** blomquisg has quit IRC | 05:05 | |
| *** gokrokve has joined #heat | 05:07 | |
| *** rwsu has quit IRC | 05:07 | |
| *** nati_ueno has quit IRC | 05:07 | |
| *** nosnos has quit IRC | 05:08 | |
| *** blomquisg has joined #heat | 05:09 | |
| *** gokrokve has quit IRC | 05:11 | |
| *** IlyaE has joined #heat | 05:11 | |
| lifeless | asalkeld: it is indeed | 05:12 |
| openstackgerrit | Steve Baker proposed a change to openstack/heat: Do not initialise stack_user password https://review.openstack.org/89999 | 05:19 |
| openstackgerrit | Steve Baker proposed a change to openstack/heat: Refactor DB resource fetching from Resource to Stack https://review.openstack.org/90000 | 05:19 |
| openstackgerrit | Steve Baker proposed a change to openstack/heat: resource_get_all_by_stack returns a dict https://review.openstack.org/90001 | 05:19 |
| openstackgerrit | Steve Baker proposed a change to openstack/heat: Fetch all db resources in one query https://review.openstack.org/90002 | 05:19 |
| openstackgerrit | Steve Baker proposed a change to openstack/heat: Do not query database for every metadata_get https://review.openstack.org/89737 | 05:19 |
| openstackgerrit | Steve Baker proposed a change to openstack/heat: Use resource methods for metadata get/set https://review.openstack.org/89736 | 05:19 |
| stevebaker | lifeless: if the above check passes, up to https://review.openstack.org/#/c/90002/ would be worth testing in yr cloud | 05:21 |
| stevebaker | SpamapS: when you're about, can you check why oac 0.1.17 didn't make it to pypi? thanks | 05:22 |
| *** e0ne has joined #heat | 05:22 | |
| *** daneyon has quit IRC | 05:23 | |
| lifeless | stevebaker: he only did ocollectc AFAIK | 05:23 |
| *** rwsu has joined #heat | 05:23 | |
| *** onorua has quit IRC | 05:26 | |
| *** e0ne has quit IRC | 05:26 | |
| *** nkhare has joined #heat | 05:27 | |
| *** wwallnrr__ has quit IRC | 05:27 | |
| *** nati_ueno has joined #heat | 05:33 | |
| *** nosnos has joined #heat | 05:35 | |
| *** tspatzier has joined #heat | 05:44 | |
| *** renlt has joined #heat | 05:44 | |
| *** renlt has quit IRC | 05:45 | |
| *** renlt has joined #heat | 05:46 | |
| *** yogeshmehra has joined #heat | 05:47 | |
| *** Qiming has quit IRC | 05:48 | |
| *** Qiming has joined #heat | 05:49 | |
| *** nati_ueno has quit IRC | 05:58 | |
| *** tspatzier__ has joined #heat | 05:59 | |
| *** tspatzier has quit IRC | 06:02 | |
| *** tspatzier__ has quit IRC | 06:05 | |
| *** nati_ueno has joined #heat | 06:05 | |
| *** tspatzier has joined #heat | 06:07 | |
| *** gokrokve has joined #heat | 06:07 | |
| openstackgerrit | OpenStack Proposal Bot proposed a change to openstack/heat: Imported Translations from Transifex https://review.openstack.org/89750 | 06:09 |
| *** yogeshmehra has quit IRC | 06:11 | |
| *** gokrokve has quit IRC | 06:12 | |
| *** IlyaE has quit IRC | 06:13 | |
| *** jprovazn has joined #heat | 06:23 | |
| *** IlyaE has joined #heat | 06:23 | |
| *** saju_m has joined #heat | 06:23 | |
| *** harlowja is now known as harlowja_away | 06:30 | |
| *** IlyaE has quit IRC | 06:37 | |
| therve | Good morning! | 06:37 |
| asalkeld | yo therve | 06:40 |
| *** yogeshmehra has joined #heat | 06:41 | |
| *** shakamunyi has quit IRC | 06:42 | |
| cmyster | morning | 06:45 |
| *** ramishra has quit IRC | 06:45 | |
| *** ramishra has joined #heat | 06:46 | |
| openstackgerrit | Sushil Kumar proposed a change to openstack/heat: Restores Nova API for volume attach and detach https://review.openstack.org/89796 | 06:49 |
| *** blomquisg has quit IRC | 06:50 | |
| *** ifarkas has joined #heat | 06:59 | |
| *** blomquisg has joined #heat | 07:05 | |
| skraynev | Good morning all ;) | 07:07 |
| *** shakamunyi has joined #heat | 07:08 | |
| *** gokrokve has joined #heat | 07:08 | |
| *** lsmola has joined #heat | 07:09 | |
| cmyster | morning | 07:11 |
| lifeless | therve: o/ | 07:11 |
| *** e0ne has joined #heat | 07:11 | |
| *** shakamunyi has quit IRC | 07:12 | |
| *** gokrokve has quit IRC | 07:12 | |
| *** e0ne has quit IRC | 07:16 | |
| *** onorua has joined #heat | 07:16 | |
| therve | lifeless, Man where's that etherpad | 07:17 |
| therve | It sounds like stuff was discussed | 07:17 |
| *** e0ne has joined #heat | 07:17 | |
| openstackgerrit | Jun Jie Nan proposed a change to openstack/heat-templates: Add one example to show deploy sequence https://review.openstack.org/81757 | 07:18 |
| therve | Oh got the mail | 07:18 |
| *** sorantis has joined #heat | 07:18 | |
| *** sorantis has quit IRC | 07:19 | |
| lifeless | therve: stuff was :) | 07:19 |
| openstackgerrit | Jun Jie Nan proposed a change to openstack/heat-templates: Example template that performs copying of SSH keys https://review.openstack.org/83397 | 07:19 |
| lifeless | therve: typical lifeless crazy, of course | 07:19 |
| *** sorantis has joined #heat | 07:19 | |
| therve | Yeah I already saw your BP yesterday :) | 07:20 |
| sorantis | morning | 07:20 |
| *** ramishra has quit IRC | 07:24 | |
| therve | The plan is cute but super unrealistic regarding time | 07:25 |
| *** ifarkas has quit IRC | 07:25 | |
| *** ifarkas has joined #heat | 07:26 | |
| lifeless | therve: J? placeholder arguably | 07:26 |
| therve | lifeless, Okay | 07:26 |
| lifeless | therve: I'm thinking 6-12 month process to deliver it all, with a focused team just doing that | 07:26 |
| lifeless | some benefits will be felt earlier than others | 07:27 |
| therve | So I'm started looking a tiny bit of that plan | 07:28 |
| therve | Which is move to use notifications | 07:28 |
| therve | Instead of polling | 07:29 |
| lifeless | stevebaker: testing your patchset now | 07:29 |
| lifeless | therve: yeah, important transition | 07:29 |
| lifeless | therve: what do you think of the idea in that plan - of an abstraction layer to move everything to events ? | 07:29 |
| therve | I don't think it involves ceilometer though, we should plug into the nova notifications directly | 07:29 |
| *** lipinski has joined #heat | 07:30 | |
| therve | lifeless, Isn't event just another term for notification? | 07:30 |
| asalkeld | therve, one potential benefit to using ceilometer would be you could just setup alarms on state changes | 07:32 |
| asalkeld | and heat would not have to process that stream of notifications | 07:32 |
| *** sorantis has quit IRC | 07:33 | |
| asalkeld | on a large deployment I could imagine that is quite a burden | 07:33 |
| asalkeld | (processing large number of notifications) | 07:33 |
| therve | Maybe | 07:34 |
| therve | From a performance standpoint I'm not sure that's valid, because creating and receiving alarms is not super cheap | 07:36 |
| therve | I can see why separating the concerns sounds appealing, though | 07:36 |
| shardy | morning all | 07:37 |
| lifeless | therve: yes | 07:37 |
| lifeless | therve: I think ceilometer for things we don't get directly (e.g. load levels on a VM) makes a lot of sense | 07:38 |
| lifeless | therve: we don't want to reinvent ceilometer | 07:38 |
| therve | lifeless, Sure, but that's not the core of the problem | 07:38 |
| therve | states change is | 07:38 |
| therve | Ie "let me know when this server transition to ACTIVE/ERROR" | 07:38 |
| lifeless | therve: well, the core of the problem is only looking for that while provisioning, rather than all the time; polling is a symptom not a cause of that. | 07:43 |
| lifeless | therve: I think we're agreeing. BTW you didn't really answer 19:29 < lifeless> therve: what do you think of the idea in that plan - of an abstraction layer to move everything to events ? | 07:44 |
| therve | lifeless, I don't think I understood it | 07:44 |
| lifeless | therve: oh, also another data point - lots of APIs fail poorly - like having to call nova delete many times to make it actually delete a node | 07:44 |
| therve | Is it the thing talking about polling the DB? | 07:45 |
| lifeless | so we need some mix of stuff in the solution | 07:45 |
| lifeless | therve: the idea of the observer is that it does *whatever is needed* to keep an up to date model of the reality, whether thats subscribing to notifications, polling via an API, or $whatever | 07:45 |
| lifeless | therve: and then all the code behind it can be built on an event basis | 07:46 |
| cmyster | morning shardy | 07:47 |
| therve | That sounds nice in theory | 07:47 |
| *** akuznetsov has quit IRC | 07:51 | |
| *** akuznetsov has joined #heat | 07:52 | |
| *** sorantis has joined #heat | 07:55 | |
| *** mkollaro has joined #heat | 08:03 | |
| *** bvandenh has joined #heat | 08:03 | |
| *** shakamunyi has joined #heat | 08:09 | |
| *** gokrokve has joined #heat | 08:09 | |
| *** sorantis has quit IRC | 08:13 | |
| *** shakamunyi has quit IRC | 08:13 | |
| *** gokrokve has quit IRC | 08:13 | |
| *** sorantis has joined #heat | 08:14 | |
| *** e0ne has quit IRC | 08:15 | |
| lifeless | stevebaker: success with 30 nodes | 08:17 |
| *** e0ne has joined #heat | 08:17 | |
| *** nosnos has quit IRC | 08:18 | |
| *** derekh has joined #heat | 08:18 | |
| *** yogeshmehra has quit IRC | 08:19 | |
| *** jistr has joined #heat | 08:21 | |
| *** julienvey has joined #heat | 08:22 | |
| *** saju_m has quit IRC | 08:35 | |
| *** alexheneveld has joined #heat | 08:41 | |
| *** nati_ueno has quit IRC | 08:46 | |
| *** alexheneveld has quit IRC | 08:48 | |
| *** e0ne_ has joined #heat | 08:48 | |
| *** e0ne has quit IRC | 08:51 | |
| *** pas-ha has joined #heat | 08:52 | |
| openstackgerrit | Dimitri Mazmanov proposed a change to openstack/heat: Add a Nova Flavor resource. https://review.openstack.org/90029 | 08:54 |
| openstackgerrit | Dimitri Mazmanov proposed a change to openstack/heat: Add a Nova Flavor resource. https://review.openstack.org/90029 | 08:57 |
| *** saju_m has joined #heat | 09:01 | |
| openstackgerrit | Dimitri Mazmanov proposed a change to openstack/heat: Add a Nova Flavor resource. https://review.openstack.org/90029 | 09:03 |
| *** renlt has quit IRC | 09:09 | |
| *** shakamunyi has joined #heat | 09:09 | |
| *** gokrokve has joined #heat | 09:10 | |
| *** shakamunyi has quit IRC | 09:14 | |
| *** gokrokve has quit IRC | 09:14 | |
| *** denis_makogon has joined #heat | 09:21 | |
| *** cdent has joined #heat | 09:26 | |
| *** zhiyan is now known as zhiyan_ | 09:32 | |
| *** jprovazn has quit IRC | 09:36 | |
| *** saju_m has quit IRC | 09:36 | |
| *** saju_m has joined #heat | 09:38 | |
| *** alexheneveld has joined #heat | 09:42 | |
| *** bvandenh has quit IRC | 09:45 | |
| openstackgerrit | Dimitri Mazmanov proposed a change to openstack/heat: Add a Nova Flavor resource. https://review.openstack.org/90029 | 09:45 |
| *** bvandenh has joined #heat | 09:45 | |
| *** blomquisg has quit IRC | 09:53 | |
| *** alexheneveld has quit IRC | 09:55 | |
| *** zhiyan_ is now known as zhiyan | 09:58 | |
| openstackgerrit | Dimitri Mazmanov proposed a change to openstack/heat: Add a Nova Flavor resource. https://review.openstack.org/90029 | 10:02 |
| *** blomquisg has joined #heat | 10:06 | |
| *** dims has quit IRC | 10:08 | |
| *** zhiyan is now known as zhiyan_ | 10:08 | |
| *** gokrokve has joined #heat | 10:11 | |
| *** jprovazn has joined #heat | 10:12 | |
| *** gokrokve has quit IRC | 10:15 | |
| *** nosnos has joined #heat | 10:15 | |
| *** dims has joined #heat | 10:19 | |
| *** e0ne_ has quit IRC | 10:20 | |
| *** Qiming has quit IRC | 10:26 | |
| *** sorantis has quit IRC | 10:34 | |
| *** blomquisg has quit IRC | 10:36 | |
| *** sorantis has joined #heat | 10:41 | |
| *** saju_m has quit IRC | 10:45 | |
| sorantis | therve, hi! got a minute? | 10:48 |
| therve | sorantis, Don't ask to ask :) | 10:49 |
| sorantis | ack :) | 10:49 |
| *** blomquisg has joined #heat | 10:49 | |
| sorantis | reading your comments now. Any reason why I should remove check_create_complete? | 10:50 |
| openstackgerrit | Sergey Kraynev proposed a change to openstack/heat: Allow empty sections in the yaml templates https://review.openstack.org/90058 | 11:04 |
| *** e0ne has joined #heat | 11:05 | |
| *** e0ne has quit IRC | 11:10 | |
| *** gokrokve has joined #heat | 11:11 | |
| *** e0ne has joined #heat | 11:12 | |
| *** blomquisg has quit IRC | 11:14 | |
| *** gokrokve has quit IRC | 11:16 | |
| therve | sorantis, Because your resource is created right away | 11:20 |
| therve | AFAIU check_create_complete is useless here | 11:20 |
| sorantis | I see | 11:20 |
| cmyster | oh right, this reminds me, | 11:20 |
| cmyster | shardy: did you see my commit ? | 11:21 |
| *** blomquisg has joined #heat | 11:28 | |
| *** julienve_ has joined #heat | 11:31 | |
| *** nkhare has quit IRC | 11:31 | |
| *** ramishra has joined #heat | 11:34 | |
| *** rpothier__ has quit IRC | 11:38 | |
| *** chandan_kumar has quit IRC | 11:45 | |
| *** pas-ha has quit IRC | 11:45 | |
| *** cdent has quit IRC | 11:46 | |
| *** Qiming has joined #heat | 11:48 | |
| *** blomquisg has quit IRC | 11:54 | |
| *** asalkeld has quit IRC | 11:56 | |
| *** shakamunyi has joined #heat | 11:57 | |
| *** achampion has quit IRC | 11:59 | |
| shardy | cmyster: You mean the software config review? | 12:00 |
| cmyster | oh hi, yes | 12:00 |
| shardy | cmyster: just looking at it now | 12:01 |
| *** jamie_h has joined #heat | 12:07 | |
| shardy | cmyster: I though you didn't write API tests :P | 12:07 |
| shardy | ;) | 12:07 |
| *** aweiteka has joined #heat | 12:08 | |
| cmyster | I don't but this is an exception. no time to write a scenario and you need to make sure it works | 12:08 |
| cmyster | I repeat myself. API means nothing from a QE POV | 12:08 |
| cmyster | 200 OK is not a valid answer from my POV etc etc... | 12:09 |
| *** erecio has joined #heat | 12:09 | |
| shardy | I see value in both test types | 12:10 |
| cmyster | there is, | 12:10 |
| cmyster | not saying there is no value. just not to me, remember the apple example ? | 12:10 |
| *** gokrokve has joined #heat | 12:12 | |
| shardy | I'm not going to argue it again, happy to see contributions which improve tempest coverage via whatever category :) | 12:12 |
| *** erecio has quit IRC | 12:13 | |
| shardy | cmyster: but FWIW my understanding is we're moving towards making the API tests things which can be done with a standard (e.g cirros) image, and the scenario tests more involved tests which require a bigger image containing agents etc, hence much much slower | 12:13 |
| shardy | cmyster: so the key value of API coverage is smoke tests which can realistically be done in the gate | 12:14 |
| shardy | if everything is a full-fat integration test in scenarios, we won't be able to gate on it because it will take hours to run | 12:14 |
| shardy | damn, I'm arguing it again, aren't I ;) | 12:14 |
| * shardy shuts up | 12:14 | |
| cmyster | I'm not arguing one bit :) you are correct obviously, but my reason to avoid it are a bit different | 12:14 |
| cmyster | arguing makes good code. | 12:15 |
| *** jdob has joined #heat | 12:16 | |
| *** gokrokve has quit IRC | 12:17 | |
| cmyster | long story shot, have I had time and could be dedicating 100% to this specific thing, I won't do it as an API test. | 12:17 |
| shardy | It looks like a good start to me | 12:18 |
| cmyster | Its to big and important to just whisk a short scenario, so here at least I can cover all the basics | 12:18 |
| shardy | perhaps you can collaborate later with stevebaker and nanjj on a more "real world" scenario test | 12:18 |
| cmyster | indeed | 12:19 |
| cmyster | I need to return to the sanity scenario I was working on as well... | 12:19 |
| cmyster | I will add elements from here as well | 12:19 |
| *** yogeshmehra has joined #heat | 12:20 | |
| *** aweiteka has quit IRC | 12:22 | |
| shardy | cmyster: few comments added, mostly minor stuff | 12:23 |
| *** erecio has joined #heat | 12:24 | |
| *** yogeshmehra has quit IRC | 12:25 | |
| *** erecio has quit IRC | 12:27 | |
| *** rpothier__ has joined #heat | 12:34 | |
| *** julienve_ has quit IRC | 12:39 | |
| *** erecio has joined #heat | 12:40 | |
| *** nosnos has quit IRC | 12:42 | |
| *** cmyster has quit IRC | 12:42 | |
| *** rbuilta has joined #heat | 12:43 | |
| *** julienve_ has joined #heat | 12:53 | |
| *** spzala has joined #heat | 12:54 | |
| sdague | stevebaker: congrats on gerrit change 90K :) | 12:55 |
| *** jamie_h has quit IRC | 12:59 | |
| *** jamie_h has joined #heat | 12:59 | |
| *** alexpilotti has joined #heat | 13:01 | |
| *** nkhare has joined #heat | 13:05 | |
| shardy | sdague: Hi, I'm working on some tests using the cirros image like we discussed last week | 13:05 |
| shardy | sdague: Is it safe to use compute.image_ref as the stack input, i.e will that always be cirros in the gate? | 13:06 |
| shardy | then we use orchestration.image_ref whereever we need the full cfntools image? | 13:06 |
| sdague | yes, I think that's sane | 13:07 |
| shardy | sdague: Ok, thanks | 13:07 |
| sdague | we should probably make that set of assumptions more explicit in the tempest.conf. That compute image needs to be something yuo can ssh to, and orchestration image needs to be something with cnftools | 13:08 |
| shardy | I've got a template which does wait condition signalling via curl with a cirros image now, so we can probably convert some of the existing tests to use the same approach | 13:08 |
| sdague | cool | 13:08 |
| shardy | Ok, sounds good | 13:08 |
| shardy | in general I've been erring towards using wait conditions to return data from the instance instead of SSHing to them | 13:09 |
| *** achampion has joined #heat | 13:09 | |
| shardy | then in future we can use either SoftwareDeployment resources or a native WaitCondition replacement instead | 13:09 |
| shardy | e.g http://paste.fedoraproject.org/96586/34500413 | 13:10 |
| *** aweiteka has joined #heat | 13:11 | |
| *** gokrokve has joined #heat | 13:13 | |
| sdague | shardy: so question on the template replacement, what happens if dev_name_2 showed up in that template? | 13:14 |
| shardy | sdague: Hmm, true, I should probably make the test a regex | 13:15 |
| sdague | shardy: yeh, this was actually less about this test in particular | 13:16 |
| shardy | I was making some assumptions like the attached disk will be vdb, because the cirros image doesn't allow disk lookup by uuid | 13:16 |
| shardy | whereas we could do an explicit lookup on e.g the full Fedora image | 13:16 |
| sdague | it was just something I was wondering about heat template replacement, because by not using a sigal of some sort, I wasn't sure what the behavior was | 13:16 |
| *** cdent has joined #heat | 13:16 | |
| shardy | Oh, you mean str_replace? | 13:16 |
| sdague | yeh | 13:17 |
| shardy | that just does a dumb replacement, so it's up to the template author to choose substitution tokens which are suitably unique within the template snippet | 13:17 |
| *** gokrokve has quit IRC | 13:17 | |
| shardy | If someone puts dev_name_2 in the userdata, it will get substituted with e.g vdb_2 | 13:18 |
| *** sgran has quit IRC | 13:19 | |
| *** blomquisg has joined #heat | 13:20 | |
| sdague | ok, like c macros | 13:20 |
| sdague | is that something well documented? I could imagine someone tripping over it. | 13:20 |
| *** ramishra_ has joined #heat | 13:21 | |
| shardy | http://docs.openstack.org/developer/heat/template_guide/hot_spec.html#str-replace | 13:21 |
| shardy | seems quite well explained there | 13:21 |
| *** ramishra has quit IRC | 13:22 | |
| *** sorantis has quit IRC | 13:23 | |
| *** vijendar has joined #heat | 13:28 | |
| *** pas-ha has joined #heat | 13:30 | |
| *** samstav has joined #heat | 13:31 | |
| *** blues-man has joined #heat | 13:31 | |
| *** sgordon has joined #heat | 13:33 | |
| *** sgordon has quit IRC | 13:33 | |
| *** sgordon has joined #heat | 13:33 | |
| *** sgran has joined #heat | 13:36 | |
| *** sorantis has joined #heat | 13:40 | |
| *** yogeshmehra has joined #heat | 13:41 | |
| *** varora has joined #heat | 13:43 | |
| *** pafuent has joined #heat | 13:45 | |
| *** akuznetsov has quit IRC | 13:46 | |
| *** nanjj has joined #heat | 13:47 | |
| *** zns has joined #heat | 13:48 | |
| *** zns has quit IRC | 13:48 | |
| *** zns has joined #heat | 13:48 | |
| *** nanjj has quit IRC | 13:48 | |
| sdake | morning | 13:49 |
| shardy | morning sdake | 13:49 |
| *** varora has left #heat | 13:50 | |
| *** nanjj has joined #heat | 13:50 | |
| *** zns has quit IRC | 13:51 | |
| nanjj | Hi | 13:51 |
| sdake | hey shardz | 13:53 |
| *** vinsh_away is now known as vinsh | 13:53 | |
| *** zns has joined #heat | 13:54 | |
| *** zhiyan_ is now known as zhiyan | 13:55 | |
| *** che-arne has joined #heat | 13:58 | |
| *** sabeen has joined #heat | 14:00 | |
| *** radez_g0n3 is now known as radez | 14:01 | |
| *** andersonvom has quit IRC | 14:01 | |
| *** gokrokve has joined #heat | 14:01 | |
| *** zns has quit IRC | 14:03 | |
| *** zz_gondoi is now known as gondoi | 14:03 | |
| *** sabeen has quit IRC | 14:04 | |
| *** sabeen has joined #heat | 14:05 | |
| *** akuznetsov has joined #heat | 14:05 | |
| *** zns has joined #heat | 14:07 | |
| *** denis_makogon has quit IRC | 14:13 | |
| *** andersonvom has joined #heat | 14:15 | |
| *** funzo has quit IRC | 14:27 | |
| *** funzo has joined #heat | 14:28 | |
| *** funzo is now known as Guest18818 | 14:28 | |
| *** kgriffs|afk is now known as kgriffs | 14:29 | |
| *** nanjj has quit IRC | 14:31 | |
| *** Guest18818 is now known as funzo | 14:37 | |
| *** TravT has joined #heat | 14:37 | |
| *** sjmc7 has joined #heat | 14:46 | |
| *** IlyaE has joined #heat | 14:49 | |
| *** daneyon has joined #heat | 14:53 | |
| *** ramishra_ has quit IRC | 14:53 | |
| *** piyush1 has joined #heat | 14:54 | |
| *** jamie_h has quit IRC | 14:57 | |
| *** jamie_h has joined #heat | 14:57 | |
| *** yogeshmehra has quit IRC | 15:00 | |
| *** dims has quit IRC | 15:03 | |
| *** chandan_kumar has joined #heat | 15:04 | |
| *** pafuent has quit IRC | 15:04 | |
| *** nkhare has quit IRC | 15:04 | |
| *** dims has joined #heat | 15:05 | |
| *** pablosan has joined #heat | 15:05 | |
| openstackgerrit | Jay Dobies proposed a change to openstack/heat: Added explicit call to validate template version https://review.openstack.org/90109 | 15:06 |
| *** ramishra has joined #heat | 15:08 | |
| *** pafuent has joined #heat | 15:10 | |
| *** tspatzier has quit IRC | 15:14 | |
| *** zns has quit IRC | 15:15 | |
| *** mspreitz has joined #heat | 15:16 | |
| *** david-lyle has joined #heat | 15:16 | |
| *** chandan_kumar has quit IRC | 15:16 | |
| openstackgerrit | Jason Dunsmore proposed a change to openstack/heat: Don't use SSH in Rackspace::Cloud::Server https://review.openstack.org/83218 | 15:20 |
| *** ramishra has quit IRC | 15:20 | |
| *** julienve_ has quit IRC | 15:22 | |
| openstackgerrit | Pavlo Shchelokovskyy proposed a change to openstack/heat: Add range constraint to AWS volume size https://review.openstack.org/89881 | 15:27 |
| *** nanjj has joined #heat | 15:28 | |
| *** onorua has quit IRC | 15:38 | |
| *** m_22 has joined #heat | 15:42 | |
| *** mspreitz has quit IRC | 15:47 | |
| *** piyush1 has quit IRC | 15:51 | |
| *** nanjj has quit IRC | 15:52 | |
| *** nanjj has joined #heat | 15:52 | |
| *** mspreitz has joined #heat | 15:53 | |
| *** mkollaro has quit IRC | 15:54 | |
| *** zns has joined #heat | 15:57 | |
| *** mspreitz_ has joined #heat | 15:57 | |
| *** mspreitz has quit IRC | 15:57 | |
| *** mspreitz_ is now known as mspreitz | 15:57 | |
| *** mspreitz has quit IRC | 15:59 | |
| *** lsmola has quit IRC | 16:00 | |
| *** tspatzier has joined #heat | 16:01 | |
| *** pafuent has quit IRC | 16:01 | |
| *** dims has quit IRC | 16:03 | |
| *** pafuent has joined #heat | 16:03 | |
| *** ramishra has joined #heat | 16:05 | |
| *** dims has joined #heat | 16:06 | |
| therve | SpamapS, We still require cfn-api for wait conditions | 16:07 |
| therve | re your email | 16:07 |
| SpamapS | therve: we do not require waitconditions, however. :) | 16:07 |
| SpamapS | deployments serve that purpose nicely now | 16:07 |
| therve | Hum right | 16:08 |
| shardy | SpamapS: the only issue is deployments require agent support | 16:08 |
| therve | shardy, So do wait conditions? | 16:08 |
| shardy | therve: no they don't, you can just use curl | 16:08 |
| therve | Oh that's right | 16:08 |
| *** randallburt has joined #heat | 16:08 | |
| shardy | I'm thinking of reviving my WaitSignal patch which would provide attributes which would allow a curl call to the native signal API | 16:08 |
| *** sorantis_ has joined #heat | 16:09 | |
| therve | Well because there are widely insecure though | 16:09 |
| SpamapS | shardy: https://git.openstack.org/cgit/openstack/tripleo-image-elements/tree/elements/os-refresh-config/os-refresh-config/post-configure.d/99-refresh-completed | 16:09 |
| SpamapS | shardy: curl works fine for deployments too | 16:09 |
| shardy | SpamapS: only if you use the CFN API | 16:09 |
| SpamapS | we only support one per server right now in tripleo .. that's our bug.. but we just alias the deployment signal as 'completion-signal' and it works | 16:09 |
| shardy | SpamapS: I'm talking about providing the same sort of interface via the native signal API | 16:10 |
| SpamapS | shardy: so deployments are feeding me a cfn url? | 16:10 |
| shardy | SpamapS: yes | 16:10 |
| SpamapS | weird | 16:10 |
| shardy | depending on the transport | 16:10 |
| SpamapS | nicely hidden from me | 16:10 |
| SpamapS | but WEIRD | 16:10 |
| shardy | I agree | 16:10 |
| shardy | I think it was a pragmatic decision based on what worked at the time | 16:10 |
| SpamapS | Yeah for sure | 16:10 |
| therve | shardy, How can you provide a URL for signal? | 16:10 |
| therve | For the native signal API I mean | 16:11 |
| shardy | therve: provide the URL, and a token, then you can use curl to post to the URL | 16:11 |
| SpamapS | I'm guessing that it would require a native ec2-signer-like interface | 16:11 |
| therve | shardy, So effectively time constrained | 16:11 |
| therve | I guess it doesn't matter so much for wait conditions | 16:12 |
| *** Qiming has quit IRC | 16:12 | |
| *** sorantis has quit IRC | 16:12 | |
| shardy | Exactly, it's a harder problem for other stuff which doesn't have a finite expiry | 16:12 |
| *** sorantis_ has quit IRC | 16:13 | |
| *** mkollaro has joined #heat | 16:13 | |
| shardy | therve: http://paste.fedoraproject.org/96649/98356011 | 16:13 |
| SpamapS | I think we might want to consider copying swift's tempurl scheme | 16:14 |
| *** piyush1 has joined #heat | 16:14 | |
| *** bvandenh has quit IRC | 16:14 | |
| shardy | there's an example of where I'd like to use a OS::Heat::WaitSignal | 16:14 |
| SpamapS | rather than trying to use tokens | 16:14 |
| SpamapS | tokens are massive | 16:14 |
| shardy | SpamapS: I think stevebaker is actually looking at using swift for the signalling | 16:14 |
| shardy | which would be another way to solve it | 16:14 |
| SpamapS | shardy: yeah, that will definitely scale better than client->heat-api->rabbitmq->heat-engine->mysql | 16:15 |
| SpamapS | at the cost of needing either some kind of swift notification mechanism or polling swift like mad | 16:15 |
| *** piyush2 has joined #heat | 16:15 | |
| therve | ? | 16:15 |
| therve | Did you really mean "definitely" here? :) | 16:16 |
| SpamapS | therve: yes | 16:16 |
| SpamapS | therve: we currently poll heat-api->rabbitmq->heat-engine->mysql like mad | 16:17 |
| *** dims has quit IRC | 16:17 | |
| SpamapS | therve: polling swift like mad WILL scale better | 16:17 |
| therve | Oh you you mean that signalling, okay | 16:17 |
| SpamapS | therve: until we have a user consumable notification bus, swift wins | 16:17 |
| *** zns has quit IRC | 16:18 | |
| *** dims has joined #heat | 16:18 | |
| *** piyush1 has quit IRC | 16:18 | |
| therve | Swift temporary URLs sounds like web hooks, which several people were adamant not to use because of security concerns | 16:18 |
| therve | But anyway | 16:18 |
| *** ramishra has quit IRC | 16:19 | |
| *** andrew_plunk has joined #heat | 16:20 | |
| *** ramishra has joined #heat | 16:22 | |
| *** kfox1111 has joined #heat | 16:23 | |
| kfox1111 | so.... I have two templates. template A creates an instance. Its very generic. I have template B, which nests template A, giving it a bunch of params, so the user doesn't have to fill out a bunch of stuff to relaunch the same stack instance. | 16:24 |
| kfox1111 | Now, here's the rub... Say I want to allow template B to attach metadata to the instance A generates, but only if they pass some metadata. Is that possible? | 16:25 |
| *** chandan_kumar has joined #heat | 16:25 | |
| shardy | kfox1111: pass a parameter into template A with a default value which equals no metadata? | 16:26 |
| kfox1111 | can I pass a metadata structure through? What happens if I pass nothing? Will it freak out if you have no value on the left hand side? | 16:27 |
| shardy | Oh, you mean the metadata template section, not the metadata property to the Server resource | 16:27 |
| shardy | I'm not sure if that will work | 16:28 |
| kfox1111 | the Nova::Server metadata map. | 16:28 |
| kfox1111 | hmmm... This I think is another case of wanting an if. :/ | 16:29 |
| kfox1111 | and maybe a json deserializer function of some kind. | 16:29 |
| *** bvandenh has joined #heat | 16:29 | |
| shardy | can't you just pass some values as parameters which modify the content of the metadata? | 16:30 |
| kfox1111 | so for now, I'd have to fork the template and allow passing of only one key=value in the forked template. | 16:30 |
| shardy | why do you have to pass the entire structure? | 16:30 |
| kfox1111 | hmm... but I probably cant do that either. I don't think I can use a Ref as a key... | 16:30 |
| kfox1111 | passing the entire structure woudl be the most flexable. | 16:30 |
| *** arbylee has joined #heat | 16:30 | |
| kfox1111 | the other option is two paramaters, a "metadata_key" and a "metadata_value", which would allow passing one metadata pair. | 16:31 |
| shardy | kfox1111: maybe start a ML thread describing your use-case, then we can all have a look and either suggest a way to do it, or work out if it makes sense to enable it | 16:31 |
| kfox1111 | but I dont think I can metadata: {{Ref: metadata_key}: {Ref: metadata_value}} | 16:31 |
| kfox1111 | k. | 16:31 |
| shardy | FWIW so far we've deliberately avoided such template magic for the sake of simplicity | 16:32 |
| shardy | but concrete use-cases are always helpful when discussing such ideas | 16:32 |
| therve | You should be able to pass the whole structure using a JSON param | 16:32 |
| *** zns has joined #heat | 16:32 | |
| *** gokrokve_ has joined #heat | 16:32 | |
| therve | That's what I did right here: https://github.com/openstack/heat-templates/blob/master/hot/lb_server.yaml | 16:33 |
| kfox1111 | therve: Really? Cool. looking... | 16:33 |
| *** ramishra has quit IRC | 16:33 | |
| therve | I didn't handle the empty case but there may be a way to make it work using defaults | 16:34 |
| kfox1111 | hmm... so how does it work if template B is yaml? | 16:34 |
| kfox1111 | does it take a string that it converts to json, or does it convert yaml to json? | 16:34 |
| shardy | therve: I thought kfox1111 was talking about the top-level metadata key, not the resource property | 16:34 |
| shardy | too many overloaded meanings of metadata :( | 16:35 |
| kfox1111 | heh. yeah. | 16:35 |
| *** arbylee has quit IRC | 16:35 | |
| *** gokrokve has quit IRC | 16:36 | |
| kfox1111 | the only relyable definition I've ever come up with for what metadata means, is: "metadata is data that is, when viewed by a particular idividual at a particular time, is not considered important enough to be condisdered data" :) | 16:37 |
| *** arbylee has joined #heat | 16:37 | |
| kfox1111 | one man's metadata is anothers data... :) | 16:37 |
| *** andersonvom_ has joined #heat | 16:38 | |
| *** andersonvom has quit IRC | 16:38 | |
| *** arbylee1 has joined #heat | 16:38 | |
| *** jistr has quit IRC | 16:40 | |
| *** arbylee has quit IRC | 16:42 | |
| *** arbylee1 has quit IRC | 16:43 | |
| *** pafuent has left #heat | 16:44 | |
| *** zns has quit IRC | 16:45 | |
| *** zns has joined #heat | 16:46 | |
| *** pafuent has joined #heat | 16:47 | |
| *** jamie_h_ has joined #heat | 16:48 | |
| *** sorantis has joined #heat | 16:48 | |
| *** harlowja_away is now known as harlowja | 16:51 | |
| shardy | SpamapS: FYI the cinder tempest test I mentioned yesterday https://review.openstack.org/#/c/90143/ | 16:51 |
| *** jamie_h has quit IRC | 16:52 | |
| *** jamie_h_ has quit IRC | 16:54 | |
| *** shardy is now known as shardy_afk | 16:57 | |
| openstackgerrit | Rob Crittenden proposed a change to openstack/python-heatclient: Heat client does not support OS_CACERT option https://review.openstack.org/87664 | 16:57 |
| *** jpeeler has quit IRC | 16:58 | |
| *** jpeeler has joined #heat | 16:59 | |
| *** jpeeler has quit IRC | 16:59 | |
| *** jpeeler has joined #heat | 16:59 | |
| *** zns has quit IRC | 17:01 | |
| *** blues-man has quit IRC | 17:01 | |
| *** cdent has quit IRC | 17:01 | |
| *** e0ne has quit IRC | 17:01 | |
| *** zhiyan is now known as zhiyan_ | 17:03 | |
| *** lindsayk has joined #heat | 17:03 | |
| *** Michalik- has quit IRC | 17:04 | |
| *** gpocentek has joined #heat | 17:04 | |
| openstackgerrit | Jason Dunsmore proposed a change to openstack/heat: Rackspace::Server::SSHWaitCondition resource https://review.openstack.org/85386 | 17:07 |
| *** gokrokve_ has quit IRC | 17:08 | |
| gpocentek | hello | 17:10 |
| gpocentek | I'm working on a patch for the heat section of the isntallation documentation: https://review.openstack.org/#/c/90071/ | 17:11 |
| gpocentek | I'd like to make sure I'm not completely wrong there, a review from an expert on the subject would be much appreciated :) | 17:12 |
| *** derekh has quit IRC | 17:15 | |
| *** chandan_kumar has quit IRC | 17:19 | |
| *** chandan_kumar has joined #heat | 17:19 | |
| *** zns has joined #heat | 17:21 | |
| *** randallburt has quit IRC | 17:22 | |
| openstackgerrit | Jason Dunsmore proposed a change to openstack/heat: API changes for param to show soft-deleted stacks https://review.openstack.org/88641 | 17:23 |
| openstackgerrit | Jason Dunsmore proposed a change to openstack/heat: Engine changes for API param to show soft-deleted stacks https://review.openstack.org/88642 | 17:23 |
| *** piyush2 has quit IRC | 17:28 | |
| *** akuznetsov has quit IRC | 17:32 | |
| *** akuznetsov has joined #heat | 17:32 | |
| *** daneyon has quit IRC | 17:38 | |
| *** gokrokve has joined #heat | 17:40 | |
| *** andersonvom_ has quit IRC | 17:42 | |
| *** jprovazn has quit IRC | 17:47 | |
| *** zns has quit IRC | 17:48 | |
| *** andersonvom has joined #heat | 17:49 | |
| *** andersonvom has quit IRC | 17:49 | |
| *** mkollaro has quit IRC | 17:50 | |
| *** IlyaE has quit IRC | 17:52 | |
| *** nati_ueno has joined #heat | 17:52 | |
| *** zns has joined #heat | 17:57 | |
| *** yogesh has joined #heat | 17:59 | |
| *** randallburt has joined #heat | 17:59 | |
| *** e0ne has joined #heat | 18:03 | |
| *** ifarkas has quit IRC | 18:05 | |
| *** nati_ueno has quit IRC | 18:06 | |
| *** piyush1 has joined #heat | 18:11 | |
| *** piyush2 has joined #heat | 18:12 | |
| *** che-arne has quit IRC | 18:13 | |
| *** nati_ueno has joined #heat | 18:13 | |
| *** nati_ueno has quit IRC | 18:14 | |
| *** zns has quit IRC | 18:14 | |
| *** piyush1 has quit IRC | 18:15 | |
| *** nanjj has quit IRC | 18:16 | |
| openstackgerrit | A change was merged to openstack/heat: Add link to a resource's nested stack https://review.openstack.org/85781 | 18:21 |
| *** e0ne has quit IRC | 18:21 | |
| *** e0ne has joined #heat | 18:22 | |
| *** nati_ueno has joined #heat | 18:22 | |
| *** Darnoth has joined #heat | 18:23 | |
| *** lindsayk has quit IRC | 18:27 | |
| *** andersonvom has joined #heat | 18:27 | |
| *** blamar_ has joined #heat | 18:29 | |
| *** blamar_ is now known as blamar | 18:29 | |
| *** mspreitz has joined #heat | 18:30 | |
| mspreitz | Was there some discussion of removing tenant ID from the URLs of Heat? | 18:30 |
| zaneb | there was, yes | 18:30 |
| mspreitz | resolution? | 18:30 |
| zaneb | probably will happen in the v2 API | 18:30 |
| mspreitz | thanks | 18:30 |
| *** derekh has joined #heat | 18:31 | |
| zaneb | expect to see a design summit session on the v2 api | 18:31 |
| *** ramishra has joined #heat | 18:34 | |
| *** zns has joined #heat | 18:37 | |
| *** mkollaro has joined #heat | 18:38 | |
| *** ramishra has quit IRC | 18:39 | |
| *** lindsayk has joined #heat | 18:42 | |
| *** andersonvom has quit IRC | 18:46 | |
| *** nati_ueno has quit IRC | 18:49 | |
| *** andersonvom has joined #heat | 18:50 | |
| *** sballe has quit IRC | 18:50 | |
| *** chandan_kumar has quit IRC | 18:52 | |
| *** zns has quit IRC | 18:54 | |
| *** zns has joined #heat | 18:55 | |
| *** ramishra has joined #heat | 18:55 | |
| *** ramishra has quit IRC | 19:00 | |
| *** sballe has joined #heat | 19:00 | |
| *** IlyaE has joined #heat | 19:00 | |
| *** arbylee has joined #heat | 19:01 | |
| openstackgerrit | Dimitri Mazmanov proposed a change to openstack/heat: Add a Nova Flavor resource. https://review.openstack.org/90029 | 19:04 |
| *** arbylee has quit IRC | 19:05 | |
| *** dims has quit IRC | 19:11 | |
| *** varora has joined #heat | 19:12 | |
| *** blamar has quit IRC | 19:12 | |
| *** andersonvom has quit IRC | 19:13 | |
| *** nanjj has joined #heat | 19:14 | |
| *** chandan_kumar has joined #heat | 19:16 | |
| *** cdent has joined #heat | 19:18 | |
| *** saurabhs has joined #heat | 19:20 | |
| *** bvandenh has quit IRC | 19:21 | |
| saurabhs | hey guys need some help with heat template. so I am trying to deploy Trove service with Heat-Tripleo. In my heat template, I am trying to create mysql and rabbitmq resources then specify IP of mysql and rabbit in control plane metadata. But that IP is not getting initialized correctly. | 19:23 |
| saurabhs | https://github.com/saurabhsurana/tripleo-heat-templates/blob/master/trove-control-plane.yaml#L704-#L706 | 19:23 |
| saurabhs | I always get empty string for rabbit.host | 19:23 |
| *** chandan_kumar has quit IRC | 19:23 | |
| saurabhs | when I do 'heat resource-metadata' | 19:24 |
| saurabhs | it shows me: | 19:24 |
| saurabhs | "rabbit": { | 19:24 |
| saurabhs | …. | 19:24 |
| saurabhs | "host": "", | 19:24 |
| saurabhs | ….. | 19:24 |
| saurabhs | }, | 19:24 |
| *** david-lyle_ has joined #heat | 19:26 | |
| *** nanjj has quit IRC | 19:27 | |
| *** rbuilta has quit IRC | 19:29 | |
| *** nati_ueno has joined #heat | 19:30 | |
| *** piyush2 has quit IRC | 19:32 | |
| *** dims has joined #heat | 19:33 | |
| *** mspreitz has quit IRC | 19:35 | |
| *** varora has left #heat | 19:35 | |
| erecio | Hi everbody. I have a doubt about the AWS::EC2::SecurityGroup resource. Under this resource you have two diff properties SecurityGroupEgress and SecurityGroupIngress. Both has a property named IpProtocol and in the AWS docs say that cant take this valid values for EC2-VPC " | 19:38 |
| erecio | (Ref http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ec2-security-group-rule.html). Right now Openstack not support the value "-1" to add tcp,udp and icmp in one rule, its possible to add a BP to support this? Other solution could be add one rule for each in the template. Im new on OS and Im not sure. Thanks. | 19:38 |
| *** sdague has quit IRC | 19:41 | |
| erecio | *Both has a property named IpProtocol and in the AWS docs say that cant take this valid values for EC2-VPC " tcp | udp | icmp or any protocol number (see Protocol Numbers).Use -1 to specify all." | 19:41 |
| therve | erecio, Does the VPC case mean anything in the case of openstack though? | 19:42 |
| *** sdague has joined #heat | 19:42 | |
| erecio | therve, Sorry I dont follow you | 19:45 |
| therve | erecio, In AWS, the -1 value is only possible for VPC, correct? | 19:45 |
| *** IlyaE has quit IRC | 19:46 | |
| *** varora has joined #heat | 19:46 | |
| *** pablosan is now known as zz_pablosan | 19:47 | |
| erecio | therve, Im not sure. Its under AWS::EC2::SecurityGroup. Im checking the AWS doc if mention something about -1 only in VPC | 19:48 |
| *** varora has left #heat | 19:48 | |
| therve | erecio, You just said "for EC2-VPC" yourself | 19:50 |
| *** IlyaE has joined #heat | 19:50 | |
| erecio | therve, Yes, i didnt realize | 19:51 |
| therve | erecio, Anyway, have you tried talking to the neutron folks about it? | 19:52 |
| erecio | its valid only vor VPC. | 19:52 |
| therve | If neutron supports it heat can use it easily | 19:52 |
| *** jreypo has joined #heat | 19:53 | |
| erecio | therve, No yet. Im not familiar with Heat so i dont know how works the parser. | 19:54 |
| erecio | therve, I know that this came from Nova | 19:55 |
| therve | erecio, Heat is mostly a way to have a template to talk to APIs | 19:55 |
| therve | So security groups APIs are exposed by either nova or neutron | 19:55 |
| therve | If they support -1 in protocol, Heat will as well | 19:56 |
| erecio | therve, Perfect | 19:56 |
| therve | It doesn't seem like a super exciting feature though :) | 19:56 |
| *** ramishra has joined #heat | 19:56 | |
| *** david-lyle_ has quit IRC | 19:56 | |
| *** piyush1 has joined #heat | 19:57 | |
| erecio | therve, ahah thats for sure. As i say, I can define three times the rule one for each protocol :-) | 19:57 |
| therve | Probably 2 because icmp is kind of seperate I think | 19:58 |
| *** piyush2 has joined #heat | 19:58 | |
| *** ramishra has quit IRC | 20:01 | |
| *** piyush1 has quit IRC | 20:01 | |
| *** sorantis has quit IRC | 20:02 | |
| *** zz_pablosan is now known as pablosan | 20:02 | |
| *** harlowja is now known as harlowja_away | 20:06 | |
| erecio | therve, Thanks! | 20:07 |
| therve | No problem | 20:08 |
| *** sgordon has quit IRC | 20:29 | |
| sdake_ | zaneb around? | 20:34 |
| zaneb | yep | 20:34 |
| *** blomquisg has quit IRC | 20:34 | |
| sdake_ | are you going to be in the office tomorrow | 20:34 |
| zaneb | define 'office' ;) | 20:34 |
| sdake_ | sitting in your pjs in front of a laptop | 20:35 |
| zaneb | then yes | 20:35 |
| zaneb | :D | 20:35 |
| *** Slower has quit IRC | 20:37 | |
| *** Slower has joined #heat | 20:38 | |
| *** nanjj has joined #heat | 20:39 | |
| *** derekh has quit IRC | 20:39 | |
| *** radez is now known as radez_g0n3 | 20:40 | |
| *** piyush2 has quit IRC | 20:44 | |
| *** piyush1 has joined #heat | 20:49 | |
| *** che-arne has joined #heat | 20:50 | |
| *** piyush2 has joined #heat | 20:51 | |
| *** jdob has quit IRC | 20:52 | |
| *** piyush1 has quit IRC | 20:53 | |
| *** Michalik- has joined #heat | 20:54 | |
| *** erecio has quit IRC | 20:55 | |
| *** cdent has quit IRC | 20:56 | |
| *** ramishra has joined #heat | 20:57 | |
| *** nanjj has quit IRC | 20:59 | |
| *** alexheneveld has joined #heat | 20:59 | |
| *** harlowja_away is now known as harlowja | 21:01 | |
| *** ramishra has quit IRC | 21:02 | |
| *** bvandenh has joined #heat | 21:05 | |
| *** nanjj has joined #heat | 21:16 | |
| *** IlyaE has quit IRC | 21:16 | |
| *** e0ne has quit IRC | 21:21 | |
| *** aweiteka has quit IRC | 21:22 | |
| *** pafuent has left #heat | 21:22 | |
| *** nanjj has quit IRC | 21:25 | |
| *** tspatzier has quit IRC | 21:31 | |
| zaneb | 3 slots left... 6 proposals to fit in | 21:32 |
| zaneb | btw I hope everyone has voted in the TC elections? | 21:32 |
| *** zns has quit IRC | 21:33 | |
| zaneb | actually, 7 proposals to fit in | 21:33 |
| *** nati_ueno has quit IRC | 21:33 | |
| zaneb | radix: so the conclusion is that we don't need either the autoscaling or the convergence sessions, and that lifeless's session only requires one slot? | 21:35 |
| *** vijendar has quit IRC | 21:39 | |
| SpamapS | zaneb: yes, radix should have communicated that to you yesterday. | 21:43 |
| SpamapS | zaneb: autoscaling, convergence, lifeless, all one session. | 21:43 |
| zaneb | he left a comment, I just wanted to confirm that was the meaning | 21:43 |
| *** zns has joined #heat | 21:45 | |
| *** mspreitz has joined #heat | 21:48 | |
| randallburt | titled "A lifeless convergence of autoscaling" | 21:49 |
| *** rpothier__ has quit IRC | 21:50 | |
| zaneb | randallburt: note to self, don't schedule that one right after lunch | 21:51 |
| radix | +1 :) | 21:51 |
| zaneb | 4 proposals, 2 slots | 21:52 |
| randallburt | indeed zaneb. btw do we know what "day" we'll have in ATL? I noticed several of us are giving presentations during that "other" part of the conference | 21:52 |
| zaneb | indeed we do | 21:52 |
| *** e0ne has joined #heat | 21:52 | |
| *** derekh has joined #heat | 21:52 | |
| randallburt | zaneb: and that day is? | 21:52 |
| zaneb | haha, yes, that's the question isn't it | 21:53 |
| randallburt | lol | 21:53 |
| * zaneb is looking for the magic link | 21:53 | |
| *** gondoi is now known as zz_gondoi | 21:53 | |
| *** IlyaE has joined #heat | 21:53 | |
| *** zz_gondoi is now known as gondoi | 21:53 | |
| *** bvandenh has quit IRC | 21:54 | |
| zaneb | randallburt: Wednesday | 21:54 |
| zaneb | https://docs.google.com/spreadsheet/ccc?key=0AmUn0hzC1InKdGNXcWlWX0FIekQxbUtvRVlnVF9IV3c&usp=drive_web#gid=5 | 21:54 |
| randallburt | zaneb: cool, thanks! | 21:54 |
| *** dims has quit IRC | 21:56 | |
| *** e0ne has quit IRC | 21:57 | |
| *** david-lyle has quit IRC | 21:57 | |
| *** ramishra has joined #heat | 21:58 | |
| *** ramishra has quit IRC | 22:02 | |
| *** gondoi is now known as zz_gondoi | 22:03 | |
| *** saurabhs has quit IRC | 22:05 | |
| *** dims has joined #heat | 22:09 | |
| *** saurabhs has joined #heat | 22:10 | |
| *** lindsayk has quit IRC | 22:11 | |
| *** lindsayk has joined #heat | 22:12 | |
| *** achampion has quit IRC | 22:15 | |
| *** e0ne has joined #heat | 22:16 | |
| *** e0ne_ has joined #heat | 22:18 | |
| *** Michalik- has quit IRC | 22:19 | |
| openstackgerrit | Mike Spreitzer proposed a change to openstack/heat-templates: Worked on Fedora 20 examples in HOT https://review.openstack.org/88523 | 22:19 |
| randallburt | zaneb: https://blueprints.launchpad.net/heat/+spec/dynamic-flavors and its associated implementation https://review.openstack.org/#/c/90029/ seem really questionable as a user-facing resource. I'm curious to your thoughts as the bp is approved. | 22:20 |
| *** shakamunyi has quit IRC | 22:20 | |
| *** e0ne has quit IRC | 22:21 | |
| *** e0ne_ has quit IRC | 22:22 | |
| *** kgriffs is now known as kgriffs|afk | 22:23 | |
| zaneb | randallburt: we discussed it (yesterday?), and my thoughts are that it's fine for /contrib and really questionable as a user-facing resource | 22:23 |
| randallburt | zaneb: k. I'll review my review then | 22:24 |
| *** piyush2 has quit IRC | 22:24 | |
| *** yogesh has quit IRC | 22:24 | |
| *** zns has quit IRC | 22:24 | |
| *** zns has joined #heat | 22:28 | |
| *** Michalik- has joined #heat | 22:30 | |
| zaneb | it's down to resource versioning or constraint-based selection of images for the last slot | 22:31 |
| *** mspreitz has quit IRC | 22:35 | |
| *** andrew_plunk has quit IRC | 22:43 | |
| *** zns has quit IRC | 22:43 | |
| randallburt | zaneb: my boss will hate me, but IMO its constraint-based image selection. | 22:44 |
| zaneb | randallburt: too late, I already picked resource versioning ;) | 22:44 |
| *** derekh has quit IRC | 22:45 | |
| zaneb | randallburt: what I wrote in the comments was "I'm going to drop this session in the hope that Heat's role will be limited to exposing the new API when it is provided by Glance." | 22:45 |
| randallburt | zaneb: maybe consolidate? I think the resource versioning will be tricky, but the constraint based selection of flavors and/or images shouldn't be too tricky/contrivercial. We could even do it with new resources instead of some sort of param constraint/lookup. | 22:45 |
| sdake | we can probably have a over-beer discussion about constraint-based image selection | 22:45 |
| randallburt | zaneb: but Glance does or should already, though. | 22:46 |
| randallburt | sdake: fair enough. | 22:46 |
| randallburt | sdake: but you buy the beer ;) | 22:46 |
| zaneb | randallburt: see spzala's comments on http://summit.openstack.org/cfp/details/68 | 22:46 |
| sdake | you assume I have more then 25$ in my checking account randallburt :) | 22:46 |
| zaneb | I'm ok with merging the two, though, if you think they're related | 22:46 |
| randallburt | sdake: its work related. RedHat buys the beer then ;) | 22:46 |
| zaneb | randallburt: don't listen, he has a corporate CC ;) | 22:47 |
| randallburt | zaneb: they aren't related, but I don't feel either would necessarily take a whole session. | 22:47 |
| sdake | I'm pretty sure the corporate cc masters will have my head after summit | 22:47 |
| *** IlyaE has quit IRC | 22:47 | |
| sdake | does splitting 50/50 ever work? | 22:47 |
| zaneb | randallburt: the question for me is, will the same audience be interested in both? | 22:47 |
| randallburt | sdake: it did for one or two session in HKG IIRC | 22:48 |
| zaneb | other PTLs have said it is a bad idea to combine topics with different audiences | 22:48 |
| sdake | might be an option - wider audience then over beer and I wont go broke :) | 22:48 |
| sdake | zaneb makes sense to follow their lead then | 22:48 |
| *** rpothier__ has joined #heat | 22:48 | |
| zaneb | nobody knows whether to show up, and then it's disruptive as people leave part-way through | 22:48 |
| randallburt | zaneb: fair point. I'm not fussed either way. I'll blame you when kebray yells at me (he's interested in a strategy around resource versioning). | 22:49 |
| zaneb | he's in luck at the moment I guess | 22:50 |
| randallburt | zaneb: :D | 22:50 |
| zaneb | randallburt: I'm scheduling it last though, when everyone will be catatonic :D | 22:50 |
| randallburt | but *I'm* interested in constraints-based-constraints so I'll just drink sdake's beer and be happy | 22:50 |
| kebray | I"m not sure the context here, but I do occasionally fuss with randallburt, but only because he's so capable and I like the challenge even when he clearly shows me how I am wrong. | 22:51 |
| randallburt | zaneb: good plan. and kebray you get your resource versioning session in ATL looks like. | 22:51 |
| zaneb | randallburt: I think kebray is saying he wants me to de-schedule it again ;) | 22:51 |
| randallburt | and don't let him fool you, he's a slave driver ;) | 22:52 |
| randallburt | zaneb: no don't! I just remembered my reviews are due. (just kidding; I give kebray a hard time every chance I get because he's so easy to work with and its unsettling sometimes ;) | 22:52 |
| kebray | I'm just waiting to cash in my chips randallburt . | 22:53 |
| randallburt | kebray: lol, indeed. | 22:53 |
| kebray | I'm going to need a big favor from you one day... I just don't know when. | 22:53 |
| randallburt | kebray: I anxiously await the day.. ;) | 22:53 |
| randallburt | zaneb: ok, caught up on the comments and I'm good. No more fussing from me. | 22:54 |
| zaneb | we have a schedule! | 22:58 |
| *** ramishra has joined #heat | 22:58 | |
| * zaneb waits for sched.org to sync | 22:59 | |
| *** Michalik- has quit IRC | 22:59 | |
| *** m_22 has quit IRC | 23:02 | |
| *** ramishra has quit IRC | 23:03 | |
| randallburt | zaneb: congrats and thanks! | 23:03 |
| zaneb | pleasure :) | 23:04 |
| *** lifeless has quit IRC | 23:04 | |
| *** lifeless has joined #heat | 23:05 | |
| *** IlyaE has joined #heat | 23:05 | |
| *** alexheneveld has quit IRC | 23:16 | |
| *** e0ne has joined #heat | 23:18 | |
| *** m_22 has joined #heat | 23:18 | |
| *** sabeen has quit IRC | 23:19 | |
| *** samstav has quit IRC | 23:22 | |
| *** e0ne has quit IRC | 23:22 | |
| *** achampion has joined #heat | 23:22 | |
| *** sjmc7 has quit IRC | 23:23 | |
| *** gokrokve has quit IRC | 23:26 | |
| *** saurabhs has left #heat | 23:27 | |
| *** randallburt has quit IRC | 23:28 | |
| zaneb | yay! http://junodesignsummit.sched.org/type/heat | 23:33 |
| *** IlyaE has quit IRC | 23:34 | |
| *** mspreitz has joined #heat | 23:40 | |
| *** m_22 has left #heat | 23:43 | |
| *** e0ne has joined #heat | 23:43 | |
| *** gokrokve has joined #heat | 23:46 | |
| spzala | randleburt: just got back on IRC. Thanks for liking the constraint-based image selection session :-) so seems like it missed by just one. | 23:46 |
| spzala | sdake: randleburt: I think the beer should be on me and tspatzier ;) when we discuss constraint-based image selection | 23:47 |
| *** e0ne has quit IRC | 23:47 | |
| spzala | zaneb: I have just added a new comment of my findings on Glance support for image properties. | 23:48 |
| spzala | zaneb: on this one, http://summit.openstack.org/cfp/details/68 | 23:48 |
| *** Qiming has joined #heat | 23:56 | |
| *** ramishra has joined #heat | 23:59 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!