17:00:46 <sergmelikyan> #startmeeting murano
17:00:47 <openstack> Meeting started Tue Oct 20 17:00:46 2015 UTC and is due to finish in 60 minutes.  The chair is sergmelikyan. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:48 <Nikolay_St> hi
17:00:48 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:50 <openstack> The meeting name has been set to 'murano'
17:00:56 <sergmelikyan> hi folks o/
17:00:58 <kzaitsev_ip> O/
17:01:04 <freerunner> heey :)
17:02:10 <katyafervent> hi
17:03:33 <sergmelikyan> Today is a last meeting before the summit and I think we should have it short :)
17:03:37 <StanLagun> o/
17:04:23 <Nikolay_St> sergmelikyan: sure, let's run through it)
17:04:26 <sergmelikyan> So I guess I have only one topic from my side: agenda for our contributors meetup
17:04:29 <sergmelikyan> https://etherpad.openstack.org/p/murano-mitaka-contributors-meetup
17:04:36 <sergmelikyan> any suggestion?
17:06:21 <sergmelikyan> Please don't hesitate to add topics that you would like to discuss :)
17:06:25 <Nikolay_St> sergmelikyan: what is 'Service API' topic?
17:06:28 <sergmelikyan> #topic Open Discussion
17:06:47 <Nikolay_St> well
17:06:54 <sergmelikyan> @Nikolay_St We didn't yet explain this topic in the etherpad, I will work on that by tomorrow
17:07:10 <Nikolay_St> I have a really small suggestion for open discussion
17:07:28 <sergmelikyan> it's a way to make our actions API more convenient, like change endpoint URL and etc...
17:07:54 <Nikolay_St> I'd like to start a work on 'APIv2' and today discussed it with sergmelikyan
17:08:19 <Nikolay_St> the good starting point could be creating a copy of existing API depends on Flask
17:08:29 <Nikolay_St> what do you think about it, guys?
17:09:14 <sergmelikyan> Nikolay_St: please add to the etherpad?
17:09:42 <Nikolay_St> sergmelikyan: ok
17:10:08 <StanLagun> Don't think it's a good idea. There is no point to switch framework for existing API if we are going to design new one and this switch gives us no clear benefits
17:10:41 <sergmelikyan> StanLagun: starting point
17:10:58 <sergmelikyan> otherwise we will never get out hands to implement that
17:11:08 <katyafervent> Flask? again?
17:11:34 <StanLagun> Starting point for what? Starting point would be implementing small part of APIv2 not to rewrite thing that already works fine
17:11:35 <sergmelikyan> and given that we thought about rewamping our vision of environment<>apps relations in object model - it may be good place to experiment
17:11:39 <katyafervent> ( we used to have murano repository related things on flask)
17:11:58 <sergmelikyan> StanLagun: I didn't say reimplemennt that thing from scratch
17:12:03 <kzaitsev_ws> why Flask?
17:12:14 <katyafervent> if we want to rewrite something we should forget about existing things
17:12:17 <sergmelikyan> copy :)
17:12:23 <sergmelikyan> katyafervent: nope
17:12:26 <katyafervent> and design from scratch
17:12:26 <kzaitsev_ws> I mean. Flask is not an api-centrik kind of thing
17:12:46 <StanLagun> sergmelikyan, that what Nikolay_St said. ...creating a copy of existing API...
17:13:09 <sergmelikyan> I propose to have this discussion on summit and think through until that. Glance team can have good hints how to do that properly
17:13:21 <kzaitsev_ws> I thought there was a dedicated thing in the global requirements
17:13:31 <sergmelikyan> StanLagun: copy, but not creating from scratch
17:13:38 <Nikolay_St> kzaitsev_ws: about API framework?
17:14:03 <kzaitsev_ws> can't remember the exact name. but Fask is a web framework, like django
17:14:09 <kzaitsev_ws> smaller in scale
17:14:15 <kzaitsev_ws> but still it's a web framework
17:14:17 <Nikolay_St> kzaitsev_ws: well
17:14:17 <StanLagun> I suggest to start with APIv2 design before implement anything
17:14:19 <sergmelikyan> kzaitsev_ws: pecan and wsgi?
17:14:20 <kzaitsev_ws> there 
17:14:26 <kzaitsev_ws> pecan yep
17:14:33 <Nikolay_St> Nikolay_St: may be I'm wrong with the name?
17:14:50 <Nikolay_St> kzaitsev_ws: pecan is not the standart
17:15:06 <katyafervent> StanLagun, + 1
17:15:17 <katyafervent> and picking framework is a separate topic
17:15:24 <kzaitsev_ws> neither is Flask
17:15:26 <Nikolay_St> and some teams said that it's not as good as it should be
17:15:43 <kzaitsev_ws> 'some teams said' is a lousy argument, don't you think?
17:15:49 <Nikolay_St> StanLagun: for how long we will wait before 'start design'?
17:15:59 <kzaitsev_ws> pecan can't do X and sucks at Y is better
17:16:11 <katyafervent> until we have a specification
17:16:17 <Nikolay_St> kzaitsev_ws: I have a link for the discussion about it.
17:16:41 <Nikolay_St> kzaitsev_ws: I think it contains some arguments
17:16:44 <StanLagun> Nikolay_St, you don't have to wait for anything. Design is a regular task that you can peek if you'd like. But design need to come before implementation
17:16:50 <kzaitsev_ws> please share, I'm all in if the arguments are solid
17:16:55 <katyafervent> api design spec and select framework can be done in separate
17:17:06 <katyafervent> know we are discussing two different things
17:17:22 <katyafervent> * now
17:17:29 <StanLagun> you are now more focused on the framework rather than with what you going to write on it. That scares me
17:17:40 <sergmelikyan> folks, folks.... :)
17:18:54 <kzaitsev_mb> StanLagun: if we pick the framework now — we're stuck with it for the next few years.
17:19:00 <sergmelikyan> StanLagun: let's go through with point that Nikolay_St and me supporting: create a copy of the current api (probable based on the new framework), should be easy task, right? When you are just changing api wrapper and routing
17:19:19 <kzaitsev_mb> which new framework?
17:19:27 <sergmelikyan> kzaitsev_mb: who cares right now?
17:19:27 <kzaitsev_mb> can we at least get a ML discussion on that?
17:19:43 <sergmelikyan> kzaitsev_mb: there are tons of them already from another teams :)
17:19:54 <kzaitsev_mb> sergmelikyan I care
17:20:00 <sergmelikyan> kzaitsev_mb: let me finish please
17:20:04 <kzaitsev_mb> sergmelikyan: that's why I care
17:20:21 <kzaitsev_mb> as if I can interrupt you over the internet
17:20:39 <StanLagun> kzaitsev_mb, I know, but we don't have to choose it right now. And we will also stick with new API for much longer I guess so I don't think framework name is what most important right now
17:20:55 <sergmelikyan> let's go through with point that Nikolay_St and me supporting: create a copy of the current api (probable based on the new framework), should be easy task, right? When you are just changing api wrapper and routing, and leave implementation as it is (we can reference same implementation which is used in v1 right?), then start changing parts of the API, writing new implementation.
17:21:04 <kzaitsev_mb> how can you implement something with the new framework without choosing it?
17:22:07 <sergmelikyan> and obviously do that having design first, StanLagun no worries about that
17:22:17 <StanLagun> sergmelikyan, lets first decide what new API should look like. Otherwise it looks like a 50/50 waste of time porting things that you may no longer need (and this requires testing and so on)
17:22:23 <sergmelikyan> I've just tired from the talks about new API v2 and nothing happening.
17:23:17 <sergmelikyan> StanLagun: we are not porting anything - we reference same implementation from v2, than let's say we are changing session mechanism and implement it in the new api. than do the same for the tasks and so on.
17:23:20 <sergmelikyan> bit by bit
17:23:34 <sergmelikyan> we will plan new api forever if we are going just do the talk
17:24:02 <StanLagun> sergmelikyan, how do you know that this is the optimal way if you don't have any design at all?
17:24:10 <kzaitsev_mb> I see what you mean. Have no objections to the idea.
17:24:30 <sergmelikyan> StanLagun: because we will have design WHEN we are going to change something
17:24:31 <kzaitsev_mb> Would like to have at least minimal discussion about the tech we choose for it
17:25:08 <sergmelikyan> kzaitsev_mb: sure thing, I propose you to check already existing discussions around pecan and flask + idea for abandoning eventlet
17:25:16 <StanLagun> sergmelikyan, cannot agree with that. We will have design when we start designing, not when we switch web framework. That doesn't make us closer to solution
17:25:19 <Nikolay_St> kzaitsev_ws: discussion is good)
17:25:43 <sergmelikyan> StanLagun: what framework does have with API design?
17:25:53 <Nikolay_St> and here is the mailing list discussion http://lists.openstack.org/pipermail/openstack-dev/2015-August/073156.html
17:26:00 <Nikolay_St> kzaitsev_ws: ^^
17:26:10 <StanLagun> nothing. So why waste our time on this instead of doing design?
17:26:25 <StanLagun> lets start with more important things
17:26:40 <sergmelikyan> StanLagun: design should come with use-cases, when you have use-cases you want to prototype, and that will give a way to do that.
17:27:35 <kzaitsev_mb> Seriously guys. This whole situation looks ugly. you've decided something, read some emails and started some work, which good. But you could at least write a simple small letter to the ML saying, "Hey, we've started doing this big important thing, rmember this X vs Y discussion — we've chose Y to implement the big thing, etc etc"
17:27:43 <StanLagun> agree with use cases and prototyping and do on. I just don't see how switch of framework help prototyping. Why not start with use cases first?
17:27:49 <sergmelikyan> It will be done anyway once you will start implementing any new thing, but I don't believe that we can design whole new API and then implement
17:27:56 <sergmelikyan> that does not work like that in open source
17:28:01 <sergmelikyan> or anywhere else
17:28:07 <Nikolay_St> kzaitsev_ws: we don't start anythinh
17:28:21 <kzaitsev_mb> Nikolay_St: don't or didnt'?
17:28:34 <Nikolay_St> kzaitsev_mb: didn't
17:28:45 <sergmelikyan> StanLagun: switching framework is possible, but is not necessity. I am talking about adding v2 endpoint which point to the same implementation as v1
17:28:56 <Nikolay_St> kzaitsev_mb: except two etherpads 2 months ago, I guess
17:29:33 <katyafervent> ativelkov, can help us with design and his experience in big api changes
17:29:54 <sergmelikyan> oh god... I feel like troll of the year :)
17:29:57 <Nikolay_St> katyafervent: if he has enough time for that
17:30:06 <katyafervent> Nikolay_St, I suggest to set up a couple of meetings where we will collect all use cases
17:30:08 <kzaitsev_mb> well, yeah.
17:30:24 <sergmelikyan> @katyafervent etherpad and e-mail regarding that didn't help at all
17:30:47 <sergmelikyan> you think on the meeting people will have better ideas from top of they heads?
17:31:01 <sergmelikyan> kzaitsev_mb: I have nothing against email, gosh
17:31:09 <kzaitsev_mb> k. I see.
17:31:15 <katyafervent> We have list of UI problems which based on lack of backend
17:31:21 <katyafervent> that can be a starting point
17:31:25 <kzaitsev_mb> I thought you've started the woek, while you were only considering doing the thing
17:31:40 <StanLagun> sergmelikyan, again, how does it make us closer to v2? There are many things that can be done in theory. But it all cost time/resources/etc. Instead of doing something that could be done later (it we decide that it needed at all) why not start instead with something that is 100% needed that is design, use cases etc. It might be that it is faster to start from scratch. Or that we don't need v2 at all. We don't know for sure
17:31:41 <StanLagun> now and doing something (even that simple task) without desigh doesn't look like a smart thing to do
17:32:08 <katyafervent> sergmelikyan, even 1 meeting can help to start the design and then we can discuss draft everywhere
17:32:10 <sergmelikyan> kzaitsev_mb: I was talking with Nikolay_St today, and we both feel that nothing going to happen, unless people will have an easy way to implement something in v2
17:32:28 <kzaitsev_mb> sergmelikyan: it's all in the wording. tbh.
17:33:01 <sergmelikyan> StanLagun: what do you think we should design in order to add v2 endpoint that point to the same implementation?
17:33:30 <StanLagun> nothing will happen until someones drives it. But this way it is more likely that nothing will change after the switch. You should be thinking how to drive this thing instead
17:33:46 <Nikolay_St> guys
17:33:48 <sergmelikyan> StanLagun: that is exactly what I am doing :)
17:33:48 <StanLagun> sergmelikyan, why do we need v2 endpoints at all?
17:34:19 <Nikolay_St> StanLagun: we have some problems with existing API
17:34:23 <Nikolay_St> I guess
17:34:24 <sergmelikyan> StanLagun: please, read arguments above, not going to repeat myself :) It's 9 in the evening, fingers are to tired
17:34:33 <StanLagun> there is nothing to design to make utility that erases HDD. But it doesn't mean we need to write one
17:34:53 <kzaitsev_mb> I thought you've started the woek, while you were only considering doing the thing, and the wording made me think, that you've made some tech decisions based on some arbitrary ideas.
17:35:09 <kzaitsev_mb> I'd like to appologise for being too swift to judge
17:35:18 <Nikolay_St> kzaitsev_mb: that's ok)
17:35:29 <kzaitsev_mb> #link http://lists.openstack.org/pipermail/openstack-dev/2015-August/073156.html
17:35:32 <kzaitsev_mb> for the record
17:36:32 <kzaitsev_mb> Nikolay_St: btw, the spec in questions considers using pecan. or am I reading it wrong?
17:37:26 <Nikolay_St> kzaitsev_mb: you're talking about the link?
17:37:55 <kzaitsev_mb> Nikolay_St: #link https://review.openstack.org/#/c/218155/1/specs/mitaka/remove-wsme.rst
17:37:56 <Nikolay_St> kzaitsev_mb: or about current discussion here?
17:37:58 <kzaitsev_mb> it says
17:38:13 <kzaitsev_mb> 'The most obvious choice is probably to use the Pecan'
17:38:27 <kzaitsev_mb> So I still would like some minimal discussion about the tech.
17:38:35 <kzaitsev_mb> like we have options A/B/C
17:38:56 <kzaitsev_mb> or we can have a spec like ceilometers, right?
17:39:29 <kzaitsev_mb> isn't that the most open way to do such things? =)
17:40:37 <Nikolay_St> kzaitsev_mb: I think I can start work on this kind of spec
17:40:52 <Nikolay_St> kzaitsev_mb: at least it's a small step forward, isn't it?
17:41:36 <kzaitsev_mb> Nikolay_St: yep. the link we both mentioned have a couple of interesting alternatives.
17:41:54 <Nikolay_St> kzaitsev_mb: sure)
17:42:07 <kzaitsev_mb> like Falcon, that's used in Zaqar and Flavio says, that they're happy with it.
17:43:21 <kzaitsev_mb> well, there are some options. maybe flask is the right tech. just would like to consider others.
17:43:37 <kzaitsev_mb> sergmelikyan: StanLagun: Nikolay_St what would you say if we called the api version 1.5?
17:43:40 <kzaitsev_mb> huh?
17:44:14 <Nikolay_St> kzaitsev_mb: what for?
17:44:37 <kzaitsev_mb> Nikolay_St: cause it won't be api v2 before we actually design v2.
17:44:48 <kzaitsev_mb> or 1.9
17:44:51 <Nikolay_St> kzaitsev_mb: sound good for me
17:45:53 <kzaitsev_mb> as far as I understand the point is to have a platform to experiment easily, do the boilerplate code now and to be able to expand it quickly after the design is there
17:46:39 <kzaitsev_mb> so we might create a 1.5, compatible with 1.0 on the new framework and then make breaking changes and call it 2.0
17:46:47 <kzaitsev_mb> might be a bad idea
17:46:54 <kzaitsev_mb> don't know, just thinking out loud
17:48:03 <kzaitsev_mb> sergmelikyan: StanLagun: are you still there? =)
17:48:12 <StanLagun> yep
17:50:30 <kzaitsev_mb> I think Serg decided to abandon us for being too edgy =)))
17:50:42 <sergmelikyan> kzaitsev_mb: I don't know what to say :)
17:51:09 <kzaitsev_mb> you've startled the hornets nest, I'm afraid =)
17:51:53 <Nikolay_St> but it works)
17:51:58 <Nikolay_St> finally
17:52:34 <sergmelikyan> You are guys fighting about different stuff and completely ignoring what I was saying :)
17:52:53 <sergmelikyan> I want to unblock contributors to be free working on the new ideas for our API.
17:53:04 <sergmelikyan> I want people stop talking and start doing
17:53:20 <sergmelikyan> I want to stop constant references to "we need to design whole api first"
17:53:48 <sergmelikyan> I want to have v1 finally stable and not add crutches on top of it
17:54:02 <StanLagun> there are several alternate ideas 1) make 1.5 2) make v2 and v3 in parallel 3) make experimental git branch 4) experiment on v1
17:54:33 <StanLagun> I also afraid of database issues because it is hard to experiment when you tied by existing database schema
17:54:50 <StanLagun> so there are too many questions for this short meeting
17:55:27 <Nikolay_St> StanLagun: I can send a letter to ML with some list of 'how to operate'
17:56:28 <sergmelikyan> Nikolay_St: I would wait until end of the summit :)
17:56:44 <sergmelikyan> Anyway people are too busy by summit activities to reply
17:56:48 <Nikolay_St> sergmelikyan: yeah, I forgot about summit
17:56:49 <StanLagun> If we want v1 to be rock-stable we need to thing on CI so that it would be impossible for change in v2 or anything to break v1
17:59:53 <StanLagun> can we pospone this for 1 month. There is ongoing design on next architecture that we are doing right now. It will materialize in next several weeks probably. This may be a better starting point for new API
18:00:16 <sergmelikyan> StanLagun: this is not anyhow related
18:00:18 <sergmelikyan> #endmeeting