*** VW has joined #craton | 00:00 | |
*** VW has quit IRC | 00:00 | |
*** VW has joined #craton | 00:00 | |
*** VW has quit IRC | 00:02 | |
*** VW has joined #craton | 00:03 | |
*** valw has joined #craton | 00:20 | |
*** Syed__ has quit IRC | 01:05 | |
*** valw has quit IRC | 01:21 | |
*** VW has quit IRC | 01:48 | |
openstackgerrit | Thomas Maddox proposed openstack/python-cratonclient master: Adds basic Cloud resource CRUD to CLI https://review.openstack.org/437098 | 02:37 |
---|---|---|
*** VW has joined #craton | 02:47 | |
*** VW has quit IRC | 03:10 | |
*** VW has joined #craton | 03:23 | |
*** wirehead_ has quit IRC | 03:55 | |
*** wirehead_ has joined #craton | 03:58 | |
*** wirehead_ has quit IRC | 03:59 | |
*** wirehead_ has joined #craton | 04:00 | |
*** valw has joined #craton | 04:02 | |
*** VW has quit IRC | 04:10 | |
*** valw has quit IRC | 04:10 | |
*** valw has joined #craton | 04:16 | |
*** valw has quit IRC | 04:18 | |
*** VW has joined #craton | 04:42 | |
*** pwnall1337 is now known as zz_pwnall1337 | 05:16 | |
*** VW has quit IRC | 06:30 | |
*** VW has joined #craton | 09:10 | |
sulo | o/ | 09:17 |
*** VW has quit IRC | 09:18 | |
openstackgerrit | Merged openstack/craton master: Updated from global requirements https://review.openstack.org/437178 | 11:49 |
openstackgerrit | Merged openstack/python-cratonclient master: Updated from global requirements https://review.openstack.org/432085 | 12:01 |
openstackgerrit | Merged openstack/python-cratonclient master: Add parent_id to host fields https://review.openstack.org/433563 | 12:01 |
-openstackstatus- NOTICE: Mirror update failures are causing some Ubuntu-based jobs to fail on invalid qemu package dependencies; the problem mirror is in the process of updating now, so this condition should clear shortly. | 12:59 | |
*** ChanServ changes topic to "Mirror update failures are causing some Ubuntu-based jobs to fail on invalid qemu package dependencies; the problem mirror is in the process of updating now, so this condition should clear shortly." | 12:59 | |
*** valw has joined #craton | 13:31 | |
*** ChanServ changes topic to "Summit talk: https://www.youtube.com/watch?v=Q-sf12SDR3M || Logs: http://eavesdrop.openstack.org/irclogs/%23craton/latest.log.html || Mon 1500 UTC in #openstack-meeting-4 || Client/ecosystem Tues 1700 UTC || Core Thur 1700 UTC || Resources: https://etherpad.openstack.org/p/Fleet_Management" | 13:36 | |
-openstackstatus- NOTICE: The mirror update process has completed and resulting issue confirmed solved; any changes whose jobs failed on invalid qemu package dependencies can now be safely rechecked to obtain new results. | 13:36 | |
*** david-lyle has joined #craton | 13:37 | |
*** valw has quit IRC | 13:50 | |
*** valw has joined #craton | 13:51 | |
*** david-lyle has quit IRC | 13:55 | |
*** valw has quit IRC | 14:09 | |
thomasem | o/ | 14:18 |
sigmavirus | \o | 14:35 |
openstackgerrit | Thomas Maddox proposed openstack/craton master: Add Cloud resource before Region https://review.openstack.org/431705 | 14:37 |
sigmavirus | thomasem: I'm beginning to wonder if there isn't a better way to apply base.http_codes to everything | 14:40 |
sigmavirus | *everything that needs it | 14:40 |
farid | hi all | 14:41 |
thomasem | sigmavirus: Is there a hook into whatever calls the HTTP verbs? | 15:03 |
thomasem | https://flask-restful-cn.readthedocs.io/en/0.3.5/extending.html#custom-error-handlers | 15:06 |
thomasem | Something worth looking into. | 15:06 |
thomasem | Looks to serve the same purpose. | 15:08 |
thomasem | "yet you want to handle all Flask-RESTful errors with the correct content type and error syntax as your 200-level requests." | 15:08 |
sigmavirus | hi farid! | 15:11 |
sigmavirus | thomasem: yeah there are pre/post filters | 15:11 |
sigmavirus | I feel like https://flask-restful-cn.readthedocs.io/en/0.3.5/extending.html#resource-method-decorators would be better though | 15:12 |
* sigmavirus shrugs | 15:12 | |
thomasem | That's fair, sigmavirus. | 15:18 |
thomasem | If nothing else, it'd probably work better with our already existing decorator (thusly not having to write something else). | 15:18 |
thomasem | I was about to send you my Spencer Reid "Well, actually..." meme, but I can't find it. :( | 15:19 |
thomasem | That's okay. I'll make another. | 15:19 |
*** VW has joined #craton | 15:22 | |
*** VW has quit IRC | 15:23 | |
*** VW has joined #craton | 15:23 | |
sigmavirus | lol | 15:24 |
*** valw has joined #craton | 15:29 | |
thomasem | Relates to this bug: https://bugs.launchpad.net/craton/+bug/1665015 | 15:32 |
openstack | Launchpad bug 1665015 in craton "All text errors reported by the Craton REST API should be JSON encoded" [High,New] | 15:32 |
thomasem | And, interestingly, we already use method_decorators for several other decorators? | 15:32 |
thomasem | Anyway, bigger fish, atm. Will look into it a bit later. | 15:34 |
*** Syed__ has joined #craton | 15:37 | |
openstackgerrit | Thomas Maddox proposed openstack/python-cratonclient master: Adds basic Cloud resource CRUD to CLI https://review.openstack.org/437098 | 15:45 |
thomasem | For listing hosts, do we want to make region AND cloud required, or just cloud? | 15:49 |
thomasem | The CLI currently requires region to be specified. | 15:50 |
thomasem | Want to better understand the goal there. | 15:50 |
sigmavirus | thomasem: that's an artifact of old timeys | 15:52 |
sigmavirus | we don't actually need to require region_id any longer | 15:52 |
sigmavirus | It's a bug | 15:52 |
sigmavirus | One that Jim has filed and is on my burner | 15:53 |
sigmavirus | I'm trying to make our integration shell tests better right now first because they drive me up the wall | 15:54 |
thomasem | Ahhhh, okay. That makes more sense. Thank you! | 15:58 |
thomasem | So, I'll just make cloud_id optional. | 15:58 |
thomasem | sigmavirus: thanks | 15:58 |
sigmavirus | thomasem: happy to help | 15:59 |
openstackgerrit | Thomas Maddox proposed openstack/python-cratonclient master: Adds basic Cloud resource CRUD to CLI https://review.openstack.org/437098 | 16:03 |
jimbaker | sounds good about a better replacement for base.http_codes, to remove even more duplicated code | 16:15 |
sulo | so only devices have links ? | 16:18 |
sulo | sigmavirus: ^ | 16:18 |
sigmavirus | sulo: huh? | 16:20 |
jimbaker | should be true of any resource collecton | 16:22 |
jimbaker | sulo, or are you referring to up links? | 16:23 |
sulo | jimbaker: whats an up link ? | 16:23 |
jimbaker | it's a link for the parent | 16:23 |
sulo | sigmavirus: sorry what i meant was in schemas i see links property defined only for somethings | 16:24 |
sulo | jimbaker: oh!? its called up instead of parent ? | 16:24 |
*** jovon has joined #craton | 16:24 | |
sulo | sigmavirus: was trying to see why that was .. jumped on the question too soon | 16:24 |
jimbaker | sulo, there was some discussion on this specific name | 16:25 |
* sigmavirus still hasn't found anything that says "up" is more canonical than "parent" but *shrug* | 16:25 | |
sigmavirus | besides, just because everyone else is naming things poorly, doesn't mean we should | 16:25 |
sulo | oh i must have missed that discussion | 16:25 |
farid | does it make sense to create a ticket in python-cratonclient to allow loading an openstack inventory into Craton ? | 16:26 |
sigmavirus | sulo: it was a very very brief discussion | 16:26 |
jimbaker | http://www.iana.org/assignments/link-relations/link-relations.xhtml | 16:26 |
sigmavirus | jimbaker: IANA does tend to win out | 16:26 |
jimbaker | since there was a reasonable convention already, we decided to follow it | 16:26 |
sulo | so its up down instead parent child ? | 16:26 |
sigmavirus | sulo: seems that way | 16:26 |
sigmavirus | there is no down though | 16:27 |
jimbaker | sulo, well, there's the problem that that doc doesn't define `down` | 16:27 |
sigmavirus | farid: would make sense | 16:27 |
farid | allright | 16:27 |
sulo | ok, thats seem even more odd then ? | 16:27 |
sigmavirus | jimbaker: so that's not a document. It's a registry that points to other documents | 16:27 |
sigmavirus | Each of those names are defined in RFCs or W3C documents | 16:27 |
jimbaker | sigmavirus, ack. but materialized as a doc :) | 16:28 |
sigmavirus | it's a glorified spreadsheet =P | 16:28 |
sulo | sigmavirus: i thought those properties could be extended ? | 16:28 |
sigmavirus | sulo: you can't just add to an IANA registry | 16:28 |
sigmavirus | But yes, the registries are meant to be expandable | 16:28 |
jimbaker | brb | 16:28 |
sigmavirus | https://tools.ietf.org/html/rfc5988#section-4.2 | 16:29 |
sigmavirus | We can define our own so long as we provide a clear definition of semantics | 16:29 |
sulo | oh well | 16:33 |
sulo | so if we are using up for parent, what are we using for child ? | 16:35 |
* sulo goes to read the spec again | 16:35 | |
farid | zz_pwnall1337: I created this one for the environment import stuff https://bugs.launchpad.net/python-cratonclient/+bug/1667376 | 16:40 |
openstack | Launchpad bug 1667376 in Craton's Python Client "Allow loading an Openstack inventory into Craton" [Undecided,New] - Assigned to Tim Pownall (pownalltim) | 16:40 |
sigmavirus | sulo: don't think we actually came to a conclusion with children links | 16:43 |
sulo | sigmavirus: rgr | 16:44 |
openstackgerrit | Thomas Maddox proposed openstack/craton master: Add Cloud resource before Region https://review.openstack.org/431705 | 16:44 |
*** zz_pwnall1337 is now known as pwnall1337 | 16:49 | |
sigmavirus | jimbaker: you're making me want to assign you a work item to write extensive documentation about this for craton's docs | 17:00 |
sigmavirus | *developer docs | 17:00 |
jimbaker | let's kick off our meeting | 17:05 |
jimbaker | #startmeeting craton | 17:05 |
openstack | Meeting started Thu Feb 23 17:05:13 2017 UTC and is due to finish in 60 minutes. The chair is jimbaker. Information about MeetBot at http://wiki.debian.org/MeetBot. | 17:05 |
openstack | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 17:05 |
jimbaker | #chair sigmavirus sulo jimbaker thomasem | 17:05 |
openstack | The meeting name has been set to 'craton' | 17:05 |
jimbaker | #link https://etherpad.openstack.org/p/craton-meetings | 17:05 |
openstack | Current chairs: jimbaker sigmavirus sulo thomasem | 17:05 |
jimbaker | #topic Roll Call | 17:05 |
thomasem | o/ | 17:05 |
sigmavirus | o/ | 17:05 |
jimbaker | o/ | 17:05 |
git-harry | hi | 17:05 |
sigmavirus | Syed__: farid jovon ping | 17:06 |
sulo | o/ | 17:06 |
jovon | o/ | 17:06 |
Syed__ | o/ | 17:06 |
farid | o/ | 17:06 |
jimbaker | thomasem, i assume you will chair today's meeting... | 17:07 |
thomasem | #topic Action Items from Monday's meeting | 17:07 |
thomasem | yep | 17:07 |
thomasem | #link http://eavesdrop.openstack.org/meetings/craton/2017/craton.2017-02-20-15.00.html | 17:08 |
thomasem | ACTION: thomasem to write BP regarding deployment as a starting point for iterating on a suggested deployment model | 17:08 |
thomasem | Carrying forward. Busy with higher priority items atm. | 17:08 |
thomasem | #action thomasem to write BP regarding deployment as a starting point for iterating on a suggested deployment model | 17:08 |
jimbaker | +1 | 17:08 |
thomasem | ACTION: jimbaker to map Dusty's requirements to work or existing features of Craton, especially with respect to short-term deliverable (~2 weeks remaining) | 17:08 |
jimbaker | so this has been in the back of my mind. i think we have been working implicitly against this | 17:09 |
jimbaker | in terms of bugs, but more fomalization needed | 17:09 |
jimbaker | carry forward, please | 17:09 |
jimbaker | (done | 17:09 |
thomasem | #action jimbaker to map Dusty's requirements to work or existing features of Craton, especially with respect to short-term deliverable (~2 weeks remaining) | 17:09 |
thomasem | ACTION: thomasem to review Dusty stories and add notes on concerns or questions | 17:09 |
thomasem | Seems we're going against Björn's use cases more than anything. I asked a few clarification questions, but overall, no discrepancies found from what we're working on overall. | 17:10 |
sigmavirus | thomasem: Bjoern ;) | 17:11 |
thomasem | Will be interested to see what comes out of jimbaker's action item regarding that. | 17:11 |
thomasem | oe = ö does it not? :P | 17:11 |
jimbaker | agreed that bjoern (= björn presumably) | 17:11 |
jimbaker | has the more detailed stories for the time being | 17:11 |
* sigmavirus just knows that's how Bjoern tends to spell his name | 17:11 | |
thomasem | Cool. I will refrain from being fancy, then. | 17:11 |
thomasem | done on that action item from me. | 17:12 |
thomasem | ACTION: sigmavirus to finish up testing on cli | 17:12 |
sigmavirus | That's in progress | 17:12 |
sigmavirus | Also as part of that, I'm throwing together a minimal pluggable formatter system so we can simply our shell integration tests | 17:12 |
sigmavirus | (That way the tests can use the json formatter for most things and verify the output that way, while also using the pretty-table formatters but not relying on those for the bulk of our tests) | 17:13 |
thomasem | Gotcha | 17:13 |
sigmavirus | #action sigmavirus finish up client/cli testing | 17:13 |
sigmavirus | (Carried that forward for you) | 17:13 |
thomasem | Aww thanks | 17:13 |
* sigmavirus is a helper | 17:13 | |
jimbaker | sigmavirus, awesome, that's great stuff | 17:13 |
sigmavirus | or something | 17:13 |
thomasem | Okay, cool. That concludes action items. | 17:13 |
thomasem | #topic Stand Up | 17:13 |
thomasem | #info each team member briefly describes what they are working on this week, and describes blockers (if there are any) | 17:14 |
thomasem | #topic Stand Up :: thomasem | 17:14 |
thomasem | Working on clouds some more, turned into quite a bit of nuances that need to be shored up. Found some issues with cloud_id filtering, so in the process of correcting those and will add tests. | 17:14 |
thomasem | Also working on the CLI changes to support the cloud endpoint and support the cloud_id which will be sprinkled throughout the child resources, as is the going pattern for our relational representation in the API at the moment. | 17:15 |
thomasem | Filed some bugs around that specifically to see if we can't clean that up in future iterations of the data model and API. | 17:15 |
thomasem | #link https://bugs.launchpad.net/craton/+bug/1666699 | 17:15 |
openstack | Launchpad bug 1666699 in craton "able to create unexpected relationships via API" [Undecided,New] | 17:15 |
thomasem | #link https://bugs.launchpad.net/craton/+bug/1666695 | 17:16 |
openstack | Launchpad bug 1666695 in craton "project ID not honored in requests" [Undecided,New] | 17:16 |
thomasem | Other than that, putting my eyes to code reviews as they come in. | 17:16 |
thomasem | Hopefully at the tail of this cloud work and then I'll pick up the next critical thing! | 17:16 |
thomasem | done | 17:16 |
thomasem | #topic Stand Up :: sigmavirus | 17:17 |
sigmavirus | Working on cratonclient tests. Looking at thomasem's cloud review occasionally. Working on a slapdash client formatter system. /fin | 17:18 |
thomasem | #topic Stand Up :: jimbaker | 17:18 |
jimbaker | finalize testing for https://review.openstack.org/#/c/427032/; write alembic script for https://bugs.launchpad.net/craton/+bug/1665066; i might tackle https://bugs.launchpad.net/craton/+bug/1661226, given this should be an important way to look up devices | 17:19 |
openstack | Launchpad bug 1665066 in craton "Alembic script must use named constraints to support future upgrades" [Critical,New] - Assigned to Jim Baker (jimbaker) | 17:19 |
jimbaker | we need to focus on specific imports from openstack and making sure that pwnall1337 is successful (thomasem is point, but this is our most important responsibility, getting this to work as expected for next week!) | 17:19 |
openstack | Launchpad bug 1661226 in craton "Filter by variables lacks resolved variables" [Critical,Confirmed] | 17:19 |
jimbaker | more reviews, especially the cloud support that thomasem has worked on | 17:19 |
jimbaker | done | 17:19 |
thomasem | #topic Stand Up :: git-harry | 17:19 |
git-harry | finishing off /v1/devices today | 17:20 |
git-harry | done | 17:20 |
thomasem | #topic Stand Up :: sulo | 17:20 |
sulo | mostly catching up | 17:21 |
sulo | got a couple of bugs to fix | 17:21 |
sulo | mostly on cross tenant search | 17:21 |
jimbaker | +1 | 17:21 |
sulo | and on cleaning up schema for creates | 17:21 |
sulo | other than that just usual stuff reviews etc | 17:22 |
sulo | done | 17:22 |
thomasem | #topic Stand Up :: jovon | 17:22 |
jimbaker | sulo, are we describing json schemas? | 17:22 |
thomasem | #undo | 17:22 |
openstack | Removing item from minutes: #topic Stand Up :: jovon | 17:22 |
sulo | yes | 17:22 |
sigmavirus | let's hold off on questions until after standup | 17:22 |
jimbaker | ok, cool | 17:22 |
thomasem | #topic Stand Up :: jovon | 17:22 |
jovon | experimenting with RAML and ramlfication to develop an easy-to-use implementation strategy with existing craton docs or a minimal manual translation | 17:23 |
jovon | done | 17:23 |
thomasem | #topic Stand Up :: Syed__ | 17:23 |
Syed__ | As per tuesday meeting, i have been looking into cratonclient, more specifically looking into https://bugs.launchpad.net/python-cratonclient/+bug/1659238 and hoping to get this done https://review.openstack.org/#/c/425463/ . | 17:23 |
openstack | Launchpad bug 1659238 in Craton's Python Client "client is missing user related commands" [Undecided,In progress] - Assigned to Syed Ahsan Shamim Zaidi (ahsanmohsin04) | 17:23 |
Syed__ | done | 17:23 |
thomasem | #topic Stand Up :: farid | 17:23 |
farid | got a couple client tickets in and plan on working today with tim on any aio/inventory load questions, tickets are https://bugs.launchpad.net/python-cratonclient/+bug/1667109 and https://bugs.launchpad.net/python-cratonclient/+bug/1667376 | 17:25 |
openstack | Launchpad bug 1667109 in Craton's Python Client "Allow environment export from client" [Undecided,New] | 17:25 |
farid | done | 17:25 |
openstack | Launchpad bug 1667376 in Craton's Python Client "Allow loading an Openstack inventory into Craton" [Undecided,New] - Assigned to Tim Pownall (pownalltim) | 17:25 |
thomasem | #topic Open Discussion | 17:25 |
thomasem | Nothing on the etherpad in the way of topics, so. | 17:25 |
thomasem | Think we're all just heads down getting it done. | 17:26 |
jimbaker | sulo, any more discussion on cross-project queries? | 17:26 |
sulo | jimbaker: not really, i veryfiy everyting and we can discuss if anything comes up | 17:27 |
jimbaker | thomasem, looks like we can just assume heads down, and maybe a quick meeting otday | 17:27 |
jimbaker | sulo, +1 | 17:27 |
thomasem | Excellent. I did have a quick question that came out of working with pwnall1337 yesterday. | 17:28 |
thomasem | What's the story with UUIDs sans hyphens? | 17:28 |
thomasem | for, like, project_id | 17:28 |
jimbaker | i'm sorry, what's the context here? | 17:28 |
jimbaker | in the database? | 17:28 |
thomasem | Yeah, and in the headers | 17:28 |
thomasem | Is that just an OpenStack thing, or something else? | 17:29 |
jimbaker | so we should be able to support UUID with and without hyphens | 17:29 |
jimbaker | at entry point | 17:29 |
thomasem | Ahhh, it truncates the UUID when you generate one when storing in the DB to the size of a UUID sans hyphens. | 17:29 |
thomasem | Which caused us to chase our tails a bit when using UUID() in MySQL | 17:30 |
jimbaker | and on exit from the api, it would be far better if they are formatted | 17:30 |
thomasem | I think they come back with hyphens just fine. | 17:30 |
thomasem | But, they're forcibly stored according to the length of an improper uuid in the DB. | 17:30 |
jimbaker | so: there's a basic assumption that we are using the uuid type that sqlachemy ext provides us | 17:30 |
thomasem | So, if that's not intended, I can file a bug. | 17:30 |
jimbaker | in the db itself, they are stored as a string without hyphens iirc | 17:31 |
jimbaker | and that's fine | 17:31 |
thomasem | Right, why is that? | 17:31 |
jimbaker | we don't expect people directly using the db :) | 17:31 |
thomasem | To bootstrap one must. :) | 17:31 |
jimbaker | and if they are, they have to play by our rules | 17:31 |
thomasem | Okay, but I'm questioning why that rule exists? | 17:31 |
thomasem | What's the purpose? Why not use proper UUIDs there? | 17:31 |
jimbaker | there are a few ways to stored uuids in the db. we chose the compact string representation | 17:32 |
jimbaker | vs the more compact bytes representation | 17:32 |
jimbaker | this is managed by the model code | 17:32 |
jimbaker | it would be a simple thing to change if we want to do so | 17:32 |
thomasem | So, it's a performance concern? | 17:32 |
jimbaker | hardly not | 17:33 |
thomasem | I don't doubt it's simple to change. I'm really only wondering what the original reasoning was for making that choice. | 17:33 |
jimbaker | but it should be a canonical repr | 17:33 |
jimbaker | so with, or without, we want it the same way | 17:34 |
thomasem | So why not store it the same way and then you never have to worry about expanding/contracting? | 17:34 |
jimbaker | fwiw, when we had all IDs as UUIDs, there may have been more of a perf concern | 17:34 |
thomasem | Haha, yeah. I can see that. | 17:34 |
jimbaker | i think it's just the default for the UUIDType here... | 17:34 |
jimbaker | https://github.com/openstack/craton/blob/master/craton/db/sqlalchemy/models.py#L233 | 17:34 |
thomasem | Ohhhh okay | 17:34 |
jimbaker | i'm pretty sure we can make it something else if we want | 17:35 |
sigmavirus | thomasem: jimbaker I'm not sure that's true. I just like being explicit in certain things I do | 17:35 |
jimbaker | tbh, we haven't looked at this for a while | 17:35 |
thomasem | Sure. That's all I was wondering. If it's just what SQLAlchemy does, that's different. I was under the impression that it was a deliberate choice. | 17:35 |
jimbaker | well it is a deliberate choice to use this library: https://github.com/openstack/craton/blob/master/craton/db/sqlalchemy/models.py#L233 | 17:35 |
jimbaker | and keep things in types, vs strings, once it entered SA | 17:36 |
jimbaker | but i don't think this usage is controversial | 17:36 |
sigmavirus | related https://github.com/kvesteri/sqlalchemy-utils/issues/261 | 17:36 |
sigmavirus | Ah, it does default to binary: https://github.com/kvesteri/sqlalchemy-utils/blob/master/sqlalchemy_utils/types/uuid.py#L31 | 17:36 |
jimbaker | it's more of a question, could we opt for a different db repr | 17:36 |
sigmavirus | I suspect I stole that from another openstack project then | 17:36 |
jimbaker | sigmavirus, yeah, it was binary at some point | 17:37 |
jimbaker | and that was much more objectionable, since it was opaque in mysql | 17:37 |
jimbaker | i believe it may adapt itself from the fact that we chose to do the storage as a string in the alembic script | 17:37 |
thomasem | Gotcha | 17:38 |
sigmavirus | these things are all fuzzy to me | 17:38 |
sigmavirus | we didn't do specs back then | 17:38 |
sigmavirus | Also, project UUIDs seems silly now that we won't be doing a horizon plugin | 17:38 |
* sigmavirus shrugs | 17:38 | |
jimbaker | sigmavirus, yeah, only the code speaks for itself | 17:38 |
thomasem | Lol, it's cool. I didn't mean to spark a bunch about it. I was mostly curious. We can work with it as-is. Something to consider changing later on, if we care. | 17:39 |
jimbaker | well, yeah, lets just keep it the way it is. at least project uuid is unique, in case we ever need to consolidate from multiple projects | 17:39 |
thomasem | Alright. That was all I had! | 17:40 |
jimbaker | that's actually a more interesting question, but fortunately mysql multisource replication can readily handle | 17:40 |
jimbaker | and whatever alt we build | 17:40 |
jimbaker | thomasem, ok, adjourn for now? | 17:40 |
thomasem | Yeppers | 17:41 |
thomasem | #endmeeting | 17:41 |
openstack | Meeting ended Thu Feb 23 17:41:06 2017 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 17:41 |
openstack | Minutes: http://eavesdrop.openstack.org/meetings/craton/2017/craton.2017-02-23-17.05.html | 17:41 |
openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/craton/2017/craton.2017-02-23-17.05.txt | 17:41 |
openstack | Log: http://eavesdrop.openstack.org/meetings/craton/2017/craton.2017-02-23-17.05.log.html | 17:41 |
jimbaker | thanks everyone! | 17:41 |
thomasem | Cheers! | 17:41 |
thomasem | I need food | 17:41 |
jovon | +1 to that | 17:41 |
jovon | :) | 17:41 |
toan | jimbaker: would it be possible to demo tomorrow, what we have so far, as far as what requirements can be checked off? | 17:52 |
toan | farid: ^ ^ | 17:52 |
jimbaker | toan, makes sense | 17:54 |
jimbaker | sulo, up for this? | 17:54 |
sulo | maybe monday ? .. i think there are way too many things in flight right now | 17:55 |
toan | jimbaker: ok. it should be just for the team and dusty... no one else so that there would be no distracting question | 17:55 |
sulo | i think monday we can have the cloud stuff and all the otehr stuff ready | 17:56 |
toan | sulo: ^ ^ | 17:56 |
toan | with data, i hope | 17:56 |
sulo | toan: fake data will still be there ;), tim is still wokring on getting aio data in .. dunno if that will be done by monday | 17:57 |
toan | sulo: would like have real data... so, i'll ping tim | 17:58 |
jimbaker | i believe we can get real data in that time frame | 17:58 |
sulo | toan: roger | 17:58 |
toan | monday would be good for demo, as cloudnull and antonym are joining back to this workstream | 17:58 |
toan | to help finish off the last week of the timebox | 17:58 |
jimbaker | it's supportable with the REST API, and it's available with this patch (which only requires testing to get merged in) https://review.openstack.org/#/c/427032/ | 17:59 |
sulo | jimbaker: yeah was going to ping re that patch | 17:59 |
jimbaker | i would like to finalize the multi cloud in a project support | 17:59 |
sulo | that needs to go in for much of my network patches to go in | 17:59 |
jimbaker | sulo, agreed, it's pretty essential | 18:00 |
jimbaker | i believe i have figured out how the mock testing works for resources and managers; although it seems to me that we could do more of it for the resources that depend on it, not just depend on what's tested with crud | 18:01 |
sulo | i am testing the cloud patch from thomasem | 18:01 |
sulo | :+1 | 18:02 |
jimbaker | but we can revisit | 18:02 |
jimbaker | also hopefully we can get tox -e integration implemented for the clients sooner than later. but definitely not before march 3 | 18:02 |
jimbaker | although i suppose it would be a straightforward reuse of what's already in tox -e functional | 18:03 |
*** david-lyle has joined #craton | 18:11 | |
*** david-lyle has quit IRC | 18:16 | |
*** david-lyle has joined #craton | 18:19 | |
farid | toan: seems like it's all good? :) | 18:23 |
toan | farid: yes! | 18:31 |
sigmavirus | jimbaker: you mean you want to have the client actually run tests against a live craton serve? | 18:33 |
* sigmavirus would call those acceptance/functional tests | 18:33 | |
*** david-lyle has quit IRC | 18:33 | |
*** harlowja has joined #craton | 18:33 | |
*** david-lyle has joined #craton | 18:42 | |
jimbaker | sigmavirus, i'm good with any name that delivers that type of testing | 18:46 |
sigmavirus | jimbaker: because I was going to add integration tests that took advantage of betamax for speed and functional tests that talk to the real sever | 18:46 |
sigmavirus | *server | 18:46 |
sigmavirus | (openstack is increasingly using betamax but they also have stable-er APIs) | 18:47 |
jimbaker | sigmavirus, :) | 18:51 |
jimbaker | yeah, that approach works for me | 18:51 |
thomasem | Uhhhh... anyone else having LP issues? I'm trying to create a bug and it keeps timing out. :( | 19:18 |
jimbaker | thomasem, i'm seeing the same timeout error | 19:19 |
thomasem | Okay, good. It's not just me. | 19:20 |
Syed__ | rev | 19:27 |
*** david-lyle has quit IRC | 19:35 | |
thomasem | Would anyone have any beef with me extracting all of these create_* methods to the base test class for Craton functional tests? | 19:38 |
thomasem | Exercising the cloud_id filter across the API is going to be a bunch of duplicated code in there otherwise. | 19:39 |
thomasem | And it's already a bunch of duplicated code. | 19:39 |
sigmavirus | thomasem: go for it | 19:39 |
thomasem | Could dry it out even more, but this is a start. | 19:39 |
thomasem | Cool, will do. | 19:39 |
openstackgerrit | git-harry proposed openstack/craton master: Add GET /v1/devices https://review.openstack.org/437585 | 19:48 |
sigmavirus | thomasem: don't use up all your towels | 19:51 |
thomasem | Lol, oh the rush of jokes that come to mind. | 19:51 |
thomasem | Must. Resist. | 19:52 |
thomasem | Mmm, botched refactorings breaking all the things. | 19:53 |
*** david-lyle has joined #craton | 20:05 | |
openstackgerrit | sulochan-acharya proposed openstack/craton master: Ensures no extra property is allowed on creates https://review.openstack.org/437606 | 20:24 |
openstackgerrit | sulochan-acharya proposed openstack/craton master: Ensures no extra property is allowed on creates https://review.openstack.org/437606 | 20:39 |
*** pwnall1337 is now known as zz_pwnall1337 | 20:41 | |
openstackgerrit | Ian Cordasco proposed openstack/python-cratonclient master: Reorganize shell based integration tests https://review.openstack.org/437658 | 20:57 |
openstackgerrit | Ian Cordasco proposed openstack/python-cratonclient master: Add --format to the client shell https://review.openstack.org/437659 | 20:57 |
sigmavirus | Later y'all | 20:58 |
*** david-lyle has quit IRC | 20:59 | |
thomasem | Cheers, sigmavirus! | 21:01 |
farid | later sigmavirus | 21:03 |
jimbaker | lots of great changes proposed, some of which are conflicting | 21:26 |
thomasem | We need to refactor these functional tests to be more isolated from each other. | 21:37 |
thomasem | The fact that data from one test impacts another is a bad sign. | 21:38 |
thomasem | Either via cleanups or unique names | 21:38 |
sulo | thomasem: what ? that shouldnt be everythig on db side gets nuked prior to each test | 21:38 |
sulo | what are you seeing ? | 21:39 |
thomasem | conflicts when I try to run self.create_cloud() twice. | 21:39 |
thomasem | without specifying a different name. | 21:39 |
sulo | on the same test ? | 21:39 |
thomasem | In another test | 21:39 |
sulo | yeah thats bad .. it shouldnt be like that | 21:40 |
thomasem | Hmmm... wait, nevermind. You're right. It's because self.create_cloud runs in setUp, too. | 21:40 |
thomasem | sulo: yeah, nevermind. I think you're correct. | 21:40 |
thomasem | red herring | 21:40 |
sulo | thomasem: cool | 21:41 |
sulo | yeah but in general i think that is taken care of | 21:41 |
sulo | every table is turncated prior to each test | 21:41 |
thomasem | Okay, good. | 21:41 |
thomasem | alright, let's see if this fixes it. | 21:43 |
thomasem | Getting wires crossed, lol. | 21:43 |
thomasem | Almost done with this refactoring + cell_id filter tests | 21:43 |
thomasem | s/cell_id/cloud_id/ | 21:44 |
jimbaker | cool | 21:46 |
thomasem | Got two extremes this week - one-liners and thousand liners. :P | 21:47 |
openstackgerrit | Thomas Maddox proposed openstack/craton master: Add Cloud resource before Region https://review.openstack.org/431705 | 21:51 |
openstackgerrit | Thomas Maddox proposed openstack/craton master: Add Cloud resource before Region https://review.openstack.org/431705 | 21:53 |
jimbaker | somehow i missed this one detail when git-harry proposed the spec (https://github.com/openstack/craton/blob/master/doc/source/specs/approved/list-devices.rst#rest-api-impact), which he has faithfully implemented | 21:53 |
jimbaker | that devices has two children (currently), hosts and network-devices | 21:53 |
thomasem | And what's the implication of your not having caught it? | 21:54 |
jimbaker | i suppose we can do it this way, but for some reason i thought we would have hosts and network-devices all at the same top level | 21:54 |
jimbaker | as links | 21:54 |
openstackgerrit | Thomas Maddox proposed openstack/python-cratonclient master: Adds basic Cloud resource CRUD to CLI https://review.openstack.org/437098 | 21:54 |
jimbaker | thomasem, well, i would prefer to have read it a bit more closely... the implication is, does this match sigmavirus' expectation or not? | 21:55 |
thomasem | Oh, where instead of {"devices": {"hosts": [...], "network-devices": [...]}} you were thinking {"hosts": [...], "network-devices": [...]}? | 21:56 |
thomasem | jimbaker: ^^ | 21:57 |
jimbaker | yes. i haven't looked at the impl details, but i cannot imagine it would be difficult to change the output. just a question of whether from a "follow the nose" perspective, the first is as easy as the second | 21:57 |
thomasem | Gotcha | 21:57 |
*** david-lyle has joined #craton | 21:57 | |
jimbaker | thomasem, in general i prefer flatter structures. so this seems to be unnecessarily nested | 21:58 |
thomasem | Yeah | 21:58 |
jimbaker | anyway, it's a quick correction, but we can wait until git-harry and sigmavirus are back online tomorrow | 21:59 |
jimbaker | (assuming correction is needed... at the very least, clarification!) | 21:59 |
thomasem | Indeed! | 22:00 |
farid | can y'all do a chat tomorrow at the same time as today? think it might be helpful to touch base before the weekend | 22:05 |
thomasem | farid: I can. | 22:07 |
thomasem | Actually, let me double-check before committing. | 22:07 |
thomasem | farid: yes, I can | 22:07 |
thomasem | Whew gerrit's sluggish this afternoon. | 22:10 |
farid | thanks thomasem | 22:11 |
thomasem | Sure thing! | 22:12 |
jimbaker | farid, sounds good | 22:18 |
farid | o/ | 22:18 |
*** VW has quit IRC | 22:23 | |
*** VW_ has joined #craton | 22:23 | |
thomasem | Alright. Been fun, folks! Time for me to get some grub. Have a lovely evening and catch ya in the morning! | 22:29 |
farid | have a good one thomasem , laters ! | 22:35 |
*** david-lyle_ has joined #craton | 22:37 | |
*** david-lyle has quit IRC | 22:37 | |
*** david-lyle_ has quit IRC | 22:52 | |
farid | gonna take off as well, laters all! | 23:20 |
*** david-lyle has joined #craton | 23:37 | |
*** david-lyle has quit IRC | 23:57 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!