Re: [openstack-dev] [ironic][nova][horizon] Serial console support for ironic instances
Jim, thank you so much for having discussed with johnthetubaguy and added this topic to the agenda. I also will attend to Nova IRC meeting. Best Regards, Yuiko Takada Mori 2016-05-25 20:27 GMT+09:00 Jim Rollenhagen : > On Wed, May 25, 2016 at 01:58:18PM +0900, Yuiko Takada wrote: > > Hi! > > > > Hironori, Lucas, thank you for bringing this topic up! > > > > Yes, as Lucas says, our latest spec is > > https://review.openstack.org/#/c/319505 > > > > I and Tien, Hironori, Akira discussed and merged our idea. > > > > And new Nova spec is here: > > https://review.openstack.org/#/c/319507 > > > > As you guys know, Nova non-priority spec approval freeze is 5/30-6/3, > > so that I guess Ironic spec need to be approved until it. > > Just a note here, I talked with johnthetubaguy this morning, and we > think the Nova blueprint doesn't need a spec. I updated the whiteboard > on the BP with some details, added it to the agenda > for the next Nova meeting, and will be there to discuss it. > > // jim > > > > > > > Best Regards, > > Yuiko Takada Mori > > > > 2016-05-25 1:15 GMT+09:00 Lucas Alvares Gomes : > > > > > Hi, > > > > > > > I'm working with Tien who is a submitter of one[1] of console specs. > > > > I joined the console session in Austin. > > > > > > > > In the session, we got the following consensus. > > > > - focus on serial console in Newton > > > > - use nova-serial proxy as is > > > > > > > > We also got some requirements[2] for this feature in the session. > > > > We have started cooperating with Akira and Yuiko who submitted > another > > > similar spec[3]. > > > > We're going to unite our specs and add solutions for the requirements > > > ASAP. > > > > > > > > > > Great stuff! So do we have an update on this? > > > > > > I see [3] is now abandoned and a new spec was proposed recently [4]. > > > Is [4] the result of the union of both specs? > > > > > > > [1] ironic-ipmiproxy: https://review.openstack.org/#/c/296869/ > > > > [2] https://etherpad.openstack.org/p/ironic-newton-summit-console > > > > [3] ironic-console-server: https://review.openstack.org/#/c/306755/ > > > > > > [4] https://review.openstack.org/#/c/319505 > > > > > > Cheers, > > > Lucas > > > > > > > __ > > > OpenStack Development Mailing List (not for usage questions) > > > Unsubscribe: > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > > > __ > > OpenStack Development Mailing List (not for usage questions) > > Unsubscribe: > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [ironic][nova][horizon] Serial console support for ironic instances
Hi! Hironori, Lucas, thank you for bringing this topic up! Yes, as Lucas says, our latest spec is https://review.openstack.org/#/c/319505 I and Tien, Hironori, Akira discussed and merged our idea. And new Nova spec is here: https://review.openstack.org/#/c/319507 As you guys know, Nova non-priority spec approval freeze is 5/30-6/3, so that I guess Ironic spec need to be approved until it. Best Regards, Yuiko Takada Mori 2016-05-25 1:15 GMT+09:00 Lucas Alvares Gomes : > Hi, > > > I'm working with Tien who is a submitter of one[1] of console specs. > > I joined the console session in Austin. > > > > In the session, we got the following consensus. > > - focus on serial console in Newton > > - use nova-serial proxy as is > > > > We also got some requirements[2] for this feature in the session. > > We have started cooperating with Akira and Yuiko who submitted another > similar spec[3]. > > We're going to unite our specs and add solutions for the requirements > ASAP. > > > > Great stuff! So do we have an update on this? > > I see [3] is now abandoned and a new spec was proposed recently [4]. > Is [4] the result of the union of both specs? > > > [1] ironic-ipmiproxy: https://review.openstack.org/#/c/296869/ > > [2] https://etherpad.openstack.org/p/ironic-newton-summit-console > > [3] ironic-console-server: https://review.openstack.org/#/c/306755/ > > [4] https://review.openstack.org/#/c/319505 > > Cheers, > Lucas > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [ironic] Summit recap
Hi, Jim, thank you for recap and blog! > # Newton priorities > > [Etherpad]( https://etherpad.openstack.org/p/ironic-newton-summit-priorities) > > We discussed our priorities for the Newton cycle here. > > Of note, we decided that we need to get cold upgrade testing (i.e. > grenade) running ASAP. We have lots of large changes lined up that feel > like they could easily break upgrades, and want to be able to test them. > Much of the team is jumping in to help get this going. > > The priorities for the cycle have been published > [here]( http://specs.openstack.org/openstack/ironic-specs/priorities/newton-priorities.html ). I'd like to discuss about priority. I don't think that we should not implement items not in priority list. But, we need to concentrate on high-priority items which need to be completed in this cycle. Especially, core developers are. Because they have Workflow+1 privilege :) I think there are 2 concerns. one is, we need to set scope in the cycle. For example, we have implemented Neutron integration from L cycle, and we want to complete it in this cycle. There are many things which we want, and to complete everything takes very long time. So that, we need to set priority in Neutron integration also, and we need to give up to implement some items and implement them in the next cycle. Another is, we need to be strict about priority a little bit. Recently, I saw the presentation "How Open Source Projects Survive Poisonous People (And You Can Too)". https://www.youtube.com/watch?v=Q52kFL8zVoM In this presentation, subversion developers are talking about how to manage OSS community. They have a TODO list, and when a new proposal comes, if it is not in the TODO list, it will be denied. Do we need to do the same thing? Of course, NO. But, now is the time we need to concern about it... Thank you for reading this long email. What should we do to manage the project efficiently? Everyone is welcome. Best Regards, Yuiko Takada Mori 2016-05-11 23:16 GMT+09:00 Jim Rollenhagen : > Others made good points for posting this on the ML, so here it is in > full. Sorry for the markdown formatting, I just copied this from the > blog post. > > // jim > > Another cycle, another summit. The ironic project had ten design summit > sessions to get together and chat about some of our current and future > work. We also led a cross-project session on bare metal networking, had > a joint session with nova, and a contributor's meetup for the first half > of Friday. The following is a summary of those sessions. > > # Cross-project: the future of bare-metal networking > > [Etherpad](https://etherpad.openstack.org/p/newton-baremetal-networking) > > This session was meant to have the Nova, Ironic, and Neutron folks get > together and figure out some of the details of the [work we're > doing](https://review.openstack.org/#/c/277853/) to decouple the > physical network infrastructure from the logical networking that users > interact with. Unfortunately, we spent most of the time explaining the > problem and the goals, and not much time actually figuring out how > things should work. We were able to decide that the trunk port work in > neutron should mostly work for us. > > There was plenty of hallway chats about this throughout the week, and > from those I think we have a good idea of what needs to be done. The > spec linked above will be updated soon to clarify where we are at here. > > # Nova-compatible serial and graphical consoles > > [Etherpad](https://etherpad.openstack.org/p/ironic-newton-summit-console) > > This session began with a number of proposals to implement serial and > graphical consoles that would work with Nova, and a goal to narrow them > down so folks can move forward with the code. > > The first thing we decided is that in the short term, we want to focus > on the serial console. It's supported by almost all hardware and most > cases where someone needs a console are covered by a simple serial > console. We do want to do graphical consoles eventually, but would like > to take one thing at a time. > > We then spent some time dissecting our requirements (and preferences) > for what we want an implementation to do, which are listed toward the > bottom of the etherpad. > > We narrowed the serial console work down to two implementations: > > * [ironic-console-server](https://review.openstack.org/#/c/306755/). > The tl;dr here is that the conductor will shell out to a command that > creates a listening port, and forks a process that connects to the > console, and pipes data between the two. This command is called once > per console session. The upside with this approach is that operators > don't need to do much when the change is deployed. > >
Re: [openstack-dev] [ironic][nova][horizon] Serial console support for ironic instances
Hi, I also want to discuss about it at summit session. 2016-04-13 0:41 GMT+09:00 Ruby Loo : > Yes, I think it would be good to have a summit session on that. However, > before the session, it would really be helpful if the folks with proposals > got together and/or reviewed each other's proposals, and summarized their > findings. > I've summarized all of related proposals. (1)Add driver using Socat https://review.openstack.org/#/c/293827/ * Pros: - There is no influence to other components - Don't need to change any other Ironic drivers(like IPMIShellinaboxConsole) - Don't need to bump API microversion/RPC * Cons: - Don't output log file (2)Add driver starting ironic-console-server https://review.openstack.org/#/c/302291/ (There is no spec, yet) * Pros: - There is no influence to other components - Output log file - Don't need to change any other Ironic drivers(like IPMIShellinaboxConsole) - No adding any Ironic services required, only add tools * Cons: - Need to bump API microversion/RPC (3)Add a custom HTTP proxy to Nova https://review.openstack.org/#/c/300582/ * Pros: - Don't need any change to Ironic API * Cons: - Need Nova API changes(bump microversion) - Need Horizon changes - Don't output log file (4)Add Ironic-ipmiproxy server https://review.openstack.org/#/c/296869/ * Pros: - There is no influence to other components - Output log file - IPMIShellinaboxConsole will be also available via Horizon * Cons: - Need IPMIShellinaboxConsole changes? - Need to bump API microversion/RPC If there is any mistake, please give me comment. Best Regards, Yuiko Takada 2016-04-13 0:41 GMT+09:00 Ruby Loo : > Yes, I think it would be good to have a summit session on that. However, > before the session, it would really be helpful if the folks with proposals > got together and/or reviewed each other's proposals, and summarized their > findings. You may find after reviewing the proposals, that eg only 2 are > really different. Or they several have merit because they are addressing > slightly different issues. That would make it easier to > present/discuss/decide at the session. > > --ruby > > > On 12 April 2016 at 09:17, Jim Rollenhagen wrote: > >> On Tue, Apr 12, 2016 at 02:02:44AM +0800, Zhenguo Niu wrote: >> > Maybe we can continue the discussion here, as there's no enough time in >> the >> > irc meeting :) >> >> Someone mentioned this would make a good summit session, as there's a >> few competing proposals that are all good options. I do welcome >> discussion here until then, but I'm going to put it on the schedule. :) >> >> // jim >> >> > >> > On Fri, Apr 8, 2016 at 1:06 AM, Zhenguo Niu >> wrote: >> > >> > > >> > > Ironic is currently using shellinabox to provide a serial console, but >> > > it's not compatible >> > > with nova, so I would like to propose a new console type and a custom >> HTTP >> > > proxy [1] >> > > which validate token and connect to ironic console from nova. >> > > >> > > On Horizon side, we should add support for the new console type [2] as >> > > well, here are some screenshots from my local environment. >> > > >> > > >> > > >> > > >> > > >> > > Additionally, shellinabox console ports management should be improved >> in >> > > ironic, instead of manually specified, we should introduce dynamically >> > > allocation/deallocation [3] mechanism. >> > > >> > > Functionality is being implemented in Nova, Horizon and Ironic: >> > > https://review.openstack.org/#/q/topic:bp/shellinabox-http-proxy >> > > https://review.openstack.org/#/q/topic:bp/ironic-shellinabox-console >> > > https://review.openstack.org/#/q/status:open+topic:bug/1526371 >> > > >> > > >> > > PS: to achieve this goal, we can also add a new console driver in >> ironic >> > > [4], but I think it doesn't conflict with this, as shellinabox is >> capable >> > > to integrate with nova, and we should support all console drivers. >> > > >> > > >> > > [1] >> https://blueprints.launchpad.net/nova/+spec/shellinabox-http-proxy >> > > [2] >> > > >> https://blueprints.launchpad.net/horizon/+spec/ironic-shellinabox-console >> > > [3] https://bugs.launchpad.net/ironic/+bug/1526371 >> > > [4] https://bugs.launchpad.net/ironic/+bug/1553083 >> > > >> > > -- >> > > Be
Re: [openstack-dev] [ironic] [inspector] Auto discovery extension for Ironic Inspector
Hi, Using fake driver means we need a manual step to set it to something > non-fake :) and the current introspection process already has 1 manual step > (enrolling nodes), so I'd like autodiscovery to require 0 of them (at least > for the majority of users). Exactly. I recognize that our purpose of auto-discovery is eradicating manual steps. I prefer option 2, but as Sam said, it's not suitable for mixed driver environment. Then, is it impossible that detecting(judging?) driver from node info? For example, if Vendor is XXX and Product Name is YYY, then driver is ZZZ. What do you think? Best Regards, Yuiko Takada 2015-11-18 22:27 GMT+09:00 Dmitry Tantsur : > I have to admin I forgot about this thread. Please find comments inline. > > On 11/06/2015 05:25 PM, Bruno Cornec wrote: > >> Hello, >> >> Pavlo Shchelokovskyy said on Tue, Nov 03, 2015 at 09:41:51PM +: >> >>> For auto-setting driver options on enrollment, I would vote for option 2 >>> with default being fake driver + optional CMDB integration. This would >>> ease >>> managing a homogeneous pool of BMs, but still (using fake driver or data >>> from CMDB) work reasonably well in heterogeneous case. >>> >> > Using fake driver means we need a manual step to set it to something > non-fake :) and the current introspection process already has 1 manual step > (enrolling nodes), so I'd like autodiscovery to require 0 of them (at least > for the majority of users). > > >>> As for setting a random password, CMDB integration is crucial IMO. Large >>> deployments usually have some sort of it already, and it must serve as a >>> single source of truth for the deployment. So if inspector is changing >>> the >>> ipmi password, it should not only notify/update Ironic's knowledge on >>> that >>> node, but also notify/update the CMDB on that change - at least there >>> must >>> be a possibility (a ready-to-use plug point) to do that before we roll >>> out >>> such feature. >>> >> > Well, if we have a CMDB, we probably don't need to set credentials. Or at > least we should rely on the CMDB as a primary source. This "setting random > password" thing is more about people without CMDB (aka using ironic as a > CMDB ;). I'm not sure it's a compelling enough use case. > > Anyway, it could be interesting to talk about some generic OpenStack-CMDB > interface, which might something proposed below. > > >> wrt interaction with CMDB, we have investigating around some ideas tha >> we have gathered at https://github.com/uggla/alexandria/wiki >> > > Oh, that's interesting. I see some potential overlap with ironic and > ironic-inspector. Would be cool to chat on it the next summit. > > >> Some code has been written to try to model some of these aspects, but >> having more contributors and patches to enhance that integration would >> be great ! Similarly available at https://github.com/uggla/alexandria >> >> We had planned to talk about these ideas at the previous OpenStack >> summit but didn't get enough votes it seems. So now aiming at preenting >> to the next one ;-) >> > > +100, would love to hear. > > >> HTH, >> Bruno. >> > > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [ironic][tempest]Tempest test plugin and microversions
Hi Ironic folks, As we discussed in Design Summit, we will move forward with tempest test tasks. I've posted a patch for tempest test plugin interface [1] (Now it fails because of flake8-ignore-difference, anyway). Then, I'd like to discuss about our tests migration procedure. As you know, we are also working for Tempest microversions, so our tests in Tempest need to be fixed for working with microversions. Its spec has been approved and now microversion testing frame work has been posted [2]. IMO, tests in Tempest should be fixed before moving into Ironic tree, but maybe [2] will take long time to be merged. What do you think? [1] https://review.openstack.org/#/c/246161/ [2] https://review.openstack.org/#/c/242346/ Best Regards, Yuiko Takada __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ironic] [OSC] Quick poll: OpenStackClient command for provision action
2015/11/10 21:19、Sam Betts (sambetts) のメッセージ: > So you would end up with a set of commands that look like this: > > Openstack baremetal [node/driver/chassis] list > Openstack baremetal port list [―node uuid] <― replicate node-port-list > > Openstack baremetal [node/port/driver] show UUID > Openstack baremetal chassis show [―nodes] UUID <― replicate > chassis-node-list > > Openstack baremetal [node/chassis/port] create > Openstack baremetal [node/chassis/port] update UUID > Openstack baremetal [node/chassis/port] delete UUID > > Openstack baremetal [node/chassis] provide UUID > Openstack baremetal [node/chassis] activate UUID > Openstack baremetal [node/chassis] rebuild UUID > Openstack baremetal [node/chassis] inspect UUID > Openstack baremetal [node/chassis] manage UUID > Openstack baremetal [node/chassis] abort UUID > Openstack baremetal [node/chassis] boot UUID > Openstack baremetal [node/chassis] shutdown UUID > Openstack baremetal [node/chassis] reboot UUID > > Openstack baremetal node maintain [―done] UUID > Openstack baremetal node console [―enable, ―disable] UUID <― With no > parameters this acts like node-get-console, otherwise acts like > node-set-console-mode > Openstack baremetal node boot-device [―supported, ―PXE, ―CDROM, etc] UUID <― > With no parameters this acts like node-get-boot-device, ―supported makes it > act like node-get-supported-boot-devices, and with a type of boot device > passed in it’ll act like node-set-boot-device > > Openstack baremetal [node/driver] passthru > > WDYT? I think I’ve covered most of what exists in the Ironic CLI currently. +1 To digress a little, Inspector also has a CLI command "openstack baremetal introspection start/status UUID" which will make people confused, WDYT? Best Regards, Yuiko Takada > > Sam > > From: "Haomeng, Wang" > Reply-To: "OpenStack Development Mailing List (not for usage questions)" > > Date: Tuesday, 10 November 2015 11:41 > To: "OpenStack Development Mailing List (not for usage questions)" > > Subject: Re: [openstack-dev] [Ironic] [OSC] Quick poll: OpenStackClient > command for provision action > > Hi Sam, > > Yes, I understand your format is： > > #openstack baremetal > > so these can cover all 'node' operations however if we want to cover support > port/chassis/driver and more ironic resources, so how about below proposal? > > #openstack baremetal > > The resource/target can be one item in following list: > > node > port > chassis > driver > ... > > Make sense? > > > > >> On Tue, Nov 10, 2015 at 7:25 PM, Sam Betts (sambetts) >> wrote: >> Openstack baremetal provision provide or ―provide Just doesn’t feel right to >> me, it feels like I am typing more that I need to and it feels like I’m >> telling it to do the same action twice. >> >> I would much rather see: >> >> Openstack baremetal provide UUID >> Openstack baremetal activate UUID >> Openstack baremetal delete UUID >> Openstack baremetal rebuild UUID >> Openstack baremetal inspect UUID >> Openstack baremetal manage UUID >> Openstack baremetal abort UUID >> >> And for power: >> >> Openstack baremetal boot UUID >> Openstack beremetal shutdown UUID >> Openstack baremetal reboot UUID >> >> WDYT? >> >> Sam >> >> From: "Haomeng, Wang" >> Reply-To: "OpenStack Development Mailing List (not for usage questions)" >> >> Date: Tuesday, 10 November 2015 10:49 >> To: "OpenStack Development Mailing List (not for usage questions)" >> >> Subject: Re: [openstack-dev] [Ironic] [OSC] Quick poll: OpenStackClient >> command for provision action >> >> >> How about below format? >> >> #openstack baremetal >> >> Example: >> >> #openstack baremetal provision provide >> #openstack baremetal power on/off >> >> I think it is easy to understand and remember:) >> >> >> >>> On Tue, Nov 10, 2015 at 6:17 PM, Pavlo Shchelokovskyy >>> wrote: >>> Hi, >>> I like the last variant by Lucas, and agree we need to ensure the CLI >>> interface is consistent between power and provision commands. >>> >>> Best regards, >>> >>> >>>> On Tue, Nov 10, 2015 at 12:00 PM Lucas Alvares Gomes >>>> wrote: >>>> > It's still not 100% consistent, "power" is a noun, "provision" is a verb. >>>> >
Re: [openstack-dev] [Ironic] [Inspector] Addition to ironic-inspector-core: Sam Betts
Sam, congrats and welcome! Yuiko Takada 2015/08/25 19:53、Dmitry Tantsur のメッセージ: > Hi all! > > Please join me in welcoming Sam to our team! He has been doing very smart > reviews recently, was contributing core features and expressed clear interest > in the ironic-inspector project. > > Thanks and welcome! > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Should project name be uppercase or lowercase?
Hi folks, I found the difference between wiki[1] and governance[2]. wiki says "Generally the capitalization of the project team names like swift is lowercase." But in governance, written as uppercase like "Nova", "Swift". How do you think which should we use uppercase vs lowercase for representing project names? [1]https://wiki.openstack.org/wiki/Documentation/Conventions [2] http://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml Best Regards, Yuiko Takada __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ironic] [Inspector] Addition to ironic-inspector-core, switching to 2x +2 rule
Thanks for all the support!! I will do my best to meet the expectations of you. Let's make Ironic Inspector better and better together. As our core team grows, I'd like us to try to stick with 2x +2 rules. Up to > now it was mostly "Dmitry approves everything" rule, now let us make sure > we have at least 2 +2 on a patch before merging it, unless it's critical > for release or fixing gate. Don't wait for me to W+1 if you see that patch > already has 2x +2. > > I'd ask the core team to review all the incoming patches. Once our > devstack gate is finally working, review will be a lot easier. Nice :) +2! Best Regards, Yuiko Takada 2015-07-01 17:56 GMT+09:00 Dmitry Tantsur : > Hi all! > > Please welcome Yuiko Takada to ironic-inspector-core team. Yuiko has been > with the team for some time already. She did substantial work on porting > ironic-inspector to Oslo libraries and on our new devstack gate job. > > Thanks Yuiko, it's a pleasure to work with you. > > As our core team grows, I'd like us to try to stick with 2x +2 rules. Up > to now it was mostly "Dmitry approves everything" rule, now let us make > sure we have at least 2 +2 on a patch before merging it, unless it's > critical for release or fixing gate. Don't wait for me to W+1 if you see > that patch already has 2x +2. > > I'd ask the core team to review all the incoming patches. Once our > devstack gate is finally working, review will be a lot easier. > > Cheers, > Dmitry > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [QA] [Ironic] [Inspector] Where should integration tests for non-core projects live now? (Was: Toward 2.0.0 release)
Hi, Dmitry, thank you for putting it up, and also Ken'ichi, thank you for your reply. > Will it be possible to run tests on Ironic as well using plugin from > > ironic-inspector? > > Yeah, it will be possible. > but I'm guessing ironic-inspector is optional and Ironic should not > depend on the gate test result of ironic-inspector. > So maybe you just need to run Ironic tests on ironic-inspector gate > tests, right? Exactly. All we want to do is run Ironic+Ironic-inspector tests on gate. Then, as you and Matt and Dimitry talked about this on IRC few days ago, We can add Ironic/Ironic-inspector tests into Tempest still, right? So that I've started to implement a test in Tempest, but I'm facing another issue. As you know, Ironic API has microversions, and Ironic-inspector can run with microversion > 1.6. But currently there is no feature testing specific Ironic API microversions on Tempest, right? So that, we have to think about some solutions. (1) Make testing specific Ironic API microversions on Tempest possible adam_g is posting this patch set. https://review.openstack.org/166386 (2)Using tempest_lib instead of adding tests into Tempest Is tempest_lib available already? Or do we need to wait for something will be merged? (3)Make Ironic-inspector available even if microversion < 1.6 Dmitry is posting this patch set. https://review.openstack.org/192196 # I don't mean asking you to review this, don't worry :p Could you please think about the best and fast solution together? Best Regards, Yuiko Takada 2015-06-10 17:57 GMT+09:00 Ken'ichi Ohmichi : > 2015-06-10 16:48 GMT+09:00 Dmitry Tantsur : > > On 06/10/2015 09:40 AM, Ken'ichi Ohmichi wrote: > >> To solve it, we have decided the scope of Tempest as the etherpad > >> mentioned. > >> > >>> Are there any hints now on where we can start with our integration > tests? > >> > >> > >> For the other projects, we are migrating the test framework of Tempest > >> to tempest-lib which is a library. > >> So each project can implement their own tests in each repository by > >> using the test framework of tempest-lib. > > > > > > So in my case we can start with putting test code to ironic-inspector > tree > > using tempest-lib, right? > > Yeah, right. > Neutron is already doing that. > maybe neutron/tests/api/ of Neutron repository will be a hint for it. > > > Will it be possible to run tests on Ironic as well using plugin from > > ironic-inspector? > > Yeah, it will be possible. > but I'm guessing ironic-inspector is optional and Ironic should not > depend on the gate test result of ironic-inspector. > So maybe you just need to run Ironic tests on ironic-inspector gate > tests, right? > > >>> After a quick look at devstack-gate I got an impression that it's > >>> expecting > >>> tests as part of tempest: > >>> > >>> > https://github.com/openstack-infra/devstack-gate/blob/master/devstack-vm-gate.sh#L600 > >>> > >>> Our final goal is to have devstack gate test for Ironic and Inspector > >>> projects working together. > >> > >> > >> We have discussed external interfaces of Tempest on the summit, so > >> that Tempest gathers tests from each project repository and runs them > >> at the same time. > >> There is a qa-spec for https://review.openstack.org/#/c/184992/ > > > > > > Cool, thanks! Does it mean that devstack-gate will also be updated to > allow > > something like DEVSTACK_GATE_TEMPEST_PLUGINS="https://github.com/...";? > > Yeah, will be. > The idea of this external interface is based on DevStack's one. > I think we will be able to use it on the gate like that. > > Thanks > Ken'ichi Ohmichi > > --- > > >>> On 06/10/2015 08:07 AM, Yuiko Takada wrote: > >>>> > >>>> > >>>> Hi, Dmitry, > >>>> > >>>> I guess the whole idea of new release models is NOT to tie > projects > >>>> to each other any more except for The Big Release twice a year :) > >>>> So > >>>> I think no, we don't need to. We still can do it, if we have > >>>> something to release by the time Ironic releases, but I suggest > >>>> deciding it on case-by-case basis. > >>>> > >>>> OK, I see. > >>>> > >>>> One more concern, about Tempest integration test which I will > implement > >>>> in V2.1.0, > >>>> it seems like that we
Re: [openstack-dev] [Ironic] [Inspector] Toward 2.0.0 release
Hi, Dmitry, I guess the whole idea of new release models is NOT to tie projects to each > other any more except for The Big Release twice a year :) So I think no, we > don't need to. We still can do it, if we have something to release by the > time Ironic releases, but I suggest deciding it on case-by-case basis. OK, I see. One more concern, about Tempest integration test which I will implement in V2.1.0, it seems like that we cannot add Ironic-inspector's tests into Tempest even if integration tests. Please see: https://etherpad.openstack.org/p/YVR-QA-in-the-big-tent But I heard from you that Devananda thinks we need this in tempest itself. [3] Do you know something like current situation? Best Regards, Yuiko Takada 2015-06-09 15:59 GMT+09:00 Dmitry Tantsur : > On 06/09/2015 03:49 AM, Yuiko Takada wrote: > >> Hi, Dmitry, >> >> Thank you for notifying. >> >> I've updated our summit etherpad [3] with whatever priorities I >> remembered, please have a look. I've also untargeted a few things in >> launchpad [4] (and will probably untarget more later on). Please >> assign yourself, if you want something done in this release time >> frame. >> >> I've assigned one item to myself in [3], and also I added one BP to [4], >> so please take a look. >> https://blueprints.launchpad.net/ironic-inspector/+spec/delete-db-api >> > > Looks good, though I don't think it's a big priority for 2.0.0. Definitely > worth doing for 2.1.0. > > Thanks for assigning for tempest work, that's definitely a priority right > now. > > >> BTW, how do you think about Ironic-inspector's release model? >> You wrote "Version released with Ironic Liberty" as >> Ironic-inspector Version 2.1.0 in etherpad [3], >> but as you know, Ironic's release model has changed to feature >> releases.(right?) >> Should we make our release model same as Ironic? >> > > I guess the whole idea of new release models is NOT to tie projects to > each other any more except for The Big Release twice a year :) So I think > no, we don't need to. We still can do it, if we have something to release > by the time Ironic releases, but I suggest deciding it on case-by-case > basis. > > >> >> Best Regards, >> Yuiko Takada(Inspector team member) >> >> 2015-06-08 20:38 GMT+09:00 Dmitry Tantsur > <mailto:dtant...@redhat.com>>: >> >> >> Hello, Inspector team! >> >> The renaming process is going pretty well, the last thing we need to >> do is to get Infra approval and actual rename [1][2]. >> >> I'd like to allow people (e.g. myself) to start packaging inspector >> under it's new name, so I'd like to make 2.0.0 release as soon as >> possible (as opposed to scheduling it to particular date). All >> breaking changes should land by this release - I don't expect 3.0.0 >> soon :) >> >> I've updated our summit etherpad [3] with whatever priorities I >> remembered, please have a look. I've also untargeted a few things in >> launchpad [4] (and will probably untarget more later on). Please >> assign yourself, if you want something done in this release time >> frame. >> >> I would like 2.1.0 to be released with Ironic Liberty and be >> properly supported. >> >> Let me know what you think. >> >> Cheers, >> Dmitry >> >> [1] https://review.openstack.org/#/c/188030/ >> [2] https://review.openstack.org/#/c/188798/ >> [3] https://etherpad.openstack.org/p/liberty-ironic-discoverd >> [4] https://bugs.launchpad.net/ironic-inspector/+milestone/2.0.0 >> >> >> __ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> <http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> >> >> >> __ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ironic] [Inspector] Toward 2.0.0 release
Hi, Dmitry, Thank you for notifying. I've updated our summit etherpad [3] with whatever priorities I remembered, > please have a look. I've also untargeted a few things in launchpad [4] (and > will probably untarget more later on). Please assign yourself, if you want > something done in this release time frame. > I've assigned one item to myself in [3], and also I added one BP to [4], so please take a look. https://blueprints.launchpad.net/ironic-inspector/+spec/delete-db-api BTW, how do you think about Ironic-inspector's release model? You wrote "Version released with Ironic Liberty" as Ironic-inspector Version 2.1.0 in etherpad [3], but as you know, Ironic's release model has changed to feature releases.(right?) Should we make our release model same as Ironic? Best Regards, Yuiko Takada(Inspector team member) 2015-06-08 20:38 GMT+09:00 Dmitry Tantsur : > Hello, Inspector team! > > The renaming process is going pretty well, the last thing we need to do is > to get Infra approval and actual rename [1][2]. > > I'd like to allow people (e.g. myself) to start packaging inspector under > it's new name, so I'd like to make 2.0.0 release as soon as possible (as > opposed to scheduling it to particular date). All breaking changes should > land by this release - I don't expect 3.0.0 soon :) > > I've updated our summit etherpad [3] with whatever priorities I > remembered, please have a look. I've also untargeted a few things in > launchpad [4] (and will probably untarget more later on). Please assign > yourself, if you want something done in this release time frame. > > I would like 2.1.0 to be released with Ironic Liberty and be properly > supported. > > Let me know what you think. > > Cheers, > Dmitry > > [1] https://review.openstack.org/#/c/188030/ > [2] https://review.openstack.org/#/c/188798/ > [3] https://etherpad.openstack.org/p/liberty-ironic-discoverd > [4] https://bugs.launchpad.net/ironic-inspector/+milestone/2.0.0 > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
