| *** openstack has joined #senlin | 00:06 | |
| openstackgerrit | Merged openstack/senlin: Updated from global requirements https://review.openstack.org/321052 | 00:09 |
|---|---|---|
| *** Qiming has quit IRC | 00:24 | |
| *** openstackstatus has quit IRC | 00:46 | |
| *** openstack has joined #senlin | 00:57 | |
| *** Qiming has joined #senlin | 01:13 | |
| *** yanyanhu has joined #senlin | 01:32 | |
| openstackgerrit | Qiming Teng proposed openstack/senlin: Fix senlin-dashboard install https://review.openstack.org/321316 | 01:40 |
| *** flwang1 has joined #senlin | 01:49 | |
| *** openstackgerrit has quit IRC | 01:49 | |
| flwang1 | Qiming: ping | 01:50 |
| *** elynn has joined #senlin | 01:50 | |
| Qiming | hi, flwang | 01:50 |
| flwang1 | Qiming: i have a question about the api ref work | 01:50 |
| Qiming | yes? | 01:50 |
| flwang1 | so 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.html | 01:52 |
| flwang1 | is it correct? | 01:52 |
| flwang1 | since i just built a local api ref of senlin | 01:52 |
| flwang1 | and i found the css style are totally diferent | 01:52 |
| Qiming | but the look and feel should be the same? | 01:52 |
| flwang1 | no, that's what i want to figure out | 01:53 |
| Qiming | let me find an artifact for you | 01:54 |
| *** elynn has quit IRC | 01:54 | |
| *** elynn has joined #senlin | 01:55 | |
| Qiming | flwang1, http://docs-draft.openstack.org/97/320297/2/check/gate-senlin-api-ref/4d9769b//api-ref/build/html/ | 01:55 |
| Qiming | flwang1, anything wrong with this output? | 01:58 |
| *** openstackgerrit has joined #senlin | 01:58 | |
| Qiming | wlc, openstackgerrit | 01:58 |
| Qiming | :) | 01:58 |
| flwang1 | Qiming: cool, that's what i want to know | 01:59 |
| flwang1 | so for that way, each project needs to create a new gate job for api-ref | 01:59 |
| Qiming | but I forgot how to dump this output to api-site | 01:59 |
| flwang1 | right? | 01:59 |
| Qiming | yes, I think so | 02:00 |
| flwang1 | then how the api docs site grab the content from each tree? | 02:00 |
| Qiming | a publisher actually, to make the generated docs public | 02:00 |
| flwang1 | does it need to be considered by each project? | 02:00 |
| flwang1 | where is the publisher? | 02:00 |
| Qiming | let me find a patch for you | 02:01 |
| Qiming | https://review.openstack.org/#/c/252230/ | 02:02 |
| Qiming | https://review.openstack.org/#/c/314832/ | 02:02 |
| flwang1 | Qiming: ok, so the publish job will automatically publish the api ref to the official site after it's merged, is it? | 02:04 |
| Qiming | yes, my impression was that it is a ftp job | 02:05 |
| Qiming | cannot recall the details | 02:05 |
| Qiming | it will build the htmls locally, package it, upload to api-site | 02:05 |
| flwang1 | Qiming: thanks, it's very helpful | 02:07 |
| Qiming | np | 02:07 |
| Qiming | oh, patch 252230 is irrelevant | 02:09 |
| Qiming | just 314832 would do | 02:09 |
| Qiming | flwang1, the job definition is here: http://git.openstack.org/cgit/openstack-infra/project-config/tree/jenkins/jobs/api-jobs.yaml#n129 | 02:13 |
| Qiming | if you are curious | 02:13 |
| flwang1 | Qiming: cool, cheers | 02:14 |
| flwang1 | now, how do you guys maintain the sample json? | 02:14 |
| Qiming | in tree | 02:14 |
| flwang1 | can those be generated automatically? | 02:14 |
| Qiming | under api-ref | 02:14 |
| Qiming | no, they are still manually generated | 02:14 |
| flwang1 | manually means there is a tool/script to run or just write manually? | 02:15 |
| Qiming | manually written | 02:15 |
| flwang1 | Qiming: oh, gosh | 02:15 |
| Qiming | that is something really bad | 02:15 |
| flwang1 | Qiming: yep | 02:16 |
| Qiming | fortunately, we were just migrating from api-site to in-tree api-ref | 02:16 |
| Qiming | json files were just copied and validated (manually) | 02:16 |
| flwang1 | Qiming: yep, at least, it can be maintained better | 02:16 |
| Qiming | at the end of the day, I really hope the schema can be used for two purposes: 1. doc generation 2. request validation | 02:17 |
| flwang1 | it would be great if there is a tool/script can validate those samples | 02:17 |
| Qiming | in its current status, we can only do doc generation | 02:17 |
| flwang1 | Qiming: hah, we're talking about the same thing | 02:17 |
| flwang1 | yes | 02:17 |
| Qiming | I challenged sean dague about the direction | 02:17 |
| flwang1 | the answer is ? | 02:17 |
| Qiming | is there any hope that nova will converge their existing api schema validation to the api-ref work? | 02:18 |
| Qiming | the answer was no, it won't happen during newton | 02:18 |
| Qiming | that was my big concern | 02:18 |
| flwang1 | Qiming: it would be nice if those samples can be used by local test | 02:18 |
| flwang1 | tempest, maybe | 02:19 |
| flwang1 | then it would be great | 02:19 |
| Qiming | since nova has already had a request validation implementation there, now they have human facing api docs (mostly in REST) reinvented | 02:19 |
| Qiming | no one would be interested in the convergence | 02:19 |
| flwang1 | Qiming: yep,i can imagine that | 02:19 |
| Qiming | totally agree | 02:19 |
| Qiming | but anyway, I do agree that the main purpose of API docs is for developers | 02:20 |
| Qiming | verbosity is never a problem for human readers, they do need to know the details | 02:20 |
| Qiming | however, a semi-structured REST cannot be parsed by tools | 02:20 |
| Qiming | I was hoping that the community will go swagger instead | 02:21 |
| Qiming | if swagger is not perfect, we fix it | 02:21 |
| Qiming | I think the doc team has the same intention, but ... you know, doc team doesn't have developer resources | 02:22 |
| Qiming | so ... they had to make a concession | 02:22 |
| openstackgerrit | Yanyan Hu proposed openstack/senlin: Fix typos in tempest API tests for profile_delete https://review.openstack.org/321322 | 02:26 |
| openstackgerrit | Qiming Teng proposed openstack/senlin: Fix links to API reference docs https://review.openstack.org/321323 | 02:27 |
| flwang1 | Qiming: i see. we(zaqar) are trying to use swagger | 02:33 |
| flwang1 | but given we're using Falcon, it's not perfect for integrating with swagger | 02:33 |
| Qiming | em ... I was worrying about that | 02:34 |
| flwang1 | Qiming: but the unclear part is how to build the swagger json file if current sphinx-build way doesn't support that | 02:35 |
| Qiming | that is beyond my knowledge | 02:36 |
| *** openstack has joined #senlin | 02:41 | |
| openstackgerrit | Merged openstack/senlin: Fix typos in tempest API tests for profile_delete https://review.openstack.org/321322 | 02:43 |
| *** yuanying has quit IRC | 02:50 | |
| flwang1 | Qiming: thanks a lot | 02:52 |
| *** Drago has joined #senlin | 03:02 | |
| openstackgerrit | Yanyan Hu proposed openstack/senlin: Add negative tempest API test for http conflict cases https://review.openstack.org/321330 | 03:02 |
| yanyanhu | hi, Qiming, around? | 03:03 |
| *** Drago has quit IRC | 03:04 | |
| yanyanhu | I 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 |
| yanyanhu | however, policy/profile delete without detaching and removing cluster will return 409(conflict) | 03:05 |
| yanyanhu | should we make them consistent? e.g. return 409 in all those cases? | 03:06 |
| Qiming | right, should be consistent wherever possible | 03:07 |
| yanyanhu | ok | 03:07 |
| yanyanhu | will make a change here | 03:07 |
| Qiming | so ... cluster_delete should return 409 when there are conflicts | 03:07 |
| yanyanhu | yes, I think so | 03:07 |
| Qiming | please double check the semantics of 409 and 400 and see if we should change | 03:08 |
| yanyanhu | ok | 03:08 |
| Qiming | about your patch 318453 | 03:08 |
| Qiming | yanyanhu, | 03:08 |
| yanyanhu | the one in rally? | 03:09 |
| Qiming | I'm a little bit confused about the 'gate-rally-dsvm-senlin' and 'gate-rally-dsvm-senlin-rally' | 03:09 |
| Qiming | no, in project config | 03:09 |
| yanyanhu | oh, the gate job | 03:09 |
| yanyanhu | yes, that's confusing | 03:09 |
| Qiming | https://review.openstack.org/#/c/318453/1/zuul/layout.yaml | 03:09 |
| Qiming | line 1340-1344 | 03:09 |
| yanyanhu | actually I may also need to revise the name of gate job "gate-rally-dsvm-senlin" in future | 03:10 |
| Qiming | pls think twice when proposing patches to project-config | 03:11 |
| yanyanhu | yes | 03:11 |
| Qiming | we are not supposed to change things back and forth there | 03:11 |
| yanyanhu | actually I think I made a mistake when posting the last patch to add "gate-rally-dsvm-senlin" job | 03:12 |
| yanyanhu | it was supposed to match this job template: http://git.openstack.org/cgit/openstack-infra/project-config/tree/jenkins/jobs/rally.yaml#n499 | 03:13 |
| Qiming | then fix it in this patch? | 03:20 |
| Qiming | before it is getting approved? | 03:20 |
| Qiming | cores, please help review https://review.openstack.org/#/c/321316 | 03:20 |
| Qiming | we need that before getting other tempest test patches merged, e.g. https://review.openstack.org/#/c/320227/ | 03:21 |
| yanyanhu | ok, will check it | 03:21 |
| elynn | Great, you are so quick to fix it. | 03:22 |
| elynn | After this patch merged, should we move this job from experimental to gate? | 03:26 |
| openstackgerrit | Merged openstack/senlin: Fix senlin-dashboard install https://review.openstack.org/321316 | 03:29 |
| *** yuanying has joined #senlin | 03:30 | |
| *** yuanying has quit IRC | 03:45 | |
| *** yuanying has joined #senlin | 03:47 | |
| *** elynn has quit IRC | 04:33 | |
| *** elynn has joined #senlin | 04:50 | |
| *** elynn_ has joined #senlin | 04:54 | |
| *** elynn has quit IRC | 04:54 | |
| *** flwang1 has quit IRC | 05:01 | |
| openstackgerrit | Merged openstack/senlin: Tune health manager module https://review.openstack.org/320311 | 05:04 |
| openstackgerrit | Qiming Teng proposed openstack/senlin: ovo - switch service calls https://review.openstack.org/321355 | 05:22 |
| *** elynn_ has quit IRC | 05:49 | |
| xuhaiwei | Qiming, yanyanhu, can we discuss the container spec now? | 06:13 |
| yanyanhu | sure | 06:13 |
| yanyanhu | I'm actually writing more comments on it :) | 06:13 |
| xuhaiwei | I saw your last comment yanyan | 06:13 |
| yanyanhu | yea | 06:14 |
| xuhaiwei | by adding 'host' and 'host_cluster' into profile, the problem I mean is | 06:14 |
| yanyanhu | so my point is trying to avoid expose a property through API before we see generic requirement of it | 06:14 |
| xuhaiwei | for example we create a profile with host=None, host_cluster=cluster1, then we use it to create a cluster, that is k | 06:15 |
| xuhaiwei | ok | 06:15 |
| yanyanhu | yes | 06:16 |
| xuhaiwei | but if when do cluster-resize to add some more nodes, we will still use this profile, right? | 06:16 |
| yanyanhu | yes | 06:16 |
| xuhaiwei | at this time the host_cluster propertity is meanless to node_create | 06:17 |
| xuhaiwei | node_create need the 'host' actually | 06:17 |
| yanyanhu | hmm, imo, I think that means user don't care which exact host new container should be located | 06:17 |
| yanyanhu | so senlin engine should pick a node from VM cluster randomly | 06:17 |
| yanyanhu | and create new container on it | 06:17 |
| yanyanhu | and if there is placement policy | 06:18 |
| yanyanhu | it will take effect to decide the location | 06:18 |
| yanyanhu | if not, random location will be the strategy | 06:18 |
| yanyanhu | that's why I feel if user really use the profile to create container cluster, it will work | 06:18 |
| yanyanhu | just for single node case, host is necessary | 06:19 |
| yanyanhu | anyway, I'm not total against adding "host"(or what ever name) property to node obj and exposing it through API interface | 06:20 |
| xuhaiwei | if the nodes will be created randomly, that may conflict with placement policy | 06:20 |
| yanyanhu | just feel it's not a so common requirement for all resource types | 06:20 |
| yanyanhu | if there is placement policy, it will decide the location | 06:20 |
| yanyanhu | if not, random picking will be done | 06:20 |
| xuhaiwei | as 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 attached | 06:21 |
| yanyanhu | about 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/scaling | 06:21 |
| yanyanhu | no necessary | 06:22 |
| yanyanhu | as what we are doing now for nova server cluster | 06:22 |
| yanyanhu | when nova server cluster is just created, there is no placement policy attached. In this case, nova decide the location, right? | 06:23 |
| xuhaiwei | yes | 06:23 |
| yanyanhu | for container, senlin can decide the location randomly since user don't care the container location as of that time, right? | 06:23 |
| yanyanhu | once they care, a placement policy can be attached | 06:24 |
| yanyanhu | then, it will take effect and decide the location of any new created containers in future | 06:24 |
| xuhaiwei | I know what you mean | 06:24 |
| yanyanhu | so imo, almost the same cases :) | 06:24 |
| openstackgerrit | Qiming Teng proposed openstack/senlin: ovo - switch profile calls https://review.openstack.org/321366 | 06:25 |
| yanyanhu | if they really want to control container location from the beginning | 06:25 |
| yanyanhu | one possible way is create an empty cluster | 06:25 |
| yanyanhu | and then attach placement policy | 06:25 |
| yanyanhu | after that, they can scale cluster to a proper size | 06:25 |
| yanyanhu | xuhaiwei, 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 case | 06:27 |
| yanyanhu | we may need to define a good abstraction for it before adding it | 06:27 |
| yanyanhu | for all possible resource types | 06:27 |
| yanyanhu | e.g. even for storage | 06:28 |
| xuhaiwei | hmm, we should think out a most approprate solution | 06:28 |
| yanyanhu | yes, if we can abstract this conception good enough | 06:28 |
| yanyanhu | we should add it | 06:28 |
| yanyanhu | then container cluster could be the first profile to consume it | 06:28 |
| yanyanhu | container resource | 06:28 |
| xuhaiwei | let me think about it more | 06:29 |
| yanyanhu | just don't clear how to explain it in some other possible use cases | 06:29 |
| yanyanhu | ok | 06:29 |
| yanyanhu | thanks, we can have more discussion on it before starting add this property to node :) | 06:29 |
| yanyanhu | once add it, we need to give a good explanation on it :) | 06:30 |
| xuhaiwei | yes | 06:30 |
| xuhaiwei | if 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' option | 06:33 |
| yanyanhu | yes, using '--host' is more convenient. But clear/correct design is more important, right :) | 06:34 |
| xuhaiwei | yes | 06:35 |
| yanyanhu | since we need to consider lots of other issues about "host" property. e.g. whether user is allowed to update it? | 06:36 |
| yanyanhu | if so, what will happen? | 06:36 |
| xuhaiwei | update the 'host'? | 06:37 |
| xuhaiwei | you mean by node-update to update the 'host'? | 06:38 |
| yanyanhu | yes | 06:38 |
| yanyanhu | since this is a property visible for user, and they can define it when create node | 06:39 |
| yanyanhu | they will want to know whether they can update it | 06:39 |
| xuhaiwei | that is container's live-migration? | 06:40 |
| yanyanhu | kinda | 06:40 |
| yanyanhu | if it is supported by backend service | 06:40 |
| yanyanhu | which is now pure docker service I think | 06:40 |
| yanyanhu | since in profile, all properties are marked as updatable or not | 06:41 |
| yanyanhu | so user is clear about it | 06:41 |
| yanyanhu | but if it is just a node property, we don't know how to handle it | 06:41 |
| yanyanhu | since in our current design, profile decides every detail of a resource type | 06:42 |
| yanyanhu | how to create/delete/update/check/recover | 06:42 |
| xuhaiwei | thats seems reasonable, not think about it that far | 06:45 |
| yanyanhu | yes, so once we are clear about how to map "host" property in node to profile property for all type of resources | 06:46 |
| yanyanhu | we are ready to have it in node object and API interface :) | 06:46 |
| xuhaiwei | yesa | 06:48 |
| yanyanhu | so 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 #senlin | 06:57 | |
| openstackgerrit | Qiming Teng proposed openstack/senlin: ovo - switch profile calls https://review.openstack.org/321366 | 06:58 |
| openstackgerrit | Qiming Teng proposed openstack/senlin: ovo - switch policy calls https://review.openstack.org/321380 | 06:59 |
| openstackgerrit | Yanyan Hu proposed openstack/senlin: Minor revise cluster_delete engine service call https://review.openstack.org/321382 | 07:06 |
| openstackgerrit | Qiming Teng proposed openstack/senlin: ovo - switch receiver calls https://review.openstack.org/321393 | 07:38 |
| *** shu-mutou is now known as shu-mutou-AFK | 08:27 | |
| openstackgerrit | Yanyan Hu proposed openstack/senlin: Minor revise cluster_delete engine service call https://review.openstack.org/321382 | 08:53 |
| openstackgerrit | Yanyan Hu proposed openstack/senlin: Add negative tempest API test for cluster_delete https://review.openstack.org/321423 | 08:53 |
| openstackgerrit | Qiming Teng proposed openstack/senlin: ovo - switch node calls https://review.openstack.org/321425 | 08:58 |
| *** flwang1 has joined #senlin | 09:16 | |
| openstackgerrit | Qiming Teng proposed openstack/senlin: ovo - switch cluster lock and node lock calls https://review.openstack.org/321441 | 09:39 |
| *** elynn_ has joined #senlin | 09:43 | |
| *** elynn_ has quit IRC | 09:47 | |
| *** elynn_ has joined #senlin | 09:48 | |
| Qiming | sigh ... | 09:59 |
| openstackgerrit | Merged openstack/senlin: ovo - switch service calls https://review.openstack.org/321355 | 09:59 |
| Qiming | pipeline is accumulating again | 09:59 |
| Qiming | cannot proceed now | 09:59 |
| Qiming | [tengqm@node1 senlin]$ git review | 10:00 |
| Qiming | You are about to submit multiple commits. This is expected if you are | 10:00 |
| Qiming | submitting a commit that is dependent on one or more in-review | 10:00 |
| Qiming | commits. Otherwise you should consider squashing your changes into one | 10:00 |
| Qiming | commit before submitting. | 10:00 |
| Qiming | The outstanding commits are: | 10:00 |
| Qiming | 31cac4c (HEAD, use-registry-object) ovo - switch health registry calls | 10:00 |
| Qiming | 87dc603 Tune health manager module | 10:00 |
| Qiming | ae3e3b9 (use-node-lock-object) ovo - switch cluster lock and node lock calls | 10:00 |
| Qiming | de15589 (use-node-object) ovo - switch node calls | 10:00 |
| Qiming | 172e7b1 (use-receiver-object) ovo - switch receiver calls | 10:00 |
| Qiming | f534b1a (use-policy-object) ovo - switch policy calls | 10:00 |
| Qiming | 3c10ef1 (use-profile-object) ovo - switch profile calls | 10:00 |
| Qiming | 2ce1f3a (user-service-object) ovo - switch service calls | 10:00 |
| Qiming | Do you really want to submit the above commits? | 10:00 |
| Qiming | Type 'yes' to confirm, other to cancel: yes | 10:00 |
| Qiming | remote: Processing changes: refs: 1, done | 10:00 |
| Qiming | remote: (W) 31cac4c: too many commit message lines longer than 70 characters; manually wrap lines | 10:00 |
| Qiming | To https://tengqm:ZcK4qjpWkuIY@review.openstack.org/openstack/senlin.git | 10:00 |
| Qiming | ! [remote rejected] HEAD -> refs/publish/master/use-registry-object (change https://review.openstack.org/320311 closed) | 10:00 |
| Qiming | error: failed to push some refs to 'https://tengqm:ZcK4qjpWkuIY@review.openstack.org/openstack/senlin.git' | 10:00 |
| Qiming | it was because the health manager tuning jumping into the middle | 10:00 |
| Qiming | maybe time to take a break | 10:01 |
| elynn_ | Then we can do a a quick merge for the patches before tuning patch. | 10:01 |
| elynn_ | :) | 10:02 |
| Qiming | yes, could use some helps now | 10:02 |
| Qiming | running home | 10:02 |
| elynn_ | Waiting for the experimental jobs result :) | 10:03 |
| *** Qiming has quit IRC | 10:08 | |
| openstackgerrit | Yanyan Hu proposed openstack/senlin: Add negative tempest API test for cluster_delete https://review.openstack.org/321423 | 10:08 |
| openstackgerrit | Yanyan Hu proposed openstack/senlin: Minor revise cluster_delete engine service call https://review.openstack.org/321382 | 10:08 |
| openstackgerrit | Merged openstack/senlin: Fix links to API reference docs https://review.openstack.org/321323 | 10:09 |
| *** yanyanhu has quit IRC | 10:09 | |
| *** elynn_ has quit IRC | 10:14 | |
| openstackgerrit | Merged openstack/senlin: ovo - switch profile calls https://review.openstack.org/321366 | 10:16 |
| openstackgerrit | Merged openstack/senlin: ovo - switch policy calls https://review.openstack.org/321380 | 10:16 |
| openstackgerrit | Merged openstack/senlin: ovo - switch receiver calls https://review.openstack.org/321393 | 10:23 |
| openstackgerrit | Merged openstack/senlin: ovo - switch node calls https://review.openstack.org/321425 | 10:24 |
| *** Qiming has joined #senlin | 10:59 | |
| *** elynn_ has joined #senlin | 12:12 | |
| *** idonotknow_ has joined #senlin | 14:48 | |
| *** Drago has joined #senlin | 14:48 | |
| *** Drago has quit IRC | 14:50 | |
| *** Drago has joined #senlin | 14:50 | |
| openstackgerrit | Qiming Teng proposed openstack/senlin: ovo - switch cluster lock and node lock calls https://review.openstack.org/321441 | 15:43 |
| *** Qiming has quit IRC | 16:08 | |
| *** elynn_ has quit IRC | 17:11 | |
| *** idonotknow_ has quit IRC | 18:07 | |
| *** flwang1 has quit IRC | 20:15 | |
| *** flwang1 has joined #senlin | 22:00 | |
| *** Drago has quit IRC | 22:39 | |
| *** Qiming has joined #senlin | 23:36 | |
| *** elynn_ has joined #senlin | 23:52 | |
| *** elynn_ has quit IRC | 23:59 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!