| *** amitgandhi has joined #openstack-marconi | 00:05 | |
| *** amitgandhi has quit IRC | 00:09 | |
| *** kgriffs_afk is now known as kgriffs | 00:23 | |
| *** kgriffs is now known as kgriffs_afk | 00:33 | |
| *** flaper87 is now known as flaper87|afk | 00:50 | |
| *** kgriffs_afk is now known as kgriffs | 01:24 | |
| *** kgriffs is now known as kgriffs_afk | 01:33 | |
| *** kgriffs_afk is now known as kgriffs | 02:24 | |
| *** kgriffs is now known as kgriffs_afk | 02:34 | |
| *** kgriffs_afk is now known as kgriffs | 03:25 | |
| *** kgriffs is now known as kgriffs_afk | 03:34 | |
| *** kgriffs_afk is now known as kgriffs | 04:25 | |
| *** kgriffs is now known as kgriffs_afk | 04:34 | |
| *** kgriffs_afk is now known as kgriffs | 05:25 | |
| *** kgriffs is now known as kgriffs_afk | 05:35 | |
| *** kgriffs_afk is now known as kgriffs | 06:26 | |
| *** kgriffs is now known as kgriffs_afk | 06:35 | |
| *** ykaplan has joined #openstack-marconi | 06:42 | |
| *** flaper87|afk is now known as flaper87 | 06:51 | |
| *** kgriffs_afk is now known as kgriffs | 07:26 | |
| *** kgriffs is now known as kgriffs_afk | 07:36 | |
| *** ykaplan has quit IRC | 07:39 | |
| *** ykaplan has joined #openstack-marconi | 07:42 | |
| openstackgerrit | Flavio Percoco proposed a change to stackforge/marconi: Implement embedded marconi-server execution https://review.openstack.org/44749 | 07:45 |
|---|---|---|
| openstackgerrit | Flavio Percoco proposed a change to stackforge/marconi: Run functional tests under tox https://review.openstack.org/44723 | 07:45 |
| *** kgriffs_afk is now known as kgriffs | 08:27 | |
| *** fifieldt has quit IRC | 08:35 | |
| *** kgriffs is now known as kgriffs_afk | 08:36 | |
| *** key4 has joined #openstack-marconi | 08:51 | |
| openstackgerrit | Flavio Percoco proposed a change to stackforge/marconi: Implement embedded marconi-server execution https://review.openstack.org/44749 | 08:57 |
| *** kgriffs_afk is now known as kgriffs | 09:27 | |
| *** kgriffs is now known as kgriffs_afk | 09:37 | |
| *** al-maisan_ is now known as al-maisan | 09:40 | |
| *** ykaplan has quit IRC | 10:23 | |
| *** kgriffs_afk is now known as kgriffs | 10:28 | |
| *** kgriffs is now known as kgriffs_afk | 10:37 | |
| *** oz_akan_ has joined #openstack-marconi | 11:07 | |
| *** oz_akan_ has quit IRC | 11:11 | |
| *** flaper87 is now known as flaper87|afk | 11:16 | |
| *** ykaplan has joined #openstack-marconi | 11:24 | |
| *** flaper87|afk is now known as flaper87 | 11:28 | |
| *** kgriffs_afk is now known as kgriffs | 11:28 | |
| *** tedross has joined #openstack-marconi | 11:37 | |
| *** kgriffs is now known as kgriffs_afk | 11:37 | |
| *** flaper87 is now known as flaper87|afk | 11:41 | |
| *** flaper87|afk is now known as flaper87 | 11:58 | |
| *** flaper87 is now known as flaper87|afk | 12:10 | |
| *** oz_akan_ has joined #openstack-marconi | 12:12 | |
| *** _alexr_ has joined #openstack-marconi | 12:15 | |
| *** kgriffs_afk is now known as kgriffs | 12:28 | |
| *** oz_akan_ has quit IRC | 12:32 | |
| *** oz_akan_ has joined #openstack-marconi | 12:33 | |
| oz_akan_ | hi all | 12:37 |
| *** kgriffs is now known as kgriffs_afk | 12:38 | |
| *** kgriffs_afk is now known as kgriffs | 12:59 | |
| *** ayoung has joined #openstack-marconi | 13:06 | |
| *** flaper87|afk is now known as flaper87 | 13:08 | |
| flaper87 | oz_akan_: hey :) | 13:08 |
| oz_akan_ | flaper87: how are you today? | 13:08 |
| flaper87 | oz_akan_: alll good, you? | 13:09 |
| oz_akan_ | flaper87: great thanks | 13:09 |
| oz_akan_ | yesterday was holiday here, so double good :) | 13:09 |
| kgriffs | good afternoon/morning folks | 13:09 |
| flaper87 | oz_akan_: hehehehe | 13:10 |
| flaper87 | kgriffs: morning :) | 13:10 |
| kgriffs | I put together IKEA furniture yesterday. I bet you are *all* jealous. | 13:10 |
| openstackgerrit | Flavio Percoco proposed a change to stackforge/marconi: Implement embedded marconi-server execution https://review.openstack.org/44749 | 13:13 |
| oz_akan_ | :) | 13:14 |
| flaper87 | https://review.openstack.org/#/q/status:open+project:stackforge/marconi+branch:master+topic:refactor-system-tests,n,z | 13:14 |
| flaper87 | ssshhhhhhh, don't say those things in here. | 13:14 |
| flaper87 | my gf is trying to convince me to go to Ikea | 13:14 |
| kgriffs | LOL | 13:17 |
| flaper87 | soooo, guys, we need to discuss the API thing before today's meeting | 13:18 |
| openstackgerrit | Flavio Percoco proposed a change to stackforge/marconi: Implement embedded marconi-server execution https://review.openstack.org/44749 | 13:25 |
| oz_akan_ | flaper87: kgriffs have you guy started to review proxy code? | 13:26 |
| kgriffs | oz_akan_: sorry, not yet. I am hoping to get to it later today | 13:27 |
| flaper87 | oz_akan_: nope, will start doing that today, I've spent some time making functional tests work under tox and preparing things for today's meeting | 13:27 |
| oz_akan_ | ok | 13:28 |
| kgriffs | flaper87: yes, we need to do that. Is now a good time? | 13:28 |
| flaper87 | yup | 13:28 |
| flaper87 | it is | 13:28 |
| kgriffs | ok | 13:28 |
| kgriffs | so, my take on it is this: | 13:28 |
| *** amitgandhi has joined #openstack-marconi | 13:28 | |
| kgriffs | judging by the survey and some comments made by TC members, it seems like it may not be in our best interest to pursue an AMQP driver. The semantics we have defined in the course of designing the API simply don't line up well with it, and I am hesitant to redesign the API to make it work at this point in the game. | 13:30 |
| kgriffs | Am I totally off base here? | 13:31 |
| *** vkmc has joined #openstack-marconi | 13:33 | |
| * kgriffs watches a tumbleweed roll by | 13:33 | |
| flaper87 | you're not. I agree with you w.r.t our API not lining up fine with AMQP technologies but I don't want us to exclude the possibility to redesign some parts of our API in the next version. I'm not saying we should do that now | 13:33 |
| kgriffs | ok, so we may be able to do something in v2.0 in order to better support AMQP backends | 13:34 |
| kgriffs | but for now it isn't practical? | 13:34 |
| flaper87 | correct, as for now, those backends can be implemented as third-party libraries w/ partial - or aweful workarounds - support of our API | 13:35 |
| amitgandhi | i agree | 13:35 |
| flaper87 | awful* | 13:35 |
| flaper87 | I also think we should develop another backend that can be used in production environments | 13:37 |
| kgriffs | ok. That will also give us time to gather feedback on integration use cases with AMQP so we have a better idea of people's real-world needs | 13:37 |
| kgriffs | flaper87: +1 | 13:37 |
| kgriffs | (for the other backend) | 13:37 |
| flaper87 | kgriffs: exactly (for the gather feedback) | 13:38 |
| flaper87 | My fear about supporting AMQP brokers is that, it aint scale!!! :D | 13:38 |
| flaper87 | we'll still have one of the issues we want to fix with marconi | 13:38 |
| flaper87 | we'd be just barrying it down the application stack | 13:38 |
| kgriffs | flaper87: what do you suggest re alternative backends to Mongo? | 13:38 |
| kgriffs | I'd like to do 1-2 more "official" backends during incubation, assuming we are accepted | 13:39 |
| flaper87 | kgriffs: TBH, I wasn't thinking about any relational backend BUT, I think that will bring more users and more feedback | 13:39 |
| zyuan_ | sqlalchemy, hyperdex | 13:40 |
| flaper87 | I'm thinking about psql and swift | 13:40 |
| flaper87 | or mysql (since it's loved throughout OS) | 13:40 |
| zyuan_ | sqlalchemy can handle both... | 13:40 |
| flaper87 | zyuan_: yeah, I know, but there's a discussion we should have about pros / cons of sqlalchemy | 13:41 |
| flaper87 | TBH | 13:41 |
| zyuan_ | flaper87: so what's the cons? | 13:41 |
| flaper87 | lets say, we should have a backend for a RDBMS and something else | 13:42 |
| kgriffs | flaper87: sounds good | 13:42 |
| flaper87 | zyuan_: can we discuss that later? | 13:42 |
| kgriffs | 1x RDBMS | 13:42 |
| kgriffs | 1x Redis or Hyperdex | 13:42 |
| flaper87 | well, cppcabrera has done some work on the redis backend | 13:43 |
| kgriffs | true | 13:43 |
| zyuan_ | sqlite -> sql*, easy | 13:43 |
| zyuan_ | mongo -> hyperdex, also easy | 13:43 |
| kgriffs | hyperdex and rethinkdb seem slightly more related to mongo than does redis | 13:43 |
| zyuan_ | actually redis might be the most complex one | 13:44 |
| kgriffs | so, maybe redis the way to go. not saying other backends would be cool, but I want a wide spread of "flavors" as reference drivers. | 13:44 |
| flaper87 | kgriffs: +! for redis | 13:44 |
| kgriffs | I gotta run to the dentist (fun!) but will be back in ~90 minutes. Let me recap... | 13:45 |
| flaper87 | kk | 13:45 |
| flaper87 | glad we discussed this | 13:45 |
| kgriffs | First, we will not target AMQP for our initial release | 13:45 |
| flaper87 | I'll keep playing with tests in the meantime | 13:45 |
| kgriffs | second, we would like to keep the mongo driver and add 2 more | 13:45 |
| kgriffs | (from different families) | 13:46 |
| kgriffs | for sure an RDBMS | 13:46 |
| kgriffs | and then a Redis or something else (TBD) | 13:46 |
| kgriffs | flaper87: one more thought | 13:46 |
| kgriffs | (to think about_ | 13:46 |
| kgriffs | rather than making a compound product+name field in the messages collection, what would be the pros/cons of having one collection per product ID? | 13:47 |
| kgriffs | anyway, gotta run. bbl. | 13:47 |
| flaper87 | you mean project, right? | 13:48 |
| flaper87 | kk, ttyl | 13:48 |
| flaper87 | mmhh | 13:48 |
| * flaper87 thinking | 13:48 | |
| zyuan_ | flaper87: so... what do think about *sql vs sqlalchemy? | 13:49 |
| *** ametts has joined #openstack-marconi | 13:50 | |
| kgriffs | flaper87: sorry, yeah, meant project | 13:51 |
| kgriffs | ttfn | 13:51 |
| flaper87 | zyuan_: I've nothing against sqlalchemy, TBH. My only concern about it (as for marconi) is it slowing down operations due to all the things it does internally. I guess we could access the core API which would bypass some of those things but, it's something we should meassure. I guess. | 13:52 |
| *** kgriffs is now known as kgriffs_afk | 13:52 | |
| flaper87 | There are many things it would help us with (models, migrations, etc) | 13:52 |
| zyuan_ | flaper87: me too. i hope core api is not that slow | 13:52 |
| zyuan_ | at least, from the api design, i think it can hardly be slow... | 13:52 |
| flaper87 | yeah, I was also thinking we could have a BaseSqlController for Queues, Messages, Claims that other rel-based backends could inherit from. This BaseSqlCotnroller would define queries, schemas etc. and leave the rest to the implementation | 13:54 |
| flaper87 | or we could go for the sqlalchemy-based one and let people aiming for more performance to implement their own w/ direct access to the database | 13:54 |
| flaper87 | that's what I've thought so far. | 13:55 |
| zyuan_ | hmm. i don't think we should have a base class for that | 13:58 |
| zyuan_ | different db should have different schema | 13:58 |
| flaper87 | zyuan_: agreed | 13:58 |
| zyuan_ | for efficiency. even for sqlalchemy, i still want some fine control over the datatypes | 13:59 |
| zyuan_ | (while it's impossible for sqlite) | 13:59 |
| openstackgerrit | Flavio Percoco proposed a change to stackforge/marconi: Implement embedded marconi-server execution https://review.openstack.org/44749 | 14:09 |
| flaper87 | is cppcabrera out ? | 14:09 |
| zyuan_ | jury duty | 14:11 |
| zyuan_ | i'm out from tomorrow, goingnative 2013 | 14:12 |
| flaper87 | aaaaaaaaaaahhh right, he said that | 14:12 |
| flaper87 | zyuan_: COOOOOOOOOOOL!!!! | 14:14 |
| flaper87 | you guys have those cool events there | 14:14 |
| flaper87 | why is this check needed? https://github.com/stackforge/marconi/blob/master/marconi/tests/storage/base.py#L142 | 14:16 |
| openstackgerrit | Flavio Percoco proposed a change to stackforge/marconi: Implement embedded marconi-server execution https://review.openstack.org/44749 | 14:17 |
| zyuan_ | i don't know whether it's needed or not, but it looks reasonable | 14:27 |
| *** kgriffs_afk is now known as kgriffs | 14:29 | |
| zyuan_ | flaper87: self.process.join(1) | 14:35 |
| zyuan_ | then the process quit?! | 14:35 |
| flaper87 | zyuan_: nope, that just gives the process a second to boot, otherwise some operations may fail because of the process not being ready, I don't like that piece of code, Ill work on a better proposal in a separate patch. | 14:36 |
| zyuan_ | flaper87: but if it takes more than 1 sec to boot it raise an timeout exception, right? | 14:38 |
| *** kgriffs is now known as kgriffs_afk | 14:38 | |
| zyuan_ | ... it does not... | 14:39 |
| flaper87 | no, it shouldn't raise any exception | 14:40 |
| flaper87 | I'll remove that join() in a separate patch. I'm thinking a better way to share resources and server instances througout our functional tests | 14:41 |
| flaper87 | (ideas are very welcome) | 14:41 |
| flaper87 | :D | 14:41 |
| *** ykaplan has quit IRC | 14:52 | |
| *** briancline has joined #openstack-marconi | 14:59 | |
| zyuan_ | http://stackoverflow.com/questions/11769366/why-is-sqlalchemy-insert-with-sqlite-25-times-slower-than-using-sqlite3-directly/11769768#11769768 | 15:01 |
| *** kgriffs_afk is now known as kgriffs | 15:18 | |
| * kgriffs is back | 15:24 | |
| * kgriffs has a numb mouth | 15:24 | |
| kgriffs | guys, don't forget about the TC meeting today at 20:00 UTC | 15:26 |
| megan_w | hi all. we should make sure we have some requirements set for a solution to be considered as a storage backend | 15:29 |
| flaper87 | kgriffs: re https://review.openstack.org/#/c/44340/3/marconi/storage/mongodb/utils.py | 15:33 |
| flaper87 | I'm not 100% sure, I'm still worried about the case where we get 10 messages back from the backend and they're all expired | 15:34 |
| flaper87 | sending back an empty collection to the user doesn't feel right | 15:34 |
| flaper87 | it doesn't feel right sending expired messages either, though | 15:34 |
| flaper87 | :P | 15:34 |
| kgriffs | flaper87: TBH I am on the fence here as well. | 15:35 |
| kgriffs | megan_w: so, we have functional requirements already: flaper87 | 15:36 |
| kgriffs | http://goo.gl/a8z7KG | 15:36 |
| kgriffs | I guess we need to create a wiki page that brings all the requirements together | 15:36 |
| flaper87 | if you guys give me your gmails, I'll give you write access | 15:36 |
| kgriffs | we have some bp pages we can pull from | 15:36 |
| kgriffs | flaper87: sffirgk@gmail.com | 15:37 |
| megan_w | so the question to me is do we support backends that don't support the full api? | 15:37 |
| flaper87 | kgriffs: we also answered the question wrt "Why Falcon" | 15:37 |
| flaper87 | we should write that down in the wiki before the meeting | 15:37 |
| megan_w | anne mentioned that it could make documentation complex, which i agree | 15:37 |
| kgriffs | good point | 15:37 |
| megan_w | flaper87: megan.wohlford@gmail.com | 15:37 |
| kgriffs | flaper87: on the incubation page? | 15:37 |
| flaper87 | kgriffs: yeah! | 15:38 |
| flaper87 | we can have a subsection like: "Raised questions and answers" | 15:38 |
| megan_w | good idea | 15:38 |
| megan_w | it | 15:38 |
| kgriffs | flaper87: let me add that | 15:41 |
| megan_w | about backends supporting all API calls... | 15:43 |
| flaper87 | megan_w: hehehe, we keep avoiding that question | 15:43 |
| flaper87 | LOl | 15:43 |
| flaper87 | sorry about that | 15:44 |
| flaper87 | :D | 15:44 |
| megan_w | what happens as Marconi wants to launch new features? | 15:44 |
| flaper87 | sooooo | 15:44 |
| megan_w | are the backends required to support them in a certain period of time? | 15:44 |
| flaper87 | here's what we decided today. We won't aim to support AMQP backends in v1 but we'll improve the API (v2?) in orther to make those backends implementation easier | 15:44 |
| megan_w | or do we make the backends support certain core api calls? | 15:44 |
| flaper87 | as for whether we will allow partial support of the API, erm, I'm not 100% sure what would be the best thing. | 15:45 |
| megan_w | i tend to agree | 15:45 |
| megan_w | kgriffs: ?? | 15:45 |
| flaper87 | I'm thinking about: If the backend wants to get into Marconi's source tree then yes, the baackend has to fully support our API | 15:45 |
| kgriffs | yeah, I would say so | 15:46 |
| flaper87 | but, mmh, you know.... Diversity :D | 15:46 |
| flaper87 | anyway, that's my thinking right now | 15:46 |
| kgriffs | but we may allow partial support in the external repo | 15:46 |
| flaper87 | kgriffs: megan_w I added you both to the doc | 15:47 |
| megan_w | ok, now what about expanding the marconi api? how do we enforce ongoing support for new features? | 15:47 |
| megan_w | or do we? | 15:47 |
| flaper87 | feel free to add sqlserver there | 15:47 |
| flaper87 | but hey, it's all logged | 15:48 |
| flaper87 | :P | 15:48 |
| kgriffs | re AMQP, I think it would be good to also mention that it will be considered as part of the v2.0 design process, taking into account community needs and feedback. | 15:48 |
| flaper87 | kgriffs: +! | 15:48 |
| flaper87 | kgriffs: +1 | 15:48 |
| flaper87 | megan_w: Unittests | 15:48 |
| flaper87 | megan_w: I mean, tests! | 15:48 |
| flaper87 | we're working hard on creating a good test structure that can be used by thrid-party libraries as well | 15:49 |
| megan_w | got it. | 15:49 |
| flaper87 | so that we can use that to certify the full support of the API | 15:49 |
| megan_w | so having a backend "officially supported" means we take on responsibility to make it a part of our test suite, right? | 15:50 |
| amitgandhi | kgriffs: the other thing to consider is that if we want to support an AMQP backend, but have a wsgi transport, that it should use our consistent api (ie dont make significant changes unless it is needed for *most* backends). If you want to support amqp, then maybe make an amqp transport layer which *could* have a different transport definition that is semantically identical to using amqp directly | 15:50 |
| flaper87 | megan_w: implementers do that. If we implement the backend ourselves the yes, it's our responsibility | 15:50 |
| flaper87 | otherwise it's up to the guy / company / ET working on the implementation | 15:51 |
| megan_w | got it | 15:51 |
| * flaper87 loves pulling ETs into technical discussions | 15:51 | |
| flaper87 | kgriffs: when you get a chance, could you take a look at the test patches? starting from here: https://review.openstack.org/#/c/44475/ | 16:01 |
| kgriffs | sure, once I get email/wiki stuff squared away I'll take a pass though the patches | 16:03 |
| flaper87 | awesome, thanks! | 16:03 |
| kgriffs | so, SQLAlchemy or just MySQL directly? | 16:04 |
| kgriffs | (working on the incubation wiki FAQ) | 16:04 |
| flaper87 | I guess you could write MySQL | 16:04 |
| flaper87 | and we can decide later whether to use sqlalchemy | 16:05 |
| kgriffs | or pg? | 16:05 |
| kgriffs | ok | 16:05 |
| kgriffs | sounds good | 16:05 |
| * flaper87 loves pg | 16:05 | |
| kgriffs | seems like OS operators favor MySQL, though, nicht? | 16:07 |
| kgriffs | or does it matter? | 16:07 |
| flaper87 | they do favor MySQL since that's what most projects support and it was the first db supported | 16:09 |
| flaper87 | which means, most deployments using OS have MySQL installed | 16:09 |
| flaper87 | (at least, it's more probable) | 16:09 |
| kgriffs | ok | 16:11 |
| kgriffs | we will run with that then | 16:11 |
| *** jergerber has joined #openstack-marconi | 16:12 | |
| *** _alexr_ has quit IRC | 16:24 | |
| kgriffs | flaper87, megan_w: https://wiki.openstack.org/wiki/Marconi/docs/drivers | 16:34 |
| flaper87 | kgriffs: thanks | 16:34 |
| kgriffs | flaper87: could you work on that page? | 16:34 |
| flaper87 | kgriffs: sure | 16:34 |
| kgriffs | thanks! | 16:34 |
| kgriffs | I am going to mention it in the incubation q&a | 16:35 |
| megan_w | it'll be good to have this documented | 16:35 |
| flaper87 | Heading to dinner, will work on it as soon as I get back. | 16:35 |
| flaper87 | kk | 16:35 |
| kgriffs | no problem | 16:35 |
| flaper87 | brb | 16:35 |
| kgriffs | ttfn | 16:35 |
| kgriffs | flaper87: FYI: https://blueprints.launchpad.net/marconi/+spec/use-pecan-framework | 16:44 |
| kgriffs | renamed: https://blueprints.launchpad.net/marconi/+spec/pecan-framework | 17:11 |
| kgriffs | feedback welcome. I'll be out for a bit to lunch. | 17:13 |
| oz_akan_ | kgriffs: flaper87 what is the motivation behind investigating pecan ? | 17:19 |
| amitgandhi | oz_akan_: just as an alternative to falcon since falcon isnt used in any other OS project. Pecan can be built as another wsgi transport option, and depending on perf compared to falcon marconi could switch, or stick with falcon if it continues to prove to be faster | 17:27 |
| oz_akan_ | I am worried to loose the quality in what we have if we try to support so many | 17:29 |
| oz_akan_ | do we think falcon is slow? | 17:30 |
| oz_akan_ | amitgandhi: ^^ | 17:31 |
| amitgandhi | we dont think so | 17:32 |
| amitgandhi | the comment came from last weeks incubation meeting | 17:32 |
| oz_akan_ | I must have missed that | 17:32 |
| amitgandhi | oz_akan: https://wiki.openstack.org/wiki/Marconi/Incubation#Raised_Questions_.2B_Answers | 17:33 |
| amitgandhi | last one in the list | 17:34 |
| oz_akan_ | got it thanks | 17:34 |
| amitgandhi | np | 17:35 |
| oz_akan_ | I wonder if an API that mimics SQS would be useful. Imagine, one uses SQS and can easily try marconi | 17:51 |
| oz_akan_ | kgriffs: flaper87 will you guys be checking claim problem? | 17:54 |
| oz_akan_ | it might be related to too many documents in messages collection issue | 17:55 |
| amitgandhi | oz_akan_: the argument to wrap all openstack api's to support sqs api semantics is often made. i think the merits to do such a thing with marconi would need to be made. i see advantages in it as long as marconi supports all sqs features, and expected results are the same. But if behaviour differs in any way then it could be dangerous as users will have made preconceived expectations on how the api behaves | 17:59 |
| oz_akan_ | +1 | 18:00 |
| *** oz_akan_ has quit IRC | 18:01 | |
| *** oz_akan_ has joined #openstack-marconi | 18:02 | |
| flaper87 | back | 18:04 |
| flaper87 | half back | 18:04 |
| flaper87 | oz_akan_: we're investigating Pecan not because Falcon is slow but because it's widely used throughout OpenStack. It's just a way to have some standard in the whole project. It's not a strong requirement and it doesn't mean we'll be replacing Flacon as default fw - unless Pecan proves to be way faster than Falcon. | 18:06 |
| oz_akan_ | flaper87: got it thanks | 18:06 |
| flaper87 | kgriffs: around? | 18:18 |
| kgriffs | back | 19:00 |
| kgriffs | (was in a mtg) | 19:00 |
| zyuan_ | kgriffs: is there a patch to use less timeutils? | 19:05 |
| *** ayoung has quit IRC | 19:09 | |
| kgriffs | zyuan_: so, couple things on that | 19:09 |
| kgriffs | just a sec (in a mtg | 19:10 |
| *** ayoung has joined #openstack-marconi | 19:22 | |
| kgriffs | back | 19:25 |
| kgriffs | zyuan_: so, we need to update our oslo-incubator code to get this: https://review.openstack.org/#/c/44363/ | 19:25 |
| kgriffs | then, we can just use utcnow_ts() | 19:25 |
| kgriffs | that will allow us to continue having testability (via override_time) but also it will still be almost as fast as calling time.time() directly. | 19:26 |
| kgriffs | make sense? | 19:26 |
| zyuan_ | thid has been merged | 19:27 |
| zyuan_ | this | 19:27 |
| zyuan_ | but we havn't merged it yet... | 19:30 |
| kgriffs | yes, let me update our copy of oslo real quick | 19:33 |
| flaper87 | back | 19:34 |
| openstackgerrit | Kurt Griffiths proposed a change to stackforge/marconi: chore: Update openstack.common to get latest timeutils https://review.openstack.org/44944 | 19:36 |
| kgriffs | zyuan_, flaper87: ^^ | 19:36 |
| * flaper87 clicks | 19:38 | |
| flaper87 | kgriffs: approved | 19:38 |
| flaper87 | actually, ninja approved | 19:38 |
| kgriffs | thanks d00d | 19:38 |
| kgriffs | don't you mean ninjapproved? | 19:39 |
| kgriffs | :D | 19:39 |
| flaper87 | hahahahhahahah, damnit :P | 19:39 |
| openstackgerrit | A change was merged to stackforge/marconi: chore: Update openstack.common to get latest timeutils https://review.openstack.org/44944 | 19:40 |
| kgriffs | flaper87: https://wiki.openstack.org/wiki/Marconi/Incubation#Raised_Questions_.2B_Answers | 19:41 |
| kgriffs | I tried to consolidate recent feedback | 19:42 |
| kgriffs | is it *mostly* accurate? :p | 19:42 |
| flaper87 | kgriffs: read it, it looks good. I'm putting together some ides for the drivers page. I started adding random paragraphs and then I'll clean it a bit | 19:43 |
| kgriffs | cool, sounds awesome | 19:43 |
| flaper87 | ok guys, the meeting is 10mins away | 19:45 |
| flaper87 | see you all in #openstack-meeting | 19:46 |
| kgriffs | +1 | 19:49 |
| flaper87 | kgriffs: btw, +1 for the email to the list. I wanted to tell you that w/ my last ping | 19:56 |
| kgriffs | flaper87: I think our brains our quantum linked somehow | 19:58 |
| * kgriffs checks for scars on the back of the neck | 19:58 | |
| megan_w | make sure everyone goes over to the #openstack-meeting channel | 20:02 |
| flaper87 | ok, meeting started | 20:03 |
| flaper87 | everyone in there | 20:03 |
| zyuan_ | kgriffs: hehe, i was looking at the 'e' handling, then i found a "bug": mongo's "grace" logic is different from sqlite's... | 20:19 |
| zyuan_ | err, no | 20:20 |
| zyuan_ | ...nothing obvious | 20:24 |
| flaper87 | w0000000000000000000000000000000000000000000000000000000000t | 20:27 |
| flaper87 | 11 YESSSSSSS | 20:27 |
| zyuan_ | !!!!!! | 20:27 |
| openstack | zyuan_: Error: "!!!!!" is not a valid command. | 20:27 |
| zyuan_ | \!!!!!! | 20:27 |
| zyuan_ | \o/ | 20:27 |
| amitgandhi | =D | 20:28 |
| amitgandhi | well done team! | 20:30 |
| megan_w | yay!! | 20:30 |
| megan_w | let's keep that scope creep in our minds | 20:30 |
| ametts | I was looking for some sort of official pronouncement -- the discussion with those abstain people was worrying me. | 20:30 |
| amitgandhi | its ok, notications wont be "part" of marconi | 20:31 |
| amitgandhi | its always one use case of many for marconi | 20:31 |
| kgriffs | interesting, I didn't expect them to want *fewer* drivers | 20:31 |
| flaper87 | yeah, me neither | 20:31 |
| amitgandhi | i like they want the focus on features and performance first | 20:31 |
| flaper87 | aaaaaaaaaaaanyway, can we go party now ? | 20:31 |
| kgriffs | sounds like they want us to be super focused and not worry so much about chasing higher-level use cases | 20:31 |
| amitgandhi | get the product working and then expand horizontally | 20:32 |
| flaper87 | I would say we need to focus on both | 20:32 |
| kgriffs | (let the broader community chase them for us) | 20:32 |
| amitgandhi | party in italy! | 20:32 |
| megan_w | flaper87: we're coming to you!! | 20:32 |
| flaper87 | meaning, we gotta split the work very well and make sure we get all those things done | 20:32 |
| ametts | flaper87: The RAX people have to get our deployment working before they can party. :) | 20:32 |
| * ametts cracks whip | 20:32 | |
| flaper87 | come on people, RT https://twitter.com/flaper87/status/374992911101743104 | 20:32 |
| flaper87 | :D | 20:32 |
| flaper87 | ametts: BOOOOO BOOOOOOOOO!!!!! | 20:33 |
| flaper87 | party while deploying | 20:33 |
| flaper87 | that makes it even better | 20:33 |
| kgriffs | right, start with a solid foundation and don't compromise that by chasing lots of driver flavors - we can do that later and/or encourage a vibrant "3rd-party" ecosystem | 20:33 |
| amitgandhi | the best deployments are done with tequila | 20:33 |
| megan_w | so what now? does the TC formally give us requirements for graducation? or is that later on? | 20:33 |
| flaper87 | https://wiki.openstack.org/wiki/Governance/Approved/Incubation | 20:34 |
| megan_w | (just wondering if we should be tracking our progress against some master list for graduation) | 20:34 |
| megan_w | got it. so next step is getting our policy board mentor | 20:35 |
| flaper87 | yeah and we need to migrate from stackforge to openstack on GH (AFAIK) | 20:35 |
| kgriffs | "ability to install marconi in a real production manner without having to install something AGPL" | 20:36 |
| kgriffs | that is one thing to track, at least. :) | 20:36 |
| kgriffs | also, get into devstack and the usual CI process as soon as possible | 20:37 |
| oz_akan_ | kgriffs: I couldn't the issues with AGPL | 20:37 |
| oz_akan_ | I couldn't get | 20:37 |
| megan_w | seems to be some general interest in horizon | 20:37 |
| kgriffs | oz_akan_: i personally think it's a bit silly, but some people are pretty religious about licensing | 20:37 |
| kgriffs | megan_w: not sure if that's a requirement for graduation? | 20:38 |
| flaper87 | in order to integrate well w/ horizon we need a client library that can be used from there | 20:38 |
| flaper87 | It's not a strong requirement though | 20:38 |
| kgriffs | megan_w: but yeah, we should be looking into that | 20:38 |
| oz_akan_ | AGPL is the like the one without any restriction, I am not sure why it might be a problem | 20:38 |
| kgriffs | flaper87: +1 | 20:38 |
| flaper87 | devstack, heat are, AFAICT | 20:38 |
| flaper87 | if you guys don't mind, I'd like to take care of the whole migration from stackforge to openstack | 20:39 |
| kgriffs | flaper87: that would be groovy. | 20:40 |
| flaper87 | cool beans | 20:43 |
| * flaper87 learned that from kgriffs | 20:43 | |
| amitgandhi | when is graduation? | 20:43 |
| flaper87 | amitgandhi: Jth | 20:43 |
| amitgandhi | so oct 2014 ish | 20:45 |
| *** ayoung has quit IRC | 20:45 | |
| kgriffs | so, we incubate during Icehouse | 20:46 |
| flaper87 | amitgandhi: no, April 2014 | 20:46 |
| flaper87 | We should apply for graduation during the next release cycle | 20:47 |
| ametts | BTW, we also need to capture/track the requirements for DevStack, Tempest, and the gating tests. | 20:47 |
| flaper87 | and that should be our very first, official release | 20:47 |
| flaper87 | ametts: I'll take care of that | 20:47 |
| flaper87 | I'll create blueprints for them | 20:47 |
| kgriffs | flaper87: thanks! | 20:47 |
| kgriffs | I added a few notes to the bottom of the incubation wiki | 20:47 |
| kgriffs | https://wiki.openstack.org/wiki/Marconi/Incubation#Raised_Questions_.2B_Answers | 20:47 |
| flaper87 | kgriffs: awesome, thanks | 20:47 |
| flaper87 | we need to add Heat to that list | 20:48 |
| kgriffs | on there | 20:48 |
| amitgandhi | need to add devstack tempest etc to that list | 20:48 |
| kgriffs | wasn't sure whether it is a "nice to have" or a hard requirement | 20:48 |
| flaper87 | Heat, devstack, tempest are all "must have" | 20:49 |
| kgriffs | oops - had that in my notes, somehow missed it | 20:49 |
| amitgandhi | it sounds like a new hard requirement (esp for day 0 incubators) | 20:49 |
| kgriffs | stand by | 20:49 |
| kgriffs | updated that wiki | 20:52 |
| flaper87 | kgriffs: awesome | 20:52 |
| kgriffs | so, re timeline, we need to graduate 6 weeks priorior to J release in order to be integrated, right? | 20:52 |
| kgriffs | icehouse release is in the Spring, isn't it? | 20:53 |
| flaper87 | kgriffs: right | 20:53 |
| * kgriffs brings up release page | 20:53 | |
| kgriffs | https://wiki.openstack.org/wiki/Releases | 20:53 |
| kgriffs | so… doesn't that mean the first integrated release Marconi would be in would be next fall? | 20:54 |
| amitgandhi | thats how i read it | 20:55 |
| flaper87 | mmh no if we graduate before J is released | 20:55 |
| flaper87 | AFAIK | 20:55 |
| kgriffs | isn't the J release in the fall? | 20:55 |
| kgriffs | (Last week someone from the TC mentioned that we would be too late for Icehouse) | 20:55 |
| flaper87 | ah damn, I meant Ith | 20:55 |
| flaper87 | sorry | 20:55 |
| flaper87 | my bad | 20:55 |
| kgriffs | oic | 20:56 |
| amitgandhi | H is released in Oct, I is released in Apr (too late for that), so J in Oct 2014 | 20:56 |
| kgriffs | we would have to graduate pretty quickly to make it into I | 20:56 |
| kgriffs | nict? | 20:56 |
| kgriffs | s/nict/nicht | 20:56 |
| * ametts is so confused | 20:56 | |
| flaper87 | kgriffs: TBH, I don't think it's going to take us much time to implement all the required bits | 20:56 |
| amitgandhi | The I release design summit is in Nov 2013 | 20:57 |
| flaper87 | amitgandhi: yeah, I meant to say Ith release and kept writing J | 20:57 |
| kgriffs | amitgandhi: right, that is planning for the Ith release | 20:57 |
| amitgandhi | we arent going to be ready for them to commit us to the release then | 20:57 |
| flaper87 | amitgandhi: why not? | 20:57 |
| kgriffs | Havana is released Oct 17, then in November planning starts in ernest for Icehouse | 20:57 |
| amitgandhi | wont they require us to meet all the graduation requirements by then (2 months), and wasnt there something about having 2 releases or something along those lines | 20:58 |
| kgriffs | I suppose that if we can graduate 6 weeks prior to Apr 2014, we should be able to make it into the integrated release. | 20:58 |
| flaper87 | amitgandhi: no, we need to meet all the graduation requirements 6 weeks prior to the next release | 20:59 |
| kgriffs | https://wiki.openstack.org/wiki/Governance/Approved/NewProjectProcess | 20:59 |
| ametts | Who's on first? | 20:59 |
| kgriffs | "All projects must be approved for promotion to core 6 weeks before a release cycle's design summit." | 20:59 |
| flaper87 | which means we have6 1/2 months starting now | 20:59 |
| kgriffs | TBH, I'm still a little fuzzy on "core" vs. "integrated release" | 20:59 |
| flaper87 | kgriffs: same #%@$ different ways to call it | 21:00 |
| flaper87 | :D | 21:00 |
| * kgriffs thought so | 21:00 | |
| amitgandhi | oh ok so as long as we meet their requirements 6 weeks before the release date, we can be part of that release | 21:01 |
| kgriffs | wow. | 21:01 |
| kgriffs | this is really interesting considering the thinking around "core" ~1 year ago | 21:01 |
| flaper87 | amitgandhi: yup | 21:01 |
| kgriffs | ok folks, I think this calls for a round of Pop-Tarts™ | 21:03 |
| oz_akan_ | it seems like we have 404s not 204s for claims | 21:04 |
| * kgriffs starts flinging pop-tarts all over | 21:04 | |
| oz_akan_ | I updated the bug report | 21:04 |
| oz_akan_ | trying to understand if it happens when we have more than a number of documents in messages collection | 21:04 |
| * ametts already popped a bag of Rackspace Atlanta popcorn. | 21:04 | |
| flaper87 | oz_akan_: you don't like pop-tarts, do you? | 21:04 |
| * flaper87 jumps around and catches his and oz_akan_'s pop-tarts | 21:05 | |
| oz_akan_ | flaper87: I like what you like | 21:05 |
| * flaper87 thinks about very disgusting things he "likes" | 21:07 | |
| oz_akan_ | hehe | 21:07 |
| oz_akan_ | I like a claim returning 201 | 21:07 |
| oz_akan_ | or 204 | 21:07 |
| flaper87 | or 500 | 21:07 |
| amitgandhi | i thought malini said something about the 404 happening after the 204's | 21:08 |
| amitgandhi | like the 204 was giving a null location and hence the subsequent 404 | 21:08 |
| ametts | amitgandhi:That's an artifact from her test rig | 21:08 |
| oz_akan_ | ok, it is about the frequency | 21:08 |
| flaper87 | ah, btw, before migrating marconi under openstack/ we need to get all those patches merged | 21:08 |
| flaper87 | :) | 21:08 |
| oz_akan_ | if I send so many requests I start to get 404s | 21:08 |
| oz_akan_ | even when there is little number of messages | 21:08 |
| flaper87 | or, re-submit them if needed | 21:08 |
| ametts | The 404 wasn't really a bug in Marconi itself. | 21:08 |
| flaper87 | lets not just merge patches if we're not sure about the code | 21:09 |
| oz_akan_ | we shall return 404 only when there isn't a queue | 21:09 |
| amitgandhi | is this with the slaves disabled? | 21:10 |
| amitgandhi | s/slaves/secondaries | 21:10 |
| oz_akan_ | this when we write primary and read from secondary | 21:11 |
| amitgandhi | it sounds like a replication issue to me getting back 404's. | 21:11 |
| oz_akan_ | if there was no data, because of replication lag, it would return 204 | 21:12 |
| oz_akan_ | but returns 404 | 21:12 |
| * amitgandhi reads above and recalls this is for claims | 21:13 | |
| amitgandhi | and this is when attempting to POST a claim right (not getting an existing claim?) | 21:14 |
| oz_akan_ | yes, post claim | 21:15 |
| kgriffs | if a queue was just barely created, but the queue collection record has not replicated, you will get a 404 when POSTing a claim | 21:16 |
| kgriffs | I have a patch pending that changes it to return a 204 in that case, but that is beside the issue | 21:17 |
| kgriffs | so, it could still be an eventual consistency thing | 21:18 |
| kgriffs | even if something reads messages after creating the queue and gets some back, they may be getting them off 1 secondary that is up to date, but the other is lagging, and that's the one that is hit when the POST claim comes in | 21:19 |
| kgriffs | anyway, only way to know for sure is to force reads from the master OR set w=3 so responses are only ack'd after replication to both secondaries. | 21:20 |
| kgriffs | flaper87: what do you think about a separate collection per project ID? | 21:20 |
| kgriffs | (switching topics) | 21:20 |
| oz_akan_ | https://bugs.launchpad.net/marconi/+bug/1219019 | 21:21 |
| oz_akan_ | i put my findings there | 21:21 |
| oz_akan_ | I think this is something wrong with mongodb and marconi both | 21:22 |
| oz_akan_ | i will re-install mongodb on these servers with latest version tomorrow to see if it will help | 21:22 |
| oz_akan_ | have to leave now | 21:22 |
| *** oz_akan_ has quit IRC | 21:23 | |
| amitgandhi | http://en.wikipedia.org/wiki/File:Piles_of_Salt_Salar_de_Uyuni_Bolivia_Luca_Galuzzi_2006_a.jpg | 21:27 |
| amitgandhi | salt stack? | 21:27 |
| * amitgandhi oops wrong room | 21:27 | |
| flaper87 | sorry, my laptop hung up | 21:28 |
| flaper87 | kgriffs: I thought a bit about that after you bring it up today. I think we would reach namespace limit very easily | 21:28 |
| flaper87 | In a deployment with many tenants / project | 21:29 |
| kgriffs | but in such a deployment, wouldn't marconi-proxy be used anyway and you would end up with disjoint clusters? | 21:29 |
| kgriffs | do you think a single "partition" would not be able to handle enough projects? | 21:30 |
| kgriffs | If my math is correct, a single Mongo server can support is 3,417,890 | 21:32 |
| flaper87 | kgriffs: mmh, this is the limit http://docs.mongodb.org/manual/reference/limits/#Number of Namespaces | 21:32 |
| kgriffs | 2047 MB = 2146435072 bytes | 21:33 |
| kgriffs | 2146435072 / 628 = 3417890 | 21:34 |
| kgriffs | (check me) | 21:34 |
| flaper87 | there | 21:34 |
| kgriffs | 16 * 2**20 / 628 | 21:35 |
| flaper87 | ops | 21:35 |
| flaper87 | there's just 1 namespace file per database | 21:35 |
| ametts | flaper87, kgriffs: Either of you know when they'll open up technical session proposals for HKG? Does our new incubation status mean we get rooms now, or are we still relegated to unconference sessions? | 21:35 |
| flaper87 | ametts: I think we get the chance to have sessions as well | 21:35 |
| ametts | We should be on the lookout for that opportunity. | 21:36 |
| flaper87 | kgriffs: IIRC | 21:36 |
| kgriffs | ametts: +1 | 21:36 |
| flaper87 | ametts: +1 | 21:36 |
| kgriffs | flaper87: "Namespace files can be no larger than 2047 megabytes." | 21:36 |
| kgriffs | "The limitation on the number of namespaces is the size of the namespace file divided by 628" | 21:37 |
| kgriffs | it isn't clear if they mean size in bytes or MB, but it seems like bytes, since 16 * 2**20 / 628 is roughly 24,000 | 21:37 |
| flaper87 | if you 'ls' mongodb's data dir, there should be just 1 .ns per database | 21:38 |
| flaper87 | kgriffs: that's bytes | 21:38 |
| kgriffs | ok | 21:38 |
| flaper87 | they always measure everything in bytes | 21:38 |
| flaper87 | (hopefully, they didn't change the standard in that particullar case) | 21:38 |
| kgriffs | so, ~3 million namespaces per namespace file? | 21:38 |
| kgriffs | (if you set nssize to the max) | 21:39 |
| flaper87 | anyway, I also think we should design things to work perfectly on a single marconi-server instance | 21:39 |
| flaper87 | then they can be faster if marconi-server is scaled out | 21:39 |
| kgriffs | sure, but I think you also have to say that if people want unlimited tenants and queues, they will need marconi-proxy | 21:39 |
| kgriffs | that being said, a single partition should be no slouch | 21:40 |
| flaper87 | would that be true for every backend? | 21:40 |
| flaper87 | or just mongodb? | 21:40 |
| kgriffs | well, say there were a Redis backend | 21:40 |
| kgriffs | you would be limited by RAM | 21:40 |
| flaper87 | right, but that's a hardware limit, not software | 21:41 |
| kgriffs | (assuming no db-level sharding) | 21:41 |
| kgriffs | flaper87: sure, I'm just saying, the backend makes a difference on how far you can scale (and in which ways you scale) | 21:41 |
| flaper87 | kgriffs: agreed | 21:42 |
| flaper87 | kgriffs: would it be fair to have a "partitioned" config param ? | 21:42 |
| flaper87 | that would let the backend know it's being partitioned | 21:42 |
| kgriffs | flaper87: re namespaces limitation, does 3 million sound right? Seems like a heck of a lot to me. | 21:42 |
| kgriffs | flaper87: what might the backend do with that knowledge? | 21:43 |
| flaper87 | kgriffs: 3M sounds right, I'd like to verify the limit w/ #mongodb guys | 21:43 |
| flaper87 | kgriffs: use different storage strategies? | 21:43 |
| flaper87 | I'm afraid that would make migrations from 1 strategy to another very difficult | 21:43 |
| kgriffs | ok. If that is correct, seems like it would be plenty to support projects (multiple queues will continue to share the same collection, per project) | 21:43 |
| flaper87 | ah, also, what would the exact benefit of having 1 col per project? | 21:44 |
| flaper87 | the lock is at DB level anyway | 21:44 |
| kgriffs | yes, but now you don't have to have the project in the index | 21:44 |
| flaper87 | kgriffs: oh, right, good point | 21:44 |
| kgriffs | and hot queues will have their indexes in RAM, not getting swapped out due to interleaving with requests for other queues | 21:45 |
| flaper87 | kgriffs: yeah, sounds like a good strategy to me | 21:45 |
| kgriffs | also, you don't repeat the project ID a gazillion times in the document store | 21:45 |
| flaper87 | well thought | 21:45 |
| kgriffs | so, I was trying to find out the cons | 21:45 |
| kgriffs | can you think of any others other than namespace limitations? | 21:45 |
| kgriffs | (not really a con, I guess, but requires the operator to set nssize before the DB is created) | 21:46 |
| kgriffs | I guess you can ping the #mongodb guys | 21:46 |
| flaper87 | yeah, I will do that | 21:46 |
| kgriffs | ok, cool. I think this would be the last major change along with changing to use unix timestamps instead of date objects | 21:47 |
| *** tedross has quit IRC | 21:47 | |
| kgriffs | (change to the schema) | 21:47 |
| kgriffs | oh, also we have multi-db support (Oz's patch) which he is working on - he mentioned that he will try to get that submitted later this week | 21:48 |
| *** openstackgerrit has quit IRC | 21:48 | |
| flaper87 | how will that patch integrate with current code? | 21:48 |
| *** openstackgerrit has joined #openstack-marconi | 21:48 | |
| flaper87 | and with this change we're planning | 21:48 |
| kgriffs | so, there will be a configurable number of DB's to partition the data across | 21:50 |
| kgriffs | if you configure 4, then you end up with marconi-1, marconi-2, marconi-3, marconi-4 | 21:50 |
| kgriffs | murmur3(project_id + queue_name) % 4 | 21:50 |
| kgriffs | something like that | 21:50 |
| kgriffs | (I haven't seen the latest code) | 21:50 |
| kgriffs | within each DB we would partition the messages collection by project | 21:51 |
| flaper87 | kk, it sounds to me that both things can be the default behavior of mongodb's driver | 21:51 |
| flaper87 | I don't see why multi-db should be turned of / on | 21:51 |
| flaper87 | one can simply specify to use 1 db | 21:52 |
| flaper87 | for the whole thing | 21:52 |
| kgriffs | yep | 21:52 |
| flaper87 | kk | 21:52 |
| kgriffs | you may get a tiny boost from avoiding the murmurhash, but probably not noticeable | 21:52 |
| kgriffs | and as long as operators are advised to increase nssize, partitioning the messages collection by project ID should be OK as well | 21:52 |
| kgriffs | just thought of something | 21:54 |
| flaper87 | kgriffs: a good documentation should do that for us | 21:54 |
| kgriffs | old tenants may clog up the namespace, so maybe we need eventually a way to GC inactive projects | 21:54 |
| flaper87 | kgriffs: if queue's are empty, then we can delete them | 21:55 |
| flaper87 | I guess | 21:55 |
| flaper87 | kgriffs: namspace creation is really cheap in mongodb | 21:55 |
| kgriffs | sure, just somebody may someday hit 3 million limit. :p | 21:56 |
| kgriffs | (that would be a lot of happy customers!) | 21:56 |
| * ametts will be happy to have that problem | 21:56 | |
| flaper87 | If we hit that issue, the driver should rebalance the dbs | 21:57 |
| flaper87 | and put the project in a separate db | 21:57 |
| kgriffs | good point | 21:57 |
| kgriffs | https://blueprints.launchpad.net/marconi/+spec/partition-messages-collection | 21:58 |
| kgriffs | since this would be a breaking change, I'd like to do it sooner rather than later | 21:58 |
| kgriffs | but let's wait to see what you find out from 10gen peeps | 21:59 |
| flaper87 | kgriffs: Mongodb Inc :D | 22:00 |
| flaper87 | the rebranded 10gen | 22:00 |
| flaper87 | :D | 22:00 |
| flaper87 | they* | 22:00 |
| kgriffs | no kidding? | 22:00 |
| flaper87 | no kididng | 22:00 |
| kgriffs | http://www.mongodb.com/ | 22:00 |
| kgriffs | heh | 22:00 |
| kgriffs | zyuan_: are you working on making the unix timestamp vs. date object change, or just investigating? | 22:01 |
| * kgriffs just realized he didn't get to any reviews today | 22:01 | |
| flaper87 | kgriffs: tests tests tests | 22:01 |
| flaper87 | :D | 22:01 |
| kgriffs | flaper87: re filtering out expired... | 22:02 |
| kgriffs | megan_w: you around to discuss ^^^ | 22:02 |
| flaper87 | btw, lets hold some patches back 'til we migrate under openstack | 22:02 |
| kgriffs | ? | 22:02 |
| kgriffs | flaper87: ok | 22:02 |
| *** ayoung has joined #openstack-marconi | 22:02 | |
| kgriffs | flaper87: ETA on the migration? | 22:02 |
| flaper87 | I'd say 1 or 2 days, I'll submit a patch tomorrow morning and start pinging the hell out of -infra | 22:02 |
| kgriffs | heh | 22:03 |
| kgriffs | OK, I will refrain from approving anything for a couple days. If oz needs something sooner he can cherry-pick or whatever | 22:04 |
| kgriffs | flaper87: just saw the cache patch got deferred until Icehouse | 22:05 |
| kgriffs | bummer | 22:05 |
| flaper87 | yeah :( | 22:06 |
| *** russellb has joined #openstack-marconi | 22:07 | |
| flaper87 | Ok guys, it's happening: https://review.openstack.org/#/c/44963/ | 22:28 |
| flaper87 | kgriffs: FYI, I was told that everything will happen automagically so, no need to hold patches back | 22:31 |
| kgriffs | sweet, thanks | 22:33 |
| *** oz_akan_ has joined #openstack-marconi | 22:34 | |
| *** oz_akan_ has quit IRC | 22:38 | |
| *** jergerber has quit IRC | 22:48 | |
| *** amitgandhi has quit IRC | 22:49 | |
| *** kgriffs is now known as kgriffs_afk | 23:01 | |
| *** vkmc has quit IRC | 23:12 | |
| *** kgriffs_afk is now known as kgriffs | 23:30 | |
| *** kgriffs is now known as kgriffs_afk | 23:44 | |
| *** amitgandhi has joined #openstack-marconi | 23:51 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!
