| *** tellesnobrega_af is now known as tellesnobrega | 00:02 | |
| *** witlessb has quit IRC | 00:32 | |
| *** egafford has joined #openstack-sahara | 00:43 | |
| *** jinxing has joined #openstack-sahara | 00:46 | |
| *** egafford has quit IRC | 00:49 | |
| *** tellesnobrega is now known as tellesnobrega_af | 00:49 | |
| *** EinstCrazy has joined #openstack-sahara | 02:08 | |
| *** jinxing has quit IRC | 02:26 | |
| *** ViswaV has quit IRC | 04:11 | |
| *** ViswaV has joined #openstack-sahara | 04:15 | |
| *** houming has joined #openstack-sahara | 04:47 | |
| *** hdd has joined #openstack-sahara | 05:36 | |
| *** Poornima has joined #openstack-sahara | 05:49 | |
| *** hdd has quit IRC | 06:06 | |
| *** houming has quit IRC | 06:07 | |
| *** rcernin has joined #openstack-sahara | 06:19 | |
| *** sgotliv has joined #openstack-sahara | 06:25 | |
| *** nkrinner has joined #openstack-sahara | 06:26 | |
| *** houming has joined #openstack-sahara | 06:26 | |
| *** vgridnev has joined #openstack-sahara | 06:54 | |
| *** sgotliv has quit IRC | 07:27 | |
| *** rcernin_ has joined #openstack-sahara | 07:47 | |
| *** tosky has joined #openstack-sahara | 07:50 | |
| *** vgridnev has quit IRC | 08:26 | |
| *** tosky has quit IRC | 08:35 | |
| *** esikachev has joined #openstack-sahara | 08:42 | |
| *** tosky has joined #openstack-sahara | 08:43 | |
| openstackgerrit | Andrey Pavlov proposed openstack/python-saharaclient: Adding ability to get plugin processes via CLI https://review.openstack.org/245674 | 09:07 |
|---|---|---|
| openstackgerrit | Evgeny Sikachev proposed openstack/sahara: [do not review]test commit https://review.openstack.org/249281 | 09:07 |
| *** ViswaV_ has joined #openstack-sahara | 09:08 | |
| *** ViswaV has quit IRC | 09:08 | |
| *** witlessb has joined #openstack-sahara | 09:19 | |
| *** vgridnev has joined #openstack-sahara | 09:31 | |
| *** _degorenko|afk is now known as degorenko | 09:35 | |
| openstackgerrit | Evgeny Sikachev proposed openstack/sahara: [do not review]test commit tempest https://review.openstack.org/249281 | 09:44 |
| *** bapalm has quit IRC | 09:53 | |
| *** bapalm has joined #openstack-sahara | 09:55 | |
| *** rcernin_ has quit IRC | 10:06 | |
| *** sgotliv has joined #openstack-sahara | 10:09 | |
| *** EinstCrazy has quit IRC | 10:13 | |
| *** AndreyPavlov has joined #openstack-sahara | 10:15 | |
| *** ViswaV_ has quit IRC | 10:18 | |
| *** houming has quit IRC | 10:29 | |
| *** AndreyPavlov has quit IRC | 11:15 | |
| *** AndreyPavlov has joined #openstack-sahara | 11:20 | |
| *** tellesnobrega_af is now known as tellesnobrega | 11:28 | |
| openstackgerrit | Evgeny Sikachev proposed openstack/sahara: [do not review]test commit tempest https://review.openstack.org/249281 | 11:30 |
| openstackgerrit | Evgeny Sikachev proposed openstack/sahara: [do not review]test commit https://review.openstack.org/249281 | 11:40 |
| *** jamielennox is now known as jamielennox|away | 11:42 | |
| *** jamielennox|away is now known as jamielennox | 12:01 | |
| *** houming has joined #openstack-sahara | 12:10 | |
| *** raildo-afk is now known as raildo | 12:23 | |
| *** Poornima has quit IRC | 12:43 | |
| *** jinxing has joined #openstack-sahara | 12:57 | |
| *** chlong has joined #openstack-sahara | 13:03 | |
| *** david-lyle has quit IRC | 13:09 | |
| openstackgerrit | Evgeny Sikachev proposed openstack/sahara-ci-config: Update timeout for tempest tests https://review.openstack.org/249770 | 13:12 |
| *** houming has quit IRC | 13:12 | |
| *** crobertsrh1 has joined #openstack-sahara | 13:13 | |
| *** AndreyPavlov has quit IRC | 13:14 | |
| *** AndreyPavlov has joined #openstack-sahara | 13:20 | |
| openstackgerrit | Andrey Pavlov proposed openstack/python-saharaclient: Adding indications of results after delete operations https://review.openstack.org/249784 | 13:36 |
| *** esikachev has quit IRC | 13:41 | |
| openstackgerrit | Andrey Pavlov proposed openstack/python-saharaclient: Adding indications of results after delete operations https://review.openstack.org/249784 | 13:42 |
| *** esikachev has joined #openstack-sahara | 13:47 | |
| *** houming has joined #openstack-sahara | 13:48 | |
| *** crobertsrh1 has quit IRC | 13:57 | |
| *** jinxing has quit IRC | 14:05 | |
| *** openstackgerrit has quit IRC | 14:06 | |
| *** jinxing has joined #openstack-sahara | 14:06 | |
| *** openstackgerrit has joined #openstack-sahara | 14:06 | |
| openstackgerrit | Evgeny Sikachev proposed openstack/sahara: [do not review]test commit tempest https://review.openstack.org/249281 | 14:15 |
| *** rcernin has quit IRC | 14:19 | |
| openstackgerrit | Andrey Pavlov proposed openstack/sahara: Launching 1 instance in grenade instead of 2 https://review.openstack.org/249810 | 14:22 |
| *** tmckay has joined #openstack-sahara | 14:26 | |
| *** egafford has joined #openstack-sahara | 14:30 | |
| egafford | SergeyLukjanov: ping | 14:31 |
| egafford | (If still sick, sorry.) | 14:32 |
| elmiko | can't you just let the man rest! | 14:33 |
| elmiko | ;) | 14:33 |
| egafford | elmiko: He said two days, I waited two days. | 14:34 |
| pino|work | so strict | 14:34 |
| elmiko | ok, then, have at it! | 14:34 |
| egafford | If he's still sick, he can rest; if he's back, I ping. | 14:34 |
| egafford | Images aren't going to generate their own in-service API. | 14:34 |
| elmiko | mr. gafford, one ping only... | 14:34 |
| elmiko | this is true, but it would be cool if they did | 14:35 |
| egafford | elmiko: While you're around, question: have we ever put any thought into using snapshots as our images? | 14:35 |
| elmiko | egafford: iirc, we briefly talked about it, but i don't remember if the talk went anywhere | 14:35 |
| elmiko | it's certainly an interesting idea, from a theoretical standpoint | 14:36 |
| egafford | I've been bopping around different ways to create a build env and modify an image file within that build env (as that's our current tech,) but doing that in Nova is at least as cumbersome as spawning an image, modifying, snapshotting. I'm worried about Ironic from that standpoint, of course; if we went down that road we might hose ourselves there. | 14:36 |
| egafford | It'd also be more cumbersome to generate multiple images in one go with snapshots. | 14:37 |
| egafford | Still, it's an interesting option, and would remove a lot of complexity around the build env. | 14:37 |
| *** tellesnobrega is now known as tellesnobrega_af | 14:38 | |
| elmiko | does snapshotting an image produce a sparse qcow2 or something? | 14:38 |
| egafford | elmiko: I added an "alternative", btw, to the image-elements merge spec suggesting a very different path, in which we never merge SIE, but just do a completely different thing in the SPI r/t idempotent image validation which could grow to replace or complement SIE organically. I actually *prefer* this approach, in many ways; it's sort of a v2 API approach to the problem. :) | 14:40 |
| egafford | elmiko: Still, there seemed to be some real desire to stick with SIE and elements, and my early experiments seem to bear out that using elements as an interface for a different backend is quite possible with a little work. | 14:40 |
| egafford | I might write 2 duelling specs and let the team decide between them. | 14:41 |
| elmiko | cool, i meant to read it again last night, but failed =( | 14:42 |
| egafford | elmiko: I respect that. | 14:42 |
| elmiko | i'll get to it today though | 14:42 |
| egafford | Eh, I don't think I'm going to be able to move in earnest on this stuff until chatting with both Mirantis Sergeys. | 14:42 |
| egafford | s/'m going to be able to/should/, really. | 14:43 |
| openstackgerrit | Evgeny Sikachev proposed openstack/sahara: Fix skiped tempest test https://review.openstack.org/249281 | 14:43 |
| elmiko | egafford: did you see my note in the review about another possible impl, whereby the plugins just generate some sort of config data that an sie-like tool would consume? | 14:43 |
| egafford | I can, I just want to get the team together on direction first, because it's important and I like consensus. | 14:43 |
| elmiko | agreed | 14:44 |
| elmiko | ;) | 14:44 |
| egafford | elmiko: Yeah, that's an interesting option. It doesn't quite build toward the API the same way, but I do like it. | 14:44 |
| *** tellesnobrega_af is now known as tellesnobrega | 14:44 | |
| elmiko | it could still sit at an api endpoint though, so you could automate something whereby the tool would get the config data from a running sahara | 14:45 |
| egafford | If the idea is that all of these ways of structuring image modification scripts are, in fact, reasonably isomorphic, there's no reason not to have the plugins write their own formatted action set, and generate a translation layer. | 14:45 |
| egafford | elmiko: Right, my goal with the API though is to have an API that *actually builds your image*. | 14:45 |
| egafford | This is harder. | 14:46 |
| elmiko | right, i was just thinking of other options because the whole image gen api might become a tangled web. especially for end user who might try to debug it | 14:47 |
| elmiko | although, i do like the possibility of asking sahara to gen an image, and that image gets auto-uploaded to glance/swift/etc... | 14:47 |
| egafford | elmiko: Right, that's exactly the objective. My thinking in the current spec though is that rather than writing a translation layer from some other format, if our contention is that isomorphism will win in the end (so we might as well write our own language or use another) that by the same token, isomorphism will win in the end, so we might as well use what we already have and move incrementally. | 14:48 |
| elmiko | egafford: yea, it's a good thought | 14:50 |
| *** tmckay has quit IRC | 14:50 | |
| egafford | elmiko: Well, I do think that in implementation, it's a cumbersome thought. | 14:50 |
| elmiko | that's kinda why i started thinking about a config file for sie | 14:50 |
| elmiko | it would make it easier to manage image gen. imo | 14:51 |
| pino|work | <elmiko> that's kinda why i started thinking about a config file for sie | 14:51 |
| elmiko | and then those "recipes" could be shared or preserved or whatever.. | 14:51 |
| pino|work | eeeeeeeeeeeeek | 14:51 |
| egafford | pino|work: :) | 14:51 |
| elmiko | pino|work: why is that bad? | 14:52 |
| pino|work | btw https://review.openstack.org/235569 | 14:52 |
| egafford | SIE is already a format for instructions to generate images, and a reasonably sparse one. | 14:52 |
| elmiko | cool, someone else is already thinking about this lol | 14:52 |
| pino|work | (which imho is just juggling around a buggy tool, and putting lipstick on it) | 14:52 |
| egafford | It's weird, and occasionally slightly opinionated, and it has a lot of coupling with its internals where it shouldn't. | 14:53 |
| egafford | But I'm largely with Pino that generating a new isomorphic language to generate SIE elements is dancing around the issue. | 14:53 |
| elmiko | both good points | 14:53 |
| pino|work | yaml is the new xml: praised like the Best Thing Ever™ today, and largely hated in 10 years | 14:54 |
| elmiko | haha! | 14:54 |
| elmiko | in fairness though, yaml is much easier on the eyes than xml | 14:55 |
| egafford | I think we pull SIE into Sahara and use the elements as the basis for clean, idempotent image generation (which will take new work to clean them up so they work that way, and an engine capable of running them on the post-provisioning side,) or we let SIE be SIE and just build something unrelated on the server-side as an image gen/image validation/clean image provisioning package, and expose it when it's ready. | 14:55 |
| tosky | pino|work: yaml AND json | 14:55 |
| egafford | elmiko: ^ | 14:56 |
| openstackgerrit | Evgeny Sikachev proposed openstack/sahara: Fix skiped tempest test https://review.openstack.org/249281 | 14:56 |
| pino|work | tosky: json is a dialect of yaml | 14:56 |
| pino|work | :p | 14:56 |
| *** sgotliv has quit IRC | 14:56 | |
| egafford | pino|work: You're a dialect of yaml. | 14:56 |
| elmiko | egafford: ack, it makes sense. i was just brainstorming other options | 14:56 |
| egafford | elmiko: Totally. | 14:56 |
| pino|work | egafford: i know you know about what i think, but i'll just mention that "elements" and "clean" cannot go in the same sentence | 14:56 |
| egafford | pino|work: So, my thinking on that: there's not THAT much wrong with the element format, itself. | 14:57 |
| egafford | It has phases, it installs packages, it runs scripts. | 14:57 |
| pino|work | egafford: sir, i beg to differ | 14:57 |
| egafford | It does a lot of things that an image gen system ought to do. | 14:57 |
| elmiko | egafford: also, i just have a nagging feeling that if we are going to ask plugin authors to generate a "recipe" for their image generation, then it would be nice to have something more neutral to use as a middle point than a script. but that may not be possible. | 14:57 |
| egafford | pino|work: What do you see as terribly wrong with elements, themselves? Not DIB, and not the mess of envvars that they throw around at each other like crazy people, but just the element format? | 14:59 |
| egafford | I mean, they're not my favorite either, but they do have some nice composability. | 14:59 |
| pino|work | egafford: "jack of all spades, and master of none" | 14:59 |
| pino|work | you can do lots of things with shell scripts... but that's exactly also the biggest problem | 15:00 |
| pino|work | you have no enforcement of any kind on the operations you want to do | 15:00 |
| egafford | pino|work: Sure, that's valid. | 15:01 |
| pino|work | some of the elements are even run on your host, and require root (so put a typo there, and eg your host /dev is gone) | 15:01 |
| *** tellesnobrega is now known as tellesnobrega_af | 15:01 | |
| elmiko | that's one nice thing about hiding image gen behind sahara, we could change to whatever tooling we wanted ;) | 15:01 |
| pino|work | also, your own script could just throw away what a script of a different element (ran earlier) did | 15:01 |
| pino|work | but you have no idea of what scripts in elements do exactly, so it's all like walking on a minefield | 15:02 |
| elmiko | pino|work: all excellent points | 15:03 |
| elmiko | the root thing is definitely scary | 15:03 |
| egafford | pino|work: Well, what you're describing on the other side is dependency encapsulation, which is nice. Except the root and guest/host stuff, which is crazy. | 15:03 |
| pino|work | egafford: yes, but encapsulation in this case is hiding for no good | 15:04 |
| pino|work | image generation should give a well-defined list of operations to do, and you should be able to see each step clearly | 15:04 |
| elmiko | pino|work: so, the whole list of operations should be composed into a single master list (or something)? | 15:05 |
| pino|work | sure, you might want to think "ok, i don't want to be bothered with partitioning", and that'd be fine from a certain POV | 15:05 |
| pino|work | but then you hide more and more stuff, so when things break you have no clue where to start from | 15:05 |
| pino|work | (and i guess on the last sentence you both might agree with me) | 15:05 |
| elmiko | i like the vision you are laying out | 15:06 |
| egafford | pino|work: I'm largely with you here, yeah. | 15:06 |
| egafford | I think elements are ok for spinning an image from nothing, but I do agree with you (completely) that sequential operations are more legible when we don't need to fundamentally change everything about the structure of the image. | 15:08 |
| *** sgotliv has joined #openstack-sahara | 15:09 | |
| pino|work | especially when you want reproduceability (is there such word?) of what you produce | 15:09 |
| pino|work | also, imho separating the image build in two could help: | 15:10 |
| pino|work | - build the base os image (cloud, vm, baremetal, etc) | 15:11 |
| pino|work | - customize the above with the services/tools needed | 15:11 |
| *** poseidon1157 has joined #openstack-sahara | 15:11 | |
| poseidon1157 | Hi all | 15:11 |
| pino|work | usually the 1st is built much less often, so it is a bit easier to build, and to validate that is good | 15:12 |
| poseidon1157 | I'm having some issues with the neutron floatingip pool | 15:12 |
| poseidon1157 | Where is that actually defined? | 15:12 |
| poseidon1157 | The UUID changed necessarily | 15:12 |
| elmiko | poseidon1157: what is the issue you are experiencing? | 15:13 |
| pino|work | poseidon1157: #openstack-neutron maybe? | 15:13 |
| elmiko | pino|work: i like the way you break down the issue, i'm also really curious about the idea of some sort of master list that could show everything that will happen | 15:13 |
| poseidon1157 | Not a neutron issue. :) | 15:14 |
| egafford | pino|work: Yup, with you completely. I'm hoping to just use the product of the first flow you describe. | 15:14 |
| poseidon1157 | Second, going to pull out the actual api error | 15:14 |
| poseidon1157 | reproducing | 15:14 |
| elmiko | poseidon1157: k, thanks | 15:14 |
| pino|work | once the former image is build, adding services is much easier to produce and validate (and less demanding, in term of needed build resources) | 15:14 |
| pino|work | egafford: it's just one actually, just split in two phases | 15:15 |
| poseidon1157 | "2015-11-25 15:15:31.959 21039 ERROR sahara.utils.api [-] Validation Error occurred: error_code=400, error_message=Floating IP pool 8f2efada-c6c7-40d2-8993-34e590d6de18 not found" | 15:15 |
| poseidon1157 | So the UUID, where is that encoded? | 15:15 |
| poseidon1157 | That network no longer exists | 15:16 |
| pino|work | especially that, if you think about it, nowadays the base image is something distros often provide by themselves (hence they ought to take care it is working) | 15:16 |
| elmiko | poseidon1157: when you create node groups, you select a neutron management network, you will most likely need to update your cluster template | 15:16 |
| poseidon1157 | elmiko That's what I was trying to do. floatingips=true in the /etc/sahara conf | 15:16 |
| elmiko | poseidon1157: or check the node group templates that are beeing used | 15:16 |
| poseidon1157 | They both say don't use floating ips | 15:17 |
| egafford | pino|work: Ah, okay, you are agreeing with me, just making an academic (but valid) point about phases. | 15:17 |
| elmiko | poseidon1157: if you have floating_ips=true i don't think you can skip giving those templates floating ip pools | 15:17 |
| poseidon1157 | elmiko So I have to designate that in all node templates? | 15:18 |
| elmiko | poseidon1157: yes | 15:18 |
| poseidon1157 | elmiko Awesome, tyvm | 15:18 |
| elmiko | np, gl =) | 15:18 |
| poseidon1157 | It's silly- Horizon renders an option "Do not assign floating IPs" | 15:19 |
| poseidon1157 | Despite the fact that this is not an option :) | 15:19 |
| elmiko | poseidon1157: yea, that's probably something we should discuss about the proper way forward. i *think* there is a way to configure sahara to have floating_ips=true but not use them. crobertsrh may know a little more | 15:20 |
| pino|work | egafford: yeah, i think we're mostly overlapping in ideas | 15:21 |
| crobertsrh | I'm not entirely sure that option is useful | 15:21 |
| *** tellesnobrega_af is now known as tellesnobrega | 15:21 | |
| elmiko | crobertsrh: the floating_ips option? | 15:21 |
| elmiko | or the "Do not assign..." | 15:22 |
| crobertsrh | yeah...we should probably find a way to hide it when it will just break things | 15:22 |
| elmiko | +1 | 15:22 |
| poseidon1157 | Hmm. I just edited all the node templates. It's still looking for the old uuid | 15:22 |
| poseidon1157 | :/ | 15:22 |
| elmiko | poseidon1157: you probably need to recreate the cluster template after updating the node groups, i've run into that before | 15:23 |
| egafford | pino|work: Okay, writing a competing spec to my own spec. | 15:23 |
| elmiko | egafford: ballsy ;) | 15:23 |
| pino|work | o_O | 15:23 |
| egafford | I want to make both first steps clear and let people decide. | 15:24 |
| pino|work | and there the one going academic was me :D | 15:24 |
| elmiko | haha | 15:24 |
| egafford | Ha! | 15:24 |
| poseidon1157 | elmiko That was it! | 15:25 |
| elmiko | \o/ | 15:25 |
| *** vgridnev has quit IRC | 15:30 | |
| crobertsrh | I plan to fix the need to regenerate a cluster template for this release :) | 15:31 |
| *** chlong has quit IRC | 15:31 | |
| elmiko | crobertsrh: awesome, i was thinking about that the other day when i ran into this | 15:31 |
| crobertsrh | I dream of the fix every time I get hosed by it. | 15:31 |
| elmiko | lol, i'll bet | 15:32 |
| openstackgerrit | Evgeny Sikachev proposed openstack/sahara: Fix skiped tempest test https://review.openstack.org/249281 | 15:32 |
| *** esikachev has quit IRC | 15:33 | |
| openstackgerrit | lu huichun proposed openstack/sahara: No need to check if edp_engine is None when run job https://review.openstack.org/249068 | 15:37 |
| openstackgerrit | Evgeny Sikachev proposed openstack/sahara: Fix skiped tempest test https://review.openstack.org/249281 | 15:37 |
| *** tmckay has joined #openstack-sahara | 15:48 | |
| *** houming has quit IRC | 15:52 | |
| poseidon1157 | Hmm | 15:54 |
| poseidon1157 | New issue deploying cloudera | 15:54 |
| *** houming has joined #openstack-sahara | 15:55 | |
| poseidon1157 | http://pastebin.com/qanK5nTm | 15:55 |
| poseidon1157 | SSL issue | 15:56 |
| elmiko | poseidon1157: interesting, where did you get the cdh image from? | 15:56 |
| poseidon1157 | apps.openstack.org I believe | 15:58 |
| elmiko | hmm | 15:59 |
| elmiko | could be an error with the images we've generated | 15:59 |
| pino|work | http://i.imgur.com/iWKad22.jpg | 15:59 |
| * elmiko chuckles | 16:00 | |
| poseidon1157 | Just had a failure with the vanilla image as well. | 16:00 |
| elmiko | poseidon1157: same error? | 16:00 |
| poseidon1157 | http://pastebin.com/J5fGXkjW | 16:00 |
| poseidon1157 | Different error | 16:00 |
| crobertsrh | Hmm, different, but somehow suspiciously similar....missing expected files | 16:01 |
| poseidon1157 | Directory in the latter case | 16:01 |
| elmiko | yea | 16:02 |
| elmiko | the cdh error makes me wonder if the online image is not fresh enough, that ssl cert stuff was only added in august of this year | 16:02 |
| crobertsrh | fine idea | 16:03 |
| elmiko | in the latter case, i haven't seen it fail to move the workflow file | 16:03 |
| elmiko | poseidon1157: is that second error reproduceable? | 16:03 |
| poseidon1157 | elmiko Let me check | 16:06 |
| *** jinxing has quit IRC | 16:06 | |
| poseidon1157 | Yes, reproducable | 16:13 |
| openstackgerrit | Andrey Pavlov proposed openstack/sahara: Launching 1 instance in grenade instead of 2 https://review.openstack.org/249810 | 16:13 |
| *** tellesnobrega is now known as tellesnobrega_af | 16:13 | |
| openstackgerrit | Javier Peña proposed openstack/puppet-sahara: Support of PyMySQL driver for MySQL backend https://review.openstack.org/245265 | 16:14 |
| poseidon1157 | sahara-kilo-vanilla-1-centos-6.6.qcow2 md5 f7309dcfc6276625f6664dc42bd8b71b | 16:15 |
| elmiko | hmm | 16:15 |
| elmiko | poseidon1157: and you are using the vanilla 1.x series plugin? | 16:16 |
| pino|work | isn't that deprecated? | 16:16 |
| elmiko | yea | 16:16 |
| poseidon1157 | 2.6 | 16:16 |
| poseidon1157 | Image marked for 2.6.0 | 16:16 |
| elmiko | ok, 2.6 is also deprecated, but not in kilo | 16:16 |
| elmiko | poseidon1157: you probably want to try this image, http://sahara-files.mirantis.com/images/upstream/kilo/sahara-kilo-vanilla-2.6-centos-6.6.qcow2 | 16:17 |
| openstackgerrit | Javier Peña proposed openstack/puppet-sahara: Support of PyMySQL driver for MySQL backend https://review.openstack.org/245265 | 16:19 |
| openstackgerrit | Javier Peña proposed openstack/puppet-sahara: Support of PyMySQL driver for MySQL backend https://review.openstack.org/245265 | 16:21 |
| *** AndreyPavlov has quit IRC | 16:25 | |
| *** vgridnev has joined #openstack-sahara | 16:28 | |
| *** houming has quit IRC | 16:37 | |
| openstackgerrit | Merged openstack/sahara: cleanup sahara commands https://review.openstack.org/246939 | 16:44 |
| *** ViswaV has joined #openstack-sahara | 16:48 | |
| poseidon1157 | Reproducible under new image as well | 16:49 |
| poseidon1157 | http://pastebin.com/3743MH0c | 16:49 |
| *** tosky has quit IRC | 16:51 | |
| *** ViswaV has quit IRC | 16:53 | |
| *** ViswaV has joined #openstack-sahara | 16:53 | |
| *** hdd has joined #openstack-sahara | 16:54 | |
| poseidon1157 | These images are missing keytool? | 17:02 |
| poseidon1157 | Hmm- well looks like CentOS has been neglected :) | 17:06 |
| poseidon1157 | I'll just use the ubuntu images | 17:06 |
| *** AndreyPavlov has joined #openstack-sahara | 17:08 | |
| openstackgerrit | Merged openstack/sahara: Update scenario test readme file https://review.openstack.org/248841 | 17:09 |
| *** houming has joined #openstack-sahara | 17:10 | |
| *** tellesnobrega_af is now known as tellesnobrega | 17:11 | |
| openstackgerrit | Merged openstack/python-saharaclient: Adding ability to provide name or ID of the flavor in CLI https://review.openstack.org/245692 | 17:20 |
| *** david-lyle has joined #openstack-sahara | 17:30 | |
| *** nkrinner has quit IRC | 17:30 | |
| *** raildo is now known as raildo-afk | 17:38 | |
| *** degorenko is now known as _degorenko|afk | 17:39 | |
| *** raildo-afk is now known as raildo | 17:39 | |
| *** david-lyle has quit IRC | 18:00 | |
| *** david-lyle has joined #openstack-sahara | 18:20 | |
| openstackgerrit | lu huichun proposed openstack/sahara: Check cluster if it is None before run job https://review.openstack.org/249068 | 18:22 |
| *** hdd has quit IRC | 18:22 | |
| *** hdd has joined #openstack-sahara | 18:26 | |
| *** vgridnev has quit IRC | 18:29 | |
| *** AndreyPavlov has quit IRC | 18:40 | |
| *** houming has quit IRC | 18:46 | |
| *** sgotliv has quit IRC | 18:49 | |
| *** vgridnev has joined #openstack-sahara | 18:56 | |
| *** stanchan has joined #openstack-sahara | 19:05 | |
| *** barra204 is now known as shakamunyi | 19:12 | |
| *** tellesnobrega is now known as tellesnobrega_af | 19:44 | |
| *** crobertsrh has quit IRC | 20:00 | |
| *** crobertsrh has joined #openstack-sahara | 20:09 | |
| elmiko | egafford: would you be opposed to adding a cli target to sahara with the sie changes that would still allow for offline creation of images? | 20:30 |
| egafford | elmiko: The current spec adds the sahara-image-elements CLI to Sahara directly. Are you imagining a separate CLI wrapper? | 20:32 |
| elmiko | egafford: maybe i'm just misunderstanding, would i still be able to invoke diskimage-create or similar? | 20:34 |
| egafford | With the spec currently up in sahara-specs, you'd actually be able to invoke the sahara-image-elements scripts exactly as they are now. | 20:35 |
| elmiko | ok, cool. just my misunderstanding | 20:35 |
| elmiko | thanks | 20:35 |
| egafford | The spec I put up just moves plugin-specific element code into the plugins themselves, and thus into the sahara repository. | 20:35 |
| elmiko | yea | 20:35 |
| egafford | After that move, we can get fancier about building alternative ways to create images (via an API.) | 20:36 |
| elmiko | cool, i re-read it, but it does take some thinking to unpack all the ideas | 20:36 |
| egafford | Or, as you noted, we can NOT do any of that, and just build a parallel means to pack and verify images into a new API (with some kind of yaml-based definition of how to modify them.) | 20:38 |
| egafford | I'm actually partial to option 2: it's kind of the v2 API approach (build it in the background, push it when it's done, leave the old stuff until then.) | 20:38 |
| elmiko | i think pino|work convinced me that path is not ideal | 20:38 |
| elmiko | wait, option 2 from the spec? | 20:38 |
| egafford | I list it under "alternatives". | 20:39 |
| elmiko | ok, yea | 20:39 |
| egafford | The spec details only one option. | 20:39 |
| egafford | But it does list "don't move anything, build something new into Sahara" as an alternative. | 20:39 |
| elmiko | right | 20:39 |
| egafford | I posted the spec this way to avoid reinventing the wheel; to take where we are and start moving it toward one solution for offline packing, (new) in-service packing, image validation, and clean image provisioning. | 20:41 |
| elmiko | yea, i just need to think about this more. sorry, but i removed my +1, i like the idea but i want to think about the options more. | 20:42 |
| egafford | But I can definitely see arguments against this approach (the main argument being that elements aren't the most readable way to describe a process.) Okay, that's fine. | 20:42 |
| egafford | What are you thinking would be better right now? | 20:42 |
| elmiko | are we talking "pie in the sky whatever mike wants" ? | 20:43 |
| egafford | No, sadly we're specifically not. :) | 20:43 |
| elmiko | damnit.. | 20:43 |
| elmiko | well, i like the idea of moving this stuff into the plugins. that makes sense to me | 20:43 |
| egafford | I've spent a bit of time thinking about what The Best Thing would be, and then thinking about How To Get There. | 20:43 |
| egafford | The second part is the hardest, by a lot. | 20:44 |
| elmiko | i'm stuck on the idea of moving all the elements into the source tree, it smells slightly off to me | 20:44 |
| egafford | Well, I think we need to move *something* that describes the image gen process into the source tree. | 20:44 |
| egafford | It doesn't have to be elements. | 20:44 |
| elmiko | something that pino|work said earlier caught my attention too, namely the idea of being able to see all the steps for creating any given image. i'm not sure how we utilize that, but i like the concept. | 20:45 |
| egafford | But if it's not elements, we're reinventing our own wheel. | 20:45 |
| elmiko | yea, exactly. | 20:45 |
| egafford | Yeah, that's simple enough. And as noted, I'm happy to reinvent that wheel if we as a team think we should. :) | 20:45 |
| egafford | I just tend to default to incrementalism and toward forcing change. | 20:45 |
| egafford | Hence this spec. | 20:46 |
| elmiko | it's a very sensible approach | 20:46 |
| elmiko | and i don't disagree with it | 20:46 |
| egafford | Thanks for your thoughts on it; it's really much appreciated. | 20:46 |
| egafford | Well; I don't know if it's the best approach. I'd be SUPER HAPPY to write some kind of linear manifest: install these packages, run this script, win. | 20:46 |
| egafford | I think that would be a better approach, in the long run. | 20:47 |
| elmiko | i'm just thinking about us agregating the elements into sahara, and then enabling the plugin authors to use the elements to compose an image (like we do now) | 20:47 |
| egafford | As a desirable plan, or as something that will drive sane men mad? | 20:47 |
| elmiko | lol | 20:48 |
| egafford | My current spec does allow for common, shared elements to be outside of plugins themselves. | 20:48 |
| elmiko | yea, i like that | 20:48 |
| elmiko | i know this isn't in the spec, just curious, do you envision the early version of this just calling out to diskimage-create with whatever options the plugin author desires? | 20:49 |
| egafford | Yup. | 20:49 |
| egafford | Probably in a nova-spawned build host. | 20:49 |
| egafford | Spawn host, pull base image from glance, run diskimage-create, rock out. | 20:50 |
| egafford | Upload to glance before or after rocking out, at plugin author's preference. | 20:50 |
| elmiko | i guess my only qualm is that it seems kinda heavy weight to need an entire stack running to gen. images, but i guess if you are planning on using them you will need a stack anyways... | 20:50 |
| egafford | Right, the problem right now is that we're thinking "this is heavyweight, you don't need all that to pack an image." True! However, a new POC user coming in will have a stack, by definition. | 20:51 |
| elmiko | right | 20:52 |
| egafford | Also, once we have an API that Just Builds Images, then it's an API: it's an interface. If we can abstract away the actual, under-the-hood generation process and engine, then we can swap it out much more at-will. | 20:52 |
| elmiko | true | 20:52 |
| *** vgridnev has quit IRC | 20:52 | |
| egafford | And right now, image gen is tricky, and often fails because people don't have clean envs. | 20:52 |
| egafford | It's much easier for us to spawn people a clean env; that's what OpenStack does. | 20:53 |
| egafford | As a note, I want to make it absolutely clear that I understand and agree with your smell concerns. | 20:53 |
| egafford | I had them too until I poked down a lot of other options, and can be convinced that we should just build something new for this case (which might, in time, remove the need for SIE as a repo.) | 20:54 |
| elmiko | agreed, it's reasonable too | 20:55 |
| elmiko | the whole "build your image in the cloud" is a nice thought too | 20:55 |
| egafford | Yeah, that's the big goal and the big UX win. | 20:55 |
| elmiko | ok, i'll read it again with a mind towards pointing out areas that could use more definition | 20:56 |
| elmiko | talking it through with you definitely helps sell the case, but i feel that i lost something from just reading the spec | 20:56 |
| openstackgerrit | Emilien Macchi proposed openstack/puppet-sahara: release: prepare 7.0.0 (liberty) https://review.openstack.org/250021 | 20:56 |
| egafford | Once we have a stable API and SPI for image gen, then plugin authors can use whatever image gen tech they want under the hood, too; wrapping an interface around it gives us a lot of ability to move. | 20:57 |
| elmiko | true, but it will add complexity to debugging image gen | 20:57 |
| egafford | Well, part of the problem is that the spec here is only step 1, but I want to talk to Sergey L before posting spec 2, and I don't want to create a strict dependency on spec 2. | 20:57 |
| elmiko | understandable | 20:57 |
| egafford | Well, hopefully it'll also make it a bit stabler, but I take your point. | 20:58 |
| egafford | I don't advocate removing the sahara-image-elements scripts anytime soon. | 20:58 |
| elmiko | agreed, i think it will make it more stable | 20:58 |
| egafford | (Or, maybe, at all; having a CLI is handy. | 20:58 |
| egafford | ) | 20:58 |
| elmiko | so, here's my crazy thought (of the moment) | 20:59 |
| egafford | K | 20:59 |
| elmiko | i can see this being a higher order openstack application | 20:59 |
| elmiko | for example, | 20:59 |
| egafford | Ha! | 20:59 |
| egafford | Yeah, me too. | 20:59 |
| elmiko | you create an app that uses novaclient and saharaclient to spawn a vm, then gain the image gen specifics from sahara, and finally use the vm to gen the image | 21:00 |
| egafford | So my problem with that is that if we wait on an image-packing service as a standalone entity to mature, we'll be here all day. | 21:00 |
| elmiko | possibly including swiftclient or glanceclient to manage the image | 21:00 |
| elmiko | right, but it doesn't need to be part of the sahara service | 21:00 |
| egafford | Yeah, I agree that an OpenStack in-cloud image packer service would be awesome. | 21:00 |
| elmiko | it could just be that when i hit some endpoint in sahara, it returns the current sie script specifically setup to gen the image i'd like, then this image-gen app just uploads that script to the vm and builds the image | 21:01 |
| egafford | That's true; I think it should be part of *a* service, though; otherwise we can't wrap it up in a pretty OpenStack API and UI. | 21:01 |
| elmiko | i'm not seeing the win in having it all be contained in sahara | 21:01 |
| egafford | The win in having it be in Sahara is that we can put a big old "generate image" button in our UI. | 21:02 |
| elmiko | we could do that regardless of having it in sahara | 21:02 |
| egafford | If we're willing to depend on some nascent service that doesn't exist yet, then yes. | 21:02 |
| elmiko | and we could still migrate the image gen bits into the plugins | 21:03 |
| egafford | To be clear, I would hope that this piece does eventually become stable enough and cleanly separated enough to spin out. | 21:03 |
| elmiko | i'm not convinced that it would need to be some large service project that exists as a server/db/etc... | 21:03 |
| egafford | I've mentioned wanting an image generation service for a while really. Well, it needs a server, for sure; it'd likely need a DB to store statuses of ongoing builds, at least. | 21:04 |
| egafford | Again, this is the incremental approach. | 21:04 |
| elmiko | it could have all that, but not needed | 21:04 |
| egafford | There are problems with the incremental approach, for sure. | 21:04 |
| *** vgridnev has joined #openstack-sahara | 21:04 | |
| elmiko | yea, i'm thinking more of an app that would consume openstack instead of providing a new service | 21:05 |
| egafford | Then we can't wrap it into the OpenStack user flow, and it has to be a specialist tool. That's not necessarily the end of the world, but it's true. | 21:05 |
| elmiko | i'm not 100% on board with that thought, but i get your point | 21:06 |
| elmiko | with all that said though, i'm ok with the general idea you are proposing | 21:08 |
| egafford | I think we're haggling between our engineering drive to separate concerns and our desire to give our users a clean and clear experience. | 21:08 |
| elmiko | heh, probably ;) | 21:08 |
| egafford | In the end, I *dont* see image packing as foreign to Sahara. | 21:08 |
| elmiko | as long as it ends with a big "gen image" button, the impl can change over time | 21:08 |
| crobertsrh | egafford, my fellow pycharmer. Have you debugged sahara-all via pycharm recently? | 21:09 |
| egafford | I think we think it's foreign to Sahara because it always has been. Right, exaclty. :) | 21:09 |
| crobertsrh | In particular since "Use oslo.service for launching sahara" merged? | 21:09 |
| elmiko | yea, given the tight coupling between plugin and image, then yea it shouldn't be foreign to sahara | 21:10 |
| egafford | sahara-image-elements is a vital part of the application, unless everyone downloads our pre-packed images and SIE is just an internal RE tool. | 21:10 |
| egafford | Yup, that's this initiative's basic argument. :) And again, your points are sane and valid, though I don't think we should go the separate-application route. We have a separate application, it's called SIE; integration or bust. | 21:11 |
| egafford | :) | 21:11 |
| egafford | crobertsrh: I don't think I have. I'm assuming everything is explodey? | 21:11 |
| *** raildo is now known as raildo-afk | 21:11 | |
| crobertsrh | I think it may be. | 21:12 |
| crobertsrh | Not as much explodey, but just unresponsivey | 21:12 |
| elmiko | egafford: fair, and i don't want to stand in the way of that. my knee-jerk reaction is based on the growing complexity of sahara versus my internal desire for smaller simpler tools =) | 21:12 |
| egafford | Sure, sure. | 21:13 |
| elmiko | especially given that openstack is looking more and more like an operating system | 21:13 |
| egafford | Happily, I think we can keep this stuff off to the side, or at least fully in its own SPI methods. | 21:13 |
| elmiko | in terms of data separation yes, but once we start handling the other openstack services (eg creating/managing images through nova) it will get messy | 21:14 |
| egafford | Sure, but if we don't do it, then n of our users have to figure it out themselves at the point when they're most likely to stop using our service. | 21:15 |
| elmiko | no argument there | 21:16 |
| elmiko | i think we both agree that image gen is a ux weak spot at this point | 21:16 |
| *** sgotliv has joined #openstack-sahara | 21:16 | |
| egafford | Anyway, please do leave any requests for clarification you like. | 21:16 |
| elmiko | i will, thanks for the extended discussion =) | 21:16 |
| egafford | And understand that all of your criticisms of the plan are valid; I still think this probably is the sanest way forward, but I agree it's a little wonky at first glance. | 21:17 |
| elmiko | you are most likely correct about it being the sanest way forward, my mind tends to wander when we throw the doors wide open ;) | 21:18 |
| elmiko | and yea, let's get buy-in to work on an image gen service for openstack | 21:19 |
| egafford | Oh, mine too., | 21:19 |
| elmiko | haha | 21:19 |
| egafford | Hey, it's not a bad plan. | 21:19 |
| elmiko | definitely not | 21:19 |
| *** poseidon11571 has joined #openstack-sahara | 21:20 | |
| *** poseidon11571 has quit IRC | 21:20 | |
| *** poseidon1157 has quit IRC | 21:23 | |
| crobertsrh | Hmm, yep. Looks like I may need some bonus pycharm love in order to work with the oslo.service launching. In the meantime, if I undo that patch, things seem to be fine for me again. | 21:28 |
| crobertsrh | egafford: If pycharm debugging does still magically work for you against master, I'll be interested in your debug config. | 21:35 |
| *** openstackgerrit has quit IRC | 21:36 | |
| *** openstackgerrit has joined #openstack-sahara | 21:36 | |
| *** vgridnev has quit IRC | 21:51 | |
| egafford | crobertsrh: I fear that at the moment I don't have a meaningful env for master. Much stable and forked work atm. | 21:52 |
| crobertsrh | No problem. More of a heads-up than a plea for help. | 21:53 |
| egafford | crobertsrh: Is it not responding AT ALL, like the service isn't even giving you output? | 21:53 |
| egafford | Appreciated then. :) | 21:53 |
| crobertsrh | It appears to start-up just fine, but doesn't seem to do anything when I hit it with a request | 21:54 |
| crobertsrh | even if I just curl the base service URL, it normally will reject me because I have no auth, but in the post oslo.service world, it just hangs | 21:54 |
| elmiko | weird | 21:54 |
| crobertsrh | same for any actual requests that try to hit it | 21:54 |
| crobertsrh | If I run without debugging turned on, things are fine | 21:55 |
| elmiko | maybe pycharm is preventing some thread from starting? | 21:55 |
| crobertsrh | Totally unsure | 21:56 |
| crobertsrh | My "fix" is to revert the patch locally for now. | 21:56 |
| elmiko | ooph, that stinks | 21:56 |
| crobertsrh | I've also pinged #os-oslo in case there is any sort of known issue at work | 21:56 |
| elmiko | good thinking | 21:56 |
| crobertsrh | Or, I suppose it's possible that I'll be the only special one with an issue | 21:57 |
| crobertsrh | I'm hoping for a mystery config in pycharm, but it will have to wait until after the holiday, I suspect. | 21:58 |
| crobertsrh | Have a fun holiday. I'm outta here | 21:58 |
| *** crobertsrh is now known as _crobertsrh | 21:58 | |
| *** tmckay has left #openstack-sahara | 22:34 | |
| *** david-lyle has quit IRC | 22:34 | |
| *** stanchan has quit IRC | 22:59 | |
| *** tellesnobrega_af is now known as tellesnobrega | 23:05 | |
| *** david-lyle has joined #openstack-sahara | 23:07 | |
| *** hdd has quit IRC | 23:14 | |
| *** david-lyle has quit IRC | 23:24 | |
| *** sgotliv has quit IRC | 23:52 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!
