| *** toddjohn_ has quit IRC | 00:47 | |
| *** kzaitsev_mb has joined #openstack-app-catalog | 00:50 | |
| *** kzaitsev_mb has quit IRC | 00:54 | |
| *** kzaitsev_mb has joined #openstack-app-catalog | 01:50 | |
| *** kzaitsev_mb has quit IRC | 01:55 | |
| *** kebray has joined #openstack-app-catalog | 02:37 | |
| *** kebray_ has quit IRC | 02:41 | |
| *** kzaitsev_mb has joined #openstack-app-catalog | 03:52 | |
| *** kzaitsev_mb has quit IRC | 03:57 | |
| *** kzaitsev_mb has joined #openstack-app-catalog | 04:53 | |
| *** kzaitsev_mb has quit IRC | 04:58 | |
| *** kzaitsev_mb has joined #openstack-app-catalog | 05:54 | |
| *** kzaitsev_mb has quit IRC | 05:58 | |
| *** kzaitsev_mb has joined #openstack-app-catalog | 06:54 | |
| *** kzaitsev_mb has quit IRC | 06:59 | |
| *** pcaruana has joined #openstack-app-catalog | 07:15 | |
| *** kzaitsev_mb has joined #openstack-app-catalog | 07:55 | |
| *** kzaitsev_mb has quit IRC | 08:00 | |
| *** kzaitsev_mb has joined #openstack-app-catalog | 08:01 | |
| *** kzaitsev_mb has quit IRC | 08:06 | |
| *** kzaitsev_mb has joined #openstack-app-catalog | 09:22 | |
| *** kzaitsev_mb has quit IRC | 10:24 | |
| *** kzaitsev_mb has joined #openstack-app-catalog | 11:01 | |
| *** kfox1111_ has joined #openstack-app-catalog | 11:04 | |
| *** kfox1111 has quit IRC | 11:06 | |
| *** toddjohn_ has joined #openstack-app-catalog | 12:20 | |
| *** toddjohn_ has quit IRC | 12:24 | |
| *** toddjohn_ has joined #openstack-app-catalog | 12:40 | |
| *** kebray has quit IRC | 14:36 | |
| *** kebray has joined #openstack-app-catalog | 14:40 | |
| openstackgerrit | Stephen Gordon proposed openstack/app-catalog: Update to Fedora 23 Atomic 20160405 release https://review.openstack.org/307234 | 14:42 |
|---|---|---|
| *** kebray_ has joined #openstack-app-catalog | 14:57 | |
| *** kebray has quit IRC | 15:00 | |
| *** spzala has joined #openstack-app-catalog | 15:18 | |
| * kfox1111_ is sad | 15:33 | |
| kfox1111_ | due to all the constraints of openstack templating, all we ever see is "single server to do..." | 15:33 |
| *** reed has quit IRC | 15:34 | |
| *** reed has joined #openstack-app-catalog | 15:34 | |
| kfox1111_ | and the nova folks have turned up their noses at instance users, again. | 15:34 |
| kfox1111_ | docaedo: I'm starting to think that the TC is the only org that has a hope of solving this. | 15:35 |
| kfox1111_ | do you think we should bring the TC in on it? Otherwise, I think the app catalog will continue to struggle. | 15:36 |
| docaedo | I am not opposed to involving the TC in anything, I don't think having instance users would have any measurable impact on the app catalog | 15:39 |
| kfox1111_ | why does everyone thing secret storage and retrieval is unimportant to applications? | 15:41 |
| kfox1111_ | think? | 15:41 |
| kfox1111_ | its usually less important for single server deployments, but is critical for multiserver deployments. | 15:41 |
| kfox1111_ | its why we tend to only see "single server template for X..." getting contributed, instead of something that actually needs a cloud. | 15:41 |
| docaedo | I would venture it's because the openstack devs working on openstack servers are not building openstack applications | 15:41 |
| docaedo | So people are definitely using heat templates to solve complicated multi-server problems | 15:43 |
| kfox1111_ | right. | 15:43 |
| docaedo | but I don't think the templates they are building are useful for other people in a generic sense | 15:43 |
| kfox1111_ | but not in a way that is contributable. | 15:43 |
| kfox1111_ | exactly. | 15:43 |
| docaedo | instance users, conditionals, something else would help | 15:43 |
| kfox1111_ | which hurts the app catalog. | 15:43 |
| kfox1111_ | all of those are important. | 15:43 |
| kfox1111_ | and I'm loosing faith that openstack will address the issues before openstack becomes largely irrelevant. :/ | 15:43 |
| kfox1111_ | it has folks attention now. if it doesn't address the elephants in the room, someone else will. (and are) | 15:44 |
| docaedo | I think my view would be that the most important thing those impact will be the application developer ecosystem more so than the app catalog. The ecosystem has to exist fist really | 15:44 |
| kfox1111_ | agreed. and its unhealthy. :/ | 15:44 |
| kfox1111_ | which leads to an unhealthy app catalog. :/ | 15:44 |
| kfox1111_ | single server apps are easy to write. most folks can just do that themselves. | 15:45 |
| kfox1111_ | its the multiserver ones that are harder, and need a real cloud dev to do. and benefit most from a cloud by adding scaling and fault tollerence. | 15:45 |
| docaedo | depends on the audience you're serve - there's a *much* larger audience for whom single server apps are mysterious and scary | 15:46 |
| kfox1111_ | but those can't be contributed/easily consumed under the current model. | 15:46 |
| kfox1111_ | but *pets* | 15:46 |
| kfox1111_ | we tell users keep your *pets* off the cloud. and then we have an app catalog that favor's them. :/ | 15:46 |
| kfox1111_ | how can our users trust us when we start off with a fundimental assumption counter to the one made at the heart of what a cloud is about? | 15:48 |
| docaedo | on the other hand, does AWS have an equivalent? A place where you can find multi-server "cloud apps"? | 15:48 |
| kfox1111_ | if we wait for amazon, then we will always be following amazon, and they eventually will rule the world of clouds (they are pretty close already) | 15:49 |
| kfox1111_ | they really don't care if people throw pets up because they still can kill them and get the mony for them existing for a while. | 15:50 |
| kfox1111_ | it makes for a worse user experience, but they can claim, you've been warned, and they get more money by at least having lots of pets in the cloud for a while. | 15:50 |
| kfox1111_ | openstack's not about that. | 15:51 |
| kfox1111_ | or shouldn't. | 15:51 |
| docaedo | well the point I'm making isn't so much that we need to copy amazon - it's that it's a "market" that doesn't really exist, so even ignoring amazon, does anyone have a "marketplace" for cloud-scale apps? | 15:55 |
| kfox1111_ | it can't exist until someone removes enough of the road blocks preventing it. once those are gone, the market will be created, and the first cloud there will have a huge leg up over the others. | 15:56 |
| kfox1111_ | this has happened time and time again in capitalism. | 15:56 |
| kfox1111_ | the old guard doesn't think a market is important. they don't do anything to let it be. | 15:57 |
| kfox1111_ | someone new comes in and makes something easy that use to be hard. | 15:57 |
| kfox1111_ | a new market flurishes. | 15:57 |
| kfox1111_ | the old guard scramble to catch up, and some die. | 15:57 |
| kfox1111_ | The cloud itself is one example of it. | 15:58 |
| kfox1111_ | but then we so quickly forget that we have to innovate and push forward, or someone else will. | 15:58 |
| docaedo | Couldn't a cloud-scale app like this be packaged/managed via ansible? | 16:01 |
| *** kebray_ has quit IRC | 16:01 | |
| kfox1111_ | its more possible to write a cloud scale app with ansible, but can't do stuff like autoscaling. | 16:01 |
| kfox1111_ | I think ansible's grown out of the non cloud world, and adapted pretty well to living in the cloud world, but it still has some fundimental assumptions in it that make it a less then ideal ultimate solution. | 16:02 |
| kfox1111_ | if you use it in a centrial place to control the nodes, | 16:02 |
| kfox1111_ | you can rely on securtiy of your secrets, but then you can't do stuff like autoscaling, self healing, etc because a human has to be there. | 16:03 |
| kfox1111_ | if you move ansible to the individual nodes, then you need instance users to provide security, and then autoscaling works. | 16:03 |
| docaedo | I agree that all of this stuff would be awesome to have for OpenStack :) | 16:04 |
| docaedo | Sorry if I sound overly negative or pushing back too much on this | 16:04 |
| kfox1111_ | sokay. It seems like only those who have tried to make autoscaling templates have tripped across these things. Then push hard for, why do we need such and such? | 16:05 |
| kfox1111_ | the same exact thing was said about the cloud itself. why is the old way not good enough? | 16:06 |
| docaedo | Just think there are a bunch of fundamental things that need to come together to make it happen, I think the conversation/consideration is even bigger than instance users | 16:06 |
| kfox1111_ | well, it mostly is good enough, except for ... | 16:06 |
| kfox1111_ | yeah. | 16:06 |
| kfox1111_ | but I'm not sure how to get there , when our attention span is usually 10 minutes, and tops out at 50 minutes at the summit. | 16:06 |
| docaedo | honestly I think Randy Bias was hitting on some of this like two years ago (digging for the post) | 16:06 |
| kfox1111_ | yeah. | 16:07 |
| kfox1111_ | it comes up periodically, then people push back, and folks give up, until someone new comes along and the cycle repeats. | 16:07 |
| docaedo | http://www.slideshare.net/randybias/the-lie-of-a-benevolent-dictator-the-truth-of-a-working-democratic-meritocracy | 16:07 |
| docaedo | it's not the whole solution exactly, but points at the same symptoms and talks about what could help | 16:08 |
| docaedo | it's about that disconnect between what the devs are creating with all their openstack projects, and what the users/consumers of openstack need most | 16:09 |
| kfox1111_ | yeah. that. | 16:09 |
| kfox1111_ | we need a TC that will lead at times when the individual projects can't see the forest through their tree. | 16:10 |
| kfox1111_ | which is why I was thinking we might have to take the issue to them. | 16:10 |
| kfox1111_ | cross project only seems to cover cases where all the silo's agree there is a problem. | 16:10 |
| kfox1111_ | nova doesn't think there is a problem, | 16:11 |
| kfox1111_ | or at minimum doesn't believe it is their problem to care about. | 16:11 |
| docaedo | I think solving this is in the User Committee's charter more than anyones | 16:14 |
| kfox1111_ | yeah, but where does the user committee get its power? do they have any other then to make suggestions? | 16:17 |
| docaedo | and big overlap with the interop efforts as well | 16:17 |
| kfox1111_ | true. | 16:17 |
| kfox1111_ | cuase suggesting stuff hasn't been working... | 16:17 |
| docaedo | nobody has any more power than making suggestions, do they? | 16:17 |
| kfox1111_ | to be fair, neither has putting up code. :/ | 16:17 |
| kfox1111_ | the tc does. | 16:17 |
| kfox1111_ | all the silo's had to submit to decisions of the TC. | 16:17 |
| kfox1111_ | if the TC says, you need functionality X for the better good of openstack, even though it makes your project a bit harder, then they are obligated to allow the functionality in. | 16:17 |
| jroll | are they, though? what's the consequence of not allowing it, even after the TC says they should? | 16:18 |
| kfox1111_ | I believe they can kick out the ptl until they find one that will allow it. | 16:19 |
| kfox1111_ | or kick the project out of the tent. | 16:19 |
| jroll | I can only imagine the storm that would happen if that happened | 16:19 |
| jroll | especially booting nova out of openstack, heh | 16:19 |
| kfox1111_ | they must submit to oversite by the TC as a condition to being in openstack. | 16:19 |
| kfox1111_ | yeah, so the TC shouldn't abuse it. | 16:19 |
| kfox1111_ | and the projects should think very carefully when the TC is willing to actually say they need X or Y. because they won't do it very often. | 16:20 |
| kfox1111_ | heh... the [app] workgroup seems to have a very different definition of app then i do. :/ | 16:21 |
| *** pcaruana has quit IRC | 16:21 | |
| kfox1111_ | their examples are all "I want to write a program that uses the openstack api" | 16:21 |
| kfox1111_ | not, "I want a cloud scaled application that runs on openstack that is easy to deploy as a unit (app)" | 16:22 |
| docaedo | think is the TC would only wield that kind of power in an extreme circumstance - if the user committee and TC can be convinced of a clear vision of how things could be implemented | 16:22 |
| docaedo | *thing | 16:22 |
| docaedo | and yes, I believe your view of an openstack application is a little different from the consensus view | 16:23 |
| kfox1111_ | yeah. | 16:23 |
| kfox1111_ | to both. | 16:23 |
| kfox1111_ | my defnition is important too. its just a few years ahead of where a lot of folks are thinking, I think. | 16:24 |
| kfox1111_ | unfortunately, I few years will probably show us ubernetes in kubernetes plus multitenancy. | 16:24 |
| kfox1111_ | and at that point, why bother deploying openstack? it will be easier to deploy kubernetes. :/ | 16:24 |
| kfox1111_ | for those with pets that are in the cloud, then openstack will probably become another cloud app (by my definition) deployed by kubernetes templates using kolla. | 16:25 |
| kfox1111_ | and nich itself in for those who only care about iaas. which will be a diminishing number of users. | 16:25 |
| docaedo | too many turtles there for me! | 16:25 |
| kfox1111_ | k. well, in a few years, we'll see. :) | 16:26 |
| kfox1111_ | containers really are changing the cloud world drastically. | 16:27 |
| docaedo | That I completely agree with | 16:27 |
| kfox1111_ | its very interesting to see the new cloud verses the old cloud, when the old cloud really isn't that old. | 16:27 |
| docaedo | for sure interesting times | 16:27 |
| kfox1111_ | the old cloud still thinks its safe because its 'new'. | 16:27 |
| kfox1111_ | But it feels like they are anoying those that need the new cloud use case, and are pushing those developers out. which means the new cloud stuff gets more developers. :/ | 16:28 |
| kfox1111_ | I still think openstack has a huge role to play, if they don't loose site of what makes the cloud awesome. but I'm afraid that's been lost more to visions of providing a vmware alternate. | 16:29 |
| *** kfox1111_ is now known as kfox1111 | 16:32 | |
| docaedo | well openstack isn't in danger of losing, all of the massive deployers who need to manage diverse infrastructure are choosing OpenStack. But they're choosing it because they need an invisible IaaS so they can get resources via API | 16:33 |
| docaedo | they're not counting on it also providing a perfect application layer, as their users aren't even comfortable getting VMs from an API call yet let alone re-thinking their entire app architecture | 16:34 |
| docaedo | "massive developers" is not the right phrase, maybe I mean "massive organizations" (telcos, companies like walmart, etc) | 16:35 |
| kfox1111 | yeah. the teloc's and walmart etc, will be just fine with openstack. | 16:44 |
| kfox1111 | I think teloc's will have to continue with it, since their use case is really anticontainer friendy at the moment. | 16:45 |
| kfox1111 | walmart on the other hand, could probably mostly drop openstack in a hot second and use something like kuberenetes. | 16:45 |
| kfox1111 | it was built for scalable web apps. | 16:45 |
| kfox1111 | openstack could see one if its beggest users mostly vanish in between 2 summits. | 16:46 |
| kfox1111 | s/if/of/ | 16:46 |
| kfox1111 | same thing happened with openstack in the first place. they want from like 10% usage of openstack, to 100% very quickly. | 16:46 |
| docaedo | nah, kubernetes solves some problems but it's not a panacea, and it's not an IaaS | 16:47 |
| kfox1111 | yeah, b ut they don't need iaas. | 16:47 |
| kfox1111 | thats the point. | 16:47 |
| kfox1111 | for example, we're running our physics cloud with one vm per compute host. | 16:47 |
| kfox1111 | a couple hundred servers. | 16:47 |
| kfox1111 | we then moved the compute task into a container on that vm, because we had issues with not having the exact same compute environment on all hosts. | 16:48 |
| kfox1111 | (version skew) | 16:48 |
| kfox1111 | likely, if kubernetes matures in the next 6 months, we will remove the vm layer, and just go back to physical hardware with the containers on top. | 16:48 |
| kfox1111 | so our openstack cloud will shrink to about 9 servers, and the rest will be in a kubernetes managed cluster. | 16:48 |
| kfox1111 | and of the remaining 9 servers, | 16:49 |
| kfox1111 | about 40% of the vm's on them contain their servers entirely in containers, which could be moved out too.... | 16:49 |
| kfox1111 | the problme with IaaS is that it provided a great api for cloud app developers to treat things that use to not be automatable, as automatable. | 16:50 |
| kfox1111 | but wasn't a perfect match. iaas refused to provide the api's they really cared about. for example, instance users. | 16:50 |
| kfox1111 | but now that containers are a thing, and those systems are starting to provide what the users truely want, iaas will shrink. | 16:51 |
| kfox1111 | for example: http://kubernetes.io/docs/user-guide/secrets/ | 16:52 |
| kfox1111 | its a thing, and its a thing *today*. | 16:52 |
| docaedo | It's possible but I still don't think the industry is going to move so quickly towards containers that it'll kill off big OpenStack deployments | 16:52 |
| kfox1111 | barbican's a thing, but its a thing, maybe a year from now. | 16:52 |
| kfox1111 | this is why I think openstack's niching itself into a corner. because one of my primary clouds is witnessing it first hand. openstack was 100% usage. it may quickly become 10% or less. | 16:53 |
| kfox1111 | yeah, I think openstaack will stick around in a lot of places. but it won't be the crown jewel anymore. thats if openstack doesn't start making some important changes. | 16:54 |
| kfox1111 | it still totally could. :/ | 16:54 |
| kfox1111 | but doesn't seem to want to. :/ | 16:55 |
| kfox1111 | I really really want to see openstack succeed in the cloud world. but I'm seeing more and more failed promices from it. | 16:55 |
| kfox1111 | and nova's top of the list feature for mitaka is "Live migration improvements" | 16:56 |
| kfox1111 | the top pet request of them all. | 16:56 |
| docaedo | Wonder if this is remotely applicable to the solution? http://lists.openstack.org/pipermail/openstack-dev/2016-April/092524.html (haven't looked closely TBH but "users self managing roles without being admin" sounds promising) | 16:56 |
| kfox1111 | yeah. last summit, there was a lot of discussion at the instance user talk about coming up with a new proxy service to wrap around all the other projects since they couldn't be bothered with adding securtiy to their own projects.... | 16:57 |
| kfox1111 | as an op, that scares me big time. | 16:58 |
| kfox1111 | now you just add a whole nother layer of securty handling code that will contain bugs and can potentially be a security exploit waiting to happen. :/ | 16:58 |
| kfox1111 | we're now coming up with technical solutions to political problems! which is usually the death nell of projects. | 16:59 |
| kfox1111 | they basically have to reimplement every projects api in their own api, with security extensions. the risk of them getting out of sync is very large. :/ | 17:00 |
| kfox1111 | bbiab | 17:01 |
| *** toddjohn_ has quit IRC | 17:11 | |
| *** toddjohn_ has joined #openstack-app-catalog | 17:12 | |
| *** toddjohn_ has quit IRC | 17:17 | |
| *** kzaitsev_mb has quit IRC | 17:28 | |
| *** kairat_ has joined #openstack-app-catalog | 17:34 | |
| *** kairat_ has left #openstack-app-catalog | 17:35 | |
| *** kairat_ has joined #openstack-app-catalog | 17:35 | |
| *** kairat_ has left #openstack-app-catalog | 17:35 | |
| *** kairat_ has joined #openstack-app-catalog | 17:36 | |
| *** kairat_ has left #openstack-app-catalog | 17:36 | |
| *** toddjohn_ has joined #openstack-app-catalog | 17:49 | |
| docaedo | kfox1111: Also will be sure to get some time in Austin with you and David Flanders, he's heading up community stuff for the foundation and is leading the charge from their side with respect to the app dev community | 17:49 |
| *** pvaneck has joined #openstack-app-catalog | 17:56 | |
| *** kzaitsev_mb has joined #openstack-app-catalog | 18:50 | |
| *** kzaitsev_mb has quit IRC | 19:36 | |
| *** kzaitsev_mb has joined #openstack-app-catalog | 19:58 | |
| *** kzaitsev_mb has quit IRC | 20:10 | |
| kfox1111 | docaedo: awesome. thanks. :) | 20:10 |
| *** kzaitsev_mb has joined #openstack-app-catalog | 20:15 | |
| *** toddjohn_ has quit IRC | 20:21 | |
| *** toddjohn_ has joined #openstack-app-catalog | 20:22 | |
| *** kzaitsev_mb has quit IRC | 20:22 | |
| *** toddjoh__ has joined #openstack-app-catalog | 20:24 | |
| docaedo | kfox1111 kzaitsev_ws - any concerns/feedback for https://review.openstack.org/#/c/305893/ ? Looks pretty good to me | 20:25 |
| *** kzaitsev_mb has joined #openstack-app-catalog | 20:26 | |
| *** toddjohn_ has quit IRC | 20:27 | |
| *** toddjoh__ has quit IRC | 20:29 | |
| *** kzaitsev_mb has quit IRC | 20:35 | |
| kfox1111 | docaedo: I don't see anything wrong with it with a quick glance. | 20:35 |
| kfox1111 | the zip/yaml thing is a little unsettling though. | 20:42 |
| kfox1111 | are the flags different on the cli depending on the type? | 20:42 |
| kfox1111 | I'd still like to see the usage issues addressed quickly before we put too many thingy's in there. | 20:42 |
| docaedo | what's unsettling? just two different formats where csar is the container | 20:48 |
| kfox1111 | we really need to add an cli thingy like: http://apps.openstack.org/#tab=glance-images&asset=AeroFS%20Private%20Cloud | 20:49 |
| kfox1111 | do we have what we need to do so? | 20:49 |
| docaedo | it depends on how the user wants to actually consume it - we don't have that for heat or murano stuff | 20:51 |
| *** kzaitsev_mb has joined #openstack-app-catalog | 20:51 | |
| kfox1111 | we kind of have it for murano. heat, I agree we should have that too. | 20:53 |
| kfox1111 | right now, we have a really terrible ui on the web site usability wise. :/ | 20:54 |
| kfox1111 | I'm hoping to fix it as part of the common code fix too, but need enough information to know what the cli should look like. | 20:56 |
| kfox1111 | I know what it should look like for heat. I think I know what it is for murano. no clue for tosca | 20:56 |
| docaedo | Tosca usage: http://docs.openstack.org/developer/heat-translator/usage.html | 20:58 |
| kfox1111 | I see no reference to zip there. | 20:59 |
| docaedo | I disagree that the UI is terrible from a usability perspective - but it depends on what you are expecting from it. Sounds like you want the UI to handle everything for the user, so they can just blindly click around and things will magically be installed for them? | 20:59 |
| kfox1111 | is it expected that the user would unzip it and run parts of it? | 20:59 |
| *** kzaitsev_mb has quit IRC | 20:59 | |
| kfox1111 | computers are good at mindless repeditive tasks. humans are not. here... try one for me. run this command and return me the results without pasting: | 21:00 |
| kfox1111 | echo f14fa88548464736bbcf53bb2b7b02de | 21:01 |
| kfox1111 | the ui there is horible. | 21:01 |
| kfox1111 | just a simple tweak, and it is at least 10% more likely the user can do the task. | 21:01 |
| kfox1111 | echo f14fa885-4846-4736-bbcf-53bb2b7b02de | 21:01 |
| kfox1111 | a little bit of usability tweaking can really go a long way to making something better. | 21:02 |
| *** kzaitsev_mb has joined #openstack-app-catalog | 21:02 | |
| kfox1111 | now add the ability to paste... it becomes hopefully almost 100% :) | 21:03 |
| docaedo | I don't disagree on that, I just disagree on blocking adding content that's usable by a lot of people. I honestly think the entire heat section should be removed from the catalog, it's a complete waste of space, does nothing useful for the catalog :) But I can't fix Heat's problems from the app catalog, I can only index heat assets | 21:04 |
| kfox1111 | heh. I think the definition of alot there is a bit overblown... :/ | 21:05 |
| kfox1111 | I don't think heat's section is all that different then tosca really. | 21:05 |
| kfox1111 | heat's at least works with a click in horizon. tosca, I'm not sure what to do with. its not archetected right. | 21:05 |
| kfox1111 | it really seems like it should be plugged into heat, as an alternate format to hot. | 21:05 |
| docaedo | fair, but I think the tosca examples in that review are more useful than the heat ones at least, and there's an active effort from the TOSCA folks to be engaged and use this. Remind me how many heat people have been interested in helping? | 21:06 |
| kfox1111 | that I agree with. | 21:06 |
| kfox1111 | I get the point. I guess we're optomizing for different things. | 21:06 |
| kfox1111 | I'm trying to optomize for user experience. your trying to maximise content. | 21:07 |
| kfox1111 | both are valuable. | 21:07 |
| kfox1111 | For the record, I'm not blocking either. blocking and not pushing are different things. | 21:07 |
| docaedo | I agree too - also I'm not opposed to adding more to the UI to make assets easier to use, but I think the two efforts are independent | 21:08 |
| docaedo | you're completely right, my use of blocking was unfair hyperbole, I apologize :) | 21:08 |
| kfox1111 | one makes more work for the other. When you have little resource, | 21:08 |
| kfox1111 | the incentive to get your content in can be enough to improve usability. | 21:08 |
| kfox1111 | if let in easy, then the incentive goes away. | 21:08 |
| kfox1111 | no worries. I'm not mad. just pointing it out. :) | 21:08 |
| docaedo | I'm glad we're talking about this stuff and considering it, I'm very hopeful we'll get a bunch more people involved in the conversation from the user committee side, and app dev eco side, etc. | 21:08 |
| kfox1111 | +1. :) | 21:09 |
| kfox1111 | we didn't allow the hello world tocsa app in right away either. we pushed back a bit and got the user interface stuff in at the same time. | 21:09 |
| kfox1111 | and it got done. :) | 21:09 |
| kfox1111 | though the horizon stuff hasn't... | 21:10 |
| kfox1111 | (There's a start of a patch for that waiting review though) | 21:10 |
| kfox1111 | I had to do it. | 21:10 |
| kfox1111 | It just shows the asset thoguh. no way to actually consume it. | 21:10 |
| kfox1111 | so I'm not sure its worth showing in the ui or not. | 21:10 |
| *** spzala has quit IRC | 21:14 | |
| kfox1111 | right now, it unchecks the checkbox for tosca, since they are not launchable, but still allows the user to check the box, then search through them. | 21:14 |
| kfox1111 | figured that might be a good middleground. | 21:14 |
| docaedo | sounds like a good approach to me | 21:14 |
| kfox1111 | but if the user finds something they like, there's not an easy way to have them deploy it. | 21:15 |
| *** spzala has joined #openstack-app-catalog | 21:36 | |
| *** spzala has quit IRC | 21:36 | |
| *** spzala has joined #openstack-app-catalog | 21:36 | |
| openstackgerrit | Kirill Zaitsev proposed openstack/app-catalog: Add glare artifacts plugin for app-catalog asset types https://review.openstack.org/276857 | 21:46 |
| openstackgerrit | Kirill Zaitsev proposed openstack/app-catalog: Add script to upload assets to glare https://review.openstack.org/281602 | 21:46 |
| openstackgerrit | Kirill Zaitsev proposed openstack/app-catalog: Allow using glare for v1 API call and add v2 proxy https://review.openstack.org/290932 | 21:46 |
| openstackgerrit | Kirill Zaitsev proposed openstack/app-catalog: Implement UI for listing artifact drafts for glare assets https://review.openstack.org/292854 | 22:01 |
| openstackgerrit | Kirill Zaitsev proposed openstack/app-catalog: Add UI for adding artifact drafts to glare https://review.openstack.org/293644 | 22:01 |
| kfox1111 | docaedo: see the magnum cross COE talk is at the same time as the app catalog meeting? | 22:06 |
| docaedo | yep, saw that :( | 22:17 |
| docaedo | yep, saw that :( | 22:17 |
| kfox1111 | yeah.... I gave them the minimum api I think we might be interested in. hopefully at least that gets considered. | 22:17 |
| kfox1111 | ..... this is.... interesting... https://github.com/openstack/ec2-driver | 22:18 |
| kzaitsev_mb | it might be not too late to request some swap. I believe I saw a letter from fuel guys about it. (I might be wrong and they were swapping their own things) | 22:18 |
| docaedo | that ec2 driver is interesting | 22:22 |
| kfox1111 | no idea how that would work with neutron tenant networks. I'm guessing it doesn't. :/ | 22:23 |
| kfox1111 | if they could solve that though, I'd me much more in favor to bursting to aws then I am now. | 22:23 |
| docaedo | yeah it can't unless it also pipes in a VPN to the private side of your AWS network (which is technically not that difficult) | 22:24 |
| docaedo | I think that approach trades a lot of technical debt for the occasional convenience of having an extra set of VMs somewhere else | 22:25 |
| *** toddjohn_ has joined #openstack-app-catalog | 22:26 | |
| kfox1111 | yeah. I like k2k federation to a real openstack cloud much better. | 22:26 |
| kfox1111 | but aws is requested a lot by name in proposals around here. :/ | 22:26 |
| kfox1111 | this at least provides enough to claim aws support while still being 100% openstack api. | 22:27 |
| docaedo | Unless I missed something, that's almost a year old though | 22:28 |
| kfox1111 | yeah. I was surprised by that too. but it was mentioned in the mitaka nova release notes. | 22:29 |
| *** toddjohn_ has quit IRC | 22:30 | |
| *** toddjohn_ has joined #openstack-app-catalog | 22:31 | |
| kfox1111 | hmm.. no, I was mistaken. I still had the liberty release notes up too. I think it must have been that I was looking at. | 22:32 |
| *** toddjohn_ has quit IRC | 22:34 | |
| openstackgerrit | Merged openstack/app-catalog: Update to Fedora 23 Atomic 20160405 release https://review.openstack.org/307234 | 22:34 |
| kfox1111 | heh.... | 23:10 |
| kfox1111 | glance tasks api was suposed to replace the v1 api for upload from url? | 23:10 |
| kfox1111 | cause mitaka claims tasks api is now admin only by default... | 23:11 |
| *** toddjohn_ has joined #openstack-app-catalog | 23:13 | |
| docaedo | goodness so weird and such a user-hostile change. That one I still don't understand the thinking behind | 23:14 |
| kfox1111 | argg...... | 23:21 |
| kfox1111 | so they deprecated importing an image from url in v1, by adding it as a task in the task api via v2. | 23:21 |
| kfox1111 | then they removed it in favor of an import api. | 23:21 |
| kfox1111 | but I can't find reference to that in the api docs anywhere. | 23:22 |
| kfox1111 | what the heck. | 23:22 |
| kfox1111 | see deprication notes second bullet here: http://docs.openstack.org/releasenotes/glance/mitaka.html | 23:22 |
| kfox1111 | uh oh... | 23:35 |
| kfox1111 | they made the angular launch instance workflow the default in Mitaka Horizon... | 23:35 |
| kfox1111 | I don't think we ever tested that code path with the horizon plugin. | 23:35 |
| kfox1111 | It may or may not work. :/ | 23:35 |
| kfox1111 | heh... "All Volume related panels in Horizon that previously used the term GB and gigabyte have been replaced with GiB and gibibyte." | 23:47 |
| kfox1111 | and fallout from that lawsuit continues... | 23:47 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!