Monday, 2015-07-27

openstackgerritChristopher Aedo proposed stackforge/apps-catalog: Combine multiple YAMLs into single YAML
docaedomarked the single-yaml effort WIP, as I don't have a combined schema that works right yet (I took the easy route with this and left the three types individual, just combined into one file)03:04
docaedoI also have a change pending (WIP) to update the puppet manifest that generates the JSON file on the server:
docaedoFeedback on #205876 welcome - if we should take a more complicated approach (i.e. one single type/schema that can incorporat all of them), let me know03:26
docaedoI won't be around again until Tuesday but will check back here (and of course will be watching email)03:26
*** kebray has joined #openstack-app-catalog04:17
*** kebray has quit IRC07:11
*** kzaitsev_mb has joined #openstack-app-catalog11:52
*** kzaitsev_mb has quit IRC12:14
*** kzaitsev_mb has joined #openstack-app-catalog13:11
kfox1111_docaedo: Yeah, I think I'd prefer the more complicated solution. Because of the way yaml is structured, it becomes much harder for someone to find the right section to add their entry into.15:22
*** kebray has joined #openstack-app-catalog15:33
docaedokfox1111_: that's true. In this case lazy way is no superior - tomorrow I'll learn me some javascript and work out a better solution16:02
kfox1111_maybe a set of small patches will be better...16:04
kfox1111_I found this:16:04
kfox1111_I was thinking, maybe we take that, and start with the glance image schema. move it to common.schema.yaml or something, and split it up to do the common stuff like license, name, etc and a glance specific one. Then, we start trying to apply it to the other yaml files.16:06
kfox1111_Once the other yaml files all validate with the common one, and we merge in the other schama's, then we can pretty easily merge them into one file.16:07
kfox1111_we have to queue up an infrastructure thing to build the common.yaml too.16:07
kfox1111_s/common/entries/ ?16:08
docaedo+1 on smaller steps16:08
docaedoinfra change is in #205882 (that's an easy one)16:08
kfox1111_ah. yeah. perfect.16:09
docaedothat schema example looks useful, thanks :) I'm planning to set aside a few hours tomorrow to take a better shot at this16:09
kfox1111_k. thanks. :)16:09
kfox1111_thinking it would be nice in the end to just have {'assets':[]} or something where there's just one flat list.16:10
kfox1111_that way, if users don't want to care which engine's used for a given app, the ui can present it without any bias.16:11
kfox1111_arg... the gnome screen recorder's broke now on my laptop. can't quickly get a video of the new ui. :/16:11
docaedoTotally agree on that point, and it's exactly where I was thinking we should head with it too.16:11
kfox1111_Ah... think I found a screen recorder that will work...16:20
kfox1111_yup... atempting to upload to youtube...16:23
kfox1111_Done. :)16:29
*** kzaitsev_mb has quit IRC16:50
kfox1111_j^2: That link you sent for ha is interesting. The AWS example is probably a better one to use then the drbd one.16:53
j^2turns out it was the wrong one16:53
kfox1111_in our clouds, we use ceph to back the cinder volumes, so they are already replicated.16:54
j^2i’m buliding HOT for that installation16:54
kfox1111_adding drbd in it makes the replication 4x or greater.16:54
kfox1111_see the topic on it.  Ithink that one's inteneded for physical machines.16:55
kfox1111_but without nova instance users, it can switch over the volume itself. :/16:56
kfox1111_We really need to get ^---- into openstack. :/16:57
j^2ahh yeah16:58
*** kebray has quit IRC18:30
*** kebray has joined #openstack-app-catalog18:46
*** kebray has quit IRC18:51
*** kebray has joined #openstack-app-catalog19:11
j^2docaedo, kfox1111_: i’m ready to add another thing to the assets.yaml, i’m assuming i should wait for: to be merged before proposing?19:50
*** kebray has quit IRC19:56
*** kzaitsev_mb has joined #openstack-app-catalog20:11
*** kebray has joined #openstack-app-catalog20:21
*** kebray has quit IRC20:21
*** kzaitsev_mb has quit IRC20:30
*** kzaitsev_mb has joined #openstack-app-catalog20:31
*** kebray has joined #openstack-app-catalog20:31
*** rhagarty has joined #openstack-app-catalog21:06
rhagartyHello - is a Horizon plug-in appropriate for adding to the OpenStack Community App Catalog?21:07
kfox1111_hmm... thats a very good question...21:25
kfox1111_Ideally we were shooting for things you could as a user load into the cloud to consume.21:26
kfox1111_a user can't plugin a horizon plugin. but an op could.21:27
kfox1111_maybe some kind of tag would be appropriate.21:27
kfox1111_Lets bring that up during the next meeting.21:27
rhagartykfox1111_: thanks for the resply... when are your meetings?22:03
kfox1111_Thursday 10am pdt.22:19
kfox1111_What's your plugin?22:19
rhagartyIt adds a new panel to Horizon, specifically for HP Storage related features. It also adds some new actions for Storage Volumes - users can link directly to HP's Storage Management App22:36
rhagartyclick on Horizon storage volume and see generic Horizon attributes, then link to HP's app and see all the details for that volume22:38
rhagartythe app will be available via GitHub or PyPI, but we were wondering if theres a better/easier place to put this kind of app so that our customers can grab it22:39
rhagartyMurano looked like a good fit, but maybe not...22:40
kfox1111_I think part of the issue we might run into is you can scale up horizon by having multiple nodes run it.22:40
kfox1111_and the plugin would have to be installed on each one.22:40
rhagartyyeah... hadn't thought that through yet, but it should be viable/doable on one node or all nodes22:41
kfox1111_so either horizon needs a config option to tell it to pull a plugin if its not already installed from somewhere, which might make some of the distributors unhappy, or there needs to be some hooks in the deployment scripts like openstack ansible, puppet, etc.22:42
rhagartywas hoping for a more simple use case. User wants it, sees it in a catalog, and deploys it. It's basically installing one library, and adding one line in horizon/local_settings22:44
kfox1111_yeah. as a user, I'd love that...22:44
kfox1111_Most of the time when I've tried that, it hasn't been that simple though. Usually dependencies kill it. :/22:44
j^2kfox1111_: did you see my question earlier about: "i’m ready to add another thing to the assets.yaml, i’m assuming i should wait for: to be merged before proposing?"22:45
kfox1111_usually in the form of, there is no rpm for such and such python module, or pip install foo to get it to work.22:45
rhagartyI've seen other Horizon plug-ins in PyPI, and they all seem content on hoping a user finds their plug-in and then follows the install instructions22:45
kfox1111_j^2: sorry, no.22:45
j^2kfox1111_: noworries22:45
kfox1111_um, go ahead and post the review assuming the assest thing won't go through. we're going to go down a slightly different path.22:46
j^2kfox1111_: kk22:46
kfox1111_we'll probably abandon that one and submit a bunch of smaller patches.22:46
kfox1111_rhagarty: Yeah. :/22:47
rhagartykfox1111_: so hopefully this will be discussed at the next meeting? If so, can I send you some more details?22:48
kfox1111_We've also kind of tossed around the idea of howto's in the catalog. Its a bit out of scope, but if the howto's like, how do you do X in the cloud that can't quite be easily be fully automated, it kind of makes sense.22:48
kfox1111_horizon plugins are kind of similar.22:48
rhagartyagree. the biggest issue for out team is how users would find our app. Really hope we can make it into some catalog listing, even if it's just a description and pointer to our PyPI package22:51
kfox1111_so a tangent...22:52
kfox1111_I assume you have a cinder plugin? is it in tree or external?22:52
rhagartyno cinder plug-in required for this feature. It uses existing cinder API22:52
kfox1111_so it uses cinder's in tree hp driver?22:53
kfox1111_So maybe a pointer in the offical cinder hp driver docs to the horizon plugin would help.22:54
rhagartythat is a good idea22:54
rhagartybut not quite what my boss is looking for :)22:55
kfox1111_sure. just trying to think of ways to get more eyes on it.22:55
kfox1111_is it open sourced?22:56
rhagartyyes, or will be shortly (going through OSRB process)22:56
kfox1111_one possibility then would be to see if the horizon folks would just fold it into horizon itself. If cinder is carrying the code for the driver, it seems possible so would horizon.22:58
rhagartythat's an interesting idea, and I may propose that. But I know they prefer to stay away from vendor specific solutions.22:59
kfox1111_yeah. I could see that. Still, cinder did it, so there's a chance.23:03
rhagartydefinitely worth a discussion...23:03
rhagartynice... thanks for that. And I really appreciate your input.23:05
kfox1111_np. its an interesting issue. It definatly could use some attention. Just not quite sure where it belongs.23:05
openstackgerritJJ Asghar proposed stackforge/apps-catalog: Adding HOT for Chef servers
j^2that was against master23:06
kfox1111_master's the right thing.23:08
j^2there we go23:11
openstackgerritJJ Asghar proposed stackforge/apps-catalog: Adding HOT for Chef servers
kfox1111_j^2, I haven't played with it yet, but there is a flag to make dropdowns out of networks/images for the templates. That might help.23:12
kfox1111_sec. let me see if Ican find an example.23:13
kfox1111_see the glance.image constraint.23:16
kfox1111_looks like there is a one as well.23:18
j^2yeah i’ll get this on for my next iterantion23:20
j^2thanks for the suggestion kfox1111_23:22
kfox1111_looks pretty good. :)23:23
kfox1111_I'd add a security group to the heat templates also, so the user doesn't have to create it themselves.23:23
j^2yeah i really want to automate the whole HA process, but if you’ve looked at the walk through it’s pretty deep23:24
kfox1111_haven't looked too much yet. just giving it the ui sniff test. :)23:25
kfox1111_lookint at the static template source now...23:25
kfox1111_the router/private net seems unneeded. what was the idea there?23:26
kfox1111_oh... it looks like your buiding your own tenant network maybe?23:28
kfox1111_yeah, reading the docs, the firewall stuff is kind of complicated. creating the security groups in the template would really help it not be as complicated.23:39
j^2hmm, i’m not following you 100% on this23:39
kfox1111_ok. so, in most setups, each tenant has their own private network.23:40
kfox1111_as well as a public network.23:40
j^2the idea for the single-stack build was that it would stay on it’s own network and have a floating ip so it wouldnt run into anything you’ve set up already23:40
j^2and on the HA setup you’d need your own network being it’s like 5-6 machines with backend stuff or what not23:40
j^2i created this so it’s something you can just add and not interfere with anything you’ve already created23:41
kfox1111_ok. so what does providing a private network, then hooking it up and making it public buy you?23:41
kfox1111_yeah, a private network for the HA case makes sense.23:41
kfox1111_for the single server case, it burns quota'd things without any benifit I think.23:41
kfox1111_I'd just put it on in the tenant's network.23:42
kfox1111_and then optionally allow it to have a floating ip on the public network.23:42
j^2ok, i’ll see if i can get that to happen23:42
kfox1111_There's an example of a security group in there too.23:43
j^2k, i’ll take a note of this23:43
kfox1111_For the ha version, it would be really nice to remove the lb vm too. but it looks like frontends need multiple ports and that isn't supported in the neutron lbaas until v2, which is experimental until L.23:44
kfox1111_also, rather then abandon,23:46
j^2cool cool, i was thinking of setting up the LB as a ha-proxy box, but yeah i’ll remove it23:46
kfox1111_you should 'git add the files you update', 'git commit --amend' then re 'git review'23:46
kfox1111_it will keep the same review but add a newer version to it.23:46
j^2nice, thanks23:46
kfox1111_one more. you can split the ha heat template up such that the duplicate things each have a nested stack. then put the common stuff in the nested stack.23:48
kfox1111_that way, you don't have to go tweak each copy every time you want to update it.23:48
j^2can you show me an example of that?23:49
kfox1111_yeah, just a sec.23:49
j^2btw, both of these templates were created over the weekend with my first ever shot at HOT23:49
j^2learned and created this over the last 48 hours23:50
kfox1111_no worries. It took me a long time to dig up this much knolege about heat. And there's still a lot I don't know yet. :/23:50
kfox1111_ah. found one.23:52
kfox1111_and nested stack:
kfox1111_yeah, that one's pretty cool. its been a while since I touched that one.23:53
kfox1111_you probably want to copy the Server group thing too. :)23:53
kfox1111_it ensures your nodes land on physically different servers.23:53
j^2yeah that’s over my head23:54
kfox1111_probably want 2. one for the front ends, and one for the backends.23:54
j^2i’ll have to come back to these23:54
kfox1111_let me explain. see the OS::Nova::ServerGroup in the ConfigCluster template?23:55
kfox1111_It makes a ServerGroup with anti-affinity schedualing. That just means the members will be schedualed apart from each other, on physically different machines.23:56
kfox1111_the ID of the server group is passed to the nested template through the param SchedulerGroup23:56
kfox1111_In ConfigSvr,23:56
kfox1111_in the Nova::Server23:57
kfox1111_it has the following:23:57
kfox1111_scheduler_hints: {'group': {Ref: SchedulerGroup} }23:57
kfox1111_thats it. :)23:57
j^2oh interesting23:57
kfox1111_nova takes care of the rest automatically. :)23:58
kfox1111_so if you create 2 ServerGroups, one for frontends, and one for backends, and pass each one to the schedular_hints of each type of server respectively, it will ensure the frontends are on different machines, and the backends are on different machines,23:59
kfox1111_but one frontend and one backend can be on the same machine.23:59

Generated by 2.14.0 by Marius Gedminas - find it at!