23:06:24 #startmeeting auto-scaling-sig 23:06:25 Meeting started Wed May 15 23:06:24 2019 UTC and is due to finish in 60 minutes. The chair is zaneb. Information about MeetBot at http://wiki.debian.org/MeetBot. 23:06:26 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 23:06:28 The meeting name has been set to 'auto_scaling_sig' 23:06:32 #chair dtruong 23:06:33 Current chairs: dtruong zaneb 23:06:48 o/ 23:06:54 o/ 23:07:06 o/ 23:07:13 do we have an agenda written down anywhere? 23:07:36 I don't think so 23:07:43 (I didn't think we had a meeting until next week, but just happened to have the chat tab open) 23:08:03 I’m making a place topics now. 23:08:34 #link https://etherpad.openstack.org/p/auto-scaling-IRC-topics 23:08:41 now adding it to wiki page. 23:08:55 pretty sure I used the calendar from eavesdrop.openstack.org, so this should be the right week 23:09:03 that links to https://wiki.openstack.org/wiki/Meetings/AutoScalingSIGMeeting (which is empty) 23:09:10 yea, it's the right week 23:10:53 * zaneb edits https://wiki.openstack.org/wiki/Meetings/AutoScalingSIGMeeting to point to the etherpad 23:11:36 so the docs patch merged, yay 23:11:40 #link https://docs.openstack.org/auto-scaling-sig/latest/ 23:11:53 cool 23:12:01 nice 23:12:53 joadavis I saw your comments earlier about 'theory of auto-scaling'. 23:13:05 Definitely think that would be helpful for operators. 23:13:09 Yes. I started a wiki - https://wiki.openstack.org/wiki/Auto-scaling_SIG/Theory_of_Auto-Scaling 23:13:11 #topic 'theory of autoscaling doc' 23:13:20 I was just hacking on it when we started 23:13:48 pretty rough draft, and I should drop the plantuml part (doesn't render nicely as text) 23:14:00 I totally agree that we should have a theory of autoscaling doc 23:14:35 I figured https://wiki.openstack.org/wiki/Auto-scaling_SIG/Theory_of_Auto-Scaling would be a start, and we can roll it in to a document in the repo to formalize 23:14:36 although I'm not sure that the specific example you mentioned belongs in there - maybe that should be in a 'Ceilometer gotchas' doc 23:15:24 I was hoping we could gather a wide range of 'gotchas'. Just having one about ceilometer isn't very helpful 23:16:10 there's plenty of very ceilometer-specific gotchas to go round ;) 23:16:22 maybe in the repo we have a subdirectory for experiences as a catch-all 23:17:24 the outline you have on the wiki there looks very good, and that good be a jumping-off point for people to dive into the individual services 23:17:28 very nice. 23:17:40 The ones you have are a good start. I'll try to think of any to add. 23:19:56 do we think this is ready to throw into a review, or would we prefer to hack on the wiki page for a bit longer? 23:20:44 Either way. I don't mind editing in a repo. Though will need to convert to .rst 23:21:46 I think it could still use a good general description of what auto-scaling is and how it differs from self-healing while using some of the same tools 23:22:02 Let's keep editing the wiki for a bit longer to give people a chance to contribute. 23:22:09 but I also want to see that on the main wiki page 23:22:17 :thumbsup: 23:23:04 sounds good. 23:23:39 ok, I'm fine with that but I'd also like to see all of the wiki pages disappear in the relatively short term 23:24:06 the downside is the bigger it gets the more work it is to convert to rst. 23:24:10 always a trade off. 23:24:39 the wiki is full of outdated information, and has spam problems that prevent people creating new accounts. infra would like to get rid of it altogether if they could 23:25:15 agreed. having a single wiki landing page that just points to the repos would be great 23:25:21 +1 23:26:05 ok, let's continue to iterate on that wiki page until the next meeting in 2 weeks 23:26:24 sounds good 23:26:34 #action hack on the Theory of Autoscaling wiki page 23:26:39 #link https://wiki.openstack.org/wiki/Auto-scaling_SIG/Theory_of_Auto-Scaling 23:27:28 #agreed move wiki content to docs repo after next meeting 23:27:57 any other topics? 23:28:14 i wanted to talk about the user survey 23:28:23 #topic user survey 23:28:43 i wonder if we wanted to propose auto-scaling questions in the user survey? 23:29:28 we would have to be quick :) 23:29:41 dtruong: do you have any in mind? 23:29:50 Maybe something like "are you auto-scaling in your OpenStack cloud?". "If so, which openstack projects are you using to do auto-scaling?" 23:31:12 that is pretty good. I'd like to ask "if you tried it what challenges did you face" but that is a longer conversation than just a survey 23:31:35 I wonder if we can infer which projects are used for autoscaling based on which projects are installed (which there's already a question about) 23:32:30 good point. Though if someone is just using Ceilometer and Heat that might not be clear 23:32:38 another possible question might be "Are you interested in auto-scaling for user workloads/infrastructure/both/neither" 23:33:09 Maybe the second question should be "which openstack projects or other projects are you using to do auto-scaling?" 23:33:52 ah true, they might have userspace parts in the stack 23:34:04 I'm wondering if people are using a combination of openstack projects and something like prometheus to do auto-scaling. 23:35:16 yeah, that would be interesting 23:36:26 it would be interesting to know what they want to scale (compute, storage, networking) 23:38:53 #link https://etherpad.openstack.org/p/auto-scaling-user-survey-question 23:39:05 What kind of considerations they have in scaling is also interesting - constrained only by amount of available resources, or if billing is a part of it. but again, too much detail for a survey 23:39:13 let's brainstorm the exact wording on that etherpad ^ 23:44:13 joadavis I added your question on the resources that people are scaling. I think that would be good to know. 23:44:14 joadavis: do you think we should list Watcher/Vitrage/Congress as separate options, or add a (please specify) for the "other openstack service" option? 23:44:58 It might be worth calling them out separately. I guess it depends on how popular we think they are and how long we want the options list. :) 23:45:25 tbh those seem to relate more to the auto-healing case than auto-scaling to me 23:46:33 time check - 15mins to go and ekcs has one more item on the agenda 23:48:24 I'm ok with the two questions as they are now. 23:48:28 (if I was being a pain I'd move Monasca to the top of the options list ;) ) 23:48:39 When do we have to send those out to get them included? 23:48:46 done 23:48:54 :) 23:49:12 dtruong: like, now, because they're going to start promoting the survey heavily next week 23:51:30 ok, everybody ok with the first two questions? 23:51:36 I'm +1 on requesting the first one. I'm not convinced of the value of the second one (what does it even mean to autoscale networks?) 23:52:30 and tbh I worry that we might be fighting an uphill battle to get anything in the survey, so I'd prefer to focus on the most useful one 23:53:07 that's true. The first question is good enough for now. 23:53:15 +1 23:54:30 Should we visit the last agenda item? 23:54:48 #agreed we will request the first q from https://etherpad.openstack.org/p/auto-scaling-user-survey-question to be added to the user survey 23:54:49 Before that, who is going to send out the email to get the questions included? 23:55:09 s/questions/question 23:55:13 ricolin would be ideal, but he isn't here 23:55:40 which makes him an even more ideal candidate ;) 23:55:47 lol 23:55:59 dtruong: unless you want to volunteer? 23:56:00 +1 23:56:13 Since it is time sensitive, I'll do it this time. 23:56:30 thanks! 23:56:51 #action dtruong to request UC to add user survey question 23:57:03 #topic quick update on advanced scaling strategies 23:57:26 ekcs: quicker update than expected, I guess, sorry 23:57:27 ok thanks 23:57:33 Been looking deeper into advanced scaling decisions. The case I mentioned at denver had to do with allocating limited pool of physical resources between various apps to optimize some objective. 23:57:38 * zaneb is out of practice at keeping meetings moving 23:57:41 I've been looking into existing work in that general realm. Med term goal is to collect and document these cases in repo and hopefully get comments on which ones are interesting. 23:57:51 Here's a paper looking at a similar scaling decision problem: 23:57:51 #link https://www.researchgate.net/publication/314296488_BATS_Budget-Constrained_Autoscaling_for_Cloud_Performance_Optimization 23:57:55 The problem they consider is how to make scaling decisions for a single app from period to period subject to a total budget over a longer period of time (say 1 month). 23:58:24 if anyone has thoughts of pointers on things in this vein, i’d love to hear/look. 23:58:40 that’s all. 23:59:38 thanks ekcs 00:00:12 When you brought it up at the PTG was my first exposure to it. neat idea, and seems most useful when scaling down isn't going to break a service just slow it down 00:00:44 joadavis: right 00:01:11 ok, this was a pretty successful first meeting :) let's wrap it up and we can continue discussing in the channel 00:01:17 thanks everyone! 00:01:19 thanks zaneb 00:01:26 #endmeeting