| kfox1111_ | thus, HA. :) | 00:00 |
|---|---|---|
| j^2 | oh nice that’s exactly what i want | 00:00 |
| *** kzaitsev_mb has quit IRC | 00:02 | |
| *** kzaitsev_mb has joined #openstack-app-catalog | 00:27 | |
| *** openstackgerrit has quit IRC | 00:46 | |
| *** openstackgerrit has joined #openstack-app-catalog | 00:47 | |
| *** kebray has quit IRC | 00:49 | |
| *** kzaitsev_mb has quit IRC | 01:03 | |
| *** kzaitsev_mb has joined #openstack-app-catalog | 01:59 | |
| *** kzaitsev_mb has quit IRC | 02:21 | |
| *** kzaitsev_mb has joined #openstack-app-catalog | 03:17 | |
| *** kzaitsev_mb has quit IRC | 03:22 | |
| *** kzaitsev_mb has joined #openstack-app-catalog | 04:33 | |
| *** kzaitsev_mb has quit IRC | 04:38 | |
| *** kzaitsev_mb has joined #openstack-app-catalog | 06:48 | |
| *** kzaitsev_mb has quit IRC | 06:53 | |
| *** kzaitsev_mb has joined #openstack-app-catalog | 07:49 | |
| *** kzaitsev_mb has quit IRC | 07:54 | |
| *** kzaitsev_mb has joined #openstack-app-catalog | 08:15 | |
| *** kzaitsev_mb has quit IRC | 08:48 | |
| *** kzaitsev_mb has joined #openstack-app-catalog | 09:39 | |
| *** kzaitsev_mb has quit IRC | 12:53 | |
| j_king | rhagarty: there is at least one already in development... nothing officially sanctioned afaik | 13:19 |
| *** kzaitsev_mb has joined #openstack-app-catalog | 13:21 | |
| docaedo | I'm catching up from what I missed yesterday, would really want to understand what the HP storage driver addition to horizon would look like for a cloud user (not operator) | 14:37 |
| rhagarty | j_king: hello - are you referring to another Horizon plug-in? Any more details? | 14:39 |
| j_king | rhagarty: I can't remember off the top of my head, busy atm, but there is another user here developing their own Horizon plugin. They did put up a github repo with their work on it | 14:40 |
| docaedo | kfox1111_ is the one working on that plugin, he shared a video yesterday (or day before?) showing the progress, it's looking pretty good | 14:41 |
| docaedo | "it" in this case being a Horizon panel that fetches catalog contents (exposed as JSON) and shows them to the user, including a button to fetch/import the asset into the local cloud | 14:42 |
| rhagarty | j_king: and how is it being proposed to be incorporated into the app catalog? | 14:43 |
| j_king | rhagarty: dunno. | 14:43 |
| docaedo | rhagarty: it's not being proposed as something that would be added to the app catalog, the intention will be to get it added to Horizon so it's an optional part of anyones cloud | 14:44 |
| rhagarty | docaedo: hello - not sure what your question is regarding cloud user and operators. could you elaborate? | 14:44 |
| docaedo | rhagarty: "cloud user" is someone without admin access, who can't modify anything at the control plane user. "operator" is the person administering/deploying the cloud, and can make config changes to OpenStack services in the cloud. | 14:45 |
| docaedo | rhagarty: most of us would be cloud users on HP public cloud, or rackspace | 14:45 |
| docaedo | The distinction for apps.openstack.org to date has been that anything landing there is targeted to end users of potentially multiple OpenStack clouds (so the apps that can run on top of openstack) | 14:46 |
| rhagarty | docaedo: ok - for our plug-in, the new panel and row actions are only visible to Horizon admins. But we may change that if there is demand for "read-only" access | 14:47 |
| docaedo | OK, that was what I was thinking from reading the scrollback. I would say if the plugin would be deployed by an end user without admin access then having it in the catalog would make sense, but I don't think anyone without admin access to the openstack environment can do much | 14:50 |
| docaedo | with a horizon plugin | 14:50 |
| rhagarty | docaedo: so the "it" plug-in is a potential solution to give users access to all available plug-ins? And possible have the ability to deploy them? | 14:51 |
| docaedo | no not plugins, kfox1111_ is working on a horizon panel that shows whatever is in the catalog (right now glance images, heat templates and murano applications), and provides a one-click button to bring that into the cloud (i.e. you see a glance image you like, you can copy it from apps.openstack.org into your own environment with one click instead of having to go to glance and tell it to import from URL) | 14:53 |
| docaedo | Here's the video kfox1111_ shared: https://www.youtube.com/watch?v=9TlPhmml-T8 | 14:53 |
| rhagarty | docaedo: gotcha... sorry for the confusion | 14:54 |
| docaedo | rhagarty: no problem at all! | 14:54 |
| docaedo | It's a good thing to be talking and thinking about, so I am glad you are here to do that | 14:55 |
| docaedo | I'm personally interested in all things that make OpenStack more useful :) so making it easier for someone to see how to integrate a storage system with an OpenStack cloud is important | 14:56 |
| docaedo | and I don't think there's a really unified/clean way to show that right now (as you need to make sure you have the cinder driver in and configured, and then also make sure your horizon config includes the panel, and has matching config) | 14:57 |
| docaedo | Great thing about OpenStack - lots of knobs to turn! Scariest thing about OpenStack - lots of knobs to turn! | 14:58 |
| rhagarty | docaedo: agreed! | 14:58 |
| rhagarty | docaedo: the problem we are trying to solve for our storage users is coordination between what Horizon/cinder CLUI knows about volumes, and what is really happending on the back end | 14:59 |
| rhagarty | so we have the concept of deep linking from Horizon (and other one-pane-of-glass front-ends) to our device managers | 15:00 |
| rhagarty | users see a volume with an "ERROR" status and would like to quickly dig deeper into the issue. We are giving them direct link | 15:02 |
| rhagarty | so, now we have a horizon plug-in, but no nice way to get it to our users (my manager doesn't consider GitHub or PyPI as a nice final solution) | 15:03 |
| rhagarty | if nothing else, a nice tab in the "Catalogs" -> "Applications" panel to show Horizon plug-ins, would be a great start. Showing the README and a link to github would be a nice addition | 15:06 |
| rhagarty | I know there are other Horizon plug-ins out there... you can find them in PyPI | 15:07 |
| docaedo | Ah, thanks for stating the problem like that, it helps. Have you been talking to the horizon folks about making it easier to find/consume plugins? | 15:14 |
| docaedo | and this does sit in a grey area to me, where it's not purely user-space but directly benefits users :) also exposes the bigger issue of "where can I find all the different bits that I can make part of my cloud" | 15:16 |
| kfox1111_ | good morning | 15:18 |
| rhagarty | I have approached some Horizon folks, but not getting much traction. Seems to be a one-off for them | 15:18 |
| rhagarty | kfox1111_: good morning | 15:18 |
| kfox1111_ | Did you talk to the ptl? | 15:19 |
| rhagarty | docaedo: yes, a gray area. But as a novice user, when I saw OpenStack had an "App Catalog", I thought that was the answer | 15:19 |
| docaedo | regarding horizon, I'm wondering what their position has been for things that are add-ons | 15:19 |
| kfox1111_ | docaedo: the video's here: https://youtu.be/9TlPhmml-T8 | 15:20 |
| rhagarty | the PTL suggested PyPI | 15:20 |
| kfox1111_ | yeah. thats what I kind of figured. | 15:20 |
| kfox1111_ | was worth a try. | 15:20 |
| kfox1111_ | docaedo: as part of the discussion about including TripleO templates, for advanced services, | 15:21 |
| kfox1111_ | those are templates more oriented to Cloud Ops, not Cloud Users. | 15:21 |
| kfox1111_ | So a Tag might be in order to hide them from regular users. | 15:22 |
| rhagarty | kfox1111_: what do thing of the idea about a new panel for plug-ins? ( a nice tab in the "Catalogs" -> "Applications" panel to show Horizon plug-ins, would be a great start. Showing the README and a link to github would be a nice addition) | 15:22 |
| rhagarty | thing/think | 15:22 |
| kfox1111_ | The same could be said for horizon plugins then. Tag them ops only. | 15:22 |
| docaedo | for me, the thing I liked about tripleO stuff was potentially (as a user) being able to spin up a service that I could play with, without requiring operator privs | 15:24 |
| kfox1111_ | bbiab | 15:24 |
| docaedo | if the "App Catalog" becomes the "OpenStack Things" catalog, seems like we're only making the "where do I find all the OpenStack bits" problem worse, not better | 15:25 |
| rhagarty | docaedo: I don't know all the use cases, but for Horizon plug-ins I link it would be better. If for nothing other than exposure that these things exist | 15:27 |
| rhagarty | ... and where to find them | 15:27 |
| kfox1111_ | back. | 15:27 |
| docaedo | rhagarty: sure, but think of the audience. The App Catalog should be (IMO) for users, and the OpenStack Marketplace should be for people who are building clouds | 15:28 |
| kfox1111_ | I'm not sure what the differnce is between horizon plugins and openstack service though. | 15:28 |
| kfox1111_ | a cloud op is just as likely to want some random advanced service, like say, Manilla, | 15:29 |
| docaedo | for me, I think of it as things I get from apps.openstack.org should be usable across multiple OpenStack clouds | 15:29 |
| kfox1111_ | as well as the plugin to go with it. | 15:29 |
| kfox1111_ | but that does somewhat fit with the Email thread we started on the devel list. | 15:29 |
| kfox1111_ | If tripleO can provide the advanced services that run in an openstack cloud, | 15:30 |
| kfox1111_ | then it would be cross cloud. | 15:30 |
| kfox1111_ | the somewhat painful thing about this is dependencies though... | 15:30 |
| kfox1111_ | so, advanced services in openstack works nicely because they run in vm's and the dependencies for the service can be a different version then what the cloud provides. | 15:31 |
| kfox1111_ | for example, you can run just fine a nova/neutron/glance/cinder juno controller, | 15:31 |
| kfox1111_ | and a kilo designate in a vm. | 15:31 |
| kfox1111_ | But horizon's different. | 15:31 |
| docaedo | I agree - but many of those services can not be deployed without significant changes at the control layer - I think it might help to clarify on the ML what you consider an advanced service | 15:31 |
| kfox1111_ | You can't run a Liberty horizon in a Kilo controller | 15:32 |
| docaedo | I agree that if it can run in a VM in a cloud that you don't have admin control over, that's great and makes sense as an application | 15:32 |
| kfox1111_ | And worse, is the dependency problem in horizon. So, | 15:32 |
| docaedo | (as an application on top of an OpenStack cloud I mean) | 15:32 |
| rhagarty | docaedo: there are plans to provide some limited access to non admin-users with our plug-in (FYI) | 15:32 |
| kfox1111_ | say you need your plugin to support kilo designate via python-designateclient. but it depends on python-keystone from kilo. | 15:32 |
| docaedo | rhagarty: could I add that plugin to horizon on the HP Public cloud? | 15:32 |
| kfox1111_ | but your horizon's juno. | 15:33 |
| kfox1111_ | they won't play nice. :/ | 15:33 |
| rhagarty | docaedo: I think so, yes. | 15:34 |
| kfox1111_ | docaedo: I'm ok with it requiring admin. we run designate for example in the cloud, then bind it to the keystone service catalog. | 15:34 |
| kfox1111_ | the users have no idea that particular service is running in a vm instead of bare metal. | 15:34 |
| docaedo | kfox1111_: I'm basically not OK with it requiring admin, as that stops being an App on top of OpenStack at that point, now you're talking about something inside your OpenStack cloud | 15:34 |
| rhagarty | kfox1111_: yes, details... but that is rampant problem with everything in OpenStack | 15:35 |
| docaedo | I agree users won't know the difference, but users also won't be able to add that | 15:35 |
| kfox1111_ | lets take a step back for a moment. | 15:35 |
| kfox1111_ | lets look at Xaas. | 15:35 |
| kfox1111_ | the Advanced Services I'm talking about are Xaas's. | 15:35 |
| kfox1111_ | if a user wants to have DNS, they can just spawn their own dns server in their tenant. | 15:36 |
| kfox1111_ | the point of the "advanced services", or Xaas running on top of openstack, becoming part of the openstack, | 15:36 |
| kfox1111_ | is that the cloud op can very easily deploy the advanced service, so all users of the cloud can gain access to it and not have to do it themselves. | 15:36 |
| kfox1111_ | so designate provides dnsaas, so that the user doesn't have to set up their own dns server. the cloud provides it. | 15:37 |
| kfox1111_ | so only a user with admin can really launch it, since it ends up being a public resource. | 15:37 |
| kfox1111_ | the idea behind allowing it into the app catalog for operators to deploy, | 15:38 |
| docaedo | Sure, but that is specifically talking about a major config change of the entire cloud, not an app that runs on openstack targeted at users | 15:38 |
| kfox1111_ | would be to make it very easy for ops to do so, and therefor have it available in more clouds. | 15:38 |
| kfox1111_ | then app writers can more relyably assume its there. | 15:38 |
| kfox1111_ | openstack services are really standalone things. | 15:38 |
| docaedo | sounds like you're solving a legitimate problem, but then what's the dividing line here? Would app catalog be the right place for a puppet manifest that deployes DNS as a service? | 15:38 |
| kfox1111_ | most of them just need the following: | 15:38 |
| kfox1111_ | * a db to store stuff | 15:39 |
| kfox1111_ | * a rabbit mq channel for communications | 15:39 |
| kfox1111_ | * a keystone user | 15:39 |
| kfox1111_ | * and an entyr in the service catalog so users can find it. | 15:39 |
| kfox1111_ | those need an op to setup, but are already very isolated things. | 15:39 |
| kfox1111_ | docaedo: good question. | 15:40 |
| kfox1111_ | I don't think we quite have an answer to that yet. | 15:40 |
| kfox1111_ | initially thought was, it is some place to find things you can load into openstack with a button push. | 15:40 |
| kfox1111_ | either a "Launch", or an "Install". | 15:41 |
| kfox1111_ | the rest should be automated. | 15:41 |
| kfox1111_ | but we already have at least one instance of something that doesn't fit that. | 15:41 |
| kfox1111_ | The windows image. | 15:41 |
| kfox1111_ | We have a deviding line in the UI that we've talked about setting with a Tag. | 15:42 |
| kfox1111_ | Application vs Component. Application is something a user can just "Launch". | 15:42 |
| docaedo | How does the windows image not fit that? It's just a glance image, it's not a cloud-wide service? | 15:42 |
| kfox1111_ | A component is something needed to be installed that is needed by apps. | 15:42 |
| kfox1111_ | docaedo: because the iamge cant be glance loaded via the website or pasted into the command line directly. | 15:42 |
| kfox1111_ | its hidden behind a eula. | 15:43 |
| kfox1111_ | So it has to be manually downloaded and installed. | 15:43 |
| kfox1111_ | See the video on how the web ui handles it. I just had top op up a link to the website for the eula. | 15:43 |
| kfox1111_ | I can't hook in the tell glance to install it wizard. | 15:43 |
| rhagarty | you guys have mentioned "tag" several times. Can you elaborate, or point me to some documentation? | 15:44 |
| docaedo | ok, there's one extra step to fetching it, but it's still an end-user only thing (a glance image) so I don't see how that opens the door to being called the same as adding a new openstack service to a running cloud | 15:44 |
| kfox1111_ | So, I can see there being a second Tag type of "End User" vs "Operator". | 15:44 |
| kfox1111_ | The advanced services templates could be tagged as Operator, and only shown to folks with Admin rights. | 15:44 |
| kfox1111_ | true. just pointing out that my origional definition of "collection of things directly installable by openstack" doesn't quite hold. | 15:45 |
| docaedo | I think it's worth (in the step back) to think about the audience we are trying to reach | 15:45 |
| kfox1111_ | so, emagine this.... | 15:45 |
| kfox1111_ | someone posts an entry for a glance image, that points to a howto that has the instructions for running diskimagebuilder for building the glance image. | 15:46 |
| kfox1111_ | is that much different then the windows website url? | 15:46 |
| docaedo | Absolutely | 15:46 |
| kfox1111_ | a human is in the middle of catalog -> human -> glance image. | 15:47 |
| docaedo | I would advocate dropping anything/everything witout a direct link before I supported a multi-step multi-depency how-to as something in the app catalog | 15:47 |
| docaedo | there's a place for that already - docs.openstack.org | 15:48 |
| kfox1111_ | yeah. its a slippery slope. :/ | 15:48 |
| docaedo | I don't think it has to be a slipper slope though - here's what I'm trying to say when I say let's consider the audience | 15:48 |
| docaedo | the genesis of this was basically "look, docker has the docker-hub, and people got quickly used to saying hey look I can docker-pull something from the hub, and magically I get the thing!" | 15:49 |
| docaedo | but openstack didn't have anything like that - nobody was even talking about what runs IN an openstack cloud (at least not in one place) | 15:49 |
| docaedo | some people were talking about it with respect to heat | 15:49 |
| docaedo | others with respect to murano | 15:50 |
| kfox1111_ | yeah. thats where I'd like to get to. | 15:50 |
| docaedo | but USERS of clouds were mostly just being pointed to the catalogs offered by their ISP (rackspace, HP, maybe some others) | 15:50 |
| kfox1111_ | yeah. | 15:50 |
| kfox1111_ | and the catalogs are very sparse since no one is collaborating to fill them. | 15:51 |
| kfox1111_ | hence this project. | 15:51 |
| docaedo | so app catalog was meant to reach the dramatically larger audience of people with access to an openstack cloud | 15:51 |
| kfox1111_ | We're in total agreement there. | 15:51 |
| *** kebray has joined #openstack-app-catalog | 15:52 | |
| docaedo | now the conversations around advanced services, and cataloging horizon plugins, etc. - those are hitting something that is a problem, which is that all the bits and pieces you can use to build an openstack cloud are spread out all over the place | 15:52 |
| kfox1111_ | The issue I run into, as a writer of heat templates to contribute, | 15:52 |
| kfox1111_ | is I need a common relyable cloud on which to build. | 15:52 |
| docaedo | that's a legit issue, but it's difference, and faces the much smaller audience of people who want to build/run/maintain an OpenStack cloud | 15:52 |
| kfox1111_ | If I need a database, I don't want to have to write a whole set of templates to spawn my own database, | 15:53 |
| kfox1111_ | I just want to say Trove, give me one. | 15:53 |
| kfox1111_ | But then Trove must be everywhere my template should run. | 15:53 |
| kfox1111_ | Trove's kind of hard to setup today, so it isn't on many clouds yet. | 15:53 |
| kfox1111_ | thus, the app catalog suffers. | 15:53 |
| docaedo | agreed, that's a huge concern but one that to me is outside what the app catalog means to solve. You're talking about common standards for OpenStack clouds (ie defcore) | 15:54 |
| kfox1111_ | If the app catalog could be part of the solution, to make it easy for clouds to gain trove, then the user that want to launch templates that depend on trove benifit. | 15:54 |
| kfox1111_ | partially yes. defcore's trying to standardize the bare minimum. | 15:54 |
| kfox1111_ | it helps greatly with providing advanced services on top of openstack itself. | 15:55 |
| kfox1111_ | cause you know nova is there and working. | 15:55 |
| kfox1111_ | but it doesn't say, trove, barbican, or designate must be there. | 15:55 |
| kfox1111_ | at best it says, if trove's there, it must function like x. | 15:55 |
| kfox1111_ | what we need is to lower the bar to make it easy for trove to be there. | 15:55 |
| docaedo | sure but you are still speaking as an operator here entirely, not as a joe-average OpenStack user | 15:55 |
| kfox1111_ | otherwise, all our templates, to be generic, can only target defcore, and do everything itself. | 15:56 |
| kfox1111_ | can't rely on neutron lbaas, trove databases, dns entries from designate, etc. | 15:56 |
| docaedo | and honestly, I think murano solves the problem you're talking about much more elegantly than heat - you can build something that expects a database, and just use an existing database app package | 15:56 |
| kfox1111_ | yes, but no. here's why... | 15:57 |
| kfox1111_ | murano's providing its own programming language. | 15:57 |
| kfox1111_ | as such, it only is safe to load things into it as an op. | 15:57 |
| kfox1111_ | so its just replacing trove with murano+db, and designate with murano+dns apps, etc. | 15:58 |
| kfox1111_ | either way, an op needs to do the work. | 15:58 |
| kfox1111_ | and I think the regular openstack services are more robust then what murano's providing. | 15:59 |
| kfox1111_ | the point is, for the murano app, you depend on the op preloading stuff in. same with the heat template. its really not any different. | 16:00 |
| kfox1111_ | the murano folks just kind of hid it a little better. | 16:00 |
| kfox1111_ | by putting what I would call an Advanced Service in one of their packages. | 16:00 |
| docaedo | not really - if a cloud has Murano you can use a murano app to deploy the DB (instead of relying on trove) | 16:00 |
| kfox1111_ | same with heat. | 16:01 |
| kfox1111_ | you just make a heat template for launching a mysql db and making a nested stack to it. | 16:01 |
| kfox1111_ | But... Trove buys you much more then that. | 16:01 |
| kfox1111_ | it gives you an api to do backups, for building fully HA databases, | 16:02 |
| docaedo | right, and that approach makes 1000x more sense than trying to get your operator to install trove for you (because most of them will not do that) | 16:02 |
| kfox1111_ | It can potentially running bare metal db's and sharing the instance for better performance not able to be done in a vm. | 16:02 |
| docaedo | and still, this is talking about operator stuff, not "apps that run on openstack" | 16:02 |
| kfox1111_ | neither murano nor heat can do that. | 16:02 |
| kfox1111_ | agreed. | 16:02 |
| kfox1111_ | Thats why I think an "Ops" tag might fit. If its not for a regular user, just don't show it to them. | 16:03 |
| kfox1111_ | If an Op is interested, (s)he can still find the heat template. | 16:03 |
| j^2 | granted, isn’t magnum arguably part of this then? it’s just a wrapper around 3 CoreOS glance images with the docker api | 16:04 |
| docaedo | I see that as a way to put non-user non-app things in the app catalog, but that runs counter to the vision of "a place for things that run on an openstack cloud" | 16:04 |
| kfox1111_ | Magnum's another advanced service by my definition. it provides kubernets as a service. Very very similar to Sahara. | 16:05 |
| kfox1111_ | but running magnum in a vm using a heat template by just clicking "Launch" is something an operator might want to do, and does seem to fit that definition. | 16:05 |
| kfox1111_ | an op is a user in that case. | 16:06 |
| j^2 | exactly | 16:06 |
| kfox1111_ | its just a very specific app that non ops probably never care about. | 16:06 |
| kfox1111_ | so we tag it as an op template, and hide it normally. | 16:06 |
| kfox1111_ | if an op is logged in, it shows up in the app catalog. | 16:07 |
| kfox1111_ | Thats really all there is to it. very simple. | 16:07 |
| kfox1111_ | horizon plugins are a whole nother kettle of fish. | 16:07 |
| docaedo | but it's not an app that runs on top of openstack, so does seem simple to me | 16:07 |
| kfox1111_ | I don't think those would be easy to one click install at all. :/ | 16:07 |
| kfox1111_ | but sahara images aren't apps either. they are components. | 16:08 |
| kfox1111_ | but they are in the catalog. | 16:08 |
| kfox1111_ | thats why we split the ui into Applications and Components. | 16:08 |
| kfox1111_ | Solum language packs are another example of components. | 16:08 |
| kfox1111_ | So... maybewe tag advanced services as Components, not Apps... | 16:09 |
| docaedo | ah yes, you are right :) kind of forgot we were already down the slippery slope | 16:09 |
| j^2 | the idea that you could just click a launch button and get the app or click to augment your whole cluster can/is extremely exciting in my mind | 16:09 |
| docaedo | tagging/categorizing things for ops makes sense (and I'm not trying to be obstructioninst, just want to make sure we have thought carefully around where we are going) | 16:11 |
| kfox1111_ | +1 for carefully thinking things through. :) | 16:11 |
| docaedo | and the one counter argument that would make sense againt it: | 16:11 |
| docaedo | if there was already "one place" to go to find the bits that can be used to augment your cloud, then talking about adding things like that to the App Catalog would just dilute the situation | 16:12 |
| docaedo | however, no place exists right now for stuff like that | 16:12 |
| kfox1111_ | yeah. | 16:12 |
| docaedo | so if we can agree on an approach that really makes sense (and is articulated well enough to prevent it from becoming a random catch-all for anything related to OpenStack), I'm in | 16:12 |
| kfox1111_ | k. | 16:13 |
| docaedo | but I see how the idea of supporting solum LPs was already moving down the slope | 16:13 |
| docaedo | however | 16:13 |
| docaedo | who is here from Solum, and has been staying part of the conversation on that front? | 16:13 |
| docaedo | show of hands? (I'll wait patiently ;) ) | 16:13 |
| docaedo | Sorry, I have a snarky streak in me that is sometimes hard to manage :) Point being though - at the summit, lots of talk around "oh support more stuff!" but since then, kind of silent on that front | 16:15 |
| kfox1111_ | Yeah. | 16:16 |
| kfox1111_ | Its slow growing a community like this. | 16:16 |
| kfox1111_ | partially because of difference in definition on what a cloud is. | 16:16 |
| kfox1111_ | I'm convinced openstack is an operating system. same as linux. and its paralleling Linux's development. | 16:17 |
| kfox1111_ | First, it was only adopted by the kernel developers. | 16:17 |
| kfox1111_ | the next stage was, it was adopted only by programmers. | 16:17 |
| kfox1111_ | user=develoer. | 16:17 |
| kfox1111_ | it was then ok that building stuff from scratch was part of the deployment workflow. | 16:17 |
| kfox1111_ | Openstack is at this stage right now. | 16:18 |
| kfox1111_ | Openstack Users are expected to build everything in their own tenant themselves. user=developer. | 16:18 |
| kfox1111_ | The next step in linux was, more users then developers. | 16:18 |
| kfox1111_ | developers provide software targeting the os, and users consume it. | 16:19 |
| kfox1111_ | to get there, openstack needs defcore, and robust common core. | 16:19 |
| kfox1111_ | and lastly, the 4th stage of OS'ness is an appstore. | 16:19 |
| kfox1111_ | a place users can go to to get the software to do stuff. | 16:20 |
| j^2 | i’d have to say that’s pretty accurate for the life cycle | 16:20 |
| kfox1111_ | So.... we're trying to make progress on stage 4, when we're still fighting a lot of battles at the stage 3 part. | 16:20 |
| kfox1111_ | hense, my trying to get advanced services as part of the app catalog to try and shore up stage 3. :) | 16:21 |
| kfox1111_ | the sucky part of stage 2 is users that are the developers themselves push back and thing all users are developers and why would you ever not want to just do "insert developery thing here". :/ | 16:23 |
| kfox1111_ | So they make things harder on non developer users. :/ Thats a cultural issue that takes time to break down. :/ | 16:24 |
| docaedo | IMO we are already at stage 4, or on the edge of it. So for me I don't see the app catalog as the way to solve "add more services to your openstack cloud" - I think the app catalog should be focused on the end user, and we have some months to make it the best place for that, the best place to share things that you can do with openstack | 16:24 |
| kfox1111_ | I totally agree with the focus is on the end users. I'm very much with you there. | 16:25 |
| kfox1111_ | as an app developer though, I fight way way too much the battles of stage 2 almost every day. | 16:25 |
| kfox1111_ | the nova instance user thing is a big example. | 16:25 |
| kfox1111_ | "Why would a user not just do that themselves? Why would the vm want to do it?" | 16:26 |
| kfox1111_ | "because a user CANT do it, because they are not skilled developers." | 16:26 |
| kfox1111_ | stage 2. :/ | 16:26 |
| docaedo | sure, but to be fair you have the perspective of someone operating an openstack cloud - not someone using an account on rackspace | 16:27 |
| kfox1111_ | j^2's ha app template cant do things like the amazon ec2 way which is a better way, because of that thinking. :/ | 16:27 |
| j^2 | :( | 16:27 |
| kfox1111_ | oh, actually I do. I'm an op trying to provide a private/public cloud to scientists. | 16:27 |
| kfox1111_ | scientists != developers. | 16:27 |
| kfox1111_ | thats why I care so much. | 16:28 |
| kfox1111_ | If I were just building it for me, I wouldn't bother. | 16:28 |
| j^2 | yeah my goal with the ha template was to just build up everything so you can walk through te tutorial it links | 16:28 |
| docaedo | oh I'm not at all trying to minize your efforts or perspective | 16:28 |
| docaedo | fully appreciate it, but I hear you hitting a lot of dev/operator level issues, and you want to fix these things | 16:28 |
| rhagarty | docaedo: clarification... so if it solution requires an OP to install, it should NOT be in the app catalog? | 16:29 |
| kfox1111_ | Sure. I'm saying, my primary focus right now is ehancing openstack so that high energy physicists, computational chemists, etc can launch applications and get science done. | 16:29 |
| kfox1111_ | but Irealize, in order to solve those problems, I need a robust cloud under the hood that does not assume the user is a skilled computer scientist. | 16:30 |
| docaedo | so "make OpenStack easier to use" is an awesome goal, and app catalog could be a huge part of that | 16:30 |
| kfox1111_ | That means, work that ops are pushing on users must be pushed back to the ops. | 16:30 |
| kfox1111_ | and the developers. | 16:30 |
| j^2 | with the Ops Meetup, we could put a section on for that, see what the ops want to do | 16:31 |
| kfox1111_ | A scientist is going to have a much better time using Trove, then laucnhing db's through murano or heat. | 16:31 |
| kfox1111_ | because the op has hooks in it to help the scientist manage their stuff. | 16:31 |
| j^2 | https://etherpad.openstack.org/p/PAO-ops-meetup | 16:31 |
| docaedo | rhagarty: that's the debate of the moment :) | 16:32 |
| kfox1111_ | part of the problem I have with some ops, is about half believe openstack is not an operating system. | 16:32 |
| kfox1111_ | so are stuck in stage2 thinking. | 16:32 |
| kfox1111_ | they want to do as little as possible to setup a cloud, and then make the users deal with everythign else. | 16:32 |
| kfox1111_ | Thats fine when a user is a developer. its not fine when a user is a scientist. :/ | 16:33 |
| kfox1111_ | or a school teacher, or .... app catalog users. :) | 16:33 |
| kfox1111_ | I get the ops meetup thing. but there's another set of users not covered much yet. | 16:34 |
| kfox1111_ | stage 3 developers. | 16:34 |
| kfox1111_ | you really have 4 sets of actors in openstack. | 16:35 |
| kfox1111_ | service developers, ops, cloud developers, cloud users. | 16:35 |
| kfox1111_ | because of stage 2 thinking, service developers and ops assume cloud develoeprs = cloud users. | 16:35 |
| kfox1111_ | What we really need, is a Cloud Developers meetup. | 16:35 |
| docaedo | on that topic, I honestly think it's a mistake to try to make people develop apps specifically for openstack. OpenStack should manage and provide infrastructure through an API. The more we chase every service imaginable (i.e. let's be AWS!) the more fragmented and broken things become | 16:36 |
| kfox1111_ | those are the folks that will contribute to the app catalog. | 16:36 |
| kfox1111_ | thats one of the reasons openstack is an operationg system. openstack API = linux syscalls. | 16:36 |
| kfox1111_ | Cloud Applications have to speak to the operating system in its own language. | 16:37 |
| kfox1111_ | THe advantage of Openstack over other operating systems (azure, aws) is that | 16:37 |
| kfox1111_ | the syscalls are standard over lots of public and private clouds. | 16:37 |
| docaedo | but as an app developer, if I'm making something that I want people to consume/use/tell others about, I want it to run on OpenStack, AWS, google, other clouds | 16:37 |
| kfox1111_ | If you write for the openstack os, your app can run on thousands of clouds. If you write it for azure, onlyh one. | 16:38 |
| docaedo | there are thousands of openstack clouds? | 16:38 |
| kfox1111_ | but thats the same issue as Win32/macos/Linux. | 16:38 |
| kfox1111_ | then you must make your app have an abstraction layer to sit on top of 3 different os's, which costs time and mony todevelop. | 16:38 |
| kfox1111_ | and we all know how that ends up. One dominant OS. :/ | 16:39 |
| kfox1111_ | yeah. thousands. Lots of little private clouds, and several big public ones. | 16:39 |
| docaedo | Or I could containerize it and use a common orchestration/management platfor (kubernetes) | 16:39 |
| kfox1111_ | containerization still has a long way to go. :/ | 16:40 |
| kfox1111_ | they are paralleling openstack development a couple of years behind. | 16:40 |
| kfox1111_ | they deal very well currently with totally stateless apps. | 16:40 |
| kfox1111_ | statefull things, not so much. | 16:40 |
| kfox1111_ | the same thing happened with openstack vm's. | 16:41 |
| kfox1111_ | the problem is, most things are not stateless. :/ | 16:41 |
| kfox1111_ | If I spawn a jenkins container, and the server its running on dies, | 16:41 |
| kfox1111_ | I'd be very very upset if I relaunch it and all my jobs are gone. | 16:41 |
| kfox1111_ | docker is a very hot topic today. but its very green technology, and suffers from some major drawbacks that aren't talked about much yet. | 16:42 |
| kfox1111_ | Security updates to containers is a huge issue. :? | 16:43 |
| kfox1111_ | got a meeting to go to. bbiab. | 16:43 |
| j^2 | i threw up a session idea for apps.openstack.org | 16:54 |
| j^2 | on the PAO-ops-meetup | 16:54 |
| j^2 | have a chance to to the different ops out there, i can run it if needed | 16:55 |
| j^2 | and report back | 16:55 |
| kfox1111_ | cool. thanks. :) | 16:55 |
| kfox1111_ | The reall issue is, developers writing code to run in their own tenant vs developrs writing code tht needs to be generic enough to run in a different tenant/different cloud. | 16:56 |
| kfox1111_ | ok. heading to meeting number 2. :/ | 16:56 |
| docaedo | On that topic I think much of what Monty had to say here was exactly right on: https://www.openstack.org/summit/vancouver-2015/summit-videos/presentation/liberty-product-management-and-openstack-technology | 16:57 |
| kfox1111_ | yay. moved to 1:00. :) | 16:58 |
| kfox1111_ | the summery looks about right. I'll have to watch it. Thanks. :) | 16:59 |
| docaedo | that and project shade are really interesting (and in my opinion exactly what we should be talking/thinking about now) | 17:00 |
| kfox1111_ | openstack suffers a from too much silo'ing. Each service assumes the other will do X. and in the end, no one does. :/ | 17:00 |
| kfox1111_ | project shade? | 17:00 |
| kfox1111_ | ah. yeah. | 17:01 |
| kfox1111_ | that will help. | 17:01 |
| kfox1111_ | but so would not having to make app developers forced to write templates for both neutron and nova-network. :/ | 17:02 |
| kfox1111_ | and lbaas supported or not. trove supported or not. etc. :/ | 17:02 |
| kfox1111_ | Topic change... so, I think I've gotten an example of an angular stand alone plugin from Horizon. | 17:03 |
| kfox1111_ | I'm going to try and extract the app catalog ui into its own repo for easy adding to an existing horizon. | 17:03 |
| kfox1111_ | docaedo: Can you request another git repo? apps-catalog-ui? | 17:03 |
| docaedo | kfox1111_: would that be for a horizon panel? | 17:18 |
| kfox1111_ | yeah. | 17:19 |
| kfox1111_ | I'm splitting up the one I have on github into the app catalog specific stuff which would go into that new repo, | 17:19 |
| kfox1111_ | and a set of patches to contribute to horizon, so the plugin can assume its there. | 17:20 |
| kfox1111_ | Once complete, we can submit an rpm to the rdo folks and then its just a yum install away. :) | 17:20 |
| kfox1111_ | or a pip install. | 17:21 |
| docaedo | Had to step away for a bit, but I think seems like we would need something like this https://review.openstack.org/#/c/202281/ | 18:28 |
| docaedo | and maybe call it app-catalog-dashboard? I'll be back around a bit later today, and I think much of tomorrow - loving that we've got some good conversation in play now by the way :) | 18:29 |
| kfox1111_ | looks about right. | 18:47 |
| kfox1111_ | that would probably work. I think most of the plugin's use -ui. | 18:47 |
| *** kzaitsev_mb has quit IRC | 19:04 | |
| *** kzaitsev_mb has joined #openstack-app-catalog | 20:06 | |
| kzaitsev_mb | I think most projects use -ui, btw =) | 20:54 |
| kzaitsev_mb | I only know, that murano uses -dashboard | 20:55 |
| kzaitsev_mb | ugh, guys, I finally came back and now have some spare time to work on app-catalog. I've been wanting to implement (at least partially) that bp of mine, but it turns out, that there is no easy way to make inputs fit it's content nicely (the way I wanted it to be) without some js. | 21:00 |
| kzaitsev_mb | But when I get into js — my vim blows up with tons of warnings/errors =) | 21:01 |
| kzaitsev_mb | I've been adding js linting job to the murano-dashboard some time ago — guess app-catalog would benifit from such a job too. | 21:02 |
| docaedo | kzaitsev_mb: sure I think a js linting job would be good | 21:04 |
| kzaitsev_mb | docaedo: I was really thining about what set of rules to use to lint app-catalog js code, but we could just use horizons default, I guess | 21:06 |
| docaedo | defaulting to horizon would make it easy and consistent | 21:13 |
| docaedo | kzaitsev_mb: any chance you can help with combining the YAMLs into a common one? That might be right up your alley :) | 21:14 |
| kzaitsev_mb | docaedo: I'll take a look at it =). Guess it requires some js fiddling? | 21:15 |
| docaedo | two pieces - one is a modified schema that has a generic base, but is flexible enough to handle extra fields that don't apply to other asset types | 21:16 |
| docaedo | then the JS piece would be to modify the site so it loads asset info from a single file and displays accordingly | 21:17 |
| docaedo | the intention then is to extend that so where we have three types now, contributors could come up with a new type (solum LP for instance), and adding it to the yaml would not break anything | 21:18 |
| docaedo | that means we also start working on the web site so it can handle multiple categories easily | 21:18 |
| docaedo | regarding the repo name, I'm happy with -ui and will be taking a "supporting kfox1111_ in his efforts" role with that | 21:19 |
| kzaitsev_mb | I'll take a look into combinig, but right after I finish with linting =) Seeing all those missed semicolons makes me cringe a little =) | 21:21 |
| kzaitsev_mb | btw, should I file a BP or a bug about linting? what do you think? | 21:26 |
| docaedo | probably bug for that since it's pretty simple | 21:52 |
| docaedo | also bug because it IS a bug | 21:52 |
| openstackgerrit | Kirill Zaitsev proposed stackforge/apps-catalog: Added eslint tox env https://review.openstack.org/206734 | 21:55 |
| openstackgerrit | Kirill Zaitsev proposed stackforge/apps-catalog: Lint js and css files https://review.openstack.org/206737 | 22:04 |
| kzaitsev_mb | hm. I've already done it the other way round =) will fix tomorrow, if you think that a bug is more appropriate ) | 22:05 |
| kzaitsev_mb | gerrit is surprisingly good with reviewing indentation changes. I'm almost imressed =) | 22:06 |
| *** kzaitsev_mb has quit IRC | 22:19 | |
| kfox1111_ | cool. :) | 22:41 |
| kfox1111_ | I think I'm really close to having the horizon plugin split out. | 22:42 |
| kfox1111_ | One more thing needed from the horizon folks so that the java script gets loaded. | 22:43 |
| kfox1111_ | nodeenv -p.... very interesting. :) | 22:46 |
| kfox1111_ | so how long do you think it will take to get the repo? I'm pretty close to having something to push to it. :) | 23:03 |
| kfox1111_ | If its a while out, I can always make a personal github repo until it becomes ready. just don't want to do so if its close. | 23:04 |
| kfox1111_ | docaedo: did you write the website? | 23:05 |
| *** kebray has quit IRC | 23:12 | |
| *** kzaitsev_mb has joined #openstack-app-catalog | 23:17 | |
| *** kzaitsev_mb has quit IRC | 23:21 | |
| *** rhagarty has quit IRC | 23:33 | |
| *** rhagarty_ has joined #openstack-app-catalog | 23:39 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!