| *** gema has quit IRC | 00:22 | |
| *** gema has joined #openstack-defcore | 00:24 | |
| *** dwalleck has joined #openstack-defcore | 00:26 | |
| *** dwalleck has quit IRC | 00:30 | |
| *** gema has quit IRC | 00:48 | |
| *** gema has joined #openstack-defcore | 00:50 | |
| *** gema has quit IRC | 01:36 | |
| *** gema has joined #openstack-defcore | 01:42 | |
| *** rick_ has joined #openstack-defcore | 03:08 | |
| *** gema has quit IRC | 03:32 | |
| *** gema has joined #openstack-defcore | 03:34 | |
| *** gema has quit IRC | 03:52 | |
| *** gema has joined #openstack-defcore | 03:54 | |
| *** markvoelker_ has quit IRC | 04:40 | |
| *** rick_ has quit IRC | 05:09 | |
| *** rick_ has joined #openstack-defcore | 05:22 | |
| *** galstrom_zzz is now known as galstrom | 05:56 | |
| *** markvoelker has joined #openstack-defcore | 06:40 | |
| *** markvoelker has quit IRC | 06:45 | |
| *** MarkAtwood has joined #openstack-defcore | 06:53 | |
| *** alex_klimov has joined #openstack-defcore | 07:01 | |
| *** markvoelker has joined #openstack-defcore | 07:41 | |
| *** markvoelker has quit IRC | 07:46 | |
| *** galstrom is now known as galstrom_zzz | 07:55 | |
| *** breitz has quit IRC | 07:58 | |
| *** breitz1 has joined #openstack-defcore | 07:58 | |
| *** MarkAtwood has quit IRC | 08:14 | |
| *** GheRivero has left #openstack-defcore | 08:15 | |
| *** alex_klimov has quit IRC | 08:21 | |
| *** alex_klimov has joined #openstack-defcore | 08:32 | |
| *** rick_ has quit IRC | 08:33 | |
| *** markvoelker has joined #openstack-defcore | 09:42 | |
| *** markvoelker has quit IRC | 09:46 | |
| *** alex_klimov has quit IRC | 10:11 | |
| *** alex_klimov has joined #openstack-defcore | 11:08 | |
| *** markvoelker has joined #openstack-defcore | 11:43 | |
| *** markvoelker has quit IRC | 11:47 | |
| *** markvoelker has joined #openstack-defcore | 12:43 | |
| *** markvoelker has quit IRC | 12:48 | |
| *** markvoelker has joined #openstack-defcore | 13:09 | |
| *** alex_klimov has quit IRC | 13:33 | |
| *** alex_klimov has joined #openstack-defcore | 13:33 | |
| *** MarkAtwood has joined #openstack-defcore | 13:59 | |
| *** MarkAtwood has quit IRC | 14:13 | |
| *** openstackgerrit has quit IRC | 14:31 | |
| *** openstackgerrit has joined #openstack-defcore | 14:32 | |
| *** mfisher_ora has joined #openstack-defcore | 14:52 | |
| *** dwalleck has joined #openstack-defcore | 15:12 | |
| *** pbredenb has quit IRC | 15:31 | |
| *** pbredenb has joined #openstack-defcore | 15:32 | |
| *** dfisher has joined #openstack-defcore | 15:50 | |
| *** pilgrimstack has joined #openstack-defcore | 15:56 | |
| *** onga has joined #openstack-defcore | 15:57 | |
| *** Catherine has joined #openstack-defcore | 15:57 | |
| *** albertw has joined #openstack-defcore | 15:57 | |
| *** Catherine is now known as Guest22962 | 15:58 | |
| *** seanw1 has joined #openstack-defcore | 15:58 | |
| *** jlk has joined #openstack-defcore | 15:59 | |
| *** Guest22962 has left #openstack-defcore | 15:59 | |
| eglute | #startmeeting defcore | 16:00 |
|---|---|---|
| openstack | Meeting started Wed Nov 18 16:00:28 2015 UTC and is due to finish in 60 minutes. The chair is eglute. Information about MeetBot at http://wiki.debian.org/MeetBot. | 16:00 |
| openstack | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 16:00 |
| openstack | The meeting name has been set to 'defcore' | 16:00 |
| eglute | Hello everyone, please let us know if you are here for the defcore meeting | 16:00 |
| *** dcarmon has joined #openstack-defcore | 16:00 | |
| dwalleck | o/ | 16:01 |
| eglute | #link https://etherpad.openstack.org/p/DefCoreRing.3 | 16:01 |
| markvoelker | o/ | 16:01 |
| dfisher | o/ | 16:01 |
| mfisher_ora | o/ | 16:01 |
| jlk | o/ | 16:01 |
| hogepodge | o/ | 16:01 |
| pbredenb | o/ | 16:01 |
| albertw | o/ | 16:01 |
| seanw1 | o/ | 16:01 |
| eglute | DefCore is popular this morning :D | 16:01 |
| dfisher | (with Oracle) :) | 16:01 |
| mfisher_ora | anthills | 16:02 |
| mfisher_ora | kicked | 16:02 |
| mfisher_ora | see comments last week :) | 16:02 |
| VanL | o/ | 16:02 |
| eglute | #topic must OpenStack run Linux OS to pass DefCore | 16:02 |
| onga | o/ | 16:02 |
| *** alex_klimov has quit IRC | 16:02 | |
| eglute | #link https://review.openstack.org/#/c/244782/ | 16:02 |
| *** Catherine1 has joined #openstack-defcore | 16:02 | |
| jlk | ^^ that's why it's poular | 16:03 |
| jlk | popular even. | 16:03 |
| eglute | please review the patch and all the comments if you have not yet | 16:03 |
| eglute | The patch is asking to flag specific tests, however, it raised a broader issue | 16:03 |
| eglute | Would someone from Oracle like to present their case? | 16:04 |
| eglute | or rather, to summarize it? mfisher_ora? | 16:05 |
| mfisher_ora | So basically, these tests use a utility function inside of Tempest in order to do instance validation | 16:05 |
| mfisher_ora | the instance validation are fairly basic things like 'make sure hostname is set correctly' or 'verify the number of vcpus is correct' | 16:05 |
| mfisher_ora | unfortunately, the utility function is hard coded to use linux-specific commands, and if the VM OS is not linux, the tests will always fail | 16:05 |
| eglute | #chair hogepodge | 16:06 |
| openstack | Current chairs: eglute hogepodge | 16:06 |
| mfisher_ora | The intent of the flags was to allow non-linux VM tests to pass until there's another option available in Tempest to either support multiple OSes (unwieldy and unwelcome for a lot of reasons), or provide an abstraction mechanism to allow a DefCore / RefStack user to provide their own commands or library of commands to run instead | 16:07 |
| mfisher_ora | In short, becaues the utilities are linux specific, no VM running a non-linux OS can ever pass a defcore standard that includes these tests | 16:07 |
| mfisher_ora | This doesn't solely apply to Oracle's Solaris offerings, but that's how I discovered it since currently we're testing our Nova driver and using Solaris Zones | 16:08 |
| markvoelker | Point of curiosity: tests aside, do those capabilities actually all work with the Zones driver? E.g. do instance hostnames actually get set, etc? | 16:08 |
| dfisher | 100% | 16:08 |
| markvoelker | Thanks. | 16:08 |
| mfisher_ora | Yes, I currently have my own version of remote_client and I've changed the tempest tests to use it instead of the linux client, and everything works fine | 16:09 |
| eglute | Thank you mfisher_ora. | 16:09 |
| markvoelker | eglute: I think there are some folks here who had strong opinions on the patch (jlk et al), perhaps we should let them say their piece as well if they have anything to add to their gerrit comments? | 16:10 |
| eglute | +1 | 16:11 |
| eglute | Anyone would like to add anything? | 16:11 |
| jlk | Hi | 16:11 |
| jlk | My main objection is that this patch is coming at the defcore repo. It really feels like putting the cart before the horse, and it's masking things we'd really like to see pass. This driver is out of tree, and according to Nova team, it may be along battle to get it into tree. | 16:12 |
| jlk | If the goal is to make tests pass, I feel like the work should instead happen at the Tempest level. | 16:12 |
| jlk | I think it's inappropriate to introduce the flags at the defcore level. | 16:13 |
| jlk | Having the flags at defcore makes this a policy of "what does OpenStack mean" argument, rather than a technical "how do we do testing" argument. | 16:13 |
| jlk | Flagging the tests doesn't actually make the driver any better or more complete, all it does is mask the places where the tests fail to account for the driver limitations | 16:14 |
| dfisher | but defining "what OpenStack means" is a critical (if not THE critical) aspect of this patch. | 16:14 |
| dfisher | it's just manifesting in a technical way | 16:14 |
| jlk | that's fair. | 16:14 |
| pbredenb | ..and to follow, isn't Defcore's charter to define "what OpenStack means"? | 16:14 |
| eglute | any other objections that have not yet been listed? | 16:14 |
| jlk | which means we don't need to focus on this specific PR | 16:14 |
| dfisher | I'm in agreement with that. This PR exposed a much much larger issue that we in Solaris would like to see resolved. | 16:15 |
| jlk | eglute: outside of what's in the gerrit review, I don't think so. | 16:15 |
| hogepodge | jlk: one of the intentions of a flag is to mark the test as problematic and give space to not have to pass the test until it is fixed. resizing compute instances is flagged until a more secure method is implemented in nova, for example. We're trying to take improving upstream into account. | 16:15 |
| mfisher_ora | A small rebuttal on flagging the test because of a technical reason, there's already precedent to do so as there is a test in defcore that is flagged because Tempest currently has skip exception applied to that test | 16:15 |
| jlk | hogepodge: that's fair, if upstream is committed to fixing the issue. From Nova team feedback, it sounds like they wouldn't accept a driver that is incapable of running a Linux userland. | 16:16 |
| eglute | I am in favor of having multiple OS VMs run on OpenStack, and right now we have defaulted to Linux. mfisher_ora are you working on supporting different OSs on your OpenStack deployments? | 16:16 |
| jlk | If upstream isn't going to take such a driver, then flagging the tests seems inappropriate. | 16:16 |
| dfisher | as a side note to jlk's previous comment: that's an absurd stance to take since Nova is designed to scale to as many compute nodes running whatever OS as an operator requires. | 16:17 |
| dfisher | with properties in images and the scheduler, everything *just works* in a heterogenous environment with a Solaris compute node and Linux/Windows compute nodes. | 16:17 |
| jlk | dfisher: they've clarified that at a minimum it should run a Linux userland. | 16:18 |
| hogepodge | jlk: yes, it seems so. The compute driver is not a designated code section, so vendors are free to not use upstream. It's just part of the guideline, and I'm not trying to argue, just want to clarify what the standard requires (indeed, using it exposes these issues) | 16:18 |
| dfisher | officially? documented? passed with all hands voting? | 16:18 |
| dfisher | because that statement completely handcuffs us. | 16:18 |
| jlk | dfisher: no, I don't think an official vote has happened, because the question hasn't necessarily come up. | 16:18 |
| jlk | but this isn't the body to speak to Nova acceptance policy :) | 16:19 |
| jlk | do we have any nova core? | 16:19 |
| *** edmondsw has quit IRC | 16:19 | |
| dfisher | we were under the impression that if our driver supported DefCore and the Hypervisor Matrix requirements, then we'd be allowed to discuss a PR for introduction of our driver. | 16:20 |
| hogepodge | jlk: It definitely is. We want developer input. I would take as an action to consider changing the nova designated sections to specify in tree driver code. | 16:20 |
| dfisher | that work is under way right now. Our driver passes a very large percentage of DefCore (mfisher_ora: have a %) and tempest in general. | 16:20 |
| mfisher_ora | So I've been told by both openstack-qa (specifically Matt Treinish) and even in the meeting last week that you should be able to point Tempest (and by extension Defcore) at any cloud and run the tests. By defining that you must have a linux image, that is now going back on both of those statements | 16:21 |
| markvoelker | dfisher: clarification: AFAIK meeting DefCore Guidelines isn't a requirement for getting your driver into Nova. There are other drivers that don't pass everything either. | 16:21 |
| *** EddieS has joined #openstack-defcore | 16:21 | |
| eglute | dfisher mfisher_ora are you working on supporting other OSs? | 16:21 |
| dfisher | markvoelker: correct. we're trying to come at this from every angle. We want to cover Nova, docs, qa, tempest, etc. | 16:22 |
| dfisher | eglute: it's unknown at this time | 16:22 |
| dwalleck | I agree with the crux of the original argument that this is at some point a test issue. The remote_client was always meant to be an abstract base to be implemented for multiple OSes | 16:22 |
| dfisher | but DefCore sets the *standard* | 16:23 |
| dfisher | that's what this is about | 16:23 |
| eglute | DefCore's purpose in life is interoperability | 16:23 |
| *** SammyD has joined #openstack-defcore | 16:24 | |
| eglute | Ideally, it will help users the most, so that they could switch between different openstack environments without having to worry that they will behave differently | 16:24 |
| dfisher | and nova *has* that interoperability. run 1 Solaris compute node and 1+ Linux node. Everything works | 16:24 |
| jlk | What we have in the review is statements from John Garbutt and Dan Smith from Nova, both seeming in agreement that a driver that can't run Linux userland wouldn't be acceptable in Nova. | 16:25 |
| mfisher_ora | eglute: yes but the mechanism being used to do that is assuming something that it shouldn't | 16:25 |
| mfisher_ora | and is therefore excluding offerings that can absolutely pass all of the defcore tests as long as a utility library is modified to change hard-coded commands | 16:25 |
| dwalleck | mfisher_ora: and I'm all for not making those hard coded, either through multiple implementations or commands passed through a resource file | 16:26 |
| jlk | but we're also talking about two different things here | 16:27 |
| jlk | A single OpenStack cloud can handle multiple hypervisors for multiple purposes | 16:27 |
| jlk | it's entirely possible to test an OpenStack cloud, and pass all the defcore tests, when it supplies a tiny fraction of capacity that can run Linux, while the majority is dedicated to something else | 16:27 |
| dfisher | isn't that dishonest in the long run? | 16:28 |
| jlk | I don't believe there is any verbiage that the /entire/ cloud has to be capable of passing the defcore standards | 16:28 |
| mfisher_ora | side note dwalleck: I'd rather use the resource manager they've been talking about then asking openstack-qa to maintain multiple remote_client libraries in tree | 16:28 |
| jlk | if that were the case, the Rackspace public cloud wouldn't pass | 16:28 |
| markvoelker | mfisher_ora: So, let's back up a little. What's the product that you're trying to get into compliance with DefCore here? I ask b/c you mentioned running Linux+Solaris side-by-side and I'm wondering if that's part of the product? | 16:28 |
| jlk | actually I take that back, it probably would, disregard that statement. | 16:28 |
| *** edmondsw has joined #openstack-defcore | 16:28 | |
| jlk | dfisher: I don't know that it's dishonest. | 16:28 |
| *** EddieS has quit IRC | 16:28 | |
| dfisher | saying that a cloud is 100% defcore compatible but only on the linux VMs? | 16:29 |
| jlk | dfisher: defcore is about capability and interop. Your cloud deployment would be providing that | 16:29 |
| jlk | the non-linux capacity would be added value of the cloud, beyond what defcore certifies | 16:29 |
| dfisher | markvoelker: we're trying to get our Solaris offering in compliance with DefCore. | 16:30 |
| markvoelker | dfisher: can you point me to a webpage or something? Need a little more background on that product as I'm not terribly familiar with it. | 16:31 |
| dfisher | about the Solaris OpenStack offereing? | 16:32 |
| markvoelker | yes | 16:32 |
| eglute | So, right now Rackspace would not pass defcore tests if we were testing on Windows VMs. Linux, no problem. Windows only would be same test issue as with Solaris | 16:32 |
| mfisher_ora | And any future OS that may want to join in openstack | 16:32 |
| jlk | yeah, fortunately the RAX cloud offers capacity for Linux and windows | 16:32 |
| breitz1 | from a pure technical standpoint - it is not hard or time consuming to create an abstraction for these tests that would allow for multiple OSs to pass. Flagging these tests until that work can happen seems appropriate. This seems completely easy to solve. | 16:33 |
| jlk | and more to the point, the Hypervisors providing Windows capability are also capable of providing Linux capability. | 16:33 |
| hogepodge | Defcore does not specify what hypervisor should be run | 16:33 |
| dfisher | markvoelker: http://www.oracle.com/technetwork/articles/servers-storage-admin/getting-started-openstack-os11-2-2195380.html http://www.oracle.com/technetwork/server-storage/solaris11/technologies/openstack-2135773.html | 16:33 |
| markvoelker | dfisher: thanks. | 16:34 |
| hogepodge | Defcore does not directly specify which operating systems must run. | 16:34 |
| jlk | breitz1: it seems premature to flag them, until A) upstream commits to changing the tests to be abstracted, B) upstream nova agrees to take in a hypervisor driver incapable of running Linux, and C) defcore agrees that solely offering non-Linux is acceptable. | 16:34 |
| dfisher | trying to find a better "one pager" for you, but that second link has links to a bunch of things | 16:34 |
| onga | markvoelker: http://www.oracle.com/technetwork/server-storage/solaris11/documentation/solaris11-2-openstack-faqs-2194278.pdf may also be of interest | 16:34 |
| hogepodge | Defcore does indirectly require linuxy commands to test for hypervisor and network capabilities. | 16:34 |
| *** Catherine1 has quit IRC | 16:34 | |
| dfisher | that link might be out of date since it references Solaris 11.2. 11.3 was released about a month ago. | 16:34 |
| markvoelker | breitz1: The reason we're hesitant to flag things without considering carefully is that they can't be unflagged for at least six months, and in the interim users cannot depend on those capabilities from an interoperability standpoint. Hence the long discussion here. =) | 16:35 |
| markvoelker | onga: thanks | 16:35 |
| jlk | hogepodge: the question is, is that indirect requirement something that should be a design feature that people were just assuming, or is it an accident, or...? | 16:35 |
| dfisher | also, and I don't know if this counts for anything, but our driver is completely in the open. | 16:35 |
| dfisher | if you want a link to it, let me know. | 16:35 |
| onga | dfisher: It's pretty high level - it's probably appropriate to get up to speed quickly on all the core components, and it is on Juno release, not Havana | 16:35 |
| hogepodge | jlk: I think it's a bad test because it's checking for things it's not testing for | 16:36 |
| dfisher | onga: right. | 16:36 |
| hogepodge | jlk: I think that if we want linuxy behavior, that needs to be a testable capability (check-boot-cirros, for example). | 16:36 |
| hogepodge | jlk: so it's not a side effect that can change or disappear | 16:37 |
| mfisher_ora | real quick, where is the rule on the unflagging? I hadn't seen that one before | 16:37 |
| catherineD | The test is not bad... it just need the correct remote-client to be set ... | 16:37 |
| jlk | hogepodge: I would agree to that. I would not be surprised at all to find other assumptions on test coverage that are purely accidents | 16:38 |
| hogepodge | bad is a strong word | 16:38 |
| mfisher_ora | which is why I didn't flag them to remove them, just suppress them until Tempest is updated to support abstracted remote client | 16:38 |
| mfisher_ora | similar to the reboot server soft test that is listed in DefCore but is currently bugged in Tempest | 16:38 |
| hogepodge | jlk: absolutely. We don't have a good understanding of the resource requirements needed to pass defcore testing (I'm trying to work that out this cycle). | 16:38 |
| catherineD | mfisher_ora: agreed that all remote clients should be officially supported by Tempest | 16:39 |
| hogepodge | (so by bad I mean 'could be better') | 16:39 |
| catherineD | hogepodge: agreed ... | 16:39 |
| mfisher_ora | catherineD: actually I'm not necessarily saying or agreeing with that | 16:39 |
| mfisher_ora | I just think there should be a mechanism to allow a user to supply the path or the import of their own remote client if needed | 16:39 |
| markvoelker | mfisher_ora: I'll dig it up in a minute for you. Basically once a flag is in, it's in for the duration of that guideline | 16:40 |
| mfisher_ora | so reboot_server_soft has this for the flag action: "action": "Remove flag after Tempest bug is fixed (in progress).", | 16:40 |
| mfisher_ora | that would not apply immediately to all guidelines once the bug is fixed? | 16:40 |
| catherineD | The reason is the any user can also initiate DefCore tests not just the vendor ... if the remote client is not in Tempest ... not all users can have access to it | 16:41 |
| markvoelker | mfisher_ora: The flag would be removed in the next guideline. Which might be up to six months away. | 16:42 |
| mfisher_ora | CatherineD: which is sort of why I'd like to see the remote commands moved to the resource manager, with linux defaults provided but overridable by a user if they know they're hitting a non-linux OS VM | 16:43 |
| mfisher_ora | I'm just forseeing heavy pushback from openstack-qa if they were asked to support multiple remote_client libraries in tree | 16:43 |
| dwalleck | mfisher_ora: But could the multiple remote instance clients exist out of tree as plugins? | 16:44 |
| *** rockyg has joined #openstack-defcore | 16:44 | |
| mfisher_ora | Possibly yes, I'm afraid my knowledge on the plugins is somewhat bare bones | 16:45 |
| hogepodge | I have to step out of the meeting. | 16:46 |
| markvoelker | #link http://git.openstack.org/cgit/openstack/defcore/tree/HACKING.rst#n81 | 16:46 |
| markvoelker | mfisher_ora: ^^ | 16:46 |
| eglute | So, if step back and talk about user experience and interoperability, would a user that wishes to run cross-cloud applications have the same experience on solaris openstack as on any other openstack? | 16:47 |
| mfisher_ora | markvoelker: thanks...although with more reading, I'm wondering if there's a technical issue with the test being suggested if it should be something lighter weight than a flag so that if the underlying bug is fixed, the 'not-flag' could be removed on all older guidelines immediately | 16:48 |
| dfisher | eglute: yes | 16:48 |
| markvoelker | eglute: From an API perspective, probably so from the sounds of it. | 16:48 |
| markvoelker | eglute: one of the arguments has been that users would be surprised not to be able to run Linux though. I'm frankly not convinced of that yet. | 16:49 |
| eglute | So if we are testing APIs, and they all work the same, what would the arguments be for requiring a linux image to be able to run? | 16:49 |
| jlk | That begs the question | 16:49 |
| jlk | is Interop solely about APIs? | 16:49 |
| eglute | APIs and dedicated code sections | 16:50 |
| jlk | If that is the line in the sand, then I don't think we have any argument | 16:50 |
| jlk | fI think Monty would object to that being the line in the sand for interop | 16:50 |
| jlk | but that could be addressed in a different proposal? | 16:50 |
| markvoelker | jlk: No, but frankly it's where we're at now at this particular point in time. There has been a lot of talk about other things (like image format portability), but we just aren't there yet. | 16:51 |
| eglute | #link https://github.com/openstack/defcore/blob/master/doc/source/process/CoreDefinition.rst | 16:51 |
| rockyg | I would think that, just ad infra (and some tests) run bash scripts, that may or may not include system calls, that scripting would break on a move from linux to Solaris | 16:51 |
| rockyg | Or Windows (unless windows has a linux compatibility mode) | 16:52 |
| breitz1 | or windows, BSD, or some new fancy cool OS that everybody jumps to next month | 16:52 |
| markvoelker | jlk: we're about a year into DefCore being enforcing, so only so much percentage of the ocean we've boiled yet. =) | 16:52 |
| jlk | agreed | 16:52 |
| * markvoelker looks at clock | 16:52 | |
| markvoelker | hogepodge: I see there's a note in the pad about the Board being interested in this? | 16:53 |
| eglute | 7 minutes to boil the ocean | 16:53 |
| markvoelker | hogepodge: Are you planning to bring this up with them, or....? | 16:53 |
| eglute | hogepodge has stepped away | 16:53 |
| rockyg | But, that begs the question, how many users wouldn't be aware of the OS flavor of the cloud they are running or planning to run on? | 16:53 |
| mfisher_ora | I can throw another meteor at it if you need eglute | 16:53 |
| eglute | but, hogepodge was telling me that before the committee makes the final decision, we take it to the board for approval | 16:53 |
| rockyg | eglute, yup. | 16:54 |
| markvoelker | hogepodge: I suspect the TC might be interested in the general discussion here as well if they aren't already, happy to bring it up with them for awareness. | 16:54 |
| eglute | however, the committee will need to present options to the board as well as suggested actions | 16:54 |
| * markvoelker would like to thank the folks from Oracle, the nova-core folks, and all the others who have weighed in on this so far | 16:54 | |
| rockyg | So, the whole purpose in creating this whole "cloud OS" in python is to remove OS differences. | 16:55 |
| eglute | I agree with markvoelker, this is a great discussion and raises awareness just how big the OpenStack ocean is and that DefCore's work is not done | 16:55 |
| markvoelker | One last question for the Oracle folks: let's say QA agrees on adding a way to get those tests passing on non-Linux OS's (whether via a new agent, a plugin, or something else)... | 16:56 |
| markvoelker | I presume you'd be willing to step up and help with that work since it sounds like you've done some of it already out of tree. Would you have a ballpark on how long it would take to get that support added in? | 16:57 |
| mfisher_ora | absolutely, I'm currently wrapping up some other work but I intend to jump on the resource manager work for Tempest since it seems to help address this problem amongst other things | 16:57 |
| markvoelker | I hear "it's pretty easy" so I'm trying to think what that mans in real terms, is all. | 16:57 |
| * jlk has to step out | 16:58 | |
| dwalleck | Part of the QA work for Mitaka is a resource manager, which would be part of this solution | 16:58 |
| rockyg | And, either get OS agnostic test writing rules accepted by QA, or continue the conversion as new tests are added... | 16:58 |
| mfisher_ora | As for how long that would take, I really don't have an estimation but definitely into the new year since the resources changes will take some time to implement and get through the integration process | 16:58 |
| markvoelker | mfisher_ora: ok, fair enough. | 16:58 |
| mfisher_ora | rockyg: They're already pretty good at being agnostic, most of the stuff being done just hits the api | 16:58 |
| rockyg | mfisher_ora, so, before end of Mitaka? | 16:59 |
| mfisher_ora | I'd have to look again but I want to say that resource manage is M2? | 16:59 |
| mfisher_ora | manager* | 16:59 |
| markvoelker | One last, last question: are these tests the only thing holding you back? E.g. is everything else passing at this point? | 17:00 |
| eglute | and which guideline are you testing against? | 17:00 |
| mfisher_ora | They're the only tests that are skips that aren't flags. We have a few other tests waiting for an internal bug fix to be generally available | 17:00 |
| markvoelker | mfisher_ora: thanks | 17:01 |
| * markvoelker looks at the clock again | 17:01 | |
| eglute | Thanks Everyone for the discussion today, we are out of time for the meeting, but this channel is always open :). | 17:01 |
| mfisher_ora | And it looks like the resource manager is targetting M3 | 17:01 |
| catherineD | Skip tests may caused by tempest.conf | 17:01 |
| eglute | #endmeeting | 17:01 |
| openstack | Meeting ended Wed Nov 18 17:01:44 2015 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 17:01 |
| openstack | Minutes: http://eavesdrop.openstack.org/meetings/defcore/2015/defcore.2015-11-18-16.00.html | 17:01 |
| openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/defcore/2015/defcore.2015-11-18-16.00.txt | 17:01 |
| openstack | Log: http://eavesdrop.openstack.org/meetings/defcore/2015/defcore.2015-11-18-16.00.log.html | 17:01 |
| mfisher_ora | They are, because I have run_validation set to false | 17:01 |
| rockyg | I'd just like to say, I'd love to see our tests being able to validate a pur Solaris or BSD cloud | 17:01 |
| dfisher | thanks folks. appreciate the open-minded approaches here. | 17:01 |
| rockyg | pure | 17:02 |
| catherineD | Most DefCore tests should not be skipped by Tempest at this point | 17:02 |
| eglute | mfisher_ora- which guideline are you testing against? 2015.7? | 17:02 |
| mfisher_ora | because otherwise I'll just get errors when it tries to do instance validation with vcpus | 17:02 |
| mfisher_ora | 2015.7 | 17:02 |
| eglute | thanks! | 17:02 |
| mfisher_ora | catherineD: It's on my list of work before the end of the month to start running RefStack and submitting some of our results, but as previously stated I have to hack Tempest a bit to work with some of the current Solaris-isms involving networking. I might need to ping you on how to grab subunit streams from Tempest and use those to get uploaded, with the intent that they're there to give you feedback rather than go for certificati | 17:04 |
| jlk | was there a decision made? I lost the convo thread | 17:04 |
| mfisher_ora | I don't think there was | 17:04 |
| dfisher | not that I saw. | 17:04 |
| jlk | okay. | 17:04 |
| catherineD | mfisher_ora: sure | 17:05 |
| eglute | sorry folks, we had a lot of discussion, but no decission. | 17:05 |
| eglute | I will work with the core of defcore to write up an opinion and take it to TC | 17:05 |
| dfisher | eglute: i think it's a bit telling that your emails to openstack-dev and openstack mailing lists garnered zero responses :( | 17:06 |
| rockyg | mfisher_ora, on a slightly di fferent topic, but still OpenStack, do you have any performance numbers on your test cloud that could be shared with the ML? Or is it too early? | 17:06 |
| eglute | dfisher true... but lots of great discussion in gerritt. We really try to hear everyone out | 17:06 |
| jlk | I think the community at large did a good job on avoiding a pile of +1s or -1s with no new opinions | 17:07 |
| rockyg | I need to go back and read the newest comments I'm a day and a half behind | 17:08 |
| eglute | arguments on both sides are very convincing, but we cannot loose track of the purpose of defcore. If saying no to one OS, are we going to be making Linux the only acceptable one? | 17:09 |
| eglute | so, it is tricky | 17:09 |
| SammyD | +1 eglute | 17:09 |
| rockyg | Yes. Very tricky. And extremely important. | 17:10 |
| dfisher | very. I don't envy DefCore's or the TC's work on this issue. | 17:10 |
| hogepodge | markvoelker: the foundation staff would like the tc and board to weigh in on the issue of requiring "boot Linux" as a policy or capability. | 17:10 |
| rockyg | But, I think it's a great problem to have. | 17:10 |
| hogepodge | sorry I had to step away at the end. | 17:10 |
| rockyg | It shows the breadth of interest in OpenStack. | 17:11 |
| dfisher | all I can realistically ask for is a) no FUD attacks against Solaris/Oracle (it doesn't help anything) and b) if the decision is made that BYO-Linux is required, that it is made crystal clear all over (DefCore, TC, Nova, the board, etc.) | 17:11 |
| eglute | dfisher no attacks against vendors or brands, we are taking this very seriously | 17:11 |
| dfisher | DefCore is. Members of Nova … less so | 17:12 |
| SammyD | mfisher_ora: dwalleck and I could help out with the sub-unit integration. We've been working a lot with that sort of thing. :-) | 17:12 |
| breitz1 | right - clear statement of what is required is critical. Imo it would be a shame to move away from the OS agnostic stance that is currently baked into the design. | 17:12 |
| johnthetubaguy | Nova is trying to define what it means to deliver a consistent experience across multiple Nova cloud, I don't think we have a consensus yet on where to draw the line | 17:13 |
| rockyg | dfisher, This is a great exercise in opening eyes about systemic exclusivity in a community that generally considers itself extremely inclusive ;-) | 17:13 |
| * dfisher nods | 17:14 | |
| * johnthetubaguy wishs he could have made the previous meeting, but it wasn't possible :( | 17:14 | |
| dfisher | johnthetubaguy: http://eavesdrop.openstack.org/meetings/defcore/2015/defcore.2015-11-18-16.00.log.html | 17:14 |
| rockyg | Maybe we should invite Solaris/BSD/Windows OpenStack devs to the diversity WG ;-) | 17:14 |
| dfisher | we have cookies!~ | 17:15 |
| eglute | chocolate chip? | 17:15 |
| rockyg | Glueten free? | 17:15 |
| dfisher | well, i think breitz1 stole a dozen boxes of Pocky from Tokyo. We could bring those | 17:15 |
| breitz1 | don't think I didn't | 17:15 |
| dfisher | of course, he probably ate all them on the way to Narita | 17:15 |
| *** SammyD has quit IRC | 17:16 | |
| mfisher_ora | rockyg: had to step away for a bit, we don't have performance numbers right now | 17:16 |
| dfisher | rally numbers, specifically? | 17:17 |
| rockyg | mfisher_ora, are you based in Silicon Valley? I'd love to host a meetup about a Solaris OpenStack cloud.... | 17:17 |
| dfisher | some of us are in Santa Clara. mfisher_ora and myself are in Denver | 17:17 |
| mfisher_ora | dfisher and I are in Broomfield Colorado if you feel like flying out for some snow! | 17:17 |
| rockyg | Oh, now you've really confused me. Both fishers are with Oracle *and* in Colorado! | 17:18 |
| dfisher | we're brothers. | 17:18 |
| mfisher_ora | and related :) | 17:18 |
| dfisher | mom thinks I'm better though. | 17:18 |
| mfisher_ora | he develops, I test | 17:18 |
| rockyg | Kewl. | 17:19 |
| *** seanw1 has left #openstack-defcore | 17:19 | |
| eglute | lol! | 17:19 |
| rockyg | Mom must be a dev. They're the only ones who don't understand testing harder than dev ;-) | 17:19 |
| dfisher | lol | 17:20 |
| rockyg | So, let me know when your test cloud will be ready for a demo and lots of questions from an SV crowd. It could be *fun* (well maybe not for the speakers....) | 17:21 |
| dfisher | rockyg: were you specifically interested in Rally numbers? | 17:21 |
| dfisher | we might have that somewhere. | 17:21 |
| mfisher_ora | so eglute, hogepodge, markvoelker, is there a way to suggest changes to, well, the way Defcore itself handles certain things? The 6 month thing for flagging is sticking in my mind as being incorrect for handling this but there's no other mechanism to use. I'd like to propose something that says 'add a new term that covers technical problems with Tempest rather than issues with what the test itself is doing' that might be less of | 17:22 |
| dfisher | cut off after: " I'd like to propose something that says 'add a new term that covers technical problems with Tempest rather than issues with what the test itself is doing' that might be less of" | 17:22 |
| mfisher_ora | bah | 17:22 |
| markvoelker | mfisher_ora: WE generally just do it by submitting patches against the file containing the procedure in question. | 17:22 |
| eglute | mfisher_ora i think bringing it to us, submitting a patch is a good way to handle it. | 17:22 |
| mfisher_ora | which file defines that though | 17:23 |
| eglute | in test cases, we would much rather see fixes to tests than flag them | 17:23 |
| markvoelker | mfisher_ora: in this case, HACKING. | 17:23 |
| eglute | we know that tempest tests as they are, are not sufficient | 17:23 |
| markvoelker | mfisher_ora: Maybe a little background on that rule would be helpful though... | 17:23 |
| *** kbaikov has quit IRC | 17:23 | |
| mfisher_ora | okay I'll probably suggest something today and I'll be as verbose as possible | 17:23 |
| *** kbaikov has joined #openstack-defcore | 17:24 | |
| eglute | I need to step away for a couple meetings, but will be back later | 17:24 |
| markvoelker | mfisher_ora: It was added as a protection for users and as a measure to keep the playing field level for vendors. Imagine a case where VendorA achieves compliance with 2015.07 while a flag is in place, and VendorB starts testing after it's removed... | 17:24 |
| markvoelker | VendorA can technically get away with not supporting the capability in question, whereas VendorB gets held to a higher standard. | 17:25 |
| mfisher_ora | Oh sure, I fully understand the idea behind the flagging, its very straight forward | 17:25 |
| markvoelker | Moreover, when End User Z starts using those two products, he may rightfully assume that they both support all the capabilities...when they actually don't. | 17:25 |
| markvoelker | So End User Z gets pretty fed up with the OpenStack Powered mark as meaning anything. | 17:25 |
| markvoelker | Thus the idea that once a thing is flagged, it stays flagged in that Guideline. Users then at least know they can't rely on the capability, rather than assuming they can and potentially finding out otherwise the hard way. | 17:26 |
| mfisher_ora | I just want to suggest something that implicitly (or explicitly) states that the test is fine, its a good test, but there are problems with the Tempest test being used for the capability that the mark can be removed once Tempest is updated rather than having to wait up to six months for glagging | 17:26 |
| mfisher_ora | flagging* | 17:27 |
| mfisher_ora | I'm not even sure that the mark should necessarily allow people to 'get away with' not passing that test, but for End User Z he now knows potentially why VendorC's cloud can't meet that guideline | 17:28 |
| markvoelker | mfisher_ora: Yeah, the hard part there is we'd have to have some way to verify that the capability actually works if the test for it isn't required. Right now "it works" is defined by the test. | 17:28 |
| mfisher_ora | which is why I can see this 'mark' doesn't suppress requirement | 17:29 |
| mfisher_ora | You still don't meet the guideline, but you have a visible reason as to why not built in to defcore | 17:29 |
| mfisher_ora | Then when tempest is updated to resolve that issue, you have no excuses anymore if you still fail :) | 17:30 |
| markvoelker | mfisher_ora: so would the idea to give vendors an OpenStack Powered logo with an asterisk that could be swapped for a non-asterisk logo when they re-test after the test is fixed? =) | 17:31 |
| mfisher_ora | No, they don't get the logo | 17:31 |
| * markvoelker has to run, but will certainly review a patch if you propose one | 17:32 | |
| *** dcarmon has quit IRC | 17:32 | |
| mfisher_ora | but when End User Z asks VendorC, 'hey why don't you meet this guideline?' VendorC has a more weighty response to say 'well if you look at the test, there is a 'mark' on the test that explains that there is a problem with the underlying testing' | 17:32 |
| *** onga has left #openstack-defcore | 17:42 | |
| *** rockyg has left #openstack-defcore | 18:31 | |
| *** MarkAtwood has joined #openstack-defcore | 18:37 | |
| *** pilgrimstack has quit IRC | 18:55 | |
| *** MarkAtwo_ has joined #openstack-defcore | 19:15 | |
| *** MarkAtwood has quit IRC | 19:16 | |
| *** dwalleck has quit IRC | 19:23 | |
| *** dwalleck has joined #openstack-defcore | 19:29 | |
| *** dfisher has left #openstack-defcore | 19:34 | |
| *** MarkAtwo_ is now known as MarkAtwood | 19:45 | |
| *** alex_klimov has joined #openstack-defcore | 19:48 | |
| *** MarkAtwood has quit IRC | 19:54 | |
| *** dwalleck has quit IRC | 20:09 | |
| *** dwalleck has joined #openstack-defcore | 20:09 | |
| *** MarkAtwood has joined #openstack-defcore | 20:11 | |
| *** MarkAtwood has quit IRC | 20:18 | |
| *** dwalleck_ has joined #openstack-defcore | 20:58 | |
| pbredenb | :q! | 20:59 |
| pbredenb | :q! | 20:59 |
| *** dwalleck_ has quit IRC | 21:00 | |
| *** openstack has joined #openstack-defcore | 21:04 | |
| *** breitz1 is now known as breitz | 21:25 | |
| *** MarkAtwood has joined #openstack-defcore | 21:50 | |
| *** dwalleck has quit IRC | 22:11 | |
| *** MarkAtwood has quit IRC | 22:27 | |
| *** rick_ has joined #openstack-defcore | 22:35 | |
| *** edmondsw has quit IRC | 22:49 | |
| *** rick_ has quit IRC | 23:16 | |
| *** mfisher_ora has quit IRC | 23:26 | |
| *** alex_klimov has quit IRC | 23:26 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!