Thursday, 2016-05-26

*** openstack has joined #senlin00:06
openstackgerritMerged openstack/senlin: Updated from global requirements  https://review.openstack.org/32105200:09
*** Qiming has quit IRC00:24
*** openstackstatus has quit IRC00:46
*** openstack has joined #senlin00:57
*** Qiming has joined #senlin01:13
*** yanyanhu has joined #senlin01:32
openstackgerritQiming Teng proposed openstack/senlin: Fix senlin-dashboard install  https://review.openstack.org/32131601:40
*** flwang1 has joined #senlin01:49
*** openstackgerrit has quit IRC01:49
flwang1Qiming: ping01:50
*** elynn has joined #senlin01:50
Qiminghi, flwang01:50
flwang1Qiming: i have a question about the api ref work01:50
Qimingyes?01:50
flwang1so based on current way, the api ref doc will using a different style instead of the current one using on http://developer.openstack.org/api-ref-clustering-v1.html01:52
flwang1is it correct?01:52
flwang1since i just built a local api ref of senlin01:52
flwang1and i found the css style are totally diferent01:52
Qimingbut the look and feel should be the same?01:52
flwang1no, that's what i want to figure out01:53
Qiminglet me find an artifact for you01:54
*** elynn has quit IRC01:54
*** elynn has joined #senlin01:55
Qimingflwang1, http://docs-draft.openstack.org/97/320297/2/check/gate-senlin-api-ref/4d9769b//api-ref/build/html/01:55
Qimingflwang1, anything wrong with this output?01:58
*** openstackgerrit has joined #senlin01:58
Qimingwlc, openstackgerrit01:58
Qiming:)01:58
flwang1Qiming: cool, that's what i want to know01:59
flwang1so for that way, each project needs to create a new gate job for api-ref01:59
Qimingbut I forgot how to dump this output to api-site01:59
flwang1right?01:59
Qimingyes, I think so02:00
flwang1then how the api docs site grab the content from each tree?02:00
Qiminga publisher actually, to make the generated docs public02:00
flwang1does it need to be considered by each project?02:00
flwang1where is the publisher?02:00
Qiminglet me find a patch for you02:01
Qiminghttps://review.openstack.org/#/c/252230/02:02
Qiminghttps://review.openstack.org/#/c/314832/02:02
flwang1Qiming: ok, so the publish job will automatically publish the api ref to the official site after it's merged, is it?02:04
Qimingyes, my impression was that it is a ftp job02:05
Qimingcannot recall the details02:05
Qimingit will build the htmls locally, package it, upload to api-site02:05
flwang1Qiming: thanks, it's very helpful02:07
Qimingnp02:07
Qimingoh, patch 252230 is irrelevant02:09
Qimingjust 314832 would do02:09
Qimingflwang1, the job definition is here: http://git.openstack.org/cgit/openstack-infra/project-config/tree/jenkins/jobs/api-jobs.yaml#n12902:13
Qimingif you are curious02:13
flwang1Qiming: cool, cheers02:14
flwang1now, how do you guys maintain the sample json?02:14
Qimingin tree02:14
flwang1can those be generated automatically?02:14
Qimingunder api-ref02:14
Qimingno, they are still manually generated02:14
flwang1manually means there is a tool/script to run or just write manually?02:15
Qimingmanually written02:15
flwang1Qiming: oh, gosh02:15
Qimingthat is something really bad02:15
flwang1Qiming: yep02:16
Qimingfortunately, we were just migrating from api-site to in-tree api-ref02:16
Qimingjson files were just copied and validated (manually)02:16
flwang1Qiming: yep, at least, it can be maintained better02:16
Qimingat the end of the day, I really hope the schema can be used for two purposes: 1. doc generation 2. request validation02:17
flwang1it would be great if there is a tool/script can validate those samples02:17
Qimingin its current status, we can only do doc generation02:17
flwang1Qiming: hah, we're talking about the same thing02:17
flwang1yes02:17
QimingI challenged sean dague about the direction02:17
flwang1the answer is ?02:17
Qimingis there any hope that nova will converge their existing api schema validation to the api-ref work?02:18
Qimingthe answer was no, it won't happen during newton02:18
Qimingthat was my big concern02:18
flwang1Qiming: it would be nice if those samples can be used by local test02:18
flwang1tempest, maybe02:19
flwang1then it would be great02:19
Qimingsince nova has already had a request validation implementation there, now they have human facing api docs (mostly in REST) reinvented02:19
Qimingno one would be interested in the convergence02:19
flwang1Qiming: yep,i can imagine that02:19
Qimingtotally agree02:19
Qimingbut anyway, I do agree that the main purpose of API docs is for developers02:20
Qimingverbosity is never a problem for human readers, they do need to know the details02:20
Qiminghowever, a semi-structured REST cannot be parsed by tools02:20
QimingI was hoping that the community will go swagger instead02:21
Qimingif swagger is not perfect, we fix it02:21
QimingI think the doc team has the same intention, but ... you know, doc team doesn't have developer resources02:22
Qimingso ... they had to make a concession02:22
openstackgerritYanyan Hu proposed openstack/senlin: Fix typos in tempest API tests for profile_delete  https://review.openstack.org/32132202:26
openstackgerritQiming Teng proposed openstack/senlin: Fix links to API reference docs  https://review.openstack.org/32132302:27
flwang1Qiming: i see. we(zaqar) are trying to use swagger02:33
flwang1but given we're using Falcon, it's not perfect for integrating with swagger02:33
Qimingem ... I was worrying about that02:34
flwang1Qiming: but the unclear part is how to build the swagger json file if current sphinx-build way doesn't support that02:35
Qimingthat is beyond my knowledge02:36
*** openstack has joined #senlin02:41
openstackgerritMerged openstack/senlin: Fix typos in tempest API tests for profile_delete  https://review.openstack.org/32132202:43
*** yuanying has quit IRC02:50
flwang1Qiming: thanks a lot02:52
*** Drago has joined #senlin03:02
openstackgerritYanyan Hu proposed openstack/senlin: Add negative tempest API test for http conflict cases  https://review.openstack.org/32133003:02
yanyanhuhi, Qiming, around?03:03
*** Drago has quit IRC03:04
yanyanhuI noticed the cluster_delete API will return 400(bad request) when user tries to delete cluster without detaching all policies and removing all receivers.03:04
yanyanhuhowever, policy/profile delete without detaching and removing cluster will return 409(conflict)03:05
yanyanhushould we make them consistent? e.g. return 409 in all those cases?03:06
Qimingright, should be consistent wherever possible03:07
yanyanhuok03:07
yanyanhuwill make a change here03:07
Qimingso ... cluster_delete should return 409 when there are conflicts03:07
yanyanhuyes, I think so03:07
Qimingplease double check the semantics of 409 and 400 and see if we should change03:08
yanyanhuok03:08
Qimingabout your patch 31845303:08
Qimingyanyanhu,03:08
yanyanhuthe one in rally?03:09
QimingI'm a little bit confused about the 'gate-rally-dsvm-senlin' and 'gate-rally-dsvm-senlin-rally'03:09
Qimingno, in project config03:09
yanyanhuoh, the gate job03:09
yanyanhuyes, that's confusing03:09
Qiminghttps://review.openstack.org/#/c/318453/1/zuul/layout.yaml03:09
Qimingline 1340-134403:09
yanyanhuactually I may also need to revise the name of gate job "gate-rally-dsvm-senlin" in future03:10
Qimingpls think twice when proposing patches to project-config03:11
yanyanhuyes03:11
Qimingwe are not supposed to change things back and forth there03:11
yanyanhuactually I think I made a mistake when posting the last patch to add "gate-rally-dsvm-senlin" job03:12
yanyanhuit was supposed to match this job template: http://git.openstack.org/cgit/openstack-infra/project-config/tree/jenkins/jobs/rally.yaml#n49903:13
Qimingthen fix it in this patch?03:20
Qimingbefore it is getting approved?03:20
Qimingcores, please help review https://review.openstack.org/#/c/32131603:20
Qimingwe need that before getting other tempest test patches merged, e.g. https://review.openstack.org/#/c/320227/03:21
yanyanhuok, will check it03:21
elynnGreat, you are so quick to fix it.03:22
elynnAfter this patch merged, should we move this job from experimental to gate?03:26
openstackgerritMerged openstack/senlin: Fix senlin-dashboard install  https://review.openstack.org/32131603:29
*** yuanying has joined #senlin03:30
*** yuanying has quit IRC03:45
*** yuanying has joined #senlin03:47
*** elynn has quit IRC04:33
*** elynn has joined #senlin04:50
*** elynn_ has joined #senlin04:54
*** elynn has quit IRC04:54
*** flwang1 has quit IRC05:01
openstackgerritMerged openstack/senlin: Tune health manager module  https://review.openstack.org/32031105:04
openstackgerritQiming Teng proposed openstack/senlin: ovo - switch service calls  https://review.openstack.org/32135505:22
*** elynn_ has quit IRC05:49
xuhaiweiQiming, yanyanhu, can we discuss the container spec now?06:13
yanyanhusure06:13
yanyanhuI'm actually writing more comments on it :)06:13
xuhaiweiI saw your last comment yanyan06:13
yanyanhuyea06:14
xuhaiweiby adding 'host' and 'host_cluster' into profile, the problem I mean is06:14
yanyanhuso my point is trying to avoid expose a property through API before we see generic requirement of it06:14
xuhaiweifor example we create a profile with host=None, host_cluster=cluster1, then we use it to create a cluster, that is k06:15
xuhaiweiok06:15
yanyanhuyes06:16
xuhaiweibut if when do cluster-resize to add some more nodes, we will still use this profile, right?06:16
yanyanhuyes06:16
xuhaiweiat this time the host_cluster propertity is meanless to node_create06:17
xuhaiweinode_create need the 'host' actually06:17
yanyanhuhmm, imo, I think that means user don't care which exact host new container should be located06:17
yanyanhuso senlin engine should pick a node from VM cluster randomly06:17
yanyanhuand create new container on it06:17
yanyanhuand if there is placement policy06:18
yanyanhuit will take effect to decide the location06:18
yanyanhuif not, random location will be the strategy06:18
yanyanhuthat's why I feel if user really use the profile to create container cluster, it will work06:18
yanyanhujust for single node case, host is necessary06:19
yanyanhuanyway, I'm not total against adding "host"(or what ever name) property to node obj and exposing it through API interface06:20
xuhaiweiif the nodes will be created randomly, that may conflict with placement policy06:20
yanyanhujust feel it's not a so common requirement for all resource types06:20
yanyanhuif there is placement policy, it will decide the location06:20
yanyanhuif not, random picking will be done06:20
xuhaiweias discussed in the spec, when creating a container cluster, a placement policy is requred, container nodes should be added to the cluster after the placement policy is attached06:21
yanyanhuabout the placement issue, my key point is user should use placement policy to decide the node(s) location if the node is created for cluster creating/scaling06:21
yanyanhuno necessary06:22
yanyanhuas what we are doing now for nova server cluster06:22
yanyanhuwhen nova server cluster is just created, there is no placement policy attached.  In this case, nova decide the location, right?06:23
xuhaiweiyes06:23
yanyanhufor container, senlin can decide the location randomly since user don't care the container location as of that time, right?06:23
yanyanhuonce they care, a placement policy can be attached06:24
yanyanhuthen, it will take effect and decide the location of any new created containers in future06:24
xuhaiweiI know what you mean06:24
yanyanhuso imo, almost the same cases :)06:24
openstackgerritQiming Teng proposed openstack/senlin: ovo - switch profile calls  https://review.openstack.org/32136606:25
yanyanhuif they really want to control container location from the beginning06:25
yanyanhuone possible way is create an empty cluster06:25
yanyanhuand then attach placement policy06:25
yanyanhuafter that, they can scale cluster to a proper size06:25
yanyanhuxuhaiwei, actually, I'm not against the idea of adding "host" property to node. Just feel we don't have so common requirement for it if only considering container cluster use case06:27
yanyanhuwe may need to define a good abstraction for it before adding it06:27
yanyanhufor all possible resource types06:27
yanyanhue.g. even for storage06:28
xuhaiweihmm, we should think out a most approprate solution06:28
yanyanhuyes, if we can abstract this conception good enough06:28
yanyanhuwe should add it06:28
yanyanhuthen container cluster could be the first profile to consume it06:28
yanyanhucontainer resource06:28
xuhaiweilet me think about it more06:29
yanyanhujust don't clear how to explain it in some other possible use cases06:29
yanyanhuok06:29
yanyanhuthanks, we can have more discussion on it before starting add this property to node :)06:29
yanyanhuonce add it, we need to give a good explanation on it :)06:30
xuhaiweiyes06:30
xuhaiweiif user wants to create a single node in some vm, he has to create a new profile, that is not user-friendly I think, less convenient than using a '--host' option06:33
yanyanhuyes, using '--host' is more convenient. But clear/correct design is more important, right :)06:34
xuhaiweiyes06:35
yanyanhusince we need to consider lots of other issues about "host" property. e.g. whether user is allowed to update it?06:36
yanyanhuif so, what will happen?06:36
xuhaiweiupdate the 'host'?06:37
xuhaiweiyou mean by node-update to update the 'host'?06:38
yanyanhuyes06:38
yanyanhusince this is a property visible for user, and they can define it when create node06:39
yanyanhuthey will want to know whether they can update it06:39
xuhaiweithat is container's live-migration?06:40
yanyanhukinda06:40
yanyanhuif it is supported by backend service06:40
yanyanhuwhich is now pure docker service I think06:40
yanyanhusince in profile, all properties are marked as updatable or not06:41
yanyanhuso user is clear about it06:41
yanyanhubut if it is just a node property, we don't know how to handle it06:41
yanyanhusince in our current design, profile decides every detail of a resource type06:42
yanyanhuhow to create/delete/update/check/recover06:42
xuhaiweithats seems reasonable, not think about it that far06:45
yanyanhuyes, so once we are clear about how to map "host" property in node to profile property for all type of resources06:46
yanyanhuwe are ready to have it in node object and API interface :)06:46
xuhaiweiyesa06:48
yanyanhuso maybe the first step is adding host property to container/docker profile and handle it well. Then we can consider to generalize this conception and add it to other resource/profile types.06:50
*** openstack has joined #senlin06:57
openstackgerritQiming Teng proposed openstack/senlin: ovo - switch profile calls  https://review.openstack.org/32136606:58
openstackgerritQiming Teng proposed openstack/senlin: ovo - switch policy calls  https://review.openstack.org/32138006:59
openstackgerritYanyan Hu proposed openstack/senlin: Minor revise cluster_delete engine service call  https://review.openstack.org/32138207:06
openstackgerritQiming Teng proposed openstack/senlin: ovo - switch receiver calls  https://review.openstack.org/32139307:38
*** shu-mutou is now known as shu-mutou-AFK08:27
openstackgerritYanyan Hu proposed openstack/senlin: Minor revise cluster_delete engine service call  https://review.openstack.org/32138208:53
openstackgerritYanyan Hu proposed openstack/senlin: Add negative tempest API test for cluster_delete  https://review.openstack.org/32142308:53
openstackgerritQiming Teng proposed openstack/senlin: ovo - switch node calls  https://review.openstack.org/32142508:58
*** flwang1 has joined #senlin09:16
openstackgerritQiming Teng proposed openstack/senlin: ovo - switch cluster lock and node lock calls  https://review.openstack.org/32144109:39
*** elynn_ has joined #senlin09:43
*** elynn_ has quit IRC09:47
*** elynn_ has joined #senlin09:48
Qimingsigh ...09:59
openstackgerritMerged openstack/senlin: ovo - switch service calls  https://review.openstack.org/32135509:59
Qimingpipeline is accumulating again09:59
Qimingcannot proceed now09:59
Qiming[tengqm@node1 senlin]$ git review10:00
QimingYou are about to submit multiple commits. This is expected if you are10:00
Qimingsubmitting a commit that is dependent on one or more in-review10:00
Qimingcommits. Otherwise you should consider squashing your changes into one10:00
Qimingcommit before submitting.10:00
QimingThe outstanding commits are:10:00
Qiming31cac4c (HEAD, use-registry-object) ovo - switch health registry calls10:00
Qiming87dc603 Tune health manager module10:00
Qimingae3e3b9 (use-node-lock-object) ovo - switch cluster lock and node lock calls10:00
Qimingde15589 (use-node-object) ovo - switch node calls10:00
Qiming172e7b1 (use-receiver-object) ovo - switch receiver calls10:00
Qimingf534b1a (use-policy-object) ovo - switch policy calls10:00
Qiming3c10ef1 (use-profile-object) ovo - switch profile calls10:00
Qiming2ce1f3a (user-service-object) ovo - switch service calls10:00
QimingDo you really want to submit the above commits?10:00
QimingType 'yes' to confirm, other to cancel: yes10:00
Qimingremote: Processing changes: refs: 1, done10:00
Qimingremote: (W) 31cac4c: too many commit message lines longer than 70 characters; manually wrap lines10:00
QimingTo https://tengqm:ZcK4qjpWkuIY@review.openstack.org/openstack/senlin.git10:00
Qiming ! [remote rejected] HEAD -> refs/publish/master/use-registry-object (change https://review.openstack.org/320311 closed)10:00
Qimingerror: failed to push some refs to 'https://tengqm:ZcK4qjpWkuIY@review.openstack.org/openstack/senlin.git'10:00
Qimingit was because the health manager tuning jumping into the middle10:00
Qimingmaybe time to take a break10:01
elynn_Then we can do a a quick merge for the patches before tuning patch.10:01
elynn_:)10:02
Qimingyes, could use some helps now10:02
Qimingrunning home10:02
elynn_Waiting for the experimental jobs result :)10:03
*** Qiming has quit IRC10:08
openstackgerritYanyan Hu proposed openstack/senlin: Add negative tempest API test for cluster_delete  https://review.openstack.org/32142310:08
openstackgerritYanyan Hu proposed openstack/senlin: Minor revise cluster_delete engine service call  https://review.openstack.org/32138210:08
openstackgerritMerged openstack/senlin: Fix links to API reference docs  https://review.openstack.org/32132310:09
*** yanyanhu has quit IRC10:09
*** elynn_ has quit IRC10:14
openstackgerritMerged openstack/senlin: ovo - switch profile calls  https://review.openstack.org/32136610:16
openstackgerritMerged openstack/senlin: ovo - switch policy calls  https://review.openstack.org/32138010:16
openstackgerritMerged openstack/senlin: ovo - switch receiver calls  https://review.openstack.org/32139310:23
openstackgerritMerged openstack/senlin: ovo - switch node calls  https://review.openstack.org/32142510:24
*** Qiming has joined #senlin10:59
*** elynn_ has joined #senlin12:12
*** idonotknow_ has joined #senlin14:48
*** Drago has joined #senlin14:48
*** Drago has quit IRC14:50
*** Drago has joined #senlin14:50
openstackgerritQiming Teng proposed openstack/senlin: ovo - switch cluster lock and node lock calls  https://review.openstack.org/32144115:43
*** Qiming has quit IRC16:08
*** elynn_ has quit IRC17:11
*** idonotknow_ has quit IRC18:07
*** flwang1 has quit IRC20:15
*** flwang1 has joined #senlin22:00
*** Drago has quit IRC22:39
*** Qiming has joined #senlin23:36
*** elynn_ has joined #senlin23:52
*** elynn_ has quit IRC23:59

Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!