| *** Qiming has quit IRC | 00:17 | |
| openstackgerrit | Merged openstack/senlin: Add unit test for cluster check action https://review.openstack.org/285896 | 01:00 |
|---|---|---|
| *** Qiming has joined #senlin | 01:13 | |
| *** zzxwill has joined #senlin | 01:13 | |
| Qiming | morning | 01:14 |
| zzxwill | Morning Qiming. | 01:17 |
| openstackgerrit | zzxwill proposed openstack/senlin: separate two different commands in two lines https://review.openstack.org/286348 | 01:23 |
| openstackgerrit | Qiming Teng proposed openstack/senlin: Simplify action initialization https://review.openstack.org/286351 | 01:37 |
| *** lixinhui_ has joined #senlin | 01:38 | |
| lixinhui_ | Qiming, there | 01:38 |
| lixinhui_ | ? | 01:38 |
| Qiming | yes | 01:38 |
| lixinhui_ | last night, I submit this https://review.openstack.org/#/c/286131/ | 01:38 |
| lixinhui_ | on hypervisor resource | 01:39 |
| lixinhui_ | it will be nice if you can help review | 01:39 |
| lixinhui_ | hope it can catch up the timeline | 01:39 |
| Qiming | okay | 01:39 |
| lixinhui_ | Thanks | 01:39 |
| Qiming | can we find a hypervisor by name? | 01:41 |
| lixinhui_ | yes | 01:43 |
| lixinhui_ | I thinl | 01:43 |
| lixinhui_ | think | 01:43 |
| Qiming | can you help try? | 01:44 |
| lixinhui_ | sure | 01:44 |
| lixinhui_ | Will confirm it then return to you | 01:44 |
| *** Yanyanhu has joined #senlin | 02:05 | |
| *** elynn has joined #senlin | 02:11 | |
| elynn | Morning | 02:13 |
| zzxwill | Morning Yanyan and Elynn. | 02:14 |
| elynn | :) | 02:16 |
| Yanyanhu | morning :) | 02:28 |
| openstackgerrit | Qiming Teng proposed openstack/senlin: Simplify action initialization https://review.openstack.org/286351 | 02:39 |
| *** dixiaoli has quit IRC | 02:41 | |
| *** idonotknow_ has joined #senlin | 02:55 | |
| openstackgerrit | zzxwill proposed openstack/senlin: separate two different commands in two lines https://review.openstack.org/286348 | 03:13 |
| *** yuanying has joined #senlin | 03:21 | |
| *** yuanying_ has quit IRC | 03:23 | |
| *** yuanying has quit IRC | 03:27 | |
| *** zzxwill has quit IRC | 03:36 | |
| *** zzxwill has joined #senlin | 03:44 | |
| *** elynn has quit IRC | 03:59 | |
| *** zzxwill has quit IRC | 04:03 | |
| *** yuanying has joined #senlin | 04:10 | |
| *** zzxwill has joined #senlin | 04:14 | |
| *** elynn has joined #senlin | 04:26 | |
| *** elynn has quit IRC | 04:30 | |
| *** elynn has joined #senlin | 04:31 | |
| *** zzxwill has quit IRC | 04:32 | |
| *** zzxwill has joined #senlin | 04:37 | |
| *** zzxwill has quit IRC | 05:20 | |
| openstackgerrit | Cindia-blue proposed openstack/senlin: Fix Health Manager Problems https://review.openstack.org/286387 | 05:28 |
| *** zzxwill has joined #senlin | 05:44 | |
| openstackgerrit | Cindia-blue proposed openstack/senlin: Fix Health Manager Problems https://review.openstack.org/286388 | 05:46 |
| *** dixiaoli has joined #senlin | 05:49 | |
| openstackgerrit | Cindia-blue proposed openstack/senlin: Fix Health Manager Problems https://review.openstack.org/286388 | 05:50 |
| openstackgerrit | Ethan Lynn proposed openstack/python-senlinclient: Fix node update receive a assertion error https://review.openstack.org/286391 | 05:53 |
| openstackgerrit | Merged openstack/senlin: separate two different commands in two lines https://review.openstack.org/286348 | 05:59 |
| *** shu-mutou-AWAY is now known as shu-mutou | 06:10 | |
| Qiming | hi, guys | 06:11 |
| elynn | Hi | 06:12 |
| Qiming | today we will have another weekly meeting | 06:12 |
| Qiming | I have put an agenda item to the meeting agenda | 06:12 |
| Qiming | we need to make a plan for the design summit | 06:13 |
| openstackgerrit | OpenStack Proposal Bot proposed openstack/senlin-dashboard: Imported Translations from Zanata https://review.openstack.org/286397 | 06:14 |
| Yanyanhu | ok, will think about it | 06:14 |
| Qiming | ttx is asking each team to present an estimation of space needs | 06:15 |
| Qiming | we will feed him with some numbers: # fishbowl slots, # workroom slots, and contributor meetup | 06:16 |
| Yanyanhu | maybe we can list topics we want to discuss in etherpad | 06:16 |
| Yanyanhu | like what we did for midcycle meetup | 06:17 |
| Qiming | it would be a pretty easy math if we have topics at hand | 06:17 |
| Yanyanhu | yes, maybe we can have a discussion and give a list in tonight weekly meeting | 06:18 |
| Qiming | that's the reason I'm communicating with you beforehand | 06:18 |
| Qiming | 1 hour is too short for brainstorming and discussion | 06:18 |
| Qiming | I'm creating a etherpad | 06:18 |
| Qiming | should we call it senlin-mitaka-summit or senlin-newton-summit? | 06:19 |
| Yanyanhu | maybe austin-summit? | 06:20 |
| Yanyanhu | this summit is for mitaka release, right? | 06:20 |
| Yanyanhu | so mitaka-summit is also ok I think | 06:20 |
| haiwei_ | should be for newton cycle | 06:20 |
| Qiming | when searching around, I found this: https://wiki.openstack.org/wiki/Design_Summit/Mitaka/Etherpads | 06:21 |
| Yanyanhu | ok, so the coming one should be newton | 06:23 |
| Qiming | https://etherpad.openstack.org/p/newton-senlin-sessions | 06:23 |
| *** zzxwill_ has joined #senlin | 06:33 | |
| *** zzxwill_ has quit IRC | 06:33 | |
| *** lixinhui_ has quit IRC | 06:34 | |
| openstackgerrit | Yanyan Hu proposed openstack/senlin: Rework to_dict method of sdk resource in functional test https://review.openstack.org/286403 | 06:41 |
| openstackgerrit | Yanyan Hu proposed openstack/senlin: Rework to_dict method of sdk resource in functional test https://review.openstack.org/286403 | 06:51 |
| *** lixinhui_ has joined #senlin | 06:54 | |
| openstackgerrit | Ethan Lynn proposed openstack/python-senlinclient: Fix node update receive a assertion error https://review.openstack.org/286391 | 06:58 |
| *** lixinhui_ has quit IRC | 07:10 | |
| openstackgerrit | Yanyan Hu proposed openstack/senlin: Add functional test for node get details https://review.openstack.org/286417 | 07:14 |
| *** zzxwill has quit IRC | 07:15 | |
| *** zzxwill has joined #senlin | 07:20 | |
| Qiming | hi, guys | 07:27 |
| elynn | hi | 07:27 |
| *** lixinhui_ has joined #senlin | 07:28 | |
| Qiming | just got a question from i18n team | 07:29 |
| Qiming | they were asking whether we can have a liaison on translation | 07:29 |
| Qiming | it is okay if we don't have one | 07:30 |
| Qiming | just please speak up if you want to assume such a role | 07:30 |
| Qiming | s/role/role+responsibility | 07:30 |
| Qiming | :) | 07:30 |
| zzxwill | I translated some strings for senlin and i18n core said senlin cores will approve the translation merge. | 07:37 |
| zzxwill | But I don't know the following process. | 07:37 |
| Qiming | zzxwill, so it means we will need one core member from senlin to review the translations? | 07:39 |
| Qiming | zzxwill, do you have a link to the patch? | 07:40 |
| Qiming | lixinhui, there? | 07:40 |
| zzxwill | Hold on for a second. | 07:40 |
| lixinhui | Yes, Qiming | 07:40 |
| Qiming | a question about the vSphereDRS policy | 07:41 |
| Qiming | I'm working on generalizing it to a generic affinity policy | 07:41 |
| Qiming | adding a property named 'enable_drs_extension' which defaults to False | 07:41 |
| Yanyanhu | hi, Qiming, the translation is between english and chinese? | 07:41 |
| openstackgerrit | Cindia-blue proposed openstack/senlin: Fix Health Manager Problems https://review.openstack.org/286388 | 07:42 |
| Qiming | yes, Yanyanhu | 07:42 |
| zzxwill | QiMing, there is no patch for the translation. https://translate.openstack.org/project/view/senlin | 07:43 |
| zzxwill | One can translate senlin as an i18n translator in Zanta. | 07:43 |
| Qiming | ah, looks like a very nice website | 07:44 |
| openstackgerrit | Cindia-blue proposed openstack/senlin: Fix Health Manager Problems https://review.openstack.org/286388 | 07:45 |
| zzxwill | So please confirm the i18n process with i18n team:) (I am not familiar with it and I'm afraid I might mislead you guys.) | 07:47 |
| Qiming | zzxwill, the translations will be proposed back to senlin when it is (half) done | 07:47 |
| Qiming | zzxwill, a million thanks for starting this | 07:50 |
| zzxwill | Happy to hear that as a small potato:) | 07:53 |
| lixinhui | Qiming, I am okay with your change on vSphereDRS | 07:53 |
| *** lixinhui_ has quit IRC | 07:54 | |
| lixinhui | If things goes on smoothly, we can customise the general policy for specific user case | 07:55 |
| lixinhui | s/goes/go | 07:55 |
| lixinhui | Existing vSphereDRSplacement does not expose DRS specific rules actually besides affinity and unti-affinity. | 07:57 |
| Qiming | lixinhui, but it does search for host names | 07:59 |
| lixinhui | Yes | 07:59 |
| lixinhui | That is reason we discussed once to name it vSphereDRS | 07:59 |
| Qiming | which is not necessary for all cases | 08:00 |
| Qiming | what I want to confirm is ... | 08:00 |
| Qiming | in current implementation, the policy is inserting a 'zone' key | 08:00 |
| Qiming | and the 'zone' value would default to 'nova' | 08:00 |
| Qiming | I want to know whether this is very specific to vsphere | 08:00 |
| lixinhui | The logic can be enabled with your add condition | 08:01 |
| lixinhui | no | 08:01 |
| lixinhui | that is common | 08:01 |
| lixinhui | even for vsphere nova | 08:01 |
| lixinhui | plugin | 08:01 |
| Qiming | you mean, when I'm specifying 'group' as part of the 'scheduler_hints', I HAVE TO provide a 'zone' key? | 08:02 |
| Qiming | I am not seeing that a requirement from nova api | 08:02 |
| Qiming | it sounds to me that only vSphere DRS requires a zone key, and that zone value has to be in format like '<zone_name>:<host_name>' | 08:04 |
| lixinhui | no | 08:04 |
| lixinhui | that is common | 08:04 |
| lixinhui | oh | 08:04 |
| lixinhui | you mean can we remove hostname? | 08:04 |
| Qiming | okay, let's start all over again | 08:05 |
| Qiming | question 1: to do an affinity based placement, we don't have to specify an availability zone, this is not required by nova api, right? | 08:05 |
| lixinhui | no. it is not enforced | 08:06 |
| Qiming | okay | 08:06 |
| Qiming | question 2: we can support an availability zone name as optional key. it means the affinity/anti-affinity will happen within an availability zone, right? | 08:08 |
| Qiming | this question is not specific to vSphere either | 08:08 |
| lixinhui | yes | 08:09 |
| lixinhui | it can cooperate with zone | 08:09 |
| Qiming | okay, now point 3 | 08:09 |
| Qiming | vsphere (as a special kind of 'hypervisor') will need the availability zone to be specified in format '<zone_name>:<drs_host>' | 08:10 |
| lixinhui | yes, that is way to find the vSphere cluster as a hypervisor backend | 08:11 |
| Qiming | because the 'drs_host' usually contain more than one physical machine --- some vsphere internals | 08:11 |
| Qiming | so, I will make the affinity policy to support an optional availability zone name, but I'm not defaulting that to 'nova' | 08:11 |
| Qiming | however, if 'enable_drs_extension' is set to True, we will check the zone name, and default that to 'nova' | 08:12 |
| Qiming | is this a viable solution? | 08:12 |
| lixinhui | 'nova' is the default zone name if no special creation actions with zone | 08:13 |
| Qiming | yes, but in production environment, I don't know what happens | 08:13 |
| Qiming | in devstack, that is true | 08:13 |
| lixinhui | I do not quiet sure I understand this question | 08:16 |
| lixinhui | nova is default set zone name by common nova | 08:16 |
| Qiming | yes | 08:16 |
| lixinhui | but user can generate their own zone | 08:16 |
| Qiming | that is the exactly the point | 08:16 |
| Qiming | if 'nova' is the implict az | 08:17 |
| Qiming | we don't need to make that assumption in our policy, let nova do it | 08:17 |
| lixinhui | en | 08:17 |
| Qiming | if we make an assumption that an az is 'nova' and pass that value to nova | 08:17 |
| Qiming | the implication is different | 08:17 |
| lixinhui | enen | 08:18 |
| Qiming | it means we are CHOOSING nova, instead of letting nova to make decision | 08:18 |
| lixinhui | en | 08:19 |
| Qiming | thanks, now gained a better understanding of this | 08:19 |
| lixinhui | glad to help. | 08:19 |
| Qiming | vsphere won't accept something like ':host1' as an availability zone name ... I guess | 08:19 |
| Qiming | so there has to be an assumption | 08:19 |
| Qiming | in other words, the guessing is still needed for vsphere, in order to form a correctly formated 'zone name' | 08:20 |
| lixinhui | yes, we need suggest user who want enable it to check correct zone | 08:21 |
| openstackgerrit | Merged openstack/senlin: Rework to_dict method of sdk resource in functional test https://review.openstack.org/286403 | 08:21 |
| Qiming | they can still use the general 'availability_zone' key for customization | 08:21 |
| lixinhui | yes | 08:22 |
| lixinhui | zone is higher concept than hypervisor, vsphere cluster is one kind of backend to hypevisor | 08:22 |
| lixinhui | so generalized zone is the ideal zone | 08:23 |
| *** dixiaoli_ has joined #senlin | 08:24 | |
| lixinhui | vSphere nova plugin will follow rules of community nova on naming of AZ | 08:25 |
| openstackgerrit | Cindia-blue proposed openstack/senlin: Fix Health Manager Problems https://review.openstack.org/286388 | 08:28 |
| Qiming | okay | 08:37 |
| Yanyanhu | hi, Qiming, I have a question about cluster update API behavior | 08:46 |
| Yanyanhu | should cluster status be marked as 'UPDATING' when the cluster update API returns | 08:47 |
| *** openstackgerrit has quit IRC | 08:48 | |
| Yanyanhu | actually, we have made some related discussion with ethan before | 08:48 |
| *** openstackgerrit has joined #senlin | 08:49 | |
| Yanyanhu | about how to check status changing when updating cluster resource in heat | 08:49 |
| Yanyanhu | he mentioned the cluster status will keep staying at 'ACTIVE' before update action is scheduled | 08:51 |
| Yanyanhu | therefore, the status check will give incorrect result if it is done very soon after cluster update API request returns | 08:51 |
| Yanyanhu | guess restful API should have some standard or discipline about this, will check it | 08:52 |
| openstackgerrit | Ethan Lynn proposed openstack/senlin: Make map schema resolve json serialized map value https://review.openstack.org/286447 | 08:53 |
| elynn | Yanyanhu, I think now cluster update will return an action id and we can check the status of action ID. | 08:55 |
| Yanyanhu | yes, elynn, I know we can get action_id from resp. Just curious whether resource should have been marked as 'UPDATING' when update API returns | 08:56 |
| elynn | it might not be good to change cluster status to update since cluster might not actually go into 'update' status... | 08:57 |
| Yanyanhu | yea, that's our current understanding | 08:57 |
| elynn | That's what Qiming told me before... | 08:57 |
| Yanyanhu | not sure whether RESTful has some discipline about this question | 08:57 |
| Yanyanhu | since it is all about resource operation :) | 08:58 |
| elynn | e.g. a scale-out action is on-going, and update action might need to wait for it to complete. | 08:58 |
| elynn | If only consider restful API guidelines, I'm not so sure... | 08:59 |
| Yanyanhu | elynn, yes, this understanding makes sense. | 08:59 |
| Qiming | I don't think the status change of resources is business of APIs | 08:59 |
| Yanyanhu | just also not sure whether there is guideline :) | 08:59 |
| Qiming | there's no guideline on this I believe | 09:00 |
| Yanyanhu | since it is not in the scope of 'API interface'? | 09:01 |
| Yanyanhu | hmm | 09:01 |
| Qiming | the only 'status' you get is the HTTP status code | 09:01 |
| Yanyanhu | Yes. that is the status of http resp | 09:02 |
| Qiming | that code only implies whether the request has been processed (200), accepted (202) | 09:02 |
| Yanyanhu | hmm, so RESTful doesn't provide constaint on what the resource looks like, e.g. what its status is or even whether it has a property named as status | 09:03 |
| Yanyanhu | not its responsibility | 09:04 |
| Yanyanhu | seems I thought too much :) | 09:05 |
| elynn | Hi Qiming , wanna know your thoughts about https://review.openstack.org/#/c/286447/ . | 09:08 |
| Qiming | elynn, acceptable | 09:12 |
| Qiming | oh, no | 09:12 |
| Qiming | if the value provided is a string, it has to be able to be parsed into a map | 09:12 |
| Qiming | okay | 09:13 |
| elynn | yes | 09:13 |
| Qiming | line 354 is guarding against invalid inputs | 09:14 |
| elynn | if a string can be parsed to a map, will raise error. | 09:14 |
| Qiming | okay | 09:14 |
| elynn | can not | 09:14 |
| Qiming | got it | 09:14 |
| elynn | If it's acceptable, I will abandon the bug in heat. | 09:17 |
| Qiming | okay | 09:18 |
| openstackgerrit | Ethan Lynn proposed openstack/senlin: Make map schema resolve json serialized map value https://review.openstack.org/286447 | 09:19 |
| elynn | Seems still not work as expected, sigh... | 09:24 |
| *** Yanyanhu has quit IRC | 09:28 | |
| elynn | oh, it worked as expected, forget to restart senlin-engine... | 09:28 |
| openstackgerrit | Qiming Teng proposed openstack/senlin: (WIP)Revise DRS policy to be a generic affinity policy https://review.openstack.org/286461 | 09:31 |
| Qiming | lixinhui, please help review the above patch ^ | 09:33 |
| Qiming | still work needed on reworking the unit tests | 09:33 |
| *** idonotknow_ has quit IRC | 10:01 | |
| *** idonotknow_ has joined #senlin | 10:02 | |
| *** elynn has quit IRC | 10:16 | |
| openstackgerrit | Béla Vancsics proposed openstack/senlin: Use assert(Not)Equal/Less/Greater https://review.openstack.org/286477 | 10:22 |
| *** dixiaoli_ has quit IRC | 10:28 | |
| *** Qiming has quit IRC | 10:30 | |
| -openstackstatus- NOTICE: Gerrit is going to be restarted due to poor performance | 10:38 | |
| *** ChanServ changes topic to "Gerrit is going to be restarted due to poor performance" | 10:38 | |
| *** ChanServ changes topic to "IRCLog: http://eavesdrop.openstack.org/irclogs/%23senlin/ | Bugs: bugs.launchpad.net/senlin | Review: https://review.openstack.org/#/q/project:openstack/senlin,n,z" | 10:45 | |
| -openstackstatus- NOTICE: gerrit finished restartign | 10:45 | |
| *** idonotknow_ has quit IRC | 11:28 | |
| *** zzxwill_ has joined #senlin | 11:32 | |
| *** zzxwill has quit IRC | 11:33 | |
| *** zzxwill_ has quit IRC | 11:34 | |
| *** zzxwill has joined #senlin | 11:34 | |
| *** Qiming has joined #senlin | 11:36 | |
| *** shu-mutou is now known as shu-mutou-AFK | 11:54 | |
| *** idonotknow_ has joined #senlin | 11:59 | |
| openstackgerrit | Merged openstack/senlin: Simplify action initialization https://review.openstack.org/286351 | 12:03 |
| *** xuhaiwei has joined #senlin | 12:53 | |
| *** yanyanhu has joined #senlin | 12:54 | |
| openstackgerrit | Cindia-blue proposed openstack/senlin: Fix Health Manager Problems https://review.openstack.org/286388 | 12:58 |
| *** idonotknow_ has quit IRC | 13:01 | |
| openstackgerrit | Cindia-blue proposed openstack/senlin: Revise DB API to Ensure Delete Success https://review.openstack.org/286575 | 13:16 |
| Qiming | lixinhui, meeting? | 13:31 |
| Qiming | yanyanhu, continue the discussion here | 14:01 |
| yanyanhu | ok | 14:01 |
| Qiming | won't have a conclusion today | 14:01 |
| yanyanhu | honestly, I understand what you mean about the different between IaaS and PaaS | 14:01 |
| Qiming | I'm not anticipating a conclusion this week, this month | 14:01 |
| yanyanhu | agree that's not that important actually | 14:01 |
| Qiming | eventually, there will be containers running on baremetal | 14:02 |
| Qiming | the big security gap will be closed | 14:02 |
| yanyanhu | but I think one problem is the design of Senlin should be different if we want to act as some services like k8s or Mesos | 14:02 |
| Qiming | although the tech is not really that ready today | 14:02 |
| yanyanhu | yes, that's right | 14:02 |
| yanyanhu | we miss some important conception in senlin as of now | 14:03 |
| Qiming | the value of senlin lies in its unification of cluster management | 14:03 |
| yanyanhu | if we want to provide that support | 14:03 |
| yanyanhu | right | 14:03 |
| Qiming | are you talking about pod? service? ... | 14:03 |
| yanyanhu | yes, service, not pod | 14:04 |
| Qiming | or 'offers'? | 14:04 |
| yanyanhu | or tasks | 14:04 |
| yanyanhu | yes, I think we miss them currently | 14:04 |
| xuhaiwei | so what is the mostly different things of Senlin's container cluster and K8s ? | 14:04 |
| yanyanhu | service is an element supported by k8s I think | 14:05 |
| Qiming | right, from users perspective, they think about micro-service, for example | 14:05 |
| yanyanhu | pod is one thing to undertake it | 14:05 |
| lixinhui | I think who do it fistly then who will catch the eyeball | 14:05 |
| Qiming | and there will be a lot developers educated by their terms | 14:06 |
| yanyanhu | based on my understanding, Senlin Now is a generic cluster management service | 14:06 |
| Qiming | so ... to deploy a cluster of 'task's or 'service's | 14:06 |
| yanyanhu | but we haven't touched stuff that deployed upon cluster that much | 14:06 |
| yanyanhu | till now | 14:06 |
| Qiming | what are the artifacts you will feed to the service (be it senlin or not) | 14:07 |
| yanyanhu | Qiming, it's possible | 14:07 |
| yanyanhu | actually, it doesn't have to be connected with Container cluster | 14:07 |
| yanyanhu | right | 14:07 |
| Qiming | today, it is just a docker image or some other image, right? | 14:07 |
| yanyanhu | app/service can be deployed in cluster of any kind of compute resource | 14:07 |
| yanyanhu | Qiming, I think we need something like 'DEPLOYMENT' | 14:08 |
| yanyanhu | to finish this gap | 14:08 |
| Qiming | I see the direction you are going | 14:08 |
| yanyanhu | it's kinda like service deployment in k8s | 14:08 |
| yanyanhu | or task framework in Mesos | 14:09 |
| Qiming | however, 'deployment' is still a little be too abstract | 14:09 |
| yanyanhu | Qiming, yes, but that's our advantage, right | 14:09 |
| Qiming | I prefer we aiming high while working low | 14:09 |
| yanyanhu | we don't want limit the cluster type to Container | 14:09 |
| Qiming | absolutely | 14:09 |
| yanyanhu | Qiming, agree | 14:09 |
| yanyanhu | but the design should be generic | 14:09 |
| yanyanhu | actually just like what we have done on cluster management :) | 14:10 |
| Qiming | so, speaking of deployment, can it be a jar, a war, an ISO, a vmdk? | 14:10 |
| yanyanhu | cluster can be composed of any kind of resources | 14:10 |
| yanyanhu | sure | 14:10 |
| yanyanhu | if we want to introduce this conception to Senlin, maybe we'd better make it generic | 14:11 |
| yanyanhu | as generic as cluster | 14:11 |
| Qiming | i was imagining that 'custom actions' can play a big role here | 14:11 |
| Qiming | or something like ansible | 14:11 |
| Qiming | or just mistral? | 14:11 |
| yanyanhu | em, not sure, maybe it varies cross the resource type at the back of node? | 14:12 |
| Qiming | you mean perform some operation on a cluster as a whole? where the 'some operation' here can be | 14:12 |
| Qiming | deploy a container image? | 14:12 |
| yanyanhu | no, I mean deploy an App/service | 14:12 |
| Qiming | right, it will vary a lot | 14:13 |
| Qiming | so ... i was asking | 14:13 |
| Qiming | what are you referring to by 'App/service' | 14:13 |
| yanyanhu | ah, I means something like a webserver | 14:13 |
| Qiming | how is that 'App/service' packaged | 14:13 |
| Qiming | what is the artifact to be deployed | 14:13 |
| yanyanhu | or db. or a spark services:) | 14:14 |
| Qiming | sigh | 14:14 |
| Qiming | still don't get the point | 14:14 |
| yanyanhu | depends on what kind service it is | 14:14 |
| yanyanhu | maybe a docker image | 14:14 |
| yanyanhu | maybe just a script | 14:14 |
| Qiming | a service is the function provided by some software, right? | 14:14 |
| yanyanhu | right | 14:14 |
| Qiming | an app is a software | 14:15 |
| Qiming | you package your software into a distributable format | 14:15 |
| Qiming | so that people can deploy again and again | 14:15 |
| yanyanhu | yes | 14:15 |
| Qiming | that 'distributable format' is the artifact I am talking about | 14:15 |
| yanyanhu | ok, I see. | 14:16 |
| Qiming | today, the most popular one is docker image | 14:16 |
| Qiming | yes today, it was jar/war | 14:16 |
| Qiming | tomorrow, it could be some xxxkernel/xxxos package | 14:17 |
| yanyanhu | ok, for docker image, maybe we can deploy it in a cluster of VM | 14:17 |
| yanyanhu | where docker service is enabled in all VMs | 14:17 |
| Qiming | if we can deploy docker image | 14:17 |
| Qiming | can we say we are deploying the 'app/svc' you talking about? | 14:17 |
| yanyanhu | sure | 14:17 |
| yanyanhu | it's kind of app/svc | 14:18 |
| Qiming | agreed | 14:18 |
| Qiming | there are other kind of distributions | 14:18 |
| yanyanhu | yes | 14:18 |
| Qiming | just like TOSCA has been trying to abstract | 14:18 |
| yanyanhu | so what I want to express is we should make it a generic conception | 14:19 |
| yanyanhu | right | 14:19 |
| Qiming | they are even talking about web service bundles | 14:19 |
| yanyanhu | not just focus on Container | 14:19 |
| Qiming | totally makes sense | 14:19 |
| Qiming | okay | 14:19 |
| yanyanhu | at least when we design the conception | 14:19 |
| Qiming | we can call it a pdu | 14:19 |
| yanyanhu | maybe we have special 'driver' or something for container cluster | 14:19 |
| Qiming | or dup | 14:19 |
| yanyanhu | duplication? | 14:20 |
| Qiming | deployable unit package | 14:20 |
| yanyanhu | :) | 14:20 |
| Qiming | it is also 'dup'lication ... we are reinventhing things, but for a good reason | 14:21 |
| yanyanhu | ok | 14:21 |
| Qiming | if the package type is 'docker' we call docker api to deploy | 14:21 |
| yanyanhu | yes | 14:22 |
| Qiming | if the du type is a script, we ssh into a vm and run it | 14:22 |
| yanyanhu | yes, any compute resource can run script | 14:22 |
| Qiming | alright, you are leading us to the software config/software deployment trap | 14:22 |
| yanyanhu | haha | 14:22 |
| Qiming | we'll need to monitor their progress, their log, their return value | 14:23 |
| Qiming | we'll need to teach users to find logs for debugging ... | 14:23 |
| Qiming | :( | 14:23 |
| yanyanhu | hmm, after thorough think, I really did... | 14:23 |
| Qiming | but anyway, that is some great vision | 14:23 |
| yanyanhu | but if you want to manage a deployment or mabye lifecycle of an App/Service | 14:24 |
| yanyanhu | we may have to think about these issues | 14:24 |
| yanyanhu | actually, there are also other things need to think about | 14:24 |
| Qiming | come on, lifecycle is murano's scope | 14:24 |
| yanyanhu | e.g. for container cluster, we need to consider the network connection inside cluster | 14:24 |
| Qiming | the top concern for me ... is scheduling | 14:24 |
| yanyanhu | the loadbalancer, the proxy | 14:25 |
| yanyanhu | etc... | 14:25 |
| Qiming | we need a basic, very naive scheduler | 14:25 |
| Qiming | anything that works for container networking, we can use | 14:25 |
| yanyanhu | hmm, can swarm help to do this? | 14:25 |
| Qiming | we are consumer of those technologies | 14:25 |
| yanyanhu | I mean the basic scheduling | 14:25 |
| Qiming | don't think so | 14:26 |
| Qiming | scheduling problem can be decomposed to several sub-domains | 14:26 |
| yanyanhu | k8s is also not what we want to talk with | 14:27 |
| Qiming | first you will need to know what you need for each UOW (unit of work) | 14:27 |
| Qiming | then you will need to know what you have at hand (resource provisioning, a thousand dimensions here) | 14:27 |
| xuhaiwei | So Qiming, for container cluster, you are willing to have almost the same design as vm cluster? | 14:27 |
| yanyanhu | yes | 14:27 |
| Qiming | finally, you need to pick some location to put your UOW | 14:28 |
| yanyanhu | Qiming, this is exactly what a Mesos scheduler does | 14:28 |
| yanyanhu | xuhaiwei, really anxious to have more talk with you guys about this topic :) | 14:29 |
| Qiming | all schedulers do the same type of jobs | 14:29 |
| yanyanhu | really need more thinking on it | 14:29 |
| Qiming | xuhaiwei, yes, that is what we call a generic clustering service | 14:29 |
| Qiming | it's very late | 14:30 |
| xuhaiwei | yanyanhu, yes, need to learn more about it | 14:31 |
| Qiming | I don't mind if you want to continue dig more | 14:31 |
| yanyanhu | xuhaiwei, yes, and hope we can figure out the correct way to do so | 14:31 |
| yanyanhu | maybe what I said was all wrong :) | 14:31 |
| xuhaiwei | I will go to bed soon | 14:31 |
| yanyanhu | yes, also really need to go | 14:31 |
| yanyanhu | otherwise, have life danger | 14:31 |
| Qiming | yes, don't waste time doing something useless, at least | 14:31 |
| yanyanhu | talk to you guys later | 14:32 |
| yanyanhu | have a good night | 14:32 |
| xuhaiwei | see you tomorrow | 14:32 |
| Qiming | to me, (secretly), magnum is useless, :) | 14:32 |
| Qiming | good night | 14:32 |
| xuhaiwei | :) | 14:32 |
| *** yanyanhu has quit IRC | 14:32 | |
| *** xuhaiwei has quit IRC | 14:32 | |
| *** zzxwill has quit IRC | 14:44 | |
| openstackgerrit | Liuqing Jing proposed openstack/senlin-dashboard: Delete useless return statement https://review.openstack.org/286645 | 15:08 |
| *** jdandrea_ has joined #senlin | 15:23 | |
| *** zzxwill has joined #senlin | 15:24 | |
| *** jdandrea has quit IRC | 15:26 | |
| *** zzxwill has quit IRC | 15:47 | |
| *** Qiming has quit IRC | 16:17 | |
| *** openstackgerrit has quit IRC | 18:18 | |
| *** openstackgerrit has joined #senlin | 18:19 | |
| *** openstack has joined #senlin | 19:18 | |
| *** openstackstatus has joined #senlin | 19:18 | |
| *** ChanServ sets mode: +v openstackstatus | 19:18 | |
| *** openstackgerrit has joined #senlin | 19:20 | |
| *** Qiming has joined #senlin | 23:41 | |
| *** zzxwill has joined #senlin | 23:58 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!