| [10:00:45] | * sander_bel has joined #aegir |
| [10:02:42] | * sander_bel has quit (Client Quit) |
| [10:05:22] | * sander_bel has joined #aegir |
| [10:06:43] | * mstenta has quit (Ping timeout: 252 seconds) |
| [10:07:08] | <sander_bel> | Hi! I struggling to create a platform from a git repo within Aegir. Could somebody point me in the right direction for documentation on this? Thx! |
| [10:11:46] | * flashpoint9 has joined #aegir |
| [10:12:55] | <sander_bel> | The platform directory gets created, the git repo gets cloned, but "drush --backend=2 @platform_platformsbel provision-verify 2>&1" keeps giving me "We could not find an applicable site for that command" |
| [10:13:31] | * flashpoi_ has joined #aegir |
| [10:16:21] | * flashpoint9 has quit (Ping timeout: 250 seconds) |
| [10:21:33] | * Egyptian[Home] has quit (Ping timeout: 250 seconds) |
| [10:23:48] | * flashpoi_ has quit (Remote host closed the connection) |
| [10:32:35] | * flashpoint9 has joined #aegir |
| [10:35:43] | * Egyptian[Home] has joined #aegir |
| [10:40:43] | * rominronin has joined #aegir |
| [10:46:21] | * rominronin has quit (Ping timeout: 276 seconds) |
| [10:51:44] | * flashpoint9 has quit (Remote host closed the connection) |
| [10:58:27] | * flashpoint9 has joined #aegir |
| [11:06:11] | * Egyptian[Home] has quit (Ping timeout: 250 seconds) |
| [11:16:01] | * flashpoint9 has quit (Remote host closed the connection) |
| [11:49:08] | * Egyptian[Home] has joined #aegir |
| [11:55:53] | * anarcat has quit (Quit: rebooting) |
| [12:05:09] | * anarcat has joined #aegir |
| [12:13:50] | * cdracars has quit (Ping timeout: 248 seconds) |
| [12:14:45] | * Egyptian[Home] has quit (Quit: Leaving.) |
| [12:15:56] | * omega8cc has joined #aegir |
| [12:20:49] | * cdracars has joined #aegir |
| [12:41:47] | * rominronin has joined #aegir |
| [12:47:20] | * rominronin has quit (Ping timeout: 268 seconds) |
| [13:15:04] | * flashpoint9 has joined #aegir |
| [13:17:00] | * sander_bel has quit (Quit: Leaving) |
| [13:24:58] | * flashpoint9 has quit (Remote host closed the connection) |
| [14:19:48] | * gusaus has quit (Quit: gusaus) |
| [14:42:51] | * rominronin has joined #aegir |
| [14:48:09] | * rominronin has quit (Ping timeout: 276 seconds) |
| [15:30:29] | * rominronin has joined #aegir |
| [15:30:40] | * rominronin has quit (Remote host closed the connection) |
| [15:30:47] | * rominronin has joined #aegir |
| [16:43:44] | * ybabel has joined #aegir |
| [18:57:17] | * DecipheredAFK is now known as Deciphered |
| [19:04:31] | * David_Hernandez has joined #aegir |
| [19:20:49] | * Deciphered is now known as DecipheredAFK |
| [19:33:42] | * gandhiano_ has joined #aegir |
| [19:35:34] | <helmo> | Deciphered: Could you grant me and clemens.tolboom access to https://www.drupal.org/project/aegir_rules |
| [19:36:16] | <helmo> | hefring: tell Deciphered Could you grant me and clemens.tolboom access to https://www.drupal.org/project/aegir_rules |
| [19:36:16] | <hefring> | helmo: I'll pass that on when Deciphered is around. |
| [20:54:22] | * Egyptian[Home] has joined #aegir |
| [22:19:36] | * zombiebeard has joined #aegir |
| [22:27:26] | * noecc has joined #aegir |
| [22:51:46] | * mstenta has joined #aegir |
| [23:01:00] | * esolitos has joined #aegir |
| [23:05:43] | * noecc has quit (Quit: No Ping reply in 180 seconds.) |
| [23:24:14] | * flashpoint9 has joined #aegir |
| [23:31:49] | * Yaazkal has joined #aegir |
| [23:32:25] | * noecc has joined #aegir |
| [00:25:46] | <ergonlogic> | gboudrias: is there a published civi extension that talks to hosting_restapi? If so, could you add it to the docs? |
| [00:26:04] | <ergonlogic> | of course, d.o is down right now... |
| [00:26:23] | <gboudrias> | ergonlogic: Not that I know of. bgm ? |
| [00:26:48] | <ergonlogic> | also, isn't hosting_saas intended to run on a seaprate site? but speak to Aegir via hosting_restapi? |
| [00:27:17] | <gboudrias> | ergonlogic: No hosting_saas is just a pre-requisite settings module for now |
| [00:27:35] | <ergonlogic> | hmm |
| [00:27:53] | <ergonlogic> | have you published the parts that speak to hosting_restapi? |
| [00:28:06] | <bgm> | ergonlogic: https://github.com/coopsymbiotic/coop.symbiotic.symbiocivicrm |
| [00:28:06] | <gboudrias> | ergonlogic: It does have a helper function to do the actual cloning etc. We want to merge all of it: https://www.drupal.org/node/2698053 |
| [00:28:29] | <bgm> | ergonlogic: more specifically: https://github.com/coopsymbiotic/coop.symbiotic.symbiocivicrm/blob/maste... |
| [00:28:52] | <bgm> | ergonlogic: as you can see, the code is rather specific to our needs, and not really used in production |
| [00:28:58] | <gboudrias> | ergonlogic: I put the code in https://praxis.coop/en/blog/automated-drupal-saas-aegir3 but the module is just way too specific to our use case |
| [00:29:13] | <ergonlogic> | gboudrias: ok |
| [00:29:24] | <ergonlogic> | bgm: ok |
| [00:29:28] | <ergonlogic> | hmm |
| [00:29:31] | <bgm> | (it should work though) |
| [00:29:53] | <ergonlogic> | it'd be nice to have a generic out-of-the-box SaaS front-end for Aegir |
| [00:30:04] | <bgm> | demo: https://crm.symbiotic.coop/en/civicrm/contribute/transact?reset=1&id=1&a... |
| [00:30:34] | <bgm> | ergonlogic: a good REST API would be a good start :) |
| [00:30:42] | <bgm> | i mostly hacked stuff around without really thinking about it |
| [00:31:08] | <bgm> | the JS calls Aegir with a receipt token, which Aegir then validates with the CRM |
| [00:31:21] | <bgm> | the token is then later used for stuff like default site name, email, et |
| [00:31:22] | <bgm> | etc |
| [00:31:29] | * Egyptian[Home] has quit (Quit: Leaving.) |
| [00:32:52] | <ergonlogic> | url: 'https://av102.symbiotic.coop/hosting/api/site', |
| [00:32:58] | <ergonlogic> | right, pretty specific |
| [00:33:01] | <bgm> | :) |
| [00:33:20] | <bgm> | that's a quickfix by comparison :) |
| [00:33:36] | <ergonlogic> | right |
| [00:33:43] | <bgm> | but i've been doing demo to other civi shops, and there's been very little interest |
| [00:33:55] | <bgm> | most shops want to handle new client onboarding manually |
| [00:34:04] | <bgm> | at least in the civi world.. |
| [00:34:25] | <bgm> | even at symbiotic, i have serious pushback against it from colleagues |
| [00:34:52] | <ergonlogic> | colan: let me know when you're tackling the SaaS stuff. It'd be nice to try to come up with a something more configurable based on the work that bgm and gboudrias have done. |
| [00:35:02] | <bgm> | (partly because once a client sign-on, we're stuck supporting that client) |
| [00:35:06] | <ergonlogic> | bgm: well, something as big and complex as CiviCRM, sure |
| [00:35:09] | <anarcat> | damn clients |
| [00:35:34] | <ergonlogic> | fir a more specific application, it makes more sense, imo |
| [00:35:47] | <bgm> | yeah, and i still intend on pushing this forward :) |
| [00:35:49] | <ergonlogic> | hey, look who's here :) |
| [00:36:01] | <gboudrias> | ergonlogic: We should have a sprint :p |
| [00:36:31] | <ergonlogic> | gboudrias bgm colan: a sprint to consolidate some Aegir SaaS stuff sounds soog to me :) |
| [00:36:38] | <ergonlogic> | soog? |
| [00:36:46] | <ergonlogic> | s/soog/good/g |
| [00:36:50] | <gboudrias> | ergonlogic: The part that you said was missing earlier, did you mean for the public-facing site? |
| [00:37:15] | <anarcat> | ergonlogic: i'm not here :p |
| [00:37:21] | <anarcat> | just idling in random channels ;) |
| [00:37:58] | <ergonlogic> | gboudrias: assuming we build something like that, it (and the civi-based one) should probably go in a separate section on the Aegir contrib docs page |
| [00:38:06] | <ergonlogic> | that was actually my point earlier |
| [00:38:20] | <ergonlogic> | anarcat: well, you're always welcome here :) |
| [00:38:25] | <gboudrias> | ok |
| [00:39:07] | <ergonlogic> | gboudrias: my reasoning being simply that it isn't a 'normal' aegir contrib component, since these are intended to run on separate sites |
| [00:39:18] | <gboudrias> | Indeed |
| [00:39:52] | <ergonlogic> | maybe we just need a proof-of-concept example in hosting_restapi, or something |
| [00:40:16] | <ergonlogic> | that way we might be able to test it (GASP!) |
| [00:41:43] | <bgm> | one thing you may want to change in the API: currently the browser sends a receipt ID to hosting_restapi |
| [00:41:58] | <bgm> | so the receipt ID then needs to be validated, and it becomes very civicrm specific |
| [00:42:17] | <bgm> | i guess a more conventional way would be to just have a secret key for accessing the API |
| [00:42:25] | <gboudrias> | bgm: Since we're on the subject, I'm still waiting for your feedback on the pull request for that :p |
| [00:42:41] | <bgm> | oh erm :-) |
| [00:43:10] | <gboudrias> | I've been using it for a while now, there's still a receipt ID (since I think it makes sense) but it doesn't get validated |
| [00:43:34] | <gboudrias> | But maybe it could use an overhaul, I wasn't really trying to rethink the whole thing at the time |
| [00:44:14] | <anarcat> | ergonlogic: thanks :) |
| [00:44:14] | <bgm> | https://github.com/coopsymbiotic/hosting_restapi/pull/4/files ? |
| [00:44:59] | <gboudrias> | bgm: Yeah looks like it, sorry it's been a while |
| [00:45:07] | <bgm> | yeah, my bad :) |
| [00:47:04] | <gboudrias> | ergonlogic: I've been working non-stop on hosting_network btw: https://www.drupal.org/node/2606072/commits |
| [00:47:04] | <hefring> | https://www.drupal.org/node/2606072 => Aegir Network => 0 comments, 1 IRC mention |
| [00:47:31] | <gboudrias> | I'm going to write a blog post soon-ish, but the cool news is you can run migrates on multiple servers concurrently |
| [00:47:42] | <gboudrias> | Based on platforms selected by name or regex |
| [00:47:57] | <ergonlogic> | neat! |
| [00:49:37] | <gboudrias> | Yeah it's nice, could use some polishing but it's definitely working |
| [00:49:43] | <gboudrias> | bgm: Thanks for the merge! |
| [00:50:00] | * bgm is a bad maintainer :) |
| [00:52:14] | <gboudrias> | bgm: Actually I forgot to do the no-specifics pull (?): https://github.com/PraxisLabs/hosting_restapi/tree/no-specifics |
| [00:52:32] | <gboudrias> | I thought that diff looked sparse... |
| [00:53:45] | <bgm> | hmm, that one removes the "get uid2 password", for which i'll need a cleaner implementation |
| [00:55:15] | <gboudrias> | bgm: Not sure what it does but if it's just to send an email I put something similar in https://github.com/PraxisLabs/hosting_saas_utils |
| [00:55:33] | <gboudrias> | Although it doesn't have a specific task, it's just a post-verify |
| [00:55:44] | <gboudrias> | (This is the module we want to merge with hosting_saas, just haven't had time yet) |
| [00:55:49] | <bgm> | it's not for email, it's to get a one-time login link for uid=2 |
| [00:56:05] | <bgm> | (since we don't give uid=1 access) |
| [00:56:39] | <bgm> | this way when the site setup is ready, we show the login-link directly on screen :) |
| [00:56:59] | <gboudrias> | I see what you mean, not sure how we do it |
| [00:58:24] | <gboudrias> | colan: ^ not sure if you've been following but everyone involved is here :) |
| [01:02:34] | <colan> | hi all, been meaning to jump in, was just doing some prep. thanks for the discussion... |
| [01:02:48] | <colan> | i created a new branch for all this stuff. see https://www.drupal.org/node/2704767 |
| [01:02:49] | <hefring> | https://www.drupal.org/node/2704767 => hosting_saas 7.x-3.x-dev => 0 comments, 1 IRC mention |
| [01:03:11] | <colan> | the 2 major issues are in there. |
| [01:05:34] | <colan> | gboudrias: thanks for helping me kick this off. yes, i agree Hosting Services should remain as-is. it's a very different use case, which i tried to highlight when i added all these to the docs contrib page yesterday. |
| [01:06:41] | <colan> | will definitely use your fork for the merge (unless the origin repo gets ahead). |
| [01:11:52] | <colan> | ergonlogic: these 3 modules are all for the server side (aegir). i don't see any client stuff anywhere (yet). i'll get there eventually, but want to put these things together and make them more generic. |
| [01:12:24] | <colan> | my use case is having the client be a D8 site, not civi. |
| [01:13:31] | <gboudrias> | Likewise for D7 |
| [01:13:39] | <gboudrias> | But D8 is the future |
| [01:15:40] | <colan> | i want aegir to be "dumb", not knowing or caring about clients, invoices or orders (hosting_restapi does some of this now). aegir will simply be told to do things it's good at, or return information. other contribs can do client/invoicing if they want, but that shouldn't be core here. |
| [01:16:01] | <colan> | i want to do this stuff on the client side. |
| [01:18:47] | <bgm> | although it should manage credentials for clients, ex: as a client, I should be able to request a backup to be run on my site, using the Aegir API |
| [01:19:03] | <bgm> | s/credentials for clients/credentials for sites/ |
| [01:20:13] | <bgm> | a bit like the hosting_git module makes it possible to call a webhook to run a git pull for a specific site |
| [01:22:15] | <colan> | bgm: makes sense. |
| [01:22:32] | <colan> | ergonlogic: so i'm looking to turn hosting_saas into your "a generic out-of-the-box SaaS front-end for Aegir |
| [01:23:36] | <colan> | ", which will be different that hosting_services which is meant for clients managing their own sites. |
| [01:24:15] | <colan> | that's not the goal here. |
| [01:25:41] | <colan> | the use case if for end users to get their own sites, that's it. they won't be running aegir tasks. |
| [01:26:16] | <colan> | well, not directly. |
| [01:28:01] | <colan> | once this stuff is more tangible, yes, i agree, it should have its own space in the docs. |
| [01:28:40] | <colan> | but before yesterday there was nothing so i wanted to bring it up-to-date to where we are now. |
| [01:28:58] | <gboudrias> | colan: Could use the Services module though, it is made for stuff like this after all |
| [01:29:35] | <colan> | gboudrias: that's another question. should we try to get away without that entire stack, or just use it? |
| [01:30:09] | <colan> | i'm wondering if it's overkill. |
| [01:30:37] | <colan> | i haven't actually used Services before, so opinions welcome. |
| [01:30:39] | <gboudrias> | Well, I thought it was which is why hosting_restapi is great, but it does a lot of the heavy lifting if we want anything other than an anonymous API |
| [01:31:28] | <gboudrias> | I guess the first step is to identify what we want to do, I just want to create new sites, most people want some sort of feedback (eg: login link) |
| [01:32:30] | <colan> | but if we're going with Services, then maybe just go with hosting_services? |
| [01:33:02] | <colan> | that requires hosting_clients though, which i don't care for. |
| [01:33:29] | <colan> | i don't know enough about it to maybe serve both use cases. |
| [01:33:32] | <gboudrias> | Bah, we could make that optional, I don't use it either and afaik I'm the only one using hosting_services right now |
| [01:33:51] | <colan> | :) |
| [01:34:23] | <colan> | alright, i can experiment with that first. |
| [01:34:29] | <bgm> | this is probably unrelated, but personally, my view is that clients shouldn't have to access the Aegir UI |
| [01:34:58] | <gboudrias> | colan: I gave you commit access to hosting_services if you want to make a feature branch or whatnot |
| [01:35:14] | <colan> | bgm: could you expand on that? |
| [01:35:27] | <colan> | gboudrias: thanks. |
| [01:35:28] | <gboudrias> | Yeah I've never seen anyone want to give clients access to the Aegir UI for Saas :) |
| [01:35:57] | <bgm> | colan: in my use-case, clients want to sign-up for a site, login, and never know that we are using Aegir |
| [01:36:15] | <bgm> | but then we may want to let clients request a backup, restore, create a dev site, etc |
| [01:36:22] | <bgm> | in those cases, I would use the API, from within their own site. |
| [01:36:31] | <bgm> | (or let developers do their own thing) |
| [01:36:58] | <colan> | in other news, re: sprinting, wasn't sure if i wanted to go to MTL for Drupal North, but maybe it wouldn't hurt to get together for this. |
| [01:37:43] | <colan> | bgm: same here. for backups, was planning to have backup_migrate on the client sites, and they do what they want with that. |
| [01:37:47] | <gboudrias> | Heh that would be awesome |
| [01:37:58] | <gboudrias> | likewise |
| [01:38:23] | <colan> | gboudrias: so you don't think hosting_services is overkill for this? |
| [01:39:01] | <gboudrias> | Meaning if we had the tools bgm describes, I would use them, but right now we have nothing and it's still pretty much fine (but we have to manage stuff manually sometimes) |
| [01:39:51] | <gboudrias> | colan: It's overkill for a single-function API, it's not overkill for the features that bgm is describing. |
| [01:40:08] | <gboudrias> | Of course it would probably deserve its own submodule |
| [01:43:24] | <colan> | gboudrias: basically, we want to run aegir tasks remotely, and add some getter calls to return info. what about that? |
| [01:43:43] | <colan> | (assuming no clients) |
| [01:45:04] | <colan> | gboudrias: can you make it to the meeting thurday? maybe we can about this more then. |
| [01:45:16] | <colan> | ^ talk |
| [01:45:51] | <gboudrias> | colan: okay |
| [01:46:21] | <gboudrias> | colan: That's definitely big enough to warrant using the existing infrastructure, include hosting_services in my opinion |
| [01:47:08] | <gboudrias> | It is actually surprisingly easy to run remote tasks with it, I do it in hosting_network if you want some code to copy |
| [01:47:09] | <bgm> | i'm not commenting fwiw, since not too familiar with drupal-specifics :) |
| [01:47:26] | <bgm> | (not a fan of the 'services' module) |
| [01:48:07] | <colan> | gboudrias: okay, great. will shift my focus over there then. |
| [01:48:33] | <colan> | bgm: i'm not a fan either, but i'd rather not duplicate efforts. |
| [01:48:48] | <bgm> | yep fair enough |
| [01:49:00] | <bgm> | does D8 have a better rest endpoint system? |
| [01:49:20] | <colan> | bgm: yep, makes a great back-end datastore. |
| [01:49:33] | <bgm> | cool |
| [01:49:55] | <bgm> | i guess with all the talk about detached head.. :) |
| [01:50:28] | <colan> | so moving aegir to d8 would be nice for this stuff (yay, no Services!), but that's too big of project right now. |
| [01:50:29] | <gboudrias> | services is bulky, but it has a lot of integrated stuff including OAuth2 authentication :) |
| [01:50:47] | <colan> | oh right, i wrote that one! |
| [01:50:50] | <gboudrias> | hahah |
| [01:51:11] | <colan> | just noticed the other day you were referring to it. |
| [01:51:55] | <colan> | sigh. i guess if the d7 standard for doing this stuff is Services, it doesn't make sense to reinvent the wheel. |
| [01:52:12] | * ergonlogic would appreciate feedback on https://www.drupal.org/node/2704799 |
| [01:52:18] | <ergonlogic> | https://www.drupal.org/node/2704799 |
| [01:52:19] | <hefring> | https://www.drupal.org/node/2704799 => RFC: Add a 'distribution' content type [#2704799] => 0 comments, 1 IRC mention |
| [01:52:55] | <colan> | when we upgrade aegir to d8, we can rip out all of the then-useless Services stuff. |
| [01:53:20] | <ergonlogic> | grr, my irc notifier isn't working, so I've missed recent mentions... sorry, let me review |
| [01:55:54] | <ergonlogic> | I agree on Aegir remaining 'dumb' to the order/invoicing |
| [01:58:00] | * cweagans has joined #aegir |
| [01:58:27] | <ergonlogic> | Last time I looked at Services, it was *very* poorly documented, but maybe that's changed... |
| [02:00:49] | * David_Hernandez has quit (Quit: Saliendo) |
| [02:03:20] | <ergonlogic> | colan: fyi, in case you haven't come across them yet, Aegir has a whole 'services' concept that has *nothing* to do with services.module |
| [02:05:37] | * rominronin has quit (Remote host closed the connection) |
| [02:06:03] | <colan> | ergonlogic: oh? ok, i'll try not to overload the term. |
| [02:06:04] | * freiheit has joined #aegir |
| [02:07:01] | <gboudrias> | ergonlogic: I commented in the issue, I hope it doesn't sound too negative, it's a good feature but based on discussions here I imagined something much lighter |
| [02:07:27] | <colan> | ergonlogic: i haven't got to the Architecture chapter yet; that's next. |
| [02:09:56] | <colan> | gboudrias: how about adding Aegir Network to the contrib page in the docs? :) |
| [02:10:20] | <gboudrias> | colan: Good idea but I'd like to polish it more first, and write the blog about the coolest feature :p |
| [02:10:58] | <gboudrias> | I mean, it's already on d.o though, so meh |
| [02:11:11] | * freiheit has left #aegir () |
| [02:11:23] | <colan> | ok, well, for now, i'll put it in & just copy your first pargraph. :P |
| [02:11:39] | <gboudrias> | 10-4 |
| [02:12:41] | <colan> | gboudrias: ah, sorry. looks like it's already in there. |
| [02:13:04] | <colan> | i thought all the web services ones were missing. |
| [02:13:54] | <colan> | anyway, looking forward to your blog post. |
| [02:14:28] | <gboudrias> | huh |
| [02:15:29] | * Yaazkal has quit () |
| [02:22:56] | * colan is afraid to run a git blame in case he's the one that added it already, and forgot about it. |
| [02:23:42] | <gboudrias> | colan: No pretty sure it's me I had just forgotten :) |
| [03:01:35] | <ergonlogic> | sorry, had to go pick up son from school, as he is ill :-/ |
| [03:02:06] | <ergonlogic> | gboudrias: it'd actually be pretty light, afaict |
| [03:04:19] | * noecc has left #aegir ("pax") |
| [03:05:10] | <gboudrias> | ergonlogic: Yeah I guess, I suppose I would try it, I never did figure out a simple way to do it with just platforms |
| [03:05:29] | <gboudrias> | ergonlogic: Mostly I just don't want to rewrite all the contrib stuff :p |
| [03:05:43] | <gboudrias> | Or I would rather have to rewrite less of it |
| [03:06:12] | * rominron_ has joined #aegir |
| [03:09:08] | <ergonlogic> | why would you need to re-write anything? |
| [03:09:53] | <ergonlogic> | everything should continue to work as usual |
| [03:10:12] | <ergonlogic> | in fact, that's pretty much a requirement |
| [03:10:23] | <gboudrias> | Right, I mean to leverage the new thing :p |
| [03:11:10] | <gboudrias> | I understand that it's optional, it's just a really useful concept that I would like to use, but whether or not I can depends on how much stuff I have to rewrite |
| [03:11:23] | <gboudrias> | But that's just me |
| [03:12:09] | <ergonlogic> | can you give me some examples of what you think you'd need to re-write? |
| [03:17:44] | <gboudrias> | ergonlogic: Mostly thinking of hosting saas and the related modules (saas utils, hosting services) and hosting network (distributions are probably significant if they are present) |
| [03:18:43] | <ergonlogic> | ok, so I don't think you're looking at building platforms via hosting_saas, et. al., right? |
| [03:19:36] | <ergonlogic> | if anything, I think it'd simplify those tools |
| [03:19:55] | <ergonlogic> | we'd need to give some thought to the fact that platforms are changing with updates |
| [03:20:04] | <gboudrias> | Not right now, though it'd be food to follow them |
| [03:20:08] | <ergonlogic> | but then, that should be the case now anyway |
| [03:20:09] | <gboudrias> | Yeah exactly |
| [03:20:30] | <gboudrias> | Well the reason I haven't done it yet is we'd need to make certain assumptions |
| [03:20:36] | <ergonlogic> | right |
| [03:21:03] | <ergonlogic> | so, as it stands, in hosting_saas, you specify a platform nid? |
| [03:21:04] | <gboudrias> | I'm just comparing your proposed implementation to the idea of having simple added attributes to platforms |
| [03:21:08] | <gboudrias> | Yes |
| [03:21:56] | <ergonlogic> | while there'd probably be a field on platforms to reference the distro, I don't think that'd be enought to do anything useful |
| [03:21:59] | <gboudrias> | I assume that you've given thought to both though, what's the problem with a simple tagging mechanism? |
| [03:22:07] | <gboudrias> | Hmm alright |
| [03:22:26] | <ergonlogic> | if anything, it'd require more work, as it'd involve having to *change* how platforms operate |
| [03:22:34] | <gboudrias> | I'm curious to know what others think, as my use case is getting very specific |
| [03:22:48] | <ergonlogic> | as oppsed to leaving them as is, and simply creating new ones as required |
| [03:23:40] | <ergonlogic> | I think the problem of knowing the platform nid to build your new SaaSy site on would be simplified by having a distro |
| [03:24:10] | <gboudrias> | Indeed |
| [03:24:11] | <ergonlogic> | in that, the distro would provide an API to find the latest platform of a particular flavour |
| [03:24:46] | <gboudrias> | Yeah actually that's a good point, we would centralize the logic |
| [03:25:02] | <ergonlogic> | so, hosting_restapi, or whatever, could probably easily be adapted to receive a distro, and look up the appropriate platform |
| [03:25:13] | <ergonlogic> | exactly |
| [03:25:35] | <ergonlogic> | we've been talking about tagging platforms and sites to represent relationships for a long time |
| [03:25:36] | <gboudrias> | Heh, much more easily if the logic is already there :p |
| [03:25:56] | <ergonlogic> | I think it hasn't gone anywhere because it didn't really capture the essence of what we mean to do |
| [03:26:33] | <gboudrias> | Alright I'll comment in the issue |
| [03:26:41] | <ergonlogic> | I *think* the concept of a 'distro' is essentially what we're trying to get at |
| [03:27:04] | <ergonlogic> | when we say something like "this platform is the next version of that platform" |
| [03:38:49] | <ergonlogic> | hefring: log? |
| [03:38:56] | <ergonlogic> | hefring: pointer? |
| [03:39:12] | <ergonlogic> | hefring: log pointer? |
| [03:39:12] | <hefring> | http://hefring.mig5.net/bot/log/aegir/2016-04-12#T616057 |
| [03:39:40] | * rominron_ has quit (Ping timeout: 244 seconds) |
| [03:40:53] | * gandhiano_ has quit (Ping timeout: 268 seconds) |
| [03:59:07] | <colan> | ergonlogic: to clarify: there would be distro nodes. then, when the saas stuff wants to spin up a new site, it would specify the distro node instead of the platform node. |
| [04:00:22] | <colan> | if that's where you guys are going, i like it because the client shouldn't need to know or care about the release/version of the distro (as already stated). |
| [04:02:47] | * flashpoint9 has quit (Read error: Connection reset by peer) |
| [04:03:22] | * flashpoint9 has joined #aegir |
| [04:36:59] | * rominron_ has joined #aegir |
| [04:44:37] | <ergonlogic> | colan: basically, yes |
| [04:45:25] | <ergonlogic> | we'd have to look at how to handle the site form in Aegi itself. But via hosting_saas, it shouldn't even be presented as an option, in most cases |
| [04:58:18] | * omega8cc has quit (Quit: Cheers! It's Time for Offline Reality) |
| [05:00:25] | * kvanderw is now known as zz_kvanderw |
| [05:07:47] | * manningx has quit (Ping timeout: 250 seconds) |
| [05:08:52] | * manningx has joined #aegir |
| [05:09:14] | * flashpoint9 has quit (Remote host closed the connection) |
| [05:11:31] | * rominron_ has quit (Ping timeout: 248 seconds) |
| [05:14:20] | * flashpoint9 has joined #aegir |
| [05:15:31] | * zz_kvanderw is now known as kvanderw |
| [05:28:06] | * gusaus has joined #aegir |
| [05:50:00] | <colan> | ergonlogic: i can confirm that the paypal button over at http://www.aegirproject.org/donate returns "This recipient is currently unable to receive money. |
| [05:50:03] | <colan> | " |
| [05:50:57] | * cweagans has quit (Quit: Leaving) |
| [05:55:35] | <ergonlogic> | helmo: ^^^ |
| [05:56:28] | <colan> | how does one get access to stats queue data? i can't seem to find a link to this anywhere in the UI. |
| [05:57:02] | <colan> | "This queue operates on the same mechanism as the cron queue, and alows you to retrieve statistics of your installed sites. This will retrieve such metrics as number of registered and active users, and number of posts / comments, which will then be viewable on the front end." |
| [06:08:40] | * rominronin has joined #aegir |
| [06:35:42] | * ybabel has quit (Quit: ybabel) |
| [06:43:28] | * Yaazkal has joined #aegir |
| [06:43:40] | * rominronin has quit (Ping timeout: 264 seconds) |
| [07:15:56] | <colan> | ergonlogic: gboudrias : thoughts on https://www.drupal.org/node/2260019#comment-11076141 ? |
| [07:15:56] | <hefring> | https://www.drupal.org/node/2260019 => How about Disk & Bandwidth Quota Per Site ? [#2260019] => 3 comments, 1 IRC mention |
| [07:16:25] | <colan> | the docs seem to be lying about monitoring already being available. |
| [07:20:36] | * flashpoint9 has quit (Remote host closed the connection) |
| [07:20:53] | * flashpoint9 has joined #aegir |
| [07:21:26] | * flashpoint9 has quit (Remote host closed the connection) |
| [07:40:13] | * rominronin has joined #aegir |
| [08:00:02] | * zombiebeard has quit (Quit: zombiebeard) |
| [08:13:52] | * rominronin has quit (Ping timeout: 260 seconds) |
| [08:39:39] | * colan assumes folks are using db_query() everywhere to fetch site nodes, etc. instead of EntityFieldQuery because this didn't exist in d6. https://www.drupal.org/node/1343708 |
| [08:41:08] | * gusaus has quit (Quit: gusaus) |
| [08:48:37] | * Yaazkal has quit (Read error: Connection reset by peer) |
| [08:53:33] | * gusaus has joined #aegir |
| [09:10:43] | * rominronin has joined #aegir |
| [09:45:20] | * rominronin has quit (Ping timeout: 268 seconds) |
