| *** wanghao has joined #openstack-mogan | 00:57 | |
| *** wanghao has quit IRC | 01:08 | |
| *** wanghao has joined #openstack-mogan | 01:09 | |
| wanghao | morning | 01:14 |
|---|---|---|
| wanghao | zhenguo: ping | 01:14 |
| wanghao | I send the tasks update email to you | 01:14 |
| wanghao | pls have a look | 01:14 |
| *** wanghao_ has joined #openstack-mogan | 01:15 | |
| *** wanghao has quit IRC | 01:18 | |
| zhenguo | wanghao:o/ | 01:22 |
| *** litao__ has joined #openstack-mogan | 01:25 | |
| zhenguo | wanghao: thanks for the proposal, how about also including 'no updates' tasks? | 01:30 |
| zhenguo | hi all, I changed to use PATCH method for flavor update and get rid of the extraspecs endpoint https://review.openstack.org/#/c/472157/ | 01:52 |
| zhenguo | liusheng: how about renaming server.extra to server.metadata | 02:10 |
| liusheng | zhenguo: yes, extra looks werid, and the extra field now is in servers table, but many flavor's fields like flavor extra is in separated tables, what your thoughts ? | 02:14 |
| zhenguo | liusheng: yes, I think we should refactor it | 02:15 |
| liusheng | zhenguo: which way you prefer ? | 02:15 |
| zhenguo | liusheng: separate extra table out and change to use metadata in api object :D | 02:15 |
| liusheng | zhenguo: too many tables to store the properties of an object may make the combination logical and handling prcess more complex, and may easy to cause issues like db deadlock | 02:18 |
| liusheng | zhenguo: just personal concern :) | 02:19 |
| zhenguo | liusheng: not sure, but seems nova split all such tables out | 02:21 |
| zhenguo | liusheng: but if we just store data in the table maybe it's not needed, I think it's benefit for indexing, right? | 02:23 |
| liusheng | zhenguo: maybe it is better to only separate the relative independent part like server_fault and server_nics | 02:24 |
| liusheng | zhenguo: not sure if that is common use case | 02:25 |
| zhenguo | liusheng: why those are independent? what's the difference between them with metadata? | 02:25 |
| liusheng | zhenguo: I am just found that the flavor model has been separated into many tables :D | 02:26 |
| zhenguo | liusheng: hah, yes, I don't see the difference with server_nics for server and nics for flavor :D | 02:27 |
| liusheng | zhenguo: the fault and nic themself include many fields and looks like a independent object | 02:27 |
| liusheng | zhenguo: like flavor_cpu, flavor_memory, flavor_disks, flavor_project, they all in separated tables | 02:29 |
| zhenguo | liusheng: yes, as I think they are just like flavor extra specs, but not sure | 02:30 |
| liusheng | zhenguo: not very sure about the advantage and disadvantage, but personally think it's better to keep things simple to avoid potential issues, since we ofen met problems like db deadlock in productive environment | 02:33 |
| zhenguo | liusheng: you mean just save a compext dict in to one column? | 02:34 |
| zhangyang | zhenguo: i noticed now we have availability zone property in compute node object. if we manage it via aggregate, shall we change it in the compute node table when we add a node to a aggregate or we just get the availability zone info from the aggregate table. | 02:36 |
| liusheng | zhenguo: not only about this, but metadata looks better to be in separated table :D | 02:37 |
| zhenguo | zhangyang: not quite sure, which do you perfer? | 02:39 |
| zhenguo | zhangyang: or maybe just get rid of it from compute node, so we don't need the backend driver provide such property | 02:39 |
| zhenguo | liusheng: really not quite sure about this | 02:40 |
| zhenguo | liusheng: but flavor things now seems really weird | 02:40 |
| liusheng | zhenguo: haha | 02:41 |
| liusheng | zhenguo: does the ubuntu image in our env has default passord ? | 02:46 |
| zhenguo | liusheng: no, you can add a keypair | 02:46 |
| liusheng | zhenguo: lol | 02:46 |
| zhenguo | liusheng: I already make it posiible to connect to private network through that mogan server | 02:47 |
| liusheng | zhenguo: cool | 02:49 |
| wanghao_ | zhenguo: sure | 02:52 |
| zhenguo | wanghao_: thanks! | 02:52 |
| wanghao_ | zhenguo: will send the email ASAP | 02:52 |
| zhenguo | wanghao_: ok | 02:52 |
| zhangyang | zhenguo: e...now we get availability zone from ironic driver? I thought we were just using the default availability zone... | 02:55 |
| zhenguo | zhangyang: hah, yes, we ineed get az from the driver | 02:55 |
| zhenguo | zhangyang: I need to be away for mins, ttyl | 02:56 |
| * zhenguo brb | 02:56 | |
| openstackgerrit | Merged openstack/mogan master: [DOC] Add sample config and policy files to mogan docs https://review.openstack.org/471637 | 03:34 |
| *** wanghao_ has quit IRC | 06:27 | |
| *** wanghao has joined #openstack-mogan | 06:27 | |
| *** wanghao has quit IRC | 06:29 | |
| *** wanghao has joined #openstack-mogan | 06:29 | |
| *** wanghao_ has joined #openstack-mogan | 06:39 | |
| zhenguo | liusheng: maybe we just need a flavor like this defination https://specs.openstack.org/openstack/ironic-specs/specs/not-implemented/node-resource-class.html | 06:41 |
| *** wanghao has quit IRC | 06:42 | |
| zhenguo | liusheng: add a resources property including the node resource class to match | 06:44 |
| liusheng | zhenguo: for now, it is the name of flavor ? | 06:47 |
| zhenguo | liusheng: yes | 06:47 |
| zhenguo | liusheng: a new resources can include not only one resurce class | 06:47 |
| zhenguo | liusheng: and maybe just get rid of the current ram, cpu,disks, nics properties, only leave a description like before, lol | 06:48 |
| liusheng | zhenguo: hah | 06:48 |
| zhenguo | liusheng: so a simple flavor with name, description, resources, extra_specs | 06:48 |
| liusheng | zhenguo: seems, the ram, cpu, disks is intuitive for end users especially use horizon | 06:50 |
| zhenguo | liusheng: we can add that information to description | 06:51 |
| zhenguo | liusheng: like the hardware specs of a server | 06:51 |
| zhenguo | liusheng: really no need to add so many tables.... | 06:51 |
| zhenguo | sorry to refactor this over and over again | 06:52 |
| liusheng | haha | 06:52 |
| zhenguo | and I don't want to take the refactor work again, lol | 06:52 |
| zhenguo | liusheng: oh, seems valence need such things | 06:53 |
| liusheng | zhenguo: if we put them into description, user may need to filter query flavors that met them required cpus, ram, disks | 06:54 |
| liusheng | zhenguo: ok, maybe just leave it as now, if we have different requirement, we refactor it in the future | 06:54 |
| zhenguo | liusheng: as I understand, users just want to see the details before claiming a server | 06:55 |
| zhenguo | liusheng: but I don't really like it | 06:55 |
| liusheng | lol | 06:55 |
| liusheng | zhenguo: yes | 06:55 |
| zhenguo | liusheng: the currently implementation is to complex for just a flavor | 06:55 |
| zhenguo | liusheng: but we can make the resources filed more nimble | 06:56 |
| zhenguo | liusheng: for valence we can define a flavor.resources = {rsd: true, ...} | 06:57 |
| liusheng | zhenguo: how about don't use resource class to match node when scheduling like nova dose ? | 06:59 |
| liusheng | zhenguo: just using as Nova's flavor, comparing the cpus, ram, disks, and other properties in request with node's | 07:00 |
| zhenguo | liusheng: check them all equal to the node's properties | 07:00 |
| liusheng | zhenguo: yes | 07:01 |
| zhenguo | liusheng: if so, why not check check the resource class | 07:01 |
| liusheng | zhenguo: users will don't care the resource class | 07:01 |
| liusheng | zhenguo: scheduler will choose a node against the creating request according the required size | 07:02 |
| *** liujiong has joined #openstack-mogan | 07:03 | |
| zhenguo | liusheng: for baremetal is not like vms | 07:03 |
| zhenguo | liusheng: a node is a resource provider, and users can see what resouce it can provide, then just choose one flavor is ok | 07:04 |
| zhenguo | liusheng: check every detail property seems a bit useless | 07:05 |
| zhenguo | liusheng: just like that ironic specs said | 07:06 |
| liusheng | zhenguo: for baremetal, we can imagine there is a nodes pool with different capacity, user choose a flavor with required capacity, and scheduler select a proper node | 07:07 |
| liusheng | zhenguo: user don't need to care resource class | 07:07 |
| liusheng | zhenguo: and we don't need to set the resource_class/node_type when adding new nodes | 07:07 |
| zhenguo | liusheng: hah, but for harwares, you can't just check the quantities, the type is also important | 07:08 |
| zhenguo | liusheng: how can you filter every hardeare specs, it's not easy to control | 07:09 |
| liusheng | zhenguo: just similar to how Nova does now. lol | 07:10 |
| zhenguo | liusheng: nova only are about quantity | 07:10 |
| zhenguo | liusheng: and the current community efforts is also want to use resource class and a single flavor math with it | 07:11 |
| liusheng | zhenguo: may flags in flavor's metadata to indicate the hardware's type ? | 07:11 |
| zhenguo | liusheng: so many types will make it more complex | 07:11 |
| liusheng | zhenguo: placement service is dessigned to accept and handle a request with filters which include's users required capacity, | 07:14 |
| zhenguo | liusheng: placement provides inventory management, we can define which things to store to it and the way we get it | 07:15 |
| liusheng | zhenguo: I am not sure what's api looks like if ironic want to add node resource into placement in the future | 07:15 |
| zhenguo | liusheng: ironic resources already save to placement now | 07:15 |
| liusheng | zhenguo: hah, does ironic only provide the filter support only "resource class" in placement ? | 07:16 |
| zhenguo | liusheng: but not ironic call placement api to save the resource | 07:16 |
| liusheng | zhenguo: or support query by filtering cpus, ram, disks ? | 07:16 |
| zhenguo | liusheng: no, nova fetch ironic resources then save it to placement | 07:17 |
| zhenguo | liusheng: nova's flavor must provide that things and it doesn't include a property like resouces, so for now, it only filter like before | 07:17 |
| liusheng | zhenguo: got it | 07:18 |
| zhenguo | liusheng: Placement is a separate service, independent of Nova. It tracks Ironic nodes as individual resources, not as a "pretend" VM. The Nova integration for selecting an Ironic node as a resource is still being developed, as we need to update our view of the mess that is "flavors", but the goal is to have a single flavor for each Ironic machine type, rather than the current state of flavors pretending that an Ironic | 07:19 |
| zhenguo | node is a VM with certain RAM/CPU/disk quantities. | 07:19 |
| liusheng | zhenguo: yes | 07:19 |
| zhenguo | liusheng: copied from here https://openstack.nimeyo.com/114187/openstack-dev-osc-ironic-mogan-nova-mogan-and-nova-existing | 07:19 |
| liusheng | zhenguo: maybe the ram, cpu, disk of Mogan's flavor should be a range than a exact number, wdyt | 07:23 |
| zhenguo | liusheng: I prefer to keep it simple, lol | 07:24 |
| liusheng | zhenguo: e.g. we provide golden, silver, copper server, but users may want to now what's capacity of each class of servers | 07:25 |
| zhenguo | liusheng: we can have flavor baremetal-gold, baremetal-silver, operators have to divide the backend nodes in to such groups by resource_class, of course every property can be a range | 07:25 |
| zhenguo | liusheng: that can control by operators by how to defaine a resource class | 07:25 |
| liusheng | zhenguo: that's was what I want to say :D | 07:26 |
| zhenguo | liusheng: hah, so we operators need to do much more work | 07:26 |
| liusheng | zhenguo: so the ram/cpu/disk is more like description info of flavor | 07:26 |
| liusheng | zhenguo: hah | 07:26 |
| zhenguo | liusheng: yes, they will be included in the flavor description | 07:27 |
| liusheng | zhenguo: but puting all them into description may hard to filter query by one of them | 07:27 |
| liusheng | zhenguo: not sure if we have the requirements | 07:28 |
| zhenguo | liusheng: seems we don't need to filter them, just a description to show what the resouce is | 07:28 |
| liusheng | zhenguo: users may need to filter out which flavors that met their requiremet | 07:29 |
| zhenguo | liusheng: we need to ask users to change their brain, hah baremetals is not like vms | 07:30 |
| liusheng | zhenguo: hah | 07:31 |
| zhenguo | liusheng: maybe we can just turn to placement, I think the only things block us is the aggregates | 07:32 |
| liusheng | zhenguo: hah, sure | 07:32 |
| liusheng | zhenguo: we can try | 07:32 |
| zhenguo | liusheng: if we use placement for resouces tracking, we don't save the nodes info | 07:32 |
| zhenguo | liusheng: but when users list nodes, I think we can call placement api to show it | 07:33 |
| zhenguo | liusheng: and when they create a node aggreate, we can call placment do that | 07:33 |
| zhenguo | liusheng: we can pass aggregates info to placement to choose a satisfied node | 07:33 |
| liusheng | zhenguo: that's what I want to ask, does placement api can be exposed to end users ? | 07:34 |
| liusheng | zhenguo: or only used by scheduler | 07:34 |
| zhenguo | liusheng: mogan will expose the api then call placement api, we don't need users to call placement directly | 07:34 |
| liusheng | zhenguo: lol | 07:34 |
| zhenguo | liusheng: I also add placement as a alternative on the node aggregates spec. | 07:35 |
| liusheng | zhenguo: just confirmed with zhenyu, that placement api can expose to end users | 07:36 |
| zhenguo | liusheng: hah | 07:37 |
| zhenguo | liusheng: will be a way for a while, ttyl, you can talk zhenyu to help confirm whether node aggregates can leverage placement aggregates | 07:37 |
| * zhenguo brb | 07:37 | |
| liusheng | zhenguo: ok | 07:38 |
| shaohe_feng | zhenguo: OK. seems spec is more difficult for a Chinese. | 07:38 |
| *** wanghao_ has quit IRC | 07:39 | |
| *** wanghao has joined #openstack-mogan | 07:39 | |
| *** wanghao_ has joined #openstack-mogan | 07:43 | |
| *** wanghao has quit IRC | 07:47 | |
| zhenguo | shaohe_feng: hah | 07:52 |
| zhenguo | wanghao: thanks for sending out the weekly report | 07:53 |
| zhenguo | wanghao_^^ | 07:53 |
| zhenguo | liusheng, shaohe_feng, wanghao: please have a look at the flavor PATCH method patch when you got time, thanks! | 07:55 |
| shaohe_feng | zhenguo: I'm looking at it. :) | 08:00 |
| zhenguo | shaohe_feng: big thanks | 08:00 |
| shaohe_feng | zhenguo: https://tools.ietf.org/html/rfc6902 JSON patch the standard in 2013. | 08:06 |
| zhenguo | shaohe_feng: yeah, I added that rfc to the api docs | 08:07 |
| shaohe_feng | zhenguo: yes, I see the link from your patch. :) | 08:07 |
| zhenguo | shaohe_feng: hah | 08:08 |
| shaohe_feng | zhenguo: So I know why many old project does not sue patch. | 08:08 |
| shaohe_feng | s/sue/use | 08:08 |
| zhenguo | shaohe_feng: for flavor, I think we don't need a separated extraspec endpoint with POST/PUT/DELETE, just use PATCH to update flavor is enough | 08:09 |
| shaohe_feng | zhenguo: yes. one PATCH is enough. | 08:33 |
| zhenguo | liusheng: hey, what's the benefit of split metadat to be a separated table? | 08:50 |
| liusheng | zhenguo: maybe just because metadata can include many items, and in a deparated table, every items can be one key-value pair, it effecient to be indexed if we want to query something filtered by metadata | 08:55 |
| zhenguo | liusheng: seems if we use PATCH server to manage it's metadata, no need to separate it | 08:55 |
| zhenguo | liusheng: can we support metadat filter? | 08:56 |
| liusheng | zhenguo: seems Nova can support | 08:56 |
| zhenguo | liusheng: really? | 08:56 |
| zhenguo | liusheng: like tag? | 08:56 |
| liusheng | zhenguo: let me confirm | 08:56 |
| liusheng | zhenguo: :D | 08:56 |
| liusheng | zhenguo: nova don't support that | 08:57 |
| zhenguo | liusheng: hah, before we cofirm why a separated table is needed, I prefer to keep it with server and just change the api object field to metadata | 08:58 |
| liusheng | zhenguo: sure, I am ok | 08:59 |
| zhenguo | liusheng: ok, so many not sure things... | 08:59 |
| liusheng | zhenguo: lol | 08:59 |
| *** wanghao_ has quit IRC | 09:45 | |
| *** liujiong has quit IRC | 09:52 | |
| * zhenguo away | 10:01 | |
| *** liusheng has quit IRC | 14:29 | |
| *** liusheng has joined #openstack-mogan | 14:30 | |
| -openstackstatus- NOTICE: The Gerrit service on review.openstack.org is being restarted now to clear an issue arising from an unanticipated SSH API connection flood | 14:57 | |
| *** litao__ has quit IRC | 15:46 | |
| *** liusheng has quit IRC | 17:50 | |
| *** liusheng has joined #openstack-mogan | 17:51 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!