| *** elynn has joined #senlin | 01:26 | |
| *** yanyanhu has joined #senlin | 01:34 | |
| openstackgerrit | Xinhui Li proposed openstack/senlin: Add mistral driver into Senlin https://review.openstack.org/417377 | 01:35 |
|---|---|---|
| *** chohoor has joined #senlin | 01:40 | |
| *** root has joined #senlin | 01:44 | |
| *** root is now known as Guest46614 | 01:44 | |
| Guest46614 | nick XueFeng | 01:48 |
| *** Guest46614 is now known as XueFeng | 01:48 | |
| yanyanhu | hi, elynn, around? | 01:55 |
| openstackgerrit | RUIJIE YUAN proposed openstack/senlin: improve tempest test for action list https://review.openstack.org/420466 | 02:08 |
| ruijie | hi yanyanhu, can you help me review this patch when you have time. To make sure this is what we want for tempest test. :) | 02:22 |
| yanyanhu | ruijie, sure, will check it :) | 02:23 |
| ruijie | thanks yanyanhu :) | 02:23 |
| yanyanhu | my pleasure | 02:23 |
| yanyanhu | hi, ruijie, just took a look, it is exactly what we want :) | 02:25 |
| yanyanhu | thanks a lot for working on it | 02:25 |
| ruijie | great! will try to finish it before release-3 :) | 02:26 |
| yanyanhu | ruijie, thanks! I think there could be a big effort to cover all API test scenarios, so please take your time :) | 02:27 |
| elynn | Hi yanyanhu | 02:27 |
| yanyanhu | hi, elynn | 02:28 |
| elynn | Saw your emals | 02:28 |
| elynn | 02:28 | |
| yanyanhu | yep, that's what I was about to ask :) | 02:28 |
| elynn | As Qiming said, the referencing part would be difficult to handle. | 02:30 |
| yanyanhu | elynn, yes it is I think | 02:31 |
| elynn | If the user_data is the only part needs to be handled, then it's easy. But for future support for NFV, we might do some simple orchestration thing in senlin | 02:32 |
| yanyanhu | yes. for user_data, it won't be difficult. Basically a string replacement I think. But the attr reference between different resources is much more complicated | 02:33 |
| yanyanhu | it also introduces implicit dependency | 02:33 |
| yanyanhu | may need a generic way to handle this kind of depedency | 02:34 |
| yanyanhu | and decide how to build the workflow | 02:34 |
| yanyanhu | but we can start from a simple one I feel | 02:35 |
| elynn | yes, if we introduce attribute reference, there might be some tricky code in do_create. | 02:35 |
| yanyanhu | e.g. fixed dependency and creating sequence? | 02:35 |
| yanyanhu | elynn, right | 02:35 |
| elynn | yanyanhu, you mean start from a simple reference only for user_data? | 02:36 |
| yanyanhu | in our case, we always know that the port is depends on sec-group | 02:36 |
| yanyanhu | and server always depends on port | 02:36 |
| elynn | For this particular case, I plan to do so, create security_groups first, then create ports, then create user_data. | 02:37 |
| yanyanhu | elynn, no, I mean we use fixed dependent relationship when handling different resources like port, sec-group, or even volume | 02:37 |
| yanyanhu | yes | 02:37 |
| yanyanhu | that can be a simple solution | 02:37 |
| yanyanhu | although we may need more complicated/generic solution later | 02:37 |
| elynn | yes, and place it at contrib/ folder first. | 02:37 |
| yanyanhu | yes | 02:38 |
| elynn | And also another problem, | 02:38 |
| elynn | We might need cluster to pass its metadata 'inputs' to node when it creates new nodes. | 02:38 |
| XueFeng | Hi,YanYan | 02:39 |
| XueFeng | https://etherpad.openstack.qorg/p/scaling-to-existing-nodes, this link can't open | 02:39 |
| yanyanhu | XueFeng, oh, let me check | 02:41 |
| yanyanhu | XueFeng, should be https://etherpad.openstack.org/p/scaling-to-existing-nodes | 02:41 |
| yanyanhu | there is a "q" letter in the url which was added accidentally :) | 02:42 |
| yanyanhu | elynn, yes. maybe we can always include the input field of cluster's metadata into node's metadata? | 02:43 |
| elynn | yanyanhu, I think so, but that will change the senlin's code. | 02:45 |
| elynn | We can't put all the code in contrib/ folder. | 02:45 |
| yanyanhu | you mean the profile's do_create logic? | 02:45 |
| yanyanhu | I see. | 02:46 |
| yanyanhu | if so, we just implement this logic in this new profile type? | 02:46 |
| elynn | I mean the pass through the cluster's metadata 'inputs' to node | 02:46 |
| yanyanhu | let me see whether it is feasible | 02:46 |
| yanyanhu | it is feasible. Just the code will be ugly if we don't change the code of master branch... | 02:47 |
| yanyanhu | currently, profile.create_object will be invoked with node obj as input parameter | 02:48 |
| yanyanhu | and also the context | 02:48 |
| elynn | yanyanhu, so I can try to get the cluster's metadata | 02:49 |
| yanyanhu | oh, context is not used when do_create is invoked | 02:49 |
| yanyanhu | elynn, yes, you can get it. Just it looks like a hack :) | 02:49 |
| yanyanhu | unless we add cluster's metadata to node's metadata | 02:50 |
| elynn | I would have to say there will be much ugly codes in this profile.. | 02:50 |
| yanyanhu | by default using a generic way | 02:50 |
| yanyanhu | elynn, yes, it will be... | 02:50 |
| Qiming | how about we add a 'config' property to a cluster? | 02:50 |
| yanyanhu | but since that could be a common requirement to access cluster's metadata in node operation | 02:50 |
| yanyanhu | maybe we add this logic? | 02:50 |
| elynn | Qiming, property? | 02:51 |
| Qiming | I'm a little bit concerned that directly copying metadata could inflate the dict quickly | 02:51 |
| Qiming | yes | 02:51 |
| Qiming | a property | 02:51 |
| Qiming | it can be a cluster-wide shared repo | 02:51 |
| yanyanhu | Qiming, so what information will be wrapped in this property? | 02:51 |
| yanyanhu | ummm, I see | 02:52 |
| Qiming | I was thinking about this in another thread | 02:52 |
| openstackgerrit | Xinhui Li proposed openstack/senlin: Add mistral driver into Senlin https://review.openstack.org/417377 | 02:52 |
| elynn | it's in a dict schema? | 02:52 |
| XueFeng | Hi, YanYan.Now it's ok | 02:52 |
| yanyanhu | currently, we are trying to define all cluster-wide control information in policies | 02:52 |
| Qiming | for example, users have a pool of volumes to be referenced when creating nodes | 02:53 |
| Qiming | elynn, yes | 02:53 |
| yanyanhu | but there are really some information not suitable for storing in policy | 02:53 |
| Qiming | a cluster-wide configuration for network name, security group etc | 02:53 |
| yanyanhu | Qiming, maybe a volume/storage policy :P | 02:54 |
| yanyanhu | just a kidding | 02:54 |
| Qiming | I didn't invent the idea | 02:54 |
| Qiming | the idea was from magnum | 02:55 |
| Qiming | also from genesis | 02:55 |
| elynn | The pool of volumes is a cluster or a policy? | 02:55 |
| Qiming | in their design, a cluster may have quite some cluster-wide properties to be shared among nodes | 02:55 |
| yanyanhu | Qiming, I think cluster config is a good idea. | 02:56 |
| elynn | That's a great idea | 02:56 |
| Qiming | if you have a {'volume_pool': pool_id} in cluster.config, when creating a node, we can check if we have that value | 02:56 |
| yanyanhu | Just we may need to distinguish the usage of cluster config and policy for some special cases | 02:56 |
| elynn | Then we can pull information from this property. | 02:57 |
| yanyanhu | e.g. we can store available host list in both placement policy or cluster config | 02:57 |
| Qiming | we will create new volumes if needed, but if the cluster has a config, we use it | 02:57 |
| Qiming | the thing I am not sure is how to manage such a wild config property | 02:57 |
| Qiming | every key we add into that property becomes a standard | 02:58 |
| Qiming | which is not supposed to be renamed, deleted randomly | 02:58 |
| yanyanhu | Qiming, you mean the config property is not allowed to update? | 02:59 |
| Qiming | value can be updated for sure | 02:59 |
| yanyanhu | yes | 02:59 |
| Qiming | but we have to be very careful in designing the key names (and name spaces) | 03:00 |
| yanyanhu | Qiming, or we let user to decide the key? | 03:00 |
| yanyanhu | beside those ones for built-in usage? | 03:00 |
| Qiming | yes, then there are two namespaces at least: system, user | 03:00 |
| yanyanhu | e.g. those keys used by built-in policies profiles | 03:00 |
| elynn | What are the key names will be there? | 03:01 |
| yanyanhu | Qiming, yes | 03:01 |
| Qiming | elynn, that is what we are discussing | 03:01 |
| yanyanhu | or senlin: username | 03:01 |
| elynn | What's the difference between system and user? | 03:01 |
| yanyanhu | and the namespace can be used to match | 03:01 |
| yanyanhu | will join a meeting, come back later | 03:01 |
| elynn | for user namespace, it's updated allowed? | 03:01 |
| Qiming | good question | 03:02 |
| Qiming | in other words, I don't have an answer, :D | 03:02 |
| yanyanhu | I think for user namespace, users can create/update any keys/values | 03:02 |
| elynn | :D | 03:03 |
| yanyanhu | according to their need | 03:03 |
| yanyanhu | but for system ones, only value can be updated | 03:03 |
| Qiming | where will be place the update logic for user defined-keys? | 03:03 |
| yanyanhu | cluster update I guess? | 03:03 |
| Qiming | update to where? | 03:03 |
| yanyanhu | it will be a sync op | 03:03 |
| Qiming | just upate the cluster.config ? | 03:04 |
| yanyanhu | to config property? | 03:04 |
| yanyanhu | Qiming, yes, I guess so | 03:04 |
| Qiming | then node cannot reference them? | 03:04 |
| yanyanhu | each time node operations will to use cluster metadata, it is required to query the latest one | 03:05 |
| yanyanhu | from db | 03:05 |
| Qiming | cluster config == node metadata? | 03:05 |
| Qiming | lemme show you an example structure from genesis | 03:05 |
| Qiming | 110 type AsgUserdata struct { | 03:05 |
| Qiming | 111 RootPass string | 03:05 |
| Qiming | 112 SSHKey string | 03:05 |
| Qiming | 113 DisgoCfg string | 03:05 |
| Qiming | 114 PassExpire string | 03:05 |
| Qiming | 115 } | 03:05 |
| yanyanhu | Qiming, no, I mean each time when some information stored in cluster config is required to finish node operations | 03:06 |
| openstackgerrit | RUIJIE YUAN proposed openstack/senlin: improve tempest api for action show https://review.openstack.org/420478 | 03:06 |
| Qiming | how do we know that? | 03:06 |
| yanyanhu | if we have cluster config, we don't use node metadata | 03:06 |
| Qiming | it is user defined, the keys and values are all provided by users | 03:06 |
| yanyanhu | Qiming, yes, so for user define ones, built-in policy/profile won't be aware of them | 03:07 |
| elynn | We could let profile retrieve the cluster.config itself? When needed | 03:08 |
| Qiming | the reference and usage of "system" config is more clear to me, but for "user" config, I'm not sure how we will handle them | 03:09 |
| yanyanhu | hmm, let me see. If build-in policies/profiles are not aware of user defined config, it could be inadequate... | 03:09 |
| Qiming | for "system" config, we add a key which is named carefully, and we will check it in profile operations and do something accordingly | 03:09 |
| elynn | I still don't know why build-in policies/profiles are not aware of user defined config? | 03:09 |
| yanyanhu | do need more think here... | 03:09 |
| Qiming | built in policies can access them for sure | 03:10 |
| yanyanhu | or maybe we should ask, what is the case user want to define customized config? | 03:10 |
| Qiming | just you are getting a collection of key-value pairs, provided by users | 03:11 |
| Qiming | and ... you don't know how to handle them .. | 03:11 |
| yanyanhu | Qiming, yes, just they don't know that they means maybe | 03:11 |
| yanyanhu | yep | 03:11 |
| Qiming | right, I cannot think of a user case for this either | 03:11 |
| Qiming | it looks to me more like a metadata | 03:11 |
| yanyanhu | Qiming, customized policy/profile :) | 03:11 |
| Qiming | e.g. cluster.metadata.department = "finance" | 03:12 |
| Qiming | okay, that makes sense | 03:12 |
| Qiming | we are adding kind of labels to clusters then | 03:13 |
| Qiming | unless user provide their own profile/policy types, senlin won't touch them | 03:13 |
| yanyanhu | if those information are only for tag, they are more like metadata rather then config I think | 03:13 |
| yanyanhu | agree with u | 03:13 |
| Qiming | senlin only provides basic CRUD operations to them | 03:13 |
| Qiming | along with cluster operations | 03:13 |
| elynn | There are two kinds of metadata here, one for user query, and one for senile internal used I think | 03:14 |
| yanyanhu | elynn, so we either add a config property for cluster, or we add a config field in cluster metadata | 03:16 |
| elynn | yanyanhu, yes, add a config field in metadata will not need to change current senlin codes until we think it thoroughly. | 03:17 |
| yanyanhu | yes | 03:18 |
| Qiming | okay | 03:19 |
| yanyanhu | leave for while, back soon | 03:19 |
| Qiming | a special key is needed then | 03:19 |
| Qiming | we are not supposed to copy the whole metadata down to node level, :) | 03:20 |
| elynn | Qiming, if profile can access cluster's metadata, then we don't need to copy the metadata to node. | 03:20 |
| Qiming | yes, we can | 03:21 |
| *** Jeffrey4l_ has quit IRC | 03:21 | |
| *** Jeffrey4l has joined #senlin | 03:21 | |
| Qiming | from the node object you get the cluster, then the cluster metadata | 03:21 |
| elynn | okay | 03:21 |
| elynn | about the security_groups part, I think we might need a policy to handle it instead create a new one in profile. | 03:22 |
| yanyanhu | i'm back | 03:24 |
| Qiming | currently we support name only | 03:24 |
| Qiming | and we are treating that as the identity of a security group to be used | 03:24 |
| Qiming | and ... it is a list ... | 03:25 |
| yanyanhu | Qiming, yes, sec-group takes effect in cluster-scope | 03:25 |
| yanyanhu | rather than node | 03:25 |
| Qiming | some intelligence we can build is to check if the specified security group can be found | 03:25 |
| *** chohoor has quit IRC | 03:26 | |
| yanyanhu | so handling it in policy sounds more reasonable | 03:26 |
| Qiming | if not, whether there are rules provided so that we can create one | 03:26 |
| yanyanhu | but we also need to consider the case that different nodes want different sec rules | 03:26 |
| Qiming | policy? | 03:26 |
| yanyanhu | maybe based on roles | 03:26 |
| Qiming | ... | 03:27 |
| Qiming | how about we handle these threads one by one? | 03:27 |
| Qiming | I cannot think clearly if roles are brought into this picture at this stage ... | 03:28 |
| yanyanhu | sure :) | 03:28 |
| Qiming | ethan and I were discussing the creation of security groups | 03:29 |
| yanyanhu | so, get back on sec-group | 03:29 |
| Qiming | if we are revising nova server profile, within or outside the current code base, how we are gonna do that | 03:29 |
| elynn | yes back to sg.. | 03:29 |
| yanyanhu | if we create it in profile, that means the creation of first node will include the creation of sec-group? | 03:30 |
| yanyanhu | and that sec-group will be logged into cluster's metadata and reused by the following created nodes? | 03:30 |
| elynn | Qiming, so you mean I can check the sg name in profile and see if it's exists and then check if rules are added, each time node creating? | 03:30 |
| Qiming | elynn, very rough idea | 03:31 |
| Qiming | but it will bring in a lot of problems I think | 03:31 |
| Qiming | too naive | 03:31 |
| elynn | I'm considering using a policy to create sgs and store the ids in cluster metadata. | 03:31 |
| Qiming | different nodes will try create the same SG | 03:32 |
| elynn | Then profile creation can reference it when creating new nodes. | 03:32 |
| Qiming | using policy sounds more feasible and practical | 03:32 |
| *** wllabs has joined #senlin | 03:32 | |
| Qiming | the problem is the process of creating cluster, creating policy, attach policy ... is boring for such a feature | 03:33 |
| elynn | Qiming, yes, that's the side effect... | 03:33 |
| elynn | We can improve the current processes, When creating policies along with cluster. | 03:35 |
| Qiming | I'm thinking about such a structure | 03:37 |
| Qiming | cluster: | 03:37 |
| Qiming | properties: | 03:37 |
| Qiming | profile_id: <blah> | 03:37 |
| Qiming | metadata: | 03:37 |
| Qiming | department: finance | 03:37 |
| Qiming | author: zhang_san | 03:37 |
| Qiming | ... | 03:37 |
| Qiming | __builtin__: # this can be promoted to a config property | 03:37 |
| Qiming | security_groups: | 03:37 |
| Qiming | - name: allow_ping | 03:37 |
| Qiming | auto_create: true | 03:38 |
| Qiming | rules: | 03:38 |
| Qiming | - direction: ingress | 03:38 |
| Qiming | protocol: ICMP | 03:38 |
| Qiming | ... | 03:38 |
| Qiming | - name: allow_ssh | 03:38 |
| Qiming | auto_create: false | 03:38 |
| elynn | When does profile handle these metadata? during cluster creation? | 03:39 |
| Qiming | yup, if we go down this road, it will become a cluster asset | 03:39 |
| elynn | auto_create here means? | 03:40 |
| elynn | just a reference? | 03:40 |
| Qiming | there are two security groups defined | 03:40 |
| Qiming | for allow_ping, we will check if an existing SG is there named 'allow_ping' | 03:41 |
| Qiming | we do nothing if so | 03:41 |
| Qiming | then if 'allow_ping' is not found, and 'auto_create' is true, we check if rules are provided to create one | 03:41 |
| Qiming | for 'allow_ssh', auto_create is false, if we cannot find such a SG, and given that 'auto_create' is false, we cannot do anything, just error | 03:42 |
| elynn | Sounds good, but what if we have others to create, like lb, should we go this road? | 03:44 |
| yanyanhu | umm, currently, sec-group is not enforced to name unique in nova | 03:45 |
| yanyanhu | so there could be situation that two sec-groups belong to the same user have the same name | 03:45 |
| Qiming | security groups are neutron objects? | 03:46 |
| yanyanhu | yes, it is provided by neutron actually | 03:46 |
| yanyanhu | also not name-unique enforced in neutron | 03:47 |
| Qiming | if there is name unique issue ... | 03:47 |
| Qiming | we can change the 'name' in the snippet above to 'id' | 03:48 |
| elynn | How do we reference 'id' if it's not created yet? | 03:48 |
| yanyanhu | umm, that is a problem. | 03:50 |
| yanyanhu | and since the node creation is concurrent, so avoid need to consider concurrency issue... | 03:51 |
| yanyanhu | e.g. two nodes' creation trigger the creation of two sec-groups... | 03:52 |
| yanyanhu | or we stored the creation result, e.g. sec-group id to cluster metadata? | 03:53 |
| Qiming | right, good question | 03:53 |
| Qiming | cluster object is always created before node objects | 03:54 |
| Qiming | so we may need to check and create SGs before creating nodes and delete them if necessary | 03:54 |
| yanyanhu | yes, delete logic is also needed | 03:54 |
| Qiming | created SGs will be stored somewhere in the cluster properties | 03:55 |
| Qiming | there are other complexities as well, there are things you can update, there are others you cannot update | 03:55 |
| Qiming | that is why I was suggesting a config property | 03:55 |
| Qiming | and even a separate group of APIs for it | 03:55 |
| Qiming | in the long run | 03:55 |
| Qiming | leaving for lunch | 03:56 |
| Qiming | starving ... | 03:56 |
| yanyanhu | ok, lets keep discussing later | 03:56 |
| elynn | see U afternoon | 03:56 |
| *** elynn has quit IRC | 04:11 | |
| wllabs | scaling policy has a propoerties number is 2 | 04:21 |
| wllabs | create a receiver-create -P count=10 | 04:21 |
| wllabs | if triggering reciver, num of node what the cluster scaling node | 04:22 |
| wllabs | if triggering reciver, How many nodes will be scaling | 04:30 |
| wllabs | Qiming， I set scaling out num is 3, but senlin cluster-scale-out mycluster only add one node | 04:46 |
| *** fabian4 has quit IRC | 05:07 | |
| *** fabian4 has joined #senlin | 05:08 | |
| *** fabian4 has quit IRC | 05:09 | |
| *** fabian4 has joined #senlin | 05:10 | |
| ruijie | it depends the max_size of your cluster | 05:24 |
| *** elynn has joined #senlin | 05:24 | |
| ruijie | e.g current you have 2 nodes in your cluster. and the max_size of your cluster is 3. And if you set the parameter "strict" to False when creating receiver, it will only create ONE node even if you set the number greater than 1 | 05:28 |
| ruijie | And for the receiver(scale_out) and policy, if you set the number when you create the receiver, the cluster_scale_out will use the number but not the number in your policy. | 05:31 |
| ruijie | wllabs | 05:31 |
| wllabs | ok, thank you | 05:36 |
| ruijie | ur welcome:) | 05:43 |
| *** chohoor has joined #senlin | 05:54 | |
| wllabs | does senlin can direct handle ceilomete? | 05:54 |
| wllabs | scale_out_alarm: | 05:54 |
| wllabs | type: OS::Ceilometer::Alarm | 05:54 |
| wllabs | properties: | 05:54 |
| wllabs | description: trigger when bandwidth insufficient | 05:54 |
| wllabs | meter_name: network.services.lb.incoming.bytes.rate | 05:54 |
| wllabs | statistic: avg | 05:54 |
| wllabs | period: 60 | 05:54 |
| wllabs | evaluation_periods: 1 | 05:54 |
| wllabs | threshold: 28000 | 05:54 |
| wllabs | repeat_actions: True | 05:54 |
| wllabs | alarm_actions: | 05:54 |
| wllabs | - {get_attr: [receiver_scale_out, channel, alarm_url]} | 05:54 |
| wllabs | comparison_operator: ge | 05:55 |
| wllabs | query: | 05:55 |
| wllabs | metadata.user_metadata.cluster_id: {get_resource: cluster} | 05:55 |
| wllabs | ruijie | 05:55 |
| yanyanhu | wllabs, we supported ceilometer resource(e.g. alarm) creating in senlin before. But that functionality was finally deprecated for we think the building of alarm is actually out of senlin's scope | 06:00 |
| yanyanhu | senlin will handle the bottom half of autoscaling, including scale up/down the cluster size | 06:00 |
| yanyanhu | but we rely on external monitoring system to trigger the scaling | 06:01 |
| wllabs | thank you | 06:01 |
| yanyanhu | hi, will leave for a meeting, back later | 06:01 |
| wllabs | Take me on | 06:01 |
| *** shu-mutou has joined #senlin | 06:10 | |
| *** Drago has quit IRC | 06:51 | |
| openstackgerrit | RUIJIE YUAN proposed openstack/senlin: revise tempest api test for cluster policy https://review.openstack.org/420526 | 07:10 |
| openstackgerrit | Shu Muto proposed openstack/senlin-dashboard: Address receiver panel to recent Horizon framework https://review.openstack.org/414900 | 07:17 |
| openstackgerrit | Shu Muto proposed openstack/senlin-dashboard: Add create action into Receiver panel https://review.openstack.org/415183 | 07:17 |
| openstackgerrit | Cao Xuan Hoang proposed openstack/senlin: Replaced e.message with str(e) https://review.openstack.org/420548 | 07:53 |
| *** zhurong has joined #senlin | 08:05 | |
| *** wllabs_ has joined #senlin | 08:48 | |
| *** wllabs has quit IRC | 08:49 | |
| *** wllabs_ is now known as wllabs | 08:50 | |
| *** shu-mutou is now known as shu-mutou-AWAY | 09:14 | |
| yanyanhu | hi, guys, just a reminding, please leave your +1 on those todos in the following etherpad, lets get through all those items in tomorrow's meeting, thanks | 09:26 |
| yanyanhu | https://etherpad.openstack.org/p/senlin-ocata-meetup | 09:26 |
| openstackgerrit | RUIJIE YUAN proposed openstack/senlin: revise tempest api test for cluster-1 https://review.openstack.org/420606 | 09:32 |
| openstackgerrit | RUIJIE YUAN proposed openstack/senlin: revise tempest api test for cluster policy https://review.openstack.org/420526 | 09:35 |
| openstackgerrit | RUIJIE YUAN proposed openstack/senlin: improve tempest test for action list https://review.openstack.org/420466 | 09:37 |
| *** zhurong has quit IRC | 09:37 | |
| openstackgerrit | RUIJIE YUAN proposed openstack/senlin: improve tempest api for action show https://review.openstack.org/420478 | 09:38 |
| *** XueFeng has quit IRC | 09:59 | |
| *** zhurong has joined #senlin | 10:08 | |
| ruijie | just be told tomorrow is out company's annual meeting .. | 10:15 |
| ruijie | may miss the IRC meeting tomorrow. | 10:15 |
| *** yanyanhu has quit IRC | 10:34 | |
| openstackgerrit | XueFeng Liu proposed openstack/senlin: Fix _add_listener cannot get project https://review.openstack.org/420631 | 10:37 |
| *** chohoor has quit IRC | 10:58 | |
| *** root____4 has joined #senlin | 11:14 | |
| root____4 | QiMing, about ironic. It's the same with QiMing, about ironic. It's the same with novanova | 11:29 |
| *** root____4 is now known as XueFeng | 11:29 | |
| XueFeng | QiMing, about ironic. We can think it's the same with nova | 11:30 |
| openstackgerrit | miaohb proposed openstack/senlin: Add db purge in senlin manage https://review.openstack.org/420666 | 11:41 |
| *** wllabs_ has joined #senlin | 12:00 | |
| *** wllabs has quit IRC | 12:01 | |
| *** wllabs_ is now known as wllabs | 12:01 | |
| *** blinky_ghost has joined #senlin | 12:08 | |
| blinky_ghost | Hi all, I'm been looking at senlin can anyone explain me if it supports auto-healing, something like I have a cluster with 2 nodes and if one the nodes is deleted or in Error state, it creates another automatically? thanks | 12:13 |
| XueFeng | hi, blinky. Senlin can do this. | 12:20 |
| XueFeng | You can create a policy which you want to do in recovering, and attach policy to cluster. | 12:22 |
| blinky_ghost | XueFeng: thanks, something like this: health_policy_poll.yaml from examples | 12:24 |
| blinky_ghost | ? | 12:24 |
| blinky_ghost | XueFeng: I applied this from file health_policy_poll.yaml with has policy NODE_STATUS_POLLING. For testing I deleted one of the nodes of the cluster but senlin didn't rebuild it. What I'm missing? | 12:41 |
| wllabs | 我也有这种情况 | 12:47 |
| wllabs | 好像根本不起作用 | 12:47 |
| wllabs | 估计是有bug | 12:47 |
| *** zhurong has quit IRC | 13:03 | |
| XueFeng | hi, you mean you delete node in nove layer? | 13:06 |
| XueFeng | This condition is a bug, need to fix. | 13:07 |
| XueFeng | If | 13:07 |
| XueFeng | http://git.openstack.org/cgit/openstack/senlin/tree/senlin/engine/actions/cluster_action.py#n661 | 13:10 |
| XueFeng | This line we need add extra conditional | 13:11 |
| XueFeng | do recover will be a complicated actions, we will continue to perfer the function. Also we will support workflow to control action flow. | 13:18 |
| openstackgerrit | Merged openstack/senlin-dashboard: Address receiver panel to recent Horizon framework https://review.openstack.org/414900 | 14:24 |
| openstackgerrit | Merged openstack/senlin: Replaced e.message with str(e) https://review.openstack.org/420548 | 14:25 |
| openstackgerrit | Merged openstack/senlin: improve tempest api for action show https://review.openstack.org/420478 | 14:25 |
| *** blinky_ghost has quit IRC | 14:32 | |
| *** blinky_ghost has joined #senlin | 14:36 | |
| blinky_ghost | XueFeng: Yes i deleted it with nova. How can I test this? When the instance is in error? | 14:38 |
| XueFeng | hi,blinky. May you can cerate many instances until your resource is insufficient. | 14:55 |
| XueFeng | Then you use senlin node-delete to delete some 'ACTIVE' nodes. | 14:56 |
| XueFeng | Then test do_recover again. | 14:56 |
| *** wllabs has quit IRC | 14:59 | |
| *** wllabs has joined #senlin | 14:59 | |
| *** ruijie-phone has joined #senlin | 15:04 | |
| ruijie-phone | this is | 15:06 |
| *** ruijie-phone has quit IRC | 15:07 | |
| blinky_ghost | XueFeng: I'm getting mycluster [f8fd34e9] CLUSTER_CHECK - error: CLUSTER_CHECK [a371e0c3] failed after deleted the node. 017-01-16 15:36:22.079 26340 ERROR senlin.drivers.openstack.sdk ResourceNotFound: ResourceNotFound: No Server found for a76e7bf4-f9a1-40a8-8a7a-55a2ffc9cca8 newnode [4f0ade66] NODE_CHECK - error: Node status is not ACTIVE. Shouldn't it create a new one now? | 15:37 |
| *** Drago has joined #senlin | 15:49 | |
| XueFeng | This because you have used nova delete before. Now you can use senlin-delete to delete this node. About If this condition need to create a new VM, will discuss tomorrow. | 15:53 |
| *** Drago has quit IRC | 15:55 | |
| *** Drago has joined #senlin | 16:01 | |
| blinky_ghost | XueFeng: but if I delete the node using senlin it only checks for the active node, because it assumes the other was deleted and does nothing. | 16:39 |
| openstackgerrit | OpenStack Proposal Bot proposed openstack/senlin: Updated from global requirements https://review.openstack.org/419941 | 16:52 |
| openstackgerrit | OpenStack Proposal Bot proposed openstack/python-senlinclient: Updated from global requirements https://review.openstack.org/420865 | 17:28 |
| openstackgerrit | OpenStack Proposal Bot proposed openstack/senlin: Updated from global requirements https://review.openstack.org/419941 | 17:29 |
| *** blinky_ghost has quit IRC | 19:00 | |
| *** elynn has quit IRC | 19:02 | |
| *** elynn_ has joined #senlin | 19:02 | |
| *** Jeffrey4l has quit IRC | 21:34 | |
| *** Jeffrey4l has joined #senlin | 21:35 | |
| *** xuhaiweixuhaiwei has joined #senlin | 23:30 | |
| *** elynn_ has quit IRC | 23:57 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!