Friday, 2015-07-31

docaedoI like it - going to run locally for personal sanity and low-rent QA :)00:00
kfox1111ok. sounds good. :)00:03
kzaitsev_mbso service then. sounds better =)00:04
kfox1111yeah. the code in the ui plugin will basically be, if x.service.type not in keystone service catalog, hide00:05
kzaitsev_mband those are service-specific parameters, I kind of like it =)00:14
kfox1111yeah. should make it very easy to add solum language packs once we're merged.00:15
kfox1111would just add a small subsection at the end of the schema for their required params.00:15
kzaitsev_mbplanning to add murano there later? =)00:16
kfox1111just doing it a piece at a time. :)00:16
kfox1111didn't want the review to get too big.00:17
kfox1111doing both glance and heat was a bit large.00:17
kfox1111for my tastes anyway.00:17
kzaitsev_mbyeah, openstack suffers from inability to split patches into smaller chunks, sometimes =)00:18
kfox1111I think its because reviews are usually somewhat painful.00:18
kfox1111so devs batch them up so there is less reviews. :/00:18
kfox1111yay. the horizon patch is top on the list now. :)00:21
kfox111115 hr 56 min. :/00:21
kzaitsev_mbzuul seems to behave even stranger now.. a bunch of tasks in check queue that have eevrything green, but stay in check queue =/00:21
kzaitsev_mbnpm test failed00:22
kzaitsev_mblooks like a legit fail.
kfox1111ak. cool. that I can work with.00:24
kfox1111ah. cause I think I copied just a little too much of the glance.service.spec.js00:26
kzaitsev_mbso... another 15 hours then =(00:26
kfox1111hopefully not that long. :)00:26
*** kzaitsev_mb has quit IRC00:31
kfox1111arg. I wonder how long this new commit's going to take. the one earlier today only took a few minutes...00:33
kfox1111wonder if the gate's snarled up again.00:33
kfox1111well, I'll just push the app catalog ui changes anyway. it should work once catches up.00:37
kfox1111gota head out. l8r.00:37
openstackgerritMerged stackforge/apps-catalog: Make glance and heat share a common schema.
*** openstackgerrit has quit IRC02:31
*** openstackgerrit has joined #openstack-app-catalog02:31
*** ig0r_ has joined #openstack-app-catalog05:25
*** kebray has joined #openstack-app-catalog05:47
*** ig0r__ has joined #openstack-app-catalog06:11
*** ig0r_ has quit IRC06:12
*** kebray has quit IRC07:43
*** rhagarty_ has quit IRC08:37
*** rhagarty has quit IRC08:37
*** rhagarty has joined #openstack-app-catalog08:38
*** kzaitsev_mb has joined #openstack-app-catalog10:29
*** ig0r__ has quit IRC11:15
*** ig0r_ has joined #openstack-app-catalog11:19
kfox1111yay! :)15:09
*** kebray has joined #openstack-app-catalog15:18
openstackgerritKevin Fox proposed stackforge/apps-catalog-ui: Update README locations.
kfox1111zuul looks happier today.15:22
openstackgerritMerged stackforge/apps-catalog-ui: Update README locations.
docaedojust in time for sysadmin day!15:27
openstackgerritKevin Fox proposed stackforge/apps-catalog: Add CirrOS
kfox1111j^2: You alive? :)15:41
j^2On the road ATM15:53
j^2Driving to Oklahoma from central Texas15:54
j^2No real computer usage for the time being :(15:55
kfox1111ah. k. vacation? work?15:56
j^2Family trip for my wife's cousin or something. I wouldn't call it vacation per se15:57
j^2I finally get to listen to Armada though, been holding off reading seeing anything about it for this trip15:58
openstackgerritKevin Fox proposed stackforge/apps-catalog: Add CirrOS
kfox1111I'm really starting to like this web ui. :)16:03
kfox1111wanted cirros, clicked install, got it. :)16:03
kfox1111(ignoring that it wasn't in the catalog at the time... )16:04
*** Alec has joined #openstack-app-catalog16:22
Alechi there, I woudl like to add a new glance image to the catalog, anybody knows how to upload the image file (qcow2)  to the storage at
openstackgerritKevin Fox proposed stackforge/apps-catalog-ui: Sort assets by name
kfox1111Hi Alec.16:31
kfox1111I didn't know we had that...16:31
kfox1111docaedo: any ideas about
Alecthere are bunch of images in th ecatalog that are stored there:16:33
Alec        url:
Alec        url:
kfox1111Yeah. not sure how they get in there either. I was thinking everything was remote.16:37
kzaitsev_mbnope, I think someone should have access there16:46
Alecok I'll try to ask the mailer, as I see at least 2 people placing their images there. This is not documented anywhere, perhaps they do not want too many people storing there  ;-)16:49
docaedoYes, right now I have access16:55
docaedoit's rackspace files, set up initially by Mirantis16:55
docaedothe intention was that it would be replaced either with automated access to a swift store on openstack infra, or "something else"16:56
docaedothe "something else" should be glance v3 I think, at which point binary assets would be stored there easily16:57
docaedoI think right now there are just a few glance images at plus the murano zip files (application packages)16:57
docaedobefore vancouver summit we were talking about a few different ways we might automate importing things into that store, but decided to hold off as it seemed unlikely that would be the long term model, and agreed that if there was a flood of binary assets to ingest, we would re-address17:00
kfox1111makes sense.17:01
Alecdo you know who would be the contact to ask permission to store an image there? I just need to store a small ubuntu image (300MB)17:01
Alecit is for teh new openstack project kloudbuster17:01
docaedoAlec: try pinging "docaedo" :)17:01
kfox1111does github allow binaries?17:01
Alecgit is terrible at storing binaries17:02
kzaitsev_mbkfox1111: it does =) but usually it is considered an antipattern to store binaries in git =)17:02
docaedoAFAIK github does allow storage of binaries, but it starts to get complicated if they get large, or get a lot of traffic17:02
Alecalthough github might allow anything, have not tried17:02
kzaitsev_mbafter all you can store png/jpg files in git, don't you? =)17:02
kfox1111ah. KloudBuster sounds cool. :)17:02
docaedoAlec: I can add the image to the app catalog storage today, just include the URL to retrieve it from and the hash in the commit message that lists it in glance assets17:03
kfox1111I was thinking more the tarball artifacts that come from a git repo.17:03
kzaitsev_mbalso git clone would become super slow very fast (cause it would need to checkout the objects, to allow you to revert to any revisions, AFAIU)17:04
Alecdocaedo: thanks, can I contact you offline when the image is ready? Also need to see how to update it if needed later17:04
kfox1111yeah, not saying images should go into git itself.17:05
kfox1111on sourceforge, they had scm, but also a artifact section for storing release tarballs. not sure if github has something like that.17:05
Alecthere are a few file hosting servers out there but would rather use something "local"17:06
docaedoAlec: you can ( but it's probably not necessary - just include Image-URL and Image-hash in the commit message ( and I'll sort it out when the CR comes in17:07
docaedo+1 for using the current app catalog storage - it's not ideal but it will get us through the next few months while we shore this all up17:08
Alecdocaedo: you mean you will make the copy at review time? You'd need to provide me the  URL to the final location so I can update the yaml file17:09
docaedoBetter than using a file hosting service and then either having super slow download, or seeing the image cut off from too many downloads or something17:09
docaedoAlec: the wiki has an example, it would look like:17:09
docaedoattributes: url: hash: dd69232d1a745a7b237bd8d5e9e8485a17:10
docaedooops, make that three lines :)17:10
docaedo  url:
docaedo  hash: dd69232d1a745a7b237bd8d5e9e8485a17:10
Alecright, but as I understand I provide you (in the review) the temporary URL with hash and you copy it to storage.apps.openstack.org17:11
Alecand I'll have to update the url in the yaml file to point to the final location17:11
docaedoCorrect - so your commit message tells the reviewer where to get it, and then the reviewer will fetch it, confirm hash matches, and then push up to<your-image-name>17:12
docaedoso your entry in the YAML should list it at, and the commit message should indicate where to get it BEFORE that17:12
AlecOk got it ;-)17:13
Alecthanks a lot, saves me a lot of time finding a storage place!17:13
docaedocool :) not totally obvious, but we picked that approach as it would give us a kind of two-step way to pull in binary assets (and the intent originally was to fully automate that anyway, so jenkins would fetch and verify hash, then push up to rackspace files)17:14
docaedoeven moving to glance v3 backend, we'll probably want to use that same approach17:14
AlecI'm sure the openstack foundation can fund some storage place (at rackspace or anywhere) to store all the images17:18
Alecthe easier it is the more apps/images you will get17:18
kfox1111I'm kind of on the fence. I think if openstack's providing the images, it should have some way to manage the internals too.17:18
kfox1111like dib elements, etc. so if there are security issues with the images, we can quickly rebuild them.17:19
kfox1111If they are external links, its up to others to maintain it.17:19
docaedo-1 on taking responsibility for rebuilding anyones image :)17:19
kfox1111then why should we store them?17:19
Alecthat should be the responsibility of the provider. In my case kloudbuster will commit the dib config within the koudbuster openstack repo17:19
kfox1111its not dissimilar to the heat template repo where we gate them to ensure they work.17:20
docaedouser convenience - look at docker hub (I know I trot that out all the time, but that was one of the motivations).  They host all kind of stuff, and it's on the user to determine if they want to use it or not17:20
docaedoside effect is good performance on fetching stuff17:20
kfox1111yeah. then the openstack provided storage would just build with that and post the artifacts.17:20
Alecright and vote by popularity will move the good stuff up and the broken stuff down17:21
kfox1111that way, if ubuntu or whatever releases a fix for the next insert random exploit here (a lot recently...) jenkins just takes care of it for us.17:21
Alecdoes app store provide any tracking of usage and downloads?17:21
docaedorequiring an image be built by DIB limits what can get in the catalog17:21
kfox1111except most users don't pay much attention to security :/17:21
docaedoapp catalog does not provide tracking right now, but it's something we want in the future (as well as votes, feedback, etc.)17:21
kfox1111see the meriod of exploatable Andorid phones and Cars these days. :/17:21
docaedowe can't take any responsibility for security AT ALL, because then we are on the hook for any issues anyone experiences17:22
kfox1111docaedo: google took the same stance with the google market.... origionally...17:23
kfox1111the reality is, users will judge the catalog by whats in it, wheher its really the app catalogs responasability or not. :/17:23
docaedosure, so a good mechanism for users to provide feedback (upvote the good stuff, flag the bad) is as good a solution as we will get17:24
openstackgerritMerged stackforge/apps-catalog: Add CirrOS
kfox1111best mechanism for generic stuff, I agree.17:24
kfox1111if its stuff provided by openstack itself, we might be able to do a bit better then that.17:24
docaedoThe openstack foundation is not going to be in a position to guarantee/support/maintain content that lands in the catalog17:24
docaedook, in this case, who is "openstack itself"?17:25
kfox1111like sahara images. if theyu are built using dib, we can just periodically update them automatically.17:25
kfox1111openstack itself being projects in the tent.17:25
docaedook something that would be pretty cool for the app catalog17:25
docaedowould be a mechanism to kick off DIB with a config17:26
kfox1111I've done it with some of my projects. just have a periodic jenkins job that builds an image,17:27
kfox1111then compares the newest posted one with the just built one. if they have the same set of packages/source, don't update.17:27
kfox1111if different, the new image is newer, so upload it.17:27
docaedoHow would you compare though? I am pretty sure DIB images built on different machines are not binary identical17:28
kfox1111rpm -qa | sort | md5sum17:28
kfox1111and the git hash.17:29
Alecauto build from dib would be a gerat idea!!!!17:29
kfox1111can even run the projects test suite on it to gate the image further.17:29
docaedoI'm definitely intrigued :) I think this is something that would be a huge benefit for the whole OpenStack community and an excellent addition to the catalog17:29
docaedoBack in the early days a few years ago there were a few different hosted image builders, but AFAIK none of them lasted17:30
kfox1111yeah. I've wanted it for a while. just havent' gotten around to it yet.17:30
kfox1111yeah. :(17:30
kfox1111its actually one of my bigest issues with docker at the moment.17:30
kfox1111they have the same issue.17:30
kfox1111they can autobuild from git, but if the base image gets updated under the container, it doesn't try and update it.17:31
kfox1111so security updates are hard to track with docker containers currently. :(17:31
docaedo(and personally I love DIB, and hooking it into app catalog would be awesome)17:31
*** kzaitsev_mb has quit IRC17:33
kfox1111somehow I missed the existing CirrOS image, and the schema didn't catch it...17:46
docaedohaha, funny I didn't catch that either and I was probably the one who listed the cirros image originally! I just figured it had been missed and you were rectifying.17:47
docaedodoes the schema enforce unique names? I didn't think we could catch duplicates that way17:47
kfox1111probably doesn't but it breaks the horizon ui bad.17:48
kfox1111should probably add a check manually in the python side.17:48
AlecI was curious to know how versioning of images was handled ? Were you considering users adding one entry in the yam; per version of image?17:48
kfox1111its not handled today. thats whats happening with the CoreOS images.17:50
kfox1111"Not all constraints can be expressed17:51
kfox1111JSON Schema limits itself to describing the structure of JSON data, it cannot express functional constraints."17:51
Alecsorry what happened to the coreOS image?17:51
kfox1111multiple entries, one per fversion.17:51
Alecand it is not supported? or not recommended?17:51
kfox1111its the way it is today.17:52
kfox1111it would be good to have some more smarts to deal with versions better.17:52
kfox1111I'm hoping whatever scheme the glance folks came up with can be easily adopted.17:52
Alecok, so for now we just add 1 entry per version17:54
kfox1111longer term, probably shoudl support multiple image url's or something, per version.17:54
kfox1111that way most of the entry is shared.17:54
kfox1111and if the user doesn't care, it can automatically pick the newest.17:54
openstackgerritKevin Fox proposed stackforge/apps-catalog: Fix duplicate entry and add a check.
*** kebray has quit IRC19:16
*** ig0r_ has quit IRC19:26
*** openstack has joined #openstack-app-catalog19:35
kfox1111is the gate horked again?20:09
*** kebray has joined #openstack-app-catalog20:22
*** kebray has quit IRC20:50
*** kebray has joined #openstack-app-catalog20:57
*** kzaitsev_mb has joined #openstack-app-catalog21:02
docaedoMaybe? I am not caught up on infra channel ATM21:07
*** kebray has quit IRC21:09
kfox1111that revert not going through quickly's making workign on the horizon a bit of a pain. :/21:09
kfox1111ok. finally got a workaround in place.21:11
openstackgerritMerged stackforge/apps-catalog: Fix duplicate entry and add a check.
kfox1111figures. ;)21:14
openstackgerritKevin Fox proposed stackforge/apps-catalog-ui: Share model for apps/components views.
kfox1111don't review this one yet.23:50

Generated by 2.14.0 by Marius Gedminas - find it at!