| *** wanghao has joined #openstack-zaqar | 00:38 | |
| *** lei-zh has joined #openstack-zaqar | 01:22 | |
| *** wanghao has quit IRC | 01:31 | |
| *** wanghao has joined #openstack-zaqar | 01:32 | |
| *** wanghao_ has joined #openstack-zaqar | 01:37 | |
| *** wanghao_ has quit IRC | 01:37 | |
| *** wanghao_ has joined #openstack-zaqar | 01:38 | |
| *** wanghao has quit IRC | 01:39 | |
| *** wanghao has joined #openstack-zaqar | 01:42 | |
| openstackgerrit | Feilong Wang proposed openstack/zaqar master: Support dead letter queue for MongoDB https://review.openstack.org/333657 | 01:44 |
|---|---|---|
| *** wanghao_ has quit IRC | 01:45 | |
| openstackgerrit | Merged openstack/zaqar master: Fix mongodb list method's param note https://review.openstack.org/484114 | 01:55 |
| *** lhx__ has joined #openstack-zaqar | 02:04 | |
| openstackgerrit | gecong proposed openstack/zaqar master: Fix message claim expires problem in swift storage https://review.openstack.org/484106 | 02:13 |
| wxy | Hi, guys. During reviewing the Swift backend related patches, I found that maybe this function is useless https://github.com/openstack/zaqar/blob/master/zaqar/storage/swift/claims.py#L51-L64 . Any one know where it's used for? | 02:18 |
| *** wxy- has joined #openstack-zaqar | 02:26 | |
| openstackgerrit | gecong proposed openstack/zaqar master: Support dead letter queue for swift https://review.openstack.org/479125 | 02:28 |
| *** wxy- has quit IRC | 02:39 | |
| openstackgerrit | wanghao proposed openstack/zaqar master: Notification Delivery Policy https://review.openstack.org/477724 | 03:22 |
| *** rajathagasthya has joined #openstack-zaqar | 03:47 | |
| *** lei-zh has quit IRC | 04:15 | |
| *** lei-zh has joined #openstack-zaqar | 04:15 | |
| *** lhx__ has quit IRC | 04:28 | |
| *** rajathagasthya has quit IRC | 04:38 | |
| *** lei-zh has quit IRC | 05:25 | |
| *** lei-zh has joined #openstack-zaqar | 05:25 | |
| *** yangzhenyu has quit IRC | 05:46 | |
| openstackgerrit | wanghao proposed openstack/zaqar master: Notification Delivery Policy https://review.openstack.org/477724 | 05:57 |
| *** rcernin_ has joined #openstack-zaqar | 06:00 | |
| *** yangzhenyu has joined #openstack-zaqar | 06:04 | |
| openstackgerrit | gecong proposed openstack/zaqar master: Support dead letter queue for swift https://review.openstack.org/479125 | 06:26 |
| *** yangzhenyu has quit IRC | 07:09 | |
| *** yangzhenyu has joined #openstack-zaqar | 07:22 | |
| *** tesseract has joined #openstack-zaqar | 07:32 | |
| *** lei-zh has quit IRC | 07:40 | |
| *** lei-zh has joined #openstack-zaqar | 07:40 | |
| *** lhx__ has joined #openstack-zaqar | 07:49 | |
| *** yangzhenyu has quit IRC | 08:13 | |
| openstackgerrit | gecong proposed openstack/zaqar master: Support dead letter queue for swift https://review.openstack.org/479125 | 08:17 |
| *** yangzhenyu has joined #openstack-zaqar | 08:33 | |
| *** tesseract has quit IRC | 08:50 | |
| *** tesseract has joined #openstack-zaqar | 08:53 | |
| *** lhx__ has quit IRC | 09:17 | |
| *** wanghao has quit IRC | 09:34 | |
| *** lei-zh has quit IRC | 09:57 | |
| *** lhx__ has joined #openstack-zaqar | 10:05 | |
| *** lhx__ has quit IRC | 12:07 | |
| *** lei-zh has joined #openstack-zaqar | 13:50 | |
| *** zhurong has joined #openstack-zaqar | 13:59 | |
| *** zhurong has quit IRC | 13:59 | |
| *** rajathagasthya has joined #openstack-zaqar | 15:59 | |
| *** lei-zh has quit IRC | 16:00 | |
| *** rajathagasthya has quit IRC | 16:06 | |
| *** rajathagasthya has joined #openstack-zaqar | 16:07 | |
| *** rcernin_ has quit IRC | 16:19 | |
| *** tbarron has joined #openstack-zaqar | 16:46 | |
| tbarron | bear with some naive questions, folks, but I want to check whether | 16:48 |
| tbarron | zaqar experience with "guest agents" may be useful for a problem | 16:49 |
| tbarron | that I have in manila | 16:49 |
| tbarron | my use case is a pair of manila "service VMs" that provide HA for one another, running pcs-corosync | 16:50 |
| tbarron | SVM2 may need to take over for SVM1 and fence it off | 16:51 |
| tbarron | SVM2 needs to "power cycle" SVM1 by getting nova to do the job | 16:51 |
| tbarron | instead of an impmi or drac or whatever | 16:51 |
| tbarron | but of course from OpenStack cloud admin POV SVM2 is "just a tenant VM" and we can't allow tenant VMs to kill one another off | 16:51 |
| tbarron | so I'd like SVM2 to just send a notification to manila (or perhaps someday a VBMC-like-thing) | 16:51 |
| tbarron | manila will check that the fencing request is sane, get admin | 16:51 |
| tbarron | keystone creds and invoke nova apis to get the job done | 16:51 |
| tbarron | all this presupposes that I can run some kind of "guest agent" | 16:51 |
| tbarron | in the SVMs that will enable them to send such notifications w/o | 16:51 |
| tbarron | actually having to run an OpenStack client & have keystone credentials themselves | 16:51 |
| tbarron | <EOF> :D | 16:51 |
| *** harlowja has joined #openstack-zaqar | 17:17 | |
| *** tesseract has quit IRC | 18:01 | |
| *** rcernin has joined #openstack-zaqar | 18:26 | |
| *** tbarron has quit IRC | 19:09 | |
| *** tbarron has joined #openstack-zaqar | 19:11 | |
| *** harlowja has quit IRC | 19:32 | |
| *** boris-42__ has joined #openstack-zaqar | 19:48 | |
| therve | tbarron, Zaqar can be the transport for your notification | 20:36 |
| therve | Though I don't get why it can't be a direct http request | 20:36 |
| tbarron | therve: well maybe it can be direct http request but I was vaguely thinking that zaqar guest agents might | 20:43 |
| therve | tbarron, zaqar doesn't have guest agents | 20:43 |
| tbarron | have some way of carrying an assurance that the request is from whom it appears to be | 20:43 |
| tbarron | therve: ok, there was talk of those once though, right? | 20:43 |
| therve | Maybe, I don't know. Nothing emerged from those talks if they happened | 20:44 |
| therve | Heat for example has agents that can use Zaqar as a transport, is that what you're thinking about? | 20:45 |
| tbarron | therve: I don't care that much about the type of transport, https would be fine probably, | 20:49 |
| tbarron | therve: but if there was a way to stick an "agent" in a guest such that when it posted a notification there was a signature or something that assured me whom it was from | 20:50 |
| tbarron | or if they used some kind of pre-set-up url for that purpose | 20:50 |
| therve | Yeah Zaqar doesn't have anything of that nature. Heat does, though. | 20:51 |
| tbarron | my experience with Heat is pretty much limited to tripleo templates | 20:52 |
| therve | So you got the worst out of it | 20:52 |
| tbarron | so a guest can trigger a workflow in heat that will message/notify back up to a service? | 20:53 |
| tbarron | :D | 20:53 |
| tbarron | therve: rofl (though I do expect that you are totally serious) | 20:53 |
| therve | I have no idea how Manila works, but I guess it talks to Nova directly and does its own orchestration? | 20:53 |
| therve | Heat does stuff that creates a keystone user per Nova server, so that you have dedicated and isolated credentials per node | 20:54 |
| tbarron | therve: yes, manila would just call nova apis directly after interacting with keystone to get auth | 20:54 |
| therve | You could duplicate that mechanism, though it's not simple | 20:54 |
| *** harlowja has joined #openstack-zaqar | 20:56 | |
| tbarron | therve: taking a step back, what I really want is a virtual-machine-power-cycler | 20:56 |
| tbarron | therve: I want to be able to configure a pcs-corosync stonith fencer | 20:57 |
| tbarron | therve: outside a cloud that would be a ipmi or drac or whatever with ssh credentials | 20:57 |
| tbarron | so one member of a HA cluster can fence off another by interacting with the power-cycler | 20:57 |
| tbarron | if my HA cluster consists of guest VMs (compute instances) then I need to call nova to start, down, restart instead of interacting with the power cycler | 20:58 |
| tbarron | but I don't want to actually put nova and keystone clients in these service VMs | 20:59 |
| tbarron | since among other things they run from pre-baked images with very little in the way of dynamic configuration | 20:59 |
| tbarron | just a little bit of cloud-init | 20:59 |
| tbarron | and the security aspects of putting admin credentials for the cloud inside these service VMs seem, umm, considerable | 21:00 |
| tbarron | therve: so i'm just looking for a way for the service VM to notify a more trusted party (manila in this case) who has full nova/keystone client capabilities | 21:01 |
| therve | Yeah there are various ways to do that | 21:01 |
| tbarron | I had read something about zaqar guest agents (in some fable I guess) so was asking here ... | 21:02 |
| therve | The Heat way is to have a specific Keystone domain, and a user per node, and deploying the creds of that user on the node | 21:02 |
| therve | Zaqar has pre signed URLs too, so it can be a more lighweight mechanism, where you create a queue per node | 21:02 |
| tbarron | keystone domain per compute node, or per sguest VM? | 21:02 |
| tbarron | guest | 21:02 |
| tbarron | therve: probably signed URLs were what I was thinking of (dimly) w.r.t. zaqar | 21:03 |
| tbarron | therve: when manila spins up a service vm it might be able to give it some signed URLs to work with ... | 21:04 |
| therve | Yeah probably | 21:05 |
| therve | Got to go, but don't hesitate to send something to the ML | 21:07 |
| tbarron | therve: thanks | 21:11 |
| *** rcernin has quit IRC | 21:33 | |
| openstackgerrit | OpenStack Proposal Bot proposed openstack/zaqar master: Updated from global requirements https://review.openstack.org/478124 | 22:14 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!