16:02:08 #startmeeting watcher 16:02:08 Meeting started Wed Nov 4 16:02:08 2015 UTC and is due to finish in 60 minutes. The chair is acabot_. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:02:09 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:02:12 The meeting name has been set to 'watcher' 16:02:16 o/ 16:02:19 o/ 16:02:20 o/ 16:02:30 o/ 16:02:31 hi everyone 16:02:53 today agenda is #link https://wiki.openstack.org/wiki/Watcher_Meeting_Agenda#11.2F4.2F2015_Agenda: 16:04:06 #topic annoucements 16:04:45 We had some great meetigns at the summit :-) Thanks to everyone involved 16:05:22 Also I have an update around the Meetup 16:05:53 sballe: you mean the mid-cycle in january ? 16:06:07 Orran/BU is looking at hosting it because I am not sure Intel can. 16:06:19 Also Boston is a better place than Hudson, MA 16:06:29 ok 16:06:51 maybe we can already fix the dates today ? 16:06:56 I will follow up with him. We talked about htis yesterday. They already hosted a midt-cycle for keysotn ehtis summer 16:07:23 we were talking about 26 and 27 and maybe 28. Orran needs to see when he has room available 16:07:27 s/rooms 16:07:52 ok 16:08:27 coming back to the agenda, we add an email from ttx about using "OpenStack Watcher" as the project name 16:08:52 acabot_: I didn't see the email 16:08:57 its confusing because of the big tent inclusion so please do not use it anymore, we should stick to "Watcher" for now 16:09:13 #link http://lists.openstack.org/pipermail/openstack-dev/2015-November/078136.html 16:09:30 oh ok so it was the "OpenStacK" piece that was the issue 16:09:47 yes sorry if I was unclear 16:09:55 Watcher is OK for the project name 16:10:00 ok cool! 16:10:16 any other annoucement ? 16:10:49 nope 16:11:09 #topic Review Action Items 16:11:36 the watcher-specs repo is now live https://github.com/openstack/watcher-specs 16:11:44 yeah!!! 16:11:57 jwcroppe submit a first patch to add all templates 16:12:09 #link https://review.openstack.org/#/c/240475/ 16:12:27 if everyone can have a look at it 16:13:03 we also have 4 core contrib on watcher-specs sable, jwcroppe, jed56 and acerbate 16:13:19 acabot_: watcher and python-watcherclient internal bugs have been moved to launchpad. We have to prioritize them now 16:13:59 #link https://bugs.launchpad.net/watcher 16:14:16 does anyone wants to start a bug triage ? 16:15:14 acabot_: I can do it 16:15:19 acabot_: I think one of the b-com folks should do that given that you have it up and running. 16:15:27 ok 16:15:38 As soon as dtardivel and I have my env up and running I can help with bugs 16:15:40 yeah i think that makes the most sense for the time being 16:15:46 #action dtardivel start the bug triage 16:16:29 ok what about devstack plugin for watcher ? 16:16:59 still a TODO for me, no updates there. hoping to work on that the end of this week and beginning of next 16:17:10 that is important IMHO but I just realized this morning that there are many pieces to make the end-to-end wathcer thing work 16:17:23 tpeoples: ok thanks 16:17:27 so I am not sure what the desvtack plug-in means 16:17:50 does it mean watcher+wathcher metring chain + agent? 16:18:42 actually we didn't look at it in detail as there are many changes in devstack for Mitaka 16:18:43 I think that reading ht metrics from ceilomters instead of having to use the metring chain+ agent might be a higher priority and would allow a clean integration wiht devstack 16:19:00 +1 16:19:47 ok 16:19:56 it would also make it easier for deployments using Ceilometer to use Watcher 16:20:05 I am fine with using ceilometer to start with for devstack and not ceilosca or monasca 16:20:09 ok so lets write a blueprint on this and give it high priority 16:20:16 adding agents is usually discouraged 16:20:17 acabot_: +1 16:20:31 edleafe: I agree 16:20:42 Hello from Moscow Nova LB team, this is Dmitry Demidov. Let me introduce my collegues Alexander Chadin (alexchad) and Alexander Stavitsky (alexstav). 16:20:44 edleafe: +1 16:21:04 hello everyone 16:21:07 Hi all 16:21:11 hello! 16:21:14 hi. 16:21:15 hi guys 16:21:24 hi 16:21:24 hi 16:21:35 What is the Nova LB? I thougth he LB effort were in Neutron 16:21:50 unless lB doesn't stand for load-balancer 16:21:55 it was the topic that came up in one of the nova unconference sessions 16:21:56 yes 16:21:58 Dmitry: can you share the blueprint link ? 16:22:27 one moment please 16:22:44 ok let's do that under open topics. 16:22:53 https://blueprints.launchpad.net/nova-loadbalancer/+spec/nova-lb-overview 16:22:57 #link 16:23:02 sballe: we discussed it on friday, there are interesting things in the Nova LB and we need to see how we can integrate it in Watcher 16:23:10 yeah 16:23:28 https://docs.google.com/document/d/1G2jYSeDzLD2JjAqZneKGQi2opVI-FIUhu6DeFhGE99Y/edit?usp=sharing 16:23:32 we are about integrating our project in Watcher 16:23:34 sballe: the nova team agreed it should be done in an external project and suggest to join Watcher effort 16:23:35 Here it is our specs 16:24:15 ok. I am just reluctant to have another LB effort beside the neutron one 16:24:35 We need to understand if and how it overlap wth neutron LB. 16:24:37 LB isn't the right term, it is the reactive part of watcher for optimization 16:24:49 I dont think it's LB like we use to have in Neutron ;-) 16:25:14 ok then it should be renamed IMHO 16:25:34 because other folks are going to not like the idea either. 16:25:35 or just integrated into Watcher :) 16:25:38 we should all take a look at the blueprint and specs and see how Dmitry's team can improve Watcher 16:25:41 Yep, it's not assosiated with neutron :) 16:25:44 it looks like decision engine inside watcher 16:26:27 acabot_: Can we get back to the devstack and ceilomter blueprint. Who has the action to write it up? 16:26:45 and it sounds like tpeoples will work on it 16:27:04 tpeoples: Will you have the time to work on it this year? I think this is super hight priority 16:27:39 sballe: we plan to do it at b-com so I will write down the blueprint 16:27:50 acabot_: great! 16:28:14 #action acabot write the blueprint for collecting metrics with ceilometer 16:28:20 i will have some time to work on it but if it is high priority then i would suggest someone from bcom since i can't be 100% yet ... acabot_ ok 16:28:22 acabot_: so both ceilomter and watcher integration? and devstack and watcher plug-in? 16:28:39 so two BPs? 16:28:59 we should definitely add a blueprint for devstack if we plan to work on it 16:29:03 yes, i would say two bps 16:29:18 tpeoples: can you submit a blueprint for devstack ? 16:29:19 i can work on the BP for devstack integration 16:29:21 yes 16:29:30 tpeoples: acabot_ +1 16:29:35 ok great, I will handle the other one on ceilometer 16:30:07 #action tpeoples write the blueprint for devstack watcher plugin 16:30:08 acabot_: +1 16:30:39 Dmitry: could you please submit a blueprint regarding how you see the Nova LB integration ? We will iterate on this later 16:30:58 and please rename LB :) 16:31:06 we have already submitted two new blueprints 16:31:17 about 10 minutes ago:) 16:31:58 ok great, #link https://blueprints.launchpad.net/watcher/+spec/watcher-overload-underload #link https://blueprints.launchpad.net/watcher/+spec/add-new-watcherclient-commands 16:32:10 so 16:32:19 we have one big spec 16:32:29 need link? 16:32:42 the one you shared previously ? 16:32:43 it was introduced at Tokyo 16:32:46 yes 16:33:09 #link https://docs.google.com/document/d/1G2jYSeDzLD2JjAqZneKGQi2opVI-FIUhu6DeFhGE99Y/edit to add it to the minutes 16:33:53 #topic Blueprint/Bug Review and Discussion 16:34:14 alexchadin: Do you have a working prototype with nova or is this still a concept? 16:34:19 yes 16:34:33 overload underload is working fine 16:34:40 ok cool! thx 16:34:47 we have repo on github 16:35:05 alexchadin: please share the link 16:35:10 how can we show our use cases at work? 16:35:15 one moment 16:35:29 record youtube video?:) 16:35:47 alexchadin: yes why not ? 16:35:47 https://github.com/Stavitsky/nova/tree/loadbalancer-client 16:35:52 okay 16:35:58 we will record it 16:36:09 to the next meeting 16:36:17 alexchadin: Where do you get the metrics you are using? 16:36:41 we collect it from compute nodes 16:36:45 to nova db 16:36:47 with nova-conductor 16:36:48 via an agent? 16:36:52 oh I see 16:37:44 we have expanded set of data we get from nodes 16:38:06 To collect CPU and RAM 16:38:35 it already balances vms among the nodes 16:38:40 we'll need to find a way to get all the metrics we need in a standard way 16:38:56 sballe: +1 16:39:41 What do you mean by 'standard way'? 16:40:36 common way 16:40:55 so watcher has one way to get the data... 16:40:59 alexchadin: does it migrate existing nodes to balance? Or simply create them in a more balanced arrangement? 16:41:20 first 16:41:33 and thta way should be extensible and easy to lugin new metrics 16:41:36 we use nova-migrate 16:41:58 s/plugin 16:42:34 it migrates existing ones 16:42:46 alexchadin: ok, thanks 16:43:37 ok next topic is blueprints review 16:43:39 it's a good idea to use plugin way 16:43:43 sorry 16:44:08 as we discussed in Tokyo, the first use case we want to handle is https://blueprints.launchpad.net/watcher/+spec/nishi-ahuja-energy-efficienct-dc 16:44:48 as soon as watcher-specs is ready, we need to define in more details what we need to do to complete this blueprint 16:44:49 acabot_: Yeah I have asked Nishi to split it up into 3 BPs but I think she ran out of time 16:45:04 acabot_: +1 16:45:10 sballe: do you think Nishi can handle specs on this ? 16:45:38 I can help her. The first one we will be tackling is: • Work load migration based on power and thermal data. 16:46:20 I will work with her over the next week to get this done 16:46:28 #action sballe add specs for blueprint on energy efficiency 16:47:05 regarding jwcroppe patch, we can probably merge it tomorrow 16:47:21 Ok. I will review it later today 16:47:22 and start from templates 16:47:28 ok great 16:47:48 we already talked about bugs, anything to add here ? 16:48:29 acabot_: did we get core access to the specs repo? 16:48:55 tpeoples: yes, jwcroppe, sballe, acabot & jed56 16:48:59 ok cool 16:49:13 #topic Open Discussion 16:49:36 does anyone had a look at ceilosca ? 16:50:02 I had extensive discussions with the team taht created ceilosca at the summit 16:50:44 they suggested that unless we need the ceilometer APIs to just go to Monasca but that Ceilosca will scale better then Ceilomter 16:52:04 But for devstack I would suggest we stick with Ceilomter. for production we'll need to support either Monasca or Ceilosca or both 16:52:06 does ceilosca provides any other advantage than scalability ? 16:52:24 compare to ceilometer I mean 16:52:34 if you already have ceilomter it gives you API compatibiltiy 16:53:04 ok 16:53:28 I would suggest we skip it for now 16:53:37 lets stick to ceilometer now with a blueprint 16:53:42 sballe: +1 16:53:42 We can revisit this decision for the next release 16:54:07 we had a discussion with vmahe about moving our diagrams on the public wiki 16:54:20 acabot_: Good idea! 16:54:30 here - sorry - calendar was wrong :( 16:54:34 but its pretty hard to maintain architectural diagrams on the wiki 16:54:40 jwcroppe: np. Welcome 16:54:45 yes, we should describe those diagrams as ascii text 16:54:50 any other solution on that ? 16:54:54 http://asciiflow.com/ 16:55:10 ascii diagrams are good, but also a nightmare to depict some things 16:55:13 that is just horrible :-( 16:55:21 jwcroppe: +1-- 16:55:29 yes but it's easier to read than XMI :-) 16:55:36 before we start moving all this drawing stuff, I would like to use the right tool... 16:55:51 +1 16:55:55 the following tool looks great http://asciidoctor.org/docs/asciidoctor-diagram/ 16:56:18 What are the other teams doing? 16:56:21 this is a much debated subject :) I personally don't mind using Google slides and draw in there 16:56:29 it integrates with PlantUML for describing class diagrams, sequence diagrams, ... 16:56:56 It's harder to version your google slides 16:56:57 once we nail down the architecture, it shouldn't be changing that much... 16:57:00 http://asciiflow.com/ is recommended in the template for specs 16:57:31 can we give a try to asciidoctor ? 16:57:42 for database and architecture schema ? 16:57:49 the good point with ascii description is that it can be handled in the git repo and with git-review as well 16:58:08 so, about integrating nova lb in Watcher, we will record video with our use cases to show how it works. 16:58:15 your diagrams can be associated to a given version of the code as well 16:58:21 I am fine with giving asciidoctor a try as long as we can change if it doesn't work 16:58:22 alexchadin: ok thx 16:58:37 sballe: +1 16:59:10 vmahe_: lets try to build 2 diagrams for next week ? 16:59:19 all right 16:59:24 acabot_: vmahe_ +1 16:59:28 ok great 16:59:37 so its time to end the meeting 16:59:42 thanks 16:59:42 did anyone have any major concern with the specs docs I pushed up? Kudos to the nova team for providing the baseline :) 16:59:49 OK. bye see you in #openstack-watcher 16:59:59 jwcroppe: we will merge it tomorrow 17:00:06 thx 17:00:09 thanks! 17:00:09 ttyl 17:00:16 #endmeeting