| *** mtreinish has quit IRC | 01:58 | |
| *** mtreinish has joined #openstack-tc | 01:59 | |
| *** liujiong has joined #openstack-tc | 02:45 | |
| *** kumarmn_ has joined #openstack-tc | 02:49 | |
| *** kumarmn has quit IRC | 02:52 | |
| *** ykarel has joined #openstack-tc | 03:14 | |
| *** gcb has joined #openstack-tc | 03:37 | |
| *** ykarel has quit IRC | 04:06 | |
| *** ykarel has joined #openstack-tc | 04:07 | |
| *** ykarel_ has joined #openstack-tc | 04:42 | |
| *** ykarel has quit IRC | 04:45 | |
| *** coolsvap has joined #openstack-tc | 05:16 | |
| *** ykarel__ has joined #openstack-tc | 05:40 | |
| *** ykarel_ has quit IRC | 05:43 | |
| *** ykarel__ is now known as ykarel | 06:52 | |
| ttx | fungi: \o/ | 08:50 |
|---|---|---|
| *** liujiong has quit IRC | 09:11 | |
| *** liujiong has joined #openstack-tc | 09:12 | |
| *** jpich has joined #openstack-tc | 09:22 | |
| *** ykarel has quit IRC | 09:29 | |
| *** ykarel has joined #openstack-tc | 09:30 | |
| ttx | On the topic of release frequency and LTS, I just read https://gravitational.com/blog/kubernetes-release-cycle/ | 09:39 |
| ttx | A few interesting bits if you can read past the OpenStack snark and the self-congratulation tone | 09:40 |
| ttx | K8s supports last 3 releases, so roughly 10 months back | 09:40 |
| ttx | been discussing faster/slower release frequency, as well as skipping-upgrades, but so far decided no change | 09:41 |
| ttx | It seems like they are struggling a bit to have those discussions -- the threads raising them die before they can find a body to make a call | 09:44 |
| ttx | Maybe dims has fresher news | 09:44 |
| ttx | (the article linked above is slanted toward delegating the LTS work to distributions, since it's written by a distributor) | 09:46 |
| ttx | I wonder if our own LTS discussion is not distorted by over-representation of DIY ops in our engaged user community. That would explain why we are struggling to find resources to do it, as a lot of our resources come from distributions, not DIY users. | 09:49 |
| *** dtantsur|afk is now known as dtantsur | 10:05 | |
| *** liujiong has quit IRC | 10:22 | |
| *** ykarel is now known as ykarel|away | 10:40 | |
| persia | Interesting article. Despite my typical economic argument that if ops want LTS, they should either donate FTEs or pay vendors sufficiently for the vendors to donate the FTEs, I suspect there are useful discussions to have to ensure there is effective alignment between those producing requirements for OpenStack and those providing resources. | 10:44 |
| *** ykarel|away has quit IRC | 10:44 | |
| *** cdent has joined #openstack-tc | 10:45 | |
| *** dtantsur is now known as dtantsur|brb | 12:17 | |
| *** gcb has quit IRC | 12:30 | |
| * dims reading | 13:04 | |
| dims | " the threads raising them die before they can find a body to make a call" ... yes! | 13:05 |
| dims | sig-architecture is making some progress in their backlog, but progress is slow. pm-sig is like ours, can't direct resources and hard for them to set direction. for example the roll out of KEP processs is taking too much time - https://github.com/kubernetes/community/tree/master/keps | 13:10 |
| dims | i am kinda heads down on the openstack<->kubernetes stuff. will be proposing a new repo in our infra in a week or two | 13:11 |
| * cdent wishes he had more spare time to help dims | 13:15 | |
| dims | thanks cdent ! :) | 13:16 |
| cdent | I even have corporate permission to do so, but can't find the time... | 13:16 |
| cdent | there's a huge list of such things | 13:16 |
| dims | persia : ttx : fungi : you may have seen this, if not, backlog/minutes from their steering committee - https://docs.google.com/document/d/1qazwMIHGeF3iUh5xMJIJ6PDr-S3bNkT8tNLRkSiOkOU/edit | 13:17 |
| smcginnis | I have been pushing in ops meetup and other discussions that LTS should really be a distro thing. | 13:26 |
| smcginnis | There's certainly things we could do in the community to make it easier (like skip level upgrade support) but the distros are the ones that are actually providing "support". | 13:26 |
| smcginnis | And the DIY folks have made the decision to - do it themselves - so if they want something long term, that's just an implication of choosing to go that route. | 13:27 |
| *** coolsvap has quit IRC | 13:34 | |
| cdent | smcginnis++ | 13:36 |
| ttx | I've been thinking of ways to get indirect ops (those who consume openstack through some distro) to be more vocal | 13:49 |
| ttx | currently they are underrepresented which leads to some perspective distortion when we poll the -ops list to make technical decisions | 13:50 |
| ttx | (they are also underrepresented in the user survey) | 13:50 |
| cdent | Yeah, I think that's a pretty big gap. | 13:50 |
| cdent | Which leads us if not astray, then at least diverts energy | 13:51 |
| ttx | basically we established a good feedback loop, but it's partial | 13:51 |
| ttx | I'll likely engage with the new UC once the elections are over. Don't want to derail that process | 13:51 |
| *** kumarmn_ has quit IRC | 13:56 | |
| ttx | dims: looks like this Google doc is not public | 13:57 |
| *** kumarmn has joined #openstack-tc | 13:57 | |
| dims | ah you need to join the kubernetes-dev google group @ttx | 13:57 |
| * ttx sighs | 13:58 | |
| * ttx wonders how one does that | 13:59 | |
| ttx | ah, that blue button probably | 13:59 |
| dims | y, and you can set it to not send you any emails too | 13:59 |
| ttx | hm , still not accessing, probably takes some time | 14:00 |
| dims | ack. "Meeting notes are available to members of the kubernetes-dev mailing list" from here - https://github.com/kubernetes/steering | 14:01 |
| *** kumarmn has quit IRC | 14:01 | |
| ttx | ok, accessing now | 14:02 |
| *** dtantsur|brb is now known as dtantsur | 14:07 | |
| dhellmann | ttx: if we need to get more user feedback from customers of distributors, maybe we should be asking the distributors more directly? | 14:14 |
| ttx | dhellmann: that's what we are doing for the user survey... we should probably be doing the same for tech feedback | 14:16 |
| dhellmann | right | 14:16 |
| ttx | not sure how to do it in practice | 14:16 |
| dhellmann | although presumably all of the contributors who work for distributors are channelling that feedback already | 14:16 |
| ttx | openstack-distros ML ? Ask distros to join openstack-ops ? | 14:16 |
| dhellmann | if only we had a product management working group to talk to | 14:17 |
| *** kumarmn has joined #openstack-tc | 14:18 | |
| *** kumarmn has quit IRC | 14:18 | |
| cdent | I suspect there are plenty of people who don't even think of the opensource community when they use (or buy) openstack, and as such the surveys are very biased | 14:19 |
| *** kumarmn has joined #openstack-tc | 14:19 | |
| cmurphy | I try to channel feedback from customers into bug reports and blueprints | 14:19 |
| cmurphy | some customers aren't willing or able to engage directly | 14:20 |
| dhellmann | I think we all do, for the things we know about already. The issue is for topics that come up in one corner of the community. It takes a while for the conversation to spread. Is there a way to make that happen more quickly? | 14:20 |
| *** coolsvap has joined #openstack-tc | 14:21 | |
| dhellmann | Not that everyone needs to be involved in everything, but if we want user input to make a technical choice (like "which distribute lock manager should we start with?") it would be nice to have a way to collect that feedback | 14:21 |
| dhellmann | OTOH, maybe we worry about this stuff too much. If people aren't engaged, is that our fault? I feel like we beg for input a lot of the time. | 14:22 |
| cdent | dhellmann++ | 14:22 |
| TheJulia | dhellmann: That is a good point | 14:23 |
| cdent | Maybe we should try a different strategy: ask for forgiveness | 14:23 |
| dhellmann | or just expect it | 14:23 |
| * dhellmann may be a little grumpy this morning | 14:23 | |
| * cdent squints at dhellmann | 14:23 | |
| dhellmann | or a big grumpy. it's early. | 14:24 |
| TheJulia | dhellmann: It would be awesome of packagers/distributions were sharing the feedback they are getting from customers, not just what goes into bugs/blueprints, but allow their vendor to come to the community and say "I have a customer with x nodes, y needs, z is a friction point" | 14:24 |
| TheJulia | Time for fresh coffee? | 14:24 |
| dhellmann | TheJulia : what form do you see that sort of feedback taking? | 14:24 |
| dhellmann | yes, need more tea | 14:24 |
| cmurphy | I think it's to the vendor's advantage to be that representation and to bring that feedback, if they're not doing that it's their loss because it's their customers' loss | 14:25 |
| TheJulia | dhellmann: dialog with the teams going into the ptg would be the most impactful. Operators who have some connections/contacts with team provide a great deal of context that helps in discussions and properly framing problems. | 14:26 |
| TheJulia | dhellmann: If we had teleporters, I would hapilly beam you excess hot water from the kettle this morning | 14:26 |
| dhellmann | cmurphy : right | 14:26 |
| TheJulia | cmurphy: I would worry the vendor has their own vision and plan, and customer feedback might take a backseat to own plans and vision | 14:27 |
| dhellmann | TheJulia : I guess I'm saying, if we have customer A of vendor X and A doesn't *want* to worry about upstream, then how do we know what they want and how much should we care? Isn't that X's responsibility, as cmurphy points out? | 14:27 |
| cmurphy | TheJulia: you don't think the vendor generally has its customers' interests at heart? | 14:28 |
| cmurphy | if customer feedback is taking a backseat that's not a vendor i would choose for anything | 14:29 |
| dhellmann | I don't think it's reasonable for us to assume that the vendor is ignoring their customers. At some point we have to assume that problem would work itself out. | 14:29 |
| TheJulia | One point, it is often not a want, but a complete lack of knowledge/understanding or time... or even worse, forbidden by policy. cmurphy is right, it is not X's responsibility, but it is good to steward information they obtain back to the underlying communities. | 14:29 |
| *** david-lyle has quit IRC | 14:30 | |
| TheJulia | cmurphy: more so the thought that all customer feedback is framed in the plans and vision of a vendor, those may not be the plans and visions of a customer. The customer may not share that data, and that intermediate step may warp the feedback as a result. The age old problem of wispering in person's ear next to you and watching the statement change as it crosses the room. | 14:31 |
| dhellmann | how far do we, as non-vendors to those customers, need to go to solicit their feedback? | 14:32 |
| *** dklyle has quit IRC | 14:32 | |
| TheJulia | I think, at least ideally, that if we could reduce the steps in any feedback loop, or more directly engage from a community standpoint, that might net us a better understanding of the customer context. | 14:32 |
| dhellmann | are you thinking of any specific steps that could be eliminated? | 14:33 |
| TheJulia | dhellmann: I think it would be in vendors best interests to help facilitate, to say "Hey, if you want to be involved in the long term direction or provide raw feedback/use cases, go to the main community" | 14:33 |
| dhellmann | ok, sure. but what could/should we do from the community side? | 14:34 |
| dhellmann | if we want to make it easy to engage with us and obvious that we want that, is there something we need to change? | 14:35 |
| cmurphy | at least one of my customers needed me to proxy for them on a launchpad bug, for some legal reason they didn't go into they wouldn't file it or comment on it themselves | 14:35 |
| dhellmann | having a legal reason is interesting. but it seems like the system worked there: they talked to their vendor | 14:36 |
| cmurphy | right - the people who choose to use vendors do so because they want their vendor to represent them in these things | 14:36 |
| dhellmann | ttx's original point was that sometimes we want input from those users more directly. maybe there are reasons we *can't* have that sometimes. I'm looking for things we could change that are hindering our ability to get it that we could fix. | 14:37 |
| dhellmann | I try to proxy the other way, fwiw. I don't know the number of threads I've started on our internal list to raise questions from the community with folks at RH who are less focused upstream than I am. | 14:38 |
| cdent | dhellmann: I wonder if we shouldn't be a bit more brazenly open "if you don't tell us, we can't do, so we're going to do this stuff we do know" | 14:38 |
| TheJulia | dhellmann: perhaps all we need is an anonymous tip box.... | 14:38 |
| dhellmann | TheJulia : that's an interesting thought experiment. it can be hard to have a conversation with an anonymous party, though. | 14:39 |
| *** mriedem has joined #openstack-tc | 14:39 | |
| TheJulia | True, but their statements, (if of course, well stated) have good context, it is something to help us frame our thoughts and try and start a discussion since it is ultimately, new information | 14:40 |
| TheJulia | of course, it may also be old, and then there is the issue of spambots | 14:40 |
| TheJulia | cdent: That makes a lot of sense to me | 14:41 |
| cdent | A related thing is for us to have some damn self respect: we do what we think is right until feedback says otherwise. Stop guessing. | 14:41 |
| dhellmann | so if we say we're less concerned with users who are not actively collaborating with us, and we expect customers of vendors to (at least optionally) be represented by those vendors, is everything we're doing now enough? can we do more to get that vendor feedback in different forms? earlier in the process? | 14:42 |
| TheJulia | cdent: ++ | 14:42 |
| cdent | dhellmann: I've got to step out, but will think on that while out. | 14:42 |
| dhellmann | ++ | 14:43 |
| fungi | an example of missed opportunities to forward feedback: recently in working to bring an arm64-based cloud into our nodepool we discovered we needed gpt/efi support added to dib... | 14:44 |
| fungi | there were no open feature requests for this so the dib team hadn't prioritized it previously | 14:44 |
| dhellmann | fungi : does that mean no one wanted it? or people worked around it? | 14:45 |
| fungi | on searching around, i found a bugzilla report against rdo asking for dib to get gpt/efi support | 14:45 |
| fungi | it had never been forwarded upstream | 14:45 |
| *** rosmaita has joined #openstack-tc | 14:45 | |
| *** gcb has joined #openstack-tc | 14:46 | |
| fungi | something as simple as copy-pasting from bz into a new lp bug would have made a noticeable difference | 14:47 |
| TheJulia | when I was at HPE, one of our engineering teams was pushing hard for it. They would collaborate on existing patches, offer up solutions. It was also a time when DIB reviews were not that active and dib was really not tracking work... nor was anyone there to say "Hey, go do x"... eventually they gave up due to resistance | 14:47 |
| fungi | well, at least the good news is you can now boot uefi-based systems with dib images, it's just unfortunate a major vendor in our ecosystem knew they had customers wanting it already and hadn't told us | 14:48 |
| TheJulia | so this kind of takes us to the discussion of a single point of truth, or in this case need | 14:49 |
| dhellmann | fungi : does not forwarding it upstream mean the vendor didn't prioritize it? | 14:49 |
| TheJulia | there are presently WAY too many places for this sort of information to get filed with some of the project overlaps | 14:49 |
| dhellmann | It doesn't seem likely that we'll get vendors to drop their own issue trackers. | 14:57 |
| smcginnis | As far as getting more indirect feedback - I wonder if we should put some effort towards having birds of a feather or other types of sessions at things like Red Hat Summit, etc. | 14:57 |
| dhellmann | I'm not sure we want to encourage them to file *everything* upstream either, even if they would. | 14:57 |
| dhellmann | smcginnis : that's an interesting idea | 14:57 |
| dhellmann | I haven't been to a RHS so I'm not sure how they're organized. | 14:58 |
| smcginnis | Still maybe limited, but it would be one path to try to get more directly to the consumers of those distro releases. | 14:58 |
| fungi | dhellmann: i suppose. i mean, in this case it was only a matter of rotting there for a few months, but the sad part is that the comment on the bug indicating dib is where support would need to be implemented was a regular openstack contributor and didn't pass that request along to the project | 15:01 |
| dhellmann | yeah, that sounds like a failure of our internal processes | 15:01 |
| fungi | so even within our established base of contributors we may be able to do a better job of raising awareness | 15:01 |
| dhellmann | so maybe that's -- exactly -- an area we can work on | 15:02 |
| *** hongbin has joined #openstack-tc | 15:02 | |
| persia | On leaving LTS to distros: when I was a distro dev, I always preferred when upstream gave us a place to collaborate with other distros: sometimes we created midstream repos when they did not. From this, I suggest we (openstack) would do well to make distro devs feel part of us when working on LTS branches, and let them use our infra to do it. | 15:05 |
| smcginnis | persia: That sounds reasonable. We tried to actually do that with the stable/* branches though. If we can at least get a couple vendors asking for something like an lts/* to collaborate, I would be all for it. | 15:09 |
| persia | Vendors+DIY ops+cv polishers is likely a better audience. | 15:11 |
| *** david-lyle has joined #openstack-tc | 15:42 | |
| *** gcb has quit IRC | 15:47 | |
| dhellmann | smcginnis : rather than renaming the branches I like the idea of just not closing them | 15:54 |
| dhellmann | besides making thing simpler for consumers, it's less work upstream | 15:54 |
| smcginnis | dhellmann: Yes, that would be simpler. | 15:54 |
| smcginnis | I just wonder if we need an explicit name change. | 15:55 |
| smcginnis | With stable we had some committment from a few vendors that they would support stable longer than our current policy. | 15:55 |
| dhellmann | perhaps we don't want to call the branches "stable" at all any more | 15:55 |
| dhellmann | since they change "modes" periodically | 15:55 |
| dhellmann | maybe just series/ | 15:55 |
| smcginnis | It was agreed to since there were multiple that were going to be ther efor it. | 15:55 |
| smcginnis | Then it broke within a couple months and no one ever did anything about it. | 15:56 |
| smcginnis | dhellmann: Oh, I like that. series/ocata would be better. Or at least better than the implied state that stable/ gives. | 15:56 |
| dhellmann | right | 15:56 |
| dhellmann | and if we want to "close" a branch we could do that with a job that just always votes -1 with an appropriate message | 15:57 |
| smcginnis | openstack-tox-nope | 15:57 |
| dhellmann | instead of deleting it | 15:57 |
| dhellmann | having to work around a bunch of our processes in reno has made me look for ways to simplify | 15:57 |
| dhellmann | that and realizing just how much of them are based on the idea of a large pool of 100% time contributors | 15:58 |
| smcginnis | We definitely need to do more simplification. | 15:58 |
| smcginnis | Code and process wise. | 15:58 |
| dhellmann | yes to both | 15:58 |
| cdent | I like the "series" idea | 16:00 |
| cdent | but either renaming branches, or using new names in the future, is a lot of changes to thinks like grenade :( | 16:00 |
| dhellmann | yeah | 16:01 |
| dhellmann | is there any reason we couldn't go through all of the projects with open stable branches and create series branches for them? | 16:01 |
| dhellmann | I mean, that's all automated now, so... | 16:01 |
| dhellmann | maybe renaming is more trouble than it's worth -- that's what we decided when we changed the release processes | 16:02 |
| openstackgerrit | Hongbin Lu proposed openstack/governance master: Add devstack-plugin-container to QA team https://review.openstack.org/540906 | 16:08 |
| ttx | yes, we considered renaming them to series/ in the past (when we dropped release/) but decided too much stuff assumes stable/ | 17:22 |
| TheJulia | why was release/ dropped? it seems kind of logical to me.. it was a release branch, it still is, it might just not be released from again | 17:27 |
| dhellmann | TheJulia : it was only called that during the period where the release was being finalized, and then immediately renamed to stable | 17:32 |
| dhellmann | the renaming took a lot of coordination, so we decided to just go right to stable and adjust acls on the branch instead | 17:32 |
| TheJulia | so it doesn't seem like there would be an issue going back to release/ if we wanted | 17:33 |
| *** jpich has quit IRC | 17:35 | |
| dhellmann | except the increasing amount of tooling built around the literal string "stable/" | 17:35 |
| *** dtantsur is now known as dtantsur|afk | 17:53 | |
| *** david-lyle has quit IRC | 18:01 | |
| fungi | also renaming long-lived existing branches would generate much downstream disruption for people tracking those branches | 18:17 |
| fungi | there is no such thing as a redirect in git reference names. closest may be a lightweight tag at the old branch name pointing to the new branch name, but i expect that would still not do much other than make `git checkout <oldname>` work, i doubt it would solve `git pull` in tracking branches with the old name | 18:19 |
| fungi | if we wanted to do it, nicest would be to update all our toolig to treat "stable/" and "series/" identically, and then transition to the new naming pattern only with newer releases while the stable/.* branches for older releases age out and get eol'd | 18:26 |
| fungi | though if we're dropping the idea of deleting branches at eol, then we effectively can't ever remove the handling for the old pattern | 18:26 |
| dhellmann | fungi : right, and if we can't drop it, let's not complicate matters further by adding another name | 18:39 |
| dhellmann | as nice as it is to have "correct" names, sometimes practicality beats purity | 18:40 |
| smcginnis | ++ | 18:45 |
| TheJulia | ++ | 18:56 |
| *** david-lyle has joined #openstack-tc | 18:57 | |
| *** harlowja has joined #openstack-tc | 19:03 | |
| *** coolsvap has quit IRC | 19:04 | |
| cdent | TheJulia: woot on ironic ptl self-nomination. Can you describe what "My vision is for ironic to be utilized in more use cases outside of what we have typically seen as our primary user." means? Who is the primary user and who are the other ones you'd like to make happen? | 19:09 |
| TheJulia | cdent: Primary user being nova, so I think it would be good to encourage the ecosystem of those who don't interact with ironic through nova. | 19:10 |
| cdent | ah, excellent. yes please. | 19:10 |
| TheJulia | Largely, that seems to be large operators who are more focused on managing baremetal as they see fit. It is not as cloudy, but we know people are doing it today | 19:11 |
| TheJulia | so it behooves us to support their efforts and try to better bring those users into the fold | 19:11 |
| fungi | infra-cloud used ironic via bifrost to manage the systems on which we puppeted our openstack deployment | 19:12 |
| fungi | it was quite a nice setup (while it lasted) | 19:12 |
| fungi | [r.i.p. infra-cloud] | 19:12 |
| cdent | :( | 19:13 |
| cmurphy | :'( | 19:14 |
| TheJulia | :( | 19:14 |
| cdent | fungi: I don't know anyone who wants to do this, so this is entirely theoretical: But supposing some organization wanted to donate money for infra to buy AWS capacity for including in the CI pool. Would that be workable? | 19:18 |
| cmurphy | o.0 | 19:19 |
| fungi | cdent: eventually probably (or more likely donate access to their account), but not until nodepool grows aws support | 19:19 |
| fungi | i don't think we'd want the foundation stuck acting as a go-between on funds for that | 19:19 |
| fungi | donating access to something someone else pays for directly tends to work out better for us | 19:20 |
| cdent | I was thinking about in more in terms of whether it would be philosophical ikcy | 19:21 |
| cdent | totally unrelated, I've managed to capture one of my biggest concerns about openstack collaboration in a tweet: https://twitter.com/anticdent/status/960593109620084736 | 19:21 |
| fungi | it's likely nodepool will grow support for non-openstack cloud platforms anyway, since we're seeing an increasing number of non-openstack downstream users (right now their only option is to define static job nodes) | 19:21 |
| fungi | i wouldn't be surprised if in another year or two nodepool had support for azure, aws, gce... | 19:22 |
| cdent | seems sane | 19:24 |
| dims | ++ fungi | 19:25 |
| fungi | i still expect openstack to be our primary backend | 19:26 |
| fungi | also one of the bits we're missing today is the ability to segment nodepool for better multi-tenancy so that different projects can get their own resource assignments (for example, someone wants to donate an aws account to augment testing for kata containers but doesn't want it used for other purposes) | 19:28 |
| fungi | well, s/projects/communities/ probably | 19:28 |
| fungi | or what the foundation is calling "strategic focus areas" | 19:29 |
| fungi | all stuff i expect to come up at the ptg for people bored^H^H^H^H^Hinterested enough to hang out in the infra room | 19:30 |
| TheJulia | fungi: perhaps obtain a hypnotoad? | 19:30 |
| fungi | all glory to the hypnotoad | 19:32 |
| TheJulia | \o/ | 19:35 |
| cdent | I need to warm up the clone machine for the PTG. I need to start soon as each clone takes a few days to be ready and I've only got the one machine. | 19:38 |
| TheJulia | I guess clones make more sense than teleportation.... | 19:39 |
| * dhellmann dusts off his time-turner | 19:49 | |
| *** diablo_rojo_ has quit IRC | 20:13 | |
| *** rockyg has joined #openstack-tc | 20:13 | |
| *** diablo_rojo_ has joined #openstack-tc | 20:15 | |
| *** cdent has quit IRC | 20:32 | |
| fungi | i just project a holographic presence into all the rooms | 20:34 |
| fungi | [please state the nature of the medical emergency] | 20:34 |
| cmurphy | :D | 20:41 |
| smcginnis | :) | 20:45 |
| openstackgerrit | Manoj Kumar proposed openstack/governance master: Fourth phase of the deprecation of trove-integration https://review.openstack.org/541007 | 21:06 |
| dmsimard | fungi: +1 for bifrost but I still haven't found something that was simpler than a PXE server :) | 21:37 |
| *** rockyg has quit IRC | 21:39 | |
| fungi | dec mop | 21:43 |
| fungi | at least if all you needed to boot were lat terminal servers | 21:45 |
| dmsimard | fungi: decnet seems to predate my career (or even my birth) :/ | 21:46 |
| fungi | you're making me feel old | 21:46 |
| dmsimard | sorry :( | 21:47 |
| fungi | not your fault, i have plenty of other reasons to feel old too | 21:49 |
| dmsimard | ah, actually I recently learned that saying "sorry" can be interpreted very differently outside Canada.. I'm going to need to really think twice about how I use it moving forward | 21:50 |
| fungi | it's quite the staple of canadian english vernacular, so i've come to interpret it based on where i think someone originates | 21:51 |
| *** kumarmn has quit IRC | 23:45 | |
| *** kumarmn has joined #openstack-tc | 23:45 | |
| *** kumarmn has quit IRC | 23:50 | |
| *** hongbin has quit IRC | 23:53 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!