19:05:03 <devananda> #startmeeting ironic
19:05:04 <openstack> Meeting started Mon Jul 15 19:05:03 2013 UTC.  The chair is devananda. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:05:05 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:05:08 <openstack> The meeting name has been set to 'ironic'
19:05:28 <devananda> so, hi! I've been gone a while
19:05:46 <devananda> thanks to NobodyCam for running things :)
19:06:00 <devananda> agenda:
19:06:01 <devananda> #link https://wiki.openstack.org/wiki/Meetings/Ironic
19:06:23 <devananda> i'm going to go slightly out of order, i think
19:06:38 <devananda> #topic pxe driver
19:06:57 <devananda> GheRivero: how's it going? the code's looking great!
19:07:18 <GheRivero> waiting for reviews both in pxe and glanceclient
19:07:33 <GheRivero> somw ideas/features are be done meanwhile
19:07:58 <anteaya> o/
19:08:17 <devananda> have you been able to do any testing of it? if not, is there a clear set of things you need for the code to get there?
19:09:03 <GheRivero> i have tested glanceclient service. Flavio is looking at it, so hopefully i-ll have some feedback in the following days
19:09:38 <GheRivero> and regarding pxe, i have plans to start looking at devstack-baremetal to test things tomorrow
19:09:51 <devananda> sounds good :)
19:10:11 <GheRivero> don't know if there is some devstack ironic work already done
19:10:22 <devananda> none. but there was baremetal integration a while back
19:10:37 <devananda> Nobodycam has work on a diskimage-builder element for ironic
19:10:42 <devananda> which, i think, is basically done
19:10:57 <devananda> so that might be a shorter path for you to get services stood up
19:11:10 <GheRivero> yeah, sure... then i will start with that
19:11:43 <devananda> OTOH, I find it difficult to do rapid development of code in dib-based images.... so, ofc, just do what works for you :)
19:12:11 <devananda> any questions on the PXE driver before we move on?
19:12:12 <GheRivero> :)
19:12:48 <devananda> #topic keystone auth
19:13:03 <romcheg> We have #link https://review.openstack.org/#/c/37102/ this review
19:13:23 <romcheg> Some tests still fail but I'm working on that.
19:13:53 <devananda> and we were just talking an hour ago about how we might do RBAC
19:14:28 <romcheg> RBAC is a nice idea
19:14:45 <devananda> i think it's good progress, and i'm happy to land admin auth first and refactor it to RBAC after, if that seems easier to you
19:15:04 <jog0> devananda: it may be worth talking to some keystone devs about this
19:15:25 <jog0> I know they have a new V3 API that changes things, and we *may* want to try it out
19:15:31 <jog0> partailly to help them
19:15:38 <romcheg> jog0: we use keystoneclient
19:15:54 <jog0> romcheg: does that have v3 API support already?
19:16:06 <romcheg> As I understand we do not depend on the version of API.
19:16:16 <romcheg> It just provides a middleware for authentication
19:16:50 <devananda> jog0: is there a difference in capabilities between keystone v2 and v3?
19:17:07 <jog0> devananda: AFAIK yes -- don't really know the details though
19:17:31 <devananda> hm, ok. who'd be good to ping?
19:17:39 <romcheg> I know some folks who said really nasty things about v3
19:17:46 <anteaya> new tokens in v2 are pki
19:17:54 <anteaya> sorry pki in v3
19:18:00 <anteaya> used to be uuid
19:18:08 <devananda> i've only very loosely been aware of nova v3, but haven't followed the work
19:18:25 <devananda> aiui, deployments are going to support both v2 and v3 for a while
19:19:31 <jog0> right, just think it may be good to sync up with keystone -- not saying we should do anything different just have a better understanding of it
19:20:06 <devananda> nothing wrong with that :)
19:20:12 <devananda> i'll see what i can learn about it
19:20:30 <anteaya> in terms of whom dolphm, bkundson, henrynash
19:20:43 <anteaya> that is who I think of when I think of keystone
19:20:59 <devananda> #action devananda to chat with dolphm, bkundson, or henrynash about keystone v3 in ironic
19:21:02 <jog0> ayoung as well
19:21:15 <anteaya> yes, ayoung
19:21:28 <devananda> #action devananda to chat with ... or ayoung
19:21:45 <devananda> thanks for the pointers
19:21:57 <devananda> moving on to the API ...
19:22:12 <devananda> #topic All the API
19:22:32 <devananda> seems to be the focus of several of us lately :)
19:23:09 <devananda> lucasagomes and jimjiang have patches up for API additions
19:23:19 <devananda> and I have a patch (and a few deps) up for RPC
19:23:26 <lucasagomes> any news bout the patch vs put ?
19:23:32 <NobodyCam> sorry was late.. will read the log
19:23:43 <devananda> i chatted with martyn last week, i think, about it
19:24:02 <devananda> and IIRC he agreed that PATCH was the right thing for changing some (but not all) properties of an object
19:24:12 <devananda> whereas PUT essentially replaces the object
19:24:24 <devananda> it preserves the uuid, but requires all the other fields to be complete
19:24:39 <ayoung> What is ironic?
19:24:55 <devananda> I think we will want to implement both PUT and PATCH for most resources and sub resources
19:24:58 <anteaya> hey ayoung it is the offshoot of nova baremetal driver
19:25:05 <devananda> ayoung: bare metal provisioning service
19:25:06 <anteaya> it is in incubation now
19:25:24 <ayoung> Oh, I thought we were talking about an Ubuntu distribution
19:25:43 <anteaya> ah okay, good to get that cleared up
19:26:32 <devananda> lucasagomes: eg, if i PUT /v1/nodes/abcd {'properties': { ... } }, it would replace the properties
19:26:33 <anteaya> we have a channel too, #openstack-ironic
19:27:03 <lucasagomes> right so for sub resources we would use PUT
19:27:07 <devananda> lucasagomes: but if I PATCH /v1/nodes/abcd {'properties': {'foo': 'bar'} } it would only add (or replace) that specific item
19:27:20 <lucasagomes> devananda, gotcha
19:27:51 <lucasagomes> so both should be supported for both (resources and sub-resources)
19:28:14 <devananda> i think so? unless someone has a reason otherwise?
19:28:56 <lucasagomes> I don't have any strong opnion about it, I'm deferring to the others
19:29:35 <devananda> ack
19:30:15 <lucasagomes> ok, another thing about the api: internally translated names
19:30:27 <lucasagomes> I think we agreed to only translate the id -> uuid
19:31:02 <lucasagomes> because openstack uses uuid across all the other projects
19:31:02 <devananda> right
19:31:35 <lucasagomes> but other fields like extra->metadata we won't translate anymore and just expose it as extra
19:31:43 <lucasagomes> everybody agree with that?
19:32:48 <romcheg> +1
19:32:53 <devananda> fine with me
19:32:56 <lucasagomes> cooleo
19:33:01 <anteaya> seems to be a reasonable approach thus far
19:33:19 <GheRivero> +1
19:34:00 <devananda> also, particularly on the API front, i feel like my absence has been slowing ya'll down
19:34:50 <devananda> i would like to merge all the current api work today, then hammer out any direction/scope/RPC etc stuff with folks this week
19:35:11 <devananda> I'll be at OSCON next week, which means less time on IRC
19:35:55 <devananda> and i think getting the API at least functional very soon is a priority
19:35:55 <anteaya> let pasta at OSCON probably, eh?
19:35:58 <lucasagomes> that would be good to merge some of the patches
19:36:02 <anteaya> s/let/less
19:36:15 <devananda> anteaya: hah. it's portland. there'll be plenty i can eat ;)
19:36:24 <anteaya> :D
19:36:51 <devananda> anything else on the api, before we move on?
19:37:21 <devananda> #topic object trees
19:37:38 <devananda> martyn and i talked about this last week, and i think we got it conceptually sorted
19:37:45 <devananda> though i dont think he put a patch up yet
19:37:59 <romcheg> I didn't see any
19:38:09 <devananda> the gist of the question is: the API needs to expose related resource UUIDs
19:38:24 <devananda> GET /node/1234 needs to return the UUIDs of its chassis and all its ports
19:38:35 <devananda> but those aren't part of the RPC-style object
19:38:36 <devananda> so
19:38:51 <devananda> we can do a trivial query in the API layer
19:39:23 <devananda> dbapi.get_ports_by_node() and such
19:39:40 <devananda> and then we don't need to worry about nested RPC objects at all :)
19:40:25 <lucasagomes> sounds reasonable
19:40:40 <romcheg> This will cause loading a lot of data a user might not need
19:40:45 <devananda> probably a simple patch could implement taht for all three objects
19:40:52 <lucasagomes> would it also be possible to access some of the resources like : GET /node/1234/ports ?
19:42:05 <devananda> romcheg: ah! sorry, i meant get_port_list() and get_node_list() and such -- dbapi methods that only return a list of UUIDs
19:42:23 <devananda> romcheg: we'll need to add an optional filter to the get_*_list() methods
19:42:32 <devananda> lucasagomes: yes, that is desirable as well
19:42:49 <devananda> lucasagomes: same for things like GET /node/1234/properties
19:43:04 <devananda> lucasagomes: any sub-resource should be queriable directly.
19:43:18 <lucasagomes> right
19:43:22 <devananda> s/any/the important/
19:44:19 <devananda> lucasagomes: is this ^ API stuff soemthing you're comfortable running with?
19:45:26 <lucasagomes> these are things I'm learning while doing :)
19:45:55 <devananda> that's fine :)
19:46:54 <devananda> you seem to have a good handle on it
19:47:51 <devananda> moving on...
19:47:53 <lucasagomes> ty
19:48:01 <devananda> #topic diskimage-builder element
19:48:16 <devananda> NobodyCam seems to be afk
19:48:28 <devananda> so I'll chime in with what I know
19:48:44 <devananda> it exists, it builds, and apparently can be launched by heat!
19:48:59 <devananda> also, running it outside of heat isn't quite as great, but can be done too
19:49:41 <devananda> however, I run into a rabbit queue problem when ever I try to use the ironic-api and ironic-conductor services inside said dib-built image...
19:49:47 <devananda> working with NobodyCam to track that down
19:50:13 <devananda> we have 10 minutes left, so ...
19:50:16 <devananda> #topic open discussion
19:50:18 <lucasagomes> thats the problem of the api talking to the wrong topic?
19:50:32 <devananda> lucasagomes: i think so. or something
19:50:54 <devananda> lucasagomes: i don't see any msgs in rabbit, even though the api service sent one, and set up a receiver queue for the reply
19:50:56 <lucasagomes> I remember you mentioned that, I didn't have a chance to look at it, will give the element a spin tomorrow
19:51:19 <lucasagomes> hmm
19:51:55 <devananda> when i run both services locally (on laptop, outside of VM) they work
19:52:01 <devananda> by which i mean, they talk to eachother
19:52:04 <GheRivero> Regarding file injection... http://lists.openstack.org/pipermail/openstack-dev/2013-July/011769.html
19:52:30 <GheRivero> tldr: avoid it while possible and move to cloud-init and drive-config
19:52:58 <devananda> GheRivero: yes! thanks for pointing that out. huge ++ from me on avoiding file injection
19:53:24 <jbjohnso> though it warrants some discussion on the dance to securely proceed without a drive
19:53:28 <lucasagomes> +1 to avoid that too, we should not touch the user fs
19:54:11 <jbjohnso> which could be done if something is hooking some secure point to point path between the instance and some trusted peer
19:54:37 <jbjohnso> e.g. bridge filtered protocol to switch (falls apart in some potential net configs) or serial channel
19:54:51 <devananda> jbjohnso: initially, let's assume a trusted tenant (so we dont need secured firmware) and let's assume the network is otherwise secured (eg, via SDN and separate provision/tenant nets)
19:55:07 <devananda> those are both constraints placed on the nova-baremetal driver today
19:55:36 <jbjohnso> devananda, well, as long as you concentrate all the security sketchiness into one place...
19:56:07 <jbjohnso> devananda, e.g. if you support https for almost everything and have a dubiously secure 'get client certificate' dance
19:56:39 <jbjohnso> devananda, then you could focus on adjusting the security of the client certificate without perturbing other stuff
19:57:34 <devananda> jbjohnso: i'm saying, today, ironic is not providing security at the hardware or network layer. it's sole (present) job is: put this image on that machine and turn it on.
19:57:59 <devananda> jbjohnso: we need to be /able/ to handle secure boot, yes. but we need to boot something first ;)
19:58:36 <devananda> jbjohnso: and opening up the user's machine image and injecting files into it is unrelated to secure boot
19:58:53 <devananda> if the boot pathway is not secure in the first place, file injection is no more so.
19:59:29 <jbjohnso> well, times up
19:59:31 <devananda> we're just about out of time :)
19:59:35 <devananda> thanks everyone!
19:59:45 <romcheg> thanks
19:59:51 <devananda> #endmeeting