| *** lkarm has joined #senlin | 00:05 | |
| *** lkarm has quit IRC | 00:09 | |
| *** Qiming has quit IRC | 00:13 | |
| *** jruano has joined #senlin | 00:19 | |
| *** elynn_ has quit IRC | 00:26 | |
| *** elynn_ has joined #senlin | 00:26 | |
| *** lawrancejing has joined #senlin | 00:29 | |
| *** jdandrea has quit IRC | 01:24 | |
| *** Qiming has joined #senlin | 01:27 | |
| *** elynn__ has joined #senlin | 01:32 | |
| *** elynn_ has quit IRC | 01:35 | |
| *** mathspanda has joined #senlin | 01:54 | |
| openstackgerrit | Qiming Teng proposed stackforge/senlin: Make profile schema versioned https://review.openstack.org/218888 | 01:55 |
|---|---|---|
| *** Yanyanhu has joined #senlin | 01:55 | |
| *** Yanyan has joined #senlin | 01:56 | |
| *** jruano has quit IRC | 01:58 | |
| openstackgerrit | Qiming Teng proposed stackforge/senlin: Sample profiles with type and version keys https://review.openstack.org/219092 | 01:59 |
| *** Yanyanhu has quit IRC | 01:59 | |
| *** branw has joined #senlin | 02:07 | |
| Yanyan | hi, Qiming, are you around | 02:08 |
| Qiming | y | 02:08 |
| Yanyan | just a question want to confirm about the patch of versioned profile | 02:09 |
| Yanyan | so the profile type_name stored in DB will always be in format like type_name-verions | 02:10 |
| Qiming | yes | 02:10 |
| Yanyan | ok, understand | 02:10 |
| Qiming | it will differentiate different versions of types easily | 02:10 |
| Yanyan | since I found in line 212, type keyword argument is always not given | 02:10 |
| Yanyan | ok | 02:10 |
| Yanyan | https://review.openstack.org/#/c/218888/2/senlin/engine/service.py | 02:10 |
| Qiming | the key of this revision is to remove 'type' from parameters, 'type' should be part of the spec | 02:12 |
| Yanyan | yes, this is much better than old design | 02:12 |
| Qiming | then when you do profile creation, you will do 'senlin profile-create -s specfile name' rather than 'senlin profile-create -t os.heat.stack -s specfile name' | 02:13 |
| Qiming | the '-t <type>' doesn't make good sense | 02:13 |
| xuhaiwei | I am still a little confused, in profile_create.json the 'type' should not contain version information? | 02:14 |
| Yanyan | yep | 02:14 |
| xuhaiwei | like os.heat.stack-1.0 | 02:14 |
| Qiming | that will introduce type string parsing problem | 02:15 |
| Yanyan | and not beautiful I think :) | 02:15 |
| Qiming | how do we impose format specifications to the type string? | 02:15 |
| xuhaiwei | but in this file https://review.openstack.org/#/c/218888/2/senlin/engine/service.py line 251, it seems the version is desired in the type | 02:16 |
| xuhaiwei | type_name = db_profile.type.split('-')[0] | 02:17 |
| Qiming | I did think about that alternative, however, I didn't convince myself it is better than separated version | 02:17 |
| Qiming | yes, you will see how much trouble we will be handling there | 02:18 |
| Qiming | a better way is to reparse the spec to get the type_name and version | 02:18 |
| Qiming | if you think that is necessary, I can propose another patch | 02:19 |
| xuhaiwei | I also think we should use the type style like 'os.heat.stack' instead of 'os.heat.stack-1.0', but type_name = db_profile.type.split('-')[0] should be fixed I think | 02:20 |
| Qiming | okay, will do | 02:20 |
| xuhaiwei | another problem is in profile_create_resp.json, we are using os.heat.stack-1.0 | 02:21 |
| Qiming | yes | 02:22 |
| xuhaiwei | this should be fixed too? | 02:23 |
| Qiming | it is part of the response, read-only | 02:23 |
| Qiming | why fix it is necessary? | 02:23 |
| xuhaiwei | oh | 02:23 |
| Qiming | when we are showing something to users, 'typename-version' is more condensed format, right? | 02:23 |
| Qiming | if it is confusing, we can delete it from DB | 02:24 |
| xuhaiwei | ok, agree | 02:24 |
| xuhaiwei | just leave it | 02:24 |
| openstackgerrit | Qiming Teng proposed stackforge/senlin: Make profile schema versioned https://review.openstack.org/218888 | 02:25 |
| xuhaiwei | Qiming, Yanyan, the fix in this patch https://review.openstack.org/218796, I got this error when creating a node ERROR: Unknown exception from SDK: Authentication cannot be scoped to multiple targets. Pick one of: project, domain or trust | 02:26 |
| xuhaiwei | both sdk and senlin are the latest | 02:27 |
| Qiming | but your DB is not up to date | 02:27 |
| xuhaiwei | I should recreate db? | 02:27 |
| *** jruano has joined #senlin | 02:27 | |
| Qiming | the profile records in your db contains bad data | 02:28 |
| Yanyan | em, I think the context property store in DB is old one | 02:28 |
| xuhaiwei | I should recreate profile | 02:28 |
| Qiming | before this patch, 'project_name' and a lot of other data are stored into the 'context' field | 02:28 |
| Yanyan | recreate profile should be able to solve the issue | 02:28 |
| Qiming | right | 02:28 |
| Qiming | there could be other holes when talking about the context | 02:30 |
| Qiming | still working on fixing them | 02:30 |
| *** jruano has quit IRC | 02:33 | |
| *** jruano has joined #senlin | 02:39 | |
| *** lkarm has joined #senlin | 02:41 | |
| *** lkarm has quit IRC | 02:45 | |
| openstackgerrit | Merged stackforge/senlin: Make profile schema versioned https://review.openstack.org/218888 | 03:07 |
| openstackgerrit | xu-haiwei proposed stackforge/senlin: Fix trust-based connection building in policy https://review.openstack.org/219106 | 03:13 |
| *** jruano has quit IRC | 03:19 | |
| openstackgerrit | Qiming Teng proposed stackforge/python-senlinclient: Revise support to profile-create/show https://review.openstack.org/219110 | 03:22 |
| openstackgerrit | Zhenguo Niu proposed stackforge/senlin-dashboard: Add profiles table https://review.openstack.org/219113 | 03:44 |
| openstackgerrit | OpenStack Proposal Bot proposed stackforge/senlin-dashboard: Updated from global requirements https://review.openstack.org/219118 | 04:29 |
| *** lawrancejing has quit IRC | 04:33 | |
| *** yonglihe has joined #senlin | 04:41 | |
| openstackgerrit | Qiming Teng proposed stackforge/python-senlinclient: Revise support to profile-create/show https://review.openstack.org/219110 | 05:38 |
| *** lawrancejing has joined #senlin | 06:00 | |
| openstackgerrit | Qiming Teng proposed stackforge/senlin: Revise doc to reflect latest changes https://review.openstack.org/219147 | 06:04 |
| Qiming | admin__, there? | 06:06 |
| admin__ | Yes | 06:09 |
| Qiming | hi, admin__ | 06:09 |
| Qiming | wondering if there are some placement policy prototypes to work on? | 06:09 |
| admin__ | sure | 06:10 |
| admin__ | VSphereDRS | 06:10 |
| Qiming | okay | 06:11 |
| admin__ | ? | 06:11 |
| admin__ | just let me know youre requirments | 06:12 |
| Qiming | https://etherpad.openstack.org/p/senlin-liberty-workitems | 06:25 |
| Qiming | admin__, I am trying to understand what we can land in the coming days | 06:25 |
| admin__ | okay, we are working across AZ | 06:29 |
| admin__ | will ping you when submit vsphereDRSplacmentPolicy for your rereview | 06:30 |
| Qiming | if the reworking of the heat patch has not started, I can take that over | 06:31 |
| Qiming | if you guys have started, I can shift to something else and jump onto this when there is a patch | 06:32 |
| admin__ | please shift to something else | 06:37 |
| admin__ | we are working on this and will catch up the progress | 06:38 |
| xuhaiwei | Qiming, will you start the test of client? | 06:47 |
| Qiming | okay, xuhaiwei | 06:47 |
| xuhaiwei | I assigned utils to myself, but it's a little difficult to me I think | 06:48 |
| Qiming | right, there are many intricate mockings to be figured out | 06:49 |
| Qiming | another issue related to function is node_update and cluster_update | 06:51 |
| Qiming | they are not implemented yet | 06:51 |
| openstackgerrit | Qiming Teng proposed stackforge/senlin: Fix functional test for policy type listing https://review.openstack.org/219159 | 06:54 |
| *** lkarm has joined #senlin | 06:57 | |
| Yanyan | hi, Qiming, free now? I have a question about current design of some DB APIs | 06:57 |
| Qiming | okay | 06:58 |
| Yanyan | I found we never use session.close() in senlin DB sqlalchemy api | 06:58 |
| Yanyan | we always use session.commit() | 06:58 |
| Yanyan | Is there any special reason for this implementation since I guess in some cases, maybe we should use session.close() | 06:59 |
| Qiming | commit is kind of a close() ? | 06:59 |
| Yanyan | em, commit will save the change but the session is kept if the obj is not gc by python | 06:59 |
| Qiming | Never saw any hints about the transaction problems about commit() | 07:00 |
| Qiming | okay, so you are not talking about the transaction problems | 07:00 |
| Yanyan | yes | 07:01 |
| Qiming | if the question is about whether session is being GC'ed, you can do a close | 07:01 |
| Yanyan | I guess some sessions may not be closed correctly | 07:01 |
| Yanyan | umm, still not very sure about it | 07:01 |
| *** lkarm has quit IRC | 07:01 | |
| Qiming | don't think so | 07:01 |
| Yanyan | but will keep look at it | 07:02 |
| Qiming | so the reference chain is this: action->context->session | 07:02 |
| Qiming | when an action object is not used, python will gc the whole reference chain | 07:02 |
| Yanyan | yes | 07:02 |
| Yanyan | this is what we expected | 07:03 |
| Qiming | unless the action object in memory is not released, e.g. still referenced | 07:03 |
| Yanyan | yes | 07:03 |
| Qiming | however, even in that case, the action is in a zombie status | 07:03 |
| Qiming | it is just a memory usage problem | 07:04 |
| Qiming | it won't cause any concurrency problem | 07:04 |
| Yanyan | but I found use fresh session, module_query of some objects can get correct result | 07:04 |
| Yanyan | but if use old session, it can't | 07:05 |
| Qiming | there caches in memory | 07:05 |
| Qiming | why are you using old session if it is supposed to be abandoned? | 07:05 |
| Yanyan | the old session is taken by context | 07:06 |
| Yanyan | so if we use context to do some db operations, e.g. get, the old session will take effect | 07:06 |
| Qiming | why we are using old context? | 07:07 |
| Yanyan | we always specify context obj for DB operation | 07:08 |
| Yanyan | let me find an example | 07:08 |
| Yanyan | http://git.openstack.org/cgit/stackforge/senlin/tree/senlin/engine/actions/base.py#n324 | 07:08 |
| Qiming | yes | 07:09 |
| Yanyan | e.g. the self.context of action will be used to query an action objet from DB | 07:09 |
| Qiming | where is it called? | 07:09 |
| Yanyan | in wait_for_dependents function http://git.openstack.org/cgit/stackforge/senlin/tree/senlin/engine/actions/cluster_action.py#n59 | 07:11 |
| Yanyan | here | 07:11 |
| Qiming | don't see a problem there | 07:12 |
| Yanyan | yes, this part is ok. What I'm wondering is whether we should close session in some places like this: http://git.openstack.org/cgit/stackforge/senlin/tree/senlin/db/sqlalchemy/api.py#n1237 | 07:12 |
| Qiming | it is a call for the executing action to check its own status | 07:12 |
| Yanyan | or http://git.openstack.org/cgit/stackforge/senlin/tree/senlin/db/sqlalchemy/api.py#n1301 | 07:13 |
| Qiming | we discussed this ... | 07:13 |
| Yanyan | ah... | 07:14 |
| Qiming | commit() is good enough to make sure data are persisted into db, with consistency ensured | 07:14 |
| Qiming | calling close() will not change that fact | 07:14 |
| Yanyan | yes, that's true. The result is stored in DB correctly | 07:14 |
| Qiming | it won't solve concurrency problems | 07:14 |
| Yanyan | but the get API can't fetch the latest result in DB... | 07:14 |
| Yanyan | unless we use a fresh session to perform get operation | 07:14 |
| Qiming | that doesn't make sense | 07:15 |
| Yanyan | yes | 07:15 |
| Qiming | it is against computer science | 07:15 |
| Yanyan | ... | 07:15 |
| Qiming | this is science, not art | 07:15 |
| Yanyan | added log in sqlalchemy API function, and found this issue... | 07:15 |
| Yanyan | the same function, will different session, the return value is different | 07:16 |
| Qiming | the same session wrote some data into db and did a commit | 07:16 |
| Yanyan | and the DB entry has been changed and contains correctly value | 07:16 |
| Qiming | the same session cannot see the result | 07:16 |
| Qiming | the new data can be seen only from a new session? | 07:16 |
| Qiming | that is rediculous | 07:16 |
| Yanyan | I'm also confused about this issue | 07:17 |
| Yanyan | maybe I can show you the result? | 07:17 |
| Qiming | what I do expect from session.close() is that we can save some unused sessions, make them gc'ed as early as possible | 07:18 |
| Qiming | there have been some problems previously, regarding the number of mysql session number | 07:18 |
| Yanyan | if the session was closed after DB writing, this problem didn't happen | 07:18 |
| Qiming | I believe you are looking into a wrong solution | 07:19 |
| Yanyan | yes, understand this limitation | 07:19 |
| Yanyan | actually I haven't found a solution for this issue yet ... Just want to understand why it happen. | 07:20 |
| Qiming | alright | 07:21 |
| Yanyan | I'm now doubting the session close could be the reason, but not sure about it | 07:21 |
| Qiming | let's take a step back | 07:21 |
| Qiming | don't hurry on a "quick" fix | 07:21 |
| Yanyan | sure | 07:21 |
| Qiming | we talked about the "badness" of contexts ... | 07:22 |
| Yanyan | I'm try to read some doc about sesssion obj in python sqlalchmey lib | 07:22 |
| Yanyan | but didn't find a very good document | 07:22 |
| Yanyan | if possible, I think we should use somthing like 'session' obj to access DB | 07:23 |
| Qiming | okay, I don't believe there is concurrency problems in the sqlalchemy lib, maybe that is true | 07:23 |
| Yanyan | we actually don't need entire context, we just need session and some user info like project_id | 07:23 |
| Qiming | but at least it is used by so many projects, I trust its maturity in this field | 07:23 |
| Qiming | yes | 07:24 |
| Yanyan | yes, I think the lib is ok | 07:24 |
| Qiming | that is what I suggest ... take a step back | 07:24 |
| Qiming | we are not seeing this kind of problems besides the action module | 07:24 |
| Qiming | I want to know if we are incorrectly (unnecessarily) deserializing an Action object somewhere | 07:25 |
| Yanyan | since the deserializing of action obj will create a new session? | 07:26 |
| Qiming | when the constructor is invoked, a new context object, thus a new db session, is created. | 07:26 |
| Yanyan | inside a new context | 07:26 |
| Qiming | that will create serious problems, not matter you "close" session of not | 07:26 |
| Qiming | s/of/or/ | 07:26 |
| Yanyan | but since currently only list operation could rely on session to do some special operations | 07:27 |
| Qiming | then we examing action code, whether an action, during its execution, is using some other contexts | 07:27 |
| Yanyan | I guess it's ok for current design? | 07:27 |
| Qiming | for example, oslo_context.get_current() | 07:27 |
| Yanyan | understand what you mean | 07:28 |
| Yanyan | actually just looked through the code of cluster_action and I think the usage of context is correct | 07:28 |
| Yanyan | will further check node_action module | 07:28 |
| Qiming | each action object should strictly work using its own context once initialized | 07:28 |
| Yanyan | yes | 07:28 |
| Qiming | an action may invoke profile code? | 07:29 |
| Yanyan | yes | 07:29 |
| Qiming | and we are creating new instances of RequestContext there? | 07:29 |
| Qiming | is there any missing pieces ? | 07:30 |
| Qiming | oslo_context.get_current() is dangerous | 07:30 |
| Yanyan | hmm, I think we have removed context usage in profile layer except those get_service_context | 07:30 |
| Qiming | if you want to ensure concurrency is solved, you will never create a new RequestContext in your current "thread" | 07:31 |
| Qiming | faint | 07:31 |
| Qiming | get_sevice_context is instantiating a RequestContext instance? | 07:31 |
| Yanyan | nope | 07:31 |
| Yanyan | oslo_context.get_current won't create RequestContext of senlin service I think | 07:32 |
| Yanyan | just oslo's RequestContext | 07:32 |
| Qiming | ... | 07:32 |
| Qiming | you need some lectures on object-oriented design | 07:33 |
| Qiming | :) | 07:33 |
| Yanyan | ah | 07:33 |
| Yanyan | hmm, will read the code about oslo_context.context | 07:34 |
| Qiming | you are never creating a standalone oslo_context.RequestContext object | 07:34 |
| Qiming | all oslo_context.RequestContext objects you created are actually instances of the senlin's RequestContext subclass | 07:35 |
| Yanyan | oh | 07:36 |
| Qiming | in oslo_context code, they can treat these objects as oslo_context.RequestContext, but the nature of those objects won't change | 07:36 |
| Qiming | in parent class you treat an object as Shape | 07:36 |
| Qiming | in child classes you treat them as Rectangle or Triangle | 07:36 |
| Qiming | but there is only one object | 07:37 |
| Qiming | I may be wrong, if that is the case, I have to say "hello, Python, you idiot!" | 07:37 |
| Yanyan | hmm, ok | 07:38 |
| Yanyan | let me go through the code again and make a test about it | 07:38 |
| Qiming | yes, what really matters is we need to be confident that the code structure is 100% correct | 07:44 |
| Qiming | we cannot rely test cases to tell me that | 07:45 |
| Yanyan | yes, definitely | 07:45 |
| Qiming | this is a great opportunity to revisit every single line of the action code | 07:45 |
| Yanyan | Yes, that's right :) | 07:46 |
| Yanyan | and also the DB session | 07:46 |
| Yanyan | at least can help me understand how it work | 07:47 |
| Qiming | regarding the context problem | 07:47 |
| Qiming | you are right, we don't need a traditional "context" at the action layer | 07:47 |
| Yanyan | yes, maybe in some future patches, we should replace it with one or two new objects | 07:49 |
| Qiming | yep | 07:49 |
| Qiming | there are several things we need at the action layer: | 07:50 |
| Qiming | db session, user, project, domain | 07:50 |
| Yanyan | yes | 07:51 |
| Yanyan | oh, understand why the object returned by get_current is a Senlin RequestContext, didn't notice this line http://git.openstack.org/cgit/openstack/oslo.context/tree/oslo_context/context.py#n68 | 07:52 |
| Qiming | there could be problems though | 07:53 |
| Yanyan | and the super() invoking in RequestContext.__init__ in Senlin service | 07:53 |
| Qiming | http://git.openstack.org/cgit/openstack/oslo.context/tree/oslo_context/context.py#n28 | 07:54 |
| Qiming | this context object reference is stored in threading.local(), which is a TLS (thread-local storage) | 07:54 |
| Yanyan | so basically, we only have one current context in all greenthreads? | 07:54 |
| Qiming | I'm not 100% sure it would be eventlet-safe, as it was designed to be "thread-safe" | 07:55 |
| Yanyan | em, seems not eventlet safe | 07:55 |
| Qiming | that is possible | 07:55 |
| Yanyan | this is really dangerous... | 07:56 |
| Qiming | sometimes, it doesn't really matter, sometimes, it does | 07:57 |
| Yanyan | to rely on oslo_context.get_current to get correct context for each greenthread | 07:57 |
| Qiming | this is something we HAVE TO figure out | 07:57 |
| Qiming | when we are sure we have been doing things right, we test if the code behaves as expected | 07:58 |
| Qiming | no the reverse direction | 07:58 |
| Yanyan | ok, let me check the usage of context in the entire workflow to see whether we find some clues | 08:00 |
| *** mathspanda has quit IRC | 08:08 | |
| *** lkarm has joined #senlin | 09:13 | |
| *** lkarm has quit IRC | 09:18 | |
| *** lawrancejing has quit IRC | 09:49 | |
| openstackgerrit | Cindia-blue proposed stackforge/senlin: Add placement policy for vSphere users, which can help control affinity and unti-affinity freely of different nodes/node groups https://review.openstack.org/219212 | 10:07 |
| Qiming | admin__, hi | 10:08 |
| admin__ | hi | 10:10 |
| Qiming | thx for the patch! | 10:11 |
| Qiming | a first glance at it, two problems | 10:11 |
| admin__ | please | 10:12 |
| Qiming | post_op is not needed | 10:12 |
| admin__ | let me know the pobblems | 10:12 |
| admin__ | okay | 10:12 |
| Qiming | a policy only guides the engine to do the work, it doesn't do the dirty work, :) | 10:12 |
| Qiming | another nit is about commit message | 10:13 |
| Qiming | the convention is to have a subject line and one (or more) paragraphs of messages | 10:13 |
| Qiming | the subject line should be no more than 60 characters | 10:14 |
| Qiming | subject line is a text with no teminating period ('.') | 10:14 |
| Qiming | the message paragraph is separated from the subject line with an empty line | 10:15 |
| admin__ | okay | 10:15 |
| Qiming | each line in the message paragraph is no longer than 80 chars | 10:15 |
| Qiming | just some weird tradition | 10:15 |
| Qiming | there is no "why" here , :) | 10:15 |
| Qiming | we just ensure everyone's code looks like being written by another person | 10:16 |
| Qiming | :) | 10:16 |
| admin__ | :) I will follow | 10:16 |
| Qiming | cool, will jump into the details later | 10:17 |
| admin__ | okay | 10:17 |
| Qiming | a good starting point | 10:17 |
| openstackgerrit | Cindia-blue proposed stackforge/senlin: Add a placement-policy to enable DRS functions for vSphere users https://review.openstack.org/219212 | 10:34 |
| openstackgerrit | Cindia-blue proposed stackforge/senlin: Add a placement-policy to enable vSphere DRS functions https://review.openstack.org/219212 | 10:53 |
| *** Yanyan has quit IRC | 10:55 | |
| openstackgerrit | Qiming Teng proposed stackforge/python-senlinclient: Shell unit test (1) https://review.openstack.org/219235 | 11:05 |
| *** Qiming has quit IRC | 11:11 | |
| *** jruano has joined #senlin | 11:26 | |
| openstackgerrit | Merged stackforge/senlin: Fix trust-based connection building in policy https://review.openstack.org/219106 | 11:42 |
| openstackgerrit | Merged stackforge/senlin-dashboard: Add profiles table https://review.openstack.org/219113 | 12:00 |
| *** Qiming has joined #senlin | 12:04 | |
| *** lkarm has joined #senlin | 12:07 | |
| openstackgerrit | Qiming Teng proposed stackforge/python-senlinclient: Shell unit test (1) https://review.openstack.org/219235 | 12:37 |
| *** yanyanhu has joined #senlin | 12:53 | |
| *** xuhaiwei_ has joined #senlin | 12:57 | |
| Qiming | meeting bot is not working? | 13:01 |
| Qiming | canot see a thing there | 13:02 |
| yanyanhu | it works | 13:02 |
| xuhaiwei_ | I saw it works | 13:02 |
| yanyanhu | I can see the topic change in the meeting channel | 13:02 |
| *** LiuWei has quit IRC | 13:10 | |
| Qiming | meeting on #openstack-meeting | 13:29 |
| Qiming | feel free to drop in | 13:29 |
| *** Qiming has quit IRC | 13:30 | |
| *** Qiming has joined #senlin | 13:31 | |
| *** jdandrea has joined #senlin | 13:55 | |
| Qiming | thanks all for attending the meeting | 13:55 |
| *** jruano has quit IRC | 13:55 | |
| yanyanhu | :) | 13:57 |
| yanyanhu | will leave, see U guys tomorrow | 13:58 |
| *** yanyanhu has quit IRC | 13:58 | |
| Qiming | see you | 13:59 |
| *** xuhaiwei_ has quit IRC | 14:01 | |
| *** jroyal has joined #senlin | 14:45 | |
| *** jroyal has quit IRC | 15:03 | |
| *** lkarm has quit IRC | 15:22 | |
| *** lkarm has joined #senlin | 15:22 | |
| *** Qiming has quit IRC | 15:23 | |
| *** zhenguo has quit IRC | 16:00 | |
| *** lkarm has quit IRC | 16:10 | |
| *** lkarm has joined #senlin | 16:11 | |
| *** lkarm has quit IRC | 16:11 | |
| *** lkarm has joined #senlin | 16:11 | |
| *** elynn__ has quit IRC | 16:29 | |
| *** jruano has joined #senlin | 16:39 | |
| *** lkarm_ has joined #senlin | 17:10 | |
| *** lkarm has quit IRC | 17:13 | |
| *** tiantian has joined #senlin | 18:09 | |
| *** huangtianhua has quit IRC | 18:12 | |
| *** jruano has quit IRC | 18:30 | |
| openstackgerrit | OpenStack Proposal Bot proposed stackforge/senlin-dashboard: Updated from global requirements https://review.openstack.org/219118 | 18:56 |
| *** lkarm_ has quit IRC | 21:45 | |
| *** lkarm has joined #senlin | 21:46 | |
| *** lkarm has quit IRC | 21:51 | |
| *** Qiming has joined #senlin | 23:37 | |
| *** Qiming has quit IRC | 23:37 | |
| *** xuhaiwei has quit IRC | 23:38 | |
| *** Qiming has joined #senlin | 23:38 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!