| *** shu-mutou-AFK is now known as shu-mutou | 00:37 | |
| *** yanyanhu has joined #openstack-zun | 01:48 | |
| *** yuanying has quit IRC | 02:47 | |
| *** sudipto has joined #openstack-zun | 03:17 | |
| *** sudipto has quit IRC | 03:24 | |
| *** sudipto has joined #openstack-zun | 03:35 | |
| *** sudipto has quit IRC | 03:36 | |
| *** sudipto has joined #openstack-zun | 03:36 | |
| *** sudipto has quit IRC | 03:36 | |
| *** yuanying has joined #openstack-zun | 03:50 | |
| *** chandankumar has joined #openstack-zun | 04:01 | |
| *** sudipto has joined #openstack-zun | 04:29 | |
| *** sudipto has quit IRC | 04:30 | |
| *** sudipto has joined #openstack-zun | 04:33 | |
| *** sudipto has quit IRC | 04:34 | |
| *** sudipto has joined #openstack-zun | 04:34 | |
| *** sudipto has quit IRC | 04:51 | |
| *** flwang1 has quit IRC | 05:09 | |
| *** mkrai has joined #openstack-zun | 05:20 | |
| *** chandankumar has quit IRC | 05:32 | |
| *** chandankumar has joined #openstack-zun | 05:32 | |
| *** sudipto has joined #openstack-zun | 06:00 | |
| *** manikanta_tadi has joined #openstack-zun | 06:01 | |
| *** janki has joined #openstack-zun | 06:02 | |
| *** sudipto_ has joined #openstack-zun | 06:06 | |
| *** sudipto has quit IRC | 06:09 | |
| *** vikasc has joined #openstack-zun | 06:11 | |
| *** yasemin has joined #openstack-zun | 06:55 | |
| *** flwang1 has joined #openstack-zun | 07:29 | |
| *** mikelk has joined #openstack-zun | 07:30 | |
| yasemin | hi, ı work on installation nova-docker in multi nodes openstack mitaka systems. how can I configure nova-scheduler filter? | 07:39 |
|---|---|---|
| mkrai | Hi sudipto_ | 07:41 |
| *** mikelk has quit IRC | 07:42 | |
| *** xiangxinyong_ is now known as xiangxinyong | 07:44 | |
| *** mikelk has joined #openstack-zun | 07:51 | |
| *** vikasc has quit IRC | 07:53 | |
| *** shu-mutou has quit IRC | 08:13 | |
| sudipto_ | mkrai, hello | 08:15 |
| sudipto_ | sorry was out for lunch | 08:15 |
| mkrai | sudipto_ Np | 08:15 |
| mkrai | I wanted to discuss about the scheduler part you were talking | 08:15 |
| sudipto_ | yeah sure. | 08:16 |
| *** chandankumar has quit IRC | 08:16 | |
| sudipto_ | So i was of the thought that - we should make the scheduler also an optional entity. | 08:16 |
| sudipto_ | which means - you should be able to plug your own schedulers if need be. | 08:16 |
| sudipto_ | and if that can be achieved then one of the implementation should be able to extend the mesos scheduler/executor framework. | 08:17 |
| mkrai | Ok so is there any scheduler available that is pluggable? | 08:17 |
| sudipto_ | and in such a case, sun would be a framework running on top of mesos. | 08:17 |
| mkrai | Ok mesos scheduler | 08:17 |
| sudipto_ | yes mesos - is what i am looking at. | 08:17 |
| mkrai | Will that fit on other run times also? | 08:18 |
| sudipto_ | kubernetes framework already runs on top of mesos. | 08:18 |
| sudipto_ | but if you are talking just runtimes - it has support for docker and mesos containers. | 08:18 |
| mkrai | could you please provide some links so that I can read about it? | 08:19 |
| sudipto_ | http://mesos.apache.org/documentation/latest/app-framework-development-guide/ | 08:19 |
| mkrai | That's cool, if so we don't have to write our own scheduler. Saving lots of effort | 08:19 |
| sudipto_ | unless someone really wants to write one of our own - that should also be possible - if we keep the scheduler optional. | 08:20 |
| *** yasemin has left #openstack-zun | 08:20 | |
| sudipto_ | inheriting the mesos scheduler should not be mandated. | 08:20 |
| sudipto_ | but it should be thought of as an option. | 08:21 |
| sudipto_ | mesos also has an executor associated with the scheduler - the executor is optional too. You can think of the executor much like something that would call your runtimes like docker. | 08:21 |
| mkrai | Compute in our case | 08:21 |
| sudipto_ | yeah. | 08:21 |
| mkrai | That calls out docker | 08:21 |
| sudipto_ | What i would like to find out though is - if we use the mesos executor - can we utilise the other openstack projects like the way we want with it or is it better to leave the executor framework to zun itself. | 08:22 |
| mkrai | Yes it is more easy to do it with our own service | 08:23 |
| sudipto_ | the other beauty of mesos is - you can run multiple frameworks at the same time. | 08:23 |
| *** vikasc has joined #openstack-zun | 08:23 | |
| mkrai | Scheduler will be an independent service | 08:23 |
| sudipto_ | so you could have a k8s framework and a zun framework running side by side. | 08:23 |
| sudipto_ | on top of the same set of h/w | 08:24 |
| mkrai | How well will it support scaling? | 08:24 |
| sudipto_ | mesos is pretty popular and it's one of the common adoption models at the moment. | 08:25 |
| sudipto_ | mkrai, read this too: https://github.com/docker/swarm/blob/master/cluster/mesos/README.md | 08:25 |
| *** yasemin has joined #openstack-zun | 08:26 | |
| mkrai | Cool I am aware of mesos popularity but haven't read much about it | 08:27 |
| mkrai | I will go through this links | 08:28 |
| mkrai | I will get back to you in case I have any confusion | 08:28 |
| mkrai | sudipto_, Ok so now for the nova-integration issue | 08:29 |
| sudipto_ | mkrai, sounds good. I am also trying out some stuff at my end. | 08:29 |
| mkrai | cool | 08:29 |
| sudipto_ | mkrai, ok nova-integration - i am not too sure about it. | 08:29 |
| sudipto_ | but that's me. | 08:30 |
| mkrai | Ok agree :) | 08:30 |
| sudipto_ | Do you follow the nova mailing list? | 08:30 |
| mkrai | I know you don't like it much | 08:30 |
| mkrai | openstack-dev | 08:30 |
| mkrai | Not much | 08:30 |
| sudipto_ | no no i do like nova :-) however, the fact that it's designed to address the use cases it thinks are deemed important, makes it a bit harder to work with. | 08:30 |
| sudipto_ | so on that note | 08:31 |
| sudipto_ | let me share something | 08:31 |
| *** vikasc has quit IRC | 08:31 | |
| mkrai | No I was not talking about nova | 08:31 |
| sudipto_ | I sent out a note yesterday: http://osdir.com/ml/openstack-dev/2016-07/msg01580.html | 08:32 |
| sudipto_ | This is w.r.t booting a virtual machine with a docker image attached to it. Something on the lines of secure containers/hyper however more to do with the nova libvirt driver than anything else. | 08:33 |
| sudipto_ | and the approach too is different from the other projects. | 08:33 |
| mkrai | Ok I am reading out your mail | 08:33 |
| sudipto_ | now the reason i pointed out to this is - to give you sense of why Nova may not want containers after all. | 08:34 |
| sudipto_ | some of the replies to that thread suggest me that. | 08:34 |
| *** manikanta_tadi has quit IRC | 08:39 | |
| mkrai | sudipto_, Yes I agree with the replies | 08:42 |
| mkrai | It is not good to support containers directly inside nova | 08:43 |
| mkrai | It is not meant to. I suppose you also have the same feeling | 08:43 |
| mkrai | There is a project in intel called clear container that runs a single container inside a vm | 08:45 |
| sudipto_ | well i have not replied to the comments yet. Since i want to wait it out. However, I am not suggesting to create a container in Nova with my RFC. So i guess that's a little different. However - what i generally understand from a nova project statement per say is that - they don't want containers. | 08:45 |
| mkrai | Yes I get it | 08:45 |
| sudipto_ | yeah clear containers uses kvm-tools and uses a different philosophy of executing the task. | 08:45 |
| mkrai | Yes | 08:45 |
| mkrai | However I feel the nova-integration is different | 08:46 |
| mkrai | nova-integration in zun | 08:46 |
| sudipto_ | mkrai, yeah can you explain that to me? I can't seem to understand if we are trying to do nova-integration - which essentially means providing a virt driver in nova to create containers using docker? | 08:46 |
| mkrai | from the replies I see that they fear to loose the features of other container related projects | 08:47 |
| mkrai | But we can have those features intact with zun | 08:47 |
| mkrai | Ok let me try to explain it | 08:47 |
| mkrai | :) | 08:47 |
| sudipto_ | yeah that'd be great. | 08:47 |
| mkrai | I think I should call Namrata also | 08:48 |
| mkrai | She was interested in the discussion | 08:48 |
| sudipto_ | Sure | 08:49 |
| *** Namrata_ has joined #openstack-zun | 08:50 | |
| mkrai | nova-integration just aims on providing a virt.driver in nova for zun like zun.ZunDriver | 08:51 |
| mkrai | That enables nova to create containers via zun | 08:51 |
| sudipto_ | yeah which essentially means you'd want to map the virtual machine APIs like nova boot to boot a container right? | 08:51 |
| mkrai | SO nova basically doesn't do anything here | 08:51 |
| mkrai | Yes sudipto_ | 08:51 |
| sudipto_ | why do you say nova doesn't do anything here? :) | 08:52 |
| sudipto_ | You'd be essentially implementing the compute manager apis in your virt driver which is a nova contract. No/ | 08:52 |
| sudipto_ | ? | 08:52 |
| mkrai | I mean it doesn't create containers by its own :) | 08:52 |
| sudipto_ | is it a right assumption to map this driver with the nova-docker driver? | 08:52 |
| mkrai | Yes | 08:53 |
| mkrai | You can say it will be same as nova-docker driver | 08:53 |
| sudipto_ | however you are saying instead of directly interfacing with the docker - this nova driver would call the zun APIs and that in turn will call the docker APIs | 08:54 |
| sudipto_ | and hence the analogy with ironic? | 08:54 |
| mkrai | Yes | 08:54 |
| mkrai | Exactly | 08:54 |
| sudipto_ | I finally have got an understanding with a few questions. | 08:55 |
| mkrai | Superb | 08:55 |
| sudipto_ | When the nova driver is called - it has already selected a host. | 08:55 |
| sudipto_ | then asking zun to create containers from there doesn't make sense. | 08:55 |
| mkrai | Yes that the issue we were talking about | 08:55 |
| mkrai | Because nova will already pick a host, what do our scheduler do | 08:56 |
| mkrai | Namrata, suggested to consider the host which zun-scheduler picks up | 08:56 |
| mkrai | Not nova one | 08:56 |
| Namrata_ | yeah. | 08:57 |
| mkrai | In ironic it is not a problem because they don't have scheduler of their own | 08:57 |
| sudipto_ | there seems to be a missing piece here. If you talking about a virt driver - it's always on the compute node. Then you seem to suggest that you'd like to by pass the nova-scheduler. | 08:58 |
| sudipto_ | i don't think the nova-scheduler is detachable at the moment. | 08:58 |
| mkrai | Yes it is tightly coupled | 08:59 |
| sudipto_ | and your primary assumption is built around that. | 08:59 |
| *** chandankumar has joined #openstack-zun | 08:59 | |
| mkrai | Ok sudipto_ I think below flow might clear your confusion | 08:59 |
| sudipto_ | and if you have called into the nova-scheduler already - there's a conflict. | 08:59 |
| mkrai | n-api -> n-cond -> n-sched -> n-cpu -> zun-api -> zun-scheduler -> zun-compute -> docker | 09:00 |
| mkrai | This is just my thought | 09:01 |
| mkrai | I am not sure whether above one is correct or not | 09:01 |
| mkrai | And you meant n-api -> n-cond -> n-sched -> n-cpu -> zun-compute -> docker | 09:01 |
| mkrai | Right? | 09:01 |
| sudipto_ | honestly i didn't mean anything. the last flow is the same as nova-docker which i know had issues with being in tree with the nova compute manager. | 09:02 |
| sudipto_ | However your flow - is not the right one either. | 09:02 |
| sudipto_ | you can't go south bound and then north bound and then eventually south bound | 09:02 |
| mkrai | I am not sure how does ironic driver work | 09:03 |
| mkrai | But that should be the path we should follow? | 09:03 |
| mkrai | sudipto_, there? | 09:10 |
| sudipto_ | see this is my 2 paisas on this. We should focus on defining and creating the basics of zun right now - than worry about a nova-integration. However, if there's a volunteer who's eager to do this in nova - i think a good approach is to start by writing an RFC to nova the implementation details. | 09:10 |
| mkrai | Yes I completely agree | 09:10 |
| mkrai | I just wanted to discuss because I didn't like this idea | 09:10 |
| sudipto_ | With that said - i would like to know the basic motivation behind doing this in nova? Given that zun is prepared to be standalone? | 09:11 |
| mkrai | Sorry my last statement was wrong. typo :D | 09:11 |
| sudipto_ | i am guessing this could be because we want to tap into the popularity of nova and if someone is really already using nova - we want them to start using zun by making minimal changes? | 09:11 |
| mkrai | Selling point for Zun, as you stated in your mail | 09:11 |
| mkrai | Yes exactly | 09:12 |
| mkrai | You got that | 09:12 |
| mkrai | Popularity of nova | 09:12 |
| sudipto_ | and i guess we want them to treat zun as a runtime as opposed to a project in such a case/ | 09:12 |
| sudipto_ | ? | 09:12 |
| sudipto_ | so if that's what we would want to do then, zun should have some real value adds over the nova-docker driver. | 09:13 |
| sudipto_ | The scenario could be - if you running zun runtime on a host - there is a nova driver that can talk to it and do your necessary things | 09:13 |
| sudipto_ | there's no need of a scheduler in such a case, neither the api is going to be the same as the zun-api that we would define for the project. | 09:14 |
| sudipto_ | it sounds like it would be a mere wrapper over the docker or some such runtime APIs. | 09:14 |
| sudipto_ | so if we stop thinking about nova-docker for a moment and start talking about nova-zun - and give a flexibility to the user that even if they have a core runtime as docker/rocket - on their host - they could use this virt driver to call a zun api - that would abstract the backend. | 09:16 |
| sudipto_ | think it of something like this n-sched --> n--cond --> n-zun --> zun runtime --> docker/rocket | 09:17 |
| mkrai | Here the zun runtime is the compute agent? | 09:17 |
| sudipto_ | mkrai, yup | 09:17 |
| sudipto_ | the zun compute agent which will sit side by side with the nova one. | 09:18 |
| sudipto_ | or it could be a just a third party like libvirt. | 09:18 |
| mkrai | Yes if we go with this flow we need to worry about the scheduler issue | 09:18 |
| sudipto_ | we don't right? | 09:18 |
| sudipto_ | there's only one scheduler in this case, that is of nova's | 09:19 |
| sudipto_ | the zun runtime is completely different than the zun-api for the project | 09:19 |
| mkrai | Yes | 09:19 |
| sudipto_ | it's more or less like libvirt. | 09:19 |
| mkrai | Yeah agree | 09:19 |
| sudipto_ | a third party dependency | 09:19 |
| sudipto_ | to make the zun virt driver work. | 09:19 |
| sudipto_ | so if you have a system where there's no hypervisor - you just install the zun runtime third party (it can optionally pull docker/rocket as runtimes) - and work with nova. | 09:20 |
| mkrai | Yes that's the actual intention behind the work | 09:21 |
| mkrai | As you said we should first aim on zun :) | 09:21 |
| sudipto_ | i think then the above flow might be simpler to do. | 09:22 |
| sudipto_ | with that said - nova seems to again have a hard dependency on glance for images. | 09:22 |
| mkrai | Yeah and no layering support :( | 09:22 |
| mkrai | But I remember there is some bp for that | 09:22 |
| sudipto_ | hence i liked the idea of working with a docker private registry or some such image repo. | 09:23 |
| mkrai | But still the dependency won't go in case of nova-zun driver | 09:24 |
| mkrai | For zun, we can consider this solution | 09:24 |
| mkrai | *this* private registry | 09:25 |
| sudipto_ | yeah unless, we are ready to work with those limitations. | 09:25 |
| mkrai | Unless the client are ready ;) | 09:25 |
| sudipto_ | fwiw - updating the images often may be more of a dev workflow than an enterprise workflow | 09:25 |
| sudipto_ | i don't see anyone willing to commit and push docker images on a regular basis - unless they are like developers. | 09:26 |
| sudipto_ | if you imagine a mysql application running on a laptop - with a data backend being on a volume - you probably would not want to do a commit/push on it often. | 09:26 |
| sudipto_ | infact i wouldn't do it unless i have to upgrade. | 09:27 |
| mkrai | Yes agree | 09:28 |
| sudipto_ | now in this case, the upgrade scenario would mean - let's pull a new docker image into glance (the upgraded one) and deploy that | 09:28 |
| mkrai | But in zun, it will be good to have support for both | 09:29 |
| sudipto_ | both being? | 09:29 |
| sudipto_ | dev and enterprise you mean? | 09:29 |
| mkrai | Yes private registry and glance | 09:30 |
| mkrai | sudipto_, I have to go for lunch now. I am starving :D | 09:31 |
| mkrai | I was a very good discussion | 09:31 |
| mkrai | Thanks for your time :) | 09:31 |
| Namrata_ | Thanks.. | 09:31 |
| sudipto_ | alright sure. have some food. it's pretty late. | 09:31 |
| mkrai | Thanks Namrata :) | 09:31 |
| sudipto_ | I guess from a consensus per say | 09:31 |
| sudipto_ | let's start a ether pad | 09:31 |
| sudipto_ | with all these thoughts | 09:31 |
| mkrai | Yeah sure | 09:31 |
| sudipto_ | i will do that. | 09:32 |
| sudipto_ | hopefully by the time you return | 09:32 |
| mkrai | Cool | 09:32 |
| sudipto_ | unless there's already one that i am not aware of? | 09:32 |
| mkrai | There is one but not populated | 09:32 |
| mkrai | Let me get the linl | 09:32 |
| mkrai | sudipto_, https://etherpad.openstack.org/p/zun-containers-nova-integration | 09:33 |
| sudipto_ | ok great | 09:33 |
| mkrai | See you. Bye! | 09:33 |
| sudipto_ | see ya! | 09:39 |
| *** manikanta_tadi has joined #openstack-zun | 09:51 | |
| mkrai | Hi sudipto_ I will read the etherpad later today | 09:59 |
| *** yanyanhu has quit IRC | 10:23 | |
| *** mkrai has quit IRC | 10:30 | |
| *** manikanta_tadi is now known as manikanta_afk | 10:46 | |
| *** manikanta_afk is now known as manikanta_tadi | 10:46 | |
| *** chandankumar has quit IRC | 10:50 | |
| *** chandankumar has joined #openstack-zun | 10:51 | |
| *** sudipto_ has quit IRC | 11:33 | |
| *** sudipto has joined #openstack-zun | 11:57 | |
| sudipto | Namrata you can see the ether pad - i have updated it with my thoughts. | 12:08 |
| sudipto | hongbin, good morning. | 12:08 |
| sudipto | I have updated my thoughts at https://etherpad.openstack.org/p/zun-containers-nova-integration | 12:10 |
| yasemin | zun is the same nova-docker project ?? | 12:13 |
| dims_ | oh dear! i am just in the process of moth balling nova-docker driver | 12:14 |
| dims_ | please don't! | 12:14 |
| dims_ | sudipto : Namrata : hongbin ^^ | 12:15 |
| sudipto | dims_, i wrote about 5 points why we should not do it :) | 12:16 |
| dims_ | thanks! | 12:16 |
| dims_ | right way to do this with Nova if at all is to follow the LXC model where LXC is under libvirt, Nova cores will support that. They will not like another container driver. | 12:17 |
| dims_ | https://libvirt.org/drvlxc.html | 12:18 |
| sudipto | yeah lxc or i saw parallels also being embedded in the code. | 12:18 |
| dims_ | parallels is via libvirt too https://libvirt.org/drvparallels.html | 12:19 |
| sudipto | yeah | 12:19 |
| sudipto | i have put warnings in that ether pad on why we should not tread that path multiple times. It's easier said than done tbh. | 12:20 |
| sudipto | However if someone is willing to do it - i thought i should help in removing the technical roadblock they had w.r.t figuring out how to eradicate a scheduler need there :) | 12:21 |
| sudipto | yasemin, no | 12:22 |
| *** janki has quit IRC | 12:23 | |
| Namrata | sudipto, i will see the etherpad..Thanks | 12:33 |
| Namrata | dims_ ,Yes.. | 12:34 |
| *** manikanta_tadi has quit IRC | 12:35 | |
| *** sudipto has quit IRC | 12:39 | |
| *** sudipto has joined #openstack-zun | 12:44 | |
| *** sudipto has quit IRC | 13:02 | |
| *** sudipto has joined #openstack-zun | 13:04 | |
| *** janki has joined #openstack-zun | 13:07 | |
| *** sudipto has quit IRC | 13:07 | |
| *** sudipto has joined #openstack-zun | 13:09 | |
| *** Namrata_ has quit IRC | 13:21 | |
| *** sudipto has quit IRC | 13:21 | |
| *** sudipto has joined #openstack-zun | 13:30 | |
| *** chandankumar has quit IRC | 13:50 | |
| *** sudipto has quit IRC | 13:56 | |
| *** sudipto has joined #openstack-zun | 13:58 | |
| hongbin | OK, will discuss the nova integration in the next meeting | 14:02 |
| *** sudipto has quit IRC | 14:08 | |
| *** sudipto has joined #openstack-zun | 14:18 | |
| *** sudipto has quit IRC | 14:21 | |
| *** sudipto has joined #openstack-zun | 14:28 | |
| *** Namrata_ has joined #openstack-zun | 14:31 | |
| *** Namrata_ has quit IRC | 14:40 | |
| *** janki has quit IRC | 14:46 | |
| *** janki has joined #openstack-zun | 14:56 | |
| *** vikasc has joined #openstack-zun | 15:07 | |
| hongbin | flwang: flwang1 there? | 15:14 |
| sudipto | hongbin, it might be late night for him in nz at the moment :) | 15:16 |
| hongbin | Yes, it is. | 15:16 |
| sudipto | hongbin, did you get a chance to think about the mesos scheduler bit? | 15:17 |
| *** openstackgerrit has quit IRC | 15:18 | |
| hongbin | sudipto: Yes, but not in deep | 15:18 |
| *** openstackgerrit has joined #openstack-zun | 15:18 | |
| sudipto | hongbin, ok | 15:18 |
| hongbin | sudipto: It looks to me an interesting idea | 15:19 |
| hongbin | sudipto: However, I am not sure if it is ok to have an OpenStack service to be a mesos framework. It sounds strange, although I couldn't find any specific problem | 15:20 |
| *** yuanying_ has joined #openstack-zun | 15:20 | |
| hongbin | That means install Zun requires to install mesos | 15:20 |
| sudipto | hongbin, well - i don't think it should be a hard dependency | 15:21 |
| sudipto | hongbin, with this we are definitely trying to do something different than usual - however - given the number of COEs in the container space - mesos seems to be one unifying layer. | 15:21 |
| hongbin | If it is a soft dependency, then Zun needs to have another option for scheduling | 15:21 |
| sudipto | hongbin, yup - i thought the team is anyway very keen on having their own scheduler. | 15:22 |
| *** yuanying has quit IRC | 15:22 | |
| sudipto | and i feel that's OK to have if you want to really operate on a pure openstack environment. | 15:23 |
| sudipto | in an ideal world i would also like to run nova with the mesos scheduler - that way zun and nova can use the same scheduler and we can have just one common set of hardware :) | 15:23 |
| hongbin | Maybe some people already run the whole OpenStack in mesos | 15:24 |
| hongbin | like how they run OpenStack in Kubernetes | 15:24 |
| sudipto | Well that's different than running it as a framework. | 15:25 |
| sudipto | in such a case, the openstack infra would still need to be separate than the container infra | 15:25 |
| hongbin | Oh, yes. You are right | 15:25 |
| hongbin | I will bring this topic to the next meeting | 15:26 |
| hongbin | See how other folks think about it | 15:26 |
| sudipto | ok few more thoughts. There are two aspects to a mesos framework - one is to extend their scheduler and the other is to use their executor framework. | 15:27 |
| sudipto | their executors at the moment support docker and mesos containers. | 15:28 |
| hongbin | Yes | 15:28 |
| hongbin | We might need a zun executor | 15:28 |
| *** janki_ has joined #openstack-zun | 15:28 | |
| sudipto | now given the zun executor is eventually going to call the docker APIs - it sounds like a duplicate. But it might still be alright for leveraging the other openstack projects for storage and network. | 15:29 |
| hongbin | The storage and network parts are not clear | 15:30 |
| sudipto | Swarm is intact also built as a framework on mesos - even though it's still probably experimental | 15:30 |
| sudipto | https://github.com/docker/swarm/blob/master/cluster/mesos/README.md | 15:30 |
| sudipto | something like this. | 15:30 |
| hongbin | Yes | 15:30 |
| sudipto | and i feel we can tread this path from the start. | 15:30 |
| sudipto | built in scheduler + a mesos 3rd party scheduler. | 15:30 |
| *** janki has quit IRC | 15:30 | |
| *** janki_ is now known as janki | 15:31 | |
| hongbin | Yes, I think that will work | 15:31 |
| hongbin | If the design of scheduler is extentible, then mesos scheduler can be plugin | 15:32 |
| sudipto | yeah | 15:33 |
| hongbin | Maybe assume the mesos scheduler is remote | 15:34 |
| sudipto | i guess we have to build independent services from the start. Like the API service should be totally independent of the scheduler | 15:34 |
| hongbin | agree | 15:34 |
| *** mikelk has quit IRC | 15:34 | |
| sudipto | yeah i will be trying to write a dummy mesos scheduler and share my thoughts around - what's the best interface like. At the moment it has support for both RPC and REST | 15:34 |
| hongbin | ok | 15:35 |
| sudipto | RPC uses some kind of protobuff messaging framework which is different from AMQP - however if kept separate it should work. | 15:35 |
| *** vikasc has quit IRC | 15:35 | |
| hongbin | k | 15:35 |
| *** janki_ has joined #openstack-zun | 15:51 | |
| *** janki has quit IRC | 15:52 | |
| *** janki_ is now known as janki | 15:53 | |
| *** chandankumar has joined #openstack-zun | 16:20 | |
| *** mkrai has joined #openstack-zun | 16:48 | |
| *** mkrai has quit IRC | 17:34 | |
| *** chandankumar has quit IRC | 17:56 | |
| *** sudipto has quit IRC | 18:11 | |
| *** janki has quit IRC | 18:12 | |
| *** janki has joined #openstack-zun | 18:18 | |
| *** flwang1 has quit IRC | 20:18 | |
| flwang | hongbin: what's up? | 21:37 |
| hongbin | flwang: hey | 21:37 |
| hongbin | flwang: want to ask you about the Glance support for docker images | 21:37 |
| flwang | sure | 21:38 |
| hongbin | flwang: I went thougth the glare spec, but still not sure if it can be used | 21:38 |
| hongbin | Basically, are you familiar with Glare? | 21:39 |
| hongbin | remove "Basically" | 21:39 |
| hongbin | https://review.openstack.org/#/c/283136/ | 21:39 |
| flwang | glare is most like an artifacts repo | 21:39 |
| hongbin | It is intend to be the backend of Glance? | 21:40 |
| hongbin | Or it is independent of Glance? | 21:40 |
| flwang | based on my understanding, now it will still be part of glance, just like aodh and ceilometer | 21:41 |
| flwang | but glare is not a **backend** of glance | 21:41 |
| flwang | you can take it as a metadata repo | 21:41 |
| hongbin | OK | 21:42 |
| flwang | TBH, i don't really understand the details about how glare can be used for the container support | 21:42 |
| hongbin | Then, how it work with container images? For example, if users upload a docker image, how the flow looks like? | 21:43 |
| hongbin | I see | 21:43 |
| flwang | without glare, you can also upload a new image | 21:43 |
| hongbin | True | 21:43 |
| flwang | but the problem is, glance doesn't support the multi layers of docker image | 21:44 |
| hongbin | Yes, and glare is supposed to solve that | 21:44 |
| flwang | i think for this case, glare just store the version metadata | 21:45 |
| flwang | and in glance, it still need to store multi images | 21:45 |
| flwang | brb in 5 mins | 21:45 |
| hongbin | k | 21:45 |
| flwang | back | 21:50 |
| hongbin | flwang: It looks nobody is working on glare right now? | 21:51 |
| *** flwang1 has joined #openstack-zun | 21:51 | |
| flwang | what does that mean? working on glare for zun? | 21:52 |
| flwang | or working for glare? | 21:52 |
| hongbin | no. How active is the glare community | 21:52 |
| hongbin | Frankly, it looks this project is dead, since I cannot find any work besides the spec | 21:53 |
| flwang | or basically glare is a part of glance as i mentioned above, so glance team is working on that, but actually, several mirantis guys I would say | 21:53 |
| flwang | hongbin: no, that's not true | 21:53 |
| flwang | the history is | 21:53 |
| flwang | glare was a part of glance v3 | 21:54 |
| hongbin | I see | 21:54 |
| flwang | and somebody complained the v3 because nova is still using v1, so v3 is like a joke | 21:54 |
| hongbin | :) | 21:54 |
| flwang | so the conclusion is split glare out and stop the v3 for now | 21:55 |
| hongbin | I see | 21:55 |
| flwang | so glare is ready for use | 21:55 |
| flwang | but will be delivered with a separated service, that's what i understand now | 21:55 |
| hongbin | I see | 21:55 |
| hongbin | Another question | 21:56 |
| hongbin | I heard somebody has proposed Glance to provide a docker registry compatible API | 21:56 |
| hongbin | Do you know anything about that? | 21:57 |
| hongbin | flwang: ^^ | 21:57 |
| flwang | oh, really? | 21:57 |
| hongbin | ..... | 21:57 |
| flwang | i have no idea about that, that's a crazy idea :) | 21:57 |
| flwang | when you said 'heard' , is there any link or anything i can take a look? | 21:58 |
| hongbin | I heard in one session in a summit | 21:58 |
| hongbin | Forgot who said that | 21:58 |
| flwang | ok, i will talk with nikhil and i think if it's on the roadmap, he must be aware | 22:00 |
| flwang | but basically, i think that's a long way | 22:00 |
| flwang | i would like to back to the original problem | 22:00 |
| flwang | or i would say requirements from zun | 22:01 |
| flwang | for glance | 22:01 |
| flwang | IIUC, the only main problem for glance is the multi layers support, right? | 22:01 |
| hongbin | In Zun, glance should served as a private docker registry equivalent | 22:01 |
| flwang | anything else? | 22:01 |
| hongbin | That is everything I think | 22:01 |
| flwang | i think glance can serve as a docker registry, and when you say 'private' i think it means multi tenant isolation, right? | 22:02 |
| hongbin | Yes, authentication, authorization, multi-tenancy is a plus | 22:03 |
| flwang | so, only the multi layers issue | 22:04 |
| hongbin | Maybe not only in ZUn, Magnum also needs it | 22:04 |
| hongbin | Yes, multi-layers issue | 22:04 |
| hongbin | I could go to the Glance channel with you if you want | 22:04 |
| flwang | let me ping nikhil first | 22:05 |
| flwang | about 3 years ago, i had some discussions with Sam, https://twitter.com/sam_alba | 22:08 |
| flwang | he is the core developer of docker image, IIRC | 22:09 |
| flwang | we're trying to support(natively?) docker image in glance, but unfortunately, we didn't make big progress | 22:10 |
| hongbin | I see | 22:10 |
| hongbin | why there is no progress in this direction? | 22:11 |
| flwang | i can't remember, too long ago | 22:11 |
| hongbin | That is fine | 22:12 |
| flwang | so, if we want this, it's most like add some new logic only for a specific image type | 22:14 |
| flwang | that's a challenge for glance i would say | 22:14 |
| flwang | in other words, we may need something extra 'fields'/tables in db to maintain the chain/relationship | 22:15 |
| hongbin | I see | 22:15 |
| flwang | i will talk with nikhil about this and get back to you | 22:16 |
| hongbin | k. thx | 22:16 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!