| *** ricolin has joined #openstack-auto-scaling | 00:48 | |
| *** ekcs has quit IRC | 01:05 | |
| *** witek has joined #openstack-auto-scaling | 07:56 | |
| witek | good morning | 09:00 |
|---|---|---|
| aspiers | hi | 09:08 |
| witek | hi Adam | 09:09 |
| aspiers | is there supposed to be a meeting now? | 09:09 |
| witek | that is what eavesdrop says | 09:09 |
| aspiers | I guess ricolin forgot ;-) | 09:10 |
| ricolin | o/ | 09:11 |
| witek | hi Rico | 09:11 |
| ricolin | actually got call to a meeting right now:( | 09:11 |
| aspiers | no worries | 09:11 |
| witek | ricolin: I have listed Monasca related AI from our session here https://wiki.openstack.org/wiki/MonascaTrainPTG#Auto-scaling_SIG | 09:14 |
| ricolin | And I'm back:) | 09:20 |
| ricolin | witek, thx! | 09:21 |
| ricolin | I sill need to send ML out for summary, I will do it today | 09:23 |
| witek | I think we will start adding documentation to Monasca repo for now | 09:24 |
| witek | we can link it to auto-scaling docs then | 09:24 |
| ricolin | witek, the use case or document can go in to auto-scaling docs too, we just need to create an nice index page for all docs:) | 09:32 |
| witek | that would be nice, please add me to review when you have the starting page ready | 09:34 |
| aspiers | ricolin: I already created that ;-) | 09:34 |
| aspiers | https://review.opendev.org/#/c/656423/ | 09:34 |
| aspiers | it has V+1 now, just waiting for reviews | 09:34 |
| ricolin | aspiers, yep, when I mean nice index I mean that patch:) | 09:35 |
| aspiers | ah OK ;-) | 09:35 |
| witek | nice, thanks aspiers | 09:36 |
| ricolin | IMO we also need a general information document too:) | 09:36 |
| aspiers | currently I guess that is https://wiki.openstack.org/wiki/Auto-scaling_SIG | 09:37 |
| ricolin | aspiers, I remember in PTG we also talk about move wiki info in to the docs too right? | 09:37 |
| aspiers | yeah, I don't think that's urgent though | 09:38 |
| ricolin | It's not urgent indeed | 09:39 |
| witek | aspiers: Found one obsolete detail in template. Other than that looks nice. | 09:47 |
| aspiers | witek: good catch | 09:48 |
| *** openstackgerrit has joined #openstack-auto-scaling | 15:36 | |
| openstackgerrit | Adam Spiers proposed openstack/auto-scaling-sig master: Initial Sphinx structure https://review.opendev.org/656423 | 15:36 |
| *** witek has quit IRC | 16:06 | |
| joadavis | I took some initiative to summarize goals discussed in the PTG - https://wiki.openstack.org/wiki/Auto-scaling_SIG#Goals Feel free to reword to make them more 'official' | 16:39 |
| joadavis | I think we agree that the wiki should be a very high level landing page where it is easy to find links off to the detailed documents. | 16:40 |
| joadavis | question - do we need a 'theory of auto-scaling' document? | 16:46 |
| joadavis | Yesterday I talked to a customer who tried autoscaling with an older ceilometer install. | 16:46 |
| joadavis | They tried turning their sample rate to a small number to make auto-scaling more responsive | 16:47 |
| joadavis | but then found that the ceilometer database grew 'very large' | 16:47 |
| joadavis | So having a description of the 'theory of auto-scaling' might help new users understand that gathering a lot of samples takes up space. But that it might not be necessary, as we don't want to auto-scale on a whim. | 16:48 |
| joadavis | in theory, we want to establish thresholds that are below where the system has a problem, and only scale when the system is consistently passing that threshold over time. this helps avoid scaling in and out too often (which can be wasteful) | 16:49 |
| *** ricolin has quit IRC | 17:07 | |
| aspiers | joadavis: that doc sounds like a great idea to me | 17:38 |
| aspiers | I am definitely not an SME in this space however (despite having a patent in it!) | 17:39 |
| *** ekcs has joined #openstack-auto-scaling | 17:39 | |
| openstackgerrit | Zane Bitter proposed openstack/auto-scaling-sig master: Initial Sphinx structure https://review.opendev.org/656423 | 19:30 |
| openstackgerrit | Merged openstack/auto-scaling-sig master: Initial Sphinx structure https://review.opendev.org/656423 | 19:45 |
| zaneb | I think it's meeting time again but ricolin is AWOL | 23:03 |
| * zaneb reads scrollback from this morning | 23:03 | |
| ekcs | hello | 23:03 |
| dtruong | o/ | 23:03 |
| dtruong | Do we want to start the meeting without ricolin? | 23:05 |
| zaneb | yeah, let's get one in the books :) | 23:06 |
| zaneb | #startmeeting auto-scaling-sig | 23:06 |
| openstack | 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 |
| openstack | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 23:06 |
| *** openstack changes topic to " (Meeting topic: auto-scaling-sig)" | 23:06 | |
| openstack | The meeting name has been set to 'auto_scaling_sig' | 23:06 |
| zaneb | #chair dtruong | 23:06 |
| openstack | Current chairs: dtruong zaneb | 23:06 |
| zaneb | o/ | 23:06 |
| dtruong | o/ | 23:06 |
| joadavis | o/ | 23:07 |
| zaneb | do we have an agenda written down anywhere? | 23:07 |
| dtruong | I don't think so | 23:07 |
| joadavis | (I didn't think we had a meeting until next week, but just happened to have the chat tab open) | 23:07 |
| ekcs | I’m making a place topics now. | 23:08 |
| ekcs | #link https://etherpad.openstack.org/p/auto-scaling-IRC-topics | 23:08 |
| ekcs | now adding it to wiki page. | 23:08 |
| zaneb | pretty sure I used the calendar from eavesdrop.openstack.org, so this should be the right week | 23:08 |
| zaneb | that links to https://wiki.openstack.org/wiki/Meetings/AutoScalingSIGMeeting (which is empty) | 23:09 |
| dtruong | yea, it's the right week | 23:09 |
| * zaneb edits https://wiki.openstack.org/wiki/Meetings/AutoScalingSIGMeeting to point to the etherpad | 23:10 | |
| zaneb | so the docs patch merged, yay | 23:11 |
| zaneb | #link https://docs.openstack.org/auto-scaling-sig/latest/ | 23:11 |
| joadavis | cool | 23:11 |
| dtruong | nice | 23:12 |
| dtruong | joadavis I saw your comments earlier about 'theory of auto-scaling'. | 23:12 |
| dtruong | Definitely think that would be helpful for operators. | 23:13 |
| joadavis | Yes. I started a wiki - https://wiki.openstack.org/wiki/Auto-scaling_SIG/Theory_of_Auto-Scaling | 23:13 |
| zaneb | #topic 'theory of autoscaling doc' | 23:13 |
| *** openstack changes topic to "'theory of autoscaling doc' (Meeting topic: auto-scaling-sig)" | 23:13 | |
| joadavis | I was just hacking on it when we started | 23:13 |
| joadavis | pretty rough draft, and I should drop the plantuml part (doesn't render nicely as text) | 23:13 |
| zaneb | I totally agree that we should have a theory of autoscaling doc | 23:14 |
| joadavis | 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 |
| zaneb | although I'm not sure that the specific example you mentioned belongs in there - maybe that should be in a 'Ceilometer gotchas' doc | 23:14 |
| joadavis | I was hoping we could gather a wide range of 'gotchas'. Just having one about ceilometer isn't very helpful | 23:15 |
| zaneb | there's plenty of very ceilometer-specific gotchas to go round ;) | 23:16 |
| joadavis | maybe in the repo we have a subdirectory for experiences as a catch-all | 23:16 |
| zaneb | 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 |
| ekcs | very nice. | 23:17 |
| dtruong | The ones you have are a good start. I'll try to think of any to add. | 23:17 |
| zaneb | 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:19 |
| joadavis | Either way. I don't mind editing in a repo. Though will need to convert to .rst | 23:20 |
| joadavis | 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:21 |
| dtruong | Let's keep editing the wiki for a bit longer to give people a chance to contribute. | 23:22 |
| joadavis | but I also want to see that on the main wiki page | 23:22 |
| joadavis | :thumbsup: | 23:22 |
| ekcs | sounds good. | 23:23 |
| zaneb | 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:23 |
| ekcs | the downside is the bigger it gets the more work it is to convert to rst. | 23:24 |
| ekcs | always a trade off. | 23:24 |
| zaneb | 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:24 |
| joadavis | agreed. having a single wiki landing page that just points to the repos would be great | 23:25 |
| zaneb | +1 | 23:25 |
| zaneb | ok, let's continue to iterate on that wiki page until the next meeting in 2 weeks | 23:26 |
| dtruong | sounds good | 23:26 |
| zaneb | #action hack on the Theory of Autoscaling wiki page | 23:26 |
| zaneb | #link https://wiki.openstack.org/wiki/Auto-scaling_SIG/Theory_of_Auto-Scaling | 23:26 |
| zaneb | #agreed move wiki content to docs repo after next meeting | 23:27 |
| zaneb | any other topics? | 23:27 |
| dtruong | i wanted to talk about the user survey | 23:28 |
| zaneb | #topic user survey | 23:28 |
| *** openstack changes topic to "user survey (Meeting topic: auto-scaling-sig)" | 23:28 | |
| dtruong | i wonder if we wanted to propose auto-scaling questions in the user survey? | 23:28 |
| zaneb | we would have to be quick :) | 23:29 |
| zaneb | dtruong: do you have any in mind? | 23:29 |
| dtruong | Maybe something like "are you auto-scaling in your OpenStack cloud?". "If so, which openstack projects are you using to do auto-scaling?" | 23:29 |
| joadavis | 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 |
| zaneb | 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:31 |
| joadavis | good point. Though if someone is just using Ceilometer and Heat that might not be clear | 23:32 |
| zaneb | another possible question might be "Are you interested in auto-scaling for user workloads/infrastructure/both/neither" | 23:32 |
| dtruong | Maybe the second question should be "which openstack projects or other projects are you using to do auto-scaling?" | 23:33 |
| zaneb | ah true, they might have userspace parts in the stack | 23:33 |
| dtruong | I'm wondering if people are using a combination of openstack projects and something like prometheus to do auto-scaling. | 23:34 |
| zaneb | yeah, that would be interesting | 23:35 |
| joadavis | it would be interesting to know what they want to scale (compute, storage, networking) | 23:36 |
| zaneb | #link https://etherpad.openstack.org/p/auto-scaling-user-survey-question | 23:38 |
| joadavis | 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 |
| zaneb | let's brainstorm the exact wording on that etherpad ^ | 23:39 |
| dtruong | joadavis I added your question on the resources that people are scaling. I think that would be good to know. | 23:44 |
| zaneb | 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 |
| joadavis | 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:44 |
| zaneb | tbh those seem to relate more to the auto-healing case than auto-scaling to me | 23:45 |
| zaneb | time check - 15mins to go and ekcs has one more item on the agenda | 23:46 |
| dtruong | I'm ok with the two questions as they are now. | 23:48 |
| joadavis | (if I was being a pain I'd move Monasca to the top of the options list ;) ) | 23:48 |
| dtruong | When do we have to send those out to get them included? | 23:48 |
| zaneb | done | 23:48 |
| joadavis | :) | 23:48 |
| zaneb | dtruong: like, now, because they're going to start promoting the survey heavily next week | 23:49 |
| dtruong | ok, everybody ok with the first two questions? | 23:51 |
| zaneb | 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:51 |
| zaneb | 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:52 |
| dtruong | that's true. The first question is good enough for now. | 23:53 |
| joadavis | +1 | 23:53 |
| joadavis | Should we visit the last agenda item? | 23:54 |
| zaneb | #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 |
| dtruong | Before that, who is going to send out the email to get the questions included? | 23:54 |
| dtruong | s/questions/question | 23:55 |
| zaneb | ricolin would be ideal, but he isn't here | 23:55 |
| zaneb | which makes him an even more ideal candidate ;) | 23:55 |
| dtruong | lol | 23:55 |
| zaneb | dtruong: unless you want to volunteer? | 23:55 |
| joadavis | +1 | 23:56 |
| dtruong | Since it is time sensitive, I'll do it this time. | 23:56 |
| zaneb | thanks! | 23:56 |
| zaneb | #action dtruong to request UC to add user survey question | 23:56 |
| zaneb | #topic quick update on advanced scaling strategies | 23:57 |
| *** openstack changes topic to "quick update on advanced scaling strategies (Meeting topic: auto-scaling-sig)" | 23:57 | |
| zaneb | ekcs: quicker update than expected, I guess, sorry | 23:57 |
| ekcs | ok thanks | 23:57 |
| ekcs | 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 |
| * zaneb is out of practice at keeping meetings moving | 23:57 | |
| ekcs | 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 |
| ekcs | Here's a paper looking at a similar scaling decision problem: | 23:57 |
| ekcs | #link https://www.researchgate.net/publication/314296488_BATS_Budget-Constrained_Autoscaling_for_Cloud_Performance_Optimization | 23:57 |
| ekcs | 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:57 |
| ekcs | if anyone has thoughts of pointers on things in this vein, i’d love to hear/look. | 23:58 |
| ekcs | that’s all. | 23:58 |
| zaneb | thanks ekcs | 23:59 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!