| openstackgerrit | Christopher Aedo proposed stackforge/apps-catalog: Combine multiple YAMLs into single YAML https://review.openstack.org/205876 | 02:57 |
|---|---|---|
| docaedo | marked 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 |
| docaedo | I also have a change pending (WIP) to update the puppet manifest that generates the JSON file on the server: https://review.openstack.org/#/c/205882/ | 03:22 |
| docaedo | Feedback 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 know | 03:26 |
| docaedo | I 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-catalog | 04:17 | |
| *** kebray has quit IRC | 07:11 | |
| *** kzaitsev_mb has joined #openstack-app-catalog | 11:52 | |
| *** kzaitsev_mb has quit IRC | 12:14 | |
| *** kzaitsev_mb has joined #openstack-app-catalog | 13: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-catalog | 15:33 | |
| docaedo | kfox1111_: that's true. In this case lazy way is no superior - tomorrow I'll learn me some javascript and work out a better solution | 16:02 |
| kfox1111_ | maybe a set of small patches will be better... | 16:04 |
| kfox1111_ | I found this: | 16:04 |
| kfox1111_ | http://json-schema.org/example2.html | 16:05 |
| 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 steps | 16:08 |
| docaedo | infra change is in #205882 (that's an easy one) | 16:08 |
| kfox1111_ | ah. yeah. perfect. | 16:09 |
| docaedo | that schema example looks useful, thanks :) I'm planning to set aside a few hours tomorrow to take a better shot at this | 16: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 |
| docaedo | Totally agree on that point, and it's exactly where I was thinking we should head with it too. | 16:11 |
| kfox1111_ | kk. | 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. https://youtu.be/9TlPhmml-T8 :) | 16:29 |
| *** kzaitsev_mb has quit IRC | 16: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^2 | turns out it was the wrong one | 16:53 |
| j^2 | http://docs.chef.io/install_server_ha_drbd.html | 16:54 |
| kfox1111_ | in our clouds, we use ceph to back the cinder volumes, so they are already replicated. | 16:54 |
| j^2 | i’m buliding HOT for that installation | 16: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_ | oh... | 16:56 |
| kfox1111_ | but without nova instance users, it can switch over the volume itself. :/ | 16:56 |
| kfox1111_ | https://review.openstack.org/#/c/186617/ | 16:56 |
| kfox1111_ | We really need to get ^---- into openstack. :/ | 16:57 |
| j^2 | ahh yeah | 16:58 |
| *** kebray has quit IRC | 18:30 | |
| *** kebray has joined #openstack-app-catalog | 18:46 | |
| *** kebray has quit IRC | 18:51 | |
| *** kebray has joined #openstack-app-catalog | 19:11 | |
| j^2 | docaedo, kfox1111_: i’m ready to add another thing to the assets.yaml, i’m assuming i should wait for: https://review.openstack.org/#/c/205876/ to be merged before proposing? | 19:50 |
| *** kebray has quit IRC | 19:56 | |
| *** kzaitsev_mb has joined #openstack-app-catalog | 20:11 | |
| *** kebray has joined #openstack-app-catalog | 20:21 | |
| *** kebray has quit IRC | 20:21 | |
| *** kzaitsev_mb has quit IRC | 20:30 | |
| *** kzaitsev_mb has joined #openstack-app-catalog | 20:31 | |
| *** kebray has joined #openstack-app-catalog | 20:31 | |
| *** rhagarty has joined #openstack-app-catalog | 21:06 | |
| rhagarty | Hello - 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 |
| rhagarty | kfox1111_: thanks for the resply... when are your meetings? | 22:03 |
| kfox1111_ | Thursday 10am pdt. | 22:19 |
| kfox1111_ | What's your plugin? | 22:19 |
| rhagarty | It 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 App | 22:36 |
| kfox1111_ | cool. | 22:37 |
| rhagarty | click on Horizon storage volume and see generic Horizon attributes, then link to HP's app and see all the details for that volume | 22:38 |
| rhagarty | the 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 it | 22:39 |
| kfox1111_ | yeah... | 22:40 |
| rhagarty | Murano 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 |
| rhagarty | yeah... hadn't thought that through yet, but it should be viable/doable on one node or all nodes | 22: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 |
| rhagarty | was 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_settings | 22: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^2 | kfox1111_: 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: https://review.openstack.org/#/c/205876/ 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 |
| rhagarty | I'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 instructions | 22:45 |
| kfox1111_ | j^2: sorry, no. | 22:45 |
| j^2 | kfox1111_: noworries | 22: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^2 | kfox1111_: kk | 22:46 |
| kfox1111_ | we'll probably abandon that one and submit a bunch of smaller patches. | 22:46 |
| kfox1111_ | rhagarty: Yeah. :/ | 22:47 |
| rhagarty | kfox1111_: 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 |
| rhagarty | agree. 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 package | 22:51 |
| kfox1111_ | so a tangent... | 22:52 |
| kfox1111_ | I assume you have a cinder plugin? is it in tree or external? | 22:52 |
| rhagarty | no cinder plug-in required for this feature. It uses existing cinder API | 22:52 |
| kfox1111_ | so it uses cinder's in tree hp driver? | 22:53 |
| rhagarty | yes | 22:53 |
| kfox1111_ | So maybe a pointer in the offical cinder hp driver docs to the horizon plugin would help. | 22:54 |
| rhagarty | that is a good idea | 22:54 |
| rhagarty | but 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 |
| rhagarty | yes, 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 |
| rhagarty | that'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 |
| rhagarty | definitely worth a discussion... | 23:03 |
| kfox1111_ | https://wiki.openstack.org/wiki/Meetings/app-catalog#Proposed_Agenda_for_July_30th.2C_2015_.281700_UTC.29 | 23:03 |
| rhagarty | nice... 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 |
| rhagarty | agree | 23:06 |
| openstackgerrit | JJ Asghar proposed stackforge/apps-catalog: Adding HOT for Chef servers https://review.openstack.org/206254 | 23:06 |
| j^2 | crap | 23:06 |
| j^2 | that was against master | 23:06 |
| j^2 | sorry | 23:06 |
| kfox1111_ | master's the right thing. | 23:08 |
| j^2 | there we go | 23:11 |
| openstackgerrit | JJ Asghar proposed stackforge/apps-catalog: Adding HOT for Chef servers https://review.openstack.org/206255 | 23:11 |
| 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 |
| j^2 | ? | 23:12 |
| kfox1111_ | sec. let me see if Ican find an example. | 23:13 |
| j^2 | kk | 23:13 |
| kfox1111_ | https://github.com/openstack/heat-templates/blob/master/hot/vm_with_cinder.yaml | 23:15 |
| kfox1111_ | see the glance.image constraint. | 23:16 |
| kfox1111_ | looks like there is a neutron.network one as well. | 23:18 |
| j^2 | ahhh | 23:20 |
| j^2 | yeah i’ll get this on for my next iterantion | 23:20 |
| j^2 | thanks for the suggestion kfox1111_ | 23:22 |
| kfox1111_ | looks pretty good. :) | 23:23 |
| j^2 | :D | 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^2 | yeah i really want to automate the whole HA process, but if you’ve looked at the walk through it’s pretty deep | 23:24 |
| kfox1111_ | hmm.... | 23: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^2 | hmm, i’m not following you 100% on this | 23: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^2 | the 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 already | 23:40 |
| j^2 | and on the HA setup you’d need your own network being it’s like 5-6 machines with backend stuff or what not | 23:40 |
| j^2 | i created this so it’s something you can just add and not interfere with anything you’ve already created | 23: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^2 | hmmm | 23:42 |
| j^2 | ok, i’ll see if i can get that to happen | 23:42 |
| kfox1111_ | ala: https://github.com/EMSL-MSC/heat-templates/blob/master/cfn/Jenkins/Jenkins.yaml | 23:42 |
| kfox1111_ | There's an example of a security group in there too. | 23:43 |
| j^2 | k, i’ll take a note of this | 23: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^2 | cool cool, i was thinking of setting up the LB as a ha-proxy box, but yeah i’ll remove it | 23: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^2 | nice, thanks | 23:46 |
| kfox1111_ | np. | 23:47 |
| 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^2 | can you show me an example of that? | 23:49 |
| kfox1111_ | yeah, just a sec. | 23:49 |
| j^2 | btw, both of these templates were created over the weekend with my first ever shot at HOT | 23:49 |
| j^2 | learned and created this over the last 48 hours | 23: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_ | https://github.com/EMSL-MSC/heat-templates/blob/master/hot/MongoDB/MongoDB_ConfigCluster.yaml | 23:52 |
| kfox1111_ | and nested stack: https://github.com/EMSL-MSC/heat-templates/blob/master/hot/MongoDB/MongoDB_ConfigSvr.yaml | 23:52 |
| kfox1111_ | oh... | 23:53 |
| 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 |
| j^2 | :D | 23:53 |
| kfox1111_ | it ensures your nodes land on physically different servers. | 23:53 |
| j^2 | yeah that’s over my head | 23:54 |
| kfox1111_ | probably want 2. one for the front ends, and one for the backends. | 23:54 |
| j^2 | i’ll have to come back to these | 23:54 |
| kfox1111_ | let me explain. see the OS::Nova::ServerGroup in the ConfigCluster template? | 23:55 |
| j^2 | yep | 23:56 |
| 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 SchedulerGroup | 23:56 |
| kfox1111_ | In ConfigSvr, | 23:56 |
| kfox1111_ | in the Nova::Server | 23:57 |
| kfox1111_ | it has the following: | 23:57 |
| kfox1111_ | scheduler_hints: {'group': {Ref: SchedulerGroup} } | 23:57 |
| kfox1111_ | thats it. :) | 23:57 |
| j^2 | oh interesting | 23: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 irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!