Tuesday, 2015-07-28

kfox1111_thus, HA. :)00:00
j^2oh nice that’s exactly what i want00:00
*** kzaitsev_mb has quit IRC00:02
*** kzaitsev_mb has joined #openstack-app-catalog00:27
*** openstackgerrit has quit IRC00:46
*** openstackgerrit has joined #openstack-app-catalog00:47
*** kebray has quit IRC00:49
*** kzaitsev_mb has quit IRC01:03
*** kzaitsev_mb has joined #openstack-app-catalog01:59
*** kzaitsev_mb has quit IRC02:21
*** kzaitsev_mb has joined #openstack-app-catalog03:17
*** kzaitsev_mb has quit IRC03:22
*** kzaitsev_mb has joined #openstack-app-catalog04:33
*** kzaitsev_mb has quit IRC04:38
*** kzaitsev_mb has joined #openstack-app-catalog06:48
*** kzaitsev_mb has quit IRC06:53
*** kzaitsev_mb has joined #openstack-app-catalog07:49
*** kzaitsev_mb has quit IRC07:54
*** kzaitsev_mb has joined #openstack-app-catalog08:15
*** kzaitsev_mb has quit IRC08:48
*** kzaitsev_mb has joined #openstack-app-catalog09:39
*** kzaitsev_mb has quit IRC12:53
j_kingrhagarty: there is at least one already in development... nothing officially sanctioned afaik13:19
*** kzaitsev_mb has joined #openstack-app-catalog13:21
docaedoI'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
rhagartyj_king: hello - are you referring to another Horizon plug-in? Any more details?14:39
j_kingrhagarty: 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 it14:40
docaedokfox1111_ is the one working on that plugin, he shared a video yesterday (or day before?) showing the progress, it's looking pretty good14: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 cloud14:42
rhagartyj_king: and how is it being proposed to be incorporated into the app catalog?14:43
j_kingrhagarty: dunno.14:43
docaedorhagarty: 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 cloud14:44
rhagartydocaedo: hello - not sure what your question is regarding cloud user and operators. could you elaborate?14:44
docaedorhagarty: "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
docaedorhagarty: most of us would be cloud users on HP public cloud, or rackspace14:45
docaedoThe 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
rhagartydocaedo: 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" access14:47
docaedoOK, 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 much14:50
docaedowith a horizon plugin14:50
rhagartydocaedo: 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
docaedono 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
docaedoHere's the video kfox1111_ shared: https://www.youtube.com/watch?v=9TlPhmml-T814:53
rhagartydocaedo: gotcha... sorry for the confusion14:54
docaedorhagarty: no problem at all!14:54
docaedoIt's a good thing to be talking and thinking about, so I am glad you are here to do that14:55
docaedoI'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 important14:56
docaedoand 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
docaedoGreat thing about OpenStack - lots of knobs to turn!  Scariest thing about OpenStack - lots of knobs to turn!14:58
rhagartydocaedo: agreed!14:58
rhagartydocaedo: 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 end14:59
rhagartyso we have the concept of deep linking from Horizon (and other one-pane-of-glass front-ends) to our device managers15:00
rhagartyusers see a volume with an "ERROR" status and would like to quickly dig deeper into the issue. We are giving them direct link15:02
rhagartyso, 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
rhagartyif 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 addition15:06
rhagartyI know there are other Horizon plug-ins out there... you can find them in PyPI15:07
docaedoAh, 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
docaedoand 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 morning15:18
rhagartyI have approached some Horizon folks, but not getting much traction. Seems to be a one-off for them15:18
rhagartykfox1111_: good morning15:18
kfox1111_Did you talk to the ptl?15:19
rhagartydocaedo: yes, a gray area. But as a novice user, when I saw OpenStack had an "App Catalog", I thought that was the answer15:19
docaedoregarding horizon, I'm wondering what their position has been for things that are add-ons15:19
kfox1111_docaedo: the video's here: https://youtu.be/9TlPhmml-T815:20
rhagartythe PTL suggested PyPI15: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
rhagartykfox1111_: 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
kfox1111_The same could be said for horizon plugins then. Tag them ops only.15:22
docaedofor 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 privs15:24
docaedoif 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 better15:25
rhagartydocaedo: 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 exist15:27
rhagarty... and where to find them15:27
docaedorhagarty: 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 clouds15: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
docaedofor me, I think of it as things I get from apps.openstack.org should be usable across multiple OpenStack clouds15: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
docaedoI 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 service15:31
kfox1111_You can't run a Liberty horizon in a Kilo controller15:32
docaedoI 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 application15: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
rhagartydocaedo: 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
docaedorhagarty: 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
rhagartydocaedo: 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
docaedokfox1111_: 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 cloud15:34
rhagartykfox1111_: yes, details... but that is rampant problem with everything in OpenStack15:35
docaedoI agree users won't know the difference, but users also won't be able to add that15: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
docaedoSure, but that is specifically talking about a major config change of the entire cloud, not an app that runs on openstack targeted at users15: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
docaedosounds 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 stuff15:39
kfox1111_ * a rabbit mq channel for communications15:39
kfox1111_ * a keystone user15: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
docaedoHow 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
rhagartyyou guys have mentioned "tag" several times. Can you elaborate, or point me to some documentation?15:44
docaedook, 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 cloud15: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
docaedoI think it's worth (in the step back) to think about the audience we are trying to reach15: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
kfox1111_a human is in the middle of catalog -> human -> glance image.15:47
docaedoI would advocate dropping anything/everything witout a direct link before I supported a multi-step multi-depency how-to as something in the app catalog15:47
docaedothere's a place for that already - docs.openstack.org15:48
kfox1111_yeah. its a slippery slope. :/15:48
docaedoI 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 audience15:48
docaedothe 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
docaedobut 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
docaedosome people were talking about it with respect to heat15:49
docaedoothers with respect to murano15:50
kfox1111_yeah. thats where I'd like to get to.15:50
docaedobut USERS of clouds were mostly just being pointed to the catalogs offered by their ISP (rackspace, HP, maybe some others)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
docaedoso app catalog was meant to reach the dramatically larger audience of people with access to an openstack cloud15:51
kfox1111_We're in total agreement there.15:51
*** kebray has joined #openstack-app-catalog15:52
docaedonow 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 place15: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
docaedothat's a legit issue, but it's difference, and faces the much smaller audience of people who want to build/run/maintain an OpenStack cloud15: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
docaedoagreed, 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
docaedosure but you are still speaking as an operator here entirely, not as a joe-average OpenStack user15: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
docaedoand 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 package15: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
docaedonot 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
docaedoright, 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
docaedoand 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_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^2granted, isn’t magnum arguably part of this then? it’s just a wrapper around 3 CoreOS glance images with the docker api16:04
docaedoI 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
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
docaedobut it's not an app that runs on top of openstack, so does seem simple to me16: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
docaedoah yes, you are right :) kind of forgot we were already down the slippery slope16:09
j^2the 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 mind16:09
docaedotagging/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
docaedoand the one counter argument that would make sense againt it:16:11
docaedoif 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 situation16:12
docaedohowever, no place exists right now for stuff like that16:12
docaedoso 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 in16:12
docaedobut I see how the idea of supporting solum LPs was already moving down the slope16:13
docaedowho is here from Solum, and has been staying part of the conversation on that front?16:13
docaedoshow of hands?  (I'll wait patiently ;) )16:13
docaedoSorry, 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 front16:15
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_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^2i’d have to say that’s pretty accurate for the life cycle16: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
docaedoIMO 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 openstack16: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
docaedosure, but to be fair you have the perspective of someone operating an openstack cloud - not someone using an account on rackspace16: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
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^2yeah my goal with the ha template was to just build up everything so you can walk through te tutorial it links16:28
docaedooh I'm not at all trying to minize your efforts or perspective16:28
docaedofully appreciate it, but I hear you hitting a lot of dev/operator level issues, and you want to fix these things16:28
rhagartydocaedo: 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
docaedoso "make OpenStack easier to use" is an awesome goal, and app catalog could be a huge part of that16: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^2with the Ops Meetup, we could put a section on for that, see what the ops want to do16: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
docaedorhagarty: 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
docaedoon 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 become16: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 that16:37
kfox1111_the syscalls are standard over lots of public and private clouds.16:37
docaedobut 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 clouds16: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
docaedothere 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
docaedoOr 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^2i threw up a session idea for apps.openstack.org16:54
j^2on the PAO-ops-meetup16:54
j^2have a chance to to the different ops out there, i can run it if needed16:55
j^2and report back16: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
docaedoOn 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-technology16:57
kfox1111_yay. moved to 1:00. :)16:58
kfox1111_the summery looks about right. I'll have to watch it. Thanks. :)16:59
docaedothat 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
docaedokfox1111_: would that be for a horizon panel?17:18
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
docaedoHad 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
docaedoand 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 IRC19:04
*** kzaitsev_mb has joined #openstack-app-catalog20:06
kzaitsev_mbI think most projects use -ui, btw =)20:54
kzaitsev_mbI only know, that murano uses -dashboard20:55
kzaitsev_mbugh, 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_mbBut when I get into js — my vim blows up with tons of warnings/errors =)21:01
kzaitsev_mbI'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
docaedokzaitsev_mb: sure I think a js linting job would be good21:04
kzaitsev_mbdocaedo: 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 guess21:06
docaedodefaulting to horizon would make it easy and consistent21:13
docaedokzaitsev_mb: any chance you can help with combining the YAMLs into a common one? That might be right up your alley :)21:14
kzaitsev_mbdocaedo: I'll take a look at it =). Guess it requires some js fiddling?21:15
docaedotwo 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 types21:16
docaedothen the JS piece would be to modify the site so it loads asset info from a single file and displays accordingly21:17
docaedothe 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 anything21:18
docaedothat means we also start working on the web site so it can handle multiple categories easily21:18
docaedoregarding the repo name, I'm happy with -ui and will be taking a "supporting kfox1111_ in his efforts" role with that21:19
kzaitsev_mbI'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_mbbtw, should I file a BP or a bug about linting? what do you think?21:26
docaedoprobably bug for that since it's pretty simple21:52
docaedoalso bug because it IS a bug21:52
openstackgerritKirill Zaitsev proposed stackforge/apps-catalog: Added eslint tox env  https://review.openstack.org/20673421:55
openstackgerritKirill Zaitsev proposed stackforge/apps-catalog: Lint js and css files  https://review.openstack.org/20673722:04
kzaitsev_mbhm. I've already done it the other way round =) will fix tomorrow, if you think that a bug is more appropriate )22:05
kzaitsev_mbgerrit is surprisingly good with reviewing indentation changes. I'm almost imressed =)22:06
*** kzaitsev_mb has quit IRC22: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 IRC23:12
*** kzaitsev_mb has joined #openstack-app-catalog23:17
*** kzaitsev_mb has quit IRC23:21
*** rhagarty has quit IRC23:33
*** rhagarty_ has joined #openstack-app-catalog23:39

Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!