*** kzaitsev_mb has quit IRC | 00:41 | |
docaedo | Infra patch for dead link checker: https://review.openstack.org/259232 | 00:48 |
---|---|---|
docaedo | Might need work, I am not sure about the paths for the shell (specifically where assets.yaml will be found in relation to where that shell runs) | 00:48 |
docaedo | but overall I think it should be low-friction to get it in, as its 99% copied from the project-yaml normalizer :) | 00:49 |
kfox1111 | I've got to head out. I'll try and review tomorrow. | 01:43 |
kfox1111 | but I'd suggest maybe moving the code into app-catalog/tools instead of infra. that would allow us to update them quicker then ifra can, and if others want to run their own app-catalogs, they can use the link checker themselves. | 01:44 |
docaedo | for an infra-job it has to live in project-config (I think to keep people from using servers they host to do interesting things :) ) | 01:47 |
*** kragniz has quit IRC | 02:41 | |
*** kragniz has joined #openstack-app-catalog | 02:47 | |
*** kzaitsev_mb has joined #openstack-app-catalog | 09:00 | |
*** kzaitsev_mb has quit IRC | 09:09 | |
*** openstackgerrit has quit IRC | 09:32 | |
*** openstackgerrit has joined #openstack-app-catalog | 09:33 | |
*** kzaitsev_mb has joined #openstack-app-catalog | 10:31 | |
*** kzaitsev_mb has quit IRC | 11:33 | |
*** kzaitsev_mb has joined #openstack-app-catalog | 12:03 | |
*** kzaitsev_mb has quit IRC | 12:45 | |
*** kzaitsev_mb has joined #openstack-app-catalog | 12:46 | |
*** kzaitsev_mb has quit IRC | 15:08 | |
*** kzaitsev_mb has joined #openstack-app-catalog | 15:16 | |
*** kzaitsev_mb has quit IRC | 15:39 | |
*** kzaitsev_mb has joined #openstack-app-catalog | 16:35 | |
*** kzaitsev_mb has quit IRC | 16:40 | |
kfox1111 | hmm... I was expecting the infra code to be running on our webserver box via cron. did I misunderstand? | 17:05 |
kfox1111 | docaedo: http://doodle.com/poll/7krdfp96kttnvmg7 | 17:14 |
*** kzaitsev_mb has joined #openstack-app-catalog | 17:36 | |
docaedo | kfox1111: thanks for the pointer to the glance meeting time poll | 17:37 |
docaedo | kfox1111: I don't know all the details and reasoning but I believe the periodic jobs are jenkins jobs. I can imagine lots of good reasons for that (not the least of which - keep any individual server from becoming too much like a snowflake) | 17:39 |
*** kzaitsev_mb has quit IRC | 17:42 | |
*** kzaitsev_mb has joined #openstack-app-catalog | 17:59 | |
*** kzaitsev_mb has quit IRC | 18:03 | |
kfox1111 | ah. yeah, and that would allow them to distribute the load, and save/retrieve the logs easily. | 18:05 |
kfox1111 | even still, I believe some of those jobs do git pulls and so stuff with the result. maybe it would be reasonable for the infra job to git pull app-catalog and run app-catalog/tools/check_links | 18:06 |
kfox1111 | I'd like to have that code in the catalog repo so that we can make the link checking code do the right thing as we transition from 1.0 to 2.0. | 18:07 |
kfox1111 | it would suck to have to patch the link checker several times goin through the infra pipeline each time. | 18:07 |
docaedo | I think it's going to just have to go through the pipeline - I'm not up for trying to convince the infra team to change things up for the sake of the app catalog work. | 18:09 |
docaedo | Realistically anyway, implementing all the glare stuff is going to big, complicated, and all kinds of fun (for strange definitions of fun) | 18:09 |
docaedo | It'll have to use a DBaaS (likely trove I think) | 18:10 |
*** kzaitsev_mb has joined #openstack-app-catalog | 18:11 | |
docaedo | and we'll have to connect to a swift backend programatically (so we get out of the business of manually updating things in rackspace cloudfiles) | 18:11 |
docaedo | I guess/assume the swift part is all going to be handled by glare so that'll be nice | 18:14 |
kfox1111 | you thought it was going to be hard to convince them to do the update_yaml thing in our repo too, and that turned out to both parties. | 18:24 |
kfox1111 | I'm just suggesting we try. if they say no, then we're not out too much. | 18:24 |
kfox1111 | if they say yes, then we're in much better shape. | 18:24 |
kfox1111 | does the infra cloud provide trove? | 18:24 |
*** kzaitsev_mb has quit IRC | 18:25 | |
docaedo | Sure :) I'll get some feedback today on the project-config proposal, and will discuss the option of having the script live outside project-config/tools | 18:26 |
docaedo | AFAIK the infra cloud is actually a bunch of public cloud providers (i.e. infra does not maintain their own openstack deployment) | 18:27 |
docaedo | Most (all?) of the hosted stuff is on RAX, and shade + nodepool spreads the jenkins workers across all the donated clouds | 18:28 |
kfox1111 | right. | 18:29 |
kfox1111 | but of the donated resource, does any of it support trove's api? | 18:30 |
kfox1111 | would be cool if they did. | 18:30 |
docaedo | Not sure but I believe so, I asked once upon a time about mysql for app-catalog and the answer was "you won't run/maintain your own sql server, it'll be hosted/maintained by the provider" | 18:31 |
docaedo | I would like to imagine RAX is trove-compatible but probably not great to assume such things | 18:32 |
kfox1111 | ah. | 18:41 |
kfox1111 | either way. | 18:42 |
kfox1111 | the ironic thing about it is openstack's made to make launching things quick and easy. but the infra team doesn't directly make it available, so as users, we're stuck in the pre-cloud days. | 18:43 |
kfox1111 | not complaining. just find it funny. | 18:43 |
docaedo | yeah, it's that really we're an edge case for infra, as their mission is all about CI/CD and code gates | 18:43 |
docaedo | but the foundation hosts some things, and those things get to conform | 18:44 |
docaedo | I actually was surprised that there are still manual steps, I thought that 100% of infra stuff was "config as code" | 18:44 |
kfox1111 | yeah. | 18:45 |
docaedo | but for the snowflakes (like long lived servers) someone still gets in with root creds to trouble-shoot rather than just deploying a new box. That DOES make sense for hosting stuff like the *.o.o sites | 18:45 |
kfox1111 | right. | 18:45 |
docaedo | but agree that it's funny/ironic slightly - I guess we're not quite yet in the cool future we all want to be in | 18:46 |
kfox1111 | still, its somewhat amusing to me that the servers seem to be deployed like pets, and not cattle. | 18:46 |
kfox1111 | shoudl be a heat autoscaling template or something for it. | 18:46 |
kfox1111 | not "a server" | 18:46 |
* docaedo resists commenting on using heat in production | 18:46 | |
kfox1111 | I've got over a hundred fifty production systems running out of heat templates and docker contai[C[C[C[C[Cners. ;) | 18:47 |
kfox1111 | containers | 18:47 |
kfox1111 | before I did that, they had to take downtimes on a lot of their services. now, the only thing that requires an actual downtime is the lbaas instances themselves and a couple of mysql db's. the rest I can do rolling upgrades. | 18:49 |
kfox1111 | in theory, octavia will support HA in Mitaka, and Trove percona, so if I can get to Mitaka, and enable DVR, there won't be any single point of failure at all. | 18:50 |
kfox1111 | heat's more stable then you think. :) | 18:51 |
kfox1111 | its just painful to write generic templates. | 18:51 |
kfox1111 | though it looks like the PTL's finally giving in on that one. | 18:52 |
docaedo | yeah nice to see movement (of any kind!) on the heat conditionals front | 18:52 |
*** openstackgerrit has quit IRC | 19:17 | |
*** openstackgerrit has joined #openstack-app-catalog | 19:18 | |
*** kzaitsev_mb has joined #openstack-app-catalog | 21:17 | |
kfox1111 | wow. Chronicles Of A DLM made it through. :) | 23:37 |
docaedo | yeah, kind of amazing in a good way | 23:41 |
kfox1111 | I'm glad they used an abstraction layer, | 23:43 |
kfox1111 | and I'm less glad the default is a java app. :/ | 23:43 |
kfox1111 | to be fair, I havent played much with zookeeper. and I kind of like elasticsearch. | 23:44 |
kfox1111 | but I can count the number of java apps I've kind of like on one finger. :/ | 23:45 |
docaedo | at least (in theory) java for this is not going to need a lot of tuning/fiddling | 23:46 |
kfox1111 | yeah.... I'm just woried that says in theory java should be a great language too. ;) | 23:48 |
docaedo | hey write once run .. | 23:48 |
docaedo | everywhere? hmm, nope | 23:48 |
docaedo | some places at least :) | 23:48 |
kfox1111 | the strange thing was, it as actully came all the way back around to what it was intended for in the first place. | 23:49 |
kfox1111 | the language was written for low memory embeded like systems, and early phones. | 23:49 |
kfox1111 | then it went to browsers, | 23:49 |
kfox1111 | kind of really sucked at that... | 23:49 |
kfox1111 | got pushed into the server, | 23:50 |
kfox1111 | then android adopted it, and now its most used on phones again. | 23:50 |
docaedo | yeah and along the way an absurdly large ecosystem of java "developers" grew. I think my frustrations with java have less to do than running/using it, and more to do with people I've worked with who seemed to only know java (and believed it was the best/only choice) | 23:52 |
kfox1111 | yeah. I've talked to developers like that. Some are really good, some are not so much. | 23:53 |
kfox1111 | my biggest two issues with it have been, 1, every time I have to install it, its a huge pain to get the java jvm to match up with the "portable java app". | 23:53 |
kfox1111 | the write once run anywhere thing is a total lie. :/ | 23:53 |
kfox1111 | the other is the licensing stuff around it. though I hear the opensource stuff is finally starting to be on par with the closed stuff. | 23:54 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!