15:02:24 #startmeeting Marconi 15:02:25 Meeting started Tue Jul 8 15:02:24 2014 UTC and is due to finish in 60 minutes. The chair is flaper87. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:02:26 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:02:29 The meeting name has been set to 'marconi' 15:02:40 #topic roll call 15:02:46 o/ 15:02:50 o/ 15:02:50 o/ 15:02:58 o/ 15:02:58 o/ 15:03:05 o/ 15:03:39 o/ 15:03:40 The agenda is quite empty but I've some topics in mind 15:03:48 feel free to add more things as we speak 15:03:52 #link https://wiki.openstack.org/wiki/Meetings/Marconi#Agenda 15:04:10 #topic Meeting Time 15:04:38 I talked to flwang about what time would be good for him. He said that anytime after 7am his TZ would be fine 15:04:47 so I think 7am his TZ is fine :P 15:05:06 7:01 am ;) 15:05:07 7 am his TZ == ? UTC 15:05:25 vkmc: wait, I'm getting the link 15:05:43 jokes apart, 7am may not be good because the TC and project meetings are at that time 15:06:05 That's 19UTC and 20UTC 15:06:23 so, we probably want to do it at 21UTC just to make sure we have presence in both meetings 15:06:26 Thoughts? 15:06:39 I checked and the channel seems to be free at that time 15:06:46 maybe we can do 7am NZ on a different day? 15:07:02 malini: changing day and time may be harder 15:07:28 flaper87: is getting the channel the hard part? 15:07:38 no, it's remembering the meeting :P 15:07:39 hahahaha 15:07:45 my brain is not that good 15:07:48 :P 15:08:14 I'd like kgriffs to agree w/ this before doing anything so, since he's not here we won't be able to start next week 15:08:26 dont worry abt the brain..we can all ping you 15:08:36 at the same time. 15:08:41 DDOS :P 15:08:44 Lets start agreeing on 21UTC for now and try to find a better day during this week 15:09:08 we can check all the tmz in one table here http://www.timeanddate.com/worldclock/meeting.html 15:09:54 there are three meeting channels we could use, so there should be some spot that works for everybody 15:10:19 vkmc: right, I'd like to change just the time if possible 15:10:23 to avoid confussion 15:10:27 flaper87, sounds good 15:10:59 #agreed 21UTC sounds like a good time. find a better day/channel if possible 15:11:09 #topic Reviews 15:11:15 sooooooooooooooooooooooooooooooooooooooooooooo 15:11:35 Marconi seems to be moving really slow 15:11:47 it's not a complain but a warning for all of us 15:12:03 agreeed.. 15:12:05 it looks like we're having very busy times elsewhere and we need to reschedule some of our time 15:12:33 agreed, will spend time on reviews. 15:12:47 +1 15:12:50 The warning I'm raising is that whenever our time has to be scheduled on other things it's important to dedicate the little time we have for marconi on reviews 15:13:03 that until we have enough time to code as well 15:13:15 this will facilitate people dedicating time on marconi to move forward 15:13:23 and keep working on the things they're working on 15:13:25 +1 15:13:42 so stop paying attention to what I'm saying here and go do reviews 15:13:50 ok, ignore the last message 15:13:52 :P 15:14:01 * malini already at that 15:14:03 ;) 15:14:13 awesome, that's all I have to say here for now 15:14:21 there's no magic trick, it's just about priorities 15:14:55 again, if you find yourself with not enough time to code on marconi, dedicate whatever you have available on reviews 15:15:05 anything else, ayone? 15:15:23 you better agree with me or I'll stop reviewing your code 15:15:25 >.> 15:15:39 agreed. 15:15:46 #topic queue flavors: Use ID or name ? 15:15:50 sriram1: good boy 15:15:57 agreed 15:16:10 I am sure sriram1 is getting pop-tarts wired 15:16:16 ok, there's a patch up there adding the base class for flavors 15:16:19 agreed :) 15:16:33 #link https://review.openstack.org/#/c/98777/ 15:16:46 flwang and others raised a question whether we should use IDs or names there 15:16:51 before we share our thoughts 15:16:57 let me share why I went with names 15:18:00 I used names because we're already using them for pools and queues. The other reason is that flavors is not something that users can create themselves., it's an admin action. Last but not least, I wanted to be consistent with compute flavors and have something easy to remember and write 15:18:24 with all that said, I really don't mind using IDs, I just find them less readable although they're easier to handle 15:18:28 thoughts? 15:18:48 I agree on names as well, much more relatable to me. 15:18:54 I like the names better because it makes it easy to remember & is obvious on what it signifies 15:19:30 flaper87, sorry I didn't reply earlier on Gerrit 15:19:35 flavor=1 doesn't convey any info 15:19:46 vkmc: np :) 15:19:48 malini: right 15:20:02 the thing about names is that we'll have to validate them, which is not a big deal 15:20:13 we already do that for queues 15:20:18 we can reuse the same validation 15:20:19 I asked about this because of some issues that arised in Nova a long time ago with instance flavors... because they use both ids and names 15:20:30 Names make more sense. 15:20:37 vkmc: do you recall what issues were those? 15:20:39 so when flavors where deleted and created again that causes lots of inconsistencies 15:20:58 ah ok, that's because they allow users to use ids and names 15:21:11 but the usage of ids were because in many use cases they needed a great amount of flavors and names can be hard to scale 15:21:42 in this case flavors creation is an admin operation, so it should be ok 15:22:04 I guess the right question is: Will we need many queue flavors? 15:22:17 flavors are related to the storage capabilities 15:22:21 I don't think so, but my head is a bit narrow when it comes to production stuff :) 15:22:32 the combinations between them are finite for sure 15:22:43 no, I think they can be sufficiently distinct to scale. 15:23:02 it shouldnt be a problem, according to me. 15:23:08 * flaper87 is a production expert, he has a marconi instance running on a single node, single gear, single mongod openshift instance 15:23:18 :P 15:23:22 haha 15:23:24 we need oz! 15:23:45 malini: can you forward this question to him? 15:23:56 I think names are enough in this case 15:24:02 sure 15:24:23 the real problem arises if flavors are shared among tenants and regular users are allowed to create flavors 15:24:25 awesome 15:24:47 * flaper87 tries to remember what he wanted to talk about next 15:25:03 vkmc: ahhhhhh 15:25:08 vkmc: why did you say that? 15:25:11 :( 15:25:23 flavors are indeed shared between tenants 15:25:29 well, not exactly shared 15:25:32 flaper87, but the admin is the only one creating flavors 15:25:41 so.. it's 'controlled' 15:26:04 vkmc: if the users are allowed to create custom flavors, then its a whole game altogether. 15:26:10 Here's the scenario: 1 tenant wants to use a flavor that is available, at that point the admin creates/clones the flavor to the other tenant 15:26:26 sriram1, yes of course :) 15:26:28 users are not allowed to create falvors for now 15:26:35 flaper87: right 15:26:50 creating flavors means the user knows what's been deployed in terms of storage 15:26:55 and the user most know the pool name 15:27:07 since all that is admin-only so has to be the flavor as well 15:27:16 it makes sense... and I agree with all the pros of using names 15:27:17 so +1 15:27:30 awesome 15:27:36 * flaper87 loves it when vkmc agrees 15:27:50 haha when everybody agrees! 15:28:00 now I don't recall what I wanted to talk about next 15:28:03 damnit 15:28:04 Ok, I'd like to bring up the benchmark environment now. :P 15:28:09 * flaper87 should stop cursing 15:28:12 ah I remember now 15:28:19 if that's ok, flaper87? 15:28:19 #topic Notifications 15:28:29 sriram1: ops sorry, sure 15:28:31 #undo 15:28:32 Removing item from minutes: 15:28:35 #topic Benchmark 15:28:39 sriram1: floor is yours 15:28:54 ok so after some work, the benchmark env is (almost) ready 15:29:01 Its usable now. 15:29:14 sriram1: link or it ain't happen 15:29:15 but I havent been able to finish performance twaeks 15:29:19 :P 15:29:23 sure, one sec. 15:29:40 http://166.78.236.4/ 15:29:45 :o 15:30:03 I'll try to add a DNS entry for this. 15:30:06 sriram1: does it have auto-update ? 15:30:25 is there a way to trigger benchmarks form the outside world ? 15:30:53 flaper87: not yet.. that's a good question. for auto update. 15:31:13 trigger benchmarks should be possible, you should be able to connect to it from anywhere. 15:31:39 sriram1: wait, so, that link is for the marconi instance, right ? 15:31:47 flaper87: correct 15:31:53 with haproxy load balancer 15:31:56 4 webheads 15:32:01 monog replica set 15:32:05 sriram1: awesome 15:32:17 for both catlog, queues, messages. 15:32:20 I was going to said that it'd be nice to be able to trigger a locally installed benchmark script 15:32:22 there is no auth. 15:32:28 but from here is a more real scenario 15:33:06 umm, so benchmark from anywhere? 15:33:40 sriram1: as it is now I'd have to point our bench tool to the benchmark server 15:33:44 sriram1: correct ? 15:33:52 yes. 15:34:19 sriram1: I think that's fine. I was going to propose having an endpoint to trigger the benchmarks on the same server 15:34:23 but that doesn't make much sense 15:34:37 Good idea though.. 15:34:41 I mean, that would be benchmark-connection_latency 15:34:47 yes 15:35:07 it's still useful but running benches from here makes it more real, so to speak 15:35:11 anyway, we could have both 15:35:25 also since its experimental now, we might continually be making changes to the environment. 15:35:53 yes we can have both, soon. 15:36:01 I have spoken with Aazza 15:36:07 is she here? 15:37:04 hey AAzza :) 15:37:21 hi, all) 15:37:48 hello AAzza! 15:37:55 hi AAzza! 15:37:58 We were just talking about the benchmarking stuff. 15:38:18 AAzza: you can start playing around with it. 15:38:56 The environment doesnt have performance tweaks yet, which I will be working on :) 15:39:04 ok 15:39:06 awesome 15:39:09 :) 15:39:12 sriram1: thanks a lot for all the hard work there 15:39:25 sriram1: AAzza please, work together on that 15:39:39 while sriram1 is working on the server AAzza can move the bench tools forward 15:39:39 no problem :) sure, we will. 15:39:46 it's important to get that done 15:39:50 of course) 15:40:10 awesome, thank you both 15:40:14 did we decide in what way we want to store/process the stats? 15:40:40 AAzza: as of now, we dump everything on the CLI or in a json file 15:40:59 s/CLI/stdout/ 15:41:37 flaper87: yes, good. and what lib is preffereable to draw results? matplotlib, gnuplot? 15:42:03 AAzza: TBH, I've no idea. I'm sure one of these is being used elsewhere in openstack 15:42:09 lets try to figure out which one 15:42:19 or pick one if not 15:42:24 aha, understand) 15:43:34 maybe we can check how is it being done in Rally? 15:44:04 vkmc: +1 15:44:33 Good idea. 15:45:30 definetely need to look at it 15:46:10 awesome 15:46:12 anything else? 15:46:26 #topic Notifications 15:46:38 I'm starting to look at this based on what we discussed at the summit 15:46:50 I'm figuring out a good way to do the webhooks dispatch 15:46:57 without locking the whole marocni node 15:47:17 the case I'm trying to figure out is when there're are more than 500 hooks subscribed on a single topic 15:47:43 calling all those hooks can be painful so we may need some extra nodes that will do this work for us 15:48:11 just some thoughts, I'll write everything down soon 15:48:29 if you guys have ideas/feedback pls let me know 15:48:48 #topic Open Discussion 15:48:50 so .. as apart of the recent hackday program .. we (Alex .. intern at rackspace and me) created a proof of concept for notifications service 15:48:56 #undo 15:48:57 Removing item from minutes: 15:49:04 so I am wondering if this will of anything interest here 15:49:22 Obulpathi: absolutely, I had no idea you guys worked on this 15:49:30 Obulpathi: you should've shared this before :P 15:49:36 Obulpathi: can you post ur github rep (if you have it) 15:49:37 Obulpathi: is it pushed somehwere? 15:49:48 the core idea is to use lightweight containers to execute templatized or user given code 15:50:04 hmm .. its a proof of concept .. 15:50:14 its contains passwords and credentials 15:50:21 Obulpathi: even a POC is useful 15:50:28 mmh, can you write the idea down somewhere? 15:50:31 so I will clean it up and sent it to you guys fore review by today evening 15:50:40 Obulpathi: awesome 15:50:42 thanks 15:50:42 Obulpathi: tht will be awesome! 15:50:44 sure ... I will document and mail it 15:50:49 perfect 15:51:00 also I have another small item to discuss 15:51:06 Last week I create a logo .. 15:51:17 Obulpathi: wait, lemme open the discussion 15:51:18 again this is proof of concept for Naav 15:51:24 #topic Open Discussion 15:51:35 Obulpathi: so, is this logo somewhere? 15:51:43 yes sir 15:51:45 https://docs.google.com/drawings/d/1bH5_h2BKD4oZxG1qmHrFLeEH2VfOguwACOHJoVKTRPs/edit 15:51:50 its a prototype .. 15:52:02 Naav means the vessel to carry the messages 15:52:20 so a boat depicting the Naav service 15:52:48 and the letters "N" "A" "A" "V" inside the logo represent the messages in a queue 15:53:18 HA! Nice! 15:53:20 looks great ! 15:53:23 subtle and precise 15:53:35 the design is asymmetrical to signify that messages are traveling in the direction of the sharp end 15:53:57 wow, looks like a lot of thought has gone into this :) 15:54:01 thank you :) 15:54:10 thanks to Balaji and Malini for feedback 15:54:29 wait..did I give feeback? :D 15:54:54 so if you guys like it ... I can get a better logo made 15:55:06 I think you forgot malini :D 15:55:30 malini has a high throughput on suggestions ;) 15:55:46 great stuff guys 15:55:49 great stuff! 15:55:50 yeah..right..I am good at telling everybody else what to do :-P 15:55:59 it looks great :) it have a lot of meaning 15:56:06 thank vkmc ;) 15:56:09 :) 15:56:25 Obulpathi: thanks for the work there 15:56:28 ok guy, 4mins left 15:56:33 anything else you guys want to discuss? 15:56:38 thanks flaper87 15:56:46 anything new from our TC rep? 15:56:58 will mail you the write up and code for containers .. please go through it .. any feedback will be appreciated 15:57:06 malini: not about the email, he's been quite busy. I'll keep you guys updated 15:57:16 Obulpathi: +1 15:57:18 will do 15:57:20 thanks flaper87! 15:57:29 thanks guys 15:57:38 right on! 15:57:42 thanks all :) 15:57:44 closing the meeting 15:57:50 take care all, tty next week 15:57:56 bye 15:58:00 (yeah right, I'll ping you all in the channel) 15:58:05 #endmeeting